On Fri, Jan 23, 2015 at 6:30 AM, Al Viro <viro(a)zeniv.linux.org.uk> wrote:
On Thu, Jan 22, 2015 at 09:40:01PM +0000, Al Viro wrote:
> On Thu, Jan 22, 2015 at 09:29:03PM +0000, Al Viro wrote:
> > On Thu, Jan 22, 2015 at 04:25:13PM -0500, Paul Moore wrote:
> >
> > > Your experimental branch looks good to me, thanks.
> >
> > Pushed into for-next; I'm probably going to move that stuff into a
never-rebased
> > branch, merged into for-next and safe to pull into your tree if you want to do
> > something on top of that set.
>
> OK, vfs.git#getname is it; it's in never-to-be-rebased mode and it's merged
> into vfs.git#for-next (as of right now; HEAD is 9ee4c4). If you need to do
> something on top of that stuff, pulling vfs.git#getname is safe.
Unfortunately, that thing was -rc2-based, leading to conflict with mainline
in kernel/auditsc.c. My fault, I hadn't realized that "audit: create private
file name copies when auditing inodes" in audit tree was, in fact, present in
mainline. vfs.git#getname2 is -rc3-based, same resulting kernel/auditsc.c as
in #getname. Please, use that. vfs.git#for-next merges from that one now,
so tomorrow -next should have no problems from vfs.git...
I have tested vfs.git#getname2 on top of Linux v3.19-rc5-184-gc4e00f1
(plus block-loopmq patchset) and it boots fine on Ubuntu/precise
amd64.
Just curious, where will this audit-filename-handling overhaul go through?
Through Paul's audit-next or Al's vfs-next tree?
AFAICS, a new linux-next will be available on Monday (2015-01-26).
I try to retest with this.
- Sedat -