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

[PATCH stable 4.18/4.19] bpf: fix partial copy of map_ptr when dst is scalar

by Daniel Borkmann

commit 0962590e553331db2cc0aef2dc35c57f6300dbbe upstream. ALU operations on pointers such as scalar_reg += map_value_ptr are handled in adjust_ptr_min_max_vals(). Problem is however that map_ptr and range in the register state share a union, so transferring state through dst_reg->range = ptr_reg->range is just buggy as any new map_ptr in the dst_reg is then truncated (or null) for subsequent checks. Fix this by adding a raw member and use it for copying state over to dst_reg. Fixes: f1174f77b50c ("bpf/verifier: rework value tracking") Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net> Cc: Edward Cree <ecree(a)solarflare.com> Acked-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Acked-by: Edward Cree <ecree(a)solarflare.com> --- include/linux/bpf_verifier.h | 3 +++ kernel/bpf/verifier.c | 10 ++++++---- 2 files changed, 9 insertions(+), 4 deletions(-) diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h index 38b04f5..1fd6fa8 100644 --- a/include/linux/bpf_verifier.h +++ b/include/linux/bpf_verifier.h @@ -50,6 +50,9 @@ struct bpf_reg_state { * PTR_TO_MAP_VALUE_OR_NULL */ struct bpf_map *map_ptr; + + /* Max size from any of the above. */ + unsigned long raw; }; /* Fixed part of pointer offset, pointer types only */ s32 off; diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index 82e8ede..b000686 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -2731,7 +2731,7 @@ static int adjust_ptr_min_max_vals(struct bpf_verifier_env *env, dst_reg->umax_value = umax_ptr; dst_reg->var_off = ptr_reg->var_off; dst_reg->off = ptr_reg->off + smin_val; - dst_reg->range = ptr_reg->range; + dst_reg->raw = ptr_reg->raw; break; } /* A new variable offset is created. Note that off_reg->off @@ -2761,10 +2761,11 @@ static int adjust_ptr_min_max_vals(struct bpf_verifier_env *env, } dst_reg->var_off = tnum_add(ptr_reg->var_off, off_reg->var_off); dst_reg->off = ptr_reg->off; + dst_reg->raw = ptr_reg->raw; if (reg_is_pkt_pointer(ptr_reg)) { dst_reg->id = ++env->id_gen; /* something was added to pkt_ptr, set range to zero */ - dst_reg->range = 0; + dst_reg->raw = 0; } break; case BPF_SUB: @@ -2793,7 +2794,7 @@ static int adjust_ptr_min_max_vals(struct bpf_verifier_env *env, dst_reg->var_off = ptr_reg->var_off; dst_reg->id = ptr_reg->id; dst_reg->off = ptr_reg->off - smin_val; - dst_reg->range = ptr_reg->range; + dst_reg->raw = ptr_reg->raw; break; } /* A new variable offset is created. If the subtrahend is known @@ -2819,11 +2820,12 @@ static int adjust_ptr_min_max_vals(struct bpf_verifier_env *env, } dst_reg->var_off = tnum_sub(ptr_reg->var_off, off_reg->var_off); dst_reg->off = ptr_reg->off; + dst_reg->raw = ptr_reg->raw; if (reg_is_pkt_pointer(ptr_reg)) { dst_reg->id = ++env->id_gen; /* something was added to pkt_ptr, set range to zero */ if (smin_val < 0) - dst_reg->range = 0; + dst_reg->raw = 0; } break; case BPF_AND: -- 2.9.5

7 years, 1 month

2
1
0 0

[PATCH 4.14 0/2] USB: serial: option: Backport Quectel EP06/endpoint patches

by Kristian Evensen

This patch series contains backports for 4.14 of two patches that were submitted to stable, but failed to apply. One patch adds support for dynamic interface configuration on the Quectel EP06, while the other contains an upstream change triggered by the EP06-change. The reason the patches failed to apply, is that option_probe() in option.c has been changed upstream. A slight reshuffling of the changes in "USB: serial: option: improve Quectel EP06 detection" was required. "USB: serial: option: add two-endpoints device-id flag" applied cleanly after the change, but a small change was still needed. The upstream commit removes a variable that is still in use in 4.14, so this change is removed. Signed-off-by: Kristian Evensen <kristian.evensen(a)gmail.com> Johan Hovold (1): USB: serial: option: add two-endpoints device-id flag Kristian Evensen (1): USB: serial: option: improve Quectel EP06 detection drivers/usb/serial/option.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) -- 2.14.1

