[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080908.204323.04156464.davem@davemloft.net>
Date: Mon, 08 Sep 2008 20:43:23 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: j@...fi
Cc: jouni.malinen@...eros.com, alex.williamson@...com,
torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT]: Networking
From: Jouni Malinen <j@...fi>
Date: Mon, 8 Sep 2008 19:55:25 -0700
> On Mon, Sep 08, 2008 at 07:46:27PM -0700, David Miller wrote:
> > This one breaks wireless with 32bit userspace/64bit kernel. Bisected
> > back to changeset 087d833e5a9f67ba933cb32eaf5a2279c1a5b47c:
> >
> > mac80211: Use IWEVASSOCREQIE instead of IWEVCUSTOM
>
> Great.. I was hoping that the WEXT compat ioctl fixes from Dave resolved
> all WEXT cases. This code is (and was) using wireless_send_event() and I
> did not find clear changes to its use in Dave's patch set. Was that
> supposed to be fixed with the compat ioctl patches? I'm not very
> familiar with this area and don't have an easy way to test this now (I'm
> traveling and don't have access to a 64/32-bit setup).
If we're talking about the netlink emission of WEXT blobs, then such
bits cannot be fixed unfortunately, because via netlink we don't know
in the message generating context what kind of process will receive
the message.
In fact, when broadcasting a netlink message, applications of different
dispositions can want to receive the message.
So in essence netlink cases cannot be fixed for COMPAT handling,
rather, netlink protocols must be designed to be COMPAT agnostic from
the beginning, and use fixed sized types only. WEXT was not.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists