* Re: follow-up: discrepancy with POSIX
From: Andi Kleen @ 2007-09-19 19:40 UTC (permalink / raw)
To: Rick Jones; +Cc: Andi Kleen, Ulrich Drepper, netdev, Linux Kernel
In-Reply-To: <46F16CC1.9090302@hp.com>
> It has hung-on in various places (stacks) as an "accepted" broadcast IP
> in the receive path, but not the send path for quite possibly decades now.
Well it is valid in Linux for sending. And who knows who relies on it.
-Andi
^ permalink raw reply
* RE: [PATCH] tehuti: driver for Tehuti 10GbE network adapters
From: Alexander Indenbaum @ 2007-09-19 19:28 UTC (permalink / raw)
To: 'Christoph Hellwig'
Cc: jeff, davem, akpm, netdev, 'Nadav Shemer',
'Andy Gospodarek'
In-Reply-To: <20070919174103.GB22795@infradead.org>
> Ok, so you do irq acquire/release in open/close so that bit is fine.
> The code might actually work as is, sorry for the noise.
It is no noise at all. Thank you for your feedback.
^ permalink raw reply
* Re: Please pull 'z1211' branch of wireless-2.6
From: Michael Buesch @ 2007-09-19 19:23 UTC (permalink / raw)
To: David Miller; +Cc: linville, jeff, netdev, linux-wireless, dsd, kune
In-Reply-To: <20070919.115903.75429061.davem@davemloft.net>
On Wednesday 19 September 2007 20:59:03 David Miller wrote:
> From: "John W. Linville" <linville@tuxdriver.com>
> Date: Wed, 19 Sep 2007 14:10:05 -0400
>
> > This patch adds z1211 (previously known as zd1211rw-mac80211),
> > a driver for Zydas ZD1211 hardware. This driver has proven very
> > robust -- Fedora 7 uses this driver and I don't think I have any open
> > bugzillas for it. Either the driver works well, or no one as using
> > it...given the common availability of the hardware, I have to presume
> > the former. :-)
> >
> > This driver is mostly a port of zd1211rw to the mac80211
> > infrastructure. In fact, most zd1211rw patches have been mirrored
> > directly to this driver for some time. I considered merely updating
> > the existing driver with this code, but I think it is more prudent to
> > include this as a separate driver just to avoid confusion. There is
> > some symbol clash between the two drivers, so I add a Kconfig hack
> > to ensure that only one or the other is built-in or that this one is
> > built as a module.
> >
> > The maintainers have identified some (IMHO minor) issues with the
> > mac80211 port of this driver. Some of them are summarized here:
> >
> > http://linuxwireless.org/en/users/Drivers/zd1211rw/mac80211Issues
> >
> > Still, I think we would be better-off having this driver upstream.
>
> Agreed, merged into net-2.6.24, thanks John.
John, please also note that the following patch is not merged, yet.
http://bu3sch.de/patches/wireless-dev/20070915-1740/patches/006-zd-fix-tx-status.patch
Without it ratecontrol does not work. It does neither scale the rate
up nor down. This patch fixes both.
I think it got lost in a (really unrelated to the actual bug) discussion
about whether it's required or not to report status in mac80211 drivers.
(It turned out that it _is_ required).
--
Greetings Michael.
^ permalink raw reply
* Re: Please pull 'z1211' branch of wireless-2.6
From: David Miller @ 2007-09-19 18:59 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: jeff-o2qLIJkoznsdnm+yROfE0A, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, dsd-aBrp7R+bbdUdnm+yROfE0A,
kune-hUSrv6EASfkEnNRfnnE9gw
In-Reply-To: <20070919181005.GB5483-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Wed, 19 Sep 2007 14:10:05 -0400
> This patch adds z1211 (previously known as zd1211rw-mac80211),
> a driver for Zydas ZD1211 hardware. This driver has proven very
> robust -- Fedora 7 uses this driver and I don't think I have any open
> bugzillas for it. Either the driver works well, or no one as using
> it...given the common availability of the hardware, I have to presume
> the former. :-)
>
> This driver is mostly a port of zd1211rw to the mac80211
> infrastructure. In fact, most zd1211rw patches have been mirrored
> directly to this driver for some time. I considered merely updating
> the existing driver with this code, but I think it is more prudent to
> include this as a separate driver just to avoid confusion. There is
> some symbol clash between the two drivers, so I add a Kconfig hack
> to ensure that only one or the other is built-in or that this one is
> built as a module.
>
> The maintainers have identified some (IMHO minor) issues with the
> mac80211 port of this driver. Some of them are summarized here:
>
> http://linuxwireless.org/en/users/Drivers/zd1211rw/mac80211Issues
>
> Still, I think we would be better-off having this driver upstream.
Agreed, merged into net-2.6.24, thanks John.
^ permalink raw reply
* Re: Please pull 'rt2x00' branch of wireless-2.6
From: Ivo van Doorn @ 2007-09-19 18:58 UTC (permalink / raw)
To: Michael Buesch
Cc: David Miller, linville-2XuSBdqkA4R54TAoqtyWWQ,
jeff-o2qLIJkoznsdnm+yROfE0A, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <200709192036.59443.mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org>
On Wednesday 19 September 2007, Michael Buesch wrote:
> On Wednesday 19 September 2007 20:47:59 Ivo van Doorn wrote:
> > On Wednesday 19 September 2007, David Miller wrote:
> > > From: Ivo van Doorn <ivdoorn-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > > Date: Wed, 19 Sep 2007 20:31:19 +0200
> > >
> > > > Because I am indeed not really happy with this early merge, but I'll do my
> > > > best to resolve the last outstanding bugs as soon as possible.
> > >
> > > Relax :-)
> >
> > :)
> >
> > > A merge upstream doesn't mean "bug free", it means "significantly
> > > better than no driver at all" and that is undoubtedly the case
> > > here.
> >
> > Well I am happy rt2x00 is being considered good enough for upstream already,
> > but I have the habbit of wanting things bug-free before pushing it further upstream.
> >
> > Well most users are happy with current rt2x00 version anyway,
> > so the remaining issues probably aren't that big anyway. (Except for the 2 panics,
> > which should be resolved soon anyway) ;)
>
> Well, you have nothing to lose, basically.
> It's impossible for you to create a regression.
> So everything is fine, even if it's buggy and doesn't
> work at all. ;)
Hehe. Thanks. I'll keep that in mind. ;)
Ivo
^ permalink raw reply
* Re: [PATCH net-2.6.24] introduce MAC_FMT/MAC_ARG
From: Joe Perches @ 2007-09-19 18:50 UTC (permalink / raw)
To: David Miller; +Cc: johannes, netdev, akpm, jgarzik
In-Reply-To: <20070919.111147.55510143.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 297 bytes --]
On Wed, 2007-09-19 at 11:11 -0700, David Miller wrote:
> Can you just extract out one single patch that does the MAC_FMT change
> and get that to me somehow?
Signed-off-by: Joe Perches <joe@perches.com>
pull from:
git://repo.or.cz/linux-2.6/trivial-mods.git print_mac
or use the attached bz2
[-- Attachment #2: net-2.6.24-print_mac.diff.bz2 --]
[-- Type: application/x-bzip, Size: 68985 bytes --]
^ permalink raw reply
* Re: [PATCH] phy: export phy_mii_ioctl
From: Jon Smirl @ 2007-09-19 18:44 UTC (permalink / raw)
To: Domen Puncer; +Cc: netdev, linuxppc-embedded, sven
In-Reply-To: <20070919115621.GI32628@nd47.coderock.org>
On 9/19/07, Domen Puncer <domen@coderock.org> wrote:
> Patch at the end.
> When compiled as module use "modprobe fec_mpc52xx mac=foo",
> when built-in add to boot line: "fec_mpc52xx.mac=foo"
This patch series is working for me now.
This needs a cleanup too, but it is unrelated....
CC drivers/serial/mpc52xx_uart.o
drivers/serial/mpc52xx_uart.c: In function 'mpc52xx_console_setup':
drivers/serial/mpc52xx_uart.c:760: warning: format '%lx' expects type
'long unsigned int', but argument 2 has type 'resource_size_t'
drivers/serial/mpc52xx_uart.c: In function 'mpc52xx_uart_of_probe':
drivers/serial/mpc52xx_uart.c:978: warning: format '%lx' expects type
'long unsigned int', but argument 3 has type 'resource_size_t'
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: follow-up: discrepancy with POSIX
From: Rick Jones @ 2007-09-19 18:38 UTC (permalink / raw)
To: Andi Kleen; +Cc: Ulrich Drepper, netdev, Linux Kernel
In-Reply-To: <20070919183004.GA18707@one.firstfloor.org>
Andi Kleen wrote:
> On Wed, Sep 19, 2007 at 11:02:00AM -0700, Ulrich Drepper wrote:
>
>>>on UDP/RAW and it's certainly possible to connect() to that.
>>
>>Where do you get this from? And where is this implemented? I don't
>
>
> Sorry it's actually loopback, not broadcast as implemented in Linux.
> In Linux it's implemented in ip_route_output_slow(). Essentially
> converted to 127.0.0.1
>
> I think it's traditional BSD behaviour but couldn't find it on
> a quick look in FreeBSD source (but haven't looked very intensively)
One has to set their way-back machine pretty far back to find the *BSD
bits which used 0.0.0.0 as the "all nets, all subnets" (to mis-use a
term) broadcast IPv4 address when sending. Perhaps as far back as the
time before HP-UX 7 or SunOS4. The bit errors in my dimm memory get
pretty dense that far back...
It has hung-on in various places (stacks) as an "accepted" broadcast IP
in the receive path, but not the send path for quite possibly decades now.
rick jones
^ permalink raw reply
* Re: Please pull 'rt2x00' branch of wireless-2.6
From: Michael Buesch @ 2007-09-19 18:36 UTC (permalink / raw)
To: Ivo van Doorn
Cc: David Miller, linville-2XuSBdqkA4R54TAoqtyWWQ,
jeff-o2qLIJkoznsdnm+yROfE0A, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <200709192048.00741.IvDoorn-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Wednesday 19 September 2007 20:47:59 Ivo van Doorn wrote:
> On Wednesday 19 September 2007, David Miller wrote:
> > From: Ivo van Doorn <ivdoorn-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date: Wed, 19 Sep 2007 20:31:19 +0200
> >
> > > Because I am indeed not really happy with this early merge, but I'll do my
> > > best to resolve the last outstanding bugs as soon as possible.
> >
> > Relax :-)
>
> :)
>
> > A merge upstream doesn't mean "bug free", it means "significantly
> > better than no driver at all" and that is undoubtedly the case
> > here.
>
> Well I am happy rt2x00 is being considered good enough for upstream already,
> but I have the habbit of wanting things bug-free before pushing it further upstream.
>
> Well most users are happy with current rt2x00 version anyway,
> so the remaining issues probably aren't that big anyway. (Except for the 2 panics,
> which should be resolved soon anyway) ;)
Well, you have nothing to lose, basically.
It's impossible for you to create a regression.
So everything is fine, even if it's buggy and doesn't
work at all. ;)
--
Greetings Michael.
^ permalink raw reply
* Re: Please pull 'rt2x00' branch of wireless-2.6
From: Ivo van Doorn @ 2007-09-19 18:47 UTC (permalink / raw)
To: David Miller; +Cc: linville, jeff, netdev, linux-wireless
In-Reply-To: <20070919.112137.48806758.davem@davemloft.net>
On Wednesday 19 September 2007, David Miller wrote:
> From: Ivo van Doorn <ivdoorn@gmail.com>
> Date: Wed, 19 Sep 2007 20:31:19 +0200
>
> > Because I am indeed not really happy with this early merge, but I'll do my
> > best to resolve the last outstanding bugs as soon as possible.
>
> Relax :-)
:)
> A merge upstream doesn't mean "bug free", it means "significantly
> better than no driver at all" and that is undoubtedly the case
> here.
Well I am happy rt2x00 is being considered good enough for upstream already,
but I have the habbit of wanting things bug-free before pushing it further upstream.
Well most users are happy with current rt2x00 version anyway,
so the remaining issues probably aren't that big anyway. (Except for the 2 panics,
which should be resolved soon anyway) ;)
Ivo
^ permalink raw reply
* Re: Please pull 'rt2x00' branch of wireless-2.6
From: Ivo van Doorn @ 2007-09-19 18:31 UTC (permalink / raw)
To: John W. Linville
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, jeff-o2qLIJkoznsdnm+yROfE0A,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20070918213202.GJ4940-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Hi,
> This patch adds the rt2x00 drivers for Ralink wireless hardware.
> This collection of drivers has seen lots of action in Fedora (both
> F7 and rawhide) and many people are using them with good results
> (although some problems do remain).
>
> Ivo in particular has been very helpful in responding to bug reports
> for these drivers, including bugs reported at kernel.org and in
> distro bugzillas. I extend my thanks to him for both his past and
> future support of these drivers. I'm sure he and the rest of the
> rt2x00 team will continue to support the community and their userbase.
>
> Ivo and his team may feel I am jumping the gun a bit -- they have
> a few more random bugs they wanted to squash before going upstream.
> But since they are bugs, any fixes should still be able to be applied
> in the -rc phase of 2.6.24. In the meantime, I definitely think it
> would be better to get this code into mainline rather than keeping
> it out of stream.
With 2.6.23 not yet released, I assume we still have a few months to get
rt2x00 shaped up to be really ready for 2.6.24?
Because I am indeed not really happy with this early merge, but I'll do my
best to resolve the last outstanding bugs as soon as possible.
Ivo
^ permalink raw reply
* Re: follow-up: discrepancy with POSIX
From: Andi Kleen @ 2007-09-19 18:30 UTC (permalink / raw)
To: Ulrich Drepper; +Cc: Andi Kleen, netdev, Linux Kernel
In-Reply-To: <46F16418.3070706@redhat.com>
On Wed, Sep 19, 2007 at 11:02:00AM -0700, Ulrich Drepper wrote:
> > on UDP/RAW and it's certainly possible to connect() to that.
>
> Where do you get this from? And where is this implemented? I don't
Sorry it's actually loopback, not broadcast as implemented in Linux.
In Linux it's implemented in ip_route_output_slow(). Essentially
converted to 127.0.0.1
I think it's traditional BSD behaviour but couldn't find it on
a quick look in FreeBSD source (but haven't looked very intensively)
Admittedly port 0 is somewhat dodgy for UDP too, but at least in RAW
context it might be valid.
-Andi
^ permalink raw reply
* Re: Please pull 'rt2x00' branch of wireless-2.6
From: David Miller @ 2007-09-19 18:21 UTC (permalink / raw)
To: ivdoorn; +Cc: linville, jeff, netdev, linux-wireless
In-Reply-To: <200709192031.19934.IvDoorn@gmail.com>
From: Ivo van Doorn <ivdoorn@gmail.com>
Date: Wed, 19 Sep 2007 20:31:19 +0200
> Because I am indeed not really happy with this early merge, but I'll do my
> best to resolve the last outstanding bugs as soon as possible.
Relax :-)
A merge upstream doesn't mean "bug free", it means "significantly
better than no driver at all" and that is undoubtedly the case
here.
^ permalink raw reply
* Re: [RESEND][PATCH 3/4 Rev-3] Initilize and populate age field
From: David Miller @ 2007-09-19 18:20 UTC (permalink / raw)
To: varunc; +Cc: netdev, kaber, socketcan, shemminger, krkumar2, tgraf, varuncha
In-Reply-To: <20070919092434.0d461f0b.varunc@linux.vnet.ibm.com>
From: Varun Chandramohan <varunc@linux.vnet.ibm.com>
Date: Wed, 19 Sep 2007 09:24:34 +0530
> The age field is filled with the current time at the time of creation of the route. When the routes are dumped
> then the age value stored in the route structure is subtracted from the current time value and the difference is the age expressed in secs.
>
> Signed-off-by: Varun Chandramohan <varunc@linux.vnet.ibm.com>
This doesn't match what your code does:
> + /* Note: The ideal place to fill up the time value for a newely created route will be
> + ** in fn_hash_insert(). But we are delaying the time insert procedure to avoid calling
> + ** do_gettimeofday() twice.
> + */
> + do_gettimeofday(&tv);
> + if (!*age) {
> + *age = timeval_to_sec(&tv);
> + NLA_PUT_U32(skb, RTA_AGE, *age);
> + } else {
> + NLA_PUT_U32(skb, RTA_AGE, timeval_to_sec(&tv) - *age);
> + }
In avoiding the age initialization at routing cache insertion time,
you make the value provided totally inaccurate and essentially
useless especially the very first time the value is asked for.
I really don't like these changes, they have had problems every step
of the way, and the above proves that we could essentially always
return an age value of zero and still be compliant with the standards.
^ permalink raw reply
* Re: [PATCH net-2.6.24] introduce MAC_FMT/MAC_ARG
From: David Miller @ 2007-09-19 18:11 UTC (permalink / raw)
To: joe; +Cc: johannes, netdev, akpm, jgarzik
In-Reply-To: <1190177401.19708.264.camel@localhost>
From: Joe Perches <joe@perches.com>
Date: Tue, 18 Sep 2007 21:50:01 -0700
> I rebased against yesterday's net-2.6.24
>
> Please pull from:
>
> git://repo.or.cz/linux-2.6/trivial-mods.git net-2.6.24-fordave
You didn't "rebase" you "merged" and this makes your tree a complete
mess.
When you do a real "rebase", you clone a fresh new tree from mine and
add only your patches on top.
Your tree as-is is difficult for me to pull from because it contains
all kinds of messy merges and merge error fixups.
Can you just extract out one single patch that does the MAC_FMT change
and get that to me somehow? Either by adding it into a fresh
net-2.6.24 clone, or as a patch. Both ways are fine.
^ permalink raw reply
* Please pull 'z1211' branch of wireless-2.6
From: John W. Linville @ 2007-09-19 18:10 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: jeff-o2qLIJkoznsdnm+yROfE0A, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, dsd-aBrp7R+bbdUdnm+yROfE0A,
kune-hUSrv6EASfkEnNRfnnE9gw
Jeff & Dave,
This patch adds z1211 (previously known as zd1211rw-mac80211),
a driver for Zydas ZD1211 hardware. This driver has proven very
robust -- Fedora 7 uses this driver and I don't think I have any open
bugzillas for it. Either the driver works well, or no one as using
it...given the common availability of the hardware, I have to presume
the former. :-)
This driver is mostly a port of zd1211rw to the mac80211
infrastructure. In fact, most zd1211rw patches have been mirrored
directly to this driver for some time. I considered merely updating
the existing driver with this code, but I think it is more prudent to
include this as a separate driver just to avoid confusion. There is
some symbol clash between the two drivers, so I add a Kconfig hack
to ensure that only one or the other is built-in or that this one is
built as a module.
The maintainers have identified some (IMHO minor) issues with the
mac80211 port of this driver. Some of them are summarized here:
http://linuxwireless.org/en/users/Drivers/zd1211rw/mac80211Issues
Still, I think we would be better-off having this driver upstream.
Thanks,
John
---
Patch is available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/0001-z1211-add-mac80211-based-driver-for-ZD1211-hardwa.patch
---
The following changes since commit 0d4cbb5e7f60b2f1a4d8b7f6ea4cc264262c7a01:
Linus Torvalds (1):
Linux 2.6.23-rc6
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git z1211
Daniel Drake (1):
z1211: add mac80211-based driver for ZD1211 hardware
MAINTAINERS | 10 +
drivers/net/wireless/Kconfig | 1 +
drivers/net/wireless/Makefile | 1 +
drivers/net/wireless/z1211/Kconfig | 18 +
drivers/net/wireless/z1211/Makefile | 10 +
drivers/net/wireless/z1211/zd_chip.c | 1619 ++++++++++++++++++++++++++++
drivers/net/wireless/z1211/zd_chip.h | 921 ++++++++++++++++
drivers/net/wireless/z1211/zd_def.h | 57 +
drivers/net/wireless/z1211/zd_ieee80211.c | 100 ++
drivers/net/wireless/z1211/zd_ieee80211.h | 75 ++
drivers/net/wireless/z1211/zd_mac.c | 949 ++++++++++++++++
drivers/net/wireless/z1211/zd_mac.h | 227 ++++
drivers/net/wireless/z1211/zd_rf.c | 178 +++
drivers/net/wireless/z1211/zd_rf.h | 108 ++
drivers/net/wireless/z1211/zd_rf_al2230.c | 439 ++++++++
drivers/net/wireless/z1211/zd_rf_al7230b.c | 492 +++++++++
drivers/net/wireless/z1211/zd_rf_rf2959.c | 279 +++++
drivers/net/wireless/z1211/zd_rf_uw2453.c | 534 +++++++++
drivers/net/wireless/z1211/zd_usb.c | 1528 ++++++++++++++++++++++++++
drivers/net/wireless/z1211/zd_usb.h | 263 +++++
drivers/net/wireless/z1211/zd_util.c | 82 ++
drivers/net/wireless/z1211/zd_util.h | 29 +
22 files changed, 7920 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/wireless/z1211/Kconfig
create mode 100644 drivers/net/wireless/z1211/Makefile
create mode 100644 drivers/net/wireless/z1211/zd_chip.c
create mode 100644 drivers/net/wireless/z1211/zd_chip.h
create mode 100644 drivers/net/wireless/z1211/zd_def.h
create mode 100644 drivers/net/wireless/z1211/zd_ieee80211.c
create mode 100644 drivers/net/wireless/z1211/zd_ieee80211.h
create mode 100644 drivers/net/wireless/z1211/zd_mac.c
create mode 100644 drivers/net/wireless/z1211/zd_mac.h
create mode 100644 drivers/net/wireless/z1211/zd_rf.c
create mode 100644 drivers/net/wireless/z1211/zd_rf.h
create mode 100644 drivers/net/wireless/z1211/zd_rf_al2230.c
create mode 100644 drivers/net/wireless/z1211/zd_rf_al7230b.c
create mode 100644 drivers/net/wireless/z1211/zd_rf_rf2959.c
create mode 100644 drivers/net/wireless/z1211/zd_rf_uw2453.c
create mode 100644 drivers/net/wireless/z1211/zd_usb.c
create mode 100644 drivers/net/wireless/z1211/zd_usb.h
create mode 100644 drivers/net/wireless/z1211/zd_util.c
create mode 100644 drivers/net/wireless/z1211/zd_util.h
--
John W. Linville
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org
^ permalink raw reply
* RE: [PATCH] tehuti: driver for Tehuti 10GbE network adapters
From: Alexander Indenbaum @ 2007-09-19 17:37 UTC (permalink / raw)
To: 'Christoph Hellwig'
Cc: jeff, davem, akpm, netdev, 'Nadav Shemer',
'Andy Gospodarek'
In-Reply-To: <20070919155258.GA14850@infradead.org>
> -----Original Message-----
> From: 'Christoph Hellwig' [mailto:hch@infradead.org]
> Sent: Wednesday, September 19, 2007 5:53 PM
>
> > Putting dual-port issue aside, could you elaborate what is the problem
> in
> > your opinion in bdx_remove() implementation? What is wrong with calling
> > free_netdev() right after unregister_netdev()? Could you provide
> pointers
> > for docs and examples to correct PCI network device remove interface
> > implementation?
>
> free_netdev can only be called if you're sure you don't reference your
> netdevice anymore. Most notably that means you need to call free_irq
> first.
In my understanding unregister_netdev(), in case netdev is still IFF_UP and
holds irq, will call dev_close() which will call netdev->stop(), bdx_close()
in our case. bdx_close() releases all netdev resources among others calls
free_irq().
That's why I'm pretty sure that we do not hold any reference to netdev after
unregister_netdev() finishes and we can free_netdev() without any worry :)
What do you think, does it still look fishy?
Alexander Indenbaum
^ permalink raw reply
* Re: follow-up: discrepancy with POSIX
From: Alan Cox @ 2007-09-19 18:06 UTC (permalink / raw)
To: Ulrich Drepper; +Cc: Andi Kleen, netdev, Linux Kernel
In-Reply-To: <46F1608E.7060908@redhat.com>
On Wed, 19 Sep 2007 10:46:54 -0700
Ulrich Drepper <drepper@redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Andi Kleen wrote:
> >> But the spec calls for a "null address" to be used and that's in my
> >> understanding something different from using AF_UNSPEC.
> >
> > memset(&sockaddr, 0, sizeof(sockaddr)) should give you AF_UNSPEC
>
> But the spec calls for <quote>null address for the protocol</quote>.
>
> That means the family for the null address is the same as the family of
> the socket.
Which is a valid address in some protocols. If I remember rightly then
appletalk net 0 node 0 port 0 is valid although I'd want to look in the
book to check that - ditto AF_ECONET although I doubt anyone cares too
much 8)
Alan
^ permalink raw reply
* Re: follow-up: discrepancy with POSIX
From: Ulrich Drepper @ 2007-09-19 18:02 UTC (permalink / raw)
To: Andi Kleen; +Cc: netdev, Linux Kernel
In-Reply-To: <20070919175700.GC18045@one.firstfloor.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andi Kleen wrote:
> Spec doesn't match traditional behaviour then.
Well, determining whether that's the case is part of this exercise.
> IPv4 0.0.0.0 is
> traditionally an synonym for old style all broadcast (255.255.255.255)
> on UDP/RAW and it's certainly possible to connect() to that.
Where do you get this from? And where is this implemented? I don't
doubt it but I have to convince people to change the standard and
possibly introduce incompatibility.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFG8WQY2ijCOnn/RHQRAlsBAJ9qZRZXNN2VEy136MFIT1daHfju5ACdGiIW
k0I5e2BGRjvjbJrrAwtehqo=
=fX+i
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: follow-up: discrepancy with POSIX
From: Andi Kleen @ 2007-09-19 17:57 UTC (permalink / raw)
To: Ulrich Drepper; +Cc: Andi Kleen, netdev, Linux Kernel
In-Reply-To: <46F1608E.7060908@redhat.com>
On Wed, Sep 19, 2007 at 10:46:54AM -0700, Ulrich Drepper wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Andi Kleen wrote:
> >> But the spec calls for a "null address" to be used and that's in my
> >> understanding something different from using AF_UNSPEC.
> >
> > memset(&sockaddr, 0, sizeof(sockaddr)) should give you AF_UNSPEC
>
> But the spec calls for <quote>null address for the protocol</quote>.
>
> That means the family for the null address is the same as the family of
> the socket.
Spec doesn't match traditional behaviour then. IPv4 0.0.0.0 is
traditionally an synonym for old style all broadcast (255.255.255.255)
on UDP/RAW and it's certainly possible to connect() to that.
-Andi
^ permalink raw reply
* Re: follow-up: discrepancy with POSIX
From: Ulrich Drepper @ 2007-09-19 17:46 UTC (permalink / raw)
To: Andi Kleen; +Cc: netdev, Linux Kernel
In-Reply-To: <20070919172653.GB18045@one.firstfloor.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andi Kleen wrote:
>> But the spec calls for a "null address" to be used and that's in my
>> understanding something different from using AF_UNSPEC.
>
> memset(&sockaddr, 0, sizeof(sockaddr)) should give you AF_UNSPEC
But the spec calls for <quote>null address for the protocol</quote>.
That means the family for the null address is the same as the family of
the socket.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFG8WCO2ijCOnn/RHQRAgtsAJ9qTFVj5QQbVG/hUflxo/6uPOfl4QCdHSX8
wi2GX7B0pht8VDaswYLqdpM=
=sMSg
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH 3/3] [PPP] L2TP: Fix skb handling in pppol2tp_xmit
From: David Miller @ 2007-09-19 17:47 UTC (permalink / raw)
To: herbert; +Cc: jchapman, mostrows, paulus, toralf.foerster, netdev
In-Reply-To: <20070919012529.GA15046@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 19 Sep 2007 09:25:29 +0800
> [PPP] L2TP: Fix skb handling in pppol2tp_xmit
>
> This patch makes pppol2tp_xmit call skb_cow_head so that we don't modify
> cloned skb data. It also gets rid of skb2 we only need to preserve the
> original skb for congestion notification, which is only applicable for
> ppp_async and ppp_sync.
>
> The other semantic change made here is the removal of socket accounting
> for data tranmitted out of pppol2tp_xmit. The original code leaked any
> existing socket skb accounting. We could fix this by dropping the
> original skb owner. However, this is undesirable as the packet has not
> physically left the host yet.
>
> In fact, all other tunnels in the kernel do not account skb's passing
> through to their own socket. In partciular, ESP over UDP does not do
> so and it is the closest tunnel type to PPPoL2TP. So this patch simply
> removes the socket accounting in pppol2tp_xmit. The accounting still
> applies to control packets of course.
>
> I've also added a reminder that the outgoing checksum here doesn't work.
> I suppose existing deployments don't actually enable checksums.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
I've replaced the older patch with the leak with this one,
thanks Herbert.
^ permalink raw reply
* Re: [PATCH 3/3] [PPP] L2TP: Fix skb handling in pppol2tp_xmit
From: David Miller @ 2007-09-19 17:45 UTC (permalink / raw)
To: herbert; +Cc: jchapman, mostrows, paulus, toralf.foerster, netdev
In-Reply-To: <20070919013018.GB15046@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 19 Sep 2007 09:30:18 +0800
> [PPP] pppoe: Fix double-free on skb after transmit failure
>
> When I got rid of the second packet in __pppoe_xmit I created
> a double-free on the skb because of the goto abort on failure.
> This patch removes that.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied.
^ permalink raw reply
* Re: SFQ qdisc crashes with limit of 2 packets
From: David Miller @ 2007-09-19 17:43 UTC (permalink / raw)
To: kaber; +Cc: kuznet, cebbert, netdev
In-Reply-To: <46F11F46.8060108@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Wed, 19 Sep 2007 15:08:22 +0200
> Alexey Kuznetsov wrote:
> > Hello!
> >
> >>CCed Alexey just to be safe, but I think the patch should be fine.
> >
> >
> > Yes. But what'a about limit == 1? tc prohibits this case, but it is still
> > not nice to have the bug in kernel. Plus, code remains creepy, the check
> >
> > + if (++sch->q.qlen < q->limit) {
> >
> > still looks as a scary off-by-one. I would go all the way: replace this
> > with natural:
> >
> > if (++sch->q.qlen <= q->limit) {
> >
> > and maxed q->limit at SFQ_DEPTH-2. Patch enclosed.
>
> Thats even better, thanks :)
I'll put this into my tree and wait while Alexey does his tests.
Thanks.
^ permalink raw reply
* Re: [PATCH] tehuti: driver for Tehuti 10GbE network adapters
From: 'Christoph Hellwig' @ 2007-09-19 17:41 UTC (permalink / raw)
To: Alexander Indenbaum
Cc: 'Christoph Hellwig', jeff, davem, akpm, netdev,
'Nadav Shemer', 'Andy Gospodarek'
In-Reply-To: <20070919173724.C810375CC7@mail.tehutinetworks.co.il>
On Wed, Sep 19, 2007 at 07:37:18PM +0200, Alexander Indenbaum wrote:
> In my understanding unregister_netdev(), in case netdev is still IFF_UP and
> holds irq, will call dev_close() which will call netdev->stop(), bdx_close()
> in our case. bdx_close() releases all netdev resources among others calls
> free_irq().
>
> That's why I'm pretty sure that we do not hold any reference to netdev after
> unregister_netdev() finishes and we can free_netdev() without any worry :)
>
> What do you think, does it still look fishy?
Ok, so you do irq acquire/release in open/close so that bit is fine.
The code might actually work as is, sorry for the noise.
^ 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