linux-kernel - Re: [GIT PULL] Btrfs

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]

Message-ID: <CA+5PVA6Qon0cskv5wDyiCxSZzc2WjUFmzYmGE0zoNJC5ms1-XQ@mail.gmail.com>
Date:	Fri, 13 Sep 2013 11:06:20 -0400
From:	Josh Boyer <jwboyer@...il.com>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Chris Mason <chris.mason@...ionio.com>,
	Mark Fasheh <mfasheh@...e.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-btrfs <linux-btrfs@...r.kernel.org>,
	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
	Linux-Arch <linux-arch@...r.kernel.org>
Subject: Re: [GIT PULL] Btrfs

On Fri, Sep 13, 2013 at 8:15 AM, Russell King <rmk@....linux.org.uk> wrote:
> On Fri, Sep 13, 2013 at 07:53:21AM -0400, Josh Boyer wrote:
>> I'm not an ARM expert, so I don't know if ARM should use the
>> asm-generic implementations, or just use __get_user/__put_user in all
>> cases.  I've CC'd rmk.
>
> Why do we have uaccess-unaligned.h ?  Normally, these kinds of things
> are spawned by architectures which have problems with unaligned accesses,
> ARM being one of them, but afaik we've never need this.
>
> With the kernel-side trapping of unaligned accesses on older hardware,
> we've always dealt with the normal accessor faulting.
>
> From what I can tell in the git history, these unaligned put_user and
> get_user have existed all the way back to the dawn of git use.
>
> Can someone enlighten me why we have them?

So while that gets sorted out, would it be safe to just do as Geert
did on m68k and put:

#define __put_user_unaligned(x, ptr) __put_user((x), (ptr))

in arch/arm/include/asm/uaccess.h, and let the normal accessors and
kernel-side trapping deal with things?  I'm thinking that's a local
fix until something gets sorted upstream, but I don't want to do it if
it's going to break things.

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