- Linux-stable-mirror - lists.linaro.org

[PATCH] virtio: Honour 'may_reduce_num' in vring_create_virtqueue

by Cornelia Huck

vring_create_virtqueue() allows the caller to specify via the may_reduce_num parameter whether the vring code is allowed to allocate a smaller ring than specified. However, the split ring allocation code tries to allocate a smaller ring on allocation failure regardless of what the caller specified. This may cause trouble for e.g. virtio-pci in legacy mode, which does not support ring resizing. (The packed ring code does not resize in any case.) Let's fix this by bailing out immediately in the split ring code if the requested size cannot be allocated and may_reduce_num has not been specified. While at it, fix a typo in the usage instructions. Fixes: 2a2d1382fe9d ("virtio: Add improved queue allocation API") Cc: stable(a)vger.kernel.org # v4.6+ Signed-off-by: Cornelia Huck <cohuck(a)redhat.com> --- drivers/virtio/virtio_ring.c | 2 ++ include/linux/virtio_ring.h | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c index 18846afb39da..5df92c308286 100644 --- a/drivers/virtio/virtio_ring.c +++ b/drivers/virtio/virtio_ring.c @@ -882,6 +882,8 @@ static struct virtqueue *vring_create_virtqueue_split( GFP_KERNEL|__GFP_NOWARN|__GFP_ZERO); if (queue) break; + if (!may_reduce_num) + return NULL; } if (!num) diff --git a/include/linux/virtio_ring.h b/include/linux/virtio_ring.h index fab02133a919..3dc70adfe5f5 100644 --- a/include/linux/virtio_ring.h +++ b/include/linux/virtio_ring.h @@ -63,7 +63,7 @@ struct virtqueue; /* * Creates a virtqueue and allocates the descriptor ring. If * may_reduce_num is set, then this may allocate a smaller ring than - * expected. The caller should query virtqueue_get_ring_size to learn + * expected. The caller should query virtqueue_get_vring_size to learn * the actual size of the ring. */ struct virtqueue *vring_create_virtqueue(unsigned int index, -- 2.17.2

6 years, 7 months

4
3
0 0

[RFC/RFT PATCH 04/18] crypto: skcipher - restore default skcipher_walk::iv on error

by Eric Biggers

From: Eric Biggers <ebiggers(a)google.com> When the user-provided IV buffer is not aligned to the algorithm's alignmask, skcipher_walk_virt() allocates an aligned buffer and copies the IV into it. However, skcipher_walk_virt() can fail after that point, and in this case the buffer will be freed. This causes a use-after-free read in callers that read from walk->iv unconditionally, e.g. the LRW template. For example, this can be reproduced by trying to encrypt fewer than 16 bytes using "lrw(aes)". Fix it by making skcipher_walk_first() reset walk->iv to walk->oiv if skcipher_walk_next() fails. This addresses a similar problem as commit 2b4f27c36bcd ("crypto: skcipher - set walk.iv for zero-length inputs"), but that didn't consider the case where skcipher_walk_virt() fails after copying the IV. This bug was detected by my patches that improve testmgr to fuzz algorithms against their generic implementation, when the extra self-tests were run on a KASAN-enabled kernel. Fixes: b286d8b1a690 ("crypto: skcipher - Add skcipher walk interface") Cc: <stable(a)vger.kernel.org> # v4.10+ Signed-off-by: Eric Biggers <ebiggers(a)google.com> --- crypto/skcipher.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/crypto/skcipher.c b/crypto/skcipher.c index bcf13d95f54ac..0f639f018047d 100644 --- a/crypto/skcipher.c +++ b/crypto/skcipher.c @@ -426,19 +426,27 @@ static int skcipher_copy_iv(struct skcipher_walk *walk) static int skcipher_walk_first(struct skcipher_walk *walk) { + int err; + if (WARN_ON_ONCE(in_irq())) return -EDEADLK; walk->buffer = NULL; if (unlikely(((unsigned long)walk->iv & walk->alignmask))) { - int err = skcipher_copy_iv(walk); + err = skcipher_copy_iv(walk); if (err) return err; } walk->page = NULL; - return skcipher_walk_next(walk); + err = skcipher_walk_next(walk); + + /* On error, don't leave 'walk->iv' pointing to freed buffer. */ + if (unlikely(err)) + walk->iv = walk->oiv; + + return err; } static int skcipher_walk_skcipher(struct skcipher_walk *walk, -- 2.21.0

6 years, 7 months

2
3
0 0

Re: [PATCH v2] mm: Fix modifying of page protection by insert_pfn_pmd()

by Aneesh Kumar K.V

Sasha Levin <sashal(a)kernel.org> writes: > Hi, > > [This is an automated email] > > This commit has been processed because it contains a -stable tag. > The stable tag indicates that it's relevant for the following trees: all > > The bot has tested the following trees: v5.0.5, v4.19.32, v4.14.109, v4.9.166, v4.4.177, v3.18.137. > > v5.0.5: Build OK! > v4.19.32: Build OK! Considering this only impact ppc64 for now I guess it is ok to apply this to the above two kernel versions. The SCM support for ppc64 was added via git describe --contains b5beae5e224f1c72c4482b0ab36fc3d89481a6b2 v4.20-rc1~24^2~68 powerpc/pseries: Add driver for PAPR SCM regions -aneesh

6 years, 7 months

1
0
0 0

[PATCH] ALSA: hda - Add two more machines to the power_save_blacklist

by Hui Wang

Recently we set CONFIG_SND_HDA_POWER_SAVE_DEFAULT to 1 when configuring the kernel, then two machines were reported to have noise after installing the new kernel. Put them in the blacklist, the noise disappears. https://bugs.launchpad.net/bugs/1821663 Cc: <stable(a)vger.kernel.org> Signed-off-by: Hui Wang <hui.wang(a)canonical.com> --- sound/pci/hda/hda_intel.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index ece256a3b48f..f62fb8b16c49 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -2150,6 +2150,9 @@ static struct snd_pci_quirk power_save_blacklist[] = { SND_PCI_QUIRK(0x17aa, 0x367b, "Lenovo IdeaCentre B550", 0), /* https://bugzilla.redhat.com/show_bug.cgi?id=1572975 */ SND_PCI_QUIRK(0x17aa, 0x36a7, "Lenovo C50 All in one", 0), + /* https://bugs.launchpad.net/bugs/1821663 */ + SND_PCI_QUIRK(0x1631, 0xe017, "Packard Bell NEC IMEDIA 5204", 0), + SND_PCI_QUIRK(0x8086, 0x2064, "Intel Laptop 8086:2064", 0), {} }; #endif /* CONFIG_PM */ -- 2.17.1

6 years, 7 months

4
4
0 0

[PATCH net] ipv6: un-do: defrag: drop non-last frags smaller than min mtu

by Captain Wiggum

Hi Greg, A previous bad patch breaks 18 test cases for IPv6 fragment headers. This has already been un-done in upstream, but not in any of the LTS. However two upstream patches are first needed to cover a DoS vulnerability. For background, there are two mail threads in [netdev] on this subject: 1) Subject: TAHI testing fails for IPv6 Fragments in Kernel 4.9 (from captwiggum) 2) Subject: Please merge IPv6 fix for drop fragment smaller than MTU (from captwiggum) Two patches from upstream needed first to cover the DoS: commit d4289fcc9b16b89619ee1c54f829e05e56de8b9a net: IP6 defrag: use rbtrees for IPv6 defrag commit 997dd96471641e147cb2c33ad54284000d0f5e35 net: IP6 defrag: use rbtrees in nf_conntrack_reasm.c One undo-patch to fix the IPv6 fragment headers: ipv6: defrag: drop non-last frags smaller than min mtu UN-DO: commit a8444b1ccb20339774af58e40ad42296074fb484 Thanks! --John Masinter (captwiggum)

6 years, 7 months

6
13
0 0

Re: [RESEND PATCH v2] usb: dwc2: disable power_down on rockchip for regression

by Doug Anderson

