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

Patch "perf/callchain: Force USER_DS when invoking perf_callchain_user()" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled perf/callchain: Force USER_DS when invoking perf_callchain_user() to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: perf-callchain-force-user_ds-when-invoking-perf_callchain_user.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Will Deacon <will.deacon(a)arm.com> Date: Tue, 9 May 2017 18:00:04 +0100 Subject: perf/callchain: Force USER_DS when invoking perf_callchain_user() From: Will Deacon <will.deacon(a)arm.com> [ Upstream commit 88b0193d9418c00340e45e0a913a0813bc6c8c96 ] Perf can generate and record a user callchain in response to a synchronous request, such as a tracepoint firing. If this happens under set_fs(KERNEL_DS), then we can end up walking the user stack (and dereferencing/saving whatever we find there) without the protections usually afforded by checks such as access_ok. Rather than play whack-a-mole with each architecture's stack unwinding implementation, fix the root of the problem by ensuring that we force USER_DS when invoking perf_callchain_user from the perf core. Reported-by: Al Viro <viro(a)ZenIV.linux.org.uk> Signed-off-by: Will Deacon <will.deacon(a)arm.com> Acked-by: Peter Zijlstra <peterz(a)infradead.org> Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme(a)redhat.com> Cc: Jiri Olsa <jolsa(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/events/callchain.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/kernel/events/callchain.c +++ b/kernel/events/callchain.c @@ -227,12 +227,18 @@ get_perf_callchain(struct pt_regs *regs, } if (regs) { + mm_segment_t fs; + if (crosstask) goto exit_put; if (add_mark) perf_callchain_store_context(&ctx, PERF_CONTEXT_USER); + + fs = get_fs(); + set_fs(USER_DS); perf_callchain_user(&ctx, regs); + set_fs(fs); } } Patches currently in stable-queue which might be from will.deacon(a)arm.com are queue-4.9/perf-callchain-force-user_ds-when-invoking-perf_callchain_user.patch queue-4.9/arm64-pci-fix-struct-acpi_pci_root_ops-allocation-failure-path.patch queue-4.9/arm64-perf-ignore-exclude_hv-when-kernel-is-running-in-hyp.patch queue-4.9/arm64-kernel-restrict-dev-mem-read-calls-to-linear-region.patch queue-4.9/arm64-futex-fix-undefined-behaviour-with-futex_op_oparg_shift-usage.patch

7 years, 8 months

1
0
0 0

