July 2022 - Linux-stable-mirror

Patch for 4.9 stable tree "net: usb: ax88179_178a needs FLAG_SEND_ZLP"

by Jose Alonso

For 4.9 stable tree: -------------------- From 36a15e1cb134c0395261ba1940762703f778438c Mon Sep 17 00:00:00 2001 From: Jose Alonso <joalonsof(a)gmail.com> Date: Mon, 13 Jun 2022 15:32:44 -0300 Subject: net: usb: ax88179_178a needs FLAG_SEND_ZLP From: Jose Alonso <joalonsof(a)gmail.com> commit 36a15e1cb134c0395261ba1940762703f778438c upstream. The extra byte inserted by usbnet.c when (length % dev->maxpacket == 0) is causing problems to device. This patch sets FLAG_SEND_ZLP to avoid this. Tested with: 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet Problems observed: ====================================================================== 1) Using ssh/sshfs. The remote sshd daemon can abort with the message: "message authentication code incorrect" This happens because the tcp message sent is corrupted during the USB "Bulk out". The device calculate the tcp checksum and send a valid tcp message to the remote sshd. Then the encryption detects the error and aborts. 2) NETDEV WATCHDOG: ... (ax88179_178a): transmit queue 0 timed out 3) Stop normal work without any log message. The "Bulk in" continue receiving packets normally. The host sends "Bulk out" and the device responds with -ECONNRESET. (The netusb.c code tx_complete ignore -ECONNRESET) Under normal conditions these errors take days to happen and in intense usage take hours. A test with ping gives packet loss, showing that something is wrong: ping -4 -s 462 {destination} # 462 = 512 - 42 - 8 Not all packets fail. My guess is that the device tries to find another packet starting at the extra byte and will fail or not depending on the next bytes (old buffer content). ====================================================================== Signed-off-by: Jose Alonso <joalonsof(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/usb/ax88179_178a.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) --- a/drivers/net/usb/ax88179_178a.c +++ b/drivers/net/usb/ax88179_178a.c @@ -1703,7 +1703,7 @@ static const struct driver_info ax88179_info = { .link_reset = ax88179_link_reset, .reset = ax88179_reset, .stop = ax88179_stop, - .flags = FLAG_ETHER | FLAG_FRAMING_AX, + .flags = FLAG_ETHER | FLAG_FRAMING_AX | FLAG_SEND_ZLP, .rx_fixup = ax88179_rx_fixup, .tx_fixup = ax88179_tx_fixup, }; @@ -1716,7 +1716,7 @@ static const struct driver_info ax88178a_info = { .link_reset = ax88179_link_reset, .reset = ax88179_reset, .stop = ax88179_stop, - .flags = FLAG_ETHER | FLAG_FRAMING_AX, + .flags = FLAG_ETHER | FLAG_FRAMING_AX | FLAG_SEND_ZLP, .rx_fixup = ax88179_rx_fixup, .tx_fixup = ax88179_tx_fixup, }; @@ -1729,7 +1729,7 @@ static const struct driver_info cypress_GX3_info = { .link_reset = ax88179_link_reset, .reset = ax88179_reset, .stop = ax88179_stop, - .flags = FLAG_ETHER | FLAG_FRAMING_AX, + .flags = FLAG_ETHER | FLAG_FRAMING_AX | FLAG_SEND_ZLP, .rx_fixup = ax88179_rx_fixup, .tx_fixup = ax88179_tx_fixup, }; @@ -1742,7 +1742,7 @@ static const struct driver_info dlink_dub1312_info = { .link_reset = ax88179_link_reset, .reset = ax88179_reset, .stop = ax88179_stop, - .flags = FLAG_ETHER | FLAG_FRAMING_AX, + .flags = FLAG_ETHER | FLAG_FRAMING_AX | FLAG_SEND_ZLP, .rx_fixup = ax88179_rx_fixup, .tx_fixup = ax88179_tx_fixup, }; @@ -1755,7 +1755,7 @@ static const struct driver_info sitecom_info = { .link_reset = ax88179_link_reset, .reset = ax88179_reset, .stop = ax88179_stop, - .flags = FLAG_ETHER | FLAG_FRAMING_AX, + .flags = FLAG_ETHER | FLAG_FRAMING_AX | FLAG_SEND_ZLP, .rx_fixup = ax88179_rx_fixup, .tx_fixup = ax88179_tx_fixup, }; @@ -1768,7 +1768,7 @@ static const struct driver_info samsung_info = { .link_reset = ax88179_link_reset, .reset = ax88179_reset, .stop = ax88179_stop, - .flags = FLAG_ETHER | FLAG_FRAMING_AX, + .flags = FLAG_ETHER | FLAG_FRAMING_AX | FLAG_SEND_ZLP, .rx_fixup = ax88179_rx_fixup, .tx_fixup = ax88179_tx_fixup, }; @@ -1781,7 +1781,7 @@ static const struct driver_info lenovo_info = { .link_reset = ax88179_link_reset, .reset = ax88179_reset, .stop = ax88179_stop, - .flags = FLAG_ETHER | FLAG_FRAMING_AX, + .flags = FLAG_ETHER | FLAG_FRAMING_AX | FLAG_SEND_ZLP, .rx_fixup = ax88179_rx_fixup, .tx_fixup = ax88179_tx_fixup, };

