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

[PATCH v2] HID: hiddev: fix potential Spectre v1

by Breno Leitao

uref->usage_index can be indirectly controlled by userspace, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This field is used as an array index by the hiddev_ioctl_usage() function, when 'cmd' is either HIDIOCGCOLLECTIONINDEX, HIDIOCGUSAGES or HIDIOCSUSAGES. For cmd == HIDIOCGCOLLECTIONINDEX case, uref->usage_index is compared to field->maxusage and then used as an index to dereference field->usage array. The same thing happens to the cmd == HIDIOC{G,S}USAGES cases, where uref->usage_index is checked against an array maximum value and then it is used as an index in an array. This is a summary of the HIDIOCGCOLLECTIONINDEX case, which matches the traditional Spectre V1 first load: copy_from_user(uref, user_arg, sizeof(*uref)) if (uref->usage_index >= field->maxusage) goto inval; i = field->usage[uref->usage_index].collection_index; return i; This patch fixes this by sanitizing field uref->usage_index before using it to index field->usage (HIDIOCGCOLLECTIONINDEX) or field->value in HIDIOC{G,S}USAGES arrays, thus, avoiding speculation in the first load. Signed-off-by: Breno Leitao <leitao(a)debian.org> Cc: <stable(a)vger.kernel.org> -- v2: Contemplate cmd == HIDIOC{G,S}USAGES case diff --git a/drivers/hid/usbhid/hiddev.c b/drivers/hid/usbhid/hiddev.c index 23872d08308c..a746017fac17 100644 --- a/drivers/hid/usbhid/hiddev.c +++ b/drivers/hid/usbhid/hiddev.c @@ -512,14 +512,24 @@ static noinline int hiddev_ioctl_usage(struct hiddev *hiddev, unsigned int cmd, if (cmd == HIDIOCGCOLLECTIONINDEX) { if (uref->usage_index >= field->maxusage) goto inval; + uref->usage_index = + array_index_nospec(uref->usage_index, + field->maxusage); } else if (uref->usage_index >= field->report_count) goto inval; } - if ((cmd == HIDIOCGUSAGES || cmd == HIDIOCSUSAGES) && - (uref_multi->num_values > HID_MAX_MULTI_USAGES || - uref->usage_index + uref_multi->num_values > field->report_count)) - goto inval; + if (cmd == HIDIOCGUSAGES || cmd == HIDIOCSUSAGES) { + if (uref_multi->num_values > HID_MAX_MULTI_USAGES || + uref->usage_index + uref_multi->num_values > + field->report_count) + goto inval; + + uref->usage_index = + array_index_nospec(uref->usage_index, + field->report_count - + uref_multi->num_values); + } switch (cmd) { case HIDIOCGUSAGE: -- 2.17.1

6 years, 10 months

2
1
0 0

for your photos 15

by Katie

We are a team of 12 image editors and we are here to edit your photos. We mainly provide images cut out and images clipping path, masking. Such as for ecommerce photos, and it is also for beauty portraits and skin images We provide test editing if you send us 1 or 2 photos. Thanks, Katie

6 years, 10 months

1
0
0 0

[PATCH AUTOSEL 4.14 01/15] ARM: dts: imx53-qsb: disable 1.2GHz OPP

by Sasha Levin

From: Sascha Hauer <s.hauer(a)pengutronix.de> [ Upstream commit eea96566c189c77e5272585984eb2729881a2f1d ] The maximum CPU frequency for the i.MX53 QSB is 1GHz, so disable the 1.2GHz OPP. This makes the board work again with configs that have cpufreq enabled like imx_v6_v7_defconfig on which the board stopped working with the addition of cpufreq-dt support. Fixes: 791f416608 ("ARM: dts: imx53: add cpufreq-dt support") Signed-off-by: Sascha Hauer <s.hauer(a)pengutronix.de> Signed-off-by: Shawn Guo <shawnguo(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/arm/boot/dts/imx53-qsb-common.dtsi | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/arch/arm/boot/dts/imx53-qsb-common.dtsi b/arch/arm/boot/dts/imx53-qsb-common.dtsi index 683dcbe27cbd..8c11190c5218 100644 --- a/arch/arm/boot/dts/imx53-qsb-common.dtsi +++ b/arch/arm/boot/dts/imx53-qsb-common.dtsi @@ -130,6 +130,17 @@ }; }; +&cpu0 { + /* CPU rated to 1GHz, not 1.2GHz as per the default settings */ + operating-points = < + /* kHz uV */ + 166666 850000 + 400000 900000 + 800000 1050000 + 1000000 1200000 + >; +}; + &esdhc1 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_esdhc1>; -- 2.17.1

6 years, 10 months

4
21
0 0

[PATCH AUTOSEL 3.18 01/98] dm thin: restore requested 'error_if_no_space' setting on OODS to WRITE transition

by Sasha Levin

From: Mike Snitzer <snitzer(a)redhat.com> [ Upstream commit 172c238612ebf81cabccc86b788c9209af591f61 ] A thin-pool that is in out-of-data-space (OODS) mode may transition back to write mode -- without the admin adding more space to the thin-pool -- if/when blocks are released (either by deleting thin devices or discarding provisioned blocks). But as part of the thin-pool's earlier transition to out-of-data-space mode the thin-pool may have set the 'error_if_no_space' flag to true if the no_space_timeout expires without more space having been made available. That implementation detail, of changing the pool's error_if_no_space setting, needs to be reset back to the default that the user specified when the thin-pool's table was loaded. Otherwise we'll drop the user requested behaviour on the floor when this out-of-data-space to write mode transition occurs. Reported-by: Vivek Goyal <vgoyal(a)redhat.com> Signed-off-by: Mike Snitzer <snitzer(a)redhat.com> Acked-by: Joe Thornber <ejt(a)redhat.com> Fixes: 2c43fd26e4 ("dm thin: fix missing out-of-data-space to write mode transition if blocks are released") Cc: stable(a)vger.kernel.org Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/md/dm-thin.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/md/dm-thin.c b/drivers/md/dm-thin.c index 68c7102a64c8..936c57b57539 100644 --- a/drivers/md/dm-thin.c +++ b/drivers/md/dm-thin.c @@ -1909,6 +1909,7 @@ static void set_pool_mode(struct pool *pool, enum pool_mode new_mode) case PM_WRITE: if (old_mode != new_mode) notify_of_pool_mode_change(pool, "write"); + pool->pf.error_if_no_space = pt->requested_pf.error_if_no_space; dm_pool_metadata_read_write(pool->pmd); pool->process_bio = process_bio; pool->process_discard = process_discard; -- 2.17.1