Hi, On Fri, Oct 26, 2018 at 7:38 AM Hal Emmerich <hal(a)halemmerich.com> wrote: > > > From 04fbf78e4e569bf872f1ffcb0a6f9b89569dc913 Mon Sep 17 00:00:00 2001 > From: Hal Emmerich <hal(a)halemmerich.com> > Date: Thu, 19 Jul 2018 21:48:08 -0500 > Subject: [PATCH] usb: dwc2: disable power_down on rockchip devices > > The bug would let the usb controller enter partial power down, > which was formally known as hibernate, upon boot if nothing was plugged > in to the port. Partial power down couldn't be exited properly, so any > usb devices plugged in after boot would not be usable. > > Before the name change, params.hibernation was false by default, so > _dwc2_hcd_suspend() would skip entering hibernation. With the > rename, _dwc2_hcd_suspend() was changed to use params.power_down > to decide whether or not to enter partial power down. > > Since params.power_down is non-zero by default, it needs to be set > to 0 for rockchip devices to restore functionality. > > This bug was reported in the linux-usb thread: > REGRESSION: usb: dwc2: USB device not seen after boot > > The commit that caused this regression is: > 6d23ee9caa6790aea047f9aca7f3c03cb8d96eb6 > > Signed-off-by: Hal Emmerich <hal(a)halemmerich.com> > Acked-by: Minas Harutyunyan <hminas(a)synopsys.com> > --- > drivers/usb/dwc2/params.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c > index bf7052e037d6..09292dc977e4 100644 > --- a/drivers/usb/dwc2/params.c > +++ b/drivers/usb/dwc2/params.c > @@ -81,6 +81,7 @@ static void dwc2_set_rk_params(struct dwc2_hsotg *hsotg) > p->host_perio_tx_fifo_size = 256; > p->ahbcfg = GAHBCFG_HBSTLEN_INCR16 << > GAHBCFG_HBSTLEN_SHIFT; > + p->power_down = 0; This landed as commit c216765d3a1d ("usb: dwc2: disable power_down on rockchip devices"). Can it please go to stable? Hotplug of USB on v4.19 stable, for example, is currently broken due to the lack of this patch. Thanks! -Doug

6 years, 7 months

1
0
0 0

