OSDN Git Service
Boris Brezillon [Fri, 25 Nov 2016 10:32:32 +0000 (11:32 +0100)]
mtd: nand: mxc: Fix mxc_v1 ooblayout
commit
3bff08dffe3115a25ce04b95ea75f6d868572c60 upstream.
Commit
a894cf6c5a82 ("mtd: nand: mxc: switch to mtd_ooblayout_ops")
introduced a bug in the OOB layout description. Even if the driver claims
that 3 ECC bytes are reserved to protect 512 bytes of data, it's actually
5 ECC bytes to protect 512+6 bytes of data (some OOB bytes are also
protected using extra ECC bytes).
Fix the mxc_v1_ooblayout_{free,ecc}() functions to reflect this behavior.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Fixes:
a894cf6c5a82 ("mtd: nand: mxc: switch to mtd_ooblayout_ops")
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Sun, 10 Sep 2017 05:49:19 +0000 (07:49 +0200)]
Linux 4.9.49
John Stultz [Tue, 17 Jan 2017 00:52:48 +0000 (16:52 -0800)]
drm/bridge: adv7511: Switch to using drm_kms_helper_hotplug_event()
commit
6d5104c5a6b56385426e15047050584794bb6254 upstream.
In chasing down a previous issue with EDID probing from calling
drm_helper_hpd_irq_event() from irq context, Laurent noticed
that the DRM documentation suggests that
drm_kms_helper_hotplug_event() should be used instead.
Thus this patch replaces drm_helper_hpd_irq_event() with
drm_kms_helper_hotplug_event(), which requires we update the
connector.status entry and only call _hotplug_event() when the
status changes.
Cc: David Airlie <airlied@linux.ie>
Cc: Archit Taneja <architt@codeaurora.org>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1484614372-15342-3-git-send-email-john.stultz@linaro.org
Signed-off-by: Thong Ho <thong.ho.px@rvc.renesas.com>
Signed-off-by: Nhan Nguyen <nhan.nguyen.yb@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
John Stultz [Tue, 17 Jan 2017 00:52:47 +0000 (16:52 -0800)]
drm/bridge: adv7511: Use work_struct to defer hotplug handing to out of irq context
commit
518cb7057a59b9441336d2e88a396d52b6ab0cce upstream.
I was recently seeing issues with EDID probing, where
the logic to wait for the EDID read bit to be set by the
IRQ wasn't happening and the code would time out and fail.
Digging deeper, I found this was due to the fact that
IRQs were disabled as we were running in IRQ context from
the HPD signal.
Thus this patch changes the logic to handle the HPD signal
via a work_struct so we can be out of irq context.
With this patch, the EDID probing on hotplug does not time
out.
Cc: David Airlie <airlied@linux.ie>
Cc: Archit Taneja <architt@codeaurora.org>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1484614372-15342-2-git-send-email-john.stultz@linaro.org
Signed-off-by: Thong Ho <thong.ho.px@rvc.renesas.com>
Signed-off-by: Nhan Nguyen <nhan.nguyen.yb@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Todd Poynor [Wed, 16 Aug 2017 04:48:43 +0000 (21:48 -0700)]
scsi: sg: recheck MMAP_IO request length with lock held
commit
8d26f491116feaa0b16de370b6a7ba40a40fa0b4 upstream.
Commit
1bc0eb044615 ("scsi: sg: protect accesses to 'reserved' page
array") adds needed concurrency protection for the "reserve" buffer.
Some checks that are initially made outside the lock are replicated once
the lock is taken to ensure the checks and resulting decisions are made
using consistent state.
The check that a request with flag SG_FLAG_MMAP_IO set fits in the
reserve buffer also needs to be performed again under the lock to ensure
the reserve buffer length compared against matches the value in effect
when the request is linked to the reserve buffer. An -ENOMEM should be
returned in this case, instead of switching over to an indirect buffer
as for non-MMAP_IO requests.
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Acked-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Todd Poynor [Wed, 16 Aug 2017 05:41:08 +0000 (22:41 -0700)]
scsi: sg: protect against races between mmap() and SG_SET_RESERVED_SIZE
commit
6a8dadcca81fceff9976e8828cceb072873b7bd5 upstream.
Take f_mutex around mmap() processing to protect against races with the
SG_SET_RESERVED_SIZE ioctl. Ensure the reserve buffer length remains
consistent during the mapping operation, and set the "mmap called" flag
to prevent further changes to the reserved buffer size as an atomic
operation with the mapping.
[mkp: fixed whitespace]
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Acked-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andrey Korolyov [Thu, 10 Aug 2017 10:21:14 +0000 (13:21 +0300)]
cs5536: add support for IDE controller variant
commit
591b6bb605785c12a21e8b07a08a277065b655a5 upstream.
Several legacy devices such as Geode-based Cisco ASA appliances
and DB800 development board do possess CS5536 IDE controller
with different PCI id than existing one. Using pata_generic is
not always feasible as at least DB800 requires MSR quirk from
pata_cs5536 to be used with vendor firmware.
Signed-off-by: Andrey Korolyov <andrey@xdel.ru>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ben Hutchings [Sun, 3 Sep 2017 00:18:41 +0000 (01:18 +0100)]
workqueue: Fix flag collision
commit
fbf1c41fc0f4d3574ac2377245efd666c1fa3075 upstream.
Commit
0a94efb5acbb ("workqueue: implicit ordered attribute should be
overridable") introduced a __WQ_ORDERED_EXPLICIT flag but gave it the
same value as __WQ_LEGACY. I don't believe these were intended to
mean the same thing, so renumber __WQ_ORDERED_EXPLICIT.
Fixes:
0a94efb5acbb ("workqueue: implicit ordered attribute should be ...")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ilia Mirkin [Thu, 10 Aug 2017 16:13:40 +0000 (12:13 -0400)]
drm/nouveau/pci/msi: disable MSI on big-endian platforms by default
commit
bc60c90f472b6e762ea96ef384072145adc8d4af upstream.
It appears that MSI does not work on either G5 PPC nor on a E5500-based
platform, where other hardware is reported to work fine with MSI.
Both tests were conducted with NV4x hardware, so perhaps other (or even
this) hardware can be made to work. It's still possible to force-enable
with config=NvMSI=1 on load.
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>
Christian Borntraeger [Thu, 24 Aug 2017 10:55:08 +0000 (12:55 +0200)]
s390/mm: avoid empty zero pages for KVM guests to avoid postcopy hangs
commit
fa41ba0d08de7c975c3e94d0067553f9b934221f upstream.
Right now there is a potential hang situation for postcopy migrations,
if the guest is enabling storage keys on the target system during the
postcopy process.
For storage key virtualization, we have to forbid the empty zero page as
the storage key is a property of the physical page frame. As we enable
storage key handling lazily we then drop all mappings for empty zero
pages for lazy refaulting later on.
This does not work with the postcopy migration, which relies on the
empty zero page never triggering a fault again in the future. The reason
is that postcopy migration will simply read a page on the target system
if that page is a known zero page to fault in an empty zero page. At
the same time postcopy remembers that this page was already transferred
- so any future userfault on that page will NOT be retransmitted again
to avoid races.
If now the guest enters the storage key mode while in postcopy, we will
break this assumption of postcopy.
The solution is to disable the empty zero page for KVM guests early on
and not during storage key enablement. With this change, the postcopy
migration process is guaranteed to start after no zero pages are left.
As guest pages are very likely not empty zero pages anyway the memory
overhead is also pretty small.
While at it this also adds proper page table locking to the zero page
removal.
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Acked-by: Janosch Frank <frankja@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Moese [Tue, 29 Aug 2017 12:47:24 +0000 (14:47 +0200)]
MCB: add support for SC31 to mcb-lpc
commit
acf5e051ac44d5dc60b21bc4734ef1b844d55551 upstream.
This patch adds the resources and DMI ID's for the MEN SC31,
which uses a different address region to map the LPC bus than
the one used for the existing SC24.
Signed-off-by: Michael Moese <michael.moese@men.de>
[jth add stable tag]
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Brian Norris [Fri, 30 Jun 2017 01:23:54 +0000 (18:23 -0700)]
mwifiex: correct channel stat buffer overflows
commit
4b5dde2d6234ff5bc68e97e6901d1f2a0a7f3749 upstream.
mwifiex records information about various channels as it receives scan
information. It does this by appending to a buffer that was sized
to the max number of supported channels on any band, but there are
numerous problems:
(a) scans can return info from more than one band (e.g., both 2.4 and 5
GHz), so the determined "max" is not large enough
(b) some firmware appears to return multiple results for a given
channel, so the max *really* isn't large enough
(c) there is no bounds checking when stashing these stats, so problems
(a) and (b) can easily lead to buffer overflows
Let's patch this by setting a slightly-more-correct max (that accounts
for a combination of both 2.4G and 5G bands) and adding a bounds check
when writing to our statistics buffer.
Due to problem (b), we still might not properly report all known survey
information (e.g., with "iw <dev> survey dump"), since duplicate results
(or otherwise "larger than expected" results) will cause some
truncation. But that's a problem for a future bugfix.
(And because of this known deficiency, only log the excess at the WARN
level, since that isn't visible by default in this driver and would
otherwise be a bit too noisy.)
Fixes:
bf35443314ac ("mwifiex: channel statistics support for mwifiex")
Cc: Avinash Patil <patila@marvell.com>
Cc: Xinming Hu <huxm@marvell.com>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Ganapathi Bhat <gbhat@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Edwin Török [Thu, 3 Aug 2017 09:30:06 +0000 (10:30 +0100)]
dlm: avoid double-free on error path in dlm_device_{register,unregister}
commit
55acdd926f6b21a5cdba23da98a48aedf19ac9c3 upstream.
Can be reproduced when running dlm_controld (tested on 4.4.x, 4.12.4):
# seq 1 100 | xargs -P0 -n1 dlm_tool join
# seq 1 100 | xargs -P0 -n1 dlm_tool leave
misc_register fails due to duplicate sysfs entry, which causes
dlm_device_register to free ls->ls_device.name.
In dlm_device_deregister the name was freed again, causing memory
corruption.
According to the comment in dlm_device_deregister the name should've been
set to NULL when registration fails,
so this patch does that.
sysfs: cannot create duplicate filename '/dev/char/10:1'
------------[ cut here ]------------
warning: cpu: 1 pid: 4450 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x56/0x70
modules linked in: msr rfcomm dlm ccm bnep dm_crypt uvcvideo
videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core videodev
btusb media btrtl btbcm btintel bluetooth ecdh_generic intel_rapl
x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm
snd_hda_codec_hdmi irqbypass crct10dif_pclmul crc32_pclmul
ghash_clmulni_intel thinkpad_acpi pcbc nvram snd_seq_midi
snd_seq_midi_event aesni_intel snd_hda_codec_realtek snd_hda_codec_generic
snd_rawmidi aes_x86_64 crypto_simd glue_helper snd_hda_intel snd_hda_codec
cryptd intel_cstate arc4 snd_hda_core snd_seq snd_seq_device snd_hwdep
iwldvm intel_rapl_perf mac80211 joydev input_leds iwlwifi serio_raw
cfg80211 snd_pcm shpchp snd_timer snd mac_hid mei_me lpc_ich mei soundcore
sunrpc parport_pc ppdev lp parport autofs4 i915 psmouse
e1000e ahci libahci i2c_algo_bit sdhci_pci ptp drm_kms_helper sdhci
pps_core syscopyarea sysfillrect sysimgblt fb_sys_fops drm wmi video
cpu: 1 pid: 4450 comm: dlm_test.exe not tainted 4.12.4-041204-generic
hardware name: lenovo 232425u/232425u, bios g2et82ww (2.02 ) 09/11/2012
task:
ffff96b0cbabe140 task.stack:
ffffb199027d0000
rip: 0010:sysfs_warn_dup+0x56/0x70
rsp: 0018:
ffffb199027d3c58 eflags:
00010282
rax:
0000000000000038 rbx:
ffff96b0e2c49158 rcx:
0000000000000006
rdx:
0000000000000000 rsi:
0000000000000086 rdi:
ffff96b15e24dcc0
rbp:
ffffb199027d3c70 r08:
0000000000000001 r09:
0000000000000721
r10:
ffffb199027d3c00 r11:
0000000000000721 r12:
ffffb199027d3cd1
r13:
ffff96b1592088f0 r14:
0000000000000001 r15:
ffffffffffffffef
fs:
00007f78069c0700(0000) gs:
ffff96b15e240000(0000)
knlgs:
0000000000000000
cs: 0010 ds: 0000 es: 0000 cr0:
0000000080050033
cr2:
000000178625ed28 cr3:
0000000091d3e000 cr4:
00000000001406e0
call trace:
sysfs_do_create_link_sd.isra.2+0x9e/0xb0
sysfs_create_link+0x25/0x40
device_add+0x5a9/0x640
device_create_groups_vargs+0xe0/0xf0
device_create_with_groups+0x3f/0x60
? snprintf+0x45/0x70
misc_register+0x140/0x180
device_write+0x6a8/0x790 [dlm]
__vfs_write+0x37/0x160
? apparmor_file_permission+0x1a/0x20
? security_file_permission+0x3b/0xc0
vfs_write+0xb5/0x1a0
sys_write+0x55/0xc0
? sys_fcntl+0x5d/0xb0
entry_syscall_64_fastpath+0x1e/0xa9
rip: 0033:0x7f78083454bd
rsp: 002b:
00007f78069bbd30 eflags:
00000293 orig_rax:
0000000000000001
rax:
ffffffffffffffda rbx:
0000000000000006 rcx:
00007f78083454bd
rdx:
000000000000009c rsi:
00007f78069bee00 rdi:
0000000000000005
rbp:
00007f77f8000a20 r08:
000000000000fcf0 r09:
0000000000000032
r10:
0000000000000024 r11:
0000000000000293 r12:
00007f78069bde00
r13:
00007f78069bee00 r14:
000000000000000a r15:
00007f78069bbd70
code: 85 c0 48 89 c3 74 12 b9 00 10 00 00 48 89 c2 31 f6 4c 89 ef e8 2c c8
ff ff 4c 89 e2 48 89 de 48 c7 c7 b0 8e 0c a8 e8 41 e8 ed ff <0f> ff 48 89
df e8 00 d5 f4 ff 5b 41 5c 41 5d 5d c3 66 0f 1f 84
---[ end trace
40412246357cc9e0 ]---
dlm:
59f24629-ae39-44e2-9030-
397ebc2eda26: leaving the lockspace group...
bug: unable to handle kernel null pointer dereference at
0000000000000001
ip: [<
ffffffff811a3b4a>] kmem_cache_alloc+0x7a/0x140
pgd 0
oops: 0000 [#1] smp
modules linked in: dlm 8021q garp mrp stp llc openvswitch nf_defrag_ipv6
nf_conntrack libcrc32c iptable_filter dm_multipath crc32_pclmul dm_mod
aesni_intel psmouse aes_x86_64 sg ablk_helper cryptd lrw gf128mul
glue_helper i2c_piix4 nls_utf8 tpm_tis tpm isofs nfsd auth_rpcgss
oid_registry nfs_acl lockd grace sunrpc xen_wdt ip_tables x_tables autofs4
hid_generic usbhid hid sr_mod cdrom sd_mod ata_generic pata_acpi 8139too
serio_raw ata_piix 8139cp mii uhci_hcd ehci_pci ehci_hcd libata
scsi_dh_rdac scsi_dh_hp_sw scsi_dh_emc scsi_dh_alua scsi_mod ipv6
cpu: 0 pid: 394 comm: systemd-udevd tainted: g w 4.4.0+0 #1
hardware name: xen hvm domu, bios 4.7.2-2.2 05/11/2017
task:
ffff880002410000 ti:
ffff88000243c000 task.ti:
ffff88000243c000
rip: e030:[<
ffffffff811a3b4a>] [<
ffffffff811a3b4a>]
kmem_cache_alloc+0x7a/0x140
rsp: e02b:
ffff88000243fd90 eflags:
00010202
rax:
0000000000000000 rbx:
ffff8800029864d0 rcx:
000000000007b36c
rdx:
000000000007b36b rsi:
00000000024000c0 rdi:
ffff880036801c00
rbp:
ffff88000243fdc0 r08:
0000000000018880 r09:
0000000000000054
r10:
000000000000004a r11:
ffff880034ace6c0 r12:
00000000024000c0
r13:
ffff880036801c00 r14:
0000000000000001 r15:
ffffffff8118dcc2
fs:
00007f0ab77548c0(0000) gs:
ffff880036e00000(0000) knlgs:
0000000000000000
cs: e033 ds: 0000 es: 0000 cr0:
0000000080050033
cr2:
0000000000000001 cr3:
000000000332d000 cr4:
0000000000040660
stack:
ffffffff8118dc90 ffff8800029864d0 0000000000000000 ffff88003430b0b0
ffff880034b78320 ffff88003430b0b0 ffff88000243fdf8 ffffffff8118dcc2
ffff8800349c6700 ffff8800029864d0 000000000000000b 00007f0ab7754b90
call trace:
[<
ffffffff8118dc90>] ? anon_vma_fork+0x60/0x140
[<
ffffffff8118dcc2>] anon_vma_fork+0x92/0x140
[<
ffffffff8107033e>] copy_process+0xcae/0x1a80
[<
ffffffff8107128b>] _do_fork+0x8b/0x2d0
[<
ffffffff81071579>] sys_clone+0x19/0x20
[<
ffffffff815a30ae>] entry_syscall_64_fastpath+0x12/0x71
] code: f6 75 1c 4c 89 fa 44 89 e6 4c 89 ef e8 a7 e4 00 00 41 f7 c4 00 80
00 00 49 89 c6 74 47 eb 32 49 63 45 20 48 8d 4a 01 4d 8b 45 00 <49> 8b 1c
06 4c 89 f0 65 49 0f c7 08 0f 94 c0 84 c0 74 ac 49 63
rip [<
ffffffff811a3b4a>] kmem_cache_alloc+0x7a/0x140
rsp <
ffff88000243fd90>
cr2:
0000000000000001
--[ end trace
70cb9fd1b164a0e8 ]--
Signed-off-by: Edwin Török <edvin.torok@citrix.com>
Signed-off-by: David Teigland <teigland@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Luca Coelho [Wed, 16 Aug 2017 05:47:38 +0000 (08:47 +0300)]
iwlwifi: pci: add new PCI ID for 7265D
commit
3f7a5e13e85026b6e460bbd6e87f87379421d272 upstream.
We have a new PCI subsystem ID for 7265D. Add it to the list.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dmitry Tunin [Tue, 8 Aug 2017 11:09:02 +0000 (14:09 +0300)]
Bluetooth: Add support of 13d3:3494 RTL8723BE device
commit
a81d72d2002d6a932bd83022cbf8c442b1b97512 upstream.
T: Bus=02 Lev=01 Prnt=01 Port=03 Cnt=03 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 2.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=13d3 ProdID=3494 Rev= 2.00
S: Manufacturer=Realtek
S: Product=Bluetooth Radio
S: SerialNumber=
00e04c000001
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Malcolm Priestley [Sun, 30 Jul 2017 08:02:19 +0000 (09:02 +0100)]
rtlwifi: rtl_pci_probe: Fix fail path of _rtl_pci_find_adapter
commit
fc81bab5eeb103711925d7510157cf5cd2b153f4 upstream.
_rtl_pci_find_adapter fail path will jump to label fail3 for
unsupported adapter types.
However, on course for fail3 there will be call rtl_deinit_core
before rtl_init_core.
For the inclusion of checking pci_iounmap this fail can be moved to
fail2.
Fixes
[ 4.492963] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 4.493067] IP: rtl_deinit_core+0x31/0x90 [rtlwifi]
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Oscar Campos [Wed, 19 Jul 2017 00:20:36 +0000 (17:20 -0700)]
Input: trackpoint - assume 3 buttons when buttons detection fails
commit
293b915fd9bebf33cdc906516fb28d54649a25ac upstream.
Trackpoint buttons detection fails on ThinkPad 570 and 470 series,
this makes the middle button of the trackpoint to not being recogized.
As I don't believe there is any trackpoint with less than 3 buttons this
patch just assumes three buttons when the extended button information
read fails.
Signed-off-by: Oscar Campos <oscar.campos@member.fsf.org>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rakesh Pillai [Wed, 2 Aug 2017 10:33:37 +0000 (16:03 +0530)]
ath10k: fix memory leak in rx ring buffer allocation
commit
f35a7f91f66af528b3ee1921de16bea31d347ab0 upstream.
The rx ring buffers are added to a hash table if
firmware support full rx reorder. If the full rx
reorder support flag is not set before allocating
the rx ring buffers, none of the buffers are added
to the hash table.
There is a race condition between rx ring refill and
rx buffer replenish from napi poll. The interrupts are
enabled in hif start, before the rx ring is refilled during init.
We replenish buffers from napi poll due to the interrupts which
get enabled after hif start. Hence before the entire rx ring is
refilled during the init, the napi poll replenishes a few buffers
in steps of 100 buffers per attempt. During this rx ring replenish
from napi poll, the rx reorder flag has not been set due to which
the replenished buffers are not added to the hash table
Set the rx full reorder support flag before we allocate
the rx ring buffer to avoid the memory leak.
Signed-off-by: Rakesh Pillai <pillair@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Cc: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexander Shishkin [Thu, 30 Jun 2016 13:11:31 +0000 (16:11 +0300)]
intel_th: pci: Add Cannon Lake PCH-LP support
commit
efb3669e14fe17d0ec4ecf57d0365039fe726f59 upstream.
This adds Intel(R) Trace Hub PCI ID for Cannon Lake PCH-LP.
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexander Shishkin [Thu, 30 Jun 2016 13:11:13 +0000 (16:11 +0300)]
intel_th: pci: Add Cannon Lake PCH-H support
commit
84331e1390b6378a5129a3678c87a42c6f697d29 upstream.
This adds Intel(R) Trace Hub PCI ID for Cannon Lake PCH-H.
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christophe JAILLET [Tue, 29 Aug 2017 19:23:49 +0000 (21:23 +0200)]
driver core: bus: Fix a potential double free
commit
0f9b011d3321ca1079c7a46c18cb1956fbdb7bcb upstream.
The .release function of driver_ktype is 'driver_release()'.
This function frees the container_of this kobject.
So, this memory must not be freed explicitly in the error handling path of
'bus_add_driver()'. Otherwise a double free will occur.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Akinobu Mita [Thu, 20 Jul 2017 15:24:22 +0000 (00:24 +0900)]
iio: adc: ti-ads1015: add adequate wait time to get correct conversion
commit
4744d4e2afebf9644a439da9ca73d822fdd67bd9 upstream.
This driver assumes that the device is operating in the continuous
conversion mode which performs the conversion continuously. So this driver
inserts a wait time before reading the conversion register if the
configuration is changed from a previous request.
Currently, the wait time is only the period required for a single
conversion that is calculated as the reciprocal of the sampling frequency.
However we also need to wait for the the previous conversion to complete.
Otherwise we probably get the conversion result for the previous
configuration when the sampling frequency is lower.
Cc: Daniel Baluta <daniel.baluta@gmail.com>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Akinobu Mita [Thu, 20 Jul 2017 15:24:21 +0000 (00:24 +0900)]
iio: adc: ti-ads1015: don't return invalid value from buffer setup callbacks
commit
a6fe5e52d5ecfc98530034d6c9db73777cf41ede upstream.
pm_runtime_get_sync() and pm_runtime_put_autosuspend() return 0 on
success, 1 if the device's runtime PM status was already requested status
or error code on failure. So a positive return value doesn't indicate an
error condition.
However, any non-zero return values from buffer preenable and postdisable
callbacks are recognized as an error and this driver reuses the return
value from pm_runtime_get_sync() and pm_runtime_put_autosuspend() in
these callbacks. This change fixes the false error detections.
Cc: Daniel Baluta <daniel.baluta@gmail.com>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Akinobu Mita [Thu, 20 Jul 2017 15:24:20 +0000 (00:24 +0900)]
iio: adc: ti-ads1015: avoid getting stale result after runtime resume
commit
73e3e3fc50de50cfd68e945d85679c983ed31bd9 upstream.
This driver assumes that the device is operating in the continuous
conversion mode which performs the conversion continuously. So this driver
doesn't insert a wait time before reading the conversion register if the
configuration is not changed from a previous request.
This assumption is broken if the device is runtime suspended and entered
a power-down state. The forthcoming request causes reading a stale result
from the conversion register as the device is runtime resumed just before.
Fix it by adding a flag to detect that condition and insert a necessary
wait time.
Cc: Daniel Baluta <daniel.baluta@gmail.com>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Akinobu Mita [Thu, 20 Jul 2017 15:24:19 +0000 (00:24 +0900)]
iio: adc: ti-ads1015: enable conversion when CONFIG_PM is not set
commit
e8245c68350104b6022b6783719e843d69ea7c43 upstream.
The ADS1015 device have two operating modes, continuous conversion mode
and single-shot mode. This driver assumes that the continuous conversion
mode is selected by runtime resume callback when the ADC result is
requested.
If CONFIG_PM is disabled, the device is always in the default single-shot
mode and no one begins a single conversion. So the conversion register
doesn't contain valid ADC result. Fix it by changing the continuous mode
in probe function.
Cc: Daniel Baluta <daniel.baluta@gmail.com>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Akinobu Mita [Thu, 20 Jul 2017 15:24:18 +0000 (00:24 +0900)]
iio: adc: ti-ads1015: fix scale information for ADS1115
commit
8d0e8e795623bd6229cf48bb7777a1c456c370ed upstream.
The ti-ads1015 driver supports ADS1015 and ADS1115 devices. The same
scale information is used for both devices in this driver, however they
have actually different values and the ADS1115's one is not correct.
These devices have the same full-scale input voltage range for each PGA
selection. So instead of adding another hardcoded scale information,
compute a correct scale on demand from each device's resolution.
Cc: Daniel Baluta <daniel.baluta@gmail.com>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Akinobu Mita [Thu, 20 Jul 2017 15:24:17 +0000 (00:24 +0900)]
iio: adc: ti-ads1015: fix incorrect data rate setting update
commit
0d106b74c558e3000aa0e058b4725cacb70ce77a upstream.
The ti-ads1015 driver has eight iio voltage channels and each iio channel
can hold own sampling frequency information.
The ADS1015 device only have a single config register which contains an
input multiplexer selection, PGA and data rate settings. So the driver
should load the correct settings when the input multiplexer selection is
changed.
However, regardless of which channlel is currently selected, changing any
iio channel's sampling frequency information immediately overwrites the
current data rate setting in the config register.
It breaks the current data rate setting if the different channel's sampling
frequency information is changed because the data rate setting is not
reloaded when the input multiplexer is switched.
This removes the unexpected config register update and correctly load the
data rate setting before getting adc result.
Cc: Daniel Baluta <daniel.baluta@gmail.com>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Colin Ian King [Fri, 18 Aug 2017 13:34:16 +0000 (14:34 +0100)]
staging/rts5208: fix incorrect shift to extract upper nybble
commit
34ff1bf4920471cff66775dc39537b15c5f0feff upstream.
The mask of sns_key_info1 suggests the upper nybble is being extracted
however the following shift of 8 bits is too large and always results in
0. Fix this by shifting only by 4 bits to correctly get the upper nybble.
Detected by CoverityScan, CID#142891 ("Operands don't affect result")
Fixes:
fa590c222fba ("staging: rts5208: add support for rts5208 and rts5288")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Douglas Anderson [Thu, 10 Aug 2017 22:42:22 +0000 (15:42 -0700)]
USB: core: Avoid race of async_completed() w/ usbdev_release()
commit
ed62ca2f4f51c17841ea39d98c0c409cb53a3e10 upstream.
While running reboot tests w/ a specific set of USB devices (and
slub_debug enabled), I found that once every few hours my device would
be crashed with a stack that looked like this:
[ 14.012445] BUG: spinlock bad magic on CPU#0, modprobe/2091
[ 14.012460] lock: 0xffffffc0cb055978, .magic:
ffffffc0, .owner: cryption contexts: %lu/%lu
[ 14.012460] /
1025536097, .owner_cpu: 0
[ 14.012466] CPU: 0 PID: 2091 Comm: modprobe Not tainted 4.4.79 #352
[ 14.012468] Hardware name: Google Kevin (DT)
[ 14.012471] Call trace:
[ 14.012483] [<....>] dump_backtrace+0x0/0x160
[ 14.012487] [<....>] show_stack+0x20/0x28
[ 14.012494] [<....>] dump_stack+0xb4/0xf0
[ 14.012500] [<....>] spin_dump+0x8c/0x98
[ 14.012504] [<....>] spin_bug+0x30/0x3c
[ 14.012508] [<....>] do_raw_spin_lock+0x40/0x164
[ 14.012515] [<....>] _raw_spin_lock_irqsave+0x64/0x74
[ 14.012521] [<....>] __wake_up+0x2c/0x60
[ 14.012528] [<....>] async_completed+0x2d0/0x300
[ 14.012534] [<....>] __usb_hcd_giveback_urb+0xc4/0x138
[ 14.012538] [<....>] usb_hcd_giveback_urb+0x54/0xf0
[ 14.012544] [<....>] xhci_irq+0x1314/0x1348
[ 14.012548] [<....>] usb_hcd_irq+0x40/0x50
[ 14.012553] [<....>] handle_irq_event_percpu+0x1b4/0x3f0
[ 14.012556] [<....>] handle_irq_event+0x4c/0x7c
[ 14.012561] [<....>] handle_fasteoi_irq+0x158/0x1c8
[ 14.012564] [<....>] generic_handle_irq+0x30/0x44
[ 14.012568] [<....>] __handle_domain_irq+0x90/0xbc
[ 14.012572] [<....>] gic_handle_irq+0xcc/0x18c
Investigation using kgdb() found that the wait queue that was passed
into wake_up() had been freed (it was filled with slub_debug poison).
I analyzed and instrumented the code and reproduced. My current
belief is that this is happening:
1. async_completed() is called (from IRQ). Moves "as" onto the
completed list.
2. On another CPU, proc_reapurbnonblock_compat() calls
async_getcompleted(). Blocks on spinlock.
3. async_completed() releases the lock; keeps running; gets blocked
midway through wake_up().
4. proc_reapurbnonblock_compat() => async_getcompleted() gets the
lock; removes "as" from completed list and frees it.
5. usbdev_release() is called. Frees "ps".
6. async_completed() finally continues running wake_up(). ...but
wake_up() has a pointer to the freed "ps".
The instrumentation that led me to believe this was based on adding
some trace_printk() calls in a select few functions and then using
kdb's "ftdump" at crash time. The trace follows (NOTE: in the trace
below I cheated a little bit and added a udelay(1000) in
async_completed() after releasing the spinlock because I wanted it to
trigger quicker):
<...>-2104 0d.h2 13759034us!: async_completed at start: as=
ffffffc0cc638200
mtpd-2055 3.... 13759356us : async_getcompleted before spin_lock_irqsave
mtpd-2055 3d..1 13759362us : async_getcompleted after list_del_init: as=
ffffffc0cc638200
mtpd-2055 3.... 13759371us+: proc_reapurbnonblock_compat: free_async(
ffffffc0cc638200)
mtpd-2055 3.... 13759422us+: async_getcompleted before spin_lock_irqsave
mtpd-2055 3.... 13759479us : usbdev_release at start: ps=
ffffffc0cc042080
mtpd-2055 3.... 13759487us : async_getcompleted before spin_lock_irqsave
mtpd-2055 3.... 13759497us!: usbdev_release after kfree(ps): ps=
ffffffc0cc042080
<...>-2104 0d.h2 13760294us : async_completed before wake_up(): as=
ffffffc0cc638200
To fix this problem we can just move the wake_up() under the ps->lock.
There should be no issues there that I'm aware of.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Thu, 24 Aug 2017 16:38:36 +0000 (11:38 -0500)]
USB: musb: fix external abort on suspend
commit
082df8be455ade361748f0385aa6c9c8d07be167 upstream.
Make sure that the controller is runtime resumed when system suspending
to avoid an external abort when accessing the interrupt registers:
Unhandled fault: external abort on non-linefetch (0x1008) at 0xd025840a
...
[<
c05481a4>] (musb_default_readb) from [<
c0545abc>] (musb_disable_interrupts+0x84/0xa8)
[<
c0545abc>] (musb_disable_interrupts) from [<
c0546b08>] (musb_suspend+0x38/0xb8)
[<
c0546b08>] (musb_suspend) from [<
c04a57f8>] (platform_pm_suspend+0x3c/0x64)
This is easily reproduced on a BBB by enabling the peripheral port only
(as the host port may enable the shared clock) and keeping it
disconnected so that the controller is runtime suspended. (Well, you
would also need to the not-yet-merged am33xx-suspend patches by Dave
Gerlach to be able to suspend the BBB.)
This is a regression that was introduced by commit
1c4d0b4e1806 ("usb:
musb: Remove pm_runtime_set_irq_safe") which allowed the parent glue
device to runtime suspend and thereby exposed a couple of older issues:
Register accesses without explicitly making sure the controller is
runtime resumed during suspend was first introduced by commit
c338412b5ded
("usb: musb: unconditionally save and restore the context on suspend")
in 3.14.
Commit
a1fc1920aaaa ("usb: musb: core: make sure musb is in RPM_ACTIVE on
resume") later started setting the RPM status to active during resume,
and this was also implicitly relying on the parent always being active.
Since commit
71723f95463d ("PM / runtime: print error when activating a
child to unactive parent") this now also results in the following
warning:
musb-hdrc musb-hdrc.0: runtime PM trying to activate child device
musb-hdrc.0 but parent (
47401400.usb) is not active
This patch has been verified on 4.13-rc2, 4.12 and 4.9 using a BBB
(the dsps glue would always be active also in 4.8).
Fixes:
c338412b5ded ("usb: musb: unconditionally save and restore the context on suspend")
Fixes:
a1fc1920aaaa ("usb: musb: core: make sure musb is in RPM_ACTIVE on resume")
Fixes:
1c4d0b4e1806 ("usb: musb: Remove pm_runtime_set_irq_safe")
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Daniel Mack <zonque@gmail.com>
Cc: Dave Gerlach <d-gerlach@ti.com>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sandeep Singh [Thu, 24 Aug 2017 04:27:15 +0000 (09:57 +0530)]
usb:xhci:Fix regression when ATI chipsets detected
commit
e6b422b88b46353cf596e0db6dc0e39d50d90d6e upstream.
The following commit cause a regression on ATI chipsets.
'commit
e788787ef4f9 ("usb:xhci:Add quirk for Certain
failing HP keyboard on reset after resume")'
This causes pinfo->smbus_dev to be wrongly set to NULL on
systems with the ATI chipset that this function checks for first.
Added conditional check for AMD chipsets to avoid the overwriting
pinfo->smbus_dev.
Reported-by: Ben Hutchings <ben@decadent.org.uk>
Fixes:
e788787ef4f9 ("usb:xhci:Add quirk for Certain
failing HP keyboard on reset after resume")
cc: Nehal Shah <Nehal-bakulchandra.Shah@amd.com>
Signed-off-by: Sandeep Singh <Sandeep.Singh@amd.com>
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dmitry Fleytman [Fri, 25 Aug 2017 07:38:35 +0000 (10:38 +0300)]
usb: Add device quirk for Logitech HD Pro Webcam C920-C
commit
a1279ef74eeeb5f627f091c71d80dd7ac766c99d upstream.
Commit
e0429362ab15
("usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e")
introduced quirk to workaround an issue with some Logitech webcams.
Apparently model C920-C has the same issue so applying
the same quirk as well.
See aforementioned commit message for detailed explanation of the problem.
Signed-off-by: Dmitry Fleytman <dmitry@daynix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Maciej S. Szmigiero [Tue, 29 Aug 2017 19:50:03 +0000 (21:50 +0200)]
USB: serial: option: add support for D-Link DWM-157 C1
commit
169e86546f5712179709de23cd64bbb15f199fab upstream.
This commit adds support (an ID, really) for D-Link DWM-157 hardware
version C1 USB modem to option driver.
According to manufacturer-provided Windows INF file the device has four
serial ports:
"D-Link HSPA+DataCard Diagnostics Interface" (interface 2; modem port),
"D-Link HSPA+DataCard NMEA Device" (interface 3),
"D-Link HSPA+DataCard Speech Port" (interface 4),
"D-Link HSPA+DataCard Debug Port" (interface 5).
usb-devices output:
T: Bus=05 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 3 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=2001 ProdID=7d0e Rev=03.00
S: Manufacturer=D-Link,Inc
S: Product=D-Link DWM-157
C: #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=02 Prot=01 Driver=option
I: If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kai-Heng Feng [Wed, 16 Aug 2017 02:53:20 +0000 (10:53 +0800)]
usb: quirks: add delay init quirk for Corsair Strafe RGB keyboard
commit
de3af5bf259d7a0bfaac70441c8568ab5998d80c upstream.
Corsair Strafe RGB keyboard has trouble to initialize:
[ 1.679455] usb 3-6: new full-speed USB device number 4 using xhci_hcd
[ 6.871136] usb 3-6: unable to read config index 0 descriptor/all
[ 6.871138] usb 3-6: can't read configurations, error -110
[ 6.991019] usb 3-6: new full-speed USB device number 5 using xhci_hcd
[ 12.246642] usb 3-6: unable to read config index 0 descriptor/all
[ 12.246644] usb 3-6: can't read configurations, error -110
[ 12.366555] usb 3-6: new full-speed USB device number 6 using xhci_hcd
[ 17.622145] usb 3-6: unable to read config index 0 descriptor/all
[ 17.622147] usb 3-6: can't read configurations, error -110
[ 17.742093] usb 3-6: new full-speed USB device number 7 using xhci_hcd
[ 22.997715] usb 3-6: unable to read config index 0 descriptor/all
[ 22.997716] usb 3-6: can't read configurations, error -110
Although it may work after several times unpluging/pluging:
[ 68.195240] usb 3-6: new full-speed USB device number 11 using xhci_hcd
[ 68.337459] usb 3-6: New USB device found, idVendor=1b1c, idProduct=1b20
[ 68.337463] usb 3-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 68.337466] usb 3-6: Product: Corsair STRAFE RGB Gaming Keyboard
[ 68.337468] usb 3-6: Manufacturer: Corsair
[ 68.337470] usb 3-6: SerialNumber:
0F013021AEB8046755A93ED3F5001941
Tried three quirks: USB_QUIRK_DELAY_INIT, USB_QUIRK_NO_LPM and
USB_QUIRK_DEVICE_QUALIFIER, user confirmed that USB_QUIRK_DELAY_INIT alone
can workaround this issue. Hence add the quirk for Corsair Strafe RGB.
BugLink: https://bugs.launchpad.net/bugs/1678477
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Thu, 7 Sep 2017 06:35:53 +0000 (08:35 +0200)]
Linux 4.9.48
Oleg Nesterov [Fri, 1 Sep 2017 16:55:33 +0000 (18:55 +0200)]
epoll: fix race between ep_poll_callback(POLLFREE) and ep_free()/ep_remove()
commit
138e4ad67afd5c6c318b056b4d17c17f2c0ca5c0 upstream.
The race was introduced by me in commit
971316f0503a ("epoll:
ep_unregister_pollwait() can use the freed pwq->whead"). I did not
realize that nothing can protect eventpoll after ep_poll_callback() sets
->whead = NULL, only whead->lock can save us from the race with
ep_free() or ep_remove().
Move ->whead = NULL to the end of ep_poll_callback() and add the
necessary barriers.
TODO: cleanup the ewake/EPOLLEXCLUSIVE logic, it was confusing even
before this patch.
Hopefully this explains use-after-free reported by syzcaller:
BUG: KASAN: use-after-free in debug_spin_lock_before
...
_raw_spin_lock_irqsave+0x4a/0x60 kernel/locking/spinlock.c:159
ep_poll_callback+0x29f/0xff0 fs/eventpoll.c:1148
this is spin_lock(eventpoll->lock),
...
Freed by task 17774:
...
kfree+0xe8/0x2c0 mm/slub.c:3883
ep_free+0x22c/0x2a0 fs/eventpoll.c:865
Fixes:
971316f0503a ("epoll: ep_unregister_pollwait() can use the freed pwq->whead")
Reported-by: 范龙飞 <long7573@126.com>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Suzuki K Poulose [Tue, 16 May 2017 09:34:54 +0000 (10:34 +0100)]
kvm: arm/arm64: Force reading uncached stage2 PGD
commit
2952a6070e07ebdd5896f1f5b861acad677caded upstream.
Make sure we don't use a cached value of the KVM stage2 PGD while
resetting the PGD.
Cc: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Reviewed-by: Christoffer Dall <cdall@linaro.org>
Signed-off-by: Christoffer Dall <cdall@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Xiangliang.Yu [Wed, 16 Aug 2017 06:25:51 +0000 (14:25 +0800)]
drm/ttm: Fix accounting error when fail to get pages for pool
commit
9afae2719273fa1d406829bf3498f82dbdba71c7 upstream.
When fail to get needed page for pool, need to put allocated pages
into pool. But current code has a miscalculation of allocated pages,
correct it.
Signed-off-by: Xiangliang.Yu <Xiangliang.Yu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Monk Liu <monk.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vladis Dronov [Wed, 2 Aug 2017 17:50:14 +0000 (19:50 +0200)]
xfrm: policy: check policy direction value
commit
7bab09631c2a303f87a7eb7e3d69e888673b9b7e upstream.
The 'dir' parameter in xfrm_migrate() is a user-controlled byte which is used
as an array index. This can lead to an out-of-bound access, kernel lockup and
DoS. Add a check for the 'dir' value.
This fixes CVE-2017-11600.
References: https://bugzilla.redhat.com/show_bug.cgi?id=
1474928
Fixes:
80c9abaabf42 ("[XFRM]: Extension for dynamic update of endpoint address(es)")
Reported-by: "bo Zhang" <zhangbo5891001@gmail.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stephan Mueller [Thu, 10 Aug 2017 06:06:18 +0000 (08:06 +0200)]
lib/mpi: kunmap after finishing accessing buffer
commit
dea3eb8b452e36cf2dd572b0a797915ccf452ae6 upstream.
Using sg_miter_start and sg_miter_next, the buffer of an SG is kmap'ed
to *buff. The current code calls sg_miter_stop (and thus kunmap) on the
SG entry before the last access of *buff.
The patch moves the sg_miter_stop call after the last access to *buff to
ensure that the memory pointed to by *buff is still mapped.
Fixes:
4816c9406430 ("lib/mpi: Fix SG miter leak")
Signed-off-by: Stephan Mueller <smueller@chronox.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cong Wang [Thu, 31 Aug 2017 14:47:43 +0000 (16:47 +0200)]
wl1251: add a missing spin_lock_init()
commit
f581a0dd744fe32b0a8805e279c59ec1ac676d60 upstream.
wl1251: add a missing spin_lock_init()
This fixes the following kernel warning:
[ 5668.771453] BUG: spinlock bad magic on CPU#0, kworker/u2:3/9745
[ 5668.771850] lock: 0xce63ef20, .magic:
00000000, .owner: <none>/-1,
.owner_cpu: 0
[ 5668.772277] CPU: 0 PID: 9745 Comm: kworker/u2:3 Tainted: G W
4.12.0-03002-gec979a4-dirty #40
[ 5668.772796] Hardware name: Nokia RX-51 board
[ 5668.773071] Workqueue: phy1 wl1251_irq_work
[ 5668.773345] [<
c010c9e4>] (unwind_backtrace) from [<
c010a274>]
(show_stack+0x10/0x14)
[ 5668.773803] [<
c010a274>] (show_stack) from [<
c01545a4>]
(do_raw_spin_lock+0x6c/0xa0)
[ 5668.774230] [<
c01545a4>] (do_raw_spin_lock) from [<
c06ca578>]
(_raw_spin_lock_irqsave+0x10/0x18)
[ 5668.774658] [<
c06ca578>] (_raw_spin_lock_irqsave) from [<
c048c010>]
(wl1251_op_tx+0x38/0x5c)
[ 5668.775115] [<
c048c010>] (wl1251_op_tx) from [<
c06a12e8>]
(ieee80211_tx_frags+0x188/0x1c0)
[ 5668.775543] [<
c06a12e8>] (ieee80211_tx_frags) from [<
c06a138c>]
(__ieee80211_tx+0x6c/0x130)
[ 5668.775970] [<
c06a138c>] (__ieee80211_tx) from [<
c06a3dbc>]
(ieee80211_tx+0xdc/0x104)
[ 5668.776367] [<
c06a3dbc>] (ieee80211_tx) from [<
c06a4af0>]
(__ieee80211_subif_start_xmit+0x454/0x8c8)
[ 5668.776824] [<
c06a4af0>] (__ieee80211_subif_start_xmit) from
[<
c06a4f94>] (ieee80211_subif_start_xmit+0x30/0x2fc)
[ 5668.777343] [<
c06a4f94>] (ieee80211_subif_start_xmit) from
[<
c0578848>] (dev_hard_start_xmit+0x80/0x118)
...
by adding the missing spin_lock_init().
Reported-by: Pavel Machek <pavel@ucw.cz>
Cc: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Steve French [Sun, 27 Aug 2017 21:56:08 +0000 (16:56 -0500)]
CIFS: remove endian related sparse warning
commit
6e3c1529c39e92ed64ca41d53abadabbaa1d5393 upstream.
Recent patch had an endian warning ie
cifs: return ENAMETOOLONG for overlong names in cifs_open()/cifs_lookup()
Signed-off-by: Steve French <smfrench@gmail.com>
CC: Ronnie Sahlberg <lsahlber@redhat.com>
Acked-by: Pavel Shilovsky <pshilov@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pavel Shilovsky [Thu, 24 Aug 2017 22:16:40 +0000 (15:16 -0700)]
CIFS: Fix maximum SMB2 header size
commit
9e37b1784f2be9397a903307574ee565bbadfd75 upstream.
Currently the maximum size of SMB2/3 header is set incorrectly which
leads to hanging of directory listing operations on encrypted SMB3
connections. Fix this by setting the maximum size to 170 bytes that
is calculated as RFC1002 length field size (4) + transform header
size (52) + SMB2 header size (64) + create response size (56).
Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
Signed-off-by: Steve French <smfrench@gmail.com>
Acked-by: Sachin Prabhu <sprabhu@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ben Hutchings [Thu, 1 Oct 2015 00:35:55 +0000 (01:35 +0100)]
alpha: uapi: Add support for __SANE_USERSPACE_TYPES__
commit
cec80d82142ab25c71eee24b529cfeaf17c43062 upstream.
This fixes compiler errors in perf such as:
tests/attr.c: In function 'store_event':
tests/attr.c:66:27: error: format '%llu' expects argument of type 'long long unsigned int', but argument 6 has type '__u64 {aka long unsigned int}' [-Werror=format=]
snprintf(path, PATH_MAX, "%s/event-%d-%llu-%d", dir,
^
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Tested-by: Michael Cree <mcree@orcon.net.nz>
Signed-off-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Waiman Long [Thu, 24 Aug 2017 16:04:29 +0000 (12:04 -0400)]
cpuset: Fix incorrect memory_pressure control file mapping
commit
1c08c22c874ac88799cab1f78c40f46110274915 upstream.
The memory_pressure control file was incorrectly set up without
a private value (0, by default). As a result, this control
file was treated like memory_migrate on read. By adding back the
FILE_MEMORY_PRESSURE private value, the correct memory pressure value
will be returned.
Signed-off-by: Waiman Long <longman@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Fixes:
7dbdb199d3bf ("cgroup: replace cftype->mode with CFTYPE_WORLD_WRITABLE")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tejun Heo [Mon, 28 Aug 2017 21:51:27 +0000 (14:51 -0700)]
cpumask: fix spurious cpumask_of_node() on non-NUMA multi-node configs
commit
b339752d054fb32863418452dff350a1086885b1 upstream.
When !NUMA, cpumask_of_node(@node) equals cpu_online_mask regardless of
@node. The assumption seems that if !NUMA, there shouldn't be more than
one node and thus reporting cpu_online_mask regardless of @node is
correct. However, that assumption was broken years ago to support
DISCONTIGMEM and whether a system has multiple nodes or not is
separately controlled by NEED_MULTIPLE_NODES.
This means that, on a system with !NUMA && NEED_MULTIPLE_NODES,
cpumask_of_node() will report cpu_online_mask for all possible nodes,
indicating that the CPUs are associated with multiple nodes which is an
impossible configuration.
This bug has been around forever but doesn't look like it has caused any
noticeable symptoms. However, it triggers a WARN recently added to
workqueue to verify NUMA affinity configuration.
Fix it by reporting empty cpumask on non-zero nodes if !NUMA.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-and-tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yan, Zheng [Fri, 4 Aug 2017 03:22:31 +0000 (11:22 +0800)]
ceph: fix readpage from fscache
commit
dd2bc473482eedc60c29cf00ad12568ce40ce511 upstream.
ceph_readpage() unlocks page prematurely prematurely in the case
that page is reading from fscache. Caller of readpage expects that
page is uptodate when it get unlocked. So page shoule get locked
by completion callback of fscache_read_or_alloc_pages()
Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
Reviewed-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mel Gorman [Thu, 31 Aug 2017 23:15:30 +0000 (16:15 -0700)]
mm, madvise: ensure poisoned pages are removed from per-cpu lists
commit
c461ad6a63b37ba74632e90c063d14823c884247 upstream.
Wendy Wang reported off-list that a RAS HWPOISON-SOFT test case failed
and bisected it to the commit
479f854a207c ("mm, page_alloc: defer
debugging checks of pages allocated from the PCP").
The problem is that a page that was poisoned with madvise() is reused.
The commit removed a check that would trigger if DEBUG_VM was enabled
but re-enabling the check only fixes the problem as a side-effect by
printing a bad_page warning and recovering.
The root of the problem is that an madvise() can leave a poisoned page
on the per-cpu list. This patch drains all per-cpu lists after pages
are poisoned so that they will not be reused. Wendy reports that the
test case in question passes with this patch applied. While this could
be done in a targeted fashion, it is over-complicated for such a rare
operation.
Link: http://lkml.kernel.org/r/20170828133414.7qro57jbepdcyz5x@techsingularity.net
Fixes:
479f854a207c ("mm, page_alloc: defer debugging checks of pages allocated from the PCP")
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Reported-by: Wang, Wendy <wendy.wang@intel.com>
Tested-by: Wang, Wendy <wendy.wang@intel.com>
Acked-by: David Rientjes <rientjes@google.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: "Hansen, Dave" <dave.hansen@intel.com>
Cc: "Luck, Tony" <tony.luck@intel.com>
Cc: Naoya Horiguchi <nao.horiguchi@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Biggers [Thu, 31 Aug 2017 23:15:26 +0000 (16:15 -0700)]
mm, uprobes: fix multiple free of ->uprobes_state.xol_area
commit
355627f518978b5167256d27492fe0b343aaf2f2 upstream.
Commit
7c051267931a ("mm, fork: make dup_mmap wait for mmap_sem for
write killable") made it possible to kill a forking task while it is
waiting to acquire its ->mmap_sem for write, in dup_mmap().
However, it was overlooked that this introduced an new error path before
the new mm_struct's ->uprobes_state.xol_area has been set to NULL after
being copied from the old mm_struct by the memcpy in dup_mm(). For a
task that has previously hit a uprobe tracepoint, this resulted in the
'struct xol_area' being freed multiple times if the task was killed at
just the right time while forking.
Fix it by setting ->uprobes_state.xol_area to NULL in mm_init() rather
than in uprobe_dup_mmap().
With CONFIG_UPROBE_EVENTS=y, the bug can be reproduced by the same C
program given by commit
2b7e8665b4ff ("fork: fix incorrect fput of
->exe_file causing use-after-free"), provided that a uprobe tracepoint
has been set on the fork_thread() function. For example:
$ gcc reproducer.c -o reproducer -lpthread
$ nm reproducer | grep fork_thread
0000000000400719 t fork_thread
$ echo "p $PWD/reproducer:0x719" > /sys/kernel/debug/tracing/uprobe_events
$ echo 1 > /sys/kernel/debug/tracing/events/uprobes/enable
$ ./reproducer
Here is the use-after-free reported by KASAN:
BUG: KASAN: use-after-free in uprobe_clear_state+0x1c4/0x200
Read of size 8 at addr
ffff8800320a8b88 by task reproducer/198
CPU: 1 PID: 198 Comm: reproducer Not tainted
4.13.0-rc7-00015-g36fde05f3fb5 #255
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-20170228_101828-anatol 04/01/2014
Call Trace:
dump_stack+0xdb/0x185
print_address_description+0x7e/0x290
kasan_report+0x23b/0x350
__asan_report_load8_noabort+0x19/0x20
uprobe_clear_state+0x1c4/0x200
mmput+0xd6/0x360
do_exit+0x740/0x1670
do_group_exit+0x13f/0x380
get_signal+0x597/0x17d0
do_signal+0x99/0x1df0
exit_to_usermode_loop+0x166/0x1e0
syscall_return_slowpath+0x258/0x2c0
entry_SYSCALL_64_fastpath+0xbc/0xbe
...
Allocated by task 199:
save_stack_trace+0x1b/0x20
kasan_kmalloc+0xfc/0x180
kmem_cache_alloc_trace+0xf3/0x330
__create_xol_area+0x10f/0x780
uprobe_notify_resume+0x1674/0x2210
exit_to_usermode_loop+0x150/0x1e0
prepare_exit_to_usermode+0x14b/0x180
retint_user+0x8/0x20
Freed by task 199:
save_stack_trace+0x1b/0x20
kasan_slab_free+0xa8/0x1a0
kfree+0xba/0x210
uprobe_clear_state+0x151/0x200
mmput+0xd6/0x360
copy_process.part.8+0x605f/0x65d0
_do_fork+0x1a5/0xbd0
SyS_clone+0x19/0x20
do_syscall_64+0x22f/0x660
return_from_SYSCALL_64+0x0/0x7a
Note: without KASAN, you may instead see a "Bad page state" message, or
simply a general protection fault.
Link: http://lkml.kernel.org/r/20170830033303.17927-1-ebiggers3@gmail.com
Fixes:
7c051267931a ("mm, fork: make dup_mmap wait for mmap_sem for write killable")
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reported-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Konstantin Khlebnikov <koct9i@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stephan Mueller [Wed, 16 Aug 2017 09:56:24 +0000 (11:56 +0200)]
crypto: algif_skcipher - only call put_page on referenced and used pages
commit
445a582738de6802669aeed9c33ca406c23c3b1f upstream.
For asynchronous operation, SGs are allocated without a page mapped to
them or with a page that is not used (ref-counted). If the SGL is freed,
the code must only call put_page for an SG if there was a page assigned
and ref-counted in the first place.
This fixes a kernel crash when using io_submit with more than one iocb
using the sendmsg and sendpage (vmsplice/splice) interface.
Signed-off-by: Stephan Mueller <smueller@chronox.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stephen Douthit [Mon, 7 Aug 2017 21:11:00 +0000 (17:11 -0400)]
i2c: ismt: Return EMSGSIZE for block reads with bogus length
commit
ba201c4f5ebe13d7819081756378777d8153f23e upstream.
Compare the number of bytes actually seen on the wire to the byte
count field returned by the slave device.
Previously we just overwrote the byte count returned by the slave
with the real byte count and let the caller figure out if the
message was sane.
Signed-off-by: Stephen Douthit <stephend@adiengineering.com>
Tested-by: Dan Priamo <danp@adiengineering.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stephen Douthit [Mon, 7 Aug 2017 21:10:59 +0000 (17:10 -0400)]
i2c: ismt: Don't duplicate the receive length for block reads
commit
b6c159a9cb69c2cf0bf59d4e12c3a2da77e4d994 upstream.
According to Table 15-14 of the C2000 EDS (Intel doc #510524) the
rx data pointed to by the descriptor dptr contains the byte count.
desc->rxbytes reports all bytes read on the wire, including the
"byte count" byte. So if a device sends 4 bytes in response to a
block read, on the wire and in the DMA buffer we see:
count data1 data2 data3 data4
0x04 0xde 0xad 0xbe 0xef
That's what we want to return in data->block to the next level.
Instead we were actually prefixing that with desc->rxbytes:
bad
count count data1 data2 data3 data4
0x05 0x04 0xde 0xad 0xbe 0xef
This was discovered while developing a BMC solution relying on the
ipmi_ssif.c driver which was trying to interpret the bogus length
field as part of the IPMI response.
Signed-off-by: Stephen Douthit <stephend@adiengineering.com>
Tested-by: Dan Priamo <danp@adiengineering.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
James Hogan [Sun, 13 Aug 2017 04:36:09 +0000 (21:36 -0700)]
irqchip: mips-gic: SYNC after enabling GIC region
commit
2c0e8382386f618c85d20cb05e7cf7df8cdd382c upstream.
A SYNC is required between enabling the GIC region and actually trying
to use it, even if the first access is a read, otherwise its possible
depending on the timing (and in my case depending on the precise
alignment of certain kernel code) to hit CM bus errors on that first
access.
Add the SYNC straight after setting the GIC base.
[paul.burton@imgtec.com:
Changes later in this series increase our likelihood of hitting this
by reducing the amount of code that runs between enabling the GIC &
accessing it.]
Fixes:
a7057270c280 ("irqchip: mips-gic: Add device-tree support")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/17019/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Sat, 2 Sep 2017 05:08:05 +0000 (07:08 +0200)]
Linux 4.9.47
Greg Kroah-Hartman [Thu, 31 Aug 2017 07:09:54 +0000 (09:09 +0200)]
lz4: fix bogus gcc warning
When building lz4 under gcc-7 we get the following bogus warning:
CC [M] lib/lz4/lz4hc_compress.o
lib/lz4/lz4hc_compress.c: In function ‘lz4hc_compress’:
lib/lz4/lz4hc_compress.c:179:42: warning: ‘delta’ may be used uninitialized in this function [-Wmaybe-uninitialized]
chaintable[(size_t)(ptr) & MAXD_MASK] = delta;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
lib/lz4/lz4hc_compress.c:134:6: note: ‘delta’ was declared here
u16 delta;
^~~~~
This doesn't show up in the 4.4-stable tree due to us turning off
warnings like this. It also doesn't show up in newer kernel versions as
this code was totally rewritten.
So for now, to get the 4.9-stable tree to build with 0 warnings on x86
allmodconfig, let's just shut the compiler up by initializing the
variable to 0, despite it not really doing anything.
To be far, this code is crazy complex, so the fact that gcc can't
determine if the variable is really used or not isn't that bad, I'd
blame the code here instead of the compiler.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hannes Reinecke [Mon, 24 Apr 2017 08:26:36 +0000 (10:26 +0200)]
scsi: sg: reset 'res_in_use' after unlinking reserved array
commit
e791ce27c3f6a1d3c746fd6a8f8e36c9540ec6f9 upstream.
Once the reserved page array is unused we can reset the 'res_in_use'
state; here we can do a lazy update without holding the mutex as we only
need to check against concurrent access, not concurrent release.
[mkp: checkpatch]
Fixes:
1bc0eb044615 ("scsi: sg: protect accesses to 'reserved' page array")
Signed-off-by: Hannes Reinecke <hare@suse.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Cc: Todd Poynor <toddpoynor@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hannes Reinecke [Fri, 7 Apr 2017 07:34:14 +0000 (09:34 +0200)]
scsi: sg: protect accesses to 'reserved' page array
commit
1bc0eb0446158cc76562176b80623aa119afee5b upstream.
The 'reserved' page array is used as a short-cut for mapping data,
saving us to allocate pages per request. However, the 'reserved' array
is only capable of holding one request, so this patch introduces a mutex
for protect 'sg_fd' against concurrent accesses.
Signed-off-by: Hannes Reinecke <hare@suse.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Tested-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[toddpoynor@google.com: backport to 3.18-4.9, fixup for bad ioctl
SG_SET_FORCE_LOW_DMA code removed in later versions and not modified by
the original patch.]
Signed-off-by: Hannes Reinecke <hare@suse.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Tested-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Waiman Long [Wed, 8 Feb 2017 19:46:48 +0000 (14:46 -0500)]
locking/spinlock/debug: Remove spinlock lockup detection code
commit
bc88c10d7e6900916f5e1ba3829d66a9de92b633 upstream.
The current spinlock lockup detection code can sometimes produce false
positives because of the unfairness of the locking algorithm itself.
So the lockup detection code is now removed. Instead, we are relying
on the NMI watchdog to detect potential lockup. We won't have lockup
detection if the watchdog isn't running.
The commented-out read-write lock lockup detection code are also
removed.
Signed-off-by: Waiman Long <longman@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sasha Levin <sasha.levin@oracle.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1486583208-11038-1-git-send-email-longman@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dave Martin [Fri, 18 Aug 2017 15:57:01 +0000 (16:57 +0100)]
arm64: fpsimd: Prevent registers leaking across exec
commit
096622104e14d8a1db4860bd557717067a0515d2 upstream.
There are some tricky dependencies between the different stages of
flushing the FPSIMD register state during exec, and these can race
with context switch in ways that can cause the old task's regs to
leak across. In particular, a context switch during the memset() can
cause some of the task's old FPSIMD registers to reappear.
Disabling preemption for this small window would be no big deal for
performance: preemption is already disabled for similar scenarios
like updating the FPSIMD registers in sigreturn.
So, instead of rearranging things in ways that might swap existing
subtle bugs for new ones, this patch just disables preemption
around the FPSIMD state flushing so that races of this type can't
occur here. This brings fpsimd_flush_thread() into line with other
code paths.
Fixes:
674c242c9323 ("arm64: flush FP/SIMD state correctly after execve()")
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arnd Bergmann [Wed, 19 Jul 2017 12:53:02 +0000 (14:53 +0200)]
x86/io: Add "memory" clobber to insb/insw/insl/outsb/outsw/outsl
commit
7206f9bf108eb9513d170c73f151367a1bdf3dbf upstream.
The x86 version of insb/insw/insl uses an inline assembly that does
not have the target buffer listed as an output. This can confuse
the compiler, leading it to think that a subsequent access of the
buffer is uninitialized:
drivers/net/wireless/wl3501_cs.c: In function ‘wl3501_mgmt_scan_confirm’:
drivers/net/wireless/wl3501_cs.c:665:9: error: ‘sig.status’ is used uninitialized in this function [-Werror=uninitialized]
drivers/net/wireless/wl3501_cs.c:668:12: error: ‘sig.cap_info’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/net/sb1000.c: In function 'sb1000_rx':
drivers/net/sb1000.c:775:9: error: 'st[0]' is used uninitialized in this function [-Werror=uninitialized]
drivers/net/sb1000.c:776:10: error: 'st[1]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/net/sb1000.c:784:11: error: 'st[1]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
I tried to mark the exact input buffer as an output here, but couldn't
figure it out. As suggested by Linus, marking all memory as clobbered
however is good enough too. For the outs operations, I also add the
memory clobber, to force the input to be written to local variables.
This is probably already guaranteed by the "asm volatile", but it can't
hurt to do this for symmetry.
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Link: http://lkml.kernel.org/r/20170719125310.2487451-5-arnd@arndb.de
Link: https://lkml.org/lkml/2017/7/12/605
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mark Rutland [Tue, 11 Jul 2017 14:19:22 +0000 (15:19 +0100)]
arm64: mm: abort uaccess retries upon fatal signal
commit
289d07a2dc6c6b6f3e4b8a62669320d99dbe6c3d upstream.
When there's a fatal signal pending, arm64's do_page_fault()
implementation returns 0. The intent is that we'll return to the
faulting userspace instruction, delivering the signal on the way.
However, if we take a fatal signal during fixing up a uaccess, this
results in a return to the faulting kernel instruction, which will be
instantly retried, resulting in the same fault being taken forever. As
the task never reaches userspace, the signal is not delivered, and the
task is left unkillable. While the task is stuck in this state, it can
inhibit the forward progress of the system.
To avoid this, we must ensure that when a fatal signal is pending, we
apply any necessary fixup for a faulting kernel instruction. Thus we
will return to an error path, and it is up to that code to make forward
progress towards delivering the fatal signal.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Laura Abbott <labbott@redhat.com>
Reviewed-by: Steve Capper <steve.capper@arm.com>
Tested-by: Steve Capper <steve.capper@arm.com>
Reviewed-by: James Morse <james.morse@arm.com>
Tested-by: James Morse <james.morse@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Suzuki K Poulose [Wed, 3 May 2017 14:17:51 +0000 (15:17 +0100)]
kvm: arm/arm64: Fix race in resetting stage2 PGD
commit
6c0d706b563af732adb094c5bf807437e8963e84 upstream.
In kvm_free_stage2_pgd() we check the stage2 PGD before holding
the lock and proceed to take the lock if it is valid. And we unmap
the page tables, followed by releasing the lock. We reset the PGD
only after dropping this lock, which could cause a race condition
where another thread waiting on or even holding the lock, could
potentially see that the PGD is still valid and proceed to perform
a stage2 operation and later encounter a NULL PGD.
[223090.242280] Unable to handle kernel NULL pointer dereference at
virtual address
00000040
[223090.262330] PC is at unmap_stage2_range+0x8c/0x428
[223090.262332] LR is at kvm_unmap_hva_handler+0x2c/0x3c
[223090.262531] Call trace:
[223090.262533] [<
ffff0000080adb78>] unmap_stage2_range+0x8c/0x428
[223090.262535] [<
ffff0000080adf40>] kvm_unmap_hva_handler+0x2c/0x3c
[223090.262537] [<
ffff0000080ace2c>] handle_hva_to_gpa+0xb0/0x104
[223090.262539] [<
ffff0000080af988>] kvm_unmap_hva+0x5c/0xbc
[223090.262543] [<
ffff0000080a2478>]
kvm_mmu_notifier_invalidate_page+0x50/0x8c
[223090.262547] [<
ffff0000082274f8>]
__mmu_notifier_invalidate_page+0x5c/0x84
[223090.262551] [<
ffff00000820b700>] try_to_unmap_one+0x1d0/0x4a0
[223090.262553] [<
ffff00000820c5c8>] rmap_walk+0x1cc/0x2e0
[223090.262555] [<
ffff00000820c90c>] try_to_unmap+0x74/0xa4
[223090.262557] [<
ffff000008230ce4>] migrate_pages+0x31c/0x5ac
[223090.262561] [<
ffff0000081f869c>] compact_zone+0x3fc/0x7ac
[223090.262563] [<
ffff0000081f8ae0>] compact_zone_order+0x94/0xb0
[223090.262564] [<
ffff0000081f91c0>] try_to_compact_pages+0x108/0x290
[223090.262569] [<
ffff0000081d5108>] __alloc_pages_direct_compact+0x70/0x1ac
[223090.262571] [<
ffff0000081d64a0>] __alloc_pages_nodemask+0x434/0x9f4
[223090.262572] [<
ffff0000082256f0>] alloc_pages_vma+0x230/0x254
[223090.262574] [<
ffff000008235e5c>] do_huge_pmd_anonymous_page+0x114/0x538
[223090.262576] [<
ffff000008201bec>] handle_mm_fault+0xd40/0x17a4
[223090.262577] [<
ffff0000081fb324>] __get_user_pages+0x12c/0x36c
[223090.262578] [<
ffff0000081fb804>] get_user_pages_unlocked+0xa4/0x1b8
[223090.262579] [<
ffff0000080a3ce8>] __gfn_to_pfn_memslot+0x280/0x31c
[223090.262580] [<
ffff0000080a3dd0>] gfn_to_pfn_prot+0x4c/0x5c
[223090.262582] [<
ffff0000080af3f8>] kvm_handle_guest_abort+0x240/0x774
[223090.262584] [<
ffff0000080b2bac>] handle_exit+0x11c/0x1ac
[223090.262586] [<
ffff0000080ab99c>] kvm_arch_vcpu_ioctl_run+0x31c/0x648
[223090.262587] [<
ffff0000080a1d78>] kvm_vcpu_ioctl+0x378/0x768
[223090.262590] [<
ffff00000825df5c>] do_vfs_ioctl+0x324/0x5a4
[223090.262591] [<
ffff00000825e26c>] SyS_ioctl+0x90/0xa4
[223090.262595] [<
ffff000008085d84>] el0_svc_naked+0x38/0x3c
This patch moves the stage2 PGD manipulation under the lock.
Reported-by: Alexander Graf <agraf@suse.de>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Radim Krčmář <rkrcmar@redhat.com>
Reviewed-by: Christoffer Dall <cdall@linaro.org>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Christoffer Dall <cdall@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Martin Liska [Fri, 12 May 2017 22:46:35 +0000 (15:46 -0700)]
gcov: support GCC 7.1
commit
05384213436ab690c46d9dfec706b80ef8d671ab upstream.
Starting from GCC 7.1, __gcov_exit is a new symbol expected to be
implemented in a profiling runtime.
[akpm@linux-foundation.org: coding-style fixes]
[mliska@suse.cz: v2]
Link: http://lkml.kernel.org/r/e63a3c59-0149-c97e-4084-20ca8f146b26@suse.cz
Link: http://lkml.kernel.org/r/8c4084fa-3885-29fe-5fc4-0d4ca199c785@suse.cz
Signed-off-by: Martin Liska <mliska@suse.cz>
Acked-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arnd Bergmann [Wed, 16 Nov 2016 15:07:10 +0000 (16:07 +0100)]
staging: wilc1000: simplify vif[i]->ndev accesses
commit
735bb39ca3bed8469b3b3a42d8cc57bdb9fc4dd7 upstream.
With gcc-7, I got a new warning for this driver:
wilc1000/linux_wlan.c: In function 'wilc_netdev_cleanup':
wilc1000/linux_wlan.c:1224:15: error: 'vif[1]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
wilc1000/linux_wlan.c:1224:15: error: 'vif[0]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
A closer look at the function reveals that it's more complex than
it needs to be, given that based on how the device is created
we always get
netdev_priv(vif->ndev) == vif
Based on this assumption, I found a few other places in the same file
that can be simplified. That code appears to be a relic from times
when the assumption above was not valid.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arnd Bergmann [Fri, 18 Nov 2016 16:14:01 +0000 (17:14 +0100)]
scsi: isci: avoid array subscript warning
commit
5cfa2a3c7342bd0b50716c8bb32ee491af43c785 upstream.
I'm getting a new warning with gcc-7:
isci/remote_node_context.c: In function 'sci_remote_node_context_destruct':
isci/remote_node_context.c:69:16: error: array subscript is above array bounds [-Werror=array-bounds]
This is odd, since we clearly cover all values for enum
scis_sds_remote_node_context_states here. Anyway, checking for an array
overflow can't harm and it makes the warning go away.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jiri Slaby [Fri, 14 Oct 2016 09:23:09 +0000 (11:23 +0200)]
p54: memset(0) whole array
commit
6f17581788206444cbbcdbc107498f85e9765e3d upstream.
gcc 7 complains:
drivers/net/wireless/intersil/p54/fwio.c: In function 'p54_scan':
drivers/net/wireless/intersil/p54/fwio.c:491:4: warning: 'memset' used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size]
Fix that by passing the correct size to memset.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Christian Lamparter <chunkeey@googlemail.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Acked-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Wed, 30 Aug 2017 08:24:43 +0000 (10:24 +0200)]
Linux 4.9.46
Benjamin Herrenschmidt [Mon, 24 Jul 2017 04:28:00 +0000 (14:28 +1000)]
powerpc/mm: Ensure cpumask update is ordered
commit
1a92a80ad386a1a6e3b36d576d52a1a456394b70 upstream.
There is no guarantee that the various isync's involved with
the context switch will order the update of the CPU mask with
the first TLB entry for the new context being loaded by the HW.
Be safe here and add a memory barrier to order any subsequent
load/store which may bring entries into the TLB.
The corresponding barrier on the other side already exists as
pte updates use pte_xchg() which uses __cmpxchg_u64 which has
a sync after the atomic operation.
Cc: stable@vger.kernel.org
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
[mpe: Add comments in the code]
[mpe: Backport to 4.12, minor context change]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lv Zheng [Wed, 16 Aug 2017 07:29:49 +0000 (15:29 +0800)]
ACPI: EC: Fix regression related to wrong ECDT initialization order
commit
98529b9272e06a7767034fb8a32e43cdecda240a upstream.
Commit
2a5708409e4e (ACPI / EC: Fix a gap that ECDT EC cannot handle
EC events) introduced acpi_ec_ecdt_start(), but that function is
invoked before acpi_ec_query_init(), which is too early. This causes
the kernel to crash if an EC event occurs after boot, when ec_query_wq
is not valid:
BUG: unable to handle kernel NULL pointer dereference at
0000000000000102
...
Workqueue: events acpi_ec_event_handler
task:
ffff9f539790dac0 task.stack:
ffffb437c0e10000
RIP: 0010:__queue_work+0x32/0x430
Normally, the DSDT EC should always be valid, so acpi_ec_ecdt_start()
is actually a no-op in the majority of cases. However, commit
c712bb58d827 (ACPI / EC: Add support to skip boot stage DSDT probe)
caused the probing of the DSDT EC as the "boot EC" to be skipped when
the ECDT EC is valid and uncovered the bug.
Fix this issue by invoking acpi_ec_ecdt_start() after acpi_ec_query_init()
in acpi_ec_init().
Link: https://jira01.devtools.intel.com/browse/LCK-4348
Fixes:
2a5708409e4e (ACPI / EC: Fix a gap that ECDT EC cannot handle EC events)
Fixes:
c712bb58d827 (ACPI / EC: Add support to skip boot stage DSDT probe)
Reported-by: Wang Wendy <wendy.wang@intel.com>
Tested-by: Feng Chenzhou <chenzhoux.feng@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
[ rjw: Changelog ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
James Morse [Thu, 16 Mar 2017 14:30:39 +0000 (14:30 +0000)]
ACPI / APEI: Add missing synchronize_rcu() on NOTIFY_SCI removal
commit
7d64f82cceb21e6d95db312d284f5f195e120154 upstream.
When removing a GHES device notified by SCI, list_del_rcu() is used,
ghes_remove() should call synchronize_rcu() before it goes on to call
kfree(ghes), otherwise concurrent RCU readers may still hold this list
entry after it has been freed.
Signed-off-by: James Morse <james.morse@arm.com>
Reviewed-by: "Huang, Ying" <ying.huang@intel.com>
Fixes:
81e88fdc432a (ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support)
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Joerg Roedel [Wed, 22 Mar 2017 17:33:23 +0000 (18:33 +0100)]
ACPI: ioapic: Clear on-stack resource before using it
commit
e3d5092b6756b9e0b08f94bbeafcc7afe19f0996 upstream.
The on-stack resource-window 'win' in setup_res() is not
properly initialized. This causes the pointers in the
embedded 'struct resource' to contain stale addresses.
These pointers (in my case the ->child pointer) later get
propagated to the global iomem_resources list, causing a #GP
exception when the list is traversed in
iomem_map_sanity_check().
Fixes:
c183619b63ec (x86/irq, ACPI: Implement ACPI driver to support IOAPIC hotplug)
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dave Jiang [Fri, 28 Jul 2017 22:10:48 +0000 (15:10 -0700)]
ntb: transport shouldn't disable link due to bogus values in SPADs
commit
f3fd2afed8eee91620d05b69ab94c14793c849d7 upstream.
It seems that under certain scenarios the SPAD can have bogus values caused
by an agent (i.e. BIOS or other software) that is not the kernel driver, and
that causes memory window setup failure. This should not cause the link to
be disabled because if we do that, the driver will never recover again. We
have verified in testing that this issue happens and prevents proper link
recovery.
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Acked-by: Allen Hubbe <Allen.Hubbe@dell.com>
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Fixes:
84f766855f61 ("ntb: stop link work when we do not have memory")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Logan Gunthorpe [Tue, 25 Jul 2017 20:57:42 +0000 (14:57 -0600)]
ntb: ntb_test: ensure the link is up before trying to configure the mws
commit
0eb46345364d7318b11068c46e8a68d5dc10f65e upstream.
After the link tests, there is a race on one side of the test for
the link coming up. It's possible, in some cases, for the test script
to write to the 'peer_trans' files before the link has come up.
To fix this, we simply use the link event file to ensure both sides
see the link as up before continuning.
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Acked-by: Allen Hubbe <Allen.Hubbe@dell.com>
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Fixes:
a9c59ef77458 ("ntb_test: Add a selftest script for the NTB subsystem")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Allen Hubbe [Fri, 9 Jun 2017 22:06:36 +0000 (18:06 -0400)]
ntb: no sleep in ntb_async_tx_submit
commit
88931ec3dc11e7dbceb3b0df455693873b508fbe upstream.
Do not sleep in ntb_async_tx_submit, which could deadlock.
This reverts commit "
8c874cc140d667f84ae4642bb5b5e0d6396d2ca4"
Fixes:
8c874cc140d6 ("NTB: Address out of DMA descriptor issue with NTB")
Reported-by: Jia-Ju Bai <baijiaju1990@163.com>
Signed-off-by: Allen Hubbe <Allen.Hubbe@dell.com>
Acked-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Logan Gunthorpe [Mon, 5 Jun 2017 16:13:24 +0000 (10:13 -0600)]
NTB: ntb_test: fix bug printing ntb_perf results
commit
07b0b22b3e58824f70b9188d085d400069ca3240 upstream.
The code mistakenly prints the local perf results for the remote test
so the script reports identical results for both directions. Fix this
by ensuring we print the remote result.
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Fixes:
a9c59ef77458 ("ntb_test: Add a selftest script for the NTB subsystem")
Acked-by: Allen Hubbe <Allen.Hubbe@dell.com>
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Logan Gunthorpe [Mon, 5 Jun 2017 20:00:53 +0000 (14:00 -0600)]
ntb_transport: fix bug calculating num_qps_mw
commit
8e8496e0e9564b66165f5219a4e8ed20b0d3fc6b upstream.
A divide by zero error occurs if qp_count is less than mw_count because
num_qps_mw is calculated to be zero. The calculation appears to be
incorrect.
The requirement is for num_qps_mw to be set to qp_count / mw_count
with any remainder divided among the earlier mws.
For example, if mw_count is 5 and qp_count is 12 then mws 0 and 1
will have 3 qps per window and mws 2 through 4 will have 2 qps per window.
Thus, when mw_num < qp_count % mw_count, num_qps_mw is 1 higher
than when mw_num >= qp_count.
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Fixes:
e26a5843f7f5 ("NTB: Split ntb_hw_intel and ntb_transport drivers")
Acked-by: Allen Hubbe <Allen.Hubbe@dell.com>
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Logan Gunthorpe [Mon, 5 Jun 2017 20:00:52 +0000 (14:00 -0600)]
ntb_transport: fix qp count bug
commit
cb827ee6ccc3e480f0d9c0e8e53eef55be5b0414 upstream.
In cases where there are more mw's than spads/2-2, the mw count gets
reduced to match the limitation. ntb_transport also tries to ensure that
there are fewer qps than mws but uses the full mw count instead of
the reduced one. When this happens, the math in
'ntb_transport_setup_qp_mw' will get confused and result in a kernel
paging request bug.
This patch fixes the bug by reducing qp_count to the reduced mw count
instead of the full mw count.
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Fixes:
e26a5843f7f5 ("NTB: Split ntb_hw_intel and ntb_transport drivers")
Acked-by: Allen Hubbe <Allen.Hubbe@dell.com>
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linus Torvalds [Sun, 27 Aug 2017 19:12:25 +0000 (12:12 -0700)]
Clarify (and fix) MAX_LFS_FILESIZE macros
commit
0cc3b0ec23ce4c69e1e890ed2b8d2fa932b14aad upstream.
We have a MAX_LFS_FILESIZE macro that is meant to be filled in by
filesystems (and other IO targets) that know they are 64-bit clean and
don't have any 32-bit limits in their IO path.
It turns out that our 32-bit value for that limit was bogus. On 32-bit,
the VM layer is limited by the page cache to only 32-bit index values,
but our logic for that was confusing and actually wrong. We used to
define that value to
(((loff_t)PAGE_SIZE << (BITS_PER_LONG-1))-1)
which is actually odd in several ways: it limits the index to 31 bits,
and then it limits files so that they can't have data in that last byte
of a page that has the highest 31-bit index (ie page index 0x7fffffff).
Neither of those limitations make sense. The index is actually the full
32 bit unsigned value, and we can use that whole full page. So the
maximum size of the file would logically be "PAGE_SIZE << BITS_PER_LONG".
However, we do wan tto avoid the maximum index, because we have code
that iterates over the page indexes, and we don't want that code to
overflow. So the maximum size of a file on a 32-bit host should
actually be one page less than the full 32-bit index.
So the actual limit is ULONG_MAX << PAGE_SHIFT. That means that we will
not actually be using the page of that last index (ULONG_MAX), but we
can grow a file up to that limit.
The wrong value of MAX_LFS_FILESIZE actually caused problems for Doug
Nazar, who was still using a 32-bit host, but with a 9.7TB 2 x RAID5
volume. It turns out that our old MAX_LFS_FILESIZE was 8TiB (well, one
byte less), but the actual true VM limit is one page less than 16TiB.
This was invisible until commit
c2a9737f45e2 ("vfs,mm: fix a dead loop
in truncate_inode_pages_range()"), which started applying that
MAX_LFS_FILESIZE limit to block devices too.
NOTE! On 64-bit, the page index isn't a limiter at all, and the limit is
actually just the offset type itself (loff_t), which is signed. But for
clarity, on 64-bit, just use the maximum signed value, and don't make
people have to count the number of 'f' characters in the hex constant.
So just use LLONG_MAX for the 64-bit case. That was what the value had
been before too, just written out as a hex constant.
Fixes:
c2a9737f45e2 ("vfs,mm: fix a dead loop in truncate_inode_pages_range()")
Reported-and-tested-by: Doug Nazar <nazard@nazar.ca>
Cc: Andreas Dilger <adilger@dilger.ca>
Cc: Mark Fasheh <mfasheh@versity.com>
Cc: Joel Becker <jlbec@evilplan.org>
Cc: Dave Kleikamp <shaggy@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Charles Milette [Fri, 18 Aug 2017 20:30:34 +0000 (16:30 -0400)]
staging: rtl8188eu: add RNX-N150NUB support
commit
f299aec6ebd747298e35934cff7709c6b119ca52 upstream.
Add support for USB Device Rosewill RNX-N150NUB.
VendorID: 0x0bda, ProductID: 0xffef
Signed-off-by: Charles Milette <charles.milette@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Srinivas Pandruvada [Sat, 12 Aug 2017 16:09:21 +0000 (09:09 -0700)]
iio: hid-sensor-trigger: Fix the race with user space powering up sensors
commit
f1664eaacec31035450132c46ed2915fd2b2049a upstream.
It has been reported for a while that with iio-sensor-proxy service the
rotation only works after one suspend/resume cycle. This required a wait
in the systemd unit file to avoid race. I found a Yoga 900 where I could
reproduce this.
The problem scenerio is:
- During sensor driver init, enable run time PM and also set a
auto-suspend for 3 seconds.
This result in one runtime resume. But there is a check to avoid
a powerup in this sequence, but rpm is active
- User space iio-sensor-proxy tries to power up the sensor. Since rpm is
active it will simply return. But sensors were not actually
powered up in the prior sequence, so actaully the sensors will not work
- After 3 seconds the auto suspend kicks
If we add a wait in systemd service file to fire iio-sensor-proxy after
3 seconds, then now everything will work as the runtime resume will
actually powerup the sensor as this is a user request.
To avoid this:
- Remove the check to match user requested state, this will cause a
brief powerup, but if the iio-sensor-proxy starts immediately it will
still work as the sensors are ON.
- Also move the autosuspend delay to place when user requested turn off
of sensors, like after user finished raw read or buffer disable
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Tested-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dragos Bogdan [Thu, 3 Aug 2017 22:37:27 +0000 (01:37 +0300)]
iio: imu: adis16480: Fix acceleration scale factor for adis16480
commit
fdd0d32eb95f135041236a6885d9006315aa9a1d upstream.
According to the datasheet, the range of the acceleration is [-10 g, + 10 g],
so the scale factor should be 10 instead of 5.
Signed-off-by: Dragos Bogdan <dragos.bogdan@analog.com>
Acked-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>
Martijn Coenen [Fri, 28 Jul 2017 11:56:08 +0000 (13:56 +0200)]
ANDROID: binder: fix proc->tsk check.
commit
b2a6d1b999a4c13e5997bb864694e77172d45250 upstream.
Commit
c4ea41ba195d ("binder: use group leader instead of open thread")'
was incomplete and didn't update a check in binder_mmap(), causing all
mmap() calls into the binder driver to fail.
Signed-off-by: Martijn Coenen <maco@android.com>
Tested-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Riley Andrews [Thu, 29 Jun 2017 19:01:37 +0000 (12:01 -0700)]
binder: Use wake up hint for synchronous transactions.
commit
00b40d613352c623aaae88a44e5ded7c912909d7 upstream.
Use wake_up_interruptible_sync() to hint to the scheduler binder
transactions are synchronous wakeups. Disable preemption while waking
to avoid ping-ponging on the binder lock.
Signed-off-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Omprakash Dhyade <odhyade@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Todd Kjos [Thu, 29 Jun 2017 19:01:36 +0000 (12:01 -0700)]
binder: use group leader instead of open thread
commit
c4ea41ba195d01c9af66fb28711a16cc97caa9c5 upstream.
The binder allocator assumes that the thread that
called binder_open will never die for the lifetime of
that proc. That thread is normally the group_leader,
however it may not be. Use the group_leader instead
of current.
Signed-off-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Todd Kjos [Wed, 5 Jul 2017 20:46:01 +0000 (13:46 -0700)]
Revert "android: binder: Sanity check at binder ioctl"
commit
a2b18708ee14baec4ef9c0fba96070bba14d0081 upstream.
This reverts commit
a906d6931f3ccaf7de805643190765ddd7378e27.
The patch introduced a race in the binder driver. An attempt to fix the
race was submitted in "[PATCH v2] android: binder: fix dangling pointer
comparison", however the conclusion in the discussion for that patch
was that the original patch should be reverted.
The reversion is being done as part of the fine-grained locking
patchset since the patch would need to be refactored when
proc->vmm_vm_mm is removed from struct binder_proc and added
in the binder allocator.
Signed-off-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jeffy Chen [Tue, 27 Jun 2017 09:34:42 +0000 (17:34 +0800)]
Bluetooth: bnep: fix possible might sleep error in bnep_session
commit
25717382c1dd0ddced2059053e3ca5088665f7a5 upstream.
It looks like bnep_session has same pattern as the issue reported in
old rfcomm:
while (1) {
set_current_state(TASK_INTERRUPTIBLE);
if (condition)
break;
// may call might_sleep here
schedule();
}
__set_current_state(TASK_RUNNING);
Which fixed at:
dfb2fae Bluetooth: Fix nested sleeps
So let's fix it at the same way, also follow the suggestion of:
https://lwn.net/Articles/628628/
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: AL Yu-Chen Cho <acho@suse.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jeffy Chen [Tue, 27 Jun 2017 09:34:43 +0000 (17:34 +0800)]
Bluetooth: cmtp: fix possible might sleep error in cmtp_session
commit
f06d977309d09253c744e54e75c5295ecc52b7b4 upstream.
It looks like cmtp_session has same pattern as the issue reported in
old rfcomm:
while (1) {
set_current_state(TASK_INTERRUPTIBLE);
if (condition)
break;
// may call might_sleep here
schedule();
}
__set_current_state(TASK_RUNNING);
Which fixed at:
dfb2fae Bluetooth: Fix nested sleeps
So let's fix it at the same way, also follow the suggestion of:
https://lwn.net/Articles/628628/
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: AL Yu-Chen Cho <acho@suse.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jeffy Chen [Tue, 27 Jun 2017 09:34:44 +0000 (17:34 +0800)]
Bluetooth: hidp: fix possible might sleep error in hidp_session_thread
commit
5da8e47d849d3d37b14129f038782a095b9ad049 upstream.
It looks like hidp_session_thread has same pattern as the issue reported in
old rfcomm:
while (1) {
set_current_state(TASK_INTERRUPTIBLE);
if (condition)
break;
// may call might_sleep here
schedule();
}
__set_current_state(TASK_RUNNING);
Which fixed at:
dfb2fae Bluetooth: Fix nested sleeps
So let's fix it at the same way, also follow the suggestion of:
https://lwn.net/Articles/628628/
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Tested-by: AL Yu-Chen Cho <acho@suse.com>
Tested-by: Rohit Vaswani <rvaswani@nvidia.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florian Westphal [Fri, 7 Jul 2017 11:07:17 +0000 (13:07 +0200)]
netfilter: nat: fix src map lookup
commit
97772bcd56efa21d9d8976db6f205574ea602f51 upstream.
When doing initial conversion to rhashtable I replaced the bucket
walk with a single rhashtable_lookup_fast().
When moving to rhlist I failed to properly walk the list of identical
tuples, but that is what is needed for this to work correctly.
The table contains the original tuples, so the reply tuples are all
distinct.
We currently decide that mapping is (not) in range only based on the
first entry, but in case its not we need to try the reply tuple of the
next entry until we either find an in-range mapping or we checked
all the entries.
This bug makes nat core attempt collision resolution while it might be
able to use the mapping as-is.
Fixes:
870190a9ec90 ("netfilter: nat: convert nat bysrc hash to rhashtable")
Reported-by: Jaco Kroon <jaco@uls.co.za>
Tested-by: Jaco Kroon <jaco@uls.co.za>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Zhang Bo [Tue, 13 Jun 2017 02:39:20 +0000 (10:39 +0800)]
Revert "leds: handle suspend/resume in heartbeat trigger"
commit
436c4c45b5b9562b59cedbb51b7343ab4a6dd8cc upstream.
This reverts commit
5ab92a7cb82c66bf30685583a38a18538e3807db.
System cannot enter suspend mode because of heartbeat led trigger.
In autosleep_wq, try_to_suspend function will try to enter suspend
mode in specific period. it will get wakeup_count then call pm_notifier
chain callback function and freeze processes.
Heartbeat_pm_notifier is called and it call led_trigger_unregister to
change the trigger of led device to none. It will send uevent message
and the wakeup source count changed. As wakeup_count changed, suspend
will abort.
Fixes:
5ab92a7cb82c ("leds: handle suspend/resume in heartbeat trigger")
Signed-off-by: Zhang Bo <bo.zhang@nxp.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vadim Lomovtsev [Mon, 21 Aug 2017 11:23:07 +0000 (07:23 -0400)]
net: sunrpc: svcsock: fix NULL-pointer exception
commit
eebe53e87f97975ee58a21693e44797608bf679c upstream.
While running nfs/connectathon tests kernel NULL-pointer exception
has been observed due to races in svcsock.c.
Race is appear when kernel accepts connection by kernel_accept
(which creates new socket) and start queuing ingress packets
to new socket. This happens in ksoftirq context which could run
concurrently on a different core while new socket setup is not done yet.
The fix is to re-order socket user data init sequence and add
write/read barrier calls to be sure that we got proper values
for callback pointers before actually calling them.
Test results: nfs/connectathon reports '0' failed tests for about 200+ iterations.
Crash log:
---<-snip->---
[ 6708.638984] Unable to handle kernel NULL pointer dereference at virtual address
00000000
[ 6708.647093] pgd =
ffff0000094e0000
[ 6708.650497] [
00000000] *pgd=
0000010ffff90003, *pud=
0000010ffff90003, *pmd=
0000010ffff80003, *pte=
0000000000000000
[ 6708.660761] Internal error: Oops:
86000005 [#1] SMP
[ 6708.665630] Modules linked in: nfsv3 nfnetlink_queue nfnetlink_log nfnetlink rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache overlay xt_CONNSECMARK xt_SECMARK xt_conntrack iptable_security ip_tables ah4 xfrm4_mode_transport sctp tun binfmt_misc ext4 jbd2 mbcache loop tcp_diag udp_diag inet_diag rpcrdma ib_isert iscsi_target_mod ib_iser rdma_cm iw_cm libiscsi scsi_transport_iscsi ib_srpt target_core_mod ib_srp scsi_transport_srp ib_ipoib ib_ucm ib_uverbs ib_umad ib_cm ib_core nls_koi8_u nls_cp932 ts_kmp nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack vfat fat ghash_ce sha2_ce sha1_ce cavium_rng_vf i2c_thunderx sg thunderx_edac i2c_smbus edac_core cavium_rng nfsd auth_rpcgss nfs_acl lockd grace sunrpc xfs libcrc32c nicvf nicpf ast i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops
[ 6708.736446] ttm drm i2c_core thunder_bgx thunder_xcv mdio_thunder mdio_cavium dm_mirror dm_region_hash dm_log dm_mod [last unloaded: stap_3c300909c5b3f46dcacd49aab3334af_87021]
[ 6708.752275] CPU: 84 PID: 0 Comm: swapper/84 Tainted: G W OE 4.11.0-4.el7.aarch64 #1
[ 6708.760787] Hardware name: www.cavium.com CRB-2S/CRB-2S, BIOS 0.3 Mar 13 2017
[ 6708.767910] task:
ffff810006842e80 task.stack:
ffff81000689c000
[ 6708.773822] PC is at 0x0
[ 6708.776739] LR is at svc_data_ready+0x38/0x88 [sunrpc]
[ 6708.781866] pc : [<
0000000000000000>] lr : [<
ffff0000029d7378>] pstate:
60000145
[ 6708.789248] sp :
ffff810ffbad3900
[ 6708.792551] x29:
ffff810ffbad3900 x28:
ffff000008c73d58
[ 6708.797853] x27:
0000000000000000 x26:
ffff81000bbe1e00
[ 6708.803156] x25:
0000000000000020 x24:
ffff800f7410bf28
[ 6708.808458] x23:
ffff000008c63000 x22:
ffff000008c63000
[ 6708.813760] x21:
ffff800f7410bf28 x20:
ffff81000bbe1e00
[ 6708.819063] x19:
ffff810012412400 x18:
00000000d82a9df2
[ 6708.824365] x17:
0000000000000000 x16:
0000000000000000
[ 6708.829667] x15:
0000000000000000 x14:
0000000000000001
[ 6708.834969] x13:
0000000000000000 x12:
722e736f622e676e
[ 6708.840271] x11:
00000000f814dd99 x10:
0000000000000000
[ 6708.845573] x9 :
7374687225000000 x8 :
0000000000000000
[ 6708.850875] x7 :
0000000000000000 x6 :
0000000000000000
[ 6708.856177] x5 :
0000000000000028 x4 :
0000000000000000
[ 6708.861479] x3 :
0000000000000000 x2 :
00000000e5000000
[ 6708.866781] x1 :
0000000000000000 x0 :
ffff81000bbe1e00
[ 6708.872084]
[ 6708.873565] Process swapper/84 (pid: 0, stack limit = 0xffff81000689c000)
[ 6708.880341] Stack: (0xffff810ffbad3900 to 0xffff8100068a0000)
[ 6708.886075] Call trace:
[ 6708.888513] Exception stack(0xffff810ffbad3710 to 0xffff810ffbad3840)
[ 6708.894942] 3700:
ffff810012412400 0001000000000000
[ 6708.902759] 3720:
ffff810ffbad3900 0000000000000000 0000000060000145 ffff800f79300000
[ 6708.910577] 3740:
ffff000009274d00 00000000000003ea 0000000000000015 ffff000008c63000
[ 6708.918395] 3760:
ffff810ffbad3830 ffff800f79300000 000000000000004d 0000000000000000
[ 6708.926212] 3780:
ffff810ffbad3890 ffff0000080f88dc ffff800f79300000 000000000000004d
[ 6708.934030] 37a0:
ffff800f7930093c ffff000008c63000 0000000000000000 0000000000000140
[ 6708.941848] 37c0:
ffff000008c2c000 0000000000040b00 ffff81000bbe1e00 0000000000000000
[ 6708.949665] 37e0:
00000000e5000000 0000000000000000 0000000000000000 0000000000000028
[ 6708.957483] 3800:
0000000000000000 0000000000000000 0000000000000000 7374687225000000
[ 6708.965300] 3820:
0000000000000000 00000000f814dd99 722e736f622e676e 0000000000000000
[ 6708.973117] [< (null)>] (null)
[ 6708.977824] [<
ffff0000086f9fa4>] tcp_data_queue+0x754/0xc5c
[ 6708.983386] [<
ffff0000086fa64c>] tcp_rcv_established+0x1a0/0x67c
[ 6708.989384] [<
ffff000008704120>] tcp_v4_do_rcv+0x15c/0x22c
[ 6708.994858] [<
ffff000008707418>] tcp_v4_rcv+0xaf0/0xb58
[ 6709.000077] [<
ffff0000086df784>] ip_local_deliver_finish+0x10c/0x254
[ 6709.006419] [<
ffff0000086dfea4>] ip_local_deliver+0xf0/0xfc
[ 6709.011980] [<
ffff0000086dfad4>] ip_rcv_finish+0x208/0x3a4
[ 6709.017454] [<
ffff0000086e018c>] ip_rcv+0x2dc/0x3c8
[ 6709.022328] [<
ffff000008692fc8>] __netif_receive_skb_core+0x2f8/0xa0c
[ 6709.028758] [<
ffff000008696068>] __netif_receive_skb+0x38/0x84
[ 6709.034580] [<
ffff00000869611c>] netif_receive_skb_internal+0x68/0xdc
[ 6709.041010] [<
ffff000008696bc0>] napi_gro_receive+0xcc/0x1a8
[ 6709.046690] [<
ffff0000014b0fc4>] nicvf_cq_intr_handler+0x59c/0x730 [nicvf]
[ 6709.053559] [<
ffff0000014b1380>] nicvf_poll+0x38/0xb8 [nicvf]
[ 6709.059295] [<
ffff000008697a6c>] net_rx_action+0x2f8/0x464
[ 6709.064771] [<
ffff000008081824>] __do_softirq+0x11c/0x308
[ 6709.070164] [<
ffff0000080d14e4>] irq_exit+0x12c/0x174
[ 6709.075206] [<
ffff00000813101c>] __handle_domain_irq+0x78/0xc4
[ 6709.081027] [<
ffff000008081608>] gic_handle_irq+0x94/0x190
[ 6709.086501] Exception stack(0xffff81000689fdf0 to 0xffff81000689ff20)
[ 6709.092929] fde0:
0000810ff2ec0000 ffff000008c10000
[ 6709.100747] fe00:
ffff000008c70ef4 0000000000000001 0000000000000000 ffff810ffbad9b18
[ 6709.108565] fe20:
ffff810ffbad9c70 ffff8100169d3800 ffff810006843ab0 ffff81000689fe80
[ 6709.116382] fe40:
0000000000000bd0 0000ffffdf979cd0 183f5913da192500 0000ffff8a254ce4
[ 6709.124200] fe60:
0000ffff8a254b78 0000aaab10339808 0000000000000000 0000ffff8a0c2a50
[ 6709.132018] fe80:
0000ffffdf979b10 ffff000008d6d450 ffff000008c10000 ffff000008d6d000
[ 6709.139836] fea0:
0000000000000054 ffff000008cd3dbc 0000000000000000 0000000000000000
[ 6709.147653] fec0:
0000000000000000 0000000000000000 0000000000000000 ffff81000689ff20
[ 6709.155471] fee0:
ffff000008085240 ffff81000689ff20 ffff000008085244 0000000060000145
[ 6709.163289] ff00:
ffff81000689ff10 ffff00000813f1e4 ffffffffffffffff ffff00000813f238
[ 6709.171107] [<
ffff000008082eb4>] el1_irq+0xb4/0x140
[ 6709.175976] [<
ffff000008085244>] arch_cpu_idle+0x44/0x11c
[ 6709.181368] [<
ffff0000087bf3b8>] default_idle_call+0x20/0x30
[ 6709.187020] [<
ffff000008116d50>] do_idle+0x158/0x1e4
[ 6709.191973] [<
ffff000008116ff4>] cpu_startup_entry+0x2c/0x30
[ 6709.197624] [<
ffff00000808e7cc>] secondary_start_kernel+0x13c/0x160
[ 6709.203878] [<
0000000001bc71c4>] 0x1bc71c4
[ 6709.207967] Code: bad PC value
[ 6709.211061] SMP: stopping secondary CPUs
[ 6709.218830] Starting crashdump kernel...
[ 6709.222749] Bye!
---<-snip>---
Signed-off-by: Vadim Lomovtsev <vlomovts@redhat.com>
Reviewed-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Biggers [Thu, 24 Aug 2017 17:50:29 +0000 (10:50 -0700)]
x86/mm: Fix use-after-free of ldt_struct
commit
ccd5b3235180eef3cfec337df1c8554ab151b5cc upstream.
The following commit:
39a0526fb3f7 ("x86/mm: Factor out LDT init from context init")
renamed init_new_context() to init_new_context_ldt() and added a new
init_new_context() which calls init_new_context_ldt(). However, the
error code of init_new_context_ldt() was ignored. Consequently, if a
memory allocation in alloc_ldt_struct() failed during a fork(), the
->context.ldt of the new task remained the same as that of the old task
(due to the memcpy() in dup_mm()). ldt_struct's are not intended to be
shared, so a use-after-free occurred after one task exited.
Fix the bug by making init_new_context() pass through the error code of
init_new_context_ldt().
This bug was found by syzkaller, which encountered the following splat:
BUG: KASAN: use-after-free in free_ldt_struct.part.2+0x10a/0x150 arch/x86/kernel/ldt.c:116
Read of size 4 at addr
ffff88006d2cb7c8 by task kworker/u9:0/3710
CPU: 1 PID: 3710 Comm: kworker/u9:0 Not tainted 4.13.0-rc4-next-
20170811 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:16 [inline]
dump_stack+0x194/0x257 lib/dump_stack.c:52
print_address_description+0x73/0x250 mm/kasan/report.c:252
kasan_report_error mm/kasan/report.c:351 [inline]
kasan_report+0x24e/0x340 mm/kasan/report.c:409
__asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:429
free_ldt_struct.part.2+0x10a/0x150 arch/x86/kernel/ldt.c:116
free_ldt_struct arch/x86/kernel/ldt.c:173 [inline]
destroy_context_ldt+0x60/0x80 arch/x86/kernel/ldt.c:171
destroy_context arch/x86/include/asm/mmu_context.h:157 [inline]
__mmdrop+0xe9/0x530 kernel/fork.c:889
mmdrop include/linux/sched/mm.h:42 [inline]
exec_mmap fs/exec.c:1061 [inline]
flush_old_exec+0x173c/0x1ff0 fs/exec.c:1291
load_elf_binary+0x81f/0x4ba0 fs/binfmt_elf.c:855
search_binary_handler+0x142/0x6b0 fs/exec.c:1652
exec_binprm fs/exec.c:1694 [inline]
do_execveat_common.isra.33+0x1746/0x22e0 fs/exec.c:1816
do_execve+0x31/0x40 fs/exec.c:1860
call_usermodehelper_exec_async+0x457/0x8f0 kernel/umh.c:100
ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
Allocated by task 3700:
save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
save_stack+0x43/0xd0 mm/kasan/kasan.c:447
set_track mm/kasan/kasan.c:459 [inline]
kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
kmem_cache_alloc_trace+0x136/0x750 mm/slab.c:3627
kmalloc include/linux/slab.h:493 [inline]
alloc_ldt_struct+0x52/0x140 arch/x86/kernel/ldt.c:67
write_ldt+0x7b7/0xab0 arch/x86/kernel/ldt.c:277
sys_modify_ldt+0x1ef/0x240 arch/x86/kernel/ldt.c:307
entry_SYSCALL_64_fastpath+0x1f/0xbe
Freed by task 3700:
save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
save_stack+0x43/0xd0 mm/kasan/kasan.c:447
set_track mm/kasan/kasan.c:459 [inline]
kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
__cache_free mm/slab.c:3503 [inline]
kfree+0xca/0x250 mm/slab.c:3820
free_ldt_struct.part.2+0xdd/0x150 arch/x86/kernel/ldt.c:121
free_ldt_struct arch/x86/kernel/ldt.c:173 [inline]
destroy_context_ldt+0x60/0x80 arch/x86/kernel/ldt.c:171
destroy_context arch/x86/include/asm/mmu_context.h:157 [inline]
__mmdrop+0xe9/0x530 kernel/fork.c:889
mmdrop include/linux/sched/mm.h:42 [inline]
__mmput kernel/fork.c:916 [inline]
mmput+0x541/0x6e0 kernel/fork.c:927
copy_process.part.36+0x22e1/0x4af0 kernel/fork.c:1931
copy_process kernel/fork.c:1546 [inline]
_do_fork+0x1ef/0xfb0 kernel/fork.c:2025
SYSC_clone kernel/fork.c:2135 [inline]
SyS_clone+0x37/0x50 kernel/fork.c:2129
do_syscall_64+0x26c/0x8c0 arch/x86/entry/common.c:287
return_from_SYSCALL_64+0x0/0x7a
Here is a C reproducer:
#include <asm/ldt.h>
#include <pthread.h>
#include <signal.h>
#include <stdlib.h>
#include <sys/syscall.h>
#include <sys/wait.h>
#include <unistd.h>
static void *fork_thread(void *_arg)
{
fork();
}
int main(void)
{
struct user_desc desc = { .entry_number = 8191 };
syscall(__NR_modify_ldt, 1, &desc, sizeof(desc));
for (;;) {
if (fork() == 0) {
pthread_t t;
srand(getpid());
pthread_create(&t, NULL, fork_thread, NULL);
usleep(rand() % 10000);
syscall(__NR_exit_group, 0);
}
wait(NULL);
}
}
Note: the reproducer takes advantage of the fact that alloc_ldt_struct()
may use vmalloc() to allocate a large ->entries array, and after
commit:
5d17a73a2ebe ("vmalloc: back off when the current task is killed")
it is possible for userspace to fail a task's vmalloc() by
sending a fatal signal, e.g. via exit_group(). It would be more
difficult to reproduce this bug on kernels without that commit.
This bug only affected kernels with CONFIG_MODIFY_LDT_SYSCALL=y.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-mm@kvack.org
Fixes:
39a0526fb3f7 ("x86/mm: Factor out LDT init from context init")
Link: http://lkml.kernel.org/r/20170824175029.76040-1-ebiggers3@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicholas Piggin [Tue, 22 Aug 2017 08:43:48 +0000 (18:43 +1000)]
timers: Fix excessive granularity of new timers after a nohz idle
commit
2fe59f507a65dbd734b990a11ebc7488f6f87a24 upstream.
When a timer base is idle, it is forwarded when a new timer is added
to ensure that granularity does not become excessive. When not idle,
the timer tick is expected to increment the base.
However there are several problems:
- If an existing timer is modified, the base is forwarded only after
the index is calculated.
- The base is not forwarded by add_timer_on.
- There is a window after a timer is restarted from a nohz idle, after
it is marked not-idle and before the timer tick on this CPU, where a
timer may be added but the ancient base does not get forwarded.
These result in excessive granularity (a 1 jiffy timeout can blow out
to 100s of jiffies), which cause the rcu lockup detector to trigger,
among other things.
Fix this by keeping track of whether the timer base has been idle
since it was last run or forwarded, and if so then forward it before
adding a new timer.
There is still a case where mod_timer optimises the case of a pending
timer mod with the same expiry time, where the timer can see excessive
granularity relative to the new, shorter interval. A comment is added,
but it's not changed because it is an important fastpath for
networking.
This has been tested and found to fix the RCU softlockup messages.
Testing was also done with tracing to measure requested versus
achieved wakeup latencies for all non-deferrable timers in an idle
system (with no lockup watchdogs running). Wakeup latency relative to
absolute latency is calculated (note this suffers from round-up skew
at low absolute times) and analysed:
max avg std
upstream 506.0 1.20 4.68
patched 2.0 1.08 0.15
The bug was noticed due to the lockup detector Kconfig changes
dropping it out of people's .configs and resulting in larger base
clk skew When the lockup detectors are enabled, no CPU can go idle for
longer than 4 seconds, which limits the granularity errors.
Sub-optimal timer behaviour is observable on a smaller scale in that
case:
max avg std
upstream 9.0 1.05 0.19
patched 2.0 1.04 0.11
Fixes: Fixes:
a683f390b93f ("timers: Forward the wheel clock whenever possible")
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Tested-by: David Miller <davem@davemloft.net>
Cc: dzickus@redhat.com
Cc: sfr@canb.auug.org.au
Cc: mpe@ellerman.id.au
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: linuxarm@huawei.com
Cc: abdhalee@linux.vnet.ibm.com
Cc: John Stultz <john.stultz@linaro.org>
Cc: akpm@linux-foundation.org
Cc: paulmck@linux.vnet.ibm.com
Cc: torvalds@linux-foundation.org
Link: http://lkml.kernel.org/r/20170822084348.21436-1-npiggin@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Gleixner [Tue, 31 Jan 2017 22:58:38 +0000 (23:58 +0100)]
perf/x86/intel/rapl: Make package handling more robust
commit
dd86e373e09fb16b83e8adf5c48c421a4ca76468 upstream.
The package management code in RAPL relies on package mapping being
available before a CPU is started. This changed with:
9d85eb9119f4 ("x86/smpboot: Make logical package management more robust")
because the ACPI/BIOS information turned out to be unreliable, but that
left RAPL in broken state. This was not noticed because on a regular boot
all CPUs are online before RAPL is initialized.
A possible fix would be to reintroduce the mess which allocates a package
data structure in CPU prepare and when it turns out to already exist in
starting throw it away later in the CPU online callback. But that's a
horrible hack and not required at all because RAPL becomes functional for
perf only in the CPU online callback. That's correct because user space is
not yet informed about the CPU being onlined, so nothing caan rely on RAPL
being available on that particular CPU.
Move the allocation to the CPU online callback and simplify the hotplug
handling. At this point the package mapping is established and correct.
This also adds a missing check for available package data in the
event_init() function.
Reported-by: Yasuaki Ishimatsu <yasu.isimatu@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sebastian Siewior <bigeasy@linutronix.de>
Cc: Stephane Eranian <eranian@google.com>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Fixes:
9d85eb9119f4 ("x86/smpboot: Make logical package management more robust")
Link: http://lkml.kernel.org/r/20170131230141.212593966@linutronix.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
[ jwang: backport to 4.9 fix Null pointer deref during hotplug cpu.]
Signed-off-by: Jack Wang <jinpu.wang@profitbricks.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Masami Hiramatsu [Wed, 4 Jan 2017 03:29:05 +0000 (12:29 +0900)]
perf probe: Fix --funcs to show correct symbols for offline module
commit
eebc509b20881b92d62e317b2c073e57c5f200f0 upstream.
Fix --funcs (-F) option to show correct symbols for offline module.
Since previous perf-probe uses machine__findnew_module_map() for offline
module, even if user passes a module file (with full path) which is for
other architecture, perf-probe always tries to load symbol map for
current kernel module.
This fix uses dso__new_map() to load the map from given binary as same
as a map for user applications.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/148350053478.19001.15435255244512631545.stgit@devbox
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Krister Johansen <kjlx@templeofstupid.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mark Rutland [Thu, 22 Jun 2017 14:41:38 +0000 (15:41 +0100)]
perf/core: Fix group {cpu,task} validation
commit
64aee2a965cf2954a038b5522f11d2cd2f0f8f3e upstream.
Regardless of which events form a group, it does not make sense for the
events to target different tasks and/or CPUs, as this leaves the group
inconsistent and impossible to schedule. The core perf code assumes that
these are consistent across (successfully intialised) groups.
Core perf code only verifies this when moving SW events into a HW
context. Thus, we can violate this requirement for pure SW groups and
pure HW groups, unless the relevant PMU driver happens to perform this
verification itself. These mismatched groups subsequently wreak havoc
elsewhere.
For example, we handle watchpoints as SW events, and reserve watchpoint
HW on a per-CPU basis at pmu::event_init() time to ensure that any event
that is initialised is guaranteed to have a slot at pmu::add() time.
However, the core code only checks the group leader's cpu filter (via
event_filter_match()), and can thus install follower events onto CPUs
violating thier (mismatched) CPU filters, potentially installing them
into a CPU without sufficient reserved slots.
This can be triggered with the below test case, resulting in warnings
from arch backends.
#define _GNU_SOURCE
#include <linux/hw_breakpoint.h>
#include <linux/perf_event.h>
#include <sched.h>
#include <stdio.h>
#include <sys/prctl.h>
#include <sys/syscall.h>
#include <unistd.h>
static int perf_event_open(struct perf_event_attr *attr, pid_t pid, int cpu,
int group_fd, unsigned long flags)
{
return syscall(__NR_perf_event_open, attr, pid, cpu, group_fd, flags);
}
char watched_char;
struct perf_event_attr wp_attr = {
.type = PERF_TYPE_BREAKPOINT,
.bp_type = HW_BREAKPOINT_RW,
.bp_addr = (unsigned long)&watched_char,
.bp_len = 1,
.size = sizeof(wp_attr),
};
int main(int argc, char *argv[])
{
int leader, ret;
cpu_set_t cpus;
/*
* Force use of CPU0 to ensure our CPU0-bound events get scheduled.
*/
CPU_ZERO(&cpus);
CPU_SET(0, &cpus);
ret = sched_setaffinity(0, sizeof(cpus), &cpus);
if (ret) {
printf("Unable to set cpu affinity\n");
return 1;
}
/* open leader event, bound to this task, CPU0 only */
leader = perf_event_open(&wp_attr, 0, 0, -1, 0);
if (leader < 0) {
printf("Couldn't open leader: %d\n", leader);
return 1;
}
/*
* Open a follower event that is bound to the same task, but a
* different CPU. This means that the group should never be possible to
* schedule.
*/
ret = perf_event_open(&wp_attr, 0, 1, leader, 0);
if (ret < 0) {
printf("Couldn't open mismatched follower: %d\n", ret);
return 1;
} else {
printf("Opened leader/follower with mismastched CPUs\n");
}
/*
* Open as many independent events as we can, all bound to the same
* task, CPU0 only.
*/
do {
ret = perf_event_open(&wp_attr, 0, 0, -1, 0);
} while (ret >= 0);
/*
* Force enable/disble all events to trigger the erronoeous
* installation of the follower event.
*/
printf("Opened all events. Toggling..\n");
for (;;) {
prctl(PR_TASK_PERF_EVENTS_DISABLE, 0, 0, 0, 0);
prctl(PR_TASK_PERF_EVENTS_ENABLE, 0, 0, 0, 0);
}
return 0;
}
Fix this by validating this requirement regardless of whether we're
moving events.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Zhou Chengming <zhouchengming1@huawei.com>
Link: http://lkml.kernel.org/r/1498142498-15758-1-git-send-email-mark.rutland@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Steven Rostedt (VMware) [Thu, 17 Aug 2017 20:37:25 +0000 (16:37 -0400)]
ftrace: Check for null ret_stack on profile function graph entry function
commit
a8f0f9e49956a74718874b800251455680085600 upstream.
There's a small race when function graph shutsdown and the calling of the
registered function graph entry callback. The callback must not reference
the task's ret_stack without first checking that it is not NULL. Note, when
a ret_stack is allocated for a task, it stays allocated until the task exits.
The problem here, is that function_graph is shutdown, and a new task was
created, which doesn't have its ret_stack allocated. But since some of the
functions are still being traced, the callbacks can still be called.
The normal function_graph code handles this, but starting with commit
8861dd303c ("ftrace: Access ret_stack->subtime only in the function
profiler") the profiler code references the ret_stack on function entry, but
doesn't check if it is NULL first.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=196611
Fixes:
8861dd303c ("ftrace: Access ret_stack->subtime only in the function profiler")
Reported-by: lilydjwg@gmail.com
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chuck Lever [Fri, 18 Aug 2017 15:12:19 +0000 (11:12 -0400)]
nfsd: Limit end of page list when decoding NFSv4 WRITE
commit
fc788f64f1f3eb31e87d4f53bcf1ab76590d5838 upstream.
When processing an NFSv4 WRITE operation, argp->end should never
point past the end of the data in the final page of the page list.
Otherwise, nfsd4_decode_compound can walk into uninitialized memory.
More critical, nfsd4_decode_write is failing to increment argp->pagelen
when it increments argp->pagelist. This can cause later xdr decoders
to assume more data is available than really is, which can cause server
crashes on malformed requests.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ronnie Sahlberg [Wed, 23 Aug 2017 04:48:14 +0000 (14:48 +1000)]
cifs: return ENAMETOOLONG for overlong names in cifs_open()/cifs_lookup()
commit
d3edede29f74d335f81d95a4588f5f136a9f7dcf upstream.
Add checking for the path component length and verify it is <= the maximum
that the server advertizes via FileFsAttributeInformation.
With this patch cifs.ko will now return ENAMETOOLONG instead of ENOENT
when users to access an overlong path.
To test this, try to cd into a (non-existing) directory on a CIFS share
that has a too long name:
cd /mnt/
aaaaaaaaaaaaaaa...
and it now should show a good error message from the shell:
bash: cd: /mnt/
aaaaaaaaaaaaaaaa...aaaaaa: File name too long
rh bz
1153996
Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com>
Signed-off-by: Steve French <smfrench@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sachin Prabhu [Thu, 3 Aug 2017 07:39:03 +0000 (13:09 +0530)]
cifs: Fix df output for users with quota limits
commit
42bec214d8bd432be6d32a1acb0a9079ecd4d142 upstream.
The df for a SMB2 share triggers a GetInfo call for
FS_FULL_SIZE_INFORMATION. The values returned are used to populate
struct statfs.
The problem is that none of the information returned by the call
contains the total blocks available on the filesystem. Instead we use
the blocks available to the user ie. quota limitation when filling out
statfs.f_blocks. The information returned does contain Actual free units
on the filesystem and is used to populate statfs.f_bfree. For users with
quota enabled, it can lead to situations where the total free space
reported is more than the total blocks on the system ending up with df
reports like the following
# df -h /mnt/a
Filesystem Size Used Avail Use% Mounted on
//192.168.22.10/a 2.5G -2.3G 2.5G - /mnt/a
To fix this problem, we instead populate both statfs.f_bfree with the
same value as statfs.f_bavail ie. CallerAvailableAllocationUnits. This
is similar to what is done already in the code for cifs and df now
reports the quota information for the user used to mount the share.
# df --si /mnt/a
Filesystem Size Used Avail Use% Mounted on
//192.168.22.10/a 2.7G 101M 2.6G 4% /mnt/a
Signed-off-by: Sachin Prabhu <sprabhu@redhat.com>
Signed-off-by: Pierguido Lambri <plambri@redhat.com>
Signed-off-by: Steve French <smfrench@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>