6 years, 10 months

6
106
0 0

[PATCH AUTOSEL 4.4 01/65] KEYS: put keyring if install_session_keyring_to_cred() fails

by Sasha Levin

From: Eric Biggers <ebiggers(a)google.com> [ Upstream commit d636bd9f12a66ea3775c9fabbf3f8e118253467a ] In join_session_keyring(), if install_session_keyring_to_cred() were to fail, we would leak the keyring reference, just like in the bug fixed by commit 23567fd052a9 ("KEYS: Fix keyring ref leak in join_session_keyring()"). Fortunately this cannot happen currently, but we really should be more careful. Do this by adding and using a new error label at which the keyring reference is dropped. Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: David Howells <dhowells(a)redhat.com> Signed-off-by: James Morris <james.l.morris(a)oracle.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- security/keys/process_keys.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/security/keys/process_keys.c b/security/keys/process_keys.c index ac1d5b2b1626..a7095372701e 100644 --- a/security/keys/process_keys.c +++ b/security/keys/process_keys.c @@ -808,15 +808,14 @@ long join_session_keyring(const char *name) ret = PTR_ERR(keyring); goto error2; } else if (keyring == new->session_keyring) { - key_put(keyring); ret = 0; - goto error2; + goto error3; } /* we've got a keyring - now to install it */ ret = install_session_keyring_to_cred(new, keyring); if (ret < 0) - goto error2; + goto error3; commit_creds(new); mutex_unlock(&key_session_mutex); @@ -826,6 +825,8 @@ long join_session_keyring(const char *name) okay: return ret; +error3: + key_put(keyring); error2: mutex_unlock(&key_session_mutex); error: -- 2.17.1

6 years, 10 months

3
69
0 0

[PATCH v2 2/2] drm/i915/hdmi: Reorder structure to match specification

by clinton.a.taylor＠intel.com

From: Clint Taylor <clinton.a.taylor(a)intel.com> reorder structure of 297, 594 N values to group Audio Sample Frequencies together to make updating from HDMI specification easier. V2: Match patch 1/2 version Cc: Jani Nikula <jani.nikula(a)linux.intel.com> Cc: stable(a)vger.kernel.org Signed-off-by: Clint Taylor <clinton.a.taylor(a)intel.com> --- drivers/gpu/drm/i915/intel_audio.c | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_audio.c b/drivers/gpu/drm/i915/intel_audio.c index ee3ca2d..47caecb 100644 --- a/drivers/gpu/drm/i915/intel_audio.c +++ b/drivers/gpu/drm/i915/intel_audio.c @@ -153,32 +153,32 @@ struct dp_aud_n_m { int n; int cts; } hdmi_aud_ncts[] = { - { 44100, TMDS_296M, 4459, 234375 }, - { 44100, TMDS_297M, 4704, 247500 }, - { 48000, TMDS_296M, 5824, 281250 }, - { 48000, TMDS_297M, 5120, 247500 }, { 32000, TMDS_296M, 5824, 421875 }, { 32000, TMDS_297M, 3072, 222750 }, + { 44100, TMDS_296M, 4459, 234375 }, + { 44100, TMDS_297M, 4704, 247500 }, { 88200, TMDS_296M, 8918, 234375 }, { 88200, TMDS_297M, 9408, 247500 }, - { 96000, TMDS_296M, 11648, 281250 }, - { 96000, TMDS_297M, 10240, 247500 }, { 176400, TMDS_296M, 17836, 234375 }, { 176400, TMDS_297M, 18816, 247500 }, + { 48000, TMDS_296M, 5824, 281250 }, + { 48000, TMDS_297M, 5120, 247500 }, + { 96000, TMDS_296M, 11648, 281250 }, + { 96000, TMDS_297M, 10240, 247500 }, { 192000, TMDS_296M, 23296, 281250 }, { 192000, TMDS_297M, 20480, 247500 }, - { 44100, TMDS_593M, 8918, 937500 }, - { 44100, TMDS_594M, 9408, 990000 }, - { 48000, TMDS_593M, 5824, 562500 }, - { 48000, TMDS_594M, 6144, 594000 }, { 32000, TMDS_593M, 5824, 843750 }, { 32000, TMDS_594M, 3072, 445500 }, + { 44100, TMDS_593M, 8918, 937500 }, + { 44100, TMDS_594M, 9408, 990000 }, { 88200, TMDS_593M, 17836, 937500 }, { 88200, TMDS_594M, 18816, 990000 }, - { 96000, TMDS_593M, 11648, 562500 }, - { 96000, TMDS_594M, 12288, 594000 }, { 176400, TMDS_593M, 35672, 937500 }, { 176400, TMDS_594M, 37632, 990000 }, + { 48000, TMDS_593M, 5824, 562500 }, + { 48000, TMDS_594M, 6144, 594000 }, + { 96000, TMDS_593M, 11648, 562500 }, + { 96000, TMDS_594M, 12288, 594000 }, { 192000, TMDS_593M, 23296, 562500 }, { 192000, TMDS_594M, 24576, 594000 }, }; -- 1.9.1

6 years, 10 months

2
1
0 0

stable@vger.kernel.org RE:For Your Urgent Perusal

by Mr Steven Walter

Dear stable(a)vger.kernel.org , I am sorry for invading your privacy because we do not know each other but I am contacting you because of my late client who died without a will. This is to notify you that your are the beneficiary to the bequest of the sum of £10,500,000.00 GBP in the intent of my deceased client. If you accept please forward your full names, current address and your direct cell for the court documentations and so that we can obtain the probate division of court papers required for you to claim the funds from the holding bank. Thanks, Steven Walter Disclaimer: Adobe® reserves the rights to protect sensitive documents against fraudsters and spyware. Adobe® secured files are encrypted with the receivers' email and can only be viewed by the recipient. For more details visit http://www.adobe.com/legal/terms.html for details.

6 years, 10 months

1
0
0 0

stable@vger.kernel.org RE:For Your Urgent Perusal

by Mr Steven Walter

Dear stable(a)vger.kernel.org , I am sorry for invading your privacy because we do not know each other but I am contacting you because of my late client who died without a will. This is to notify you that your are the beneficiary to the bequest of the sum of £10,500,000.00 GBP in the intent of my deceased client. If you accept please forward your full names, current address and your direct cell for the court documentations and so that we can obtain the probate division of court papers required for you to claim the funds from the holding bank. Thanks, Steven Walter Disclaimer: Adobe® reserves the rights to protect sensitive documents against fraudsters and spyware. Adobe® secured files are encrypted with the receivers' email and can only be viewed by the recipient. For more details visit http://www.adobe.com/legal/terms.html for details.

