linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jean Tourrilhes <jt@hpl.hp.com>
To: David Miller <davem@davemloft.net>
Cc: shaddy_baddah@hotmail.com, linux-wireless@vger.kernel.org,
	dsd@gentoo.org, johannes@sipsolutions.net
Subject: Re: zd1211rw (2.6.22 sparc64): unaligned access (do_rx)
Date: Thu, 6 Dec 2007 13:25:25 -0800	[thread overview]
Message-ID: <20071206212525.GA6509@bougret.hpl.hp.com> (raw)
In-Reply-To: <20071205.183628.211180882.davem@davemloft.net>

On Wed, Dec 05, 2007 at 06:36:28PM -0800, David Miller wrote:
> From: Jean Tourrilhes <jt@hpl.hp.com>
> Date: Wed, 5 Dec 2007 13:56:00 -0800
> 
> > 	Personally, I was under the impression that in userspace libc
> > trap unaligned access and make them work. I mean, this code was tested
> > on other 64/32 bit platforms (PPC, AMD-64, PS3) and was working there,
> > so this seems to be specific to your platform.
> 
> None of those listed platforms trap on unaligned accesses like sparc
> does.

	I knew it was a problem in kernel space, and this is why we
have nice macros to perform unaligned access. My assumption that
userspace was behaving differently, and that all this stuff was hidden
from the end user through some trap handler.

> > 	In any case, I've modified my code to use a memcpy() instead
> > of direct memory access. I'm not 100% sure it will fix it because many
> > time memcpy() is optimised away to a direct memory access.
> 
> This only works if you hide the underlying types from the compiler,
> using something like:
> 
> static void copy_object(void *dst, void *src, int len)
> {
> 	memcpy(dst, src, len);
> }
> 
> And use the copy_object() thing to move unaligned things around.

	Most likely, copy_object() will be inlined.

> Otherwise gcc can see the underlying types and assume alignment, and
> thus generate the memcpy inline using word sized loads and stores, and
> you'll just get the same unaligned access problems.

	Well, it seems that the memcpy() did the trick. I guess that
the gcc optimiser is smart enough to recognise the fact that the
pointers may be unaligned.
	I don't like being at the mercy of gcc, so I'll fix that
better.

> The fix is to eliminate the unaligned data in the first place.  This
> compat fixup stuff really belongs in the kernel.

	If people were using the kernel API directly and not using
iwlib, I would agree 100% with you.
	My long term plan is to fix the problem at the source,
i.e. always generate the data with the proper alignement regardless of
32 or 64 bits, so that you don't need any "fix" in the compat layer or
in userspace. Unfortunately, it's too early for that.


	Now, I'm wondering how to deal with unaligned access in
userspace. If you get data from hardware or the network, you can not
guarantee that everything will always be aligned, so we need a way to
deal with it.
	In the kernel, we have get_unaligned(). I wonder what's the
equivalent in userspace.

	Have fun...

	Jean

  reply	other threads:[~2007-12-06 21:26 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-19  0:56 zd1211rw (2.6.22 sparc64): unaligned access (do_rx) Shaddy Baddah
2007-11-19  8:27 ` David Miller
2007-11-19 12:11   ` Shaddy Baddah
2007-11-19 12:19     ` David Miller
2007-11-21 13:08     ` Shaddy Baddah
2007-11-19 15:03   ` Johannes Berg
2007-11-19 18:04     ` Jean Tourrilhes
2007-11-21 13:18       ` Shaddy Baddah
2007-11-21 13:30         ` Shaddy Baddah
2007-11-21 14:23           ` Daniel Drake
2007-11-21 18:05             ` Kyle McMartin
2007-11-30  5:31             ` Shaddy Baddah
2007-11-21 14:33           ` Daniel Drake
2007-11-21 18:44         ` Jean Tourrilhes
2007-11-30  3:42           ` Shaddy Baddah
2007-11-30 20:21             ` Jean Tourrilhes
2007-12-04  0:01               ` Jean Tourrilhes
     [not found]                 ` <4756AABC.3000204@hotmail.com>
     [not found]                   ` <20071205215600.GA28349@bougret.hpl.hp.com>
2007-12-05 23:25                     ` Shaddy Baddah
2007-12-05 23:40                       ` Jean Tourrilhes
2007-12-06 21:59                       ` Jean Tourrilhes
2007-12-06  2:36                     ` David Miller
2007-12-06 21:25                       ` Jean Tourrilhes [this message]
2007-12-06 21:33                         ` Michael Buesch
2007-12-06 21:43                           ` Jean Tourrilhes
2007-12-07  3:52                             ` David Miller
2007-12-07 11:35                               ` Michael Buesch
2007-12-07 12:34                                 ` David Miller
2007-12-07 13:36                                   ` Michael Buesch
2007-12-07 14:48                                     ` Daniel Drake
2007-12-08  1:36                                       ` David Miller
2007-12-08  1:35                                     ` David Miller
2007-12-08 11:21                                       ` Michael Buesch
2007-12-08 12:54                                         ` Daniel Drake
2007-12-07  3:50                           ` David Miller
2007-12-07  3:49                         ` David Miller
2007-11-19 22:20     ` David Miller
2007-11-19 22:35       ` Jean Tourrilhes
2007-11-20  7:42         ` David Miller
2007-11-20 17:43           ` Jean Tourrilhes
2007-11-20 21:56             ` David Miller
2007-11-20 12:40       ` Johannes Berg
2007-11-20 12:46         ` David Miller
     [not found]           ` <20071120180016.GC1480@bougret.hpl.hp.com>
2007-11-20 21:58             ` David Miller
2007-11-20 22:08               ` John W. Linville
2007-11-20 22:38                 ` David Miller
2007-11-20 22:16               ` Jean Tourrilhes
2007-11-20 22:41                 ` David Miller
     [not found]             ` <20071120180601.GA2019@bougret.hpl.hp.com>
     [not found]               ` <47443430.3010504@hotmail.com>
2007-11-21 19:06                 ` Jean Tourrilhes
2007-11-20 17:38         ` Jean Tourrilhes
2007-11-20 12:34   ` David Miller
2007-11-20 13:15     ` Johannes Berg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071206212525.GA6509@bougret.hpl.hp.com \
    --to=jt@hpl.hp.com \
    --cc=davem@davemloft.net \
    --cc=dsd@gentoo.org \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=shaddy_baddah@hotmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).