+ ocfs2-fix-ocfs2-read-inode-data-panic-in-ocfs2_iget.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: ocfs2: fix ocfs2 read inode data panic in ocfs2_iget has been added to the -mm tree. Its filename is ocfs2-fix-ocfs2-read-inode-data-panic-in-ocfs2_iget.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/ocfs2-fix-ocfs2-read-inode-data-pa… and later at http://ozlabs.org/~akpm/mmotm/broken-out/ocfs2-fix-ocfs2-read-inode-data-pa… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Shuning Zhang <sunny.s.zhang(a)oracle.com> Subject: ocfs2: fix ocfs2 read inode data panic in ocfs2_iget In some cases, ocfs2_iget() reads the data of inode, which has been deleted for some reason. That will make the system panic. So We should judge whether this inode has been deleted, and tell the caller that the inode is a bad inode. For example, the ocfs2 is used as the backed of nfs, and the client is nfsv3. This issue can be reproduced by the following steps. on the nfs server side, ..../patha/pathb Step 1: The process A was scheduled before calling the function fh_verify. Step 2: The process B is removing the 'pathb', and just completed the call to function dput. Then the dentry of 'pathb' has been deleted from the dcache, and all ancestors have been deleted also. The relationship of dentry and inode was deleted through the function hlist_del_init. The following is the call stack. dentry_iput->hlist_del_init(&dentry->d_u.d_alias) At this time, the inode is still in the dcache. Step 3: The process A call the function ocfs2_get_dentry, which get the inode from dcache. Then the refcount of inode is 1. The following is the call stack. nfsd3_proc_getacl->fh_verify->exportfs_decode_fh->fh_to_dentry(ocfs2_get_dentry) Step 4: Dirty pages are flushed by bdi threads. So the inode of 'patha' is evicted, and this directory was deleted. But the inode of 'pathb' can't be evicted, because the refcount of the inode was 1. Step 5: The process A keep running, and call the function reconnect_path(in exportfs_decode_fh), which call function ocfs2_get_parent of ocfs2. Get the block number of parent directory(patha) by the name of ... Then read the data from disk by the block number. But this inode has been deleted, so the system panic. Process A Process B 1. in nfsd3_proc_getacl | 2. | dput 3. fh_to_dentry(ocfs2_get_dentry) | 4. bdi flush dirty cache | 5. ocfs2_iget | [283465.542049] OCFS2: ERROR (device sdp): ocfs2_validate_inode_block: Invalid dinode #580640: OCFS2_VALID_FL not set [283465.545490] Kernel panic - not syncing: OCFS2: (device sdp): panic forced after error [283465.546889] CPU: 5 PID: 12416 Comm: nfsd Tainted: G W 4.1.12-124.18.6.el6uek.bug28762940v3.x86_64 #2 [283465.548382] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 09/21/2015 [283465.549657] 0000000000000000 ffff8800a56fb7b8 ffffffff816e839c ffffffffa0514758 [283465.550392] 000000000008dc20 ffff8800a56fb838 ffffffff816e62d3 0000000000000008 [283465.551056] ffff880000000010 ffff8800a56fb848 ffff8800a56fb7e8 ffff88005df9f000 [283465.551710] Call Trace: [283465.552516] [<ffffffff816e839c>] dump_stack+0x63/0x81 [283465.553291] [<ffffffff816e62d3>] panic+0xcb/0x21b [283465.554037] [<ffffffffa04e66b0>] ocfs2_handle_error+0xf0/0xf0 [ocfs2] [283465.554882] [<ffffffffa04e7737>] __ocfs2_error+0x67/0x70 [ocfs2] [283465.555768] [<ffffffffa049c0f9>] ocfs2_validate_inode_block+0x229/0x230 [ocfs2] [283465.556683] [<ffffffffa047bcbc>] ocfs2_read_blocks+0x46c/0x7b0 [ocfs2] [283465.557408] [<ffffffffa049bed0>] ? ocfs2_inode_cache_io_unlock+0x20/0x20 [ocfs2] [283465.557973] [<ffffffffa049f0eb>] ocfs2_read_inode_block_full+0x3b/0x60 [ocfs2] [283465.558525] [<ffffffffa049f5ba>] ocfs2_iget+0x4aa/0x880 [ocfs2] [283465.559082] [<ffffffffa049146e>] ocfs2_get_parent+0x9e/0x220 [ocfs2] [283465.559622] [<ffffffff81297c05>] reconnect_path+0xb5/0x300 [283465.560156] [<ffffffff81297f46>] exportfs_decode_fh+0xf6/0x2b0 [283465.560708] [<ffffffffa062faf0>] ? nfsd_proc_getattr+0xa0/0xa0 [nfsd] [283465.561262] [<ffffffff810a8196>] ? prepare_creds+0x26/0x110 [283465.561932] [<ffffffffa0630860>] fh_verify+0x350/0x660 [nfsd] [283465.562862] [<ffffffffa0637804>] ? nfsd_cache_lookup+0x44/0x630 [nfsd] [283465.563697] [<ffffffffa063a8b9>] nfsd3_proc_getattr+0x69/0xf0 [nfsd] [283465.564510] [<ffffffffa062cf60>] nfsd_dispatch+0xe0/0x290 [nfsd] [283465.565358] [<ffffffffa05eb892>] ? svc_tcp_adjust_wspace+0x12/0x30 [sunrpc] [283465.566272] [<ffffffffa05ea652>] svc_process_common+0x412/0x6a0 [sunrpc] [283465.567155] [<ffffffffa05eaa03>] svc_process+0x123/0x210 [sunrpc] [283465.568020] [<ffffffffa062c90f>] nfsd+0xff/0x170 [nfsd] [283465.568962] [<ffffffffa062c810>] ? nfsd_destroy+0x80/0x80 [nfsd] [283465.570112] [<ffffffff810a622b>] kthread+0xcb/0xf0 [283465.571099] [<ffffffff810a6160>] ? kthread_create_on_node+0x180/0x180 [283465.572114] [<ffffffff816f11b8>] ret_from_fork+0x58/0x90 [283465.573156] [<ffffffff810a6160>] ? kthread_create_on_node+0x180/0x180 Link: http://lkml.kernel.org/r/1554185919-3010-1-git-send-email-sunny.s.zhang@ora… Signed-off-by: Shuning Zhang <sunny.s.zhang(a)oracle.com> Reviewed-by: Joseph Qi <jiangqi903(a)gmail.com> Cc: Mark Fasheh <mark(a)fasheh.com> Cc: Joel Becker <jlbec(a)evilplan.org> Cc: Junxiao Bi <junxiao.bi(a)oracle.com> Cc: Changwei Ge <gechangwei(a)live.cn> Cc: piaojun <piaojun(a)huawei.com> Cc: "Gang He" <ghe(a)suse.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/ocfs2/export.c | 30 +++++++++++++++++++++++++++++- 1 file changed, 29 insertions(+), 1 deletion(-) --- a/fs/ocfs2/export.c~ocfs2-fix-ocfs2-read-inode-data-panic-in-ocfs2_iget +++ a/fs/ocfs2/export.c @@ -148,16 +148,24 @@ static struct dentry *ocfs2_get_parent(s u64 blkno; struct dentry *parent; struct inode *dir = d_inode(child); + int set; trace_ocfs2_get_parent(child, child->d_name.len, child->d_name.name, (unsigned long long)OCFS2_I(dir)->ip_blkno); + status = ocfs2_nfs_sync_lock(OCFS2_SB(dir->i_sb), 1); + if (status < 0) { + mlog(ML_ERROR, "getting nfs sync lock(EX) failed %d\n", status); + parent = ERR_PTR(status); + goto bail; + } + status = ocfs2_inode_lock(dir, NULL, 0); if (status < 0) { if (status != -ENOENT) mlog_errno(status); parent = ERR_PTR(status); - goto bail; + goto unlock_nfs_sync; } status = ocfs2_lookup_ino_from_name(dir, "..", 2, &blkno); @@ -166,11 +174,31 @@ static struct dentry *ocfs2_get_parent(s goto bail_unlock; } + status = ocfs2_test_inode_bit(OCFS2_SB(dir->i_sb), blkno, &set); + if (status < 0) { + if (status == -EINVAL) { + status = -ESTALE; + } else + mlog(ML_ERROR, "test inode bit failed %d\n", status); + parent = ERR_PTR(status); + goto bail_unlock; + } + + trace_ocfs2_get_dentry_test_bit(status, set); + if (!set) { + status = -ESTALE; + parent = ERR_PTR(status); + goto bail_unlock; + } + parent = d_obtain_alias(ocfs2_iget(OCFS2_SB(dir->i_sb), blkno, 0, 0)); bail_unlock: ocfs2_inode_unlock(dir, 0); +unlock_nfs_sync: + ocfs2_nfs_sync_unlock(OCFS2_SB(dir->i_sb), 1); + bail: trace_ocfs2_get_parent_end(parent); _ Patches currently in -mm which might be from sunny.s.zhang(a)oracle.com are ocfs2-fix-ocfs2-read-inode-data-panic-in-ocfs2_iget.patch

6 years, 7 months

1
0
0 0

+ mm-memory_hotplug-do-not-unlock-when-fails-to-take-the-device_hotplug_lock.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/memory_hotplug: do not unlock after failing to take the device_hotplug_lock has been added to the -mm tree. Its filename is mm-memory_hotplug-do-not-unlock-when-fails-to-take-the-device_hotplug_lock.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-memory_hotplug-do-not-unlock-wh… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-memory_hotplug-do-not-unlock-wh… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: zhong jiang <zhongjiang(a)huawei.com> Subject: mm/memory_hotplug: do not unlock after failing to take the device_hotplug_lock When adding memory by probing a memory block in the sysfs interface, there is an obvious issue where we will unlock the device_hotplug_lock when we failed to takes it. That issue was introduced in 8df1d0e4a265 ("mm/memory_hotplug: make add_memory() take the device_hotplug_lock"). We should drop out in time when failing to take the device_hotplug_lock. Link: http://lkml.kernel.org/r/1554696437-9593-1-git-send-email-zhongjiang@huawei… Fixes: 8df1d0e4a265 ("mm/memory_hotplug: make add_memory() take the device_hotplug_lock") Signed-off-by: zhong jiang <zhongjiang(a)huawei.com> Reported-by: Yang yingliang <yangyingliang(a)huawei.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Reviewed-by: David Hildenbrand <david(a)redhat.com> Reviewed-by: Oscar Salvador <osalvador(a)suse.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- drivers/base/memory.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/base/memory.c~mm-memory_hotplug-do-not-unlock-when-fails-to-take-the-device_hotplug_lock +++ a/drivers/base/memory.c @@ -506,7 +506,7 @@ static ssize_t probe_store(struct device ret = lock_device_hotplug_sysfs(); if (ret) - goto out; + return ret; nid = memory_add_physaddr_to_nid(phys_addr); ret = __add_memory(nid, phys_addr, _ Patches currently in -mm which might be from zhongjiang(a)huawei.com are mm-memory_hotplug-do-not-unlock-when-fails-to-take-the-device_hotplug_lock.patch

6 years, 7 months

1
0
0 0

[PATCH 4/8] ACPICA: Namespace: remove address node from global list after method termination

