linux-ext4 - [Bug 201631] WARNING: CPU: 11 PID: 29593 at fs/ext4/inode.c:3927 .ext4_set_page

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 20 Dec 2018 08:21:10 +0000
From:   bugzilla-daemon@...zilla.kernel.org
To:     linux-ext4@...r.kernel.org
Subject: [Bug 201631] WARNING: CPU: 11 PID: 29593 at fs/ext4/inode.c:3927
 .ext4_set_page_dirty+0x70/0xb0

https://bugzilla.kernel.org/show_bug.cgi?id=201631

--- Comment #29 from Benjamin Herrenschmidt (benh@...nel.crashing.org) ---
The problem is of course that not everybody *can* use the MMU notifiers.

Say I am KVM on POWER9, with the currently work-in-progress feature (unmerged
patches) of exploiting the new HW support for interrupt virtualization.

In that context, the guest allocates a page for receiving interrupt events
(it's a ring buffer) and "registers" it with the hypervisor (a hypercall). The
HV gups it and passes the physical address to the HW, which will write to it
from then on.

There's *nothing* KVM can do when getting the MMU notifier. The MM simply MUST
NOT try to get rid of that page, it's going to be actively under HW use until
the VM terminates.

How do we do that safely ?

There is a very similar problem when doing PCI pass-through. The guest pages
are GUP'ed and put into the IOMMU so the devices can DMA to them. Here too,
there's nothing useful KVM can do on an MMU notifier, those pages must remain
pinned until either the guest is terminated or the IOMMU mapping is removed (in
the case where it's done via hypercalls).

So how do we do that in such a way that doesn't involve all the crashes, data
loss etc... that you mention ?

Talking of which, I noticed the AMD GPU driver in the call traces above, could
it be a similar case of fun with GUP ?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.