Dan Carpenter wrote:
> On Thu, Apr 07, 2016 at 06:49:58AM +0900, Tetsuo Handa wrote:
> > Dan Carpenter wrote:
> > > Hello Tetsuo Handa,
> >
> > Hello, Dan.
> >
> > >
> > > This is a semi-automatic email about new static checker warnings.
> > >
> > > The patch 77ed2c5745d9: "android,lowmemorykiller: Don't abuse
> > > TIF_MEMDIE." from Mar 8, 2016, leads to the following Smatch
> > > complaint:
> > >
> > > drivers/staging/android/lowmemorykiller.c:145 lowmem_scan()
> > > error: we previously assumed 'p->mm' could be null (see line 134)
> >
> > This is a false positive. find_lock_task_mm() returns a task_struct
> > whose mm is not NULL (with alloc_lock spinlock held).
>
> Yeah. Smatch isn't supposed to warn about this. I'll look at it. But
> we should still remove the unneeded NULL check, right?
>
Indeed, this "p->mm &&" is pointless. You can remove it.
Well,
task_lock(selected);
send_sig(SIGKILL, selected, 0);
if (selected->mm)
task_set_lmk_waiting(selected);
task_unlock(selected);
sets PFA_LMK_WAITING to only one of threads in the victim's thread group, and
if (task_lmk_waiting(p) &&
time_before_eq(jiffies, lowmem_deathpending_timeout)) {
task_unlock(p);
rcu_read_unlock();
return 0;
}
will select next thread in the same victim's thread group as soon as
previous thread in the same victim's thread group released its mm.
Maybe we are calling lowmem_print() more frequently than needed.
_______________________________________________
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
