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

Re: [PATCH 3.18 00/21] 3.18.113-stable review

by Greg Kroah-Hartman

On Tue, Jun 12, 2018 at 03:08:12PM -0700, kernelci.org bot wrote: > stable-rc/linux-3.18.y boot: 52 boots: 28 failed, 18 passed with 1 offline, 5 conflicts (v3.18.112-22-gb0582263e3c9) > > Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-3.18.y/kernel/v3.1… > Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-3.18.y/kernel/v3.18.112-2… > > Tree: stable-rc > Branch: linux-3.18.y > Git Describe: v3.18.112-22-gb0582263e3c9 > Git Commit: b0582263e3c9810fd887ca92d19cb9ff30a4d9f6 > Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > Tested: 24 unique boards, 12 SoC families, 13 builds out of 183 > > Boot Regressions Detected: > > arm: > > bcm2835_defconfig: > bcm2835-rpi-b: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > > davinci_all_defconfig: > dm365evm,legacy: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > > exynos_defconfig: > exynos5800-peach-pi: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > > imx_v6_v7_defconfig: > imx6dl-wandboard_dual: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > imx6dl-wandboard_solo: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > imx6q-wandboard: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > > multi_v7_defconfig: > am335x-boneblack: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > armada-xp-openblocks-ax3-4: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > exynos5800-peach-pi: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > imx6dl-wandboard_dual: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > imx6dl-wandboard_solo: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > imx6q-wandboard: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > omap3-beagle: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > omap3-beagle-xm: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > omap4-panda: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > sun4i-a10-cubieboard: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > sun7i-a20-cubietruck: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > tegra124-jetson-tk1: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > tegra20-iris-512: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > tegra30-beaver: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > zynq-zc702: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > > mvebu_v7_defconfig: > armada-xp-openblocks-ax3-4: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > > omap2plus_defconfig: > am335x-boneblack: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > omap3-beagle: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > omap3-beagle-xm: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > omap3-beagle-xm,legacy: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > omap4-panda: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > > sama5_defconfig: > at91-sama5d4ek: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > > sunxi_defconfig: > sun4i-a10-cubieboard: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > sun7i-a20-cubietruck: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > > tegra_defconfig: > tegra124-jetson-tk1: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > tegra20-iris-512: > lab-baylibre-seattle: new failure (last pass: v3.18.112) > tegra30-beaver: > lab-baylibre-seattle: new failure (last pass: v3.18.112) That is a lot of new failures, did the whole lab fail, or is this really a problem in v3.18.112 here? thanks, greg k-h

7 years, 5 months

3
4
0 0

[PATCH v3] target: fix truncated PR-in ReadKeys response

by David Disseldorp

SPC5r17 states that the contents of the ADDITIONAL LENGTH field are not altered based on the allocation length, so always calculate and pack the full key list length even if the list itself is truncated. According to Maged: Yes it fixes the "Storage Spaces Persistent Reservation" test in the Windows 2016 Server Failover Cluster validation suites when having many connections that result in more than 8 registrations. I tested your patch on 4.17 with iblock. This behaviour can be tested using the libiscsi PrinReadKeys.Truncate test. Cc: stable(a)vger.kernel.org Signed-off-by: David Disseldorp <ddiss(a)suse.de> Reviewed-by: Mike Christie <mchristi(a)redhat.com> Tested-by: Maged Mokhtar <mmokhtar(a)petasan.org> Reviewed-by: Christoph Hellwig <hch(a)lst.de> --- Changes since v2: * drop unnecessary braces * add Christoph's Reviewed-by Changes since v1: * CC stable * mention Maged's Windows PR test fix comment in commit message * add Reviewed-by and Tested-by tags drivers/target/target_core_pr.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/drivers/target/target_core_pr.c b/drivers/target/target_core_pr.c index 01ac306131c1..10db5656fd5d 100644 --- a/drivers/target/target_core_pr.c +++ b/drivers/target/target_core_pr.c @@ -3727,11 +3727,16 @@ core_scsi3_pri_read_keys(struct se_cmd *cmd) * Check for overflow of 8byte PRI READ_KEYS payload and * next reservation key list descriptor. */ - if ((add_len + 8) > (cmd->data_length - 8)) - break; - - put_unaligned_be64(pr_reg->pr_res_key, &buf[off]); - off += 8; + if (off + 8 <= cmd->data_length) { + put_unaligned_be64(pr_reg->pr_res_key, &buf[off]); + off += 8; + } + /* + * SPC5r17: 6.16.2 READ KEYS service action + * The ADDITIONAL LENGTH field indicates the number of bytes in + * the Reservation key list. The contents of the ADDITIONAL + * LENGTH field are not altered based on the allocation length + */ add_len += 8; } spin_unlock(&dev->t10_pr.registration_lock); -- 2.13.7

