commit 4d4a6a3f8a12602ce8dc800123715fe7b5c1c3a1 Author: Greg Kroah-Hartman Date: Sat Oct 21 17:21:39 2017 +0200 Linux 4.9.58 commit 480fd4fb29c596bf669a864ceda00dec7f0c2134 Author: Manu Gautam Date: Wed Jul 19 17:07:10 2017 +0530 usb: dwc3: gadget: Correct ISOC DATA PIDs for short packets commit 40d829fb2ec636b6b4b0cc95e2546ab9aca04cc9 upstream. The PIDs for Isochronous data transfers are incorrect for high bandwidth IN endpoints when the request length is less than EP wMaxPacketSize. As per spec correct PIDs for ISOC data transfers are: 1) For request length <= maxpacket - DATA0, 2) For maxpacket < length <= (2 * maxpacket) - DATA1, DATA0 3) For (2 * maxpacket) < length <= (3 * maxpacket) - DATA2, DATA1, DATA0. But driver always sets PCM fields based on wMaxPacketSize due to which DATA2 happens even for small requests. Fix this by setting the PCM field of trb->size depending on request length rather than fixing it to the value depending on wMaxPacketSize. Ideally it shouldn't give any issues as dwc3 will send 0-length packet for next IN token if host sends (even after receiving a short packet). Windows seems to ignore this but with MacOS frame loss observed when using f_uvc. Signed-off-by: Manu Gautam Signed-off-by: Felipe Balbi [b-liu@ti.com added following change for v4.9.] - unsigned int maxp = usb_endpoint_maxp(ep->desc); + unsigned int maxp; + maxp = usb_endpoint_maxp(ep->desc) & 0x07ff; Signed-off-by: Bin Liu Signed-off-by: Greg Kroah-Hartman commit 9b9843154cd1d6916f49a1a95c9b49c7cee9c477 Author: Arnd Bergmann Date: Tue Feb 14 22:19:18 2017 +0100 cpufreq: CPPC: add ACPI_PROCESSOR dependency [ Upstream commit a578884fa0d2768f13d37c6591a9e1ed600482d3 ] Without the Kconfig dependency, we can get this warning: warning: ACPI_CPPC_CPUFREQ selects ACPI_CPPC_LIB which has unmet direct dependencies (ACPI && ACPI_PROCESSOR) Fixes: 5477fb3bd1e8 (ACPI / CPPC: Add a CPUFreq driver for use with CPPC) Signed-off-by: Arnd Bergmann Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2ee4d596e44599f894386223848bf27a51d5fbef Author: Yazen Ghannam Date: Wed Feb 15 14:56:22 2017 -0600 EDAC, mce_amd: Print IPID and Syndrome on a separate line [ Upstream commit 75bf2f6478cab9b0c1d7f5f674a765d1e2ad530e ] Currently, the IPID and Syndrome are printed on the same line as the Address. There are cases when we can have a valid Syndrome but not a valid Address. For example, the MCA_SYND register can be used to hold more detailed error info that the hardware folks can use. It's not just DRAM ECC syndromes. There are some error types that aren't related to memory that may have valid syndromes, like some errors related to links in the Data Fabric, etc. In these cases, the IPID and Syndrome are not printed at the same log level as the rest of the stanza, so users won't see them on the console. Console: [Hardware Error]: CPU:16 (17:1:0) MC22_STATUS[Over|CE|MiscV|-|-|-|-|SyndV|-]: 0xd82000000002080b [Hardware Error]: Power, Interrupts, etc. Extended Error Code: 2 Dmesg: [Hardware Error]: CPU:16 (17:1:0) MC22_STATUS[Over|CE|MiscV|-|-|-|-|SyndV|-]: 0xd82000000002080b , Syndrome: 0x000000010b404000, IPID: 0x0001002e00000002 [Hardware Error]: Power, Interrupts, etc. Extended Error Code: 2 Print the IPID first and on a new line. The IPID should always be printed on SMCA systems. The Syndrome will then be printed with the IPID and at the same log level when valid: [Hardware Error]: CPU:16 (17:1:0) MC22_STATUS[Over|CE|MiscV|-|-|-|-|SyndV|-]: 0xd82000000002080b [Hardware Error]: IPID: 0x0001002e00000002, Syndrome: 0x000000010b404000 [Hardware Error]: Power, Interrupts, etc. Extended Error Code: 2 Signed-off-by: Yazen Ghannam Cc: linux-edac Link: http://lkml.kernel.org/r/1487192182-2474-1-git-send-email-Yazen.Ghannam@amd.com Signed-off-by: Borislav Petkov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8a7a752441a95b861079707cb7467ecc70b4836e Author: Jeffy Chen Date: Mon Jan 23 12:18:51 2017 +0800 btmrvl: avoid double-disable_irq() race [ Upstream commit 9af02d86e11dc409e5c3de46e81c0a492ba58905 ] It's much the same as what we did for mwifiex in: b9da4d2 mwifiex: avoid double-disable_irq() race "We have a race where the wakeup IRQ might be in flight while we're calling mwifiex_disable_wake() from resume(). This can leave us disabling the IRQ twice. Let's disable the IRQ and enable it in case if we have double-disabled it." Signed-off-by: Jeffy Chen Reviewed-by: Brian Norris Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a127483e9ee2d9229723ce6ccbf1bd7d18f3f2b0 Author: Javier Martinez Canillas Date: Thu Feb 16 14:30:02 2017 -0300 regulator: core: Resolve supplies before disabling unused regulators [ Upstream commit 3827b64dba27ebadb4faf51f2c91143e01ba1f6d ] After commit 66d228a2bf03 ("regulator: core: Don't use regulators as supplies until the parent is bound"), input supplies aren't resolved if the input supplies parent device has not been bound. This prevent regulators to hold an invalid reference if its supply parent device driver probe is deferred. But this causes issues on some boards where a PMIC's regulator use as input supply a regulator from another PMIC whose driver is registered after the driver for the former. In this case the regulators for the first PMIC will fail to resolve input supplies on regulators registration (since the other PMIC wasn't probed yet). And when the core attempts to resolve again latter when the other PMIC registers its own regulators, it will fail again since the parent device isn't bound yet. This will cause some parent supplies to never be resolved and wrongly be disabled on boot due taking them as unused. To solve this problem, also attempt to resolve the pending regulators input supplies before disabling the unused regulators. Signed-off-by: Javier Martinez Canillas Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 16ee696eed67f9c08424161f1424842e061147a9 Author: Ben Skeggs Date: Thu Dec 22 10:07:49 2016 +1000 drm/nouveau/gr/gf100-: fix ccache error logging [ Upstream commit 1894054dc1b6e4395048b2c0f28832a3f4320fd3 ] Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 62a3af1f1bc0338d642992f8e2d8601221cbf02e Author: Madhavan Srinivasan Date: Sun Feb 12 22:33:15 2017 +0530 powerpc/perf: Add restrictions to PMC5 in power9 DD1 [ Upstream commit 8d911904f3ce412b20874a9c95f82009dcbb007c ] PMC5 on POWER9 DD1 may not provide right counts in all sampling scenarios, hence use PM_INST_DISP event instead in PMC2 or PMC3 in preference. Signed-off-by: Madhavan Srinivasan Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d4bda742831e0ee5f1d313cf915fa467f346f3b0 Author: Kinglong Mee Date: Sun Feb 5 09:57:07 2017 +0800 nfsd/callback: Cleanup callback cred on shutdown [ Upstream commit f7d1ddbe7648af7460d23688c8c131342eb43b3a ] The rpccred gotten from rpc_lookup_machine_cred() should be put when state is shutdown. Signed-off-by: Kinglong Mee Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0c92e732937c8b159c73ba3c244d29eed5be9f57 Author: Marc Zyngier Date: Fri Jan 15 17:41:09 2016 +0000 hrtimer: Catch invalid clockids again [ Upstream commit 336a9cde10d641e70bac67d90ae91b3190c3edca ] commit 82e88ff1ea94 ("hrtimer: Revert CLOCK_MONOTONIC_RAW support") removed unfortunately a sanity check in the hrtimer code which was part of that MONOTONIC_RAW patch series. It would have caught the bogus usage of CLOCK_MONOTONIC_RAW in the wireless code. So bring it back. It is way too easy to take any random clockid and feed it to the hrtimer subsystem. At best, it gets mapped to a monotonic base, but it would be better to just catch illegal values as early as possible. Detect invalid clockids, map them to CLOCK_MONOTONIC and emit a warning. [ tglx: Replaced the BUG by a WARN and gracefully map to CLOCK_MONOTONIC ] Signed-off-by: Marc Zyngier Cc: Tomasz Nowicki Cc: Christoffer Dall Link: http://lkml.kernel.org/r/1452879670-16133-3-git-send-email-marc.zyngier@arm.com Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b200b6dc7f3953aa8bd6fba7f7e07b460e4c72eb Author: Varun Prakash Date: Fri Jan 20 16:44:33 2017 +0530 target/iscsi: Fix unsolicited data seq_end_offset calculation [ Upstream commit 4d65491c269729a1e3b375c45e73213f49103d33 ] In case of unsolicited data for the first sequence seq_end_offset must be set to minimum of total data length and FirstBurstLength, so do not add cmd->write_data_done to the min of total data length and FirstBurstLength. This patch avoids that with ImmediateData=Yes, InitialR2T=No, MaxXmitDataSegmentLength < FirstBurstLength that a WRITE command with IO size above FirstBurstLength triggers sequence error messages, for example Set following parameters on target (linux-4.8.12) ImmediateData = Yes InitialR2T = No MaxXmitDataSegmentLength = 8k FirstBurstLength = 64k Log in from Open iSCSI initiator and execute dd if=/dev/zero of=/dev/sdb bs=128k count=1 oflag=direct Error messages on target Command ITT: 0x00000035 with Offset: 65536, Length: 8192 outside of Sequence 73728:131072 while DataSequenceInOrder=Yes. Command ITT: 0x00000035, received DataSN: 0x00000001 higher than expected 0x00000000. Unable to perform within-command recovery while ERL=0. Signed-off-by: Varun Prakash [ bvanassche: Use min() instead of open-coding it / edited patch description ] Signed-off-by: Bart Van Assche Signed-off-by: Nicholas Bellinger Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e0fcd1e40db4d8c5a9711f76caa4ea2362f01b26 Author: Sebastian Sanchez Date: Wed Feb 8 05:26:37 2017 -0800 IB/hfi1: Allocate context data on memory node [ Upstream commit b448bf9a0df6093dbadac36979a55ce4e012a677 ] There are some memory allocation calls in hfi1_create_ctxtdata() that do not use the numa function parameter. This can cause cache lines to be filled over QPI. Reviewed-by: Mike Marciniszyn Signed-off-by: Sebastian Sanchez Signed-off-by: Dennis Dalessandro Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 06f2d879c308615ecf81870e672c40144453eb18 Author: Easwar Hariharan Date: Wed Feb 8 05:26:14 2017 -0800 IB/hfi1: Use static CTLE with Preset 6 for integrated HFIs [ Upstream commit 39e2afa8d042a53d855137d4c5a689a6f5492b39 ] After extended testing, it was found that the previous PCIe Gen 3 recipe, which used adaptive CTLE with Preset 4, could cause an NMI/Surprise Link Down in about 1 in 100 to 1 in 1000 power cycles on some platforms. New EV data combined with extensive empirical data indicates that the new recipe should use static CTLE with Preset 6 for all integrated silicon SKUs. Fixes: c3f8de0b334c ("IB/hfi1: Add static PCIe Gen3 CTLE tuning") Reviewed-by: Dennis Dalessandro Signed-off-by: Easwar Hariharan Signed-off-by: Dennis Dalessandro Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 939f4f6ec7414246d7a6ff3cafc0eea42c699eac Author: Dmitry V. Levin Date: Thu Feb 16 18:04:29 2017 +0300 uapi: fix linux/mroute6.h userspace compilation errors [ Upstream commit 72aa107df6a275cf03359934ca5799a2be7a1bf7 ] Include to fix the following linux/mroute6.h userspace compilation errors: /usr/include/linux/mroute6.h:80:22: error: field 'mf6cc_origin' has incomplete type struct sockaddr_in6 mf6cc_origin; /* Origin of mcast */ /usr/include/linux/mroute6.h:81:22: error: field 'mf6cc_mcastgrp' has incomplete type struct sockaddr_in6 mf6cc_mcastgrp; /* Group in question */ /usr/include/linux/mroute6.h:91:22: error: field 'src' has incomplete type struct sockaddr_in6 src; /usr/include/linux/mroute6.h:92:22: error: field 'grp' has incomplete type struct sockaddr_in6 grp; /usr/include/linux/mroute6.h:132:18: error: field 'im6_src' has incomplete type struct in6_addr im6_src, im6_dst; /usr/include/linux/mroute6.h:132:27: error: field 'im6_dst' has incomplete type struct in6_addr im6_src, im6_dst; Signed-off-by: Dmitry V. Levin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ad50561ba7a664bc581826c9d57d137fcf17bfa5 Author: Dmitry V. Levin Date: Thu Feb 16 18:05:45 2017 +0300 uapi: fix linux/rds.h userspace compilation errors [ Upstream commit feb0869d90e51ce8b6fd8a46588465b1b5a26d09 ] Consistently use types from linux/types.h to fix the following linux/rds.h userspace compilation errors: /usr/include/linux/rds.h:106:2: error: unknown type name 'uint8_t' uint8_t name[32]; /usr/include/linux/rds.h:107:2: error: unknown type name 'uint64_t' uint64_t value; /usr/include/linux/rds.h:117:2: error: unknown type name 'uint64_t' uint64_t next_tx_seq; /usr/include/linux/rds.h:118:2: error: unknown type name 'uint64_t' uint64_t next_rx_seq; /usr/include/linux/rds.h:121:2: error: unknown type name 'uint8_t' uint8_t transport[TRANSNAMSIZ]; /* null term ascii */ /usr/include/linux/rds.h:122:2: error: unknown type name 'uint8_t' uint8_t flags; /usr/include/linux/rds.h:129:2: error: unknown type name 'uint64_t' uint64_t seq; /usr/include/linux/rds.h:130:2: error: unknown type name 'uint32_t' uint32_t len; /usr/include/linux/rds.h:135:2: error: unknown type name 'uint8_t' uint8_t flags; /usr/include/linux/rds.h:139:2: error: unknown type name 'uint32_t' uint32_t sndbuf; /usr/include/linux/rds.h:144:2: error: unknown type name 'uint32_t' uint32_t rcvbuf; /usr/include/linux/rds.h:145:2: error: unknown type name 'uint64_t' uint64_t inum; /usr/include/linux/rds.h:153:2: error: unknown type name 'uint64_t' uint64_t hdr_rem; /usr/include/linux/rds.h:154:2: error: unknown type name 'uint64_t' uint64_t data_rem; /usr/include/linux/rds.h:155:2: error: unknown type name 'uint32_t' uint32_t last_sent_nxt; /usr/include/linux/rds.h:156:2: error: unknown type name 'uint32_t' uint32_t last_expected_una; /usr/include/linux/rds.h:157:2: error: unknown type name 'uint32_t' uint32_t last_seen_una; /usr/include/linux/rds.h:164:2: error: unknown type name 'uint8_t' uint8_t src_gid[RDS_IB_GID_LEN]; /usr/include/linux/rds.h:165:2: error: unknown type name 'uint8_t' uint8_t dst_gid[RDS_IB_GID_LEN]; /usr/include/linux/rds.h:167:2: error: unknown type name 'uint32_t' uint32_t max_send_wr; /usr/include/linux/rds.h:168:2: error: unknown type name 'uint32_t' uint32_t max_recv_wr; /usr/include/linux/rds.h:169:2: error: unknown type name 'uint32_t' uint32_t max_send_sge; /usr/include/linux/rds.h:170:2: error: unknown type name 'uint32_t' uint32_t rdma_mr_max; /usr/include/linux/rds.h:171:2: error: unknown type name 'uint32_t' uint32_t rdma_mr_size; /usr/include/linux/rds.h:212:9: error: unknown type name 'uint64_t' typedef uint64_t rds_rdma_cookie_t; /usr/include/linux/rds.h:215:2: error: unknown type name 'uint64_t' uint64_t addr; /usr/include/linux/rds.h:216:2: error: unknown type name 'uint64_t' uint64_t bytes; /usr/include/linux/rds.h:221:2: error: unknown type name 'uint64_t' uint64_t cookie_addr; /usr/include/linux/rds.h:222:2: error: unknown type name 'uint64_t' uint64_t flags; /usr/include/linux/rds.h:228:2: error: unknown type name 'uint64_t' uint64_t cookie_addr; /usr/include/linux/rds.h:229:2: error: unknown type name 'uint64_t' uint64_t flags; /usr/include/linux/rds.h:234:2: error: unknown type name 'uint64_t' uint64_t flags; /usr/include/linux/rds.h:240:2: error: unknown type name 'uint64_t' uint64_t local_vec_addr; /usr/include/linux/rds.h:241:2: error: unknown type name 'uint64_t' uint64_t nr_local; /usr/include/linux/rds.h:242:2: error: unknown type name 'uint64_t' uint64_t flags; /usr/include/linux/rds.h:243:2: error: unknown type name 'uint64_t' uint64_t user_token; /usr/include/linux/rds.h:248:2: error: unknown type name 'uint64_t' uint64_t local_addr; /usr/include/linux/rds.h:249:2: error: unknown type name 'uint64_t' uint64_t remote_addr; /usr/include/linux/rds.h:252:4: error: unknown type name 'uint64_t' uint64_t compare; /usr/include/linux/rds.h:253:4: error: unknown type name 'uint64_t' uint64_t swap; /usr/include/linux/rds.h:256:4: error: unknown type name 'uint64_t' uint64_t add; /usr/include/linux/rds.h:259:4: error: unknown type name 'uint64_t' uint64_t compare; /usr/include/linux/rds.h:260:4: error: unknown type name 'uint64_t' uint64_t swap; /usr/include/linux/rds.h:261:4: error: unknown type name 'uint64_t' uint64_t compare_mask; /usr/include/linux/rds.h:262:4: error: unknown type name 'uint64_t' uint64_t swap_mask; /usr/include/linux/rds.h:265:4: error: unknown type name 'uint64_t' uint64_t add; /usr/include/linux/rds.h:266:4: error: unknown type name 'uint64_t' uint64_t nocarry_mask; /usr/include/linux/rds.h:269:2: error: unknown type name 'uint64_t' uint64_t flags; /usr/include/linux/rds.h:270:2: error: unknown type name 'uint64_t' uint64_t user_token; /usr/include/linux/rds.h:274:2: error: unknown type name 'uint64_t' uint64_t user_token; /usr/include/linux/rds.h:275:2: error: unknown type name 'int32_t' int32_t status; Signed-off-by: Dmitry V. Levin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bd530852210d9a9bb96cb4c08adc13a6b116c75e Author: Jeff Layton Date: Thu Dec 15 08:37:57 2016 -0500 ceph: clean up unsafe d_parent accesses in build_dentry_path [ Upstream commit c6b0b656ca24ede6657abb4a2cd910fa9c1879ba ] While we hold a reference to the dentry when build_dentry_path is called, we could end up racing with a rename that changes d_parent. Handle that situation correctly, by using the rcu_read_lock to ensure that the parent dentry and inode stick around long enough to safely check ceph_snap and ceph_ino. Link: http://tracker.ceph.com/issues/18148 Signed-off-by: Jeff Layton Reviewed-by: Yan, Zheng Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6839ad59f9d5058b3b7e2c608b4a9d08619134a3 Author: Jeff Layton Date: Thu Jan 12 14:42:40 2017 -0500 ceph: fix bogus endianness change in ceph_ioctl_set_layout [ Upstream commit 24c149ad6914d349d8b64749f20f3f8ea5031fe0 ] sparse says: fs/ceph/ioctl.c:100:28: warning: cast to restricted __le64 preferred_osd is a __s64 so we don't need to do any conversion. Also, just remove the cast in ceph_ioctl_get_layout as it's not needed. Signed-off-by: Jeff Layton Reviewed-by: Sage Weil Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit df37e8fadf749d2bd7010e420baef11542ecaca9 Author: Jeff Layton Date: Thu Jan 26 16:14:18 2017 -0500 ceph: don't update_dentry_lease unless we actually got one [ Upstream commit 80d025ffede88969f6adf7266fbdedfd5641148a ] This if block updates the dentry lease even in the case where the MDS didn't grant one. Signed-off-by: Jeff Layton Reviewed-by: Yan, Zheng Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b025eb5d2678af7e2d40ffa715e173b81a5a7972 Author: Alexandre Belloni Date: Thu Feb 16 18:27:59 2017 +0100 i2c: at91: ensure state is restored after suspending [ Upstream commit e3ccc921b7d8fd1fcd10a00720e09823d8078666 ] When going to suspend, the I2C registers may be lost because the power to VDDcore is cut. Restore them when resuming. Signed-off-by: Alexandre Belloni Acked-by: Ludovic Desroches Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1226f6993357300042faae9e379cafcdfe0292d3 Author: Ram Amrani Date: Mon Feb 20 22:43:31 2017 +0200 qed: Read queue state before releasing buffer [ Upstream commit c5212b943d4b52a7d9e0d9f747e7ad59c50d31f1 ] Currently the state is read only after the buffers are relesed. Signed-off-by: Ram Amrani Signed-off-by: Yuval Mintz Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7f8ea2674b447db447830c21a195955183ff0b23 Author: Ram Amrani Date: Mon Feb 20 22:43:33 2017 +0200 qed: Reserve doorbell BAR space for present CPUs [ Upstream commit c2dedf8773e873474535bd4a158609b9eda5403d ] Reserving doorbell BAR space according to the currently active CPUs may result in a bug if disabled CPUs are later enabled but no doorbell space was reserved for them. Signed-off-by: Ram Amrani Signed-off-by: Yuval Mintz Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a506d326cbec565f2871e376c9702f9f9a047a37 Author: Sudarsana Reddy Kalluru Date: Mon Feb 20 22:43:37 2017 +0200 qede: Prevent index problems in loopback test [ Upstream commit afe981d664aeeebc8d1bcbd7d2070b5432edaecb ] Driver currently utilizes the same loop variable in two nested loops. Signed-off-by: Sudarsana Reddy Kalluru Signed-off-by: Yuval Mintz Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f6a72741241f27ccc880b89d3923e7c829facd9a Author: Thomas Petazzoni Date: Tue Feb 21 11:28:05 2017 +0100 net: mvpp2: release reference to txq_cpu[] entry after unmapping [ Upstream commit 36fb7435b6ac4d288a2d4deea8934f9456ab46b6 ] The mvpp2_txq_bufs_free() function is called upon TX completion to DMA unmap TX buffers, and free the corresponding SKBs. It gets the references to the SKB to free and the DMA buffer to unmap from a per-CPU txq_pcpu data structure. However, the code currently increments the pointer to the next entry before doing the DMA unmap and freeing the SKB. It does not cause any visible problem because for a given SKB the TX completion is guaranteed to take place on the CPU where the TX was started. However, it is much more logical to increment the pointer to the next entry once the current entry has been completely unmapped/released. Signed-off-by: Thomas Petazzoni Acked-by: Russell King Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0ea82b90d8448d6a74650c6891bc07ad20689b1f Author: Nicolai Hähnle Date: Thu Feb 16 23:49:12 2017 +0100 drm/amdgpu: refuse to reserve io mem for split VRAM buffers [ Upstream commit 4694335dad7357e9b3d7822ab13049014d74d8b0 ] When the fast blit path fails while attempting to move a buffer from RAM to VRAM, we fall back to a CPU-based memcpy that cannot handle split VRAM buffers. Instead of crashing, simply fail the buffer move. Ideally, we would teach TTM about split buffers so that the fallback still works in this case, but that is quite involved. So for now, apply the simplest possible fix. Fixes: 40361bb1704b ("drm/amdgpu: add VRAM manager v2") Signed-off-by: Nicolai Hähnle Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b01eb463130675a03a89ea8ca97b06ad6710fde5 Author: Arnd Bergmann Date: Tue Feb 21 23:00:46 2017 +0100 ASoC: mediatek: add I2C dependency for CS42XX8 [ Upstream commit 72cedf599fcebfd6cd2550274d7855838068d28c ] We should not select drivers that depend on I2C when that is disabled, as it results in a build error: warning: (SND_SOC_MT2701_CS42448) selects SND_SOC_CS42XX8_I2C which has unmet direct dependencies (SOUND && !M68K && !UML && SND && SND_SOC && I2C) sound/soc/codecs/cs42xx8-i2c.c:60:1: warning: data definition has no type or storage class module_i2c_driver(cs42xx8_i2c_driver); sound/soc/codecs/cs42xx8-i2c.c:60:1: error: type defaults to 'int' in declaration of 'module_i2c_driver' [-Werror=implicit-int] Fixes: 1f458d53f76c ("ASoC: mediatek: Add mt2701-cs42448 driver and config option.") Signed-off-by: Arnd Bergmann Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 10ae48453347f7b11c76b7dd64ea469b61434d1b Author: Dan Carpenter Date: Tue Feb 21 21:46:37 2017 +0300 scsi: scsi_dh_emc: return success in clariion_std_inquiry() [ Upstream commit 4d7d39a18b8b81511f0b893b7d2203790bf8a58b ] We accidentally return an uninitialized variable on success. Fixes: b6ff1b14cdf4 ("[SCSI] scsi_dh: Update EMC handler") Signed-off-by: Dan Carpenter Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 076a6220bc0198983432704e03ed993b2230ba7b Author: Grygorii Maistrenko Date: Wed Feb 22 15:40:59 2017 -0800 slub: do not merge cache if slub_debug contains a never-merge flag [ Upstream commit c6e28895a4372992961888ffaadc9efc643b5bfe ] In case CONFIG_SLUB_DEBUG_ON=n, find_mergeable() gets debug features from commandline but never checks if there are features from the SLAB_NEVER_MERGE set. As a result selected by slub_debug caches are always mergeable if they have been created without a custom constructor set or without one of the SLAB_* debug features on. This moves the SLAB_NEVER_MERGE check below the flags update from commandline to make sure it won't merge the slab cache if one of the debug features is on. Link: http://lkml.kernel.org/r/20170101124451.GA4740@lp-laptop-d Signed-off-by: Grygorii Maistrenko Reviewed-by: Pekka Enberg Acked-by: David Rientjes Acked-by: Christoph Lameter Cc: Joonsoo Kim Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2ada592fc8e53998c7b383af23e2e794bfe571bf Author: Eric Ren Date: Wed Feb 22 15:40:41 2017 -0800 ocfs2/dlmglue: prepare tracking logic to avoid recursive cluster lock [ Upstream commit 439a36b8ef38657f765b80b775e2885338d72451 ] We are in the situation that we have to avoid recursive cluster locking, but there is no way to check if a cluster lock has been taken by a precess already. Mostly, we can avoid recursive locking by writing code carefully. However, we found that it's very hard to handle the routines that are invoked directly by vfs code. For instance: const struct inode_operations ocfs2_file_iops = { .permission = ocfs2_permission, .get_acl = ocfs2_iop_get_acl, .set_acl = ocfs2_iop_set_acl, }; Both ocfs2_permission() and ocfs2_iop_get_acl() call ocfs2_inode_lock(PR): do_sys_open may_open inode_permission ocfs2_permission ocfs2_inode_lock() <=== first time generic_permission get_acl ocfs2_iop_get_acl ocfs2_inode_lock() <=== recursive one A deadlock will occur if a remote EX request comes in between two of ocfs2_inode_lock(). Briefly describe how the deadlock is formed: On one hand, OCFS2_LOCK_BLOCKED flag of this lockres is set in BAST(ocfs2_generic_handle_bast) when downconvert is started on behalf of the remote EX lock request. Another hand, the recursive cluster lock (the second one) will be blocked in in __ocfs2_cluster_lock() because of OCFS2_LOCK_BLOCKED. But, the downconvert never complete, why? because there is no chance for the first cluster lock on this node to be unlocked - we block ourselves in the code path. The idea to fix this issue is mostly taken from gfs2 code. 1. introduce a new field: struct ocfs2_lock_res.l_holders, to keep track of the processes' pid who has taken the cluster lock of this lock resource; 2. introduce a new flag for ocfs2_inode_lock_full: OCFS2_META_LOCK_GETBH; it means just getting back disk inode bh for us if we've got cluster lock. 3. export a helper: ocfs2_is_locked_by_me() is used to check if we have got the cluster lock in the upper code path. The tracking logic should be used by some of the ocfs2 vfs's callbacks, to solve the recursive locking issue cuased by the fact that vfs routines can call into each other. The performance penalty of processing the holder list should only be seen at a few cases where the tracking logic is used, such as get/set acl. You may ask what if the first time we got a PR lock, and the second time we want a EX lock? fortunately, this case never happens in the real world, as far as I can see, including permission check, (get|set)_(acl|attr), and the gfs2 code also do so. [sfr@canb.auug.org.au remove some inlines] Link: http://lkml.kernel.org/r/20170117100948.11657-2-zren@suse.com Signed-off-by: Eric Ren Reviewed-by: Junxiao Bi Reviewed-by: Joseph Qi Cc: Stephen Rothwell Cc: Mark Fasheh Cc: Joel Becker Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a5f043b2419e09d9f40758fb4627f524f7755c8f Author: Yasuaki Ishimatsu Date: Wed Feb 22 15:45:13 2017 -0800 mm/memory_hotplug: set magic number to page->freelist instead of page->lru.next [ Upstream commit ddffe98d166f4a93d996d5aa628fd745311fc1e7 ] To identify that pages of page table are allocated from bootmem allocator, magic number sets to page->lru.next. But page->lru list is initialized in reserve_bootmem_region(). So when calling free_pagetable(), the function cannot find the magic number of pages. And free_pagetable() frees the pages by free_reserved_page() not put_page_bootmem(). But if the pages are allocated from bootmem allocator and used as page table, the pages have private flag. So before freeing the pages, we should clear the private flag by put_page_bootmem(). Before applying the commit 7bfec6f47bb0 ("mm, page_alloc: check multiple page fields with a single branch"), we could find the following visible issue: BUG: Bad page state in process kworker/u1024:1 page:ffffea103cfd8040 count:0 mapcount:0 mappi flags: 0x6fffff80000800(private) page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set bad because of flags: 0x800(private) Call Trace: [...] dump_stack+0x63/0x87 [...] bad_page+0x114/0x130 [...] free_pages_prepare+0x299/0x2d0 [...] free_hot_cold_page+0x31/0x150 [...] __free_pages+0x25/0x30 [...] free_pagetable+0x6f/0xb4 [...] remove_pagetable+0x379/0x7ff [...] vmemmap_free+0x10/0x20 [...] sparse_remove_one_section+0x149/0x180 [...] __remove_pages+0x2e9/0x4f0 [...] arch_remove_memory+0x63/0xc0 [...] remove_memory+0x8c/0xc0 [...] acpi_memory_device_remove+0x79/0xa5 [...] acpi_bus_trim+0x5a/0x8d [...] acpi_bus_trim+0x38/0x8d [...] acpi_device_hotplug+0x1b7/0x418 [...] acpi_hotplug_work_fn+0x1e/0x29 [...] process_one_work+0x152/0x400 [...] worker_thread+0x125/0x4b0 [...] kthread+0xd8/0xf0 [...] ret_from_fork+0x22/0x40 And the issue still silently occurs. Until freeing the pages of page table allocated from bootmem allocator, the page->freelist is never used. So the patch sets magic number to page->freelist instead of page->lru.next. [isimatu.yasuaki@jp.fujitsu.com: fix merge issue] Link: http://lkml.kernel.org/r/722b1cc4-93ac-dd8b-2be2-7a7e313b3b0b@gmail.com Link: http://lkml.kernel.org/r/2c29bd9f-5b67-02d0-18a3-8828e78bbb6f@gmail.com Signed-off-by: Yasuaki Ishimatsu Cc: Thomas Gleixner Cc: Ingo Molnar Cc: H. Peter Anvin Cc: Dave Hansen Cc: Vlastimil Babka Cc: Mel Gorman Cc: Xishi Qiu Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6145171a6bc0abdc3eca7a4b795ede467d2ba569 Author: Milan Broz Date: Thu Feb 23 08:38:26 2017 +0100 crypto: xts - Add ECB dependency [ Upstream commit 12cb3a1c4184f891d965d1f39f8cfcc9ef617647 ] Since the commit f1c131b45410a202eb45cc55980a7a9e4e4b4f40 crypto: xts - Convert to skcipher the XTS mode is based on ECB, so the mode must select ECB otherwise it can fail to initialize. Signed-off-by: Milan Broz Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8909b26a51fc7e47b8f4094c39c6b0f38676b02b Author: Majd Dibbiny Date: Thu Feb 23 12:02:43 2017 +0200 net/mlx4_core: Fix VF overwrite of module param which disables DMFS on new probed PFs [ Upstream commit 95f1ba9a24af9769f6e20dfe9a77c863f253f311 ] In the VF driver, module parameter mlx4_log_num_mgm_entry_size was mistakenly overwritten -- and in a manner which overrode the device-managed flow steering option encoded in the parameter. log_num_mgm_entry_size is a global module parameter which affects all ConnectX-3 PFs installed on that host. If a VF changes log_num_mgm_entry_size, this will affect all PFs which are probed subsequent to the change (by disabling DMFS for those PFs). Fixes: 3c439b5586e9 ("mlx4_core: Allow choosing flow steering mode") Signed-off-by: Majd Dibbiny Reviewed-by: Jack Morgenstein Signed-off-by: Tariq Toukan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 84a66ca775438dc3f9918a977a169f49a9700e2d Author: Vijay Kumar Date: Wed Feb 1 11:34:38 2017 -0800 sparc64: Migrate hvcons irq to panicked cpu [ Upstream commit 7dd4fcf5b70694dc961eb6b954673e4fc9730dbd ] On panic, all other CPUs are stopped except the one which had hit panic. To keep console alive, we need to migrate hvcons irq to panicked CPU. Signed-off-by: Vijay Kumar Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cf368c29f5ac57c798eb99c1fba04314588e8566 Author: Shaohua Li Date: Tue Feb 21 11:57:01 2017 -0800 md/linear: shutup lockdep warnning [ Upstream commit d939cdfde34f50b95254b375f498447c82190b3e ] Commit 03a9e24(md linear: fix a race between linear_add() and linear_congested()) introduces the warnning. Acked-by: Coly Li Signed-off-by: Shaohua Li Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e9afe7c8641ab23a060799f19f1aeb5b84d1807a Author: Jaegeuk Kim Date: Fri Feb 17 09:55:55 2017 -0800 f2fs: do not wait for writeback in write_begin [ Upstream commit 86d54795c94532075d862aa0a79f0c981dab4bdd ] Otherwise we can get livelock like below. [79880.428136] dbench D 0 18405 18404 0x00000000 [79880.428139] Call Trace: [79880.428142] __schedule+0x219/0x6b0 [79880.428144] schedule+0x36/0x80 [79880.428147] schedule_timeout+0x243/0x2e0 [79880.428152] ? update_sd_lb_stats+0x16b/0x5f0 [79880.428155] ? ktime_get+0x3c/0xb0 [79880.428157] io_schedule_timeout+0xa6/0x110 [79880.428161] __lock_page+0xf7/0x130 [79880.428164] ? unlock_page+0x30/0x30 [79880.428167] pagecache_get_page+0x16b/0x250 [79880.428171] grab_cache_page_write_begin+0x20/0x40 [79880.428182] f2fs_write_begin+0xa2/0xdb0 [f2fs] [79880.428192] ? f2fs_mark_inode_dirty_sync+0x16/0x30 [f2fs] [79880.428197] ? kmem_cache_free+0x79/0x200 [79880.428203] ? __mark_inode_dirty+0x17f/0x360 [79880.428206] generic_perform_write+0xbb/0x190 [79880.428213] ? file_update_time+0xa4/0xf0 [79880.428217] __generic_file_write_iter+0x19b/0x1e0 [79880.428226] f2fs_file_write_iter+0x9c/0x180 [f2fs] [79880.428231] __vfs_write+0xc5/0x140 [79880.428235] vfs_write+0xb2/0x1b0 [79880.428238] SyS_write+0x46/0xa0 [79880.428242] entry_SYSCALL_64_fastpath+0x1e/0xad Fixes: cae96a5c8ab6 ("f2fs: check io submission more precisely") Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e215b6bb2dfeb34cf3aba0feab8c5c62f477a7b5 Author: Robbie Ko Date: Thu Jan 5 16:24:55 2017 +0800 Btrfs: send, fix failure to rename top level inode due to name collision [ Upstream commit 4dd9920d991745c4a16f53a8f615f706fbe4b3f7 ] Under certain situations, an incremental send operation can fail due to a premature attempt to create a new top level inode (a direct child of the subvolume/snapshot root) whose name collides with another inode that was removed from the send snapshot. Consider the following example scenario. Parent snapshot: . (ino 256, gen 8) |---- a1/ (ino 257, gen 9) |---- a2/ (ino 258, gen 9) Send snapshot: . (ino 256, gen 3) |---- a2/ (ino 257, gen 7) In this scenario, when receiving the incremental send stream, the btrfs receive command fails like this (ran in verbose mode, -vv argument): rmdir a1 mkfile o257-7-0 rename o257-7-0 -> a2 ERROR: rename o257-7-0 -> a2 failed: Is a directory What happens when computing the incremental send stream is: 1) An operation to remove the directory with inode number 257 and generation 9 is issued. 2) An operation to create the inode with number 257 and generation 7 is issued. This creates the inode with an orphanized name of "o257-7-0". 3) An operation rename the new inode 257 to its final name, "a2", is issued. This is incorrect because inode 258, which has the same name and it's a child of the same parent (root inode 256), was not yet processed and therefore no rmdir operation for it was yet issued. The rename operation is issued because we fail to detect that the name of the new inode 257 collides with inode 258, because their parent, a subvolume/snapshot root (inode 256) has a different generation in both snapshots. So fix this by ignoring the generation value of a parent directory that matches a root inode (number 256) when we are checking if the name of the inode currently being processed collides with the name of some other inode that was not yet processed. We can achieve this scenario of different inodes with the same number but different generation values either by mounting a filesystem with the inode cache option (-o inode_cache) or by creating and sending snapshots across different filesystems, like in the following example: $ mkfs.btrfs -f /dev/sdb $ mount /dev/sdb /mnt $ mkdir /mnt/a1 $ mkdir /mnt/a2 $ btrfs subvolume snapshot -r /mnt /mnt/snap1 $ btrfs send /mnt/snap1 -f /tmp/1.snap $ umount /mnt $ mkfs.btrfs -f /dev/sdc $ mount /dev/sdc /mnt $ touch /mnt/a2 $ btrfs subvolume snapshot -r /mnt /mnt/snap2 $ btrfs receive /mnt -f /tmp/1.snap # Take note that once the filesystem is created, its current # generation has value 7 so the inode from the second snapshot has # a generation value of 7. And after receiving the first snapshot # the filesystem is at a generation value of 10, because the call to # create the second snapshot bumps the generation to 8 (the snapshot # creation ioctl does a transaction commit), the receive command calls # the snapshot creation ioctl to create the first snapshot, which bumps # the filesystem's generation to 9, and finally when the receive # operation finishes it calls an ioctl to transition the first snapshot # (snap1) from RW mode to RO mode, which does another transaction commit # and bumps the filesystem's generation to 10. $ rm -f /tmp/1.snap $ btrfs send /mnt/snap1 -f /tmp/1.snap $ btrfs send -p /mnt/snap1 /mnt/snap2 -f /tmp/2.snap $ umount /mnt $ mkfs.btrfs -f /dev/sdd $ mount /dev/sdd /mnt $ btrfs receive /mnt /tmp/1.snap # Receive of snapshot snap2 used to fail. $ btrfs receive /mnt /tmp/2.snap Signed-off-by: Robbie Ko Reviewed-by: Filipe Manana [Rewrote changelog to be more precise and clear] Signed-off-by: Filipe Manana Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ab3d531745cf6cbbbf3a42679d50168d455dbbe4 Author: Wanpeng Li Date: Tue Feb 21 23:52:55 2017 -0800 sched/fair: Update rq clock before changing a task's CPU affinity [ Upstream commit a499c3ead88ccf147fc50689e85a530ad923ce36 ] This is triggered during boot when CONFIG_SCHED_DEBUG is enabled: ------------[ cut here ]------------ WARNING: CPU: 6 PID: 81 at kernel/sched/sched.h:812 set_next_entity+0x11d/0x380 rq->clock_update_flags < RQCF_ACT_SKIP CPU: 6 PID: 81 Comm: torture_shuffle Not tainted 4.10.0+ #1 Hardware name: LENOVO ThinkCentre M8500t-N000/SHARKBAY, BIOS FBKTC1AUS 02/16/2016 Call Trace: dump_stack+0x85/0xc2 __warn+0xcb/0xf0 warn_slowpath_fmt+0x5f/0x80 set_next_entity+0x11d/0x380 set_curr_task_fair+0x2b/0x60 do_set_cpus_allowed+0x139/0x180 __set_cpus_allowed_ptr+0x113/0x260 set_cpus_allowed_ptr+0x10/0x20 torture_shuffle+0xfd/0x180 kthread+0x10f/0x150 ? torture_shutdown_init+0x60/0x60 ? kthread_create_on_node+0x60/0x60 ret_from_fork+0x31/0x40 ---[ end trace dd94d92344cea9c6 ]--- The task is running && !queued, so there is no rq clock update before calling set_curr_task(). This patch fixes it by updating rq clock after holding rq->lock/pi_lock just as what other dequeue + put_prev + enqueue + set_curr story does. Signed-off-by: Wanpeng Li Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Matt Fleming Cc: Linus Torvalds Cc: Mike Galbraith Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1487749975-5994-1-git-send-email-wanpeng.li@hotmail.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e5226e92bed86880c52454fc8ed7f8e5e48ac5bb Author: Yunlong Song Date: Wed Feb 22 20:50:49 2017 +0800 f2fs: do SSR for data when there is enough free space [ Upstream commit 035e97adab26c1121cedaeb9bd04cf48a8e8cf51 ] In allocate_segment_by_default(), need_SSR() already detected it's time to do SSR. So, let's try to find victims for data segments more aggressively in time. Signed-off-by: Yunlong Song Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 90a8dfa5ae7a1589d9c99503ce160334a474b8a0 Author: Christophe JAILLET Date: Tue Feb 21 07:34:00 2017 +0100 iio: adc: xilinx: Fix error handling [ Upstream commit ca1c39ef76376b67303d01f94fe98bb68bb3861a ] Reorder error handling labels in order to match the way resources have been allocated. Signed-off-by: Christophe JAILLET Acked-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f107c6ddf8db81bda0f784c57c9d26ca87cc3c38 Author: Jarno Rajahalme Date: Thu Feb 23 17:08:54 2017 -0800 netfilter: nf_ct_expect: Change __nf_ct_expect_check() return value. [ Upstream commit 4b86c459c7bee3acaf92f0e2b4c6ac803eaa1a58 ] Commit 4dee62b1b9b4 ("netfilter: nf_ct_expect: nf_ct_expect_insert() returns void") inadvertently changed the successful return value of nf_ct_expect_related_report() from 0 to 1 due to __nf_ct_expect_check() returning 1 on success. Prevent this regression in the future by changing the return value of __nf_ct_expect_check() to 0 on success. Signed-off-by: Jarno Rajahalme Acked-by: Joe Stringer Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0500fcd885561a41d49ef635453247df41a80df5 Author: Michael Zoran Date: Sat Feb 18 03:22:01 2017 -0800 staging: vchiq_2835_arm: Make cache-line-size a required DT property [ Upstream commit 6cf1bf636a067eb308cb3a8322b9d6b1844a075d ] The original github source allowed for the cache-line-size property to be missing. Since recent firmwares also require this property, it makes sense to always require it in the driver as well. If the cache-line-size property is missing, then the driver probe should fail as no dev since the kernel and dt may be out of sync. The fix is to add a check for the return value of of_property_read_u32. Changes V2: 1. Add error message if cache-line-size is missing. 2. Simple check for non-zero return value from of_property_read_u32. Signed-off-by: Michael Zoran Acked-by: Stefan Wahren Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b1b73cc0460837f328d091de2746040e30fbd808 Author: Eric Dumazet Date: Thu Feb 23 15:22:43 2017 -0800 net/mlx4_en: fix overflow in mlx4_en_init_timestamp() [ Upstream commit 47d3a07528ecbbccf53bc4390d70b4e3d1c04fcf ] The cited commit makes a great job of finding optimal shift/multiplier values assuming a 10 seconds wrap around, but forgot to change the overflow_period computation. It overflows in cyclecounter_cyc2ns(), and the final result is 804 ms, which is silly. Lets simply use 5 seconds, no need to recompute this, given how it is supposed to work. Later, we will use a timer instead of a work queue, since the new RX allocation schem will no longer need mlx4_en_recover_from_oom() and the service_task firing every 250 ms. Fixes: 31c128b66e5b ("net/mlx4_en: Choose time-stamping shift value according to HW frequency") Signed-off-by: Eric Dumazet Cc: Tariq Toukan Cc: Eugenia Emantayev Reviewed-by: Tariq Toukan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c1bc62d729f46be9dae02a68a7e7b867cb8af25f Author: Emmanuel Grumbach Date: Mon Feb 20 14:24:36 2017 +0100 mac80211: fix power saving clients handling in iwlwifi [ Upstream commit d98937f4ea713d21e0fcc345919f86c877dd8d6f ] iwlwifi now supports RSS and can't let mac80211 track the PS state based on the Rx frames since they can come out of order. iwlwifi is now advertising AP_LINK_PS, and uses explicit notifications to teach mac80211 about the PS state of the stations and the PS poll / uAPSD trigger frames coming our way from the peers. Because of that, the TIM stopped being maintained in mac80211. I tried to fix this in commit c68df2e7be0c ("mac80211: allow using AP_LINK_PS with mac80211-generated TIM IE") but that was later reverted by Felix in commit 6c18a6b4e799 ("Revert "mac80211: allow using AP_LINK_PS with mac80211-generated TIM IE") since it broke drivers that do not implement set_tim. Since none of the drivers that set AP_LINK_PS have the set_tim() handler set besides iwlwifi, I can bail out in __sta_info_recalc_tim if AP_LINK_PS AND .set_tim is not implemented. Signed-off-by: Emmanuel Grumbach Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fff654b43e12d41db0a0918ac08ddd2e76bf1579 Author: Mintz, Yuval Date: Mon Feb 27 11:06:33 2017 +0200 qed: Don't use attention PTT for configuring BW [ Upstream commit 6f437d431930ff86e4a971d29321951faadb97c7 ] Commit 653d2ffd6405 ("qed*: Fix link indication race") introduced another race - one of the inner functions called from the link-change flow is explicitly using the slowpath context dedicated PTT instead of gaining that PTT from the caller. Since this flow can now be called from a different context as well, we're in risk of the PTT breaking. Fixes: 653d2ffd6405 ("qed*: Fix link indication race") Signed-off-by: Yuval Mintz Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 145ded700722eef2a9992bc7435f302c5c91b6e0 Author: Vinod Koul Date: Mon Feb 27 21:19:44 2017 +0530 ALSA: hda: Add Geminilake HDMI codec ID [ Upstream commit 126cfa2f5e15ae2ca7f70be71b07e6cd8d2b44d1 ] Geminilake HDMI codec 0x280d is similar to previous platforms, so add it with similar ops as previous. Signed-off-by: Senthilnathan Veppur Signed-off-by: Vinod Koul Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4799163a7a19499678327a04d65ce0394492632a Author: Johannes Berg Date: Mon Feb 27 17:15:28 2017 +0100 mac80211_hwsim: check HWSIM_ATTR_RADIO_NAME length [ Upstream commit ff4dd73dd2b4806419f8ff65cbce11d5019548d0 ] Unfortunately, the nla policy was defined to have HWSIM_ATTR_RADIO_NAME as an NLA_STRING, rather than NLA_NUL_STRING, so we can't use it as a NUL-terminated string in the kernel. Rather than break the API, kasprintf() the string to a new buffer to guarantee NUL termination. Reported-by: Andrew Zaborowski Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit aaf54d40b83fa6ebcdccdd895f97cd86b8f67406 Author: Lokesh Vutla Date: Mon Feb 27 14:28:12 2017 -0800 initramfs: finish fput() before accessing any binary from initramfs [ Upstream commit 08865514805d2de8e7002fa8149c5de3e391f412 ] Commit 4a9d4b024a31 ("switch fput to task_work_add") implements a schedule_work() for completing fput(), but did not guarantee calling __fput() after unpacking initramfs. Because of this, there is a possibility that during boot a driver can see ETXTBSY when it tries to load a binary from initramfs as fput() is still pending on that binary. This patch makes sure that fput() is completed after unpacking initramfs and removes the call to flush_delayed_fput() in kernel_init() which happens very late after unpacking initramfs. Link: http://lkml.kernel.org/r/20170201140540.22051-1-lokeshvutla@ti.com Signed-off-by: Lokesh Vutla Reported-by: Murali Karicheri Cc: Al Viro Cc: Tero Kristo Cc: Sekhar Nori Cc: Nishanth Menon Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d413c3f0bd6fc515a2b8bff889b80728941d0d7c Author: Franck Demathieu Date: Thu Feb 23 10:48:55 2017 +0100 irqchip/crossbar: Fix incorrect type of local variables [ Upstream commit b28ace12661fbcfd90959c1e84ff5a85113a82a1 ] The max and entry variables are unsigned according to the dt-bindings. Fix following 3 sparse issues (-Wtypesign): drivers/irqchip/irq-crossbar.c:222:52: warning: incorrect type in argument 3 (different signedness) drivers/irqchip/irq-crossbar.c:222:52: expected unsigned int [usertype] *out_value drivers/irqchip/irq-crossbar.c:222:52: got int * drivers/irqchip/irq-crossbar.c:245:56: warning: incorrect type in argument 4 (different signedness) drivers/irqchip/irq-crossbar.c:245:56: expected unsigned int [usertype] *out_value drivers/irqchip/irq-crossbar.c:245:56: got int * drivers/irqchip/irq-crossbar.c:263:56: warning: incorrect type in argument 4 (different signedness) drivers/irqchip/irq-crossbar.c:263:56: expected unsigned int [usertype] *out_value drivers/irqchip/irq-crossbar.c:263:56: got int * Signed-off-by: Franck Demathieu Cc: marc.zyngier@arm.com Cc: jason@lakedaemon.net Link: http://lkml.kernel.org/r/20170223094855.6546-1-fdemathieu@gmail.com Signed-off-by: Thomas Gleixner Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bbb5f0062b74505e654bd516cb8114d54c4c2db1 Author: Arnd Bergmann Date: Wed Mar 1 10:15:29 2017 +0100 watchdog: kempld: fix gcc-4.3 build [ Upstream commit 3736d4eb6af37492aeded7fec0072dedd959c842 ] gcc-4.3 can't decide whether the constant value in kempld_prescaler[PRESCALER_21] is built-time constant or not, and gets confused by the logic in do_div(): drivers/watchdog/kempld_wdt.o: In function `kempld_wdt_set_stage_timeout': kempld_wdt.c:(.text.kempld_wdt_set_stage_timeout+0x130): undefined reference to `__aeabi_uldivmod' This adds a call to ACCESS_ONCE() to force it to not consider it to be constant, and leaves the more efficient normal case in place for modern compilers, using an #ifdef to annotate why we do this hack. Signed-off-by: Arnd Bergmann Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8b0be545deba980344915b67ee39dd6b5b0b2e76 Author: Peter Zijlstra Date: Wed Mar 1 16:23:30 2017 +0100 locking/lockdep: Add nest_lock integrity test [ Upstream commit 7fb4a2cea6b18dab56d609530d077f168169ed6b ] Boqun reported that hlock->references can overflow. Add a debug test for that to generate a clear error when this happens. Without this, lockdep is likely to report a mysterious failure on unlock. Reported-by: Boqun Feng Signed-off-by: Peter Zijlstra (Intel) Cc: Andrew Morton Cc: Chris Wilson Cc: Linus Torvalds Cc: Nicolai Hähnle Cc: Paul E. McKenney Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 43588be0735f78b4fbbcbae1e8234a5d4620c191 Author: Anoob Soman Date: Thu Mar 2 10:50:20 2017 +0000 xen-netback: Use GFP_ATOMIC to allocate hash [ Upstream commit 9f674e48c13dcbc31ac903433727837795b81efe ] Allocation of new_hash, inside xenvif_new_hash(), always happen in softirq context, so use GFP_ATOMIC instead of GFP_KERNEL for new hash allocation. Signed-off-by: Anoob Soman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ebbd5ac4acdbfd8e4286a96286b057e49287133a Author: Greg Kroah-Hartman Date: Thu Oct 19 14:55:29 2017 +0200 Revert "bsg-lib: don't free job in bsg_prepare_job" This reverts commit eb4375e1969c48d454998b2a284c2e6a5dc9eb68 which was commit f507b54dccfd8000c517d740bc45f20c74532d18 upstream. Ben reports: That function doesn't exist here (it was introduced in 4.13). Instead, this backport has modified bsg_create_job(), creating a leak. Please revert this on the 3.18, 4.4 and 4.9 stable branches. So I'm dropping it from here. Reported-by: Ben Hutchings Cc: Christoph Hellwig Cc: Ming Lei Cc: Jens Axboe Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org commit 0054c0bca32190ccaa283ecaef1c970e4610b7da Author: Matt Redfearn Date: Mon Jul 10 09:43:31 2017 +0100 MIPS: Fix minimum alignment requirement of IRQ stack commit 5fdc66e046206306bf61ff2d626bfa52ca087f7b upstream. Commit db8466c581cc ("MIPS: IRQ Stack: Unwind IRQ stack onto task stack") erroneously set the initial stack pointer of the IRQ stack to a value with a 4 byte alignment. The MIPS32 ABI requires that the minimum stack alignment is 8 byte, and the MIPS64 ABIs(n32/n64) require 16 byte minimum alignment. Fix IRQ_STACK_START such that it leaves space for the dummy stack frame (containing interrupted task kernel stack pointer) while also meeting minimum alignment requirements. Fixes: db8466c581cc ("MIPS: IRQ Stack: Unwind IRQ stack onto task stack") Reported-by: Darius Ivanauskas Signed-off-by: Matt Redfearn Cc: Chris Metcalf Cc: Petr Mladek Cc: Aaron Tomlin Cc: Jason A. Donenfeld Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/16760/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman