On Mon 13-08-18 12:12:52, Jan Kara wrote:
> On Fri 10-08-18 22:10:53, Theodore Y. Ts'o wrote:
> > The generic/344 failure seems to be caused by a WARNING triggered in
> > the nvdimm code:
>
> OK, apparently this is nothing new for you as generic/344 fails for you
> even with 3.17. But it should
On Mon, Aug 13, 2018 at 12:12:52PM +0200, Jan Kara wrote:
> > The generic/081 regression appears to be a device-mapper issue...
>
> I'll see if this reproduces for me. Doesn't seem to be related to the DAX
> patches you caary though.
It does seem to be a DAX-specific failure though.
> > The
On Fri 10-08-18 22:10:53, Theodore Y. Ts'o wrote:
> On Fri, Aug 10, 2018 at 04:33:49PM -0400, Theodore Y. Ts'o wrote:
> > I just kicked off a DAX test ("gce-xfstests -c dax -g auto") with
> > CONFIG_KASAN disabled, and I expect it shouldn't show up anything
> > concerning. So assuming nothing
On Fri, Aug 10, 2018 at 04:33:49PM -0400, Theodore Y. Ts'o wrote:
> I just kicked off a DAX test ("gce-xfstests -c dax -g auto") with
> CONFIG_KASAN disabled, and I expect it shouldn't show up anything
> concerning. So assuming nothing surprising pops up, yes it should be
> merged at the next
On Fri, Aug 10, 2018 at 02:52:53PM -0500, Eric Sandeen wrote:
>
> Hi Ted, hadn't seem feedback from you on this by the time it gathered reviews,
> is this something you plan to merge for realz? (I see it's on your dev
> branch now, just not sure of its permanence at this point.)
Yes, the dev
On 7/10/18 2:10 PM, Ross Zwisler wrote:
> Inodes using DAX should only ever have exceptional entries in their page
> caches. Make this clear by warning if the iteration in
> dax_layout_busy_page() ever sees a non-exceptional entry, and by adding a
> comment for the pagevec_release() call which
Inodes using DAX should only ever have exceptional entries in their page
caches. Make this clear by warning if the iteration in
dax_layout_busy_page() ever sees a non-exceptional entry, and by adding a
comment for the pagevec_release() call which only deals with struct page
pointers.