6 years, 10 months

1
0
0 0

[PATCH v2 1/2] drm/i915/hdmi: Add HDMI 2.0 audio clock recovery N values

by clinton.a.taylor＠intel.com

From: Clint Taylor <clinton.a.taylor(a)intel.com> HDMI 2.0 594Mhz modes were incorrectly selecting 25.200Mhz Automatic N value mode instead of HDMI specification values. V2: Fix 88.2 Hz N value Cc: Jani Nikula <jani.nikula(a)linux.intel.com> Cc: stable(a)vger.kernel.org Signed-off-by: Clint Taylor <clinton.a.taylor(a)intel.com> --- drivers/gpu/drm/i915/intel_audio.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_audio.c b/drivers/gpu/drm/i915/intel_audio.c index 769f3f5..ee3ca2d 100644 --- a/drivers/gpu/drm/i915/intel_audio.c +++ b/drivers/gpu/drm/i915/intel_audio.c @@ -144,6 +144,9 @@ struct dp_aud_n_m { /* HDMI N/CTS table */ #define TMDS_297M 297000 #define TMDS_296M 296703 +#define TMDS_594M 594000 +#define TMDS_593M 593407 + static const struct { int sample_rate; int clock; @@ -164,6 +167,20 @@ struct dp_aud_n_m { { 176400, TMDS_297M, 18816, 247500 }, { 192000, TMDS_296M, 23296, 281250 }, { 192000, TMDS_297M, 20480, 247500 }, + { 44100, TMDS_593M, 8918, 937500 }, + { 44100, TMDS_594M, 9408, 990000 }, + { 48000, TMDS_593M, 5824, 562500 }, + { 48000, TMDS_594M, 6144, 594000 }, + { 32000, TMDS_593M, 5824, 843750 }, + { 32000, TMDS_594M, 3072, 445500 }, + { 88200, TMDS_593M, 17836, 937500 }, + { 88200, TMDS_594M, 18816, 990000 }, + { 96000, TMDS_593M, 11648, 562500 }, + { 96000, TMDS_594M, 12288, 594000 }, + { 176400, TMDS_593M, 35672, 937500 }, + { 176400, TMDS_594M, 37632, 990000 }, + { 192000, TMDS_593M, 23296, 562500 }, + { 192000, TMDS_594M, 24576, 594000 }, }; /* get AUD_CONFIG_PIXEL_CLOCK_HDMI_* value for mode */ -- 1.9.1

6 years, 10 months

2
1
0 0

stable@vger.kernel.org RE:For Your Urgent Perusal

by Mr Steven Walter

Dear stable(a)vger.kernel.org , I am sorry for invading your privacy because we do not know each other but I am contacting you because of my late client who died without a will. This is to notify you that your are the beneficiary to the bequest of the sum of £10,500,000.00 GBP in the intent of my deceased client. If you accept please forward your full names, current address and your direct cell for the court documentations and so that we can obtain the probate division of court papers required for you to claim the funds from the holding bank. Thanks, Steven Walter Disclaimer: Adobe® reserves the rights to protect sensitive documents against fraudsters and spyware. Adobe® secured files are encrypted with the receivers' email and can only be viewed by the recipient. For more details visit http://www.adobe.com/legal/terms.html for details.

6 years, 10 months

1
0
0 0

stable@vger.kernel.org RE:For Your Urgent Perusal

by Mr Steven Walter

Dear stable(a)vger.kernel.org , I am sorry for invading your privacy because we do not know each other but I am contacting you because of my late client who died without a will. This is to notify you that your are the beneficiary to the bequest of the sum of £10,500,000.00 GBP in the intent of my deceased client. If you accept please forward your full names, current address and your direct cell for the court documentations and so that we can obtain the probate division of court papers required for you to claim the funds from the holding bank. Thanks, Steven Walter Disclaimer: Adobe® reserves the rights to protect sensitive documents against fraudsters and spyware. Adobe® secured files are encrypted with the receivers' email and can only be viewed by the recipient. For more details visit http://www.adobe.com/legal/terms.html for details.

6 years, 10 months

1
0
0 0

[PATCH] spi: uniphier: fix incorrect property items

by Keiji Hayashibara

This commit fixes incorrect property because it was different from the actual. The parameters of '#address-cells' and '#size-cells' were removed, and 'interrupts', 'pinctrl-names' and 'pinctrl-0' were added. Fixes: 4dcd5c2781f3 ("spi: add DT bindings for UniPhier SPI controller") Signed-off-by: Keiji Hayashibara <hayashibara.keiji(a)socionext.com> --- Documentation/devicetree/bindings/spi/spi-uniphier.txt | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/spi/spi-uniphier.txt b/Documentation/devicetree/bindings/spi/spi-uniphier.txt index 504a4ec..b04e66a 100644 --- a/Documentation/devicetree/bindings/spi/spi-uniphier.txt +++ b/Documentation/devicetree/bindings/spi/spi-uniphier.txt @@ -5,18 +5,20 @@ UniPhier SoCs have SCSSI which supports SPI single channel. Required properties: - compatible: should be "socionext,uniphier-scssi" - reg: address and length of the spi master registers - - #address-cells: must be <1>, see spi-bus.txt - - #size-cells: must be <0>, see spi-bus.txt - - clocks: A phandle to the clock for the device. - - resets: A phandle to the reset control for the device. + - interrupts: a single interrupt specifier + - pinctrl-names: should be "default" + - pinctrl-0: pin control state for the default mode + - clocks: a phandle to the clock for the device + - resets: a phandle to the reset control for the device Example: spi0: spi@54006000 { compatible = "socionext,uniphier-scssi"; reg = <0x54006000 0x100>; - #address-cells = <1>; - #size-cells = <0>; + interrupts = <0 39 4>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_spi0>; clocks = <&peri_clk 11>; resets = <&peri_rst 11>; }; -- 2.7.4

6 years, 10 months

3
3
0 0

[PATCH v3] x86/microcode: Handle negative microcode revisions

by Andi Kleen

From: Andi Kleen <ak(a)linux.intel.com> The Intel microcode revision space is unsigned. Inside Intel there are special microcode revisions that have the highest bit set, and they are considered to have a higher revision than any microcodes that don't have this bit set. The function comparing the microcode revision in the Linux driver compares u32 with int, which ends up being signed extended to long on 64bit systems. This results in these highest bit set microcode revision not loading because their revision appears negative and smaller than the existing microcode. Change the comparison to unsigned. With that the loading works as expected. Cc: stable(a)vger.kernel.org # Any supported stable Signed-off-by: Andi Kleen <ak(a)linux.intel.com> -- v2: White space changes. v3: Be more verbose --- arch/x86/kernel/cpu/microcode/intel.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/microcode/intel.c b/arch/x86/kernel/cpu/microcode/intel.c index 16936a24795c..e54d402500d3 100644 --- a/arch/x86/kernel/cpu/microcode/intel.c +++ b/arch/x86/kernel/cpu/microcode/intel.c @@ -93,7 +93,8 @@ static int find_matching_signature(void *mc, unsigned int csig, int cpf) /* * Returns 1 if update has been found, 0 otherwise. */ -static int has_newer_microcode(void *mc, unsigned int csig, int cpf, int new_rev) +static int has_newer_microcode(void *mc, unsigned int csig, int cpf, + unsigned new_rev) { struct microcode_header_intel *mc_hdr = mc; -- 2.17.2

6 years, 10 months

1
0
0 0

[PATCH v3] x86/numa_emulation: Fix uniform-split numa emulation

by Dan Williams

From: Dave Jiang <dave.jiang(a)intel.com> The numa_emulation() routine in the 'uniform' case walks through all the physical 'memblk' instances and divides them into N emulated nodes with split_nodes_size_interleave_uniform(). As each physical node is consumed it is removed from the physical memblk array in the numa_remove_memblk_from() helper. Since split_nodes_size_interleave_uniform() handles advancing the array as the 'memblk' is consumed it is expected that the base of the array is always specified as the argument. Otherwise, on multi-socket (> 2) configurations the uniform-split capability can generate an invalid numa configuration leading to boot failures with signatures like the following: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: Sending NMI from CPU 0 to CPUs 2: NMI backtrace for cpu 2 CPU: 2 PID: 1332 Comm: pgdatinit0 Not tainted 4.19.0-rc8-next-20181019-baseline #59 RIP: 0010:__init_single_page.isra.74+0x81/0x90 [..] Call Trace: deferred_init_pages+0xaa/0xe3 deferred_init_memmap+0x18f/0x318 kthread+0xf8/0x130 ? deferred_free_pages.isra.105+0xc9/0xc9 ? kthread_stop+0x110/0x110 ret_from_fork+0x35/0x40 Cc: x86(a)kernel.org Cc: Borislav Petkov <bp(a)alien8.de> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: "H. Peter Anvin" <hpa(a)zytor.com> Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> Fixes: 1f6a2c6d9f121 ("x86/numa_emulation: Introduce uniform split capability") Signed-off-by: Dave Jiang <dave.jiang(a)intel.com> Tested-by: Alexander Duyck <alexander.h.duyck(a)linux.intel.com> Signed-off-by: Dan Williams <dan.j.williams(a)intel.com> --- Changes since v2: https://lore.kernel.org/patchwork/patch/988541/ * Update the changelog with details from testing by Alex arch/x86/mm/numa_emulation.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/arch/x86/mm/numa_emulation.c b/arch/x86/mm/numa_emulation.c index b54d52a2d00a..d71d72cf6c66 100644 --- a/arch/x86/mm/numa_emulation.c +++ b/arch/x86/mm/numa_emulation.c @@ -400,9 +400,17 @@ void __init numa_emulation(struct numa_meminfo *numa_meminfo, int numa_dist_cnt) n = simple_strtoul(emu_cmdline, &emu_cmdline, 0); ret = -1; for_each_node_mask(i, physnode_mask) { + /* + * The reason we pass in blk[0] is due to + * numa_remove_memblk_from() called by + * emu_setup_memblk() will delete entry 0 + * and then move everything else up in the pi.blk + * array. Therefore we should always be looking + * at blk[0]. + */ ret = split_nodes_size_interleave_uniform(&ei, &pi, - pi.blk[i].start, pi.blk[i].end, 0, - n, &pi.blk[i], nid); + pi.blk[0].start, pi.blk[0].end, 0, + n, &pi.blk[0], nid); if (ret < 0) break; if (ret < n) {

6 years, 10 months

2
2
0 0

[PATCH v2] nfit, mce: only handle uncorrectable machine checks

by Vishal Verma

The mce handler for 'nfit' devices is called for memory errors on a Non-Volatile DIMM, and adds the error location to a 'badblocks' list. This list is used by the various NVDIMM drivers to avoid consuming known poison locations during IO. The mce handler gets called for both corrected and uncorrectable errors. Until now, both kinds of errors have been added to the badblocks list. However, corrected memory errors indicate that the problem has already been fixed by hardware, and the resulting interrupt is merely a notification to Linux. As far as future accesses to that location are concerned, it is perfectly fine to use, and thus doesn't need to be included in the above badblocks list. Add a check in the nfit mce handler to filter out corrected mce events, and only process uncorrectable errors. Reported-by: Omar Avelar <omar.avelar(a)intel.com> Fixes: 6839a6d96f4e ("nfit: do an ARS scrub on hitting a latent media error") Cc: stable(a)vger.kernel.org Cc: Dan Williams <dan.j.williams(a)intel.com> Cc: Tony Luck <tony.luck(a)intel.com> Cc: Borislav Petkov <bp(a)alien8.de> Signed-off-by: Vishal Verma <vishal.l.verma(a)intel.com> --- arch/x86/include/asm/mce.h | 1 + arch/x86/kernel/cpu/mcheck/mce.c | 3 ++- drivers/acpi/nfit/mce.c | 4 ++-- 3 files changed, 5 insertions(+), 3 deletions(-) v2: Reword the changelog to explain the motivation for this patch better (Borisalv) diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h index 3a17107594c8..3111b3cee2ee 100644 --- a/arch/x86/include/asm/mce.h +++ b/arch/x86/include/asm/mce.h @@ -216,6 +216,7 @@ static inline int umc_normaddr_to_sysaddr(u64 norm_addr, u16 nid, u8 umc, u64 *s int mce_available(struct cpuinfo_x86 *c); bool mce_is_memory_error(struct mce *m); +bool mce_is_correctable(struct mce *m); DECLARE_PER_CPU(unsigned, mce_exception_count); DECLARE_PER_CPU(unsigned, mce_poll_count); diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c index 953b3ce92dcc..27015948bc41 100644 --- a/arch/x86/kernel/cpu/mcheck/mce.c +++ b/arch/x86/kernel/cpu/mcheck/mce.c @@ -534,7 +534,7 @@ bool mce_is_memory_error(struct mce *m) } EXPORT_SYMBOL_GPL(mce_is_memory_error); -static bool mce_is_correctable(struct mce *m) +bool mce_is_correctable(struct mce *m) { if (m->cpuvendor == X86_VENDOR_AMD && m->status & MCI_STATUS_DEFERRED) return false; @@ -544,6 +544,7 @@ static bool mce_is_correctable(struct mce *m) return true; } +EXPORT_SYMBOL_GPL(mce_is_correctable); static bool cec_add_mce(struct mce *m) { diff --git a/drivers/acpi/nfit/mce.c b/drivers/acpi/nfit/mce.c index e9626bf6ca29..7a51707f87e9 100644 --- a/drivers/acpi/nfit/mce.c +++ b/drivers/acpi/nfit/mce.c @@ -25,8 +25,8 @@ static int nfit_handle_mce(struct notifier_block *nb, unsigned long val, struct acpi_nfit_desc *acpi_desc; struct nfit_spa *nfit_spa; - /* We only care about memory errors */ - if (!mce_is_memory_error(mce)) + /* We only care about uncorrectable memory errors */ + if (!mce_is_memory_error(mce) || mce_is_correctable(mce)) return NOTIFY_DONE; /* -- 2.17.1

6 years, 10 months

2
1
0 0

[PATCH v2 01/10] mtd: cfi_cmdset_0002: Change do_write_oneword() to use chip_good()

by Tokunori Ikegami

This is required for OpenWrt Project to result the flash write issue as below patche. <https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=ddc11c3932c7b…> Also the original patch in OpenWRT is below. <https://github.com/openwrt/openwrt/blob/v18.06.0/target/linux/ar71xx/patche…> So change to use chip_good() instead of chip_ready(). The reason to use chip_good() is that just actually fix the issue. And also in the past I had fixed the erase function also as same way by the patch below. <https://patchwork.ozlabs.org/patch/922656/> Note: The reason for the patch for erase is same. In my understanding the chip_ready() is just checked the value twice from flash. So I think that sometimes incorrect value is read twice and it is depended on the flash device behavior but not sure.. So change to use chip_good() instead of chip_ready(). Signed-off-by: Tokunori Ikegami <ikegami(a)allied-telesis.co.jp> Signed-off-by: Hauke Mehrtens <hauke(a)hauke-m.de> Signed-off-by: Koen Vandeputte <koen.vandeputte(a)ncentric.com> Signed-off-by: Fabio Bettoni <fbettoni(a)gmail.com> Co-Developed-by: Hauke Mehrtens <hauke(a)hauke-m.de> Co-Developed-by: Koen Vandeputte <koen.vandeputte(a)ncentric.com> Co-Developed-by: Fabio Bettoni <fbettoni(a)gmail.com> Reported-by: Fabio Bettoni <fbettoni(a)gmail.com> Cc: Chris Packham <chris.packham(a)alliedtelesis.co.nz> Cc: Joakim Tjernlund <Joakim.Tjernlund(a)infinera.com> Cc: Boris Brezillon <boris.brezillon(a)free-electrons.com> Cc: linux-mtd(a)lists.infradead.org Cc: stable(a)vger.kernel.org --- Changes since v1: - Just update the commit message. drivers/mtd/chips/cfi_cmdset_0002.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c index 72428b6bfc47..251c9e1675bd 100644 --- a/drivers/mtd/chips/cfi_cmdset_0002.c +++ b/drivers/mtd/chips/cfi_cmdset_0002.c @@ -1627,31 +1627,37 @@ static int __xipram do_write_oneword(struct map_info *map, struct flchip *chip, continue; } - if (time_after(jiffies, timeo) && !chip_ready(map, adr)){ + if (chip_good(map, adr, datum)) + break; + + if (time_after(jiffies, timeo)){ xip_enable(map, chip, adr); printk(KERN_WARNING "MTD %s(): software timeout\n", __func__); xip_disable(map, chip, adr); + ret = -EIO; break; } - if (chip_ready(map, adr)) - break; - /* Latency issues. Drop the lock, wait a while and retry */ UDELAY(map, chip, adr, 1); } + /* Did we succeed? */ - if (!chip_good(map, adr, datum)) { + if (ret) { /* reset on all failures. */ map_write(map, CMD(0xF0), chip->start); /* FIXME - should have reset delay before continuing */ - if (++retry_cnt <= MAX_RETRIES) + if (++retry_cnt <= MAX_RETRIES) { + ret = 0; goto retry; + } ret = -EIO; } + xip_enable(map, chip, adr); + op_done: if (mode == FL_OTP_WRITE) otp_exit(map, chip, adr, map_bankwidth(map)); -- 2.18.0

6 years, 10 months

3
2
0 0

My request

by Abel Brent

Dear friend, Greetings, I am Abel Brent, a NATO soldier serving in Afghanistan. I and my comrades we are seeking your assistance to help us receive/invest our funds in your country in any lucrative business. Please if this proposal is acceptable by you, kindly respond back to me for more details. Thanks and waiting to hear from you Abel.

6 years, 10 months

1
0
0 0

[PATCH AUTOSEL 4.18 1/8] x86/paravirt: Fix some warning messages

by Sasha Levin

From: Dan Carpenter <dan.carpenter(a)oracle.com> [ Upstream commit 571d0563c8881595f4ab027aef9ed1c55e3e7b7c ] The first argument to WARN_ONCE() is a condition. Fixes: 5800dc5c19f3 ("x86/paravirt: Fix spectre-v2 mitigations for paravirt guests") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Reviewed-by: Juergen Gross <jgross(a)suse.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Alok Kataria <akataria(a)vmware.com> Cc: "H. Peter Anvin" <hpa(a)zytor.com> Cc: virtualization(a)lists.linux-foundation.org Cc: kernel-janitors(a)vger.kernel.org Link: https://lkml.kernel.org/r/20180919103553.GD9238@mwanda Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/x86/kernel/paravirt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c index 930c88341e4e..1fbf38dde84c 100644 --- a/arch/x86/kernel/paravirt.c +++ b/arch/x86/kernel/paravirt.c @@ -90,7 +90,7 @@ unsigned paravirt_patch_call(void *insnbuf, if (len < 5) { #ifdef CONFIG_RETPOLINE - WARN_ONCE("Failing to patch indirect CALL in %ps\n", (void *)addr); + WARN_ONCE(1, "Failing to patch indirect CALL in %ps\n", (void *)addr); #endif return len; /* call too long for patch site */ } @@ -110,7 +110,7 @@ unsigned paravirt_patch_jmp(void *insnbuf, const void *target, if (len < 5) { #ifdef CONFIG_RETPOLINE - WARN_ONCE("Failing to patch indirect JMP in %ps\n", (void *)addr); + WARN_ONCE(1, "Failing to patch indirect JMP in %ps\n", (void *)addr); #endif return len; /* call too long for patch site */ } -- 2.17.1

6 years, 10 months

1
7
0 0

[PATCH] drm/i915: Fix ilk+ watermarks when disabling pipes

by Ville Syrjala

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> We're no longer programming any watermarks when we're disabling a pipe. That means ilk_wm_merge() & co. will keep considering the any pipe that is getting disabled as still enabled. Thus we either get no LP1+ watermakrs (ilk-ivb), or we get suboptimal ones (hsw-bdw). This seems to have been broken by commit b6b178a77210 ("drm/i915: Calculate ironlake intermediate watermarks correctly, v2."). Before that we apparently had some difference between the intermediate and optimal watermarks and so we would program the optiomal ones. Now intermediate and optimal are identical for disabled pipes and so we don't program either. Fix this by programming the intermediate watermarks even for disabled pipes. We were already doing that for skl+. We'll leave out gmch platforms for now since those do the merging in a different manner and should work as is. We'll want to unify this eventually, but play it safe for now and just put in a FIXME. Cc: stable(a)vger.kernel.org Cc: Matt Roper <matthew.d.roper(a)intel.com> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Fixes: b6b178a77210 ("drm/i915: Calculate ironlake intermediate watermarks correctly, v2.") Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> --- drivers/gpu/drm/i915/intel_display.c | 17 ++++++----------- 1 file changed, 6 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index fe045abb6472..1e963dcebf2d 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -12818,17 +12818,12 @@ static void intel_atomic_commit_tail(struct drm_atomic_state *state) intel_check_cpu_fifo_underruns(dev_priv); intel_check_pch_fifo_underruns(dev_priv); - if (!new_crtc_state->active) { - /* - * Make sure we don't call initial_watermarks - * for ILK-style watermark updates. - * - * No clue what this is supposed to achieve. - */ - if (INTEL_GEN(dev_priv) >= 9) - dev_priv->display.initial_watermarks(intel_state, - new_intel_crtc_state); - } + /* FIXME unify this for all platforms */ + if (!new_crtc_state->active && + !HAS_GMCH_DISPLAY(dev_priv) && + dev_priv->display.initial_watermarks) + dev_priv->display.initial_watermarks(intel_state, + new_intel_crtc_state); } } -- 2.18.1

