patch,
and to Aneesh for now sounding the alarm.
The only 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 wit
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
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(+), 1 deletion(-)
--- mmotm/
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(>i_data)); on two
machines, within an hour or few, repeatably though not to order.
The stack backtrace has
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 Fri, 2 Apr 2021, Hugh Dickins wrote:
>
> There is a "Put holes back where they were" xas_store(, 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(, NULL)
> where there was no
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 hit c