by Erik Schmauss

ACPICA commit b233720031a480abd438f2e9c643080929d144c3 ASL operation_regions declare a range of addresses that it uses. In a perfect world, the range of addresses should be used exclusively by the AML interpreter. The OS can use this information to decide which drivers to load so that the AML interpreter and device drivers use different regions of memory. During table load, the address information is added to a global address range list. Each node in this list contains an address range as well as a namespace node of the operation_region. This list is deleted at ACPI shutdown. Unfortunately, ASL operation_regions can be declared inside of control methods. Although this is not recommended, modern firmware contains such code. New module level code changes unintentionally removed the functionality of adding and removing nodes to the global address range list. A few months ago, support for adding addresses has been re- implemented. However, the removal of the address range list was missed and resulted in some systems to crash due to the address list containing bogus namespace nodes from operation_regions declared in control methods. In order to fix the crash, this change removes dynamic operation_regions after control method termination. Link: https://github.com/acpica/acpica/commit/b2337200 Link: https://bugzilla.kernel.org/show_bug.cgi?id=202475 Cc: stable(a)vger.kernel.org # 4.20+ Fixes: 4abb951b73ff (ACPICA: AML interpreter: add region addresses in global list during initialization) Reported-by: Michael J Gruber <mjg(a)fedoraproject.org> Signed-off-by: Erik Schmauss <erik.schmauss(a)intel.com> Signed-off-by: Bob Moore <robert.moore(a)intel.com> --- drivers/acpi/acpica/nsobject.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/acpi/acpica/nsobject.c b/drivers/acpi/acpica/nsobject.c index 8638f43cfc3d..79d86da1c892 100644 --- a/drivers/acpi/acpica/nsobject.c +++ b/drivers/acpi/acpica/nsobject.c @@ -186,6 +186,10 @@ void acpi_ns_detach_object(struct acpi_namespace_node *node) } } + if (obj_desc->common.type == ACPI_TYPE_REGION) { + acpi_ut_remove_address_range(obj_desc->region.space_id, node); + } + /* Clear the Node entry in all cases */ node->object = NULL; -- 2.17.2

6 years, 7 months

1
0
0 0

[PATCH 4/8] ACPICA: Namespace: remove address node from global list after method termination

by Erik Schmauss

ACPICA commit b233720031a480abd438f2e9c643080929d144c3 ASL operation_regions declare a range of addresses that it uses. In a perfect world, the range of addresses should be used exclusively by the AML interpreter. The OS can use this information to decide which drivers to load so that the AML interpreter and device drivers use different regions of memory. During table load, the address information is added to a global address range list. Each node in this list contains an address range as well as a namespace node of the operation_region. This list is deleted at ACPI shutdown. Unfortunately, ASL operation_regions can be declared inside of control methods. Although this is not recommended, modern firmware contains such code. New module level code changes unintentionally removed the functionality of adding and removing nodes to the global address range list. A few months ago, support for adding addresses has been re- implemented. However, the removal of the address range list was missed and resulted in some systems to crash due to the address list containing bogus namespace nodes from operation_regions declared in control methods. In order to fix the crash, this change removes dynamic operation_regions after control method termination. Link: https://github.com/acpica/acpica/commit/b2337200 Link: https://bugzilla.kernel.org/show_bug.cgi?id=202475 Cc: stable(a)vger.kernel.org # 4.20+ Fixes: 4abb951b73ff (ACPICA: AML interpreter: add region addresses in global list during initialization) Reported-by: Michael J Gruber <mjg(a)fedoraproject.org> Signed-off-by: Erik Schmauss <erik.schmauss(a)intel.com> Signed-off-by: Bob Moore <robert.moore(a)intel.com> --- drivers/acpi/acpica/nsobject.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/acpi/acpica/nsobject.c b/drivers/acpi/acpica/nsobject.c index 8638f43cfc3d..79d86da1c892 100644 --- a/drivers/acpi/acpica/nsobject.c +++ b/drivers/acpi/acpica/nsobject.c @@ -186,6 +186,10 @@ void acpi_ns_detach_object(struct acpi_namespace_node *node) } } + if (obj_desc->common.type == ACPI_TYPE_REGION) { + acpi_ut_remove_address_range(obj_desc->region.space_id, node); + } + /* Clear the Node entry in all cases */ node->object = NULL; -- 2.17.2

6 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror