Hi, On Sunday, 10 October 2021 23:42:39 CEST Francois Le Hir wrote: > I am not sure what is the correct process and I apologize if this is not the > appropriate way to do it, but could you please include this patch in your > next testing, unstable or experimental kernel ? Please don't use HTML email, but plain-text email. It is (strongly) preferred and in several cases (like linux MLs) even required. > Re: kvm crash in 5.14.1? — Linux Kernel > > > Re: kvm crash in 5.14.1? — Linux Kernel > > Linux Kernel: Re: kvm crash in 5.14.1? The plain-text view of your mail doesn't show what this issue is about; with plain-text email that wouldn't be the case ;-) For reference, this is what the issue is about: > I haven't reproduced the crash, but the code signature (CMP against an > absolute address) is quite distinct, and is consistent across all three > crashes. I'm pretty sure the issue is that page_is_secretmem() doesn't > check for a null page->mapping, e.g. if the page is truncated, which IIUC > can happen in parallel since gup() doesn't hold the lock. > > I think this should fix the problems? > > diff --git a/include/linux/secretmem.h b/include/linux/secretmem.h > index 21c3771e6a56..988528b5da43 100644 > --- a/include/linux/secretmem.h > +++ b/include/linux/secretmem.h > @@ -23,7 +23,7 @@ static inline bool page_is_secretmem(struct page *page) > > mapping = (struct address_space *) > > ((unsigned long)page->mapping & ~PAGE_MAPPING_FLAGS); > > - if (mapping != page->mapping) > + if (!mapping || mapping != page->mapping) > > return false; > > return mapping->a_ops == &secretmem_aops; src: https://www.spinics.net/lists/kernel/msg4094132.html This file was introduced in (tag) v5.14-rc1 and apparently causes a problem with KVM. I don't use KVM so I haven't experienced this issue myself. The best way to report an issue in the Debian kernel, is to file a bug in Debian's BTS with the 'reportbug' tool against the package you encountered the bug in. Provide all the relevant information in it. And in this case also a reference to LKML for the upstream discussion. To get the fix in Debian's kernel, the general procedure is to get the fix included in the upstream Linux kernel first. Both current 'master' and 'linux-5.14.y' branches do currently not contain that fix, so do/help to get that done first. When it's accepted upstream, it'll likely get backported to linux-5.14.y and then it would get picked up automatically when the Debian kernel upgrades to that version. In some cases it could get backported/applied to Debian before that, but the general requirement is that it is *first* applied upstream. HTH, Diederik
Attachment:
signature.asc
Description: This is a digitally signed message part.