[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160823145235.t3xs3fcf24qkaaw2@mguzik>
Date: Tue, 23 Aug 2016 16:52:36 +0200
From: Mateusz Guzik <mguzik@...hat.com>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Konstantin Khlebnikov <khlebnikov@...dex-team.ru>,
Richard Guy Briggs <rgb@...hat.com>, ebiederm@...ssion.com,
sgrubb@...hat.com, pmoore@...hat.com, eparis@...hat.com,
luto@...capital.net, linux-audit@...hat.com,
linux-kernel@...r.kernel.org, Al Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCHv2 1/2] mm: introduce get_task_exe_file
On Tue, Aug 23, 2016 at 04:48:13PM +0200, Oleg Nesterov wrote:
> On 08/23, Mateusz Guzik wrote:
> >
> > +struct file *get_task_exe_file(struct task_struct *task)
> > +{
> > + struct file *exe_file = NULL;
> > + struct mm_struct *mm;
> > +
> > + task_lock(task);
> > + mm = task->mm;
> > + if (mm) {
> > + if (!(task->flags & PF_KTHREAD))
> > + exe_file = get_mm_exe_file(mm);
> > + }
> > + task_unlock(task);
> > + return exe_file;
> > +}
>
> I can't believe I am going to comment the coding style but I can't resist ;)
>
> if (mm && !(task->flags & PF_KTHREAD)))
> exe_file = get_mm_exe_file(mm);
>
> looks a bit simpler to me. But this is purely cosmetic and subjective,
> both patches look good to me.
>
Actually I did it for some consistency with get_task_mm.
The check can likely be done prior to taking the lock in both functions
and that would clean them up a little bit, but I wanted to avoid nit
picking... :>
> Acked-by: Oleg Nesterov <oleg@...hat.com>
>
Thanks
--
Mateusz Guzik
Powered by blists - more mailing lists