Patch "PCI/msi: fix the pci_alloc_irq_vectors_affinity stub" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled PCI/msi: fix the pci_alloc_irq_vectors_affinity stub to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: pci-msi-fix-the-pci_alloc_irq_vectors_affinity-stub.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Christoph Hellwig <hch(a)lst.de> Date: Sat, 20 May 2017 18:59:54 +0200 Subject: PCI/msi: fix the pci_alloc_irq_vectors_affinity stub From: Christoph Hellwig <hch(a)lst.de> [ Upstream commit 83b4605b0c16cde5b00c8cf192408d51eab75402 ] We need to return an error for any call that asks for MSI / MSI-X vectors only, so that non-trivial fallback logic can work properly. Also valid dev->irq and use the "correct" errno value based on feedback from Linus. Signed-off-by: Christoph Hellwig <hch(a)lst.de> Reported-by: Steven Rostedt <rostedt(a)goodmis.org> Fixes: aff17164 ("PCI: Provide sensible IRQ vector alloc/free routines") Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/linux/pci.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -1348,9 +1348,9 @@ static inline int pci_alloc_irq_vectors( unsigned int min_vecs, unsigned int max_vecs, unsigned int flags) { - if (min_vecs > 1) - return -EINVAL; - return 1; + if ((flags & PCI_IRQ_LEGACY) && min_vecs == 1 && dev->irq) + return 1; + return -ENOSPC; } static inline void pci_free_irq_vectors(struct pci_dev *dev) { Patches currently in stable-queue which might be from hch(a)lst.de are queue-4.9/nvme-pci-fix-multiple-ctrl-removal-scheduling.patch queue-4.9/bio-integrity-do-not-allocate-integrity-context-for-bio-w-o-data.patch queue-4.9/scsi-libsas-initialize-sas_phy-status-according-to-response-of-discover.patch queue-4.9/nvme-fix-hang-in-remove-path.patch queue-4.9/scsi-libsas-fix-error-when-getting-phy-events.patch queue-4.9/ib-srpt-avoid-that-aborting-a-command-triggers-a-kernel-warning.patch queue-4.9/blk-mq-fix-race-between-updating-nr_hw_queues-and-switching-io-sched.patch queue-4.9/pci-msi-fix-the-pci_alloc_irq_vectors_affinity-stub.patch queue-4.9/scsi-libsas-fix-memory-leak-in-sas_smp_get_phy_events.patch queue-4.9/ib-srpt-fix-abort-handling.patch

7 years, 8 months

1
0
0 0

Patch "ovl: persistent inode numbers for upper hardlinks" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ovl: persistent inode numbers for upper hardlinks to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ovl-persistent-inode-numbers-for-upper-hardlinks.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Amir Goldstein <amir73il(a)gmail.com> Date: Mon, 24 Apr 2017 19:54:13 +0300 Subject: ovl: persistent inode numbers for upper hardlinks From: Amir Goldstein <amir73il(a)gmail.com> [ Upstream commit 5b6c9053fb38a66fd5c6177fcf5022b24767811a ] An upper type non directory dentry that is a copy up target should have a reference to its lower copy up origin. There are three ways for an upper type dentry to be instantiated: 1. A lower type dentry that is being copied up 2. An entry that is found in upper dir by ovl_lookup() 3. A negative dentry is hardlinked to an upper type dentry In the first case, the lower reference is set before copy up. In the second case, the lower reference is found by ovl_lookup(). In the last case of hardlinked upper dentry, it is not easy to update the lower reference of the negative dentry. Instead, drop the newly hardlinked negative dentry from dcache and let the next access call ovl_lookup() to find its lower reference. This makes sure that the inode number reported by stat(2) after the hardlink is created is the same inode number that will be reported by stat(2) after mount cycle, which is the inode number of the lower copy up origin of the hardlink source. NOTE that this does not fix breaking of lower hardlinks on copy up, but only fixes the case of lower nlink == 1, whose upper copy up inode is hardlinked in upper dir. Signed-off-by: Amir Goldstein <amir73il(a)gmail.com> Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/overlayfs/dir.c | 3 +++ 1 file changed, 3 insertions(+) --- a/fs/overlayfs/dir.c +++ b/fs/overlayfs/dir.c @@ -180,6 +180,9 @@ static void ovl_instantiate(struct dentr inc_nlink(inode); } d_instantiate(dentry, inode); + /* Force lookup of new upper hardlink to find its lower */ + if (hardlink) + d_drop(dentry); } static int ovl_create_upper(struct dentry *dentry, struct inode *inode, Patches currently in stable-queue which might be from amir73il(a)gmail.com are queue-4.9/ovl-persistent-inode-numbers-for-upper-hardlinks.patch

7 years, 8 months

1
0
0 0

Patch "ovl: filter trusted xattr for non-admin" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ovl: filter trusted xattr for non-admin to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ovl-filter-trusted-xattr-for-non-admin.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Miklos Szeredi <mszeredi(a)redhat.com> Date: Mon, 29 May 2017 15:15:27 +0200 Subject: ovl: filter trusted xattr for non-admin From: Miklos Szeredi <mszeredi(a)redhat.com> [ Upstream commit a082c6f680da298cf075886ff032f32ccb7c5e1a ] Filesystems filter out extended attributes in the "trusted." domain for unprivlieged callers. Overlay calls underlying filesystem's method with elevated privs, so need to do the filtering in overlayfs too. Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/overlayfs/inode.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) --- a/fs/overlayfs/inode.c +++ b/fs/overlayfs/inode.c @@ -227,6 +227,16 @@ int ovl_xattr_get(struct dentry *dentry, return res; } +static bool ovl_can_list(const char *s) +{ + /* List all non-trusted xatts */ + if (strncmp(s, XATTR_TRUSTED_PREFIX, XATTR_TRUSTED_PREFIX_LEN) != 0) + return true; + + /* Never list trusted.overlay, list other trusted for superuser only */ + return !ovl_is_private_xattr(s) && capable(CAP_SYS_ADMIN); +} + ssize_t ovl_listxattr(struct dentry *dentry, char *list, size_t size) { struct dentry *realdentry = ovl_dentry_real(dentry); @@ -250,7 +260,7 @@ ssize_t ovl_listxattr(struct dentry *den return -EIO; len -= slen; - if (ovl_is_private_xattr(s)) { + if (!ovl_can_list(s)) { res -= slen; memmove(s, s + slen, len); } else { Patches currently in stable-queue which might be from mszeredi(a)redhat.com are queue-4.9/ovl-persistent-inode-numbers-for-upper-hardlinks.patch queue-4.9/ovl-filter-trusted-xattr-for-non-admin.patch

7 years, 8 months

1
0
0 0

Patch "nvme-pci: fix multiple ctrl removal scheduling" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled nvme-pci: fix multiple ctrl removal scheduling to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: nvme-pci-fix-multiple-ctrl-removal-scheduling.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Rakesh Pandit <rakesh(a)tuxera.com> Date: Mon, 5 Jun 2017 14:43:11 +0300 Subject: nvme-pci: fix multiple ctrl removal scheduling From: Rakesh Pandit <rakesh(a)tuxera.com> [ Upstream commit 82b057caefaff2a891f821a617d939f46e03e844 ] Commit c5f6ce97c1210 tries to address multiple resets but fails as work_busy doesn't involve any synchronization and can fail. This is reproducible easily as can be seen by WARNING below which is triggered with line: WARN_ON(dev->ctrl.state == NVME_CTRL_RESETTING) Allowing multiple resets can result in multiple controller removal as well if different conditions inside nvme_reset_work fail and which might deadlock on device_release_driver. [ 480.327007] WARNING: CPU: 3 PID: 150 at drivers/nvme/host/pci.c:1900 nvme_reset_work+0x36c/0xec0 [ 480.327008] Modules linked in: rfcomm fuse nf_conntrack_netbios_ns nf_conntrack_broadcast... [ 480.327044] btusb videobuf2_core ghash_clmulni_intel snd_hwdep cfg80211 acer_wmi hci_uart.. [ 480.327065] CPU: 3 PID: 150 Comm: kworker/u16:2 Not tainted 4.12.0-rc1+ #13 [ 480.327065] Hardware name: Acer Predator G9-591/Mustang_SLS, BIOS V1.10 03/03/2016 [ 480.327066] Workqueue: nvme nvme_reset_work [ 480.327067] task: ffff880498ad8000 task.stack: ffffc90002218000 [ 480.327068] RIP: 0010:nvme_reset_work+0x36c/0xec0 [ 480.327069] RSP: 0018:ffffc9000221bdb8 EFLAGS: 00010246 [ 480.327070] RAX: 0000000000460000 RBX: ffff880498a98128 RCX: dead000000000200 [ 480.327070] RDX: 0000000000000001 RSI: ffff8804b1028020 RDI: ffff880498a98128 [ 480.327071] RBP: ffffc9000221be50 R08: 0000000000000000 R09: 0000000000000000 [ 480.327071] R10: ffffc90001963ce8 R11: 000000000000020d R12: ffff880498a98000 [ 480.327072] R13: ffff880498a53500 R14: ffff880498a98130 R15: ffff880498a98128 [ 480.327072] FS: 0000000000000000(0000) GS:ffff8804c1cc0000(0000) knlGS:0000000000000000 [ 480.327073] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 480.327074] CR2: 00007ffcf3c37f78 CR3: 0000000001e09000 CR4: 00000000003406e0 [ 480.327074] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 480.327075] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 480.327075] Call Trace: [ 480.327079] ? __switch_to+0x227/0x400 [ 480.327081] process_one_work+0x18c/0x3a0 [ 480.327082] worker_thread+0x4e/0x3b0 [ 480.327084] kthread+0x109/0x140 [ 480.327085] ? process_one_work+0x3a0/0x3a0 [ 480.327087] ? kthread_park+0x60/0x60 [ 480.327102] ret_from_fork+0x2c/0x40 [ 480.327103] Code: e8 5a dc ff ff 85 c0 41 89 c1 0f..... This patch addresses the problem by using state of controller to decide whether reset should be queued or not as state change is synchronizated using controller spinlock. Also cancel_work_sync is used to make sure remove cancels the reset_work and waits for it to finish. This patch also changes return value from -ENODEV to more appropriate -EBUSY if nvme_reset fails to change state. Fixes: c5f6ce97c1210 ("nvme: don't schedule multiple resets") Signed-off-by: Rakesh Pandit <rakesh(a)tuxera.com> Reviewed-by: Sagi Grimberg <sagi(a)grimberg.me> Signed-off-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/nvme/host/pci.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) --- a/drivers/nvme/host/pci.c +++ b/drivers/nvme/host/pci.c @@ -1263,7 +1263,7 @@ static bool nvme_should_reset(struct nvm bool nssro = dev->subsystem && (csts & NVME_CSTS_NSSRO); /* If there is a reset ongoing, we shouldn't reset again. */ - if (work_busy(&dev->reset_work)) + if (dev->ctrl.state == NVME_CTRL_RESETTING) return false; /* We shouldn't reset unless the controller is on fatal error state @@ -1755,7 +1755,7 @@ static void nvme_reset_work(struct work_ struct nvme_dev *dev = container_of(work, struct nvme_dev, reset_work); int result = -ENODEV; - if (WARN_ON(dev->ctrl.state == NVME_CTRL_RESETTING)) + if (WARN_ON(dev->ctrl.state != NVME_CTRL_RESETTING)) goto out; /* @@ -1765,9 +1765,6 @@ static void nvme_reset_work(struct work_ if (dev->ctrl.ctrl_config & NVME_CC_ENABLE) nvme_dev_disable(dev, false); - if (!nvme_change_ctrl_state(&dev->ctrl, NVME_CTRL_RESETTING)) - goto out; - result = nvme_pci_enable(dev); if (result) goto out; @@ -1841,8 +1838,8 @@ static int nvme_reset(struct nvme_dev *d { if (!dev->ctrl.admin_q || blk_queue_dying(dev->ctrl.admin_q)) return -ENODEV; - if (work_busy(&dev->reset_work)) - return -ENODEV; + if (!nvme_change_ctrl_state(&dev->ctrl, NVME_CTRL_RESETTING)) + return -EBUSY; if (!queue_work(nvme_workq, &dev->reset_work)) return -EBUSY; return 0; @@ -1944,6 +1941,7 @@ static int nvme_probe(struct pci_dev *pd if (result) goto release_pools; + nvme_change_ctrl_state(&dev->ctrl, NVME_CTRL_RESETTING); dev_info(dev->ctrl.device, "pci function %s\n", dev_name(&pdev->dev)); queue_work(nvme_workq, &dev->reset_work); @@ -1987,6 +1985,7 @@ static void nvme_remove(struct pci_dev * nvme_change_ctrl_state(&dev->ctrl, NVME_CTRL_DELETING); + cancel_work_sync(&dev->reset_work); pci_set_drvdata(pdev, NULL); if (!pci_device_is_present(pdev)) { Patches currently in stable-queue which might be from rakesh(a)tuxera.com are queue-4.9/nvme-pci-fix-multiple-ctrl-removal-scheduling.patch queue-4.9/nvme-fix-hang-in-remove-path.patch

7 years, 8 months

1
0
0 0

Patch "nvme: fix hang in remove path" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled nvme: fix hang in remove path to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: nvme-fix-hang-in-remove-path.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Ming Lei <ming.lei(a)redhat.com> Date: Fri, 2 Jun 2017 16:32:08 +0800 Subject: nvme: fix hang in remove path From: Ming Lei <ming.lei(a)redhat.com> [ Upstream commit 82654b6b8ef8b93ee87a97fc562f87f081fc2f91 ] We need to start admin queues too in nvme_kill_queues() for avoiding hang in remove path[1]. This patch is very similar with 806f026f9b901eaf(nvme: use blk_mq_start_hw_queues() in nvme_kill_queues()). [1] hang stack trace [<ffffffff813c9716>] blk_execute_rq+0x56/0x80 [<ffffffff815cb6e9>] __nvme_submit_sync_cmd+0x89/0xf0 [<ffffffff815ce7be>] nvme_set_features+0x5e/0x90 [<ffffffff815ce9f6>] nvme_configure_apst+0x166/0x200 [<ffffffff815cef45>] nvme_set_latency_tolerance+0x35/0x50 [<ffffffff8157bd11>] apply_constraint+0xb1/0xc0 [<ffffffff8157cbb4>] dev_pm_qos_constraints_destroy+0xf4/0x1f0 [<ffffffff8157b44a>] dpm_sysfs_remove+0x2a/0x60 [<ffffffff8156d951>] device_del+0x101/0x320 [<ffffffff8156db8a>] device_unregister+0x1a/0x60 [<ffffffff8156dc4c>] device_destroy+0x3c/0x50 [<ffffffff815cd295>] nvme_uninit_ctrl+0x45/0xa0 [<ffffffff815d4858>] nvme_remove+0x78/0x110 [<ffffffff81452b69>] pci_device_remove+0x39/0xb0 [<ffffffff81572935>] device_release_driver_internal+0x155/0x210 [<ffffffff81572a02>] device_release_driver+0x12/0x20 [<ffffffff815d36fb>] nvme_remove_dead_ctrl_work+0x6b/0x70 [<ffffffff810bf3bc>] process_one_work+0x18c/0x3a0 [<ffffffff810bf61e>] worker_thread+0x4e/0x3b0 [<ffffffff810c5ac9>] kthread+0x109/0x140 [<ffffffff8185800c>] ret_from_fork+0x2c/0x40 [<ffffffffffffffff>] 0xffffffffffffffff Fixes: c5552fde102fc("nvme: Enable autonomous power state transitions") Reported-by: Rakesh Pandit <rakesh(a)tuxera.com> Tested-by: Rakesh Pandit <rakesh(a)tuxera.com> Reviewed-by: Sagi Grimberg <sagi(a)grimberg.me> Signed-off-by: Ming Lei <ming.lei(a)redhat.com> Signed-off-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/nvme/host/core.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/drivers/nvme/host/core.c +++ b/drivers/nvme/host/core.c @@ -2040,6 +2040,10 @@ void nvme_kill_queues(struct nvme_ctrl * struct nvme_ns *ns; mutex_lock(&ctrl->namespaces_mutex); + + /* Forcibly start all queues to avoid having stuck requests */ + blk_mq_start_hw_queues(ctrl->admin_q); + list_for_each_entry(ns, &ctrl->namespaces, list) { /* * Revalidating a dead namespace sets capacity to 0. This will Patches currently in stable-queue which might be from ming.lei(a)redhat.com are queue-4.9/blk-mq-fix-kernel-oops-in-blk_mq_tag_idle.patch queue-4.9/nvme-fix-hang-in-remove-path.patch queue-4.9/fix-loop-device-flush-before-configure-v3.patch queue-4.9/blk-mq-fix-race-between-updating-nr_hw_queues-and-switching-io-sched.patch

7 years, 8 months

1
0
0 0

Patch "NFSv4.1: Work around a Linux server bug..." has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled NFSv4.1: Work around a Linux server bug... to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: nfsv4.1-work-around-a-linux-server-bug.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Trond Myklebust <trond.myklebust(a)primarydata.com> Date: Tue, 9 May 2017 15:47:15 -0400 Subject: NFSv4.1: Work around a Linux server bug... From: Trond Myklebust <trond.myklebust(a)primarydata.com> [ Upstream commit f4b23de3dda1536590787c9e5c3d16b8738ab108 ] It turns out the Linux server has a bug in its implementation of supattr_exclcreat; it returns the set of all attributes, whether or not they are supported by minor version 1. In order to avoid a regression, we therefore apply the supported_attrs as a mask on top of whatever the server sent us. Reported-by: Anna Schumaker <Anna.Schumaker(a)Netapp.com> Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/nfs/nfs4proc.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/fs/nfs/nfs4proc.c +++ b/fs/nfs/nfs4proc.c @@ -3300,6 +3300,7 @@ static int _nfs4_server_capabilities(str .rpc_resp = &res, }; int status; + int i; bitmask[0] = FATTR4_WORD0_SUPPORTED_ATTRS | FATTR4_WORD0_FH_EXPIRE_TYPE | @@ -3365,8 +3366,13 @@ static int _nfs4_server_capabilities(str server->cache_consistency_bitmask[0] &= FATTR4_WORD0_CHANGE|FATTR4_WORD0_SIZE; server->cache_consistency_bitmask[1] &= FATTR4_WORD1_TIME_METADATA|FATTR4_WORD1_TIME_MODIFY; server->cache_consistency_bitmask[2] = 0; + + /* Avoid a regression due to buggy server */ + for (i = 0; i < ARRAY_SIZE(res.exclcreat_bitmask); i++) + res.exclcreat_bitmask[i] &= res.attr_bitmask[i]; memcpy(server->exclcreat_bitmask, res.exclcreat_bitmask, sizeof(server->exclcreat_bitmask)); + server->acl_bitmask = res.acl_bitmask; server->fh_expire_type = res.fh_expire_type; } Patches currently in stable-queue which might be from trond.myklebust(a)primarydata.com are queue-4.9/pnfs-flexfiles-missing-error-code-in-ff_layout_alloc_lseg.patch queue-4.9/nfsv4.1-work-around-a-linux-server-bug.patch queue-4.9/sunrpc-ensure-correct-error-is-reported-by-xs_tcp_setup_socket.patch queue-4.9/nfsv4.1-reclaim_complete-must-handle-nfs4err_conn_not_bound_to_session.patch

7 years, 8 months

1
0
0 0

Patch "netxen_nic: set rcode to the return status from the call to netxen_issue_cmd" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled netxen_nic: set rcode to the return status from the call to netxen_issue_cmd to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: netxen_nic-set-rcode-to-the-return-status-from-the-call-to-netxen_issue_cmd.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Colin Ian King <colin.king(a)canonical.com> Date: Tue, 9 May 2017 17:19:42 +0100 Subject: netxen_nic: set rcode to the return status from the call to netxen_issue_cmd From: Colin Ian King <colin.king(a)canonical.com> [ Upstream commit 0fe20fafd1791f993806d417048213ec57b81045 ] Currently rcode is being initialized to NX_RCODE_SUCCESS and later it is checked to see if it is not NX_RCODE_SUCCESS which is never true. It appears that there is an unintentional missing assignment of rcode from the return of the call to netxen_issue_cmd() that was dropped in an earlier fix, so add it in. Detected by CoverityScan, CID#401900 ("Logically dead code") Fixes: 2dcd5d95ad6b2 ("netxen_nic: fix cdrp race condition") Signed-off-by: Colin Ian King <colin.king(a)canonical.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/qlogic/netxen/netxen_nic_ctx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_ctx.c +++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_ctx.c @@ -247,7 +247,7 @@ nx_fw_cmd_set_mtu(struct netxen_adapter cmd.req.arg3 = 0; if (recv_ctx->state == NX_HOST_CTX_STATE_ACTIVE) - netxen_issue_cmd(adapter, &cmd); + rcode = netxen_issue_cmd(adapter, &cmd); if (rcode != NX_RCODE_SUCCESS) return -EIO; Patches currently in stable-queue which might be from colin.king(a)canonical.com are queue-4.9/wl1251-check-return-from-call-to-wl1251_acx_arp_ip_filter.patch queue-4.9/netxen_nic-set-rcode-to-the-return-status-from-the-call-to-netxen_issue_cmd.patch queue-4.9/btrfs-fix-incorrect-error-return-ret-being-passed-to-mapping_set_error.patch queue-4.9/ath5k-fix-memory-leak-on-buf-on-failed-eeprom-read.patch

7 years, 8 months

1
0
0 0

Patch "NFSv4.1: RECLAIM_COMPLETE must handle NFS4ERR_CONN_NOT_BOUND_TO_SESSION" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled NFSv4.1: RECLAIM_COMPLETE must handle NFS4ERR_CONN_NOT_BOUND_TO_SESSION to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: nfsv4.1-reclaim_complete-must-handle-nfs4err_conn_not_bound_to_session.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Trond Myklebust <trond.myklebust(a)primarydata.com> Date: Thu, 4 May 2017 13:44:04 -0400 Subject: NFSv4.1: RECLAIM_COMPLETE must handle NFS4ERR_CONN_NOT_BOUND_TO_SESSION From: Trond Myklebust <trond.myklebust(a)primarydata.com> [ Upstream commit 0048fdd06614a4ea088f9fcad11511956b795698 ] If the server returns NFS4ERR_CONN_NOT_BOUND_TO_SESSION because we are trunking, then RECLAIM_COMPLETE must handle that by calling nfs4_schedule_session_recovery() and then retrying. Reported-by: Chuck Lever <chuck.lever(a)oracle.com> Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com> Tested-by: Chuck Lever <chuck.lever(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/nfs/nfs4proc.c | 7 ++++++- fs/nfs/nfs4state.c | 10 +++++++--- 2 files changed, 13 insertions(+), 4 deletions(-) --- a/fs/nfs/nfs4proc.c +++ b/fs/nfs/nfs4proc.c @@ -8173,6 +8173,12 @@ static int nfs41_reclaim_complete_handle /* fall through */ case -NFS4ERR_RETRY_UNCACHED_REP: return -EAGAIN; + case -NFS4ERR_BADSESSION: + case -NFS4ERR_DEADSESSION: + case -NFS4ERR_CONN_NOT_BOUND_TO_SESSION: + nfs4_schedule_session_recovery(clp->cl_session, + task->tk_status); + break; default: nfs4_schedule_lease_recovery(clp); } @@ -8251,7 +8257,6 @@ static int nfs41_proc_reclaim_complete(s if (status == 0) status = task->tk_status; rpc_put_task(task); - return 0; out: dprintk("<-- %s status=%d\n", __func__, status); return status; --- a/fs/nfs/nfs4state.c +++ b/fs/nfs/nfs4state.c @@ -1637,13 +1637,14 @@ static void nfs4_state_start_reclaim_reb nfs4_state_mark_reclaim_helper(clp, nfs4_state_mark_reclaim_reboot); } -static void nfs4_reclaim_complete(struct nfs_client *clp, +static int nfs4_reclaim_complete(struct nfs_client *clp, const struct nfs4_state_recovery_ops *ops, struct rpc_cred *cred) { /* Notify the server we're done reclaiming our state */ if (ops->reclaim_complete) - (void)ops->reclaim_complete(clp, cred); + return ops->reclaim_complete(clp, cred); + return 0; } static void nfs4_clear_reclaim_server(struct nfs_server *server) @@ -1690,13 +1691,16 @@ static void nfs4_state_end_reclaim_reboo { const struct nfs4_state_recovery_ops *ops; struct rpc_cred *cred; + int err; if (!nfs4_state_clear_reclaim_reboot(clp)) return; ops = clp->cl_mvops->reboot_recovery_ops; cred = nfs4_get_clid_cred(clp); - nfs4_reclaim_complete(clp, ops, cred); + err = nfs4_reclaim_complete(clp, ops, cred); put_rpccred(cred); + if (err == -NFS4ERR_CONN_NOT_BOUND_TO_SESSION) + set_bit(NFS4CLNT_RECLAIM_REBOOT, &clp->cl_state); } static void nfs4_state_start_reclaim_nograce(struct nfs_client *clp) Patches currently in stable-queue which might be from trond.myklebust(a)primarydata.com are queue-4.9/pnfs-flexfiles-missing-error-code-in-ff_layout_alloc_lseg.patch queue-4.9/nfsv4.1-work-around-a-linux-server-bug.patch queue-4.9/sunrpc-ensure-correct-error-is-reported-by-xs_tcp_setup_socket.patch queue-4.9/nfsv4.1-reclaim_complete-must-handle-nfs4err_conn_not_bound_to_session.patch

7 years, 8 months

1
0
0 0

Patch "netfilter: ctnetlink: fix incorrect nf_ct_put during hash resize" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled netfilter: ctnetlink: fix incorrect nf_ct_put during hash resize to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: netfilter-ctnetlink-fix-incorrect-nf_ct_put-during-hash-resize.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Mon Apr 9 17:09:24 CEST 2018 From: Liping Zhang <zlpnobody(a)gmail.com> Date: Sun, 21 May 2017 07:22:49 +0800 Subject: netfilter: ctnetlink: fix incorrect nf_ct_put during hash resize From: Liping Zhang <zlpnobody(a)gmail.com> [ Upstream commit fefa92679dbe0c613e62b6c27235dcfbe9640ad1 ] If nf_conntrack_htable_size was adjusted by the user during the ct dump operation, we may invoke nf_ct_put twice for the same ct, i.e. the "last" ct. This will cause the ct will be freed but still linked in hash buckets. It's very easy to reproduce the problem by the following commands: # while : ; do echo $RANDOM > /proc/sys/net/netfilter/nf_conntrack_buckets done # while : ; do conntrack -L done # iperf -s 127.0.0.1 & # iperf -c 127.0.0.1 -P 60 -t 36000 After a while, the system will hang like this: NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [bash:20184] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [iperf:20382] ... So at last if we find cb->args[1] is equal to "last", this means hash resize happened, then we can set cb->args[1] to 0 to fix the above issue. Fixes: d205dc40798d ("[NETFILTER]: ctnetlink: fix deadlock in table dumping") Signed-off-by: Liping Zhang <zlpnobody(a)gmail.com> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/netfilter/nf_conntrack_netlink.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) --- a/net/netfilter/nf_conntrack_netlink.c +++ b/net/netfilter/nf_conntrack_netlink.c @@ -890,8 +890,13 @@ restart: } out: local_bh_enable(); - if (last) + if (last) { + /* nf ct hash resize happened, now clear the leftover. */ + if ((struct nf_conn *)cb->args[1] == last) + cb->args[1] = 0; + nf_ct_put(last); + } while (i) { i--; Patches currently in stable-queue which might be from zlpnobody(a)gmail.com are queue-4.9/netfilter-ctnetlink-fix-incorrect-nf_ct_put-during-hash-resize.patch

7 years, 8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror