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

Reply via email to