Re: android,lowmemorykiller: Don't abuse TIF_MEMDIE.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel



[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux