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] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 21 Jun 2009 10:57:00 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Thomas Gleixner <tglx@...utronix.de>
cc:	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [GIT PULL] core kernel fixes



On Sun, 21 Jun 2009, Linus Torvalds wrote:
> 
> And as far as I can tell, that is indeed the only case where you use that 
> 'get_user_writeable()' thing. You've had futex_atomic_op_inuser() fail, 
> and need to repeat. No?

I just checked. Yes, this code is _only_ entered when an atomic op 
returned EFAULT. IOW, we absolutely know that the page tables are not set 
up for writability, and thus that the "fast" case will never ever trigger.

(Ok, in theory you could have some other thread writing to that page at 
the same time and handle the page fault and making it writable, but in 
practice that's not really relevant).

So just doing a "make_sure_its_writable()" and using handle_fault() is the 
right thing to do. Because it's what get_user_fast() would have done too, 
except it would have gone through first the fast case, and failed, then 
the slow case, and failed the lookup there, and then the slow case would 
have done that handle_mm_fault() in the end anyway.

In fact, since you're not actually interested in the page, you _could_ 
just do

	get_user_pages(tsk, mm, uaddr, 4, 1, 0, NULL, NULL);

where a NULL "pages" pointer already tells get_user_pages() that you're 
not interested.

That's at least cleaner than doing a "gup_fast()" (which isn't fast), and 
then freeing the page that you weren't even interested in.

		Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