linux-kernel - Re: [PATCH v2 21/29] nios2: Futex operations

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <17186253.ZJUn1qWK0f@wuerfel>
Date:	Fri, 18 Jul 2014 11:09:10 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Ley Foon Tan <lftan@...era.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Linux-Arch <linux-arch@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	Chung-Lin Tang <cltang@...esourcery.com>
Subject: Re: [PATCH v2 21/29] nios2: Futex operations

On Friday 18 July 2014 14:07:42 Ley Foon Tan wrote:
> On Thu, Jul 17, 2014 at 7:07 PM, Arnd Bergmann <arnd@...db.de> wrote:
> > The get_user/put_user functions really need to be annotated might_fault(),
> > because that's what they do.
> >
> > The whole point of get_user() is to access an unchecked user space
> > pointer, which  can do a number of things based on what the pointer
> > points to:
> >
> > - access a user space variable that resides in memory
> > - access a kernel pointer and fail because of the access_ok()
> >   check
> > - access a user space pointer that is not mapped and return
> >   through the __ex_table fixup.
> > - access a user space pointer that has a valid VMA but not PTE,
> >   causing a page fault to be resolved.
> >
> > It's the last case that breaks here.
> So, do you mean that we can't use get_user/put_user in futex support?
> BTW, some architectures like sh,parisc, m68k use get_user in futex
> function as well.
> Any recommendation way to support futex if we can't use get_user.
> Note, nios2 doesn't have atomic instruction.
> Thanks.

I looked at it again now and I'm no longer sure about my initial
interpretation. The way it seems to work is that pagefault_disable()
turns the case I mentioned into a simple error through the fixup,
so we return -EFAULT from get_user, and retry the futex from
futex_wake_op().

This would however also mean that there is no need for a spinlock
at all, atomicity is already implied by pagefault_disable() here
because you are running on a UP kernel and pagefault_disable() also
means there is no preemption.

If this understanding is right, we can probably just merge the
m68k implementation into the asm-generic version, as that does
exactly that, and just isn't SMP safe. I'm still unsure whether
I'm missing something here though, as everything else seems to
do this in assembly, even for non-SMP machines that could use
the trivial method that m68k has.

	Arnd
--
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/