2 years, 5 months

2
1
0 0

[PATCH v2 0/3][5.18.y backport] ASoC: SOF: Intel: fix resume from hibernate

by Pierre-Louis Bossart

Backport for 5.18 stable, the first two patches were not modified, only the third patch had a missing dependency with 2a68ff846164 ("ASoC: SOF: Intel: hda: Revisit IMR boot sequence") v2: updated commit IDs - no code change Pierre-Louis Bossart (3): ASoC: SOF: pm: add explicit behavior for ACPI S1 and S2 ASoC: SOF: pm: add definitions for S4 and S5 states ASoC: SOF: Intel: disable IMR boot when resuming from ACPI S4 and S5 states sound/soc/sof/intel/hda-loader.c | 3 ++- sound/soc/sof/pm.c | 21 ++++++++++++++++++++- sound/soc/sof/sof-priv.h | 2 ++ 3 files changed, 24 insertions(+), 2 deletions(-) -- 2.34.1

2 years, 5 months

2
4
0 0

Info. 28. July, 2022

by m.gaceb＠univ-alger.dz

Hello, We have no intention of wasting your time. We give out loans to individuals and companies. The interest rate will be 2% annually. We have capacity to finance projects in these fields; real estate development, construction, mining, oil and gas, airline and various trading. If interested, Please provide the following: 1- Full name: 2- Loan amount required: 3- Payback Duration (1 – 30 Years): 4- Phone Number / WhatsApp Number: I will send you the loan terms and condition once I receive the above information. Your refund plan starts after 6 months (6 months grace period). Funding will take approximately 7 banking days from the day you present your loan application. Reply us for more information. Yours truly Uwe Wanner -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

2 years, 5 months

1
0
0 0

s0i3 fixes on Yellow Carp

by Limonciello, Mario

[Public] Hi, Can you please backport the following fixes to 5.15.y? 791255ca9fbe3 ("drm/amd/display: Reset DMCUB before HW init") 34316c1e561db ("drm/amd/display: Optimize bandwidth on following fast update") 62e5a7e2333a9 ("drm/amd/display: Fix surface optimization regression on Carrizo") These help with some s0i3 cases on Yellow Carp (Rembrandt). Thanks,

2 years, 5 months

2
1
0 0

apply 'exfat: use updated exfat_chain directly during renaming' to 5.15.y/5.18.y please

by Wang Yugui

Hi, apply 'exfat: use updated exfat_chain directly during renaming' to 5.15.y/5.18.y please. because it fix some problem of the patch 'exfat-fix-referencing-wrong-parent-directory-informa.patch' just applied in to 5.15.y/5.18.y exfat: use updated exfat_chain directly during renaming Fixes: d8dad2588add ("exfat: fix referencing wrong parent directory information after renaming") Best Regards Wang Yugui (wangyugui(a)e16-tech.com) 2022/07/26

2 years, 5 months

2
1
0 0

[PATCH 4.19] perf/core: Fix data race between perf_event_set_output() and perf_mmap_close()

by Yang Jihong