6 years, 10 months

1
0
0 0

[PATCH] xen/pvh: don't try to unplug emulated devices

by Juergen Gross

A Xen PVH guest has no associated qemu device model, so trying to unplug any emulated devices is making no sense at all. Bail out early from xen_unplug_emulated_devices() when running as PVH guest. This will avoid issuing the boot message: [ 0.000000] Xen Platform PCI: unrecognised magic value Cc: <stable(a)vger.kernel.org> # 4.11 Signed-off-by: Juergen Gross <jgross(a)suse.com> --- arch/x86/xen/platform-pci-unplug.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/x86/xen/platform-pci-unplug.c b/arch/x86/xen/platform-pci-unplug.c index 66ab96a4e2b3..96d7f7d39cb9 100644 --- a/arch/x86/xen/platform-pci-unplug.c +++ b/arch/x86/xen/platform-pci-unplug.c @@ -134,6 +134,10 @@ void xen_unplug_emulated_devices(void) { int r; + /* PVH guests don't have emulated devices. */ + if (xen_pvh_domain()) + return; + /* user explicitly requested no unplug */ if (xen_emul_unplug & XEN_UNPLUG_NEVER) return; -- 2.16.4

6 years, 10 months

2
1
0 0

[PATCH] netfilter: conntrack: fix calculation of next bucket number in early_drop

