Re: [GIT PULL] Btrfs

From: Russell King
Date: Fri Sep 13 2013 - 11:59:09 EST


On Fri, Sep 13, 2013 at 11:38:15AM -0400, Josh Boyer wrote:
> On Fri, Sep 13, 2013 at 11:06 AM, Josh Boyer <jwboyer@xxxxxxxxx> wrote:
> > On Fri, Sep 13, 2013 at 8:15 AM, Russell King <rmk@xxxxxxxxxxxxxxxx> 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?
>
> I somehow fail at email and dropped Russell from CC on accident. Sigh.

You're not the first to do that recently. I'm beginning to think it's
something someone has written into email clients to make them do in order
to piss me off. I mean, it's _hard_ to do - you have to manually edit the
recipients list to just drop one person.

> > 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.

Yep, that should work just fine.

--
Russell King
ARM architecture Linux Kernel maintainer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/