7 years, 1 month

2
3
0 0

+ mm-use-kvzalloc-for-swap_info_struct-allocation.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/swapfile.c: use kvzalloc for swap_info_struct allocation has been added to the -mm tree. Its filename is mm-use-kvzalloc-for-swap_info_struct-allocation.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-use-kvzalloc-for-swap_info_stru… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-use-kvzalloc-for-swap_info_stru… 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: Vasily Averin <vvs(a)virtuozzo.com> Subject: mm/swapfile.c: use kvzalloc for swap_info_struct allocation a2468cc9bfdf ("swap: choose swap device according to numa node") changed 'avail_lists' field of 'struct swap_info_struct' to an array. In popular linux distros it increased size of swap_info_struct up to 40 Kbytes and now swap_info_struct allocation requires order-4 page. Switch to kvzmalloc allows to avoid unexpected allocation failures. Link: http://lkml.kernel.org/r/fc23172d-3c75-21e2-d551-8b1808cbe593@virtuozzo.com Fixes: a2468cc9bfdf ("swap: choose swap device according to numa node") Signed-off-by: Vasily Averin <vvs(a)virtuozzo.com> Acked-by: Aaron Lu <aaron.lu(a)intel.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org> Cc: Huang Ying <ying.huang(a)intel.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/swapfile.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/mm/swapfile.c~mm-use-kvzalloc-for-swap_info_struct-allocation +++ a/mm/swapfile.c @@ -2813,7 +2813,7 @@ static struct swap_info_struct *alloc_sw unsigned int type; int i; - p = kzalloc(sizeof(*p), GFP_KERNEL); + p = kvzalloc(sizeof(*p), GFP_KERNEL); if (!p) return ERR_PTR(-ENOMEM); @@ -2824,7 +2824,7 @@ static struct swap_info_struct *alloc_sw } if (type >= MAX_SWAPFILES) { spin_unlock(&swap_lock); - kfree(p); + kvfree(p); return ERR_PTR(-EPERM); } if (type >= nr_swapfiles) { @@ -2838,7 +2838,7 @@ static struct swap_info_struct *alloc_sw smp_wmb(); nr_swapfiles++; } else { - kfree(p); + kvfree(p); p = swap_info[type]; /* * Do not memset this entry: a racing procfs swap_next() _ Patches currently in -mm which might be from vvs(a)virtuozzo.com are mm-use-kvzalloc-for-swap_info_struct-allocation.patch

7 years, 1 month

1
0
0 0

4.14/4.18: Please add "eeprom: at24: Add support for address-width property"

by Adrian Bunk

Please cherry-pick the following commit to 4.14 and 4.18: commit a2b3bf4846e5eed62ea6abb096af2c950961033c Author: Alan Chiang <alanx.chiang(a)intel.com> Date: Wed Jul 25 11:20:22 2018 +0800 eeprom: at24: Add support for address-width property Provide a flexible way to determine the addressing bits of eeprom. Pass the addressing bits to driver through address-width property. Signed-off-by: Alan Chiang <alanx.chiang(a)intel.com> Signed-off-by: Andy Yeh <andy.yeh(a)intel.com> Signed-off-by: Bartosz Golaszewski <brgl(a)bgdev.pl> Confirmed to work on 4.14 with the Identification Page of an ST M24M02-DR (256 bytes but 16 bit addressing). Cannot be cherry-picked trivially on 4.9. The corresponding documentation commit 21d04054501fb27b56e995b54ac74e39aee79a46 can be cherry-picked to 4.18, the backport for 4.14 is below. Thanks Adrian >From 2562e333f39b8077ffb06bdf79430f10b74c11f5 Mon Sep 17 00:00:00 2001 From: Alan Chiang <alanx.chiang(a)intel.com> Date: Wed, 25 Jul 2018 11:20:21 +0800 Subject: [PATCH] dt-bindings: at24: Add address-width property Currently the only way to use a variant of a supported model with a different address width is to define a new compatible string and the corresponding chip data structure. Provide a flexible way to specify the size of the address pointer by defining a new property: address-width. Signed-off-by: Alan Chiang <alanx.chiang(a)intel.com> Signed-off-by: Andy Yeh <andy.yeh(a)intel.com> Acked-by: Sakari Ailus <sakari.ailus(a)linux.intel.com> Reviewed-by: Rob Herring <robh(a)kernel.org> [Bartosz: fixed the commit message] Signed-off-by: Bartosz Golaszewski <brgl(a)bgdev.pl> [Adrian Bunk: backported to 4.14] Signed-off-by: Adrian Bunk <bunk(a)kernel.org> --- Documentation/devicetree/bindings/eeprom/eeprom.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt b/Documentation/devicetree/bindings/eeprom/eeprom.txt index afc04589eadf..44bfffc43bed 100644 --- a/Documentation/devicetree/bindings/eeprom/eeprom.txt +++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt @@ -36,6 +36,8 @@ Optional properties: - read-only: this parameterless property disables writes to the eeprom + - address-width: number of address bits (one of 8, 16). + Example: eeprom@52 { -- 2.11.0

7 years, 1 month

3
4
0 0

[PATCH] ahci: don't ignore result code of ahci_reset_controller()

by Loic

Hello, Please picked up this patch for linux 4.4 and 4.9. Compiled/tested without problem. [ Upstream commit d312fefea8387503375f728855c9a62de20c9665 ] From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Date: Mon, 2 Oct 2017 19:31:24 +0100 Subject: [PATCH] ahci: don't ignore result code of ahci_reset_controller() ahci_pci_reset_controller() calls ahci_reset_controller(), which may fail, but ignores the result code and always returns success. This may result in failures like below ahci 0000:02:00.0: version 3.0 ahci 0000:02:00.0: enabling device (0000 -> 0003) ahci 0000:02:00.0: SSS flag set, parallel bus scan disabled ahci 0000:02:00.0: controller reset failed (0xffffffff) ahci 0000:02:00.0: failed to stop engine (-5) ... repeated many times ... ahci 0000:02:00.0: failed to stop engine (-5) Unable to handle kernel paging request at virtual address ffff0000093f9018 ... PC is at ahci_stop_engine+0x5c/0xd8 [libahci] LR is at ahci_deinit_port.constprop.12+0x1c/0xc0 [libahci] ... [<ffff000000a17014>] ahci_stop_engine+0x5c/0xd8 [libahci] [<ffff000000a196b4>] ahci_deinit_port.constprop.12+0x1c/0xc0 [libahci] [<ffff000000a197d8>] ahci_init_controller+0x80/0x168 [libahci] [<ffff000000a260f8>] ahci_pci_init_controller+0x60/0x68 [ahci] [<ffff000000a26f94>] ahci_init_one+0x75c/0xd88 [ahci] [<ffff000008430324>] local_pci_probe+0x3c/0xb8 [<ffff000008431728>] pci_device_probe+0x138/0x170 [<ffff000008585e54>] driver_probe_device+0x2dc/0x458 [<ffff0000085860e4>] __driver_attach+0x114/0x118 [<ffff000008583ca8>] bus_for_each_dev+0x60/0xa0 [<ffff000008585638>] driver_attach+0x20/0x28 [<ffff0000085850b0>] bus_add_driver+0x1f0/0x2a8 [<ffff000008586ae0>] driver_register+0x60/0xf8 [<ffff00000842f9b4>] __pci_register_driver+0x3c/0x48 [<ffff000000a3001c>] ahci_pci_driver_init+0x1c/0x1000 [ahci] [<ffff000008083918>] do_one_initcall+0x38/0x120 where an obvious hardware level failure results in an unnecessary 15 second delay and a subsequent crash. So record the result code of ahci_reset_controller() and relay it, rather than ignoring it. Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Signed-off-by: Tejun Heo <tj(a)kernel.org> --- drivers/ata/ahci.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c index cb9b0e9090e3b..9f78bb03bb763 100644 --- a/drivers/ata/ahci.c +++ b/drivers/ata/ahci.c @@ -621,8 +621,11 @@ static void ahci_pci_save_initial_config(struct pci_dev *pdev, static int ahci_pci_reset_controller(struct ata_host *host) { struct pci_dev *pdev = to_pci_dev(host->dev); + int rc; - ahci_reset_controller(host); + rc = ahci_reset_controller(host); + if (rc) + return rc; if (pdev->vendor == PCI_VENDOR_ID_INTEL) { struct ahci_host_priv *hpriv = host->private_data;

7 years, 1 month

2
1
0 0

[PATCH] mfd: max8925-i2c: Drop unnecessary static

by Loic

Hello, Please picked up this patch for linux 4.4 and 4.9. Compiled/tested without problem. [ Upstream commit 0953075112d7626474b0bb88690f5f1ab93ec803 ] From: Julia Lawall <Julia.Lawall(a)lip6.fr> Date: Thu, 4 May 2017 22:10:54 +0200 Subject: [PATCH] mfd: max8925-i2c: Drop unnecessary static Drop static on a local variable, when the variable is initialized before any use, on every possible execution path through the function. The static has no benefit, and dropping it reduces the code size. The semantic patch that fixes this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @bad exists@ position p; identifier x; type T; @@ static T x@p; ... x = <+...x...+> @@ identifier x; expression e; type T; position p != bad.p; @@ -static T x@p; ... when != x when strict ?x = e; // </smpl> The change in code size is indicates by the following output from the size command. before: text data bss dec hex filename 2579 240 16 2835 b13 drivers/mfd/max8925-i2c.o after: text data bss dec hex filename 2531 240 8 2779 adb drivers/mfd/max8925-i2c.o Signed-off-by: Julia Lawall <Julia.Lawall(a)lip6.fr> Acked-by: Kees Cook <keescook(a)chromium.org> Signed-off-by: Lee Jones <lee.jones(a)linaro.org> --- drivers/mfd/max8925-i2c.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mfd/max8925-i2c.c b/drivers/mfd/max8925-i2c.c index 5c80aea3211fd..10063236132c1 100644 --- a/drivers/mfd/max8925-i2c.c +++ b/drivers/mfd/max8925-i2c.c @@ -151,7 +151,7 @@ static int max8925_probe(struct i2c_client *client, const struct i2c_device_id *id) { struct max8925_platform_data *pdata = dev_get_platdata(&client->dev); - static struct max8925_chip *chip; + struct max8925_chip *chip; struct device_node *node = client->dev.of_node; if (node && !pdata) {

7 years, 1 month

2
1
0 0

[PATCH] crypto: shash - Fix a sleep-in-atomic bug in shash_setkey_unaligned

by Loic

Hello, Please picked up this patch for linux 4.4 and 4.9. Compiled/tested without problem. [ Upstream commit 9039f3ef446e9ffa200200c934f049add9e58426 ] From: Jia-Ju Bai <baijiaju1990(a)163.com> Date: Tue, 3 Oct 2017 10:25:22 +0800 Subject: [PATCH] crypto: shash - Fix a sleep-in-atomic bug in shash_setkey_unaligned The SCTP program may sleep under a spinlock, and the function call path is: sctp_generate_t3_rtx_event (acquire the spinlock) sctp_do_sm sctp_side_effects sctp_cmd_interpreter sctp_make_init_ack sctp_pack_cookie crypto_shash_setkey shash_setkey_unaligned kmalloc(GFP_KERNEL) For the same reason, the orinoco driver may sleep in interrupt handler, and the function call path is: orinoco_rx_isr_tasklet orinoco_rx orinoco_mic crypto_shash_setkey shash_setkey_unaligned kmalloc(GFP_KERNEL) To fix it, GFP_KERNEL is replaced with GFP_ATOMIC. This bug is found by my static analysis tool and my code review. Signed-off-by: Jia-Ju Bai <baijiaju1990(a)163.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> --- crypto/shash.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/crypto/shash.c b/crypto/shash.c index 5e31c8d776dfc..8fcecc66741d1 100644 --- a/crypto/shash.c +++ b/crypto/shash.c @@ -41,7 +41,7 @@ static int shash_setkey_unaligned(struct crypto_shash *tfm, const u8 *key, int err; absize = keylen + (alignmask & ~(crypto_tfm_ctx_alignment() - 1)); - buffer = kmalloc(absize, GFP_KERNEL); + buffer = kmalloc(absize, GFP_ATOMIC); if (!buffer) return -ENOMEM;

7 years, 1 month

2
1
0 0

[PATCH] mtd: nand: Fix nanddev_neraseblocks()

by Boris Brezillon

nanddev_neraseblocks() currently returns the number pages per LUN instead of the total number of eraseblocks. Fixes: 9c3736a3de21 ("mtd: nand: Add core infrastructure to deal with NAND devices") Cc: <stable(a)vger.kernel.org> Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com> --- include/linux/mtd/nand.h | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h index abe975c87b90..78b86dea2f29 100644 --- a/include/linux/mtd/nand.h +++ b/include/linux/mtd/nand.h @@ -324,9 +324,8 @@ static inline unsigned int nanddev_ntargets(const struct nand_device *nand) */ static inline unsigned int nanddev_neraseblocks(const struct nand_device *nand) { - return (u64)nand->memorg.luns_per_target * - nand->memorg.eraseblocks_per_lun * - nand->memorg.pages_per_eraseblock; + return nand->memorg.ntargets * nand->memorg.luns_per_target * + nand->memorg.eraseblocks_per_lun; } /** -- 2.17.1

7 years, 1 month

2
2
0 0

[PATCH 1/2] mtd: docg3: don't set conflicting BCH_CONST_PARAMS option

by Arnd Bergmann

I noticed during the creation of another bugfix that the BCH_CONST_PARAMS option that is set by DOCG3 breaks setting variable parameters for any other users of the BCH library code. The only other user we have today is the MTD_NAND software BCH implementation (most flash controllers use hardware BCH these days and are not affected). I considered removing BCH_CONST_PARAMS entirely because of the inherent conflict, but according to the description in lib/bch.c there is a significant performance benefit in keeping it. To avoid the immediate problem of the conflict between MTD_NAND_BCH and DOCG3, this only sets the constant parameters if MTD_NAND_BCH is disabled, which should fix the problem for all cases that are affected. This should also work for all stable kernels. Note that there is only one machine that actually seems to use the DOCG3 driver (arch/arm/mach-pxa/mioa701.c), so most users should have the driver disabled, but it almost certainly shows up if we wanted to test random kernels on machines that use software BCH in MTD. Fixes: d13d19ece39f ("mtd: docg3: add ECC correction code") Cc: stable(a)vger.kernel.org Cc: Robert Jarzmik <robert.jarzmik(a)free.fr> Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- drivers/mtd/devices/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/devices/Kconfig b/drivers/mtd/devices/Kconfig index e514d57a0419..aa983422aa97 100644 --- a/drivers/mtd/devices/Kconfig +++ b/drivers/mtd/devices/Kconfig @@ -207,7 +207,7 @@ comment "Disk-On-Chip Device Drivers" config MTD_DOCG3 tristate "M-Systems Disk-On-Chip G3" select BCH - select BCH_CONST_PARAMS + select BCH_CONST_PARAMS if !MTD_NAND_BCH select BITREVERSE help This provides an MTD device driver for the M-Systems DiskOnChip -- 2.18.0

7 years, 1 month

2
2
0 0

[PATCH AUTOSEL 4.19 01/57] mm: thp: fix MADV_DONTNEED vs migrate_misplaced_transhuge_page race condition

by Sasha Levin

From: Andrea Arcangeli <aarcange(a)redhat.com> [ Upstream commit d7c3393413fe7e7dc54498ea200ea94742d61e18 ] Patch series "migrate_misplaced_transhuge_page race conditions". Aaron found a new instance of the THP MADV_DONTNEED race against pmdp_clear_flush* variants, that was apparently left unfixed. While looking into the race found by Aaron, I may have found two more issues in migrate_misplaced_transhuge_page. These race conditions would not cause kernel instability, but they'd corrupt userland data or leave data non zero after MADV_DONTNEED. I did only minor testing, and I don't expect to be able to reproduce this (especially the lack of ->invalidate_range before migrate_page_copy, requires the latest iommu hardware or infiniband to reproduce). The last patch is noop for x86 and it needs further review from maintainers of archs that implement flush_cache_range() (not in CC yet). To avoid confusion, it's not the first patch that introduces the bug fixed in the second patch, even before removing the pmdp_huge_clear_flush_notify, that _notify suffix was called after migrate_page_copy already run. This patch (of 3): This is a corollary of ced108037c2aa ("thp: fix MADV_DONTNEED vs. numa balancing race"), 58ceeb6bec8 ("thp: fix MADV_DONTNEED vs. MADV_FREE race") and 5b7abeae3af8c ("thp: fix MADV_DONTNEED vs clear soft dirty race). When the above three fixes where posted Dave asked https://lkml.kernel.org/r/929b3844-aec2-0111-fef7-8002f9d4e2b9@intel.com but apparently this was missed. The pmdp_clear_flush* in migrate_misplaced_transhuge_page() was introduced in a54a407fbf7 ("mm: Close races between THP migration and PMD numa clearing"). The important part of such commit is only the part where the page lock is not released until the first do_huge_pmd_numa_page() finished disarming the pagenuma/protnone. The addition of pmdp_clear_flush() wasn't beneficial to such commit and there's no commentary about such an addition either. I guess the pmdp_clear_flush() in such commit was added just in case for safety, but it ended up introducing the MADV_DONTNEED race condition found by Aaron. At that point in time nobody thought of such kind of MADV_DONTNEED race conditions yet (they were fixed later) so the code may have looked more robust by adding the pmdp_clear_flush(). This specific race condition won't destabilize the kernel, but it can confuse userland because after MADV_DONTNEED the memory won't be zeroed out. This also optimizes the code and removes a superfluous TLB flush. [akpm(a)linux-foundation.org: reflow comment to 80 cols, fix grammar and typo (beacuse)] Link: http://lkml.kernel.org/r/20181013002430.698-2-aarcange@redhat.com Signed-off-by: Andrea Arcangeli <aarcange(a)redhat.com> Reported-by: Aaron Tomlin <atomlin(a)redhat.com> Acked-by: Mel Gorman <mgorman(a)suse.de> Acked-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: Jerome Glisse <jglisse(a)redhat.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- mm/migrate.c | 25 ++++++++++++++++++------- 1 file changed, 18 insertions(+), 7 deletions(-) diff --git a/mm/migrate.c b/mm/migrate.c index 84381b55b2bd..1f634b1563b6 100644 --- a/mm/migrate.c +++ b/mm/migrate.c @@ -2029,15 +2029,26 @@ int migrate_misplaced_transhuge_page(struct mm_struct *mm, entry = maybe_pmd_mkwrite(pmd_mkdirty(entry), vma); /* - * Clear the old entry under pagetable lock and establish the new PTE. - * Any parallel GUP will either observe the old page blocking on the - * page lock, block on the page table lock or observe the new page. - * The SetPageUptodate on the new page and page_add_new_anon_rmap - * guarantee the copy is visible before the pagetable update. + * Overwrite the old entry under pagetable lock and establish + * the new PTE. Any parallel GUP will either observe the old + * page blocking on the page lock, block on the page table + * lock or observe the new page. The SetPageUptodate on the + * new page and page_add_new_anon_rmap guarantee the copy is + * visible before the pagetable update. */ flush_cache_range(vma, mmun_start, mmun_end); page_add_anon_rmap(new_page, vma, mmun_start, true); - pmdp_huge_clear_flush_notify(vma, mmun_start, pmd); + /* + * At this point the pmd is numa/protnone (i.e. non present) and the TLB + * has already been flushed globally. So no TLB can be currently + * caching this non present pmd mapping. There's no need to clear the + * pmd before doing set_pmd_at(), nor to flush the TLB after + * set_pmd_at(). Clearing the pmd here would introduce a race + * condition against MADV_DONTNEED, because MADV_DONTNEED only holds the + * mmap_sem for reading. If the pmd is set to NULL at any given time, + * MADV_DONTNEED won't wait on the pmd lock and it'll skip clearing this + * pmd. + */ set_pmd_at(mm, mmun_start, pmd, entry); update_mmu_cache_pmd(vma, address, &entry); @@ -2051,7 +2062,7 @@ int migrate_misplaced_transhuge_page(struct mm_struct *mm, * No need to double call mmu_notifier->invalidate_range() callback as * the above pmdp_huge_clear_flush_notify() did already call it. */ - mmu_notifier_invalidate_range_only_end(mm, mmun_start, mmun_end); + mmu_notifier_invalidate_range_end(mm, mmun_start, mmun_end); /* Take an "isolate" reference and put new page on the LRU. */ get_page(new_page); -- 2.17.1

7 years, 1 month

2
57
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror