commit c843445f19f4e6f05b32125d7556958f98033999 Author: Greg Kroah-Hartman Date: Fri Oct 28 03:53:25 2016 -0400 Linux 4.4.28 commit 1191dcfd650f8342c99f13898fa6e9c6ead01fb9 Author: Dinesh Israni Date: Mon Oct 10 20:22:03 2016 -0700 target: Don't override EXTENDED_COPY xcopy_pt_cmd SCSI status code commit 926317de33998c112c5510301868ea9aa34097e2 upstream. This patch addresses a bug where a local EXTENDED_COPY WRITE or READ backend I/O request would always return SAM_STAT_CHECK_CONDITION, even if underlying xcopy_pt_cmd->se_cmd generated a different SCSI status code. ESX host environments expect to hit SAM_STAT_RESERVATION_CONFLICT for certain scenarios, and SAM_STAT_CHECK_CONDITION results in non-retriable status for these cases. Tested on v4.1.y with ESX v5.5u2+ with local IBLOCK backend copy. Reported-by: Nixon Vincent Tested-by: Nixon Vincent Cc: Nixon Vincent Tested-by: Dinesh Israni Signed-off-by: Dinesh Israni Cc: Dinesh Israni Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit f4186e0b11819ae3ae689df68816b993ed89b985 Author: Nicholas Bellinger Date: Sat Oct 8 17:26:44 2016 -0700 target: Make EXTENDED_COPY 0xe4 failure return COPY TARGET DEVICE NOT REACHABLE commit 449a137846c84829a328757cd21fd9ca65c08519 upstream. This patch addresses a bug where EXTENDED_COPY across multiple LUNs results in a CHECK_CONDITION when the source + destination are not located on the same physical node. ESX Host environments expect sense COPY_ABORTED w/ COPY TARGET DEVICE NOT REACHABLE to be returned when this occurs, in order to signal fallback to local copy method. As described in section 6.3.3 of spc4r22: "If it is not possible to complete processing of a segment because the copy manager is unable to establish communications with a copy target device, because the copy target device does not respond to INQUIRY, or because the data returned in response to INQUIRY indicates an unsupported logical unit, then the EXTENDED COPY command shall be terminated with CHECK CONDITION status, with the sense key set to COPY ABORTED, and the additional sense code set to COPY TARGET DEVICE NOT REACHABLE." Tested on v4.1.y with ESX v5.5u2+ with BlockCopy across multiple nodes. Reported-by: Nixon Vincent Tested-by: Nixon Vincent Cc: Nixon Vincent Tested-by: Dinesh Israni Signed-off-by: Dinesh Israni Cc: Dinesh Israni Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 56661d2b89b2a549be04f37dcf824c39d7aca9c6 Author: Nicholas Bellinger Date: Tue Oct 4 16:37:05 2016 -0700 target: Re-add missing SCF_ACK_KREF assignment in v4.1.y commit 527268df31e57cf2b6d417198717c6d6afdb1e3e upstream. This patch fixes a regression in >= v4.1.y code where the original SCF_ACK_KREF assignment in target_get_sess_cmd() was dropped upstream in commit 054922bb, but the series for addressing TMR ABORT_TASK + LUN_RESET with fabric session reinstatement in commit febe562c20 still depends on this code in transport_cmd_finish_abort(). The regression manifests itself as a se_cmd->cmd_kref +1 leak, where ABORT_TASK + LUN_RESET can hang indefinately for a specific I_T session for drivers using SCF_ACK_KREF, resulting in hung kthreads. This patch has been verified with v4.1.y code. Reported-by: Vaibhav Tandon Tested-by: Vaibhav Tandon Cc: Vaibhav Tandon Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit d98a0641c0d267ec7b20381885e92d353e5bfc48 Author: Richard Weinberger Date: Tue Sep 20 10:08:30 2016 +0200 ubifs: Fix xattr_names length in exit paths commit 843741c5778398ea67055067f4cc65ae6c80ca0e upstream. When the operation fails we also have to undo the changes we made to ->xattr_names. Otherwise listxattr() will report wrong lengths. Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit 795422ec43a7888a997c39020a1874258cce79b9 Author: Taesoo Kim Date: Wed Oct 12 23:19:18 2016 -0400 jbd2: fix incorrect unlock on j_list_lock commit 559cce698eaf4ccecb2213b2519ea3a0413e5155 upstream. When 'jh->b_transaction == transaction' (asserted by below) J_ASSERT_JH(jh, (jh->b_transaction == transaction || ... 'journal->j_list_lock' will be incorrectly unlocked, since the the lock is aquired only at the end of if / else-if statements (missing the else case). Signed-off-by: Taesoo Kim Signed-off-by: Theodore Ts'o Reviewed-by: Andreas Dilger Fixes: 6e4862a5bb9d12be87e4ea5d9a60836ebed71d28 Signed-off-by: Greg Kroah-Hartman commit 80dbd616eccee0d52ac77d2a2fbd59145a32e2d7 Author: Eric Biggers Date: Wed Oct 12 23:24:51 2016 -0400 ext4: do not advertise encryption support when disabled commit c4704a4fbe834eee4109ca064131d440941f6235 upstream. The sysfs file /sys/fs/ext4/features/encryption was present on kernels compiled with CONFIG_EXT4_FS_ENCRYPTION=n. This was misleading because such kernels do not actually support ext4 encryption. Therefore, only provide this file on kernels compiled with CONFIG_EXT4_FS_ENCRYPTION=y. Note: since the ext4 feature files are all hardcoded to have a contents of "supported", it really is the presence or absence of the file that is significant, not the contents (and this change reflects that). Signed-off-by: Eric Biggers Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit aef07c9db2fb6d4a7d9e0e5ee587c04c411c6369 Author: Ulf Hansson Date: Thu Sep 15 14:46:21 2016 +0200 mmc: rtsx_usb_sdmmc: Handle runtime PM while changing the led commit 4f48aa7a11bfed9502a7c85a5b68cd40ea827f73 upstream. Accesses of the rtsx sdmmc's parent device, which is the rtsx usb device, must be done when it's runtime resumed. Currently this isn't case when changing the led, so let's fix this by adding a pm_runtime_get_sync() and a pm_runtime_put() around those operations. Reported-by: Ritesh Raj Sarraf Tested-by: Ritesh Raj Sarraf Cc: Alan Stern Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 55110f2f7e1b4c5607cee12cd52deb1ec5f1cbca Author: Ulf Hansson Date: Tue Sep 27 08:44:33 2016 -0700 mmc: rtsx_usb_sdmmc: Avoid keeping the device runtime resumed when unused commit 31cf742f515c275d22843c4c756e048d2b6d716c upstream. The rtsx_usb_sdmmc driver may bail out in its ->set_ios() callback when no SD card is inserted. This is wrong, as it could cause the device to remain runtime resumed when it's unused. Fix this behaviour. Tested-by: Ritesh Raj Sarraf Cc: Alan Stern Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 2983d3fa16a3dfbc889a1f56de6be34f9ef4d3d2 Author: Jiri Slaby Date: Mon Oct 3 10:58:28 2016 +0200 mmc: core: Annotate cmd_hdr as __le32 commit 3f2d26643595973e835e8356ea90c7c15cb1b0f1 upstream. Commit f68381a70bb2 (mmc: block: fix packed command header endianness) correctly fixed endianness handling of packed_cmd_hdr in mmc_blk_packed_hdr_wrq_prep. But now, sparse complains about incorrect types: drivers/mmc/card/block.c:1613:27: sparse: incorrect type in assignment (different base types) drivers/mmc/card/block.c:1613:27: expected unsigned int [unsigned] [usertype] drivers/mmc/card/block.c:1613:27: got restricted __le32 [usertype] ... So annotate cmd_hdr properly using __le32 to make everyone happy. Signed-off-by: Jiri Slaby Fixes: f68381a70bb2 (mmc: block: fix packed command header endianness) Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit c346241e752ab9131689bce55d250ab2493ef952 Author: Frederic Barrat Date: Fri Jun 17 18:53:28 2016 +0200 powerpc/mm: Prevent unlikely crash in copro_calculate_slb() commit d2cf909cda5f8c5609cb7ed6cda816c3e15528c7 upstream. If a cxl adapter faults on an invalid address for a kernel context, we may enter copro_calculate_slb() with a NULL mm pointer (kernel context) and an effective address which looks like a user address. Which will cause a crash when dereferencing mm. It is clearly an AFU bug, but there's no reason to crash either. So return an error, so that cxl can ack the interrupt with an address error. Fixes: 73d16a6e0e51 ("powerpc/cell: Move data segment faulting code out of cell platform") Signed-off-by: Frederic Barrat Acked-by: Ian Munsie Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit e382e130d45a9f95c8da77bc8bca1464ae9c6cae Author: Nikolay Borisov Date: Mon Oct 10 15:38:18 2016 +0300 ceph: fix error handling in ceph_read_iter commit 0d7718f666be181fda1ba2d08f137d87c1419347 upstream. In case __ceph_do_getattr returns an error and the retry_op in ceph_read_iter is not READ_INLINE, then it's possible to invoke __free_page on a page which is NULL, this naturally leads to a crash. This can happen when, for example, a process waiting on a MDS reply receives sigterm. Fix this by explicitly checking whether the page is set or not. Signed-off-by: Nikolay Borisov Reviewed-by: Yan, Zheng Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 08cd19c602145b75e2782831e1822f6fe7f560c9 Author: Marc Zyngier Date: Mon Oct 17 13:47:34 2016 +0100 arm64: kernel: Init MDCR_EL2 even in the absence of a PMU commit 850540351bb1a4fa5f192e5ce55b89928cc57f42 upstream. Commit f436b2ac90a0 ("arm64: kernel: fix architected PMU registers unconditional access") made sure we wouldn't access unimplemented PMU registers, but also left MDCR_EL2 uninitialized in that case, leading to trap bits being potentially left set. Make sure we always write something in that register. Fixes: f436b2ac90a0 ("arm64: kernel: fix architected PMU registers unconditional access") Cc: Lorenzo Pieralisi Cc: Will Deacon Signed-off-by: Marc Zyngier Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit b31070890d2a5ecd9523d123a2ea94c0ee18d310 Author: Will Deacon Date: Mon Jul 4 17:44:48 2016 +0100 arm64: percpu: rewrite ll/sc loops in assembly commit 1e6e57d9b34a9075d5f9e2048ea7b09756590d11 upstream. Writing the outer loop of an LL/SC sequence using do {...} while constructs potentially allows the compiler to hoist memory accesses between the STXR and the branch back to the LDXR. On CPUs that do not guarantee forward progress of LL/SC loops when faced with memory accesses to the same ERG (up to 2k) between the failed STXR and the branch back, we may end up livelocking. This patch avoids this issue in our percpu atomics by rewriting the outer loop as part of the LL/SC inline assembly block. Fixes: f97fc810798c ("arm64: percpu: Implement this_cpu operations") Reviewed-by: Mark Rutland Tested-by: Mark Rutland Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 8dc22842bd73eab7701c02b5857e8b25afd349dc Author: Ulf Hansson Date: Wed Sep 28 11:33:28 2016 -0700 memstick: rtsx_usb_ms: Manage runtime PM when accessing the device commit 9158cb29e7c2f10dd325eb1589f0fe745a271257 upstream. Accesses to the rtsx usb device, which is the parent of the rtsx memstick device, must not be done unless it's runtime resumed. This is currently not the case and it could trigger various errors. Fix this by properly deal with runtime PM in this regards. This means making sure the device is runtime resumed, when serving requests via the ->request() callback or changing settings via the ->set_param() callbacks. Cc: Ritesh Raj Sarraf Cc: Alan Stern Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit d538518771a659b2ef3014dce23244c19ede415d Author: Alan Stern Date: Mon Sep 26 15:45:41 2016 -0700 memstick: rtsx_usb_ms: Runtime resume the device when polling for cards commit 796aa46adf1d90eab36ae06a42e6d3f10b28a75c upstream. Accesses to the rtsx usb device, which is the parent of the rtsx memstick device, must not be done unless it's runtime resumed. Therefore when the rtsx_usb_ms driver polls for inserted memstick cards, let's add pm_runtime_get|put*() to make sure accesses is done when the rtsx usb device is runtime resumed. Reported-by: Ritesh Raj Sarraf Tested-by: Ritesh Raj Sarraf Signed-off-by: Alan Stern Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 74005674c821250b16fd2ed291588fffbdfee262 Author: Jan Kara Date: Tue Oct 4 13:44:06 2016 +0200 isofs: Do not return EACCES for unknown filesystems commit a2ed0b391dd9c3ef1d64c7c3e370f4a5ffcd324a upstream. When isofs_mount() is called to mount a device read-write, it returns EACCES even before it checks that the device actually contains an isofs filesystem. This may confuse mount(8) which then tries to mount all subsequent filesystem types in read-only mode. Fix the problem by returning EACCES only once we verify that the device indeed contains an iso9660 filesystem. Fixes: 17b7f7cf58926844e1dd40f5eb5348d481deca6a Reported-by: Kent Overstreet Reported-by: Karel Zak Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 76fd38eae33765b92aefa73aaf6cca3f22a3faa3 Author: Vladimir Murzin Date: Mon Oct 17 16:00:46 2016 +0100 irqchip/gic-v3-its: Fix entry size mask for GITS_BASER commit 9224eb77e63f70f16c0b6b7a20ca7d395f3bc077 upstream. Entry Size in GITS_BASER occupies 5 bits [52:48], but we mask out 8 bits. Fixes: cc2d3216f53c ("irqchip: GICv3: ITS command queue") Signed-off-by: Vladimir Murzin Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman commit 675525e3f469a73c44862bde44ebda8f3984dbe6 Author: David Hildenbrand Date: Thu Jul 7 10:44:10 2016 +0200 s390/mm: fix gmap tlb flush issues commit f045402984404ddc11016358411e445192919047 upstream. __tlb_flush_asce() should never be used if multiple asce belong to a mm. As this function changes mm logic determining if local or global tlb flushes will be neded, we might end up flushing only the gmap asce on all CPUs and a follow up mm asce flushes will only flush on the local CPU, although that asce ran on multiple CPUs. The missing tlb flushes will provoke strange faults in user space and even low address protections in user space, crashing the kernel. Fixes: 1b948d6caec4 ("s390/mm,tlb: optimize TLB flushing for zEC12") Cc: stable@vger.kernel.org # 3.15+ Reported-by: Sascha Silbe Acked-by: Martin Schwidefsky Signed-off-by: David Hildenbrand Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit e765b192093d3b7fc8899bd33b0867492a405ba0 Author: Linus Torvalds Date: Mon Oct 3 21:03:48 2016 -0700 Using BUG_ON() as an assert() is _never_ acceptable commit 21f54ddae449f4bdd9f1498124901d67202243d9 upstream. That just generally kills the machine, and makes debugging only much harder, since the traces may long be gone. Debugging by assert() is a disease. Don't do it. If you can continue, you're much better off doing so with a live machine where you have a much higher chance that the report actually makes it to the system logs, rather than result in a machine that is just completely dead. The only valid situation for BUG_ON() is when continuing is not an option, because there is massive corruption. But if you are just verifying that something is true, you warn about your broken assumptions (preferably just once), and limp on. Fixes: 22f2ac51b6d6 ("mm: workingset: fix crash in shadow node shrinker caused by replace_page_cache_page()") Cc: Johannes Weiner Cc: Miklos Szeredi Cc: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Michal Hocko Signed-off-by: Greg Kroah-Hartman commit ddafc880082e0e7b809ca84866eeddb2b5ef118e Author: Johannes Weiner Date: Tue Oct 4 16:58:06 2016 +0200 mm: filemap: fix mapping->nrpages double accounting in fuse commit 3ddf40e8c31964b744ff10abb48c8e36a83ec6e7 upstream. Commit 22f2ac51b6d6 ("mm: workingset: fix crash in shadow node shrinker caused by replace_page_cache_page()") switched replace_page_cache() from raw radix tree operations to page_cache_tree_insert() but didn't take into account that the latter function, unlike the raw radix tree op, handles mapping->nrpages. As a result, that counter is bumped for each page replacement rather than balanced out even. The mapping->nrpages counter is used to skip needless radix tree walks when invalidating, truncating, syncing inodes without pages, as well as statistics for userspace. Since the error is positive, we'll do more page cache tree walks than necessary; we won't miss a necessary one. And we'll report more buffer pages to userspace than there are. The error is limited to fuse inodes. Fixes: 22f2ac51b6d6 ("mm: workingset: fix crash in shadow node shrinker caused by replace_page_cache_page()") Signed-off-by: Johannes Weiner Cc: Andrew Morton Cc: Miklos Szeredi Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Michal Hocko Signed-off-by: Greg Kroah-Hartman commit f84311d7cd04cb1da9f0192417a584543be879a3 Author: Johannes Weiner Date: Fri Sep 30 15:11:29 2016 -0700 mm: workingset: fix crash in shadow node shrinker caused by replace_page_cache_page() commit 22f2ac51b6d643666f4db093f13144f773ff3f3a upstream. Antonio reports the following crash when using fuse under memory pressure: kernel BUG at /build/linux-a2WvEb/linux-4.4.0/mm/workingset.c:346! invalid opcode: 0000 [#1] SMP Modules linked in: all of them CPU: 2 PID: 63 Comm: kswapd0 Not tainted 4.4.0-36-generic #55-Ubuntu Hardware name: System manufacturer System Product Name/P8H67-M PRO, BIOS 3904 04/27/2013 task: ffff88040cae6040 ti: ffff880407488000 task.ti: ffff880407488000 RIP: shadow_lru_isolate+0x181/0x190 Call Trace: __list_lru_walk_one.isra.3+0x8f/0x130 list_lru_walk_one+0x23/0x30 scan_shadow_nodes+0x34/0x50 shrink_slab.part.40+0x1ed/0x3d0 shrink_zone+0x2ca/0x2e0 kswapd+0x51e/0x990 kthread+0xd8/0xf0 ret_from_fork+0x3f/0x70 which corresponds to the following sanity check in the shadow node tracking: BUG_ON(node->count & RADIX_TREE_COUNT_MASK); The workingset code tracks radix tree nodes that exclusively contain shadow entries of evicted pages in them, and this (somewhat obscure) line checks whether there are real pages left that would interfere with reclaim of the radix tree node under memory pressure. While discussing ways how fuse might sneak pages into the radix tree past the workingset code, Miklos pointed to replace_page_cache_page(), and indeed there is a problem there: it properly accounts for the old page being removed - __delete_from_page_cache() does that - but then does a raw raw radix_tree_insert(), not accounting for the replacement page. Eventually the page count bits in node->count underflow while leaving the node incorrectly linked to the shadow node LRU. To address this, make sure replace_page_cache_page() uses the tracked page insertion code, page_cache_tree_insert(). This fixes the page accounting and makes sure page-containing nodes are properly unlinked from the shadow node LRU again. Also, make the sanity checks a bit less obscure by using the helpers for checking the number of pages and shadows in a radix tree node. [mhocko@suse.com: backport for 4.4] Fixes: 449dd6984d0e ("mm: keep page cache radix tree nodes in check") Link: http://lkml.kernel.org/r/20160919155822.29498-1-hannes@cmpxchg.org Signed-off-by: Johannes Weiner Reported-by: Antonio SJ Musumeci Debugged-by: Miklos Szeredi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Michal Hocko Signed-off-by: Greg Kroah-Hartman commit 74688ce499ad18375b8b2fb6f784f4dddc6fc1db Author: Vishal Verma Date: Fri Aug 19 14:40:58 2016 -0600 acpi, nfit: check for the correct event code in notifications commit c09f12186d6b03b798832d95289af76495990192 upstream. Commit 209851649dc4 "acpi: nfit: Add support for hot-add" added support for _FIT notifications, but it neglected to verify the notification event code matches the one in the ACPI spec for "NFIT Update". Currently there is only one code in the spec, but once additional codes are added, older kernels (without this fix) will misbehave by assuming all event notifications are for an NFIT Update. Fixes: 209851649dc4 ("acpi: nfit: Add support for hot-add") Cc: Cc: Cc: Dan Williams Reported-by: Linda Knippers Signed-off-by: Vishal Verma Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 70c66946ef35691eeaf15977236219ffbc16f398 Author: Jack Morgenstein Date: Wed Mar 2 17:47:46 2016 +0200 net/mlx4_core: Allow resetting VF admin mac to zero commit 6e5224224faa50ec4c8949dcefadf895e565f0d1 upstream. The VF administrative mac addresses (stored in the PF driver) are initialized to zero when the PF driver starts up. These addresses may be modified in the PF driver through ndo calls initiated by iproute2 or libvirt. While we allow the PF/host to change the VF admin mac address from zero to a valid unicast mac, we do not allow restoring the VF admin mac to zero. We currently only allow changing this mac to a different unicast mac. This leads to problems when libvirt scripts are used to deal with VF mac addresses, and libvirt attempts to revoke the mac so this host will not use it anymore. Fix this by allowing resetting a VF administrative MAC back to zero. Fixes: 8f7ba3ca12f6 ('net/mlx4: Add set VF mac address support') Signed-off-by: Jack Morgenstein Reported-by: Moshe Levi Signed-off-by: David S. Miller Signed-off-by: Juerg Haefliger Signed-off-by: Greg Kroah-Hartman commit 6896b3dd2da5848ca54c96ee54a15ccd532e2904 Author: Yuval Mintz Date: Tue Mar 15 19:52:04 2016 +0200 bnx2x: Prevent false warning for lack of FC NPIV commit 1e6bb1a3540fec3ef112b9a89dda88e684c3ff59 upstream. Not all adapters have FC-NPIV configured. If bnx2fc is used with such an adapter, driver would read irrelevant data from the the nvram and log "FC-NPIV table with bad length..." In system logs. Simply accept that reading '0' as the feature offset in nvram indicates the feature isn't there and return. Reported-by: Andrew Patterson Signed-off-by: Yuval Mintz Signed-off-by: David S. Miller Signed-off-by: Juerg Haefliger Signed-off-by: Greg Kroah-Hartman commit e0c4d7bf1f29bc14fab390358bcc2e4486402eb7 Author: Peter Jones Date: Mon Jan 18 10:49:58 2016 -0500 PKCS#7: Don't require SpcSpOpusInfo in Authenticode pkcs7 signatures commit 7ee7014d0eb6bcac679c0bd5fe9ce65bc4325648 upstream. Dave Young reported: > Hi, > > I saw the warning "Missing required AuthAttr" when testing kexec, > known issue? Idea about how to fix it? > > The kernel is latest linus tree plus sevral patches from Toshi to > cleanup io resource structure. > > in function pkcs7_sig_note_set_of_authattrs(): > if (!test_bit(sinfo_has_content_type, &sinfo->aa_set) || > !test_bit(sinfo_has_message_digest, &sinfo->aa_set) || > (ctx->msg->data_type == OID_msIndirectData && > !test_bit(sinfo_has_ms_opus_info, &sinfo->aa_set))) { > pr_warn("Missing required AuthAttr\n"); > return -EBADMSG; > } > > The third condition below is true: > (ctx->msg->data_type == OID_msIndirectData && > !test_bit(sinfo_has_ms_opus_info, &sinfo->aa_set)) > > I signed the kernel with redhat test key like below: > pesign -c 'Red Hat Test Certificate' -i arch/x86/boot/bzImage -o /boot/vmlinuz-4.4.0-rc8+ -s --force And right he is! The Authenticode specification is a paragon amongst technical documents, and has this pearl of wisdom to offer: --------------------------------- Authenticode-Specific SignerInfo UnauthenticatedAttributes Structures The following Authenticode-specific data structures are present in SignerInfo authenticated attributes. SpcSpOpusInfo SpcSpOpusInfo is identified by SPC_SP_OPUS_INFO_OBJID (1.3.6.1.4.1.311.2.1.12) and is defined as follows: SpcSpOpusInfo ::= SEQUENCE { programName [0] EXPLICIT SpcString OPTIONAL, moreInfo [1] EXPLICIT SpcLink OPTIONAL, } --#public-- SpcSpOpusInfo has two fields: programName This field contains the program description: If publisher chooses not to specify a description, the SpcString structure contains a zero-length program name. If the publisher chooses to specify a description, the SpcString structure contains a Unicode string. moreInfo This field is set to an SPCLink structure that contains a URL for a Web site with more information about the signer. The URL is an ASCII string. --------------------------------- Which is to say that this is an optional *unauthenticated* field which may be present in the Authenticated Attribute list. This is not how pkcs7 is supposed to work, so when David implemented this, he didn't appreciate the subtlety the original spec author was working with, and missed the part of the sublime prose that says this Authenticated Attribute is an Unauthenticated Attribute. As a result, the code in question simply takes as given that the Authenticated Attributes should be authenticated. But this one should not, individually. Because it says it's not authenticated. It still has to hash right so the TBS digest is correct. So it is both authenticated and unauthenticated, all at once. Truly, a wonder of technical accomplishment. Additionally, pesign's implementation has always attempted to be compatible with the signatures emitted from contemporary versions of Microsoft's signtool.exe. During the initial implementation, Microsoft signatures always produced the same values for SpcSpOpusInfo - {U"Microsoft Windows", "http://www.microsoft.com"} - without regard to who the signer was. Sometime between Windows 8 and Windows 8.1 they stopped including the field in their signatures altogether, and as such pesign stopped producing them in commits c0c4da6 and d79cb0c, sometime around June of 2012. The theory here is that anything that breaks with pesign signatures would also be breaking with signtool.exe sigs as well, and that'll be a more noticed problem for firmwares parsing it, so it'll get fixed. The fact that we've done exactly this bug in Linux code is first class, grade A irony. So anyway, we should not be checking this field for presence or any particular value: if the field exists, it should be at the right place, but aside from that, as long as the hash matches the field is good. Signed-off-by: Peter Jones Tested-by: Dave Young Signed-off-by: Herbert Xu Signed-off-by: Juerg Haefliger Signed-off-by: Greg Kroah-Hartman commit 652a174a7d14e5334d2a3f5aa9be9ba52d293bc2 Author: Don Brace Date: Fri Jul 1 13:37:31 2016 -0500 hpsa: correct skipping masked peripherals commit 64ce60cab24603ac0fcd59c9fbc3be78f4c4d229 upstream. The SA controller spins down RAID drive spares. A REGNEWD event causes an inquiry to be sent to all physical drives. This causes the SA controller to spin up the spare. The controller suspends all I/O to a logical volume until the spare is spun up. The spin-up can take over 50 seconds. This can result in one or both of the following: - SML sends down aborts and resets to the logical volume and can cause the logical volume to be off-lined. - a negative impact on the logical volume's I/O performance each time a REGNEWD is triggered. Reviewed-by: Scott Teel Reviewed-by: Kevin Barnett Signed-off-by: Don Brace Signed-off-by: Martin K. Petersen Signed-off-by: Juerg Haefliger Signed-off-by: Greg Kroah-Hartman commit 9814eb75495bcd2fd2fc234bd474f0c395407c4c Author: Martin K. Petersen Date: Thu May 12 22:17:34 2016 -0400 sd: Fix rw_max for devices that report an optimal xfer size commit 6b7e9cde49691e04314342b7dce90c67ad567fcc upstream. For historic reasons, io_opt is in bytes and max_sectors in block layer sectors. This interface inconsistency is error prone and should be fixed. But for 4.4--4.7 let's make the unit difference explicit via a wrapper function. Fixes: d0eb20a863ba ("sd: Optimal I/O size is in bytes, not sectors") Reported-by: Fam Zheng Reviewed-by: Bart Van Assche Reviewed-by: Christoph Hellwig Tested-by: Andrew Patterson Signed-off-by: Martin K. Petersen Signed-off-by: Juerg Haefliger Signed-off-by: Greg Kroah-Hartman commit 43d03a59f1c00d6492a786c87d3a53336b6f375f Author: Dan Carpenter Date: Fri Oct 14 10:26:21 2016 +0300 irqchip/gicv3: Handle loop timeout proper commit d102eb5c1ac5e6743b1c6d145c06a25d98ad1375 upstream. The timeout loop terminates when the loop count is zero, but the decrement of the count variable is post check. So count is -1 when we check for the timeout and therefor the error message is supressed. Change it to predecrement, so the error message is emitted. [ tglx: Massaged changelog ] Fixes: a2c225101234 ("irqchip: gic-v3: Refactor gic_enable_redist to support both enabling and disabling") Signed-off-by: Dan Carpenter Acked-by: Sudeep Holla Cc: Marc Zyngier Cc: kernel-janitors@vger.kernel.org Cc: Jason Cooper Link: http://lkml.kernel.org/r/20161014072534.GA15168@mwanda Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 742b0cee459cd7d9e9415e2f71694a95f1c05df0 Author: Jiri Slaby Date: Thu Oct 13 17:45:20 2016 +0200 kvm: x86: memset whole irq_eoi commit 8678654e3c7ad7b0f4beb03fa89691279cba71f9 upstream. gcc 7 warns: arch/x86/kvm/ioapic.c: In function 'kvm_ioapic_reset': arch/x86/kvm/ioapic.c:597:2: warning: 'memset' used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size] And it is right. Memset whole array using sizeof operator. Signed-off-by: Jiri Slaby Cc: Paolo Bonzini Cc: Radim Krčmář Cc: Thomas Gleixner Cc: Ingo Molnar Cc: H. Peter Anvin Cc: x86@kernel.org Cc: kvm@vger.kernel.org Cc: linux-kernel@vger.kernel.org Reviewed-by: Paolo Bonzini [Added x86 subject tag] Signed-off-by: Radim Krčmář Signed-off-by: Greg Kroah-Hartman commit c234231da4e0565d89259da73c8a5e417fe5bba5 Author: Dan Williams Date: Wed Oct 12 11:01:48 2016 -0700 x86/e820: Don't merge consecutive E820_PRAM ranges commit 23446cb66c073b827779e5eb3dec301623299b32 upstream. Commit: 917db484dc6a ("x86/boot: Fix kdump, cleanup aborted E820_PRAM max_pfn manipulation") ... fixed up the broken manipulations of max_pfn in the presence of E820_PRAM ranges. However, it also broke the sanitize_e820_map() support for not merging E820_PRAM ranges. Re-introduce the enabling to keep resource boundaries between consecutive defined ranges. Otherwise, for example, an environment that boots with memmap=2G!8G,2G!10G will end up with a single 4G /dev/pmem0 device instead of a /dev/pmem0 and /dev/pmem1 device 2G in size. Reported-by: Dave Chinner Signed-off-by: Dan Williams Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Jeff Moyer Cc: Josh Poimboeuf Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Zhang Yi Cc: linux-nvdimm@lists.01.org Fixes: 917db484dc6a ("x86/boot: Fix kdump, cleanup aborted E820_PRAM max_pfn manipulation") Link: http://lkml.kernel.org/r/147629530854.10618.10383744751594021268.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 6d4c93affe9e3ee9c61404fc6aa7f45ba3aba40f Author: Bart Van Assche Date: Thu Sep 29 08:33:30 2016 -0700 blkcg: Unlock blkcg_pol_mutex only once when cpd == NULL commit bbb427e342495df1cda10051d0566388697499c0 upstream. Unlocking a mutex twice is wrong. Hence modify blkcg_policy_register() such that blkcg_pol_mutex is unlocked once if cpd == NULL. This patch avoids that smatch reports the following error: block/blk-cgroup.c:1378: blkcg_policy_register() error: double unlock 'mutex:&blkcg_pol_mutex' Fixes: 06b285bd1125 ("blkcg: fix blkcg_policy_data allocation bug") Signed-off-by: Bart Van Assche Cc: Tejun Heo Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit e6222f00a3aebb2d03302c09aa58b52d87d6f784 Author: Sachin Prabhu Date: Tue Sep 6 13:22:34 2016 +0100 Fix regression which breaks DFS mounting commit d171356ff11ab1825e456dfb979755e01b3c54a1 upstream. Patch a6b5058 results in -EREMOTE returned by is_path_accessible() in cifs_mount() to be ignored which breaks DFS mounting. Signed-off-by: Sachin Prabhu Reviewed-by: Aurelien Aptel Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit d8f4633d765f1c9b6e11d4f56e0567f5553fd901 Author: Steve French Date: Thu Sep 29 04:20:23 2016 -0500 Cleanup missing frees on some ioctls commit 24df1483c272c99ed88b0cba135d0e1dfdee3930 upstream. Cleanup some missing mem frees on some cifs ioctls, and clarify others to make more obvious that no data is returned. Signed-off-by: Steve French Acked-by: Sachin Prabhu Signed-off-by: Greg Kroah-Hartman commit 588e5ed80f8ca9f709613d1dbd127cc87487e548 Author: Steve French Date: Mon Sep 26 14:23:08 2016 -0500 Do not send SMB3 SET_INFO request if nothing is changing commit 18dd8e1a65ddae2351d0f0d6dd4a334f441fc5fa upstream. [CIFS] We had cases where we sent a SMB2/SMB3 setinfo request with all timestamp (and DOS attribute) fields marked as 0 (ie do not change) e.g. on chmod or chown. Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit a8c240c8d22dc00f15cfaf21f9e176521b4acfcd Author: Steve French Date: Thu Sep 22 00:39:34 2016 -0500 SMB3: GUIDs should be constructed as random but valid uuids commit fa70b87cc6641978b20e12cc5d517e9ffc0086d4 upstream. GUIDs although random, and 16 bytes, need to be generated as proper uuids. Signed-off-by: Steve French Reviewed-by: Aurelien Aptel Reported-by: David Goebels Signed-off-by: Greg Kroah-Hartman commit b2120e0b9143beae76d73ccc6ce020ee03349b1f Author: Steve French Date: Tue Sep 20 22:56:13 2016 -0500 Set previous session id correctly on SMB3 reconnect commit c2afb8147e69819885493edf3a7c1ce03aaf2d4e upstream. Signed-off-by: Steve French Reported-by: David Goebel Signed-off-by: Greg Kroah-Hartman commit 9517a23765513f5d186d9e1eabef9cd4a3eb277c Author: Steve French Date: Mon Sep 19 22:06:35 2016 -0500 Display number of credits available commit 9742805d6b1bfb45d7f267648c34fb5bcd347397 upstream. In debugging smb3, it is useful to display the number of credits available, so we can see when the server has not granted sufficient operations for the client to make progress, or alternatively the client has requested too many credits (as we saw in a recent bug) so we can compare with the number of credits the server thinks we have. Add a /proc/fs/cifs/DebugData line to display the client view on how many credits are available. Signed-off-by: Steve French Reported-by: Germano Percossi Signed-off-by: Greg Kroah-Hartman commit ed3ccfea6c2b0d873d72ca7b7a250b7a747eac33 Author: Steve French Date: Thu Sep 22 18:58:16 2016 -0500 Clarify locking of cifs file and tcon structures and make more granular commit 3afca265b5f53a0b15b79531c13858049505582d upstream. Remove the global file_list_lock to simplify cifs/smb3 locking and have spinlocks that more closely match the information they are protecting. Add new tcon->open_file_lock and file->file_info_lock spinlocks. Locks continue to follow a heirachy, cifs_socket --> cifs_ses --> cifs_tcon --> cifs_file where global tcp_ses_lock still protects socket and cifs_ses, while the the newer locks protect the lower level structure's information (tcon and cifs_file respectively). Signed-off-by: Steve French Signed-off-by: Pavel Shilovsky Reviewed-by: Aurelien Aptel Reviewed-by: Germano Percossi Signed-off-by: Greg Kroah-Hartman commit 46d355f595c39fb8e57f7b1b8a7a5f0ae2a8040d Author: Aurelien Aptel Date: Thu Sep 22 07:38:50 2016 +0200 fs/cifs: keep guid when assigning fid to fileinfo commit 94f873717571c759b7928399cbbddfa3d569bd01 upstream. When we open a durable handle we give a Globally Unique Identifier (GUID) to the server which we must keep for later reference e.g. when reopening persistent handles on reconnection. Without this the GUID generated for a new persistent handle was lost and 16 zero bytes were used instead on re-opening. Signed-off-by: Aurelien Aptel Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 9a465ebbe751aa6489b0df12f27f2b89e3ebf41a Author: Ross Lagerwall Date: Tue Sep 20 13:37:13 2016 +0100 cifs: Limit the overall credit acquired commit 7d414f396c91a3382e51cf628c1cf0709ad0188b upstream. The kernel client requests 2 credits for many operations even though they only use 1 credit (presumably to build up a buffer of credit). Some servers seem to give the client as much credit as is requested. In this case, the amount of credit the client has continues increasing to the point where (server->credits * MAX_BUFFER_SIZE) overflows in smb2_wait_mtu_credits(). Fix this by throttling the credit requests if an set limit is reached. For async requests where the credit charge may be > 1, request as much credit as what is charged. The limit is chosen somewhat arbitrarily. The Windows client defaults to 128 credits, the Windows server allows clients up to 512 credits (or 8192 for Windows 2016), and the NetApp server (and at least one other) does not limit clients at all. Choose a high enough value such that the client shouldn't limit performance. This behavior was seen with a NetApp filer (NetApp Release 9.0RC2). Signed-off-by: Ross Lagerwall Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 2f634e1322f7e1ca0973a606cb24f5f669884359 Author: Oleg Nesterov Date: Mon Sep 26 18:07:48 2016 +0200 fs/super.c: fix race between freeze_super() and thaw_super() commit 89f39af129382a40d7cd1f6914617282cfeee28e upstream. Change thaw_super() to check frozen != SB_FREEZE_COMPLETE rather than frozen == SB_UNFROZEN, otherwise it can race with freeze_super() which drops sb->s_umount after SB_FREEZE_WRITE to preserve the lock ordering. In this case thaw_super() will wrongly call s_op->unfreeze_fs() before it was actually frozen, and call sb_freeze_unlock() which leads to the unbalanced percpu_up_write(). Unfortunately lockdep can't detect this, so this triggers misc BUG_ON()'s in kernel/rcu/sync.c. Reported-and-tested-by: Nikolay Borisov Signed-off-by: Oleg Nesterov Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 8cffabab018cad0dfcfe3ab44ff8c2510fc2408d Author: Al Viro Date: Sat Sep 10 16:31:04 2016 -0400 arc: don't leak bits of kernel stack into coredump commit 7798bf2140ebcc36eafec6a4194fffd8d585d471 upstream. On faulting sigreturn we do get SIGSEGV, all right, but anything we'd put into pt_regs could end up in the coredump. And since __copy_from_user() never zeroed on arc, we'd better bugger off on its failure without copying random uninitialized bits of kernel stack into pt_regs... Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit f2e81c026017222c18b178f175adf415c276b131 Author: Jens Axboe Date: Wed Jan 13 13:04:11 2016 -0700 lightnvm: ensure that nvm_dev_ops can be used without CONFIG_NVM commit a7fd9a4f3e8179bab31e4637236ebb0e0b7867c6 upstream. null_blk defines an empty version of this ops structure if CONFIG_NVM isn't set, but it doesn't know the type. Move those bits out of the protection of CONFIG_NVM in the main lightnvm include. Signed-off-by: Jens Axboe [pebolle: backport to v4.4] Signed-off-by: Paul Bolle Signed-off-by: Greg Kroah-Hartman commit f6031d95320dc2930f1b813e98533a01c92f3dc0 Author: Manfred Spraul Date: Tue Oct 11 13:54:50 2016 -0700 ipc/sem.c: fix complex_count vs. simple op race commit 5864a2fd3088db73d47942370d0f7210a807b9bc upstream. Commit 6d07b68ce16a ("ipc/sem.c: optimize sem_lock()") introduced a race: sem_lock has a fast path that allows parallel simple operations. There are two reasons why a simple operation cannot run in parallel: - a non-simple operations is ongoing (sma->sem_perm.lock held) - a complex operation is sleeping (sma->complex_count != 0) As both facts are stored independently, a thread can bypass the current checks by sleeping in the right positions. See below for more details (or kernel bugzilla 105651). The patch fixes that by creating one variable (complex_mode) that tracks both reasons why parallel operations are not possible. The patch also updates stale documentation regarding the locking. With regards to stable kernels: The patch is required for all kernels that include the commit 6d07b68ce16a ("ipc/sem.c: optimize sem_lock()") (3.10?) The alternative is to revert the patch that introduced the race. The patch is safe for backporting, i.e. it makes no assumptions about memory barriers in spin_unlock_wait(). Background: Here is the race of the current implementation: Thread A: (simple op) - does the first "sma->complex_count == 0" test Thread B: (complex op) - does sem_lock(): This includes an array scan. But the scan can't find Thread A, because Thread A does not own sem->lock yet. - the thread does the operation, increases complex_count, drops sem_lock, sleeps Thread A: - spin_lock(&sem->lock), spin_is_locked(sma->sem_perm.lock) - sleeps before the complex_count test Thread C: (complex op) - does sem_lock (no array scan, complex_count==1) - wakes up Thread B. - decrements complex_count Thread A: - does the complex_count test Bug: Now both thread A and thread C operate on the same array, without any synchronization. Fixes: 6d07b68ce16a ("ipc/sem.c: optimize sem_lock()") Link: http://lkml.kernel.org/r/1469123695-5661-1-git-send-email-manfred@colorfullife.com Reported-by: Cc: "H. Peter Anvin" Cc: Peter Zijlstra Cc: Davidlohr Bueso Cc: Thomas Gleixner Cc: Ingo Molnar Cc: <1vier1@web.de> Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit b52b7b5a5cafe1b415291b971259cee319345d18 Author: Johannes Weiner Date: Tue Oct 4 22:02:08 2016 +0200 mm: filemap: don't plant shadow entries without radix tree node commit d3798ae8c6f3767c726403c2ca6ecc317752c9dd upstream. When the underflow checks were added to workingset_node_shadow_dec(), they triggered immediately: kernel BUG at ./include/linux/swap.h:276! invalid opcode: 0000 [#1] SMP Modules linked in: isofs usb_storage fuse xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_REJECT nf_reject_ipv6 soundcore wmi acpi_als pinctrl_sunrisepoint kfifo_buf tpm_tis industrialio acpi_pad pinctrl_intel tpm_tis_core tpm nfsd auth_rpcgss nfs_acl lockd grace sunrpc dm_crypt CPU: 0 PID: 20929 Comm: blkid Not tainted 4.8.0-rc8-00087-gbe67d60ba944 #1 Hardware name: System manufacturer System Product Name/Z170-K, BIOS 1803 05/06/2016 task: ffff8faa93ecd940 task.stack: ffff8faa7f478000 RIP: page_cache_tree_insert+0xf1/0x100 Call Trace: __add_to_page_cache_locked+0x12e/0x270 add_to_page_cache_lru+0x4e/0xe0 mpage_readpages+0x112/0x1d0 blkdev_readpages+0x1d/0x20 __do_page_cache_readahead+0x1ad/0x290 force_page_cache_readahead+0xaa/0x100 page_cache_sync_readahead+0x3f/0x50 generic_file_read_iter+0x5af/0x740 blkdev_read_iter+0x35/0x40 __vfs_read+0xe1/0x130 vfs_read+0x96/0x130 SyS_read+0x55/0xc0 entry_SYSCALL_64_fastpath+0x13/0x8f Code: 03 00 48 8b 5d d8 65 48 33 1c 25 28 00 00 00 44 89 e8 75 19 48 83 c4 18 5b 41 5c 41 5d 41 5e 5d c3 0f 0b 41 bd ef ff ff ff eb d7 <0f> 0b e8 88 68 ef ff 0f 1f 84 00 RIP page_cache_tree_insert+0xf1/0x100 This is a long-standing bug in the way shadow entries are accounted in the radix tree nodes. The shrinker needs to know when radix tree nodes contain only shadow entries, no pages, so node->count is split in half to count shadows in the upper bits and pages in the lower bits. Unfortunately, the radix tree implementation doesn't know of this and assumes all entries are in node->count. When there is a shadow entry directly in root->rnode and the tree is later extended, the radix tree implementation will copy that entry into the new node and and bump its node->count, i.e. increases the page count bits. Once the shadow gets removed and we subtract from the upper counter, node->count underflows and triggers the warning. Afterwards, without node->count reaching 0 again, the radix tree node is leaked. Limit shadow entries to when we have actual radix tree nodes and can count them properly. That means we lose the ability to detect refaults from files that had only the first page faulted in at eviction time. Fixes: 449dd6984d0e ("mm: keep page cache radix tree nodes in check") Signed-off-by: Johannes Weiner Reported-and-tested-by: Linus Torvalds Reviewed-by: Jan Kara Cc: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit c8f0fef21d6426a08aa262073bc41f3c7512f651 Author: Guenter Roeck Date: Fri Oct 7 10:40:59 2016 -0700 metag: Only define atomic_dec_if_positive conditionally commit 35d04077ad96ed33ceea2501f5a4f1eacda77218 upstream. The definition of atomic_dec_if_positive() assumes that atomic_sub_if_positive() exists, which is only the case if metag specific atomics are used. This results in the following build error when trying to build metag1_defconfig. kernel/ucount.c: In function 'dec_ucount': kernel/ucount.c:211: error: implicit declaration of function 'atomic_sub_if_positive' Moving the definition of atomic_dec_if_positive() into the metag conditional code fixes the problem. Fixes: 6006c0d8ce94 ("metag: Atomics, locks and bitops") Signed-off-by: Guenter Roeck Signed-off-by: James Hogan Signed-off-by: Greg Kroah-Hartman commit bffff9301e1dde678ebe511636999dffa2dfa117 Author: Ming Lei Date: Sun Oct 9 13:23:27 2016 +0800 scsi: Fix use-after-free commit bcd8f2e94808fcddf6ef3af5f060a36820dcc432 upstream. This patch fixes one use-after-free report[1] by KASAN. In __scsi_scan_target(), when a type 31 device is probed, SCSI_SCAN_TARGET_PRESENT is returned and the target will be scanned again. Inside the following scsi_report_lun_scan(), one new scsi_device instance is allocated, and scsi_probe_and_add_lun() is called again to probe the target and still see type 31 device, finally __scsi_remove_device() is called to remove & free the device at the end of scsi_probe_and_add_lun(), so cause use-after-free in scsi_report_lun_scan(). And the following SCSI log can be observed: scsi 0:0:2:0: scsi scan: INQUIRY pass 1 length 36 scsi 0:0:2:0: scsi scan: INQUIRY successful with code 0x0 scsi 0:0:2:0: scsi scan: peripheral device type of 31, no device added scsi 0:0:2:0: scsi scan: Sending REPORT LUNS to (try 0) scsi 0:0:2:0: scsi scan: REPORT LUNS successful (try 0) result 0x0 scsi 0:0:2:0: scsi scan: REPORT LUN scan scsi 0:0:2:0: scsi scan: INQUIRY pass 1 length 36 scsi 0:0:2:0: scsi scan: INQUIRY successful with code 0x0 scsi 0:0:2:0: scsi scan: peripheral device type of 31, no device added BUG: KASAN: use-after-free in __scsi_scan_target+0xbf8/0xe40 at addr ffff88007b44a104 This patch fixes the issue by moving the putting reference at the end of scsi_report_lun_scan(). [1] KASAN report ================================================================== [ 3.274597] PM: Adding info for serio:serio1 [ 3.275127] BUG: KASAN: use-after-free in __scsi_scan_target+0xd87/0xdf0 at addr ffff880254d8c304 [ 3.275653] Read of size 4 by task kworker/u10:0/27 [ 3.275903] CPU: 3 PID: 27 Comm: kworker/u10:0 Not tainted 4.8.0 #2121 [ 3.276258] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 [ 3.276797] Workqueue: events_unbound async_run_entry_fn [ 3.277083] ffff880254d8c380 ffff880259a37870 ffffffff94bbc6c1 ffff880078402d80 [ 3.277532] ffff880254d8bb80 ffff880259a37898 ffffffff9459fec1 ffff880259a37930 [ 3.277989] ffff880254d8bb80 ffff880078402d80 ffff880259a37920 ffffffff945a0165 [ 3.278436] Call Trace: [ 3.278528] [] dump_stack+0x65/0x84 [ 3.278797] [] kasan_object_err+0x21/0x70 [ 3.279063] device: 'psaux': device_add [ 3.279616] [] kasan_report_error+0x205/0x500 [ 3.279651] PM: Adding info for No Bus:psaux [ 3.280202] [] ? kfree_const+0x22/0x30 [ 3.280486] [] ? kobject_release+0x119/0x370 [ 3.280805] [] __asan_report_load4_noabort+0x43/0x50 [ 3.281170] [] ? __scsi_scan_target+0xd87/0xdf0 [ 3.281506] [] __scsi_scan_target+0xd87/0xdf0 [ 3.281848] [] ? scsi_add_device+0x30/0x30 [ 3.282156] [] ? pm_runtime_autosuspend_expiration+0x60/0x60 [ 3.282570] [] ? _raw_spin_lock+0x17/0x40 [ 3.282880] [] scsi_scan_channel+0x105/0x160 [ 3.283200] [] scsi_scan_host_selected+0x212/0x2f0 [ 3.283563] [] do_scsi_scan_host+0x1bc/0x250 [ 3.283882] [] do_scan_async+0x41/0x450 [ 3.284173] [] async_run_entry_fn+0xfe/0x610 [ 3.284492] [] ? pwq_dec_nr_in_flight+0x124/0x2a0 [ 3.284876] [] ? preempt_count_add+0x130/0x160 [ 3.285207] [] process_one_work+0x544/0x12d0 [ 3.285526] [] worker_thread+0xd9/0x12f0 [ 3.285844] [] ? process_one_work+0x12d0/0x12d0 [ 3.286182] [] kthread+0x1c5/0x260 [ 3.286443] [] ? __switch_to+0x88d/0x1430 [ 3.286745] [] ? kthread_worker_fn+0x5a0/0x5a0 [ 3.287085] [] ret_from_fork+0x1f/0x40 [ 3.287368] [] ? kthread_worker_fn+0x5a0/0x5a0 [ 3.287697] Object at ffff880254d8bb80, in cache kmalloc-2048 size: 2048 [ 3.288064] Allocated: [ 3.288147] PID = 27 [ 3.288218] [] save_stack_trace+0x2b/0x50 [ 3.288531] [] save_stack+0x46/0xd0 [ 3.288806] [] kasan_kmalloc+0xad/0xe0 [ 3.289098] [] __kmalloc+0x13e/0x250 [ 3.289378] [] scsi_alloc_sdev+0xea/0xcf0 [ 3.289701] [] __scsi_scan_target+0xa06/0xdf0 [ 3.290034] [] scsi_scan_channel+0x105/0x160 [ 3.290362] [] scsi_scan_host_selected+0x212/0x2f0 [ 3.290724] [] do_scsi_scan_host+0x1bc/0x250 [ 3.291055] [] do_scan_async+0x41/0x450 [ 3.291354] [] async_run_entry_fn+0xfe/0x610 [ 3.291695] [] process_one_work+0x544/0x12d0 [ 3.292022] [] worker_thread+0xd9/0x12f0 [ 3.292325] [] kthread+0x1c5/0x260 [ 3.292594] [] ret_from_fork+0x1f/0x40 [ 3.292886] Freed: [ 3.292945] PID = 27 [ 3.293016] [] save_stack_trace+0x2b/0x50 [ 3.293327] [] save_stack+0x46/0xd0 [ 3.293600] [] kasan_slab_free+0x71/0xb0 [ 3.293916] [] kfree+0xa2/0x1f0 [ 3.294168] [] scsi_device_dev_release_usercontext+0x50a/0x730 [ 3.294598] [] execute_in_process_context+0xda/0x130 [ 3.294974] [] scsi_device_dev_release+0x1c/0x20 [ 3.295322] [] device_release+0x76/0x1e0 [ 3.295626] [] kobject_release+0x107/0x370 [ 3.295942] [] kobject_put+0x4e/0xa0 [ 3.296222] [] put_device+0x17/0x20 [ 3.296497] [] scsi_device_put+0x7c/0xa0 [ 3.296801] [] __scsi_scan_target+0xd4c/0xdf0 [ 3.297132] [] scsi_scan_channel+0x105/0x160 [ 3.297458] [] scsi_scan_host_selected+0x212/0x2f0 [ 3.297829] [] do_scsi_scan_host+0x1bc/0x250 [ 3.298156] [] do_scan_async+0x41/0x450 [ 3.298453] [] async_run_entry_fn+0xfe/0x610 [ 3.298777] [] process_one_work+0x544/0x12d0 [ 3.299105] [] worker_thread+0xd9/0x12f0 [ 3.299408] [] kthread+0x1c5/0x260 [ 3.299676] [] ret_from_fork+0x1f/0x40 [ 3.299967] Memory state around the buggy address: [ 3.300209] ffff880254d8c200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 3.300608] ffff880254d8c280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 3.300986] >ffff880254d8c300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 3.301408] ^ [ 3.301550] ffff880254d8c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 3.301987] ffff880254d8c400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 3.302396] ================================================================== Cc: Christoph Hellwig Signed-off-by: Ming Lei Reviewed-by: Christoph Hellwig Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 52bee8880ff4fddd1c7b520f8af34075a92f644e Author: Jeff Layton Date: Tue Oct 4 00:07:43 2016 -0400 NFSv4.2: Fix a reference leak in nfs42_proc_layoutstats_generic commit 3f807e5ae5597bd65a6fff684083e8eaa21f3fa7 upstream. The caller of rpc_run_task also gets a reference that must be put. Signed-off-by: Jeff Layton Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 2c52c33a25f508bc8ba80d666339cf2f44ece3ad Author: Trond Myklebust Date: Thu Sep 22 13:39:18 2016 -0400 NFSv4: Open state recovery must account for file permission changes commit 304020fe48c6c7fff8b5a38f382b54404f0f79d3 upstream. If the file permissions change on the server, then we may not be able to recover open state. If so, we need to ensure that we mark the file descriptor appropriately. Signed-off-by: Trond Myklebust Tested-by: Oleg Drokin Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit c7a128f02ef89b8f4da86098c707ff229172cf63 Author: Trond Myklebust Date: Thu Sep 22 13:38:54 2016 -0400 NFSv4: nfs4_copy_delegation_stateid() must fail if the delegation is invalid commit aa05c87f23efe417adc7ff9b4193b7201ec0dd79 upstream. We must not allow the use of delegations that have been revoked or are being returned. Signed-off-by: Trond Myklebust Fixes: 869f9dfa4d6d ("NFSv4: Fix races between nfs_remove_bad_delegation()...") Signed-off-by: Trond Myklebust Tested-by: Oleg Drokin Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 79e7e444ed6cc249208798d1effea31945719c10 Author: Trond Myklebust Date: Thu Sep 22 13:38:53 2016 -0400 NFSv4: Don't report revoked delegations as valid in nfs_have_delegation() commit b3f9e7239074613aa6bdafa4caf7c104fe1e7276 upstream. If the delegation is revoked, then it can't be used for caching. Fixes: 869f9dfa4d6d ("NFSv4: Fix races between nfs_remove_bad_delegation()...") Signed-off-by: Trond Myklebust Tested-by: Oleg Drokin Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit a13ca3d638f9f741b6053fb46ce51c1e5e1a3123 Author: David Vrabel Date: Mon Sep 19 13:58:30 2016 +0100 sunrpc: fix write space race causing stalls commit d48f9ce73c997573e1b512893fa6eddf353a6f69 upstream. Write space becoming available may race with putting the task to sleep in xprt_wait_for_buffer_space(). The existing mechanism to avoid the race does not work. This (edited) partial trace illustrates the problem: [1] rpc_task_run_action: task:43546@5 ... action=call_transmit [2] xs_write_space <-xs_tcp_write_space [3] xprt_write_space <-xs_write_space [4] rpc_task_sleep: task:43546@5 ... [5] xs_write_space <-xs_tcp_write_space [1] Task 43546 runs but is out of write space. [2] Space becomes available, xs_write_space() clears the SOCKWQ_ASYNC_NOSPACE bit. [3] xprt_write_space() attemts to wake xprt->snd_task (== 43546), but this has not yet been queued and the wake up is lost. [4] xs_nospace() is called which calls xprt_wait_for_buffer_space() which queues task 43546. [5] The call to sk->sk_write_space() at the end of xs_nospace() (which is supposed to handle the above race) does not call xprt_write_space() as the SOCKWQ_ASYNC_NOSPACE bit is clear and thus the task is not woken. Fix the race by resetting the SOCKWQ_ASYNC_NOSPACE bit in xs_nospace() so the second call to sk->sk_write_space() calls xprt_write_space(). Suggested-by: Trond Myklebust Signed-off-by: David Vrabel Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit c6fde5646e91bd3cf4fdd96b1155f3af9d3ef9c4 Author: Dmitry Torokhov Date: Wed Oct 5 22:49:30 2016 -0700 Input: elantech - add Fujitsu Lifebook E556 to force crc_enabled commit 62837b3c1a95535d1a287c9c8c6563bbd8d37033 upstream. Another Lifebook machine that needs the same quirk as other similar models to make the driver working. Also let's reorder elantech_dmi_force_crc_enabled list so LIfebook enries are in alphabetical order. Reported-by: William Linna Tested-by: William Linna Reviewed-by: Benjamin Tissoires Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 58ba76ae7fdbd08fe39c81091b81a3f82e00cb5e Author: Matti Kurkela Date: Mon Oct 3 16:48:17 2016 -0700 Input: elantech - force needed quirks on Fujitsu H760 commit f9a703a54d16ba2470391c4b12236ee56591d50c upstream. Just like Fujitsu CELSIUS H730, the H760 also has an Elantech touchpad with the same quirks. Without this patch, the touchpad is useless out-of-the-box as the mouse pointer won't move. This patch makes the driver aware of both the crc_enabled=1 requirement and the middle button, making the touchpad fully functional out-of-the-box. Signed-off-by: Matti Kurkela Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 91af8da4471df91ea680ec83103fcc9d5698a96c Author: Marcos Paulo de Souza Date: Sat Oct 1 12:07:35 2016 -0700 Input: i8042 - skip selftest on ASUS laptops commit 930e19248e9b61da36c967687ca79c4d5f977919 upstream. On suspend/resume cycle, selftest is executed to reset i8042 controller. But when this is done in Asus devices, subsequent calls to detect/init functions to elantech driver fails. Skipping selftest fixes this problem. An easier step to reproduce this problem is adding i8042.reset=1 as a kernel parameter. On Asus laptops, it'll make the system to start with the touchpad already stuck, since psmouse_probe forcibly calls the selftest function. This patch was inspired by John Hiesey's change[1], but, since this problem affects a lot of models of Asus, let's avoid running selftests on them. All models affected by this problem: A455LD K401LB K501LB K501LX R409L V502LX X302LA X450LCP X450LD X455LAB X455LDB X455LF Z450LA [1]: https://marc.info/?l=linux-input&m=144312209020616&w=2 Fixes: "ETPS/2 Elantech Touchpad dies after resume from suspend" (https://bugzilla.kernel.org/show_bug.cgi?id=107971) Signed-off-by: Marcos Paulo de Souza Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 75bd91f51e5e306a2c1c2fcadf5ff821c7ca34df Author: Kees Cook Date: Thu Mar 17 14:22:57 2016 -0700 lib: add "on"/"off" support to kstrtobool commit a81a5a17d44b26521fb1199f8ccf27f4af337a67 upstream. Add support for "on" and "off" when converting to boolean. Signed-off-by: Kees Cook Cc: Amitkumar Karwar Cc: Andy Shevchenko Cc: Daniel Borkmann Cc: Heiko Carstens Cc: Joe Perches Cc: Kalle Valo Cc: Martin Schwidefsky Cc: Michael Ellerman Cc: Nishant Sarmukadam Cc: Rasmus Villemoes Cc: Steve French Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 7367f9deceadab778cea65448e880ebb295fe995 Author: Kees Cook Date: Thu Mar 17 14:22:54 2016 -0700 lib: update single-char callers of strtobool() commit 1404297ebf76fd91a41de215fc8c94c2619e5fdb upstream. Some callers of strtobool() were passing a pointer to unterminated strings. In preparation of adding multi-character processing to kstrtobool(), update the callers to not pass single-character pointers, and switch to using the new kstrtobool_from_user() helper where possible. Signed-off-by: Kees Cook Cc: Amitkumar Karwar Cc: Nishant Sarmukadam Cc: Kalle Valo Cc: Steve French Cc: Andy Shevchenko Cc: Daniel Borkmann Cc: Heiko Carstens Cc: Joe Perches Cc: Kees Cook Cc: Martin Schwidefsky Cc: Michael Ellerman Cc: Rasmus Villemoes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [removed mwifiex driver change as it was correct and not needed for 4.4.y] Signed-off-by: Greg Kroah-Hartman commit e0d61779d3fe56bf139c6e4c8381d9dd3eddc1f0 Author: Kees Cook Date: Thu Mar 17 14:22:50 2016 -0700 lib: move strtobool() to kstrtobool() commit ef951599074ba4fad2d0efa0a977129b41e6d203 upstream. Create the kstrtobool_from_user() helper and move strtobool() logic into the new kstrtobool() (matching all the other kstrto* functions). Provides an inline wrapper for existing strtobool() callers. Signed-off-by: Kees Cook Cc: Joe Perches Cc: Andy Shevchenko Cc: Rasmus Villemoes Cc: Daniel Borkmann Cc: Amitkumar Karwar Cc: Nishant Sarmukadam Cc: Kalle Valo Cc: Steve French Cc: Michael Ellerman Cc: Heiko Carstens Cc: Martin Schwidefsky Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 1ea47896151dd617edb2155664f00bbe176728fd Author: Marcin Nowakowski Date: Wed Oct 12 09:32:56 2016 +0200 MIPS: ptrace: Fix regs_return_value for kernel context commit 74f1077b5b783e7bf4fa3007cefdc8dbd6c07518 upstream. Currently regs_return_value always negates reg[2] if it determines the syscall has failed, but when called in kernel context this check is invalid and may result in returning a wrong value. This fixes errors reported by CONFIG_KPROBES_SANITY_TEST Fixes: d7e7528bcd45 ("Audit: push audit success and retcode into arch ptrace.h") Signed-off-by: Marcin Nowakowski Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14381/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit 5eff24cc6eafebf194ef02225ce171649a2a675a Author: James Hogan Date: Thu Oct 6 23:10:41 2016 +0100 MIPS: Fix -mabi=64 build of vdso.lds commit 034827c727f7f3946a18355b63995b402c226c82 upstream. The native ABI vDSO linker script vdso.lds is built by preprocessing vdso.lds.S, with the native -mabi flag passed in to get the correct ABI definitions. Unfortunately however certain toolchains choke on -mabi=64 without a corresponding compatible -march flag, for example: cc1: error: ‘-march=mips32r2’ is not compatible with the selected ABI scripts/Makefile.build:338: recipe for target 'arch/mips/vdso/vdso.lds' failed Fix this by including ccflags-vdso in the KBUILD_CPPFLAGS for vdso.lds, which includes the appropriate -march flag. Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO") Signed-off-by: James Hogan Reviewed-by: Maciej W. Rozycki Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14368/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit b3f1735ba466d2fc38ebc6c750ed2cade16dee2d Author: Hui Wang Date: Tue Oct 11 10:48:58 2016 +0800 ALSA: hda - Fix a failure of micmute led when having multi adcs commit 4875a5f7218068cdeea5f998330dfa3d118b2fea upstream. On a Dell laptop, there is no global adcs for all input devices, so the input devices use the different adc, as a result, dyn_adc_switch is set to true. In this situation, it is safe to control the micmute led according to user's choice of muting/unmuting the current input device, since only current input device path is active, while other input device paths are inactive and powered down. Fixes: 00ef99408b6c ('ALSA: hda - add mic mute led hook for dell machines') Signed-off-by: Hui Wang Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9058e7d70cd70205a508966cd75c18fcf8745e87 Author: Mauro Carvalho Chehab Date: Sun Sep 4 10:06:39 2016 -0300 cx231xx: fix GPIOs for Pixelview SBTVD hybrid commit 24b923f073ac37eb744f56a2c7f77107b8219ab2 upstream. This device uses GPIOs: 28 to switch between analog and digital modes: on digital mode, it should be set to 1. The code that sets it on analog mode is OK, but it misses the logic that sets it on digital mode. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 5fecc841270529852514709c091cddc8243f0c05 Author: Mauro Carvalho Chehab Date: Sun Sep 4 09:56:33 2016 -0300 cx231xx: don't return error on success commit 1871d718a9db649b70f0929d2778dc01bc49b286 upstream. The cx231xx_set_agc_analog_digital_mux_select() callers expect it to return 0 or an error. Returning a positive value makes the first attempt to switch between analog/digital to fail. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 68bf9d10b0f0248d44e62d38d4e7a8fc5b409599 Author: Mauro Carvalho Chehab Date: Sun Sep 4 10:43:53 2016 -0300 mb86a20s: fix demod settings commit 505a0ea706fc1db4381baa6c6bd2e596e730a55e upstream. With the current settings, only one channel locks properly. That's likely because, when this driver was written, Brazil were still using experimental transmissions. Change it to reproduce the settings used by the newer drivers. That makes it lock on other channels. Tested with both PixelView SBTVD Hybrid (cx231xx-based) and C3Tech Digital Duo HDTV/SDTV (em28xx-based) devices. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 177251ecc6f4c62986bf326c6505dd9caef1d1ea Author: Mauro Carvalho Chehab Date: Sun Sep 4 10:16:18 2016 -0300 mb86a20s: fix the locking logic commit dafb65fb98d85d8e78405e82c83e81975e5d5480 upstream. On this frontend, it takes a while to start output normal TS data. That only happens on state S9. On S8, the TS output is enabled, but it is not reliable enough. However, the zigzag loop is too fast to let it sync. As, on practical tests, the zigzag software loop doesn't seem to be helping, but just slowing down the tuning, let's switch to hardware algorithm, as the tuners used on such devices are capable of work with frequency drifts without any help from software. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 714ac6de4454bd134f5bc0777e2bc7c5c50629db Author: Miklos Szeredi Date: Fri Sep 16 14:12:11 2016 +0200 ovl: copy_up_xattr(): use strnlen commit 8b326c61de08f5ca4bc454a168f19e7e43c4cc2a upstream. Be defensive about what underlying fs provides us in the returned xattr list buffer. strlen() may overrun the buffer, so use strnlen() and WARN if the contents are not properly null terminated. Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 0a5600d83fa5a251c91459779d5311a005e4c5b3 Author: Richard Weinberger Date: Fri Sep 16 11:45:24 2016 +0200 ovl: Fix info leak in ovl_lookup_temp() commit 6a45b3628ce4dcf7498b39c87d475bab6e2a9b24 upstream. The function uses the memory address of a struct dentry as unique id. While the address-based directory entry is only visible to root it is IMHO still worth fixing since the temporary name does not have to be a kernel address. It can be any unique number. Replace it by an atomic integer which is allowed to wrap around. Signed-off-by: Richard Weinberger Reviewed-by: Kees Cook Signed-off-by: Miklos Szeredi Fixes: e9be9d5e76e3 ("overlay filesystem") Signed-off-by: Greg Kroah-Hartman commit 2add76a428bc6b9e4506d9caa4f8ced9b8bdcb70 Author: Max Staudt Date: Mon Jun 13 19:15:59 2016 +0200 fbdev/efifb: Fix 16 color palette entry calculation commit d50b3f43db739f03fcf8c0a00664b3d2fed0496e upstream. When using efifb with a 16-bit (5:6:5) visual, fbcon's text is rendered in the wrong colors - e.g. text gray (#aaaaaa) is rendered as green (#50bc50) and neighboring pixels have slightly different values (such as #50bc78). The reason is that fbcon loads its 16 color palette through efifb_setcolreg(), which in turn calculates a 32-bit value to write into memory for each palette index. Until now, this code could only handle 8-bit visuals and didn't mask overlapping values when ORing them. With this patch, fbcon displays the correct colors when a qemu VM is booted in 16-bit mode (in GRUB: "set gfxpayload=800x600x16"). Fixes: 7c83172b98e5 ("x86_64 EFI boot support: EFI frame buffer driver") # v2.6.24+ Signed-off-by: Max Staudt Acked-By: Peter Jones Signed-off-by: Tomi Valkeinen Signed-off-by: Greg Kroah-Hartman commit 63411d98626c04139d801465597431ad16c6cf36 Author: Dan Carpenter Date: Fri Oct 14 16:18:39 2016 -0400 scsi: zfcp: spin_lock_irqsave() is not nestable commit e7cb08e894a0b876443ef8fdb0706575dc00a5d2 upstream. We accidentally overwrite the original saved value of "flags" so that we can't re-enable IRQs at the end of the function. Presumably this function is mostly called with IRQs disabled or it would be obvious in testing. Fixes: aceeffbb59bb ("zfcp: trace full payload of all SAN records (req,resp,iels)") Signed-off-by: Dan Carpenter Signed-off-by: Steffen Maier Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 84386a526e81745d019fc402165edf5fbaa9fa83 Author: Steffen Maier Date: Wed Aug 10 18:30:53 2016 +0200 zfcp: trace full payload of all SAN records (req,resp,iels) commit aceeffbb59bb91404a0bda32a542d7ebf878433a upstream. This was lost with commit 2c55b750a884b86dea8b4cc5f15e1484cc47a25c ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.") but is necessary for problem determination, e.g. to see the currently active zone set during automatic port scan. For the large GPN_FT response (4 pages), save space by not dumping any empty residual entries. Signed-off-by: Steffen Maier Fixes: 2c55b750a884 ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.") Reviewed-by: Alexey Ishchuk Reviewed-by: Benjamin Block Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 918637a5c0d33d0107d9966b31e5c814fc710cbb Author: Steffen Maier Date: Wed Aug 10 18:30:52 2016 +0200 zfcp: fix payload trace length for SAN request&response commit 94db3725f049ead24c96226df4a4fb375b880a77 upstream. commit 2c55b750a884b86dea8b4cc5f15e1484cc47a25c ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.") started to add FC_CT_HDR_LEN which made zfcp dump random data out of bounds for RSPN GS responses because u.rspn.rsp is the largest and last field in the union of struct zfcp_fc_req. Other request/response types only happened to stay within bounds due to the padding of the union or due to the trace capping of u.gspn.rsp to ZFCP_DBF_SAN_MAX_PAYLOAD. Timestamp : ... Area : SAN Subarea : 00 Level : 1 Exception : - CPU id : .. Caller : ... Record id : 2 Tag : fsscth2 Request id : 0x... Destination ID : 0x00fffffc Payload short : 01000000 fc020000 80020000 00000000 xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx <=== 00000000 00000000 00000000 00000000 Payload length : 32 <=== struct zfcp_fc_req { [0] struct zfcp_fsf_ct_els ct_els; [56] struct scatterlist sg_req; [96] struct scatterlist sg_rsp; union { struct {req; rsp;} adisc; SIZE: 28+28= 56 struct {req; rsp;} gid_pn; SIZE: 24+20= 44 struct {rspsg; req;} gpn_ft; SIZE: 40*4+20=180 struct {req; rsp;} gspn; SIZE: 20+273= 293 struct {req; rsp;} rspn; SIZE: 277+16= 293 [136] } u; } SIZE: 432 Signed-off-by: Steffen Maier Fixes: 2c55b750a884 ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.") Reviewed-by: Alexey Ishchuk Reviewed-by: Benjamin Block Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 3125f1f4908634e514c3a2d3d40f471c969c1716 Author: Steffen Maier Date: Wed Aug 10 18:30:51 2016 +0200 zfcp: fix D_ID field with actual value on tracing SAN responses commit 771bf03537ddfa4a4dde62ef9dfbc82e4f77ab20 upstream. With commit 2c55b750a884b86dea8b4cc5f15e1484cc47a25c ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.") we lost the N_Port-ID where an ELS response comes from. With commit 7c7dc196814b9e1d5cc254dc579a5fa78ae524f7 ("[SCSI] zfcp: Simplify handling of ct and els requests") we lost the N_Port-ID where a CT response comes from. It's especially useful if the request SAN trace record with D_ID was already lost due to trace buffer wrap. GS uses an open WKA port handle and ELS just a D_ID, and only for ELS we could get D_ID from QTCB bottom via zfcp_fsf_req. To cover both cases, add a new field to zfcp_fsf_ct_els and fill it in on request to use in SAN response trace. Strictly speaking the D_ID on SAN response is the FC frame's S_ID. We don't need a field for the other end which is always us. Signed-off-by: Steffen Maier Fixes: 2c55b750a884 ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.") Fixes: 7c7dc196814b ("[SCSI] zfcp: Simplify handling of ct and els requests") Reviewed-by: Benjamin Block Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit aab264b6e353fc75faeeb46b151efedbabfb6d40 Author: Steffen Maier Date: Wed Aug 10 18:30:50 2016 +0200 zfcp: restore tracing of handle for port and LUN with HBA records commit 7c964ffe586bc0c3d9febe9bf97a2e4b2866e5b7 upstream. This information was lost with commit a54ca0f62f953898b05549391ac2a8a4dad6482b ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.") but is required to debug e.g. invalid handle situations. Signed-off-by: Steffen Maier Fixes: a54ca0f62f95 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.") Reviewed-by: Benjamin Block Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit b5752b0db014046e4733737a1f82ea24067ec0ff Author: Steffen Maier Date: Wed Aug 10 18:30:49 2016 +0200 zfcp: trace on request for open and close of WKA port commit d27a7cb91960cf1fdd11b10071e601828cbf4b1f upstream. Since commit a54ca0f62f953898b05549391ac2a8a4dad6482b ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.") HBA records no longer contain WWPN, D_ID, or LUN to reduce duplicate information which is already in REC records. In contrast to "regular" target ports, we don't use recovery to open WKA ports such as directory/nameserver, so we don't get REC records. Therefore, introduce pseudo REC running records without any actual recovery action but including D_ID of WKA port on open/close. Signed-off-by: Steffen Maier Fixes: a54ca0f62f95 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.") Reviewed-by: Benjamin Block Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit f9fbf66c6de9b133f572234df7b3adeed57260ea Author: Steffen Maier Date: Wed Aug 10 18:30:48 2016 +0200 zfcp: restore: Dont use 0 to indicate invalid LUN in rec trace commit 0102a30a6ff60f4bb4c07358ca3b1f92254a6c25 upstream. bring back commit d21e9daa63e009ce5b87bbcaa6d11ce48e07bbbe ("[SCSI] zfcp: Dont use 0 to indicate invalid LUN in rec trace") which was lost with commit ae0904f60fab7cb20c48d32eefdd735e478b91fb ("[SCSI] zfcp: Redesign of the debug tracing for recovery actions.") Signed-off-by: Steffen Maier Fixes: ae0904f60fab ("[SCSI] zfcp: Redesign of the debug tracing for recovery actions.") Reviewed-by: Benjamin Block Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 31eaad72448a39c01056041f20010bcb575e97e4 Author: Steffen Maier Date: Wed Aug 10 18:30:47 2016 +0200 zfcp: retain trace level for SCSI and HBA FSF response records commit 35f040df97fa0e94c7851c054ec71533c88b4b81 upstream. While retaining the actual filtering according to trace level, the following commits started to write such filtered records with a hardcoded record level of 1 instead of the actual record level: commit 250a1352b95e1db3216e5c5d4f4365bea5122f4a ("[SCSI] zfcp: Redesign of the debug tracing for SCSI records.") commit a54ca0f62f953898b05549391ac2a8a4dad6482b ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.") Now we can distinguish written records again for offline level filtering. Signed-off-by: Steffen Maier Fixes: 250a1352b95e ("[SCSI] zfcp: Redesign of the debug tracing for SCSI records.") Fixes: a54ca0f62f95 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.") Reviewed-by: Benjamin Block Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit a01fae0faf1dd6819c67873a73ee1635df163742 Author: Steffen Maier Date: Wed Aug 10 18:30:46 2016 +0200 zfcp: close window with unblocked rport during rport gone commit 4eeaa4f3f1d6c47b69f70e222297a4df4743363e upstream. On a successful end of reopen port forced, zfcp_erp_strategy_followup_success() re-uses the port erp_action and the subsequent zfcp_erp_action_cleanup() now sees ZFCP_ERP_SUCCEEDED with erp_action->action==ZFCP_ERP_ACTION_REOPEN_PORT instead of ZFCP_ERP_ACTION_REOPEN_PORT_FORCED but must not perform zfcp_scsi_schedule_rport_register(). We can detect this because the fresh port reopen erp_action is in its very first step ZFCP_ERP_STEP_UNINITIALIZED. Otherwise this opens a time window with unblocked rport (until the followup port reopen recovery would block it again). If a scsi_cmnd timeout occurs during this time window fc_timed_out() cannot work as desired and such command would indeed time out and trigger scsi_eh. This prevents a clean and timely path failover. This should not happen if the path issue can be recovered on FC transport layer such as path issues involving RSCNs. Also, unnecessary and repeated DID_IMM_RETRY for pending and undesired new requests occur because internally zfcp still has its zfcp_port blocked. As follow-on errors with scsi_eh, it can cause, in the worst case, permanently lost paths due to one of: sd : [] Medium access timeout failure. Offlining disk! sd : Device offlined - not ready after error recovery For fix validation and to aid future debugging with other recoveries we now also trace (un)blocking of rports. Signed-off-by: Steffen Maier Fixes: 5767620c383a ("[SCSI] zfcp: Do not unblock rport from REOPEN_PORT_FORCED") Fixes: a2fa0aede07c ("[SCSI] zfcp: Block FC transport rports early on errors") Fixes: 5f852be9e11d ("[SCSI] zfcp: Fix deadlock between zfcp ERP and SCSI") Fixes: 338151e06608 ("[SCSI] zfcp: make use of fc_remote_port_delete when target port is unavailable") Fixes: 3859f6a248cb ("[PATCH] zfcp: add rports to enable scsi_add_device to work again") Reviewed-by: Benjamin Block Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit c9f34228ac085b7ecb680e7b5d4f4d807feb3b48 Author: Steffen Maier Date: Wed Aug 10 18:30:45 2016 +0200 zfcp: fix ELS/GS request&response length for hardware data router commit 70369f8e15b220f50a16348c79a61d3f7054813c upstream. In the hardware data router case, introduced with kernel 3.2 commit 86a9668a8d29 ("[SCSI] zfcp: support for hardware data router") the ELS/GS request&response length needs to be initialized as in the chained SBAL case. Otherwise, the FCP channel rejects ELS requests with FSF_REQUEST_SIZE_TOO_LARGE. Such ELS requests can be issued by user space through BSG / HBA API, or zfcp itself uses ADISC ELS for remote port link test on RSCN. The latter can cause a short path outage due to unnecessary remote target port recovery because the always failing ADISC cannot detect extremely short path interruptions beyond the local FCP channel. Below example is decoded with zfcpdbf from s390-tools: Timestamp : ... Area : SAN Subarea : 00 Level : 1 Exception : - CPU id : .. Caller : zfcp_dbf_san_req+0408 Record id : 1 Tag : fssels1 Request id : 0x Destination ID : 0x00 Payload info : 52000000 00000000 [ADISC] 00 00000000 00000000 00000000 00000000 00000000 Timestamp : ... Area : HBA Subarea : 00 Level : 1 Exception : - CPU id : .. Caller : zfcp_dbf_hba_fsf_res+0740 Record id : 1 Tag : fs_ferr Request id : 0x Request status : 0x00000010 FSF cmnd : 0x0000000b [FSF_QTCB_SEND_ELS] FSF sequence no: 0x... FSF issued : ... FSF stat : 0x00000061 [FSF_REQUEST_SIZE_TOO_LARGE] FSF stat qual : 00000000 00000000 00000000 00000000 Prot stat : 0x00000100 Prot stat qual : 00000000 00000000 00000000 00000000 Signed-off-by: Steffen Maier Fixes: 86a9668a8d29 ("[SCSI] zfcp: support for hardware data router") Reviewed-by: Benjamin Block Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 4abdfdd09e4991b705326399e5bcd436e969e196 Author: Steffen Maier Date: Wed Aug 10 18:30:44 2016 +0200 zfcp: fix fc_host port_type with NPIV commit bd77befa5bcff8c51613de271913639edf85fbc2 upstream. For an NPIV-enabled FCP device, zfcp can erroneously show "NPort (fabric via point-to-point)" instead of "NPIV VPORT" for the port_type sysfs attribute of the corresponding fc_host. s390-tools that can be affected are dbginfo.sh and ziomon. zfcp_fsf_exchange_config_evaluate() ignores fsf_qtcb_bottom_config.connection_features indicating NPIV and only sets fc_host_port_type to FC_PORTTYPE_NPORT if fsf_qtcb_bottom_config.fc_topology is FSF_TOPO_FABRIC. Only the independent zfcp_fsf_exchange_port_evaluate() evaluates connection_features to overwrite fc_host_port_type to FC_PORTTYPE_NPIV in case of NPIV. Code was introduced with upstream kernel 2.6.30 commit 0282985da5923fa6365adcc1a1586ae0c13c1617 ("[SCSI] zfcp: Report fc_host_port_type as NPIV"). This works during FCP device recovery (such as set online) because it performs FSF_QTCB_EXCHANGE_CONFIG_DATA followed by FSF_QTCB_EXCHANGE_PORT_DATA in sequence. However, the zfcp-specific scsi host sysfs attributes "requests", "megabytes", or "seconds_active" trigger only zfcp_fsf_exchange_config_evaluate() resetting fc_host port_type to FC_PORTTYPE_NPORT despite NPIV. The zfcp-specific scsi host sysfs attribute "utilization" triggers only zfcp_fsf_exchange_port_evaluate() correcting the fc_host port_type again in case of NPIV. Evaluate fsf_qtcb_bottom_config.connection_features in zfcp_fsf_exchange_config_evaluate() where it belongs to. Signed-off-by: Steffen Maier Fixes: 0282985da592 ("[SCSI] zfcp: Report fc_host_port_type as NPIV") Reviewed-by: Benjamin Block Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 7f2e25fa12421e6d3c4d192e4115673d8493f58d Author: Richard Weinberger Date: Wed Aug 24 14:36:13 2016 +0200 ubi: Deal with interrupted erasures in WL commit 2365418879e9abf12ea9def7f9f3caf0dfa7ffb0 upstream. When Fastmap is used we can face here an -EBADMSG since Fastmap cannot know about unmaps. If the erasure was interrupted the PEB may show ECC errors and UBI would go to ro-mode as it assumes that the PEB was check during attach time, which is not the case with Fastmap. Fixes: dbb7d2a88d ("UBI: Add fastmap core") Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit b57af607da42ca00914fecfe4bdf3d163e333093 Author: Laurent Dufour Date: Thu Oct 6 15:33:21 2016 +0200 powerpc/pseries: Fix stack corruption in htpe code commit 05af40e885955065aee8bb7425058eb3e1adca08 upstream. This commit fixes a stack corruption in the pseries specific code dealing with the huge pages. In __pSeries_lpar_hugepage_invalidate() the buffer used to pass arguments to the hypervisor is not large enough. This leads to a stack corruption where a previously saved register could be corrupted leading to unexpected result in the caller, like the following panic: Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=2048 NUMA pSeries Modules linked in: virtio_balloon ip_tables x_tables autofs4 virtio_blk 8139too virtio_pci virtio_ring 8139cp virtio CPU: 11 PID: 1916 Comm: mmstress Not tainted 4.8.0 #76 task: c000000005394880 task.stack: c000000005570000 NIP: c00000000027bf6c LR: c00000000027bf64 CTR: 0000000000000000 REGS: c000000005573820 TRAP: 0300 Not tainted (4.8.0) MSR: 8000000000009033 CR: 84822884 XER: 20000000 CFAR: c00000000010a924 DAR: 420000000014e5e0 DSISR: 40000000 SOFTE: 1 GPR00: c00000000027bf64 c000000005573aa0 c000000000e02800 c000000004447964 GPR04: c00000000404de18 c000000004d38810 00000000042100f5 00000000f5002104 GPR08: e0000000f5002104 0000000000000001 042100f5000000e0 00000000042100f5 GPR12: 0000000000002200 c00000000fe02c00 c00000000404de18 0000000000000000 GPR16: c1ffffffffffe7ff 00003fff62000000 420000000014e5e0 00003fff63000000 GPR20: 0008000000000000 c0000000f7014800 0405e600000000e0 0000000000010000 GPR24: c000000004d38810 c000000004447c10 c00000000404de18 c000000004447964 GPR28: c000000005573b10 c000000004d38810 00003fff62000000 420000000014e5e0 NIP [c00000000027bf6c] zap_huge_pmd+0x4c/0x470 LR [c00000000027bf64] zap_huge_pmd+0x44/0x470 Call Trace: [c000000005573aa0] [c00000000027bf64] zap_huge_pmd+0x44/0x470 (unreliable) [c000000005573af0] [c00000000022bbd8] unmap_page_range+0xcf8/0xed0 [c000000005573c30] [c00000000022c2d4] unmap_vmas+0x84/0x120 [c000000005573c80] [c000000000235448] unmap_region+0xd8/0x1b0 [c000000005573d80] [c0000000002378f0] do_munmap+0x2d0/0x4c0 [c000000005573df0] [c000000000237be4] SyS_munmap+0x64/0xb0 [c000000005573e30] [c000000000009560] system_call+0x38/0x108 Instruction dump: fbe1fff8 fb81ffe0 7c7f1b78 7ca32b78 7cbd2b78 f8010010 7c9a2378 f821ffb1 7cde3378 4bfffea9 7c7b1b79 41820298 48000130 7fa5eb78 7fc4f378 Most of the time, the bug is surfacing in a caller up in the stack from __pSeries_lpar_hugepage_invalidate() which is quite confusing. This bug is pending since v3.11 but was hidden if a caller of the caller of __pSeries_lpar_hugepage_invalidate() has pushed the corruped register (r18 in this case) in the stack and is not using it until restoring it. GCC 6.2.0 seems to raise it more frequently. This commit also change the definition of the parameter buffer in pSeries_lpar_flush_hash_range() to rely on the global define PLPAR_HCALL9_BUFSIZE (no functional change here). Fixes: 1a5272866f87 ("powerpc: Optimize hugepage invalidate") Signed-off-by: Laurent Dufour Reviewed-by: Aneesh Kumar K.V Acked-by: Balbir Singh Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 800b55c471c2a3902560f40df1180092acdb53e2 Author: Paul Mackerras Date: Tue Oct 11 22:25:47 2016 +1100 powerpc/64: Fix incorrect return value from __copy_tofrom_user commit 1a34439e5a0b2235e43f96816dbb15ee1154f656 upstream. Debugging a data corruption issue with virtio-net/vhost-net led to the observation that __copy_tofrom_user was occasionally returning a value 16 larger than it should. Since the return value from __copy_tofrom_user is the number of bytes not copied, this means that __copy_tofrom_user can occasionally return a value larger than the number of bytes it was asked to copy. In turn this can cause higher-level copy functions such as copy_page_to_iter_iovec to corrupt memory by copying data into the wrong memory locations. It turns out that the failing case involves a fault on the store at label 79, and at that point the first unmodified byte of the destination is at R3 + 16. Consequently the exception handler for that store needs to add 16 to R3 before using it to work out how many bytes were not copied, but in this one case it was not adding the offset to R3. To fix it, this moves the label 179 to the point where we add 16 to R3. I have checked manually all the exception handlers for the loads and stores in this code and the rest of them are correct (it would be excellent to have an automated test of all the exception cases). This bug has been present since this code was initially committed in May 2002 to Linux version 2.5.20. Signed-off-by: Paul Mackerras Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 8f7929ce0c85c9a77b4845b992920e4f800264c8 Author: Gavin Shan Date: Tue Aug 2 14:10:32 2016 +1000 powerpc/powernv: Use CPU-endian PEST in pnv_pci_dump_p7ioc_diag_data() commit 5adaf8629b193f185ca5a1665b9e777a0579f518 upstream. This fixes the warnings reported from sparse: pci.c:312:33: warning: restricted __be64 degrades to integer pci.c:313:33: warning: restricted __be64 degrades to integer Fixes: cee72d5bb489 ("powerpc/powernv: Display diag data on p7ioc EEH errors") Signed-off-by: Gavin Shan Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 450a3ad8669572523e8e08d1dba993a2ab013301 Author: Gavin Shan Date: Tue Aug 2 14:10:30 2016 +1000 powerpc/powernv: Use CPU-endian hub diag-data type in pnv_eeh_get_and_dump_hub_diag() commit a7032132d7560a8434e1f54b71efd7fa20f073bd upstream. The hub diag-data type is filled with big-endian data by OPAL call opal_pci_get_hub_diag_data(). We need convert it to CPU-endian value before using it. The issue is reported by sparse as pointed by Michael Ellerman: eeh-powernv.c:1309:21: warning: restricted __be16 degrades to integer This converts hub diag-data type to CPU-endian before using it in pnv_eeh_get_and_dump_hub_diag(). Fixes: 2a485ad7c88d ("powerpc/powernv: Drop PHB operation next_error()") Suggested-by: Michael Ellerman Signed-off-by: Gavin Shan Reviewed-by: Russell Currey Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit f0a933ef44629a754aadd9de46b57513291a956a Author: Gavin Shan Date: Tue Aug 2 14:10:29 2016 +1000 powerpc/powernv: Pass CPU-endian PE number to opal_pci_eeh_freeze_clear() commit d63e51b31e0b655ed0f581b8a8fd4c4b4f8d1919 upstream. The PE number (@frozen_pe_no), filled by opal_pci_next_error() is in big-endian format. It should be converted to CPU-endian before it is passed to opal_pci_eeh_freeze_clear() when clearing the frozen state if the PE is invalid one. As Michael Ellerman pointed out, the issue is also detected by sparse: eeh-powernv.c:1541:41: warning: incorrect type in argument 2 (different base types) This passes CPU-endian PE number to opal_pci_eeh_freeze_clear() and it should be part of commit <0f36db77643b> ("powerpc/eeh: Fix wrong printed PE number"), which was merged to 4.3 kernel. Fixes: 71b540adffd9 ("powerpc/powernv: Don't escalate non-existing frozen PE") Suggested-by: Paul Mackerras Signed-off-by: Gavin Shan Reviewed-by: Russell Currey Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 74c77018155818fbffd2120a4a8785da2688d09f Author: Anton Blanchard Date: Sun Sep 25 17:16:53 2016 +1000 powerpc/vdso64: Use double word compare on pointers commit 5045ea37377ce8cca6890d32b127ad6770e6dce5 upstream. __kernel_get_syscall_map() and __kernel_clock_getres() use cmpli to check if the passed in pointer is non zero. cmpli maps to a 32 bit compare on binutils, so we ignore the top 32 bits. A simple test case can be created by passing in a bogus pointer with the bottom 32 bits clear. Using a clk_id that is handled by the VDSO, then one that is handled by the kernel shows the problem: printf("%d\n", clock_getres(CLOCK_REALTIME, (void *)0x100000000)); printf("%d\n", clock_getres(CLOCK_BOOTTIME, (void *)0x100000000)); And we get: 0 -1 The bigger issue is if we pass a valid pointer with the bottom 32 bits clear, in this case we will return success but won't write any data to the pointer. I stumbled across this issue because the LLVM integrated assembler doesn't accept cmpli with 3 arguments. Fix this by converting them to cmpldi. Fixes: a7f290dad32e ("[PATCH] powerpc: Merge vdso's and add vdso support to 32 bits kernel") Signed-off-by: Anton Blanchard Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit a35c9d6749dbe79ab327c27ac411b0dfe6b5c5b5 Author: Rabin Vincent Date: Wed Sep 21 16:22:29 2016 +0200 dm crypt: fix crash on exit commit f659b10087daaf4ce0087c3f6aec16746be9628f upstream. As the documentation for kthread_stop() says, "if threadfn() may call do_exit() itself, the caller must ensure task_struct can't go away". dm-crypt does not ensure this and therefore crashes when crypt_dtr() calls kthread_stop(). The crash is trivially reproducible by adding a delay before the call to kthread_stop() and just opening and closing a dm-crypt device. general protection fault: 0000 [#1] PREEMPT SMP CPU: 0 PID: 533 Comm: cryptsetup Not tainted 4.8.0-rc7+ #7 task: ffff88003bd0df40 task.stack: ffff8800375b4000 RIP: 0010: kthread_stop+0x52/0x300 Call Trace: crypt_dtr+0x77/0x120 dm_table_destroy+0x6f/0x120 __dm_destroy+0x130/0x250 dm_destroy+0x13/0x20 dev_remove+0xe6/0x120 ? dev_suspend+0x250/0x250 ctl_ioctl+0x1fc/0x530 ? __lock_acquire+0x24f/0x1b10 dm_ctl_ioctl+0x13/0x20 do_vfs_ioctl+0x91/0x6a0 ? ____fput+0xe/0x10 ? entry_SYSCALL_64_fastpath+0x5/0xbd ? trace_hardirqs_on_caller+0x151/0x1e0 SyS_ioctl+0x41/0x70 entry_SYSCALL_64_fastpath+0x1f/0xbd This problem was introduced by bcbd94ff481e ("dm crypt: fix a possible hang due to race condition on exit"). Looking at the description of that patch (excerpted below), it seems like the problem it addresses can be solved by just using set_current_state instead of __set_current_state, since we obviously need the memory barrier. | dm crypt: fix a possible hang due to race condition on exit | | A kernel thread executes __set_current_state(TASK_INTERRUPTIBLE), | __add_wait_queue, spin_unlock_irq and then tests kthread_should_stop(). | It is possible that the processor reorders memory accesses so that | kthread_should_stop() is executed before __set_current_state(). If | such reordering happens, there is a possible race on thread | termination: [...] So this patch just reverts the aforementioned patch and changes the __set_current_state(TASK_INTERRUPTIBLE) to set_current_state(...). This fixes the crash and should also fix the potential hang. Fixes: bcbd94ff481e ("dm crypt: fix a possible hang due to race condition on exit") Cc: Mikulas Patocka Signed-off-by: Rabin Vincent Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 293441e493cc35e8f3a0a9d79ca3cdd29bfd1afe Author: Mike Snitzer Date: Thu Sep 1 12:06:37 2016 -0400 dm mpath: check if path's request_queue is dying in activate_path() commit f10e06b744074824fb8ec7066bc03ecc90918f5b upstream. If pg_init_retries is set and a request is queued against a multipath device with all underlying block device request_queues in the "dying" state then an infinite loop is triggered because activate_path() never succeeds and hence never calls pg_init_done(). This change avoids that device removal triggers an infinite loop by failing the activate_path() which causes the "dying" path to be failed. Reported-by: Bart Van Assche Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit bf74a108c67947a2c72d16786338b89d75119a48 Author: Minfei Huang Date: Tue Sep 6 16:00:29 2016 +0800 dm: return correct error code in dm_resume()'s retry loop commit 8dc23658b7aaa8b6b0609c81c8ad75e98b612801 upstream. dm_resume() will return success (0) rather than -EINVAL if !dm_suspended_md() upon retry within dm_resume(). Reset the error code at the start of dm_resume()'s retry loop. Also, remove a useless assignment at the end of dm_resume(). Fixes: ffcc393641 ("dm: enhance internal suspend and resume interface") Signed-off-by: Minfei Huang Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 90be7f1538fb0ab22582f018e42115f18315eb8d Author: Bart Van Assche Date: Wed Aug 31 15:17:49 2016 -0700 dm: mark request_queue dead before destroying the DM device commit 3b785fbcf81c3533772c52b717f77293099498d3 upstream. This avoids that new requests are queued while __dm_destroy() is in progress. Signed-off-by: Bart Van Assche Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit b1d528d09048ef2ee2621544e115659f86031951 Author: Adrian Hunter Date: Wed Sep 28 14:41:36 2016 +0300 perf intel-pt: Fix MTC timestamp calculation for large MTC periods commit 3bccbe20f6d188ce7b00326e776b745cfd35b10a upstream. The MTC packet provides a 8-bit slice of CTC which is related to TSC by the TMA packet, however the TMA packet only provides the lower 16 bits of CTC. If mtc_shift > 8 then some of the MTC bits are not in the CTC provided by the TMA packet. Fix-up the last_mtc calculated from the TMA packet by copying the missing bits from the current MTC assuming the least difference between the two, and that the current MTC comes after last_mtc. Signed-off-by: Adrian Hunter Cc: Jiri Olsa Link: http://lkml.kernel.org/r/1475062896-22274-2-git-send-email-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit d04565939ca6f34097e1bc21f3c01e8e1131291f Author: Adrian Hunter Date: Wed Sep 28 14:41:35 2016 +0300 perf intel-pt: Fix estimated timestamps for cycle-accurate mode commit 51ee6481fa8e879cc942bcc1b0af713e158b7a98 upstream. In cycle-accurate mode, timestamps can be calculated from CYC packets. The decoder also estimates timestamps based on the number of instructions since the last timestamp. For that to work in cycle-accurate mode, the instruction count needs to be reset to zero when a timestamp is calculated from a CYC packet, but that wasn't happening, so fix it. Signed-off-by: Adrian Hunter Cc: Jiri Olsa Link: http://lkml.kernel.org/r/1475062896-22274-1-git-send-email-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 0ea2bdfcdd0e10783a6f5bd0834934e506ec3b65 Author: Adrian Hunter Date: Fri Sep 23 17:38:41 2016 +0300 perf intel-pt: Fix snapshot overlap detection decoder errors commit 810c398bc09b2f2dfde52a7d2483a710612c5fb8 upstream. Fix occasional decoder errors decoding trace data collected in snapshot mode. Snapshot mode can take successive snapshots of trace which might overlap. The decoder checks whether there is an overlap but only looks at the current and previous buffer. However buffers that do not contain synchronization (i.e. PSB) packets cannot be decoded or used for overlap checking. That means the decoder actually needs to check overlaps between the current buffer and the previous buffer that contained usable data. Make that change. Signed-off-by: Adrian Hunter Cc: Jiri Olsa Cc: Masami Hiramatsu Cc: Mathieu Poirier Link: http://lkml.kernel.org/r/1474641528-18776-10-git-send-email-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 987ec3eb8f6360d43be358ebb9e350114bc78a32 Author: Andrew Bresticker Date: Mon Feb 15 09:19:49 2016 +0100 pstore/ram: Use memcpy_fromio() to save old buffer commit d771fdf94180de2bd811ac90cba75f0f346abf8d upstream. The ramoops buffer may be mapped as either I/O memory or uncached memory. On ARM64, this results in a device-type (strongly-ordered) mapping. Since unnaligned accesses to device-type memory will generate an alignment fault (regardless of whether or not strict alignment checking is enabled), it is not safe to use memcpy(). memcpy_fromio() is guaranteed to only use aligned accesses, so use that instead. Signed-off-by: Andrew Bresticker Signed-off-by: Enric Balletbo Serra Reviewed-by: Puneet Kumar Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman commit 93a6ca7f6d02c7ffd49af699c874977872000e18 Author: Furquan Shaikh Date: Mon Feb 15 09:19:48 2016 +0100 pstore/ram: Use memcpy_toio instead of memcpy commit 7e75678d23167c2527e655658a8ef36a36c8b4d9 upstream. persistent_ram_update uses vmap / iomap based on whether the buffer is in memory region or reserved region. However, both map it as non-cacheable memory. For armv8 specifically, non-cacheable mapping requests use a memory type that has to be accessed aligned to the request size. memcpy() doesn't guarantee that. Signed-off-by: Furquan Shaikh Signed-off-by: Enric Balletbo Serra Reviewed-by: Aaron Durbin Reviewed-by: Olof Johansson Tested-by: Furquan Shaikh Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman commit 8a3a5110c3a4cb312673bc5dea27d581629c7b4d Author: Sebastian Andrzej Siewior Date: Thu Sep 8 13:48:06 2016 +0200 pstore/core: drop cmpxchg based updates commit d5a9bf0b38d2ac85c9a693c7fb851f74fd2a2494 upstream. I have here a FPGA behind PCIe which exports SRAM which I use for pstore. Now it seems that the FPGA no longer supports cmpxchg based updates and writes back 0xff…ff and returns the same. This leads to crash during crash rendering pstore useless. Since I doubt that there is much benefit from using cmpxchg() here, I am dropping this atomic access and use the spinlock based version. Cc: Anton Vorontsov Cc: Colin Cross Cc: Kees Cook Cc: Tony Luck Cc: Rabin Vincent Tested-by: Rabin Vincent Signed-off-by: Sebastian Andrzej Siewior Reviewed-by: Guenter Roeck [kees: remove "_locked" suffix since it's the only option now] Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman commit 6ae56031f17d04ebcf380fd1c074b7c352d4ac26 Author: Sebastian Andrzej Siewior Date: Thu Sep 8 13:48:05 2016 +0200 pstore/ramoops: fixup driver removal commit 4407de74df18ed405cc5998990004c813ccfdbde upstream. A basic rmmod ramoops segfaults. Let's see why. Since commit 34f0ec82e0a9 ("pstore: Correct the max_dump_cnt clearing of ramoops") sets ->max_dump_cnt to zero before looping over ->przs but we didn't use it before that either. And since commit ee1d267423a1 ("pstore: add pstore unregister") we free that memory on rmmod. But even then, we looped until a NULL pointer or ERR. I don't see where it is ensured that the last member is NULL. Let's try this instead: simply error recovery and free. Clean up in error case where resources were allocated. And then, in the free path, rely on ->max_dump_cnt in the free path. Cc: Anton Vorontsov Cc: Colin Cross Cc: Kees Cook Cc: Tony Luck Cc: Namhyung Kim Acked-by: Namhyung Kim Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman commit e3fffa6705e0995c1e4e74bd25aab3a3ca6ce708 Author: Helge Deller Date: Sun Oct 9 09:57:54 2016 +0200 parisc: Increase initial kernel mapping size commit 65bf34f59594c11f13d371c5334a6a0a385cd7ae upstream. Increase the initial kernel default page mapping size for 64-bit kernels to 64 MB and for 32-bit kernels to 32 MB. Due to the additional support of ftrace, tracepoint and huge pages the kernel size can exceed the sizes we used up to now. Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 59db586d09cd1a511270e5f21ed5aa8c0b5570b3 Author: Helge Deller Date: Sun Oct 9 11:12:34 2016 +0200 parisc: Fix kernel memory layout regarding position of __gp commit f8850abb7ba68229838014b3409460e576751c6d upstream. Architecturally we need to keep __gp below 0x1000000. But because of ftrace and tracepoint support, the RO_DATA_SECTION now gets much bigger than it was before. By moving the linkage tables before RO_DATA_SECTION we can avoid that __gp gets positioned at a too high address. Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 97ba83a01c8c835e581b1451276716d5cef48e11 Author: Helge Deller Date: Fri Oct 7 18:19:55 2016 +0200 parisc: Increase KERNEL_INITIAL_SIZE for 32-bit SMP kernels commit 690d097c00c88fa9d93d198591e184164b1d8c20 upstream. Increase the initial kernel default page mapping size for SMP kernels to 32MB and add a runtime check which panics early if the kernel is bigger than the initial mapping size. This fixes boot crashes of 32bit SMP kernels. Due to the introduction of huge page support in kernel 4.4 and it's required initial kernel layout in memory, a 32bit SMP kernel usually got bigger (in layout, not size) than 16MB. Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit d756b52c8bbe7735cc881dab46378518d2d4b1f1 Author: Srinivas Pandruvada Date: Sat Oct 8 12:42:38 2016 -0700 cpufreq: intel_pstate: Fix unsafe HWP MSR access commit f9f4872df6e1801572949f8a370c886122d4b6da upstream. This is a requirement that MSR MSR_PM_ENABLE must be set to 0x01 before reading MSR_HWP_CAPABILITIES on a given CPU. If cpufreq init() is scheduled on a CPU which is not same as policy->cpu or migrates to a different CPU before calling msr read for MSR_HWP_CAPABILITIES, it is possible that MSR_PM_ENABLE was not to set to 0x01 on that CPU. This will cause GP fault. So like other places in this path rdmsrl_on_cpu should be used instead of rdmsrl. Moreover the scope of MSR_HWP_CAPABILITIES is on per thread basis, so it should be read from the same CPU, for which MSR MSR_HWP_REQUEST is getting set. dmesg dump or warning: [ 22.014488] WARNING: CPU: 139 PID: 1 at arch/x86/mm/extable.c:50 ex_handler_rdmsr_unsafe+0x68/0x70 [ 22.014492] unchecked MSR access error: RDMSR from 0x771 [ 22.014493] Modules linked in: [ 22.014507] CPU: 139 PID: 1 Comm: swapper/0 Not tainted 4.7.5+ #1 ... ... [ 22.014516] Call Trace: [ 22.014542] [] dump_stack+0x63/0x82 [ 22.014558] [] __warn+0xcb/0xf0 [ 22.014561] [] warn_slowpath_fmt+0x4f/0x60 [ 22.014563] [] ex_handler_rdmsr_unsafe+0x68/0x70 [ 22.014564] [] fixup_exception+0x39/0x50 [ 22.014604] [] do_general_protection+0x80/0x150 [ 22.014610] [] general_protection+0x28/0x30 [ 22.014635] [] ? get_target_pstate_use_performance+0xb0/0xb0 [ 22.014642] [] ? native_read_msr+0x7/0x40 [ 22.014657] [] intel_pstate_hwp_set+0x23/0x130 [ 22.014660] [] intel_pstate_set_policy+0x1b6/0x340 [ 22.014662] [] cpufreq_set_policy+0xeb/0x2c0 [ 22.014664] [] cpufreq_init_policy+0x79/0xe0 [ 22.014666] [] ? cpufreq_update_policy+0x120/0x120 [ 22.014669] [] cpufreq_online+0x406/0x820 [ 22.014671] [] cpufreq_add_dev+0x5f/0x90 [ 22.014717] [] subsys_interface_register+0xb8/0x100 [ 22.014719] [] cpufreq_register_driver+0x14c/0x210 [ 22.014749] [] intel_pstate_init+0x39d/0x4d5 [ 22.014751] [] ? cpufreq_gov_dbs_init+0x12/0x12 Signed-off-by: Srinivas Pandruvada Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 3fc96b9e2bd08f730df18b079a2036cddab021b7 Author: Sergei Shtylyov Date: Mon Jul 4 01:04:24 2016 +0300 platform: don't return 0 from platform_get_irq[_byname]() on error commit e330b9a6bb35dc7097a4f02cb1ae7b6f96df92af upstream. of_irq_get[_byname]() return 0 iff irq_create_of_mapping() call fails. Returning both error code and 0 on failure is a sign of a misdesigned API, it makes the failure check unnecessarily complex and error prone. We should rely on the platform IRQ resource in this case, not return 0, especially as 0 can be a valid IRQ resource too... Fixes: aff008ad813c ("platform_get_irq: Revert to platform_get_resource if of_irq_get fails") Signed-off-by: Sergei Shtylyov Signed-off-by: Greg Kroah-Hartman commit e7837af6160e9b717ed12fc9fd1012e28c55e3cf Author: Maik Broemme Date: Tue Aug 9 16:41:31 2016 +0200 PCI: Mark Atheros AR9580 to avoid bus reset commit 8e2e03179923479ca0c0b6fdc7c93ecf89bce7a8 upstream. Similar to the AR93xx and the AR94xx series, the AR95xx also have the same quirk for the Bus Reset. It will lead to instant system reset if the device is assigned via VFIO to a KVM VM. I've been able reproduce this behavior with a MikroTik R11e-2HnD. Fixes: c3e59ee4e766 ("PCI: Mark Atheros AR93xx to avoid bus reset") Signed-off-by: Maik Broemme Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit 68b13e229be9368faa34ac226d647bdd7a577e31 Author: Haibo Chen Date: Mon Oct 17 10:18:37 2016 +0200 mmc: sdhci: cast unsigned int to unsigned long long to avoid unexpeted error commit 02265cd60335a2c1417abae4192611e1fc05a6e5 upstream. Potentially overflowing expression 1000000 * data->timeout_clks with type unsigned int is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type unsigned long long. To avoid overflow, cast 1000000U to type unsigned long long. Special thanks to Coverity. Fixes: 7f05538af71c ("mmc: sdhci: fix data timeout (part 2)") Signed-off-by: Haibo Chen Acked-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit bc7e4a29a556f753ed916cdd90f6f860d7d9a5cb Author: Daniel Glöckner Date: Tue Aug 30 14:17:30 2016 +0200 mmc: block: don't use CMD23 with very old MMC cards commit 0ed50abb2d8fc81570b53af25621dad560cd49b3 upstream. CMD23 aka SET_BLOCK_COUNT was introduced with MMC v3.1. Older versions of the specification allowed to terminate multi-block transfers only with CMD12. The patch fixes the following problem: mmc0: new MMC card at address 0001 mmcblk0: mmc0:0001 SDMB-16 15.3 MiB mmcblk0: timed out sending SET_BLOCK_COUNT command, card status 0x400900 ... blk_update_request: I/O error, dev mmcblk0, sector 0 Buffer I/O error on dev mmcblk0, logical block 0, async page read mmcblk0: unable to read partition table Signed-off-by: Daniel Glöckner Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 7dcd1cd07760224f046713e7234113d08f151f06 Author: Larry Finger Date: Mon Aug 22 14:27:59 2016 -0500 rtlwifi: Fix missing country code for Great Britain commit 0c9d3491530773858ff9d705ec2a9c382f449230 upstream. Some RTL8821AE devices sold in Great Britain have the country code of 0x25 encoded in their EEPROM. This value is not tested in the routine that establishes the regulatory info for the chip. The fix is to set this code to have the same capabilities as the EU countries. In addition, the channels allowed for COUNTRY_CODE_ETSI were more properly suited for China and Israel, not the EU. This problem has also been fixed. Signed-off-by: Larry Finger Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 8bfd0c41d2ed123729d30768dde2a189dc6fd181 Author: Lin Huang Date: Thu Aug 4 19:32:33 2016 +0900 PM / devfreq: event: remove duplicate devfreq_event_get_drvdata() commit c8a9a6daccad495c48d5435d3487956ce01bc6a1 upstream. there define two devfreq_event_get_drvdata() function in devfreq-event.h when disable CONFIG_PM_DEVFREQ_EVENT, it will lead to build fail. So remove devfreq_event_get_drvdata() function. Fixes: f262f28c1470 ("PM / devfreq: event: Add devfreq_event class") Signed-off-by: Lin Huang Signed-off-by: Chanwoo Choi Signed-off-by: MyungJoo Ham Signed-off-by: Greg Kroah-Hartman commit aed6dd564609e5c234f2c6c0240e873c4a7df0d7 Author: Lucas Stach Date: Fri Sep 16 11:16:11 2016 +0200 clk: imx6: initialize GPU clocks commit d8846023aed1293e54d33499558fc2aa2b2f393f upstream. Initialize the GPU clock muxes to sane inputs. Until now they have not been changed from their default values, which means that both GPU3D shader and GPU2D core were fed by clock inputs whose rates exceed the maximium allowed frequency of the cores by as much as 200MHz. This fixes a severe GPU stability issue on i.MX6DL. Signed-off-by: Lucas Stach Acked-by: Shawn Guo Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 5122ea50c63e41a2548ee9e08f343a7fb1847839 Author: Jan Remmet Date: Fri Sep 23 10:52:00 2016 +0200 regulator: tps65910: Work around silicon erratum SWCZ010 commit 8f9165c981fed187bb483de84caf9adf835aefda upstream. http://www.ti.com/lit/pdf/SWCZ010: DCDC o/p voltage can go higher than programmed value Impact: VDDI, VDD2, and VIO output programmed voltage level can go higher than expected or crash, when coming out of PFM to PWM mode or using DVFS. Description: When DCDC CLK SYNC bits are 11/01: * VIO 3-MHz oscillator is the source clock of the digital core and input clock of VDD1 and VDD2 * Turn-on of VDD1 and VDD2 HSD PFETis synchronized or at a constant phase shift * Current pulled though VCC1+VCC2 is Iload(VDD1) + Iload(VDD2) * The 3 HSD PFET will be turned-on at the same time, causing the highest possible switching noise on the application. This noise level depends on the layout, the VBAT level, and the load current. The noise level increases with improper layout. When DCDC CLK SYNC bits are 00: * VIO 3-MHz oscillator is the source clock of digital core * VDD1 and VDD2 are running on their own 3-MHz oscillator * Current pulled though VCC1+VCC2 average of Iload(VDD1) + Iload(VDD2) * The switching noise of the 3 SMPS will be randomly spread over time, causing lower overall switching noise. Workaround: Set DCDCCTRL_REG[1:0]= 00. Signed-off-by: Jan Remmet Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 5c99f32c461c041c9e4193419ed534d406af6d47 Author: Alexander Usyskin Date: Mon Sep 12 16:21:43 2016 +0300 mei: me: add kaby point device ids commit ac182e8abc6f93c1c4cc12f042af64c9d7be0d1e upstream. Add device ids for Intel Kabypoint PCH (Kabylake) Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman commit 02785b1fc2fbdc86c62ffa3f550865303ee3235d Author: Liu Gang Date: Fri Oct 21 15:31:28 2016 +0800 gpio: mpc8xxx: Correct irq handler function commit d71cf15b865bdd45925f7b094d169aaabd705145 upstream. From the beginning of the gpio-mpc8xxx.c, the "handle_level_irq" has being used to handle GPIO interrupts in the PowerPC/Layerscape platforms. But actually, almost all PowerPC/Layerscape platforms assert an interrupt request upon either a high-to-low change or any change on the state of the signal. So the "handle_level_irq" is not reasonable for PowerPC/Layerscape GPIO interrupt, it should be "handle_edge_irq". Otherwise the system may lost some interrupts from the PIN's state changes. Signed-off-by: Liu Gang Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman