- 23 Feb, 2017 40 commits
-
-
Gerald Schaefer authored
commit 2247bb33 upstream. Patch series "mm/hugetlb: memory offline issues with hugepages", v4. This addresses several issues with hugepages and memory offline. While the first patch fixes a panic, and is therefore rather important, the last patch is just a performance optimization. The second patch fixes a theoretical issue with reserved hugepages, while still leaving some ugly usability issue, see description. This patch (of 3): dissolve_free_huge_pages() will either run into the VM_BUG_ON() or a list corruption and addressing exception when trying to set a memory block offline that is part (but not the first part) of a "gigantic" hugetlb page with a size > memory block size. When no other smaller hugetlb page sizes are present, the VM_BUG_ON() will trigger directly. In the other case we will run into an addressing exception later, because dissolve_free_huge_page() will not work on the head page of the compound hugetlb page which will result in a NULL hstate from page_hstate(). To fix this, first remove the VM_BUG_ON() because it is wrong, and then use the compound head page in dissolve_free_huge_page(). This means that an unused pre-allocated gigantic page that has any part of itself inside the memory block that is going offline will be dissolved completely. Losing an unused gigantic hugepage is preferable to failing the memory offline, for example in the situation where a (possibly faulty) memory DIMM needs to go offline. Fixes: c8721bbb ("mm: memory-hotplug: enable memory hotplug to handle hugepage") Link: http://lkml.kernel.org/r/20160926172811.94033-2-gerald.schaefer@de.ibm.comSigned-off-by:
Gerald Schaefer <gerald.schaefer@de.ibm.com> Acked-by:
Michal Hocko <mhocko@suse.com> Acked-by:
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Mike Kravetz <mike.kravetz@oracle.com> Cc: "Aneesh Kumar K . V" <aneesh.kumar@linux.vnet.ibm.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Rui Teng <rui.teng@linux.vnet.ibm.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> [bwh: Backported to 3.16: adjust context] Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Dmitry Torokhov authored
commit 62837b3c 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 <william.linna@gmail.com> Tested-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Bart Van Assche authored
commit 681cc360 upstream. Avoid that mapping an sg-list in which the first element has a non-zero offset triggers an infinite loop when using FMR. This patch makes the FMR mapping code similar to that of ib_sg_to_pages(). Note: older Mellanox HCAs do not support non-zero offsets for FMR. See also commit 8c4037b5 ("IB/srp: always avoid non-zero offsets into an FMR"). Reported-by:
Alex Estrin <alex.estrin@intel.com> Signed-off-by:
Bart Van Assche <bart.vanassche@sandisk.com> Signed-off-by:
Doug Ledford <dledford@redhat.com> [bwh: Backported to 3.16: adjust context] Signed-off-by:
-
Guenter Roeck authored
commit 35d04077 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: 6006c0d8 ("metag: Atomics, locks and bitops") Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
James Hogan <james.hogan@imgtec.com> Signed-off-by:
-
Eric Dumazet authored
commit d35c99ff upstream. Since linux-3.15, netlink_dump() can use up to 16384 bytes skb allocations. Due to struct skb_shared_info ~320 bytes overhead, we end up using order-3 (on x86) page allocations, that might trigger direct reclaim and add stress. The intent was really to attempt a large allocation but immediately fallback to a smaller one (order-1 on x86) in case of memory stress. On recent kernels (linux-4.4), we can remove __GFP_DIRECT_RECLAIM to meet the goal. Old kernels would need to remove __GFP_WAIT While we are at it, since we do an order-3 allocation, allow to use all the allocated bytes instead of 16384 to reduce syscalls during large dumps. iproute2 already uses 32KB recvmsg() buffer sizes. Alexei provided an initial patch downsizing to SKB_WITH_OVERHEAD(16384) Fixes: 9063e21f ("netlink: autosize skb lengthes") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
Alexei Starovoitov <ast@kernel.org> Cc: Greg Thelen <gthelen@google.com> Reviewed-by:
Greg Rose <grose@lightfleet.com> Acked-by:
David S. Miller <davem@davemloft.net> [bwh: Backported to 3.16: - Adjust context - Mask out __GFP_WAIT, as suggested] Signed-off-by:
-
Johannes Weiner authored
commit 3ddf40e8 upstream. Commit 22f2ac51 ("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: 22f2ac51 ("mm: workingset: fix crash in shadow node shrinker caused by replace_page_cache_page()") Signed-off-by:
Johannes Weiner <hannes@cmpxchg.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Miklos Szeredi <miklos@szeredi.hu> Signed-off-by:
-
Justin Maggard authored
commit c8475090 upstream. Add missing dmaengine_unmap_put(), so we don't OOM during RAID6 sync. Fixes: 1786b943 ("async_pq_val: convert to dmaengine_unmap_data") Signed-off-by:
Justin Maggard <jmaggard@netgear.com> Reviewed-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
Vinod Koul <vinod.koul@intel.com> Signed-off-by:
-
Lu Baolu authored
commit 8dcc5ff8 upstream. Member "status" of struct usb_sg_request is managed by usb core. A spin lock is used to serialize the change of it. The driver could check the value of req->status, but should avoid changing it without the hold of the spinlock. Otherwise, it could cause race or error in usb core. This patch could be backported to stable kernels with version later than v3.14. Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Roger Tseng <rogerable@realtek.com> Signed-off-by:
Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Dan Carpenter authored
commit 9a6dc644 upstream. set_bit() and clear_bit() take the bit number so this code is really doing "1 << (1 << irq)" which is a double shift bug. It's done consistently so it won't cause a problem unless "irq" is more than 4. Fixes: 70c6cce0 ('mfd: Support 88pm80x in 80x driver') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Uwe Kleine-König authored
commit 88003fb1 upstream. This fixes a compile failure: drivers/built-in.o: In function `wm8350_i2c_probe': core.c:(.text+0x828b0): undefined reference to `__devm_regmap_init_i2c' Makefile:953: recipe for target 'vmlinux' failed Fixes: 52b461b8 ("mfd: Add regmap cache support for wm8350") Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by:
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by:
-
Gavin Shan authored
commit 5adaf862 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: cee72d5b ("powerpc/powernv: Display diag data on p7ioc EEH errors") Signed-off-by:
Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Guilherme G Piccoli authored
commit edfc23ee upstream. Although rare, it's possible to hit PCI error early on device probe, meaning possibly some structs are not entirely initialized, and some might even be completely uninitialized, leading to NULL pointer dereference. The i40e driver currently presents a "bad" behavior if device hits such early PCI error: firstly, the struct i40e_pf might not be attached to pci_dev yet, leading to a NULL pointer dereference on access to pf->state. Even checking if the struct is NULL and avoiding the access in that case isn't enough, since the driver cannot recover from PCI error that early; in our experiments we saw multiple failures on kernel log, like: [549.664] i40e 0007:01:00.1: Initial pf_reset failed: -15 [549.664] i40e: probe of 0007:01:00.1 failed with error -15 [...] [871.644] i40e 0007:01:00.1: The driver for the device stopped because the device firmware failed to init. Try updating your NVM image. [871.644] i40e: probe of 0007:01:00.1 failed with error -32 [...] [872.516] i40e 0007:01:00.0: ARQ: Unknown event 0x0000 ignored Between the first probe failure (error -15) and the second (error -32) another PCI error happened due to the first bad probe. Also, driver started to flood console with those ARQ event messages. This patch will prevent these issues by allowing error recovery mechanism to remove the failed device from the system instead of trying to recover from early PCI errors during device probe. Signed-off-by:
Guilherme G Piccoli <gpiccoli@linux.vnet.ibm.com> Acked-by:
Jacob Keller <jacob.e.keller@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Richard Weinberger authored
commit f7d11b33 upstream. Usually Fastmap is free to consider every PEB in one of the pools as newer than the existing PEB. Since PEBs in a pool are by definition newer than everything else. But update_vol() missed the case that a pool can contain more than one candidate. Fixes: dbb7d2a8 ("UBI: Add fastmap core") Signed-off-by:
Richard Weinberger <richard@nod.at> Reviewed-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by:
-
Richard Weinberger authored
commit 2e8f08de upstream. When writing a new Fastmap the first thing that happens is refilling the pools in memory. At this stage it is possible that new PEBs from the new pools get already claimed and written with data. If this happens before the new Fastmap data structure hits the flash and we face power cut the freshly written PEB will not scanned and unnoticed. Solve the issue by locking the pools until Fastmap is written. Fixes: dbb7d2a8 ("UBI: Add fastmap core") Signed-off-by:
-
Richard Weinberger authored
commit 23654188 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: dbb7d2a8 ("UBI: Add fastmap core") Signed-off-by:
-
Boris Brezillon authored
commit ecbfa8ea upstream. scan_pool() does not mark the PEB for scrubing when bitflips are detected in the EC header of a free PEB (VID header region left to 0xff). Make sure we scrub the PEB in this case. Signed-off-by:
-
Wei Yongjun authored
commit 23bf4042 upstream. Fix following static checker warning: drivers/staging/rtl8188eu/os_dep/usb_intf.c:311 rtw_resume_process() error: double unlock 'mutex:&pwrpriv->mutex_lock' Fixes: eaf47b71 ("staging: rtl8188eu: fix missing unlock on error in rtw_resume_process()") Reported-By:
Wei Yongjun <weiyj.lk@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> [bwh: Backported to 3.16: - Adjust context - Unlock pwrctrl_priv::lock] Signed-off-by:
-
Wei Yongjun authored
commit eaf47b71 upstream. Add the missing unlock before return from function rtw_resume_process() in the error handling case. Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
-
Ondrej Mosnáček authored
commit 50d2e6dc upstream. The cipher block size for GCM is 16 bytes, and thus the CTR transform used in crypto_gcm_setkey() will also expect a 16-byte IV. However, the code currently reserves only 8 bytes for the IV, causing an out-of-bounds access in the CTR transform. This patch fixes the issue by setting the size of the IV buffer to 16 bytes. Fixes: 84c91152 ("[CRYPTO] gcm: Add support for async ciphers") Signed-off-by:
Ondrej Mosnacek <omosnacek@gmail.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Miklos Szeredi authored
commit cb3ae6d2 upstream. Make sure userspace filesystem is returning a well formed list of xattr names (zero or more nonzero length, null terminated strings). [Michael Theall: only verify in the nonzero size case] Signed-off-by:
Miklos Szeredi <mszeredi@redhat.com> [bwh: Backported to 3.16: adjust context, indentation] Signed-off-by:
-
Miklos Szeredi authored
commit a09f99ed upstream. Fuse allowed VFS to set mode in setattr in order to clear suid/sgid on chown and truncate, and (since writeback_cache) write. The problem with this is that it'll potentially restore a stale mode. The poper fix would be to let the filesystems do the suid/sgid clearing on the relevant operations. Possibly some are already doing it but there's no way we can detect this. So fix this by refreshing and recalculating the mode. Do this only if ATTR_KILL_S[UG]ID is set to not destroy performance for writes. This is still racy but the size of the window is reduced. Signed-off-by:
-
Miklos Szeredi authored
commit 5e2b8828 upstream. Without "default_permissions" the userspace filesystem's lookup operation needs to perform the check for search permission on the directory. If directory does not allow search for everyone (this is quite rare) then userspace filesystem has to set entry timeout to zero to make sure permissions are always performed. Changing the mode bits of the directory should also invalidate the (previously cached) dentry to make sure the next lookup will have a chance of updating the timeout, if needed. Reported-by:
Jean-Pierre André <jean-pierre.andre@wanadoo.fr> Signed-off-by:
-
Sascha Silbe authored
commit 6cd997db upstream. con3270 contains an optimisation that reduces the amount of data to be transmitted to the 3270 terminal by putting a Repeat to Address (RA) order into the data stream. The RA order itself takes up space, so con3270 only uses it if there's enough space left in the line buffer. Otherwise it just pads out the line manually. For lines that were _just_ short enough that the RA order still fit in the line buffer, the line was instead padded with an insufficient amount of spaces. This was caused by examining the size of the allocated line buffer rather than the length of the string to be displayed. For con3270_cline_end(), we just compare against the line length. For con3270_update_string() however that isn't available anymore, so we check whether the Repeat to Address order is present. Fixes: f51320a5 ("[PATCH] s390: new 3270 driver.") (tglx/history.git) Tested-by:
Jing Liu <liujbjl@linux.vnet.ibm.com> Tested-by:
Yang Chen <bjcyang@linux.vnet.ibm.com> Signed-off-by:
Sascha Silbe <silbe@linux.vnet.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Sascha Silbe authored
commit c14f2aac upstream. con3270 contains an optimisation that reduces the amount of data to be transmitted to the 3270 terminal by putting a Repeat to Address (RA) order into the data stream. The RA order itself takes up space, so con3270 only uses it if there's enough space left in the line buffer. Otherwise it just pads out the line manually. For lines too long to include the RA order, one byte was left uninitialised. This was caused by an off-by-one bug in the loop that pads out the line. Since the buffer is allocated from a common pool, the single byte left uninitialised contained some previous buffer content. Usually this was just a space or some character (which can result in clutter but is otherwise harmless). Sometimes, however, it was a Repeat to Address order, messing up the entire screen layout and causing the display to send the entire buffer content on every keystroke. Fixes: f51320a5 ("[PATCH] s390: new 3270 driver.") (tglx/history.git) Reported-by:
-
gmail authored
commit e81d4477 upstream. The commit 6050d47a: "ext4: bail out from make_indexed_dir() on first error" could end up leaking bh2 in the error path. [ Also avoid renaming bh2 to bh, which just confuses things --tytso ] Signed-off-by:
yangsheng <yngsion@gmail.com> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> [bwh: Backported to 3.16: adjust context] Signed-off-by:
-
Anton Blanchard authored
commit 5045ea37 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: a7f290da ("[PATCH] powerpc: Merge vdso's and add vdso support to 32 bits kernel") Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
-
Alex Deucher authored
commit 42792029 upstream. Used the wrong index to setup the phase shedding mask. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> [bwh: Backported to 3.16: adjust context, indentation] Signed-off-by:
-
Greg Kroah-Hartman authored
commit ab21b63e upstream. This reverts commit e6c7efdc. Turns out it was totally wrong. The memory is supposed to be bound to the kref, as the original code was doing correctly, not the device/driver binding as the devm_kzalloc() would cause. This fixes an oops when read would be called after the device was unbound from the driver. Reported-by:
Ladislav Michl <ladis@linux-mips.org> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Trond Myklebust authored
commit 304020fe 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 <trond.myklebust@primarydata.com> Tested-by:
Oleg Drokin <green@linuxhacker.ru> Signed-off-by:
Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by:
-
Kyle Jones authored
commit decc5360 upstream. Signed-off-by:
Kyle Jones <kyle@kf5jwc.us> Signed-off-by:
-
Thomas Huth authored
commit fa73c3b2 upstream. The MMCR2 register is available twice, one time with number 785 (privileged access), and one time with number 769 (unprivileged, but it can be disabled completely). In former times, the Linux kernel was using the unprivileged register 769 only, but since commit 8dd75ccb ("powerpc: Use privileged SPR number for MMCR2"), it uses the privileged register 785 instead. The KVM-PR code then of course also switched to use the SPR 785, but this is causing older guest kernels to crash, since these kernels still access 769 instead. So to support older kernels with KVM-PR again, we have to support register 769 in KVM-PR, too. Fixes: 8dd75ccbSigned-off-by:
Thomas Huth <thuth@redhat.com> Signed-off-by:
Paul Mackerras <paulus@ozlabs.org> Signed-off-by:
-
Dan Carpenter authored
commit ac0e89bb upstream. We use logical negate where bitwise negate was intended. It means that we never return -EINVAL here. Fixes: ce11e48b ('KVM: PPC: E500: Add userspace debug stub support') Signed-off-by:
Alexander Graf <agraf@suse.de> Signed-off-by:
-
Paul Mackerras authored
commit 88b02cf9 upstream. POWER8 has one virtual timebase (VTB) register per subcore, not one per CPU thread. The HV KVM code currently treats VTB as a per-thread register, which can lead to spurious soft lockup messages from guests which use the VTB as the time source for the soft lockup detector. (CPUs before POWER8 did not have the VTB register.) For HV KVM, this fixes the problem by making only the primary thread in each virtual core save and restore the VTB value. With this, the VTB state becomes part of the kvmppc_vcore structure. This also means that "piggybacking" of multiple virtual cores onto one subcore is not possible on POWER8, because then the virtual cores would share a single VTB register. PR KVM emulates a VTB register, which is per-vcpu because PR KVM has no notion of CPU threads or SMT. For PR KVM we move the VTB state into the kvmppc_vcpu_book3s struct. Reported-by:
-
Daniel Glöckner authored
commit 0ed50abb 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 <dg@emlix.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Nicholas Mc Guire authored
commit 41f469ca upstream. wait_for_completion_timeout_interruptible returns long not unsigned long so dma_time, which is used exclusively here, is changed to long. Fixes: 1b66e94e ("mmc: moxart: Add MOXA ART SD/MMC driver") Signed-off-by:
Nicholas Mc Guire <hofrat@osadl.org> Signed-off-by:
-
Hui Wang authored
commit 392c9da2 upstream. We have two new Dell laptop models, they have the same ALC255 pin definition, but not in the pin quirk table yet, as a result, the headset microphone can't work. After adding the definition in the table, the headset microphone works well. Signed-off-by:
Hui Wang <hui.wang@canonical.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Jan Remmet authored
commit 8f9165c9 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 <j.remmet@phytec.de> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Bart Van Assche authored
commit 55679c8d upstream. Avoid that sparse complains about blkg_hint manipulations. Fixes: a637120e ("blkcg: use radix tree to index blkgs from blkcg") Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
Jens Axboe <axboe@fb.com> [bwh: Backported to 3.16: adjust filename] Signed-off-by:
-
Chuck Lever authored
commit cace564f upstream. The ctxt's count field is overloaded to mean the number of pages in the ctxt->page array and the number of SGEs in the ctxt->sge array. Typically these two numbers are the same. However, when an inline RPC reply is constructed from an xdr_buf with a tail iovec, the head and tail often occupy the same page, but each are DMA mapped independently. In that case, ->count equals the number of pages, but it does not equal the number of SGEs. There's one more SGE, for the tail iovec. Hence there is one more DMA mapping than there are pages in the ctxt->page array. This isn't a real problem until the server's iommu is enabled. Then each RPC reply that has content in that iovec orphans a DMA mapping that consists of real resources. krb5i and krb5p always populate that tail iovec. After a couple million sent krb5i/p RPC replies, the NFS server starts behaving erratically. Reboot is needed to clear the problem. Fixes: 9d11b51c ("svcrdma: Fix send_reply() scatter/gather set-up") Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> [bwh: Backported to 3.16: - Adjust context - Drop changes to svc_rdma_bc_sendto() - s/xprt->sc_pd->local_dma_lkey/xprt->sc_dma_lkey/ Signed-off-by:
-
Laura Garcia Liebana authored
commit 36b701fa upstream. Fetch value and validate u32 netlink attribute. This validation is usually required when the u32 netlink attributes are being stored in a field whose size is smaller. This patch revisits 4da449ae ("netfilter: nft_exthdr: Add size check on u8 nft_exthdr attributes"). Fixes: 96518518 ("netfilter: add nftables") Suggested-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
Laura Garcia Liebana <nevola@gmail.com> Signed-off-by:
-