by Vasily Khoruzhick

If there's no entry to drop in bucket that corresponds to the hash, early_drop() should look for it in other buckets. But since it increments hash instead of bucket number, it actually looks in the same bucket 8 times: hsize is 16k by default (14 bits) and hash is 32-bit value, so reciprocal_scale(hash, hsize) returns the same value for hash..hash+7 in most cases. Fix it by increasing bucket number instead of hash and rename _hash to bucket to avoid future confusion. Fixes: 3e86638e9a0b ("netfilter: conntrack: consider ct netns in early_drop logic") Cc: <stable(a)vger.kernel.org> # v4.7+ Signed-off-by: Vasily Khoruzhick <vasilykh(a)arista.com> --- net/netfilter/nf_conntrack_core.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c index ca1168d67fac..a04af246b184 100644 --- a/net/netfilter/nf_conntrack_core.c +++ b/net/netfilter/nf_conntrack_core.c @@ -1073,19 +1073,22 @@ static unsigned int early_drop_list(struct net *net, return drops; } -static noinline int early_drop(struct net *net, unsigned int _hash) +static noinline int early_drop(struct net *net, unsigned int hash) { unsigned int i; for (i = 0; i < NF_CT_EVICTION_RANGE; i++) { struct hlist_nulls_head *ct_hash; - unsigned int hash, hsize, drops; + unsigned int bucket, hsize, drops; rcu_read_lock(); nf_conntrack_get_ht(&ct_hash, &hsize); - hash = reciprocal_scale(_hash++, hsize); + if (!i) + bucket = reciprocal_scale(hash, hsize); + else + bucket = (bucket + 1) % hsize; - drops = early_drop_list(net, &ct_hash[hash]); + drops = early_drop_list(net, &ct_hash[bucket]); rcu_read_unlock(); if (drops) { -- 2.19.1

6 years, 10 months

3
2
0 0

[PATCH] nfit, mce: only handle uncorrectable machine checks

by Vishal Verma

We only want a machine check error to be added to libnvdimm's 'badblock' if it was an uncorrectable error. Currently we insert both corrected and uncorrectable errors. Add a check in the nfit mce handler to filter out corrected mce events. Reported-by: Omar Avelar <omar.avelar(a)intel.com> Fixes: 6839a6d96f4e ("nfit: do an ARS scrub on hitting a latent media error") Cc: stable(a)vger.kernel.org Cc: Dan Williams <dan.j.williams(a)intel.com> Cc: Tony Luck <tony.luck(a)intel.com> Cc: Borislav Petkov <bp(a)alien8.de> Signed-off-by: Vishal Verma <vishal.l.verma(a)intel.com> --- arch/x86/include/asm/mce.h | 1 + arch/x86/kernel/cpu/mcheck/mce.c | 3 ++- drivers/acpi/nfit/mce.c | 4 ++-- 3 files changed, 5 insertions(+), 3 deletions(-) diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h index 3a17107594c8..3111b3cee2ee 100644 --- a/arch/x86/include/asm/mce.h +++ b/arch/x86/include/asm/mce.h @@ -216,6 +216,7 @@ static inline int umc_normaddr_to_sysaddr(u64 norm_addr, u16 nid, u8 umc, u64 *s int mce_available(struct cpuinfo_x86 *c); bool mce_is_memory_error(struct mce *m); +bool mce_is_correctable(struct mce *m); DECLARE_PER_CPU(unsigned, mce_exception_count); DECLARE_PER_CPU(unsigned, mce_poll_count); diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c index 953b3ce92dcc..27015948bc41 100644 --- a/arch/x86/kernel/cpu/mcheck/mce.c +++ b/arch/x86/kernel/cpu/mcheck/mce.c @@ -534,7 +534,7 @@ bool mce_is_memory_error(struct mce *m) } EXPORT_SYMBOL_GPL(mce_is_memory_error); -static bool mce_is_correctable(struct mce *m) +bool mce_is_correctable(struct mce *m) { if (m->cpuvendor == X86_VENDOR_AMD && m->status & MCI_STATUS_DEFERRED) return false; @@ -544,6 +544,7 @@ static bool mce_is_correctable(struct mce *m) return true; } +EXPORT_SYMBOL_GPL(mce_is_correctable); static bool cec_add_mce(struct mce *m) { diff --git a/drivers/acpi/nfit/mce.c b/drivers/acpi/nfit/mce.c index e9626bf6ca29..7a51707f87e9 100644 --- a/drivers/acpi/nfit/mce.c +++ b/drivers/acpi/nfit/mce.c @@ -25,8 +25,8 @@ static int nfit_handle_mce(struct notifier_block *nb, unsigned long val, struct acpi_nfit_desc *acpi_desc; struct nfit_spa *nfit_spa; - /* We only care about memory errors */ - if (!mce_is_memory_error(mce)) + /* We only care about uncorrectable memory errors */ + if (!mce_is_memory_error(mce) || mce_is_correctable(mce)) return NOTIFY_DONE; /* -- 2.17.1

