[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CA+55aFwtxgOAD78RnoEfwEHfr=D+Lr+9rktKTc_0-0zcE2XJTQ@mail.gmail.com>
Date: Fri, 7 Jul 2017 21:36:09 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Al Viro <viro@...iv.linux.org.uk>,
Dan Williams <dan.j.williams@...el.com>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Oleg Drokin <oleg.drokin@...el.com>,
Andreas Dilger <andreas.dilger@...el.com>,
James Simmons <jsimmons@...radead.org>
Subject: Re: [git pull] vfs.git pile 11 - iov_iter/hardening
On Fri, Jul 7, 2017 at 5:29 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
>
> Trivial conflicts with libnvdimm; this stuff will get some
> followups, but again, that's for another series.
Gaah. Yeah, I guess I could have done the trivial ugly merge that just
took the new copy_from_iter_flushcache() as-is, and didn't match it up
with all the new iov_iter hardening.
Except I decided I don't want that, and want to do a proper merge instead.
Which made the trivial merge something that actually changed that
copy_from_iter_flushcache() logic, and maybe I screwed it up in the
process.
It builds, and it looks right to me, but you and Dan should really
check out the end result.
Particularly so for the CONFIG_ARCH_HAS_UACCESS_FLUSHCACHE logic,
which is where this differs from the other cases, and which I changed
to make the #ifdef less noticeable.
I did try both a i386 and a x86-64 build of the iov_iter code, since
that should test both of those ARCH_HAS cases, but that was purely a
build test.
Also, the new __must_check warnings do trigger. At least for lustre. I
couldn't be arsed to try to fix those, since .. lustre. But I'm also
adding a couple of lustre people to the cc, just to make them aware of
it.. I'd really like the allmodconfig build to be clean.
Linus
Powered by blists - more mailing lists