commit f40b3cc69de8c97bbcdb74e3cffda06ffcad2cd7 Author: Sasha Levin Date: Wed Jan 18 13:48:06 2017 -0500 Linux 4.1.38 Signed-off-by: Sasha Levin commit d8435bb5e8fb1d20c480756ed6b76121c4d2d50d Author: Alexander Duyck Date: Tue Mar 29 14:55:22 2016 -0700 gro: Allow tunnel stacking in the case of FOU/GUE [ Upstream commit c3483384ee511ee2af40b4076366cd82a6a47b86 ] This patch should fix the issues seen with a recent fix to prevent tunnel-in-tunnel frames from being generated with GRO. The fix itself is correct for now as long as we do not add any devices that support NETIF_F_GSO_GRE_CSUM. When such a device is added it could have the potential to mess things up due to the fact that the outer transport header points to the outer UDP header and not the GRE header as would be expected. Fixes: fac8e0f579695 ("tunnels: Don't apply GRO to multiple layers of encapsulation.") Signed-off-by: Alexander Duyck Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 066b300e5be43cb61697539e2a3a9aac5afb422f Author: Jesse Gross Date: Sat Mar 19 09:32:01 2016 -0700 tunnels: Don't apply GRO to multiple layers of encapsulation. [ Upstream commit fac8e0f579695a3ecbc4d3cac369139d7f819971 ] When drivers express support for TSO of encapsulated packets, they only mean that they can do it for one layer of encapsulation. Supporting additional levels would mean updating, at a minimum, more IP length fields and they are unaware of this. No encapsulation device expresses support for handling offloaded encapsulated packets, so we won't generate these types of frames in the transmit path. However, GRO doesn't have a check for multiple levels of encapsulation and will attempt to build them. UDP tunnel GRO actually does prevent this situation but it only handles multiple UDP tunnels stacked on top of each other. This generalizes that solution to prevent any kind of tunnel stacking that would cause problems. Fixes: bf5a755f ("net-gre-gro: Add GRE support to the GRO stack") Signed-off-by: Jesse Gross Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b11e1542feca30e7ea0baf1b412e44e7b27f93c2 Author: Deepa Dinamani Date: Sat Feb 27 00:32:15 2016 -0800 net: ipv4: Convert IP network timestamps to be y2038 safe [ Upstream commit 822c868532cae2cc1c51f4f18ab61c194d98aaf6 ] ICMP timestamp messages and IP source route options require timestamps to be in milliseconds modulo 24 hours from midnight UT format. Add inet_current_timestamp() function to support this. The function returns the required timestamp in network byte order. Timestamp calculation is also changed to call ktime_get_real_ts64() which uses struct timespec64. struct timespec64 is y2038 safe. Previously it called getnstimeofday() which uses struct timespec. struct timespec is not y2038 safe. Signed-off-by: Deepa Dinamani Cc: "David S. Miller" Cc: Alexey Kuznetsov Cc: Hideaki YOSHIFUJI Cc: James Morris Cc: Patrick McHardy Acked-by: YOSHIFUJI Hideaki Acked-by: Arnd Bergmann Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5023ae270216fd980d51770aec1806acaf90846c Author: Jesse Gross Date: Sat Mar 19 09:32:00 2016 -0700 ipip: Properly mark ipip GRO packets as encapsulated. [ Upstream commit b8cba75bdf6a48ea4811bbefb11a94a5c7281b68 ] ipip encapsulated packets can be merged together by GRO but the result does not have the proper GSO type set or even marked as being encapsulated at all. Later retransmission of these packets will likely fail if the device does not support ipip offloads. This is similar to the issue resolved in IPv6 sit in feec0cb3 ("ipv6: gro: support sit protocol"). Reported-by: Patrick Boutilier Fixes: 9667e9bb ("ipip: Add gro callbacks to ipip offload") Tested-by: Patrick Boutilier Acked-by: Eric Dumazet Signed-off-by: Jesse Gross Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3e3267311e3b6557206f293eeb9205b41e090625 Author: Al Viro Date: Fri Dec 16 13:42:06 2016 -0500 sg_write()/bsg_write() is not fit to be called under KERNEL_DS [ Upstream commit 128394eff343fc6d2f32172f03e24829539c5835 ] Both damn things interpret userland pointers embedded into the payload; worse, they are actually traversing those. Leaving aside the bad API design, this is very much _not_ safe to call with KERNEL_DS. Bail out early if that happens. Cc: stable@vger.kernel.org Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 363f1a90b7f3057efa6e08bf7b707874232f153c Author: Aleksa Sarai Date: Wed Dec 21 16:26:24 2016 +1100 fs: exec: apply CLOEXEC before changing dumpable task flags [ Upstream commit 613cc2b6f272c1a8ad33aefa21cad77af23139f7 ] If you have a process that has set itself to be non-dumpable, and it then undergoes exec(2), any CLOEXEC file descriptors it has open are "exposed" during a race window between the dumpable flags of the process being reset for exec(2) and CLOEXEC being applied to the file descriptors. This can be exploited by a process by attempting to access /proc//fd/... during this window, without requiring CAP_SYS_PTRACE. The race in question is after set_dumpable has been (for get_link, though the trace is basically the same for readlink): [vfs] -> proc_pid_link_inode_operations.get_link -> proc_pid_get_link -> proc_fd_access_allowed -> ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS); Which will return 0, during the race window and CLOEXEC file descriptors will still be open during this window because do_close_on_exec has not been called yet. As a result, the ordering of these calls should be reversed to avoid this race window. This is of particular concern to container runtimes, where joining a PID namespace with file descriptors referring to the host filesystem can result in security issues (since PRCTL_SET_DUMPABLE doesn't protect against access of CLOEXEC file descriptors -- file descriptors which may reference filesystem objects the container shouldn't have access to). Cc: dev@opencontainers.org Cc: # v3.2+ Reported-by: Michael Crosby Signed-off-by: Aleksa Sarai Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit c63e64ae7665e503efe720a97037d844db3a3038 Author: Bart Van Assche Date: Mon Dec 19 18:00:05 2016 +0100 IB/cma: Fix a race condition in iboe_addr_get_sgid() [ Upstream commit fba332b079029c2f4f7e84c1c1cd8e3867310c90 ] Code that dereferences the struct net_device ip_ptr member must be protected with an in_dev_get() / in_dev_put() pair. Hence insert calls to these functions. Fixes: commit 7b85627b9f02 ("IB/cma: IBoE (RoCE) IP-based GID addressing") Signed-off-by: Bart Van Assche Reviewed-by: Moni Shoua Cc: Or Gerlitz Cc: Roland Dreier Cc: Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin commit 6242668e855c8e203644c8023976c87cb042ebcb Author: Takashi Iwai Date: Wed Dec 21 11:28:28 2016 +0100 Revert "ALSA: usb-audio: Fix race at stopping the stream" [ Upstream commit f8114f8583bb18a467c04ddc1e8978330e445801 ] This reverts commit 16200948d8353fe29a473a394d7d26790deae0e7. The commit was intended to cover the race condition, but it introduced yet another regression for devices with the implicit feedback, leading to a kernel panic due to NULL-dereference in an irq context. As the race condition that was addressed by the commit is very rare and the regression is much worse, let's revert the commit for rc1, and fix the issue properly in a later patch. Fixes: 16200948d835 ("ALSA: usb-audio: Fix race at stopping the stream") Reported-by: Ioan-Adrian Ratiu Cc: Signed-off-by: Takashi Iwai Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit dd5035276792edbd3dac21620d9b91d3a8e3785a Author: Jim Mattson Date: Mon Dec 12 11:01:37 2016 -0800 kvm: nVMX: Allow L1 to intercept software exceptions (#BP and #OF) [ Upstream commit ef85b67385436ddc1998f45f1d6a210f935b3388 ] When L2 exits to L0 due to "exception or NMI", software exceptions (#BP and #OF) for which L1 has requested an intercept should be handled by L1 rather than L0. Previously, only hardware exceptions were forwarded to L1. Signed-off-by: Jim Mattson Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 6fdb4af13f9faf27b8ca3b25c1d3284f0be7b31b Author: Russell Currey Date: Thu Dec 15 16:12:41 2016 +1100 drivers/gpu/drm/ast: Fix infinite loop if read fails [ Upstream commit 298360af3dab45659810fdc51aba0c9f4097e4f6 ] ast_get_dram_info() configures a window in order to access BMC memory. A BMC register can be configured to disallow this, and if so, causes an infinite loop in the ast driver which renders the system unusable. Fix this by erroring out if an error is detected. On powerpc systems with EEH, this leads to the device being fenced and the system continuing to operate. Cc: # 3.10+ Signed-off-by: Russell Currey Reviewed-by: Joel Stanley Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20161215051241.20815-1-ruscur@russell.cc Signed-off-by: Sasha Levin commit d1b9fb84c423d6a6777da3238abf7e08c13bd7f5 Author: Andy Grover Date: Mon Nov 21 16:35:30 2016 -0800 target/user: Fix use-after-free of tcmu_cmds if they are expired [ Upstream commit d0905ca757bc40bd1ebc261a448a521b064777d7 ] Don't free the cmd in tcmu_check_expired_cmd, it's still referenced by an entry in our cmd_id->cmd idr. If userspace ever resumes processing, tcmu_handle_completions() will use the now-invalid cmd pointer. Instead, don't free cmd. It will be freed by tcmu_handle_completion() if userspace ever recovers, or tcmu_free_device if not. Cc: stable@vger.kernel.org Reported-by: Bryant G Ly Tested-by: Bryant G Ly Signed-off-by: Andy Grover Signed-off-by: Bart Van Assche Signed-off-by: Sasha Levin commit bbe48c2f932ec0cae18291b13553a38aa0e86569 Author: Douglas Anderson Date: Wed Dec 14 15:05:49 2016 -0800 kernel/debug/debug_core.c: more properly delay for secondary CPUs [ Upstream commit 2d13bb6494c807bcf3f78af0e96c0b8615a94385 ] We've got a delay loop waiting for secondary CPUs. That loop uses loops_per_jiffy. However, loops_per_jiffy doesn't actually mean how many tight loops make up a jiffy on all architectures. It is quite common to see things like this in the boot log: Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=24000) In my case I was seeing lots of cases where other CPUs timed out entering the debugger only to print their stack crawls shortly after the kdb> prompt was written. Elsewhere in kgdb we already use udelay(), so that should be safe enough to use to implement our timeout. We'll delay 1 ms for 1000 times, which should give us a full second of delay (just like the old code wanted) but allow us to notice that we're done every 1 ms. [akpm@linux-foundation.org: simplifications, per Daniel] Link: http://lkml.kernel.org/r/1477091361-2039-1-git-send-email-dianders@chromium.org Signed-off-by: Douglas Anderson Reviewed-by: Daniel Thompson Cc: Jason Wessel Cc: Brian Norris Cc: [4.0+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 1b51fce881b201cc00e88f64357d61b067e6b588 Author: Wei Fang Date: Tue Dec 13 09:25:21 2016 +0800 scsi: avoid a permanent stop of the scsi device's request queue [ Upstream commit d2a145252c52792bc59e4767b486b26c430af4bb ] A race between scanning and fc_remote_port_delete() may result in a permanent stop if the device gets blocked before scsi_sysfs_add_sdev() and unblocked after. The reason is that blocking a device sets both the SDEV_BLOCKED state and the QUEUE_FLAG_STOPPED. However, scsi_sysfs_add_sdev() unconditionally sets SDEV_RUNNING which causes the device to be ignored by scsi_target_unblock() and thus never have its QUEUE_FLAG_STOPPED cleared leading to a device which is apparently running but has a stopped queue. We actually have two places where SDEV_RUNNING is set: once in scsi_add_lun() which respects the blocked flag and once in scsi_sysfs_add_sdev() which doesn't. Since the second set is entirely spurious, simply remove it to fix the problem. Cc: Reported-by: Zengxi Chen Signed-off-by: Wei Fang Reviewed-by: Ewan D. Milne Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit f413092ea8e0c838c784abfcbd927d44ee6d01c7 Author: Bart Van Assche Date: Mon Nov 21 10:22:17 2016 -0800 IB/multicast: Check ib_find_pkey() return value [ Upstream commit d3a2418ee36a59bc02e9d454723f3175dcf4bfd9 ] This patch avoids that Coverity complains about not checking the ib_find_pkey() return value. Fixes: commit 547af76521b3 ("IB/multicast: Report errors on multicast groups if P_key changes") Signed-off-by: Bart Van Assche Cc: Sean Hefty Cc: Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin commit 8c84816cedcbd17d0b1c8e8ce991a0dadf47f301 Author: Bart Van Assche Date: Mon Nov 21 10:21:41 2016 -0800 IPoIB: Avoid reading an uninitialized member variable [ Upstream commit 11b642b84e8c43e8597de031678d15c08dd057bc ] This patch avoids that Coverity reports the following: Using uninitialized value port_attr.state when calling printk Fixes: commit 94232d9ce817 ("IPoIB: Start multicast join process only on active ports") Signed-off-by: Bart Van Assche Cc: Erez Shitrit Cc: Reviewed-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin commit 5eba61298b748b9f948a1de1055e84e620299d81 Author: NeilBrown Date: Mon Dec 12 08:21:51 2016 -0700 block_dev: don't test bdev->bd_contains when it is not stable [ Upstream commit bcc7f5b4bee8e327689a4d994022765855c807ff ] bdev->bd_contains is not stable before calling __blkdev_get(). When __blkdev_get() is called on a parition with ->bd_openers == 0 it sets bdev->bd_contains = bdev; which is not correct for a partition. After a call to __blkdev_get() succeeds, ->bd_openers will be > 0 and then ->bd_contains is stable. When FMODE_EXCL is used, blkdev_get() calls bd_start_claiming() -> bd_prepare_to_claim() -> bd_may_claim() This call happens before __blkdev_get() is called, so ->bd_contains is not stable. So bd_may_claim() cannot safely use ->bd_contains. It currently tries to use it, and this can lead to a BUG_ON(). This happens when a whole device is already open with a bd_holder (in use by dm in my particular example) and two threads race to open a partition of that device for the first time, one opening with O_EXCL and one without. The thread that doesn't use O_EXCL gets through blkdev_get() to __blkdev_get(), gains the ->bd_mutex, and sets bdev->bd_contains = bdev; Immediately thereafter the other thread, using FMODE_EXCL, calls bd_start_claiming() from blkdev_get(). This should fail because the whole device has a holder, but because bdev->bd_contains == bdev bd_may_claim() incorrectly reports success. This thread continues and blocks on bd_mutex. The first thread then sets bdev->bd_contains correctly and drops the mutex. The thread using FMODE_EXCL then continues and when it calls bd_may_claim() again in: BUG_ON(!bd_may_claim(bdev, whole, holder)); The BUG_ON fires. Fix this by removing the dependency on ->bd_contains in bd_may_claim(). As bd_may_claim() has direct access to the whole device, it can simply test if the target bdev is the whole device. Fixes: 6b4517a7913a ("block: implement bd_claiming and claiming block") Cc: stable@vger.kernel.org (v2.6.35+) Signed-off-by: NeilBrown Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 25e9e23674573b1e52c4b7e663af0ac6716ffaff Author: Maxim Patlasov Date: Mon Dec 12 14:32:44 2016 -0800 btrfs: limit async_work allocation and worker func duration [ Upstream commit 2939e1a86f758b55cdba73e29397dd3d94df13bc ] Problem statement: unprivileged user who has read-write access to more than one btrfs subvolume may easily consume all kernel memory (eventually triggering oom-killer). Reproducer (./mkrmdir below essentially loops over mkdir/rmdir): [root@kteam1 ~]# cat prep.sh DEV=/dev/sdb mkfs.btrfs -f $DEV mount $DEV /mnt for i in `seq 1 16` do mkdir /mnt/$i btrfs subvolume create /mnt/SV_$i ID=`btrfs subvolume list /mnt |grep "SV_$i$" |cut -d ' ' -f 2` mount -t btrfs -o subvolid=$ID $DEV /mnt/$i chmod a+rwx /mnt/$i done [root@kteam1 ~]# sh prep.sh [maxim@kteam1 ~]$ for i in `seq 1 16`; do ./mkrmdir /mnt/$i 2000 2000 & done [root@kteam1 ~]# for i in `seq 1 4`; do grep "kmalloc-128" /proc/slabinfo | grep -v dma; sleep 60; done kmalloc-128 10144 10144 128 32 1 : tunables 0 0 0 : slabdata 317 317 0 kmalloc-128 9992352 9992352 128 32 1 : tunables 0 0 0 : slabdata 312261 312261 0 kmalloc-128 24226752 24226752 128 32 1 : tunables 0 0 0 : slabdata 757086 757086 0 kmalloc-128 42754240 42754240 128 32 1 : tunables 0 0 0 : slabdata 1336070 1336070 0 The huge numbers above come from insane number of async_work-s allocated and queued by btrfs_wq_run_delayed_node. The problem is caused by btrfs_wq_run_delayed_node() queuing more and more works if the number of delayed items is above BTRFS_DELAYED_BACKGROUND. The worker func (btrfs_async_run_delayed_root) processes at least BTRFS_DELAYED_BATCH items (if they are present in the list). So, the machinery works as expected while the list is almost empty. As soon as it is getting bigger, worker func starts to process more than one item at a time, it takes longer, and the chances to have async_works queued more than needed is getting higher. The problem above is worsened by another flaw of delayed-inode implementation: if async_work was queued in a throttling branch (number of items >= BTRFS_DELAYED_WRITEBACK), corresponding worker func won't quit until the number of items < BTRFS_DELAYED_BACKGROUND / 2. So, it is possible that the func occupies CPU infinitely (up to 30sec in my experiments): while the func is trying to drain the list, the user activity may add more and more items to the list. The patch fixes both problems in straightforward way: refuse queuing too many works in btrfs_wq_run_delayed_node and bail out of worker func if at least BTRFS_DELAYED_WRITEBACK items are processed. Changed in v2: remove support of thresh == NO_THRESHOLD. Signed-off-by: Maxim Patlasov Signed-off-by: Chris Mason Cc: stable@vger.kernel.org # v3.15+ Signed-off-by: Sasha Levin commit ced9b7a66a35568fd21c9885e7d7c51d00c084b6 Author: Shaohua Li Date: Mon Dec 12 16:41:50 2016 -0800 mm/vmscan.c: set correct defer count for shrinker [ Upstream commit 5f33a0803bbd781de916f5c7448cbbbbc763d911 ] Our system uses significantly more slab memory with memcg enabled with the latest kernel. With 3.10 kernel, slab uses 2G memory, while with 4.6 kernel, 6G memory is used. The shrinker has problem. Let's see we have two memcg for one shrinker. In do_shrink_slab: 1. Check cg1. nr_deferred = 0, assume total_scan = 700. batch size is 1024, then no memory is freed. nr_deferred = 700 2. Check cg2. nr_deferred = 700. Assume freeable = 20, then total_scan = 10 or 40. Let's assume it's 10. No memory is freed. nr_deferred = 10. The deferred share of cg1 is lost in this case. kswapd will free no memory even run above steps again and again. The fix makes sure one memcg's deferred share isn't lost. Link: http://lkml.kernel.org/r/2414be961b5d25892060315fbb56bb19d81d0c07.1476227351.git.shli@fb.com Signed-off-by: Shaohua Li Cc: Johannes Weiner Cc: Michal Hocko Cc: Vladimir Davydov Cc: [4.0+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit a62e45871b7b8e69a6fe62a0d2b812bb1156658a Author: Jingkui Wang Date: Mon Dec 12 13:51:46 2016 -0800 Input: drv260x - fix input device's parent assignment [ Upstream commit 5a8a6b89c15766446d845671d574a9243b6d8786 ] We were assigning I2C bus controller instead of client as parent device. Besides being logically wrong, it messed up with devm handling of input device. As a result we were leaving input device and event node behind after rmmod-ing the driver, which lead to a kernel oops if one were to access the event node later. Let's remove the assignment and rely on devm_input_allocate_device() to set it up properly for us. Signed-off-by: Jingkui Wang Fixes: 7132fe4f5687 ("Input: drv260x - add TI drv260x haptics driver") Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit e1589b27ffb95ef8286dee5c2a2e4f7ab97763cd Author: Ilya Dryomov Date: Fri Dec 2 16:35:09 2016 +0100 libceph: verify authorize reply on connect [ Upstream commit 5c056fdc5b474329037f2aa18401bd73033e0ce0 ] After sending an authorizer (ceph_x_authorize_a + ceph_x_authorize_b), the client gets back a ceph_x_authorize_reply, which it is supposed to verify to ensure the authenticity and protect against replay attacks. The code for doing this is there (ceph_x_verify_authorizer_reply(), ceph_auth_verify_authorizer_reply() + plumbing), but it is never invoked by the the messenger. AFAICT this goes back to 2009, when ceph authentication protocols support was added to the kernel client in 4e7a5dcd1bba ("ceph: negotiate authentication protocol; implement AUTH_NONE protocol"). The second param of ceph_connection_operations::verify_authorizer_reply is unused all the way down. Pass 0 to facilitate backporting, and kill it in the next commit. Cc: stable@vger.kernel.org Signed-off-by: Ilya Dryomov Reviewed-by: Sage Weil Signed-off-by: Sasha Levin commit ed21b94ebbf4218baadbaad82bbea8a43a8bf5a9 Author: Jussi Laako Date: Mon Nov 28 11:27:45 2016 +0200 ALSA: hiface: Fix M2Tech hiFace driver sampling rate change [ Upstream commit 995c6a7fd9b9212abdf01160f6ce3193176be503 ] Sampling rate changes after first set one are not reflected to the hardware, while driver and ALSA think the rate has been changed. Fix the problem by properly stopping the interface at the beginning of prepare call, allowing new rate to be set to the hardware. This keeps the hardware in sync with the driver. Signed-off-by: Jussi Laako Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit f8c36e2b98b7b5ea41a01c60349f70764a4e33e6 Author: Gerald Schaefer Date: Mon Nov 21 12:13:58 2016 +0100 s390/vmlogrdr: fix IUCV buffer allocation [ Upstream commit 5457e03de918f7a3e294eb9d26a608ab8a579976 ] The buffer for iucv_message_receive() needs to be below 2 GB. In __iucv_message_receive(), the buffer address is casted to an u32, which would result in either memory corruption or an addressing exception when using addresses >= 2 GB. Fix this by using GFP_DMA for the buffer allocation. Cc: stable@vger.kernel.org Signed-off-by: Gerald Schaefer Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin commit 0848a2672eb3a9be93b6eb0c28e7c161f465ca97 Author: Ben Hutchings Date: Thu Nov 24 22:10:23 2016 +0000 kconfig/nconf: Fix hang when editing symbol with a long prompt [ Upstream commit 79e51b5c2deea542b3bb8c66e0d502230b017dde ] Currently it is impossible to edit the value of a config symbol with a prompt longer than (terminal width - 2) characters. dialog_inputbox() calculates a negative x-offset for the input window and newwin() fails as this is invalid. It also doesn't check for this failure, so it busy-loops calling wgetch(NULL) which immediately returns -1. The additions in the offset calculations also don't match the intended size of the window. Limit the window size and calculate the offset similarly to show_scroll_win(). Cc: stable Fixes: 692d97c380c6 ("kconfig: new configuration interface (nconfig)") Signed-off-by: Ben Hutchings Signed-off-by: Sasha Levin commit 7b53fb41d44765193a0e3211d42a96dd9cf0b92d Author: NeilBrown Date: Mon Dec 5 15:10:11 2016 +1100 SUNRPC: fix refcounting problems with auth_gss messages. [ Upstream commit 1cded9d2974fe4fe339fc0ccd6638b80d465ab2c ] There are two problems with refcounting of auth_gss messages. First, the reference on the pipe->pipe list (taken by a call to rpc_queue_upcall()) is not counted. It seems to be assumed that a message in pipe->pipe will always also be in pipe->in_downcall, where it is correctly reference counted. However there is no guaranty of this. I have a report of a NULL dereferences in rpc_pipe_read() which suggests a msg that has been freed is still on the pipe->pipe list. One way I imagine this might happen is: - message is queued for uid=U and auth->service=S1 - rpc.gssd reads this message and starts processing. This removes the message from pipe->pipe - message is queued for uid=U and auth->service=S2 - rpc.gssd replies to the first message. gss_pipe_downcall() calls __gss_find_upcall(pipe, U, NULL) and it finds the *second* message, as new messages are placed at the head of ->in_downcall, and the service type is not checked. - This second message is removed from ->in_downcall and freed by gss_release_msg() (even though it is still on pipe->pipe) - rpc.gssd tries to read another message, and dereferences a pointer to this message that has just been freed. I fix this by incrementing the reference count before calling rpc_queue_upcall(), and decrementing it if that fails, or normally in gss_pipe_destroy_msg(). It seems strange that the reply doesn't target the message more precisely, but I don't know all the details. In any case, I think the reference counting irregularity became a measureable bug when the extra arg was added to __gss_find_upcall(), hence the Fixes: line below. The second problem is that if rpc_queue_upcall() fails, the new message is not freed. gss_alloc_msg() set the ->count to 1, gss_add_msg() increments this to 2, gss_unhash_msg() decrements to 1, then the pointer is discarded so the memory never gets freed. Fixes: 9130b8dbc6ac ("SUNRPC: allow for upcalls for same uid but different gss service") Cc: stable@vger.kernel.org Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1011250 Signed-off-by: NeilBrown Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 14927595fec915a90a050a1f43c20ca6a4115785 Author: Dan Carpenter Date: Sat Dec 10 09:56:01 2016 -0500 ext4: return -ENOMEM instead of success [ Upstream commit 578620f451f836389424833f1454eeeb2ffc9e9f ] We should set the error code if kzalloc() fails. Fixes: 67cf5b09a46f ("ext4: add the basic function for inline data support") Signed-off-by: Dan Carpenter Signed-off-by: Theodore Ts'o Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 576cfe615febe0eccc95f7884ef998d15024b025 Author: Al Viro Date: Mon Sep 5 21:42:32 2016 -0400 nfs_write_end(): fix handling of short copies [ Upstream commit c0cf3ef5e0f47e385920450b245d22bead93e7ad ] What matters when deciding if we should make a page uptodate is not how much we _wanted_ to copy, but how much we actually have copied. As it is, on architectures that do not zero tail on short copy we can leave uninitialized data in page marked uptodate. Cc: stable@vger.kernel.org Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 77f3c11c13ddf7aa5b63b1f8b2e238d93cc6ecaf Author: Steven Rostedt (Red Hat) Date: Thu Dec 8 20:54:49 2016 -0500 fgraph: Handle a case where a tracer ignores set_graph_notrace [ Upstream commit 794de08a16cf1fc1bf785dc48f66d36218cf6d88 ] Both the wakeup and irqsoff tracers can use the function graph tracer when the display-graph option is set. The problem is that they ignore the notrace file, and record the entry of functions that would be ignored by the function_graph tracer. This causes the trace->depth to be recorded into the ring buffer. The set_graph_notrace uses a trick by adding a large negative number to the trace->depth when a graph function is to be ignored. On trace output, the graph function uses the depth to record a stack of functions. But since the depth is negative, it accesses the array with a negative number and causes an out of bounds access that can cause a kernel oops or corrupt data. Have the print functions handle cases where a tracer still records functions even when they are in set_graph_notrace. Also add warnings if the depth is below zero before accessing the array. Note, the function graph logic will still prevent the return of these functions from being recorded, which means that they will be left hanging without a return. For example: # echo '*spin*' > set_graph_notrace # echo 1 > options/display-graph # echo wakeup > current_tracer # cat trace [...] _raw_spin_lock() { preempt_count_add() { do_raw_spin_lock() { update_rq_clock(); Where it should look like: _raw_spin_lock() { preempt_count_add(); do_raw_spin_lock(); } update_rq_clock(); Cc: stable@vger.kernel.org Cc: Namhyung Kim Fixes: 29ad23b00474 ("ftrace: Add set_graph_notrace filter") Signed-off-by: Steven Rostedt Signed-off-by: Sasha Levin commit 29955c9a00d52120ddbe249e658c2133c88d7645 Author: Thomas Gleixner Date: Thu Dec 8 20:49:32 2016 +0000 timekeeping_Force_unsigned_clocksource_to_nanoseconds_conversion [ Upstream commit 9c1645727b8fa90d07256fdfcc45bf831242a3ab ] The clocksource delta to nanoseconds conversion is using signed math, but the delta is unsigned. This makes the conversion space smaller than necessary and in case of a multiplication overflow the conversion can become negative. The conversion is done with scaled math: s64 nsec_delta = ((s64)clkdelta * clk->mult) >> clk->shift; Shifting a signed integer right obvioulsy preserves the sign, which has interesting consequences: - Time jumps backwards - __iter_div_u64_rem() which is used in one of the calling code pathes will take forever to piecewise calculate the seconds/nanoseconds part. This has been reported by several people with different scenarios: David observed that when stopping a VM with a debugger: "It was essentially the stopped by debugger case. I forget exactly why, but the guest was being explicitly stopped from outside, it wasn't just scheduling lag. I think it was something in the vicinity of 10 minutes stopped." When lifting the stop the machine went dead. The stopped by debugger case is not really interesting, but nevertheless it would be a good thing not to die completely. But this was also observed on a live system by Liav: "When the OS is too overloaded, delta will get a high enough value for the msb of the sum delta * tkr->mult + tkr->xtime_nsec to be set, and so after the shift the nsec variable will gain a value similar to 0xffffffffff000000." Unfortunately this has been reintroduced recently with commit 6bd58f09e1d8 ("time: Add cycles to nanoseconds translation"). It had been fixed a year ago already in commit 35a4933a8959 ("time: Avoid signed overflow in timekeeping_get_ns()"). Though it's not surprising that the issue has been reintroduced because the function itself and the whole call chain uses s64 for the result and the propagation of it. The change in this recent commit is subtle: s64 nsec; - nsec = (d * m + n) >> s: + nsec = d * m + n; + nsec >>= s; d being type of cycle_t adds another level of obfuscation. This wouldn't have happened if the previous change to unsigned computation would have made the 'nsec' variable u64 right away and a follow up patch had cleaned up the whole call chain. There have been patches submitted which basically did a revert of the above patch leaving everything else unchanged as signed. Back to square one. This spawned a admittedly pointless discussion about potential users which rely on the unsigned behaviour until someone pointed out that it had been fixed before. The changelogs of said patches added further confusion as they made finally false claims about the consequences for eventual users which expect signed results. Despite delta being cycle_t, aka. u64, it's very well possible to hand in a signed negative value and the signed computation will happily return the correct result. But nobody actually sat down and analyzed the code which was added as user after the propably unintended signed conversion. Though in sensitive code like this it's better to analyze it proper and make sure that nothing relies on this than hunting the subtle wreckage half a year later. After analyzing all call chains it stands that no caller can hand in a negative value (which actually would work due to the s64 cast) and rely on the signed math to do the right thing. Change the conversion function to unsigned math. The conversion of all call chains is done in a follow up patch. This solves the starvation issue, which was caused by the negative result, but it does not solve the underlying problem. It merily procrastinates it. When the timekeeper update is deferred long enough that the unsigned multiplication overflows, then time going backwards is observable again. It does neither solve the issue of clocksources with a small counter width which will wrap around possibly several times and cause random time stamps to be generated. But those are usually not found on systems used for virtualization, so this is likely a non issue. I took the liberty to claim authorship for this simply because analyzing all callsites and writing the changelog took substantially more time than just making the simple s/s64/u64/ change and ignore the rest. Fixes: 6bd58f09e1d8 ("time: Add cycles to nanoseconds translation") Reported-by: David Gibson Reported-by: Liav Rehana Signed-off-by: Thomas Gleixner Reviewed-by: David Gibson Acked-by: Peter Zijlstra (Intel) Cc: Parit Bhargava Cc: Laurent Vivier Cc: "Christopher S. Hall" Cc: Chris Metcalf Cc: Richard Cochran Cc: John Stultz Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/20161208204228.688545601@linutronix.de Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin commit 951f4b1f13a75f024d2b39f76df47c998c7580fc Author: Giuseppe Lippolis Date: Tue Dec 6 21:24:19 2016 +0100 USB: serial: option: add dlink dwm-158 [ Upstream commit d8a12b7117b42fd708f1e908498350232bdbd5ff ] Adding registration for 3G modem DWM-158 in usb-serial-option Signed-off-by: Giuseppe Lippolis Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0c4f2f61d68f819910369e81535549fc7a10cb88 Author: Daniele Palmas Date: Thu Dec 1 16:38:39 2016 +0100 USB: serial: option: add support for Telit LE922A PIDs 0x1040, 0x1041 [ Upstream commit 5b09eff0c379002527ad72ea5ea38f25da8a8650 ] This patch adds support for PIDs 0x1040, 0x1041 of Telit LE922A. Since the interface positions are the same than the ones used for other Telit compositions, previous defined blacklists are used. Signed-off-by: Daniele Palmas Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0a32f5b4f72d601b53f9213221c2aacb803d3cb6 Author: Con Kolivas Date: Fri Dec 9 15:15:57 2016 +1100 ALSA: usb-audio: Add QuickCam Communicate Deluxe/S7500 to volume_control_quirks [ Upstream commit 82ffb6fc637150b279f49e174166d2aa3853eaf4 ] The Logitech QuickCam Communicate Deluxe/S7500 microphone fails with the following warning. [ 6.778995] usb 2-1.2.2.2: Warning! Unlikely big volume range (=3072), cval->res is probably wrong. [ 6.778996] usb 2-1.2.2.2: [5] FU [Mic Capture Volume] ch = 1, val = 4608/7680/1 Adding it to the list of devices in volume_control_quirks makes it work properly, fixing related typo. Signed-off-by: Con Kolivas Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 1d53a630766ef6c786eae2ed64b0ac5831789d17 Author: Benjamin Marzinski Date: Wed Nov 30 17:56:14 2016 -0600 dm space map metadata: fix 'struct sm_metadata' leak on failed create [ Upstream commit 314c25c56c1ee5026cf99c570bdfe01847927acb ] In dm_sm_metadata_create() we temporarily change the dm_space_map operations from 'ops' (whose .destroy function deallocates the sm_metadata) to 'bootstrap_ops' (whose .destroy function doesn't). If dm_sm_metadata_create() fails in sm_ll_new_metadata() or sm_ll_extend(), it exits back to dm_tm_create_internal(), which calls dm_sm_destroy() with the intention of freeing the sm_metadata, but it doesn't (because the dm_space_map operations is still set to 'bootstrap_ops'). Fix this by setting the dm_space_map operations back to 'ops' if dm_sm_metadata_create() fails when it is set to 'bootstrap_ops'. Signed-off-by: Benjamin Marzinski Acked-by: Joe Thornber Signed-off-by: Mike Snitzer Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 67bcfac25cb8627476535870e611bf3159134f73 Author: Julien Grall Date: Wed Dec 7 12:24:40 2016 +0000 arm/xen: Use alloc_percpu rather than __alloc_percpu [ Upstream commit 24d5373dda7c00a438d26016bce140299fae675e ] The function xen_guest_init is using __alloc_percpu with an alignment which are not power of two. However, the percpu allocator never supported alignments which are not power of two and has always behaved incorectly in thise case. Commit 3ca45a4 "percpu: ensure requested alignment is power of two" introduced a check which trigger a warning [1] when booting linux-next on Xen. But in reality this bug was always present. This can be fixed by replacing the call to __alloc_percpu with alloc_percpu. The latter will use an alignment which are a power of two. [1] [ 0.023921] illegal size (48) or align (48) for percpu allocation [ 0.024167] ------------[ cut here ]------------ [ 0.024344] WARNING: CPU: 0 PID: 1 at linux/mm/percpu.c:892 pcpu_alloc+0x88/0x6c0 [ 0.024584] Modules linked in: [ 0.024708] [ 0.024804] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-rc7-next-20161128 #473 [ 0.025012] Hardware name: Foundation-v8A (DT) [ 0.025162] task: ffff80003d870000 task.stack: ffff80003d844000 [ 0.025351] PC is at pcpu_alloc+0x88/0x6c0 [ 0.025490] LR is at pcpu_alloc+0x88/0x6c0 [ 0.025624] pc : [] lr : [] pstate: 60000045 [ 0.025830] sp : ffff80003d847cd0 [ 0.025946] x29: ffff80003d847cd0 x28: 0000000000000000 [ 0.026147] x27: 0000000000000000 x26: 0000000000000000 [ 0.026348] x25: 0000000000000000 x24: 0000000000000000 [ 0.026549] x23: 0000000000000000 x22: 00000000024000c0 [ 0.026752] x21: ffff000008e97000 x20: 0000000000000000 [ 0.026953] x19: 0000000000000030 x18: 0000000000000010 [ 0.027155] x17: 0000000000000a3f x16: 00000000deadbeef [ 0.027357] x15: 0000000000000006 x14: ffff000088f79c3f [ 0.027573] x13: ffff000008f79c4d x12: 0000000000000041 [ 0.027782] x11: 0000000000000006 x10: 0000000000000042 [ 0.027995] x9 : ffff80003d847a40 x8 : 6f697461636f6c6c [ 0.028208] x7 : 6120757063726570 x6 : ffff000008f79c84 [ 0.028419] x5 : 0000000000000005 x4 : 0000000000000000 [ 0.028628] x3 : 0000000000000000 x2 : 000000000000017f [ 0.028840] x1 : ffff80003d870000 x0 : 0000000000000035 [ 0.029056] [ 0.029152] ---[ end trace 0000000000000000 ]--- [ 0.029297] Call trace: [ 0.029403] Exception stack(0xffff80003d847b00 to 0xffff80003d847c30) [ 0.029621] 7b00: 0000000000000030 0001000000000000 ffff80003d847cd0 ffff00000818e678 [ 0.029901] 7b20: 0000000000000002 0000000000000004 ffff000008f7c060 0000000000000035 [ 0.030153] 7b40: ffff000008f79000 ffff000008c4cd88 ffff80003d847bf0 ffff000008101778 [ 0.030402] 7b60: 0000000000000030 0000000000000000 ffff000008e97000 00000000024000c0 [ 0.030647] 7b80: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 0.030895] 7ba0: 0000000000000035 ffff80003d870000 000000000000017f 0000000000000000 [ 0.031144] 7bc0: 0000000000000000 0000000000000005 ffff000008f79c84 6120757063726570 [ 0.031394] 7be0: 6f697461636f6c6c ffff80003d847a40 0000000000000042 0000000000000006 [ 0.031643] 7c00: 0000000000000041 ffff000008f79c4d ffff000088f79c3f 0000000000000006 [ 0.031877] 7c20: 00000000deadbeef 0000000000000a3f [ 0.032051] [] pcpu_alloc+0x88/0x6c0 [ 0.032229] [] __alloc_percpu+0x18/0x20 [ 0.032409] [] xen_guest_init+0x174/0x2f4 [ 0.032591] [] do_one_initcall+0x38/0x130 [ 0.032783] [] kernel_init_freeable+0xe0/0x248 [ 0.032995] [] kernel_init+0x10/0x100 [ 0.033172] [] ret_from_fork+0x10/0x50 Reported-by: Wei Chen Link: https://lkml.org/lkml/2016/11/28/669 Signed-off-by: Julien Grall Signed-off-by: Stefano Stabellini Reviewed-by: Stefano Stabellini Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit d09b66f9e70bac9ea2e0d7b4069f0c7e7a89b782 Author: Alex Deucher Date: Fri Dec 2 00:21:48 2016 -0500 drm/radeon: add additional pci revision to dpm workaround [ Upstream commit 8729675c00a8d13cb2094d617d70a4a4da7d83c5 ] New variant. Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit e9631583d6c0815abd6ce236ad05485fa0c27b60 Author: Michel Dänzer Date: Thu Oct 27 14:54:31 2016 +0900 drm/radeon: Hide the HW cursor while it's out of bounds [ Upstream commit 6b16cf7785a4200b1bddf4f70c9dda2efc49e278 ] Fixes hangs in that case under some circumstances. v2: * Only use non-0 x/yorigin if the cursor is (partially) outside of the top/left edge of the total surface with AVIVO/DCE Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1000433 Cc: stable@vger.kernel.org Signed-off-by: Michel Dänzer Reviewed-by: Alex Deucher (v1) Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit beeda93356ae5e69653013606d3fe2ce5f74bf75 Author: Michel Dänzer Date: Thu Oct 27 15:37:44 2016 +0900 drm/radeon: Always store CRTC relative radeon_crtc->cursor_x/y values [ Upstream commit 4349bd775cc8fd75cb648e3a2036a690f497de5c ] We were storing viewport relative coordinates for AVIVO/DCE display engines. However, radeon_crtc_cursor_set2 and radeon_cursor_reset pass radeon_crtc->cursor_x/y as the x/y parameters of radeon_cursor_move_locked, which would break if the CRTC isn't located at (0, 0). Cc: stable@vger.kernel.org Signed-off-by: Michel Dänzer Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 7198dbbaa242e151abc94c67bc926b302bb4e799 Author: Michel Dänzer Date: Thu Oct 27 13:03:23 2016 +0900 drm/radeon: Also call cursor_move_locked when the cursor size changes [ Upstream commit dcab0fa64e300afa18f39cd98d05e0950f652adf ] The cursor size also affects the register programming. Cc: stable@vger.kernel.org Signed-off-by: Michel Dänzer Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 15a12fbbf365a483b1c19f9caeb707b3bea77e10 Author: Pavel Shilovsky Date: Fri Nov 4 11:50:31 2016 -0700 CIFS: Fix a possible memory corruption during reconnect [ Upstream commit 53e0e11efe9289535b060a51d4cf37c25e0d0f2b ] We can not unlock/lock cifs_tcp_ses_lock while walking through ses and tcon lists because it can corrupt list iterator pointers and a tcon structure can be released if we don't hold an extra reference. Fix it by moving a reconnect process to a separate delayed work and acquiring a reference to every tcon that needs to be reconnected. Also do not send an echo request on newly established connections. CC: Stable Signed-off-by: Pavel Shilovsky Signed-off-by: Sasha Levin commit 51fce08b64ec4d8cb2cc91eb08a84caf29dcd272 Author: Pavel Shilovsky Date: Tue Nov 29 16:14:43 2016 -0800 CIFS: Fix a possible memory corruption in push locks [ Upstream commit e3d240e9d505fc67f8f8735836df97a794bbd946 ] If maxBuf is not 0 but less than a size of SMB2 lock structure we can end up with a memory corruption. Cc: Stable Signed-off-by: Pavel Shilovsky Signed-off-by: Sasha Levin commit 7f16769173dfa6c3f616602d633452eda4b0c1fc Author: Pavel Shilovsky Date: Tue Nov 29 11:30:58 2016 -0800 CIFS: Fix missing nls unload in smb2_reconnect() [ Upstream commit 4772c79599564bd08ee6682715a7d3516f67433f ] Cc: Stable Acked-by: Sachin Prabhu Signed-off-by: Pavel Shilovsky Signed-off-by: Sasha Levin commit 0ee8faf89305e7e8ace820a214089e17c1375eac Author: Nathaniel Quillin Date: Mon Dec 5 06:53:00 2016 -0800 USB: cdc-acm: add device id for GW Instek AFG-125 [ Upstream commit 301216044e4c27d5a7323c1fa766266fad00db5e ] Add device-id entry for GW Instek AFG-125, which has a byte swapped bInterfaceSubClass (0x20). Signed-off-by: Nathaniel Quillin Acked-by: Oliver Neukum Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a2080cc28041dedeec50b5610beaa00850c62d73 Author: Adrian Hunter Date: Fri Dec 2 15:14:20 2016 +0200 mmc: sdhci: Fix recovery from tuning timeout [ Upstream commit 61e53bd0047d58caee0c7170613045bf96de4458 ] Clearing the tuning bits should reset the tuning circuit. However there is more to do. Reset the command and data lines for good measure, and then for eMMC ensure the card is not still trying to process a tuning command by sending a stop command. Note the JEDEC eMMC specification says the stop command (CMD12) can be used to stop a tuning command (CMD21) whereas the SD specification is silent on the subject with respect to the SD tuning command (CMD19). Considering that CMD12 is not a valid SDIO command, the stop command is sent only when the tuning command is CMD21 i.e. for eMMC. That addresses cases seen so far which have been on eMMC. Note that this replaces the commit fe5fb2e3b58f ("mmc: sdhci: Reset cmd and data circuits after tuning failure") which is being reverted for v4.9+. Signed-off-by: Adrian Hunter Tested-by: Dan O'Donovan Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 2a1dc36fdc71dabcf55ee316e09f5cc01b6a5a18 Author: Takashi Iwai Date: Mon Dec 5 11:19:38 2016 +0100 ALSA: usb-audio: Fix race at stopping the stream [ Upstream commit 16200948d8353fe29a473a394d7d26790deae0e7 ] We've got a kernel crash report showing like: Unable to handle kernel NULL pointer dereference at virtual address 00000008 pgd = a1d7c000 [00000008] *pgd=31c93831, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] PREEMPT SMP ARM CPU: 0 PID: 250 Comm: dbus-daemon Not tainted 3.14.51-03479-gf50bdf4 #1 task: a3ae61c0 ti: a08c8000 task.ti: a08c8000 PC is at retire_capture_urb+0x10/0x1f4 [snd_usb_audio] LR is at snd_complete_urb+0x140/0x1f0 [snd_usb_audio] pc : [<7f0eb22c>] lr : [<7f0e57fc>] psr: 200e0193 sp : a08c9c98 ip : a08c9ce8 fp : a08c9ce4 r10: 0000000a r9 : 00000102 r8 : 94cb3000 r7 : 94cb3000 r6 : 94d0f000 r5 : 94d0e8e8 r4 : 94d0e000 r3 : 7f0eb21c r2 : 00000000 r1 : 94cb3000 r0 : 00000000 Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 31d7c04a DAC: 00000015 Process dbus-daemon (pid: 250, stack limit = 0xa08c8238) Stack: (0xa08c9c98 to 0xa08ca000) ... Backtrace: [<7f0eb21c>] (retire_capture_urb [snd_usb_audio]) from [<7f0e57fc>] (snd_complete_urb+0x140/0x1f0 [snd_usb_audio]) [<7f0e56bc>] (snd_complete_urb [snd_usb_audio]) from [<80371118>] (__usb_hcd_giveback_urb+0x78/0xf4) [<803710a0>] (__usb_hcd_giveback_urb) from [<80371514>] (usb_giveback_urb_bh+0x8c/0xc0) [<80371488>] (usb_giveback_urb_bh) from [<80028e3c>] (tasklet_hi_action+0xc4/0x148) [<80028d78>] (tasklet_hi_action) from [<80028358>] (__do_softirq+0x190/0x380) [<800281c8>] (__do_softirq) from [<80028858>] (irq_exit+0x8c/0xfc) [<800287cc>] (irq_exit) from [<8000ea88>] (handle_IRQ+0x8c/0xc8) [<8000e9fc>] (handle_IRQ) from [<800085e8>] (gic_handle_irq+0xbc/0xf8) [<8000852c>] (gic_handle_irq) from [<80509044>] (__irq_svc+0x44/0x78) [<80508820>] (_raw_spin_unlock_irq) from [<8004b880>] (finish_task_switch+0x5c/0x100) [<8004b824>] (finish_task_switch) from [<805052f0>] (__schedule+0x48c/0x6d8) [<80504e64>] (__schedule) from [<805055d4>] (schedule+0x98/0x9c) [<8050553c>] (schedule) from [<800116c8>] (do_work_pending+0x30/0xd0) [<80011698>] (do_work_pending) from [<8000e160>] (work_pending+0xc/0x20) Code: e1a0c00d e92ddff0 e24cb004 e24dd024 (e5902008) Kernel panic - not syncing: Fatal exception in interrupt There is a race between retire_capture_urb() and stop_endpoints(). The latter is called at stopping the stream and it sets some endpoint fields to NULL. But its call is asynchronous, thus the pending complete callback might get called after these NULL clears, and it leads the NULL dereference like the above. The fix is to move the NULL clearance after the synchronization, i.e. wait_clear_urbs(). This is called at prepare and hw_free callbacks, so it's assured to be called before the restart of the stream or the release of the stream. Also, while we're at it, put the EP_FLAG_RUNNING flag check at the beginning of snd_complete_urb() to skip the pending complete after the stream is stopped. Fixes: b2eb950de2f0 ("ALSA: usb-audio: stop both data and sync...") Reported-by: Jiada Wang Reported-by: Mark Craske Cc: Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 93f5b2b5d28b7610d5255475c4e22ff90b6cc9c0 Author: Eric Sandeen Date: Mon Dec 5 12:31:06 2016 +1100 xfs: set AGI buffer type in xlog_recover_clear_agi_bucket [ Upstream commit 6b10b23ca94451fae153a5cc8d62fd721bec2019 ] xlog_recover_clear_agi_bucket didn't set the type to XFS_BLFT_AGI_BUF, so we got a warning during log replay (or an ASSERT on a debug build). XFS (md0): Unknown buffer type 0! XFS (md0): _xfs_buf_ioapply: no ops on block 0xaea8802/0x1 Fix this, as was done in f19b872b for 2 other locations with the same problem. cc: # 3.10 to current Signed-off-by: Eric Sandeen Reviewed-by: Brian Foster Reviewed-by: Christoph Hellwig Signed-off-by: Dave Chinner Signed-off-by: Sasha Levin commit 73e7d7aef06c4f590c539844782d3720c7958efa Author: Rabin Vincent Date: Thu Dec 1 09:18:28 2016 +0100 block: protect iterate_bdevs() against concurrent close [ Upstream commit af309226db916e2c6e08d3eba3fa5c34225200c4 ] If a block device is closed while iterate_bdevs() is handling it, the following NULL pointer dereference occurs because bdev->b_disk is NULL in bdev_get_queue(), which is called from blk_get_backing_dev_info() (in turn called by the mapping_cap_writeback_dirty() call in __filemap_fdatawrite_range()): BUG: unable to handle kernel NULL pointer dereference at 0000000000000508 IP: [] blk_get_backing_dev_info+0x10/0x20 PGD 9e62067 PUD 9ee8067 PMD 0 Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC Modules linked in: CPU: 1 PID: 2422 Comm: sync Not tainted 4.5.0-rc7+ #400 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) task: ffff880009f4d700 ti: ffff880009f5c000 task.ti: ffff880009f5c000 RIP: 0010:[] [] blk_get_backing_dev_info+0x10/0x20 RSP: 0018:ffff880009f5fe68 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88000ec17a38 RCX: ffffffff81a4e940 RDX: 7fffffffffffffff RSI: 0000000000000000 RDI: ffff88000ec176c0 RBP: ffff880009f5fe68 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: ffff88000ec17860 R13: ffffffff811b25c0 R14: ffff88000ec178e0 R15: ffff88000ec17a38 FS: 00007faee505d700(0000) GS:ffff88000fb00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000508 CR3: 0000000009e8a000 CR4: 00000000000006e0 Stack: ffff880009f5feb8 ffffffff8112e7f5 0000000000000000 7fffffffffffffff 0000000000000000 0000000000000000 7fffffffffffffff 0000000000000001 ffff88000ec178e0 ffff88000ec17860 ffff880009f5fec8 ffffffff8112e81f Call Trace: [] __filemap_fdatawrite_range+0x85/0x90 [] filemap_fdatawrite+0x1f/0x30 [] fdatawrite_one_bdev+0x16/0x20 [] iterate_bdevs+0xf2/0x130 [] sys_sync+0x63/0x90 [] entry_SYSCALL_64_fastpath+0x12/0x76 Code: 0f 1f 44 00 00 48 8b 87 f0 00 00 00 55 48 89 e5 <48> 8b 80 08 05 00 00 5d RIP [] blk_get_backing_dev_info+0x10/0x20 RSP CR2: 0000000000000508 ---[ end trace 2487336ceb3de62d ]--- The crash is easily reproducible by running the following command, if an msleep(100) is inserted before the call to func() in iterate_devs(): while :; do head -c1 /dev/nullb0; done > /dev/null & while :; do sync; done Fix it by holding the bd_mutex across the func() call and only calling func() if the bdev is opened. Cc: stable@vger.kernel.org Fixes: 5c0d6b60a0ba ("vfs: Create function for iterating over block devices") Reported-and-tested-by: Wei Fang Signed-off-by: Rabin Vincent Signed-off-by: Jan Kara Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit a6d0744b18ae2e697fbd50b7986ee9eed96efe75 Author: Takashi Iwai Date: Fri Nov 25 16:54:06 2016 +0100 ASoC: intel: Fix crash at suspend/resume without card registration [ Upstream commit 2fc995a87f2efcd803438f07bfecd35cc3d90d32 ] When ASoC Intel SST Medfield driver is probed but without codec / card assigned, it causes an Oops and freezes the kernel at suspend/resume, PM: Suspending system (freeze) Suspending console(s) (use no_console_suspend to debug) BUG: unable to handle kernel NULL pointer dereference at 0000000000000018 IP: [] sst_soc_prepare+0x19/0xa0 [snd_soc_sst_mfld_platform] Oops: 0000 [#1] PREEMPT SMP CPU: 0 PID: 1552 Comm: systemd-sleep Tainted: G W 4.9.0-rc6-1.g5f5c2ad-default #1 Call Trace: [] dpm_prepare+0x209/0x460 [] dpm_suspend_start+0x11/0x60 [] suspend_devices_and_enter+0xb2/0x710 [] pm_suspend+0x30e/0x390 [] state_store+0x8a/0x90 [] kobj_attr_store+0xf/0x20 [] sysfs_kf_write+0x37/0x40 [] kernfs_fop_write+0x11c/0x1b0 [] __vfs_write+0x28/0x140 [] ? apparmor_file_permission+0x18/0x20 [] ? security_file_permission+0x3b/0xc0 [] vfs_write+0xb5/0x1a0 [] SyS_write+0x46/0xa0 [] entry_SYSCALL_64_fastpath+0x1e/0xad Add proper NULL checks in the PM code of mdfld driver. Signed-off-by: Takashi Iwai Acked-by: Vinod Koul Signed-off-by: Mark Brown Cc: Signed-off-by: Sasha Levin commit 90604ed2f10c9453814b8ca5a5b50243b5bf7c10 Author: Robbie Ko Date: Fri Oct 7 17:30:47 2016 +0800 Btrfs: fix tree search logic when replaying directory entry deletes [ Upstream commit 2a7bf53f577e49c43de4ffa7776056de26db65d9 ] If a log tree has a layout like the following: leaf N: ... item 240 key (282 DIR_LOG_ITEM 0) itemoff 8189 itemsize 8 dir log end 1275809046 leaf N + 1: item 0 key (282 DIR_LOG_ITEM 3936149215) itemoff 16275 itemsize 8 dir log end 18446744073709551615 ... When we pass the value 1275809046 + 1 as the parameter start_ret to the function tree-log.c:find_dir_range() (done by replay_dir_deletes()), we end up with path->slots[0] having the value 239 (points to the last item of leaf N, item 240). Because the dir log item in that position has an offset value smaller than *start_ret (1275809046 + 1) we need to move on to the next leaf, however the logic for that is wrong since it compares the current slot to the number of items in the leaf, which is smaller and therefore we don't lookup for the next leaf but instead we set the slot to point to an item that does not exist, at slot 240, and we later operate on that slot which has unexpected content or in the worst case can result in an invalid memory access (accessing beyond the last page of leaf N's extent buffer). So fix the logic that checks when we need to lookup at the next leaf by first incrementing the slot and only after to check if that slot is beyond the last item of the current leaf. Signed-off-by: Robbie Ko Reviewed-by: Filipe Manana Fixes: e02119d5a7b4 (Btrfs: Add a write ahead tree log to optimize synchronous operations) Cc: stable@vger.kernel.org # 2.6.29+ Signed-off-by: Filipe Manana [Modified changelog for clarity and correctness] Signed-off-by: Sasha Levin commit 575b6eddbf739a02bdaea80557cf0e203ef1b889 Author: Robbie Ko Date: Fri Oct 28 10:48:26 2016 +0800 Btrfs: fix deadlock caused by fsync when logging directory entries [ Upstream commit ec125cfb7ae2157af3dd45dd8abe823e3e233eec ] While logging new directory entries, at tree-log.c:log_new_dir_dentries(), after we call btrfs_search_forward() we get a leaf with a read lock on it, and without unlocking that leaf we can end up calling btrfs_iget() to get an inode pointer. The later (btrfs_iget()) can end up doing a read-only search on the same tree again, if the inode is not in memory already, which ends up causing a deadlock if some other task in the meanwhile started a write search on the tree and is attempting to write lock the same leaf that btrfs_search_forward() locked while holding write locks on upper levels of the tree blocking the read search from btrfs_iget(). In this scenario we get a deadlock. So fix this by releasing the search path before calling btrfs_iget() at tree-log.c:log_new_dir_dentries(). Example trace of such deadlock: [ 4077.478852] kworker/u24:10 D ffff88107fc90640 0 14431 2 0x00000000 [ 4077.486752] Workqueue: btrfs-endio-write btrfs_endio_write_helper [btrfs] [ 4077.494346] ffff880ffa56bad0 0000000000000046 0000000000009000 ffff880ffa56bfd8 [ 4077.502629] ffff880ffa56bfd8 ffff881016ce21c0 ffffffffa06ecb26 ffff88101a5d6138 [ 4077.510915] ffff880ebb5173b0 ffff880ffa56baf8 ffff880ebb517410 ffff881016ce21c0 [ 4077.519202] Call Trace: [ 4077.528752] [] ? btrfs_tree_lock+0xdd/0x2f0 [btrfs] [ 4077.536049] [] ? wake_up_atomic_t+0x30/0x30 [ 4077.542574] [] ? btrfs_search_slot+0x79f/0xb10 [btrfs] [ 4077.550171] [] ? btrfs_lookup_file_extent+0x33/0x40 [btrfs] [ 4077.558252] [] ? __btrfs_drop_extents+0x13b/0xdf0 [btrfs] [ 4077.566140] [] ? add_delayed_data_ref+0xe2/0x150 [btrfs] [ 4077.573928] [] ? btrfs_add_delayed_data_ref+0x149/0x1d0 [btrfs] [ 4077.582399] [] ? __set_extent_bit+0x4c0/0x5c0 [btrfs] [ 4077.589896] [] ? insert_reserved_file_extent.constprop.75+0xa4/0x320 [btrfs] [ 4077.599632] [] ? start_transaction+0x8d/0x470 [btrfs] [ 4077.607134] [] ? btrfs_finish_ordered_io+0x2e7/0x600 [btrfs] [ 4077.615329] [] ? process_one_work+0x142/0x3d0 [ 4077.622043] [] ? worker_thread+0x109/0x3b0 [ 4077.628459] [] ? manage_workers.isra.26+0x270/0x270 [ 4077.635759] [] ? kthread+0xaf/0xc0 [ 4077.641404] [] ? kthread_create_on_node+0x110/0x110 [ 4077.648696] [] ? ret_from_fork+0x58/0x90 [ 4077.654926] [] ? kthread_create_on_node+0x110/0x110 [ 4078.358087] kworker/u24:15 D ffff88107fcd0640 0 14436 2 0x00000000 [ 4078.365981] Workqueue: btrfs-endio-write btrfs_endio_write_helper [btrfs] [ 4078.373574] ffff880ffa57fad0 0000000000000046 0000000000009000 ffff880ffa57ffd8 [ 4078.381864] ffff880ffa57ffd8 ffff88103004d0a0 ffffffffa06ecb26 ffff88101a5d6138 [ 4078.390163] ffff880fbeffc298 ffff880ffa57faf8 ffff880fbeffc2f8 ffff88103004d0a0 [ 4078.398466] Call Trace: [ 4078.408019] [] ? btrfs_tree_lock+0xdd/0x2f0 [btrfs] [ 4078.415322] [] ? wake_up_atomic_t+0x30/0x30 [ 4078.421844] [] ? btrfs_search_slot+0x79f/0xb10 [btrfs] [ 4078.429438] [] ? btrfs_lookup_file_extent+0x33/0x40 [btrfs] [ 4078.437518] [] ? __btrfs_drop_extents+0x13b/0xdf0 [btrfs] [ 4078.445404] [] ? add_delayed_data_ref+0xe2/0x150 [btrfs] [ 4078.453194] [] ? btrfs_add_delayed_data_ref+0x149/0x1d0 [btrfs] [ 4078.461663] [] ? __set_extent_bit+0x4c0/0x5c0 [btrfs] [ 4078.469161] [] ? insert_reserved_file_extent.constprop.75+0xa4/0x320 [btrfs] [ 4078.478893] [] ? start_transaction+0x8d/0x470 [btrfs] [ 4078.486388] [] ? btrfs_finish_ordered_io+0x2e7/0x600 [btrfs] [ 4078.494561] [] ? process_one_work+0x142/0x3d0 [ 4078.501278] [] ? pwq_activate_delayed_work+0x27/0x40 [ 4078.508673] [] ? worker_thread+0x109/0x3b0 [ 4078.515098] [] ? manage_workers.isra.26+0x270/0x270 [ 4078.522396] [] ? kthread+0xaf/0xc0 [ 4078.528032] [] ? kthread_create_on_node+0x110/0x110 [ 4078.535325] [] ? ret_from_fork+0x58/0x90 [ 4078.541552] [] ? kthread_create_on_node+0x110/0x110 [ 4079.355824] user-space-program D ffff88107fd30640 0 32020 1 0x00000000 [ 4079.363716] ffff880eae8eba10 0000000000000086 0000000000009000 ffff880eae8ebfd8 [ 4079.372003] ffff880eae8ebfd8 ffff881016c162c0 ffffffffa06ecb26 ffff88101a5d6138 [ 4079.380294] ffff880fbed4b4c8 ffff880eae8eba38 ffff880fbed4b528 ffff881016c162c0 [ 4079.388586] Call Trace: [ 4079.398134] [] ? btrfs_tree_lock+0x85/0x2f0 [btrfs] [ 4079.405431] [] ? wake_up_atomic_t+0x30/0x30 [ 4079.411955] [] ? btrfs_lock_root_node+0x2b/0x40 [btrfs] [ 4079.419644] [] ? btrfs_search_slot+0xa03/0xb10 [btrfs] [ 4079.427237] [] ? btrfs_buffer_uptodate+0x52/0x70 [btrfs] [ 4079.435041] [] ? generic_bin_search.constprop.38+0x80/0x190 [btrfs] [ 4079.443897] [] ? btrfs_insert_empty_items+0x74/0xd0 [btrfs] [ 4079.451975] [] ? copy_items+0x128/0x850 [btrfs] [ 4079.458890] [] ? btrfs_log_inode+0x629/0xbf3 [btrfs] [ 4079.466292] [] ? btrfs_log_inode_parent+0xc61/0xf30 [btrfs] [ 4079.474373] [] ? btrfs_log_dentry_safe+0x59/0x80 [btrfs] [ 4079.482161] [] ? btrfs_sync_file+0x20d/0x330 [btrfs] [ 4079.489558] [] ? do_fsync+0x4c/0x80 [ 4079.495300] [] ? SyS_fdatasync+0xa/0x10 [ 4079.501422] [] ? system_call_fastpath+0x16/0x1b [ 4079.508334] user-space-program D ffff88107fc30640 0 32021 1 0x00000004 [ 4079.516226] ffff880eae8efbf8 0000000000000086 0000000000009000 ffff880eae8effd8 [ 4079.524513] ffff880eae8effd8 ffff881030279610 ffffffffa06ecb26 ffff88101a5d6138 [ 4079.532802] ffff880ebb671d88 ffff880eae8efc20 ffff880ebb671de8 ffff881030279610 [ 4079.541092] Call Trace: [ 4079.550642] [] ? btrfs_tree_lock+0x85/0x2f0 [btrfs] [ 4079.557941] [] ? wake_up_atomic_t+0x30/0x30 [ 4079.564463] [] ? btrfs_search_slot+0x79f/0xb10 [btrfs] [ 4079.572058] [] ? btrfs_truncate_inode_items+0x168/0xb90 [btrfs] [ 4079.580526] [] ? join_transaction.isra.15+0x1e/0x3a0 [btrfs] [ 4079.588701] [] ? start_transaction+0x8d/0x470 [btrfs] [ 4079.596196] [] ? block_rsv_add_bytes+0x16/0x50 [btrfs] [ 4079.603789] [] ? btrfs_truncate+0xe9/0x2e0 [btrfs] [ 4079.610994] [] ? btrfs_setattr+0x30b/0x410 [btrfs] [ 4079.618197] [] ? notify_change+0x1dc/0x680 [ 4079.624625] [] ? aa_path_perm+0xd4/0x160 [ 4079.630854] [] ? do_truncate+0x5b/0x90 [ 4079.636889] [] ? do_sys_ftruncate.constprop.15+0x10a/0x160 [ 4079.644869] [] ? SyS_fcntl+0x5b/0x570 [ 4079.650805] [] ? system_call_fastpath+0x16/0x1b [ 4080.410607] user-space-program D ffff88107fc70640 0 32028 12639 0x00000004 [ 4080.418489] ffff880eaeccbbe0 0000000000000086 0000000000009000 ffff880eaeccbfd8 [ 4080.426778] ffff880eaeccbfd8 ffff880f317ef1e0 ffffffffa06ecb26 ffff88101a5d6138 [ 4080.435067] ffff880ef7e93928 ffff880f317ef1e0 ffff880eaeccbc08 ffff880f317ef1e0 [ 4080.443353] Call Trace: [ 4080.452920] [] ? btrfs_tree_read_lock+0xdd/0x190 [btrfs] [ 4080.460703] [] ? wake_up_atomic_t+0x30/0x30 [ 4080.467225] [] ? btrfs_read_lock_root_node+0x2b/0x40 [btrfs] [ 4080.475400] [] ? btrfs_search_slot+0x801/0xb10 [btrfs] [ 4080.482994] [] ? btrfs_clean_one_deleted_snapshot+0xe0/0xe0 [btrfs] [ 4080.491857] [] ? btrfs_lookup_inode+0x26/0x90 [btrfs] [ 4080.499353] [] ? kmem_cache_alloc+0xaf/0xc0 [ 4080.505879] [] ? btrfs_iget+0xd5/0x5d0 [btrfs] [ 4080.512696] [] ? btrfs_get_token_64+0x104/0x120 [btrfs] [ 4080.520387] [] ? btrfs_log_inode_parent+0xbdf/0xf30 [btrfs] [ 4080.528469] [] ? btrfs_log_dentry_safe+0x59/0x80 [btrfs] [ 4080.536258] [] ? btrfs_sync_file+0x20d/0x330 [btrfs] [ 4080.543657] [] ? do_fsync+0x4c/0x80 [ 4080.549399] [] ? SyS_fdatasync+0xa/0x10 [ 4080.555534] [] ? system_call_fastpath+0x16/0x1b Signed-off-by: Robbie Ko Reviewed-by: Filipe Manana Fixes: 2f2ff0ee5e43 (Btrfs: fix metadata inconsistencies after directory fsync) Cc: stable@vger.kernel.org # 4.1+ Signed-off-by: Filipe Manana [Modified changelog for clarity and correctness] Signed-off-by: Sasha Levin commit 32a27da220fb38ea8227d958b8092b834006c945 Author: Geoff Levand Date: Tue Nov 29 10:47:32 2016 -0800 powerpc/ps3: Fix system hang with GCC 5 builds [ Upstream commit 6dff5b67054e17c91bd630bcdda17cfca5aa4215 ] GCC 5 generates different code for this bootwrapper null check that causes the PS3 to hang very early in its bootup. This check is of limited value, so just get rid of it. Cc: stable@vger.kernel.org Signed-off-by: Geoff Levand Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin commit 07340eaf074342522108475ce0b4d535f52b911b Author: Johan Hovold Date: Tue Nov 29 16:55:01 2016 +0100 USB: serial: kl5kusb105: fix open error path [ Upstream commit 6774d5f53271d5f60464f824748995b71da401ab ] Kill urbs and disable read before returning from open on failure to retrieve the line state. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Sasha Levin commit b4fa7414cb796668b06e23275d2c1775ae9814c8 Author: Krzysztof Kozlowski Date: Tue Nov 22 19:22:44 2016 +0200 thermal: hwmon: Properly report critical temperature in sysfs [ Upstream commit f37fabb8643eaf8e3b613333a72f683770c85eca ] In the critical sysfs entry the thermal hwmon was returning wrong temperature to the user-space. It was reporting the temperature of the first trip point instead of the temperature of critical trip point. For example: /sys/class/hwmon/hwmon0/temp1_crit:50000 /sys/class/thermal/thermal_zone0/trip_point_0_temp:50000 /sys/class/thermal/thermal_zone0/trip_point_0_type:active /sys/class/thermal/thermal_zone0/trip_point_3_temp:120000 /sys/class/thermal/thermal_zone0/trip_point_3_type:critical Since commit e68b16abd91d ("thermal: add hwmon sysfs I/F") the driver have been registering a sysfs entry if get_crit_temp() callback was provided. However when accessed, it was calling get_trip_temp() instead of the get_crit_temp(). Fixes: e68b16abd91d ("thermal: add hwmon sysfs I/F") Cc: Signed-off-by: Krzysztof Kozlowski Signed-off-by: Zhang Rui Signed-off-by: Sasha Levin commit 3225aec938da2b7135168906057015eb27b4918e Author: Konstantin Khlebnikov Date: Sun Nov 27 19:32:32 2016 +0300 md/raid5: limit request size according to implementation limits [ Upstream commit e8d7c33232e5fdfa761c3416539bc5b4acd12db5 ] Current implementation employ 16bit counter of active stripes in lower bits of bio->bi_phys_segments. If request is big enough to overflow this counter bio will be completed and freed too early. Fortunately this not happens in default configuration because several other limits prevent that: stripe_cache_size * nr_disks effectively limits count of active stripes. And small max_sectors_kb at lower disks prevent that during normal read/write operations. Overflow easily happens in discard if it's enabled by module parameter "devices_handle_discard_safely" and stripe_cache_size is set big enough. This patch limits requests size with 256Mb - 8Kb to prevent overflows. Signed-off-by: Konstantin Khlebnikov Cc: Shaohua Li Cc: Neil Brown Cc: stable@vger.kernel.org Signed-off-by: Shaohua Li Signed-off-by: Sasha Levin commit 93da0de16c94b19ae71e2ff6701a626ea9d44325 Author: Yves-Alexis Perez Date: Fri Nov 11 11:28:40 2016 -0800 firmware: fix usermode helper fallback loading [ Upstream commit 2e700f8d85975f516ccaad821278c1fe66b2cc98 ] When you use the firmware usermode helper fallback with a timeout value set to a value greater than INT_MAX (2147483647) a cast overflow issue causes the timeout value to go negative and breaks all usermode helper loading. This regression was introduced through commit 68ff2a00dbf5 ("firmware_loader: handle timeout via wait_for_completion_interruptible_timeout()") on kernel v4.0. The firmware_class drivers relies on the firmware usermode helper fallback as a mechanism to look for firmware if the direct filesystem search failed only if: a) You've enabled CONFIG_FW_LOADER_USER_HELPER_FALLBACK (not many distros): Then all of these callers will rely on the fallback mechanism in case the firmware is not found through an initial direct filesystem lookup: o request_firmware() o request_firmware_into_buf() o request_firmware_nowait() b) If you've only enabled CONFIG_FW_LOADER_USER_HELPER (most distros): Then only callers using request_firmware_nowait() with the second argument set to false, this explicitly is requesting the UMH firmware fallback to be relied on in case the first filesystem lookup fails. Using Coccinelle SmPL grammar we have identified only two drivers explicitly requesting the UMH firmware fallback mechanism: - drivers/firmware/dell_rbu.c - drivers/leds/leds-lp55xx-common.c Since most distributions only enable CONFIG_FW_LOADER_USER_HELPER the biggest impact of this regression are users of the dell_rbu and leds-lp55xx-common device driver which required the UMH to find their respective needed firmwares. The default timeout for the UMH is set to 60 seconds always, as of commit 68ff2a00dbf5 ("firmware_loader: handle timeout via wait_for_completion_interruptible_timeout()") the timeout was bumped to MAX_JIFFY_OFFSET ((LONG_MAX >> 1)-1). Additionally the MAX_JIFFY_OFFSET value was also used if the timeout was configured by a user to 0. The following works: echo 2147483647 > /sys/class/firmware/timeout But both of the following set the timeout to MAX_JIFFY_OFFSET even if we display 0 back to userspace: echo 2147483648 > /sys/class/firmware/timeout cat /sys/class/firmware/timeout 0 echo 0> /sys/class/firmware/timeout cat /sys/class/firmware/timeout 0 A max value of INT_MAX (2147483647) seconds is therefore implicit due to the another cast with simple_strtol(). This fixes the secondary cast (the first one is simple_strtol() but its an issue only by forcing an implicit limit) by re-using the timeout variable and only setting retval in appropriate cases. Lastly worth noting systemd had ripped out the UMH firmware fallback mechanism from udev since udev 2014 via commit be2ea723b1d023b3d ("udev: remove userspace firmware loading support"), so as of systemd v217. Signed-off-by: Yves-Alexis Perez Fixes: 68ff2a00dbf5 "firmware_loader: handle timeout via wait_for_completion_interruptible_timeout()" Cc: Luis R. Rodriguez Cc: Ming Lei Cc: Bjorn Andersson Cc: Greg Kroah-Hartman Cc: stable@vger.kernel.org Acked-by: Luis R. Rodriguez Reviewed-by: Bjorn Andersson [mcgrof@kernel.org: gave commit log a whole lot of love] Signed-off-by: Luis R. Rodriguez Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d7a1bfa59593a0323e1a0526f82c0231938c7d6b Author: Boris Ostrovsky Date: Mon Nov 21 09:56:06 2016 -0500 xen/gntdev: Use VM_MIXEDMAP instead of VM_IO to avoid NUMA balancing [ Upstream commit 30faaafdfa0c754c91bac60f216c9f34a2bfdf7e ] Commit 9c17d96500f7 ("xen/gntdev: Grant maps should not be subject to NUMA balancing") set VM_IO flag to prevent grant maps from being subjected to NUMA balancing. It was discovered recently that this flag causes get_user_pages() to always fail with -EFAULT. check_vma_flags __get_user_pages __get_user_pages_locked __get_user_pages_unlocked get_user_pages_fast iov_iter_get_pages dio_refill_pages do_direct_IO do_blockdev_direct_IO do_blockdev_direct_IO ext4_direct_IO_read generic_file_read_iter aio_run_iocb (which can happen if guest's vdisk has direct-io-safe option). To avoid this let's use VM_MIXEDMAP flag instead --- it prevents NUMA balancing just as VM_IO does and has no effect on check_vma_flags(). Cc: stable@vger.kernel.org Reported-by: Olaf Hering Suggested-by: Hugh Dickins Signed-off-by: Boris Ostrovsky Acked-by: Hugh Dickins Tested-by: Olaf Hering Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin commit 315419538d84b1f28f0805cd278a1ae748f7a5b2 Author: Jason Gunthorpe Date: Wed Oct 26 16:28:45 2016 -0600 tpm xen: Remove bogus tpm_chip_unregister [ Upstream commit 1f0f30e404b3d8f4597a2d9b77fba55452f8fd0e ] tpm_chip_unregister can only be called after tpm_chip_register. devm manages the allocation so no unwind is needed here. Cc: stable@vger.kernel.org Fixes: afb5abc262e96 ("tpm: two-phase chip management functions") Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit fee2ddaee7757fd8c62bbf82ce0f66df71a6d4a6 Author: Nicolai Stange Date: Sun Nov 20 19:57:23 2016 +0100 f2fs: set ->owner for debugfs status file's file_operations [ Upstream commit 05e6ea2685c964db1e675a24a4f4e2adc22d2388 ] The struct file_operations instance serving the f2fs/status debugfs file lacks an initialization of its ->owner. This means that although that file might have been opened, the f2fs module can still get removed. Any further operation on that opened file, releasing included, will cause accesses to unmapped memory. Indeed, Mike Marshall reported the following: BUG: unable to handle kernel paging request at ffffffffa0307430 IP: [] full_proxy_release+0x24/0x90 <...> Call Trace: [] __fput+0xdf/0x1d0 [] ____fput+0xe/0x10 [] task_work_run+0x8e/0xc0 [] do_exit+0x2ae/0xae0 [] ? __audit_syscall_entry+0xae/0x100 [] ? syscall_trace_enter+0x1ca/0x310 [] do_group_exit+0x44/0xc0 [] SyS_exit_group+0x14/0x20 [] do_syscall_64+0x61/0x150 [] entry_SYSCALL64_slow_path+0x25/0x25 <...> ---[ end trace f22ae883fa3ea6b8 ]--- Fixing recursive fault but reboot is needed! Fix this by initializing the f2fs/status file_operations' ->owner with THIS_MODULE. This will allow debugfs to grab a reference to the f2fs module upon any open on that file, thus preventing it from getting removed. Fixes: 902829aa0b72 ("f2fs: move proc files to debugfs") Reported-by: Mike Marshall Reported-by: Martin Brandenburg Cc: stable@vger.kernel.org Signed-off-by: Nicolai Stange Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit f52d439916f0de9731b67f2a0e9de8be6d1a5785 Author: Hui Wang Date: Wed Nov 23 16:05:38 2016 +0800 ALSA: hda - fix headset-mic problem on a Dell laptop [ Upstream commit 989dbe4a30728c047316ab87e5fa8b609951ce7c ] This group of new pins is not in the pin quirk table yet, adding them to the pin quirk table to fix the headset-mic problem. Cc: Signed-off-by: Hui Wang Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 506d7d5211741a6bdd5424d4145919acbd3923af Author: Ondrej Kozina Date: Wed Nov 2 15:02:08 2016 +0100 dm crypt: mark key as invalid until properly loaded [ Upstream commit 265e9098bac02bc5e36cda21fdbad34cb5b2f48d ] In crypt_set_key(), if a failure occurs while replacing the old key (e.g. tfm->setkey() fails) the key must not have DM_CRYPT_KEY_VALID flag set. Otherwise, the crypto layer would have an invalid key that still has DM_CRYPT_KEY_VALID flag set. Cc: stable@vger.kernel.org Signed-off-by: Ondrej Kozina Reviewed-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit 4a7036809383fc30a715d6ed04aa8b5a2e03a137 Author: Paul Mackerras Date: Wed Nov 16 16:43:28 2016 +1100 KVM: PPC: Book3S HV: Don't lose hardware R/C bit updates in H_PROTECT [ Upstream commit f064a0de1579fabded8990bed93971e30deb9ecb ] The hashed page table MMU in POWER processors can update the R (reference) and C (change) bits in a HPTE at any time until the HPTE has been invalidated and the TLB invalidation sequence has completed. In kvmppc_h_protect, which implements the H_PROTECT hypercall, we read the HPTE, modify the second doubleword, invalidate the HPTE in memory, do the TLB invalidation sequence, and then write the modified value of the second doubleword back to memory. In doing so we could overwrite an R/C bit update done by hardware between when we read the HPTE and when the TLB invalidation completed. To fix this we re-read the second doubleword after the TLB invalidation and OR in the (possibly) new values of R and C. We can use an OR since hardware only ever sets R and C, never clears them. This race was found by code inspection. In principle this bug could cause occasional guest memory corruption under host memory pressure. Fixes: a8606e20e41a ("KVM: PPC: Handle some PAPR hcalls in the kernel", 2011-06-29) Cc: stable@vger.kernel.org # v3.19+ Signed-off-by: Paul Mackerras Signed-off-by: Sasha Levin commit ec05ce11c1e99a4c34f0c9937dc6abe00c7a43de Author: Paul Mackerras Date: Mon Nov 7 15:09:58 2016 +1100 KVM: PPC: Book3S HV: Save/restore XER in checkpointed register state [ Upstream commit 0d808df06a44200f52262b6eb72bcb6042f5a7c5 ] When switching from/to a guest that has a transaction in progress, we need to save/restore the checkpointed register state. Although XER is part of the CPU state that gets checkpointed, the code that does this saving and restoring doesn't save/restore XER. This fixes it by saving and restoring the XER. To allow userspace to read/write the checkpointed XER value, we also add a new ONE_REG specifier. The visible effect of this bug is that the guest may see its XER value being corrupted when it uses transactions. Fixes: e4e38121507a ("KVM: PPC: Book3S HV: Add transactional memory support") Fixes: 0a8eccefcb34 ("KVM: PPC: Book3S HV: Add missing code for transaction reclaim on guest exit") Cc: stable@vger.kernel.org # v3.15+ Signed-off-by: Paul Mackerras Reviewed-by: Thomas Huth Signed-off-by: Paul Mackerras Signed-off-by: Sasha Levin commit b1a75800973969f7bdbfd53f6cbfdad5fdd76fb3 Author: Theodore Ts'o Date: Fri Nov 18 13:37:47 2016 -0500 ext4: add sanity checking to count_overhead() [ Upstream commit c48ae41bafe31e9a66d8be2ced4e42a6b57fa814 ] The commit "ext4: sanity check the block and cluster size at mount time" should prevent any problems, but in case the superblock is modified while the file system is mounted, add an extra safety check to make sure we won't overrun the allocated buffer. Signed-off-by: Theodore Ts'o Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 31eb998aa42dd8fa96bea51320f21eb005ad752d Author: Theodore Ts'o Date: Fri Nov 18 13:28:30 2016 -0500 ext4: use more strict checks for inodes_per_block on mount [ Upstream commit cd6bb35bf7f6d7d922509bf50265383a0ceabe96 ] Centralize the checks for inodes_per_block and be more strict to make sure the inodes_per_block_group can't end up being zero. Signed-off-by: Theodore Ts'o Reviewed-by: Andreas Dilger Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 526cfedac0b3e2a4fd19bd43f34be2a52e002234 Author: Theodore Ts'o Date: Fri Nov 18 13:00:24 2016 -0500 ext4: sanity check the block and cluster size at mount time [ Upstream commit 9e47a4c9fc58032ee135bf76516809c7624b1551 ] If the block size or cluster size is insane, reject the mount. This is important for security reasons (although we shouldn't be just depending on this check). Ref: http://www.securityfocus.com/archive/1/539661 Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1332506 Reported-by: Borislav Petkov Reported-by: Nikolay Borisov Signed-off-by: Theodore Ts'o Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit c2404d06b82e0ca6a9b457d3901b5aa5624a85d7 Author: Mathias Nyman Date: Thu Nov 17 11:14:14 2016 +0200 usb: hub: Fix auto-remount of safely removed or ejected USB-3 devices [ Upstream commit 37be66767e3cae4fd16e064d8bb7f9f72bf5c045 ] USB-3 does not have any link state that will avoid negotiating a connection with a plugged-in cable but will signal the host when the cable is unplugged. For USB-3 we used to first set the link to Disabled, then to RxDdetect to be able to detect cable connects or disconnects. But in RxDetect the connected device is detected again and eventually enabled. Instead set the link into U3 and disable remote wakeups for the device. This is what Windows does, and what Alan Stern suggested. Cc: stable@vger.kernel.org Cc: Alan Stern Acked-by: Alan Stern Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2861b336b5943f83af9ccf2f636235340ecc5cd7 Author: Larry Finger Date: Sat Nov 5 14:08:57 2016 -0500 ssb: Fix error routine when fallback SPROM fails [ Upstream commit 8052d7245b6089992343c80b38b14dbbd8354651 ] When there is a CRC error in the SPROM read from the device, the code attempts to handle a fallback SPROM. When this also fails, the driver returns zero rather than an error code. Signed-off-by: Larry Finger Cc: Stable Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 44ef406441e2406434bbf04932b6bd2ba1c916f8 Author: Vittorio Gambaletta (VittGam) Date: Wed Nov 9 03:40:56 2016 +0200 ath9k: Really fix LED polarity for some Mini PCI AR9220 MB92 cards. [ Upstream commit 79e57dd113d307a6c74773b8aaecf5442068988a ] The active_high LED of my Wistron DNMA-92 is still being recognized as active_low on 4.7.6 mainline. When I was preparing my former commit 0f9edcdd88a9 ("ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards.") to fix that I must have somehow messed up with testing, because I tested the final version of that patch before sending it, and it was apparently working; but now it is not working on 4.7.6 mainline. I initially added the PCI_DEVICE_SUB section for 0x0029/0x2096 above the PCI_VDEVICE section for 0x0029; but then I moved the former below the latter after seeing how 0x002A sections were sorted in the file. This turned out to be wrong: if a generic PCI_VDEVICE entry (that has both subvendor and subdevice IDs set to PCI_ANY_ID) is put before a more specific one (PCI_DEVICE_SUB), then the generic PCI_VDEVICE entry will match first and will be used. With this patch, 0x0029/0x2096 has finally got active_high LED on 4.7.6. While I'm at it, let's fix 0x002A too by also moving its generic definition below its specific ones. Fixes: 0f9edcdd88a9 ("ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards.") Cc: #4.7+ Signed-off-by: Vittorio Gambaletta [kvalo@qca.qualcomm.com: improve the commit log based on email discussions] Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit be733405b0574e8dc8d95cd8ef49142ee5945a3b Author: Ian Abbott Date: Mon Nov 14 20:16:21 2016 +0000 staging: comedi: ni_mio_common: fix M Series ni_ai_insn_read() data mask [ Upstream commit 655c4d442d1213b617926cc6d54e2a9a793fb46b ] For NI M Series cards, the Comedi `insn_read` handler for the AI subdevice is broken due to ANDing the value read from the AI FIFO data register with an incorrect mask. The incorrect mask clears all but the most significant bit of the sample data. It should preserve all the sample data bits. Correct it. Fixes: 817144ae7fda ("staging: comedi: ni_mio_common: remove unnecessary use of 'board->adbits'") Signed-off-by: Ian Abbott Cc: Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9d45d2e798000a0c622e96fc486e0ab8fb1f933d Author: Chandan Rajendra Date: Mon Nov 14 21:26:26 2016 -0500 ext4: fix stack memory corruption with 64k block size [ Upstream commit 30a9d7afe70ed6bd9191d3000e2ef1a34fb58493 ] The number of 'counters' elements needed in 'struct sg' is super_block->s_blocksize_bits + 2. Presently we have 16 'counters' elements in the array. This is insufficient for block sizes >= 32k. In such cases the memcpy operation performed in ext4_mb_seq_groups_show() would cause stack memory corruption. Fixes: c9de560ded61f Signed-off-by: Chandan Rajendra Signed-off-by: Theodore Ts'o Reviewed-by: Jan Kara Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit d6ddc9cf431b6887cf57984a152dd537d54aa35b Author: Chandan Rajendra Date: Mon Nov 14 21:04:37 2016 -0500 ext4: fix mballoc breakage with 64k block size [ Upstream commit 69e43e8cc971a79dd1ee5d4343d8e63f82725123 ] 'border' variable is set to a value of 2 times the block size of the underlying filesystem. With 64k block size, the resulting value won't fit into a 16-bit variable. Hence this commit changes the data type of 'border' to 'unsigned int'. Fixes: c9de560ded61f Signed-off-by: Chandan Rajendra Signed-off-by: Theodore Ts'o Reviewed-by: Andreas Dilger Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit b3409ef1849bbcce0c0bf4d4fd87cbf6cc15fe74 Author: Omar Sandoval Date: Mon Nov 14 14:56:17 2016 -0800 loop: return proper error from loop_queue_rq() [ Upstream commit b4a567e8114327518c09f5632339a5954ab975a3 ] ->queue_rq() should return one of the BLK_MQ_RQ_QUEUE_* constants, not an errno. f4aa4c7bbac6 ("block: loop: convert to per-device workqueue") Signed-off-by: Omar Sandoval Cc: stable@vger.kernel.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 9e19c28455b3c1451081bb673ea168fb1a1a8b93 Author: Alex Porosanu Date: Wed Nov 9 10:46:11 2016 +0200 crypto: caam - fix AEAD givenc descriptors [ Upstream commit d128af17876d79b87edf048303f98b35f6a53dbc ] The AEAD givenc descriptor relies on moving the IV through the output FIFO and then back to the CTX2 for authentication. The SEQ FIFO STORE could be scheduled before the data can be read from OFIFO, especially since the SEQ FIFO LOAD needs to wait for the SEQ FIFO LOAD SKIP to finish first. The SKIP takes more time when the input is SG than when it's a contiguous buffer. If the SEQ FIFO LOAD is not scheduled before the STORE, the DECO will hang waiting for data to be available in the OFIFO so it can be transferred to C2. In order to overcome this, first force transfer of IV to C2 by starting the "cryptlen" transfer first and then starting to store data from OFIFO to the output buffer. Fixes: 1acebad3d8db8 ("crypto: caam - faster aead implementation") Cc: # 3.2+ Signed-off-by: Alex Porosanu Signed-off-by: Horia Geantă Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 332086b806acb16cf085f909e53ca0ec3687258b Author: Linus Walleij Date: Sat Nov 12 15:22:38 2016 +0100 regulator: stw481x-vmmc: fix ages old enable error [ Upstream commit 295070e9aa015abb9b92cccfbb1e43954e938133 ] The regulator has never been properly enabled, it has been dormant all the time. It's strange that MMC was working at all, but it likely worked by the signals going through the levelshifter and reaching the card anyways. Fixes: 3615a34ea1a6 ("regulator: add STw481x VMMC driver") Signed-off-by: Linus Walleij Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 9e4033f56d3d9c7b7c11d5d02d48faaa0dc24f0e Author: Alan Stern Date: Fri Oct 21 16:49:07 2016 -0400 USB: UHCI: report non-PME wakeup signalling for Intel hardware [ Upstream commit ccdb6be9ec6580ef69f68949ebe26e0fb58a6fb0 ] The UHCI controllers in Intel chipsets rely on a platform-specific non-PME mechanism for wakeup signalling. They can generate wakeup signals even though they don't support PME. We need to let the USB core know this so that it will enable runtime suspend for UHCI controllers. Signed-off-by: Alan Stern Signed-off-by: Bjorn Helgaas Acked-by: Greg Kroah-Hartman CC: stable@vger.kernel.org Signed-off-by: Sasha Levin commit 257cb82ee6d7a530c121b6dbb3cd20c93eff3d5d Author: Alan Stern Date: Fri Oct 21 16:45:38 2016 -0400 PCI: Check for PME in targeted sleep state [ Upstream commit 6496ebd7edf446fccf8266a1a70ffcb64252593e ] One some systems, the firmware does not allow certain PCI devices to be put in deep D-states. This can cause problems for wakeup signalling, if the device does not support PME# in the deepest allowed suspend state. For example, Pierre reports that on his system, ACPI does not permit his xHCI host controller to go into D3 during runtime suspend -- but D3 is the only state in which the controller can generate PME# signals. As a result, the controller goes into runtime suspend but never wakes up, so it doesn't work properly. USB devices plugged into the controller are never detected. If the device relies on PME# for wakeup signals but is not capable of generating PME# in the target state, the PCI core should accurately report that it cannot do wakeup from runtime suspend. This patch modifies the pci_dev_run_wake() routine to add this check. Reported-by: Pierre de Villemereuil Tested-by: Pierre de Villemereuil Signed-off-by: Alan Stern Signed-off-by: Bjorn Helgaas Acked-by: Rafael J. Wysocki CC: stable@vger.kernel.org CC: Lukas Wunner Signed-off-by: Sasha Levin commit 78ef3e710efde520451452abd4b85062847aa191 Author: Kashyap Desai Date: Fri Oct 21 06:33:29 2016 -0700 scsi: megaraid_sas: For SRIOV enabled firmware, ensure VF driver waits for 30secs before reset [ Upstream commit 18e1c7f68a5814442abad849abe6eacbf02ffd7c ] For SRIOV enabled firmware, if there is a OCR(online controller reset) possibility driver set the convert flag to 1, which is not happening if there are outstanding commands even after 180 seconds. As driver does not set convert flag to 1 and still making the OCR to run, VF(Virtual function) driver is directly writing on to the register instead of waiting for 30 seconds. Setting convert flag to 1 will cause VF driver will wait for 30 secs before going for reset. CC: stable@vger.kernel.org Signed-off-by: Kiran Kumar Kasturi Signed-off-by: Sumit Saxena Reviewed-by: Hannes Reinecke Reviewed-by: Tomas Henzl Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 28a8e88f1d2f80ad0dd48e1b3ffc14b8450ba197 Author: Patrik Jakobsson Date: Tue Nov 1 15:43:15 2016 +0100 drm/gma500: Add compat ioctl [ Upstream commit 0a97c81a9717431e6c57ea845b59c3c345edce67 ] Hook up drm_compat_ioctl to support 32-bit userspace on 64-bit kernels. It turns out that N2600 and N2800 comes with 64-bit enabled. We previously assumed there where no such systems out there. Cc: stable@vger.kernel.org Signed-off-by: Patrik Jakobsson Signed-off-by: Sean Paul Link: http://patchwork.freedesktop.org/patch/msgid/20161101144315.2955-1-patrik.r.jakobsson@gmail.com Signed-off-by: Sasha Levin commit 6ec54b062038fb74619e79e4013c0be1f9e50154 Author: Felipe Balbi Date: Wed Sep 28 10:38:11 2016 +0300 usb: gadget: composite: correctly initialize ep->maxpacket [ Upstream commit e8f29bb719b47a234f33b0af62974d7a9521a52c ] usb_endpoint_maxp() returns wMaxPacketSize in its raw form. Without taking into consideration that it also contains other bits reserved for isochronous endpoints. This patch fixes one occasion where this is a problem by making sure that we initialize ep->maxpacket only with lower 10 bits of the value returned by usb_endpoint_maxp(). Note that seperate patches will be necessary to audit all call sites of usb_endpoint_maxp() and make sure that usb_endpoint_maxp() only returns lower 10 bits of wMaxPacketSize. Cc: Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 33166482bf4913abe977a92e54cb94764eeffc4b Author: Chris Wilson Date: Mon Oct 3 13:45:15 2016 +0100 drm/i915: Unalias obj->phys_handle and obj->userptr [ Upstream commit 5f12b80a0b42da253691ca03828033014bb786eb ] We use obj->phys_handle to choose the pread/pwrite path, but as obj->phys_handle is a union with obj->userptr, we then mistakenly use the phys_handle path for userptr objects within pread/pwrite. Testcase: igt/gem_userptr_blits/forbidden-operations Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97519 Signed-off-by: Chris Wilson Cc: stable@vger.kernel.org Reviewed-by: Joonas Lahtinen Link: http://patchwork.freedesktop.org/patch/msgid/20161003124516.12388-2-chris@chris-wilson.co.uk Signed-off-by: Sasha Levin commit d7633e23c7f67ce5032e7a3cb54c904095f07352 Author: Paulo Zanoni Date: Thu Sep 22 18:00:30 2016 -0300 drm/i915/gen9: fix the WaWmMemoryReadLatency implementation [ Upstream commit 0727e40a48a1d08cf54ce2c01e120864b92e59bf ] Bspec says: "The mailbox response data may not account for memory read latency. If the mailbox response data for level 0 is 0us, add 2 microseconds to the result for each valid level." This means we should only do the +2 in case wm[0] == 0, not always. So split the sanitizing implementation from the WA implementation and fix the WA implementation. v2: Add Fixes tag (Maarten). Fixes: 367294be7c25 ("drm/i915/gen9: Add 2us read latency to WM level") Cc: stable@vger.kernel.org Cc: Vandana Kannan Reviewed-by: Maarten Lankhorst Signed-off-by: Paulo Zanoni Link: http://patchwork.freedesktop.org/patch/msgid/1474578035-424-5-git-send-email-paulo.r.zanoni@intel.com Signed-off-by: Sasha Levin