6 years, 10 months

2
1
0 0

+ mm-hmm-fix-race-between-hmm_mirror_unregister-and-mmu_notifier-callback.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/hmm: fix race between hmm_mirror_unregister() and mmu_notifier callback has been added to the -mm tree. Its filename is mm-hmm-fix-race-between-hmm_mirror_unregister-and-mmu_notifier-callback.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-hmm-fix-race-between-hmm_mirror… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-hmm-fix-race-between-hmm_mirror… 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: Ralph Campbell <rcampbell(a)nvidia.com> Subject: mm/hmm: fix race between hmm_mirror_unregister() and mmu_notifier callback In hmm_mirror_unregister(), mm->hmm is set to NULL and then mmu_notifier_unregister_no_release() is called. That creates a small window where mmu_notifier can call mmu_notifier_ops with mm->hmm equal to NULL. Fix this by first unregistering mmu notifier callbacks and then setting mm->hmm to NULL. Similarly in hmm_register(), set mm->hmm before registering mmu_notifier callbacks so callback functions always see mm->hmm set. Link: http://lkml.kernel.org/r/20181019160442.18723-4-jglisse@redhat.com Signed-off-by: Ralph Campbell <rcampbell(a)nvidia.com> Signed-off-by: Jérôme Glisse <jglisse(a)redhat.com> Reviewed-by: John Hubbard <jhubbard(a)nvidia.com> Reviewed-by: Jérôme Glisse <jglisse(a)redhat.com> Reviewed-by: Balbir Singh <bsingharora(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/hmm.c | 36 +++++++++++++++++++++--------------- 1 file changed, 21 insertions(+), 15 deletions(-) --- a/mm/hmm.c~mm-hmm-fix-race-between-hmm_mirror_unregister-and-mmu_notifier-callback +++ a/mm/hmm.c @@ -91,16 +91,6 @@ static struct hmm *hmm_register(struct m spin_lock_init(&hmm->lock); hmm->mm = mm; - /* - * We should only get here if hold the mmap_sem in write mode ie on - * registration of first mirror through hmm_mirror_register() - */ - hmm->mmu_notifier.ops = &hmm_mmu_notifier_ops; - if (__mmu_notifier_register(&hmm->mmu_notifier, mm)) { - kfree(hmm); - return NULL; - } - spin_lock(&mm->page_table_lock); if (!mm->hmm) mm->hmm = hmm; @@ -108,12 +98,27 @@ static struct hmm *hmm_register(struct m cleanup = true; spin_unlock(&mm->page_table_lock); - if (cleanup) { - mmu_notifier_unregister(&hmm->mmu_notifier, mm); - kfree(hmm); - } + if (cleanup) + goto error; + + /* + * We should only get here if hold the mmap_sem in write mode ie on + * registration of first mirror through hmm_mirror_register() + */ + hmm->mmu_notifier.ops = &hmm_mmu_notifier_ops; + if (__mmu_notifier_register(&hmm->mmu_notifier, mm)) + goto error_mm; return mm->hmm; + +error_mm: + spin_lock(&mm->page_table_lock); + if (mm->hmm == hmm) + mm->hmm = NULL; + spin_unlock(&mm->page_table_lock); +error: + kfree(hmm); + return NULL; } void hmm_mm_destroy(struct mm_struct *mm) @@ -278,12 +283,13 @@ void hmm_mirror_unregister(struct hmm_mi if (!should_unregister || mm == NULL) return; + mmu_notifier_unregister_no_release(&hmm->mmu_notifier, mm); + spin_lock(&mm->page_table_lock); if (mm->hmm == hmm) mm->hmm = NULL; spin_unlock(&mm->page_table_lock); - mmu_notifier_unregister_no_release(&hmm->mmu_notifier, mm); kfree(hmm); } EXPORT_SYMBOL(hmm_mirror_unregister); _ Patches currently in -mm which might be from rcampbell(a)nvidia.com are mm-rmap-map_pte-was-not-handling-private-zone_device-page-properly-v3.patch mm-hmm-fix-race-between-hmm_mirror_unregister-and-mmu_notifier-callback.patch

