Messages in this thread | ![/](/images/icornerl.gif) | | Date | Wed, 20 Mar 2024 14:58:59 +0100 | Subject | Re: [PATCH RESEND 1/1] um: oops on accessing a non-present page in the vmalloc area | From | Petr Tesarik <> |
| |
On 3/19/2024 11:18 PM, Richard Weinberger wrote: > ----- Ursprüngliche Mail ----- >> Von: "Petr Tesarik" <petrtesarik@huaweicloud.com> >> An: "richard" <richard@nod.at>, "anton ivanov" <anton.ivanov@cambridgegreys.com>, "Johannes Berg" >> <johannes@sipsolutions.net>, "linux-um" <linux-um@lists.infradead.org>, "linux-kernel" <linux-kernel@vger.kernel.org> >> CC: "Roberto Sassu" <roberto.sassu@huaweicloud.com>, "petr" <petr@tesarici.cz> >> Gesendet: Montag, 18. März 2024 14:09:07 >> Betreff: Re: [PATCH RESEND 1/1] um: oops on accessing a non-present page in the vmalloc area > >> On 3/12/2024 4:07 PM, Petr Tesarik wrote: >>> On 2/23/2024 3:04 PM, Petr Tesarik wrote: >>>> From: Petr Tesarik <petr.tesarik1@huawei-partners.com> >>>> >>>> If a segmentation fault is caused by accessing an address in the vmalloc >>>> area, check that the target page is present. >>>> >>>> Currently, if the kernel hits a guard page in the vmalloc area, UML blindly >>>> assumes that the fault is caused by a stale mapping and will be fixed by >>>> flush_tlb_kernel_vm(). Unsurprisingly, if the fault is caused by accessing >>>> a guard page, no mapping is created, and when the faulting instruction is >>>> restarted, it will cause exactly the same fault again, effectively creating >>>> an infinite loop. >>> >>> Ping. Any comment on this fix? >> >> I don't think I have seen a reply from you. If you did comment, then >> your email has not reached me. >> >> Please, can you confirm you have seen my patch? > > Yes. I'm just way behind my maintainer schedule. :-/
Understood. Thank you for your reply.
By the way, are you looking for more people to help with the amount of work?
Petr T
| ![\](/images/icornerr.gif) |