commit 68e3c69803dada336893640110cb87221bb01dcf upstream. Yang Jihing reported a race between perf_event_set_output() and perf_mmap_close(): CPU1 CPU2 perf_mmap_close(e2) if (atomic_dec_and_test(&e2->rb->mmap_count)) // 1 - > 0 detach_rest = true ioctl(e1, IOC_SET_OUTPUT, e2) perf_event_set_output(e1, e2) ... list_for_each_entry_rcu(e, &e2->rb->event_list, rb_entry) ring_buffer_attach(e, NULL); // e1 isn't yet added and // therefore not detached ring_buffer_attach(e1, e2->rb) list_add_rcu(&e1->rb_entry, &e2->rb->event_list) After this; e1 is attached to an unmapped rb and a subsequent perf_mmap() will loop forever more: again: mutex_lock(&e->mmap_mutex); if (event->rb) { ... if (!atomic_inc_not_zero(&e->rb->mmap_count)) { ... mutex_unlock(&e->mmap_mutex); goto again; } } The loop in perf_mmap_close() holds e2->mmap_mutex, while the attach in perf_event_set_output() holds e1->mmap_mutex. As such there is no serialization to avoid this race. Change perf_event_set_output() to take both e1->mmap_mutex and e2->mmap_mutex to alleviate that problem. Additionally, have the loop in perf_mmap() detach the rb directly, this avoids having to wait for the concurrent perf_mmap_close() to get around to doing it to make progress. Fixes: 9bb5d40cd93c ("perf: Fix mmap() accounting hole") Reported-by: Yang Jihong <yangjihong1(a)huawei.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Tested-by: Yang Jihong <yangjihong1(a)huawei.com> Link: https://lkml.kernel.org/r/YsQ3jm2GR38SW7uD@worktop.programming.kicks-ass.net [YJH: backport to 4.19: adjusted context] Signed-off-by: Yang Jihong <yangjihong1(a)huawei.com> --- kernel/events/core.c | 45 ++++++++++++++++++++++++++++++-------------- 1 file changed, 31 insertions(+), 14 deletions(-) diff --git a/kernel/events/core.c b/kernel/events/core.c index 88dd1398ae88..ba66ea3ca705 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -5719,10 +5719,10 @@ static int perf_mmap(struct file *file, struct vm_area_struct *vma) if (!atomic_inc_not_zero(&event->rb->mmap_count)) { /* - * Raced against perf_mmap_close() through - * perf_event_set_output(). Try again, hope for better - * luck. + * Raced against perf_mmap_close(); remove the + * event and try again. */ + ring_buffer_attach(event, NULL); mutex_unlock(&event->mmap_mutex); goto again; } @@ -10396,14 +10396,25 @@ static int perf_copy_attr(struct perf_event_attr __user *uattr, goto out; } +static void mutex_lock_double(struct mutex *a, struct mutex *b) +{ + if (b < a) + swap(a, b); + + mutex_lock(a); + mutex_lock_nested(b, SINGLE_DEPTH_NESTING); +} + static int perf_event_set_output(struct perf_event *event, struct perf_event *output_event) { struct ring_buffer *rb = NULL; int ret = -EINVAL; - if (!output_event) + if (!output_event) { + mutex_lock(&event->mmap_mutex); goto set; + } /* don't allow circular references */ if (event == output_event) @@ -10441,8 +10452,15 @@ perf_event_set_output(struct perf_event *event, struct perf_event *output_event) event->pmu != output_event->pmu) goto out; + /* + * Hold both mmap_mutex to serialize against perf_mmap_close(). Since + * output_event is already on rb->event_list, and the list iteration + * restarts after every removal, it is guaranteed this new event is + * observed *OR* if output_event is already removed, it's guaranteed we + * observe !rb->mmap_count. + */ + mutex_lock_double(&event->mmap_mutex, &output_event->mmap_mutex); set: - mutex_lock(&event->mmap_mutex); /* Can't redirect output if we've got an active mmap() */ if (atomic_read(&event->mmap_count)) goto unlock; @@ -10452,6 +10470,12 @@ perf_event_set_output(struct perf_event *event, struct perf_event *output_event) rb = ring_buffer_get(output_event); if (!rb) goto unlock; + + /* did we race against perf_mmap_close() */ + if (!atomic_read(&rb->mmap_count)) { + ring_buffer_put(rb); + goto unlock; + } } ring_buffer_attach(event, rb); @@ -10459,20 +10483,13 @@ perf_event_set_output(struct perf_event *event, struct perf_event *output_event) ret = 0; unlock: mutex_unlock(&event->mmap_mutex); + if (output_event) + mutex_unlock(&output_event->mmap_mutex); out: return ret; } -static void mutex_lock_double(struct mutex *a, struct mutex *b) -{ - if (b < a) - swap(a, b); - - mutex_lock(a); - mutex_lock_nested(b, SINGLE_DEPTH_NESTING); -} - static int perf_event_set_clock(struct perf_event *event, clockid_t clk_id) { bool nmi_safe = false; -- 2.30.GIT

2 years, 5 months

2
1
0 0

Backport request to fix a WARNING in sco_sock_sendmsg on LTS

by Harshit Mogalapalli

Hi, We have seen a WARNING message while fuzzing with syzkaller. Kernel 5.15.54 on an x86_64 localhost login: [ 104.557712] ------------[ cut here ]------------ [ 104.558404] WARNING: CPU: 1 PID: 15544 at mm/page_alloc.c:5358 __alloc_pages+0x38a/0x410 [ 104.559584] Modules linked in: [ 104.560030] CPU: 1 PID: 15544 Comm: repro Not tainted 5.15.54 #1 [ 104.560896] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 [ 104.562190] RIP: 0010:__alloc_pages+0x38a/0x410 [ 104.562864] Code: ff 4c 89 fa 44 89 f6 89 ef 89 6c 24 48 c6 44 24 78 00 4c 89 6c 24 60 e8 c4 e5 ff ff 49 89 c4 e9 43 fe ff ff 40 80 e5 3f eb c5 <0f> 0b eb a5 4c 89 e7 44 89 f6 45 31 e4 e8 c4 9f ff ff e9 4a fe ff [ 104.565421] RSP: 0018:ffff88801b4577f0 EFLAGS: 00010246 [ 104.566182] RAX: 0000000000000000 RBX: 1ffff1100368aeff RCX: dffffc0000000000 [ 104.567177] RDX: 0000000000000000 RSI: 0000000000000012 RDI: 0000000000040cc0 [ 104.568185] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 [ 104.569196] R10: fffffff900000000 R11: 0000000000000001 R12: 0000000000000001 [ 104.570194] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 104.571201] FS: 00007fda701c7740(0000) GS:ffff888107080000(0000) knlGS:0000000000000000 [ 104.572330] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 104.573146] CR2: 0000000020004640 CR3: 0000000020c34000 CR4: 00000000000006e0 [ 104.574149] Call Trace: [ 104.574503] <TASK> [ 104.574838] ? __sanitizer_cov_trace_cmp4+0x25/0x90 [ 104.575535] ? __alloc_pages_slowpath.constprop.0+0x16c0/0x16c0 [ 104.576391] ? bpf_ksym_find+0x171/0x1c0 [ 104.576985] ? selinux_socket_sendmsg+0x207/0x2d0 [ 104.577938] ? __sanitizer_cov_trace_const_cmp8+0x27/0x90 [ 104.578739] alloc_pages+0x191/0x3f0 [ 104.579258] kmalloc_order+0x34/0xb0 [ 104.579794] kmalloc_order_trace+0x19/0xa0 [ 104.580375] sco_sock_sendmsg+0x10f/0x300 [ 104.581228] ? security_socket_sendmsg+0x8e/0xc0 I have attached the report and the reproducer. A similar warning is seen on some testing previously. Ref: https://lore.kernel.org/linux-mm/812dab5c-845d-df58-2752-abea7c07890@google… Commit: 99c23da0eed4 ("Bluetooth: sco: Fix lock_sock() blockage by memcpy_from_msg()") is backported to LTS. So we have this bug on LTS branches. The Fix commit is not backported to LTS. Commit: 0771cbb3b97d ("Bluetooth: SCO: Replace use of memcpy_from_msg with bt_skb_sendmsg") I have tried backporting onto LTS locally. Can you please backport the following commits to these branches. 4.14.y, 4.19.y, 5.4.y, 5.10.y, 5.15.y LTS. (applying from 1 to 7) 1. commit 38f64f650dc0e44c146ff88d15a7339efa325918 upstream ("Bluetooth: Add bt_skb_sendmsg helper") 2. commit 97e4e80299844bb5f6ce5a7540742ffbffae3d97 upstream ("Bluetooth: Add bt_skb_sendmmsg helper") 3. commit 0771cbb3b97d3c1d68eecd7f00055f599954c34e upstream ("Bluetooth: SCO: Replace use of memcpy_from_msg with bt_skb_sendmsg") 4. commit 81be03e026dc0c16dc1c64e088b2a53b73caa895 upstream ("Bluetooth: RFCOMM: Replace use of memcpy_from_msg with bt_skb_sendmmsg") 5. commit 266191aa8d14b84958aaeb5e96ee4e97839e3d87 upstream ("Bluetooth: Fix passing NULL to PTR_ERR") 6. commit 037ce005af6b8a3e40ee07c6e9266c8997e6a4d6 upstream ("Bluetooth: SCO: Fix sco_send_frame returning skb->len") 7. commit 29fb608396d6a62c1b85acc421ad7a4399085b9f upstream ("Bluetooth: Fix bt_skb_sendmmsg not allocating partial chunks") Notes: 3 is the fix for the WARNING. 1,2 are prerequisites for applying 3. At this stage the WARNING is fixed. 4,5,6,7 are necessary as they are fixing newly introduced commits by us. This is a clean cherry-pick series(7 commits) on all mentioned branches(LTS 4.14->5.15) I have tested all mentioned LTS branches with the reproducer(only) and the WARNING is fixed after applying these 7 patches. Please correct me if I am missing something. Thanks, Harshit

2 years, 5 months

2
1
0 0

Your contact number

by Pawan kumar

Sir Am on my way to airport will like to contact you if i reach chicago please kindly share your contact number with me so i can reach you

2 years, 5 months

1
0
0 0

[PATCH v3] ufs: core: fix lockdep warning of clk_scaling_lock

by peter.wang＠mediatek.com

From: Peter Wang <peter.wang(a)mediatek.com> There have a lockdep warning like below in current flow. kworker/u16:0: Possible unsafe locking scenario: kworker/u16:0: CPU0 CPU1 kworker/u16:0: ---- ---- kworker/u16:0: lock(&hba->clk_scaling_lock); kworker/u16:0: lock(&hba->dev_cmd.lock); kworker/u16:0: lock(&hba->clk_scaling_lock); kworker/u16:0: lock(&hba->dev_cmd.lock); kworker/u16:0: Before this patch clk_scaling_lock was held in reader mode during the ufshcd_wb_toggle() call. With this patch applied clk_scaling_lock is not held while ufshcd_wb_toggle() is called. This is safe because ufshcd_wb_toggle will held clk_scaling_lock in reader mode "again" in flow ufshcd_wb_toggle -> __ufshcd_wb_toggle -> ufshcd_query_flag_retry -> ufshcd_query_flag -> ufshcd_exec_dev_cmd -> down_read(&hba->clk_scaling_lock); The protect should enough and make sure clock is not change while send command. ufshcd_wb_toggle can protected by hba->clk_scaling.is_allowed to make sure ufshcd_devfreq_scale function not run concurrently. Fixes: 0e9d4ca43ba8 ("scsi: ufs: Protect some contexts from unexpected clock scaling") Signed-off-by: Peter Wang <peter.wang(a)mediatek.com> --- drivers/ufs/core/ufshcd.c | 27 ++++++++++++++++----------- 1 file changed, 16 insertions(+), 11 deletions(-) diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c index c7b337480e3e..aa57126fdb49 100644 --- a/drivers/ufs/core/ufshcd.c +++ b/drivers/ufs/core/ufshcd.c @@ -272,6 +272,7 @@ static void ufshcd_wb_toggle_flush_during_h8(struct ufs_hba *hba, bool set); static inline void ufshcd_wb_toggle_flush(struct ufs_hba *hba, bool enable); static void ufshcd_hba_vreg_set_lpm(struct ufs_hba *hba); static void ufshcd_hba_vreg_set_hpm(struct ufs_hba *hba); +static void ufshcd_clk_scaling_allow(struct ufs_hba *hba, bool allow); static inline void ufshcd_enable_irq(struct ufs_hba *hba) { @@ -1249,12 +1250,10 @@ static int ufshcd_clock_scaling_prepare(struct ufs_hba *hba) return ret; } -static void ufshcd_clock_scaling_unprepare(struct ufs_hba *hba, bool writelock) +static void ufshcd_clock_scaling_unprepare(struct ufs_hba *hba) { - if (writelock) - up_write(&hba->clk_scaling_lock); - else - up_read(&hba->clk_scaling_lock); + up_write(&hba->clk_scaling_lock); + ufshcd_scsi_unblock_requests(hba); ufshcd_release(hba); } @@ -1271,7 +1270,7 @@ static void ufshcd_clock_scaling_unprepare(struct ufs_hba *hba, bool writelock) static int ufshcd_devfreq_scale(struct ufs_hba *hba, bool scale_up) { int ret = 0; - bool is_writelock = true; + bool wb_toggle = false; ret = ufshcd_clock_scaling_prepare(hba); if (ret) @@ -1300,13 +1299,19 @@ static int ufshcd_devfreq_scale(struct ufs_hba *hba, bool scale_up) } } - /* Enable Write Booster if we have scaled up else disable it */ - downgrade_write(&hba->clk_scaling_lock); - is_writelock = false; - ufshcd_wb_toggle(hba, scale_up); + /* Disable clk_scaling until ufshcd_wb_toggle finish */ + hba->clk_scaling.is_allowed = false; + wb_toggle = true; out_unprepare: - ufshcd_clock_scaling_unprepare(hba, is_writelock); + ufshcd_clock_scaling_unprepare(hba); + + /* Enable Write Booster if we have scaled up else disable it */ + if (wb_toggle) { + ufshcd_wb_toggle(hba, scale_up); + ufshcd_clk_scaling_allow(hba, true); + } + return ret; } -- 2.18.0

2 years, 5 months

3
2
0 0

[merged mm-hotfixes-stable] userfaultfd-provide-properly-masked-address-for-huge-pages.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: userfaultfd: provide properly masked address for huge-pages has been removed from the -mm tree. Its filename was userfaultfd-provide-properly-masked-address-for-huge-pages.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Nadav Amit <namit(a)vmware.com> Subject: userfaultfd: provide properly masked address for huge-pages Date: Mon, 11 Jul 2022 09:59:06 -0700 Commit 824ddc601adc ("userfaultfd: provide unmasked address on page-fault") was introduced to fix an old bug, in which the offset in the address of a page-fault was masked. Concerns were raised - although were never backed by actual code - that some userspace code might break because the bug has been around for quite a while. To address these concerns a new flag was introduced, and only when this flag is set by the user, userfaultfd provides the exact address of the page-fault. The commit however had a bug, and if the flag is unset, the offset was always masked based on a base-page granularity. Yet, for huge-pages, the behavior prior to the commit was that the address is masked to the huge-page granulrity. While there are no reports on real breakage, fix this issue. If the flag is unset, use the address with the masking that was done before. Link: https://lkml.kernel.org/r/20220711165906.2682-1-namit@vmware.com Fixes: 824ddc601adc ("userfaultfd: provide unmasked address on page-fault") Signed-off-by: Nadav Amit <namit(a)vmware.com> Reported-by: James Houghton <jthoughton(a)google.com> Reviewed-by: Mike Rapoport <rppt(a)linux.ibm.com> Reviewed-by: Peter Xu <peterx(a)redhat.com> Reviewed-by: James Houghton <jthoughton(a)google.com> Cc: David Hildenbrand <david(a)redhat.com> Cc: Jan Kara <jack(a)suse.cz> Cc: Andrea Arcangeli <aarcange(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/userfaultfd.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) --- a/fs/userfaultfd.c~userfaultfd-provide-properly-masked-address-for-huge-pages +++ a/fs/userfaultfd.c @@ -192,17 +192,19 @@ static inline void msg_init(struct uffd_ } static inline struct uffd_msg userfault_msg(unsigned long address, + unsigned long real_address, unsigned int flags, unsigned long reason, unsigned int features) { struct uffd_msg msg; + msg_init(&msg); msg.event = UFFD_EVENT_PAGEFAULT; - if (!(features & UFFD_FEATURE_EXACT_ADDRESS)) - address &= PAGE_MASK; - msg.arg.pagefault.address = address; + msg.arg.pagefault.address = (features & UFFD_FEATURE_EXACT_ADDRESS) ? + real_address : address; + /* * These flags indicate why the userfault occurred: * - UFFD_PAGEFAULT_FLAG_WP indicates a write protect fault. @@ -488,8 +490,8 @@ vm_fault_t handle_userfault(struct vm_fa init_waitqueue_func_entry(&uwq.wq, userfaultfd_wake_function); uwq.wq.private = current; - uwq.msg = userfault_msg(vmf->real_address, vmf->flags, reason, - ctx->features); + uwq.msg = userfault_msg(vmf->address, vmf->real_address, vmf->flags, + reason, ctx->features); uwq.ctx = ctx; uwq.waken = false; _ Patches currently in -mm which might be from namit(a)vmware.com are

2 years, 5 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror July 2022