6 years, 10 months

1
0
0 0

+ mm-rmap-map_pte-was-not-handling-private-zone_device-page-properly-v3.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/rmap: map_pte() was not handling private ZONE_DEVICE page properly has been added to the -mm tree. Its filename is mm-rmap-map_pte-was-not-handling-private-zone_device-page-properly-v3.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-rmap-map_pte-was-not-handling-p… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-rmap-map_pte-was-not-handling-p… 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: Ralph Campbell <rcampbell(a)nvidia.com> Subject: mm/rmap: map_pte() was not handling private ZONE_DEVICE page properly Private ZONE_DEVICE pages use a special pte entry and thus are not present. Properly handle this case in map_pte(), it is already handled in check_pte(), the map_pte() part was lost in some rebase most probably. Without this patch the slow migration path can not migrate back to any private ZONE_DEVICE memory to regular memory. This was found after stress testing migration back to system memory. This ultimatly can lead to the CPU constantly page fault looping on the special swap entry. Link: http://lkml.kernel.org/r/20181019160442.18723-3-jglisse@redhat.com Signed-off-by: Ralph Campbell <rcampbell(a)nvidia.com> Signed-off-by: Jérôme Glisse <jglisse(a)redhat.com> Reviewed-by: Balbir Singh <bsingharora(a)gmail.com> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/page_vma_mapped.c | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) --- a/mm/page_vma_mapped.c~mm-rmap-map_pte-was-not-handling-private-zone_device-page-properly-v3 +++ a/mm/page_vma_mapped.c @@ -21,7 +21,29 @@ static bool map_pte(struct page_vma_mapp if (!is_swap_pte(*pvmw->pte)) return false; } else { - if (!pte_present(*pvmw->pte)) + /* + * We get here when we are trying to unmap a private + * device page from the process address space. Such + * page is not CPU accessible and thus is mapped as + * a special swap entry, nonetheless it still does + * count as a valid regular mapping for the page (and + * is accounted as such in page maps count). + * + * So handle this special case as if it was a normal + * page mapping ie lock CPU page table and returns + * true. + * + * For more details on device private memory see HMM + * (include/linux/hmm.h or mm/hmm.c). + */ + if (is_swap_pte(*pvmw->pte)) { + swp_entry_t entry; + + /* Handle un-addressable ZONE_DEVICE memory */ + entry = pte_to_swp_entry(*pvmw->pte); + if (!is_device_private_entry(entry)) + return false; + } else if (!pte_present(*pvmw->pte)) return false; } } _ Patches currently in -mm which might be from rcampbell(a)nvidia.com are mm-rmap-map_pte-was-not-handling-private-zone_device-page-properly-v3.patch mm-hmm-fix-race-between-hmm_mirror_unregister-and-mmu_notifier-callback.patch

6 years, 10 months

1
0
0 0

[PATCH 3/6] mm/hmm: fix race between hmm_mirror_unregister() and mmu_notifier callback

by jglisse＠redhat.com

From: Ralph Campbell <rcampbell(a)nvidia.com> In hmm_mirror_unregister(), mm->hmm is set to NULL and then mmu_notifier_unregister_no_release() is called. That creates a small window where mmu_notifier can call mmu_notifier_ops with mm->hmm equal to NULL. Fix this by first unregistering mmu notifier callbacks and then setting mm->hmm to NULL. Similarly in hmm_register(), set mm->hmm before registering mmu_notifier callbacks so callback functions always see mm->hmm set. Signed-off-by: Ralph Campbell <rcampbell(a)nvidia.com> Reviewed-by: John Hubbard <jhubbard(a)nvidia.com> Reviewed-by: Jérôme Glisse <jglisse(a)redhat.com> Reviewed-by: Balbir Singh <bsingharora(a)gmail.com> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: stable(a)vger.kernel.org --- mm/hmm.c | 36 +++++++++++++++++++++--------------- 1 file changed, 21 insertions(+), 15 deletions(-) diff --git a/mm/hmm.c b/mm/hmm.c index 9a068a1da487..a16678d08127 100644 --- a/mm/hmm.c +++ b/mm/hmm.c @@ -91,16 +91,6 @@ static struct hmm *hmm_register(struct mm_struct *mm) spin_lock_init(&hmm->lock); hmm->mm = mm; - /* - * We should only get here if hold the mmap_sem in write mode ie on - * registration of first mirror through hmm_mirror_register() - */ - hmm->mmu_notifier.ops = &hmm_mmu_notifier_ops; - if (__mmu_notifier_register(&hmm->mmu_notifier, mm)) { - kfree(hmm); - return NULL; - } - spin_lock(&mm->page_table_lock); if (!mm->hmm) mm->hmm = hmm; @@ -108,12 +98,27 @@ static struct hmm *hmm_register(struct mm_struct *mm) cleanup = true; spin_unlock(&mm->page_table_lock); - if (cleanup) { - mmu_notifier_unregister(&hmm->mmu_notifier, mm); - kfree(hmm); - } + if (cleanup) + goto error; + + /* + * We should only get here if hold the mmap_sem in write mode ie on + * registration of first mirror through hmm_mirror_register() + */ + hmm->mmu_notifier.ops = &hmm_mmu_notifier_ops; + if (__mmu_notifier_register(&hmm->mmu_notifier, mm)) + goto error_mm; return mm->hmm; + +error_mm: + spin_lock(&mm->page_table_lock); + if (mm->hmm == hmm) + mm->hmm = NULL; + spin_unlock(&mm->page_table_lock); +error: + kfree(hmm); + return NULL; } void hmm_mm_destroy(struct mm_struct *mm) @@ -278,12 +283,13 @@ void hmm_mirror_unregister(struct hmm_mirror *mirror) if (!should_unregister || mm == NULL) return; + mmu_notifier_unregister_no_release(&hmm->mmu_notifier, mm); + spin_lock(&mm->page_table_lock); if (mm->hmm == hmm) mm->hmm = NULL; spin_unlock(&mm->page_table_lock); - mmu_notifier_unregister_no_release(&hmm->mmu_notifier, mm); kfree(hmm); } EXPORT_SYMBOL(hmm_mirror_unregister); -- 2.17.2

6 years, 10 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror