- 08 Nov, 2016 40 commits
-
-
Chris Wilson authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit 56a76c01 upstream. dma_buf_export() adds a reference to the owning module to the dmabuf (to prevent the driver from being unloaded whilst a third party still refers to the dmabuf). However, drm_gem_prime_export() was passing its own THIS_MODULE (i.e. drm.ko) rather than the driver. Extract the right owner from the device->fops instead. v2: Use C99 initializers to zero out unset elements of dma_buf_export_info v3: Extract the right module from dev->fops. Testcase: igt/vgem_basic/unload Reported-by:
Petri Latvala <petri.latvala@intel.com> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Petri Latvala <petri.latvala@intel.com> Cc: Christian König <christian.koenig@amd.com> Tested-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161005122145.1507-1-chris@chris-wilson.co.ukSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Tim Gardner <tim.gardner@canonical.com>
-
Balbir Singh authored
BugLink: http://bugs.launchpad.net/bugs/1632045 When PCI Device pass-through is enabled via VFIO, KVM-PPC will pin pages using get_user_pages_fast(). One of the downsides of the pinning is that the page could be in CMA region. The CMA region is used for other allocations like the hash page table. Ideally we want the pinned pages to be from non CMA region. This patch (currently only for KVM PPC with VFIO) forcefully migrates the pages out (huge pages are omitted for the moment). There are more efficient ways of doing this, but that might be elaborate and might impact a larger audience beyond just the kvm ppc implementation. The magic is in new_iommu_non_cma_page() which allocates the new page from a non CMA region. I've tested the patches lightly at my end. The full solution requires migration of THP pages in the CMA region. That work will be done incrementally on top of this. Signed-off-by:
Balbir Singh <bsingharora@gmail.com> Acked-by:
Alexey Kardashevskiy <aik@ozlabs.ru> [mpe: Merged via powerpc tree as that's where the changes are] Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> (cherry picked from commit 2e5bbb54) Signed-off-by:
Brad Figg <brad.figg@canonical.com> Acked-by:
Seth Forshee <seth.forshee@canonical.com>
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1637510Signed-off-by:
-
Dinesh Israni authored
BugLink: http://bugs.launchpad.net/bugs/1637510 commit 926317de 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 <nixon.vincent@calsoftinc.com> Tested-by:
Dinesh Israni <ddi@datera.io> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Nicholas Bellinger authored
BugLink: http://bugs.launchpad.net/bugs/1637510 commit 449a1378 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:
-
Nicholas Bellinger authored
BugLink: http://bugs.launchpad.net/bugs/1637510 commit 527268df 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 febe562c 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 <vst@datera.io> Tested-by:
-
Richard Weinberger authored
BugLink: http://bugs.launchpad.net/bugs/1637510 commit 843741c5 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 <richard@nod.at> Signed-off-by:
-
Taesoo Kim authored
BugLink: http://bugs.launchpad.net/bugs/1637510 commit 559cce69 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 <tsgatesv@gmail.com> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Reviewed-by:
Andreas Dilger <adilger@dilger.ca> Fixes: 6e4862a5Signed-off-by:
-
Eric Biggers authored
BugLink: http://bugs.launchpad.net/bugs/1637510 commit c4704a4f 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 <ebiggers@google.com> Signed-off-by:
-
Ulf Hansson authored
BugLink: http://bugs.launchpad.net/bugs/1637510 commit 4f48aa7a 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 <rrs@researchut.com> Tested-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Ulf Hansson authored
BugLink: http://bugs.launchpad.net/bugs/1637510 commit 31cf742f 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:
-
Jiri Slaby authored
BugLink: http://bugs.launchpad.net/bugs/1637510 commit 3f2d2664 upstream. Commit f68381a7 (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] <noident> drivers/mmc/card/block.c:1613:27: got restricted __le32 [usertype] <noident> ... So annotate cmd_hdr properly using __le32 to make everyone happy. Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Fixes: f68381a7 (mmc: block: fix packed command header endianness) Signed-off-by:
-
Frederic Barrat authored
BugLink: http://bugs.launchpad.net/bugs/1637510 commit d2cf909c 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: 73d16a6e ("powerpc/cell: Move data segment faulting code out of cell platform") Signed-off-by:
Frederic Barrat <fbarrat@linux.vnet.ibm.com> Acked-by:
Ian Munsie <imunsie@au1.ibm.com> Signed-off-by:
-
Nikolay Borisov authored
BugLink: http://bugs.launchpad.net/bugs/1637510 commit 0d7718f6 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 <kernel@kyup.com> Reviewed-by:
Yan, Zheng <zyan@redhat.com> Signed-off-by:
Ilya Dryomov <idryomov@gmail.com> Signed-off-by:
-
Marc Zyngier authored
BugLink: http://bugs.launchpad.net/bugs/1637510 commit 85054035 upstream. Commit f436b2ac ("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: f436b2ac ("arm64: kernel: fix architected PMU registers unconditional access") Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Will Deacon authored
BugLink: http://bugs.launchpad.net/bugs/1637510 commit 1e6e57d9 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: f97fc810 ("arm64: percpu: Implement this_cpu operations") Reviewed-by:
Mark Rutland <mark.rutland@arm.com> Tested-by:
-
Ulf Hansson authored
BugLink: http://bugs.launchpad.net/bugs/1637510 commit 9158cb29 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 <rrs@researchut.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Alan Stern authored
BugLink: http://bugs.launchpad.net/bugs/1637510 commit 796aa46a 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:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Jan Kara authored
BugLink: http://bugs.launchpad.net/bugs/1637510 commit a2ed0b39 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: 17b7f7cfReported-by:
Kent Overstreet <kent.overstreet@gmail.com> Reported-by:
Karel Zak <kzak@redhat.com> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Vladimir Murzin authored
BugLink: http://bugs.launchpad.net/bugs/1637510 commit 9224eb77 upstream. Entry Size in GITS_BASER<n> occupies 5 bits [52:48], but we mask out 8 bits. Fixes: cc2d3216 ("irqchip: GICv3: ITS command queue") Signed-off-by:
Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by:
-
David Hildenbrand authored
BugLink: http://bugs.launchpad.net/bugs/1637510 commit f0454029 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: 1b948d6c ("s390/mm,tlb: optimize TLB flushing for zEC12") Cc: stable@vger.kernel.org # 3.15+ Reported-by:
Sascha Silbe <silbe@linux.vnet.ibm.com> Acked-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
David Hildenbrand <dahi@linux.vnet.ibm.com> Signed-off-by:
-
Linus Torvalds authored
BugLink: http://bugs.launchpad.net/bugs/1637510 commit 21f54dda 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: 22f2ac51 ("mm: workingset: fix crash in shadow node shrinker caused by replace_page_cache_page()") Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Miklos Szeredi <miklos@szeredi.hu> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Michal Hocko <mhocko@suse.com> Signed-off-by:
-
Johannes Weiner authored
BugLink: http://bugs.launchpad.net/bugs/1637510 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> Cc: stable@vger.kernel.org Signed-off-by:
-
Johannes Weiner authored
BugLink: http://bugs.launchpad.net/bugs/1637510 commit 22f2ac51 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: 449dd698 ("mm: keep page cache radix tree nodes in check") Link: http://lkml.kernel.org/r/20160919155822.29498-1-hannes@cmpxchg.orgSigned-off-by:
Antonio SJ Musumeci <trapexit@spawn.link> Debugged-by:
Miklos Szeredi <miklos@szeredi.hu> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Vishal Verma authored
BugLink: http://bugs.launchpad.net/bugs/1637510 commit c09f1218 upstream. Commit 20985164 "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: 20985164 ("acpi: nfit: Add support for hot-add") Cc: <stable@vger.kernel.org> Cc: <linux-acpi@vger.kernel.org> Cc: Dan Williams <dan.j.williams@intel.com> Reported-by:
Linda Knippers <linda.knippers@hpe.com> Signed-off-by:
Vishal Verma <vishal.l.verma@intel.com> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
Jack Morgenstein authored
BugLink: http://bugs.launchpad.net/bugs/1637510 commit 6e522422 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: 8f7ba3ca ('net/mlx4: Add set VF mac address support') Signed-off-by:
Jack Morgenstein <jackm@dev.mellanox.co.il> Reported-by:
Moshe Levi <moshele@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Juerg Haefliger <juerg.haefliger@hpe.com> Signed-off-by:
-
Yuval Mintz authored
BugLink: http://bugs.launchpad.net/bugs/1637510 commit 1e6bb1a3 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 <andrew.patterson@hpe.com> Signed-off-by:
Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by:
-
Peter Jones authored
BugLink: http://bugs.launchpad.net/bugs/1637510 commit 7ee7014d 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 <pjones@redhat.com> Tested-by:
Dave Young <dyoung@redhat.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Don Brace authored
BugLink: http://bugs.launchpad.net/bugs/1637510 commit 64ce60ca 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 <scott.teel@microsemi.com> Reviewed-by:
Kevin Barnett <kevin.barnett@microsemi.com> Signed-off-by:
Don Brace <don.brace@microsemi.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Martin K. Petersen authored
BugLink: http://bugs.launchpad.net/bugs/1637510 commit 6b7e9cde 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: d0eb20a8 ("sd: Optimal I/O size is in bytes, not sectors") Reported-by:
Fam Zheng <famz@redhat.com> Reviewed-by:
Bart Van Assche <bart.vanassche@sandisk.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Tested-by:
-
Dan Carpenter authored
BugLink: http://bugs.launchpad.net/bugs/1637510 commit d102eb5c 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: a2c22510 ("irqchip: gic-v3: Refactor gic_enable_redist to support both enabling and disabling") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Sudeep Holla <sudeep.holla@arm.com> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: kernel-janitors@vger.kernel.org Cc: Jason Cooper <jason@lakedaemon.net> Link: http://lkml.kernel.org/r/20161014072534.GA15168@mwandaSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Jiri Slaby authored
BugLink: http://bugs.launchpad.net/bugs/1637510 commit 8678654e 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:
Paolo Bonzini <pbonzini@redhat.com> [Added x86 subject tag] Signed-off-by:
Radim Krčmář <rkrcmar@redhat.com> Signed-off-by:
-
Dan Williams authored
BugLink: http://bugs.launchpad.net/bugs/1637510 commit 23446cb6 upstream. Commit: 917db484 ("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 <david@fromorbit.com> Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Bart Van Assche authored
BugLink: http://bugs.launchpad.net/bugs/1637510 commit bbb427e3 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: 06b285bd ("blkcg: fix blkcg_policy_data allocation bug") Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Steve French authored
BugLink: http://bugs.launchpad.net/bugs/1637510 commit 24df1483 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 <smfrench@gmail.com> Acked-by:
Sachin Prabhu <sprabhu@redhat.com> Signed-off-by:
-
Steve French authored
BugLink: http://bugs.launchpad.net/bugs/1637510 commit 18dd8e1a 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 <steve.french@primarydata.com> Signed-off-by:
-
Steve French authored
BugLink: http://bugs.launchpad.net/bugs/1637510 commit fa70b87c upstream. GUIDs although random, and 16 bytes, need to be generated as proper uuids. Signed-off-by:
Aurelien Aptel <aaptel@suse.com> Reported-by:
David Goebels <davidgoe@microsoft.com> Signed-off-by:
-
Steve French authored
BugLink: http://bugs.launchpad.net/bugs/1637510 commit c2afb814 upstream. Signed-off-by:
-
Steve French authored
BugLink: http://bugs.launchpad.net/bugs/1637510 commit 9742805d 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:
Germano Percossi <germano.percossi@citrix.com> Signed-off-by:
-
Steve French authored
BugLink: http://bugs.launchpad.net/bugs/1637510 commit 3afca265 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:
Pavel Shilovsky <pshilov@microsoft.com> Reviewed-by:
-
