- 18 7月, 2017 4 次提交
-
-
由 Tom Lendacky 提交于
Since video memory needs to be accessed decrypted, be sure that the memory encryption mask is not set for the video ranges. Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com> Reviewed-by: NThomas Gleixner <tglx@linutronix.de> Reviewed-by: NBorislav Petkov <bp@suse.de> Cc: Alexander Potapenko <glider@google.com> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Borislav Petkov <bp@alien8.de> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Dave Young <dyoung@redhat.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Larry Woodman <lwoodman@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Rik van Riel <riel@redhat.com> Cc: Toshimitsu Kani <toshi.kani@hpe.com> Cc: kasan-dev@googlegroups.com Cc: kvm@vger.kernel.org Cc: linux-arch@vger.kernel.org Cc: linux-doc@vger.kernel.org Cc: linux-efi@vger.kernel.org Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/a19436f30424402e01f63a09b32ab103272acced.1500319216.git.thomas.lendacky@amd.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Tom Lendacky 提交于
The IOMMU is programmed with physical addresses for the various tables and buffers that are used to communicate between the device and the driver. When the driver allocates this memory it is encrypted. In order for the IOMMU to access the memory as encrypted the encryption mask needs to be included in these physical addresses during configuration. The PTE entries created by the IOMMU should also include the encryption mask so that when the device behind the IOMMU performs a DMA, the DMA will be performed to encrypted memory. Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com> Reviewed-by: NThomas Gleixner <tglx@linutronix.de> Reviewed-by: NBorislav Petkov <bp@suse.de> Acked-by: NJoerg Roedel <jroedel@suse.de> Cc: <iommu@lists.linux-foundation.org> Cc: Alexander Potapenko <glider@google.com> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Borislav Petkov <bp@alien8.de> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Dave Young <dyoung@redhat.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Larry Woodman <lwoodman@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Rik van Riel <riel@redhat.com> Cc: Toshimitsu Kani <toshi.kani@hpe.com> Cc: kasan-dev@googlegroups.com Cc: kvm@vger.kernel.org Cc: linux-arch@vger.kernel.org Cc: linux-doc@vger.kernel.org Cc: linux-efi@vger.kernel.org Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/3053631ea25ba8b1601c351cb7c541c496f6d9bc.1500319216.git.thomas.lendacky@amd.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Tom Lendacky 提交于
Add a function that will determine if a supplied physical address matches the address of an EFI table. Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com> Reviewed-by: NThomas Gleixner <tglx@linutronix.de> Reviewed-by: NMatt Fleming <matt@codeblueprint.co.uk> Reviewed-by: NBorislav Petkov <bp@suse.de> Cc: Alexander Potapenko <glider@google.com> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Borislav Petkov <bp@alien8.de> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Dave Young <dyoung@redhat.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Larry Woodman <lwoodman@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Rik van Riel <riel@redhat.com> Cc: Toshimitsu Kani <toshi.kani@hpe.com> Cc: kasan-dev@googlegroups.com Cc: kvm@vger.kernel.org Cc: linux-arch@vger.kernel.org Cc: linux-doc@vger.kernel.org Cc: linux-efi@vger.kernel.org Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/e1e06441d80f44776df391e0e4cb485b345b7518.1500319216.git.thomas.lendacky@amd.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Tom Lendacky 提交于
The ioremap() function is intended for mapping MMIO. For RAM, the memremap() function should be used. Convert calls from ioremap() to memremap() when re-mapping RAM. This will be used later by SME to control how the encryption mask is applied to memory mappings, with certain memory locations being mapped decrypted vs encrypted. Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com> Reviewed-by: NThomas Gleixner <tglx@linutronix.de> Reviewed-by: NBorislav Petkov <bp@suse.de> Cc: Alexander Potapenko <glider@google.com> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Borislav Petkov <bp@alien8.de> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Dave Young <dyoung@redhat.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Larry Woodman <lwoodman@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Rik van Riel <riel@redhat.com> Cc: Toshimitsu Kani <toshi.kani@hpe.com> Cc: kasan-dev@googlegroups.com Cc: kvm@vger.kernel.org Cc: linux-arch@vger.kernel.org Cc: linux-doc@vger.kernel.org Cc: linux-efi@vger.kernel.org Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/b13fccb9abbd547a7eef7b1fdfc223431b211c88.1500319216.git.thomas.lendacky@amd.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
- 17 7月, 2017 1 次提交
-
-
由 minimumlaw@rambler.ru 提交于
Fixes: cc5d0db3 ("regmap: Add 1-Wire bus support") Commit de0d6dbd ("w1: Add subsystem kernel public interface") Fix place off w1.h header file Cosmetic: Fix company name (local to international) Signed-off-by: NAlex A. Mihaylov <minimumlaw@rambler.ru> Signed-off-by: NMark Brown <broonie@kernel.org>
-
- 16 7月, 2017 2 次提交
-
-
Avoid the READ_ONCE in commit 4a072c71 ("random: silence compiler warnings and fix race") if we can leave the function after arch_get_random_XXX(). Cc: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
-
由 Theodore Ts'o 提交于
Unfortunately, on some models of some architectures getting a fully seeded CRNG is extremely difficult, and so this can result in dmesg getting spammed for a surprisingly long time. This is really bad from a security perspective, and so architecture maintainers really need to do what they can to get the CRNG seeded sooner after the system is booted. However, users can't do anything actionble to address this, and spamming the kernel messages log will only just annoy people. For developers who want to work on improving this situation, CONFIG_WARN_UNSEEDED_RANDOM has been renamed to CONFIG_WARN_ALL_UNSEEDED_RANDOM. By default the kernel will always print the first use of unseeded randomness. This way, hopefully the security obsessed will be happy that there is _some_ indication when the kernel boots there may be a potential issue with that architecture or subarchitecture. To see all uses of unseeded randomness, developers can enable CONFIG_WARN_ALL_UNSEEDED_RANDOM. Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
-
- 14 7月, 2017 1 次提交
-
-
由 Jeffy Chen 提交于
DRM_IOCTL_VERSION is supposed to update the name_len/date_len/desc_len fields to user. Fixes: 012c6741 ("switch compat_drm_version() to drm_ioctl_kernel()") Signed-off-by: NJeffy Chen <jeffy.chen@rock-chips.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 13 7月, 2017 32 次提交
-
-
由 Chris Brandt 提交于
The existing code gives an incorrect pointer value. The buffer pointer 'buf' was of type unsigned short *, and 'count' was a number in bytes. A cast of buf should have been used. However, instead of casting, just change the code to use u32 pointers. Reported-by: NDan Carpenter <dan.carpenter@oracle.com> Fixes: 8185e51f: ("mmc: tmio-mmc: add support for 32bit data port") Signed-off-by: NChris Brandt <chris.brandt@renesas.com> Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be> Acked-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Cc: <stable@vger.kernel.org> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Grzegorz Sluja 提交于
The commit 304419d8 ("mmc: core: Allocate per-request data using the block layer core"), refactored the mechanism of queue handling, but also made mmc_init_request() to be called after mmc_cleanup_queue(). This triggers a null pointer dereference: [ 683.123791] BUG: unable to handle kernel NULL pointer dereference at (null) [ 683.123801] IP: mmc_init_request+0x2c/0xf0 [mmc_block] ... [ 683.123905] Call Trace: [ 683.123913] alloc_request_size+0x4f/0x70 [ 683.123919] mempool_alloc+0x5f/0x150 [ 683.123925] ? __enqueue_entity+0x6c/0x70 [ 683.123928] get_request+0x3ad/0x720 [ 683.123933] ? prepare_to_wait_event+0x110/0x110 [ 683.123937] blk_queue_bio+0xc1/0x3a0 [ 683.123940] generic_make_request+0xf8/0x2a0 [ 683.123942] submit_bio+0x75/0x150 [ 683.123947] submit_bio_wait+0x51/0x70 [ 683.123951] blkdev_issue_flush+0x5c/0x90 [ 683.123956] ext4_sync_fs+0x171/0x1b0 [ 683.123961] sync_filesystem+0x73/0x90 [ 683.123965] fsync_bdev+0x24/0x50 [ 683.123971] invalidate_partition+0x24/0x50 [ 683.123973] del_gendisk+0xb2/0x2a0 [ 683.123977] mmc_blk_remove_req.part.38+0x71/0xa0 [mmc_block] [ 683.123980] mmc_blk_remove+0xba/0x190 [mmc_block] [ 683.123990] mmc_bus_remove+0x1a/0x20 [mmc_core] [ 683.123995] device_release_driver_internal+0x141/0x200 [ 683.123999] device_release_driver+0x12/0x20 [ 683.124001] bus_remove_device+0xfd/0x170 [ 683.124004] device_del+0x1e8/0x330 [ 683.124012] mmc_remove_card+0x60/0xc0 [mmc_core] [ 683.124019] mmc_remove+0x19/0x30 [mmc_core] [ 683.124025] mmc_stop_host+0xfb/0x1a0 [mmc_core] [ 683.124032] mmc_remove_host+0x1a/0x40 [mmc_core] [ 683.124037] sdhci_remove_host+0x2e/0x1c0 [mmc_sdhci] [ 683.124042] sdhci_pci_remove_slot+0x3f/0x80 [sdhci_pci] [ 683.124045] sdhci_pci_remove+0x39/0x70 [sdhci_pci] [ 683.124049] pci_device_remove+0x39/0xc0 [ 683.124052] device_release_driver_internal+0x141/0x200 [ 683.124056] driver_detach+0x3f/0x80 [ 683.124059] bus_remove_driver+0x55/0xd0 [ 683.124062] driver_unregister+0x2c/0x50 [ 683.124065] pci_unregister_driver+0x29/0x90 [ 683.124069] sdhci_driver_exit+0x10/0x4f3 [sdhci_pci] [ 683.124073] SyS_delete_module+0x171/0x250 [ 683.124078] entry_SYSCALL_64_fastpath+0x1e/0xa9 Fix this by setting the queue DYING flag before cleanup the queue, as it prevents new reqs from entering the queue. Signed-off-by: NGrzegorz Sluja <grzegorzx.sluja@intel.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org> Fixes: 304419d8 ("mmc: core: Allocate per-request data using the...") [Ulf: Updated the changelog] Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Rafael J. Wysocki 提交于
Commit 76cde7e4 (PCI / PM: Make PCIe PME interrupts wake up from suspend-to-idle) went too far with preventing pcie_pme_work_fn() from clearing the root port's PME Status and re-enabling the PME interrupt which should be done for PMEs to work correctly after system resume. The failing scenario is as follows: 1. pcie_pme_suspend() finds that the PME IRQ should be designated for system wakeup, so it calls enable_irq_wake() and then sets data->suspend_level to PME_SUSPEND_WAKEUP. 2. PME interrupt happens at this point. 3. pcie_pme_irq() runs, disables the PME interrupt and queues up the execution of pcie_pme_work_fn(). 4. pcie_pme_work_fn() runs before pcie_pme_resume() and breaks out of the loop right away, because data->suspend_level is not PME_SUSPEND_NONE, and it doesn't re-enable the PME interrupt for the same reason. 5. pcie_pme_resume() runs and simply calls disable_irq_wake() without re-enabling the PME interrupt (because data->suspend_level is not PME_SUSPEND_NONE), so the PME interrupt remains disabled and the PME Status remains set. To fix this notice that there is no reason why pcie_pme_work_fn() should behave in a special way during system resume if the PME interrupt is not disabled by pcie_pme_suspend() and partially revert commit 76cde7e4 and restore the previous (and correct) behavior of pcie_pme_work_fn(). Fixes: 76cde7e4 (PCI / PM: Make PCIe PME interrupts wake up from suspend-to-idle) Reported-and-tested-by: NNaresh Solanki <naresh.solanki@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Joe Perches 提交于
Make the code like the rest of the kernel. Link: http://lkml.kernel.org/r/bc5927726abc70d7c066df7ab4cb7cfce4a7b577.1499284835.git.joe@perches.comSigned-off-by: NJoe Perches <joe@perches.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Joe Perches 提交于
Make the code like the rest of the kernel. But there is an oddity here because the inline should probably be removed. It's an extern function in intelfb.h and it is used in intelfbdrv.c and intelfbhw.c. The inline is kept here as I suppose it's possible for some compiler to make the uses inline in intelfbdrv and and also create an external function for intelfbhw. Link: http://lkml.kernel.org/r/8ba151a1fdc84e42cbf4aafc798513c0158edee1.1499284835.git.joe@perches.comSigned-off-by: NJoe Perches <joe@perches.com> Cc: Maik Broemme <mbroemme@libmpq.org> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Joe Perches 提交于
Make the code like the rest of the kernel. Also use inline instead of __inline__. Link: http://lkml.kernel.org/r/a5072b74b6c293e6ec93c4900482e9d3267f15b2.1499284835.git.joe@perches.comSigned-off-by: NJoe Perches <joe@perches.com> Cc: Johan Hovold <johan@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Joe Perches 提交于
Make the code like the rest of the kernel. Link: http://lkml.kernel.org/r/55d3e89d50bb03d603bfb28019fab07f48bdc714.1499284835.git.joe@perches.comSigned-off-by: NJoe Perches <joe@perches.com> Cc: Pat Gefre <pfg@sgi.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jslaby@suse.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Joe Perches 提交于
Make the code like the rest of the kernel. Link: http://lkml.kernel.org/r/3f980cd89084ae09716353aba3171e4b3815e690.1499284835.git.joe@perches.comSigned-off-by: NJoe Perches <joe@perches.com> Cc: Julian Wiedmann <jwi@linux.vnet.ibm.com> Cc: Ursula Braun <ubraun@linux.vnet.ibm.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Michal Hocko 提交于
Commit 24f8e00a ("drm/i915: Prefer to report ENOMEM rather than incur the oom for gfx allocations") has tried to remove disruptive OOM killer because the userspace should be able to cope with allocation failures. At the time only __GFP_NORETRY could achieve that and it turned out that this would fail the allocations just too easily. So "drm/i915: Remove __GFP_NORETRY from our buffer allocator" removed it and hoped for a better solution. __GFP_RETRY_MAYFAIL is that solution. It will keep retrying the allocation until there is no more progress and we would go OOM. Instead we fail the allocation and let the caller to deal with it. Link: http://lkml.kernel.org/r/20170623085345.11304-6-mhocko@kernel.orgSigned-off-by: NMichal Hocko <mhocko@suse.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Alex Belits <alex.belits@cavium.com> Cc: Christoph Hellwig <hch@infradead.org> Cc: Darrick J. Wong <darrick.wong@oracle.com> Cc: David Daney <david.daney@cavium.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Mel Gorman <mgorman@suse.de> Cc: NeilBrown <neilb@suse.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Vlastimil Babka <vbabka@suse.cz> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Michal Hocko 提交于
__GFP_REPEAT was designed to allow retry-but-eventually-fail semantic to the page allocator. This has been true but only for allocations requests larger than PAGE_ALLOC_COSTLY_ORDER. It has been always ignored for smaller sizes. This is a bit unfortunate because there is no way to express the same semantic for those requests and they are considered too important to fail so they might end up looping in the page allocator for ever, similarly to GFP_NOFAIL requests. Now that the whole tree has been cleaned up and accidental or misled usage of __GFP_REPEAT flag has been removed for !costly requests we can give the original flag a better name and more importantly a more useful semantic. Let's rename it to __GFP_RETRY_MAYFAIL which tells the user that the allocator would try really hard but there is no promise of a success. This will work independent of the order and overrides the default allocator behavior. Page allocator users have several levels of guarantee vs. cost options (take GFP_KERNEL as an example) - GFP_KERNEL & ~__GFP_RECLAIM - optimistic allocation without _any_ attempt to free memory at all. The most light weight mode which even doesn't kick the background reclaim. Should be used carefully because it might deplete the memory and the next user might hit the more aggressive reclaim - GFP_KERNEL & ~__GFP_DIRECT_RECLAIM (or GFP_NOWAIT)- optimistic allocation without any attempt to free memory from the current context but can wake kswapd to reclaim memory if the zone is below the low watermark. Can be used from either atomic contexts or when the request is a performance optimization and there is another fallback for a slow path. - (GFP_KERNEL|__GFP_HIGH) & ~__GFP_DIRECT_RECLAIM (aka GFP_ATOMIC) - non sleeping allocation with an expensive fallback so it can access some portion of memory reserves. Usually used from interrupt/bh context with an expensive slow path fallback. - GFP_KERNEL - both background and direct reclaim are allowed and the _default_ page allocator behavior is used. That means that !costly allocation requests are basically nofail but there is no guarantee of that behavior so failures have to be checked properly by callers (e.g. OOM killer victim is allowed to fail currently). - GFP_KERNEL | __GFP_NORETRY - overrides the default allocator behavior and all allocation requests fail early rather than cause disruptive reclaim (one round of reclaim in this implementation). The OOM killer is not invoked. - GFP_KERNEL | __GFP_RETRY_MAYFAIL - overrides the default allocator behavior and all allocation requests try really hard. The request will fail if the reclaim cannot make any progress. The OOM killer won't be triggered. - GFP_KERNEL | __GFP_NOFAIL - overrides the default allocator behavior and all allocation requests will loop endlessly until they succeed. This might be really dangerous especially for larger orders. Existing users of __GFP_REPEAT are changed to __GFP_RETRY_MAYFAIL because they already had their semantic. No new users are added. __alloc_pages_slowpath is changed to bail out for __GFP_RETRY_MAYFAIL if there is no progress and we have already passed the OOM point. This means that all the reclaim opportunities have been exhausted except the most disruptive one (the OOM killer) and a user defined fallback behavior is more sensible than keep retrying in the page allocator. [akpm@linux-foundation.org: fix arch/sparc/kernel/mdesc.c] [mhocko@suse.com: semantic fix] Link: http://lkml.kernel.org/r/20170626123847.GM11534@dhcp22.suse.cz [mhocko@kernel.org: address other thing spotted by Vlastimil] Link: http://lkml.kernel.org/r/20170626124233.GN11534@dhcp22.suse.cz Link: http://lkml.kernel.org/r/20170623085345.11304-3-mhocko@kernel.orgSigned-off-by: NMichal Hocko <mhocko@suse.com> Acked-by: NVlastimil Babka <vbabka@suse.cz> Cc: Alex Belits <alex.belits@cavium.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Christoph Hellwig <hch@infradead.org> Cc: Darrick J. Wong <darrick.wong@oracle.com> Cc: David Daney <david.daney@cavium.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Mel Gorman <mgorman@suse.de> Cc: NeilBrown <neilb@suse.com> Cc: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Kees Cook 提交于
This fixes a over-read condition detected by FORTIFY_SOURCE for this line: memcpy(SKB_TO_PKT(skb), &ack_pkt, sizeof(skb->cb)); The error was: In file included from ./include/linux/bitmap.h:8:0, from ./include/linux/cpumask.h:11, from ./include/linux/mm_types_task.h:13, from ./include/linux/mm_types.h:4, from ./include/linux/kmemcheck.h:4, from ./include/linux/skbuff.h:18, from drivers/infiniband/sw/rxe/rxe_resp.c:34: In function 'memcpy', inlined from 'send_atomic_ack.constprop' at drivers/infiniband/sw/rxe/rxe_resp.c:998:2, inlined from 'acknowledge' at drivers/infiniband/sw/rxe/rxe_resp.c:1026:3, inlined from 'rxe_responder' at drivers/infiniband/sw/rxe/rxe_resp.c:1286:10: ./include/linux/string.h:309:4: error: call to '__read_overflow2' declared with attribute error: detected read beyond size of object passed as 2nd parameter __read_overflow2(); Daniel Micay noted that struct rxe_pkt_info is 32 bytes on 32-bit architectures, but skb->cb is still 64. The memcpy() over-reads 32 bytes. This fixes it by zeroing the unused bytes in skb->cb. Link: http://lkml.kernel.org/r/1497903987-21002-5-git-send-email-keescook@chromium.orgSigned-off-by: NKees Cook <keescook@chromium.org> Cc: Moni Shoua <monis@mellanox.com> Cc: Doug Ledford <dledford@redhat.com> Cc: Sean Hefty <sean.hefty@intel.com> Cc: Daniel Micay <danielmicay@gmail.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Kees Cook 提交于
This avoids CONFIG_FORTIFY_SOURCE from being enabled during the EFI stub build, as adding a panic() implementation may not work well. This can be adjusted in the future. Link: http://lkml.kernel.org/r/1497903987-21002-2-git-send-email-keescook@chromium.orgSigned-off-by: NKees Cook <keescook@chromium.org> Suggested-by: NDaniel Micay <danielmicay@gmail.com> Reviewed-by: NArd Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: NMark Rutland <mark.rutland@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Kees Cook 提交于
The add_device_randomness() function would ignore incoming bytes if the crng wasn't ready. This additionally makes sure to make an early enough call to add_latent_entropy() to influence the initial stack canary, which is especially important on non-x86 systems where it stays the same through the life of the boot. Link: http://lkml.kernel.org/r/20170626233038.GA48751@beastSigned-off-by: NKees Cook <keescook@chromium.org> Cc: "Theodore Ts'o" <tytso@mit.edu> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jessica Yu <jeyu@redhat.com> Cc: Steven Rostedt (VMware) <rostedt@goodmis.org> Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: Tejun Heo <tj@kernel.org> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Lokesh Vutla <lokeshvutla@ti.com> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: AKASHI Takahiro <takahiro.akashi@linaro.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 LABBE Corentin 提交于
Since internal phy-mode is reserved for non-xMII protocol we cannot use it with dwmac-sun8i. Furthermore, all DT patchs which comes with this patch were cleaned, so the current state is broken. This reverts commit 1c2fa5f8 ("net: stmmac: support future possible different internal phy mode") Fixes: 1c2fa5f8 ("net: stmmac: support future possible different internal phy mode") Signed-off-by: NCorentin Labbe <clabbe.montjoie@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Bert Kenward 提交于
If we have more than 32 unicast MAC addresses assigned to an interface we will read beyond the end of the address table in the driver when adding filters. The next 256 entries store multicast addresses, so we will end up attempting to insert duplicate filters, which is mostly harmless. If we add more than 288 unicast addresses we will then read past the multicast address table, which is likely to be more exciting. Fixes: 12fb0da4 ("sfc: clean fallbacks between promisc/normal in efx_ef10_filter_sync_rx_mode") Signed-off-by: NBert Kenward <bkenward@solarflare.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Alexey Khoroshilov 提交于
There is no check for return code of smsc911x_drv_probe() in smsc911x_drv_probe(). The patch adds one. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: NAlexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Dan Carpenter 提交于
This patch is basically to silence a static checker warning. drivers/scsi/libfc/fc_disc.c:326 fc_disc_error() warn: passing a valid pointer to 'PTR_ERR' It doesn't affect runtime because it treats -ENOMEM and a valid pointer the same. But the documentation says we should be passing an error pointer. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Acked-by: NJohannes Thumshirn <jth@kernel.org> Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
-
由 Colin Ian King 提交于
Don't populate various tables on the stack but make them static const. Makes the object code smaller by over 280 bytes: Before: text data bss dec hex filename 39887 5080 64 45031 afe7 hisi_sas_v2_hw.o After: text data bss dec hex filename 39318 5368 64 44750 aece hisi_sas_v2_hw.o Signed-off-by: NColin Ian King <colin.king@canonical.com> Acked-by: NJohn Garry <john.garry@huawei.com> Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
-
由 Dan Carpenter 提交于
There are "req->num_outstanding_cmds" elements in the req->outstanding_cmds[] array so the > here should be >=. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Reviewed-by: NNicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
-
由 Johannes Thumshirn 提交于
SG_DXFER_FROM_DEV transfers do not necessarily have a dxferp as we set it to NULL for the old sg_io read/write interface, but must have a length bigger than 0. This fixes a regression introduced by commit 28676d86 ("scsi: sg: check for valid direction before starting the request") Signed-off-by: NJohannes Thumshirn <jthumshirn@suse.de> Fixes: 28676d86 ("scsi: sg: check for valid direction before starting the request") Reported-by: NChris Clayton <chris2553@googlemail.com> Tested-by: NChris Clayton <chris2553@googlemail.com> Cc: Douglas Gilbert <dgilbert@interlog.com> Reviewed-by: NHannes Reinecke <hare@suse.com> Tested-by: NChris Clayton <chris2553@googlemail.com> Acked-by: NDouglas Gilbert <dgilbert@interlog.com> Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
-
由 Paolo Bonzini 提交于
Multi-queue virtio-scsi uses a different scsi_host_template struct. Add the .device_alloc field there, too. Fixes: 25d1d50e Cc: stable@vger.kernel.org Cc: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NFam Zheng <famz@redhat.com> Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com> Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
-
由 Colin Ian King 提交于
Trivial fix to spelling mistake in QEDF_INFO message and remove duplicated "since" (thanks to Tyrel Datwyler for spotting the latter issue). Signed-off-by: NColin Ian King <colin.king@canonical.com> Acked-by: NChad Dupuis <chad.dupuis@cavium.com> Reviewed-by: NTyrel Datwyler <tyreld@linux.vnet.ibm.com> Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
-
由 Colin Ian King 提交于
Trivial fix to spelling mistake in QEDF_ERR message. I should have also included this in a previous fix, but I only just spotted this one. Signed-off-by: NColin Ian King <colin.king@canonical.com> Acked-by: NManish Rangankar <Manish.Rangankar@cavium.com> Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
-
由 Colin Ian King 提交于
There are a couple of typos in function names and spelling of request where the letters u and e are swapped: scu_ssp_reqeust_construct_task_context scu_sata_reqeust_construct_task_context Fix the spelling of request. Signed-off-by: NColin Ian King <colin.king@canonical.com> Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
-
由 Rafael J. Wysocki 提交于
Commit dc15e71e (PCI / PM: Restore PME Enable if skipping wakeup setup) introduced a mechanism by which the PME Enable bit can be restored by pci_enable_wake() if dev->wakeup_prepared is set in case it has been overwritten by PCI config space restoration. However, that commit overlooked the fact that on some systems (Dell XPS13 9360 in particular) the AML handling wakeup events checks PME Status and PME Enable and it won't trigger a Notify() for devices where those bits are not set while it is running. That happens during resume from suspend-to-idle when pci_restore_state() invoked by pci_pm_default_resume_early() clears PME Enable before the wakeup events are processed by AML, effectively causing those wakeup events to be ignored. Fix this issue by restoring the PME Enable configuration right after pci_restore_state() has been called instead of doing that in pci_enable_wake(). Fixes: dc15e71e (PCI / PM: Restore PME Enable if skipping wakeup setup) Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Dan Carpenter 提交于
The copy_from/to_user() functions return the number of bytes remaining to be copied but we had intended to return -EFAULT here. Fixes: bc88ac47 ("scsi: cxlflash: Support AFU debug") Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Acked-by: NMatthew R. Ochs <mrochs@linux.vnet.ibm.com> Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
-
由 Hans de Goede 提交于
This Ployer Momo7w revision has the same hardware as the Trekstor ST70416-6, so we re-use the surftab_wintron70_st70416_6_data. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>
-
由 Nilesh Javali 提交于
This patch adds support for Boot from SAN over iSCSI offload. The iSCSI boot information in the NVRAM is populated under /sys/firmware/iscsi_bootX/ using qed NVM-image reading API and further exported to open-iscsi to perform iSCSI login enabling boot over offload iSCSI interface in a Boot from SAN environment. Signed-off-by: NArun Easi <arun.easi@cavium.com> Signed-off-by: NAndrew Vasquez <andrew.vasquez@cavium.com> Signed-off-by: NManish Rangankar <manish.rangankar@cavium.com> Signed-off-by: NNilesh Javali <nilesh.javali@cavium.com> Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
-
由 Chen Hong 提交于
The driver checks port->exists twice in i8042_interrupt(), first when trying to assign temporary "serio" variable, and second time when deciding whether it should call serio_interrupt(). The value of port->exists may change between the 2 checks, and we may end up calling serio_interrupt() with a NULL pointer: BUG: unable to handle kernel NULL pointer dereference at 0000000000000050 IP: [<ffffffff8150feaf>] _spin_lock_irqsave+0x1f/0x40 PGD 0 Oops: 0002 [#1] SMP last sysfs file: CPU 0 Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.32-358.el6.x86_64 #1 QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:[<ffffffff8150feaf>] [<ffffffff8150feaf>] _spin_lock_irqsave+0x1f/0x40 RSP: 0018:ffff880028203cc0 EFLAGS: 00010082 RAX: 0000000000010000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000282 RSI: 0000000000000098 RDI: 0000000000000050 RBP: ffff880028203cc0 R08: ffff88013e79c000 R09: ffff880028203ee0 R10: 0000000000000298 R11: 0000000000000282 R12: 0000000000000050 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000098 FS: 0000000000000000(0000) GS:ffff880028200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 0000000000000050 CR3: 0000000001a85000 CR4: 00000000001407f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process swapper (pid: 1, threadinfo ffff88013e79c000, task ffff88013e79b500) Stack: ffff880028203d00 ffffffff813de186 ffffffffffffff02 0000000000000000 <d> 0000000000000000 0000000000000000 0000000000000000 0000000000000098 <d> ffff880028203d70 ffffffff813e0162 ffff880028203d20 ffffffff8103b8ac Call Trace: <IRQ> [<ffffffff813de186>] serio_interrupt+0x36/0xa0 [<ffffffff813e0162>] i8042_interrupt+0x132/0x3a0 [<ffffffff8103b8ac>] ? kvm_clock_read+0x1c/0x20 [<ffffffff8103b8b9>] ? kvm_clock_get_cycles+0x9/0x10 [<ffffffff810e1640>] handle_IRQ_event+0x60/0x170 [<ffffffff8103b154>] ? kvm_guest_apic_eoi_write+0x44/0x50 [<ffffffff810e3d8e>] handle_edge_irq+0xde/0x180 [<ffffffff8100de89>] handle_irq+0x49/0xa0 [<ffffffff81516c8c>] do_IRQ+0x6c/0xf0 [<ffffffff8100b9d3>] ret_from_intr+0x0/0x11 [<ffffffff81076f63>] ? __do_softirq+0x73/0x1e0 [<ffffffff8109b75b>] ? hrtimer_interrupt+0x14b/0x260 [<ffffffff8100c1cc>] ? call_softirq+0x1c/0x30 [<ffffffff8100de05>] ? do_softirq+0x65/0xa0 [<ffffffff81076d95>] ? irq_exit+0x85/0x90 [<ffffffff81516d80>] ? smp_apic_timer_interrupt+0x70/0x9b [<ffffffff8100bb93>] ? apic_timer_interrupt+0x13/0x20 To avoid the issue let's change the second check to test whether serio is NULL or not. Also, let's take i8042_lock in i8042_start() and i8042_stop() instead of trying to be overly smart and using memory barriers. Signed-off-by: NChen Hong <chenhong3@huawei.com> [dtor: take lock in i8042_start()/i8042_stop()] Cc: stable@vger.kernel.org Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Shawn Lin 提交于
pci_scan_root_bus_bridge() returns zero for success, or a negative errno. A typo in ae13cb9b ("PCI: rockchip: Convert PCI scan API to pci_scan_root_bus_bridge()") treated zero as a failure. Fix the typo. Fixes: ae13cb9b ("PCI: rockchip: Convert PCI scan API to pci_scan_root_bus_bridge()") Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com> [bhelgaas: changelog] Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
-
由 Benjamin Gaignard 提交于
Even if CONFIG_FB_PROVIDE_GET_FB_UNMAPPED_AREA flag is selected do not compile and use get_fb_unmapped_area() if CONFIG_MMU is also set. This will avoid mmap errors when compiling multi architectures at same time. Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Emil Velikov <emil.l.velikov@gmail.com> Cc: Yannick Fertre <yannick.fertre@st.com> Cc: Eric Engestrom <eric.engestrom@imgtec.com> Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
-
由 Arnd Bergmann 提交于
The vdisplay variable is now only accessed inside of an #ifdef, producing a harmless warning: drivers/video/fbdev/aty/atyfb_base.c: In function 'aty_var_to_crtc': drivers/video/fbdev/aty/atyfb_base.c:805:19: error: unused variable 'vdisplay' [-Werror=unused-variable] This moves the declaration into the ifdef as well. Fixes: dd7d958a ("video: fbdev: aty: remove useless variable assignments in aty_var_to_crtc()") Signed-off-by: NArnd Bergmann <arnd@arndb.de> Cc: "Gustavo A. R. Silva" <garsilva@embeddedor.com> Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
-