- Aug 20, 2019
-
-
David Howells authored
Disallow access to /proc/kcore when the kernel is locked down to prevent access to cryptographic data. This is limited to lockdown confidentiality mode and is still permitted in integrity mode. Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
Matthew Garrett <mjg59@google.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
James Morris <jmorris@namei.org>
-
David Howells authored
The testmmiotrace module shouldn't be permitted when the kernel is locked down as it can be used to arbitrarily read and write MMIO space. This is a runtime check rather than buildtime in order to allow configurations where the same kernel may be run in both locked down or permissive modes depending on local policy. Suggested-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
Matthew Garrett <mjg59@google.com> Acked-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Reviewed-by:
Kees Cook <keescook@chromium.org> cc: Thomas Gleixner <tglx@linutronix.de> cc: Steven Rostedt <rostedt@goodmis.org> cc: Ingo Molnar <mingo@kernel.org> cc: "H. Peter Anvin" <hpa@zytor.com> cc: x86@kernel.org Signed-off-by:
James Morris <jmorris@namei.org>
-
David Howells authored
Provided an annotation for module parameters that specify hardware parameters (such as io ports, iomem addresses, irqs, dma channels, fixed dma buffers and other types). Suggested-by:
Alan Cox <gnomes@lxorguk.ukuu.org.uk> Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
Matthew Garrett <mjg59@google.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Cc: Jessica Yu <jeyu@kernel.org> Signed-off-by:
James Morris <jmorris@namei.org>
-
David Howells authored
Lock down TIOCSSERIAL as that can be used to change the ioport and irq settings on a serial port. This only appears to be an issue for the serial drivers that use the core serial code. All other drivers seem to either ignore attempts to change port/irq or give an error. Reported-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
Matthew Garrett <mjg59@google.com> Reviewed-by:
Kees Cook <keescook@chromium.org> cc: Jiri Slaby <jslaby@suse.com> Cc: linux-serial@vger.kernel.org Signed-off-by:
James Morris <jmorris@namei.org>
-
David Howells authored
Prohibit replacement of the PCMCIA Card Information Structure when the kernel is locked down. Suggested-by:
Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
Matthew Garrett <mjg59@google.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
James Morris <jmorris@namei.org>
-
Linn Crosetto authored
>From the kernel documentation (initrd_table_override.txt): If the ACPI_INITRD_TABLE_OVERRIDE compile option is true, it is possible to override nearly any ACPI table provided by the BIOS with an instrumented, modified one. When lockdown is enabled, the kernel should disallow any unauthenticated changes to kernel space. ACPI tables contain code invoked by the kernel, so do not allow ACPI tables to be overridden if the kernel is locked down. Signed-off-by:
Linn Crosetto <lcrosetto@gmail.com> Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
Matthew Garrett <mjg59@google.com> Reviewed-by:
Kees Cook <keescook@chromium.org> cc: linux-acpi@vger.kernel.org Signed-off-by:
James Morris <jmorris@namei.org>
-
Josh Boyer authored
This option allows userspace to pass the RSDP address to the kernel, which makes it possible for a user to modify the workings of hardware. Reject the option when the kernel is locked down. This requires some reworking of the existing RSDP command line logic, since the early boot code also makes use of a command-line passed RSDP when locating the SRAT table before the lockdown code has been initialised. This is achieved by separating the command line RSDP path in the early boot code from the generic RSDP path, and then copying the command line RSDP into boot params in the kernel proper if lockdown is not enabled. If lockdown is enabled and an RSDP is provided on the command line, this will only be used when parsing SRAT (which shouldn't permit kernel code execution) and will be ignored in the rest of the kernel. (Modified by Matthew Garrett in order to handle the early boot RSDP environment) Signed-off-by:
Josh Boyer <jwboyer@redhat.com> Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
Matthew Garrett <mjg59@google.com> Reviewed-by:
Kees Cook <keescook@chromium.org> cc: Dave Young <dyoung@redhat.com> cc: linux-acpi@vger.kernel.org Signed-off-by:
James Morris <jmorris@namei.org>
-
Matthew Garrett authored
custom_method effectively allows arbitrary access to system memory, making it possible for an attacker to circumvent restrictions on module loading. Disable it if the kernel is locked down. Signed-off-by:
Matthew Garrett <mjg59@google.com> Signed-off-by:
David Howells <dhowells@redhat.com> Reviewed-by:
Kees Cook <keescook@chromium.org> cc: linux-acpi@vger.kernel.org Signed-off-by:
James Morris <jmorris@namei.org>
-
Matthew Garrett authored
Writing to MSRs should not be allowed if the kernel is locked down, since it could lead to execution of arbitrary code in kernel mode. Based on a patch by Kees Cook. Signed-off-by:
Matthew Garrett <mjg59@google.com> Signed-off-by:
David Howells <dhowells@redhat.com> Acked-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Thomas Gleixner <tglx@linutronix.de> cc: x86@kernel.org Signed-off-by:
James Morris <jmorris@namei.org>
-
Matthew Garrett authored
IO port access would permit users to gain access to PCI configuration registers, which in turn (on a lot of hardware) give access to MMIO register space. This would potentially permit root to trigger arbitrary DMA, so lock it down by default. This also implicitly locks down the KDADDIO, KDDELIO, KDENABIO and KDDISABIO console ioctls. Signed-off-by:
Matthew Garrett <mjg59@google.com> Signed-off-by:
David Howells <dhowells@redhat.com> Reviewed-by:
Kees Cook <keescook@chromium.org> cc: x86@kernel.org Signed-off-by:
James Morris <jmorris@namei.org>
-
Matthew Garrett authored
Any hardware that can potentially generate DMA has to be locked down in order to avoid it being possible for an attacker to modify kernel code, allowing them to circumvent disabled module loading or module signing. Default to paranoid - in future we can potentially relax this for sufficiently IOMMU-isolated devices. Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
Matthew Garrett <mjg59@google.com> Acked-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Kees Cook <keescook@chromium.org> cc: linux-pci@vger.kernel.org Signed-off-by:
James Morris <jmorris@namei.org>
-
Josh Boyer authored
There is currently no way to verify the resume image when returning from hibernate. This might compromise the signed modules trust model, so until we can work with signed hibernate images we disable it when the kernel is locked down. Signed-off-by:
Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
Matthew Garrett <mjg59@google.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Cc: rjw@rjwysocki.net Cc: pavel@ucw.cz cc: linux-pm@vger.kernel.org Signed-off-by:
James Morris <jmorris@namei.org>
-
Jiri Bohac authored
When KEXEC_SIG is not enabled, kernel should not load images through kexec_file systemcall if the kernel is locked down. [Modified by David Howells to fit with modifications to the previous patch and to return -EPERM if the kernel is locked down for consistency with other lockdowns. Modified by Matthew Garrett to remove the IMA integration, which will be replaced by integrating with the IMA architecture policy patches.] Signed-off-by:
Jiri Bohac <jbohac@suse.cz> Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
Matthew Garrett <mjg59@google.com> cc: kexec@lists.infradead.org Signed-off-by:
James Morris <jmorris@namei.org>
-
Jiri Bohac authored
This is a preparatory patch for kexec_file_load() lockdown. A locked down kernel needs to prevent unsigned kernel images from being loaded with kexec_file_load(). Currently, the only way to force the signature verification is compiling with KEXEC_VERIFY_SIG. This prevents loading usigned images even when the kernel is not locked down at runtime. This patch splits KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE. Analogous to the MODULE_SIG and MODULE_SIG_FORCE for modules, KEXEC_SIG turns on the signature verification but allows unsigned images to be loaded. KEXEC_SIG_FORCE disallows images without a valid signature. Signed-off-by:
Jiri Bohac <jbohac@suse.cz> Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
Matthew Garrett <mjg59@google.com> cc: kexec@lists.infradead.org Signed-off-by:
James Morris <jmorris@namei.org>
-
Dave Young authored
Kexec reboot in case secure boot being enabled does not keep the secure boot mode in new kernel, so later one can load unsigned kernel via legacy kexec_load. In this state, the system is missing the protections provided by secure boot. Adding a patch to fix this by retain the secure_boot flag in original kernel. secure_boot flag in boot_params is set in EFI stub, but kexec bypasses the stub. Fixing this issue by copying secure_boot flag across kexec reboot. Signed-off-by:
Dave Young <dyoung@redhat.com> Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
Matthew Garrett <mjg59@google.com> Reviewed-by:
Kees Cook <keescook@chromium.org> cc: kexec@lists.infradead.org Signed-off-by:
James Morris <jmorris@namei.org>
-
Matthew Garrett authored
The kexec_load() syscall permits the loading and execution of arbitrary code in ring 0, which is something that lock-down is meant to prevent. It makes sense to disable kexec_load() in this situation. This does not affect kexec_file_load() syscall which can check for a signature on the image to be booted. Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
Matthew Garrett <mjg59@google.com> Acked-by:
Dave Young <dyoung@redhat.com> Reviewed-by:
Kees Cook <keescook@chromium.org> cc: kexec@lists.infradead.org Signed-off-by:
James Morris <jmorris@namei.org>
-
Matthew Garrett authored
Allowing users to read and write to core kernel memory makes it possible for the kernel to be subverted, avoiding module loading restrictions, and also to steal cryptographic information. Disallow /dev/mem and /dev/kmem from being opened this when the kernel has been locked down to prevent this. Also disallow /dev/port from being opened to prevent raw ioport access and thus DMA from being used to accomplish the same thing. Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
Matthew Garrett <mjg59@google.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Cc: x86@kernel.org Signed-off-by:
James Morris <jmorris@namei.org>
-
David Howells authored
If the kernel is locked down, require that all modules have valid signatures that we can verify. I have adjusted the errors generated: (1) If there's no signature (ENODATA) or we can't check it (ENOPKG, ENOKEY), then: (a) If signatures are enforced then EKEYREJECTED is returned. (b) If there's no signature or we can't check it, but the kernel is locked down then EPERM is returned (this is then consistent with other lockdown cases). (2) If the signature is unparseable (EBADMSG, EINVAL), the signature fails the check (EKEYREJECTED) or a system error occurs (eg. ENOMEM), we return the error we got. Note that the X.509 code doesn't check for key expiry as the RTC might not be valid or might not have been transferred to the kernel's clock yet. [Modified by Matthew Garrett to remove the IMA integration. This will be replaced with integration with the IMA architecture policy patchset.] Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
Matthew Garrett <matthewgarrett@google.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Cc: Jessica Yu <jeyu@kernel.org> Signed-off-by:
James Morris <jmorris@namei.org>
-
Matthew Garrett authored
While existing LSMs can be extended to handle lockdown policy, distributions generally want to be able to apply a straightforward static policy. This patch adds a simple LSM that can be configured to reject either integrity or all lockdown queries, and can be configured at runtime (through securityfs), boot time (via a kernel parameter) or build time (via a kconfig option). Based on initial code by David Howells. Signed-off-by:
Matthew Garrett <mjg59@google.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Cc: David Howells <dhowells@redhat.com> Signed-off-by:
James Morris <jmorris@namei.org>
-
Matthew Garrett authored
Add a mechanism to allow LSMs to make a policy decision around whether kernel functionality that would allow tampering with or examining the runtime state of the kernel should be permitted. Signed-off-by:
Matthew Garrett <mjg59@google.com> Acked-by:
Kees Cook <keescook@chromium.org> Acked-by:
Casey Schaufler <casey@schaufler-ca.com> Signed-off-by:
James Morris <jmorris@namei.org>
-
Matthew Garrett authored
The lockdown module is intended to allow for kernels to be locked down early in boot - sufficiently early that we don't have the ability to kmalloc() yet. Add support for early initialisation of some LSMs, and then add them to the list of names when we do full initialisation later. Early LSMs are initialised in link order and cannot be overridden via boot parameters, and cannot make use of kmalloc() (since the allocator isn't initialised yet). (Fixed by Stephen Rothwell to include a stub to fix builds when !CONFIG_SECURITY) Signed-off-by:
Matthew Garrett <mjg59@google.com> Acked-by:
Kees Cook <keescook@chromium.org> Acked-by:
Casey Schaufler <casey@schaufler-ca.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
James Morris <jmorris@namei.org>
-
- Jul 08, 2019
-
-
Linus Torvalds authored
-
- Jul 07, 2019
-
-
git://git.kernel.dk/linux-blockLinus Torvalds authored
Pull block fix from Jens Axboe: "Just a single fix for a patch from Greg KH, which reportedly break block debugfs locations for certain setups. Trivial enough that I think we should include it now, rather than wait and release 5.2 with it, since it's a regression in this series" * tag 'for-linus-20190706' of git://git.kernel.dk/linux-block: blk-mq: fix up placement of debugfs directory of queue files
-
git://git.kernel.org/pub/scm/linux/kernel/git/mips/linuxLinus Torvalds authored
Pull MIPS fixes from Paul Burton: "A few more MIPS fixes: - Fix a silly typo in virt_addr_valid which led to completely bogus behavior (that happened to stop tripping up hardened usercopy despite being broken). - Fix UART parity setup on AR933x systems. - A build fix for non-Linux build machines. - Have the 'all' make target build DTBs, primarily to fit in with the behavior of scripts/package/builddeb. - Handle an execution hazard in TLB exceptions that use KScratch registers, which could inadvertently clobber the $1 register on some generally higher-end out-of-order CPUs. - A MAINTAINERS update to fix the path to the NAND driver for Ingenic systems" * tag 'mips_fixes_5.2_2' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux: MAINTAINERS: Correct path to moved files MIPS: Add missing EHB in mtc0 -> mfc0 sequence. MIPS: have "plain" make calls build dtbs for selected platforms MIPS: fix build on non-linux hosts MIPS: ath79: fix ar933x uart parity mode MIPS: Fix bounds check virt_addr_valid
-
git://git.infradead.org/users/vkoul/slave-dmaLinus Torvalds authored
Pull dmaengine fixes from Vinod Koul: - bam_dma fix for completed descriptor count - fix for imx-sdma remove BD_INTR for channel0 and use-after-free on probe error path - endian bug fix in jz4780 IRQ handler * tag 'dmaengine-fix-5.2' of git://git.infradead.org/users/vkoul/slave-dma: dmaengine: qcom: bam_dma: Fix completed descriptors count dmaengine: imx-sdma: remove BD_INTR for channel0 dmaengine: imx-sdma: fix use-after-free on probe error path dmaengine: jz4780: Fix an endian bug in IRQ handler
-
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsiLinus Torvalds authored
Pull SCSI fixes from James Bottomley: "Two iscsi fixes. One for an oops in the client which can be triggered by the server authentication protocol and the other in the target code which causes data corruption" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: iscsi: set auth_protocol back to NULL if CHAP_A value is not supported scsi: target/iblock: Fix overrun in WRITE SAME emulation
-
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds authored
Pull vfs fixlet from Al Viro: "Fix bogus default y in Kconfig (VALIDATE_FS_PARSER) That thing should not be turned on by default, especially since it's not quiet in case it finds no problems. Geert has sent the obvious fix quite a few times, but it fell through the cracks" * 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: fs: VALIDATE_FS_PARSER should default to n
-
Greg Kroah-Hartman authored
When the blk-mq debugfs file creation logic was "cleaned up" it was cleaned up too much, causing the queue file to not be created in the correct location. Turns out the check for the directory being present is needed as if that has not happened yet, the files should not be created, and the function will be called later on in the initialization code so that the files can be created in the correct location. Fixes: 6cfc0081 ("blk-mq: no need to check return value of debugfs_create functions") Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Cc: linux-block@vger.kernel.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
- Jul 06, 2019
-
-
Linus Torvalds authored
This reverts commit 5fd4ca2d . Mikhail Gavrilov reports that it causes the VM_BUG_ON_PAGE() in __delete_from_swap_cache() to trigger: page:ffffd6d34dff0000 refcount:1 mapcount:1 mapping:ffff97812323a689 index:0xfecec363 anon flags: 0x17fffe00080034(uptodate|lru|active|swapbacked) raw: 0017fffe00080034 ffffd6d34c67c508 ffffd6d3504b8d48 ffff97812323a689 raw: 00000000fecec363 0000000000000000 0000000100000000 ffff978433ace000 page dumped because: VM_BUG_ON_PAGE(entry != page) page->mem_cgroup:ffff978433ace000 ------------[ cut here ]------------ kernel BUG at mm/swap_state.c:170! invalid opcode: 0000 [#1] SMP NOPTI CPU: 1 PID: 221 Comm: kswapd0 Not tainted 5.2.0-0.rc2.git0.1.fc31.x86_64 #1 Hardware name: System manufacturer System Product Name/ROG STRIX X470-I GAMING, BIOS 2202 04/11/2019 RIP: 0010:__delete_from_swap_cache+0x20d/0x240 Code: 30 65 48 33 04 25 28 00 00 00 75 4a 48 83 c4 38 5b 5d 41 5c 41 5d 41 5e 41 5f c3 48 c7 c6 2f dc 0f 8a 48 89 c7 e8 93 1b fd ff <0f> 0b 48 c7 c6 a8 74 0f 8a e8 85 1b fd ff 0f 0b 48 c7 c6 a8 7d 0f RSP: 0018:ffffa982036e7980 EFLAGS: 00010046 RAX: 0000000000000021 RBX: 0000000000000040 RCX: 0000000000000006 RDX: 0000000000000000 RSI: 0000000000000086 RDI: ffff97843d657900 RBP: 0000000000000001 R08: ffffa982036e7835 R09: 0000000000000535 R10: ffff97845e21a46c R11: ffffa982036e7835 R12: ffff978426387120 R13: 0000000000000000 R14: ffffd6d34dff0040 R15: ffffd6d34dff0000 FS: 0000000000000000(0000) GS:ffff97843d640000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00002cba88ef5000 CR3: 000000078a97c000 CR4: 00000000003406e0 Call Trace: delete_from_swap_cache+0x46/0xa0 try_to_free_swap+0xbc/0x110 swap_writepage+0x13/0x70 pageout.isra.0+0x13c/0x350 shrink_page_list+0xc14/0xdf0 shrink_inactive_list+0x1e5/0x3c0 shrink_node_memcg+0x202/0x760 shrink_node+0xe0/0x470 balance_pgdat+0x2d1/0x510 kswapd+0x220/0x420 kthread+0xfb/0x130 ret_from_fork+0x22/0x40 and it's not immediately obvious why it happens. It's too late in the rc cycle to do anything but revert for now. Link: https://lore.kernel.org/lkml/CABXGCsN9mYmBD-4GaaeW_NrDu+FDXLzr_6x+XNxfmFV6QkYCDg@mail.gmail.com/ Reported-and-bisected-by:
Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com> Suggested-by:
Jan Kara <jack@suse.cz> Cc: Michal Hocko <mhocko@kernel.org> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Matthew Wilcox <willy@infradead.org> Cc: Kirill Shutemov <kirill@shutemov.name> Cc: William Kucharski <william.kucharski@oracle.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds authored
Pull kvm fixes from Paolo Bonzini: "x86 bugfix patches and one compilation fix for ARM" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: arm64/sve: Fix vq_present() macro to yield a bool KVM: LAPIC: Fix pending interrupt in IRR blocked by software disable LAPIC KVM: nVMX: Change KVM_STATE_NESTED_EVMCS to signal vmcs12 is copied from eVMCS KVM: nVMX: Allow restore nested-state to enable eVMCS when vCPU in SMM KVM: x86: degrade WARN to pr_warn_ratelimited
-
git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linuxLinus Torvalds authored
Pull mtf fixes from Miquel Raynal: - Fix the memory organization structure of a Macronix SPI-NAND chip. - Fix a build dependency wrongly described. - Fix the sunxi NAND driver for A23/A33 SoCs by (a) reverting the faulty commit introducing broken DMA support and (b) applying another commit bringing working DMA support. * tag 'mtd/fixes-for-5.2-final' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: mtd: rawnand: sunxi: Add A23/A33 DMA support with extra MBUS configuration Revert "mtd: rawnand: sunxi: Add A23/A33 DMA support" mtd: rawnand: ingenic: Fix ingenic_ecc dependency mtd: spinand: Fix max_bad_eraseblocks_per_lun info in memorg
-
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linuxLinus Torvalds authored
Pull i2c fixlet from Wolfram Sang: "I2C has a MAINTAINERS update which will be benfitial for developers, so let's add it right away" * 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: tegra: Add Dmitry as a reviewer
-
git://linux-nfs.org/~bfields/linuxLinus Torvalds authored
Pull nfsd fixes from Bruce Fields: "Two more quick bugfixes for nfsd: fixing a regression causing mount failures on high-memory machines and fixing the DRC over RDMA" * tag 'nfsd-5.2-2' of git://linux-nfs.org/~bfields/linux: nfsd: Fix overflow causing non-working mounts on 1 TB machines svcrdma: Ignore source port when computing DRC hash
-
Miquel Raynal authored
Allwinner NAND controllers can make use of DMA to enhance the I/O throughput thanks to ECC pipelining. DMA handling with A23/A33 NAND IP is a bit different than with the older SoCs, hence the introduction of a new compatible to handle: * the differences between register offsets, * the burst length change from 4 to minimum 8, * manage SRAM accesses through MBUS with extra configuration. Fixes: c49836f0 ("mtd: rawnand: sunxi: Add A23/A33 DMA support") Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com>
-
Miquel Raynal authored
This reverts commit c49836f0. The commit is wrong and its approach actually does not work. Let's revert it in order to add the feature with a clean patch. Fixes: c49836f0 ("mtd: rawnand: sunxi: Add A23/A33 DMA support") Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com>
-
Dmitry Osipenko authored
I'm contributing to Tegra's upstream development in general and happened to review the Tegra's I2C patches for awhile because I'm actively using upstream kernel on all of my Tegra-powered devices and initially some of the submitted patches were getting my attention since they were causing problems. Recently Wolfram Sang asked whether I'm interested in becoming a reviewer for the driver and I don't mind at all. Signed-off-by:
Dmitry Osipenko <digetx@gmail.com> [wsa: ack was expressed by Thierry Reding in a mail thread] Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
- Jul 05, 2019
-
-
Geert Uytterhoeven authored
CONFIG_VALIDATE_FS_PARSER is a debugging tool to check that the parser tables are vaguely sane. It was set to default to 'Y' for the moment to catch errors in upcoming fs conversion development. Make sure it is not enabled by default in the final release of v5.1. Fixes: 31d921c7 ("vfs: Add configuration parser helpers") Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Zhang Lei authored
The original implementation of vq_present() relied on aggressive inlining in order for the compiler to know that the code is correct, due to some const-casting issues. This was causing sparse and clang to complain, while GCC compiled cleanly. Commit 0c529ff7 addressed this problem, but since vq_present() is no longer a function, there is now no implicit casting of the returned value to the return type (bool). In set_sve_vls(), this uncast bit value is compared against a bool, and so may spuriously compare as unequal when both are nonzero. As a result, KVM may reject valid SVE vector length configurations as invalid, and vice versa. Fix it by forcing the returned value to a bool. Signed-off-by:
Zhang Lei <zhang.lei@jp.fujitsu.com> Fixes: 0c529ff7 ("KVM: arm64: Implement vq_present() as a macro") Signed-off-by: Dave Martin <Dave.Martin@arm.com> [commit message rewrite] Cc: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
Sricharan R authored
One space is left unused in circular FIFO to differentiate 'full' and 'empty' cases. So take that in to account while counting for the descriptors completed. Fixes the issue reported here, https://lkml.org/lkml/2019/6/18/669 Cc: stable@vger.kernel.org Reported-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by:
Sricharan R <sricharan@codeaurora.org> Tested-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by:
Vinod Koul <vkoul@kernel.org>
-
Robin Gong authored
It is possible for an irq triggered by channel0 to be received later after clks are disabled once firmware loaded during sdma probe. If that happens then clearing them by writing to SDMA_H_INTR won't work and the kernel will hang processing infinite interrupts. Actually, don't need interrupt triggered on channel0 since it's pollling SDMA_H_STATSTOP to know channel0 done rather than interrupt in current code, just clear BD_INTR to disable channel0 interrupt to avoid the above case. This issue was brought by commit 1d069bfa ("dmaengine: imx-sdma: ack channel 0 IRQ in the interrupt handler") which didn't take care the above case. Fixes: 1d069bfa ("dmaengine: imx-sdma: ack channel 0 IRQ in the interrupt handler") Cc: stable@vger.kernel.org #5.0+ Signed-off-by:
Robin Gong <yibin.gong@nxp.com> Reported-by:
Sven Van Asbroeck <thesven73@gmail.com> Tested-by:
Sven Van Asbroeck <thesven73@gmail.com> Reviewed-by:
Michael Olbrich <m.olbrich@pengutronix.de> Signed-off-by:
Vinod Koul <vkoul@kernel.org>
-