* RE: [PATCH 2/2] NET: Re-add VLAN tag for devices incapable of keeping it
From: Ramkrishna Vepa @ 2007-11-06 18:28 UTC (permalink / raw)
To: Dave Johnson, David Miller, jes, mchan, ram.vepa, <linux-ke
In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD77027E9D5E@nekter>
Dave,
If you can remove the patch for the s2io driver, we can submit a patch
that can dynamically program Xframe to strip or not strip the vlan tag
based on whether the vlan group is not NULL or NULL respectively. For
this, we have to modify the initialization as well as the vlan
registration.
With regards to the question on the Vlan id received not added to the
group, I think we should drop these packets. This change requires
additional changes to support multiple receive rings. But will add it to
the driver on our website, which supports multiple rx rings, tx fifos,
multiqueue etc, and is a very small incremental change.
Thanks,
Ram
> -----Original Message-----
> From: Ramkrishna Vepa [mailto:Ramkrishna.Vepa@neterion.com]
> Sent: Monday, November 05, 2007 6:40 PM
> To: Dave Johnson; David Miller; jes@trained-monkey.org;
> mchan@broadcom.com; ram.vepa@neterion.com;
linux-kernel@vger.kernel.org;
> netdev@vger.kernel.org; bguo@sw.starentnetworks.com
> Subject: RE: [PATCH 2/2] NET: Re-add VLAN tag for devices incapable of
> keeping it
>
> The Xframe (S2io) adapter can be programmed dynamically to either,
> always strip the vlan tag or not. In this case, if the vlan group is
> NULL, it can be programmed at run time to NOT strip the vlan tag.
>
> When a packet with a Vlan id is received that is not added to the
group,
> should it be dropped or indicated up? Either can be handled by the
> hardware. The vlan tag in this particular case will be stripped as the
> vlan group is not NULL.
>
> Ram
>
> > -----Original Message-----
> > From: Dave Johnson
> [mailto:djohnson+linux-kernel@sw.starentnetworks.com]
> > Sent: Monday, November 05, 2007 9:47 AM
> > To: David Miller; jes@trained-monkey.org; mchan@broadcom.com;
> > ram.vepa@neterion.com; linux-kernel@vger.kernel.org;
> > netdev@vger.kernel.org; bguo@sw.starentnetworks.com
> > Subject: [PATCH 2/2] NET: Re-add VLAN tag for devices incapable of
> keeping
> > it
> >
> >
> > This patch changes the following drivers to use vlan_hwaccel_rx()
> > and/or vlan_hwaccel_receive_skb() with a NULL vlan group if needed
as
> > they are not setup to dynamically enable/disable vlan removal in
> > their MAC based on the vlan group:
> >
> > drivers/net/tg3.c Tested on BCM5704, looks good
> > drivers/net/bnx2.c Tested on BCM5708, looks good
> > drivers/net/acenic.c Not tested, I don't have one of these
> > drivers/net/s2io.c Not tested, I don't have one of these
> >
> > In addition, these drivers might also need changes, but should
> > probably be done by the maintainer as it's not clear exactly what
> > change is needed:
> >
> > drivers/net/amd8111e.c
> > drivers/net/cxgb3/*
> >
> > Signed-off-by: Dave Johnson <djohnson@sw.starentnetworks.com>
> >
> > ===== drivers/net/acenic.c 1.77 vs edited =====
> > --- 1.77/drivers/net/acenic.c 2007-07-24 16:28:41 -04:00
> > +++ edited/drivers/net/acenic.c 2007-11-03 12:27:40 -04:00
> > @@ -2036,7 +2036,7 @@
> >
> > /* send it up */
> > #if ACENIC_DO_VLAN
> > - if (ap->vlgrp && (bd_flags & BD_FLG_VLAN_TAG)) {
> > + if (bd_flags & BD_FLG_VLAN_TAG) {
> > vlan_hwaccel_rx(skb, ap->vlgrp, retdesc->vlan);
> > } else
> > #endif
> > ===== drivers/net/bnx2.c 1.135 vs edited =====
> > --- 1.135/drivers/net/bnx2.c 2007-09-20 15:14:21 -04:00
> > +++ edited/drivers/net/bnx2.c 2007-11-05 09:34:26 -05:00
> > @@ -2493,7 +2493,8 @@
> > }
> >
> > #ifdef BCM_VLAN
> > - if ((status & L2_FHDR_STATUS_L2_VLAN_TAG) && (bp->vlgrp
> != 0))
> > {
> > + if ((status & L2_FHDR_STATUS_L2_VLAN_TAG) &&
> > + (bp->vlgrp || (bp->flags & ASF_ENABLE_FLAG))) {
> > vlan_hwaccel_receive_skb(skb, bp->vlgrp,
> > rx_hdr->l2_fhdr_vlan_tag);
> > }
> > ===== drivers/net/s2io.c 1.124 vs edited =====
> > --- 1.124/drivers/net/s2io.c 2007-08-03 18:10:44 -04:00
> > +++ edited/drivers/net/s2io.c 2007-11-03 12:29:09 -04:00
> > @@ -6834,8 +6834,7 @@
> > sp->mac_control.stats_info->sw_stat.mem_freed += skb->truesize;
> > if (!sp->lro) {
> > skb->protocol = eth_type_trans(skb, dev);
> > - if ((sp->vlgrp && RXD_GET_VLAN_TAG(rxdp->Control_2) &&
> > - vlan_strip_flag)) {
> > + if (RXD_GET_VLAN_TAG(rxdp->Control_2) &&
> vlan_strip_flag) {
> > /* Queueing the vlan frame to the upper layer */
> > if (napi)
> > vlan_hwaccel_receive_skb(skb, sp->vlgrp,
> > ===== drivers/net/tg3.c 1.523 vs edited =====
> > --- 1.523/drivers/net/tg3.c 2007-09-11 04:28:44 -04:00
> > +++ edited/drivers/net/tg3.c 2007-11-05 09:38:33 -05:00
> > @@ -3417,7 +3417,7 @@
> >
> > skb->protocol = eth_type_trans(skb, tp->dev);
> > #if TG3_VLAN_TAG_USED
> > - if (tp->vlgrp != NULL &&
> > + if ((tp->vlgrp || (tp->tg3_flags & TG3_FLAG_ENABLE_ASF))
> &&
> > desc->type_flags & RXD_FLAG_VLAN) {
> > tg3_vlan_rx(tp, skb,
> > desc->err_vlan & RXD_VLAN_MASK);
^ permalink raw reply
* Re: [PATCH 1/2] NET: Re-add VLAN tag for devices incapable of keeping it
From: Krzysztof Halasa @ 2007-11-06 18:03 UTC (permalink / raw)
To: Patrick McHardy
Cc: David Miller, djohnson+linux-kernel, jes, mchan, ram.vepa,
linux-kernel, netdev, bguo
In-Reply-To: <472FB375.1020802@trash.net>
Patrick McHardy <kaber@trash.net> writes:
> I think there is one more case that matters, which is briding
> from a device with VLAN stripping for a VLAN not configured
> locally. The tag will be stripped and will be lost for forwarded
> packets.
I think we should drop such packets on RX. Anyway we shouldn't
forward them.
--
Krzysztof Halasa
^ permalink raw reply
* Re: [PATCH 2.6.24 1/1]S2io: Fixed memory leak by freeing MSI-X local entry memories when vector allocation fails
From: Jeff Garzik @ 2007-11-06 17:46 UTC (permalink / raw)
To: Sreenivasa Honnur; +Cc: netdev, support
In-Reply-To: <Pine.GSO.4.10.10710310408190.9897-100000@guinness>
Sreenivasa Honnur wrote:
> - Fixed memory leak by freeing MSI-X local entry memories when vector allocation
> fails in s2io_add_isr.
> - Added two utility functions remove_msix_isr and remove_inta_isr to eliminate
> code duplication.
> - Implemented following review comments from Jeff
> - Removed redundant stats->mem_freed and synchronize_irq call
> - do_rem_msix_isr is renamed as remove_msix_isr
> - do_rem_inta_isr is renamed as remove_inta_isr
>
> Signed-off-by: Sreenivasa Honnur <sreenivasa.honnur@neterion.com>
> Signed-off-by: Ramkrishna Vepa <ram.vepa@neterion.com>
this patch should go into 2.6.24-rc, but it doesn't apply to upstream.
This may be because it requires "S2io: Support for
add/delete/store/restore ethernet addresses", I am guessing?
We want to reverse the order of those two patches, because "S2io:
Support for add/delete/store/restore ethernet addresses" is more
appropriate for non-bug-fix 2.6.24 rather than current bugfix-only
2.6.24-rc.
Jeff
^ permalink raw reply
* Re: Please pull 'upstream-jgarzik' branch of wireless-2.6
From: Jeff Garzik @ 2007-11-06 17:43 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, linux-wireless
In-Reply-To: <20071106011627.GB23747@tuxdriver.com>
John W. Linville wrote:
> Jeff,
>
> Here is a slew of patches targeted for 2.6.25. There are a bunch
> of rt2x00, iwl3945, iwl4965, b43, and b43legacy patches, as well as
> a few others. I'm sorry I didn't spread this out better -- I got a
> bit behind... :-(
>
> Thanks,
>
> John
>
> ---
>
> Individual patches are available here:
>
> http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/upstream-jgarzik/
pulled
^ permalink raw reply
* Re: [PATCH] add support for smc91x ethernet interface on zylonite
From: Jeff Garzik @ 2007-11-06 17:41 UTC (permalink / raw)
To: eric miao; +Cc: netdev, Nicolas Pitre
In-Reply-To: <f17812d70711051645p4d1a8e44mbc21413cc6ef12ba@mail.gmail.com>
eric miao wrote:
>>From 9363662844b6373ddf4265e7007eb29ff963a377 Mon Sep 17 00:00:00 2001
> From: eric miao <eric.miao@marvell.com>
> Date: Tue, 30 Oct 2007 09:48:41 +0800
> Subject: [PATCH] add support for smc91x ethernet interface on zylonite
>
> This patch adds LAN91C111 ethernet interface support for zylonite
> (a.k.a Marvell's PXA3xx Development Platform) with smc91x driver.
>
> It would be better if a patch would support zylonite along with all
> other PXA boards with a single binary of smc91x driver, but it looks
> quite difficult for the moment, so ugly #ifdef is still used here.
>
> Signed-off-by: Aleksey Makarov <amakarov@ru.mvista.com>
> Acked-by: eric miao <eric.miao@marvell.com>
> ---
> drivers/net/smc91x.h | 15 +++++++++++++++
> 1 files changed, 15 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/smc91x.h b/drivers/net/smc91x.h
> index 729fd28..db34e1e 100644
> --- a/drivers/net/smc91x.h
> +++ b/drivers/net/smc91x.h
> @@ -224,6 +224,21 @@ SMC_outw(u16 val, void __iomem *ioaddr, int reg)
> }
> }
>
> +#elif defined(CONFIG_MACH_ZYLONITE)
> +
> +#define SMC_CAN_USE_8BIT 1
> +#define SMC_CAN_USE_16BIT 1
> +#define SMC_CAN_USE_32BIT 0
> +#define SMC_IO_SHIFT 0
> +#define SMC_NOWAIT 1
> +#define SMC_USE_PXA_DMA 1
> +#define SMC_inb(a, r) readb((a) + (r))
> +#define SMC_inw(a, r) readw((a) + (r))
> +#define SMC_insw(a, r, p, l) insw((a) + (r), p, l)
> +#define SMC_outsw(a, r, p, l) outsw((a) + (r), p, l)
> +#define SMC_outb(v, a, r) writeb(v, (a) + (r))
> +#define SMC_outw(v, a, r) writew(v, (a) + (r))
> +
> #elif defined(CONFIG_ARCH_OMAP)
applied
^ permalink raw reply
* Re: [PATCH 1/7] sky2: enable PCI config writes
From: Jeff Garzik @ 2007-11-06 17:41 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20071105235339.973177053@linux-foundation.org>
applied 1-7
^ permalink raw reply
* Re: [BUG] in inet6_create
From: Roel Kluin @ 2007-11-06 17:31 UTC (permalink / raw)
To: Pavel Emelyanov; +Cc: netdev, linux-net
In-Reply-To: <473090FF.7000707@openvz.org>
Pavel Emelyanov wrote:
> Roel Kluin wrote:
>> Pavel Emelyanov wrote:
>>> Roel Kluin wrote:
>>>> Pavel Emelyanov wrote:
>>>>> Roel Kluin wrote:
>>>>>> Roel Kluin wrote:
>>>>>>> I got this bug recently, I am not sure whether this is related to any previously
>>>>>>> reported ones. It was a recently pulled git kernel. Also I have been hacking my
>>>>>>> kernel a bit lately, but I think that I haven't got any changes in the currently
>>>>>>> running kernel.
>>>>>>>
>>>>>>> FYI: my network card was not running (module not loaded, and I just started
>>>>>>> thunderbird)
>>>>>>>
>>>>>>> More information needed?
>>>>> Yes, please.
>>>>>
>>>>> Can you send us the disasm (objdump -dr) of your ipv6 module.
>>>>> More precisely - I need the disassembled inet6_create() function to
>>>>> figure out where exactly this thing happened.
>>>> I was very lucky to still be able to produce this: When the bug hit me, I had just
>>>> recompiled a new kernel, however, since I had previously git-pulled, (but not yet
>>>> compiled) the old module was not overwritten.
>>>>
>>>> to answer the question in your other mail - whether I hacked this kernel - I am not
>>>> 100% certain, I am certain, however that I did not touch IPv6 code, and my changes
>>>> to net code were very trivial oneliner changes that I have previously posted, and
>>>> were generally accepted as fixes.
>>>> --
>>>> 000002f0 <inet6_create>:
>>> Hm... The oops says that the buggy place is <inet6_create>+0x5f, that is
>>> (according to this dump) 0x2f0 + 0x5f = 0x34f, but:
>>>
>>> 1. there's no instruction at this address (there are 0x34e and 0x355)
>>> 2. the codeline (... 1c <8b> 00 0f 18 ...) is not present here
>>>
>>> There's something wrong with this oops...
>> hmmm, I see my mistake:
>> I _was_ already running the 2.6.24-rc1 kernel. It even says so in the BUG report
>
> Brrr... I'm completely confused. What was the kernel that oops-ed?
> 2.6.24-rc, net-2.6.24-rc1 or net-2.6.24-rc1-with-your-patches?
It was a git kernel, pulled from linus' tree:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
The version number on the bug was 2.6.24-rc1. I posted here because the bug mentioned
inet6_create and ipv6, which is net code.
>> Since the module is already overwritten, does it still help to make the objdump?
>>
>> Ok, I'll check for the address... yes it exists
>
> Yup. My first guess was correct - the inetsw6 list is broken - there's
> some NULL pointer in it. Looking at the code I see that this list
> is accessed for modifications under the spinlock and that it is properly
> initialized in the ->init callback before any code gets the access to this
> list. No ideas why this can happen... :(
>
>> Sorry for my mistake, the objdump for this module is below. note however that the
>> module has been overwritten previously after kernel compilation.
>>
>>> Is this reproducible? If yes, can you try the non-patched net-2.6 kernel.
>> I'll try to reproduce it. I'll confirm it when it happens again.
>
> Yes, please.
Ok, I tried but it did not work.
My kernel is very non-modular (which is also called monolithic?) one of the few
things that still was a module is my network card. ipv6 was another.
You may want to skip the next part: a lengthy explanation of the situation during
the bug.
In the original situation I had tried to build a kernel: I was trying an adapted
version of the profile-likely-unlikely-macros.patch, but due to an error in my code
kernel compilation failed,
I was using a stupid script which did:
make O=$BUILDDIR;
sudo make O=$BUILDDIR modules_install install
Note that I probably didn't run make mrproper beforehand.
Building failed, but modules were removed and I should have recompiled without the
error. I forgot that, so after rebooting my modules didn't work. the kernel booted
because all necessary code is compiled in.
My network card didn't function, however. So I decided to recompile with my
network card compiled in.
Then I was doing some other stuff, got bored, pressed Thunderbird - it's an
automatism - and right at that moment I got the oops.
So to try to reproduce this I compiled a new kernel, without compiling and
installing the modules. It did not reoccur, however.
Roel
^ permalink raw reply
* [PATCH] Clean proto_(un)register from in-code ifdefs
From: Pavel Emelyanov @ 2007-11-06 17:20 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, devel
The struct proto has the per-cpu "inuse" counter, which is handled
with a special care. All the handling code hides under the ifdef
CONFIG_SMP and it introduces some code duplication and makes it
look worse than it could.
Clean this.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
diff --git a/net/core/sock.c b/net/core/sock.c
index e077f26..8fc2f84 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1819,23 +1819,48 @@ static int inuse_get(const struct proto *prot)
res += per_cpu_ptr(prot->inuse_ptr, cpu)[0];
return res;
}
-#endif
-int proto_register(struct proto *prot, int alloc_slab)
+static int inuse_init(struct proto *prot)
{
- char *request_sock_slab_name = NULL;
- char *timewait_sock_slab_name;
- int rc = -ENOBUFS;
-
-#ifdef CONFIG_SMP
if (!prot->inuse_getval || !prot->inuse_add) {
prot->inuse_ptr = alloc_percpu(int);
if (prot->inuse_ptr == NULL)
- goto out;
+ return -ENOBUFS;
+
prot->inuse_getval = inuse_get;
prot->inuse_add = inuse_add;
}
+ return 0;
+}
+
+static void inuse_fini(struct proto *prot)
+{
+ if (prot->inuse_ptr != NULL) {
+ free_percpu(prot->inuse_ptr);
+ prot->inuse_ptr = NULL;
+ prot->inuse_getval = NULL;
+ prot->inuse_add = NULL;
+ }
+}
+#else
+static inline int inuse_init(struct proto *prot)
+{
+ return 0;
+}
+
+static inline void inuse_fini(struct proto *prot)
+{
+}
#endif
+
+int proto_register(struct proto *prot, int alloc_slab)
+{
+ char *request_sock_slab_name = NULL;
+ char *timewait_sock_slab_name;
+
+ if (inuse_init(prot))
+ goto out;
+
if (alloc_slab) {
prot->slab = kmem_cache_create(prot->name, prot->obj_size, 0,
SLAB_HWCACHE_ALIGN, NULL);
@@ -1887,9 +1912,8 @@ int proto_register(struct proto *prot, int alloc_slab)
write_lock(&proto_list_lock);
list_add(&prot->node, &proto_list);
write_unlock(&proto_list_lock);
- rc = 0;
-out:
- return rc;
+ return 0;
+
out_free_timewait_sock_slab_name:
kfree(timewait_sock_slab_name);
out_free_request_sock_slab:
@@ -1903,15 +1927,9 @@ out_free_sock_slab:
kmem_cache_destroy(prot->slab);
prot->slab = NULL;
out_free_inuse:
-#ifdef CONFIG_SMP
- if (prot->inuse_ptr != NULL) {
- free_percpu(prot->inuse_ptr);
- prot->inuse_ptr = NULL;
- prot->inuse_getval = NULL;
- prot->inuse_add = NULL;
- }
-#endif
- goto out;
+ inuse_fini(prot);
+out:
+ return -ENOBUFS;
}
EXPORT_SYMBOL(proto_register);
@@ -1922,14 +1940,7 @@ void proto_unregister(struct proto *prot)
list_del(&prot->node);
write_unlock(&proto_list_lock);
-#ifdef CONFIG_SMP
- if (prot->inuse_ptr != NULL) {
- free_percpu(prot->inuse_ptr);
- prot->inuse_ptr = NULL;
- prot->inuse_getval = NULL;
- prot->inuse_add = NULL;
- }
-#endif
+ inuse_fini(prot);
if (prot->slab != NULL) {
kmem_cache_destroy(prot->slab);
prot->slab = NULL;
^ permalink raw reply related
* Re: Endianness problem with u32 classifier hash masks
From: Radu Rendec @ 2007-11-06 17:00 UTC (permalink / raw)
To: hadi; +Cc: Jarek Poplawski, netdev
In-Reply-To: <1194360226.4444.39.camel@localhost>
On Tue, 2007-11-06 at 09:43 -0500, jamal wrote:
> On Tue, 2007-06-11 at 15:25 +0100, Jarek Poplawski wrote:
>
> > Yes, it saves one htonl() on the slow path!
>
> Would it feel better to say grew down exponentially from version 1 to
> 3? ;->
Not only it saves one htonl(), but also keeps the code readable :)
Computing offsets within the rtnetlink response skb and applying htonl()
there is quite tricky and might get broken if RTA_PUT() is changed.
Unfortunately I spent about an hour figuring out how to do that :))
The bad news is that today I haven't got the chance to work on the two
patches. But the good news is that I managed to finish the (urgent) task
that had been assigned to me at work, and tomorrow I will be able to
work on the kernel and test it leisurely.
> > > Please give yourself a little pat on the back for me.
> >
> > Wait a minute! Don't forget to take a picture or something!
>
> He needs the other arm for balance;-> so unless someone else takes the
> photo, i would say that should he be successful taking the photo, that
> achievement itself needs a double-self-pat-on-the-back (which i am going
> to say if he can also take a photo of needs to go on some records book)
I'm sorry to disappoint you, guys, but most probably I'll pat myself on
the back here at work, after I get enthusiastic about the patches. So my
fellow colleagues will take the picture for me. If I get really
enthusiastic, then I'll have my both arms available for patting :)
Cheers,
Radu
^ permalink raw reply
* Re: [PATCH] Fix e100 on systems that have cache incoherent DMA
From: Kok, Auke @ 2007-11-06 17:01 UTC (permalink / raw)
To: David Acker, Jeff Garzik
Cc: Auke Kok, e1000-devel, netdev, Jesse Brandeburg, Milton Miller,
Scott Feldman, John Ronciak, Jeff Kirsher
In-Reply-To: <20071102132703.1652446C128@localhost>
David Acker wrote:
> On the systems that have cache incoherent DMA, including ARM, there is a
> race condition between software allocating a new receive buffer and hardware
> writing into a buffer. The two race on touching the last Receive Frame
> Descriptor (RFD). It has its el-bit set and its next link equal to 0.
> When hardware encounters this buffer it attempts to write data to it and
> then update Status Word bits and Actual Count in the RFD. At the same time
> software may try to clear the el-bit and set the link address to a new buffer.
>
> Since the entire RFD is once cache-line, the two write operations can collide.
> This can lead to the receive unit stalling or interpreting random memory as
> its receive area.
>
> The fix is to set the el-bit on and the size to 0 on the next to last buffer
> in the chain. When the hardware encounters this buffer it stops and does not
> write to it at all. The hardware issues an RNR interrupt with the receive
> unit in the No Resources state. Software can write to the tail of the list
> because it knows hardware will stop on the previous descriptor that was
> marked as the end of list.
>
> Once it has a new next to last buffer prepared, it can clear the el-bit and
> set the size on the previous one. The race on this buffer is safe since
> the link already points to a valid next buffer and the software can handle
> the race setting the size (assuming aligned 16 bit writes are atomic with
> respect to the DMA read). If the hardware sees the el-bit cleared without
> the size set, it will move on to the next buffer and skip this one. If it
> sees the size set but the el-bit still set, it will complete that buffer
> and then RNR interrupt and wait.
>
>
> This is a patch for 2.6.24-rc1.
>
> Signed-off-by: David Acker <dacker@roinet.com>
OK, there are still a few small tests running but I think it's good. It ran over
the weekend in various tests and we didn't see any receive unit hangs, which we
would have spotted by now. That means that the patch as far as I can assess is
good to go and I will send it to Jeff later on.
There is a minute impact to small packet receive performance. the driver uses
about 0.5% more CPU at 64byte packets wire speed but it's still in the 3% total
range, so I think we're fine there.
Thanks for all the work David!
Auke
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
^ permalink raw reply
* Re: [BUG] in inet6_create
From: Pavel Emelyanov @ 2007-11-06 16:06 UTC (permalink / raw)
To: Roel Kluin; +Cc: netdev, linux-net
In-Reply-To: <47308BEC.1040302@tiscali.nl>
Roel Kluin wrote:
> Pavel Emelyanov wrote:
>> Roel Kluin wrote:
>>> Pavel Emelyanov wrote:
>>>> Roel Kluin wrote:
>>>>> Roel Kluin wrote:
>>>>>> I got this bug recently, I am not sure whether this is related to any previously
>>>>>> reported ones. It was a recently pulled git kernel. Also I have been hacking my
>>>>>> kernel a bit lately, but I think that I haven't got any changes in the currently
>>>>>> running kernel.
>>>>>>
>>>>>> FYI: my network card was not running (module not loaded, and I just started
>>>>>> thunderbird)
>>>>>>
>>>>>> More information needed?
>>>> Yes, please.
>>>>
>>>> Can you send us the disasm (objdump -dr) of your ipv6 module.
>>>> More precisely - I need the disassembled inet6_create() function to
>>>> figure out where exactly this thing happened.
>>> I was very lucky to still be able to produce this: When the bug hit me, I had just
>>> recompiled a new kernel, however, since I had previously git-pulled, (but not yet
>>> compiled) the old module was not overwritten.
>>>
>>> to answer the question in your other mail - whether I hacked this kernel - I am not
>>> 100% certain, I am certain, however that I did not touch IPv6 code, and my changes
>>> to net code were very trivial oneliner changes that I have previously posted, and
>>> were generally accepted as fixes.
>>> --
>>> 000002f0 <inet6_create>:
>> Hm... The oops says that the buggy place is <inet6_create>+0x5f, that is
>> (according to this dump) 0x2f0 + 0x5f = 0x34f, but:
>>
>> 1. there's no instruction at this address (there are 0x34e and 0x355)
>> 2. the codeline (... 1c <8b> 00 0f 18 ...) is not present here
>>
>> There's something wrong with this oops...
>
> hmmm, I see my mistake:
> I _was_ already running the 2.6.24-rc1 kernel. It even says so in the BUG report
Brrr... I'm completely confused. What was the kernel that oops-ed?
2.6.24-rc, net-2.6.24-rc1 or net-2.6.24-rc1-with-your-patches?
> Since the module is already overwritten, does it still help to make the objdump?
>
> Ok, I'll check for the address... yes it exists
Yup. My first guess was correct - the inetsw6 list is broken - there's
some NULL pointer in it. Looking at the code I see that this list
is accessed for modifications under the spinlock and that it is properly
initialized in the ->init callback before any code gets the access to this
list. No ideas why this can happen... :(
> Sorry for my mistake, the objdump for this module is below. note however that the
> module has been overwritten previously after kernel compilation.
>
>> Is this reproducible? If yes, can you try the non-patched net-2.6 kernel.
>
> I'll try to reproduce it. I'll confirm it when it happens again.
Yes, please.
> --
> 000002f0 <inet6_create>:
> 2f0: 55 push %ebp
> 2f1: bd 9f ff ff ff mov $0xffffff9f,%ebp
> 2f6: 57 push %edi
> 2f7: 89 cf mov %ecx,%edi
> 2f9: 56 push %esi
> 2fa: 53 push %ebx
> 2fb: 83 ec 20 sub $0x20,%esp
> 2fe: 3d 00 00 00 00 cmp $0x0,%eax
> 2ff: R_386_32 init_net
> 303: 89 54 24 10 mov %edx,0x10(%esp)
> 307: 74 0a je 313 <inet6_create+0x23>
> 309: 83 c4 20 add $0x20,%esp
> 30c: 89 e8 mov %ebp,%eax
> 30e: 5b pop %ebx
> 30f: 5e pop %esi
> 310: 5f pop %edi
> 311: 5d pop %ebp
> 312: c3 ret
> 313: 8b 72 20 mov 0x20(%edx),%esi
> 316: 8d 46 fe lea -0x2(%esi),%eax
> 319: 66 83 f8 01 cmp $0x1,%ax
> 31d: 76 0e jbe 32d <inet6_create+0x3d>
> 31f: 8b 0d 00 00 00 00 mov 0x0,%ecx
> 321: R_386_32 inet_ehash_secret
> 325: 85 c9 test %ecx,%ecx
> 327: 0f 84 12 02 00 00 je 53f <inet6_create+0x24f>
> 32d: c7 44 24 18 00 00 00 movl $0x0,0x18(%esp)
> 334: 00
> 335: 0f bf c6 movswl %si,%eax
> 338: c1 e0 03 shl $0x3,%eax
> 33b: 8b 98 00 00 00 00 mov 0x0(%eax),%ebx
> 33d: R_386_32 .bss
> 341: 8d 90 00 00 00 00 lea 0x0(%eax),%edx
> 343: R_386_32 .bss
> 347: 89 5c 24 1c mov %ebx,0x1c(%esp)
> 34b: 8b 44 24 1c mov 0x1c(%esp),%eax
> 34f: 8b 00 mov (%eax),%eax
> 351: 8d 44 20 00 lea 0x0(%eax),%eax
> 355: 39 d3 cmp %edx,%ebx
> 357: bd a2 ff ff ff mov $0xffffffa2,%ebp
> 35c: 75 36 jne 394 <inet6_create+0xa4>
> 35e: e9 f3 01 00 00 jmp 556 <inet6_create+0x266>
> 363: 85 ff test %edi,%edi
> 365: 0f 84 25 02 00 00 je 590 <inet6_create+0x2a0>
> 36b: 66 85 c0 test %ax,%ax
> 36e: 66 90 xchg %ax,%ax
> 370: 74 31 je 3a3 <inet6_create+0xb3>
> 372: 8b 1b mov (%ebx),%ebx
> 374: 89 5c 24 1c mov %ebx,0x1c(%esp)
> 378: 8b 44 24 1c mov 0x1c(%esp),%eax
> 37c: 8b 00 mov (%eax),%eax
> 37e: 8d 44 20 00 lea 0x0(%eax),%eax
> 382: 0f bf c6 movswl %si,%eax
> 385: 8d 04 c5 00 00 00 00 lea 0x0(,%eax,8),%eax
> 388: R_386_32 .bss
> 38c: 39 d8 cmp %ebx,%eax
> 38e: 0f 84 bd 01 00 00 je 551 <inet6_create+0x261>
> 394: 0f b7 43 0a movzwl 0xa(%ebx),%eax
> 398: 0f b7 c8 movzwl %ax,%ecx
> 39b: 39 cf cmp %ecx,%edi
> 39d: 75 c4 jne 363 <inet6_create+0x73>
> 39f: 85 ff test %edi,%edi
> 3a1: 74 cf je 372 <inet6_create+0x82>
> 3a3: 8b 43 14 mov 0x14(%ebx),%eax
> 3a6: 85 c0 test %eax,%eax
> 3a8: 7e 12 jle 3bc <inet6_create+0xcc>
> 3aa: e8 fc ff ff ff call 3ab <inet6_create+0xbb>
> 3ab: R_386_PC32 capable
> 3af: 85 c0 test %eax,%eax
> 3b1: bd ff ff ff ff mov $0xffffffff,%ebp
> 3b6: 0f 84 4d ff ff ff je 309 <inet6_create+0x19>
> 3bc: 8b 43 10 mov 0x10(%ebx),%eax
> 3bf: 8b 54 24 10 mov 0x10(%esp),%edx
> 3c3: 89 42 08 mov %eax,0x8(%edx)
> 3c6: 0f b6 43 18 movzbl 0x18(%ebx),%eax
> 3ca: 8b 73 0c mov 0xc(%ebx),%esi
> 3cd: 88 44 24 17 mov %al,0x17(%esp)
> 3d1: 0f b6 53 19 movzbl 0x19(%ebx),%edx
> 3d5: 88 54 24 16 mov %dl,0x16(%esp)
> 3d9: 8b 56 70 mov 0x70(%esi),%edx
> 3dc: 85 d2 test %edx,%edx
> 3de: 0f 84 17 02 00 00 je 5fb <inet6_create+0x30b>
> 3e4: b9 d0 00 00 00 mov $0xd0,%ecx
> 3e9: ba 0a 00 00 00 mov $0xa,%edx
> 3ee: b8 00 00 00 00 mov $0x0,%eax
> 3ef: R_386_32 init_net
> 3f3: 89 34 24 mov %esi,(%esp)
> 3f6: c7 44 24 04 01 00 00 movl $0x1,0x4(%esp)
> 3fd: 00
> 3fe: bd 97 ff ff ff mov $0xffffff97,%ebp
> 403: e8 fc ff ff ff call 404 <inet6_create+0x114>
> 404: R_386_PC32 sk_alloc
> 408: 85 c0 test %eax,%eax
> 40a: 89 c6 mov %eax,%esi
> 40c: 0f 84 f7 fe ff ff je 309 <inet6_create+0x19>
> 412: 89 c2 mov %eax,%edx
> 414: 8b 44 24 10 mov 0x10(%esp),%eax
> 418: e8 fc ff ff ff call 419 <inet6_create+0x129>
> 419: R_386_PC32 sock_init_data
> 41d: 80 64 24 17 03 andb $0x3,0x17(%esp)
> 422: 0f b6 54 24 17 movzbl 0x17(%esp),%edx
> 427: 0f b6 46 28 movzbl 0x28(%esi),%eax
> 42b: c1 e2 02 shl $0x2,%edx
> 42e: 83 e0 f3 and $0xfffffff3,%eax
> 431: 09 d0 or %edx,%eax
> 433: 88 46 28 mov %al,0x28(%esi)
> 436: 0f b6 44 24 16 movzbl 0x16(%esp),%eax
> 43b: a8 01 test $0x1,%al
> 43d: 74 04 je 443 <inet6_create+0x153>
> 43f: c6 46 03 01 movb $0x1,0x3(%esi)
> 443: 0f b6 96 5b 01 00 00 movzbl 0x15b(%esi),%edx
> 44a: c1 e8 02 shr $0x2,%eax
> 44d: 83 e0 01 and $0x1,%eax
> 450: 01 c0 add %eax,%eax
> 452: 83 e2 fd and $0xfffffffd,%edx
> 455: 09 c2 or %eax,%edx
> 457: 88 96 5b 01 00 00 mov %dl,0x15b(%esi)
> 45d: 8b 44 24 10 mov 0x10(%esp),%eax
> 461: 66 83 78 20 03 cmpw $0x3,0x20(%eax)
> 466: 0f 84 43 01 00 00 je 5af <inet6_create+0x2bf>
> 46c: 89 fa mov %edi,%edx
> 46e: c7 86 34 01 00 00 00 movl $0x0,0x134(%esi)
> 475: 00 00 00
> 474: R_386_32 inet_sock_destruct
> 478: 66 c7 06 0a 00 movw $0xa,(%esi)
> 47d: 88 56 29 mov %dl,0x29(%esi)
> 480: 8b 43 0c mov 0xc(%ebx),%eax
> 483: 8b 40 40 mov 0x40(%eax),%eax
> 486: 89 86 30 01 00 00 mov %eax,0x130(%esi)
> 48c: 8b 46 20 mov 0x20(%esi),%eax
> 48f: 8b 48 74 mov 0x74(%eax),%ecx
> 492: 83 e9 70 sub $0x70,%ecx
> 495: 8d 0c 0e lea (%esi,%ecx,1),%ecx
> 498: 89 8e 38 01 00 00 mov %ecx,0x138(%esi)
> 49e: 0f b6 41 46 movzbl 0x46(%ecx),%eax
> 4a2: 66 c7 41 3c ff ff movw $0xffff,0x3c(%ecx)
> 4a8: 66 c7 41 3e ff ff movw $0xffff,0x3e(%ecx)
> 4ae: 83 e0 e7 and $0xffffffe7,%eax
> 4b1: 83 c8 09 or $0x9,%eax
> 4b4: 88 41 46 mov %al,0x46(%ecx)
> 4b7: 0f b6 15 00 00 00 00 movzbl 0x0,%edx
> 4ba: R_386_32 sysctl_ipv6_bindv6only
> 4be: 83 e0 df and $0xffffffdf,%eax
> 4c1: 83 e2 01 and $0x1,%edx
> 4c4: c1 e2 05 shl $0x5,%edx
> 4c7: 09 d0 or %edx,%eax
> 4c9: 88 41 46 mov %al,0x46(%ecx)
> 4cc: 80 8e 5b 01 00 00 10 orb $0x10,0x15b(%esi)
> 4d3: 66 c7 86 4c 01 00 00 movw $0xffff,0x14c(%esi)
> 4da: ff ff
> 4dc: c6 86 59 01 00 00 01 movb $0x1,0x159(%esi)
> 4e3: c7 86 5c 01 00 00 00 movl $0x0,0x15c(%esi)
> 4ea: 00 00 00
> 4ed: c7 86 64 01 00 00 00 movl $0x0,0x164(%esi)
> 4f4: 00 00 00
> 4f7: a1 04 00 00 00 mov 0x4,%eax
> 4f8: R_386_32 ipv4_config
> 4fc: 85 c0 test %eax,%eax
> 4fe: 0f b7 86 46 01 00 00 movzwl 0x146(%esi),%eax
> 505: 0f 94 86 5a 01 00 00 sete 0x15a(%esi)
> 50c: 66 85 c0 test %ax,%ax
> 50f: 0f 85 82 00 00 00 jne 597 <inet6_create+0x2a7>
> 515: 8b 46 20 mov 0x20(%esi),%eax
> 518: 31 ed xor %ebp,%ebp
> 51a: 8b 50 14 mov 0x14(%eax),%edx
> 51d: 85 d2 test %edx,%edx
> 51f: 0f 84 e4 fd ff ff je 309 <inet6_create+0x19>
> 525: 89 f0 mov %esi,%eax
> 527: ff d2 call *%edx
> 529: 85 c0 test %eax,%eax
> 52b: 89 c5 mov %eax,%ebp
> 52d: 0f 84 d6 fd ff ff je 309 <inet6_create+0x19>
> 533: 89 f0 mov %esi,%eax
> 535: e8 fc ff ff ff call 536 <inet6_create+0x246>
> 536: R_386_PC32 sk_common_release
> 53a: e9 ca fd ff ff jmp 309 <inet6_create+0x19>
> 53f: 90 nop
> 540: e8 fc ff ff ff call 541 <inet6_create+0x251>
> 541: R_386_PC32 build_ehash_secret
> 545: 8b 44 24 10 mov 0x10(%esp),%eax
> 549: 8b 70 20 mov 0x20(%eax),%esi
> 54c: e9 dc fd ff ff jmp 32d <inet6_create+0x3d>
> 551: bd a3 ff ff ff mov $0xffffffa3,%ebp
> 556: 83 7c 24 18 02 cmpl $0x2,0x18(%esp)
> 55b: 0f 84 a8 fd ff ff je 309 <inet6_create+0x19>
> 561: ff 44 24 18 incl 0x18(%esp)
> 565: 83 7c 24 18 01 cmpl $0x1,0x18(%esp)
> 56a: 74 64 je 5d0 <inet6_create+0x2e0>
> 56c: 89 7c 24 08 mov %edi,0x8(%esp)
> 570: c7 44 24 04 0a 00 00 movl $0xa,0x4(%esp)
> 577: 00
> 578: c7 04 24 1b 00 00 00 movl $0x1b,(%esp)
> 57b: R_386_32 .rodata.str1.1
> 57f: e8 fc ff ff ff call 580 <inet6_create+0x290>
> 580: R_386_PC32 request_module
> 584: 8b 44 24 10 mov 0x10(%esp),%eax
> 588: 8b 70 20 mov 0x20(%eax),%esi
> 58b: e9 a5 fd ff ff jmp 335 <inet6_create+0x45>
> 590: 89 cf mov %ecx,%edi
> 592: e9 0c fe ff ff jmp 3a3 <inet6_create+0xb3>
> 597: 8b 56 20 mov 0x20(%esi),%edx
> 59a: 66 c1 c0 08 rol $0x8,%ax
> 59e: 66 89 86 54 01 00 00 mov %ax,0x154(%esi)
> 5a5: 89 f0 mov %esi,%eax
> 5a7: ff 52 44 call *0x44(%edx)
> 5aa: e9 66 ff ff ff jmp 515 <inet6_create+0x225>
> 5af: 81 ff ff 00 00 00 cmp $0xff,%edi
> 5b5: 66 89 be 46 01 00 00 mov %di,0x146(%esi)
> 5bc: 0f 85 aa fe ff ff jne 46c <inet6_create+0x17c>
> 5c2: 83 ca 08 or $0x8,%edx
> 5c5: 88 96 5b 01 00 00 mov %dl,0x15b(%esi)
> 5cb: e9 9c fe ff ff jmp 46c <inet6_create+0x17c>
> 5d0: 0f bf c6 movswl %si,%eax
> 5d3: 89 7c 24 08 mov %edi,0x8(%esp)
> 5d7: c7 44 24 04 0a 00 00 movl $0xa,0x4(%esp)
> 5de: 00
> 5df: 89 44 24 0c mov %eax,0xc(%esp)
> 5e3: c7 04 24 00 00 00 00 movl $0x0,(%esp)
> 5e6: R_386_32 .rodata.str1.1
> 5ea: e8 fc ff ff ff call 5eb <inet6_create+0x2fb>
> 5eb: R_386_PC32 request_module
> 5ef: 8b 54 24 10 mov 0x10(%esp),%edx
> 5f3: 8b 72 20 mov 0x20(%edx),%esi
> 5f6: e9 3a fd ff ff jmp 335 <inet6_create+0x45>
> 5fb: c7 44 24 0c a2 00 00 movl $0xa2,0xc(%esp)
> 602: 00
> 603: c7 44 24 08 a0 00 00 movl $0xa0,0x8(%esp)
> 60a: 00
> 607: R_386_32 .rodata.str1.4
> 60b: c7 44 24 04 2e 00 00 movl $0x2e,0x4(%esp)
> 612: 00
> 60f: R_386_32 .rodata.str1.1
> 613: c7 04 24 e0 00 00 00 movl $0xe0,(%esp)
> 616: R_386_32 .rodata.str1.4
> 61a: e8 fc ff ff ff call 61b <inet6_create+0x32b>
> 61b: R_386_PC32 printk
> 61f: e9 c0 fd ff ff jmp 3e4 <inet6_create+0xf4>
> 624: 8d b6 00 00 00 00 lea 0x0(%esi),%esi
> 62a: 8d bf 00 00 00 00 lea 0x0(%edi),%edi
>
> 00000630 <inet6_destroy_sock>:
>
^ permalink raw reply
* Re: [BUG] in inet6_create
From: Roel Kluin @ 2007-11-06 15:44 UTC (permalink / raw)
To: Pavel Emelyanov; +Cc: netdev, linux-net
In-Reply-To: <47302255.7060708@openvz.org>
Pavel Emelyanov wrote:
> Roel Kluin wrote:
>> Pavel Emelyanov wrote:
>>> Roel Kluin wrote:
>>>> Roel Kluin wrote:
>>>>> I got this bug recently, I am not sure whether this is related to any previously
>>>>> reported ones. It was a recently pulled git kernel. Also I have been hacking my
>>>>> kernel a bit lately, but I think that I haven't got any changes in the currently
>>>>> running kernel.
>>>>>
>>>>> FYI: my network card was not running (module not loaded, and I just started
>>>>> thunderbird)
>>>>>
>>>>> More information needed?
>>> Yes, please.
>>>
>>> Can you send us the disasm (objdump -dr) of your ipv6 module.
>>> More precisely - I need the disassembled inet6_create() function to
>>> figure out where exactly this thing happened.
>> I was very lucky to still be able to produce this: When the bug hit me, I had just
>> recompiled a new kernel, however, since I had previously git-pulled, (but not yet
>> compiled) the old module was not overwritten.
>>
>> to answer the question in your other mail - whether I hacked this kernel - I am not
>> 100% certain, I am certain, however that I did not touch IPv6 code, and my changes
>> to net code were very trivial oneliner changes that I have previously posted, and
>> were generally accepted as fixes.
>> --
>> 000002f0 <inet6_create>:
>
> Hm... The oops says that the buggy place is <inet6_create>+0x5f, that is
> (according to this dump) 0x2f0 + 0x5f = 0x34f, but:
>
> 1. there's no instruction at this address (there are 0x34e and 0x355)
> 2. the codeline (... 1c <8b> 00 0f 18 ...) is not present here
>
> There's something wrong with this oops...
hmmm, I see my mistake:
I _was_ already running the 2.6.24-rc1 kernel. It even says so in the BUG report
Since the module is already overwritten, does it still help to make the objdump?
Ok, I'll check for the address... yes it exists
Sorry for my mistake, the objdump for this module is below. note however that the
module has been overwritten previously after kernel compilation.
> Is this reproducible? If yes, can you try the non-patched net-2.6 kernel.
I'll try to reproduce it. I'll confirm it when it happens again.
--
000002f0 <inet6_create>:
2f0: 55 push %ebp
2f1: bd 9f ff ff ff mov $0xffffff9f,%ebp
2f6: 57 push %edi
2f7: 89 cf mov %ecx,%edi
2f9: 56 push %esi
2fa: 53 push %ebx
2fb: 83 ec 20 sub $0x20,%esp
2fe: 3d 00 00 00 00 cmp $0x0,%eax
2ff: R_386_32 init_net
303: 89 54 24 10 mov %edx,0x10(%esp)
307: 74 0a je 313 <inet6_create+0x23>
309: 83 c4 20 add $0x20,%esp
30c: 89 e8 mov %ebp,%eax
30e: 5b pop %ebx
30f: 5e pop %esi
310: 5f pop %edi
311: 5d pop %ebp
312: c3 ret
313: 8b 72 20 mov 0x20(%edx),%esi
316: 8d 46 fe lea -0x2(%esi),%eax
319: 66 83 f8 01 cmp $0x1,%ax
31d: 76 0e jbe 32d <inet6_create+0x3d>
31f: 8b 0d 00 00 00 00 mov 0x0,%ecx
321: R_386_32 inet_ehash_secret
325: 85 c9 test %ecx,%ecx
327: 0f 84 12 02 00 00 je 53f <inet6_create+0x24f>
32d: c7 44 24 18 00 00 00 movl $0x0,0x18(%esp)
334: 00
335: 0f bf c6 movswl %si,%eax
338: c1 e0 03 shl $0x3,%eax
33b: 8b 98 00 00 00 00 mov 0x0(%eax),%ebx
33d: R_386_32 .bss
341: 8d 90 00 00 00 00 lea 0x0(%eax),%edx
343: R_386_32 .bss
347: 89 5c 24 1c mov %ebx,0x1c(%esp)
34b: 8b 44 24 1c mov 0x1c(%esp),%eax
34f: 8b 00 mov (%eax),%eax
351: 8d 44 20 00 lea 0x0(%eax),%eax
355: 39 d3 cmp %edx,%ebx
357: bd a2 ff ff ff mov $0xffffffa2,%ebp
35c: 75 36 jne 394 <inet6_create+0xa4>
35e: e9 f3 01 00 00 jmp 556 <inet6_create+0x266>
363: 85 ff test %edi,%edi
365: 0f 84 25 02 00 00 je 590 <inet6_create+0x2a0>
36b: 66 85 c0 test %ax,%ax
36e: 66 90 xchg %ax,%ax
370: 74 31 je 3a3 <inet6_create+0xb3>
372: 8b 1b mov (%ebx),%ebx
374: 89 5c 24 1c mov %ebx,0x1c(%esp)
378: 8b 44 24 1c mov 0x1c(%esp),%eax
37c: 8b 00 mov (%eax),%eax
37e: 8d 44 20 00 lea 0x0(%eax),%eax
382: 0f bf c6 movswl %si,%eax
385: 8d 04 c5 00 00 00 00 lea 0x0(,%eax,8),%eax
388: R_386_32 .bss
38c: 39 d8 cmp %ebx,%eax
38e: 0f 84 bd 01 00 00 je 551 <inet6_create+0x261>
394: 0f b7 43 0a movzwl 0xa(%ebx),%eax
398: 0f b7 c8 movzwl %ax,%ecx
39b: 39 cf cmp %ecx,%edi
39d: 75 c4 jne 363 <inet6_create+0x73>
39f: 85 ff test %edi,%edi
3a1: 74 cf je 372 <inet6_create+0x82>
3a3: 8b 43 14 mov 0x14(%ebx),%eax
3a6: 85 c0 test %eax,%eax
3a8: 7e 12 jle 3bc <inet6_create+0xcc>
3aa: e8 fc ff ff ff call 3ab <inet6_create+0xbb>
3ab: R_386_PC32 capable
3af: 85 c0 test %eax,%eax
3b1: bd ff ff ff ff mov $0xffffffff,%ebp
3b6: 0f 84 4d ff ff ff je 309 <inet6_create+0x19>
3bc: 8b 43 10 mov 0x10(%ebx),%eax
3bf: 8b 54 24 10 mov 0x10(%esp),%edx
3c3: 89 42 08 mov %eax,0x8(%edx)
3c6: 0f b6 43 18 movzbl 0x18(%ebx),%eax
3ca: 8b 73 0c mov 0xc(%ebx),%esi
3cd: 88 44 24 17 mov %al,0x17(%esp)
3d1: 0f b6 53 19 movzbl 0x19(%ebx),%edx
3d5: 88 54 24 16 mov %dl,0x16(%esp)
3d9: 8b 56 70 mov 0x70(%esi),%edx
3dc: 85 d2 test %edx,%edx
3de: 0f 84 17 02 00 00 je 5fb <inet6_create+0x30b>
3e4: b9 d0 00 00 00 mov $0xd0,%ecx
3e9: ba 0a 00 00 00 mov $0xa,%edx
3ee: b8 00 00 00 00 mov $0x0,%eax
3ef: R_386_32 init_net
3f3: 89 34 24 mov %esi,(%esp)
3f6: c7 44 24 04 01 00 00 movl $0x1,0x4(%esp)
3fd: 00
3fe: bd 97 ff ff ff mov $0xffffff97,%ebp
403: e8 fc ff ff ff call 404 <inet6_create+0x114>
404: R_386_PC32 sk_alloc
408: 85 c0 test %eax,%eax
40a: 89 c6 mov %eax,%esi
40c: 0f 84 f7 fe ff ff je 309 <inet6_create+0x19>
412: 89 c2 mov %eax,%edx
414: 8b 44 24 10 mov 0x10(%esp),%eax
418: e8 fc ff ff ff call 419 <inet6_create+0x129>
419: R_386_PC32 sock_init_data
41d: 80 64 24 17 03 andb $0x3,0x17(%esp)
422: 0f b6 54 24 17 movzbl 0x17(%esp),%edx
427: 0f b6 46 28 movzbl 0x28(%esi),%eax
42b: c1 e2 02 shl $0x2,%edx
42e: 83 e0 f3 and $0xfffffff3,%eax
431: 09 d0 or %edx,%eax
433: 88 46 28 mov %al,0x28(%esi)
436: 0f b6 44 24 16 movzbl 0x16(%esp),%eax
43b: a8 01 test $0x1,%al
43d: 74 04 je 443 <inet6_create+0x153>
43f: c6 46 03 01 movb $0x1,0x3(%esi)
443: 0f b6 96 5b 01 00 00 movzbl 0x15b(%esi),%edx
44a: c1 e8 02 shr $0x2,%eax
44d: 83 e0 01 and $0x1,%eax
450: 01 c0 add %eax,%eax
452: 83 e2 fd and $0xfffffffd,%edx
455: 09 c2 or %eax,%edx
457: 88 96 5b 01 00 00 mov %dl,0x15b(%esi)
45d: 8b 44 24 10 mov 0x10(%esp),%eax
461: 66 83 78 20 03 cmpw $0x3,0x20(%eax)
466: 0f 84 43 01 00 00 je 5af <inet6_create+0x2bf>
46c: 89 fa mov %edi,%edx
46e: c7 86 34 01 00 00 00 movl $0x0,0x134(%esi)
475: 00 00 00
474: R_386_32 inet_sock_destruct
478: 66 c7 06 0a 00 movw $0xa,(%esi)
47d: 88 56 29 mov %dl,0x29(%esi)
480: 8b 43 0c mov 0xc(%ebx),%eax
483: 8b 40 40 mov 0x40(%eax),%eax
486: 89 86 30 01 00 00 mov %eax,0x130(%esi)
48c: 8b 46 20 mov 0x20(%esi),%eax
48f: 8b 48 74 mov 0x74(%eax),%ecx
492: 83 e9 70 sub $0x70,%ecx
495: 8d 0c 0e lea (%esi,%ecx,1),%ecx
498: 89 8e 38 01 00 00 mov %ecx,0x138(%esi)
49e: 0f b6 41 46 movzbl 0x46(%ecx),%eax
4a2: 66 c7 41 3c ff ff movw $0xffff,0x3c(%ecx)
4a8: 66 c7 41 3e ff ff movw $0xffff,0x3e(%ecx)
4ae: 83 e0 e7 and $0xffffffe7,%eax
4b1: 83 c8 09 or $0x9,%eax
4b4: 88 41 46 mov %al,0x46(%ecx)
4b7: 0f b6 15 00 00 00 00 movzbl 0x0,%edx
4ba: R_386_32 sysctl_ipv6_bindv6only
4be: 83 e0 df and $0xffffffdf,%eax
4c1: 83 e2 01 and $0x1,%edx
4c4: c1 e2 05 shl $0x5,%edx
4c7: 09 d0 or %edx,%eax
4c9: 88 41 46 mov %al,0x46(%ecx)
4cc: 80 8e 5b 01 00 00 10 orb $0x10,0x15b(%esi)
4d3: 66 c7 86 4c 01 00 00 movw $0xffff,0x14c(%esi)
4da: ff ff
4dc: c6 86 59 01 00 00 01 movb $0x1,0x159(%esi)
4e3: c7 86 5c 01 00 00 00 movl $0x0,0x15c(%esi)
4ea: 00 00 00
4ed: c7 86 64 01 00 00 00 movl $0x0,0x164(%esi)
4f4: 00 00 00
4f7: a1 04 00 00 00 mov 0x4,%eax
4f8: R_386_32 ipv4_config
4fc: 85 c0 test %eax,%eax
4fe: 0f b7 86 46 01 00 00 movzwl 0x146(%esi),%eax
505: 0f 94 86 5a 01 00 00 sete 0x15a(%esi)
50c: 66 85 c0 test %ax,%ax
50f: 0f 85 82 00 00 00 jne 597 <inet6_create+0x2a7>
515: 8b 46 20 mov 0x20(%esi),%eax
518: 31 ed xor %ebp,%ebp
51a: 8b 50 14 mov 0x14(%eax),%edx
51d: 85 d2 test %edx,%edx
51f: 0f 84 e4 fd ff ff je 309 <inet6_create+0x19>
525: 89 f0 mov %esi,%eax
527: ff d2 call *%edx
529: 85 c0 test %eax,%eax
52b: 89 c5 mov %eax,%ebp
52d: 0f 84 d6 fd ff ff je 309 <inet6_create+0x19>
533: 89 f0 mov %esi,%eax
535: e8 fc ff ff ff call 536 <inet6_create+0x246>
536: R_386_PC32 sk_common_release
53a: e9 ca fd ff ff jmp 309 <inet6_create+0x19>
53f: 90 nop
540: e8 fc ff ff ff call 541 <inet6_create+0x251>
541: R_386_PC32 build_ehash_secret
545: 8b 44 24 10 mov 0x10(%esp),%eax
549: 8b 70 20 mov 0x20(%eax),%esi
54c: e9 dc fd ff ff jmp 32d <inet6_create+0x3d>
551: bd a3 ff ff ff mov $0xffffffa3,%ebp
556: 83 7c 24 18 02 cmpl $0x2,0x18(%esp)
55b: 0f 84 a8 fd ff ff je 309 <inet6_create+0x19>
561: ff 44 24 18 incl 0x18(%esp)
565: 83 7c 24 18 01 cmpl $0x1,0x18(%esp)
56a: 74 64 je 5d0 <inet6_create+0x2e0>
56c: 89 7c 24 08 mov %edi,0x8(%esp)
570: c7 44 24 04 0a 00 00 movl $0xa,0x4(%esp)
577: 00
578: c7 04 24 1b 00 00 00 movl $0x1b,(%esp)
57b: R_386_32 .rodata.str1.1
57f: e8 fc ff ff ff call 580 <inet6_create+0x290>
580: R_386_PC32 request_module
584: 8b 44 24 10 mov 0x10(%esp),%eax
588: 8b 70 20 mov 0x20(%eax),%esi
58b: e9 a5 fd ff ff jmp 335 <inet6_create+0x45>
590: 89 cf mov %ecx,%edi
592: e9 0c fe ff ff jmp 3a3 <inet6_create+0xb3>
597: 8b 56 20 mov 0x20(%esi),%edx
59a: 66 c1 c0 08 rol $0x8,%ax
59e: 66 89 86 54 01 00 00 mov %ax,0x154(%esi)
5a5: 89 f0 mov %esi,%eax
5a7: ff 52 44 call *0x44(%edx)
5aa: e9 66 ff ff ff jmp 515 <inet6_create+0x225>
5af: 81 ff ff 00 00 00 cmp $0xff,%edi
5b5: 66 89 be 46 01 00 00 mov %di,0x146(%esi)
5bc: 0f 85 aa fe ff ff jne 46c <inet6_create+0x17c>
5c2: 83 ca 08 or $0x8,%edx
5c5: 88 96 5b 01 00 00 mov %dl,0x15b(%esi)
5cb: e9 9c fe ff ff jmp 46c <inet6_create+0x17c>
5d0: 0f bf c6 movswl %si,%eax
5d3: 89 7c 24 08 mov %edi,0x8(%esp)
5d7: c7 44 24 04 0a 00 00 movl $0xa,0x4(%esp)
5de: 00
5df: 89 44 24 0c mov %eax,0xc(%esp)
5e3: c7 04 24 00 00 00 00 movl $0x0,(%esp)
5e6: R_386_32 .rodata.str1.1
5ea: e8 fc ff ff ff call 5eb <inet6_create+0x2fb>
5eb: R_386_PC32 request_module
5ef: 8b 54 24 10 mov 0x10(%esp),%edx
5f3: 8b 72 20 mov 0x20(%edx),%esi
5f6: e9 3a fd ff ff jmp 335 <inet6_create+0x45>
5fb: c7 44 24 0c a2 00 00 movl $0xa2,0xc(%esp)
602: 00
603: c7 44 24 08 a0 00 00 movl $0xa0,0x8(%esp)
60a: 00
607: R_386_32 .rodata.str1.4
60b: c7 44 24 04 2e 00 00 movl $0x2e,0x4(%esp)
612: 00
60f: R_386_32 .rodata.str1.1
613: c7 04 24 e0 00 00 00 movl $0xe0,(%esp)
616: R_386_32 .rodata.str1.4
61a: e8 fc ff ff ff call 61b <inet6_create+0x32b>
61b: R_386_PC32 printk
61f: e9 c0 fd ff ff jmp 3e4 <inet6_create+0xf4>
624: 8d b6 00 00 00 00 lea 0x0(%esi),%esi
62a: 8d bf 00 00 00 00 lea 0x0(%edi),%edi
00000630 <inet6_destroy_sock>:
^ permalink raw reply
* Re: Endianness problem with u32 classifier hash masks
From: jamal @ 2007-11-06 14:43 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: Radu Rendec, netdev
In-Reply-To: <20071106142558.GC1666@ff.dom.local>
On Tue, 2007-06-11 at 15:25 +0100, Jarek Poplawski wrote:
> Yes, it saves one htonl() on the slow path!
Would it feel better to say grew down exponentially from version 1 to
3? ;->
> > Please give yourself a little pat on the back for me.
>
> Wait a minute! Don't forget to take a picture or something!
He needs the other arm for balance;-> so unless someone else takes the
photo, i would say that should he be successful taking the photo, that
achievement itself needs a double-self-pat-on-the-back (which i am going
to say if he can also take a photo of needs to go on some records book)
cheers,
jamal
^ permalink raw reply
* [PATCH] PCMCIA NET: Use roundup_pow_of_two() macro instead of grotesque loop.
From: Robert P. J. Day @ 2007-11-06 14:41 UTC (permalink / raw)
To: netdev; +Cc: Andrew Morton
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
---
i'm just going to assume that loop is rounding up to the next power
of two, right?
diff --git a/drivers/net/pcmcia/pcnet_cs.c b/drivers/net/pcmcia/pcnet_cs.c
index db6a97d..07eae16 100644
--- a/drivers/net/pcmcia/pcnet_cs.c
+++ b/drivers/net/pcmcia/pcnet_cs.c
@@ -38,6 +38,7 @@
#include <linux/delay.h>
#include <linux/ethtool.h>
#include <linux/netdevice.h>
+#include <linux/log2.h>
#include "../8390.h"
#include <pcmcia/cs_types.h>
@@ -1484,8 +1485,7 @@ static int setup_shmem_window(struct pcmcia_device *link, int start_pg,
window_size = 32 * 1024;
/* Make sure it's a power of two. */
- while ((window_size & (window_size - 1)) != 0)
- window_size += window_size & ~(window_size - 1);
+ window_size = roundup_pow_of_two(window_size);
/* Allocate a memory window */
req.Attributes = WIN_DATA_WIDTH_16|WIN_MEMORY_TYPE_CM|WIN_ENABLE;
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
========================================================================
^ permalink raw reply related
* Re: Endianness problem with u32 classifier hash masks
From: Jarek Poplawski @ 2007-11-06 14:25 UTC (permalink / raw)
To: jamal; +Cc: Radu Rendec, netdev
In-Reply-To: <1194356071.4444.23.camel@localhost>
On Tue, Nov 06, 2007 at 08:34:31AM -0500, jamal wrote:
> On Tue, 2007-06-11 at 10:09 +0200, Radu Rendec wrote:
>
> > Yup, you're right. Bitwise anding is the same regardless of the byte
> > ordering of the operands. As long as you don't have one operand in host
> > order and the other in net order, it's ok.
>
> Ok
>
> > However, Jarek's computations with his mask and your patch seemed
> > correct to me yesterday. And I think I know the answer: data must be
> > changed to host order _before_ shifting. I mean something like this:
> >
> > static __inline__ unsigned u32_hash_fold(u32 key, struct tc_u32_sel
> > *sel, u8 fshift)
> > {
> > unsigned h = ntohl(key & sel->hmask) >> fshift;
> > return h;
> > }
>
> Even better than what i suggested ;->
Yes, it saves one htonl() on the slow path!
>
> > > > On paper i get the same result with the new or old scheme for the bucket selection.
> > > > As i stated on the patch - i never did test the theory.
> >
> > Well, neither did I (about what I stated above). But still I think,
> > Jarek was right yesterday and I can't figure out how it worked for you
> > on paper. How about this new version?
>
> Looks good - we can think of optimizing later.
>
> > Well, I think it's pretty clear now: I'll try my version of Jamal's
> > patch :)
>
> Which derived from your original patch using little effort in comparison
> to yours. All the hardwork is yours.
> You did quiet an impressive debug work. Please give yourself a little
> pat on the back for me.
Wait a minute! Don't forget to take a picture or something!
>
> > But not right now, because I also have to show up at work.
>
> I empathize.
> Please send two patches instead of one. One for this and the next for
> the ffs conversion (please run some simple tests in both cases).
>
> Jarek,
> Heres a few more derivations of Canada for you:
>
> Legend has it that Canada's name is derived from
> "settlement" in Iroquoian (One the First Nations in present day Canada).
> I think it was pronounced "Kanata"
> An alternative legend says the early Spanish called it acánada meaning
> "nothing here"
>
> I tend to believe the Iroquoian version since to this day Canada
> continues to serve as a new settlement for many people. And the Spanish
> were totaly wrong - there is something here ;-> At least Tim Hortons
> coffee.
Nice stories! Thanks. Btw, with this Polish saying, the strangest thing
is US was always preferred as a settlment, after all.
Regards,
Jarek P.
^ permalink raw reply
* Re: Endianness problem with u32 classifier hash masks
From: jamal @ 2007-11-06 13:34 UTC (permalink / raw)
To: Radu Rendec; +Cc: Jarek Poplawski, netdev
In-Reply-To: <1194336542.3305.33.camel@rad.rendec.ines.ro>
On Tue, 2007-06-11 at 10:09 +0200, Radu Rendec wrote:
> Yup, you're right. Bitwise anding is the same regardless of the byte
> ordering of the operands. As long as you don't have one operand in host
> order and the other in net order, it's ok.
Ok
> However, Jarek's computations with his mask and your patch seemed
> correct to me yesterday. And I think I know the answer: data must be
> changed to host order _before_ shifting. I mean something like this:
>
> static __inline__ unsigned u32_hash_fold(u32 key, struct tc_u32_sel
> *sel, u8 fshift)
> {
> unsigned h = ntohl(key & sel->hmask) >> fshift;
> return h;
> }
Even better than what i suggested ;->
> > > On paper i get the same result with the new or old scheme for the bucket selection.
> > > As i stated on the patch - i never did test the theory.
>
> Well, neither did I (about what I stated above). But still I think,
> Jarek was right yesterday and I can't figure out how it worked for you
> on paper. How about this new version?
Looks good - we can think of optimizing later.
> Well, I think it's pretty clear now: I'll try my version of Jamal's
> patch :)
Which derived from your original patch using little effort in comparison
to yours. All the hardwork is yours.
You did quiet an impressive debug work. Please give yourself a little
pat on the back for me.
> But not right now, because I also have to show up at work.
I empathize.
Please send two patches instead of one. One for this and the next for
the ffs conversion (please run some simple tests in both cases).
Jarek,
Heres a few more derivations of Canada for you:
Legend has it that Canada's name is derived from
"settlement" in Iroquoian (One the First Nations in present day Canada).
I think it was pronounced "Kanata"
An alternative legend says the early Spanish called it acánada meaning
"nothing here"
I tend to believe the Iroquoian version since to this day Canada
continues to serve as a new settlement for many people. And the Spanish
were totaly wrong - there is something here ;-> At least Tim Hortons
coffee.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH -net 2/2] Put proc_net_create() on death row
From: Christoph Hellwig @ 2007-11-06 13:32 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: davem, linux-kernel, netdev, devel
In-Reply-To: <20071106122350.GB6215@localhost.sw.ru>
On Tue, Nov 06, 2007 at 03:23:50PM +0300, Alexey Dobriyan wrote:
> proc_net_create() stands on the way of shrinking the number of
> interfaces one can use for /proc files, namely, it uses ->get_info
> hook which will be converted, deprecated and deleted on its own
> schedule.
It's just a trivial helper, so please just remove it once you've
converted all users.
^ permalink raw reply
* Re: [PATCH -net 2/2] Put proc_net_create() on death row
From: David Miller @ 2007-11-06 13:28 UTC (permalink / raw)
To: adobriyan; +Cc: linux-kernel, netdev, devel
In-Reply-To: <20071106122350.GB6215@localhost.sw.ru>
From: Alexey Dobriyan <adobriyan@sw.ru>
Date: Tue, 6 Nov 2007 15:23:50 +0300
> proc_net_create() stands on the way of shrinking the number of
> interfaces one can use for /proc files, namely, it uses ->get_info
> hook which will be converted, deprecated and deleted on its own
> schedule.
>
> Signed-off-by: Alexey Dobriyan <adobriyan@sw.ru>
Applied.
^ permalink raw reply
* Re: [PATCH -net 1/2] Convert /proc/net/ipv6_route to seq_file interface
From: David Miller @ 2007-11-06 13:27 UTC (permalink / raw)
To: adobriyan; +Cc: netdev, devel
In-Reply-To: <20071106122150.GA6215@localhost.sw.ru>
From: Alexey Dobriyan <adobriyan@sw.ru>
Date: Tue, 6 Nov 2007 15:21:50 +0300
> This removes last proc_net_create() user. Kudos to Benjamin Thery and
> Stephen Hemminger for comments on previous version.
>
> Signed-off-by: Alexey Dobriyan <adobriyan@sw.ru>
Applied.
^ permalink raw reply
* [PATCH -net 2/2] Put proc_net_create() on death row
From: Alexey Dobriyan @ 2007-11-06 12:23 UTC (permalink / raw)
To: davem; +Cc: linux-kernel, netdev, devel
proc_net_create() stands on the way of shrinking the number of
interfaces one can use for /proc files, namely, it uses ->get_info
hook which will be converted, deprecated and deleted on its own
schedule.
Signed-off-by: Alexey Dobriyan <adobriyan@sw.ru>
---
Documentation/feature-removal-schedule.txt | 9 +++++++++
include/linux/proc_fs.h | 8 ++++++--
2 files changed, 15 insertions(+), 2 deletions(-)
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -130,6 +130,15 @@ Who: Christoph Hellwig <hch@lst.de>
---------------------------
+What: proc_net_create()
+When: 2.6.25
+Why: proc_net_create() stands on the way of shrinking the number of
+ interfaces one can use for /proc files, namely, it uses ->get_info
+ hook which will be deleted later.
+Who: Alexey Dobriyan <adobriyan@gmail.com>
+
+---------------------------
+
What: CONFIG_FORCED_INLINING
When: June 2006
Why: Config option is there to see if gcc is good enough. (in january
--- a/include/linux/proc_fs.h
+++ b/include/linux/proc_fs.h
@@ -196,7 +196,7 @@ static inline struct proc_dir_entry *create_proc_info_entry(const char *name,
return res;
}
-extern struct proc_dir_entry *proc_net_create(struct net *net,
+extern __deprecated struct proc_dir_entry *proc_net_create(struct net *net,
const char *name, mode_t mode, get_info_t *get_info);
extern struct proc_dir_entry *proc_net_fops_create(struct net *net,
const char *name, mode_t mode, const struct file_operations *fops);
@@ -208,7 +208,11 @@ extern void proc_net_remove(struct net *net, const char *name);
#define proc_bus NULL
#define proc_net_fops_create(net, name, mode, fops) ({ (void)(mode), NULL; })
-#define proc_net_create(net, name, mode, info) ({ (void)(mode), NULL; })
+static inline __deprecated struct proc_dir_entry *proc_net_create(
+ struct net *net, const char *name, mode_t mode, get_info_t *get_info)
+{
+ return NULL;
+}
static inline void proc_net_remove(struct net *net, const char *name) {}
static inline void proc_flush_task(struct task_struct *task)
^ permalink raw reply
* [PATCH -net 1/2] Convert /proc/net/ipv6_route to seq_file interface
From: Alexey Dobriyan @ 2007-11-06 12:21 UTC (permalink / raw)
To: davem; +Cc: netdev, devel
This removes last proc_net_create() user. Kudos to Benjamin Thery and
Stephen Hemminger for comments on previous version.
Signed-off-by: Alexey Dobriyan <adobriyan@sw.ru>
---
net/ipv6/route.c | 91 +++++++++++++++++--------------------------------------
1 file changed, 29 insertions(+), 62 deletions(-)
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -38,12 +38,8 @@
#include <linux/in6.h>
#include <linux/init.h>
#include <linux/if_arp.h>
-
-#ifdef CONFIG_PROC_FS
#include <linux/proc_fs.h>
#include <linux/seq_file.h>
-#endif
-
#include <net/net_namespace.h>
#include <net/snmp.h>
#include <net/ipv6.h>
@@ -2288,71 +2284,50 @@ struct rt6_proc_arg
static int rt6_info_route(struct rt6_info *rt, void *p_arg)
{
- struct rt6_proc_arg *arg = (struct rt6_proc_arg *) p_arg;
+ struct seq_file *m = p_arg;
- if (arg->skip < arg->offset / RT6_INFO_LEN) {
- arg->skip++;
- return 0;
- }
-
- if (arg->len >= arg->length)
- return 0;
-
- arg->len += sprintf(arg->buffer + arg->len,
- NIP6_SEQFMT " %02x ",
- NIP6(rt->rt6i_dst.addr),
- rt->rt6i_dst.plen);
+ seq_printf(m, NIP6_SEQFMT " %02x ", NIP6(rt->rt6i_dst.addr),
+ rt->rt6i_dst.plen);
#ifdef CONFIG_IPV6_SUBTREES
- arg->len += sprintf(arg->buffer + arg->len,
- NIP6_SEQFMT " %02x ",
- NIP6(rt->rt6i_src.addr),
- rt->rt6i_src.plen);
+ seq_printf(m, NIP6_SEQFMT " %02x ", NIP6(rt->rt6i_src.addr),
+ rt->rt6i_src.plen);
#else
- arg->len += sprintf(arg->buffer + arg->len,
- "00000000000000000000000000000000 00 ");
+ seq_puts(m, "00000000000000000000000000000000 00 ");
#endif
if (rt->rt6i_nexthop) {
- arg->len += sprintf(arg->buffer + arg->len,
- NIP6_SEQFMT,
- NIP6(*((struct in6_addr *)rt->rt6i_nexthop->primary_key)));
+ seq_printf(m, NIP6_SEQFMT,
+ NIP6(*((struct in6_addr *)rt->rt6i_nexthop->primary_key)));
} else {
- arg->len += sprintf(arg->buffer + arg->len,
- "00000000000000000000000000000000");
+ seq_puts(m, "00000000000000000000000000000000");
}
- arg->len += sprintf(arg->buffer + arg->len,
- " %08x %08x %08x %08x %8s\n",
- rt->rt6i_metric, atomic_read(&rt->u.dst.__refcnt),
- rt->u.dst.__use, rt->rt6i_flags,
- rt->rt6i_dev ? rt->rt6i_dev->name : "");
+ seq_printf(m, " %08x %08x %08x %08x %8s\n",
+ rt->rt6i_metric, atomic_read(&rt->u.dst.__refcnt),
+ rt->u.dst.__use, rt->rt6i_flags,
+ rt->rt6i_dev ? rt->rt6i_dev->name : "");
return 0;
}
-static int rt6_proc_info(char *buffer, char **start, off_t offset, int length)
+static int ipv6_route_show(struct seq_file *m, void *v)
{
- struct rt6_proc_arg arg = {
- .buffer = buffer,
- .offset = offset,
- .length = length,
- };
-
- fib6_clean_all(rt6_info_route, 0, &arg);
-
- *start = buffer;
- if (offset)
- *start += offset % RT6_INFO_LEN;
-
- arg.len -= offset % RT6_INFO_LEN;
-
- if (arg.len > length)
- arg.len = length;
- if (arg.len < 0)
- arg.len = 0;
+ fib6_clean_all(rt6_info_route, 0, m);
+ return 0;
+}
- return arg.len;
+static int ipv6_route_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, ipv6_route_show, NULL);
}
+static const struct file_operations ipv6_route_proc_fops = {
+ .owner = THIS_MODULE,
+ .open = ipv6_route_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+};
+
static int rt6_stats_seq_show(struct seq_file *seq, void *v)
{
seq_printf(seq, "%04x %04x %04x %04x %04x %04x %04x\n",
@@ -2489,22 +2464,14 @@ ctl_table ipv6_route_table[] = {
void __init ip6_route_init(void)
{
-#ifdef CONFIG_PROC_FS
- struct proc_dir_entry *p;
-#endif
ip6_dst_ops.kmem_cachep =
kmem_cache_create("ip6_dst_cache", sizeof(struct rt6_info), 0,
SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL);
ip6_dst_blackhole_ops.kmem_cachep = ip6_dst_ops.kmem_cachep;
fib6_init();
-#ifdef CONFIG_PROC_FS
- p = proc_net_create(&init_net, "ipv6_route", 0, rt6_proc_info);
- if (p)
- p->owner = THIS_MODULE;
-
+ proc_net_fops_create(&init_net, "ipv6_route", 0, &ipv6_route_proc_fops);
proc_net_fops_create(&init_net, "rt6_stats", S_IRUGO, &rt6_stats_seq_fops);
-#endif
#ifdef CONFIG_XFRM
xfrm6_init();
#endif
^ permalink raw reply
* Re: kernel panic removing devices from a teql queuing discipline
From: David Miller @ 2007-11-06 11:08 UTC (permalink / raw)
To: johnpol; +Cc: cebbert, netdev
In-Reply-To: <20071106104855.GA32033@2ka.mipt.ru>
From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Date: Tue, 6 Nov 2007 13:48:55 +0300
> Tested, works, fixed.
>
> Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Applied, thanks a lot Evgeniy!
I'll queue this up for -stable too.
^ permalink raw reply
* Re: localhost network processing on smp machines
From: Andi Kleen @ 2007-11-06 10:53 UTC (permalink / raw)
To: Matthew Faulkner; +Cc: netdev
In-Reply-To: <c565abbb0711051248g76fbd695w2dbb13f0e014087d@mail.gmail.com>
"Matthew Faulkner" <matthew.faulkner@gmail.com> writes:
> I'm probably being stupid and very confused here. Appologies if it is
> a stupid question.
>
> For a particular test I assign a client to core 1 and a server to core
> 0. My first assumption was all the sending side kernel TCP/IP
> processing will be done on core 1 and all the receiving side
> processing on core 0. However, having looked at the linux TCP/IP code,
> more specifically the loopback device code, when the loopbacks
> dev_queue_xmit function gets called it simply passes the skb to the
> netif_rx function. Therefore my question is thus, when i assign the
> sending / receiving side to different cores is the actual TCP/IP
> processing done the assigned sending / receiving cores ? or is TCP/IP
> processing done on the sending side only until a certain point?
> it simply a single core that does all the TCP/IP processing. If it's
> the first two and you have any idea, could you point me where in the
> kernel the cores the processing swap over.
You need to define what you mean with TCP/IP processing. It has lots
of little sub-actions. For the loopback case some will always run on
the sender side (IP, socket demultiplex, some will sometimes run on
either depending on workload (using TCP prequeue and depending on the
tcp_latency setting and how quickly the receiver schedules), and some
always on the receiver side (recvmsg user processing)
-Andi
^ permalink raw reply
* Re: kernel panic removing devices from a teql queuing discipline
From: Evgeniy Polyakov @ 2007-11-06 10:48 UTC (permalink / raw)
To: David Miller; +Cc: cebbert, netdev
In-Reply-To: <20071105200800.GA4075@2ka.mipt.ru>
On Mon, Nov 05, 2007 at 11:08:00PM +0300, Evgeniy Polyakov (johnpol@2ka.mipt.ru) wrote:
> On Tue, Oct 30, 2007 at 01:33:41AM -0700, David Miller (davem@davemloft.net) wrote:
> > > The panic is in __teql_resolve (which has been inlined into teql_master_xmit) in
> > > net/sched/sch_teql.c at this line:
> > >
> > > if (n && n->tbl == mn->tbl &&
> > >
> > > Specifically the dereference of n->tbl is faulting as n is not valid.
>
> n is never valid (null), mn is garbage.
My fault, of course you are right, n is invalid because it is
dereferenced from qdisc, which was changed. That was too late in Moscow
for conclusions...
> > > And the address looks like part of an ASCCI string... "figt"
> >
> > I studied sch_teql.c a bit and I suspect that the slave list
> > management in teql_destroy() and teql_qdisc_init() might be
> > suspect.
>
> tecl_reset() is called from deactivate and qdisc is set to noop already,
> but subsequent teql_xmit does not know about it and dereference private
> data as teql qdisc and thus oopses. I will fix it tomorrow if you will
> not catch it first :)
It looks like I am.
Tested, works, fixed.
Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
diff --git a/net/sched/sch_teql.c b/net/sched/sch_teql.c
index f05ad9a..e0a44b9 100644
--- a/net/sched/sch_teql.c
+++ b/net/sched/sch_teql.c
@@ -263,6 +276,9 @@ __teql_resolve(struct sk_buff *skb, struct sk_buff *skb_res, struct net_device *
static __inline__ int
teql_resolve(struct sk_buff *skb, struct sk_buff *skb_res, struct net_device *dev)
{
+ if (dev->qdisc == &noop_qdisc)
+ return -ENODEV;
+
if (dev->hard_header == NULL ||
skb->dst == NULL ||
skb->dst->neighbour == NULL)
--
Evgeniy Polyakov
^ permalink raw reply related
* [PATCH] [NETFILTER] Consolidate nf_sockopt and compat_nf_sockopt v2
From: Pavel Emelyanov @ 2007-11-06 8:29 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Linux Netdev List, devel
Both lookup the nf_sockopt_ops object to call the get/set callbacks
from, but they perform it in a completely similar way.
Introduce the helper for finding the ops.
Ported at the top of today's net-2.6 tree to resolve conflict
with the patch from Alexey Dobriyan.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
diff --git a/net/netfilter/nf_sockopt.c b/net/netfilter/nf_sockopt.c
index 2dfac32..87bc144 100644
--- a/net/netfilter/nf_sockopt.c
+++ b/net/netfilter/nf_sockopt.c
@@ -60,46 +60,57 @@ void nf_unregister_sockopt(struct nf_sockopt_ops *reg)
}
EXPORT_SYMBOL(nf_unregister_sockopt);
-/* Call get/setsockopt() */
-static int nf_sockopt(struct sock *sk, int pf, int val,
- char __user *opt, int *len, int get)
+static struct nf_sockopt_ops *nf_sockopt_find(struct sock *sk, int pf,
+ int val, int get)
{
struct nf_sockopt_ops *ops;
- int ret;
if (sk->sk_net != &init_net)
- return -ENOPROTOOPT;
+ return ERR_PTR(-ENOPROTOOPT);
if (mutex_lock_interruptible(&nf_sockopt_mutex) != 0)
- return -EINTR;
+ return ERR_PTR(-EINTR);
list_for_each_entry(ops, &nf_sockopts, list) {
if (ops->pf == pf) {
if (!try_module_get(ops->owner))
goto out_nosup;
+
if (get) {
- if (val >= ops->get_optmin
- && val < ops->get_optmax) {
- mutex_unlock(&nf_sockopt_mutex);
- ret = ops->get(sk, val, opt, len);
+ if (val >= ops->get_optmin &&
+ val < ops->get_optmax)
goto out;
- }
} else {
- if (val >= ops->set_optmin
- && val < ops->set_optmax) {
- mutex_unlock(&nf_sockopt_mutex);
- ret = ops->set(sk, val, opt, *len);
+ if (val >= ops->set_optmin &&
+ val < ops->set_optmax)
goto out;
- }
}
module_put(ops->owner);
}
}
- out_nosup:
+out_nosup:
+ ops = ERR_PTR(-ENOPROTOOPT);
+out:
mutex_unlock(&nf_sockopt_mutex);
- return -ENOPROTOOPT;
+ return ops;
+}
+
+/* Call get/setsockopt() */
+static int nf_sockopt(struct sock *sk, int pf, int val,
+ char __user *opt, int *len, int get)
+{
+ struct nf_sockopt_ops *ops;
+ int ret;
+
+ ops = nf_sockopt_find(sk, pf, val, get);
+ if (IS_ERR(ops))
+ return PTR_ERR(ops);
+
+ if (get)
+ ret = ops->get(sk, val, opt, len);
+ else
+ ret = ops->set(sk, val, opt, *len);
- out:
module_put(ops->owner);
return ret;
}
@@ -124,51 +135,22 @@ static int compat_nf_sockopt(struct sock *sk, int pf, int val,
struct nf_sockopt_ops *ops;
int ret;
- if (sk->sk_net != &init_net)
- return -ENOPROTOOPT;
-
-
- if (mutex_lock_interruptible(&nf_sockopt_mutex) != 0)
- return -EINTR;
-
- list_for_each_entry(ops, &nf_sockopts, list) {
- if (ops->pf == pf) {
- if (!try_module_get(ops->owner))
- goto out_nosup;
-
- if (get) {
- if (val >= ops->get_optmin
- && val < ops->get_optmax) {
- mutex_unlock(&nf_sockopt_mutex);
- if (ops->compat_get)
- ret = ops->compat_get(sk,
- val, opt, len);
- else
- ret = ops->get(sk,
- val, opt, len);
- goto out;
- }
- } else {
- if (val >= ops->set_optmin
- && val < ops->set_optmax) {
- mutex_unlock(&nf_sockopt_mutex);
- if (ops->compat_set)
- ret = ops->compat_set(sk,
- val, opt, *len);
- else
- ret = ops->set(sk,
- val, opt, *len);
- goto out;
- }
- }
- module_put(ops->owner);
- }
+ ops = nf_sockopt_find(sk, pf, val, get);
+ if (IS_ERR(ops))
+ return PTR_ERR(ops);
+
+ if (get) {
+ if (ops->compat_get)
+ ret = ops->compat_get(sk, val, opt, len);
+ else
+ ret = ops->get(sk, val, ops, len);
+ } else {
+ if (ops->compat_set)
+ ret = ops->compat_set(sk, val, ops, *len);
+ else
+ ret = ops->set(sk, val, ops, *len);
}
- out_nosup:
- mutex_unlock(&nf_sockopt_mutex);
- return -ENOPROTOOPT;
- out:
module_put(ops->owner);
return ret;
}
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox