* Re: From: Carlos Mart??n <carlos@cmartin.tk>
From: Carlos Martín @ 2006-02-22 15:06 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: netdev, acx100-devel
In-Reply-To: <20060222143604.GA16269@infradead.org>
On Wednesday 22 February 2006 15:36, Christoph Hellwig wrote:
> On Tue, Feb 21, 2006 at 10:03:58PM +0100, Carlos Mart?n wrote:
> > > The important bit is that you need the pointers with the above module
> > > spit, because you can't call usb- or pci-specific routines from
> > > acx-common.ko
> >
> > Yes, I realise that (unless you export them, but I don't think we want
that).
>
> even that wouldn't work with current module because the usb and pci modules
> call into the common code and thus we'd have recursive module depency.
And you may not build both modules, so acx-common.ko would never be satisfied.
Function pointers all the way then.
>
> > This approach is probably better even if the driver is unified. Pointer
> > dereferences are cheaper than branches/jumping, aren't they?
>
> It shouldn't matter these days as cpus have nice branch prediction.
I remember reading P4s have problems with this because they had really long
branch pipes (the proper name escapes me at the moment) and if they got it
wrong, it took quite a bit of time (in CPU terms, of course) to flush them. I
don't use them personally, but I believe the trend is to do that.
cmn
--
Carlos Martín Nieto | http://www.cmartin.tk
Hobbyist programmer |
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
^ permalink raw reply
* Re: From: Carlos Mart??n <carlos@cmartin.tk>
From: Christoph Hellwig @ 2006-02-22 14:36 UTC (permalink / raw)
To: Carlos Mart?n; +Cc: netdev, acx100-devel
In-Reply-To: <200602212203.58216.carlos@cmartin.tk>
On Tue, Feb 21, 2006 at 10:03:58PM +0100, Carlos Mart?n wrote:
> > The important bit is that you need the pointers with the above module
> > spit, because you can't call usb- or pci-specific routines from
> > acx-common.ko
>
> Yes, I realise that (unless you export them, but I don't think we want that).
even that wouldn't work with current module because the usb and pci modules
call into the common code and thus we'd have recursive module depency.
> This approach is probably better even if the driver is unified. Pointer
> dereferences are cheaper than branches/jumping, aren't they?
It shouldn't matter these days as cpus have nice branch prediction.
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
^ permalink raw reply
* Re: [PATCH] tg3: netif_carrier_off runs too early; could still be queued when init fails
From: David S. Miller @ 2006-02-22 0:35 UTC (permalink / raw)
To: mchan; +Cc: jeffm, akpm, torvalds, linux-kernel, jgarzik, netdev
In-Reply-To: <1140559048.20584.20.camel@rh4>
From: "Michael Chan" <mchan@broadcom.com>
Date: Tue, 21 Feb 2006 13:57:28 -0800
> On Tue, 2006-02-21 at 17:41 -0500, Jeff Mahoney wrote:
>
> > dmesg after modprobe tg3:
> > tg3.c:v3.49 (Feb 2, 2006)
> > ACPI: PCI Interrupt 0000:0a:02.0[A] -> GSI 24 (level, low) -> IRQ 201
> > Uhhuh. NMI received for unknown reason 21 on CPU 0.
> > Dazed and confused, but trying to continue
> > Do you have a strange power saving mode enabled?
> > tg3_test_dma() Write the buffer failed -19
> > tg3: DMA engine test failed, aborting.
>
> You're getting an NMI during tg3_init_one() which means that the NIC is
> probably bad. I did a quick test on the same version of the 5701 NIC
> with the same tg3 driver and it worked fine.
>
> Please find out if the NIC is known to be bad. Thanks.
I wonder if this is how this platform informs the cpu of master-abort
or target-abort cycles? It could maybe also be an IRQ routing
problem...
^ permalink raw reply
* Re: [PATCH] tg3: netif_carrier_off runs too early; could still be queued when init fails
From: Jeff Mahoney @ 2006-02-21 22:41 UTC (permalink / raw)
To: David S. Miller; +Cc: mchan, akpm, torvalds, linux-kernel, jgarzik, netdev
In-Reply-To: <20060221.133947.05470613.davem@davemloft.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
David S. Miller wrote:
> From: "Michael Chan" <mchan@broadcom.com>
> Date: Tue, 21 Feb 2006 08:44:20 -0800
>
>> On Mon, 2006-02-20 at 14:43 -0500, Jeff Mahoney wrote:
>>> This patch moves the netif_carrier_off() call from tg3_init_one()->
>>> tg3_init_link_config() to tg3_open() as is the convention for most
>>> other network drivers.
>> I think moving netif_carrier_off() later is the right thing to do. We
>> can also move it to the end of tg3_init_one() just before returning 0.
>
> Agreed.
>
>>> I was getting a panic after a tg3 device failed to initialize due to DMA
>>> failure. The oops pointed to the link watch queue with spinlock debugging
>>> enabled. Without spinlock debugging, the Oops didn't occur.
>>>
>>> I suspect that the link event was getting queued but not executed until
>>> after the DMA test had failed and the device was freed. The link event
>>> was then operating on freed memory, which could contain anything. With this
>>> patch applied, the Oops no longer occurs.
>> DMA test failed? What NIC device do you have? How did it fail?
>
> I get this too with an old 5700 3COM card on sparc64. I'll get
> you some more detailed info later today, hopefully.
>
> Jeff, please get some details for Michael about your failure
> case. Thanks.
dmesg after modprobe tg3:
tg3.c:v3.49 (Feb 2, 2006)
ACPI: PCI Interrupt 0000:0a:02.0[A] -> GSI 24 (level, low) -> IRQ 201
Uhhuh. NMI received for unknown reason 21 on CPU 0.
Dazed and confused, but trying to continue
Do you have a strange power saving mode enabled?
tg3_test_dma() Write the buffer failed -19
tg3: DMA engine test failed, aborting.
relevant lspci output:
0000:0a:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5701
Gigabit Ethernet (rev 15)
Subsystem: Compaq Computer Corporation NC7770 Gigabit Server
Adapter (PCI-X, 10/100/1000-T)
Flags: 66Mhz, medium devsel, IRQ 201
Memory at f7df0000 (64-bit, non-prefetchable) [size=64K]
Expansion ROM at dc080000 [disabled] [size=64K]
Capabilities: [40] PCI-X non-bridge device.
Capabilities: [48] Power Management version 2
Capabilities: [50] Vital Product Data
Capabilities: [58] Message Signalled Interrupts: 64bit+
Queue=0/3 Enable-
If you need more details, I can try to dig them up. This is a machine
I've only been using for a few days for some testing and I'm not yet
familiar with all the hardware details.
- -Jeff
- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFD+5cXLPWxlyuTD7IRArVcAJ4nEwx2b1j50dJp1uLBbqKJp9UlGwCfbE9N
P9iCdmB7IvGXDsuxTyjRj5M=
=5QzB
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] tg3: netif_carrier_off runs too early; could still be queued when init fails
From: Michael Chan @ 2006-02-21 21:57 UTC (permalink / raw)
To: Jeff Mahoney
Cc: David S. Miller, akpm, torvalds, linux-kernel, jgarzik, netdev
In-Reply-To: <43FB9718.4050606@suse.com>
On Tue, 2006-02-21 at 17:41 -0500, Jeff Mahoney wrote:
>
> dmesg after modprobe tg3:
> tg3.c:v3.49 (Feb 2, 2006)
> ACPI: PCI Interrupt 0000:0a:02.0[A] -> GSI 24 (level, low) -> IRQ 201
> Uhhuh. NMI received for unknown reason 21 on CPU 0.
> Dazed and confused, but trying to continue
> Do you have a strange power saving mode enabled?
> tg3_test_dma() Write the buffer failed -19
> tg3: DMA engine test failed, aborting.
>
You're getting an NMI during tg3_init_one() which means that the NIC is
probably bad. I did a quick test on the same version of the 5701 NIC
with the same tg3 driver and it worked fine.
Please find out if the NIC is known to be bad. Thanks.
^ permalink raw reply
* Re: [PATCH] tg3: netif_carrier_off runs too early; could still be queued when init fails
From: David S. Miller @ 2006-02-21 21:39 UTC (permalink / raw)
To: mchan; +Cc: jeffm, akpm, torvalds, linux-kernel, jgarzik, netdev
In-Reply-To: <1140540260.20584.6.camel@rh4>
From: "Michael Chan" <mchan@broadcom.com>
Date: Tue, 21 Feb 2006 08:44:20 -0800
> On Mon, 2006-02-20 at 14:43 -0500, Jeff Mahoney wrote:
> > This patch moves the netif_carrier_off() call from tg3_init_one()->
> > tg3_init_link_config() to tg3_open() as is the convention for most
> > other network drivers.
>
> I think moving netif_carrier_off() later is the right thing to do. We
> can also move it to the end of tg3_init_one() just before returning 0.
Agreed.
> > I was getting a panic after a tg3 device failed to initialize due to DMA
> > failure. The oops pointed to the link watch queue with spinlock debugging
> > enabled. Without spinlock debugging, the Oops didn't occur.
> >
> > I suspect that the link event was getting queued but not executed until
> > after the DMA test had failed and the device was freed. The link event
> > was then operating on freed memory, which could contain anything. With this
> > patch applied, the Oops no longer occurs.
>
> DMA test failed? What NIC device do you have? How did it fail?
I get this too with an old 5700 3COM card on sparc64. I'll get
you some more detailed info later today, hopefully.
Jeff, please get some details for Michael about your failure
case. Thanks.
^ permalink raw reply
* Re: From: Carlos Mart??n <carlos@cmartin.tk>
From: Carlos Martín @ 2006-02-21 21:03 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: netdev, acx100-devel
In-Reply-To: <20060221203211.GA29627@infradead.org>
On Tuesday 21 February 2006 21:32, Christoph Hellwig wrote:
> On Tue, Feb 21, 2006 at 09:24:23PM +0100, Carlos Mart?n wrote:
> > Wouldn't this lead to duplicated function definitions at link time if both
are
> > compiled-in? From your module split above I understood you wanted
acx-common
> > to be another module, but here I see it goes into the modules.
> >
>
> No. The above makefile fragment builds three modules: acx-common.o,
> acx-pci.o and acx-usb.o as mentioned above. The magic here is that with
> that makefile fragment is that the kbuild systems builds acx-common.o if
> either CONFIG_ACX_PCI or CONFIG_ACX_USB is set, and even makes sure to
> do the right thing if either is builtin. There is not code duplication
> at all.
Then all is good.
>
> > > ---- snip ----
> > >
> > > - kill the IS_PCI/IS_USB macros and add a acx_operations structure that
> > > handles the different hardware without branches all over and allows
> > > the hw-specific code to be in separate modules.
> >
> > There aren't that many IS_{PCI,USB} uses and most if not all are justified
> > (extra step for one case). It might be a good idea to do that for the
> > IS_ACX{100,111} macros instead of calling the generic function which then
> > calls the chip-specific one.
>
> The important bit is that you need the pointers with the above module
> spit, because you can't call usb- or pci-specific routines from
> acx-common.ko
Yes, I realise that (unless you export them, but I don't think we want that).
I've started this, but I think it'll probably be next week before I have time
to really work on it.
This approach is probably better even if the driver is unified. Pointer
dereferences are cheaper than branches/jumping, aren't they?
cmn
--
Carlos Martín Nieto | http://www.cmartin.tk
Hobbyist programmer |
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
^ permalink raw reply
* Re: From: Carlos Mart??n <carlos@cmartin.tk>
From: Christoph Hellwig @ 2006-02-21 20:32 UTC (permalink / raw)
To: Carlos Mart?n; +Cc: Christoph Hellwig, netdev, acx100-devel
In-Reply-To: <200602212124.23572.carlos@cmartin.tk>
On Tue, Feb 21, 2006 at 09:24:23PM +0100, Carlos Mart?n wrote:
> > acx-common-y += wlan.o conv.o ioctl.o common.o
> > acx-pci-y += pci.o
> > acx-usb-y += usb.o
> >
> > obj-$(CONFIG_ACX_PCI) += acx-common.o acx-pci.o
> > obj-$(CONFIG_ACX_USB) += acx-common.o acx-usb.o
>
> This is how we had it before, which leads to having a lot of the same code on
> both modules. The unified driver is not much larger so it was made this way,
> and that's where all the problem comes from.
> Wouldn't this lead to duplicated function definitions at link time if both are
> compiled-in? From your module split above I understood you wanted acx-common
> to be another module, but here I see it goes into the modules.
>
No. The above makefile fragment builds three modules: acx-common.o,
acx-pci.o and acx-usb.o as mentioned above. The magic here is that with
that makefile fragment is that the kbuild systems builds acx-common.o if
either CONFIG_ACX_PCI or CONFIG_ACX_USB is set, and even makes sure to
do the right thing if either is builtin. There is not code duplication
at all.
> > ---- snip ----
> >
> > - kill the IS_PCI/IS_USB macros and add a acx_operations structure that
> > handles the different hardware without branches all over and allows
> > the hw-specific code to be in separate modules.
>
> There aren't that many IS_{PCI,USB} uses and most if not all are justified
> (extra step for one case). It might be a good idea to do that for the
> IS_ACX{100,111} macros instead of calling the generic function which then
> calls the chip-specific one.
The important bit is that you need the pointers with the above module
spit, because you can't call usb- or pci-specific routines from acx-common.ko
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
^ permalink raw reply
* Re: From: Carlos Mart??n <carlos@cmartin.tk>
From: Carlos Martín @ 2006-02-21 20:24 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: netdev, acx100-devel
In-Reply-To: <20060221192601.GA28560@infradead.org>
On Tuesday 21 February 2006 20:26, Christoph Hellwig wrote:
> On Sat, Feb 18, 2006 at 11:35:21PM +0100, Carlos Martin wrote:
> > [PATCH] acxsm: Fix Kconfig option check
> >
> > This check never actually worked because CONFIG_ACX_{ACX,USB} are
> > tristate. With Adrian Bunk's patch to the Kconfig, this works with the
> > _BOOL hidden Kconfig options.
> > Also update error message adding that this shouldn't happen anymore.
>
> All the fixes discussed so far are not very nice at all. The right
> fix is the following:
>
>
> - split the module into three:
> acx-common.ko
> acx-pci.ko
> acx-usb.ko
I don't really like this method. It's not for any real reason though, so I'll
go with it if people want it. I've used this for the rt2x00 driver by loading
it manually, which was really annoying, but I suppose when it's properly
installed it works well.
>
> - make CONFIG_ACX_PCI and CONFIG_ACX_USB user-visible tristate
> varibles in the Kconfig.
> - build acx-common.ko when either of those is selected, with the
> following makefile:
>
> ---- snip ----
> acx-common-y += wlan.o conv.o ioctl.o common.o
> acx-pci-y += pci.o
> acx-usb-y += usb.o
>
> obj-$(CONFIG_ACX_PCI) += acx-common.o acx-pci.o
> obj-$(CONFIG_ACX_USB) += acx-common.o acx-usb.o
This is how we had it before, which leads to having a lot of the same code on
both modules. The unified driver is not much larger so it was made this way,
and that's where all the problem comes from.
Wouldn't this lead to duplicated function definitions at link time if both are
compiled-in? From your module split above I understood you wanted acx-common
to be another module, but here I see it goes into the modules.
> ---- snip ----
>
> - kill the IS_PCI/IS_USB macros and add a acx_operations structure that
> handles the different hardware without branches all over and allows
> the hw-specific code to be in separate modules.
There aren't that many IS_{PCI,USB} uses and most if not all are justified
(extra step for one case). It might be a good idea to do that for the
IS_ACX{100,111} macros instead of calling the generic function which then
calls the chip-specific one.
cmn
--
Carlos Martín Nieto | http://www.cmartin.tk
Hobbyist programmer |
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
^ permalink raw reply
* Re: From: Carlos Mart??n <carlos@cmartin.tk>
From: Christoph Hellwig @ 2006-02-21 19:26 UTC (permalink / raw)
To: Carlos Martin; +Cc: netdev, acx100-devel
In-Reply-To: <11403021213131-git-send-email-carlos@cmartin.tk>
On Sat, Feb 18, 2006 at 11:35:21PM +0100, Carlos Martin wrote:
> [PATCH] acxsm: Fix Kconfig option check
>
> This check never actually worked because CONFIG_ACX_{ACX,USB} are
> tristate. With Adrian Bunk's patch to the Kconfig, this works with the
> _BOOL hidden Kconfig options.
> Also update error message adding that this shouldn't happen anymore.
All the fixes discussed so far are not very nice at all. The right
fix is the following:
- split the module into three:
acx-common.ko
acx-pci.ko
acx-usb.ko
- make CONFIG_ACX_PCI and CONFIG_ACX_USB user-visible tristate
varibles in the Kconfig.
- build acx-common.ko when either of those is selected, with the
following makefile:
---- snip ----
acx-common-y += wlan.o conv.o ioctl.o common.o
acx-pci-y += pci.o
acx-usb-y += usb.o
obj-$(CONFIG_ACX_PCI) += acx-common.o acx-pci.o
obj-$(CONFIG_ACX_USB) += acx-common.o acx-usb.o
---- snip ----
- kill the IS_PCI/IS_USB macros and add a acx_operations structure that
handles the different hardware without branches all over and allows
the hw-specific code to be in separate modules.
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
^ permalink raw reply
* Re: [PATCH] tg3: netif_carrier_off runs too early; could still be queued when init fails
From: Michael Chan @ 2006-02-21 16:44 UTC (permalink / raw)
To: Jeff Mahoney
Cc: Andrew Morton, Linus Torvalds, Linux Kernel Mailing List,
Jeff Garzik, netdev
In-Reply-To: <20060220194337.GA21719@locomotive.unixthugs.org>
On Mon, 2006-02-20 at 14:43 -0500, Jeff Mahoney wrote:
> This patch moves the netif_carrier_off() call from tg3_init_one()->
> tg3_init_link_config() to tg3_open() as is the convention for most
> other network drivers.
I think moving netif_carrier_off() later is the right thing to do. We
can also move it to the end of tg3_init_one() just before returning 0.
>
> I was getting a panic after a tg3 device failed to initialize due to DMA
> failure. The oops pointed to the link watch queue with spinlock debugging
> enabled. Without spinlock debugging, the Oops didn't occur.
>
> I suspect that the link event was getting queued but not executed until
> after the DMA test had failed and the device was freed. The link event
> was then operating on freed memory, which could contain anything. With this
> patch applied, the Oops no longer occurs.
DMA test failed? What NIC device do you have? How did it fail?
Thanks.
^ permalink raw reply
* Re: From: Carlos Martц╜n <carlos@cmartin.tk>
From: Carlos Martín @ 2006-02-21 14:31 UTC (permalink / raw)
To: Denis Vlasenko; +Cc: acx100-devel, netdev
In-Reply-To: <200602210817.19138.vda@ilport.com.ua>
On Tuesday 21 February 2006 07:17, Denis Vlasenko wrote:
>
> allmodconfig for acx is:
>
> CONFIG_ACX=m
> CONFIG_ACX_PCI=y
> CONFIG_ACX_USB=y
>
> and it compiles for me just fine. Please send me your .config.
> Mine is attached.
My bad, sorry. I forgot to copy the Kconfig file over, so I was getting
tristate ACX_{PCI,USB} instead of bools.
I had
CONFIG_ACX=m
CONFIG_ACX_PCI=m
CONFIG_ACX_PCI_BOOL=y
CONFIG_ACX_USB=m
CONFIG_ACX_USB_BOOL=y
So of course it was failing. Once I copied Kconfig over, all goes according to
plan.
cmn
--
Carlos Martín Nieto | http://www.cmartin.tk
Hobbyist programmer |
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
^ permalink raw reply
* Re: From: Carlos Martц╜n <carlos@cmartin.tk>
From: Denis Vlasenko @ 2006-02-21 6:17 UTC (permalink / raw)
To: acx100-devel; +Cc: Carlos Martín, netdev
In-Reply-To: <200602201956.07340.carlos@cmartin.tk>
[-- Attachment #1: Type: text/plain, Size: 971 bytes --]
On Monday 20 February 2006 20:56, Carlos Martín wrote:
> On Monday 20 February 2006 16:30, Denis Vlasenko wrote:
> > On Sunday 19 February 2006 00:35, Carlos Martin wrote:
> > > [PATCH] acxsm: Fix Kconfig option check
> > >
> > > This check never actually worked because CONFIG_ACX_{ACX,USB} are
> > > tristate. With Adrian Bunk's patch to the Kconfig, this works with the
> > > _BOOL hidden Kconfig options.
> > > Also update error message adding that this shouldn't happen anymore.
> >
> > Carlos, I didn't apply Adrian's patch to my tree.
> >
> > I am not sure we want to support every imaginable .config.
> > Realistic goal is:
> > * allnoconfig must compile
> > * allyesconfig must compile
> > * allmodconfig must compile
> Which doesn't work with your #error condition.
allmodconfig for acx is:
CONFIG_ACX=m
CONFIG_ACX_PCI=y
CONFIG_ACX_USB=y
and it compiles for me just fine. Please send me your .config.
Mine is attached.
--
vda
[-- Attachment #2: .config.bz2 --]
[-- Type: application/x-bzip2, Size: 9085 bytes --]
^ permalink raw reply
* Re: Re: [PATCH RESEND] net: Move destructor from neigh->ops to neigh_params
From: David S. Miller @ 2006-02-21 4:55 UTC (permalink / raw)
To: rdreier; +Cc: yoshfuji, netdev, openib-general
In-Reply-To: <adahd6t5nc1.fsf@cisco.com>
From: Roland Dreier <rdreier@cisco.com>
Date: Mon, 20 Feb 2006 20:48:30 -0800
> Do you think you'll get a chance to look at it for 2.6.17?
Yes I will.
^ permalink raw reply
* Re: Re: [PATCH RESEND] net: Move destructor from neigh->ops to neigh_params
From: Roland Dreier @ 2006-02-21 4:48 UTC (permalink / raw)
To: David S. Miller; +Cc: yoshfuji, netdev, openib-general
In-Reply-To: <20060220.200152.00014728.davem@davemloft.net>
David> Not yet, it's very low on the priority list at the moment,
David> but I do still have it in my inbox so don't worry.
Do you think you'll get a chance to look at it for 2.6.17? If not we
can work around things in the IPoIB driver in a slightly uglier way
for 2.6.17.
Thanks,
Roland
^ permalink raw reply
* Re: [NETFILTER]: Fix skb->nf_bridge lifetime issues
From: David S. Miller @ 2006-02-21 4:21 UTC (permalink / raw)
To: kaber; +Cc: netdev, netfilter-devel, bdschuym
In-Reply-To: <43FA9440.6070103@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Tue, 21 Feb 2006 05:17:04 +0100
> I think net-2.6.17 is better, the bridging stuff is really to
> fragile for this to be sure it won't break anything and this
> has never worked so far.
Ok, done.
^ permalink raw reply
* Re: [NETFILTER]: Fix skb->nf_bridge lifetime issues
From: Patrick McHardy @ 2006-02-21 4:17 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, netfilter-devel, bdschuym
In-Reply-To: <20060220.200943.51907116.davem@davemloft.net>
David S. Miller wrote:
> From: Patrick McHardy <kaber@trash.net>
> Date: Mon, 20 Feb 2006 10:33:34 +0100
>
>
>>This time compile tested and s/nfct/nf_bridge/ above.
>
>
> Want me to push this into net-2.6 now that Bart has ACK'd it?
I think net-2.6.17 is better, the bridging stuff is really to
fragile for this to be sure it won't break anything and this
has never worked so far.
^ permalink raw reply
* Re: [NETFILTER]: Fix skb->nf_bridge lifetime issues
From: David S. Miller @ 2006-02-21 4:09 UTC (permalink / raw)
To: kaber; +Cc: netdev, netfilter-devel, bdschuym
In-Reply-To: <43F98CEE.1080609@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Mon, 20 Feb 2006 10:33:34 +0100
> This time compile tested and s/nfct/nf_bridge/ above.
Want me to push this into net-2.6 now that Bart has ACK'd it?
Thanks.
^ permalink raw reply
* Re: 2.6.16-rc4 bridge/iptables Oops
From: David S. Miller @ 2006-02-21 4:07 UTC (permalink / raw)
To: kaber; +Cc: earny, linux-kernel, netdev, netfilter-devel
In-Reply-To: <43FA8439.6080009@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Tue, 21 Feb 2006 04:08:41 +0100
> Thanks for testing. Dave, please take this patch instead, it avoids
> having to guess whether a packet originates from bridging in IP
> netfilter by using DST_NOXFRM for bridge-netfilter's fake dst_entry.
Applied, thanks Patrick.
^ permalink raw reply
* Re: Re: [PATCH RESEND] net: Move destructor from neigh->ops to neigh_params
From: David S. Miller @ 2006-02-21 4:01 UTC (permalink / raw)
To: rdreier; +Cc: yoshfuji, netdev, openib-general
In-Reply-To: <adalkw55qdq.fsf@cisco.com>
From: Roland Dreier <rdreier@cisco.com>
Date: Mon, 20 Feb 2006 19:42:41 -0800
> Hi Dave, have you had a chance to look at this?
Not yet, it's very low on the priority list at the moment,
but I do still have it in my inbox so don't worry.
^ permalink raw reply
* Re: Re: [PATCH RESEND] net: Move destructor from neigh->ops to neigh_params
From: Roland Dreier @ 2006-02-21 3:42 UTC (permalink / raw)
To: davem
Cc: YOSHIFUJI Hideaki / 吉藤英明, netdev,
openib-general
In-Reply-To: <20060202.103448.118065476.yoshfuji@linux-ipv6.org>
Hi Dave, have you had a chance to look at this? I can resend again if
you've lost the original mail. Also, let me know if you want me to
merge this through my tree when 2.6.17 opens up.
The only feedback I've seen is that Yoshfuji-san has said that this
looks sane.
Thanks,
Roland
^ permalink raw reply
* Re: 2.6.16-rc4 bridge/iptables Oops
From: Patrick McHardy @ 2006-02-21 3:08 UTC (permalink / raw)
To: Ernst Herzberg
Cc: Kernel Netdev Mailing List, Netfilter Development Mailinglist,
linux-kernel, David S. Miller
In-Reply-To: <200602210211.22364.earny@net4u.de>
[-- Attachment #1: Type: text/plain, Size: 634 bytes --]
Ernst Herzberg wrote:
>>This patch should fix it. Please test it and report if it helps.
>
>
> oernie:~ # uname -a ; uptime
> Linux oernie 2.6.16-rc4 #1 PREEMPT Mon Feb 20 22:07:34 CET 2006 i686 Intel(R)
> Pentium(R) 4 CPU 2.80GHz GenuineIntel GNU/Linux
> 02:06:00 up 3:53, 4 users, load average: 0.08, 0.15, 0.10
>
> No oops so far. Serial console still connected, will report if this or a
> similar problem occurs again.
Thanks for testing. Dave, please take this patch instead, it avoids
having to guess whether a packet originates from bridging in IP
netfilter by using DST_NOXFRM for bridge-netfilter's fake dst_entry.
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 2136 bytes --]
[NETFILTER]: Fix bridge netfilter related in xfrm_lookup
The bridge-netfilter code attaches a fake dst_entry with dst->ops == NULL
to purely bridged packets. When these packets are SNATed and a policy
lookup is done, xfrm_lookup crashes because it tries to dereference
dst->ops.
Change xfrm_lookup not to dereference dst->ops before checking for the
DST_NOXFRM flag and set this flag in the fake dst_entry.
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
commit 6f149cebfdad51205b405058496a501a550dfdb4
tree f87624178d8e9e8b255080f20a5b91a5c25d45e9
parent a8372f035aa2f6717123eb30679a08b619321dd4
author Patrick McHardy <kaber@trash.net> Tue, 21 Feb 2006 04:03:16 +0100
committer Patrick McHardy <kaber@trash.net> Tue, 21 Feb 2006 04:03:16 +0100
net/bridge/br_netfilter.c | 1 +
net/xfrm/xfrm_policy.c | 7 ++++---
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
index 6bb0c7e..e060aad 100644
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -90,6 +90,7 @@ static struct rtable __fake_rtable = {
.dev = &__fake_net_device,
.path = &__fake_rtable.u.dst,
.metrics = {[RTAX_MTU - 1] = 1500},
+ .flags = DST_NOXFRM,
}
},
.rt_flags = 0,
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index 5e6b05a..8206025 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -782,7 +782,7 @@ int xfrm_lookup(struct dst_entry **dst_p
int nx = 0;
int err;
u32 genid;
- u16 family = dst_orig->ops->family;
+ u16 family;
u8 dir = policy_to_flow_dir(XFRM_POLICY_OUT);
u32 sk_sid = security_sk_sid(sk, fl, dir);
restart:
@@ -796,13 +796,14 @@ restart:
if ((dst_orig->flags & DST_NOXFRM) || !xfrm_policy_list[XFRM_POLICY_OUT])
return 0;
- policy = flow_cache_lookup(fl, sk_sid, family, dir,
- xfrm_policy_lookup);
+ policy = flow_cache_lookup(fl, sk_sid, dst_orig->ops->family,
+ dir, xfrm_policy_lookup);
}
if (!policy)
return 0;
+ family = dst_orig->ops->family;
policy->curlft.use_time = (unsigned long)xtime.tv_sec;
switch (policy->action) {
^ permalink raw reply related
* Re: 2.6.16-rc4 bridge/iptables Oops
From: Ernst Herzberg @ 2006-02-21 1:11 UTC (permalink / raw)
To: linux-kernel
Cc: Patrick McHardy, David S. Miller, Kernel Netdev Mailing List,
Netfilter Development Mailinglist
In-Reply-To: <43FA0C02.8000909@trash.net>
On Monday 20 February 2006 19:35, Patrick McHardy wrote:
> Ernst Herzberg wrote:
> > This machine oopses one to three (or more?) times a day. Occurs since
> > upgrading from -rc3 to -rc4 (and adding/reconfiguring raid).
> >
> > It is reproducable, i have only to wait 10min to a couple of hours:-)
> >
> > Opps copy/pasted from a serial console, long lines maybe truncated.
> > dmesg is from the _previous_ boot/oops....
> >
> > -------------------------------------------
> > Oops: 0000 [#1]
> > PREEMPT
> > Modules linked in: ebt_log ebt_ip ebtable_filter ebtables nfsd exportfs
> > lockd sunrpc w83627hf hwmon_vid i2c_isa xt_tcpudp xt_state ipt_MASQUERADE
> > iptable_e CPU: 0
> > EIP: 0060:[<b033fbf3>] Not tainted VLI
> > EFLAGS: 00010282 (2.6.16-rc4 #3)
> > EIP is at xfrm_lookup+0x1f/0x47d
> This patch should fix it. Please test it and report if it helps.
oernie:~ # uname -a ; uptime
Linux oernie 2.6.16-rc4 #1 PREEMPT Mon Feb 20 22:07:34 CET 2006 i686 Intel(R)
Pentium(R) 4 CPU 2.80GHz GenuineIntel GNU/Linux
02:06:00 up 3:53, 4 users, load average: 0.08, 0.15, 0.10
No oops so far. Serial console still connected, will report if this or a
similar problem occurs again.
Thanks!
<earn/>
^ permalink raw reply
* [2.6 patch] make UNIX a bool
From: Adrian Bunk @ 2006-02-20 22:36 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Christoph Hellwig, Dipankar Sarma, Andrew Morton, linux-kernel,
paulmck, dada1, davem, netdev
In-Reply-To: <1140265890.4035.17.camel@laptopd505.fenrus.org>
On Sat, Feb 18, 2006 at 01:31:30PM +0100, Arjan van de Ven wrote:
> On Sat, 2006-02-18 at 12:14 +0000, Christoph Hellwig wrote:
> > > > - Make the get_max_files export use _GPL - only unix.ko uses it.
> >
> > The real question is, does af_unix really need to allow beeing built
> > modular? It's quite different from other network protocol and deeply
> > tied to the kernel due to things like descriptor passing or using
> > the filesystem namespace. I already had to export another symbol that
> > really should be internal just for it, and if one module acquires lots
> > of such hacks it's usually a bad sign..
>
> in 2.4 the answer would have been simple; modutils back then used
> AF_UNIX stuff before it could load modules, so modular was in practice
> impossible.
>
> Anyway I'd agree with making this non-modular... NOBODY will use this as
> a module, or if they do loading it somehow is the very first thing done.
> You just can't live without this, so making it a module is non-sensical.
So let's send a patch. ;-)
cu
Adrian
<-- snip -->
CONFIG_UNIX=m doesn't make much sense.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.16-rc4-mm1-full/net/unix/Kconfig.old 2006-02-20 14:40:19.000000000 +0100
+++ linux-2.6.16-rc4-mm1-full/net/unix/Kconfig 2006-02-20 14:40:27.000000000 +0100
@@ -3,7 +3,7 @@
#
config UNIX
- tristate "Unix domain sockets"
+ bool "Unix domain sockets"
---help---
If you say Y here, you will include support for Unix domain sockets;
sockets are the standard Unix mechanism for establishing and
^ permalink raw reply
* Re: [PATCH 02/02] add mask options to fwmark masking code
From: Carl-Daniel Hailfinger @ 2006-02-20 19:58 UTC (permalink / raw)
To: Michael Richardson; +Cc: kuznet, netfilter-devel, Jamal Hadi Salim, netdev
In-Reply-To: <23140.1140452813@sandelman.ottawa.on.ca>
Michael Richardson schrieb:
> [PATCH] This patch introduces a mask to the fwmark test cases in the advanced
> routing. This let's one test individual bits of the fwmark to determine
> how things should be routed (pick a routing table). This patch retains
> compatibility with tests that do not set the mask by assuming a mask
> of 0 is equivalent to a mask of 0xffffffff.
Sorry if I misunderstood the intention of your patch, but isn't similar code
already in mainline?
linux-2.6.16-rc3/net/sched/cls_u32.c:146
#ifdef CONFIG_CLS_U32_MARK
if ((skb->nfmark & n->mark.mask) != n->mark.val) {
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
^ permalink raw reply
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