7 years, 5 months

2
1
0 0

[PATCH] scsi: sd: Optimal I/O size should be a multiple of physical block size

by Martin K. Petersen

It was reported that some devices report an OPTIMAL TRANSFER LENGTH of 0xFFFF blocks. That looks bogus, especially for a device with a 4096-byte physical block size. Ignore OPTIMAL TRANSFER LENGTH if it is not a multiple of the device's reported physical block size. Cc: <stable(a)vger.kernel.org> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199759 Reported-by: Christoph Anton Mitterer <calestyo(a)scientia.net> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> --- Before: NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME sda 0 4096 33553920 4096 512 0 mq-deadline 256 128 32M After: NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME sda 0 4096 0 4096 512 0 mq-deadline 256 4096 32M --- drivers/scsi/sd.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index 9421d9877730..2d19eed3dfbc 100644 --- a/drivers/scsi/sd.c +++ b/drivers/scsi/sd.c @@ -3067,7 +3067,7 @@ static int sd_revalidate_disk(struct gendisk *disk) struct request_queue *q = sdkp->disk->queue; sector_t old_capacity = sdkp->capacity; unsigned char *buffer; - unsigned int dev_max, rw_max; + unsigned int dev_max, rw_max, opt_xfer_bytes; SCSI_LOG_HLQUEUE(3, sd_printk(KERN_INFO, sdkp, "sd_revalidate_disk\n")); @@ -3126,13 +3126,16 @@ static int sd_revalidate_disk(struct gendisk *disk) /* * Determine the device's preferred I/O size for reads and writes - * unless the reported value is unreasonably small, large, or - * garbage. + * unless the reported value is unreasonably small, large, not a + * multiple of the physical block size, or simply garbage. */ + opt_xfer_bytes = logical_to_bytes(sdp, sdkp->opt_xfer_blocks); + if (sdkp->opt_xfer_blocks && sdkp->opt_xfer_blocks <= dev_max && sdkp->opt_xfer_blocks <= SD_DEF_XFER_BLOCKS && - logical_to_bytes(sdp, sdkp->opt_xfer_blocks) >= PAGE_SIZE) { + opt_xfer_bytes >= PAGE_SIZE && + (opt_xfer_bytes & (sdkp->physical_block_size - 1)) != 0) { q->limits.io_opt = logical_to_bytes(sdp, sdkp->opt_xfer_blocks); rw_max = logical_to_sectors(sdp, sdkp->opt_xfer_blocks); } else -- 2.17.1

7 years, 5 months

1
1
0 0

[PATCH v3 4/7] vmw_balloon: fix VMCI use when balloon built into kernel

by Nadav Amit

Currently, when all modules, including VMCI and VMware balloon are built into the kernel, the initialization of the balloon happens before the VMCI is probed. As a result, the balloon fails to initialize the VMCI doorbell, which it uses to get asynchronous requests for balloon size changes. The problem can be seen in the logs, in the form of the following message: "vmw_balloon: failed to initialize vmci doorbell" The driver would work correctly but slightly less efficiently, probing for requests periodically. This patch changes the balloon to be initialized using late_initcall() instead of module_init() to address this issue. It does not address a situation in which VMCI is built as a module and the balloon is built into the kernel. Fixes: 48e3d668b790 ("VMware balloon: Enable notification via VMCI") Cc: stable(a)vger.kernel.org Reviewed-by: Xavier Deguillard <xdeguillard(a)vmware.com> Signed-off-by: Nadav Amit <namit(a)vmware.com> --- drivers/misc/vmw_balloon.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/misc/vmw_balloon.c b/drivers/misc/vmw_balloon.c index a7df4c24a28d..e7cfc85f6961 100644 --- a/drivers/misc/vmw_balloon.c +++ b/drivers/misc/vmw_balloon.c @@ -1297,7 +1297,14 @@ static int __init vmballoon_init(void) return 0; } -module_init(vmballoon_init); + +/* + * Using late_initcall() instead of module_init() allows the balloon to use the + * VMCI doorbell even when the balloon is built into the kernel. Otherwise the + * VMCI is probed only after the balloon is initialized. If the balloon is used + * as a module, late_initcall() is equivalent to module_init(). + */ +late_initcall(vmballoon_init); static void __exit vmballoon_exit(void) { -- 2.17.0

7 years, 5 months

1
0
0 0

[PATCH v3 3/7] vmw_balloon: VMCI_DOORBELL_SET does not check status

by Nadav Amit

When vmballoon_vmci_init() sets a doorbell using VMCI_DOORBELL_SET, for some reason it does not consider the status and looks at the result. However, the hypervisor does not update the result - it updates the status. This might cause VMCI doorbell not to be enabled, resulting in degraded performance. Fixes: 48e3d668b790 ("VMware balloon: Enable notification via VMCI") Cc: stable(a)vger.kernel.org Reviewed-by: Xavier Deguillard <xdeguillard(a)vmware.com> Signed-off-by: Nadav Amit <namit(a)vmware.com> --- drivers/misc/vmw_balloon.c | 37 +++++++++++++++++++------------------ 1 file changed, 19 insertions(+), 18 deletions(-) diff --git a/drivers/misc/vmw_balloon.c b/drivers/misc/vmw_balloon.c index 60ab83d3d0ef..a7df4c24a28d 100644 --- a/drivers/misc/vmw_balloon.c +++ b/drivers/misc/vmw_balloon.c @@ -1036,29 +1036,30 @@ static void vmballoon_vmci_cleanup(struct vmballoon *b) */ static int vmballoon_vmci_init(struct vmballoon *b) { - int error = 0; + unsigned long error, dummy; - if ((b->capabilities & VMW_BALLOON_SIGNALLED_WAKEUP_CMD) != 0) { - error = vmci_doorbell_create(&b->vmci_doorbell, - VMCI_FLAG_DELAYED_CB, - VMCI_PRIVILEGE_FLAG_RESTRICTED, - vmballoon_doorbell, b); - - if (error == VMCI_SUCCESS) { - VMWARE_BALLOON_CMD(VMCI_DOORBELL_SET, - b->vmci_doorbell.context, - b->vmci_doorbell.resource, error); - STATS_INC(b->stats.doorbell_set); - } - } + if ((b->capabilities & VMW_BALLOON_SIGNALLED_WAKEUP_CMD) == 0) + return 0; - if (error != 0) { - vmballoon_vmci_cleanup(b); + error = vmci_doorbell_create(&b->vmci_doorbell, VMCI_FLAG_DELAYED_CB, + VMCI_PRIVILEGE_FLAG_RESTRICTED, + vmballoon_doorbell, b); - return -EIO; - } + if (error != VMCI_SUCCESS) + goto fail; + + error = VMWARE_BALLOON_CMD(VMCI_DOORBELL_SET, b->vmci_doorbell.context, + b->vmci_doorbell.resource, dummy); + + STATS_INC(b->stats.doorbell_set); + + if (error != VMW_BALLOON_SUCCESS) + goto fail; return 0; +fail: + vmballoon_vmci_cleanup(b); + return -EIO; } /* -- 2.17.0

7 years, 5 months

1
0
0 0

[PATCH v3 2/7] vmw_balloon: do not use 2MB without batching

by Nadav Amit

If the hypervisor sets 2MB batching is on, while batching is cleared, the balloon code breaks. In this case the legacy mechanism is used with 2MB page. The VM would report a 2MB page is ballooned, and the hypervisor would only take the first 4KB. While the hypervisor should not report such settings, make the code more robust by not enabling 2MB support without batching. Fixes: 365bd7ef7ec8e ("VMware balloon: Support 2m page ballooning.") Cc: stable(a)vger.kernel.org Reviewed-by: Xavier Deguillard <xdeguillard(a)vmware.com> Signed-off-by: Nadav Amit <nadav.amit(a)gmail.com> --- drivers/misc/vmw_balloon.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/misc/vmw_balloon.c b/drivers/misc/vmw_balloon.c index 28e77ab1e136..60ab83d3d0ef 100644 --- a/drivers/misc/vmw_balloon.c +++ b/drivers/misc/vmw_balloon.c @@ -341,7 +341,13 @@ static bool vmballoon_send_start(struct vmballoon *b, unsigned long req_caps) success = false; } - if (b->capabilities & VMW_BALLOON_BATCHED_2M_CMDS) + /* + * 2MB pages are only supported with batching. If batching is for some + * reason disabled, do not use 2MB pages, since otherwise the legacy + * mechanism is used with 2MB pages, causing a failure. + */ + if ((b->capabilities & VMW_BALLOON_BATCHED_2M_CMDS) && + (b->capabilities & VMW_BALLOON_BATCHED_CMDS)) b->supported_page_sizes = 2; else b->supported_page_sizes = 1; -- 2.17.0

7 years, 5 months

1
0
0 0

[PATCH v3 1/7] vmw_balloon: fix inflation of 64-bit GFNs

by Nadav Amit

When balloon batching is not supported by the hypervisor, the guest frame number (GFN) must fit in 32-bit. However, due to a bug, this check was mistakenly ignored. In practice, when total RAM is greater than 16TB, the balloon does not work currently, making this bug unlikely to happen. Fixes: ef0f8f112984 ("VMware balloon: partially inline vmballoon_reserve_page.") Cc: stable(a)vger.kernel.org Reviewed-by: Xavier Deguillard <xdeguillard(a)vmware.com> Signed-off-by: Nadav Amit <namit(a)vmware.com> --- drivers/misc/vmw_balloon.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/misc/vmw_balloon.c b/drivers/misc/vmw_balloon.c index efd733472a35..28e77ab1e136 100644 --- a/drivers/misc/vmw_balloon.c +++ b/drivers/misc/vmw_balloon.c @@ -450,7 +450,7 @@ static int vmballoon_send_lock_page(struct vmballoon *b, unsigned long pfn, pfn32 = (u32)pfn; if (pfn32 != pfn) - return -1; + return -EINVAL; STATS_INC(b->stats.lock[false]); @@ -460,7 +460,7 @@ static int vmballoon_send_lock_page(struct vmballoon *b, unsigned long pfn, pr_debug("%s - ppn %lx, hv returns %ld\n", __func__, pfn, status); STATS_INC(b->stats.lock_fail[false]); - return 1; + return -EIO; } static int vmballoon_send_batched_lock(struct vmballoon *b, @@ -597,11 +597,12 @@ static int vmballoon_lock_page(struct vmballoon *b, unsigned int num_pages, locked = vmballoon_send_lock_page(b, page_to_pfn(page), &hv_status, target); - if (locked > 0) { + if (locked) { STATS_INC(b->stats.refused_alloc[false]); - if (hv_status == VMW_BALLOON_ERROR_RESET || - hv_status == VMW_BALLOON_ERROR_PPN_NOTNEEDED) { + if (locked == -EIO && + (hv_status == VMW_BALLOON_ERROR_RESET || + hv_status == VMW_BALLOON_ERROR_PPN_NOTNEEDED)) { vmballoon_free_page(page, false); return -EIO; } @@ -617,7 +618,7 @@ static int vmballoon_lock_page(struct vmballoon *b, unsigned int num_pages, } else { vmballoon_free_page(page, false); } - return -EIO; + return locked; } /* track allocated page */ -- 2.17.0

7 years, 5 months

1
0
0 0

+ slub-fix-__kmem_cache_empty-for-config_slub_debug.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: slub: fix __kmem_cache_empty for !CONFIG_SLUB_DEBUG has been added to the -mm tree. Its filename is slub-fix-__kmem_cache_empty-for-config_slub_debug.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/slub-fix-__kmem_cache_empty-for-co… and later at http://ozlabs.org/~akpm/mmotm/broken-out/slub-fix-__kmem_cache_empty-for-co… 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: Shakeel Butt <shakeelb(a)google.com> Subject: slub: fix __kmem_cache_empty for !CONFIG_SLUB_DEBUG f9e13c0a5a33 ("slab, slub: skip unnecessary kasan_cache_shutdown()") causes crashes when using slub, as described at http://lkml.kernel.org/r/CAHmME9rtoPwxUSnktxzKso14iuVCWT7BE_-_8PAC=pGw1iJnQ… For !CONFIG_SLUB_DEBUG, SLUB does not maintain the number of slabs allocated per node for a kmem_cache. Thus, slabs_node() in __kmem_cache_empty() will always return 0. So, in such situation, it is required to check per-cpu slabs to make sure if a kmem_cache is empty or not. Please note that __kmem_cache_shutdown() and __kmem_cache_shrink() are not affected by !CONFIG_SLUB_DEBUG as they call flush_all() to clear per-cpu slabs. Link: http://lkml.kernel.org/r/20180619213352.71740-1-shakeelb@google.com Link: http://lkml.kernel.org/r/CAHmME9rtoPwxUSnktxzKso14iuVCWT7BE_-_8PAC=pGw1iJnQ… Fixes: f9e13c0a5a33 ("slab, slub: skip unnecessary kasan_cache_shutdown()") Signed-off-by: Shakeel Butt <shakeelb(a)google.com> Reported-by: Jason A. Donenfeld <Jason(a)zx2c4.com> Tested-by: Jason A. Donenfeld <Jason(a)zx2c4.com> Cc: Christoph Lameter <cl(a)linux.com> Cc: Pekka Enberg <penberg(a)kernel.org> Cc: David Rientjes <rientjes(a)google.com> Cc: Joonsoo Kim <iamjoonsoo.kim(a)lge.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/slub.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff -puN mm/slub.c~slub-fix-__kmem_cache_empty-for-config_slub_debug mm/slub.c --- a/mm/slub.c~slub-fix-__kmem_cache_empty-for-config_slub_debug +++ a/mm/slub.c @@ -3673,9 +3673,23 @@ static void free_partial(struct kmem_cac bool __kmem_cache_empty(struct kmem_cache *s) { - int node; + int cpu, node; struct kmem_cache_node *n; + /* + * slabs_node will always be 0 for !CONFIG_SLUB_DEBUG. So, manually + * check slabs for all cpus. + */ + if (!IS_ENABLED(CONFIG_SLUB_DEBUG)) { + for_each_online_cpu(cpu) { + struct kmem_cache_cpu *c; + + c = per_cpu_ptr(s->cpu_slab, cpu); + if (c->page || slub_percpu_partial(c)) + return false; + } + } + for_each_kmem_cache_node(s, node, n) if (n->nr_partial || slabs_node(s, node)) return false; _ Patches currently in -mm which might be from shakeelb(a)google.com are slub-fix-__kmem_cache_empty-for-config_slub_debug.patch

7 years, 5 months

1
0
0 0

[to-be-updated] mm-devm_memremap_pages-handle-errors-allocating-final-devres-action.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm, devm_memremap_pages: handle errors allocating final devres action has been removed from the -mm tree. Its filename was mm-devm_memremap_pages-handle-errors-allocating-final-devres-action.patch This patch was dropped because an updated version will be merged ------------------------------------------------------ From: Dan Williams <dan.j.williams(a)intel.com> Subject: mm, devm_memremap_pages: handle errors allocating final devres action The last step before devm_memremap_pages() returns success is to allocate a release action to tear the entire setup down. However, the result from devm_add_action() is not checked. Checking the error also means that we need to handle the fact that the percpu_ref may not be killed by the time devm_memremap_pages_release() runs. Add a new state flag for this case. Without this change we could fail to register the teardown of devm_memremap_pages(). The likelihood of hitting this failure is tiny as small memory allocations almost always succeed. However, the impact of the failure is large given any future reconfiguration, or disable/enable, of an nvdimm namespace will fail forever as subsequent calls to devm_memremap_pages() will fail to setup the pgmap_radix since there will be stale entries for the physical address range. Link: http://lkml.kernel.org/r/152694212460.5484.13180030631810166467.stgit@dwill… Fixes: e8d513483300 ("memremap: change devm_memremap_pages interface...") Signed-off-by: Dan Williams <dan.j.williams(a)intel.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Cc: "Jérôme Glisse" <jglisse(a)redhat.com> Cc: Logan Gunthorpe <logang(a)deltatee.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/memremap.h | 1 + kernel/memremap.c | 8 ++++++-- 2 files changed, 7 insertions(+), 2 deletions(-) diff -puN include/linux/memremap.h~mm-devm_memremap_pages-handle-errors-allocating-final-devres-action include/linux/memremap.h --- a/include/linux/memremap.h~mm-devm_memremap_pages-handle-errors-allocating-final-devres-action +++ a/include/linux/memremap.h @@ -115,6 +115,7 @@ struct dev_pagemap { dev_page_free_t page_free; struct vmem_altmap altmap; bool altmap_valid; + bool registered; struct resource res; struct percpu_ref *ref; struct device *dev; diff -puN kernel/memremap.c~mm-devm_memremap_pages-handle-errors-allocating-final-devres-action kernel/memremap.c --- a/kernel/memremap.c~mm-devm_memremap_pages-handle-errors-allocating-final-devres-action +++ a/kernel/memremap.c @@ -124,7 +124,7 @@ static void devm_memremap_pages_release( for_each_device_pfn(pfn, pgmap) put_page(pfn_to_page(pfn)); - if (percpu_ref_tryget_live(pgmap->ref)) { + if (pgmap->registered && percpu_ref_tryget_live(pgmap->ref)) { dev_WARN(dev, "%s: page mapping is still live!\n", __func__); percpu_ref_put(pgmap->ref); } @@ -246,7 +246,11 @@ void *devm_memremap_pages(struct device percpu_ref_get(pgmap->ref); } - devm_add_action(dev, devm_memremap_pages_release, pgmap); + error = devm_add_action_or_reset(dev, devm_memremap_pages_release, + pgmap); + if (error) + return ERR_PTR(error); + pgmap->registered = true; return __va(res->start); _ Patches currently in -mm which might be from dan.j.williams(a)intel.com are mm-hmm-use-devm-semantics-for-hmm_devmem_add-remove.patch mm-hmm-replace-hmm_devmem_pages_create-with-devm_memremap_pages.patch mm-hmm-mark-hmm_devmem_add-add_resource-export_symbol_gpl.patch

7 years, 5 months

1
0
0 0

[PATCH 4.4 1/2] Revert "Btrfs: fix scrub to repair raid6 corruption"

by Sasha Levin

This reverts commit 95b286daf7ba784191023ad110122703eb2ebabc. This commit used an incorrect log message. Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> --- fs/btrfs/raid56.c | 18 ++++-------------- fs/btrfs/volumes.c | 9 +-------- 2 files changed, 5 insertions(+), 22 deletions(-) diff --git a/fs/btrfs/raid56.c b/fs/btrfs/raid56.c index b9fa99577bf7..1a33d3eb36de 100644 --- a/fs/btrfs/raid56.c +++ b/fs/btrfs/raid56.c @@ -2160,21 +2160,11 @@ int raid56_parity_recover(struct btrfs_root *root, struct bio *bio, } /* - * Loop retry: - * for 'mirror == 2', reconstruct from all other stripes. - * for 'mirror_num > 2', select a stripe to fail on every retry. + * reconstruct from the q stripe if they are + * asking for mirror 3 */ - if (mirror_num > 2) { - /* - * 'mirror == 3' is to fail the p stripe and - * reconstruct from the q stripe. 'mirror > 3' is to - * fail a data stripe and reconstruct from p+q stripe. - */ - rbio->failb = rbio->real_stripes - (mirror_num - 1); - ASSERT(rbio->failb > 0); - if (rbio->failb <= rbio->faila) - rbio->failb--; - } + if (mirror_num == 3) + rbio->failb = rbio->real_stripes - 2; ret = lock_stripe_add(rbio); diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index b4d63a9842fa..ed75d70b4bc2 100644 --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -5056,14 +5056,7 @@ int btrfs_num_copies(struct btrfs_fs_info *fs_info, u64 logical, u64 len) else if (map->type & BTRFS_BLOCK_GROUP_RAID5) ret = 2; else if (map->type & BTRFS_BLOCK_GROUP_RAID6) - /* - * There could be two corrupted data stripes, we need - * to loop retry in order to rebuild the correct data. - * - * Fail a stripe at a time on every retry except the - * stripe under reconstruction. - */ - ret = map->num_stripes; + ret = 3; else ret = 1; free_extent_map(em); -- 2.17.1

7 years, 5 months

2
5
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror