es (or the next user of the struct inode may use them);
but this has been happening for years, and the new BUG_ON(!mapping_empty)
was only guilty of revealing that. A proper fix will follow, but no hurry.
Signed-off-by: Hugh Dickins
---
fs/inode.c |9 -
1 file changed, 8 insertions
On Fri, 2 Apr 2021, Hugh Dickins wrote:
>
> There is a "Put holes back where they were" xas_store(&xas, NULL) on
> the failure path, which I think we would expect to delete empty nodes.
> But it only goes as far as nr_none. Is it ok to xas_store(&xas, NULL)
>
On Fri, 2 Apr 2021, Matthew Wilcox wrote:
> OK, more competent testing, and that previous bug now detected and fixed.
> I have a reasonable amount of confidence this will solve your problem.
> If you do apply this patch, don't enable CONFIG_TEST_XARRAY as the new
> tests assume that attempting to
On Wed, 31 Mar 2021, Matthew Wilcox wrote:
> On Tue, Mar 30, 2021 at 06:30:22PM -0700, Hugh Dickins wrote:
> > Running my usual tmpfs kernel builds swapping load, on Sunday's rc4-mm1
> > mmotm (I never got to try rc3-mm1 but presume it behaved the same way),
> > I
Running my usual tmpfs kernel builds swapping load, on Sunday's rc4-mm1
mmotm (I never got to try rc3-mm1 but presume it behaved the same way),
I hit clear_inode()'s BUG_ON(!mapping_empty(&inode->i_data)); on two
machines, within an hour or few, repeatably though not to order.
The stack backtrace
On Wed, 16 Nov 2016, Dan Williams wrote:
> The device-dax implementation originally tried to be tricky and allow
> private read-only mappings, but in the process allowed writable
> MAP_PRIVATE + MAP_NORESERVE mappings. For simplicity and predictability
> just fail all private mapping attempts sin
ly reassurance is that at least all the rest of it has
been under test for the last few months, via the SHMEM_HUGE_FORCE
override. So it's not as if none of the code has been tested,
but I am still mystified why it hasn't been obvious without.
To the patch,
Acked-by: Hugh Dickins
b
