lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <201206010036.40468.vapier@gentoo.org>
Date:	Fri, 1 Jun 2012 00:36:35 -0400
From:	Mike Frysinger <vapier@...too.org>
To:	Anton Vorontsov <anton.vorontsov@...aro.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Russell King <linux@....linux.org.uk>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Richard Weinberger <richard@....at>,
	Paul Mundt <lethal@...ux-sh.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	John Stultz <john.stultz@...aro.org>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	uclinux-dist-devel@...ckfin.uclinux.org,
	linuxppc-dev@...ts.ozlabs.org, linux-sh@...r.kernel.org,
	user-mode-linux-devel@...ts.sourceforge.net,
	linaro-kernel@...ts.linaro.org, patches@...aro.org,
	linux-mm@...ck.org
Subject: Re: [PATCH 5/9] blackfin: A couple of task->mm handling fixes

On Monday 23 April 2012 03:09:01 Anton Vorontsov wrote:
> 1. Working with task->mm w/o getting mm or grabing the task lock is
>    dangerous as ->mm might disappear (exit_mm() assigns NULL under
>    task_lock(), so tasklist lock is not enough).

that isn't a problem for this code as it specifically checks if it's in an 
atomic section.  if it is, then task->mm can't go away on us.

>    We can't use get_task_mm()/mmput() pair as mmput() might sleep,
>    so we have to take the task lock while handle its mm.

if we're not in an atomic section, then sleeping is fine.

> 2. Checking for process->mm is not enough because process' main
>    thread may exit or detach its mm via use_mm(), but other threads
>    may still have a valid mm.

i don't think it matters for this code (per the reasons above).

>    To catch this we use find_lock_task_mm(), which walks up all
>    threads and returns an appropriate task (with task lock held).

certainly fine for the non-atomic code path.  i guess we'll notice in crashes 
if it causes a problem in atomic code paths as well.
-mike

Download attachment "signature.asc " of type "application/pgp-signature" (837 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