Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

For next #1

Merged
merged 36 commits into from
Mar 14, 2016
Merged

For next #1

merged 36 commits into from
Mar 14, 2016

Conversation

bgly
Copy link

@bgly bgly commented Mar 14, 2016

No description provided.

Nicholas Bellinger and others added 30 commits February 27, 2016 14:59
target: Add target_alloc_session() helper function
7861728 
Based on HCH's original patch, this adds a full version to
support percpu-ida tag pre-allocation and callback function
pointer into fabric driver code to complete session setup.

Reported-by: Christoph Hellwig <hch@lst.de>
Cc: Sagi Grimberg <sagig@mellanox.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Andy Grover <agrover@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
target: Convert demo-mode only drivers to target_alloc_session
8b00965 
(Fix possible usb-gadget + tcm-loop make_nexus breakage - Dan Carpenter)

Acked-by: Juergen Gross <jgross@suse.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Chris Boot <bootc@bootc.net>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
vhost/scsi: Convert to target_alloc_session usage
1ccafc1 
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
tcm_qla2xxx: Convert to target_alloc_session usage
910e0c6 
Cc: Himanshu Madhani <himanshu.madhani@qlogic.com>
Cc: Quinn Tran <quinn.tran@qlogic.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
tcm_fc: Convert to target_alloc_session usage
869525a 
Cc: Vasu Dev <vasu.dev@linux.intel.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
ib_srpt: Convert to target_alloc_session usage
d74a601 
Cc: Vu Pham <vu@mellanox.com>
Cc: Sagi Grimberg <sagig@mellanox.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
sbp-target: Conversion to percpu_ida tag pre-allocation
e7741b0 
(Fix sbp_mgt_get_req() IS_ERR failure checking - Dan Carpenter)

Cc: Chris Boot <bootc@bootc.net>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Hannes Reinecke <hare@suse.de>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
sbp-target: Convert to TARGET_SCF_ACK_KREF I/O krefs
a778862 
Cc: Chris Boot <bootc@bootc.net>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Hannes Reinecke <hare@suse.de>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
usb-gadget/tcm: Conversion to percpu_ida tag pre-allocation
1fdf5f7 
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
usb-gadget/tcm: Convert to TARGET_SCF_ACK_KREF I/O krefs
c4468d4 
This patch drops struct usbg_cmd->kref internal kref-erence
usage, for proper TARGET_SCF_ACK_KREF conversion.

Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
xen-scsiback: Convert to percpu_ida tag allocation
194509e 
(Add wrapper for handling pending_req tag failure - Juergen)
(Drop left-over se_cmd memset in scsiback_cmd_exec - Juergen)

Acked-by: Juergen Gross <jgross@suse.com>
Tested-by: Juergen Gross <jgross@suse.com>
Cc: Hannes Reinecke <hare@suse.de>
Cc: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
xen-scsiback: Convert to TARGET_SCF_ACK_KREF I/O krefs
130e8a2 
Acked-by: Juergen Gross <jgross@suse.com>
Tested-by: Juergen Gross <jgross@suse.com>
Cc: Hannes Reinecke <hare@suse.de>
Cc: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
tcm_fc: Convert to TARGET_SCF_ACK_KREF I/O + TMR krefs
c8d336d 
Cc: Vasu Dev <vasu.dev@linux.intel.com>
Cc: Mark Rustad <mark.d.rustad@intel.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
ib_srpt: Convert to percpu_ida tag allocation
1335b45 
Cc: Vu Pham <vu@mellanox.com>
Cc: Sagi Grimberg <sagig@mellanox.com>
Cc: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
qla2xxx: Add DebugFS node for target sess list.
1d5c042 
 #cat  /sys/kernel/debug/qla2xxx/qla2xxx_31/tgt_sess
 qla2xxx_31
 Port ID   Port Name                Handle
 ff:fc:01  21:fd:00:05:33:c7:ec:16  0
 01:0e:00  21:00:00:24:ff:7b:8a:e4  1
 01:0f:00  21:00:00:24:ff:7b:8a:e5  2
 ....

(Drop ->check_initiator_node_acl() parameter usage - nab)

Signed-off-by: Quinn Tran <quinn.tran@qlogic.com>
Signed-off-by: Himanshu Madhani <himanshu.madhani@qlogic.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
@jennyj-mellanox
iser-target: Fix identification of login rx descriptor type
b609cc1 
Once connection request is accepted, one rx descriptor
is posted to receive login request. This descriptor has rx type,
but is outside the main pool of rx descriptors, and thus
was mistreated as tx type.

Signed-off-by: Jenny Derzhavetz <jennyf@mellanox.com>
Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
Cc: stable@vger.kernel.org # v3.10+
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
@jennyj-mellanox
iser-target: Add new state ISER_CONN_BOUND to isert_conn
eb2770e 
We need an indication that isert_conn->iscsi_conn binding has
happened so we'll know not to invoke a connection reinstatement
on an unbound connection which will lead to a bogus isert_conn->conn
dereferece.

Signed-off-by: Jenny Derzhavetz <jennyf@mellanox.com>
Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
Cc: stable@vger.kernel.org # v3.10+
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
@jennyj-mellanox
iser-target: Separate flows for np listeners and connections cma events
cd7f942 
No need to restrict this check to specific events.

Signed-off-by: Jenny Derzhavetz <jennyf@mellanox.com>
Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
Cc: stable@vger.kernel.org # v3.10+
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
@jennyj-mellanox
iser-target: Rework connection termination
ff93150 
When we receive an event that triggers connection termination,
we have a a couple of things we may want to do:
1. In case we are already terminating, bailout early
2. In case we are connected but not bound, disconnect and schedule
   a connection cleanup silently (don't reinstate)
3. In case we are connected and bound, disconnect and reinstate the connection

This rework fixes a bug that was detected against a mis-behaved
initiator which rejected our rdma_cm accept, in this stage the
isert_conn is no bound and reinstate caused a bogus dereference.

What's great about this is that we don't need the
post_recv_buf_count anymore, so get rid of it.

Signed-off-by: Jenny Derzhavetz <jennyf@mellanox.com>
Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
Cc: stable@vger.kernel.org # v3.10+
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
@jennyj-mellanox
iser-target: Remove redundant wait in release_conn
c3d141c 
With current termination flow we call release_conn after completion.

Signed-off-by: Jenny Derzhavetz <jennyf@mellanox.com>
Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
@jennyj-mellanox
iser-target: Remove impossible condition from isert_wait_conn
2e54a93 
We can never get to isert_wait_conn in INIT state anymore, so
get rid of this condition.

Signed-off-by: Jenny Derzhavetz <jennyf@mellanox.com>
Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
iser-target: Remove ISER_RECV_DATA_SEG_LEN
a6324f7 
This is the same as ISCSI_DEF_MAX_RECV_SEG_LEN (and must be the same given
the structure layouts), so just use that constant instead.  This also
allows removing ISER_RX_LOGIN_SIZE in favor of ISER_RX_PAYLOAD_SIZE.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
iser-target: Split and properly type the login buffer
7e2f756 
The login receive buffer is used as a iser_rx_desc, so type it as such
in struct isert_conn and allocate the exactly right space for it.  The
TX buffer is moved to a separate variable and properly sized as well.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
iser-target: Convert to new CQ API
c3ddb7f 
Use the workqueue based CQ type similar to what isert was using previously,
and properly split up the completion handlers.

Note that this also takes special care to handle the magic login WRs
separately, and also renames the submission functions so that it's clear
that they are only to be used for the login buffers.

(Fix up isert_print_wc usage in isert_beacon_done - nab)

Signed-off-by: Christoph Hellwig <hch@lst.de>
[sagig: added iscsi conn reinstatement in non-flush
 error completions and added error completion type print]
Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
iser-target: Kill struct isert_rdma_wr
fd625eb 
There is exactly one instance per struct isert_cmd, so merge the two to
simplify everyones life.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
iser-target: Kill the ->isert_cmd back pointer in struct iser_tx_desc
2866108 
We only use the pointer when processing regular iSER commands, and it then
always points to the struct iser_cmd that contains the TX descriptor.

Remove it and rely on container_of to save a little space and avoid a
pointer that is updated multiple times per processed command.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
target/iblock: pass WRITE_SAME to device if possible
cf12009 
This patch has iblock pass the WRITE_SAME command to
the device for offloading if possible. It is similar to what is
done for UNMAP/discards, except that we export a large max write same
value to the initiator, and then rely on the block layer to
break it up into multiple requests if it cannot fit into one.

v2.

- Drop file backend changes and move helper function to
iblock backend.

Signed-off-by: Mike Christie <mchristi@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
target: Remove enum transport_lunflags_table
0a95b29 
se_dev_entry.lun_flags and se_lun.lun_access are only used for keeping
track of read-write vs. read-only state. Since this is an either/or thing
we can represent it as bool, and remove the unneeded enum
transport_lunflags_table, which is left over from when there were more
flags.

Change code that uses this enum to just use true/false, and make it clear
through variable and param names that true means read-only, false means
read-write.

Signed-off-by: Andy Grover <agrover@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
@yasker
target/user: Use iovec[] to describe continuous area
ba6b96e 
We don't need use one iovec per scatter-gather list entry, since data
area are continuous.

Reviewed-by: Andy Grover <agrover@redhat.com>
Signed-off-by: Sheng Yang <sheng@yasker.org>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
@yasker
target/user: Free data ring in unified function
62e7b25 
Prepare for data_bitmap in the next patch.

Reviewed-by: Andy Grover <agrover@redhat.com>
Signed-off-by: Sheng Yang <sheng@yasker.org>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
bgly pushed a commit that referenced this pull request Aug 18, 2017
@groeck @ksacilotto
usb: hub: Do not attempt to autosuspend disconnected devices
3339589 
BugLink: http://bugs.launchpad.net/bugs/1692900

commit f5cccf4 upstream.

While running a bind/unbind stress test with the dwc3 usb driver on rk3399,
the following crash was observed.

Unable to handle kernel NULL pointer dereference at virtual address 00000218
pgd = ffffffc00165f000
[00000218] *pgd=000000000174f003, *pud=000000000174f003,
				*pmd=0000000001750003, *pte=00e8000001751713
Internal error: Oops: 96000005 [#1] PREEMPT SMP
Modules linked in: uinput uvcvideo videobuf2_vmalloc cmac
ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat rfcomm
xt_mark fuse bridge stp llc zram btusb btrtl btbcm btintel bluetooth
ip6table_filter mwifiex_pcie mwifiex cfg80211 cdc_ether usbnet r8152 mii joydev
snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device ppp_async
ppp_generic slhc tun
CPU: 1 PID: 29814 Comm: kworker/1:1 Not tainted 4.4.52 torvalds#507
Hardware name: Google Kevin (DT)
Workqueue: pm pm_runtime_work
task: ffffffc0ac540000 ti: ffffffc0af4d4000 task.ti: ffffffc0af4d4000
PC is at autosuspend_check+0x74/0x174
LR is at autosuspend_check+0x70/0x174
...
Call trace:
[<ffffffc00080dcc0>] autosuspend_check+0x74/0x174
[<ffffffc000810500>] usb_runtime_idle+0x20/0x40
[<ffffffc000785ae0>] __rpm_callback+0x48/0x7c
[<ffffffc000786af0>] rpm_idle+0x1e8/0x498
[<ffffffc000787cdc>] pm_runtime_work+0x88/0xcc
[<ffffffc000249bb8>] process_one_work+0x390/0x6b8
[<ffffffc00024abcc>] worker_thread+0x480/0x610
[<ffffffc000251a80>] kthread+0x164/0x178
[<ffffffc0002045d0>] ret_from_fork+0x10/0x40

Source:

(gdb) l *0xffffffc00080dcc0
0xffffffc00080dcc0 is in autosuspend_check
(drivers/usb/core/driver.c:1778).
1773		/* We don't need to check interfaces that are
1774		 * disabled for runtime PM.  Either they are unbound
1775		 * or else their drivers don't support autosuspend
1776		 * and so they are permanently active.
1777		 */
1778		if (intf->dev.power.disable_depth)
1779			continue;
1780		if (atomic_read(&intf->dev.power.usage_count) > 0)
1781			return -EBUSY;
1782		w |= intf->needs_remote_wakeup;

Code analysis shows that intf is set to NULL in usb_disable_device() prior
to setting actconfig to NULL. At the same time, usb_runtime_idle() does not
lock the usb device, and neither does any of the functions in the
traceback. This means that there is no protection against a race condition
where usb_disable_device() is removing dev->actconfig->interface[] pointers
while those are being accessed from autosuspend_check().

To solve the problem, synchronize and validate device state between
autosuspend_check() and usb_disconnect().

Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
bgly pushed a commit that referenced this pull request Aug 18, 2017
@ebiggers @ksacilotto
ext4: evict inline data when writing to memory map
64ae35e 
BugLink: http://bugs.launchpad.net/bugs/1692900

commit 7b4cc97 upstream.

Currently the case of writing via mmap to a file with inline data is not
handled.  This is maybe a rare case since it requires a writable memory
map of a very small file, but it is trivial to trigger with on
inline_data filesystem, and it causes the
'BUG_ON(ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA));' in
ext4_writepages() to be hit:

    mkfs.ext4 -O inline_data /dev/vdb
    mount /dev/vdb /mnt
    xfs_io -f /mnt/file \
	-c 'pwrite 0 1' \
	-c 'mmap -w 0 1m' \
	-c 'mwrite 0 1' \
	-c 'fsync'

	kernel BUG at fs/ext4/inode.c:2723!
	invalid opcode: 0000 [#1] SMP
	CPU: 1 PID: 2532 Comm: xfs_io Not tainted 4.11.0-rc1-xfstests-00301-g071d9acf3d1f torvalds#633
	Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-20170228_101828-anatol 04/01/2014
	task: ffff88003d3a8040 task.stack: ffffc90000300000
	RIP: 0010:ext4_writepages+0xc89/0xf8a
	RSP: 0018:ffffc90000303ca0 EFLAGS: 00010283
	RAX: 0000028410000000 RBX: ffff8800383fa3b0 RCX: ffffffff812afcdc
	RDX: 00000a9d00000246 RSI: ffffffff81e660e0 RDI: 0000000000000246
	RBP: ffffc90000303dc0 R08: 0000000000000002 R09: 869618e8f99b4fa5
	R10: 00000000852287a2 R11: 00000000a03b49f4 R12: ffff88003808e698
	R13: 0000000000000000 R14: 7fffffffffffffff R15: 7fffffffffffffff
	FS:  00007fd3e53094c0(0000) GS:ffff88003e400000(0000) knlGS:0000000000000000
	CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
	CR2: 00007fd3e4c51000 CR3: 000000003d554000 CR4: 00000000003406e0
	Call Trace:
	 ? _raw_spin_unlock+0x27/0x2a
	 ? kvm_clock_read+0x1e/0x20
	 do_writepages+0x23/0x2c
	 ? do_writepages+0x23/0x2c
	 __filemap_fdatawrite_range+0x80/0x87
	 filemap_write_and_wait_range+0x67/0x8c
	 ext4_sync_file+0x20e/0x472
	 vfs_fsync_range+0x8e/0x9f
	 ? syscall_trace_enter+0x25b/0x2d0
	 vfs_fsync+0x1c/0x1e
	 do_fsync+0x31/0x4a
	 SyS_fsync+0x10/0x14
	 do_syscall_64+0x69/0x131
	 entry_SYSCALL64_slow_path+0x25/0x25

We could try to be smart and keep the inline data in this case, or at
least support delayed allocation when allocating the block, but these
solutions would be more complicated and don't seem worthwhile given how
rare this case seems to be.  So just fix the bug by calling
ext4_convert_inline_data() when we're asked to make a page writable, so
that any inline data gets evicted, with the block allocated immediately.

Reported-by: Nick Alcock <nick.alcock@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
bgly pushed a commit that referenced this pull request Aug 18, 2017
@qnap-dennisyang @ksacilotto
md: update slab_cache before releasing new stripes when stripes resizing
368c193 
BugLink: http://bugs.launchpad.net/bugs/1694621

commit 583da48 upstream.

When growing raid5 device on machine with small memory, there is chance that
mdadm will be killed and the following bug report can be observed. The same
bug could also be reproduced in linux-4.10.6.

[57600.075774] BUG: unable to handle kernel NULL pointer dereference at           (null)
[57600.083796] IP: [<ffffffff81a6aa87>] _raw_spin_lock+0x7/0x20
[57600.110378] PGD 421cf067 PUD 4442d067 PMD 0
[57600.114678] Oops: 0002 [#1] SMP
[57600.180799] CPU: 1 PID: 25990 Comm: mdadm Tainted: P           O    4.2.8 #1
[57600.187849] Hardware name: To be filled by O.E.M. To be filled by O.E.M./MAHOBAY, BIOS QV05AR66 03/06/2013
[57600.197490] task: ffff880044e47240 ti: ffff880043070000 task.ti: ffff880043070000
[57600.204963] RIP: 0010:[<ffffffff81a6aa87>]  [<ffffffff81a6aa87>] _raw_spin_lock+0x7/0x20
[57600.213057] RSP: 0018:ffff880043073810  EFLAGS: 00010046
[57600.218359] RAX: 0000000000000000 RBX: 000000000000000c RCX: ffff88011e296dd0
[57600.225486] RDX: 0000000000000001 RSI: ffffe8ffffcb46c0 RDI: 0000000000000000
[57600.232613] RBP: ffff880043073878 R08: ffff88011e5f8170 R09: 0000000000000282
[57600.239739] R10: 0000000000000005 R11: 28f5c28f5c28f5c3 R12: ffff880043073838
[57600.246872] R13: ffffe8ffffcb46c0 R14: 0000000000000000 R15: ffff8800b9706a00
[57600.253999] FS:  00007f576106c700(0000) GS:ffff88011e280000(0000) knlGS:0000000000000000
[57600.262078] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[57600.267817] CR2: 0000000000000000 CR3: 00000000428fe000 CR4: 00000000001406e0
[57600.274942] Stack:
[57600.276949]  ffffffff8114ee35 ffff880043073868 0000000000000282 000000000000eb3f
[57600.284383]  ffffffff81119043 ffff880043073838 ffff880043073838 ffff88003e197b98
[57600.291820]  ffffe8ffffcb46c0 ffff88003e197360 0000000000000286 ffff880043073968
[57600.299254] Call Trace:
[57600.301698]  [<ffffffff8114ee35>] ? cache_flusharray+0x35/0xe0
[57600.307523]  [<ffffffff81119043>] ? __page_cache_release+0x23/0x110
[57600.313779]  [<ffffffff8114eb53>] kmem_cache_free+0x63/0xc0
[57600.319344]  [<ffffffff81579942>] drop_one_stripe+0x62/0x90
[57600.324915]  [<ffffffff81579b5b>] raid5_cache_scan+0x8b/0xb0
[57600.330563]  [<ffffffff8111b98a>] shrink_slab.part.36+0x19a/0x250
[57600.336650]  [<ffffffff8111e38c>] shrink_zone+0x23c/0x250
[57600.342039]  [<ffffffff8111e4f3>] do_try_to_free_pages+0x153/0x420
[57600.348210]  [<ffffffff8111e851>] try_to_free_pages+0x91/0xa0
[57600.353959]  [<ffffffff811145b1>] __alloc_pages_nodemask+0x4d1/0x8b0
[57600.360303]  [<ffffffff8157a30b>] check_reshape+0x62b/0x770
[57600.365866]  [<ffffffff8157a4a5>] raid5_check_reshape+0x55/0xa0
[57600.371778]  [<ffffffff81583df7>] update_raid_disks+0xc7/0x110
[57600.377604]  [<ffffffff81592b73>] md_ioctl+0xd83/0x1b10
[57600.382827]  [<ffffffff81385380>] blkdev_ioctl+0x170/0x690
[57600.388307]  [<ffffffff81195238>] block_ioctl+0x38/0x40
[57600.393525]  [<ffffffff811731c5>] do_vfs_ioctl+0x2b5/0x480
[57600.399010]  [<ffffffff8115e07b>] ? vfs_write+0x14b/0x1f0
[57600.404400]  [<ffffffff811733cc>] SyS_ioctl+0x3c/0x70
[57600.409447]  [<ffffffff81a6ad97>] entry_SYSCALL_64_fastpath+0x12/0x6a
[57600.415875] Code: 00 00 00 00 55 48 89 e5 8b 07 85 c0 74 04 31 c0 5d c3 ba 01 00 00 00 f0 0f b1 17 85 c0 75 ef b0 01 5d c3 90 31 c0 ba 01 00 00 00 <f0> 0f b1 17 85 c0 75 01 c3 55 89 c6 48 89 e5 e8 85 d1 63 ff 5d
[57600.435460] RIP  [<ffffffff81a6aa87>] _raw_spin_lock+0x7/0x20
[57600.441208]  RSP <ffff880043073810>
[57600.444690] CR2: 0000000000000000
[57600.448000] ---[ end trace cbc6b5cc4bf9831d ]---

The problem is that resize_stripes() releases new stripe_heads before assigning new
slab cache to conf->slab_cache. If the shrinker function raid5_cache_scan() gets called
after resize_stripes() starting releasing new stripes but right before new slab cache
being assigned, it is possible that these new stripe_heads will be freed with the old
slab_cache which was already been destoryed and that triggers this bug.

Signed-off-by: Dennis Yang <dennisyang@qnap.com>
Fixes: edbe83a ("md/raid5: allow the stripe_cache to grow and shrink.")
Reviewed-by: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
bgly pushed a commit that referenced this pull request Aug 18, 2017
@ksacilotto
KVM: x86: Fix load damaged SSEx MXCSR register
7ce55e3 
BugLink: http://bugs.launchpad.net/bugs/1694621

commit a575813 upstream.

Reported by syzkaller:

   BUG: unable to handle kernel paging request at ffffffffc07f6a2e
   IP: report_bug+0x94/0x120
   PGD 348e12067
   P4D 348e12067
   PUD 348e14067
   PMD 3cbd84067
   PTE 80000003f7e87161

   Oops: 0003 [#1] SMP
   CPU: 2 PID: 7091 Comm: kvm_load_guest_ Tainted: G           OE   4.11.0+ #8
   task: ffff92fdfb525400 task.stack: ffffbda6c3d04000
   RIP: 0010:report_bug+0x94/0x120
   RSP: 0018:ffffbda6c3d07b20 EFLAGS: 00010202
    do_trap+0x156/0x170
    do_error_trap+0xa3/0x170
    ? kvm_load_guest_fpu.part.175+0x12a/0x170 [kvm]
    ? mark_held_locks+0x79/0xa0
    ? retint_kernel+0x10/0x10
    ? trace_hardirqs_off_thunk+0x1a/0x1c
    do_invalid_op+0x20/0x30
    invalid_op+0x1e/0x30
   RIP: 0010:kvm_load_guest_fpu.part.175+0x12a/0x170 [kvm]
    ? kvm_load_guest_fpu.part.175+0x1c/0x170 [kvm]
    kvm_arch_vcpu_ioctl_run+0xed6/0x1b70 [kvm]
    kvm_vcpu_ioctl+0x384/0x780 [kvm]
    ? kvm_vcpu_ioctl+0x384/0x780 [kvm]
    ? sched_clock+0x13/0x20
    ? __do_page_fault+0x2a0/0x550
    do_vfs_ioctl+0xa4/0x700
    ? up_read+0x1f/0x40
    ? __do_page_fault+0x2a0/0x550
    SyS_ioctl+0x79/0x90
    entry_SYSCALL_64_fastpath+0x23/0xc2

SDM mentioned that "The MXCSR has several reserved bits, and attempting to write
a 1 to any of these bits will cause a general-protection exception(#GP) to be
generated". The syzkaller forks' testcase overrides xsave area w/ random values
and steps on the reserved bits of MXCSR register. The damaged MXCSR register
values of guest will be restored to SSEx MXCSR register before vmentry. This
patch fixes it by catching userspace override MXCSR register reserved bits w/
random values and bails out immediately.

Reported-by: Andrey Konovalov <andreyknvl@google.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
bgly pushed a commit that referenced this pull request Aug 18, 2017
@kleinerm @ksacilotto
drm/amdgpu: Avoid overflows/divide-by-zero in latency_watermark calcu…
c3aef11 
…lations.

BugLink: http://bugs.launchpad.net/bugs/1694621

commit e190ed1 upstream.

At dot clocks > approx. 250 Mhz, some of these calcs will overflow and
cause miscalculation of latency watermarks, and for some overflows also
divide-by-zero driver crash ("divide error: 0000 [#1] PREEMPT SMP" in
"dce_v10_0_latency_watermark+0x12d/0x190").

This zero-divide happened, e.g., on AMD Tonga Pro under DCE-10,
on a Displayport panel when trying to set a video mode of 2560x1440
at 165 Hz vrefresh with a dot clock of 635.540 Mhz.

Refine calculations to avoid the overflows.

Tested for DCE-10 with R9 380 Tonga + ASUS ROG PG279 panel.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
bgly pushed a commit that referenced this pull request Aug 18, 2017
@l1k @ksacilotto
PCI: Freeze PME scan before suspending devices
40ed882 
BugLink: http://bugs.launchpad.net/bugs/1694621

commit ea00353 upstream.

Laurent Pinchart reported that the Renesas R-Car H2 Lager board (r8a7790)
crashes during suspend tests.  Geert Uytterhoeven managed to reproduce the
issue on an M2-W Koelsch board (r8a7791):

  It occurs when the PME scan runs, once per second.  During PME scan, the
  PCI host bridge (rcar-pci) registers are accessed while its module clock
  has already been disabled, leading to the crash.

One reproducer is to configure s2ram to use "s2idle" instead of "deep"
suspend:

  # echo 0 > /sys/module/printk/parameters/console_suspend
  # echo s2idle > /sys/power/mem_sleep
  # echo mem > /sys/power/state

Another reproducer is to write either "platform" or "processors" to
/sys/power/pm_test.  It does not (or is less likely) to happen during full
system suspend ("core" or "none") because system suspend also disables
timers, and thus the workqueue handling PME scans no longer runs.  Geert
believes the issue may still happen in the small window between disabling
module clocks and disabling timers:

  # echo 0 > /sys/module/printk/parameters/console_suspend
  # echo platform > /sys/power/pm_test    # Or "processors"
  # echo mem > /sys/power/state

(Make sure CONFIG_PCI_RCAR_GEN2 and CONFIG_USB_OHCI_HCD_PCI are enabled.)

Rafael Wysocki agrees that PME scans should be suspended before the host
bridge registers become inaccessible.  To that end, queue the task on a
workqueue that gets frozen before devices suspend.

Rafael notes however that as a result, some wakeup events may be missed if
they are delivered via PME from a device without working IRQ (which hence
must be polled) and occur after the workqueue has been frozen.  If that
turns out to be an issue in practice, it may be possible to solve it by
calling pci_pme_list_scan() once directly from one of the host bridge's
pm_ops callbacks.

Stacktrace for posterity:

  PM: Syncing filesystems ... [   38.566237] done.
  PM: Preparing system for sleep (mem)
  Freezing user space processes ... [   38.579813] (elapsed 0.001 seconds) done.
  Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
  PM: Suspending system (mem)
  PM: suspend of devices complete after 152.456 msecs
  PM: late suspend of devices complete after 2.809 msecs
  PM: noirq suspend of devices complete after 29.863 msecs
  suspend debug: Waiting for 5 second(s).
  Unhandled fault: asynchronous external abort (0x1211) at 0x00000000
  pgd = c0003000
  [00000000] *pgd=80000040004003, *pmd=00000000
  Internal error: : 1211 [#1] SMP ARM
  Modules linked in:
  CPU: 1 PID: 20 Comm: kworker/1:1 Not tainted
  4.9.0-rc1-koelsch-00011-g68db9bc814362e7f #3383
  Hardware name: Generic R8A7791 (Flattened Device Tree)
  Workqueue: events pci_pme_list_scan
  task: eb56e140 task.stack: eb58e000
  PC is at pci_generic_config_read+0x64/0x6c
  LR is at rcar_pci_cfg_base+0x64/0x84
  pc : [<c041d7b4>]    lr : [<c04309a0>]    psr: 600d0093
  sp : eb58fe98  ip : c041d750  fp : 00000008
  r10: c0e2283c  r9 : 00000000  r8 : 600d0013
  r7 : 00000008  r6 : eb58fed6  r5 : 00000002  r4 : eb58feb4
  r3 : 00000000  r2 : 00000044  r1 : 00000008  r0 : 00000000
  Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
  Control: 30c5387d  Table: 6a9f6c80  DAC: 55555555
  Process kworker/1:1 (pid: 20, stack limit = 0xeb58e210)
  Stack: (0xeb58fe98 to 0xeb590000)
  fe80:                                                       00000002 00000044
  fea0: eb6f5800 c041d9b0 eb58feb4 00000008 00000044 00000000 eb78a000 eb78a000
  fec0: 00000044 00000000 eb9aff00 c0424bf0 eb78a000 00000000 eb78a000 c0e22830
  fee0: ea8a6fc0 c0424c5c eaae79c0 c0424ce0 eb55f380 c0e22838 eb9a9800 c0235fbc
  ff00: eb55f380 c0e22838 eb55f380 eb9a9800 eb9a9800 eb58e000 eb9a9824 c0e02100
  ff20: eb55f398 c02366c4 eb56e140 eb5631c0 00000000 eb55f380 c023641c 00000000
  ff40: 00000000 00000000 00000000 c023a928 cd105598 00000000 40506a34 eb55f380
  ff60: 00000000 00000000 dead4ead ffffffff ffffffff eb58ff74 eb58ff74 00000000
  ff80: 00000000 dead4ead ffffffff ffffffff eb58ff90 eb58ff90 eb58ffac eb5631c0
  ffa0: c023a844 00000000 00000000 c0206d68 00000000 00000000 00000000 00000000
  ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 3a81336c 10ccd1dd
  [<c041d7b4>] (pci_generic_config_read) from [<c041d9b0>]
  (pci_bus_read_config_word+0x58/0x80)
  [<c041d9b0>] (pci_bus_read_config_word) from [<c0424bf0>]
  (pci_check_pme_status+0x34/0x78)
  [<c0424bf0>] (pci_check_pme_status) from [<c0424c5c>] (pci_pme_wakeup+0x28/0x54)
  [<c0424c5c>] (pci_pme_wakeup) from [<c0424ce0>] (pci_pme_list_scan+0x58/0xb4)
  [<c0424ce0>] (pci_pme_list_scan) from [<c0235fbc>]
  (process_one_work+0x1bc/0x308)
  [<c0235fbc>] (process_one_work) from [<c02366c4>] (worker_thread+0x2a8/0x3e0)
  [<c02366c4>] (worker_thread) from [<c023a928>] (kthread+0xe4/0xfc)
  [<c023a928>] (kthread) from [<c0206d68>] (ret_from_fork+0x14/0x2c)
  Code: ea000000 e5903000 f57ff04f e3a00000 (e5843000)
  ---[ end trace 667d43ba3aa9e589 ]---

Fixes: df17e62 ("PCI: Add support for polling PME state on suspended legacy PCI devices")
Reported-and-tested-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reported-and-tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Cc: Simon Horman <horms+renesas@verge.net.au>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
bgly pushed a commit that referenced this pull request Aug 18, 2017
@ebiggers
KEYS: fix freeing uninitialized memory in key_update()
31605d5 
BugLink: http://bugs.launchpad.net/bugs/1698799

commit 63a0b05 upstream.

key_update() freed the key_preparsed_payload even if it was not
initialized first.  This would cause a crash if userspace called
keyctl_update() on a key with type like "asymmetric" that has a
->preparse() method but not an ->update() method.  Possibly it could
even be triggered for other key types by racing with keyctl_setperm() to
make the KEY_NEED_WRITE check fail (the permission was already checked,
so normally it wouldn't fail there).

Reproducer with key type "asymmetric", given a valid cert.der:

keyctl new_session
keyid=$(keyctl padd asymmetric desc @s < cert.der)
keyctl setperm $keyid 0x3f000000
keyctl update $keyid data

[  150.686666] BUG: unable to handle kernel NULL pointer dereference at 0000000000000001
[  150.687601] IP: asymmetric_key_free_kids+0x12/0x30
[  150.688139] PGD 38a3d067
[  150.688141] PUD 3b3de067
[  150.688447] PMD 0
[  150.688745]
[  150.689160] Oops: 0000 [#1] SMP
[  150.689455] Modules linked in:
[  150.689769] CPU: 1 PID: 2478 Comm: keyctl Not tainted 4.11.0-rc4-xfstests-00187-ga9f6b6b8cd2f torvalds#742
[  150.690916] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-20170228_101828-anatol 04/01/2014
[  150.692199] task: ffff88003b30c480 task.stack: ffffc90000350000
[  150.692952] RIP: 0010:asymmetric_key_free_kids+0x12/0x30
[  150.693556] RSP: 0018:ffffc90000353e58 EFLAGS: 00010202
[  150.694142] RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000004
[  150.694845] RDX: ffffffff81ee3920 RSI: ffff88003d4b0700 RDI: 0000000000000001
[  150.697569] RBP: ffffc90000353e60 R08: ffff88003d5d2140 R09: 0000000000000000
[  150.702483] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001
[  150.707393] R13: 0000000000000004 R14: ffff880038a4d2d8 R15: 000000000040411f
[  150.709720] FS:  00007fcbcee35700(0000) GS:ffff88003fd00000(0000) knlGS:0000000000000000
[  150.711504] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  150.712733] CR2: 0000000000000001 CR3: 0000000039eab000 CR4: 00000000003406e0
[  150.714487] Call Trace:
[  150.714975]  asymmetric_key_free_preparse+0x2f/0x40
[  150.715907]  key_update+0xf7/0x140
[  150.716560]  ? key_default_cmp+0x20/0x20
[  150.717319]  keyctl_update_key+0xb0/0xe0
[  150.718066]  SyS_keyctl+0x109/0x130
[  150.718663]  entry_SYSCALL_64_fastpath+0x1f/0xc2
[  150.719440] RIP: 0033:0x7fcbce75ff19
[  150.719926] RSP: 002b:00007ffd5d167088 EFLAGS: 00000206 ORIG_RAX: 00000000000000fa
[  150.720918] RAX: ffffffffffffffda RBX: 0000000000404d80 RCX: 00007fcbce75ff19
[  150.721874] RDX: 00007ffd5d16785e RSI: 000000002866cd36 RDI: 0000000000000002
[  150.722827] RBP: 0000000000000006 R08: 000000002866cd36 R09: 00007ffd5d16785e
[  150.723781] R10: 0000000000000004 R11: 0000000000000206 R12: 0000000000404d80
[  150.724650] R13: 00007ffd5d16784d R14: 00007ffd5d167238 R15: 000000000040411f
[  150.725447] Code: 83 c4 08 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 85 ff 74 23 55 48 89 e5 53 48 89 fb <48> 8b 3f e8 06 21 c5 ff 48 8b 7b 08 e8 fd 20 c5 ff 48 89 df e8
[  150.727489] RIP: asymmetric_key_free_kids+0x12/0x30 RSP: ffffc90000353e58
[  150.728117] CR2: 0000000000000001
[  150.728430] ---[ end trace f7f8fe1da2d5ae8d ]---

Fixes: 4d8c025 ("KEYS: Call ->free_preparse() even after ->preparse() returns an error")
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
bgly pushed a commit that referenced this pull request Aug 18, 2017
KVM: arm/arm64: Handle possible NULL stage2 pud when ageing pages
dfbcccd 
BugLink: http://bugs.launchpad.net/bugs/1698799

commit d6dbdd3 upstream.

Under memory pressure, we start ageing pages, which amounts to parsing
the page tables. Since we don't want to allocate any extra level,
we pass NULL for our private allocation cache. Which means that
stage2_get_pud() is allowed to fail. This results in the following
splat:

[ 1520.409577] Unable to handle kernel NULL pointer dereference at virtual address 00000008
[ 1520.417741] pgd = ffff810f52fef000
[ 1520.421201] [00000008] *pgd=0000010f636c5003, *pud=0000010f56f48003, *pmd=0000000000000000
[ 1520.429546] Internal error: Oops: 96000006 [#1] PREEMPT SMP
[ 1520.435156] Modules linked in:
[ 1520.438246] CPU: 15 PID: 53550 Comm: qemu-system-aar Tainted: G        W       4.12.0-rc4-00027-g1885c397eaec #7205
[ 1520.448705] Hardware name: FOXCONN R2-1221R-A4/C2U4N_MB, BIOS G31FB12A 10/26/2016
[ 1520.463726] task: ffff800ac5fb4e00 task.stack: ffff800ce04e0000
[ 1520.469666] PC is at stage2_get_pmd+0x34/0x110
[ 1520.474119] LR is at kvm_age_hva_handler+0x44/0xf0
[ 1520.478917] pc : [<ffff0000080b137c>] lr : [<ffff0000080b149c>] pstate: 40000145
[ 1520.486325] sp : ffff800ce04e33d0
[ 1520.489644] x29: ffff800ce04e33d0 x28: 0000000ffff40064
[ 1520.494967] x27: 0000ffff27e00000 x26: 0000000000000000
[ 1520.500289] x25: ffff81051ba65008 x24: 0000ffff40065000
[ 1520.505618] x23: 0000ffff40064000 x22: 0000000000000000
[ 1520.510947] x21: ffff810f52b20000 x20: 0000000000000000
[ 1520.516274] x19: 0000000058264000 x18: 0000000000000000
[ 1520.521603] x17: 0000ffffa6fe7438 x16: ffff000008278b70
[ 1520.526940] x15: 000028ccd8000000 x14: 0000000000000008
[ 1520.532264] x13: ffff7e0018298000 x12: 0000000000000002
[ 1520.537582] x11: ffff000009241b93 x10: 0000000000000940
[ 1520.542908] x9 : ffff0000092ef800 x8 : 0000000000000200
[ 1520.548229] x7 : ffff800ce04e36a8 x6 : 0000000000000000
[ 1520.553552] x5 : 0000000000000001 x4 : 0000000000000000
[ 1520.558873] x3 : 0000000000000000 x2 : 0000000000000008
[ 1520.571696] x1 : ffff000008fd5000 x0 : ffff0000080b149c
[ 1520.577039] Process qemu-system-aar (pid: 53550, stack limit = 0xffff800ce04e0000)
[...]
[ 1521.510735] [<ffff0000080b137c>] stage2_get_pmd+0x34/0x110
[ 1521.516221] [<ffff0000080b149c>] kvm_age_hva_handler+0x44/0xf0
[ 1521.522054] [<ffff0000080b0610>] handle_hva_to_gpa+0xb8/0xe8
[ 1521.527716] [<ffff0000080b3434>] kvm_age_hva+0x44/0xf0
[ 1521.532854] [<ffff0000080a58b0>] kvm_mmu_notifier_clear_flush_young+0x70/0xc0
[ 1521.539992] [<ffff000008238378>] __mmu_notifier_clear_flush_young+0x88/0xd0
[ 1521.546958] [<ffff00000821eca0>] page_referenced_one+0xf0/0x188
[ 1521.552881] [<ffff00000821f36c>] rmap_walk_anon+0xec/0x250
[ 1521.558370] [<ffff000008220f78>] rmap_walk+0x78/0xa0
[ 1521.563337] [<ffff000008221104>] page_referenced+0x164/0x180
[ 1521.569002] [<ffff0000081f1af0>] shrink_active_list+0x178/0x3b8
[ 1521.574922] [<ffff0000081f2058>] shrink_node_memcg+0x328/0x600
[ 1521.580758] [<ffff0000081f23f4>] shrink_node+0xc4/0x328
[ 1521.585986] [<ffff0000081f2718>] do_try_to_free_pages+0xc0/0x340
[ 1521.592000] [<ffff0000081f2a64>] try_to_free_pages+0xcc/0x240
[...]

The trivial fix is to handle this NULL pud value early, rather than
dereferencing it blindly.

Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Christoffer Dall <cdall@linaro.org>
Signed-off-by: Christoffer Dall <cdall@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
bgly pushed a commit that referenced this pull request Aug 18, 2017
mm: consider memblock reservations for deferred memory initialization…
8998d9c 
… sizing

BugLink: http://bugs.launchpad.net/bugs/1698799

commit 864b9a3 upstream.

We have seen an early OOM killer invocation on ppc64 systems with
crashkernel=4096M:

	kthreadd invoked oom-killer: gfp_mask=0x16040c0(GFP_KERNEL|__GFP_COMP|__GFP_NOTRACK), nodemask=7, order=0, oom_score_adj=0
	kthreadd cpuset=/ mems_allowed=7
	CPU: 0 PID: 2 Comm: kthreadd Not tainted 4.4.68-1.gd7fe927-default #1
	Call Trace:
	  dump_stack+0xb0/0xf0 (unreliable)
	  dump_header+0xb0/0x258
	  out_of_memory+0x5f0/0x640
	  __alloc_pages_nodemask+0xa8c/0xc80
	  kmem_getpages+0x84/0x1a0
	  fallback_alloc+0x2a4/0x320
	  kmem_cache_alloc_node+0xc0/0x2e0
	  copy_process.isra.25+0x260/0x1b30
	  _do_fork+0x94/0x470
	  kernel_thread+0x48/0x60
	  kthreadd+0x264/0x330
	  ret_from_kernel_thread+0x5c/0xa4

	Mem-Info:
	active_anon:0 inactive_anon:0 isolated_anon:0
	 active_file:0 inactive_file:0 isolated_file:0
	 unevictable:0 dirty:0 writeback:0 unstable:0
	 slab_reclaimable:5 slab_unreclaimable:73
	 mapped:0 shmem:0 pagetables:0 bounce:0
	 free:0 free_pcp:0 free_cma:0
	Node 7 DMA free:0kB min:0kB low:0kB high:0kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:52428800kB managed:110016kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:320kB slab_unreclaimable:4672kB kernel_stack:1152kB pagetables:0kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
	lowmem_reserve[]: 0 0 0 0
	Node 7 DMA: 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB = 0kB
	0 total pagecache pages
	0 pages in swap cache
	Swap cache stats: add 0, delete 0, find 0/0
	Free swap  = 0kB
	Total swap = 0kB
	819200 pages RAM
	0 pages HighMem/MovableOnly
	817481 pages reserved
	0 pages cma reserved
	0 pages hwpoisoned

the reason is that the managed memory is too low (only 110MB) while the
rest of the the 50GB is still waiting for the deferred intialization to
be done.  update_defer_init estimates the initial memoty to initialize
to 2GB at least but it doesn't consider any memory allocated in that
range.  In this particular case we've had

	Reserving 4096MB of memory at 128MB for crashkernel (System RAM: 51200MB)

so the low 2GB is mostly depleted.

Fix this by considering memblock allocations in the initial static
initialization estimation.  Move the max_initialise to
reset_deferred_meminit and implement a simple memblock_reserved_memory
helper which iterates all reserved blocks and sums the size of all that
start below the given address.  The cumulative size is than added on top
of the initial estimation.  This is still not ideal because
reset_deferred_meminit doesn't consider holes and so reservation might
be above the initial estimation whihch we ignore but let's make the
logic simpler until we really need to handle more complicated cases.

Fixes: 3a80a7f ("mm: meminit: initialise a subset of struct pages if CONFIG_DEFERRED_STRUCT_PAGE_INIT is set")
Link: http://lkml.kernel.org/r/20170531104010.GI27783@dhcp22.suse.cz
Signed-off-by: Michal Hocko <mhocko@suse.com>
Acked-by: Mel Gorman <mgorman@suse.de>
Tested-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
bgly pushed a commit that referenced this pull request Aug 18, 2017
@dhowells
fscache: Fix dead object requeue
9cb3f8d 
BugLink: http://bugs.launchpad.net/bugs/1698817

[ Upstream commit e26bfeb ]

Under some circumstances, an fscache object can become queued such that it
fscache_object_work_func() can be called once the object is in the
OBJECT_DEAD state.  This results in the kernel oopsing when it tries to
invoke the handler for the state (which is hard coded to 0x2).

The way this comes about is something like the following:

 (1) The object dispatcher is processing a work state for an object.  This
     is done in workqueue context.

 (2) An out-of-band event comes in that isn't masked, causing the object to
     be queued, say EV_KILL.

 (3) The object dispatcher finishes processing the current work state on
     that object and then sees there's another event to process, so,
     without returning to the workqueue core, it processes that event too.
     It then follows the chain of events that initiates until we reach
     OBJECT_DEAD without going through a wait state (such as
     WAIT_FOR_CLEARANCE).

     At this point, object->events may be 0, object->event_mask will be 0
     and oob_event_mask will be 0.

 (4) The object dispatcher returns to the workqueue processor, and in due
     course, this sees that the object's work item is still queued and
     invokes it again.

 (5) The current state is a work state (OBJECT_DEAD), so the dispatcher
     jumps to it - resulting in an OOPS.

When I'm seeing this, the work state in (1) appears to have been either
LOOK_UP_OBJECT or CREATE_OBJECT (object->oob_table is
fscache_osm_lookup_oob).

The window for (2) is very small:

 (A) object->event_mask is cleared whilst the event dispatch process is
     underway - though there's no memory barrier to force this to the top
     of the function.

     The window, therefore is from the time the object was selected by the
     workqueue processor and made requeueable to the time the mask was
     cleared.

 (B) fscache_raise_event() will only queue the object if it manages to set
     the event bit and the corresponding event_mask bit was set.

     The enqueuement is then deferred slightly whilst we get a ref on the
     object and get the per-CPU variable for workqueue congestion.  This
     slight deferral slightly increases the probability by allowing extra
     time for the workqueue to make the item requeueable.

Handle this by giving the dead state a processor function and checking the
for the dead state address rather than seeing if the processor function is
address 0x2.  The dead state processor function can then set a flag to
indicate that it's occurred and give a warning if it occurs more than once
per object.

If this race occurs, an oops similar to the following is seen (note the RIP
value):

BUG: unable to handle kernel NULL pointer dereference at 0000000000000002
IP: [<0000000000000002>] 0x1
PGD 0
Oops: 0010 [#1] SMP
Modules linked in: ...
CPU: 17 PID: 16077 Comm: kworker/u48:9 Not tainted 3.10.0-327.18.2.el7.x86_64 #1
Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 12/27/2015
Workqueue: fscache_object fscache_object_work_func [fscache]
task: ffff880302b63980 ti: ffff880717544000 task.ti: ffff880717544000
RIP: 0010:[<0000000000000002>]  [<0000000000000002>] 0x1
RSP: 0018:ffff880717547df8  EFLAGS: 00010202
RAX: ffffffffa0368640 RBX: ffff880edf7a4480 RCX: dead000000200200
RDX: 0000000000000002 RSI: 00000000ffffffff RDI: ffff880edf7a4480
RBP: ffff880717547e18 R08: 0000000000000000 R09: dfc40a25cb3a4510
R10: dfc40a25cb3a4510 R11: 0000000000000400 R12: 0000000000000000
R13: ffff880edf7a4510 R14: ffff8817f6153400 R15: 0000000000000600
FS:  0000000000000000(0000) GS:ffff88181f420000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000002 CR3: 000000000194a000 CR4: 00000000001407e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Stack:
 ffffffffa0363695 ffff880edf7a4510 ffff88093f16f900 ffff8817faa4ec00
 ffff880717547e60 ffffffff8109d5db 00000000faa4ec18 0000000000000000
 ffff8817faa4ec18 ffff88093f16f930 ffff880302b63980 ffff88093f16f900
Call Trace:
 [<ffffffffa0363695>] ? fscache_object_work_func+0xa5/0x200 [fscache]
 [<ffffffff8109d5db>] process_one_work+0x17b/0x470
 [<ffffffff8109e4ac>] worker_thread+0x21c/0x400
 [<ffffffff8109e290>] ? rescuer_thread+0x400/0x400
 [<ffffffff810a5acf>] kthread+0xcf/0xe0
 [<ffffffff810a5a00>] ? kthread_create_on_node+0x140/0x140
 [<ffffffff816460d8>] ret_from_fork+0x58/0x90
 [<ffffffff810a5a00>] ? kthread_create_on_node+0x140/0x140

Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Jeremy McNicoll <jeremymc@redhat.com>
Tested-by: Frank Sorenson <sorenson@redhat.com>
Tested-by: Benjamin Coddington <bcodding@redhat.com>
Reviewed-by: Benjamin Coddington <bcodding@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
bgly pushed a commit that referenced this pull request Aug 18, 2017
gianfar: synchronize DMA API usage by free_skb_rx_queue w/ gfar_new_page
e22292d 
BugLink: http://bugs.launchpad.net/bugs/1698817

[ Upstream commit 4af0e5b ]

In spite of switching to paged allocation of Rx buffers, the driver still
called dma_unmap_single() in the Rx queues tear-down path.

The DMA region unmapping code in free_skb_rx_queue() basically predates
the introduction of paged allocation to the driver. While being refactored,
it apparently hasn't reflected the change in the DMA API usage by its
counterpart gfar_new_page().

As a result, setting an interface to the DOWN state now yields the following:

  # ip link set eth2 down
  fsl-gianfar ffe24000.ethernet: DMA-API: device driver frees DMA memory with wrong function [device address=0x000000001ecd0000] [size=40]
  ------------[ cut here ]------------
  WARNING: CPU: 1 PID: 189 at lib/dma-debug.c:1123 check_unmap+0x8e0/0xa28
  CPU: 1 PID: 189 Comm: ip Tainted: G           O    4.9.5 #1
  task: dee73400 task.stack: dede2000
  NIP: c02101e8 LR: c02101e8 CTR: c0260d74
  REGS: dede3bb0 TRAP: 0700   Tainted: G           O     (4.9.5)
  MSR: 00021000 <CE,ME>  CR: 28002222  XER: 00000000

  GPR00: c02101e8 dede3c60 dee73400 000000b6 dfbd033c dfbd36c4 1f622000 dede2000
  GPR08: 00000007 c05b1634 1f622000 00000000 22002484 100a9904 00000000 00000000
  GPR16: 00000000 db4c849c 00000002 db4c8480 00000001 df142240 db4c84bc 00000000
  GPR24: c0706148 c0700000 00029000 c07552e8 c07323b4 dede3cb8 c07605e0 db535540
  NIP [c02101e8] check_unmap+0x8e0/0xa28
  LR [c02101e8] check_unmap+0x8e0/0xa28
  Call Trace:
  [dede3c60] [c02101e8] check_unmap+0x8e0/0xa28 (unreliable)
  [dede3cb0] [c02103b8] debug_dma_unmap_page+0x88/0x9c
  [dede3d30] [c02dffbc] free_skb_resources+0x2c4/0x404
  [dede3d80] [c02e39b4] gfar_close+0x24/0xc8
  [dede3da0] [c0361550] __dev_close_many+0xa0/0xf8
  [dede3dd0] [c03616f0] __dev_close+0x2c/0x4c
  [dede3df0] [c036b1b8] __dev_change_flags+0xa0/0x174
  [dede3e10] [c036b2ac] dev_change_flags+0x20/0x60
  [dede3e30] [c03e130c] devinet_ioctl+0x540/0x824
  [dede3e90] [c0347dcc] sock_ioctl+0x134/0x298
  [dede3eb0] [c0111814] do_vfs_ioctl+0xac/0x854
  [dede3f20] [c0111ffc] SyS_ioctl+0x40/0x74
  [dede3f40] [c000f290] ret_from_syscall+0x0/0x3c
  --- interrupt: c01 at 0xff45da0
      LR = 0xff45cd0
  Instruction dump:
  811d001c 7c66482e 813d0020 9061000c 807f000c 5463103a 7cc6182e 3c60c052
  386309ac 90c10008 4cc63182 4826b845 <0fe00000> 4bfffa60 3c80c052 388402c4
  ---[ end trace 695ae6d7ac1d0c47 ]---
  Mapped at:
   [<c02e22a8>] gfar_alloc_rx_buffs+0x178/0x248
   [<c02e3ef0>] startup_gfar+0x368/0x570
   [<c036aeb4>] __dev_open+0xdc/0x150
   [<c036b1b8>] __dev_change_flags+0xa0/0x174
   [<c036b2ac>] dev_change_flags+0x20/0x60

Even though the issue was discovered in 4.9 kernel, the code in question
is identical in the current net and net-next trees.

Fixes: 7535414 ("gianfar: Add paged allocation and Rx S/G")
Signed-off-by: Arseny Solokha <asolokha@kb.kras.ru>
Acked-by: Claudiu Manoil <claudiu.manoil@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
bgly pushed a commit that referenced this pull request Aug 18, 2017
@gfreewind @ksacilotto
net: 8021q: Fix one possible panic caused by BUG_ON in free_netdev
4762bd9 
BugLink: http://bugs.launchpad.net/bugs/1702863

[ Upstream commit 9745e36 ]

The register_vlan_device would invoke free_netdev directly, when
register_vlan_dev failed. It would trigger the BUG_ON in free_netdev
if the dev was already registered. In this case, the netdev would be
freed in netdev_run_todo later.

So add one condition check now. Only when dev is not registered, then
free it directly.

The following is the part coredump when netdev_upper_dev_link failed
in register_vlan_dev. I removed the lines which are too long.

[  411.237457] ------------[ cut here ]------------
[  411.237458] kernel BUG at net/core/dev.c:7998!
[  411.237484] invalid opcode: 0000 [#1] SMP
[  411.237705]  [last unloaded: 8021q]
[  411.237718] CPU: 1 PID: 12845 Comm: vconfig Tainted: G            E   4.12.0-rc5+ #6
[  411.237737] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/02/2015
[  411.237764] task: ffff9cbeb6685580 task.stack: ffffa7d2807d8000
[  411.237782] RIP: 0010:free_netdev+0x116/0x120
[  411.237794] RSP: 0018:ffffa7d2807dbdb0 EFLAGS: 00010297
[  411.237808] RAX: 0000000000000002 RBX: ffff9cbeb6ba8fd8 RCX: 0000000000001878
[  411.237826] RDX: 0000000000000001 RSI: 0000000000000282 RDI: 0000000000000000
[  411.237844] RBP: ffffa7d2807dbdc8 R08: 0002986100029841 R09: 0002982100029801
[  411.237861] R10: 0004000100029980 R11: 0004000100029980 R12: ffff9cbeb6ba9000
[  411.238761] R13: ffff9cbeb6ba9060 R14: ffff9cbe60f1a000 R15: ffff9cbeb6ba9000
[  411.239518] FS:  00007fb690d81700(0000) GS:ffff9cbebb640000(0000) knlGS:0000000000000000
[  411.239949] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  411.240454] CR2: 00007f7115624000 CR3: 0000000077cdf000 CR4: 00000000003406e0
[  411.240936] Call Trace:
[  411.241462]  vlan_ioctl_handler+0x3f1/0x400 [8021q]
[  411.241910]  sock_ioctl+0x18b/0x2c0
[  411.242394]  do_vfs_ioctl+0xa1/0x5d0
[  411.242853]  ? sock_alloc_file+0xa6/0x130
[  411.243465]  SyS_ioctl+0x79/0x90
[  411.243900]  entry_SYSCALL_64_fastpath+0x1e/0xa9
[  411.244425] RIP: 0033:0x7fb69089a357
[  411.244863] RSP: 002b:00007ffcd04e0fc8 EFLAGS: 00000202 ORIG_RAX: 0000000000000010
[  411.245445] RAX: ffffffffffffffda RBX: 00007ffcd04e2884 RCX: 00007fb69089a357
[  411.245903] RDX: 00007ffcd04e0fd0 RSI: 0000000000008983 RDI: 0000000000000003
[  411.246527] RBP: 00007ffcd04e0fd0 R08: 0000000000000000 R09: 1999999999999999
[  411.246976] R10: 000000000000053f R11: 0000000000000202 R12: 0000000000000004
[  411.247414] R13: 00007ffcd04e1128 R14: 00007ffcd04e2888 R15: 0000000000000001
[  411.249129] RIP: free_netdev+0x116/0x120 RSP: ffffa7d2807dbdb0

Signed-off-by: Gao Feng <gfree.wind@vip.163.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
bgly pushed a commit that referenced this pull request Aug 18, 2017
@wangbaolin719 @ksacilotto
usb: gadget: f_fs: Fix possibe deadlock
21665c1 
BugLink: http://bugs.launchpad.net/bugs/1702863

commit b3ce3ce upstream.

When system try to close /dev/usb-ffs/adb/ep0 on one core, at the same
time another core try to attach new UDC, which will cause deadlock as
below scenario. Thus we should release ffs lock before issuing
unregister_gadget_item().

[   52.642225] c1 ======================================================
[   52.642228] c1 [ INFO: possible circular locking dependency detected ]
[   52.642236] c1 4.4.6+ #1 Tainted: G        W  O
[   52.642241] c1 -------------------------------------------------------
[   52.642245] c1 usb ffs open/2808 is trying to acquire lock:
[   52.642270] c0  (udc_lock){+.+.+.}, at: [<ffffffc00065aeec>]
		usb_gadget_unregister_driver+0x3c/0xc8
[   52.642272] c1  but task is already holding lock:
[   52.642283] c0  (ffs_lock){+.+.+.}, at: [<ffffffc00066b244>]
		ffs_data_clear+0x30/0x140
[   52.642285] c1 which lock already depends on the new lock.
[   52.642287] c1
               the existing dependency chain (in reverse order) is:
[   52.642295] c0
	       -> #1 (ffs_lock){+.+.+.}:
[   52.642307] c0        [<ffffffc00012340c>] __lock_acquire+0x20f0/0x2238
[   52.642314] c0        [<ffffffc000123b54>] lock_acquire+0xe4/0x298
[   52.642322] c0        [<ffffffc000aaf6e8>] mutex_lock_nested+0x7c/0x3cc
[   52.642328] c0        [<ffffffc00066f7bc>] ffs_func_bind+0x504/0x6e8
[   52.642334] c0        [<ffffffc000654004>] usb_add_function+0x84/0x184
[   52.642340] c0        [<ffffffc000658ca4>] configfs_composite_bind+0x264/0x39c
[   52.642346] c0        [<ffffffc00065b348>] udc_bind_to_driver+0x58/0x11c
[   52.642352] c0        [<ffffffc00065b49c>] usb_udc_attach_driver+0x90/0xc8
[   52.642358] c0        [<ffffffc0006598e0>] gadget_dev_desc_UDC_store+0xd4/0x128
[   52.642369] c0        [<ffffffc0002c14e8>] configfs_write_file+0xd0/0x13c
[   52.642376] c0        [<ffffffc00023c054>] vfs_write+0xb8/0x214
[   52.642381] c0        [<ffffffc00023cad4>] SyS_write+0x54/0xb0
[   52.642388] c0        [<ffffffc000085ff0>] el0_svc_naked+0x24/0x28
[   52.642395] c0
              -> #0 (udc_lock){+.+.+.}:
[   52.642401] c0        [<ffffffc00011e3d0>] print_circular_bug+0x84/0x2e4
[   52.642407] c0        [<ffffffc000123454>] __lock_acquire+0x2138/0x2238
[   52.642412] c0        [<ffffffc000123b54>] lock_acquire+0xe4/0x298
[   52.642420] c0        [<ffffffc000aaf6e8>] mutex_lock_nested+0x7c/0x3cc
[   52.642427] c0        [<ffffffc00065aeec>] usb_gadget_unregister_driver+0x3c/0xc8
[   52.642432] c0        [<ffffffc00065995c>] unregister_gadget_item+0x28/0x44
[   52.642439] c0        [<ffffffc00066b34c>] ffs_data_clear+0x138/0x140
[   52.642444] c0        [<ffffffc00066b374>] ffs_data_reset+0x20/0x6c
[   52.642450] c0        [<ffffffc00066efd0>] ffs_data_closed+0xac/0x12c
[   52.642454] c0        [<ffffffc00066f070>] ffs_ep0_release+0x20/0x2c
[   52.642460] c0        [<ffffffc00023dbe4>] __fput+0xb0/0x1f4
[   52.642466] c0        [<ffffffc00023dd9c>] ____fput+0x20/0x2c
[   52.642473] c0        [<ffffffc0000ee944>] task_work_run+0xb4/0xe8
[   52.642482] c0        [<ffffffc0000cd45c>] do_exit+0x360/0xb9c
[   52.642487] c0        [<ffffffc0000cf228>] do_group_exit+0x4c/0xb0
[   52.642494] c0        [<ffffffc0000dd3c8>] get_signal+0x380/0x89c
[   52.642501] c0        [<ffffffc00008a8f0>] do_signal+0x154/0x518
[   52.642507] c0        [<ffffffc00008af00>] do_notify_resume+0x70/0x78
[   52.642512] c0        [<ffffffc000085ee8>] work_pending+0x1c/0x20
[   52.642514] c1
              other info that might help us debug this:
[   52.642517] c1  Possible unsafe locking scenario:
[   52.642518] c1        CPU0                    CPU1
[   52.642520] c1        ----                    ----
[   52.642525] c0   lock(ffs_lock);
[   52.642529] c0                                lock(udc_lock);
[   52.642533] c0                                lock(ffs_lock);
[   52.642537] c0   lock(udc_lock);
[   52.642539] c1
                      *** DEADLOCK ***
[   52.642543] c1 1 lock held by usb ffs open/2808:
[   52.642555] c0  #0:  (ffs_lock){+.+.+.}, at: [<ffffffc00066b244>]
		ffs_data_clear+0x30/0x140
[   52.642557] c1 stack backtrace:
[   52.642563] c1 CPU: 1 PID: 2808 Comm: usb ffs open Tainted: G
[   52.642565] c1 Hardware name: Spreadtrum SP9860g Board (DT)
[   52.642568] c1 Call trace:
[   52.642573] c1 [<ffffffc00008b430>] dump_backtrace+0x0/0x170
[   52.642577] c1 [<ffffffc00008b5c0>] show_stack+0x20/0x28
[   52.642583] c1 [<ffffffc000422694>] dump_stack+0xa8/0xe0
[   52.642587] c1 [<ffffffc00011e548>] print_circular_bug+0x1fc/0x2e4
[   52.642591] c1 [<ffffffc000123454>] __lock_acquire+0x2138/0x2238
[   52.642595] c1 [<ffffffc000123b54>] lock_acquire+0xe4/0x298
[   52.642599] c1 [<ffffffc000aaf6e8>] mutex_lock_nested+0x7c/0x3cc
[   52.642604] c1 [<ffffffc00065aeec>] usb_gadget_unregister_driver+0x3c/0xc8
[   52.642608] c1 [<ffffffc00065995c>] unregister_gadget_item+0x28/0x44
[   52.642613] c1 [<ffffffc00066b34c>] ffs_data_clear+0x138/0x140
[   52.642618] c1 [<ffffffc00066b374>] ffs_data_reset+0x20/0x6c
[   52.642621] c1 [<ffffffc00066efd0>] ffs_data_closed+0xac/0x12c
[   52.642625] c1 [<ffffffc00066f070>] ffs_ep0_release+0x20/0x2c
[   52.642629] c1 [<ffffffc00023dbe4>] __fput+0xb0/0x1f4
[   52.642633] c1 [<ffffffc00023dd9c>] ____fput+0x20/0x2c
[   52.642636] c1 [<ffffffc0000ee944>] task_work_run+0xb4/0xe8
[   52.642640] c1 [<ffffffc0000cd45c>] do_exit+0x360/0xb9c
[   52.642644] c1 [<ffffffc0000cf228>] do_group_exit+0x4c/0xb0
[   52.642647] c1 [<ffffffc0000dd3c8>] get_signal+0x380/0x89c
[   52.642651] c1 [<ffffffc00008a8f0>] do_signal+0x154/0x518
[   52.642656] c1 [<ffffffc00008af00>] do_notify_resume+0x70/0x78
[   52.642659] c1 [<ffffffc000085ee8>] work_pending+0x1c/0x20

Acked-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Cc: Jerry Zhang <zhangjerry@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
bgly pushed a commit that referenced this pull request Aug 18, 2017
@gkurz @ksacilotto
vfio/spapr: fail tce_iommu_attach_group() when iommu_data is null
db6ad32 
BugLink: http://bugs.launchpad.net/bugs/1702863

[ Upstream commit bd00fdf ]

The recently added mediated VFIO driver doesn't know about powerpc iommu.
It thus doesn't register a struct iommu_table_group in the iommu group
upon device creation. The iommu_data pointer hence remains null.

This causes a kernel oops when userspace tries to set the iommu type of a
container associated with a mediated device to VFIO_SPAPR_TCE_v2_IOMMU.

[   82.585440] mtty mtty: MDEV: Registered
[   87.655522] iommu: Adding device 83b8f4f2-509f-382f-3c1e-e6bfe0fa1001 to group 10
[   87.655527] vfio_mdev 83b8f4f2-509f-382f-3c1e-e6bfe0fa1001: MDEV: group_id = 10
[  116.297184] Unable to handle kernel paging request for data at address 0x00000030
[  116.297389] Faulting instruction address: 0xd000000007870524
[  116.297465] Oops: Kernel access of bad area, sig: 11 [#1]
[  116.297611] SMP NR_CPUS=2048
[  116.297611] NUMA
[  116.297627] PowerNV
...
[  116.297954] CPU: 33 PID: 7067 Comm: qemu-system-ppc Not tainted 4.10.0-rc5-mdev-test #8
[  116.297993] task: c000000e7718b680 task.stack: c000000e77214000
[  116.298025] NIP: d000000007870524 LR: d000000007870518 CTR: 0000000000000000
[  116.298064] REGS: c000000e77217990 TRAP: 0300   Not tainted  (4.10.0-rc5-mdev-test)
[  116.298103] MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE>
[  116.298107]   CR: 84004444  XER: 00000000
[  116.298154] CFAR: c00000000000888c DAR: 0000000000000030 DSISR: 40000000 SOFTE: 1
               GPR00: d000000007870518 c000000e77217c10 d00000000787b0ed c000000eed2103c0
               GPR04: 0000000000000000 0000000000000000 c000000eed2103e0 0000000f24320000
               GPR08: 0000000000000104 0000000000000001 0000000000000000 d0000000078729b0
               GPR12: c00000000025b7e0 c00000000fe08400 0000000000000001 000001002d31d100
               GPR16: 000001002c22c850 00003ffff315c750 0000000043145680 0000000043141bc0
               GPR20: ffffffffffffffed fffffffffffff000 0000000020003b65 d000000007706018
               GPR24: c000000f16cf0d98 d000000007706000 c000000003f42980 c000000003f42980
               GPR28: c000000f1575ac00 c000000003f429c8 0000000000000000 c000000eed2103c0
[  116.298504] NIP [d000000007870524] tce_iommu_attach_group+0x10c/0x360 [vfio_iommu_spapr_tce]
[  116.298555] LR [d000000007870518] tce_iommu_attach_group+0x100/0x360 [vfio_iommu_spapr_tce]
[  116.298601] Call Trace:
[  116.298610] [c000000e77217c10] [d000000007870518] tce_iommu_attach_group+0x100/0x360 [vfio_iommu_spapr_tce] (unreliable)
[  116.298671] [c000000e77217cb0] [d0000000077033a0] vfio_fops_unl_ioctl+0x278/0x3e0 [vfio]
[  116.298713] [c000000e77217d40] [c0000000002a3ebc] do_vfs_ioctl+0xcc/0x8b0
[  116.298745] [c000000e77217de0] [c0000000002a4700] SyS_ioctl+0x60/0xc0
[  116.298782] [c000000e77217e30] [c00000000000b220] system_call+0x38/0xfc
[  116.298812] Instruction dump:
[  116.298828] 7d3f4b78 409effc8 3d220000 e9298020 3c800140 38a00018 608480c0 e8690028
[  116.298869] 4800249d e8410018 7c7f1b79 41820230 <e93e0030> 2fa90000 419e0114 e9090020
[  116.298914] ---[ end trace 1e10b0ced08b9120 ]---

This patch fixes the oops.

Reported-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Signed-off-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
bgly pushed a commit that referenced this pull request Aug 21, 2017
@bgly
target: Fix transport_init_se_cmd()
d67cae9 
Avoid that aborting a command before it has been submitted onto
a workqueue triggers the following warning:

INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 3 PID: 46 Comm: kworker/u8:1 Not tainted 4.12.0-rc2-dbg+ #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
Workqueue: tmr-iblock target_tmr_work [target_core_mod]
Call Trace:
 dump_stack+0x86/0xcf
 register_lock_class+0xe8/0x570
 __lock_acquire+0xa1/0x11d0
 lock_acquire+0x59/0x80
 flush_work+0x42/0x2b0
 __cancel_work_timer+0x10c/0x180
 cancel_work_sync+0xb/0x10
 core_tmr_lun_reset+0x352/0x740 [target_core_mod]
 target_tmr_work+0xd6/0x130 [target_core_mod]
 process_one_work+0x1ca/0x3f0
 worker_thread+0x49/0x3b0
 kthread+0x109/0x140
 ret_from_fork+0x31/0x40

Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Hannes Reinecke <hare@suse.com>
Cc: David Disseldorp <ddiss@suse.de>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
bgly pushed a commit that referenced this pull request Aug 21, 2017
@bgly
target: Fix node_acl demo-mode + uncached dynamic shutdown regression
0dfc9f9 
This patch fixes a generate_node_acls = 1 + cache_dynamic_acls = 0
regression, that was introduced by

  commit 01d4d67
  Author: Nicholas Bellinger <nab@linux-iscsi.org>
  Date:   Wed Dec 7 12:55:54 2016 -0800

which originally had the proper list_del_init() usage, but was
dropped during list review as it was thought unnecessary by HCH.

However, list_del_init() usage is required during the special
generate_node_acls = 1 + cache_dynamic_acls = 0 case when
transport_free_session() does a list_del(&se_nacl->acl_list),
followed by target_complete_nacl() doing the same thing.

This was manifesting as a general protection fault as reported
by Justin:

kernel: general protection fault: 0000 [#1] SMP
kernel: Modules linked in:
kernel: CPU: 0 PID: 11047 Comm: iscsi_ttx Not tainted 4.13.0-rc2.x86_64.1+ #20
kernel: Hardware name: Intel Corporation S5500BC/S5500BC, BIOS S5500.86B.01.00.0064.050520141428 05/05/2014
kernel: task: ffff88026939e800 task.stack: ffffc90007884000
kernel: RIP: 0010:target_put_nacl+0x49/0xb0
kernel: RSP: 0018:ffffc90007887d70 EFLAGS: 00010246
kernel: RAX: dead000000000200 RBX: ffff8802556ca000 RCX: 0000000000000000
kernel: RDX: dead000000000100 RSI: 0000000000000246 RDI: ffff8802556ce028
kernel: RBP: ffffc90007887d88 R08: 0000000000000001 R09: 0000000000000000
kernel: R10: ffffc90007887df8 R11: ffffea0009986900 R12: ffff8802556ce020
kernel: R13: ffff8802556ce028 R14: ffff8802556ce028 R15: ffffffff88d85540
kernel: FS:  0000000000000000(0000) GS:ffff88027fc00000(0000) knlGS:0000000000000000
kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: CR2: 00007fffe36f5f94 CR3: 0000000009209000 CR4: 00000000003406f0
kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
kernel: Call Trace:
kernel:  transport_free_session+0x67/0x140
kernel:  transport_deregister_session+0x7a/0xc0
kernel:  iscsit_close_session+0x92/0x210
kernel:  iscsit_close_connection+0x5f9/0x840
kernel:  iscsit_take_action_for_connection_exit+0xfe/0x110
kernel:  iscsi_target_tx_thread+0x140/0x1e0
kernel:  ? wait_woken+0x90/0x90
kernel:  kthread+0x124/0x160
kernel:  ? iscsit_thread_get_cpumask+0x90/0x90
kernel:  ? kthread_create_on_node+0x40/0x40
kernel:  ret_from_fork+0x22/0x30
kernel: Code: 00 48 89 fb 4c 8b a7 48 01 00 00 74 68 4d 8d 6c 24 08 4c
89 ef e8 e8 28 43 00 48 8b 93 20 04 00 00 48 8b 83 28 04 00 00 4c 89
ef <48> 89 42 08 48 89 10 48 b8 00 01 00 00 00 00 ad de 48 89 83 20
kernel: RIP: target_put_nacl+0x49/0xb0 RSP: ffffc90007887d70
kernel: ---[ end trace f12821adbfd46fed ]---

To address this, go ahead and use proper list_del_list() for all
cases of se_nacl->acl_list deletion.

Reported-by: Justin Maggard <jmaggard01@gmail.com>
Tested-by: Justin Maggard <jmaggard01@gmail.com>
Cc: Justin Maggard <jmaggard01@gmail.com>
Cc: stable@vger.kernel.org # 4.1+
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
bgly added a commit that referenced this pull request Aug 22, 2017
@bgly
ibmveth: Kernel crash LSO offload flag toggle
07a8b96 
 The following script when run (along with some iperf traffic recreates the crash within 5-10 mins or so).

while true
do
	ethtool -k ibmveth0 | grep tcp-segmentation-offload
	ethtool -K ibmveth0 tso off
	ethtool -k ibmveth0 | grep tcp-segmentation-offload
	ethtool -K ibmveth0 tso on
done

Note: This issue happens the very first time largsesend offload is turned off too (but the above script recreates the issue all the times)

Stack trace output:
 [76563.914380] NIP [c000000000063940] memcpy_power7+0x40/0x800
[76563.914387] LR [d000000000d31788] ibmveth_start_xmit+0x1c8/0x8d0 [ibmveth]
[76563.914392] Call Trace:
[76563.914396] [c0000000feab3270] [c0000000feab32d0] 0xc0000000feab32d0 (unreliable)
[76563.914407] [c0000000feab3360] [c0000000009816f4] dev_hard_start_xmit+0x304/0x530
[76563.914415] [c0000000feab3440] [c0000000009b6564] sch_direct_xmit+0x124/0x330
[76563.914423] [c0000000feab34e0] [c000000000981ddc] __dev_queue_xmit+0x26c/0x770
[76563.914431] [c0000000feab3580] [c000000000a1efc0] arp_xmit+0x30/0xd0
[76563.914438] [c0000000feab35f0] [c000000000a1f0f4] arp_send_dst.part.0+0x94/0xb0
[76563.914445] [c0000000feab3660] [c000000000a1fcb4] arp_solicit+0x114/0x2b0
[76563.914452] [c0000000feab3730] [c00000000098d8f4] neigh_probe+0x84/0xd0
[76563.914460] [c0000000feab3760] [c0000000009937cc] neigh_timer_handler+0xbc/0x320
[76563.914468] [c0000000feab37a0] [c00000000014a3fc] call_timer_fn+0x5c/0x1c0
[76563.914474] [c0000000feab3830] [c00000000014a8bc] run_timer_softirq+0x31c/0x3f0
[76563.914483] [c0000000feab3900] [c0000000000bec58] __do_softirq+0x188/0x3e0
[76563.914490] [c0000000feab39f0] [c0000000000bf128] irq_exit+0xc8/0x100
[76563.914498] [c0000000feab3a10] [c00000000001f974] timer_interrupt+0xa4/0xe0
[76563.914505] [c0000000feab3a40] [c000000000002714] decrementer_common+0x114/0x180

Oops output:
 [76563.914173] Unable to handle kernel paging request for data at address 0x00000000
[76563.914197] Faulting instruction address: 0xc000000000063940
[76563.914205] Oops: Kernel access of bad area, sig: 11 [#1]
[76563.914210] SMP NR_CPUS=2048 NUMA pSeries
[76563.914217] Modules linked in: rpadlpar_io rpaphp dccp_diag dccp tcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag nls_utf8 isofs binfmt_misc pseries_rng rtc_generic autofs4 ibmvfc scsi_transport_fc ibmvscsi ibmveth
[76563.914251] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.4.0-34-generic #53-Ubuntu
[76563.914258] task: c0000000fe9efcc0 ti: c0000000feab0000 task.ti: c0000000feab0000
[76563.914265] NIP: c000000000063940 LR: d000000000d31788 CTR: c000000000064100
[76563.914271] REGS: c0000000feab2ff0 TRAP: 0300   Not tainted  (4.4.0-34-generic)
[76563.914277] MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE>  CR: 4800284e  XER: 0000001a
[76563.914294] CFAR: c000000000008468 DAR: 0000000000000000 DSISR: 42000000 SOFTE: 1
GPR00: 000000000000f240 c0000000feab3270 c0000000015b5d00 0000000000000000
GPR04: c00000000d9b0004 000000000000002a 0000000000000006 c0000000efc0ccac
GPR08: d000000000d3dd28 0000000000000080 0000000000000000 d000000000d34758
GPR12: c000000000064100 c00000000e7f1c80 c0000000ffdca938 0000000000000100
GPR16: c0000000ffdca738 c0000000ffdca538 c0000000feab34a0 c0000000015f4d00
GPR20: 0000000000000000 c0000000015f4cf0 c0000000f5945900 0000000000000000
GPR24: 0000000000000000 0000000080000000 c0000000feab32d0 c0000000efc0ccac
GPR28: c0000000f23ccb00 c0000000f5945000 c0000000f23ccb00 c0000000efc0cc00
[76563.914380] NIP [c000000000063940] memcpy_power7+0x40/0x800
[76563.914387] LR [d000000000d31788] ibmveth_start_xmit+0x1c8/0x8d0 [ibmveth]
[76563.914392] Call Trace:
[76563.914396] [c0000000feab3270] [c0000000feab32d0] 0xc0000000feab32d0 (unreliable)
[76563.914407] [c0000000feab3360] [c0000000009816f4] dev_hard_start_xmit+0x304/0x530
[76563.914415] [c0000000feab3440] [c0000000009b6564] sch_direct_xmit+0x124/0x330
[76563.914423] [c0000000feab34e0] [c000000000981ddc] __dev_queue_xmit+0x26c/0x770
[76563.914431] [c0000000feab3580] [c000000000a1efc0] arp_xmit+0x30/0xd0
[76563.914438] [c0000000feab35f0] [c000000000a1f0f4] arp_send_dst.part.0+0x94/0xb0
[76563.914445] [c0000000feab3660] [c000000000a1fcb4] arp_solicit+0x114/0x2b0
[76563.914452] [c0000000feab3730] [c00000000098d8f4] neigh_probe+0x84/0xd0
[76563.914460] [c0000000feab3760] [c0000000009937cc] neigh_timer_handler+0xbc/0x320
[76563.914468] [c0000000feab37a0] [c00000000014a3fc] call_timer_fn+0x5c/0x1c0
[76563.914474] [c0000000feab3830] [c00000000014a8bc] run_timer_softirq+0x31c/0x3f0
[76563.914483] [c0000000feab3900] [c0000000000bec58] __do_softirq+0x188/0x3e0
[76563.914490] [c0000000feab39f0] [c0000000000bf128] irq_exit+0xc8/0x100
[76563.914498] [c0000000feab3a10] [c00000000001f974] timer_interrupt+0xa4/0xe0
[76563.914505] [c0000000feab3a40] [c000000000002714] decrementer_common+0x114/0x180
[76563.914515] --- interrupt: 901 at plpar_hcall_norets+0x1c/0x28
[76563.914515]     LR = check_and_cede_processor+0x34/0x50
[76563.914525] [c0000000feab3d30] [c000000000916bf0] check_and_cede_processor+0x20/0x50 (unreliable)
[76563.914534] [c0000000feab3d90] [c000000000916e18] shared_cede_loop+0x68/0x170
[76563.914541] [c0000000feab3dd0] [c000000000913e20] cpuidle_enter_state+0x160/0x410
[76563.914549] [c0000000feab3e30] [c000000000119d48] call_cpuidle+0x78/0xd0
[76563.914556] [c0000000feab3e70] [c00000000011a11c] cpu_startup_entry+0x37c/0x480
[76563.914564] [c0000000feab3f30] [c00000000004563c] start_secondary+0x33c/0x360
[76563.914572] [c0000000feab3f90] [c000000000008b6c] start_secondary_prolog+0x10/0x14
[76563.914579] Instruction dump:
[76563.914584] 4185024c 7cc400d0 7cd01120 78c60760 409f0014 88040000 38840001 98030000
[76563.914596] 38630001 409e0014 a0040000 38840002 <b0030000> 38630002 409d0014 80040000
[76563.914613] ---[ end trace 5382b3d78671418e ]---
[76563.916817]
[76565.916870] Kernel panic - not syncing: Fatal exception in interrupt
[76565.919468] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
bgly added a commit that referenced this pull request Sep 19, 2017
@bgly
tcmu: fix crash when removing the tcmu device
447e3e1 
Before the nl REMOVE msg has been sent to the userspace, the ring's
and other resources have been released, but the userspace maybe still
using them. And then we can see the crash messages like:

ring broken, not handling completions
BUG: unable to handle kernel paging request at ffffffffffffffd0
IP: tcmu_handle_completions+0x134/0x2f0 [target_core_user]
PGD 11bdc0c067
P4D 11bdc0c067
PUD 11bdc0e067
PMD 0

Oops: 0000 [#1] SMP
cmd_id not found, ring is broken
RIP: 0010:tcmu_handle_completions+0x134/0x2f0 [target_core_user]
RSP: 0018:ffffb8a2d8983d88 EFLAGS: 00010296
RAX: 0000000000000000 RBX: ffffb8a2aaa4e000 RCX: 00000000ffffffff
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000220
R10: 0000000076c71401 R11: ffff8d2e76c713f0 R12: ffffb8a2aad56bc0
R13: 000000000000001c R14: ffff8d2e32c90000 R15: ffff8d2e76c713f0
FS:  00007f411ffff700(0000) GS:ffff8d1e7fdc0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffffffffd0 CR3: 0000001027070000 CR4:
00000000001406e0
Call Trace:
? tcmu_irqcontrol+0x2a/0x40 [target_core_user]
? uio_write+0x7b/0xc0 [uio]
? __vfs_write+0x37/0x150
? __getnstimeofday64+0x3b/0xd0
? vfs_write+0xb2/0x1b0
? syscall_trace_enter+0x1d0/0x2b0
? SyS_write+0x55/0xc0
? do_syscall_64+0x67/0x150
? entry_SYSCALL64_slow_path+0x25/0x25
Code: 41 5d 41 5e 41 5f 5d c3 83 f8 01 0f 85 cf 01 00
00 48 8b 7d d0 e8 dd 5c 1d f3 41 0f b7 74 24 04 48 8b
7d c8 31 d2 e8 5c c7 1b f3 <48> 8b 7d d0 49 89 c7 c6 07
00 0f 1f 40 00 4d 85 ff 0f 84 82 01  RIP:
tcmu_handle_completions+0x134/0x2f0 [target_core_user]
RSP: ffffb8a2d8983d88
CR2: ffffffffffffffd0

And the crash also could happen in tcmu_page_fault and other places.

Signed-off-by: Zhang Zhuoyu <zhangzhuoyu@cmss.chinamobile.com>
Signed-off-by: Xiubo Li <lixiubo@cmss.chinamobile.com>
bgly added a commit that referenced this pull request Sep 19, 2017
@bgly
tcmu: fix crash when removing the tcmu device
8c8494a 
Before the nl REMOVE msg has been sent to the userspace, the ring's
and other resources have been released, but the userspace maybe still
using them. And then we can see the crash messages like:

ring broken, not handling completions
BUG: unable to handle kernel paging request at ffffffffffffffd0
IP: tcmu_handle_completions+0x134/0x2f0 [target_core_user]
PGD 11bdc0c067
P4D 11bdc0c067
PUD 11bdc0e067
PMD 0

Oops: 0000 [#1] SMP
cmd_id not found, ring is broken
RIP: 0010:tcmu_handle_completions+0x134/0x2f0 [target_core_user]
RSP: 0018:ffffb8a2d8983d88 EFLAGS: 00010296
RAX: 0000000000000000 RBX: ffffb8a2aaa4e000 RCX: 00000000ffffffff
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000220
R10: 0000000076c71401 R11: ffff8d2e76c713f0 R12: ffffb8a2aad56bc0
R13: 000000000000001c R14: ffff8d2e32c90000 R15: ffff8d2e76c713f0
FS:  00007f411ffff700(0000) GS:ffff8d1e7fdc0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffffffffd0 CR3: 0000001027070000 CR4:
00000000001406e0
Call Trace:
? tcmu_irqcontrol+0x2a/0x40 [target_core_user]
? uio_write+0x7b/0xc0 [uio]
? __vfs_write+0x37/0x150
? __getnstimeofday64+0x3b/0xd0
? vfs_write+0xb2/0x1b0
? syscall_trace_enter+0x1d0/0x2b0
? SyS_write+0x55/0xc0
? do_syscall_64+0x67/0x150
? entry_SYSCALL64_slow_path+0x25/0x25
Code: 41 5d 41 5e 41 5f 5d c3 83 f8 01 0f 85 cf 01 00
00 48 8b 7d d0 e8 dd 5c 1d f3 41 0f b7 74 24 04 48 8b
7d c8 31 d2 e8 5c c7 1b f3 <48> 8b 7d d0 49 89 c7 c6 07
00 0f 1f 40 00 4d 85 ff 0f 84 82 01  RIP:
tcmu_handle_completions+0x134/0x2f0 [target_core_user]
RSP: ffffb8a2d8983d88
CR2: ffffffffffffffd0

And the crash also could happen in tcmu_page_fault and other places.

Signed-off-by: Zhang Zhuoyu <zhangzhuoyu@cmss.chinamobile.com>
Signed-off-by: Xiubo Li <lixiubo@cmss.chinamobile.com>
bgly added a commit that referenced this pull request Sep 19, 2017
@bgly
tcmu: fix crash when removing the tcmu device
2c8d523 
Before the nl REMOVE msg has been sent to the userspace, the ring's
and other resources have been released, but the userspace maybe still
using them. And then we can see the crash messages like:

ring broken, not handling completions
BUG: unable to handle kernel paging request at ffffffffffffffd0
IP: tcmu_handle_completions+0x134/0x2f0 [target_core_user]
PGD 11bdc0c067
P4D 11bdc0c067
PUD 11bdc0e067
PMD 0

Oops: 0000 [#1] SMP
cmd_id not found, ring is broken
RIP: 0010:tcmu_handle_completions+0x134/0x2f0 [target_core_user]
RSP: 0018:ffffb8a2d8983d88 EFLAGS: 00010296
RAX: 0000000000000000 RBX: ffffb8a2aaa4e000 RCX: 00000000ffffffff
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000220
R10: 0000000076c71401 R11: ffff8d2e76c713f0 R12: ffffb8a2aad56bc0
R13: 000000000000001c R14: ffff8d2e32c90000 R15: ffff8d2e76c713f0
FS:  00007f411ffff700(0000) GS:ffff8d1e7fdc0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffffffffd0 CR3: 0000001027070000 CR4:
00000000001406e0
Call Trace:
? tcmu_irqcontrol+0x2a/0x40 [target_core_user]
? uio_write+0x7b/0xc0 [uio]
? __vfs_write+0x37/0x150
? __getnstimeofday64+0x3b/0xd0
? vfs_write+0xb2/0x1b0
? syscall_trace_enter+0x1d0/0x2b0
? SyS_write+0x55/0xc0
? do_syscall_64+0x67/0x150
? entry_SYSCALL64_slow_path+0x25/0x25
Code: 41 5d 41 5e 41 5f 5d c3 83 f8 01 0f 85 cf 01 00
00 48 8b 7d d0 e8 dd 5c 1d f3 41 0f b7 74 24 04 48 8b
7d c8 31 d2 e8 5c c7 1b f3 <48> 8b 7d d0 49 89 c7 c6 07
00 0f 1f 40 00 4d 85 ff 0f 84 82 01  RIP:
tcmu_handle_completions+0x134/0x2f0 [target_core_user]
RSP: ffffb8a2d8983d88
CR2: ffffffffffffffd0

And the crash also could happen in tcmu_page_fault and other places.

Signed-off-by: Zhang Zhuoyu <zhangzhuoyu@cmss.chinamobile.com>
Signed-off-by: Xiubo Li <lixiubo@cmss.chinamobile.com>
bgly added a commit that referenced this pull request Nov 8, 2017
@bgly
Squashed commit of the following:
4054d83 
commit 80ad406dc1f29f1e6924b5c850c614168abcf081
Author: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Date:   Tue Oct 10 08:56:58 2017 -0300

    UBUNTU: Ubuntu-4.4.0-98.121

    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit c8f09013b02fc4f19916a7d429014718adf4e53b
Author: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
Date:   Wed Sep 27 17:23:49 2017 -0300

    UBUNTU: d/s/m/insert-ubuntu-changes: use full version numbers

    Ignore: yes

    Make insert-ubuntu-changes to consider full version numbers when looping
    through debian.master/changelog entries and comparing the version number
    of each entry with the arguments passed to the script to decide which
    entries should be included in the output changelog file.

    Previously, only the last number in the version was used in this
    comparison. For example, when comparing 4.4.0-50.51 and 4.4.0-83.84 only
    the numbers 51 and 84 were actually used in the comparison. That however
    might not work properly when the major version is bumped.

    For instance, using "end" as 4.4.0-50.51 and "start" as 4.4.0-83.84 used
    to work fine because 84 is greater than 51. However when using "end"
    as 4.11.0-10.11 and "start" as 4.13.0-2.3, no entry was being selected
    since 3 is not greater than 11.

    Signed-off-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
    Acked-by: Stefan Bader <stefan.bader@canonical.com>
    Acked-by: Kamal Mostafa <kamal@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit 6c4fa18da50ecc184055e56a0acfe74942081b3c
Author: Yadan Fan <ydfan@suse.com>
Date:   Fri Oct 6 16:32:58 2017 -0400

    scsi: hpsa: limit transfer length to 1MB

    BugLink: https://bugs.launchpad.net/bugs/1720359

    The hpsa firmware will bypass the cache for any request larger than 1MB,
    so we should cap the request size to avoid any performance degradation
    in kernels later than v4.3

    This degradation is caused from d2be537c3ba3568acd79cd178327b842e60d035e,
    which changed max_sectors_kb to 1280k, but the hardware is able to work
    fine with it, so the true fix should be from hpsa driver.

    Signed-off-by: Yadan Fan <ydfan@suse.com>
    Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
    Acked-by: Don Brace <don.brace@microsemi.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    (cherry picked from commit e2c7b433f729cedb32514480af8cbdf2fe5cf264)
    Signed-off-by: Eric Desrochers <eric.desrochers@canonical.com>
    Acked-by: Stefan Bader <stefan.bader@canonical.com>
    Acked-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit 688c168ef8fd7d5a140864aadb50f8f23a0a0fe0
Author: hayeswang <hayeswang@realtek.com>
Date:   Thu Oct 5 10:19:22 2017 +0800

    r8152: fix the list rx_done may be used without initialization

    BugLink: http://bugs.launchpad.net/bugs/1720977

    The list rx_done would be initialized when the linking on occurs.
    Therefore, if a napi is scheduled without any linking on before,
    the following kernel panic would happen.

    	BUG: unable to handle kernel NULL pointer dereference at 000000000000008
    	IP: [<ffffffffc085efde>] r8152_poll+0xe1e/0x1210 [r8152]
    	PGD 0
    	Oops: 0002 [#1] SMP

    Signed-off-by: Hayes Wang <hayeswang@realtek.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    (cherry picked from commit 98d068ab52b4b11d403995ed14154660797e7136)
    Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
    Acked-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
    Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit e8ddfc4680cdfba5ba20579fa8f504570583fd4c
Author: Vinson Lee <vlee@freedesktop.org>
Date:   Fri Sep 29 22:42:52 2017 +0000

    UBUNTU: d-i: Add bnxt_en to nic-modules.

    BugLink: http://bugs.launchpad.net/bugs/1720466

    Signed-off-by: Vinson Lee <vlee@freedesktop.org>
    Acked-by: Seth Forshee <seth.forshee@canonical.com>
    Acked-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit 1ab5e52e52437c3ed12ceeb6d8c4198e5b767450
Author: Paolo Pisati <paolo.pisati@canonical.com>
Date:   Fri Sep 22 11:11:57 2017 +0200

    UBUNTU: snapcraft.yaml: add dpkg-dev to the build deps

    BugLink: http://bugs.launchpad.net/bugs/1718886

    Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
    Acked-by: Stefan Bader <stefan.bader@canonical.com>
    Acked-by: Kamal Mostafa <kamal@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit 17b4c108e3eabb5ab5bb3f407725d2cac731c2e1
Author: Weifeng Voon <weifeng.voon@intel.com>
Date:   Thu Sep 21 13:03:57 2017 +0800

    i2c: designware: Use transfer timeout from ioctl I2C_TIMEOUT

    BugLink: https://bugs.launchpad.net/bugs/1718578

    This allows applications to set the transfer timeout in 10ms increments via
    ioctl I2C_TIMEOUT.

    Signed-off-by: Weifeng Voon <weifeng.voon@intel.com>
    Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
    Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    (cherry picked from commit d0bcd8df9aea2bcdbfcb074d408bdc7136031bc5)
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Acked-by: Shrirang Bagul <shrirang.bagul@canonical.com>
    Acked-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit 63b70075e5005762da11c975d3900e9997cd70ae
Author: Ewan D. Milne <emilne@redhat.com>
Date:   Wed Sep 20 15:12:56 2017 -0400

    scsi: ses: Fix SAS device detection in enclosure

    BugLink: http://bugs.launchpad.net/bugs/1693369

    The call to scsi_is_sas_rphy() needs to be made on the SAS end_device,
    not on the SCSI device.

    Fixes: 835831c57e9b ("ses: use scsi_is_sas_rphy instead of is_sas_attached")
    Signed-off-by: Ewan D. Milne <emilne@redhat.com>
    Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
    Reviewed-by: James Bottomley <James.Bottomley@HansenPartnership.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    (back ported from commit 9373eba6cfae48911b977d14323032cd5d161aae)
    Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
    Acked-by: Stefan Bader <stefan.bader@canonical.com>
    Acked-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit 908c4745b591ea3e545a74e44a5c176a599054e3
Author: Johannes Thumshirn <jthumshirn@suse.de>
Date:   Wed Sep 20 15:12:55 2017 -0400

    scsi: sas: provide stub implementation for scsi_is_sas_rphy

    BugLink: http://bugs.launchpad.net/bugs/1693369

    Provide a stub implementation for scsi_is_sas_rphy for kernel
    configurations which do not have CONFIG_SCSI_SAS_ATTRS defined.

    Reported-by: kbuild test robot <lkp@intel.com>
    Suggested-by: James Bottomley <jejb@linux.vnet.ibm.com>
    Reviewed-by: James E.J. Bottomley <jejb@linux.vnet.ibm.com>
    Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    (back ported from commit c1a23f6d64552b4480208aa584ec7e9c13d6d9c3)
    Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
    Acked-by: Stefan Bader <stefan.bader@canonical.com>
    Acked-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit 19a501eec44c3ed9525b3b6991a21a83d702ecd4
Author: James Bottomley <James.Bottomley@HansenPartnership.com>
Date:   Wed Sep 20 15:12:54 2017 -0400

    ses: fix discovery of SATA devices in SAS enclosures

    BugLink: http://bugs.launchpad.net/bugs/1693369

    The current discovery routines use the VPD 0x83 inquiry page to find
    the device SAS address and match it to the end point in the enclosure.
    This doesn't work for SATA devices because expanders (or hosts) simply
    make up an endpoint address for STP and thus the address returned by
    the VPD page never matches.  Instead of doing this, for SAS attached
    devices, match by the direct endpoint address instead.

    Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
    (cherry picked from commit 3f8d6f2a0797e8c650a47e5c1b5c2601a46f4293)
    Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
    Acked-by: Stefan Bader <stefan.bader@canonical.com>
    Acked-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit ec384fb9948065e0e1b84d9ecaebda228a590816
Author: James Bottomley <James.Bottomley@HansenPartnership.com>
Date:   Wed Sep 20 15:12:53 2017 -0400

    scsi_transport_sas: add function to get SAS endpoint address

    BugLink: http://bugs.launchpad.net/bugs/1693369

    For a device known to be SAS connected, this will return the endpoint
    address.  This is useful for getting the SAS address of SATA devices.

    Reviewed-by: Hannes Reinecke <hare@suse.com>
    Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
    (cherry picked from commit bcf508c13385e74972f5cc06d8471d5c100395b0)
    Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
    Acked-by: Stefan Bader <stefan.bader@canonical.com>
    Acked-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit 6a03f9bee206347b812585ef5737f1eae6ae1a89
Author: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
Date:   Wed Sep 20 11:55:28 2017 -0300

    fs: aio: fix the increment of aio-nr and counting against aio-max-nr

    BugLink: http://bugs.launchpad.net/bugs/1718397

    Currently, aio-nr is incremented in steps of 'num_possible_cpus() * 8'
    for io_setup(nr_events, ..) with 'nr_events < num_possible_cpus() * 4':

        ioctx_alloc()
        ...
            nr_events = max(nr_events, num_possible_cpus() * 4);
            nr_events *= 2;
        ...
            ctx->max_reqs = nr_events;
        ...
            aio_nr += ctx->max_reqs;
        ....

    This limits the number of aio contexts actually available to much less
    than aio-max-nr, and is increasingly worse with greater number of CPUs.

    For example, with 64 CPUs, only 256 aio contexts are actually available
    (with aio-max-nr = 65536) because the increment is 512 in that scenario.

    Note: 65536 [max aio contexts] / (64*4*2) [increment per aio context]
    is 128, but make it 256 (double) as counting against 'aio-max-nr * 2':

        ioctx_alloc()
        ...
            if (aio_nr + nr_events > (aio_max_nr * 2UL) ||
            ...
                goto err_ctx;
        ...

    This patch uses the original value of nr_events (from userspace) to
    increment aio-nr and count against aio-max-nr, which resolves those.

    Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
    Reported-by: Lekshmi C. Pillai <lekshmi.cpillai@in.ibm.com>
    Tested-by: Lekshmi C. Pillai <lekshmi.cpillai@in.ibm.com>
    Tested-by: Paul Nguyen <nguyenp@us.ibm.com>
    Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
    Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
    (cherry picked from commit 2a8a98673c13cb2a61a6476153acf8344adfa992)
    Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
    Acked-by: Seth Forshee <seth.forshee@canonical.com>
    Acked-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit 66a7f616d2cc10fc526b92ce2ee5bcbb911ded54
Author: Shrirang Bagul <shrirang.bagul@canonical.com>
Date:   Thu Oct 5 15:45:01 2017 +0800

    UBUNTU: SAUCE: USB: serial: qcserial: add Dell DW5818, DW5819

    BugLink: http://bugs.launchpad.net/bugs/1721455

    Dell Wireless 5819/5818 devices are re-branded Sierra Wireless MC74
    series which will by default boot with vid 0x413c and pid's 0x81cf,
    0x81d0, 0x81d1,0x81d2.

    Signed-off-by: Shrirang Bagul <shrirang.bagul@canonical.com>
    Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
    Acked-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit cbfc1a9519f86210fc84dbb90b49b8d23a2e92a9
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Oct 5 16:31:25 2017 +0800

    xen-blkback: don't leak stack data via response ring

    Rather than constructing a local structure instance on the stack, fill
    the fields directly on the shared ring, just like other backends do.
    Build on the fact that all response structure flavors are actually
    identical (the old code did make this assumption too).

    This is XSA-216.

    Cc: stable@vger.kernel.org

    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

    CVE-2017-10911

    (backported from commit 089bc0143f489bd3a4578bdff5f4ca68fb26f341)
    Signed-off-by: Shrirang Bagul <shrirang.bagul@canonical.com>
    Acked-by: Stefan Bader <stefan.bader@canonical.com>
    Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit 643be1b19d3fccb9bfaa43dac91b31de0f4752e2
Author: Tyler Hicks <tyhicks@canonical.com>
Date:   Fri Oct 6 04:43:49 2017 +0000

    seccomp: Action to log before allowing

    BugLink: https://launchpad.net/bugs/1567597

    Add a new action, SECCOMP_RET_LOG, that logs a syscall before allowing
    the syscall. At the implementation level, this action is identical to
    the existing SECCOMP_RET_ALLOW action. However, it can be very useful when
    initially developing a seccomp filter for an application. The developer
    can set the default action to be SECCOMP_RET_LOG, maybe mark any
    obviously needed syscalls with SECCOMP_RET_ALLOW, and then put the
    application through its paces. A list of syscalls that triggered the
    default action (SECCOMP_RET_LOG) can be easily gleaned from the logs and
    that list can be used to build the syscall whitelist. Finally, the
    developer can change the default action to the desired value.

    This provides a more friendly experience than seeing the application get
    killed, then updating the filter and rebuilding the app, seeing the
    application get killed due to a different syscall, then updating the
    filter and rebuilding the app, etc.

    The functionality is similar to what's supported by the various LSMs.
    SELinux has permissive mode, AppArmor has complain mode, SMACK has
    bring-up mode, etc.

    SECCOMP_RET_LOG is given a lower value than SECCOMP_RET_ALLOW as allow
    while logging is slightly more restrictive than quietly allowing.

    Unfortunately, the tests added for SECCOMP_RET_LOG are not capable of
    inspecting the audit log to verify that the syscall was logged.

    With this patch, the logic for deciding if an action will be logged is:

    if action == RET_ALLOW:
      do not log
    else if action == RET_KILL && RET_KILL in actions_logged:
      log
    else if action == RET_LOG && RET_LOG in actions_logged:
      log
    else if filter-requests-logging && action in actions_logged:
      log
    else if audit_enabled && process-is-being-audited:
      log
    else:
      do not log

    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    (backported from commit 59f5cf44a38284eb9e76270c786fb6cc62ef8ac4)
    Acked-by: Stefan Bader <stefan.bader@canonical.com>
    Acked-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit 854381716daaa1a9fe488c979b29502260f4ce6a
Author: Tyler Hicks <tyhicks@canonical.com>
Date:   Fri Oct 6 04:43:48 2017 +0000

    seccomp: Filter flag to log all actions except SECCOMP_RET_ALLOW

    BugLink: https://launchpad.net/bugs/1721676

    Add a new filter flag, SECCOMP_FILTER_FLAG_LOG, that enables logging for
    all actions except for SECCOMP_RET_ALLOW for the given filter.

    SECCOMP_RET_KILL actions are always logged, when "kill" is in the
    actions_logged sysctl, and SECCOMP_RET_ALLOW actions are never logged,
    regardless of this flag.

    This flag can be used to create noisy filters that result in all
    non-allowed actions to be logged. A process may have one noisy filter,
    which is loaded with this flag, as well as a quiet filter that's not
    loaded with this flag. This allows for the actions in a set of filters
    to be selectively conveyed to the admin.

    Since a system could have a large number of allocated seccomp_filter
    structs, struct packing was taken in consideration. On 64 bit x86, the
    new log member takes up one byte of an existing four byte hole in the
    struct. On 32 bit x86, the new log member creates a new four byte hole
    (unavoidable) and consumes one of those bytes.

    Unfortunately, the tests added for SECCOMP_FILTER_FLAG_LOG are not
    capable of inspecting the audit log to verify that the actions taken in
    the filter were logged.

    With this patch, the logic for deciding if an action will be logged is:

    if action == RET_ALLOW:
      do not log
    else if action == RET_KILL && RET_KILL in actions_logged:
      log
    else if filter-requests-logging && action in actions_logged:
      log
    else if audit_enabled && process-is-being-audited:
      log
    else:
      do not log

    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    (backported from commit e66a39977985b1e69e17c4042cb290768eca9b02)
    [tyhicks: disabled ability to log SECCOMP_RET_TRACE due to code changes]
    Acked-by: Stefan Bader <stefan.bader@canonical.com>
    Acked-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit 893f00af1f5d12e17b2a41dcfdaa4498855954a1
Author: Tyler Hicks <tyhicks@canonical.com>
Date:   Fri Oct 6 04:43:47 2017 +0000

    seccomp: Selftest for detection of filter flag support

    BugLink: https://launchpad.net/bugs/1721676
    BugLink: https://launchpad.net/bugs/1567597

    Userspace needs to be able to reliably detect the support of a filter
    flag. A good way of doing that is by attempting to enter filter mode,
    with the flag bit(s) in question set, and a NULL pointer for the args
    parameter of seccomp(2). EFAULT indicates that the flag is valid and
    EINVAL indicates that the flag is invalid.

    This patch adds a selftest that can be used to test this method of
    detection in userspace.

    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    (cherry picked from commit 2b7ea5b5b5799f2878ed454bb48032bed6d101d3)
    Acked-by: Stefan Bader <stefan.bader@canonical.com>
    Acked-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit c8a22a5f2af9b6484b9730e8ef5ced834d15d803
Author: Tyler Hicks <tyhicks@canonical.com>
Date:   Fri Oct 6 04:43:46 2017 +0000

    seccomp: Sysctl to configure actions that are allowed to be logged

    BugLink: https://launchpad.net/bugs/1721676
    BugLink: https://launchpad.net/bugs/1567597

    Adminstrators can write to this sysctl to set the seccomp actions that
    are allowed to be logged. Any actions not found in this sysctl will not
    be logged.

    For example, all SECCOMP_RET_KILL, SECCOMP_RET_TRAP, and
    SECCOMP_RET_ERRNO actions would be loggable if "kill trap errno" were
    written to the sysctl. SECCOMP_RET_TRACE actions would not be logged
    since its string representation ("trace") wasn't present in the sysctl
    value.

    The path to the sysctl is:

     /proc/sys/kernel/seccomp/actions_logged

    The actions_avail sysctl can be read to discover the valid action names
    that can be written to the actions_logged sysctl with the exception of
    "allow". SECCOMP_RET_ALLOW actions cannot be configured for logging.

    The default setting for the sysctl is to allow all actions to be logged
    except SECCOMP_RET_ALLOW. While only SECCOMP_RET_KILL actions are
    currently logged, an upcoming patch will allow applications to request
    additional actions to be logged.

    There's one important exception to this sysctl. If a task is
    specifically being audited, meaning that an audit context has been
    allocated for the task, seccomp will log all actions other than
    SECCOMP_RET_ALLOW despite the value of actions_logged. This exception
    preserves the existing auditing behavior of tasks with an allocated
    audit context.

    With this patch, the logic for deciding if an action will be logged is:

    if action == RET_ALLOW:
      do not log
    else if action == RET_KILL && RET_KILL in actions_logged:
      log
    else if audit_enabled && task-is-being-audited:
      log
    else:
      do not log

    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    (backported from commit 0ddec0fc8900201c0897b87b762b7c420436662f)
    Acked-by: Stefan Bader <stefan.bader@canonical.com>
    Acked-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit 4ae31a2fb2f5c8a810887ab6e1e0226fb478aaf7
Author: Tyler Hicks <tyhicks@canonical.com>
Date:   Fri Oct 6 04:43:45 2017 +0000

    seccomp: Operation for checking if an action is available

    BugLink: https://launchpad.net/bugs/1721676
    BugLink: https://launchpad.net/bugs/1567597

    Userspace code that needs to check if the kernel supports a given action
    may not be able to use the /proc/sys/kernel/seccomp/actions_avail
    sysctl. The process may be running in a sandbox and, therefore,
    sufficient filesystem access may not be available. This patch adds an
    operation to the seccomp(2) syscall that allows userspace code to ask
    the kernel if a given action is available.

    If the action is supported by the kernel, 0 is returned. If the action
    is not supported by the kernel, -1 is returned with errno set to
    -EOPNOTSUPP. If this check is attempted on a kernel that doesn't support
    this new operation, -1 is returned with errno set to -EINVAL meaning
    that userspace code will have the ability to differentiate between the
    two error cases.

    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Suggested-by: Andy Lutomirski <luto@amacapital.net>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    (backported from commit d612b1fd8010d0d67b5287fe146b8b55bcbb8655)
    Acked-by: Stefan Bader <stefan.bader@canonical.com>
    Acked-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit aac883e7a2c96921e885b43db10fa1a70b624a39
Author: Tyler Hicks <tyhicks@canonical.com>
Date:   Fri Oct 6 04:43:44 2017 +0000

    seccomp: Sysctl to display available actions

    BugLink: https://launchpad.net/bugs/1721676
    BugLink: https://launchpad.net/bugs/1567597

    This patch creates a read-only sysctl containing an ordered list of
    seccomp actions that the kernel supports. The ordering, from left to
    right, is the lowest action value (kill) to the highest action value
    (allow). Currently, a read of the sysctl file would return "kill trap
    errno trace allow". The contents of this sysctl file can be useful for
    userspace code as well as the system administrator.

    The path to the sysctl is:

      /proc/sys/kernel/seccomp/actions_avail

    libseccomp and other userspace code can easily determine which actions
    the current kernel supports. The set of actions supported by the current
    kernel may be different than the set of action macros found in kernel
    headers that were installed where the userspace code was built.

    In addition, this sysctl will allow system administrators to know which
    actions are supported by the kernel and make it easier to configure
    exactly what seccomp logs through the audit subsystem. Support for this
    level of logging configuration will come in a future patch.

    Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    (backported from commit 8e5f1ad116df6b0de65eac458d5e7c318d1c05af)
    Acked-by: Stefan Bader <stefan.bader@canonical.com>
    Acked-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit 806b808512d66cbce45068ce5bb47d76d52ced94
Author: Kees Cook <keescook@chromium.org>
Date:   Fri Oct 6 04:43:43 2017 +0000

    seccomp: Provide matching filter for introspection

    BugLink: https://launchpad.net/bugs/1721676
    BugLink: https://launchpad.net/bugs/1567597

    Both the upcoming logging improvements and changes to RET_KILL will need
    to know which filter a given seccomp return value originated from. In
    order to delay logic processing of result until after the seccomp loop,
    this adds a single pointer assignment on matches. This will allow both
    log and RET_KILL logic to work off the filter rather than doing more
    expensive tests inside the time-critical run_filters loop.

    Running tight cycles of getpid() with filters attached shows no measurable
    difference in speed.

    Suggested-by: Tyler Hicks <tyhicks@canonical.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
    (backported from commit deb4de8b31bc5bf21efb6ac31150a01a631cd647)
    Acked-by: Stefan Bader <stefan.bader@canonical.com>
    Acked-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit 9e189a1bed487edd84687e73d564c4c4a6ba20a1
Author: Wen-chien Jesse Sung <jesse.sung@canonical.com>
Date:   Fri Oct 6 09:19:06 2017 +0200

    UBUNTU: SAUCE: update OpenNSL kernel modules to 6.5.10

    BugLink: https://launchpad.net/bugs/1721511

    The new version can be found at OpenNSL git repo:
    https://github.com/Broadcom-Switch/OpenNSL/tree/v3.4.1.5

    Signed-off-by: Wen-chien Jesse Sung <jesse.sung@canonical.com>
    Acked-by: Juerg Haefliger <juerg.haefliger@canonical.com>
    Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
    Signed-off-by: Juerg Haefliger <juerg.haefliger@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit 01683e9fc6cf52b1e2739b6fcabdec54aa7c784d
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Oct 5 09:41:59 2017 +0200

    Linux 4.4.90

    BugLink: http://bugs.launchpad.net/bugs/1721550

    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit d5cd768afa0fead38412c45b55fce30f7620cf2b
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Oct 4 15:51:29 2017 +0200

    fix xen_swiotlb_dma_mmap prototype

    BugLink: http://bugs.launchpad.net/bugs/1721550

    xen_swiotlb_dma_mmap was backported from v4.10, but older
    kernels before commit 00085f1efa38 ("dma-mapping: use unsigned long
    for dma_attrs") use a different signature:

    arm/xen/mm.c:202:10: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
      .mmap = xen_swiotlb_dma_mmap,
              ^~~~~~~~~~~~~~~~~~~~
    arm/xen/mm.c:202:10: note: (near initialization for 'xen_swiotlb_dma_ops.mmap')

    This adapts the patch to the old calling conventions.

    Fixes: "swiotlb-xen: implement xen_swiotlb_dma_mmap callback"
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit 37012690c95f902d06d41df589566362949f6585
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Tue Feb 7 19:58:02 2017 +0200

    swiotlb-xen: implement xen_swiotlb_dma_mmap callback

    BugLink: http://bugs.launchpad.net/bugs/1721550

    commit 7e91c7df29b5e196de3dc6f086c8937973bd0b88 upstream.

    This function creates userspace mapping for the DMA-coherent memory.

    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
    Signed-off-by: Andrii Anisov <andrii_anisov@epam.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit 354452b1340fd93c9c61f89d9f02567c906c1c67
Author: Vladis Dronov <vdronov@redhat.com>
Date:   Mon Sep 4 16:00:50 2017 +0200

    video: fbdev: aty: do not leak uninitialized padding in clk to userspace

    BugLink: http://bugs.launchpad.net/bugs/1721550

    commit 8e75f7a7a00461ef6d91797a60b606367f6e344d upstream.

    'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
    field unitialized, leaking data from the stack. Fix this ensuring all of
    'clk' is initialized to zero.

    References: https://github.com/torvalds/linux/pull/441
    Reported-by: sohu0106 <sohu0106@126.com>
    Signed-off-by: Vladis Dronov <vdronov@redhat.com>
    Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit f73d047ff53a3888c8f0f819e30fde14bdb3869c
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Thu Sep 28 17:58:41 2017 +0200

    KVM: VMX: use cmpxchg64

    BugLink: http://bugs.launchpad.net/bugs/1721550

    commit c0a1666bcb2a33e84187a15eabdcd54056be9a97 upstream.

    This fixes a compilation failure on 32-bit systems.

    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit 8185a7db5ef3faad2f7673c475664bcec719d2ac
Author: Robert Jarzmik <robert.jarzmik@free.fr>
Date:   Wed Mar 9 00:46:11 2016 +0100

    ARM: pxa: fix the number of DMA requestor lines

    BugLink: http://bugs.launchpad.net/bugs/1721550

    commit 4c35430ad18f5a034302cb90e559ede5a27f93b9 upstream.

    The number of requestor lines was clamped to 0 for all pxa architectures
    in the requestor declaration. Fix this by using the value.

    Fixes: 72b195cb7162 ("ARM: pxa: add the number of DMA requestor lines")
    Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit e2a32f50ee1e3559bfc9b9dec467f53de79f21ab
Author: Robert Jarzmik <robert.jarzmik@free.fr>
Date:   Mon Feb 15 21:57:47 2016 +0100

    ARM: pxa: add the number of DMA requestor lines

    BugLink: http://bugs.launchpad.net/bugs/1721550

    commit 72b195cb716284217e8b270af420bc7e5cf04b3c upstream.

    Declare the number of DMA requestor lines per platform :
     - for pxa25x: 40 requestor lines
     - for pxa27x: 75 requestor lines
     - for pxa3xx: 100 requestor lines

    This information will be used to activate the DMA flow control or not.

    Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit 41a0602031127e53d2d33589a8f324fda85a2bd5
Author: Robert Jarzmik <robert.jarzmik@free.fr>
Date:   Mon Feb 15 21:57:46 2016 +0100

    dmaengine: mmp-pdma: add number of requestors

    BugLink: http://bugs.launchpad.net/bugs/1721550

    commit c283e41ef32442f41e7180f9bb1c5aedf9255bfe upstream.

    The DMA chip has a fixed number of requestor lines used for flow
    control. This number is platform dependent. The pxa_dma dma driver will
    use this value to activate or not the flow control.

    There won't be any impact on mmp_pdma driver.

    Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit d16597b8c4f0ca0c952b124f8f49b61152c98be0
Author: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Date:   Wed Aug 30 12:15:49 2017 +0200

    cxl: Fix driver use count

    BugLink: http://bugs.launchpad.net/bugs/1721550

    commit 197267d0356004a31c4d6b6336598f5dff3301e1 upstream.

    cxl keeps a driver use count, which is used with the hash memory model
    on p8 to know when to upgrade local TLBIs to global and to trigger
    callbacks to manage the MMU for PSL8.

    If a process opens a context and closes without attaching or fails the
    attachment, the driver use count is never decremented. As a
    consequence, TLB invalidations remain global, even if there are no
    active cxl contexts.

    We should increment the driver use count when the process is attaching
    to the cxl adapter, and not on open. It's not needed before the
    adapter starts using the context and the use count is decremented on
    the detach path, so it makes more sense.

    It affects only the user api. The kernel api is already doing The
    Right Thing.

    Signed-off-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
    Fixes: 7bb5d91a4dda ("cxl: Rework context lifetimes")
    Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    [ajd: backport to stable v4.4 tree]
    Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit 5510c743e2ebfe4392e94bdee32b140ef82615df
Author: Haozhong Zhang <haozhong.zhang@intel.com>
Date:   Mon Sep 18 09:56:50 2017 +0800

    KVM: VMX: remove WARN_ON_ONCE in kvm_vcpu_trigger_posted_interrupt

    BugLink: http://bugs.launchpad.net/bugs/1721550

    commit 5753743fa5108b8f98bd61e40dc63f641b26c768 upstream.

    WARN_ON_ONCE(pi_test_sn(&vmx->pi_desc)) in kvm_vcpu_trigger_posted_interrupt()
    intends to detect the violation of invariant that VT-d PI notification
    event is not suppressed when vcpu is in the guest mode. Because the
    two checks for the target vcpu mode and the target suppress field
    cannot be performed atomically, the target vcpu mode may change in
    between. If that does happen, WARN_ON_ONCE() here may raise false
    alarms.

    As the previous patch fixed the real invariant breaker, remove this
    WARN_ON_ONCE() to avoid false alarms, and document the allowed cases
    instead.

    Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com>
    Reported-by: "Ramamurthy, Venkatesh" <venkatesh.ramamurthy@intel.com>
    Reported-by: Dan Williams <dan.j.williams@intel.com>
    Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
    Fixes: 28b835d60fcc ("KVM: Update Posted-Interrupts Descriptor when vCPU is preempted")
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit 5c2898624597f0e0f925d0258529bb3602b759e4
Author: Haozhong Zhang <haozhong.zhang@intel.com>
Date:   Mon Sep 18 09:56:49 2017 +0800

    KVM: VMX: do not change SN bit in vmx_update_pi_irte()

    BugLink: http://bugs.launchpad.net/bugs/1721550

    commit dc91f2eb1a4021eb6705c15e474942f84ab9b211 upstream.

    In kvm_vcpu_trigger_posted_interrupt() and pi_pre_block(), KVM
    assumes that PI notification events should not be suppressed when the
    target vCPU is not blocked.

    vmx_update_pi_irte() sets the SN field before changing an interrupt
    from posting to remapping, but it does not check the vCPU mode.
    Therefore, the change of SN field may break above the assumption.
    Besides, I don't see reasons to suppress notification events here, so
    remove the changes of SN field to avoid race condition.

    Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com>
    Reported-by: "Ramamurthy, Venkatesh" <venkatesh.ramamurthy@intel.com>
    Reported-by: Dan Williams <dan.j.williams@intel.com>
    Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
    Fixes: 28b835d60fcc ("KVM: Update Posted-Interrupts Descriptor when vCPU is preempted")
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit 20f1b7919dda139de591f91f99bfcbd5a06b1e14
Author: Myungho Jung <mhjungk@gmail.com>
Date:   Wed Apr 19 15:24:50 2017 -0700

    timer/sysclt: Restrict timer migration sysctl values to 0 and 1

    BugLink: http://bugs.launchpad.net/bugs/1721550

    commit b94bf594cf8ed67cdd0439e70fa939783471597a upstream.

    timer_migration sysctl acts as a boolean switch, so the allowed values
    should be restricted to 0 and 1.

    Add the necessary extra fields to the sysctl table entry to enforce that.

    [ tglx: Rewrote changelog ]

    Signed-off-by: Myungho Jung <mhjungk@gmail.com>
    Link: http://lkml.kernel.org/r/1492640690-3550-1-git-send-email-mhjungk@gmail.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Kazuhiro Hayashi <kazuhiro3.hayashi@toshiba.co.jp>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit 00503210f742ba762b8a629f62f24068d1227c14
Author: Andreas Gruenbacher <agruenba@redhat.com>
Date:   Tue Sep 19 07:15:35 2017 -0500

    gfs2: Fix debugfs glocks dump

    BugLink: http://bugs.launchpad.net/bugs/1721550

    commit 10201655b085df8e000822e496e5d4016a167a36 upstream.

    The switch to rhashtables (commit 88ffbf3e03) broke the debugfs glock
    dump (/sys/kernel/debug/gfs2/<device>/glocks) for dumps bigger than a
    single buffer: the right function for restarting an rhashtable iteration
    from the beginning of the hash table is rhashtable_walk_enter;
    rhashtable_walk_stop + rhashtable_walk_start will just resume from the
    current position.

    The upstream commit doesn't directly apply to 4.4.y because 4.4.y
    doesn't have rhashtable_walk_enter and the following mainline commits:

      92ecd73a887c4a2b94daf5fc35179d75d1c4ef95
        gfs2: Deduplicate gfs2_{glocks,glstats}_open
      cc37a62785a584f4875788689f3fd1fa6e4eb291
        gfs2: Replace rhashtable_walk_init with rhashtable_walk_enter

    Other than rhashtable_walk_enter, rhashtable_walk_init can fail.  To
    handle the failure case in gfs2_glock_seq_stop, we check if
    rhashtable_walk_init has initialized iter->walker; if it has not, we
    must not call rhashtable_walk_stop or rhashtable_walk_exit.

    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
    Signed-off-by: Bob Peterson <rpeterso@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit 30985ef38f1370106852840b604e3e4143a2f4e7
Author: Eric Biggers <ebiggers@google.com>
Date:   Mon Oct 2 11:04:09 2017 -0700

    x86/fpu: Don't let userspace set bogus xcomp_bv

    BugLink: http://bugs.launchpad.net/bugs/1721550

    commit 814fb7bb7db5433757d76f4c4502c96fc53b0b5e upstream.

    [Please apply to 4.4-stable.  Note: the backport includes the
    fpstate_init() call in xstateregs_set(), since fix is useless without
    it.  It was added by commit 91c3dba7dbc1 ("x86/fpu/xstate: Fix PTRACE
    frames for XSAVES"), but it doesn't make sense to backport that whole
    commit.]

    On x86, userspace can use the ptrace() or rt_sigreturn() system calls to
    set a task's extended state (xstate) or "FPU" registers.  ptrace() can
    set them for another task using the PTRACE_SETREGSET request with
    NT_X86_XSTATE, while rt_sigreturn() can set them for the current task.
    In either case, registers can be set to any value, but the kernel
    assumes that the XSAVE area itself remains valid in the sense that the
    CPU can restore it.

    However, in the case where the kernel is using the uncompacted xstate
    format (which it does whenever the XSAVES instruction is unavailable),
    it was possible for userspace to set the xcomp_bv field in the
    xstate_header to an arbitrary value.  However, all bits in that field
    are reserved in the uncompacted case, so when switching to a task with
    nonzero xcomp_bv, the XRSTOR instruction failed with a #GP fault.  This
    caused the WARN_ON_FPU(err) in copy_kernel_to_xregs() to be hit.  In
    addition, since the error is otherwise ignored, the FPU registers from
    the task previously executing on the CPU were leaked.

    Fix the bug by checking that the user-supplied value of xcomp_bv is 0 in
    the uncompacted case, and returning an error otherwise.

    The reason for validating xcomp_bv rather than simply overwriting it
    with 0 is that we want userspace to see an error if it (incorrectly)
    provides an XSAVE area in compacted format rather than in uncompacted
    format.

    Note that as before, in case of error we clear the task's FPU state.
    This is perhaps non-ideal, especially for PTRACE_SETREGSET; it might be
    better to return an error before changing anything.  But it seems the
    "clear on error" behavior is fine for now, and it's a little tricky to
    do otherwise because it would mean we couldn't simply copy the full
    userspace state into kernel memory in one __copy_from_user().

    This bug was found by syzkaller, which hit the above-mentioned
    WARN_ON_FPU():

        WARNING: CPU: 1 PID: 0 at ./arch/x86/include/asm/fpu/internal.h:373 __switch_to+0x5b5/0x5d0
        CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.13.0 #453
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
        task: ffff9ba2bc8e42c0 task.stack: ffffa78cc036c000
        RIP: 0010:__switch_to+0x5b5/0x5d0
        RSP: 0000:ffffa78cc08bbb88 EFLAGS: 00010082
        RAX: 00000000fffffffe RBX: ffff9ba2b8bf2180 RCX: 00000000c0000100
        RDX: 00000000ffffffff RSI: 000000005cb10700 RDI: ffff9ba2b8bf36c0
        RBP: ffffa78cc08bbbd0 R08: 00000000929fdf46 R09: 0000000000000001
        R10: 0000000000000000 R11: 0000000000000000 R12: ffff9ba2bc8e42c0
        R13: 0000000000000000 R14: ffff9ba2b8bf3680 R15: ffff9ba2bf5d7b40
        FS:  00007f7e5cb10700(0000) GS:ffff9ba2bf400000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 00000000004005cc CR3: 0000000079fd5000 CR4: 00000000001406e0
        Call Trace:
        Code: 84 00 00 00 00 00 e9 11 fd ff ff 0f ff 66 0f 1f 84 00 00 00 00 00 e9 e7 fa ff ff 0f ff 66 0f 1f 84 00 00 00 00 00 e9 c2 fa ff ff <0f> ff 66 0f 1f 84 00 00 00 00 00 e9 d4 fc ff ff 66 66 2e 0f 1f

    Here is a C reproducer.  The expected behavior is that the program spin
    forever with no output.  However, on a buggy kernel running on a
    processor with the "xsave" feature but without the "xsaves" feature
    (e.g. Sandy Bridge through Broadwell for Intel), within a second or two
    the program reports that the xmm registers were corrupted, i.e. were not
    restored correctly.  With CONFIG_X86_DEBUG_FPU=y it also hits the above
    kernel warning.

        #define _GNU_SOURCE
        #include <stdbool.h>
        #include <inttypes.h>
        #include <linux/elf.h>
        #include <stdio.h>
        #include <sys/ptrace.h>
        #include <sys/uio.h>
        #include <sys/wait.h>
        #include <unistd.h>

        int main(void)
        {
            int pid = fork();
            uint64_t xstate[512];
            struct iovec iov = { .iov_base = xstate, .iov_len = sizeof(xstate) };

            if (pid == 0) {
                bool tracee = true;
                for (int i = 0; i < sysconf(_SC_NPROCESSORS_ONLN) && tracee; i++)
                    tracee = (fork() != 0);
                uint32_t xmm0[4] = { [0 ... 3] = tracee ? 0x00000000 : 0xDEADBEEF };
                asm volatile("   movdqu %0, %%xmm0\n"
                             "   mov %0, %%rbx\n"
                             "1: movdqu %%xmm0, %0\n"
                             "   mov %0, %%rax\n"
                             "   cmp %%rax, %%rbx\n"
                             "   je 1b\n"
                             : "+m" (xmm0) : : "rax", "rbx", "xmm0");
                printf("BUG: xmm registers corrupted!  tracee=%d, xmm0=%08X%08X%08X%08X\n",
                       tracee, xmm0[0], xmm0[1], xmm0[2], xmm0[3]);
            } else {
                usleep(100000);
                ptrace(PTRACE_ATTACH, pid, 0, 0);
                wait(NULL);
                ptrace(PTRACE_GETREGSET, pid, NT_X86_XSTATE, &iov);
                xstate[65] = -1;
                ptrace(PTRACE_SETREGSET, pid, NT_X86_XSTATE, &iov);
                ptrace(PTRACE_CONT, pid, 0, 0);
                wait(NULL);
            }
            return 1;
        }

    Note: the program only tests for the bug using the ptrace() system call.
    The bug can also be reproduced using the rt_sigreturn() system call, but
    only when called from a 32-bit program, since for 64-bit programs the
    kernel restores the FPU state from the signal frame by doing XRSTOR
    directly from userspace memory (with proper error checking).

    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Rik van Riel <riel@redhat.com>
    Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Andy Lutomirski <luto@amacapital.net>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Eric Biggers <ebiggers3@gmail.com>
    Cc: Fenghua Yu <fenghua.yu@intel.com>
    Cc: Kevin Hao <haokexin@gmail.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Michael Halcrow <mhalcrow@google.com>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Wanpeng Li <wanpeng.li@hotmail.com>
    Cc: Yu-cheng Yu <yu-cheng.yu@intel.com>
    Cc: kernel-hardening@lists.openwall.com
    Fixes: 0b29643a5843 ("x86/xsaves: Change compacted format xsave area header")
    Link: http://lkml.kernel.org/r/20170922174156.16780-2-ebiggers3@gmail.com
    Link: http://lkml.kernel.org/r/20170923130016.21448-25-mingo@kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit ad45ddb452b135811f22ade526efa04cf908f11f
Author: satoru takeuchi <satoru.takeuchi@gmail.com>
Date:   Tue Sep 12 22:42:52 2017 +0900

    btrfs: prevent to set invalid default subvolid

    BugLink: http://bugs.launchpad.net/bugs/1721550

    commit 6d6d282932d1a609e60dc4467677e0e863682f57 upstream.

    `btrfs sub set-default` succeeds to set an ID which isn't corresponding to any
    fs/file tree. If such the bad ID is set to a filesystem, we can't mount this
    filesystem without specifying `subvol` or `subvolid` mount options.

    Fixes: 6ef5ed0d386b ("Btrfs: add ioctl and incompat flag to set the default mount subvol")
    Signed-off-by: Satoru Takeuchi <satoru.takeuchi@gmail.com>
    Reviewed-by: Qu Wenruo <quwenruo.btrfs@gmx.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit 7d08e00266e9265591355d77535324a79a2de862
Author: Naohiro Aota <naohiro.aota@wdc.com>
Date:   Fri Sep 8 17:48:55 2017 +0900

    btrfs: propagate error to btrfs_cmp_data_prepare caller

    BugLink: http://bugs.launchpad.net/bugs/1721550

    commit 78ad4ce014d025f41b8dde3a81876832ead643cf upstream.

    btrfs_cmp_data_prepare() (almost) always returns 0 i.e. ignoring errors
    from gather_extent_pages(). While the pages are freed by
    btrfs_cmp_data_free(), cmp->num_pages still has > 0. Then,
    btrfs_extent_same() try to access the already freed pages causing faults
    (or violates PageLocked assertion).

    This patch just return the error as is so that the caller stop the process.

    Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
    Fixes: f441460202cb ("btrfs: fix deadlock with extent-same and readpage")
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit be5f93e0f67e3cbf3d08b96fbf6d2462076098a3
Author: Naohiro Aota <naohiro.aota@wdc.com>
Date:   Fri Aug 25 14:15:14 2017 +0900

    btrfs: fix NULL pointer dereference from free_reloc_roots()

    BugLink: http://bugs.launchpad.net/bugs/1721550

    commit bb166d7207432d3c7d10c45dc052f12ba3a2121d upstream.

    __del_reloc_root should be called before freeing up reloc_root->node.
    If not, calling __del_reloc_root() dereference reloc_root->node, causing
    the system BUG.

    Fixes: 6bdf131fac23 ("Btrfs: don't leak reloc root nodes on error")
    Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
    Reviewed-by: Nikolay Borisov <nborisov@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit 01ef598752c2f711c5a13b7ce1d4782b41a654f3
Author: Nicolai Stange <nstange@suse.de>
Date:   Mon Sep 11 09:45:40 2017 +0200

    PCI: Fix race condition with driver_override

    BugLink: http://bugs.launchpad.net/bugs/1721550

    commit 9561475db680f7144d2223a409dd3d7e322aca03 upstream.

    The driver_override implementation is susceptible to a race condition when
    different threads are reading vs. storing a different driver override.  Add
    locking to avoid the race condition.

    This is in close analogy to commit 6265539776a0 ("driver core: platform:
    fix race condition with driver_override") from Adrian Salido.

    Fixes: 782a985d7af2 ("PCI: Introduce new device binding path using pci_dev.driver_override")
    Signed-off-by: Nicolai Stange <nstange@suse.de>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit 0be892c3db33c8d9d22e9ac7858a9db829b45b24
Author: Jim Mattson <jmattson@google.com>
Date:   Tue Sep 12 13:02:54 2017 -0700

    kvm: nVMX: Don't allow L2 to access the hardware CR8

    BugLink: http://bugs.launchpad.net/bugs/1721550

    commit 51aa68e7d57e3217192d88ce90fd5b8ef29ec94f upstream.

    If L1 does not specify the "use TPR shadow" VM-execution control in
    vmcs12, then L0 must specify the "CR8-load exiting" and "CR8-store
    exiting" VM-execution controls in vmcs02. Failure to do so will give
    the L2 VM unrestricted read/write access to the hardware CR8.

    This fixes CVE-2017-12154.

    Signed-off-by: Jim Mattson <jmattson@google.com>
    Reviewed-by: David Hildenbrand <david@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit d04ff9748aa68af51297911ca6c010be2966d98d
Author: Jan H. Schönherr <jschoenh@amazon.de>
Date:   Thu Sep 7 19:02:30 2017 +0100

    KVM: VMX: Do not BUG() on out-of-bounds guest IRQ

    BugLink: http://bugs.launchpad.net/bugs/1721550

    commit 3a8b0677fc6180a467e26cc32ce6b0c09a32f9bb upstream.

    The value of the guest_irq argument to vmx_update_pi_irte() is
    ultimately coming from a KVM_IRQFD API call. Do not BUG() in
    vmx_update_pi_irte() if the value is out-of bounds. (Especially,
    since KVM as a whole seems to hang after that.)

    Instead, print a message only once if we find that we don't have a
    route for a certain IRQ (which can be out-of-bounds or within the
    array).

    This fixes CVE-2017-1000252.

    Fixes: efc644048ecde54 ("KVM: x86: Update IRTE for posted-interrupts")
    Signed-off-by: Jan H. Schönherr <jschoenh@amazon.de>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit 97dd4725562107211fcc091dd97ae4e750a52e3a
Author: Will Deacon <will.deacon@arm.com>
Date:   Fri Sep 29 12:27:41 2017 +0100

    arm64: fault: Route pte translation faults via do_translation_fault

    BugLink: http://bugs.launchpad.net/bugs/1721550

    commit 760bfb47c36a07741a089bf6a28e854ffbee7dc9 upstream.

    We currently route pte translation faults via do_page_fault, which elides
    the address check against TASK_SIZE before invoking the mm fault handling
    code. However, this can cause issues with the path walking code in
    conjunction with our word-at-a-time implementation because
    load_unaligned_zeropad can end up faulting in kernel space if it reads
    across a page boundary and runs into a page fault (e.g. by attempting to
    read from a guard region).

    In the case of such a fault, load_unaligned_zeropad has registered a
    fixup to shift the valid data and pad with zeroes, however the abort is
    reported as a level 3 translation fault and we dispatch it straight to
    do_page_fault, despite it being a kernel address. This results in calling
    a sleeping function from atomic context:

      BUG: sleeping function called from invalid context at arch/arm64/mm/fault.c:313
      in_atomic(): 0, irqs_disabled(): 0, pid: 10290
      Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
      [...]
      [<ffffff8e016cd0cc>] ___might_sleep+0x134/0x144
      [<ffffff8e016cd158>] __might_sleep+0x7c/0x8c
      [<ffffff8e016977f0>] do_page_fault+0x140/0x330
      [<ffffff8e01681328>] do_mem_abort+0x54/0xb0
      Exception stack(0xfffffffb20247a70 to 0xfffffffb20247ba0)
      [...]
      [<ffffff8e016844fc>] el1_da+0x18/0x78
      [<ffffff8e017f399c>] path_parentat+0x44/0x88
      [<ffffff8e017f4c9c>] filename_parentat+0x5c/0xd8
      [<ffffff8e017f5044>] filename_create+0x4c/0x128
      [<ffffff8e017f59e4>] SyS_mkdirat+0x50/0xc8
      [<ffffff8e01684e30>] el0_svc_naked+0x24/0x28
      Code: 36380080 d5384100 f9400800 9402566d (d4210000)
      ---[ end trace 2d01889f2bca9b9f ]---

    Fix this by dispatching all translation faults to do_translation_faults,
    which avoids invoking the page fault logic for faults on kernel addresses.

    Reported-by: Ankit Jain <ankijain@codeaurora.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit 26149820c808e2846972846496cf6a267d4006cb
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Tue Sep 26 15:57:16 2017 +0100

    arm64: Make sure SPsel is always set

    BugLink: http://bugs.launchpad.net/bugs/1721550

    commit 5371513fb338fb9989c569dc071326d369d6ade8 upstream.

    When the kernel is entered at EL2 on an ARMv8.0 system, we construct
    the EL1 pstate and make sure this uses the the EL1 stack pointer
    (we perform an exception return to EL1h).

    But if the kernel is either entered at EL1 or stays at EL2 (because
    we're on a VHE-capable system), we fail to set SPsel, and use whatever
    stack selection the higher exception level has choosen for us.

    Let's not take any chance, and make sure that SPsel is set to one
    before we decide the mode we're going to run in.

    Acked-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit 236de4e67c64a3850f6f1c8ee81bf5961f1ebc80
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Wed Sep 27 09:25:30 2017 -0600

    seccomp: fix the usage of get/put_seccomp_filter() in seccomp_get_filter()

    BugLink: http://bugs.launchpad.net/bugs/1721550

    commit 66a733ea6b611aecf0119514d2dddab5f9d6c01e upstream.

    As Chris explains, get_seccomp_filter() and put_seccomp_filter() can end
    up using different filters. Once we drop ->siglock it is possible for
    task->seccomp.filter to have been replaced by SECCOMP_FILTER_FLAG_TSYNC.

    Fixes: f8e529ed941b ("seccomp, ptrace: add support for dumping seccomp filters")
    Reported-by: Chris Salls <chrissalls5@gmail.com>
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    [tycho: add __get_seccomp_filter vs. open coding refcount_inc()]
    Signed-off-by: Tycho Andersen <tycho@docker.com>
    [kees: tweak commit log]
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit ae80264367d76604c4af92a6700ede72a585bb0d
Author: Christoph Hellwig <hch@lst.de>
Date:   Thu Sep 7 13:54:35 2017 +0200

    bsg-lib: don't free job in bsg_prepare_job

    BugLink: http://bugs.launchpad.net/bugs/1721550

    commit f507b54dccfd8000c517d740bc45f20c74532d18 upstream.

    The job structure is allocated as part of the request, so we should not
    free it in the error path of bsg_prepare_job.

    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit 1e82abc154c00e7cc56ef67250c6430b397b0930
Author: Vladis Dronov <vdronov@redhat.com>
Date:   Wed Sep 13 00:21:21 2017 +0200

    nl80211: check for the required netlink attributes presence

    BugLink: http://bugs.launchpad.net/bugs/1721550

    commit e785fa0a164aa11001cba931367c7f94ffaff888 upstream.

    nl80211_set_rekey_data() does not check if the required attributes
    NL80211_REKEY_DATA_{REPLAY_CTR,KEK,KCK} are present when processing
    NL80211_CMD_SET_REKEY_OFFLOAD request. This request can be issued by
    users with CAP_NET_ADMIN privilege and may result in NULL dereference
    and a system crash. Add a check for the required attributes presence.
    This patch is based on the patch by bo Zhang.

    This fixes CVE-2017-12153.

    References: https://bugzilla.redhat.com/show_bug.cgi?id=1491046
    Fixes: e5497d766ad ("cfg80211/nl80211: support GTK rekey offload")
    Reported-by: bo Zhang <zhangbo5891001@gmail.com>
    Signed-off-by: Vladis Dronov <vdronov@redhat.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit 10e98800df1d94ec3b5d91dac7123c2e20c7fe26
Author: Andreas Gruenbacher <agruenba@redhat.com>
Date:   Mon Sep 25 12:23:03 2017 +0200

    vfs: Return -ENXIO for negative SEEK_HOLE / SEEK_DATA offsets

    BugLink: http://bugs.launchpad.net/bugs/1721550

    commit fc46820b27a2d9a46f7e90c9ceb4a64a1bc5fab8 upstream.

    In generic_file_llseek_size, return -ENXIO for negative offsets as well
    as offsets beyond EOF.  This affects filesystems which don't implement
    SEEK_HOLE / SEEK_DATA internally, possibly because they don't support
    holes.

    Fixes xfstest generic/448.

    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit 38e4532c2c7ee00bf66647dd4c88ad7131b70752
Author: Steve French <smfrench@gmail.com>
Date:   Fri Sep 22 01:40:27 2017 -0500

    SMB3: Don't ignore O_SYNC/O_DSYNC and O_DIRECT flags

    BugLink: http://bugs.launchpad.net/bugs/1721550

    commit 1013e760d10e614dc10b5624ce9fc41563ba2e65 upstream.

    Signed-off-by: Steve French <smfrench@gmail.com>
    Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
    Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit 29375fe72a51678a043c76b8dd7fbe537719bc4d
Author: Steve French <smfrench@gmail.com>
Date:   Wed Sep 20 19:57:18 2017 -0500

    SMB: Validate negotiate (to protect against downgrade) even if signing off

    BugLink: http://bugs.launchpad.net/bugs/1721550

    commit 0603c96f3af50e2f9299fa410c224ab1d465e0f9 upstream.

    As long as signing is supported (ie not a guest user connection) and
    connection is SMB3 or SMB3.02, then validate negotiate (protect
    against man in the middle downgrade attacks).  We had been doing this
    only when signing was required, not when signing was just enabled,
    but this more closely matches recommended SMB3 behavior and is
    better security.  Suggested by Metze.

    Signed-off-by: Steve French <smfrench@gmail.com>
    Reviewed-by: Jeremy Allison <jra@samba.org>
    Acked-by: Stefan Metzmacher <metze@samba.org>
    Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit a26167cd2c854e3f20f57d8996c1212b28f5e56d
Author: Steve French <smfrench@gmail.com>
Date:   Mon Sep 18 18:18:45 2017 -0500

    Fix SMB3.1.1 guest authentication to Samba

    BugLink: http://bugs.launchpad.net/bugs/1721550

    commit 23586b66d84ba3184b8820277f3fc42761640f87 upstream.

    Samba rejects SMB3.1.1 dialect (vers=3.1.1) negotiate requests from
    the kernel client due to the two byte pad at the end of the negotiate
    contexts.

    Signed-off-by: Steve French <smfrench@gmail.com>
    Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>

commit c6540f6c259b3d0b2e7c5ee3de79e7ed6050bce8
Author: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Date:   Wed Sep 20 17:02:52 2017 -0400

    powerpc/pseries: Fix parent_dn reference leak in add_dt_node()

    BugLink: http://bugs.launchpad.net/bugs/1721550

    commit b537ca6fede69a281dc524983e5e633d79a10a08 upstream.

    A reference to the parent device node is held by add_dt_node() for the
    node to be added. If the call to dlpar_configure_connector() fails
    add_dt_node() returns ENOENT and that reference is not freed.

    Add a call…
bgly pushed a commit that referenced this pull request Nov 8, 2017
@bgly
tcmu: fix crash when removing the tcmu device
8189d8f 
Before the nl REMOVE msg has been sent to the userspace, the ring's
and other resources have been released, but the userspace maybe still
using them. And then we can see the crash messages like:

ring broken, not handling completions
BUG: unable to handle kernel paging request at ffffffffffffffd0
IP: tcmu_handle_completions+0x134/0x2f0 [target_core_user]
PGD 11bdc0c067
P4D 11bdc0c067
PUD 11bdc0e067
PMD 0

Oops: 0000 [#1] SMP
cmd_id not found, ring is broken
RIP: 0010:tcmu_handle_completions+0x134/0x2f0 [target_core_user]
RSP: 0018:ffffb8a2d8983d88 EFLAGS: 00010296
RAX: 0000000000000000 RBX: ffffb8a2aaa4e000 RCX: 00000000ffffffff
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000220
R10: 0000000076c71401 R11: ffff8d2e76c713f0 R12: ffffb8a2aad56bc0
R13: 000000000000001c R14: ffff8d2e32c90000 R15: ffff8d2e76c713f0
FS:  00007f411ffff700(0000) GS:ffff8d1e7fdc0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffffffffd0 CR3: 0000001027070000 CR4:
00000000001406e0
Call Trace:
? tcmu_irqcontrol+0x2a/0x40 [target_core_user]
? uio_write+0x7b/0xc0 [uio]
? __vfs_write+0x37/0x150
? __getnstimeofday64+0x3b/0xd0
? vfs_write+0xb2/0x1b0
? syscall_trace_enter+0x1d0/0x2b0
? SyS_write+0x55/0xc0
? do_syscall_64+0x67/0x150
? entry_SYSCALL64_slow_path+0x25/0x25
Code: 41 5d 41 5e 41 5f 5d c3 83 f8 01 0f 85 cf 01 00
00 48 8b 7d d0 e8 dd 5c 1d f3 41 0f b7 74 24 04 48 8b
7d c8 31 d2 e8 5c c7 1b f3 <48> 8b 7d d0 49 89 c7 c6 07
00 0f 1f 40 00 4d 85 ff 0f 84 82 01  RIP:
tcmu_handle_completions+0x134/0x2f0 [target_core_user]
RSP: ffffb8a2d8983d88
CR2: ffffffffffffffd0

And the crash also could happen in tcmu_page_fault and other places.

Signed-off-by: Zhang Zhuoyu <zhangzhuoyu@cmss.chinamobile.com>
Signed-off-by: Xiubo Li <lixiubo@cmss.chinamobile.com>
Reviewed-by: Mike Christie <mchristi@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Bryant G. Ly <bryantly@linux.vnet.ibm.com>

# Conflicts:
#	drivers/target/target_core_user.c
bgly pushed a commit that referenced this pull request Nov 8, 2017
@bgly
tcmu: fix crash when removing the tcmu device
4928a26 
Before the nl REMOVE msg has been sent to the userspace, the ring's
and other resources have been released, but the userspace maybe still
using them. And then we can see the crash messages like:

ring broken, not handling completions
BUG: unable to handle kernel paging request at ffffffffffffffd0
IP: tcmu_handle_completions+0x134/0x2f0 [target_core_user]
PGD 11bdc0c067
P4D 11bdc0c067
PUD 11bdc0e067
PMD 0

Oops: 0000 [#1] SMP
cmd_id not found, ring is broken
RIP: 0010:tcmu_handle_completions+0x134/0x2f0 [target_core_user]
RSP: 0018:ffffb8a2d8983d88 EFLAGS: 00010296
RAX: 0000000000000000 RBX: ffffb8a2aaa4e000 RCX: 00000000ffffffff
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000220
R10: 0000000076c71401 R11: ffff8d2e76c713f0 R12: ffffb8a2aad56bc0
R13: 000000000000001c R14: ffff8d2e32c90000 R15: ffff8d2e76c713f0
FS:  00007f411ffff700(0000) GS:ffff8d1e7fdc0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffffffffd0 CR3: 0000001027070000 CR4:
00000000001406e0
Call Trace:
? tcmu_irqcontrol+0x2a/0x40 [target_core_user]
? uio_write+0x7b/0xc0 [uio]
? __vfs_write+0x37/0x150
? __getnstimeofday64+0x3b/0xd0
? vfs_write+0xb2/0x1b0
? syscall_trace_enter+0x1d0/0x2b0
? SyS_write+0x55/0xc0
? do_syscall_64+0x67/0x150
? entry_SYSCALL64_slow_path+0x25/0x25
Code: 41 5d 41 5e 41 5f 5d c3 83 f8 01 0f 85 cf 01 00
00 48 8b 7d d0 e8 dd 5c 1d f3 41 0f b7 74 24 04 48 8b
7d c8 31 d2 e8 5c c7 1b f3 <48> 8b 7d d0 49 89 c7 c6 07
00 0f 1f 40 00 4d 85 ff 0f 84 82 01  RIP:
tcmu_handle_completions+0x134/0x2f0 [target_core_user]
RSP: ffffb8a2d8983d88
CR2: ffffffffffffffd0

And the crash also could happen in tcmu_page_fault and other places.

Signed-off-by: Zhang Zhuoyu <zhangzhuoyu@cmss.chinamobile.com>
Signed-off-by: Xiubo Li <lixiubo@cmss.chinamobile.com>
Reviewed-by: Mike Christie <mchristi@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
bgly pushed a commit that referenced this pull request Nov 8, 2017
@bgly
tcmu: fix crash when removing the tcmu device
1062c34 
Before the nl REMOVE msg has been sent to the userspace, the ring's
and other resources have been released, but the userspace maybe still
using them. And then we can see the crash messages like:

ring broken, not handling completions
BUG: unable to handle kernel paging request at ffffffffffffffd0
IP: tcmu_handle_completions+0x134/0x2f0 [target_core_user]
PGD 11bdc0c067
P4D 11bdc0c067
PUD 11bdc0e067
PMD 0

Oops: 0000 [#1] SMP
cmd_id not found, ring is broken
RIP: 0010:tcmu_handle_completions+0x134/0x2f0 [target_core_user]
RSP: 0018:ffffb8a2d8983d88 EFLAGS: 00010296
RAX: 0000000000000000 RBX: ffffb8a2aaa4e000 RCX: 00000000ffffffff
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000220
R10: 0000000076c71401 R11: ffff8d2e76c713f0 R12: ffffb8a2aad56bc0
R13: 000000000000001c R14: ffff8d2e32c90000 R15: ffff8d2e76c713f0
FS:  00007f411ffff700(0000) GS:ffff8d1e7fdc0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffffffffd0 CR3: 0000001027070000 CR4:
00000000001406e0
Call Trace:
? tcmu_irqcontrol+0x2a/0x40 [target_core_user]
? uio_write+0x7b/0xc0 [uio]
? __vfs_write+0x37/0x150
? __getnstimeofday64+0x3b/0xd0
? vfs_write+0xb2/0x1b0
? syscall_trace_enter+0x1d0/0x2b0
? SyS_write+0x55/0xc0
? do_syscall_64+0x67/0x150
? entry_SYSCALL64_slow_path+0x25/0x25
Code: 41 5d 41 5e 41 5f 5d c3 83 f8 01 0f 85 cf 01 00
00 48 8b 7d d0 e8 dd 5c 1d f3 41 0f b7 74 24 04 48 8b
7d c8 31 d2 e8 5c c7 1b f3 <48> 8b 7d d0 49 89 c7 c6 07
00 0f 1f 40 00 4d 85 ff 0f 84 82 01  RIP:
tcmu_handle_completions+0x134/0x2f0 [target_core_user]
RSP: ffffb8a2d8983d88
CR2: ffffffffffffffd0

And the crash also could happen in tcmu_page_fault and other places.

Signed-off-by: Zhang Zhuoyu <zhangzhuoyu@cmss.chinamobile.com>
Signed-off-by: Xiubo Li <lixiubo@cmss.chinamobile.com>
Reviewed-by: Mike Christie <mchristi@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
bgly added a commit that referenced this pull request Nov 14, 2017
@bgly
ibmveth: Kernel crash LSO offload flag toggle
0560bfb 
The following patch ensures that the bounce_buffer is not null
prior to using it within skb_copy_from_linear_data.

The problem can be recreated toggling on/off Large send offload.

The following script when run (along with some iperf traffic recreates the
crash within 5-10 mins or so).

while true
do
	ethtool -k ibmveth0 | grep tcp-segmentation-offload
	ethtool -K ibmveth0 tso off
	ethtool -k ibmveth0 | grep tcp-segmentation-offload
	ethtool -K ibmveth0 tso on
done

Note: This issue happens the very first time largsesend offload is
turned off too (but the above script recreates the issue all the times)

[76563.914173] Unable to handle kernel paging request for data at address 0x00000000
[76563.914197] Faulting instruction address: 0xc000000000063940
[76563.914205] Oops: Kernel access of bad area, sig: 11 [#1]
[76563.914210] SMP NR_CPUS=2048 NUMA pSeries
[76563.914217] Modules linked in: rpadlpar_io rpaphp dccp_diag dccp tcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag nls_utf8 isofs binfmt_misc pseries_rng rtc_generic autofs4 ibmvfc scsi_transport_fc ibmvscsi ibmveth
[76563.914251] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.4.0-34-generic #53-Ubuntu
[76563.914258] task: c0000000fe9efcc0 ti: c0000000feab0000 task.ti: c0000000feab0000
[76563.914265] NIP: c000000000063940 LR: d000000000d31788 CTR: c000000000064100
[76563.914271] REGS: c0000000feab2ff0 TRAP: 0300   Not tainted  (4.4.0-34-generic)
[76563.914277] MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE>  CR: 4800284e  XER: 0000001a
[76563.914294] CFAR: c000000000008468 DAR: 0000000000000000 DSISR: 42000000 SOFTE: 1
GPR00: 000000000000f240 c0000000feab3270 c0000000015b5d00 0000000000000000
GPR04: c00000000d9b0004 000000000000002a 0000000000000006 c0000000efc0ccac
GPR08: d000000000d3dd28 0000000000000080 0000000000000000 d000000000d34758
GPR12: c000000000064100 c00000000e7f1c80 c0000000ffdca938 0000000000000100
GPR16: c0000000ffdca738 c0000000ffdca538 c0000000feab34a0 c0000000015f4d00
GPR20: 0000000000000000 c0000000015f4cf0 c0000000f5945900 0000000000000000
GPR24: 0000000000000000 0000000080000000 c0000000feab32d0 c0000000efc0ccac
GPR28: c0000000f23ccb00 c0000000f5945000 c0000000f23ccb00 c0000000efc0cc00
[76563.914380] NIP [c000000000063940] memcpy_power7+0x40/0x800
[76563.914387] LR [d000000000d31788] ibmveth_start_xmit+0x1c8/0x8d0 [ibmveth]
[76563.914392] Call Trace:
[76563.914396] [c0000000feab3270] [c0000000feab32d0] 0xc0000000feab32d0 (unreliable)
[76563.914407] [c0000000feab3360] [c0000000009816f4] dev_hard_start_xmit+0x304/0x530
[76563.914415] [c0000000feab3440] [c0000000009b6564] sch_direct_xmit+0x124/0x330
[76563.914423] [c0000000feab34e0] [c000000000981ddc] __dev_queue_xmit+0x26c/0x770
[76563.914431] [c0000000feab3580] [c000000000a1efc0] arp_xmit+0x30/0xd0
[76563.914438] [c0000000feab35f0] [c000000000a1f0f4] arp_send_dst.part.0+0x94/0xb0
[76563.914445] [c0000000feab3660] [c000000000a1fcb4] arp_solicit+0x114/0x2b0
[76563.914452] [c0000000feab3730] [c00000000098d8f4] neigh_probe+0x84/0xd0
[76563.914460] [c0000000feab3760] [c0000000009937cc] neigh_timer_handler+0xbc/0x320
[76563.914468] [c0000000feab37a0] [c00000000014a3fc] call_timer_fn+0x5c/0x1c0
[76563.914474] [c0000000feab3830] [c00000000014a8bc] run_timer_softirq+0x31c/0x3f0
[76563.914483] [c0000000feab3900] [c0000000000bec58] __do_softirq+0x188/0x3e0
[76563.914490] [c0000000feab39f0] [c0000000000bf128] irq_exit+0xc8/0x100
[76563.914498] [c0000000feab3a10] [c00000000001f974] timer_interrupt+0xa4/0xe0
[76563.914505] [c0000000feab3a40] [c000000000002714] decrementer_common+0x114/0x180
[76563.914515] --- interrupt: 901 at plpar_hcall_norets+0x1c/0x28
[76563.914515]     LR = check_and_cede_processor+0x34/0x50
[76563.914525] [c0000000feab3d30] [c000000000916bf0] check_and_cede_processor+0x20/0x50 (unreliable)
[76563.914534] [c0000000feab3d90] [c000000000916e18] shared_cede_loop+0x68/0x170
[76563.914541] [c0000000feab3dd0] [c000000000913e20] cpuidle_enter_state+0x160/0x410
[76563.914549] [c0000000feab3e30] [c000000000119d48] call_cpuidle+0x78/0xd0
[76563.914556] [c0000000feab3e70] [c00000000011a11c] cpu_startup_entry+0x37c/0x480
[76563.914564] [c0000000feab3f30] [c00000000004563c] start_secondary+0x33c/0x360
[76563.914572] [c0000000feab3f90] [c000000000008b6c] start_secondary_prolog+0x10/0x14

Signed-off-by: Bryant G. Ly <bryantly@linux.vnet.ibm.com>
Signed-off-by: Sivakumar Krishnasamy <ksiva@linux.vnet.ibm.com>
Cc: <stable@vger.kernel.org> # 4.4+
bgly pushed a commit that referenced this pull request Nov 28, 2017
@bgly
tcmu: fix crash when removing the tcmu device
5531ea8 
Before the nl REMOVE msg has been sent to the userspace, the ring's
and other resources have been released, but the userspace maybe still
using them. And then we can see the crash messages like:

ring broken, not handling completions
BUG: unable to handle kernel paging request at ffffffffffffffd0
IP: tcmu_handle_completions+0x134/0x2f0 [target_core_user]
PGD 11bdc0c067
P4D 11bdc0c067
PUD 11bdc0e067
PMD 0

Oops: 0000 [#1] SMP
cmd_id not found, ring is broken
RIP: 0010:tcmu_handle_completions+0x134/0x2f0 [target_core_user]
RSP: 0018:ffffb8a2d8983d88 EFLAGS: 00010296
RAX: 0000000000000000 RBX: ffffb8a2aaa4e000 RCX: 00000000ffffffff
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000220
R10: 0000000076c71401 R11: ffff8d2e76c713f0 R12: ffffb8a2aad56bc0
R13: 000000000000001c R14: ffff8d2e32c90000 R15: ffff8d2e76c713f0
FS:  00007f411ffff700(0000) GS:ffff8d1e7fdc0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffffffffd0 CR3: 0000001027070000 CR4:
00000000001406e0
Call Trace:
? tcmu_irqcontrol+0x2a/0x40 [target_core_user]
? uio_write+0x7b/0xc0 [uio]
? __vfs_write+0x37/0x150
? __getnstimeofday64+0x3b/0xd0
? vfs_write+0xb2/0x1b0
? syscall_trace_enter+0x1d0/0x2b0
? SyS_write+0x55/0xc0
? do_syscall_64+0x67/0x150
? entry_SYSCALL64_slow_path+0x25/0x25
Code: 41 5d 41 5e 41 5f 5d c3 83 f8 01 0f 85 cf 01 00
00 48 8b 7d d0 e8 dd 5c 1d f3 41 0f b7 74 24 04 48 8b
7d c8 31 d2 e8 5c c7 1b f3 <48> 8b 7d d0 49 89 c7 c6 07
00 0f 1f 40 00 4d 85 ff 0f 84 82 01  RIP:
tcmu_handle_completions+0x134/0x2f0 [target_core_user]
RSP: ffffb8a2d8983d88
CR2: ffffffffffffffd0

And the crash also could happen in tcmu_page_fault and other places.

Signed-off-by: Zhang Zhuoyu <zhangzhuoyu@cmss.chinamobile.com>
Signed-off-by: Xiubo Li <lixiubo@cmss.chinamobile.com>
Reviewed-by: Mike Christie <mchristi@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
bgly added a commit that referenced this pull request Apr 12, 2018
@bgly
target: Fix Fortify_panic kernel exception
2c3c13d 
[  496.212783] ------------[ cut here ]------------
[  496.212784] kernel BUG at /build/linux-hwe-edge-ojNirv/linux-hwe-edge-4.15.0/lib/string.c:1052!
[  496.212789] Oops: Exception in kernel mode, sig: 5 [#1]
[  496.212791] LE SMP NR_CPUS=2048 NUMA pSeries
[  496.212795] Modules linked in: hvcs(OE) hvcserver dm_snapshot dm_bufio rpadlpar_io rpaphp ip6table_raw xt_CT xt_mac xt_tcpudp xt_comment xt_physdev xt_set ip_set_hash_net ip_set iptable_raw dccp_diag dccp tcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag target_core_pscsi(OE) target_core_file(OE) target_core_iblock(OE) iscsi_target_mod(OE) vxlan ip6_udp_tunnel udp_tunnel openvswitch nsh nf_nat_ipv6 target_core_user(OE) uio binfmt_misc xt_conntrack nf_conntrack_netlink nfnetlink nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv6 nf_defrag_ipv6 nbd ipt_REJECT nf_reject_ipv4 ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 pseries_rng nf_nat ibmvmc(OE) nf_conntrack libcrc32c vmx_crypto crct10dif_vpmsum iptable_mangle iptable_filter
[  496.212854]  ip_tables ip6table_filter ip6_tables ebtables x_tables br_netfilter bridge stp llc ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 mlx4_en ses enclosure scsi_transport_sas uas usb_storage ibmvscsis(OE) target_core_mod(OE) ibmveth(OE) mlx5_core mlx4_core mlxfw crc32c_vpmsum be2net tg3 ipr devlink
[  496.212888] CPU: 1 PID: 2587 Comm: kworker/1:2 Tainted: G           OE    4.15.0-15-generic #16~16.04.1-Ubuntu
[  496.212897] Workqueue: ibmvscsis3000000f ibmvscsis_scheduler [ibmvscsis]
[  496.212900] NIP:  c000000000cbbf00 LR: c000000000cbbefc CTR: 0000000000655170
[  496.212903] REGS: c0000007e58e3580 TRAP: 0700   Tainted: G           OE     (4.15.0-15-generic)
[  496.212906] MSR:  800000000282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE>  CR: 286c2222  XER: 20000003
[  496.212915] CFAR: c00000000018d634 SOFTE: 1
               GPR00: c000000000cbbefc c0000007e58e3800 c0000000016bae00 0000000000000022
               GPR04: c0000007fe94ce18 c0000007fe964368 0000000000000003 ffffffffffffffff
               GPR08: 0000000000000007 c000000001193a74 00000007fd7c0000 0000000000003986
               GPR12: 0000000000002200 c00000000fa80b00 c00000000013a308 c0000007f48adb00
               GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
               GPR20: 0000000000000000 0000000000000000 fffffffffffffef7 0000000000000402
               GPR24: 0000000000000000 f000000001a8cb40 00000000000003f0 0000000000648010
               GPR28: c0000005a360a570 c0000007f4095880 c0000000fc9e7e00 c0000007f1f56000
[  496.212952] NIP [c000000000cbbf00] fortify_panic+0x28/0x38
[  496.212956] LR [c000000000cbbefc] fortify_panic+0x24/0x38
[  496.212958] Call Trace:
[  496.212960] [c0000007e58e3800] [c000000000cbbefc] fortify_panic+0x24/0x38 (unreliable)
[  496.212965] [c0000007e58e3860] [d00000000f150c28] iblock_execute_write_same+0x3b8/0x3c0 [target_core_iblock]
[  496.212976] [c0000007e58e3910] [d000000006c737d4] __target_execute_cmd+0x54/0x150 [target_core_mod]
[  496.212982] [c0000007e58e3940] [d000000006d32ce4] ibmvscsis_write_pending+0x74/0xe0 [ibmvscsis]
[  496.212991] [c0000007e58e39b0] [d000000006c74fc8] transport_generic_new_cmd+0x318/0x370 [target_core_mod]
[  496.213001] [c0000007e58e3a30] [d000000006c75084] transport_handle_cdb_direct+0x64/0xd0 [target_core_mod]
[  496.213011] [c0000007e58e3aa0] [d000000006c75298] target_submit_cmd_map_sgls+0x1a8/0x320 [target_core_mod]
[  496.213021] [c0000007e58e3b30] [d000000006c75458] target_submit_cmd+0x48/0x60 [target_core_mod]
[  496.213026] [c0000007e58e3bd0] [d000000006d34c20] ibmvscsis_scheduler+0x370/0x600 [ibmvscsis]
[  496.213031] [c0000007e58e3c90] [c00000000013135c] process_one_work+0x1ec/0x580
[  496.213035] [c0000007e58e3d20] [c000000000131798] worker_thread+0xa8/0x600
[  496.213039] [c0000007e58e3dc0] [c00000000013a468] kthread+0x168/0x1b0
[  496.213044] [c0000007e58e3e30] [c00000000000b528] ret_from_kernel_thread+0x5c/0xb4
[  496.213047] Instruction dump:
[  496.213049] 7c0803a6 4e800020 3c4c00a0 3842ef28 7c0802a6 f8010010 f821ffa1 7c641b78
[  496.213055] 3c62ff94 3863dc00 4b4d16f1 60000000 <0fe00000> 00000000 00000000 00000000
[  496.213062] ---[ end trace 4c7e8c92043f3868 ]---
[  654.577815] ibmvscsis 3000000f: connection lost with outstanding work

The patch fixes the above trace where the size passed into
memcmp is greater than the size of the data passed in from
ptr1 or ptr2 then a fortify_panic is posted.

Fixes: 2237498 ("target/iblock: Convert WRITE_SAME to blkdev_issue_zeroout")
Signed-off-by: Bryant G. Ly <bryantly@linux.vnet.ibm.com>
Reviewed-by: Steven Royer <seroyer@linux.vnet.ibm.com>
Tested-by: Taylor Jakobson <tjakobs@us.ibm.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Nicholas Bellinger <nab@linux-iscsi.org>
Cc: <stable@vger.kernel.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@bgly @jennyj-mellanox @yasker