Grant Grundler | 1 May 2008 02:15
Favicon

Re: [PATCH] unify the macro get_u16 in the file tulip.h

On Thu, May 01, 2008 at 01:34:38AM +0800, gao changli wrote:
> Unify the macro get_u16 with le16_to_cpu.
>
> Signed-off-by: Changli Gao <xiaosuo <at> gmail.com>

Acked-by: Grant Grundler <grundler <at> parisc-linux.org>

Jeff,
please apply.  Depends on other patches that define le16_to_cpu().

grant

> ---
>
>  tulip.h |    6 +-----
>  1 file changed, 1 insertion(+), 5 deletions(-)
>
> --- linux/drivers/net/tulip/tulip.h	2008-04-30 23:25:24.000000000 +0800
> +++ linux-new/drivers/net/tulip/tulip.h	2008-04-30 23:28:04.000000000 +0800
>  <at>  <at>  -299,11 +299,7  <at>  <at> 
>
>  #define RUN_AT(x) (jiffies + (x))
>
> -#if defined(__i386__)			/* AKA get_unaligned() */
> -#define get_u16(ptr) (*(u16 *)(ptr))
> -#else
> -#define get_u16(ptr) (((u8*)(ptr))[0] + (((u8*)(ptr))[1]<<8))
> -#endif
> +#define get_u16(ptr) le16_to_cpu(*(u16*)(ptr))
>
(Continue reading)

Joe Perches | 1 May 2008 02:43

Re: [PATCH] unify the macro get_u16 in the file tulip.h

On Wed, 2008-04-30 at 18:15 -0600, Grant Grundler wrote:
> On Thu, May 01, 2008 at 01:34:38AM +0800, gao changli wrote:
> > Unify the macro get_u16 with le16_to_cpu.
> > Signed-off-by: Changli Gao <xiaosuo <at> gmail.com>
> Acked-by: Grant Grundler <grundler <at> parisc-linux.org>
> please apply.  Depends on other patches that define le16_to_cpu().

Wouldn't it be better to remove get_u16 altogether
and use le16_to_cpu or __le16_to_cpup directly?

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

John W. Linville | 1 May 2008 02:43
Favicon

pull request: wireless-2.6 2008-04-30

David,

Here is another volley of fixes for 2.6.26.  It all seems fairly
straight-forward.

Thanks,

John

---

Individual patches are available here:

	http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/

---

The following changes since commit 809917903127804c2b2ac76342ab0f29f4b394d3:
  Pavel Emelyanov (1):
        ipv6: Compilation fix for compat MCAST_MSFILTER sockopts.

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master

Harvey Harrison (1):
      mac80211: incorrect shift direction

Holger Schurig (1):
      libertas: fix use-before-check violation
(Continue reading)

Herbert Xu | 1 May 2008 03:11
Picon
Picon

Re: [Patch]net/xfrm/xfrm_policy.c: replace timer with delayed_work

On Thu, May 01, 2008 at 12:06:55AM +0800, WANG Cong wrote:
> 
> Hi, Herbert.
> 
> I referenced the book Linux Device Drivers, it is said that
> the work function in workqueue can sleep, that is to say, it only
> works in process context, so we don't need the disable the lock
> in softirq, which is interrupt context, right?

Because it can sleep, you must disable BH for locks that can
be taken on the softirq path as otherwise a softirq can come
in, try to take the lock again and dead-lock.

Cheers,
--

-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert <at> gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Johannes Berg | 1 May 2008 04:02
Favicon

mac80211 truesize bugs

Hi,

Whenever you run a monitor interface in mac80211, you can see lots of
truesize bugs:

SKB BUG: Invalid truesize (464) len=307, sizeof(sk_buff)=176

It appears to be caused by mac80211's re-injection of the transmitted
frame. For those not familiar, here's what happens:

When a frame comes in on say wlan0's hard_start_xmit(), it is prepared
for transmission by the code there (802.11 headers added etc.) and then
scheduled to the master interface. Once it arrives on the master
(wmaster0) interface's hard_start_xmit(), it is modified again and
finally handed to the driver.

When the driver has transmitted the frame (successfully or not) it
reports the status of the transmission to mac80211 including the skb the
driver was given. At that point, things go different depending on
circumstances.

If no monitor interfaces are present, mac80211 simply orphans the skb
and destroys it. If there are monitor interfaces, it pushes some data
into the skb (the radiotap transmit status) and hands clones of the skb
to netif_rx() for each monitor interface, or the skb itself for the last
interface in the list.

All this is in net/mac80211/main.c:ieee80211_tx_status.

Now, the thing is that the skb truesize bug ONLY occurs when the last
(Continue reading)

Greg KH | 1 May 2008 05:12
Picon

Re: [PATCH 00/10] sysfs tagged directories

On Tue, Apr 29, 2008 at 02:34:17PM -0500, Serge E. Hallyn wrote:
> Quoting Greg KH (gregkh <at> suse.de):
> > On Tue, Apr 29, 2008 at 01:04:45PM -0500, Serge E. Hallyn wrote:
> > > Quoting Greg KH (gregkh <at> suse.de):
> > > > On Tue, Apr 29, 2008 at 07:10:15PM +0200, Benjamin Thery wrote:
> > > > > Here is the announcement Eric wrote back in December to introduce his 
> > > > > patchset:
> > > > 
> > > > <snip>
> > > > 
> > > > Are the objections that Al Viro made to this patchset when it was last
> > > > sent out addressed in this new series?
> > > > 
> > > > thanks,
> > > > 
> > > > greg k-h
> > > 
> > > Which objections were those?  The last submission which I see by Eric
> > > was http://lkml.org/lkml/2007/12/1/15 this past December.  I see no
> > > response from Al and get the feeling you were ok with them.
> > > 
> > > So my hunch would be that Eric had addressed those before that last
> > > submission, but if not I'm sorry, and please do set me straight.
> > 
> > See the thread from Al starting with:
> > 	Date: Mon, 7 Jan 2008 10:24:17 +0000
> > 	From: Al Viro <viro <at> ZenIV.linux.org.uk>
> > 	To: "Eric W. Biederman" <ebiederm <at> xmission.com>
> > 	Cc: linux-kernel <at> vger.kernel.org, htejun <at> gmail.com,
> > 	        linux-fsdevel <at> vger.kernel.org, gregkh <at> suse.de
(Continue reading)

Greg KH | 1 May 2008 05:13
Picon

Re: [PATCH 00/10] sysfs tagged directories

On Tue, Apr 29, 2008 at 02:34:17PM -0500, Serge E. Hallyn wrote:
> Finally, to give an idea about how the trees end up looking, here is
> what I just did on my test box;
> 
> /usr/sbin/ip link add type veth
> mount --bind /mnt /mnt
> mkdir /mnt/sys
> mount --make-shared /mnt
> ns_exec -cmn /bin/sh  # unshare netns and mounts ns
>  # At this point, I still see eth0 and friends under /sys/class/net etc
> mount -t sysfs none /sys
>  # At this point, /sys/class/net has only lo0 and sit0, and
>  # /sys/devices/pci0000:00/0000:00:03.0/net:eth0 is a dead link
> mount --bind /sys /mnt/sys
> echo $$
> 	3050
> 
> (back in another shell):
> /usr/sbin/ip link set veth1 netns 3050
> 
> (back in container shell):
> /usr/sbin/ip link set veth1 name eth0
>  # Now /sys/devices/pci0000:00/0000:00:03.0/net:eth0 is a live link to
>  # the /sys/class/net/eth0 which is really the original veth1
> exit
> 
> ls /mnt/sys/class/net
>  # empty directory

What does this all look like without CONFIG_SYSFS_DEPRECATED enabled,
(Continue reading)

Ivo van Doorn | 1 May 2008 10:21
Picon

Re: [RFC/RFT 4/4] mac80211: use multi-queue master netdevice

On Wednesday 30 April 2008, Johannes Berg wrote:
> Turns out there was something missing (last hunk of this updated
> version) from the rt2x00 part of the patch that I accidentally didn't
> quilt edit, here's an updated version if anybody wants to test on rt2x00
> hw.

I've tested the following patch series:

mac80211: clean up get_tx_stats callback
mac80211: remove queue info from ieee80211_tx_status
mac80211: QoS related cleanups
mac80211: use rate index in TX control
GSO: generalize for mac80211
mac80211: use GSO for fragmentation
mac80211: use multi-queue master netdevice

My rt61 card (4 TX queues) seems to work correctly, it uses
queue 3 as default queue, and a few packets seem to go
over queue 1.

Ivo

> johannes
> 
> Subject: mac80211: use multi-queue master netdevice
> 
> This patch updates mac80211 and drivers to be multi-queue aware and
> use that instead of the internal queue mapping.
> 
> Signed-off-by: Johannes Berg <johannes@...>
(Continue reading)

Johannes Berg | 1 May 2008 10:54
Favicon

Re: [RFC/RFT 4/4] mac80211: use multi-queue master netdevice


> I've tested the following patch series:
> 
> mac80211: clean up get_tx_stats callback
> mac80211: remove queue info from ieee80211_tx_status
> mac80211: QoS related cleanups
> mac80211: use rate index in TX control
> GSO: generalize for mac80211
> mac80211: use GSO for fragmentation
> mac80211: use multi-queue master netdevice
> 
> My rt61 card (4 TX queues) seems to work correctly, it uses
> queue 3 as default queue, and a few packets seem to go
> over queue 1.

Nice, thanks for testing!

johannes
Michael Buesch | 1 May 2008 10:58
Picon
Favicon

Re: mac80211 truesize bugs

On Thursday 01 May 2008 04:02:48 Johannes Berg wrote:
> Hi,
> 
> Whenever you run a monitor interface in mac80211, you can see lots of
> truesize bugs:
> 
> SKB BUG: Invalid truesize (464) len=307, sizeof(sk_buff)=176
> 
> It appears to be caused by mac80211's re-injection of the transmitted
> frame. For those not familiar, here's what happens:
> 
> When a frame comes in on say wlan0's hard_start_xmit(), it is prepared
> for transmission by the code there (802.11 headers added etc.) and then
> scheduled to the master interface. Once it arrives on the master
> (wmaster0) interface's hard_start_xmit(), it is modified again and
> finally handed to the driver.
> 
> When the driver has transmitted the frame (successfully or not) it
> reports the status of the transmission to mac80211 including the skb the
> driver was given. At that point, things go different depending on
> circumstances.
> 
> If no monitor interfaces are present, mac80211 simply orphans the skb
> and destroys it. If there are monitor interfaces, it pushes some data
> into the skb (the radiotap transmit status) and hands clones of the skb
> to netif_rx() for each monitor interface, or the skb itself for the last
> interface in the list.

Hm, unrelated to this...
But I am wondering what happens if the driver adds a device header to the skb.
(Continue reading)


Gmane