James Hogan [Wed, 31 May 2017 15:19:47 +0000 (16:19 +0100)]
MIPS: Fix mips_atomic_set() retry condition
commit
2ec420b26f7b6ff332393f0bb5a7d245f7ad87f0 upstream.
The inline asm retry check in the MIPS_ATOMIC_SET operation of the
sysmips system call has been backwards since commit
f1e39a4a616c ("MIPS:
Rewrite sysmips(MIPS_ATOMIC_SET, ...) in C with inline assembler")
merged in v2.6.32, resulting in the non R10000_LLSC_WAR case retrying
until the operation was inatomic, before returning the new value that
was probably just written multiple times instead of the old value.
Invert the branch condition to fix that particular issue.
Fixes: f1e39a4a616c ("MIPS: Rewrite sysmips(MIPS_ATOMIC_SET, ...) in C with inline assembler")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/16148/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Paul Burton [Thu, 30 Mar 2017 18:37:44 +0000 (11:37 -0700)]
MIPS: module: Ensure we always clean up r_mips_hi16_list
commit
351b0940d473146923711bc943fc881354a4c1f3 upstream.
If we hit an error whilst processing a reloc then we would return early
from apply_relocate & potentially not free entries in r_mips_hi16_list,
thereby leaking memory. Fix this by ensuring that we always run the code
to free r_mipps_hi16_list when errors occur.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Fixes: 861667dc82f5 ("MIPS: Fix race condition in module relocation code.")
Fixes: 04211a574641 ("MIPS: Bail on unsupported module relocs")
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/15831/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Paul Burton [Thu, 4 Feb 2016 13:05:02 +0000 (13:05 +0000)]
MIPS: Bail on unsupported module relocs
commit
04211a574641e29b529dcc84e75c03d7e9e368cf upstream.
When an unsupported reloc is encountered in a module, we currently
blindly branch to whatever would be at its entry in the reloc handler
function pointer arrays. This may be NULL, or if the unsupported reloc
has a type greater than that of the supported reloc with the highest
type then we'll dereference some value after the function pointer array
& branch to that. The result is at best a kernel oops.
Fix this by checking that the reloc type has an entry in the function
pointer array (ie. is less than the number of items in the array) and
that the handler is non-NULL, returning an error code to fail the module
load if no handler is found.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Steven J. Hill <Steven.Hill@imgtec.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/12432/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Johan Hovold [Wed, 21 Jun 2017 09:35:09 +0000 (11:35 +0200)]
scsi: sun_esp: fix device reference leaks
commit
f62f9ffdb5ef683ef8cffb43932fa72cc3713e94 upstream.
Make sure to drop the reference to the dma device taken by
of_find_device_by_node() on probe errors and on driver unbind.
Fixes: 334ae614772b ("sparc: Kill SBUS DVMA layer.")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Jan Kara [Mon, 26 Jun 2017 15:48:18 +0000 (08:48 -0700)]
xfs: Don't clear SGID when inheriting ACLs
commit
8ba358756aa08414fa9e65a1a41d28304ed6fd7f upstream.
When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit
set, DIR1 is expected to have SGID bit set (and owning group equal to
the owning group of 'DIR0'). However when 'DIR0' also has some default
ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on
'DIR1' to get cleared if user is not member of the owning group.
Fix the problem by calling __xfs_set_acl() instead of xfs_set_acl() when
setting up inode in xfs_generic_create(). That prevents SGID bit
clearing and mode is properly set by posix_acl_create() anyway. We also
reorder arguments of __xfs_set_acl() to match the ordering of
xfs_set_acl() to make things consistent.
Fixes: 073931017b49d9458aa351605b43a7e34598caef
CC: Darrick J. Wong <darrick.wong@oracle.com>
CC: linux-xfs@vger.kernel.org
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Dan Carpenter [Fri, 23 Jun 2017 07:02:00 +0000 (10:02 +0300)]
scsi: bnx2i: missing error code in bnx2i_ep_connect()
commit
1d32a62c74b3bcb69822b0f4745af5410cfec3a7 upstream.
If bnx2i_map_ep_dbell_regs() then we accidentally return NULL instead of
an error pointer. It results in a NULL dereference in
iscsi_if_ep_connect().
Fixes: cf4e6363859d ("[SCSI] bnx2i: Add bnx2i iSCSI driver.")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Paolo Bonzini [Wed, 21 Jun 2017 14:35:46 +0000 (16:35 +0200)]
scsi: virtio_scsi: let host do exception handling
commit
e72c9a2a67a6400c8ef3d01d4c461dbbbfa0e1f0 upstream.
virtio_scsi tries to do exception handling after the default 30 seconds
timeout expires. However, it's better to let the host control the
timeout, otherwise with a heavy I/O load it is likely that an abort will
also timeout. This leads to fatal errors like filesystems going
offline.
Disable the 'sd' timeout and allow the host to do exception handling,
following the precedent of the storvsc driver.
Hannes has a proposal to introduce timeouts in virtio, but this provides
an immediate solution for stable kernels too.
[mkp: fixed typo]
Reported-by: Douglas Miller <dougmill@linux.vnet.ibm.com>
Cc: "James E.J. Bottomley" <jejb@linux.vnet.ibm.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Hannes Reinecke <hare@suse.de>
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Mateusz Jurczyk [Fri, 23 Jun 2017 17:32:28 +0000 (19:32 +0200)]
af_iucv: Move sockaddr length checks to before accessing sa_family in bind and connect handlers
commit
e3c42b61ff813921ba58cfc0019e3fd63f651190 upstream.
Verify that the caller-provided sockaddr structure is large enough to
contain the sa_family field, before accessing it in bind() and connect()
handlers of the AF_IUCV socket. Since neither syscall enforces a minimum
size of the corresponding memory region, very short sockaddrs (zero or
one byte long) result in operating on uninitialized memory while
referencing .sa_family.
Fixes: 52a82e23b9f2 ("af_iucv: Validate socket address length in iucv_sock_bind()")
Signed-off-by: Mateusz Jurczyk <mjurczyk@google.com>
[jwi: removed unneeded null-check for addr]
Signed-off-by: Julian Wiedmann <jwi@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Matt Weber [Thu, 22 Jun 2017 20:00:33 +0000 (15:00 -0500)]
i2c: cadance: fix ctrl/addr reg write order
commit
8064c616984eaa015f018dba595d78cd24a0cc8c upstream.
The driver was clearing the hold bit in the control register before
writing to the address register which resulted in a stop condition
being generated rather than a repeated start.
This issue was only observed when a system was running much
slower than a normal processor would execute. The IP data sheet
mentions a ordering of writing to the address register before
clearing the hold.
Fixes: df8eb5691c4 ("i2c: Add driver for Cadence I2C controller")
Signed-off-by: John Linn <john.linn@xilinx.com>
Signed-off-by: Paresh Chaudhary <paresh.chaudhary@rockwellcollins.com>
Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Ian Abbott [Fri, 16 Jun 2017 18:35:34 +0000 (19:35 +0100)]
staging: comedi: fix clean-up of comedi_class in comedi_init()
commit
a9332e9ad09c2644c99058fcf6ae2f355e93ce74 upstream.
There is a clean-up bug in the core comedi module initialization
functions, `comedi_init()`. If the `comedi_num_legacy_minors` module
parameter is non-zero (and valid), it creates that many "legacy" devices
and registers them in SysFS. A failure causes the function to clean up
and return an error. Unfortunately, it fails to destroy the "comedi"
class that was created earlier. Fix it by adding a call to
`class_destroy(comedi_class)` at the appropriate place in the clean-up
sequence.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cyrille Pitchen [Fri, 23 Jun 2017 15:39:16 +0000 (17:39 +0200)]
spi: atmel: fix corrupted data issue on SAM9 family SoCs
commit
7094576ccdc3acfe1e06a1e2ab547add375baf7f upstream.
This patch disables the use of the DMA for data transfer and forces the
use of PIO transfers instead as a quick fixup to solve the cache aliasing
issue on ARM9 based cores, which embeds a VIVT data cache.
Indeed in the case of VIVT data caches, it is not safe to call dma_map_*()
functions to map buffers for DMA transfers when those buffers have been
allocated by vmalloc() or from any DMA-unsafe area.
Further patches may propose a better solution based on the use of a bounce
buffer at the SPI sub-system level but such solution needs more time to be
discussed. Then the use of DMA transfers could be enabled again to improve
the performances but before that, this patch already solves the issue.
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@microchip.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Emmanuel Grumbach [Fri, 5 May 2017 05:51:24 +0000 (08:51 +0300)]
iwlwifi: mvm: fix the recovery flow while connecting
commit
6b28f9784c394f0692e160f81b07c82cb64af160 upstream.
In BSS mode in the disconnection flow, mac80211 removes
the AP station before the vif is set to unassociated.
Our firmware wants it the other way around: first set
the vif as unassociated, and then remove the AP station.
In order to bridge between those two different behaviors,
iwlmvm doesn't remove the station from the firmware when
mac80211 removes it, but only after the vif is set to
unassociated. The implementation is in
iwl_mvm_bss_info_changed_station:
if (assoc state was modified && mvmvif->ap_sta_id is VALID
&& assoc state is now UNASSC)
remove_the_station_from_the_firmware()
During the recovery flow, mac80211 re-adds the AP station
and then reconfigures the vif. Since the vif is not
associated, and then, we enter the if above (which was
intended to be taken in the disconnection flow only) and
remove the station we just added. This defeats the
recovery flow.
Fix this by not removing the AP station in this flow if
we are in recovery flow.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
[bwh: Backported to 3.16: adjust filename, context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Filipe Manana [Tue, 30 May 2017 04:29:09 +0000 (05:29 +0100)]
Btrfs: fix invalid extent maps due to hole punching
commit
609805d809733d0c669f21f710bdac308cc63cba upstream.
While punching a hole in a range that is not aligned with the sector size
(currently the same as the page size) we can end up leaving an extent map
in memory with a length that is smaller then the sector size or with a
start offset that is not aligned to the sector size. Both cases are not
expected and can lead to problems. This issue is easily detected
after the patch from commit
a7e3b975a0f9 ("Btrfs: fix reported number of
inode blocks"), introduced in kernel 4.12-rc1, in a scenario like the
following for example:
$ mkfs.btrfs -f /dev/sdb
$ mount /dev/sdb /mnt
$ xfs_io -c "pwrite -S 0xaa -b 100K 0 100K" /mnt/foo
$ xfs_io -c "fpunch 60K 90K" /mnt/foo
$ xfs_io -c "pwrite -S 0xbb -b 100K 50K 100K" /mnt/foo
$ xfs_io -c "pwrite -S 0xcc -b 50K 100K 50K" /mnt/foo
$ umount /mnt
After the unmount operation we can see several warnings emmitted due to
underflows related to space reservation counters:
[ 2837.443299] ------------[ cut here ]------------
[ 2837.447395] WARNING: CPU: 8 PID: 2474 at fs/btrfs/inode.c:9444 btrfs_destroy_inode+0xe8/0x27e [btrfs]
[ 2837.452108] Modules linked in: dm_flakey dm_mod ppdev parport_pc psmouse parport sg pcspkr acpi_cpufreq tpm_tis tpm_tis_core i2c_piix4 i2c_core evdev tpm button se
rio_raw sunrpc loop autofs4 ext4 crc16 jbd2 mbcache btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_gene
ric raid1 raid0 multipath linear md_mod sr_mod cdrom sd_mod ata_generic virtio_scsi ata_piix libata virtio_pci virtio_ring virtio e1000 scsi_mod floppy
[ 2837.458389] CPU: 8 PID: 2474 Comm: umount Tainted: G W 4.10.0-rc8-btrfs-next-43+ #1
[ 2837.459754] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.9.1-0-gb3ef39f-prebuilt.qemu-project.org 04/01/2014
[ 2837.462379] Call Trace:
[ 2837.462379] dump_stack+0x68/0x92
[ 2837.462379] __warn+0xc2/0xdd
[ 2837.462379] warn_slowpath_null+0x1d/0x1f
[ 2837.462379] btrfs_destroy_inode+0xe8/0x27e [btrfs]
[ 2837.462379] destroy_inode+0x3d/0x55
[ 2837.462379] evict+0x177/0x17e
[ 2837.462379] dispose_list+0x50/0x71
[ 2837.462379] evict_inodes+0x132/0x141
[ 2837.462379] generic_shutdown_super+0x3f/0xeb
[ 2837.462379] kill_anon_super+0x12/0x1c
[ 2837.462379] btrfs_kill_super+0x16/0x21 [btrfs]
[ 2837.462379] deactivate_locked_super+0x30/0x68
[ 2837.462379] deactivate_super+0x36/0x39
[ 2837.462379] cleanup_mnt+0x58/0x76
[ 2837.462379] __cleanup_mnt+0x12/0x14
[ 2837.462379] task_work_run+0x77/0x9b
[ 2837.462379] prepare_exit_to_usermode+0x9d/0xc5
[ 2837.462379] syscall_return_slowpath+0x196/0x1b9
[ 2837.462379] entry_SYSCALL_64_fastpath+0xab/0xad
[ 2837.462379] RIP: 0033:0x7f3ef3e6b9a7
[ 2837.462379] RSP: 002b:
00007ffdd0d8de58 EFLAGS:
00000246 ORIG_RAX:
00000000000000a6
[ 2837.462379] RAX:
0000000000000000 RBX:
0000556f76a39060 RCX:
00007f3ef3e6b9a7
[ 2837.462379] RDX:
0000000000000001 RSI:
0000000000000000 RDI:
0000556f76a3f910
[ 2837.462379] RBP:
0000556f76a3f910 R08:
0000556f76a3e670 R09:
0000000000000015
[ 2837.462379] R10:
00000000000006b4 R11:
0000000000000246 R12:
00007f3ef436ce64
[ 2837.462379] R13:
0000000000000000 R14:
0000556f76a39240 R15:
00007ffdd0d8e0e0
[ 2837.519355] ---[ end trace
e79345fe24b30b8d ]---
[ 2837.596256] ------------[ cut here ]------------
[ 2837.597625] WARNING: CPU: 8 PID: 2474 at fs/btrfs/extent-tree.c:5699 btrfs_free_block_groups+0x246/0x3eb [btrfs]
[ 2837.603547] Modules linked in: dm_flakey dm_mod ppdev parport_pc psmouse parport sg pcspkr acpi_cpufreq tpm_tis tpm_tis_core i2c_piix4 i2c_core evdev tpm button serio_raw sunrpc loop autofs4 ext4 crc16 jbd2 mbcache btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod sr_mod cdrom sd_mod ata_generic virtio_scsi ata_piix libata virtio_pci virtio_ring virtio e1000 scsi_mod floppy
[ 2837.659372] CPU: 8 PID: 2474 Comm: umount Tainted: G W 4.10.0-rc8-btrfs-next-43+ #1
[ 2837.663359] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.9.1-0-gb3ef39f-prebuilt.qemu-project.org 04/01/2014
[ 2837.663359] Call Trace:
[ 2837.663359] dump_stack+0x68/0x92
[ 2837.663359] __warn+0xc2/0xdd
[ 2837.663359] warn_slowpath_null+0x1d/0x1f
[ 2837.663359] btrfs_free_block_groups+0x246/0x3eb [btrfs]
[ 2837.663359] close_ctree+0x1dd/0x2e1 [btrfs]
[ 2837.663359] ? evict_inodes+0x132/0x141
[ 2837.663359] btrfs_put_super+0x15/0x17 [btrfs]
[ 2837.663359] generic_shutdown_super+0x6a/0xeb
[ 2837.663359] kill_anon_super+0x12/0x1c
[ 2837.663359] btrfs_kill_super+0x16/0x21 [btrfs]
[ 2837.663359] deactivate_locked_super+0x30/0x68
[ 2837.663359] deactivate_super+0x36/0x39
[ 2837.663359] cleanup_mnt+0x58/0x76
[ 2837.663359] __cleanup_mnt+0x12/0x14
[ 2837.663359] task_work_run+0x77/0x9b
[ 2837.663359] prepare_exit_to_usermode+0x9d/0xc5
[ 2837.663359] syscall_return_slowpath+0x196/0x1b9
[ 2837.663359] entry_SYSCALL_64_fastpath+0xab/0xad
[ 2837.663359] RIP: 0033:0x7f3ef3e6b9a7
[ 2837.663359] RSP: 002b:
00007ffdd0d8de58 EFLAGS:
00000246 ORIG_RAX:
00000000000000a6
[ 2837.663359] RAX:
0000000000000000 RBX:
0000556f76a39060 RCX:
00007f3ef3e6b9a7
[ 2837.663359] RDX:
0000000000000001 RSI:
0000000000000000 RDI:
0000556f76a3f910
[ 2837.663359] RBP:
0000556f76a3f910 R08:
0000556f76a3e670 R09:
0000000000000015
[ 2837.663359] R10:
00000000000006b4 R11:
0000000000000246 R12:
00007f3ef436ce64
[ 2837.663359] R13:
0000000000000000 R14:
0000556f76a39240 R15:
00007ffdd0d8e0e0
[ 2837.739445] ---[ end trace
e79345fe24b30b8e ]---
[ 2837.745595] ------------[ cut here ]------------
[ 2837.746412] WARNING: CPU: 8 PID: 2474 at fs/btrfs/extent-tree.c:5700 btrfs_free_block_groups+0x261/0x3eb [btrfs]
[ 2837.747955] Modules linked in: dm_flakey dm_mod ppdev parport_pc psmouse parport sg pcspkr acpi_cpufreq tpm_tis tpm_tis_core i2c_piix4 i2c_core evdev tpm button serio_raw sunrpc loop autofs4 ext4 crc16 jbd2 mbcache btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod sr_mod cdrom sd_mod ata_generic virtio_scsi ata_piix libata virtio_pci virtio_ring virtio e1000 scsi_mod floppy
[ 2837.755395] CPU: 8 PID: 2474 Comm: umount Tainted: G W 4.10.0-rc8-btrfs-next-43+ #1
[ 2837.756769] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.9.1-0-gb3ef39f-prebuilt.qemu-project.org 04/01/2014
[ 2837.758526] Call Trace:
[ 2837.758925] dump_stack+0x68/0x92
[ 2837.759383] __warn+0xc2/0xdd
[ 2837.759383] warn_slowpath_null+0x1d/0x1f
[ 2837.759383] btrfs_free_block_groups+0x261/0x3eb [btrfs]
[ 2837.759383] close_ctree+0x1dd/0x2e1 [btrfs]
[ 2837.759383] ? evict_inodes+0x132/0x141
[ 2837.759383] btrfs_put_super+0x15/0x17 [btrfs]
[ 2837.759383] generic_shutdown_super+0x6a/0xeb
[ 2837.759383] kill_anon_super+0x12/0x1c
[ 2837.759383] btrfs_kill_super+0x16/0x21 [btrfs]
[ 2837.759383] deactivate_locked_super+0x30/0x68
[ 2837.759383] deactivate_super+0x36/0x39
[ 2837.759383] cleanup_mnt+0x58/0x76
[ 2837.759383] __cleanup_mnt+0x12/0x14
[ 2837.759383] task_work_run+0x77/0x9b
[ 2837.759383] prepare_exit_to_usermode+0x9d/0xc5
[ 2837.759383] syscall_return_slowpath+0x196/0x1b9
[ 2837.759383] entry_SYSCALL_64_fastpath+0xab/0xad
[ 2837.759383] RIP: 0033:0x7f3ef3e6b9a7
[ 2837.759383] RSP: 002b:
00007ffdd0d8de58 EFLAGS:
00000246 ORIG_RAX:
00000000000000a6
[ 2837.759383] RAX:
0000000000000000 RBX:
0000556f76a39060 RCX:
00007f3ef3e6b9a7
[ 2837.759383] RDX:
0000000000000001 RSI:
0000000000000000 RDI:
0000556f76a3f910
[ 2837.759383] RBP:
0000556f76a3f910 R08:
0000556f76a3e670 R09:
0000000000000015
[ 2837.759383] R10:
00000000000006b4 R11:
0000000000000246 R12:
00007f3ef436ce64
[ 2837.759383] R13:
0000000000000000 R14:
0000556f76a39240 R15:
00007ffdd0d8e0e0
[ 2837.777063] ---[ end trace
e79345fe24b30b8f ]---
[ 2837.778235] ------------[ cut here ]------------
[ 2837.778856] WARNING: CPU: 8 PID: 2474 at fs/btrfs/extent-tree.c:9825 btrfs_free_block_groups+0x348/0x3eb [btrfs]
[ 2837.791385] Modules linked in: dm_flakey dm_mod ppdev parport_pc psmouse parport sg pcspkr acpi_cpufreq tpm_tis tpm_tis_core i2c_piix4 i2c_core evdev tpm button serio_raw sunrpc loop autofs4 ext4 crc16 jbd2 mbcache btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod sr_mod cdrom sd_mod ata_generic virtio_scsi ata_piix libata virtio_pci virtio_ring virtio e1000 scsi_mod floppy
[ 2837.797711] CPU: 8 PID: 2474 Comm: umount Tainted: G W 4.10.0-rc8-btrfs-next-43+ #1
[ 2837.798594] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.9.1-0-gb3ef39f-prebuilt.qemu-project.org 04/01/2014
[ 2837.800118] Call Trace:
[ 2837.800515] dump_stack+0x68/0x92
[ 2837.801015] __warn+0xc2/0xdd
[ 2837.801471] warn_slowpath_null+0x1d/0x1f
[ 2837.801698] btrfs_free_block_groups+0x348/0x3eb [btrfs]
[ 2837.801698] close_ctree+0x1dd/0x2e1 [btrfs]
[ 2837.801698] ? evict_inodes+0x132/0x141
[ 2837.801698] btrfs_put_super+0x15/0x17 [btrfs]
[ 2837.801698] generic_shutdown_super+0x6a/0xeb
[ 2837.801698] kill_anon_super+0x12/0x1c
[ 2837.801698] btrfs_kill_super+0x16/0x21 [btrfs]
[ 2837.801698] deactivate_locked_super+0x30/0x68
[ 2837.801698] deactivate_super+0x36/0x39
[ 2837.801698] cleanup_mnt+0x58/0x76
[ 2837.801698] __cleanup_mnt+0x12/0x14
[ 2837.801698] task_work_run+0x77/0x9b
[ 2837.801698] prepare_exit_to_usermode+0x9d/0xc5
[ 2837.801698] syscall_return_slowpath+0x196/0x1b9
[ 2837.801698] entry_SYSCALL_64_fastpath+0xab/0xad
[ 2837.801698] RIP: 0033:0x7f3ef3e6b9a7
[ 2837.801698] RSP: 002b:
00007ffdd0d8de58 EFLAGS:
00000246 ORIG_RAX:
00000000000000a6
[ 2837.801698] RAX:
0000000000000000 RBX:
0000556f76a39060 RCX:
00007f3ef3e6b9a7
[ 2837.801698] RDX:
0000000000000001 RSI:
0000000000000000 RDI:
0000556f76a3f910
[ 2837.801698] RBP:
0000556f76a3f910 R08:
0000556f76a3e670 R09:
0000000000000015
[ 2837.801698] R10:
00000000000006b4 R11:
0000000000000246 R12:
00007f3ef436ce64
[ 2837.801698] R13:
0000000000000000 R14:
0000556f76a39240 R15:
00007ffdd0d8e0e0
[ 2837.818441] ---[ end trace
e79345fe24b30b90 ]---
[ 2837.818991] BTRFS info (device sdc): space_info 1 has
7974912 free, is not full
[ 2837.819830] BTRFS info (device sdc): space_info total=
8388608, used=417792, pinned=0, reserved=0, may_use=
18446744073709547520, readonly=0
What happens in the above example is the following:
1) When punching the hole, at btrfs_punch_hole(), the variable tail_len
is set to 2048 (as tail_start is 148Kb + 1 and offset + len is 150Kb).
This results in the creation of an extent map with a length of 2Kb
starting at file offset 148Kb, through find_first_non_hole() ->
btrfs_get_extent().
2) The second write (first write after the hole punch operation), sets
the range [50Kb, 152Kb[ to delalloc.
3) The third write, at btrfs_find_new_delalloc_bytes(), sees the extent
map covering the range [148Kb, 150Kb[ and ends up calling
set_extent_bit() for the same range, which results in splitting an
existing extent state record, covering the range [148Kb, 152Kb[ into
two 2Kb extent state records, covering the ranges [148Kb, 150Kb[ and
[150Kb, 152Kb[.
4) Finally at lock_and_cleanup_extent_if_need(), immediately after calling
btrfs_find_new_delalloc_bytes() we clear the delalloc bit from the
range [100Kb, 152Kb[ which results in the btrfs_clear_bit_hook()
callback being invoked against the two 2Kb extent state records that
cover the ranges [148Kb, 150Kb[ and [150Kb, 152Kb[. When called against
the first 2Kb extent state, it calls btrfs_delalloc_release_metadata()
with a length argument of 2048 bytes. That function rounds up the length
to a sector size aligned length, so it ends up considering a length of
4096 bytes, and then calls calc_csum_metadata_size() which results in
decrementing the inode's csum_bytes counter by 4096 bytes, so after
it stays a value of 0 bytes. Then the same happens when
btrfs_clear_bit_hook() is called against the second extent state that
has a length of 2Kb, covering the range [150Kb, 152Kb[, the length is
rounded up to 4096 and calc_csum_metadata_size() ends up being called
to decrement 4096 bytes from the inode's csum_bytes counter, which
at that time has a value of 0, leading to an underflow, which is
exactly what triggers the first warning, at btrfs_destroy_inode().
All the other warnings relate to several space accounting counters
that underflow as well due to similar reasons.
A similar case but where the hole punching operation creates an extent map
with a start offset not aligned to the sector size is the following:
$ mkfs.btrfs -f /dev/sdb
$ mount /dev/sdb /mnt
$ xfs_io -f -c "fpunch 695K 820K" $SCRATCH_MNT/bar
$ xfs_io -c "pwrite -S 0xaa 1008K 307K" $SCRATCH_MNT/bar
$ xfs_io -c "pwrite -S 0xbb -b 630K 1073K 630K" $SCRATCH_MNT/bar
$ xfs_io -c "pwrite -S 0xcc -b 459K 1068K 459K" $SCRATCH_MNT/bar
$ umount /mnt
During the unmount operation we get similar traces for the same reasons as
in the first example.
So fix the hole punching operation to make sure it never creates extent
maps with a length that is not aligned to the sector size nor with a start
offset that is not aligned to the sector size, as this breaks all
assumptions and it's a land mine.
Fixes: d77815461f04 ("btrfs: Avoid trucating page or punching hole in a already existed hole.")
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.com>
[bwh: Backported to 3.16:
- sectorsize is a member of btrfs_root not btrfs_fs_info
- Adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Dan Carpenter [Mon, 19 Jun 2017 10:53:04 +0000 (13:53 +0300)]
x86/nmi: Fix timeout test in test_nmi_ipi()
commit
c133c7615751008f6c32ccae7cdfc5ff6e989c35 upstream.
We're supposed to exit the loop with "timeout" set to zero.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Don Zickus <dzickus@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: kernel-janitors@vger.kernel.org
Fixes: 99e8b9ca90d6 ("x86, NMI: Add NMI IPI selftest")
Link: http://lkml.kernel.org/r/20170619105304.GA23995@elgon.mountain
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Jiahau Chang [Mon, 19 Jun 2017 10:08:30 +0000 (13:08 +0300)]
xhci: Limit USB2 port wake support for AMD Promontory hosts
commit
dec08194ffeccfa1cf085906b53d301930eae18f upstream.
For AMD Promontory xHCI host, although you can disable USB 2.0 ports in
BIOS settings, those ports will be enabled anyway after you remove a
device on that port and re-plug it in again. It's a known limitation of
the chip. As a workaround we can clear the PORT_WAKE_BITS.
This will disable wake on connect, disconnect and overcurrent on
AMD Promontory USB2 ports
[checkpatch cleanup and commit message reword -Mathias]
Cc: Tsai Nicholas <nicholas.tsai@amd.com>
Signed-off-by: Jiahau Chang <Lars_Chang@asmedia.com.tw>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Liu Bo [Fri, 19 May 2017 17:39:15 +0000 (11:39 -0600)]
Btrfs: skip commit transaction if we don't have enough pinned bytes
commit
28785f70ef882e4798cd5706066a55dbf7adf80e upstream.
We commit transaction in order to reclaim space from pinned bytes because
it could process delayed refs, and in may_commit_transaction(), we check
first if pinned bytes are enough for the required space, we then check if
that plus bytes reserved for delayed insert are enough for the required
space.
This changes the code to the above logic.
Fixes: b150a4f10d87 ("Btrfs: use a percpu to keep track of possibly pinned bytes")
Tested-by: Nikolay Borisov <nborisov@suse.com>
Reported-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Satish Babu Patakokila [Sat, 17 Jun 2017 00:33:40 +0000 (17:33 -0700)]
ASoC: compress: Derive substream from stream based on direction
commit
01b8cedfd0422326caae308641dcadaa85e0ca72 upstream.
Currently compress driver hardcodes direction as playback to get
substream from the stream. This results in getting the incorrect
substream for compressed capture usecase.
To fix this, remove the hardcoding and derive substream based on
the stream direction.
Signed-off-by: Satish Babu Patakokila <sbpata@codeaurora.org>
Signed-off-by: Banajit Goswami <bgoswami@codeaurora.org>
Acked-By: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Martin Hicks [Tue, 2 May 2017 13:38:35 +0000 (09:38 -0400)]
crypto: talitos - Extend max key length for SHA384/512-HMAC and AEAD
commit
03d2c5114c95797c0aa7d9f463348b171a274fd4 upstream.
An updated patch that also handles the additional key length requirements
for the AEAD algorithms.
The max keysize is not 96. For SHA384/512 it's 128, and for the AEAD
algorithms it's longer still. Extend the max keysize for the
AEAD size for AES256 + HMAC(SHA512).
Fixes: 357fb60502ede ("crypto: talitos - add sha224, sha384 and sha512 to existing AEAD algorithms")
Signed-off-by: Martin Hicks <mort@bork.org>
Acked-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Johan Hovold [Thu, 30 Mar 2017 10:15:35 +0000 (12:15 +0200)]
NFC: fix broken device allocation
commit
20777bc57c346b6994f465e0d8261a7fbf213a09 upstream.
Commit
7eda8b8e9677 ("NFC: Use IDR library to assing NFC devices IDs")
moved device-id allocation and struct-device initialisation from
nfc_allocate_device() to nfc_register_device().
This broke just about every nfc-device-registration error path, which
continue to call nfc_free_device() that tries to put the device
reference of the now uninitialised (but zeroed) struct device:
kobject: '(null)' (
ce316420): is not initialized, yet kobject_put() is being called.
The late struct-device initialisation also meant that various work
queues whose names are derived from the nfc device name were also
misnamed:
421 root 0 SW< [(null)_nci_cmd_]
422 root 0 SW< [(null)_nci_rx_w]
423 root 0 SW< [(null)_nci_tx_w]
Move the id-allocation and struct-device initialisation back to
nfc_allocate_device() and fix up the single call site which did not use
nfc_free_device() in its error path.
Fixes: 7eda8b8e9677 ("NFC: Use IDR library to assing NFC devices IDs")
Cc: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
[bwh: Backported to 3.16: drop change in nci_allocate_device()]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Liviu Dudau [Thu, 15 Jun 2017 14:13:46 +0000 (15:13 +0100)]
drm/msm/hdmi: Use bitwise operators when building register values
commit
ffe8f53f9cc73fb25c8f78d4aed7ddf285503a60 upstream.
Commit
c0c0d9eeeb8d ("drm/msm: hdmi audio support") uses logical
OR operators to build up a value to be written in the
REG_HDMI_AUDIO_INFO0 and REG_HDMI_AUDIO_INFO1 registers when it
should have used bitwise operators.
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
Fixes: c0c0d9eeeb8d ("drm/msm: hdmi audio support")
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Jan Kara [Tue, 13 Jun 2017 14:20:25 +0000 (16:20 +0200)]
udf: Fix deadlock between writeback and udf_setsize()
commit
f2e95355891153f66d4156bf3a142c6489cd78c6 upstream.
udf_setsize() called truncate_setsize() with i_data_sem held. Thus
truncate_pagecache() called from truncate_setsize() could lock a page
under i_data_sem which can deadlock as page lock ranks below
i_data_sem - e. g. writeback can hold page lock and try to acquire
i_data_sem to map a block.
Fix the problem by moving truncate_setsize() calls from under
i_data_sem. It is safe for us to change i_size without holding
i_data_sem as all the places that depend on i_size being stable already
hold inode_lock.
Fixes: 7e49b6f2480cb9a9e7322a91592e56a5c85361f5
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Jan Kara [Tue, 13 Jun 2017 13:54:58 +0000 (15:54 +0200)]
udf: Fix races with i_size changes during readpage
commit
9795e0e8ac0d6a3ee092f1b555b284b57feef99e upstream.
__udf_adinicb_readpage() uses i_size several times. When truncate
changes i_size while the function is running, it can observe several
different values and thus e.g. expose uninitialized parts of page to
userspace. Also use i_size_read() in the function since it does not hold
inode_lock. Since i_size is guaranteed to be small, this cannot really
cause any issues even on 32-bit archs but let's be careful.
Fixes: 9c2fc0de1a6e638fe58c354a463f544f42a90a09
Signed-off-by: Jan Kara <jack@suse.cz>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Bjørn Mork [Tue, 13 Jun 2017 17:11:42 +0000 (19:11 +0200)]
USB: serial: qcserial: new Sierra Wireless EM7305 device ID
commit
996fab55d864ed604158f71724ff52db1c2454a3 upstream.
A new Sierra Wireless EM7305 device ID used in a Toshiba laptop.
Reported-by: Petr Kloc <petr_kloc@yahoo.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Johan Hovold [Mon, 12 Jun 2017 14:30:16 +0000 (16:30 +0200)]
USB: serial: option: add two Longcheer device ids
commit
8fb060da715ad10fe956d7c0077b2fb0c12bb9d7 upstream.
Add two Longcheer device-id entries which specifically enables a
Telewell TW-3G HSPA+ branded modem (0x9801).
Reported-by: Teemu Likonen <tlikonen@iki.fi>
Reported-by: Bjørn Mork <bjorn@mork.no>
Reported-by: Lars Melin <larsm17@gmail.com>
Tested-by: Teemu Likonen <tlikonen@iki.fi>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Mikulas Patocka [Wed, 7 Jun 2017 23:05:31 +0000 (19:05 -0400)]
md: don't use flush_signals in userspace processes
commit
f9c79bc05a2a91f4fba8bfd653579e066714b1ec upstream.
The function flush_signals clears all pending signals for the process. It
may be used by kernel threads when we need to prepare a kernel thread for
responding to signals. However using this function for an userspaces
processes is incorrect - clearing signals without the program expecting it
can cause misbehavior.
The raid1 and raid5 code uses flush_signals in its request routine because
it wants to prepare for an interruptible wait. This patch drops
flush_signals and uses sigprocmask instead to block all signals (including
SIGKILL) around the schedule() call. The signals are not lost, but the
schedule() call won't respond to them.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Acked-by: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Bjorn Helgaas [Fri, 19 May 2017 19:40:50 +0000 (14:40 -0500)]
PCI: Correct PCI_STD_RESOURCE_END usage
commit
2f686f1d9beee135de6d08caea707ec7bfc916d4 upstream.
PCI_STD_RESOURCE_END is (confusingly) the index of the last valid BAR, not
the *number* of BARs. To iterate through all possible BARs, we need to
include PCI_STD_RESOURCE_END.
Fixes: 9fe373f9997b ("PCI: Increase IBM ipr SAS Crocodile BARs to at least system page size")
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Benjamin Herrenschmidt [Tue, 13 Jun 2017 06:01:13 +0000 (16:01 +1000)]
usb: Fix typo in the definition of Endpoint[out]Request
commit
7cf916bd639bd26db7214f2205bccdb4b9306256 upstream.
The current definition is wrong. This breaks my upcoming
Aspeed virtual hub driver.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Michael Grzeschik [Mon, 22 May 2017 11:02:44 +0000 (13:02 +0200)]
usb: usbip: set buffer pointers to NULL after free
commit
b3b51417d0af63fb9a06662dc292200aed9ea53f upstream.
The usbip stack dynamically allocates the transfer_buffer and
setup_packet of each urb that got generated by the tcp to usb stub code.
As these pointers are always used only once we will set them to NULL
after use. This is done likewise to the free_urb code in vudc_dev.c.
This patch fixes double kfree situations where the usbip remote side
added the URB_FREE_BUFFER.
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Acked-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[bwh: Backported to 3.16: adjust filenames]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Roopa Prabhu [Sun, 11 Jun 2017 23:32:50 +0000 (16:32 -0700)]
vxlan: dont migrate permanent fdb entries during learn
commit
e0090a9e979de5202c7d16c635dea2f005221073 upstream.
This patch fixes vxlan_snoop to not move permanent fdb entries
on learn events. This is consistent with the bridge fdb
handling of permanent entries.
Fixes: 26a41ae60438 ("vxlan: only migrate dynamic FDB entries")
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Lorenzo Bianconi [Tue, 6 Jun 2017 20:51:24 +0000 (22:51 +0200)]
iio: magnetometer: st_magn_spi: fix spi_device_id table
commit
c83761ff0aac954aa368c623bb0f0d1a3214e834 upstream.
Remove LSM303DLHC, LSM303DLM from st_magn_id_table since LSM303DL series
does not support spi interface
Fixes: 872e79add756 (iio: magn: Add STMicroelectronics magn driver)
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@st.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Lorenzo Bianconi [Tue, 6 Jun 2017 20:51:23 +0000 (22:51 +0200)]
iio: accel: st_accel_spi: fix spi_device_id table
commit
93b1b02fae8abff3efe570243e0f11f61e16e973 upstream.
Remove LSM303DL, LSM303DLM, LSM303DLH, LSM303DLHC from st_accel_id_table
since LSM303DL series does not support spi interface
Fixes: d62511689de5 (iio: accel: Add STMicroelectronics accel driver)
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@st.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Jason A. Donenfeld [Sat, 10 Jun 2017 02:59:11 +0000 (04:59 +0200)]
Bluetooth: use constant time memory comparison for secret values
commit
329d82309824ff1082dc4a91a5bbed8c3bec1580 upstream.
This file is filled with complex cryptography. Thus, the comparisons of
MACs and secret keys and curve points and so forth should not add timing
attacks, which could either result in a direct forgery, or, given the
complexity, some other type of attack.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
[bwh: Backported to 3.16:
- Drop inapplicable changes
- Adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Adam Borowski [Sat, 3 Jun 2017 07:35:06 +0000 (09:35 +0200)]
vt: fix unchecked __put_user() in tioclinux ioctls
commit
6987dc8a70976561d22450b5858fc9767788cc1c upstream.
Only read access is checked before this call.
Actually, at the moment this is not an issue, as every in-tree arch does
the same manual checks for VERIFY_READ vs VERIFY_WRITE, relying on the MMU
to tell them apart, but this wasn't the case in the past and may happen
again on some odd arch in the future.
If anyone cares about 3.7 and earlier, this is a security hole (untested)
on real 80386 CPUs.
Signed-off-by: Adam Borowski <kilobyte@angband.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Arnd Bergmann [Thu, 8 Jun 2017 08:53:10 +0000 (10:53 +0200)]
xen: avoid type warning in xchg_xen_ulong
commit
9cc91f212111cdcbefa02dcdb7dd443f224bf52c upstream.
The improved type-checking version of container_of() triggers a warning for
xchg_xen_ulong, pointing out that 'xen_ulong_t' is unsigned, but atomic64_t
contains a signed value:
drivers/xen/events/events_2l.c: In function 'evtchn_2l_handle_events':
drivers/xen/events/events_2l.c:187:1020: error: call to '__compiletime_assert_187' declared with attribute error: pointer type mismatch in container_of()
This adds a cast to work around the warning.
Cc: Ian Abbott <abbotti@mev.co.uk>
Fixes: 85323a991d40 ("xen: arm: mandate EABI and use generic atomic operations.")
Fixes: daa2ac80834d ("kernel.h: handle pointers to arrays better in container_of()")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Peter Zijlstra [Tue, 30 May 2017 09:45:12 +0000 (11:45 +0200)]
perf/core: Correct event creation with PERF_FORMAT_GROUP
commit
ba5213ae6b88fb170c4771fef6553f759c7d8cdd upstream.
Andi was asking about PERF_FORMAT_GROUP vs inherited events, which led
to the discovery of a bug from commit:
3dab77fb1bf8 ("perf: Rework/fix the whole read vs group stuff")
- PERF_SAMPLE_GROUP = 1U << 4,
+ PERF_SAMPLE_READ = 1U << 4,
- if (attr->inherit && (attr->sample_type & PERF_SAMPLE_GROUP))
+ if (attr->inherit && (attr->read_format & PERF_FORMAT_GROUP))
is a clear fail :/
While this changes user visible behaviour; it was previously possible
to create an inherited event with PERF_SAMPLE_READ; this is deemed
acceptible because its results were always incorrect.
Reported-by: Andi Kleen <ak@linux.intel.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: Jiri Olsa <jolsa@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vince@deater.net>
Fixes: 3dab77fb1bf8 ("perf: Rework/fix the whole read vs group stuff")
Link: http://lkml.kernel.org/r/20170530094512.dy2nljns2uq7qa3j@hirez.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Chris Wilson [Wed, 31 May 2017 15:50:43 +0000 (18:50 +0300)]
e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails
commit
833521ebc65b1c3092e5c0d8a97092f98eec595d upstream.
An error during suspend (e100e_pm_suspend),
[ 429.994338] ACPI : EC: event blocked
[ 429.994633] e1000e: EEE TX LPI TIMER:
00000011
[ 430.955451] pci_pm_suspend(): e1000e_pm_suspend+0x0/0x30 [e1000e] returns -2
[ 430.955454] dpm_run_callback(): pci_pm_suspend+0x0/0x140 returns -2
[ 430.955458] PM: Device 0000:00:19.0 failed to suspend async: error -2
[ 430.955581] PM: Some devices failed to suspend, or early wake event detected
[ 430.957709] ACPI : EC: event unblocked
lead to complete failure:
[ 432.585002] ------------[ cut here ]------------
[ 432.585013] WARNING: CPU: 3 PID: 8372 at kernel/irq/manage.c:1478 __free_irq+0x9f/0x280
[ 432.585015] Trying to free already-free IRQ 20
[ 432.585016] Modules linked in: cdc_ncm usbnet x86_pkg_temp_thermal intel_powerclamp coretemp mii crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep lpc_ich snd_hda_core snd_pcm mei_me mei sdhci_pci sdhci i915 mmc_core e1000e ptp pps_core prime_numbers
[ 432.585042] CPU: 3 PID: 8372 Comm: kworker/u16:40 Tainted: G U 4.10.0-rc8-CI-Patchwork_3870+ #1
[ 432.585044] Hardware name: LENOVO 2356GCG/2356GCG, BIOS G7ET31WW (1.13 ) 07/02/2012
[ 432.585050] Workqueue: events_unbound async_run_entry_fn
[ 432.585051] Call Trace:
[ 432.585058] dump_stack+0x67/0x92
[ 432.585062] __warn+0xc6/0xe0
[ 432.585065] warn_slowpath_fmt+0x4a/0x50
[ 432.585070] ? _raw_spin_lock_irqsave+0x49/0x60
[ 432.585072] __free_irq+0x9f/0x280
[ 432.585075] free_irq+0x34/0x80
[ 432.585089] e1000_free_irq+0x65/0x70 [e1000e]
[ 432.585098] e1000e_pm_freeze+0x7a/0xb0 [e1000e]
[ 432.585106] e1000e_pm_suspend+0x21/0x30 [e1000e]
[ 432.585113] pci_pm_suspend+0x71/0x140
[ 432.585118] dpm_run_callback+0x6f/0x330
[ 432.585122] ? pci_pm_freeze+0xe0/0xe0
[ 432.585125] __device_suspend+0xea/0x330
[ 432.585128] async_suspend+0x1a/0x90
[ 432.585132] async_run_entry_fn+0x34/0x160
[ 432.585137] process_one_work+0x1f4/0x6d0
[ 432.585140] ? process_one_work+0x16e/0x6d0
[ 432.585143] worker_thread+0x49/0x4a0
[ 432.585145] kthread+0x107/0x140
[ 432.585148] ? process_one_work+0x6d0/0x6d0
[ 432.585150] ? kthread_create_on_node+0x40/0x40
[ 432.585154] ret_from_fork+0x2e/0x40
[ 432.585156] ---[ end trace
6712df7f8c4b9124 ]---
The unwind failures stems from commit
2800209994f8 ("e1000e: Refactor PM
flows"), but it may be a later patch that introduced the non-recoverable
behaviour.
Fixes: 2800209994f8 ("e1000e: Refactor PM flows")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99847
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
David Ertman [Fri, 11 Jul 2014 06:21:31 +0000 (06:21 +0000)]
e1000e: Fix Runtime PM blocks EEE link negotiation in S5
commit
2a7e19af94104b270d675c52bba2ca1bc20efa70 upstream.
Adding a function, and associated calls, to flush writes to (read) the LPIC
MAC register before entering the shutdown flow. This fixes the problem
of the PHY never negotiating a 100M link (if both sides of the link support
EEE and 100M link) when Runtime PM is enabled.
Signed-off-by: Dave Ertman <david.m.ertman@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Jim Mattson [Tue, 23 May 2017 18:52:54 +0000 (11:52 -0700)]
kvm: vmx: Check value written to IA32_BNDCFGS
commit
4531662d1abf6c1f0e5c2b86ddb60e61509786c8 upstream.
Bits 11:2 must be zero and the linear addess in bits 63:12 must be
canonical. Otherwise, WRMSR(BNDCFGS) should raise #GP.
Fixes: 0dd376e709975779 ("KVM: x86: add MSR_IA32_BNDCFGS to msrs_to_save")
Signed-off-by: Jim Mattson <jmattson@google.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
[bwh: Backported to 3.16: adjust filename, context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Jim Mattson [Wed, 24 May 2017 17:49:25 +0000 (10:49 -0700)]
kvm: x86: Guest BNDCFGS requires guest MPX support
commit
4439af9f911ae0243ffe4e2dfc12bace49605d8b upstream.
The BNDCFGS MSR should only be exposed to the guest if the guest
supports MPX. (cf. the TSC_AUX MSR and RDTSCP.)
Fixes: 0dd376e709975779 ("KVM: x86: add MSR_IA32_BNDCFGS to msrs_to_save")
Change-Id: I3ad7c01bda616715137ceac878f3fa7e66b6b387
Signed-off-by: Jim Mattson <jmattson@google.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Jim Mattson [Tue, 23 May 2017 18:52:52 +0000 (11:52 -0700)]
kvm: vmx: Do not disable intercepts for BNDCFGS
commit
a8b6fda38f80e75afa3b125c9e7f2550b579454b upstream.
The MSR permission bitmaps are shared by all VMs. However, some VMs
may not be configured to support MPX, even when the host does. If the
host supports VMX and the guest does not, we should intercept accesses
to the BNDCFGS MSR, so that we can synthesize a #GP
fault. Furthermore, if the host does not support MPX and the
"ignore_msrs" kvm kernel parameter is set, then we should intercept
accesses to the BNDCFGS MSR, so that we can skip over the rdmsr/wrmsr
without raising a #GP fault.
Fixes: da8999d31818fdc8 ("KVM: x86: Intel MPX vmx and msr handle")
Signed-off-by: Jim Mattson <jmattson@google.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Johan Hovold [Thu, 1 Jun 2017 07:45:59 +0000 (04:45 -0300)]
mceusb: fix memory leaks in error path
commit
2d5a6ce71c72d98d4f7948672842e3e8c265a8b7 upstream.
Fix urb and transfer-buffer leaks in an urb-submission error path which
may be hit when a device is disconnected.
Fixes: 66e89522aff7 ("V4L/DVB: IR: add mceusb IR receiver driver")
Cc: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
[bwh: Backported to 3.16:
- Add check on urb_type, as async_buf and async_urb aren't always allocated
- Adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Ville Syrjälä [Thu, 15 Dec 2016 17:47:34 +0000 (19:47 +0200)]
drm/i915: Workaround VLV/CHV DSI scanline counter hardware fail
commit
ec1b4ee2834e66884e5b0d3d465f347ff212e372 upstream.
The scanline counter is bonkers on VLV/CHV DSI. The scanline counter
increment is not lined up with the start of vblank like it is on
every other platform and output type. This causes problems for
both the vblank timestamping and atomic update vblank evasion.
On my FFRD8 machine at least, the scanline counter increment
happens about 1/3 of a scanline ahead of the start of vblank (which
is where all register latching happens still). That means we can't
trust the scanline counter to tell us whether we're in vblank or not
while we're on that particular line. In order to keep vblank
timestamping in working condition when called from the vblank irq,
we'll leave scanline_offset at one, which means that the entire
line containing the start of vblank is considered to be inside
the vblank.
For the vblank evasion we'll need to consider that entire line
to be bad, since we can't tell whether the registers already
got latched or not. And we can't actually use the start of vblank
interrupt to get us past that line as the interrupt would fire
too soon, and then we'd up waiting for the next start of vblank
instead. One way around that would using the frame start
interrupt instead since that wouldn't fire until the next
scanline, but that would require some bigger changes in the
interrupt code. So for simplicity we'll just poll until we get
past the bad line.
v2: Adjust the comments a bit
Cc: Jonas Aaberg <cja@gmx.net>
Tested-by: Jonas Aaberg <cja@gmx.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99086
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161215174734.28779-1-ville.syrjala@linux.intel.com
Tested-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
[bwh: Backported to 3.16:
- Pass dev instead of dev_priv to hardware type predicates
- Use intel_pipe_has_type() to check output type]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Wolfram Sang [Sat, 27 May 2017 18:52:43 +0000 (20:52 +0200)]
Documentation: DMA API: fix a typo in a function name
commit
6a08d83e4324fcb23994dfd481acedf49e37cc06 upstream.
Correct the typo, the wrongly typed function does not exist.
Fixes: 6c9c6d6301287e ("dma-debug: New interfaces to debug dma mapping errors")
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Ben Hutchings [Thu, 25 May 2017 12:58:33 +0000 (12:58 +0000)]
tools/lib/lockdep: Reduce MAX_LOCK_DEPTH to avoid overflowing lock_chain/: Depth
commit
98dcea0cfd04e083ac74137ceb9a632604740e2d upstream.
liblockdep has been broken since commit
75dd602a5198 ("lockdep: Fix
lock_chain::base size"), as that adds a check that MAX_LOCK_DEPTH is
within the range of lock_chain::depth and in liblockdep it is much
too large.
That should have resulted in a compiler error, but didn't because:
- the check uses ARRAY_SIZE(), which isn't yet defined in liblockdep
so is assumed to be an (undeclared) function
- putting a function call inside a BUILD_BUG_ON() expression quietly
turns it into some nonsense involving a variable-length array
It did produce a compiler warning, but I didn't notice because
liblockdep already produces too many warnings if -Wall is enabled
(which I'll fix shortly).
Even before that commit, which reduced lock_chain::depth from 8 bits
to 6, MAX_LOCK_DEPTH was too large.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: a.p.zijlstra@chello.nl
Link: http://lkml.kernel.org/r/20170525130005.5947-3-alexander.levin@verizon.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Thomas Bogendoerfer [Wed, 31 May 2017 20:21:03 +0000 (22:21 +0200)]
Fix serial console on SNI RM400 machines
commit
e279e6d98e0cf2c2fe008b3c29042b92f0e17b1d upstream.
sccnxp driver doesn't get the correct uart clock rate, if CONFIG_HAVE_CLOCK
is disabled. Correct usage of clk API to make it work with/without it.
Fixes: 90efa75f7ab0 (serial: sccnxp: Using CLK API for getting UART clock)
Suggested-by: Russell King - ARM Linux <linux@armlinux.org.uk>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Dong Bo [Tue, 25 Apr 2017 06:11:29 +0000 (14:11 +0800)]
arm64: Preventing READ_IMPLIES_EXEC propagation
commit
48f99c8ec0b25756d0283ab058826ae07d14fad7 upstream.
Like arch/arm/, we inherit the READ_IMPLIES_EXEC personality flag across
fork(). This is undesirable for a number of reasons:
* ELF files that don't require executable stack can end up with it
anyway
* We end up performing un-necessary I-cache maintenance when mapping
what should be non-executable pages
* Restricting what is executable is generally desirable when defending
against overflow attacks
This patch clears the personality flag when setting up the personality for
newly spwaned native tasks. Given that semi-recent AArch64 toolchains emit
a non-executable PT_GNU_STACK header, userspace applications can already
not rely on READ_IMPLIES_EXEC so shouldn't be adversely affected by this
change.
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Dong Bo <dongbo4@huawei.com>
[will: added comment to compat code, rewrote commit message]
Signed-off-by: Will Deacon <will.deacon@arm.com>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Arnd Bergmann [Thu, 11 May 2017 11:52:09 +0000 (13:52 +0200)]
wlcore: fix 64K page support
commit
4a4274bf2dbbd1c7a45be0c89a1687c9d2eef4a0 upstream.
In the stable linux-3.16 branch, I ran into a warning in the
wlcore driver:
drivers/net/wireless/ti/wlcore/spi.c: In function 'wl12xx_spi_raw_write':
drivers/net/wireless/ti/wlcore/spi.c:315:1: error: the frame size of 12848 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
Newer kernels no longer show the warning, but the bug is still there,
as the allocation is based on the CPU page size rather than the
actual capabilities of the hardware.
This replaces the PAGE_SIZE macro with the SZ_4K macro, i.e. 4096 bytes
per buffer.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
[bwh: Backported to 3.16:
- Include <linux/sizes.h> for definition of SZ_4K
- Adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Jaegeuk Kim [Wed, 17 May 2017 17:36:58 +0000 (10:36 -0700)]
f2fs: try to freeze in gc and discard threads
commit
1d7be2708277edfef95171d52fb65ee26eaa076b upstream.
This allows to freeze gc and discard threads.
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
[bwh: Backported to 3.16: drop changes to discard thread]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Jaegeuk Kim [Tue, 16 May 2017 20:20:16 +0000 (13:20 -0700)]
f2fs: load inode's flag from disk
commit
93607124c5450148e592c3d18ac533b4e5f25b8b upstream.
This patch fixes missing inode flag loaded from disk, reported by Tom.
[tom@localhost ~]$ sudo mount /dev/loop0 /mnt/
[tom@localhost ~]$ sudo chown tom:tom /mnt/
[tom@localhost ~]$ touch /mnt/testfile
[tom@localhost ~]$ sudo chattr +i /mnt/testfile
[tom@localhost ~]$ echo test > /mnt/testfile
bash: /mnt/testfile: Operation not permitted
[tom@localhost ~]$ rm /mnt/testfile
rm: cannot remove '/mnt/testfile': Operation not permitted
[tom@localhost ~]$ sudo umount /mnt/
[tom@localhost ~]$ sudo mount /dev/loop0 /mnt/
[tom@localhost ~]$ lsattr /mnt/testfile
----i-------------- /mnt/testfile
[tom@localhost ~]$ echo test > /mnt/testfile
[tom@localhost ~]$ rm /mnt/testfile
[tom@localhost ~]$ sudo umount /mnt/
Reported-by: Tom Yan <tom.ty89@outlook.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
[bwh: Backported to 3.16: mark_inode_dirty() is in the right place, so only
f2fs_iget() needs to be changed]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Dong Aisheng [Fri, 19 May 2017 07:05:41 +0000 (15:05 +0800)]
pinctrl: imx: fix debug message for SHARE_MUX_CONF_REG case
commit
66b54e3a5a64925d9819eae86b8f36e90e60037f upstream.
The original implemented debug message does not work for
SHARE_MUX_CONF_REG case. This patch fixes it.
Fixes: bf5a530971af ("pinctrl: imx: add VF610 support to imx pinctrl framework")
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Acked-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
[bwh: Backported to 3.16: adjust filename]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Brian Norris [Fri, 12 May 2017 16:41:58 +0000 (09:41 -0700)]
mwifiex: fixup error cases in mwifiex_add_virtual_intf()
commit
8535107aa4ef92520cbb9a4739563b389c5f8e2c upstream.
If we fail to add an interface in mwifiex_add_virtual_intf(), we might
hit a BUG_ON() in the networking code, because we didn't tear things
down properly. Among the problems:
(a) when failing to allocate workqueues, we fail to unregister the
netdev before calling free_netdev()
(b) even if we do try to unregister the netdev, we're still holding the
rtnl lock, so the device never properly unregistered; we'll be at
state NETREG_UNREGISTERING, and then hit free_netdev()'s:
BUG_ON(dev->reg_state != NETREG_UNREGISTERED);
(c) we're allocating some dependent resources (e.g., DFS workqueues)
after we've registered the interface; this may or may not cause
problems, but it's good practice to allocate these before registering
(d) we're not even trying to unwind anything when mwifiex_send_cmd() or
mwifiex_sta_init_cmd() fail
To fix these issues, let's:
* add a stacked set of error handling labels, to keep error handling
consistent and properly ordered (resolving (a) and (d))
* move the workqueue allocations before the registration (to resolve
(c); also resolves (b) by avoiding error cases where we have to
unregister)
[Incidentally, it's pretty easy to interrupt the alloc_workqueue() in,
e.g., the following:
iw phy phy0 interface add mlan0 type station
by sending it SIGTERM.]
This bugfix covers commits like commit
7d652034d1a0 ("mwifiex: channel
switch support for mwifiex"), but parts of this bug exist all the way
back to the introduction of dynamic interface handling in commit
93a1df48d224 ("mwifiex: add cfg80211 handlers add/del_virtual_intf").
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
[bwh: Backported to 3.16:
- There is no workqueue allocation or cleanup needed here
- Add 'ret' variable
- Keep logging errors with wiphy_err()
- Adjust filename]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Peter Zijlstra [Tue, 25 Apr 2017 12:31:11 +0000 (14:31 +0200)]
sched/topology: Fix overlapping sched_group_capacity
commit
1676330ecfa840113a37b25a49afda068380d19c upstream.
When building the overlapping groups we need to attach a consistent
sched_group_capacity structure. That is, all 'identical' sched_group's
should have the _same_ sched_group_capacity.
This can (once again) be demonstrated with a topology like:
node 0 1 2 3
0: 10 20 30 20
1: 20 10 20 30
2: 30 20 10 20
3: 20 30 20 10
But we need at least 2 CPUs per node for this to show up, after all,
if there is only one CPU per node, our CPU @i is per definition a
unique CPU that reaches this domain (aka balance-cpu).
Given the above NUMA topo and 2 CPUs per node:
[] CPU0 attaching sched-domain(s):
[] domain-0: span=0,4 level=DIE
[] groups: 0:{ span=0 }, 4:{ span=4 }
[] domain-1: span=0-1,3-5,7 level=NUMA
[] groups: 0:{ span=0,4 mask=0,4 cap=2048 }, 1:{ span=1,5 mask=1,5 cap=2048 }, 3:{ span=3,7 mask=3,7 cap=2048 }
[] domain-2: span=0-7 level=NUMA
[] groups: 0:{ span=0-1,3-5,7 mask=0,4 cap=6144 }, 2:{ span=1-3,5-7 mask=2,6 cap=6144 }
[] CPU1 attaching sched-domain(s):
[] domain-0: span=1,5 level=DIE
[] groups: 1:{ span=1 }, 5:{ span=5 }
[] domain-1: span=0-2,4-6 level=NUMA
[] groups: 1:{ span=1,5 mask=1,5 cap=2048 }, 2:{ span=2,6 mask=2,6 cap=2048 }, 4:{ span=0,4 mask=0,4 cap=2048 }
[] domain-2: span=0-7 level=NUMA
[] groups: 1:{ span=0-2,4-6 mask=1,5 cap=6144 }, 3:{ span=0,2-4,6-7 mask=3,7 cap=6144 }
Observe how CPU0-domain1-group0 and CPU1-domain1-group4 are the
'same' but have a different id (0 vs 4).
To fix this, use the group balance CPU to select the SGC. This means
we have to compute the full mask for each CPU and require a second
temporary mask to store the group mask in (it otherwise lives in the
SGC).
The fixed topology looks like:
[] CPU0 attaching sched-domain(s):
[] domain-0: span=0,4 level=DIE
[] groups: 0:{ span=0 }, 4:{ span=4 }
[] domain-1: span=0-1,3-5,7 level=NUMA
[] groups: 0:{ span=0,4 mask=0,4 cap=2048 }, 1:{ span=1,5 mask=1,5 cap=2048 }, 3:{ span=3,7 mask=3,7 cap=2048 }
[] domain-2: span=0-7 level=NUMA
[] groups: 0:{ span=0-1,3-5,7 mask=0,4 cap=6144 }, 2:{ span=1-3,5-7 mask=2,6 cap=6144 }
[] CPU1 attaching sched-domain(s):
[] domain-0: span=1,5 level=DIE
[] groups: 1:{ span=1 }, 5:{ span=5 }
[] domain-1: span=0-2,4-6 level=NUMA
[] groups: 1:{ span=1,5 mask=1,5 cap=2048 }, 2:{ span=2,6 mask=2,6 cap=2048 }, 0:{ span=0,4 mask=0,4 cap=2048 }
[] domain-2: span=0-7 level=NUMA
[] groups: 1:{ span=0-2,4-6 mask=1,5 cap=6144 }, 3:{ span=0,2-4,6-7 mask=3,7 cap=6144 }
Debugged-by: Lauro Ramos Venancio <lvenanci@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Fixes: e3589f6c81e4 ("sched: Allow for overlapping sched_domain spans")
Signed-off-by: Ingo Molnar <mingo@kernel.org>
[bwh: Backported to 3.16: adjust filename, context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Peter Zijlstra [Tue, 25 Apr 2017 12:00:49 +0000 (14:00 +0200)]
sched/topology: Fix overlapping sched_group_mask
commit
73bb059f9b8a00c5e1bf2f7ca83138c05d05e600 upstream.
The point of sched_group_mask is to select those CPUs from
sched_group_cpus that can actually arrive at this balance domain.
The current code gets it wrong, as can be readily demonstrated with a
topology like:
node 0 1 2 3
0: 10 20 30 20
1: 20 10 20 30
2: 30 20 10 20
3: 20 30 20 10
Where (for example) domain 1 on CPU1 ends up with a mask that includes
CPU0:
[] CPU1 attaching sched-domain:
[] domain 0: span 0-2 level NUMA
[] groups: 1 (mask: 1), 2, 0
[] domain 1: span 0-3 level NUMA
[] groups: 0-2 (mask: 0-2) (cpu_capacity: 3072), 0,2-3 (cpu_capacity: 3072)
This causes sched_balance_cpu() to compute the wrong CPU and
consequently should_we_balance() will terminate early resulting in
missed load-balance opportunities.
The fixed topology looks like:
[] CPU1 attaching sched-domain:
[] domain 0: span 0-2 level NUMA
[] groups: 1 (mask: 1), 2, 0
[] domain 1: span 0-3 level NUMA
[] groups: 0-2 (mask: 1) (cpu_capacity: 3072), 0,2-3 (cpu_capacity: 3072)
(note: this relies on OVERLAP domains to always have children, this is
true because the regular topology domains are still here -- this is
before degenerate trimming)
Debugged-by: Lauro Ramos Venancio <lvenanci@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Fixes: e3589f6c81e4 ("sched: Allow for overlapping sched_domain spans")
Signed-off-by: Ingo Molnar <mingo@kernel.org>
[bwh: Backported to 3.16:
- Use span, not sg_span
- Adjust filename context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Peter Zijlstra [Fri, 14 Apr 2017 15:24:02 +0000 (17:24 +0200)]
sched/topology: Fix building of overlapping sched-groups
commit
0372dd2736e02672ac6e189c31f7d8c02ad543cd upstream.
When building the overlapping groups, we very obviously should start
with the previous domain of _this_ @cpu, not CPU-0.
This can be readily demonstrated with a topology like:
node 0 1 2 3
0: 10 20 30 20
1: 20 10 20 30
2: 30 20 10 20
3: 20 30 20 10
Where (for example) CPU1 ends up generating the following nonsensical groups:
[] CPU1 attaching sched-domain:
[] domain 0: span 0-2 level NUMA
[] groups: 1 2 0
[] domain 1: span 0-3 level NUMA
[] groups: 1-3 (cpu_capacity = 3072) 0-1,3 (cpu_capacity = 3072)
Where the fact that domain 1 doesn't include a group with span 0-2 is
the obvious fail.
With patch this looks like:
[] CPU1 attaching sched-domain:
[] domain 0: span 0-2 level NUMA
[] groups: 1 0 2
[] domain 1: span 0-3 level NUMA
[] groups: 0-2 (cpu_capacity = 3072) 0,2-3 (cpu_capacity = 3072)
Debugged-by: Lauro Ramos Venancio <lvenanci@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Fixes: e3589f6c81e4 ("sched: Allow for overlapping sched_domain spans")
Signed-off-by: Ingo Molnar <mingo@kernel.org>
[bwh: Backported to 3.16: adjust filename]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Peter Zijlstra [Fri, 14 Apr 2017 12:20:05 +0000 (14:20 +0200)]
sched/fair, cpumask: Export for_each_cpu_wrap()
commit
c743f0a5c50f2fcbc628526279cfa24f3dabe182 upstream.
More users for for_each_cpu_wrap() have appeared. Promote the construct
to generic cpumask interface.
The implementation is slightly modified to reduce arguments.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Lauro Ramos Venancio <lvenanci@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: lwang@redhat.com
Link: http://lkml.kernel.org/r/20170414122005.o35me2h5nowqkxbv@hirez.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
[bwh: Backported to 3.16: there's no old version of the function to delete]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Lauro Ramos Venancio [Thu, 13 Apr 2017 13:56:07 +0000 (10:56 -0300)]
sched/topology: Refactor function build_overlap_sched_groups()
commit
8c0334697dc37eb3d6d7632304d3a3662248daac upstream.
Create functions build_group_from_child_sched_domain() and
init_overlap_sched_group(). No functional change.
Signed-off-by: Lauro Ramos Venancio <lvenanci@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Rik van Riel <riel@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1492091769-19879-2-git-send-email-lvenanci@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
[bwh: Backported to 3.16:
- Ccode being moved is slightly different
- Adjust filename]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Zhihui Zhang [Sat, 2 Aug 2014 01:18:03 +0000 (21:18 -0400)]
sched: Rename a misleading variable in build_overlap_sched_groups()
commit
aaecac4ad46b35ad308245384d019633fb9bc21b upstream.
The child variable in build_overlap_sched_groups() actually refers to the
peer or sibling domain of the given CPU. Rename it to sibling to be consistent
with the naming in build_group_mask().
Signed-off-by: Zhihui Zhang <zzhsuny@gmail.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org
Link: http://lkml.kernel.org/r/1406942283-18249-1-git-send-email-zzhsuny@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Ben Hutchings [Fri, 15 Sep 2017 17:30:20 +0000 (18:30 +0100)]
Linux 3.16.48
Linus Torvalds [Sun, 20 Aug 2017 20:26:27 +0000 (13:26 -0700)]
Sanitize 'move_pages()' permission checks
commit
197e7e521384a23b9e585178f3f11c9fa08274b9 upstream.
The 'move_paghes()' system call was introduced long long ago with the
same permission checks as for sending a signal (except using
CAP_SYS_NICE instead of CAP_SYS_KILL for the overriding capability).
That turns out to not be a great choice - while the system call really
only moves physical page allocations around (and you need other
capabilities to do a lot of it), you can check the return value to map
out some the virtual address choices and defeat ASLR of a binary that
still shares your uid.
So change the access checks to the more common 'ptrace_may_access()'
model instead.
This tightens the access checks for the uid, and also effectively
changes the CAP_SYS_NICE check to CAP_SYS_PTRACE, but it's unlikely that
anybody really _uses_ this legacy system call any more (we hav ebetter
NUMA placement models these days), so I expect nobody to notice.
Famous last words.
Reported-by: Otto Ebeling <otto.ebeling@iki.fi>
Acked-by: Eric W. Biederman <ebiederm@xmission.com>
Cc: Willy Tarreau <w@1wt.eu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Wei Wang [Thu, 18 May 2017 18:22:33 +0000 (11:22 -0700)]
tcp: initialize rcv_mss to TCP_MIN_MSS instead of 0
commit
499350a5a6e7512d9ed369ed63a4244b6536f4f8 upstream.
When tcp_disconnect() is called, inet_csk_delack_init() sets
icsk->icsk_ack.rcv_mss to 0.
This could potentially cause tcp_recvmsg() => tcp_cleanup_rbuf() =>
__tcp_select_window() call path to have division by 0 issue.
So this patch initializes rcv_mss to TCP_MIN_MSS instead of 0.
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Wei Wang <weiwan@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Roger Pau Monne [Tue, 18 Jul 2017 14:01:00 +0000 (15:01 +0100)]
xen: fix bio vec merging
commit
462cdace790ac2ed6aad1b19c9c0af0143b6aab0 upstream.
The current test for bio vec merging is not fully accurate and can be
tricked into merging bios when certain grant combinations are used.
The result of these malicious bio merges is a bio that extends past
the memory page used by any of the originating bios.
Take into account the following scenario, where a guest creates two
grant references that point to the same mfn, ie: grant 1 -> mfn A,
grant 2 -> mfn A.
These references are then used in a PV block request, and mapped by
the backend domain, thus obtaining two different pfns that point to
the same mfn, pfn B -> mfn A, pfn C -> mfn A.
If those grants happen to be used in two consecutive sectors of a disk
IO operation becoming two different bios in the backend domain, the
checks in xen_biovec_phys_mergeable will succeed, because bfn1 == bfn2
(they both point to the same mfn). However due to the bio merging,
the backend domain will end up with a bio that expands past mfn A into
mfn A + 1.
Fix this by making sure the check in xen_biovec_phys_mergeable takes
into account the offset and the length of the bio, this basically
replicates whats done in __BIOVEC_PHYS_MERGEABLE using mfns (bus
addresses). While there also remove the usage of
__BIOVEC_PHYS_MERGEABLE, since that's already checked by the callers
of xen_biovec_phys_mergeable.
Reported-by: "Jan H. Schönherr" <jschoenh@amazon.de>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
[bwh: Backported to 3.16:
- s/bfn/mfn/g
- Adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
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: Ben Hutchings <ben@decadent.org.uk>
Arend van Spriel [Fri, 7 Jul 2017 20:09:06 +0000 (21:09 +0100)]
brcmfmac: fix possible buffer overflow in brcmf_cfg80211_mgmt_tx()
commit
8f44c9a41386729fea410e688959ddaa9d51be7c upstream.
The lower level nl80211 code in cfg80211 ensures that "len" is between
25 and NL80211_ATTR_FRAME (2304). We subtract DOT11_MGMT_HDR_LEN (24) from
"len" so thats's max of 2280. However, the action_frame->data[] buffer is
only BRCMF_FIL_ACTION_FRAME_SIZE (1800) bytes long so this memcpy() can
overflow.
memcpy(action_frame->data, &buf[DOT11_MGMT_HDR_LEN],
le16_to_cpu(action_frame->len));
Fixes: 18e2f61db3b70 ("brcmfmac: P2P action frame tx.")
Reported-by: "freenerguo(郭大兴)" <freenerguo@tencent.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[bwh: Backported to 3.16: adjust filename]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Jann Horn [Wed, 20 Jan 2016 23:00:04 +0000 (15:00 -0800)]
ptrace: use fsuid, fsgid, effective creds for fs access checks
commit
caaee6234d05a58c5b4d05e7bf766131b810a657 upstream.
By checking the effective credentials instead of the real UID / permitted
capabilities, ensure that the calling process actually intended to use its
credentials.
To ensure that all ptrace checks use the correct caller credentials (e.g.
in case out-of-tree code or newly added code omits the PTRACE_MODE_*CREDS
flag), use two new flags and require one of them to be set.
The problem was that when a privileged task had temporarily dropped its
privileges, e.g. by calling setreuid(0, user_uid), with the intent to
perform following syscalls with the credentials of a user, it still passed
ptrace access checks that the user would not be able to pass.
While an attacker should not be able to convince the privileged task to
perform a ptrace() syscall, this is a problem because the ptrace access
check is reused for things in procfs.
In particular, the following somewhat interesting procfs entries only rely
on ptrace access checks:
/proc/$pid/stat - uses the check for determining whether pointers
should be visible, useful for bypassing ASLR
/proc/$pid/maps - also useful for bypassing ASLR
/proc/$pid/cwd - useful for gaining access to restricted
directories that contain files with lax permissions, e.g. in
this scenario:
lrwxrwxrwx root root /proc/13020/cwd -> /root/foobar
drwx------ root root /root
drwxr-xr-x root root /root/foobar
-rw-r--r-- root root /root/foobar/secret
Therefore, on a system where a root-owned mode 6755 binary changes its
effective credentials as described and then dumps a user-specified file,
this could be used by an attacker to reveal the memory layout of root's
processes or reveal the contents of files he is not allowed to access
(through /proc/$pid/cwd).
[akpm@linux-foundation.org: fix warning]
Signed-off-by: Jann Horn <jann@thejh.net>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: Casey Schaufler <casey@schaufler-ca.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: James Morris <james.l.morris@oracle.com>
Cc: "Serge E. Hallyn" <serge.hallyn@ubuntu.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Willy Tarreau <w@1wt.eu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[bwh: Backported to 3.16:
- Update mm_access() calls in fs/proc/task_{,no}mmu.c too
- Adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Sabrina Dubroca [Thu, 22 Jun 2017 09:24:42 +0000 (11:24 +0200)]
tracing/kprobes: Allow to create probe with a module name starting with a digit
commit
9e52b32567126fe146f198971364f68d3bc5233f upstream.
Always try to parse an address, since kstrtoul() will safely fail when
given a symbol as input. If that fails (which will be the case for a
symbol), try to parse a symbol instead.
This allows creating a probe such as:
p:probe/vlan_gro_receive 8021q:vlan_gro_receive+0
Which is necessary for this command to work:
perf probe -m 8021q -a vlan_gro_receive
Link: http://lkml.kernel.org/r/fd72d666f45b114e2c5b9cf7e27b91de1ec966f1.1498122881.git.sd@queasysnail.net
Fixes: 413d37d1e ("tracing: Add kprobe-based event tracer")
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
[bwh: Backported to 3.16: preserve the check that an addresses isn't used for
a kretprobe]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
James Hogan [Thu, 29 Jun 2017 14:05:04 +0000 (15:05 +0100)]
MIPS: Avoid accidental raw backtrace
commit
854236363370995a609a10b03e35fd3dc5e9e4a1 upstream.
Since commit
81a76d7119f6 ("MIPS: Avoid using unwind_stack() with
usermode") show_backtrace() invokes the raw backtracer when
cp0_status & ST0_KSU indicates user mode to fix issues on EVA kernels
where user and kernel address spaces overlap.
However this is used by show_stack() which creates its own pt_regs on
the stack and leaves cp0_status uninitialised in most of the code paths.
This results in the non deterministic use of the raw back tracer
depending on the previous stack content.
show_stack() deals exclusively with kernel mode stacks anyway, so
explicitly initialise regs.cp0_status to KSU_KERNEL (i.e. 0) to ensure
we get a useful backtrace.
Fixes: 81a76d7119f6 ("MIPS: Avoid using unwind_stack() with usermode")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/16656/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Paul Burton [Fri, 3 Mar 2017 23:26:05 +0000 (15:26 -0800)]
MIPS: Fix IRQ tracing & lockdep when rescheduling
commit
d8550860d910c6b7b70f830f59003b33daaa52c9 upstream.
When the scheduler sets TIF_NEED_RESCHED & we call into the scheduler
from arch/mips/kernel/entry.S we disable interrupts. This is true
regardless of whether we reach work_resched from syscall_exit_work,
resume_userspace or by looping after calling schedule(). Although we
disable interrupts in these paths we don't call trace_hardirqs_off()
before calling into C code which may acquire locks, and we therefore
leave lockdep with an inconsistent view of whether interrupts are
disabled or not when CONFIG_PROVE_LOCKING & CONFIG_DEBUG_LOCKDEP are
both enabled.
Without tracing this interrupt state lockdep will print warnings such
as the following once a task returns from a syscall via
syscall_exit_partial with TIF_NEED_RESCHED set:
[ 49.927678] ------------[ cut here ]------------
[ 49.934445] WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:3687 check_flags.part.41+0x1dc/0x1e8
[ 49.946031] DEBUG_LOCKS_WARN_ON(current->hardirqs_enabled)
[ 49.946355] CPU: 0 PID: 1 Comm: init Not tainted
4.10.0-00439-gc9fd5d362289-dirty #197
[ 49.963505] Stack :
0000000000000000 ffffffff81bb5d6a 0000000000000006 ffffffff801ce9c4
[ 49.974431]
0000000000000000 0000000000000000 0000000000000000 000000000000004a
[ 49.985300]
ffffffff80b7e487 ffffffff80a24498 a8000000ff160000 ffffffff80ede8b8
[ 49.996194]
0000000000000001 0000000000000000 0000000000000000 0000000077c8030c
[ 50.007063]
000000007fd8a510 ffffffff801cd45c 0000000000000000 a8000000ff127c88
[ 50.017945]
0000000000000000 ffffffff801cf928 0000000000000001 ffffffff80a24498
[ 50.028827]
0000000000000000 0000000000000001 0000000000000000 0000000000000000
[ 50.039688]
0000000000000000 a8000000ff127bd0 0000000000000000 ffffffff805509bc
[ 50.050575]
00000000140084e0 0000000000000000 0000000000000000 0000000000040a00
[ 50.061448]
0000000000000000 ffffffff8010e1b0 0000000000000000 ffffffff805509bc
[ 50.072327] ...
[ 50.076087] Call Trace:
[ 50.079869] [<
ffffffff8010e1b0>] show_stack+0x80/0xa8
[ 50.086577] [<
ffffffff805509bc>] dump_stack+0x10c/0x190
[ 50.093498] [<
ffffffff8015dde0>] __warn+0xf0/0x108
[ 50.099889] [<
ffffffff8015de34>] warn_slowpath_fmt+0x3c/0x48
[ 50.107241] [<
ffffffff801c15b4>] check_flags.part.41+0x1dc/0x1e8
[ 50.114961] [<
ffffffff801c239c>] lock_is_held_type+0x8c/0xb0
[ 50.122291] [<
ffffffff809461b8>] __schedule+0x8c0/0x10f8
[ 50.129221] [<
ffffffff80946a60>] schedule+0x30/0x98
[ 50.135659] [<
ffffffff80106278>] work_resched+0x8/0x34
[ 50.142397] ---[ end trace
0cb4f6ef5b99fe21 ]---
[ 50.148405] possible reason: unannotated irqs-off.
[ 50.154600] irq event stamp: 400463
[ 50.159566] hardirqs last enabled at (400463): [<
ffffffff8094edc8>] _raw_spin_unlock_irqrestore+0x40/0xa8
[ 50.171981] hardirqs last disabled at (400462): [<
ffffffff8094eb98>] _raw_spin_lock_irqsave+0x30/0xb0
[ 50.183897] softirqs last enabled at (400450): [<
ffffffff8016580c>] __do_softirq+0x4ac/0x6a8
[ 50.195015] softirqs last disabled at (400425): [<
ffffffff80165e78>] irq_exit+0x110/0x128
Fix this by using the TRACE_IRQS_OFF macro to call trace_hardirqs_off()
when CONFIG_TRACE_IRQFLAGS is enabled. This is done before invoking
schedule() following the work_resched label because:
1) Interrupts are disabled regardless of the path we take to reach
work_resched() & schedule().
2) Performing the tracing here avoids the need to do it in paths which
disable interrupts but don't call out to C code before hitting a
path which uses the RESTORE_SOME macro that will call
trace_hardirqs_on() or trace_hardirqs_off() as appropriate.
We call trace_hardirqs_on() using the TRACE_IRQS_ON macro before calling
syscall_trace_leave() for similar reasons, ensuring that lockdep has a
consistent view of state after we re-enable interrupts.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/15385/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Paul Burton [Thu, 2 Mar 2017 22:02:40 +0000 (14:02 -0800)]
MIPS: pm-cps: Drop manual cache-line alignment of ready_count
commit
161c51ccb7a6faf45ffe09aa5cf1ad85ccdad503 upstream.
We allocate memory for a ready_count variable per-CPU, which is accessed
via a cached non-coherent TLB mapping to perform synchronisation between
threads within the core using LL/SC instructions. In order to ensure
that the variable is contained within its own data cache line we
allocate 2 lines worth of memory & align the resulting pointer to a line
boundary. This is however unnecessary, since kmalloc is guaranteed to
return memory which is at least cache-line aligned (see
ARCH_DMA_MINALIGN). Stop the redundant manual alignment.
Besides cleaning up the code & avoiding needless work, this has the side
effect of avoiding an arithmetic error found by Bryan on 64 bit systems
due to the 32 bit size of the former dlinesz. This led the ready_count
variable to have its upper 32b cleared erroneously for MIPS64 kernels,
causing problems when ready_count was later used on MIPS64 via cpuidle.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Fixes: 3179d37ee1ed ("MIPS: pm-cps: add PM state entry code for CPS systems")
Reported-by: Bryan O'Donoghue <bryan.odonoghue@imgtec.com>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@imgtec.com>
Tested-by: Bryan O'Donoghue <bryan.odonoghue@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/15383/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Doug Berger [Thu, 29 Jun 2017 17:41:36 +0000 (18:41 +0100)]
ARM: 8685/1: ensure memblock-limit is pmd-aligned
commit
9e25ebfe56ece7541cd10a20d715cbdd148a2e06 upstream.
The pmd containing memblock_limit is cleared by prepare_page_table()
which creates the opportunity for early_alloc() to allocate unmapped
memory if memblock_limit is not pmd aligned causing a boot-time hang.
Commit
965278dcb8ab ("ARM: 8356/1: mm: handle non-pmd-aligned end of RAM")
attempted to resolve this problem, but there is a path through the
adjust_lowmem_bounds() routine where if all memory regions start and
end on pmd-aligned addresses the memblock_limit will be set to
arm_lowmem_limit.
Since arm_lowmem_limit can be affected by the vmalloc early parameter,
the value of arm_lowmem_limit may not be pmd-aligned. This commit
corrects this oversight such that memblock_limit is always rounded
down to pmd-alignment.
Fixes: 965278dcb8ab ("ARM: 8356/1: mm: handle non-pmd-aligned end of RAM")
Signed-off-by: Doug Berger <opendmb@gmail.com>
Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Michal Kubeček [Thu, 29 Jun 2017 09:13:36 +0000 (11:13 +0200)]
net: handle NAPI_GRO_FREE_STOLEN_HEAD case also in napi_frags_finish()
commit
e44699d2c28067f69698ccb68dd3ddeacfebc434 upstream.
Recently I started seeing warnings about pages with refcount -1. The
problem was traced to packets being reused after their head was merged into
a GRO packet by skb_gro_receive(). While bisecting the issue pointed to
commit
c21b48cc1bbf ("net: adjust skb->truesize in ___pskb_trim()") and
I have never seen it on a kernel with it reverted, I believe the real
problem appeared earlier when the option to merge head frag in GRO was
implemented.
Handling NAPI_GRO_FREE_STOLEN_HEAD state was only added to GRO_MERGED_FREE
branch of napi_skb_finish() so that if the driver uses napi_gro_frags()
and head is merged (which in my case happens after the skb_condense()
call added by the commit mentioned above), the skb is reused including the
head that has been merged. As a result, we release the page reference
twice and eventually end up with negative page refcount.
To fix the problem, handle NAPI_GRO_FREE_STOLEN_HEAD in napi_frags_finish()
the same way it's done in napi_skb_finish().
Fixes: d7e8883cfcf4 ("net: make GRO aware of skb->head_frag")
Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
Signed-off-by: David S. Miller <davem@davemloft.net>
[bwh: Backported to 3.16: The necessary cleanup is just kmem_cache_free(),
so don't bother adding a function for this.]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Hui Wang [Wed, 28 Jun 2017 00:59:16 +0000 (08:59 +0800)]
ALSA: hda - set input_path bitmap to zero after moving it to new place
commit
a8f20fd25bdce81a8e41767c39f456d346b63427 upstream.
Recently we met a problem, the codec has valid adcs and input pins,
and they can form valid input paths, but the driver does not build
valid controls for them like "Mic boost", "Capture Volume" and
"Capture Switch".
Through debugging, I found the driver needs to shrink the invalid
adcs and input paths for this machine, so it will move the whole
column bitmap value to the previous column, after moving it, the
driver forgets to set the original column bitmap value to zero, as a
result, the driver will invalidate the path whose index value is the
original colume bitmap value. After executing this function, all
valid input paths are invalidated by a mistake, there are no any
valid input paths, so the driver won't build controls for them.
Fixes: 3a65bcdc577a ("ALSA: hda - Fix inconsistent input_paths after ADC reduction")
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Eric Dumazet [Tue, 27 Jun 2017 14:02:20 +0000 (07:02 -0700)]
net: prevent sign extension in dev_get_stats()
commit
6f64ec74515925cced6df4571638b5a099a49aae upstream.
Similar to the fix provided by Dominik Heidler in commit
9b3dc0a17d73 ("l2tp: cast l2tp traffic counter to unsigned")
we need to take care of 32bit kernels in dev_get_stats().
When using atomic_long_read(), we add a 'long' to u64 and
might misinterpret high order bit, unless we cast to unsigned.
Fixes: caf586e5f23ce ("net: add a core netdev->rx_dropped counter")
Fixes: 015f0688f57ca ("net: net: add a core netdev->tx_dropped counter")
Fixes: 6e7333d315a76 ("net: add rx_nohandler stat counter")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jarod Wilson <jarod@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[bwh: Backported to 3.16: only {rx,tx}_dropped are updated here]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
WANG Cong [Sun, 25 Jun 2017 06:50:30 +0000 (23:50 -0700)]
tcp: reset sk_rx_dst in tcp_disconnect()
commit
d747a7a51b00984127a88113cdbbc26f91e9d815 upstream.
We have to reset the sk->sk_rx_dst when we disconnect a TCP
connection, because otherwise when we re-connect it this
dst reference is simply overridden in tcp_finish_connect().
This fixes a dst leak which leads to a loopback dev refcnt
leak. It is a long-standing bug, Kevin reported a very similar
(if not same) bug before. Thanks to Andrei for providing such
a reliable reproducer which greatly narrows down the problem.
Fixes: 41063e9dd119 ("ipv4: Early TCP socket demux.")
Reported-by: Andrei Vagin <avagin@gmail.com>
Reported-by: Kevin Xu <kaiwen.xu@hulu.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Ilya Matveychikov [Fri, 23 Jun 2017 22:08:49 +0000 (15:08 -0700)]
lib/cmdline.c: fix get_options() overflow while parsing ranges
commit
a91e0f680bcd9e10c253ae8b62462a38bd48f09f upstream.
When using get_options() it's possible to specify a range of numbers,
like 1-100500. The problem is that it doesn't track array size while
calling internally to get_range() which iterates over the range and
fills the memory with numbers.
Link: http://lkml.kernel.org/r/2613C75C-B04D-4BFF-82A6-12F97BA0F620@gmail.com
Signed-off-by: Ilya V. Matveychikov <matvejchikov@gmail.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
NeilBrown [Fri, 23 Jun 2017 22:08:43 +0000 (15:08 -0700)]
autofs: sanity check status reported with AUTOFS_DEV_IOCTL_FAIL
commit
9fa4eb8e490a28de40964b1b0e583d8db4c7e57c upstream.
If a positive status is passed with the AUTOFS_DEV_IOCTL_FAIL ioctl,
autofs4_d_automount() will return
ERR_PTR(status)
with that status to follow_automount(), which will then dereference an
invalid pointer.
So treat a positive status the same as zero, and map to ENOENT.
See comment in systemd src/core/automount.c::automount_send_ready().
Link: http://lkml.kernel.org/r/871sqwczx5.fsf@notabene.neil.brown.name
Signed-off-by: NeilBrown <neilb@suse.com>
Cc: Ian Kent <raven@themaw.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Richard Cochran [Fri, 23 Jun 2017 15:51:31 +0000 (17:51 +0200)]
net: dp83640: Avoid NULL pointer dereference.
commit
db9d8b29d19d2801793e4419f4c6272bf8951c62 upstream.
The function, skb_complete_tx_timestamp(), used to allow passing in a
NULL pointer for the time stamps, but that was changed in commit
62bccb8cdb69051b95a55ab0c489e3cab261c8ef ("net-timestamp: Make the
clone operation stand-alone from phy timestamping"), and the existing
call sites, all of which are in the dp83640 driver, were fixed up.
Even though the kernel-doc was subsequently updated in commit
7a76a021cd5a292be875fbc616daf03eab1e6996 ("net-timestamp: Update
skb_complete_tx_timestamp comment"), still a bug fix from Manfred
Rudigier came into the driver using the old semantics. Probably
Manfred derived that patch from an older kernel version.
This fix should be applied to the stable trees as well.
Fixes: 81e8f2e930fe ("net: dp83640: Fix tx timestamp overflow handling.")
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Michal Kubeček [Mon, 19 Jun 2017 11:03:43 +0000 (13:03 +0200)]
net: account for current skb length when deciding about UFO
commit
a5cb659bbc1c8644efa0c3138a757a1e432a4880 upstream.
Our customer encountered stuck NFS writes for blocks starting at specific
offsets w.r.t. page boundary caused by networking stack sending packets via
UFO enabled device with wrong checksum. The problem can be reproduced by
composing a long UDP datagram from multiple parts using MSG_MORE flag:
sendto(sd, buff, 1000, MSG_MORE, ...);
sendto(sd, buff, 1000, MSG_MORE, ...);
sendto(sd, buff, 3000, 0, ...);
Assume this packet is to be routed via a device with MTU 1500 and
NETIF_F_UFO enabled. When second sendto() gets into __ip_append_data(),
this condition is tested (among others) to decide whether to call
ip_ufo_append_data():
((length + fragheaderlen) > mtu) || (skb && skb_is_gso(skb))
At the moment, we already have skb with 1028 bytes of data which is not
marked for GSO so that the test is false (fragheaderlen is usually 20).
Thus we append second 1000 bytes to this skb without invoking UFO. Third
sendto(), however, has sufficient length to trigger the UFO path so that we
end up with non-UFO skb followed by a UFO one. Later on, udp_send_skb()
uses udp_csum() to calculate the checksum but that assumes all fragments
have correct checksum in skb->csum which is not true for UFO fragments.
When checking against MTU, we need to add skb->len to length of new segment
if we already have a partially filled skb and fragheaderlen only if there
isn't one.
In the IPv6 case, skb can only be null if this is the first segment so that
we have to use headersize (length of the first IPv6 header) rather than
fragheaderlen (length of IPv6 header of further fragments) for skb == NULL.
Fixes: e89e9cf539a2 ("[IPv4/IPv6]: UFO Scatter-gather approach")
Fixes: e4c5e13aa45c ("ipv6: Should use consistent conditional judgement for
ip6 fragment between __ip6_append_data and ip6_finish_output")
Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
Acked-by: Vlad Yasevich <vyasevic@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[bwh: Backported to 3.16:
- Move headersize out of the if-statement in ip6_append_data() so it can be
used for this
- Adjust context to apply after "udp: consistently apply ufo or fragmentation"]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
zheng li [Mon, 12 Dec 2016 01:56:05 +0000 (09:56 +0800)]
ipv4: Should use consistent conditional judgement for ip fragment in __ip_append_data and ip_finish_output
commit
0a28cfd51e17f4f0a056bcf66bfbe492c3b99f38 upstream.
There is an inconsistent conditional judgement in __ip_append_data and
ip_finish_output functions, the variable length in __ip_append_data just
include the length of application's payload and udp header, don't include
the length of ip header, but in ip_finish_output use
(skb->len > ip_skb_dst_mtu(skb)) as judgement, and skb->len include the
length of ip header.
That causes some particular application's udp payload whose length is
between (MTU - IP Header) and MTU were fragmented by ip_fragment even
though the rst->dev support UFO feature.
Add the length of ip header to length in __ip_append_data to keep
consistent conditional judgement as ip_finish_output for ip fragment.
Signed-off-by: Zheng Li <james.z.li@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[bwh: Backported to 3.16: adjust context to apply after "udp: consistently apply
ufo or fragmentation"]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Nicholas Piggin [Wed, 21 Jun 2017 05:58:29 +0000 (15:58 +1000)]
powerpc/64: Initialise thread_info for emergency stacks
commit
34f19ff1b5a0d11e46df479623d6936460105c9f upstream.
Emergency stacks have their thread_info mostly uninitialised, which in
particular means garbage preempt_count values.
Emergency stack code runs with interrupts disabled entirely, and is
used very rarely, so this has been unnoticed so far. It was found by a
proposed new powerpc watchdog that takes a soft-NMI directly from the
masked_interrupt handler and using the emergency stack. That crashed
at BUG_ON(in_nmi()) in nmi_enter(). preempt_count()s were found to be
garbage.
To fix this, zero the entire THREAD_SIZE allocation, and initialize
the thread_info.
Reported-by: Abdul Haleem <abdhalee@linux.vnet.ibm.com>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
[mpe: Move it all into setup_64.c, use a function not a macro. Fix
crashes on Cell by setting preempt_count to 0 not HARDIRQ_OFFSET]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
[bwh: Backported to 3.16:
- There are only two emergency stacks
- No need to call klp_init_thread_info()
- Add the ti variable in emergency_stack_init()]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
WANG Cong [Wed, 21 Jun 2017 21:34:58 +0000 (14:34 -0700)]
ipv6: avoid unregistering inet6_dev for loopback
commit
60abc0be96e00ca71bac083215ac91ad2e575096 upstream.
The per netns loopback_dev->ip6_ptr is unregistered and set to
NULL when its mtu is set to smaller than IPV6_MIN_MTU, this
leads to that we could set rt->rt6i_idev NULL after a
rt6_uncached_list_flush_dev() and then crash after another
call.
In this case we should just bring its inet6_dev down, rather
than unregistering it, at least prior to commit
176c39af29bc
("netns: fix addrconf_ifdown kernel panic") we always
override the case for loopback.
Thanks a lot to Andrey for finding a reliable reproducer.
Fixes: 176c39af29bc ("netns: fix addrconf_ifdown kernel panic")
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Cc: Andrey Konovalov <andreyknvl@google.com>
Cc: Daniel Lezcano <dlezcano@fr.ibm.com>
Cc: David Ahern <dsahern@gmail.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Acked-by: David Ahern <dsahern@gmail.com>
Tested-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[bwh: Backported to 3.16: the NETDEV_CHANGEMTU case used to fall-through to the
NETDEV_DOWN case here, so replace that with a separate call to addrconf_ifdown()]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
WANG Cong [Tue, 20 Jun 2017 18:42:27 +0000 (11:42 -0700)]
ipv6: only call ip6_route_dev_notify() once for NETDEV_UNREGISTER
commit
76da0704507bbc51875013f6557877ab308cfd0a upstream.
In commit
242d3a49a2a1 ("ipv6: reorder ip6_route_dev_notifier after ipv6_dev_notf")
I assumed NETDEV_REGISTER and NETDEV_UNREGISTER are paired,
unfortunately, as reported by jeffy, netdev_wait_allrefs()
could rebroadcast NETDEV_UNREGISTER event until all refs are
gone.
We have to add an additional check to avoid this corner case.
For netdev_wait_allrefs() dev->reg_state is NETREG_UNREGISTERED,
for dev_change_net_namespace(), dev->reg_state is
NETREG_REGISTERED. So check for dev->reg_state != NETREG_UNREGISTERED.
Fixes: 242d3a49a2a1 ("ipv6: reorder ip6_route_dev_notifier after ipv6_dev_notf")
Reported-by: jeffy <jeffy.chen@rock-chips.com>
Cc: David Ahern <dsahern@gmail.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Acked-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
WANG Cong [Mon, 8 May 2017 17:12:13 +0000 (10:12 -0700)]
ipv6: reorder ip6_route_dev_notifier after ipv6_dev_notf
commit
242d3a49a2a1a71d8eb9f953db1bcaa9d698ce00 upstream.
For each netns (except init_net), we initialize its null entry
in 3 places:
1) The template itself, as we use kmemdup()
2) Code around dst_init_metrics() in ip6_route_net_init()
3) ip6_route_dev_notify(), which is supposed to initialize it after
loopback registers
Unfortunately the last one still happens in a wrong order because
we expect to initialize net->ipv6.ip6_null_entry->rt6i_idev to
net->loopback_dev's idev, thus we have to do that after we add
idev to loopback. However, this notifier has priority == 0 same as
ipv6_dev_notf, and ipv6_dev_notf is registered after
ip6_route_dev_notifier so it is called actually after
ip6_route_dev_notifier. This is similar to commit
2f460933f58e
("ipv6: initialize route null entry in addrconf_init()") which
fixes init_net.
Fix it by picking a smaller priority for ip6_route_dev_notifier.
Also, we have to release the refcnt accordingly when unregistering
loopback_dev because device exit functions are called before subsys
exit functions.
Acked-by: David Ahern <dsahern@gmail.com>
Tested-by: David Ahern <dsahern@gmail.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
WANG Cong [Thu, 4 May 2017 05:07:31 +0000 (22:07 -0700)]
ipv6: initialize route null entry in addrconf_init()
commit
2f460933f58eee3393aba64f0f6d14acb08d1724 upstream.
Andrey reported a crash on init_net.ipv6.ip6_null_entry->rt6i_idev
since it is always NULL.
This is clearly wrong, we have code to initialize it to loopback_dev,
unfortunately the order is still not correct.
loopback_dev is registered very early during boot, we lose a chance
to re-initialize it in notifier. addrconf_init() is called after
ip6_route_init(), which means we have no chance to correct it.
Fix it by moving this initialization explicitly after
ipv6_add_dev(init_net.loopback_dev) in addrconf_init().
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Tested-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Michail Georgios Etairidis [Tue, 20 Jun 2017 08:20:42 +0000 (10:20 +0200)]
i2c: imx: Use correct function to write to register
commit
6c782a5ea56a799658e213a78dc1455264938afa upstream.
The i2c-imx driver incorrectly uses readb()/writeb() to read and
write to the appropriate registers when performing a repeated start.
The appropriate imx_i2c_read_reg()/imx_i2c_write_reg() functions
should be used instead. Performing a repeated start results in
a kernel panic. The platform is imx.
Signed-off-by: Michail G Etairidis <m.etairidis@beck-ipc.com>
Fixes: ce1a78840ff7 ("i2c: imx: add DMA support for freescale i2c driver")
Fixes: 054b62d9f25c ("i2c: imx: fix the i2c bus hang issue when do repeat restart")
Acked-by: Fugang Duan <fugang.duan@nxp.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
[bwh: Backported to 3.16: drop changes in i2c_imx_dma_read()]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Pavel Shilovsky [Tue, 6 Jun 2017 23:58:58 +0000 (16:58 -0700)]
CIFS: Improve readdir verbosity
commit
dcd87838c06f05ab7650b249ebf0d5b57ae63e1e upstream.
Downgrade the loglevel for SMB2 to prevent filling the log
with messages if e.g. readdir was interrupted. Also make SMB2
and SMB1 codepaths do the same logging during readdir.
Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
Signed-off-by: Steve French <smfrench@gmail.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Serhey Popovych [Tue, 20 Jun 2017 11:35:23 +0000 (14:35 +0300)]
rtnetlink: add IFLA_GROUP to ifla_policy
commit
db833d40ad3263b2ee3b59a1ba168bb3cfed8137 upstream.
Network interface groups support added while ago, however
there is no IFLA_GROUP attribute description in policy
and netlink message size calculations until now.
Add IFLA_GROUP attribute to the policy.
Fixes: cbda10fa97d7 ("net_device: add support for network device groups")
Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Serhey Popovych [Tue, 20 Jun 2017 10:29:25 +0000 (13:29 +0300)]
ipv6: Do not leak throw route references
commit
07f615574f8ac499875b21c1142f26308234a92c upstream.
While commit
73ba57bfae4a ("ipv6: fix backtracking for throw routes")
does good job on error propagation to the fib_rules_lookup()
in fib rules core framework that also corrects throw routes
handling, it does not solve route reference leakage problem
happened when we return -EAGAIN to the fib_rules_lookup()
and leave routing table entry referenced in arg->result.
If rule with matched throw route isn't last matched in the
list we overwrite arg->result losing reference on throw
route stored previously forever.
We also partially revert commit
ab997ad40839 ("ipv6: fix the
incorrect return value of throw route") since we never return
routing table entry with dst.error == -EAGAIN when
CONFIG_IPV6_MULTIPLE_TABLES is on. Also there is no point
to check for RTF_REJECT flag since it is always set throw
route.
Fixes: 73ba57bfae4a ("ipv6: fix backtracking for throw routes")
Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[bwh: Backported to 3.16: commit
ab997ad40839 was never applied here and does
not need to be reverted]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Alex Deucher [Mon, 19 Jun 2017 19:59:58 +0000 (15:59 -0400)]
drm/radeon: add a quirk for Toshiba Satellite L20-183
commit
acfd6ee4fa7ebeee75511825fe02be3f7ac1d668 upstream.
Fixes resume from suspend.
bug: https://bugzilla.kernel.org/show_bug.cgi?id=196121
Reported-by: Przemek <soprwa@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Alex Deucher [Mon, 19 Jun 2017 16:52:47 +0000 (12:52 -0400)]
drm/radeon: add a PX quirk for another K53TK variant
commit
4eb59793cca00b0e629b6d55b5abb5acb82c5868 upstream.
Disable PX on these systems.
bug: https://bugs.freedesktop.org/show_bug.cgi?id=101491
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Daniel Drake [Tue, 20 Jun 2017 02:48:52 +0000 (19:48 -0700)]
Input: i8042 - add Fujitsu Lifebook AH544 to notimeout list
commit
817ae460c784f32cd45e60b2b1b21378c3c6a847 upstream.
Without this quirk, the touchpad is not responsive on this product, with
the following message repeated in the logs:
psmouse serio1: bad data from KBC - timeout
Add it to the notimeout list alongside other similar Fujitsu laptops.
Signed-off-by: Daniel Drake <drake@endlessm.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Eric W. Biederman [Tue, 13 Jun 2017 09:31:16 +0000 (04:31 -0500)]
signal: Only reschedule timers on signals timers have sent
commit
57db7e4a2d92c2d3dfbca4ef8057849b2682436b upstream.
Thomas Gleixner wrote:
> The CRIU support added a 'feature' which allows a user space task to send
> arbitrary (kernel) signals to itself. The changelog says:
>
> The kernel prevents sending of siginfo with positive si_code, because
> these codes are reserved for kernel. I think we can allow a task to
> send such a siginfo to itself. This operation should not be dangerous.
>
> Quite contrary to that claim, it turns out that it is outright dangerous
> for signals with info->si_code == SI_TIMER. The following code sequence in
> a user space task allows to crash the kernel:
>
> id = timer_create(CLOCK_XXX, ..... signo = SIGX);
> timer_set(id, ....);
> info->si_signo = SIGX;
> info->si_code = SI_TIMER:
> info->_sifields._timer._tid = id;
> info->_sifields._timer._sys_private = 2;
> rt_[tg]sigqueueinfo(..., SIGX, info);
> sigemptyset(&sigset);
> sigaddset(&sigset, SIGX);
> rt_sigtimedwait(sigset, info);
>
> For timers based on CLOCK_PROCESS_CPUTIME_ID, CLOCK_THREAD_CPUTIME_ID this
> results in a kernel crash because sigwait() dequeues the signal and the
> dequeue code observes:
>
> info->si_code == SI_TIMER && info->_sifields._timer._sys_private != 0
>
> which triggers the following callchain:
>
> do_schedule_next_timer() -> posix_cpu_timer_schedule() -> arm_timer()
>
> arm_timer() executes a list_add() on the timer, which is already armed via
> the timer_set() syscall. That's a double list add which corrupts the posix
> cpu timer list. As a consequence the kernel crashes on the next operation
> touching the posix cpu timer list.
>
> Posix clocks which are internally implemented based on hrtimers are not
> affected by this because hrtimer_start() can handle already armed timers
> nicely, but it's a reliable way to trigger the WARN_ON() in
> hrtimer_forward(), which complains about calling that function on an
> already armed timer.
This problem has existed since the posix timer code was merged into
2.5.63. A few releases earlier in 2.5.60 ptrace gained the ability to
inject not just a signal (which linux has supported since 1.0) but the
full siginfo of a signal.
The core problem is that the code will reschedule in response to
signals getting dequeued not just for signals the timers sent but
for other signals that happen to a si_code of SI_TIMER.
Avoid this confusion by testing to see if the queued signal was
preallocated as all timer signals are preallocated, and so far
only the timer code preallocates signals.
Move the check for if a timer needs to be rescheduled up into
collect_signal where the preallocation check must be performed,
and pass the result back to dequeue_signal where the code reschedules
timers. This makes it clear why the code cares about preallocated
timers.
Reported-by: Thomas Gleixner <tglx@linutronix.de>
History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
Reference:
66dd34ad31e5 ("signal: allow to send any siginfo to itself")
Reference:
1669ce53e2ff ("Add PTRACE_GETSIGINFO and PTRACE_SETSIGINFO")
Fixes: db8b50ba75f2 ("[PATCH] POSIX clocks & timers")
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Mark Rutland [Fri, 16 Jun 2017 21:02:34 +0000 (14:02 -0700)]
mm: numa: avoid waiting on freed migrated pages
commit
3c226c637b69104f6b9f1c6ec5b08d7b741b3229 upstream.
In do_huge_pmd_numa_page(), we attempt to handle a migrating thp pmd by
waiting until the pmd is unlocked before we return and retry. However,
we can race with migrate_misplaced_transhuge_page():
// do_huge_pmd_numa_page // migrate_misplaced_transhuge_page()
// Holds 0 refs on page // Holds 2 refs on page
vmf->ptl = pmd_lock(vma->vm_mm, vmf->pmd);
/* ... */
if (pmd_trans_migrating(*vmf->pmd)) {
page = pmd_page(*vmf->pmd);
spin_unlock(vmf->ptl);
ptl = pmd_lock(mm, pmd);
if (page_count(page) != 2)) {
/* roll back */
}
/* ... */
mlock_migrate_page(new_page, page);
/* ... */
spin_unlock(ptl);
put_page(page);
put_page(page); // page freed here
wait_on_page_locked(page);
goto out;
}
This can result in the freed page having its waiters flag set
unexpectedly, which trips the PAGE_FLAGS_CHECK_AT_PREP checks in the
page alloc/free functions. This has been observed on arm64 KVM guests.
We can avoid this by having do_huge_pmd_numa_page() take a reference on
the page before dropping the pmd lock, mirroring what we do in
__migration_entry_wait().
When we hit the race, migrate_misplaced_transhuge_page() will see the
reference and abort the migration, as it may do today in other cases.
Fixes: b8916634b77bffb2 ("mm: Prevent parallel splits during THP migration")
Link: http://lkml.kernel.org/r/1497349722-6731-2-git-send-email-will.deacon@arm.com
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Acked-by: Steve Capper <steve.capper@arm.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Mel Gorman <mgorman@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Yu Zhao [Fri, 16 Jun 2017 21:02:31 +0000 (14:02 -0700)]
swap: cond_resched in swap_cgroup_prepare()
commit
ef70762948dde012146926720b70e79736336764 upstream.
I saw need_resched() warnings when swapping on large swapfile (TBs)
because continuously allocating many pages in swap_cgroup_prepare() took
too long.
We already cond_resched when freeing page in swap_cgroup_swapoff(). Do
the same for the page allocation.
Link: http://lkml.kernel.org/r/20170604200109.17606-1-yuzhao@google.com
Signed-off-by: Yu Zhao <yuzhao@google.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Vladimir Davydov <vdavydov.dev@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[bwh: Backported to 3.16: adjust filename]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
James Morse [Fri, 16 Jun 2017 21:02:29 +0000 (14:02 -0700)]
mm/memory-failure.c: use compound_head() flags for huge pages
commit
7258ae5c5a2ce2f5969e8b18b881be40ab55433d upstream.
memory_failure() chooses a recovery action function based on the page
flags. For huge pages it uses the tail page flags which don't have
anything interesting set, resulting in:
> Memory failure: 0x9be3b4: Unknown page state
> Memory failure: 0x9be3b4: recovery action for unknown page: Failed
Instead, save a copy of the head page's flags if this is a huge page,
this means if there are no relevant flags for this tail page, we use the
head pages flags instead. This results in the me_huge_page() recovery
action being called:
> Memory failure: 0x9b7969: recovery action for huge page: Delayed
For hugepages that have not yet been allocated, this allows the hugepage
to be dequeued.
Fixes: 524fca1e7356 ("HWPOISON: fix misjudgement of page_action() for errors on mlocked pages")
Link: http://lkml.kernel.org/r/20170524130204.21845-1-james.morse@arm.com
Signed-off-by: James Morse <james.morse@arm.com>
Tested-by: Punit Agrawal <punit.agrawal@arm.com>
Acked-by: Punit Agrawal <punit.agrawal@arm.com>
Acked-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Naveen N. Rao [Thu, 1 Jun 2017 10:48:15 +0000 (16:18 +0530)]
powerpc/kprobes: Pause function_graph tracing during jprobes handling
commit
a9f8553e935f26cb5447f67e280946b0923cd2dc upstream.
This fixes a crash when function_graph and jprobes are used together.
This is essentially commit
237d28db036e ("ftrace/jprobes/x86: Fix
conflict between jprobes and function graph tracing"), but for powerpc.
Jprobes breaks function_graph tracing since the jprobe hook needs to use
jprobe_return(), which never returns back to the hook, but instead to
the original jprobe'd function. The solution is to momentarily pause
function_graph tracing before invoking the jprobe hook and re-enable it
when returning back to the original jprobe'd function.
Fixes: 6794c78243bf ("powerpc64: port of the function graph tracer")
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Liwei Song [Tue, 13 Jun 2017 04:59:53 +0000 (00:59 -0400)]
i2c: ismt: fix wrong device address when unmap the data buffer
commit
17e83549e199d89aace7788a9f11c108671eecf5 upstream.
Fix the following kernel bug:
kernel BUG at drivers/iommu/intel-iommu.c:3260!
invalid opcode: 0000 [#5] PREEMPT SMP
Hardware name: Intel Corp. Harcuvar/Server, BIOS HAVLCRB0.X64.0013.D39.
1608311820 08/31/2016
task:
ffff880175389950 ti:
ffff880176bec000 task.ti:
ffff880176bec000
RIP: 0010:[<
ffffffff8150a83b>] [<
ffffffff8150a83b>] intel_unmap+0x25b/0x260
RSP: 0018:
ffff880176bef5e8 EFLAGS:
00010296
RAX:
0000000000000024 RBX:
ffff8800773c7c88 RCX:
000000000000ce04
RDX:
0000000080000000 RSI:
0000000000000000 RDI:
0000000000000009
RBP:
ffff880176bef638 R08:
0000000000000010 R09:
0000000000000004
R10:
ffff880175389c78 R11:
0000000000000a4f R12:
ffff8800773c7868
R13:
00000000ffffac88 R14:
ffff8800773c7818 R15:
0000000000000001
FS:
00007fef21258700(0000) GS:
ffff88017b5c0000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
000000000066d6d8 CR3:
000000007118c000 CR4:
00000000003406e0
Stack:
00000000ffffac88 ffffffff8199867f ffff880176bef5f8 ffff880100000030
ffff880176bef668 ffff8800773c7c88 ffff880178288098 ffff8800772c0010
ffff8800773c7818 0000000000000001 ffff880176bef648 ffffffff8150a86e
Call Trace:
[<
ffffffff8199867f>] ? printk+0x46/0x48
[<
ffffffff8150a86e>] intel_unmap_page+0xe/0x10
[<
ffffffffa039d99b>] ismt_access+0x27b/0x8fa [i2c_ismt]
[<
ffffffff81554420>] ? __pm_runtime_suspend+0xa0/0xa0
[<
ffffffff815544a0>] ? pm_suspend_timer_fn+0x80/0x80
[<
ffffffff81554420>] ? __pm_runtime_suspend+0xa0/0xa0
[<
ffffffff815544a0>] ? pm_suspend_timer_fn+0x80/0x80
[<
ffffffff8143dfd0>] ? pci_bus_read_dev_vendor_id+0xf0/0xf0
[<
ffffffff8172b36c>] i2c_smbus_xfer+0xec/0x4b0
[<
ffffffff810aa4d5>] ? vprintk_emit+0x345/0x530
[<
ffffffffa038936b>] i2cdev_ioctl_smbus+0x12b/0x240 [i2c_dev]
[<
ffffffff810aa829>] ? vprintk_default+0x29/0x40
[<
ffffffffa0389b33>] i2cdev_ioctl+0x63/0x1ec [i2c_dev]
[<
ffffffff811b04c8>] do_vfs_ioctl+0x328/0x5d0
[<
ffffffff8119d8ec>] ? vfs_write+0x11c/0x190
[<
ffffffff8109d449>] ? rt_up_read+0x19/0x20
[<
ffffffff811b07f1>] SyS_ioctl+0x81/0xa0
[<
ffffffff819a351b>] system_call_fastpath+0x16/0x6e
This happen When run "i2cdetect -y 0" detect SMBus iSMT adapter.
After finished I2C block read/write, when unmap the data buffer,
a wrong device address was pass to dma_unmap_single().
To fix this, give dma_unmap_single() the "dev" parameter, just like
what dma_map_single() does, then unmap can find the right devices.
Fixes: 13f35ac14cd0 ("i2c: Adding support for Intel iSMT SMBus 2.0 host controller")
Signed-off-by: Liwei Song <liwei.song@windriver.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Paul Mackerras [Thu, 15 Jun 2017 06:10:27 +0000 (16:10 +1000)]
KVM: PPC: Book3S HV: Preserve userspace HTM state properly
commit
46a704f8409f79fd66567ad3f8a7304830a84293 upstream.
If userspace attempts to call the KVM_RUN ioctl when it has hardware
transactional memory (HTM) enabled, the values that it has put in the
HTM-related SPRs TFHAR, TFIAR and TEXASR will get overwritten by
guest values. To fix this, we detect this condition and save those
SPR values in the thread struct, and disable HTM for the task. If
userspace goes to access those SPRs or the HTM facility in future,
a TM-unavailable interrupt will occur and the handler will reload
those SPRs and re-enable HTM.
If userspace has started a transaction and suspended it, we would
currently lose the transactional state in the guest entry path and
would almost certainly get a "TM Bad Thing" interrupt, which would
cause the host to crash. To avoid this, we detect this case and
return from the KVM_RUN ioctl with an EINVAL error, with the KVM
exit reason set to KVM_EXIT_FAIL_ENTRY.
Fixes: b005255e12a3 ("KVM: PPC: Book3S HV: Context-switch new POWER8 SPRs", 2014-01-08)
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Feras Daoud [Wed, 14 Jun 2017 06:59:09 +0000 (09:59 +0300)]
IB/ipoib: Fix memory leak in create child syscall
commit
4542d66bb26f2d021c70a78e46f183c6675fc4c9 upstream.
The flow of creating a new child goes through ipoib_vlan_add
which allocates a new interface and checks the rtnl_lock.
If the lock is taken, restart_syscall will be called to restart
the system call again. In this case we are not releasing the
already allocated interface, causing a leak.
Fixes: 9baa0b036410 ("IB/ipoib: Add rtnl_link_ops support")
Signed-off-by: Feras Daoud <ferasda@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Doug Ledford <dledford@redhat.com>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Dan Carpenter [Wed, 14 Jun 2017 10:35:37 +0000 (13:35 +0300)]
xfrm: NULL dereference on allocation failure
commit
e747f64336fc15e1c823344942923195b800aa1e upstream.
The default error code in pfkey_msg2xfrm_state() is -ENOBUFS. We
added a new call to security_xfrm_state_alloc() which sets "err" to zero
so there several places where we can return ERR_PTR(0) if kmalloc()
fails. The caller is expecting error pointers so it leads to a NULL
dereference.
Fixes: df71837d5024 ("[LSM-IPSec]: Security association restriction.")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Dan Carpenter [Wed, 14 Jun 2017 10:34:05 +0000 (13:34 +0300)]
xfrm: Oops on error in pfkey_msg2xfrm_state()
commit
1e3d0c2c70cd3edb5deed186c5f5c75f2b84a633 upstream.
There are some missing error codes here so we accidentally return NULL
instead of an error pointer. It results in a NULL pointer dereference.
Fixes: df71837d5024 ("[LSM-IPSec]: Security association restriction.")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
projects / wrapfs-4.13.y.git / log