jeongsup.jeong [Fri, 24 Apr 2020 10:08:09 +0000 (19:08 +0900)]
arm64: dts: tw3: use array for motor strength and frequency setting for multiple level
Add new properties data to devicetree in order to support
the new motor parameters.
Change-Id: Ieb2255ecc48a03fdc6783086ad406316722c9d05
Signed-off-by: jeongsup.jeong <jeongsup.jeong@samsung.com>
[cw00.choi: Add commit-msg as the public style]
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
jeongsup.jeong [Wed, 25 Mar 2020 10:30:57 +0000 (19:30 +0900)]
Motor: use default frequency when platform frequency request is predefined value, 0
Change the default value of frequency from 1 to 0 as following:
- 0 (Use default frequency)
- 1 ~ 8191 (0.1 ~ 819.1 Hz)
And check whether intensity_level is valid or in the early ztm620_motor_run()
function. The intensity_level should be less than count_strength and
count_frequency. The number of count_strength and count_frequency are fixed
according to the h/w device. Each h/w device specifies the number of
count_strength and count_frequency in their own devicetree.
Change-Id: Ie3fd07fbbbf41f72726149864cc0dbe2ac9c71d3
Signed-off-by: jeongsup.jeong <jeongsup.jeong@samsung.com>
[cw00.choi: Add commig-msg as the public style]
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
jeongsup.jeong [Fri, 27 Dec 2019 06:09:50 +0000 (15:09 +0900)]
Motor: change motor control parameters for new haptic concept
Change the motor control parameters which are used for communicating
between feedbackd in user-space and motor device driver in kernel.
[Detailed motor control parameters]
struct ff_rumble_effect {
__u16 strong_magnitude; // strong_magnitude[15:15] = 0 (Reserved)
// strong_magnitude[14:14]
// = Overdrive : 0 (Off) or 1 (On)
// strong_magnitude[13:0]
// = Intensity Value : 0 (Stop)
// or 1 ~ 10000 (Intensity)
__u16 weak_magnitude; // weak_magnitude[15:13]
// = Intensity Level : 1 ~ 5
// weak_magnitude[12:0]
// = Frequency in 0.1Hz : 0 ~ 8191 (0 ~ 819.1 Hz)
}; */
Change-Id: I9ec052003b099f4dddeeecaea3ee9517673158a2
Signed-off-by: jeongsup.jeong <jeongsup.jeong@samsung.com>
[cw00.choi: Add commit-msg as the public style]
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
jeongsup.jeong [Mon, 22 Jul 2019 09:39:34 +0000 (18:39 +0900)]
Motor: add handling freq, overdrive param on ff effect
In order to handle the motor behavior in details,
add new 'frequency' and 'overdrive' parameter for ff (force feedback) effect.
Use the existing 'struct ff_runbm_effect' without any added variable
to pass the user data to input device driver of kernel.
Change-Id: I09a920efe80babaf9e758918ab870dab62c7611b
Signed-off-by: jeongsup.jeong <jeongsup.jeong@samsung.com>
[cw00.choi: Add commit-msg as public style and fix the merge conflict]
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
jeongsup.jeong [Thu, 13 Jun 2019 04:36:32 +0000 (13:36 +0900)]
Motor: ztm620: add motor status interface
Add exported ztm620_motor_is_running() function to inform the motor state
to outside of ztm620 device driver.
Change-Id: Ib0596c106bac5f4a387d821cd86ce59e4a638279
Signed-off-by: jeongsup.jeong <jeongsup.jeong@samsung.com>
[cw00.choi: Add commit-msg as the public style]
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
woochul.shin [Wed, 6 May 2020 09:56:00 +0000 (18:56 +0900)]
motor: ztm620: set dc motor dt and add switch motor type
Modify the motor data such as motor_start_data and motor_stop_dat
according to the motor type. Each h/w device is able to select
the their own motor type in devicetree.
Example of the motor type,
- TW3's motor type is LRA
Change-Id: If584ffab5c265f56266536b50d9fdab468cb0044
Signed-off-by: woochul.shin <woochul.shin@samsung.com>
[cw00.choi: Add commig-msg as the public style]
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
jeongsup.jeong [Tue, 20 Nov 2018 04:50:58 +0000 (13:50 +0900)]
Motor: ztm620: add pm_notifier
Add PM Notifier in order to control the state of motor device.
When PM_SUSPEND_PREPARE, disable the motor and in case of PM_POST_SUSPEND,
enable motor device. And do refactor the code for the readability.
Change-Id: I6e99c72ba4af08d614f8969a1bf9890614fe73b7
Signed-off-by: jeongsup.jeong <jeongsup.jeong@samsung.com>
[cw00.choi: Add commig-msg as the public style]
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
lsmin.lee [Fri, 3 Jan 2020 09:31:42 +0000 (18:31 +0900)]
Input: tizen_bezel: Change event value of the bezel device
Until Tizen 5.0, for bezel input device, its event value was in
between -2 and 2, but value 1. meant starting movement to
counter clockwiseare or clockwise, and value -1, meant moving back
to original position, never used. Change event value of the bezel
device for Tizen 5.5 and later version.
It changes bezel input driver event interface, so user input
framework for bezel input should be also changed.
Ref: https://review.tizen.org/gerrit/#/c/platform/upstream/enlightenment/+/220346/
Signed-off-by: lsmin.lee <lsmin.lee@samsung.com>
[sw0312.kim: adjust commit-msg to public style]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I1293db138c71d2a5c4f52b827f3a441b47710449
Matias Karhumaa [Wed, 26 Sep 2018 06:13:46 +0000 (09:13 +0300)]
Bluetooth: SMP: fix crash in unpairing
[ Upstream commit
cb28c306b93b71f2741ce1a5a66289db26715f4d ]
In case unpair_device() was called through mgmt interface at the same time
when pairing was in progress, Bluetooth kernel module crash was seen.
[ 600.351225] general protection fault: 0000 [#1] SMP PTI
[ 600.351235] CPU: 1 PID: 11096 Comm: btmgmt Tainted: G OE 4.19.0-rc1+ #1
[ 600.351238] Hardware name: Dell Inc. Latitude E5440/08RCYC, BIOS A18 05/14/2017
[ 600.351272] RIP: 0010:smp_chan_destroy.isra.10+0xce/0x2c0 [bluetooth]
[ 600.351276] Code: c0 0f 84 b4 01 00 00 80 78 28 04 0f 84 53 01 00 00 4d 85 ed 0f 85 ab 00 00 00 48 8b 08 48 8b 50 08 be 10 00 00 00 48 89 51 08 <48> 89 0a 48 b9 00 02 00 00 00 00 ad de 48 89 48 08 48 8b 83 00 01
[ 600.351279] RSP: 0018:
ffffa9be839b3b50 EFLAGS:
00010246
[ 600.351282] RAX:
ffff9c999ac565a0 RBX:
ffff9c9996e98c00 RCX:
ffff9c999aa28b60
[ 600.351285] RDX:
dead000000000200 RSI:
0000000000000010 RDI:
ffff9c999e403500
[ 600.351287] RBP:
ffffa9be839b3b70 R08:
0000000000000000 R09:
ffffffff92a25c00
[ 600.351290] R10:
ffffa9be839b3ae8 R11:
0000000000000001 R12:
ffff9c995375b800
[ 600.351292] R13:
0000000000000000 R14:
ffff9c99619a5000 R15:
ffff9c9962a01c00
[ 600.351295] FS:
00007fb2be27c700(0000) GS:
ffff9c999e880000(0000) knlGS:
0000000000000000
[ 600.351298] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 600.351300] CR2:
00007fb2bdadbad0 CR3:
000000041c328001 CR4:
00000000001606e0
[ 600.351302] Call Trace:
[ 600.351325] smp_failure+0x4f/0x70 [bluetooth]
[ 600.351345] smp_cancel_pairing+0x74/0x80 [bluetooth]
[ 600.351370] unpair_device+0x1c1/0x330 [bluetooth]
[ 600.351399] hci_sock_sendmsg+0x960/0x9f0 [bluetooth]
[ 600.351409] ? apparmor_socket_sendmsg+0x1e/0x20
[ 600.351417] sock_sendmsg+0x3e/0x50
[ 600.351422] sock_write_iter+0x85/0xf0
[ 600.351429] do_iter_readv_writev+0x12b/0x1b0
[ 600.351434] do_iter_write+0x87/0x1a0
[ 600.351439] vfs_writev+0x98/0x110
[ 600.351443] ? ep_poll+0x16d/0x3d0
[ 600.351447] ? ep_modify+0x73/0x170
[ 600.351451] do_writev+0x61/0xf0
[ 600.351455] ? do_writev+0x61/0xf0
[ 600.351460] __x64_sys_writev+0x1c/0x20
[ 600.351465] do_syscall_64+0x5a/0x110
[ 600.351471] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 600.351474] RIP: 0033:0x7fb2bdb62fe0
[ 600.351477] Code: 73 01 c3 48 8b 0d b8 6e 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 69 c7 2c 00 00 75 10 b8 14 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 de 80 01 00 48 89 04 24
[ 600.351479] RSP: 002b:
00007ffe062cb8f8 EFLAGS:
00000246 ORIG_RAX:
0000000000000014
[ 600.351484] RAX:
ffffffffffffffda RBX:
000000000255b3d0 RCX:
00007fb2bdb62fe0
[ 600.351487] RDX:
0000000000000001 RSI:
00007ffe062cb920 RDI:
0000000000000004
[ 600.351490] RBP:
00007ffe062cb920 R08:
000000000255bd80 R09:
0000000000000000
[ 600.351494] R10:
0000000000000353 R11:
0000000000000246 R12:
0000000000000001
[ 600.351497] R13:
00007ffe062cbbe0 R14:
0000000000000000 R15:
0000000000000000
[ 600.351501] Modules linked in: algif_hash algif_skcipher af_alg cmac ipt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo iptable_nat nf_nat_ipv4 xt_addrtype iptable_filter ip_tables xt_conntrack x_tables nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c br_netfilter bridge stp llc overlay arc4 nls_iso8859_1 dm_crypt intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp dell_laptop kvm_intel crct10dif_pclmul dell_smm_hwmon crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd cryptd glue_helper intel_cstate intel_rapl_perf uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev media hid_multitouch input_leds joydev serio_raw dell_wmi snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic dell_smbios dcdbas sparse_keymap
[ 600.351569] snd_hda_intel btusb snd_hda_codec btrtl btbcm btintel snd_hda_core bluetooth(OE) snd_hwdep snd_pcm iwlmvm ecdh_generic wmi_bmof dell_wmi_descriptor snd_seq_midi mac80211 snd_seq_midi_event lpc_ich iwlwifi snd_rawmidi snd_seq snd_seq_device snd_timer cfg80211 snd soundcore mei_me mei dell_rbtn dell_smo8800 mac_hid parport_pc ppdev lp parport autofs4 hid_generic usbhid hid i915 nouveau kvmgt vfio_mdev mdev vfio_iommu_type1 vfio kvm irqbypass i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt mxm_wmi psmouse ahci sdhci_pci cqhci libahci fb_sys_fops sdhci drm e1000e video wmi
[ 600.351637] ---[ end trace
e49e9f1df09c94fb ]---
[ 600.351664] RIP: 0010:smp_chan_destroy.isra.10+0xce/0x2c0 [bluetooth]
[ 600.351666] Code: c0 0f 84 b4 01 00 00 80 78 28 04 0f 84 53 01 00 00 4d 85 ed 0f 85 ab 00 00 00 48 8b 08 48 8b 50 08 be 10 00 00 00 48 89 51 08 <48> 89 0a 48 b9 00 02 00 00 00 00 ad de 48 89 48 08 48 8b 83 00 01
[ 600.351669] RSP: 0018:
ffffa9be839b3b50 EFLAGS:
00010246
[ 600.351672] RAX:
ffff9c999ac565a0 RBX:
ffff9c9996e98c00 RCX:
ffff9c999aa28b60
[ 600.351674] RDX:
dead000000000200 RSI:
0000000000000010 RDI:
ffff9c999e403500
[ 600.351676] RBP:
ffffa9be839b3b70 R08:
0000000000000000 R09:
ffffffff92a25c00
[ 600.351679] R10:
ffffa9be839b3ae8 R11:
0000000000000001 R12:
ffff9c995375b800
[ 600.351681] R13:
0000000000000000 R14:
ffff9c99619a5000 R15:
ffff9c9962a01c00
[ 600.351684] FS:
00007fb2be27c700(0000) GS:
ffff9c999e880000(0000) knlGS:
0000000000000000
[ 600.351686] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 600.351689] CR2:
00007fb2bdadbad0 CR3:
000000041c328001 CR4:
00000000001606e0
Crash happened because list_del_rcu() was called twice for smp->ltk. This
was possible if unpair_device was called right after ltk was generated
but before keys were distributed.
In this commit smp_cancel_pairing was refactored to cancel pairing if it
is in progress and otherwise just removes keys. Once keys are removed from
rcu list, pointers to smp context's keys are set to NULL to make sure
removed list items are not accessed later.
This commit also adjusts the functionality of mgmt unpair_device() little
bit. Previously pairing was canceled only if pairing was in state that
keys were already generated. With this commit unpair_device() cancels
pairing already in earlier states.
Bug was found by fuzzing kernel SMP implementation using Synopsys
Defensics.
Reported-by: Pekka Oikarainen <pekka.oikarainen@synopsys.com>
Signed-off-by: Matias Karhumaa <matias.karhumaa@gmail.com>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[dh79.pyun: apply mainline stable linux-4.9.y commit
83e158f93d66 to handle BT crash issue]
Signed-off-by: DoHyun Pyun <dh79.pyun@samsung.com>
Change-Id: Iaa7196d5bb49fe993ba9ca0bf9b9a1eece7b6200
Szymon Janc [Mon, 26 Feb 2018 14:41:53 +0000 (15:41 +0100)]
Bluetooth: Fix missing encryption refresh on Security Request
commit
64e759f58f128730b97a3c3a26d283c075ad7c86 upstream.
If Security Request is received on connection that is already encrypted
with sufficient security master should perform encryption key refresh
procedure instead of just ignoring Slave Security Request
(Core Spec 5.0 Vol 3 Part H 2.4.6).
> ACL Data RX: Handle 3585 flags 0x02 dlen 6
SMP: Security Request (0x0b) len 1
Authentication requirement: Bonding, No MITM, SC, No Keypresses (0x09)
< HCI Command: LE Start Encryption (0x08|0x0019) plen 28
Handle: 3585
Random number: 0x0000000000000000
Encrypted diversifier: 0x0000
Long term key:
44264272a5c426a9e868f034cf0e69f3
> HCI Event: Command Status (0x0f) plen 4
LE Start Encryption (0x08|0x0019) ncmd 1
Status: Success (0x00)
> HCI Event: Encryption Key Refresh Complete (0x30) plen 3
Status: Success (0x00)
Handle: 3585
Signed-off-by: Szymon Janc <szymon.janc@codecoup.pl>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[dh79.pyun: apply mainline stable linux-4.9.y commit
24382a60331d to handle BT issue]
Signed-off-by: DoHyun Pyun <dh79.pyun@samsung.com>
Change-Id: Ifb94f389253d8515bcc4676fffcfd73c09f1242c
Seung-Woo Kim [Tue, 22 Oct 2019 08:46:13 +0000 (17:46 +0900)]
soc: samsung: cal-if: exynos9110: remove clocks for secure world
In exynos9110, some clocks are protected by trustzone secure world,
and accessing them causes system abort. Not to access the clocks from
kernel in normal world, remove the clocks protected by secure
world including ispp, vts, mfcmscl, g3dp, chubp.
Change-Id: I6ef4de7bbb77f50492cc34f90f7e012fa55395cf
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Seung-Woo Kim [Tue, 22 Oct 2019 10:45:52 +0000 (19:45 +0900)]
soc: samsung: cal-if: exynos9110: remove a clock for unassigned block
From exynos9110 clock sfr, sfr of BLK_MODEM is set as just 0 and
that means it is not assigned. Accessing clock for the block
causes memory abort accessing wrong address. So remove the clock
for unassigned modem block.
Change-Id: Id880ed48ef8d01f4d8c348642fdcffc4004997fd
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Seung-Woo Kim [Tue, 22 Oct 2019 01:52:24 +0000 (10:52 +0900)]
video: fbdev: exynos: dpu9110: fix null pointer deference for recovery_cnt
There is no drvdata for specific instance of dpp when it is not
assigned from dt, and accessing it without null check causes null
pointer deference. Fix the null pointer defercens when accessing
recovery_cnt.
Change-Id: Ie57024101d461b1135f341bd1f76b55d0d77ec73
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Seung-Woo Kim [Wed, 31 Jul 2019 07:31:01 +0000 (16:31 +0900)]
arm64: tizen_tw3_defconfig: Enable NETFILTER_XT_MATCH_OWNER config
Enable the NETFILTER_XT_MATCH_OWNER config option to use xt_owner
supplementary groups.
Change-Id: I3c40c2d41dd29eede403f430887aab8f1ee4eaea
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Pablo Neira Ayuso [Fri, 7 Jun 2019 14:37:30 +0000 (16:37 +0200)]
netfilter: xt_owner: bail out with EINVAL in case of unsupported flags
Reject flags that are not supported with EINVAL.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
[sw0312.kim: backport from mainline to support supplementary groups on netfilter]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I178cb193c6593b40d004e3110e512fcd5627d125
Lukasz Pawelczyk [Fri, 10 May 2019 11:46:22 +0000 (13:46 +0200)]
netfilter: xt_owner: Add supplementary groups option
The XT_OWNER_SUPPL_GROUPS flag causes GIDs specified with XT_OWNER_GID
to be also checked in the supplementary groups of a process.
f_cred->group_info cannot be modified during its lifetime and f_cred
holds a reference to it so it's safe to use.
Signed-off-by: Lukasz Pawelczyk <l.pawelczyk@samsung.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
[sw0312.kim: backport from mainline to support supplementary groups on netfilter]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: If8a18f3c90378800fdee702c4eb0d7ec7c8c744e
Jaechul Lee [Wed, 15 May 2019 07:17:02 +0000 (16:17 +0900)]
arm64: dts: exynos: Support offload playback
Change-Id: I9a000740ef332018484f4a055baa700b27093821
Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
Jaehoon Chung [Fri, 8 Feb 2019 09:39:50 +0000 (18:39 +0900)]
script: release.sh: allow the local build on 32bit machine
Allow the local build on 32bit machine, not only 64bit machine.
Change-Id: I7b8d9769bb1426b41ebde7b4eb8a5a74b6c3d5d6
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Hoegeun Kwon [Fri, 11 Jan 2019 00:55:37 +0000 (09:55 +0900)]
drm/tgm: tdm_pp: fix not to call sync fence without fence/dma_buf
When without fence or dma_buf, tdm_pp tries to call sync fence and
it causes null deference or not necessary error message. Fix not
to call sync fence without fence or dma_buf.
Change-Id: Ic762185f1934c7dd0489a2dc8332d5bace29bae5
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
Seung-Woo Kim [Wed, 9 Jan 2019 03:51:56 +0000 (12:51 +0900)]
arm64: tizen_tw3_defconfig: enable SECURITY_SMACK_APPEND_SIGNALS
Enable SECURITY_SMACK_APPEND_SIGNALS to allow smack rules denying
signal delivery while allowing IPC in Tizen.
Change-Id: If438465b6ced7f529baf69754555778eb554c6c5
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Seung-Woo Kim [Wed, 9 Jan 2019 03:45:55 +0000 (12:45 +0900)]
arm64: tizen_tw3_defconfig: enable CONNECTOR and PROC_EVENTS options
These options enable Netlink Connector feature of kernel to monitor
process lifecycle like Fork and Exit status of all processes
asynchronously.
In Tzen, it will be used by stc-manager(smart traffic control) to
monitor process lifecycle.
Change-Id: I265504609e6b2ce963875e66884d064affc48d9d
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Roman Gushchin [Fri, 17 Nov 2017 23:26:45 +0000 (15:26 -0800)]
proc, coredump: add CoreDumping flag to /proc/pid/status
Right now there is no convenient way to check if a process is being
coredumped at the moment.
It might be necessary to recognize such state to prevent killing the
process and getting a broken coredump. Writing a large core might take
significant time, and the process is unresponsive during it, so it might
be killed by timeout, if another process is monitoring and
killing/restarting hanging tasks.
We're getting a significant number of corrupted coredump files on
machines in our fleet, just because processes are being killed by
timeout in the middle of the core writing process.
We do have a process health check, and some agent is responsible for
restarting processes which are not responding for health check requests.
Writing a large coredump to the disk can easily exceed the reasonable
timeout (especially on an overloaded machine).
This flag will allow the agent to distinguish processes which are being
coredumped, extend the timeout for them, and let them produce a full
coredump file.
To provide an ability to detect if a process is in the state of being
coredumped, we can expose a boolean CoreDumping flag in
/proc/pid/status.
Example:
$ cat core.sh
#!/bin/sh
echo "|/usr/bin/sleep 10" > /proc/sys/kernel/core_pattern
sleep 1000 &
PID=$!
cat /proc/$PID/status | grep CoreDumping
kill -ABRT $PID
sleep 1
cat /proc/$PID/status | grep CoreDumping
$ ./core.sh
CoreDumping: 0
CoreDumping: 1
[guro@fb.com: document CoreDumping flag in /proc/<pid>/status]
Link: http://lkml.kernel.org/r/20170928135357.GA8470@castle.DHCP.thefacebook.com
Link: http://lkml.kernel.org/r/20170920230634.31572-1-guro@fb.com
Signed-off-by: Roman Gushchin <guro@fb.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Konstantin Khlebnikov <koct9i@gmail.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[sw0312.kim: backport mainline commit
c643401218be to allow Tizen system recognizes coredump status]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I32d92f59d203b9ff081420b95ad2f8329893657f
Seung-Woo Kim [Mon, 12 Dec 2016 08:35:26 +0000 (17:35 +0900)]
Smack: ignore private inode for file functions
The access to fd from anon_inode is always failed because there is
no set xattr operations. So this patch fixes to ignore private
inode including anon_inode for file functions.
It was only ignored for smack_file_receive() to share dma-buf fd,
but dma-buf has other functions like ioctl and mmap.
Reference: https://lkml.org/lkml/2015/4/17/16
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
[sw0312.kim: backport mainline commit
83a1e53f3920 for Tizen security smack]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: I31719d13885b63ebd643fe03565314ad7d65ee3c
Rafal Krypa [Fri, 9 Dec 2016 13:03:04 +0000 (14:03 +0100)]
Smack: fix d_instantiate logic for sockfs and pipefs
Since
4b936885a (v2.6.32) all inodes on sockfs and pipefs are disconnected.
It caused filesystem specific code in smack_d_instantiate to be skipped,
because all inodes on those pseudo filesystems were treated as root inodes.
As a result all sockfs inodes had the Smack label set to floor.
In most cases access checks for sockets use socket_smack data so the inode
label is not important. But there are special cases that were broken.
One example would be calling fcntl with F_SETOWN command on a socket fd.
Now smack_d_instantiate expects all pipefs and sockfs inodes to be
disconnected and has the logic in appropriate place.
Signed-off-by: Rafal Krypa <r.krypa@samsung.com>
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
[sw0312.kim: backport mainline commit
805b65a80bed for Tizen security smack]
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Change-Id: Ib60a38ea4173df99ef1998e4ef5eba215a63c38a
Jaechul Lee [Wed, 9 Jan 2019 00:52:06 +0000 (09:52 +0900)]
ASoC: samsung: abox:changes ABOX_ROUTE_CTRL1 initial value
ABOX_ROUTE_CTRL1 register needs to be set UAIF0(0x8) because pulseaudio
fails to load the source module at booting.
Change-Id: Ia38aaa925fe542edeeccee860c19f0a9368fc870
Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
Seung-Woo Kim [Fri, 4 Jan 2019 06:59:39 +0000 (15:59 +0900)]
ARM64: tizen_tw3_defconfig: enable MODULES
To support kernel modules build, loading, and unloading enable config
option MODULES and force loading and unloading options.
Note: in tizen, to support swap-modules, it is required to support
kernel module build.
Change-Id: If67e5a8c5ae91c632a3225244a385ac9ff26728b
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Seung-Woo Kim [Fri, 4 Jan 2019 06:56:18 +0000 (15:56 +0900)]
kconfig: fix not to select TIMA_LKMAUTH from MODULES
TIMA_LKMAUTH prevents loading modules built for development. Fix
not to select TIMA_LKMAUTH by selecting MODULES for possibility
to set the config option.
Change-Id: I65b084ff31e7428296d8995ecb1a9c7a005118c8
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Seung-Woo Kim [Fri, 4 Jan 2019 07:35:32 +0000 (16:35 +0900)]
arm64: tizen_tw3_defconfig: disable SWAP_DA config.
To use swap-modules instead of in-tree SWAP_DA, disable related
configs.
Change-Id: I773919821d2e3443878b44672b1d67617f425e8c
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Seung-Woo Kim [Mon, 17 Dec 2018 08:42:04 +0000 (17:42 +0900)]
sensorhub: remove unreachable log printing
Remove unreachable log printing which causes build warning with
-Wswitch-unreachable.
Change-Id: I7775546c9aabf588169ff7facfeba598d6a62a9f
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Seung-Woo Kim [Thu, 6 Sep 2018 02:00:16 +0000 (11:00 +0900)]
net: bcmdhd: remove gcc 7 build warnings
Remove following gcc 7 build warnings:
drivers/net/wireless/bcmdhd/dhd_common.c: In function ‘dhd_pktfilter_offload_set’:
drivers/net/wireless/bcmdhd/dhd_common.c:3015:16: error: comparison between pointer and zero character constant [-Werror=pointer-compare]
if (argv[i] == '\0') {
^~
drivers/net/wireless/bcmdhd/dhd_common.c:3015:8: note: did you mean to dereference the pointer?
if (argv[i] == '\0') {
^
drivers/net/wireless/bcmdhd/dhd_rtt.c: In function ‘dhd_rtt_init’:
drivers/net/wireless/bcmdhd/dhd_rtt.c:983:56: error: ‘subcmd_info.version’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
*out_version = (ret == BCME_OK) ? subcmd_info.version : 0;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
drivers/net/wireless/bcmdhd/dhd_rtt.c:977:20: note: ‘subcmd_info.version’ was declared here
ftm_subcmd_info_t subcmd_info;
^~~~~~~~~~~
Change-Id: I5990eaba2272ecb9633bb0058668eb426fc99d2e
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Seung-Woo Kim [Mon, 17 Dec 2018 08:34:36 +0000 (17:34 +0900)]
Input: zxt_ztm620_ts: fix incorrect memset size parameter
Fix incorrect memset size parameter which caueses build warnings
for -Wmemset-elt-size.
Change-Id: I15b8014149eb52106ebc7ddd7412acb50cfe0464
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Seung-Woo Kim [Mon, 17 Dec 2018 07:27:31 +0000 (16:27 +0900)]
packaging: exclude arch for non arm
For tw3, it is not required to build on non arm arch. exclude non
arm arch by adding ExclusiveArch: armv7l and aarch64.
Note: for aarch64, it really builds binary and for armv7l, only
headers package is built.
Change-Id: I5c4f15a997aec1da3e7d89509f3affd0dc43ff5e
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Jaehoon Chung [Thu, 13 Dec 2018 07:30:03 +0000 (16:30 +0900)]
packaging: added baselibs.conf for building armv7l arch
It also needs to build kernel based on armv7l.
Change-Id: Ic04336b57d5f60e8bcad31b710a2056d1e116e33
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Jaehoon Chung [Tue, 11 Dec 2018 07:57:53 +0000 (16:57 +0900)]
ARM64: configs: tizen_tw3_defconfig: disable modem interface config
Disable modem interface configurations.
This config is based on galileo large config.
(Previous config was based on galileo large lte na.)
Change-Id: If3de5097a78e258f8ffbba4c16977e0337a7f0e4
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Jaehoon Chung [Thu, 6 Dec 2018 22:58:27 +0000 (07:58 +0900)]
packaging: use upstream tags with .gbs.conf
To build properly with upstream version tag in obs, add .gbs.conf.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Jaehoon Chung [Wed, 5 Dec 2018 01:01:01 +0000 (10:01 +0900)]
ARM64: defconfig: use the bootloader's cmmdline
Use bootloader's cmdline.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Jaehoon Chung [Mon, 3 Dec 2018 11:58:48 +0000 (20:58 +0900)]
packaging: spec: modify linux-4.9-exynos9110 spec file for gbs build
Modify linux-4.9-exynos9110 file for gbs build.
It refers to tw2 spec.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Jaehoon Chung [Mon, 3 Dec 2018 11:56:56 +0000 (20:56 +0900)]
script: release_obs.sh: change to more simple build script
Change to more simple build script for obs.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Jaehoon Chung [Mon, 3 Dec 2018 11:04:55 +0000 (20:04 +0900)]
script: release.sh: use tizen_tw3_defconfig
Use tizen_tw3_defconfig instead of variant kconfig.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Jaehoon Chung [Mon, 3 Dec 2018 10:52:53 +0000 (19:52 +0900)]
ARM64: configs: add tizen_tw3_defconfig file
Add tizen_tw3_defconfig file.
This config is from Galileo Large Lte Na.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Jaehoon Chung [Mon, 3 Dec 2018 09:40:24 +0000 (18:40 +0900)]
script: release.sh: remove the product specific codes
Remove the product specific codes.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Jaehoon Chung [Mon, 3 Dec 2018 09:28:47 +0000 (18:28 +0900)]
Remove the unnecessary config files
Remove the unnecessary config files.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Jaehoon Chung [Mon, 3 Dec 2018 03:47:33 +0000 (12:47 +0900)]
scripts: add the dtbtool and mkdzimage script files
Add the dtbtool and mkdzimage script files.
This file is from tw2 git repository.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Jaehoon Chung [Fri, 30 Nov 2018 06:40:47 +0000 (15:40 +0900)]
Import codes from product
Impor codes from product.
These codes are from opensource.samsung.com.
- Version : R880XU1ARGB
Greg Kroah-Hartman [Fri, 27 Oct 2017 08:38:11 +0000 (10:38 +0200)]
Linux 4.9.59
Eric Biggers [Mon, 9 Oct 2017 19:40:00 +0000 (12:40 -0700)]
FS-Cache: fix dereference of NULL user_key_payload
commit
d124b2c53c7bee6569d2a2d0b18b4a1afde00134 upstream.
When the file /proc/fs/fscache/objects (available with
CONFIG_FSCACHE_OBJECT_LIST=y) is opened, we request a user key with
description "fscache:objlist", then access its payload. However, a
revoked key has a NULL payload, and we failed to check for this.
request_key() *does* skip revoked keys, but there is still a window
where the key can be revoked before we access its payload.
Fix it by checking for a NULL payload, treating it like a key which was
already revoked at the time it was requested.
Fixes:
4fbf4291aa15 ("FS-Cache: Allow the current state of all objects to be dumped")
Reviewed-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Howells [Wed, 4 Oct 2017 15:43:25 +0000 (16:43 +0100)]
KEYS: Fix race between updating and finding a negative key
commit
363b02dab09b3226f3bd1420dad9c72b79a42a76 upstream.
Consolidate KEY_FLAG_INSTANTIATED, KEY_FLAG_NEGATIVE and the rejection
error into one field such that:
(1) The instantiation state can be modified/read atomically.
(2) The error can be accessed atomically with the state.
(3) The error isn't stored unioned with the payload pointers.
This deals with the problem that the state is spread over three different
objects (two bits and a separate variable) and reading or updating them
atomically isn't practical, given that not only can uninstantiated keys
change into instantiated or rejected keys, but rejected keys can also turn
into instantiated keys - and someone accessing the key might not be using
any locking.
The main side effect of this problem is that what was held in the payload
may change, depending on the state. For instance, you might observe the
key to be in the rejected state. You then read the cached error, but if
the key semaphore wasn't locked, the key might've become instantiated
between the two reads - and you might now have something in hand that isn't
actually an error code.
The state is now KEY_IS_UNINSTANTIATED, KEY_IS_POSITIVE or a negative error
code if the key is negatively instantiated. The key_is_instantiated()
function is replaced with key_is_positive() to avoid confusion as negative
keys are also 'instantiated'.
Additionally, barriering is included:
(1) Order payload-set before state-set during instantiation.
(2) Order state-read before payload-read when using the key.
Further separate barriering is necessary if RCU is being used to access the
payload content after reading the payload pointers.
Fixes:
146aa8b1453b ("KEYS: Merge the type-specific data with the payload data")
Reported-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Biggers [Mon, 9 Oct 2017 19:46:18 +0000 (12:46 -0700)]
fscrypt: fix dereference of NULL user_key_payload
commit
d60b5b7854c3d135b869f74fb93eaf63cbb1991a upstream.
When an fscrypt-encrypted file is opened, we request the file's master
key from the keyrings service as a logon key, then access its payload.
However, a revoked key has a NULL payload, and we failed to check for
this. request_key() *does* skip revoked keys, but there is still a
window where the key can be revoked before we acquire its semaphore.
Fix it by checking for a NULL payload, treating it like a key which was
already revoked at the time it was requested.
Fixes:
88bd6ccdcdd6 ("ext4 crypto: add encryption key management facilities")
Reviewed-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Brian Foster [Fri, 13 Oct 2017 16:47:46 +0000 (09:47 -0700)]
xfs: trim writepage mapping to within eof
commit
40214d128e07dd21bb07a8ed6a7fe2f911281ab2 upstream.
The writeback rework in commit
fbcc02561359 ("xfs: Introduce
writeback context for writepages") introduced a subtle change in
behavior with regard to the block mapping used across the
->writepages() sequence. The previous xfs_cluster_write() code would
only flush pages up to EOF at the time of the writepage, thus
ensuring that any pages due to file-extending writes would be
handled on a separate cycle and with a new, updated block mapping.
The updated code establishes a block mapping in xfs_writepage_map()
that could extend beyond EOF if the file has post-eof preallocation.
Because we now use the generic writeback infrastructure and pass the
cached mapping to each writepage call, there is no implicit EOF
limit in place. If eofblocks trimming occurs during ->writepages(),
any post-eof portion of the cached mapping becomes invalid. The
eofblocks code has no means to serialize against writeback because
there are no pages associated with post-eof blocks. Therefore if an
eofblocks trim occurs and is followed by a file-extending buffered
write, not only has the mapping become invalid, but we could end up
writing a page to disk based on the invalid mapping.
Consider the following sequence of events:
- A buffered write creates a delalloc extent and post-eof
speculative preallocation.
- Writeback starts and on the first writepage cycle, the delalloc
extent is converted to real blocks (including the post-eof blocks)
and the mapping is cached.
- The file is closed and xfs_release() trims post-eof blocks. The
cached writeback mapping is now invalid.
- Another buffered write appends the file with a delalloc extent.
- The concurrent writeback cycle picks up the just written page
because the writeback range end is LLONG_MAX. xfs_writepage_map()
attributes it to the (now invalid) cached mapping and writes the
data to an incorrect location on disk (and where the file offset is
still backed by a delalloc extent).
This problem is reproduced by xfstests test generic/464, which
triggers racing writes, appends, open/closes and writeback requests.
To address this problem, trim the mapping used during writeback to
within EOF when the mapping is validated. This ensures the mapping
is revalidated for any pages encountered beyond EOF as of the time
the current mapping was cached or last validated.
Reported-by: Eryu Guan <eguan@redhat.com>
Diagnosed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dave Chinner [Fri, 13 Oct 2017 16:47:45 +0000 (09:47 -0700)]
xfs: cancel dirty pages on invalidation
commit
793d7dbe6d82a50b9d14bf992b9eaacb70a11ce6 upstream.
Recently we've had warnings arise from the vm handing us pages
without bufferheads attached to them. This should not ever occur
in XFS, but we don't defend against it properly if it does. The only
place where we remove bufferheads from a page is in
xfs_vm_releasepage(), but we can't tell the difference here between
"page is dirty so don't release" and "page is dirty but is being
invalidated so release it".
In some places that are invalidating pages ask for pages to be
released and follow up afterward calling ->releasepage by checking
whether the page was dirty and then aborting the invalidation. This
is a possible vector for releasing buffers from a page but then
leaving it in the mapping, so we really do need to avoid dirty pages
in xfs_vm_releasepage().
To differentiate between invalidated pages and normal pages, we need
to clear the page dirty flag when invalidating the pages. This can
be done through xfs_vm_invalidatepage(), and will result
xfs_vm_releasepage() seeing the page as clean which matches the
bufferhead state on the page after calling block_invalidatepage().
Hence we can re-add the page dirty check in xfs_vm_releasepage to
catch the case where we might be releasing a page that is actually
dirty and so should not have the bufferheads on it removed. This
will remove one possible vector of "dirty page with no bufferheads"
and so help narrow down the search for the root cause of that
problem.
Signed-Off-By: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Sandeen [Tue, 10 Oct 2017 04:08:06 +0000 (21:08 -0700)]
xfs: handle error if xfs_btree_get_bufs fails
commit
93e8befc17f6d6ea92b0aee3741ceac8bca4590f upstream.
Jason reported that a corrupted filesystem failed to replay
the log with a metadata block out of bounds warning:
XFS (dm-2): _xfs_buf_find: Block out of range: block 0x80270fff8, EOFS 0x9c40000
_xfs_buf_find() and xfs_btree_get_bufs() return NULL if
that happens, and then when xfs_alloc_fix_freelist() calls
xfs_trans_binval() on that NULL bp, we oops with:
BUG: unable to handle kernel NULL pointer dereference at
00000000000000f8
We don't handle _xfs_buf_find errors very well, every
caller higher up the stack gets to guess at why it failed.
But we should at least handle it somehow, so return
EFSCORRUPTED here.
Reported-by: Jason L Tibbitts III <tibbs@math.uh.edu>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Brian Foster [Mon, 9 Oct 2017 18:38:56 +0000 (11:38 -0700)]
xfs: reinit btree pointer on attr tree inactivation walk
commit
f35c5e10c6ed6ba52a8dd8573924a80b6a02f03f upstream.
xfs_attr3_root_inactive() walks the attr fork tree to invalidate the
associated blocks. xfs_attr3_node_inactive() recursively descends
from internal blocks to leaf blocks, caching block address values
along the way to revisit parent blocks, locate the next entry and
descend down that branch of the tree.
The code that attempts to reread the parent block is unsafe because
it assumes that the local xfs_da_node_entry pointer remains valid
after an xfs_trans_brelse() and re-read of the parent buffer. Under
heavy memory pressure, it is possible that the buffer has been
reclaimed and reallocated by the time the parent block is reread.
This means that 'btree' can point to an invalid memory address, lead
to a random/garbage value for child_fsb and cause the subsequent
read of the attr fork to go off the rails and return a NULL buffer
for an attr fork offset that is most likely not allocated.
Note that this problem can be manufactured by setting
XFS_ATTR_BTREE_REF to 0 to prevent LRU caching of attr buffers,
creating a file with a multi-level attr fork and removing it to
trigger inactivation.
To address this problem, reinit the node/btree pointers to the
parent buffer after it has been re-read. This ensures btree points
to a valid record and allows the walk to proceed.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dave Chinner [Mon, 9 Oct 2017 18:37:23 +0000 (11:37 -0700)]
xfs: don't change inode mode if ACL update fails
commit
67f2ffe31d1a683170c2ba0ecc643e42a5fdd397 upstream.
If we get ENOSPC half way through setting the ACL, the inode mode
can still be changed even though the ACL does not exist. Reorder the
operation to only change the mode of the inode if the ACL is set
correctly.
Whilst this does not fix the problem with crash consistency (that requires
attribute addition to be a deferred op) it does prevent ENOSPC and other
non-fatal errors setting an xattr to be handled sanely.
This fixes xfstests generic/449.
Signed-Off-By: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dave Chinner [Mon, 9 Oct 2017 18:37:22 +0000 (11:37 -0700)]
xfs: move more RT specific code under CONFIG_XFS_RT
commit
bb9c2e5433250f5b477035dc478314f8e6dd5e36 upstream.
Various utility functions and interfaces that iterate internal
devices try to reference the realtime device even when RT support is
not compiled into the kernel.
Make sure this code is excluded from the CONFIG_XFS_RT=n build,
and where appropriate stub functions to return fatal errors if
they ever get called when RT support is not present.
Signed-Off-By: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dave Chinner [Mon, 9 Oct 2017 18:37:22 +0000 (11:37 -0700)]
xfs: Don't log uninitialised fields in inode structures
commit
20413e37d71befd02b5846acdaf5e2564dd1c38e upstream.
Prevent kmemcheck from throwing warnings about reading uninitialised
memory when formatting inodes into the incore log buffer. There are
several issues here - we don't always log all the fields in the
inode log format item, and we never log the inode the
di_next_unlinked field.
In the case of the inode log format item, this is exacerbated
by the old xfs_inode_log_format structure padding issue. Hence make
the padded, 64 bit aligned version of the structure the one we always
use for formatting the log and get rid of the 64 bit variant. This
means we'll always log the 64-bit version and so recovery only needs
to convert from the unpadded 32 bit version from older 32 bit
kernels.
Signed-Off-By: Dave Chinner <dchinner@redhat.com>
Tested-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christoph Hellwig [Tue, 3 Oct 2017 15:58:33 +0000 (08:58 -0700)]
xfs: handle racy AIO in xfs_reflink_end_cow
commit
e12199f85d0ad1b04ce6c425ad93cd847fe930bb upstream.
If we got two AIO writes into a COW area the second one might not have any
COW extents left to convert. Handle that case gracefully instead of
triggering an assert or accessing beyond the bounds of the extent list.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Darrick J. Wong [Mon, 18 Sep 2017 16:41:18 +0000 (09:41 -0700)]
xfs: always swap the cow forks when swapping extents
commit
52bfcdd7adbc26639bc7b2356ab9a3f5dad68ad6 upstream.
Since the CoW fork exists as a secondary data structure to the data
fork, we must always swap cow forks during swapext. We also need to
swap the extent counts and reset the cowblocks tags.
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Carlos Maiolino [Fri, 22 Sep 2017 18:47:46 +0000 (11:47 -0700)]
xfs: Capture state of the right inode in xfs_iflush_done
commit
842f6e9f786226c58fcbd5ef80eadca72fdfe652 upstream.
My previous patch:
d3a304b6292168b83b45d624784f973fdc1ca674 check for
XFS_LI_FAILED flag xfs_iflush done, so the failed item can be properly
resubmitted.
In the loop scanning other inodes being completed, it should check the
current item for the XFS_LI_FAILED, and not the initial one.
The state of the initial inode is checked after the loop ends
Kudos to Eric for catching this.
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Darrick J. Wong [Mon, 18 Sep 2017 16:42:09 +0000 (09:42 -0700)]
xfs: perag initialization should only touch m_ag_max_usable for AG 0
commit
9789dd9e1d939232e8ff4c50ef8e75aa6781b3fb upstream.
We call __xfs_ag_resv_init to make a per-AG reservation for each AG.
This makes the reservation per-AG, not per-filesystem. Therefore, it
is incorrect to adjust m_ag_max_usable for each AG. Adjust it only
when we're reserving AG 0's blocks so that we only do it once per fs.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eryu Guan [Thu, 21 Sep 2017 18:26:18 +0000 (11:26 -0700)]
xfs: update i_size after unwritten conversion in dio completion
commit
ee70daaba82d70766d0723b743d9fdeb3b06102a upstream.
Since commit
d531d91d6990 ("xfs: always use unwritten extents for
direct I/O writes"), we start allocating unwritten extents for all
direct writes to allow appending aio in XFS.
But for dio writes that could extend file size we update the in-core
inode size first, then convert the unwritten extents to real
allocations at dio completion time in xfs_dio_write_end_io(). Thus a
racing direct read could see the new i_size and find the unwritten
extents first and read zeros instead of actual data, if the direct
writer also takes a shared iolock.
Fix it by updating the in-core inode size after the unwritten extent
conversion. To do this, introduce a new boolean argument to
xfs_iomap_write_unwritten() to tell if we want to update in-core
i_size or not.
Suggested-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
[hch: backported to the old direct I/O code before Linux 4.10]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eryu Guan [Mon, 18 Sep 2017 18:39:23 +0000 (11:39 -0700)]
xfs: report zeroed or not correctly in xfs_zero_range()
commit
d20a5e3851969fa685f118a80e4df670255a4e8d upstream.
The 'did_zero' param of xfs_zero_range() was not passed to
iomap_zero_range() correctly. This was introduced by commit
7bb41db3ea16 ("xfs: handle 64-bit length in xfs_iozero"), and found
by code inspection.
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Helge Deller [Mon, 18 Sep 2017 18:34:16 +0000 (11:34 -0700)]
fs/xfs: Use %pS printk format for direct addresses
commit
e150dcd459e1b441eaf08f341a986f04e61bf3b8 upstream.
Use the %pS instead of the %pF printk format specifier for printing symbols
from direct addresses. This is needed for the ia64, ppc64 and parisc64
architectures.
Signed-off-by: Helge Deller <deller@gmx.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Darrick J. Wong [Mon, 18 Sep 2017 16:41:17 +0000 (09:41 -0700)]
xfs: evict CoW fork extents when performing finsert/fcollapse
commit
3af423b03435c81036fa710623d3ae92fbe346a3 upstream.
When we perform an finsert/fcollapse operation, cancel all the CoW
extents for the affected file offset range so that they don't end up
pointing to the wrong blocks.
Reported-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Darrick J. Wong [Mon, 18 Sep 2017 16:41:16 +0000 (09:41 -0700)]
xfs: don't unconditionally clear the reflink flag on zero-block files
commit
cc6f77710a6de6210f9feda7cd53e2f5ee7a7e69 upstream.
If we have speculative cow preallocations hanging around in the cow
fork, don't let a truncate operation clear the reflink flag because if
we do then there's a chance we'll forget to free those extents when we
destroy the incore inode.
Reported-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dexuan Cui [Thu, 19 Oct 2017 18:07:35 +0000 (18:07 +0000)]
vmbus: fix missing signaling in hv_signal_on_read()
[Fixes upstream in a much larger set of patches that are not worth backporting
to 4.9 - gregkh]
When the space available before start of reading (cached_write_sz)
is the same as the host required space (pending_sz), we need to
still signal host.
Fixes:
433e19cf33d3 ("Drivers: hv: vmbus: finally fix hv_need_to_signal_on_read()")
Signed-off-by: John Starks <jon.Starks@microsoft.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Sesterhenn [Sun, 8 Oct 2017 18:02:32 +0000 (20:02 +0200)]
pkcs7: Prevent NULL pointer dereference, since sinfo is not always set.
commit
68a1fdbbf8bd3378325e45c19e167a165f9ffc3a upstream.
The ASN.1 parser does not necessarily set the sinfo field,
this patch prevents a NULL pointer dereference on broken
input.
Fixes:
99db44350672 ("PKCS#7: Appropriately restrict authenticated attributes and content type")
Signed-off-by: Eric Sesterhenn <eric.sesterhenn@x41-dsec.de>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Howells [Thu, 12 Oct 2017 15:00:41 +0000 (16:00 +0100)]
KEYS: don't let add_key() update an uninstantiated key
commit
60ff5b2f547af3828aebafd54daded44cfb0807a upstream.
Currently, when passed a key that already exists, add_key() will call the
key's ->update() method if such exists. But this is heavily broken in the
case where the key is uninstantiated because it doesn't call
__key_instantiate_and_link(). Consequently, it doesn't do most of the
things that are supposed to happen when the key is instantiated, such as
setting the instantiation state, clearing KEY_FLAG_USER_CONSTRUCT and
awakening tasks waiting on it, and incrementing key->user->nikeys.
It also never takes key_construction_mutex, which means that
->instantiate() can run concurrently with ->update() on the same key. In
the case of the "user" and "logon" key types this causes a memory leak, at
best. Maybe even worse, the ->update() methods of the "encrypted" and
"trusted" key types actually just dereference a NULL pointer when passed an
uninstantiated key.
Change key_create_or_update() to wait interruptibly for the key to finish
construction before continuing.
This patch only affects *uninstantiated* keys. For now we still allow a
negatively instantiated key to be updated (thereby positively
instantiating it), although that's broken too (the next patch fixes it)
and I'm not sure that anyone actually uses that functionality either.
Here is a simple reproducer for the bug using the "encrypted" key type
(requires CONFIG_ENCRYPTED_KEYS=y), though as noted above the bug
pertained to more than just the "encrypted" key type:
#include <stdlib.h>
#include <unistd.h>
#include <keyutils.h>
int main(void)
{
int ringid = keyctl_join_session_keyring(NULL);
if (fork()) {
for (;;) {
const char payload[] = "update user:foo 32";
usleep(rand() % 10000);
add_key("encrypted", "desc", payload, sizeof(payload), ringid);
keyctl_clear(ringid);
}
} else {
for (;;)
request_key("encrypted", "desc", "callout_info", ringid);
}
}
It causes:
BUG: unable to handle kernel NULL pointer dereference at
0000000000000018
IP: encrypted_update+0xb0/0x170
PGD
7a178067 P4D
7a178067 PUD
77269067 PMD 0
PREEMPT SMP
CPU: 0 PID: 340 Comm: reproduce Tainted: G D 4.14.0-rc1-00025-g428490e38b2e #796
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task:
ffff8a467a39a340 task.stack:
ffffb15c40770000
RIP: 0010:encrypted_update+0xb0/0x170
RSP: 0018:
ffffb15c40773de8 EFLAGS:
00010246
RAX:
0000000000000000 RBX:
ffff8a467a275b00 RCX:
0000000000000000
RDX:
0000000000000005 RSI:
ffff8a467a275b14 RDI:
ffffffffb742f303
RBP:
ffffb15c40773e20 R08:
0000000000000000 R09:
ffff8a467a275b17
R10:
0000000000000020 R11:
0000000000000000 R12:
0000000000000000
R13:
0000000000000000 R14:
ffff8a4677057180 R15:
ffff8a467a275b0f
FS:
00007f5d7fb08700(0000) GS:
ffff8a467f200000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
0000000000000018 CR3:
0000000077262005 CR4:
00000000001606f0
Call Trace:
key_create_or_update+0x2bc/0x460
SyS_add_key+0x10c/0x1d0
entry_SYSCALL_64_fastpath+0x1f/0xbe
RIP: 0033:0x7f5d7f211259
RSP: 002b:
00007ffed03904c8 EFLAGS:
00000246 ORIG_RAX:
00000000000000f8
RAX:
ffffffffffffffda RBX:
000000003b2a7955 RCX:
00007f5d7f211259
RDX:
00000000004009e4 RSI:
00000000004009ff RDI:
0000000000400a04
RBP:
0000000068db8bad R08:
000000003b2a7955 R09:
0000000000000004
R10:
000000000000001a R11:
0000000000000246 R12:
0000000000400868
R13:
00007ffed03905d0 R14:
0000000000000000 R15:
0000000000000000
Code: 77 28 e8 64 34 1f 00 45 31 c0 31 c9 48 8d 55 c8 48 89 df 48 8d 75 d0 e8 ff f9 ff ff 85 c0 41 89 c4 0f 88 84 00 00 00 4c 8b 7d c8 <49> 8b 75 18 4c 89 ff e8 24 f8 ff ff 85 c0 41 89 c4 78 6d 49 8b
RIP: encrypted_update+0xb0/0x170 RSP:
ffffb15c40773de8
CR2:
0000000000000018
Reported-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Eric Biggers <ebiggers@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Biggers [Mon, 9 Oct 2017 19:43:20 +0000 (12:43 -0700)]
lib/digsig: fix dereference of NULL user_key_payload
commit
192cabd6a296cbc57b3d8c05c4c89d87fc102506 upstream.
digsig_verify() requests a user key, then accesses its payload.
However, a revoked key has a NULL payload, and we failed to check for
this. request_key() *does* skip revoked keys, but there is still a
window where the key can be revoked before we acquire its semaphore.
Fix it by checking for a NULL payload, treating it like a key which was
already revoked at the time it was requested.
Fixes:
051dbb918c7f ("crypto: digital signature verification support")
Reviewed-by: James Morris <james.l.morris@oracle.com>
Cc: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Biggers [Mon, 9 Oct 2017 19:37:49 +0000 (12:37 -0700)]
KEYS: encrypted: fix dereference of NULL user_key_payload
commit
13923d0865ca96312197962522e88bc0aedccd74 upstream.
A key of type "encrypted" references a "master key" which is used to
encrypt and decrypt the encrypted key's payload. However, when we
accessed the master key's payload, we failed to handle the case where
the master key has been revoked, which sets the payload pointer to NULL.
Note that request_key() *does* skip revoked keys, but there is still a
window where the key can be revoked before we acquire its semaphore.
Fix it by checking for a NULL payload, treating it like a key which was
already revoked at the time it was requested.
This was an issue for master keys of type "user" only. Master keys can
also be of type "trusted", but those cannot be revoked.
Fixes:
7e70cb497850 ("keys: add new key-type encrypted")
Reviewed-by: James Morris <james.l.morris@oracle.com>
Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>
Cc: David Safford <safford@us.ibm.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Borislav Petkov [Wed, 18 Oct 2017 11:12:25 +0000 (13:12 +0200)]
x86/microcode/intel: Disable late loading on model 79
commit
723f2828a98c8ca19842042f418fb30dd8cfc0f7 upstream.
Blacklist Broadwell X model 79 for late loading due to an erratum.
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Tony Luck <tony.luck@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20171018111225.25635-1-bp@alien8.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Larry Finger [Wed, 20 Sep 2017 21:15:05 +0000 (16:15 -0500)]
rtlwifi: rtl8821ae: Fix connection lost problem
commit
b8b8b16352cd90c6083033fd4487f04fae935c18 upstream.
In commit
40b368af4b75 ("rtlwifi: Fix alignment issues"), the read
of REG_DBI_READ was changed from 16 to 8 bits. For unknown reasonsi
this change results in reduced stability for the wireless connection.
This regression was located using bisection.
Fixes:
40b368af4b75 ("rtlwifi: Fix alignment issues")
Reported-and-tested-by: James Cameron <quozl@laptop.org>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Kozub [Thu, 19 Oct 2017 20:57:02 +0000 (22:57 +0200)]
clockevents/drivers/cs5535: Improve resilience to spurious interrupts
commit
eb39a7c0355393c5a8d930f342ad7a6231b552c4 upstream.
The interrupt handler mfgpt_tick() is not robust versus spurious interrupts
which happen before the clock event device is registered and fully
initialized.
The reason is that the safe guard against spurious interrupts solely checks
for the clockevents shutdown state, but lacks a check for detached
state. If the interrupt hits while the device is in detached state it
passes the safe guard and dereferences the event handler call back which is
NULL.
Add the missing state check.
Fixes:
8f9327cbb6e8 ("clockevents/drivers/cs5535: Migrate to new 'set-state' interface")
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: David Kozub <zub@linux.fjfi.cvut.cz>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lkml.kernel.org/r/20171020093103.3317F6004D@linux.fjfi.cvut.cz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Luebbe [Mon, 28 Aug 2017 15:25:16 +0000 (17:25 +0200)]
bus: mbus: fix window size calculation for 4GB windows
commit
2bbbd96357ce76cc45ec722c00f654aa7b189112 upstream.
At least the Armada XP SoC supports 4GB on a single DRAM window. Because
the size register values contain the actual size - 1, the MSB is set in
that case. For example, the SDRAM window's control register's value is
0xffffffe1 for 4GB (bits 31 to 24 contain the size).
The MBUS driver reads back each window's size from registers and
calculates the actual size as (control_reg | ~DDR_SIZE_MASK) + 1, which
overflows for 32 bit values, resulting in other miscalculations further
on (a bad RAM window for the CESA crypto engine calculated by
mvebu_mbus_setup_cpu_target_nooverlap() in my case).
This patch changes the type in 'struct mbus_dram_window' from u32 to
u64, which allows us to keep using the same register calculation code in
most MBUS-using drivers (which calculate ->size - 1 again).
Fixes:
fddddb52a6c4 ("bus: introduce an Marvell EBU MBus driver")
Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arnd Bergmann [Fri, 22 Sep 2017 21:29:12 +0000 (23:29 +0200)]
brcmsmac: make some local variables 'static const' to reduce stack size
commit
c503dd38f850be28867ef7a42d9abe5ade81a9bd upstream.
With KASAN and a couple of other patches applied, this driver is one
of the few remaining ones that actually use more than 2048 bytes of
kernel stack:
broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_workarounds_nphy_gainctrl':
broadcom/brcm80211/brcmsmac/phy/phy_n.c:16065:1: warning: the frame size of 3264 bytes is larger than 2048 bytes [-Wframe-larger-than=]
broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_workarounds_nphy':
broadcom/brcm80211/brcmsmac/phy/phy_n.c:17138:1: warning: the frame size of 2864 bytes is larger than 2048 bytes [-Wframe-larger-than=]
Here, I'm reducing the stack size by marking as many local variables as
'static const' as I can without changing the actual code.
This is the first of three patches to improve the stack usage in this
driver. It would be good to have this backported to stabl kernels
to get all drivers in 'allmodconfig' below the 2048 byte limit so
we can turn on the frame warning again globally, but I realize that
the patch is larger than the normal limit for stable backports.
The other two patches do not need to be backported.
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kevin Cernekee [Sun, 17 Sep 2017 04:08:24 +0000 (21:08 -0700)]
brcmfmac: Add check for short event packets
commit
dd2349121bb1b8ff688c3ca6a2a0bea9d8c142ca upstream.
The length of the data in the received skb is currently passed into
brcmf_fweh_process_event() as packet_len, but this value is not checked.
event_packet should be followed by DATALEN bytes of additional event
data. Ensure that the received packet actually contains at least
DATALEN bytes of additional data, to avoid copying uninitialized memory
into event->data.
Suggested-by: Mattias Nissler <mnissler@chromium.org>
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guenter Roeck [Sat, 15 Jul 2017 23:51:26 +0000 (16:51 -0700)]
i2c: piix4: Fix SMBus port selection for AMD Family 17h chips
commit
0fe16195f89173652cf111d7b384941b00c5aabd upstream.
AMD Family 17h uses the KERNCZ SMBus controller. While its documentation
is not publicly available, it is documented in the BIOS and Kernel
Developer’s Guide for AMD Family 15h Models 60h-6Fh Processors.
On this SMBus controller, the port select register is at PMx register
0x02, bit 4:3 (PMx00 register bit 20:19).
Without this patch, the 4 SMBus channels on AMD Family 17h chips are
mirrored and report the same chips on all channels.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pontus Andersson [Mon, 2 Oct 2017 12:45:19 +0000 (14:45 +0200)]
i2c: ismt: Separate I2C block read from SMBus block read
commit
c6ebcedbab7ca78984959386012a17b21183e1a3 upstream.
Commit
b6c159a9cb69 ("i2c: ismt: Don't duplicate the receive length for
block reads") broke I2C block reads. It aimed to fix normal SMBus block
read, but changed the correct behavior of I2C block read in the process.
According to Documentation/i2c/smbus-protocol, one vital difference
between normal SMBus block read and I2C block read is that there is no
byte count prefixed in the data sent on the wire:
SMBus Block Read: i2c_smbus_read_block_data()
S Addr Wr [A] Comm [A]
S Addr Rd [A] [Count] A [Data] A [Data] A ... A [Data] NA P
I2C Block Read: i2c_smbus_read_i2c_block_data()
S Addr Wr [A] Comm [A]
S Addr Rd [A] [Data] A [Data] A ... A [Data] NA P
Therefore the two transaction types need to be processed differently in
the driver by copying of the dma_buffer as done previously for the
I2C_SMBUS_I2C_BLOCK_DATA case.
Fixes:
b6c159a9cb69 ("i2c: ismt: Don't duplicate the receive length for block reads")
Signed-off-by: Pontus Andersson <epontan@gmail.com>
Tested-by: Stephen Douthit <stephend@adiengineering.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Tue, 17 Oct 2017 14:38:55 +0000 (16:38 +0200)]
ALSA: hda: Abort capability probe at invalid register read
commit
098a0a62c1554f5a3813ef1b8539563214ada8f6 upstream.
The loop in snd_hdac_bus_parse_capabilities() may go to nirvana when
it hits an invalid register value read:
BUG: unable to handle kernel paging request at
ffffad5dc41f3fff
IP: pci_azx_readl+0x5/0x10 [snd_hda_intel]
Call Trace:
snd_hdac_bus_parse_capabilities+0x3c/0x1f0 [snd_hda_core]
azx_probe_continue+0x7d5/0x940 [snd_hda_intel]
.....
This happened on a new Intel machine, and we need to check the value
and abort the loop accordingly.
[Note: the fixes tag below indicates only the commit where this patch
can be applied; the original problem was introduced even before that
commit]
Fixes:
6720b38420a0 ("ALSA: hda - move bus_parse_capabilities to core")
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Tue, 17 Oct 2017 09:58:17 +0000 (11:58 +0200)]
ALSA: hda: Remove superfluous '-' added by printk conversion
commit
6bf88a343db2b3c160edf9b82a74966b31cc80bd upstream.
While converting the error messages to the standard macros in the
commit
4e76a8833fac ("ALSA: hda - Replace with standard printk"), a
superfluous '-' slipped in the code mistakenly. Its influence is
almost negligible, merely shows a dB value as negative integer instead
of positive integer (or vice versa) in the rare error message.
So let's kill this embarrassing byte to show more correct value.
Fixes:
4e76a8833fac ("ALSA: hda - Replace with standard printk")
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ben Hutchings [Tue, 17 Oct 2017 23:45:49 +0000 (00:45 +0100)]
ALSA: seq: Enable 'use' locking in all configurations
commit
8009d506a1dd00cf436b0c4cca0dcec130580a21 upstream.
The 'use' locking macros are no-ops if neither SMP or SND_DEBUG is
enabled. This might once have been OK in non-preemptible
configurations, but even in that case snd_seq_read() may sleep while
relying on a 'use' lock. So always use the proper implementations.
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ben Skeggs [Mon, 25 Sep 2017 05:05:38 +0000 (15:05 +1000)]
drm/nouveau/mmu: flush tlbs before deleting page tables
commit
77913bbcb43ac9a07a6fe849c2fd3bf85fc8bdd8 upstream.
Even though we've zeroed the PDE, the GPU may have cached the PD, so we
need to flush when deleting them.
Noticed while working on replacement MMU code, but a backport might be a
good idea, so let's fix it in the current code too.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ilia Mirkin [Sun, 1 Oct 2017 17:52:43 +0000 (13:52 -0400)]
drm/nouveau/bsp/g92: disable by default
commit
194d68dd051c2dd5ac2b522ae16100e774e8d869 upstream.
G92's seem to require some additional bit of initialization before the
BSP engine can work. It feels like clocks are not set up for the
underlying VLD engine, which means that all commands submitted to the
xtensa chip end up hanging. VP seems to work fine though.
This still allows people to force-enable the bsp engine if they want to
play around with it, but makes it harder for the card to hang by
default.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stefan Mätje [Wed, 18 Oct 2017 11:25:17 +0000 (13:25 +0200)]
can: esd_usb2: Fix can_dlc value for received RTR, frames
commit
72d92e865d1560723e1957ee3f393688c49ca5bf upstream.
The dlc member of the struct rx_msg contains also the ESD_RTR flag to
mark received RTR frames. Without the fix the can_dlc value for received
RTR frames would always be set to 8 by get_can_dlc() instead of the
received value.
Fixes:
96d8e90382dc ("can: Add driver for esd CAN-USB/2 device")
Signed-off-by: Stefan Mätje <stefan.maetje@esd.eu>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mathias Nyman [Fri, 6 Oct 2017 14:45:27 +0000 (17:45 +0300)]
xhci: Identify USB 3.1 capable hosts by their port protocol capability
commit
ea7d0d69426cab6747ed311c53f4142eb48b9454 upstream.
Many USB 3.1 capable hosts never updated the Serial Bus Release Number
(SBRN) register to USB 3.1 from USB 3.0
xhci driver identified USB 3.1 capable hosts based on this SBRN register,
which according to specs "contains the release of the Universal Serial
Bus Specification with which this Universal Serial Bus Host Controller
module is compliant." but still in october 2017 gives USB 3.0 as
the only possible option.
Make an additional check for USB 3.1 support and enable it if the xHCI
supported protocol capablity lists USB 3.1 capable ports.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jonathan Liu [Tue, 10 Oct 2017 03:46:12 +0000 (22:46 -0500)]
usb: musb: Check for host-mode using is_host_active() on reset interrupt
commit
445ef61543da3db5b699f87fb0aa4f227165f6ed upstream.
The sunxi musb has a bug where sometimes it will generate a babble
error on device disconnect instead of a disconnect IRQ. When this
happens the musb controller switches from host mode to device mode
(it clears MUSB_DEVCTL_HM/MUSB_DEVCTL_SESSION and sets
MUSB_DEVCTL_BDEVICE) and gets stuck in this state.
The babble error is misdetected as a bus reset because MUSB_DEVCTL_HM
was cleared.
To fix this, use is_host_active() rather than (devctl & MUSB_DEVCTL_HM)
to detect babble error so that sunxi musb babble recovery can handle it
by restoring the mode. This information is provided by the driver logic
and does not rely on register contents.
Signed-off-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jonathan Liu [Tue, 10 Oct 2017 03:46:13 +0000 (22:46 -0500)]
usb: musb: sunxi: Explicitly release USB PHY on exit
commit
6ed05c68cbcae42cd52b8e53b66952bfa9c002ce upstream.
This fixes a kernel oops when unloading the driver due to usb_put_phy
being called after usb_phy_generic_unregister when the device is
detached. Calling usb_phy_generic_unregister causes x->dev->driver to
be NULL in usb_put_phy and results in a NULL pointer dereference.
Signed-off-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lars-Peter Clausen [Fri, 29 Sep 2017 13:24:05 +0000 (15:24 +0200)]
iio: dummy: events: Add missing break
commit
be94a6f6d488b4767662e8949dc62361bd1d6311 upstream.
Add missing break in iio_simple_dummy_write_event_config() for the voltage
threshold event enable attribute. Without this writing to the
in_voltage0_thresh_rising_en always returns -EINVAL even though the change
was correctly applied.
Fixes:
3e34e650db197 ("iio: dummy: Demonstrate the usage of new channel types")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
John David Anglin [Sat, 30 Sep 2017 21:24:23 +0000 (17:24 -0400)]
parisc: Fix double-word compare and exchange in LWS code on 32-bit kernels
commit
374b3bf8e8b519f61eb9775888074c6e46b3bf0c upstream.
As discussed on the debian-hppa list, double-wordcompare and exchange
operations fail on 32-bit kernels. Looking at the code, I realized that
the ",ma" completer does the wrong thing in the "ldw,ma 4(%r26), %r29"
instruction. This increments %r26 and causes the following store to
write to the wrong location.
Note by Helge Deller:
The patch applies cleanly to stable kernel series if this upstream
commit is merged in advance:
f4125cfdb300 ("parisc: Avoid trashing sr2 and sr3 in LWS code").
Signed-off-by: John David Anglin <dave.anglin@bell.net>
Tested-by: Christoph Biedl <debian.axhn@manchmal.in-ulm.de>
Fixes:
89206491201c ("parisc: Implement new LWS CAS supporting 64 bit operations.")
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wolfgang Grandegger [Thu, 14 Sep 2017 16:37:14 +0000 (18:37 +0200)]
can: gs_usb: fix busy loop if no more TX context is available
commit
97819f943063b622eca44d3644067c190dc75039 upstream.
If sending messages with no cable connected, it quickly happens that
there is no more TX context available. Then "gs_can_start_xmit()"
returns with "NETDEV_TX_BUSY" and the upper layer does retry
immediately keeping the CPU busy. To fix that issue, I moved
"atomic_dec(&dev->active_tx_urbs)" from "gs_usb_xmit_callback()" to
the TX done handling in "gs_usb_receive_bulk_callback()". Renaming
"active_tx_urbs" to "active_tx_contexts" and moving it into
"gs_[alloc|free]_tx_context()" would also make sense.
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jussi Laako [Sun, 15 Oct 2017 09:41:32 +0000 (12:41 +0300)]
ALSA: usb-audio: Add native DSD support for Pro-Ject Pre Box S2 Digital
commit
9bb201a5d5acc733943e8af7151cceab9d976a69 upstream.
Add native DSD support quirk for Pro-Ject Pre Box S2 Digital USB id
2772:0230.
Signed-off-by: Jussi Laako <jussi@sonarnerd.net>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mathias Nyman [Tue, 17 Oct 2017 13:07:33 +0000 (16:07 +0300)]
usb: hub: Allow reset retry for USB2 devices on connect bounce
commit
1ac7db63333db1eeff901bfd6bbcd502b4634fa4 upstream.
If the connect status change is set during reset signaling, but
the status remains connected just retry port reset.
This solves an issue with connecting a 90W HP Thunderbolt 3 dock
with a Lenovo Carbon x1 (5th generation) which causes a 30min loop
of a high speed device being re-discovererd before usb ports starts
working.
[...]
[ 389.023845] usb 3-1: new high-speed USB device number 55 using xhci_hcd
[ 389.491841] usb 3-1: new high-speed USB device number 56 using xhci_hcd
[ 389.959928] usb 3-1: new high-speed USB device number 57 using xhci_hcd
[...]
This is caused by a high speed device that doesn't successfully go to the
enabled state after the second port reset. Instead the connection bounces
(connected, with connect status change), bailing out completely from
enumeration just to restart from scratch.
Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1716332
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Felipe Balbi [Tue, 3 Oct 2017 08:16:43 +0000 (11:16 +0300)]
usb: quirks: add quirk for WORLDE MINI MIDI keyboard
commit
2811501e6d8f5747d08f8e25b9ecf472d0dc4c7d upstream.
This keyboard doesn't implement Get String descriptors properly even
though string indexes are valid. What happens is that when requesting
for the String descriptor, the device disconnects and
reconnects. Without this quirk, this loop will continue forever.
Cc: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Владимир Мартьянов <vilgeforce@gmail.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Maksim Salau [Wed, 11 Oct 2017 08:10:52 +0000 (11:10 +0300)]
usb: cdc_acm: Add quirk for Elatec TWN3
commit
765fb2f181cad669f2beb87842a05d8071f2be85 upstream.
Elatec TWN3 has the union descriptor on data interface. This results in
failure to bind the device to the driver with the following log:
usb 1-1.2: new full speed USB device using streamplug-ehci and address 4
usb 1-1.2: New USB device found, idVendor=09d8, idProduct=0320
usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1.2: Product: RFID Device (COM)
usb 1-1.2: Manufacturer: OEM
cdc_acm 1-1.2:1.0: Zero length descriptor references
cdc_acm: probe of 1-1.2:1.0 failed with error -22
Adding the NO_UNION_NORMAL quirk for the device fixes the issue.
`lsusb -v` of the device:
Bus 001 Device 003: ID 09d8:0320
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 32
idVendor 0x09d8
idProduct 0x0320
bcdDevice 3.00
iManufacturer 1 OEM
iProduct 2 RFID Device (COM)
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 67
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 250mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 2
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 0
CDC Header:
bcdCDC 1.10
CDC Call Management:
bmCapabilities 0x03
call management
use DataInterface
bDataInterface 1
CDC ACM:
bmCapabilities 0x06
sends break
line coding and serial state
CDC Union:
bMasterInterface 0
bSlaveInterface 1
Device Status: 0x0000
(Bus Powered)
Signed-off-by: Maksim Salau <msalau@iotecha.com>
Acked-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Thu, 12 Oct 2017 12:50:46 +0000 (14:50 +0200)]
USB: serial: metro-usb: add MS7820 device id
commit
31dc3f819bac28a0990b36510197560258ab7421 upstream.
Add device-id entry for (Honeywell) Metrologic MS7820 bar code scanner.
The device has two interfaces (in this mode?); a vendor-specific
interface with two interrupt endpoints and a second HID interface, which
we do not bind to.
Reported-by: Ladislav Dobrovsky <ladislav.dobrovsky@gmail.com>
Tested-by: Ladislav Dobrovsky <ladislav.dobrovsky@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alan Stern [Wed, 18 Oct 2017 16:49:38 +0000 (12:49 -0400)]
USB: core: fix out-of-bounds access bug in usb_get_bos_descriptor()
commit
1c0edc3633b56000e18d82fc241e3995ca18a69e upstream.
Andrey used the syzkaller fuzzer to find an out-of-bounds memory
access in usb_get_bos_descriptor(). The code wasn't checking that the
next usb_dev_cap_header structure could fit into the remaining buffer
space.
This patch fixes the error and also reduces the bNumDeviceCaps field
in the header to match the actual number of capabilities found, in
cases where there are fewer than expected.
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hans de Goede [Mon, 16 Oct 2017 14:21:19 +0000 (16:21 +0200)]
USB: devio: Revert "USB: devio: Don't corrupt user memory"
commit
845d584f41eac3475c21e4a7d5e88d0f6e410cf7 upstream.
Taking the uurb->buffer_length userspace passes in as a maximum for the
actual urbs transfer_buffer_length causes 2 serious issues:
1) It breaks isochronous support for all userspace apps using libusb,
as existing libusb versions pass in 0 for uurb->buffer_length,
relying on the kernel using the lenghts of the usbdevfs_iso_packet_desc
descriptors passed in added together as buffer length.
This for example causes redirection of USB audio and Webcam's into
virtual machines using qemu-kvm to no longer work. This is a userspace
ABI break and as such must be reverted.
Note that the original commit does not protect other users / the
kernels memory, it only stops the userspace process making the call
from shooting itself in the foot.
2) It may cause the kernel to program host controllers to DMA over random
memory. Just as the devio code used to only look at the iso_packet_desc
lenghts, the host drivers do the same, relying on the submitter of the
urbs to make sure the entire buffer is large enough and not checking
transfer_buffer_length.
But the "USB: devio: Don't corrupt user memory" commit now takes the
userspace provided uurb->buffer_length for the buffer-size while copying
over the user-provided iso_packet_desc lengths 1:1, allowing the user
to specify a small buffer size while programming the host controller to
dma a lot more data.
(Atleast the ohci, uhci, xhci and fhci drivers do not check
transfer_buffer_length for isoc transfers.)
This reverts commit
fa1ed74eb1c2 ("USB: devio: Don't corrupt user memory")
fixing both these issues.
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Sat, 21 Oct 2017 15:21:39 +0000 (17:21 +0200)]
Linux 4.9.58
Manu Gautam [Wed, 19 Jul 2017 11:37:10 +0000 (17:07 +0530)]
usb: dwc3: gadget: Correct ISOC DATA PIDs for short packets
commit
40d829fb2ec636b6b4b0cc95e2546ab9aca04cc9 upstream.
The PIDs for Isochronous data transfers are incorrect
for high bandwidth IN endpoints when the request length
is less than EP wMaxPacketSize.
As per spec correct PIDs for ISOC data transfers are:
1) For request length <= maxpacket
- DATA0,
2) For maxpacket < length <= (2 * maxpacket)
- DATA1, DATA0
3) For (2 * maxpacket) < length <= (3 * maxpacket)
- DATA2, DATA1, DATA0.
But driver always sets PCM fields based on wMaxPacketSize
due to which DATA2 happens even for small requests.
Fix this by setting the PCM field of trb->size depending
on request length rather than fixing it to the value
depending on wMaxPacketSize.
Ideally it shouldn't give any issues as dwc3 will send
0-length packet for next IN token if host sends (even
after receiving a short packet). Windows seems to ignore
this but with MacOS frame loss observed when using f_uvc.
Signed-off-by: Manu Gautam <mgautam@codeaurora.org>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
[b-liu@ti.com added following change for v4.9.]
- unsigned int maxp = usb_endpoint_maxp(ep->desc);
+ unsigned int maxp;
+ maxp = usb_endpoint_maxp(ep->desc) & 0x07ff;
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arnd Bergmann [Tue, 14 Feb 2017 21:19:18 +0000 (22:19 +0100)]
cpufreq: CPPC: add ACPI_PROCESSOR dependency
[ Upstream commit
a578884fa0d2768f13d37c6591a9e1ed600482d3 ]
Without the Kconfig dependency, we can get this warning:
warning: ACPI_CPPC_CPUFREQ selects ACPI_CPPC_LIB which has unmet direct dependencies (ACPI && ACPI_PROCESSOR)
Fixes:
5477fb3bd1e8 (ACPI / CPPC: Add a CPUFreq driver for use with CPPC)
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yazen Ghannam [Wed, 15 Feb 2017 20:56:22 +0000 (14:56 -0600)]
EDAC, mce_amd: Print IPID and Syndrome on a separate line
[ Upstream commit
75bf2f6478cab9b0c1d7f5f674a765d1e2ad530e ]
Currently, the IPID and Syndrome are printed on the same line as the
Address. There are cases when we can have a valid Syndrome but not a
valid Address.
For example, the MCA_SYND register can be used to hold more detailed
error info that the hardware folks can use. It's not just DRAM ECC
syndromes. There are some error types that aren't related to memory that
may have valid syndromes, like some errors related to links in the Data
Fabric, etc.
In these cases, the IPID and Syndrome are not printed at the same log
level as the rest of the stanza, so users won't see them on the console.
Console:
[Hardware Error]: CPU:16 (17:1:0) MC22_STATUS[Over|CE|MiscV|-|-|-|-|SyndV|-]: 0xd82000000002080b
[Hardware Error]: Power, Interrupts, etc. Extended Error Code: 2
Dmesg:
[Hardware Error]: CPU:16 (17:1:0) MC22_STATUS[Over|CE|MiscV|-|-|-|-|SyndV|-]: 0xd82000000002080b
, Syndrome: 0x000000010b404000, IPID: 0x0001002e00000002
[Hardware Error]: Power, Interrupts, etc. Extended Error Code: 2
Print the IPID first and on a new line. The IPID should always be
printed on SMCA systems. The Syndrome will then be printed with the IPID
and at the same log level when valid:
[Hardware Error]: CPU:16 (17:1:0) MC22_STATUS[Over|CE|MiscV|-|-|-|-|SyndV|-]: 0xd82000000002080b
[Hardware Error]: IPID: 0x0001002e00000002, Syndrome: 0x000000010b404000
[Hardware Error]: Power, Interrupts, etc. Extended Error Code: 2
Signed-off-by: Yazen Ghannam <Yazen.Ghannam@amd.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Link: http://lkml.kernel.org/r/1487192182-2474-1-git-send-email-Yazen.Ghannam@amd.com
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
projects / profile / wearable / platform / kernel / linux-4.9-exynos9110.git / log