[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120307195104.GA5071@redhat.com>
Date: Wed, 7 Mar 2012 20:51:04 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: Cyrill Gorcunov <gorcunov@...nvz.org>
Cc: akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
adobriyan@...il.com, ebiederm@...ssion.com, keescook@...omium.org,
kosaki.motohiro@...fujitsu.com, matthltc@...ibm.com, tj@...nel.org,
xemul@...allels.com
Subject: Re: + mm-exec-rename-mm-exe_file-to-mm-exe_path.patch added to -mm
tree
Andrew, please drop this (trivial as I thought) patch :/
On 03/07, Cyrill Gorcunov wrote:
>
> On Wed, Mar 07, 2012 at 06:41:13PM +0100, Oleg Nesterov wrote:
> ...
> > I do not think I really need it, but just in case... could you send me
> > (privately) the result of "make fs/dcache.s" ?
> >
>
> yes, just sent.
>
> > I'll try to recheck the patch and think.
> >
> > But if you can _explain_ why do you think that "struct path" can't work,
> > please explain ;)
>
> OK, the best way to prove myself that I was wrong is to try to
> explain why it can't work. So I prepared a call trace to point
> where we can get a reference to non-existing path and... found
> that it's simply impossible.
It is possible, and you even explained this in the private email
with asm you sent me.
> OOPs. Sorry for false alarm, Oleg!
No, thanks for the report and analysis.
Indeed, the patch is deadly wrong. Somehow I missed that ->f_path
is not the pointer! So set_mm_exe_path(&bprm->file->f_path) is
is obvioulsy wrong. I didn't bother to think about "&" think call
needs.
Thanks!
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists