* Re: [PATCH ethtool 1/2] ethtool: Use inet_aton() to parse IPv4 addresses for RX n-tuple control
From: Jeff Garzik @ 2010-08-04 20:36 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1279825899.2104.28.camel@achroite.uk.solarflarecom.com>
FYI, I'm about to roll a new ethtool release for kernel 2.6.35. Are
these two patches the only outstanding ones? (they look good, will be
applied)
Jeff
P.S. The maintainer address is jgarzik@pobox.com, my standard kernel
address. jgarzik@redhat.com has a much higher latency, as it doesn't
get used very much.
^ permalink raw reply
* Re: [GIT] Networking
From: David Miller @ 2010-08-04 20:41 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
In-Reply-To: <AANLkTimxv1y3QJ7s+ghi1FFCcwnUVWT1n6dvT-NNN=Oo@mail.gmail.com>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Wed, 4 Aug 2010 12:06:47 -0700
> On Tue, Aug 3, 2010 at 8:38 PM, David Miller <davem@davemloft.net> wrote:
>>
>> Another release, another merge window, another set of networking
>> changes to merge :-)
>
> Ok, merged. But you should double-check my merge resolution fixes,
Will do, thanks a lot.
> I'm also a bit unhappy about how it introduces new warnings in very
> subtle ways.
Joe Perches presented patches to fix this (arguably always broken)
issue to James Bottomley and co. several weeks ago:
http://marc.info/?l=linux-next&m=127882494322533&w=2
And it's been, in typical SCSI subsystem maintainer fastion, in
"stall" mode ever since.
In fact, when we noticed this problem, Joe Perches said he would only
post the patches to the SCSI folks if I would "deal" with James
Bottomley. If it's to that point, well... I don't know what to say.
I know the warning is introduced by changes in my tree, but I
figured with weeks until the merge window James would be OK with
Joe's fix for the warning by then. Perhaps I was wrong.
If under my control, I would never _ever_ let something like that
linger for weeks upon weeks in my tree. 24 hour resolution, tops.
And the same goes for Joe Perches, which is why I trust him and merged
his changes which triggered the warning in the first place. I can
always count on him to do something immediately to try and fix
fallout, or in the worst case say "ok we can't resolve this just
revert my original change".
So I'm sorry, I'll never create a situation again where the SCSI
maintainer is in the critical path for getting a warning fixed. :-)
^ permalink raw reply
* Re: [PATCH 2/3] PPTP: PPP over IPv4 (Point-to-Point Tunneling Protocol)
From: xeb @ 2010-08-04 20:49 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20100804102535.37bd94c4@nehalam>
On Wed, 4 Aug 2010 10:25:35 -0700 Stephen Hemminger <shemminger@vyatta.com> wrote:
> > +static DEFINE_RWLOCK(chan_lock);
>
> A reader-writer lock is going to be slower than a spin lock
> (or RCU) for this. IF possible, could you use RCU?
>
don't know, need to think about ...
^ permalink raw reply
* Re: [PATCH ethtool 1/2] ethtool: Use inet_aton() to parse IPv4 addresses for RX n-tuple control
From: Ben Hutchings @ 2010-08-04 20:51 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linux-net-drivers
In-Reply-To: <4C59CF65.2060801@garzik.org>
On Wed, 2010-08-04 at 16:36 -0400, Jeff Garzik wrote:
> FYI, I'm about to roll a new ethtool release for kernel 2.6.35. Are
> these two patches the only outstanding ones? (they look good, will be
> applied)
Yes, those are the only ones.
> P.S. The maintainer address is jgarzik@pobox.com, my standard kernel
> address. jgarzik@redhat.com has a much higher latency, as it doesn't
> get used very much.
Sorry about that. I've changed my git-format-patch config accordingly.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH 2/3] PPTP: PPP over IPv4 (Point-to-Point Tunneling Protocol)
From: xeb @ 2010-08-04 20:51 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20100804102431.4cec4313@nehalam>
On Wed, 4 Aug 2010 10:24:31 -0700 Stephen Hemminger <shemminger@vyatta.com> wrote:
> On Wed, 04 Aug 2010 14:45:33 +0400
> xeb@mail.ru wrote:
>
> > +struct pptp_gre_header {
> > + u_int8_t flags; /* bitfield */
> > + u_int8_t ver; /* should be PPTP_GRE_VER (enhanced GRE) */
> > + u_int16_t protocol; /* should be PPTP_GRE_PROTO (ppp-encaps) */
> > + u_int16_t payload_len; /* size of ppp payload, not inc. gre header */
> > + u_int16_t call_id; /* peer's call_id for this session */
> > + u_int32_t seq; /* sequence number. Present if S==1 */
> > + u_int32_t ack; /* seq number of highest packet recieved by */
> > +
>
> Use u8, u16, u32 in kernel code.
ok
^ permalink raw reply
* Re: [iproute2] iproute2: Allow 'ip addr flush' to loop more than 10 times.
From: Stephen Hemminger @ 2010-08-04 21:00 UTC (permalink / raw)
To: greearb; +Cc: netdev, Ben Greear
In-Reply-To: <1277790959-28075-1-git-send-email-greearb@candelatech.com>
On Mon, 28 Jun 2010 22:55:59 -0700
greearb@gmail.com wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> The default remains at 10 for backwards compatibility.
>
> For instance:
> # ip addr flush dev eth2
> *** Flush remains incomplete after 10 rounds. ***
> # ip -l 20 addr flush dev eth2
> *** Flush remains incomplete after 20 rounds. ***
> # ip -loops 0 addr flush dev eth2
> #
>
> This is useful for getting rid of large numbers of IP
> addresses in scripts.
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
The current userspace driven flush behavior is crap.
There really should be an atomic flush netlink message
with kernel support.
^ permalink raw reply
* Re: [PATCH] Add ip route {save,restore}
From: Stephen Hemminger @ 2010-08-04 21:03 UTC (permalink / raw)
To: Dan Smith; +Cc: netdev
In-Reply-To: <1274460311-4036-1-git-send-email-danms@us.ibm.com>
On Fri, 21 May 2010 09:45:11 -0700
Dan Smith <danms@us.ibm.com> wrote:
> This patch adds save and restore commands to "ip route". Save dumps
> the RTNL stream to stdout which can then be passed to restore later.
> This may be helpful in some normal situations, and will allow C/R to
> migrate the routing information in userspace. Tweaking of the stream
> can be done by userspace helpers to convert between versions and adjust
> things like device indexes when restoring routes in a different
> environment.
>
> By factoring out some of the common bits of print_route() into
> filter_nlmsg(), the "save" command can use the same selection logic
> as "list," allowing the caller to save only specific routes as
> necessary.
>
> The only change since the RFC is the addition of manpage and doc
> material.
>
> Signed-off-by: Dan Smith <danms@us.ibm.com>
I think Jamal/Alexey original intent was that output of show
command could be piped back in, allowing the same kind of
save/restore without special format.
But probably over the intervening time, the output format diverged
and that isn't possible.
^ permalink raw reply
* Re: [iproute2] iproute2: Allow 'ip addr flush' to loop more than 10 times.
From: Ben Greear @ 2010-08-04 21:13 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: greearb, netdev
In-Reply-To: <20100804140012.577b2195@nehalam>
On 08/04/2010 02:00 PM, Stephen Hemminger wrote:
> On Mon, 28 Jun 2010 22:55:59 -0700
> greearb@gmail.com wrote:
>
>> From: Ben Greear<greearb@candelatech.com>
>>
>> The default remains at 10 for backwards compatibility.
>>
>> For instance:
>> # ip addr flush dev eth2
>> *** Flush remains incomplete after 10 rounds. ***
>> # ip -l 20 addr flush dev eth2
>> *** Flush remains incomplete after 20 rounds. ***
>> # ip -loops 0 addr flush dev eth2
>> #
>>
>> This is useful for getting rid of large numbers of IP
>> addresses in scripts.
>>
>> Signed-off-by: Ben Greear<greearb@candelatech.com>
>
> The current userspace driven flush behavior is crap.
> There really should be an atomic flush netlink message
> with kernel support.
No argument from me, but I've no time to figure out how
to do that properly.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: NET_NS: unregister_netdevice: waiting for lo to become free (after using openvpn) (was Re: sysfs bug when using tun with network namespaces)
From: Greg KH @ 2010-08-04 21:46 UTC (permalink / raw)
To: Michael Leun, Eric W. Biederman; +Cc: netdev, davem, linux-kernel
In-Reply-To: <20100804153543.56f6ecad@xenia.leun.net>
On Wed, Aug 04, 2010 at 03:35:43PM +0200, Michael Leun wrote:
> Hi,
>
> On Sun, 11 Jul 2010 19:29:39 +0200
> Michael Leun <lkml20100708@newton.leun.net> wrote:
>
> [...]
> > Jul 10 20:02:36 doris kernel: unregister_netdevice: waiting for lo to
> > become free. Usage count = 3 [repeated]
> >
> > Now one might say it is fault of openvpn (used OpenVPN 2.1_rc20
> > i586-suse-linux - the one in openSuSE 11.2 package), openvpn didn't
> > close some ressource and ssh does fine.
> >
> > But: should'nt kernel clean up after process when it exits?
> > And/or: Should'nt kernel clean up if last process in network namespace
> > exits - there is nothing left which might use that interface?!
> >
> > Greg KH <greg@kroah.com> wrote:
> >
> > > Yes, you are correct. Care to resend all of this to the
> > > network-namespace developer(s) and the netdev mailing list so that
> > > the correct people are notified so they can fix it all?
> >
> > [X] done - hopefully, cannot find a particular network namespace
> > developer in MAINTAINERS or source files. If such a one exists, please
> > forward.
>
> Did'nt work. Got no reaction from network mailinglist at all and bug
> still is in 2.6.35.
Eric, here's a bug with the network namespace stuff, care to work on
resolving it?
thanks,
greg k-h
^ permalink raw reply
* Compat-wireless for 2.6.35 final - 802.11, Bluetooth, Ethernet backported
From: Luis R. Rodriguez @ 2010-08-04 21:50 UTC (permalink / raw)
To: linux-wireless, linux-bluetooth, netdev-u79uwXL29TY76Z2rM5mHXA
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Linus released 2.6.35 so we get our respective compat-wireless-2.6.35
released which backports the kernel's 802.11, Bluetooth and some
Ethernet drivers down to kernels >= 2.6.27. Goal is to always backport
all drivers down to the oldest supported 2.6. kenrel release listed on
kernel.org. Some drivers are backported to even further older kernels
(ath9k should go down to 2.6.23), to enable only one driver use the
./scripts/driver-select script. You can get compat-wireless-2.6.35
from:
http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.35/compat-wireless-2.6.35-0.tar.bz2
sha1sum: a718b6377136560894e7919304d0cf7a5106815b
compat-wireless code metrics
491756 - Total lines of upstream code being pulled
1394 - backport code changes
1163 - backport code additions
231 - backport code deletions
5737 - backport from compat module
7131 - total lines of backport code
1.45 - % of code consists of backport work
Base tree: linux-2.6-allstable.git
Base tree version: v2.6.35
compat-wireless release: compat-wireless-v2.6.35-0
Since we can have extra fixes within compat.git / compat-wireless.git
for stable releases in between stable kernel extra version updates I'm
started to rely on -release_number tag postfixes to the release tag.
So this release has the -0 release number, if we get a new fix/update
on this package before 2.6.35.1 we'll have compat-wireless-2.6.35-1,
and so on.
Changes that went into the Linux kernel for this release:
http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.35/ChangeLog-2.6.35-wireless
This comes from:
git log v2.6.34..HEAD \
net/wireless/ \
net/mac80211/ \
net/rfkill/ \
drivers/net/wireless/ \
net/bluetooth/ \
drivers/net/atl1c/ \
drivers/net/atl1e/ \
drivers/net/atlx/ \
drivers/bluetooth/ \
include/linux/nl80211.h \
include/linux/rfkill.h \
include/net/cfg80211.h \
include/net/regulatory.h \
include/net/cfg80211.h
For more information see:
http://wireless.kernel.org/en/users/Download/stable
compat-wireless makes use of the compat.git tree which provides a
generic Linux kernel compatibility module which besides providing
generic kernel helpers also backports the new rfkill, pm-qos and
firmware_class stuff. The updates from compat since the 2.6.34 kernel
release are:
Hauke Mehrtens (7):
compat: backport eth_change_mtu and eth_validate_addr
compat: move kparam_{block,unblock}_sysfs_write
compat: move usb_{alloc,free}_coherent
compat: update bitops.h and wireless.h
compat: move kparam_{block,unblock}_sysfs_write
compat: backport small functions and defines
compat: use kernel pm_qos_params.h
Luis R. Rodriguez (11):
compat: add new way to backport the usage of net_device_ops
compat: add the rest of the missing netdev_attach_ops()
compat: add the ndo_select_queue for netdev_attach_ops()
compat: add compat_version read-only module parameter
Modify the compat print
Add the COMPAT_BASE_TREE and COMPAT_BASE_TREE_VERSION
Add a COMPAT_PROJECT tag
Fix the syntax for the defines passed for compat
Remove the stupid SET_NETDEVOP
compat: create the udev directories for compat_firmware file
compat: backport USHRT_MAX, SHRT_MAX and SHRT_MIN
Rajkumar Manoharan (1):
compat: Fix panic caused by NULL pointer derefence in rtnl_fill_ifinfo
compat-wireless changes since the compat-wireless-2.6.34 release are:
Bruno Randolf (1):
compat-wireless: fix 07-change-default-rate-alg.patch
Hauke Mehrtens (23):
compat-wireless: rename {free,alloc}_ieee80211 to {free,alloc}_libipw
compat-wireless: fix building of iwmc3200wifi
compat-wireless: remove some uneeded header files
compat-wireless: update config symbols
compat-wireless: add orinoco to compat-wireless
compat-wireless: remove rename {free,alloc}_ieee80211 patch
compat-wireless: refresh patch to apply again
compat-wireless: Backport changes in pcmcia system
compat-wireless: fix use of device_create
compat-wireless: use wireless_handlers for wext functions.
compat-wireless: backport convert multicast list to list_head.
compat-wireless: Remove use of sdio quirks attribute
compat-wireless: include net and trace includes form compat.
compat-wireless: refresh patches
compat-wireless: updates for orinoco
compat-wireless: backport pm_qos_{add,remove,update}_request
compat-wireless: make patches apply again
Revert "compat-wireless: fix 07-change-default-rate-alg.patch"
compat-wireless: Update Readme to reflect changes
compat-wireless: update clean scripts
compat-wireless: use /etc/init.d/ and not sudo service
compat-wireless: run refresh only on last applied directory
compat-wireless: fix build of ath5k for CONFIG_PM_SLEEP=n
Luis R. Rodriguez (77):
./scripts/admin-update.sh refresh
./scripts/admin-update.sh refres
admin-update refresh the patches
driver-select: enable listing of ath9k_htc
driver-select: fix selecting ath9k_htc
admin-update refresh
Fix patches/06-header-changes.patch
Fix patches/13-trace.patch
admin-update refresh
admin-update refresh
admin-update refresh
Update USB makefile for new driver ipheth.o
./scripts/admin-update.sh refresh
compat-wireless: make use of new netdev_attach_ops() for orinoco
scripts/admin-update.sh refresh
Make rndis_host use netdev_attach_ops()
usbnet: use netdev_attach_ops()
rndis_wlan: fix backport of netdev_attach_ops() usage
rndis_wlan: use netdev_attach_ops()
mac80211: use netdev_attach_ops()
admin-update refresh
b44: use netdev_attach_ops()
ipw2100: use netdev_attach_ops()
ipw2200: use netdev_attach_ops()
libertas: use netdev_attach_ops()
mac80211_hwsim: use netdevice_attach_ops()
bnep, atl1e, atl1c: use netdev_attach_ops()
atl1: use netdev_attach_ops()
atl2: use netdev_attach_ops()
./scripts/admin-update.sh refresh
./scripts/admin-update.sh refresh
Change admin-update.sh to use system version files
Remove double line on admin-update.sh
Split up the NOSTDINC_FLAGS into a few lines
Use the defines to tag the compat module
Fix dependency on on WEXT
Fix the CREL compat-wireless release name on top level Makefile
Fix gen-compat-autoconf.sh for new version name changes
Fix scripts/driver-select due to new version changes
Add the compat to the unload of the modules
compat-wireless: add linux-next-pending, crap patch dirs and nagometer
rm -rf drivers when running scripts/admin-update.sh
compat-wireless: add a set of pending patches for linux-wireless
compat-wireless: add the Kconfig for drivers
compat-wireless: add some Atheros crap patches
compat-wireless: run ./scripts/compat_firmware_install
compat-wireless: remove some new files upon make clean
compat-wireless: add the new versioning files to .gitignore
Revert "compat-wireless: run ./scripts/compat_firmware_install"
compat-wireless: remove pending patches as of next-20100525
compat-wireless: ./scripts/admin-update.sh refresh
compat-wireless: fix backport code calculation
compat-wireless: only copy existing Kconfig files
compat-wireless: ./scripts/admin-update.sh -p refresh
compat-wireless: fix typo for used color for nagometer
compat-wireless: add new set of pending patches for 2010-05-25
compat-wireless: update the atheros crap patches
compat-wireless: clarify usage of linux-next-cherry-pick for bleeding edge
compat-wireless: remove two pending patches now upstream
compat-wireless: add pending fix patch for ath9k
compat-wireless: fixes offsets for
07-change-default-rate-alg.patch for 2.6.35-rc1
./scripts/admin-update.sh refresh
compat-wireless: fix hunks for crap/0002-ath9k-Add-pktlog-support.patch
compat-wireless: accept extra arguments for scripts/gen-stable-release.sh
Remove sucked in patch post 2.6.35-rc1
compat-wireless: add -n -p -c support for gen-stable-release.sh
compat-wireless: optimize branch selection on gen-stable-release.sh
compat-wireless: update the usage() print for gen-stable-release.sh
compat-wireless: fix target kernel expecations on gen-stable-release.sh
compat-wireless: Drop all the linux-next-pending patches
compat-wireless: remove the crap patches
compat-wireless: refresh hunks for 2.6.35-rc2
compat-wireless: refresh hunks for 2.6.35-rc2 as of June 11 2010
compat-wireless: fix patch patches/25-multicast-list_head.patch
for BT bnet
compat-wireless: ./scripts/admin-update.sh refresh
compta-wireless: update unload script
compat-wireless: refresh patches for 2.6.36-rc6
Paul Fertser (1):
compat-wireless: driver-select: add b43 to the list
Pavel Roskin (9):
compat-wireless: disable rt2800 if crc_ccitt is not available
compat-wireless: disable wl1251 SPI and wl1271 if crc7 is not available
compat-wireless: add support for ath9k_htc
compat-wireless: update 22-multiqueue.patch for the current linux-next
compat-wireless: remove patch part dealing with net/net_namespace.h
compat-wireless: remove 13-trace.patch, it's handled in compat now
compat-wireless: remove 25-device_create.patch, it's handled by compat
compat-wireless: find the actual remote URL
compat-wireless: fix fallbacks for unknown branch, remote or remote URL
Walter Goldens (2):
compat-wireless, unload rt2800usb
compat-wireless: rt2x00 added to driver-select
Thanks to the contributors!
Luis
^ permalink raw reply
* Re: [GIT] Networking
From: David Miller @ 2010-08-04 21:53 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
In-Reply-To: <20100804.134115.260072845.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 04 Aug 2010 13:41:15 -0700 (PDT)
> From: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Wed, 4 Aug 2010 12:06:47 -0700
>
>> On Tue, Aug 3, 2010 at 8:38 PM, David Miller <davem@davemloft.net> wrote:
>>>
>>> Another release, another merge window, another set of networking
>>> changes to merge :-)
>>
>> Ok, merged. But you should double-check my merge resolution fixes,
>
> Will do, thanks a lot.
I just double-checked everything and it all looks fine, thanks
again.
^ permalink raw reply
* Re: NET_NS: unregister_netdevice: waiting for lo to become free (after using openvpn)
From: Eric W. Biederman @ 2010-08-04 22:04 UTC (permalink / raw)
To: Greg KH; +Cc: Michael Leun, netdev, davem, linux-kernel
In-Reply-To: <20100804214618.GA6289@kroah.com>
Greg KH <greg@kroah.com> writes:
> On Wed, Aug 04, 2010 at 03:35:43PM +0200, Michael Leun wrote:
>> Hi,
>>
>> On Sun, 11 Jul 2010 19:29:39 +0200
>> Michael Leun <lkml20100708@newton.leun.net> wrote:
>>
>> [...]
>> > Jul 10 20:02:36 doris kernel: unregister_netdevice: waiting for lo to
>> > become free. Usage count = 3 [repeated]
Does this repeat indefinitely, or are there only a couple of repetitions?
If this repeats indefinitely every 5 seconds or so we have a serious bug.
Otherwise we just have cleanup taking longer than it should, which isn't
ideal but it is much less severe.
>> > Now one might say it is fault of openvpn (used OpenVPN 2.1_rc20
>> > i586-suse-linux - the one in openSuSE 11.2 package), openvpn didn't
>> > close some ressource and ssh does fine.
>> >
>> > But: should'nt kernel clean up after process when it exits?
>> > And/or: Should'nt kernel clean up if last process in network namespace
>> > exits - there is nothing left which might use that interface?!
>> >
>> > Greg KH <greg@kroah.com> wrote:
>> >
>> > > Yes, you are correct. Care to resend all of this to the
>> > > network-namespace developer(s) and the netdev mailing list so that
>> > > the correct people are notified so they can fix it all?
>> >
>> > [X] done - hopefully, cannot find a particular network namespace
>> > developer in MAINTAINERS or source files. If such a one exists, please
>> > forward.
>>
>> Did'nt work. Got no reaction from network mailinglist at all and bug
>> still is in 2.6.35.
>
> Eric, here's a bug with the network namespace stuff, care to work on
> resolving it?
Greg thanks for forwarding this in my direction.
Eric
^ permalink raw reply
* Re: NET_NS: unregister_netdevice: waiting for lo to become free (after using openvpn) (was Re: sysfs bug when using tun with network namespaces)
From: Michael Leun @ 2010-08-04 22:11 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Greg KH, netdev, davem, linux-kernel
In-Reply-To: <20100804214618.GA6289@kroah.com>
Hi,
On Wed, 4 Aug 2010 14:46:18 -0700
Greg KH <greg@kroah.com> wrote:
> Eric, here's a bug with the network namespace stuff, care to work on
> resolving it?
Just in case I provide the complete scenario again below.
If I can help somehow (provide further information, test something...)
of course I'll happily do so.
In an network namespace I can use an tun/tap tunnel through ssh and
when closing that namespace then eveything is fine.
But when using openvpn (also tunnel trough tun/tap) in an network
namespace and then closing that namespace I get:
unregister_netdevice: waiting for lo to become free
[repeated]
Please see the following two examples showing that difference:
# > unshare -n /bin/bash
# > # how to setup veth device pair to get connectivity into namespace not shown here
# > tunctl -u ml -t tap1
# > ssh -o Tunnel=Ethernet -w 1:1 somewhere
[ running some traffic over tap1 not shown here ]
^d # logging out from somewhere
# > tunctl -d tap1
# > exit # logging out from shell in network namespace
Now the veth device pair used automagically vanishes and nothing
from that different network namespace remains - very well.
but
# > unshare -n /bin/bash
# > # how to setup veth device pair to get connectivity into namespace not shown here
# > openvpn --config some.config
[ running some traffic over vpn device not shown here ]
^c # stopping openvpn
# > lsof -i
# > netstat -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address
State Active UNIX domain sockets (servers and established)
Proto RefCnt Flags Type State I-Node Path
# > ps ax|grep openvpn|grep -v grep
# > # cannot find anything that suggests there is anything left from that openvpn session
# > exit # logging out from shell in network namespace
Now I get
Jul 10 20:02:36 doris kernel: unregister_netdevice: waiting for lo to
become free. Usage count = 3 [repeated]
Now one might say it is fault of openvpn (used OpenVPN 2.1_rc20
i586-suse-linux - the one in openSuSE 11.2 package - EDIT: meanwhile it
is 2.1.1, openSuSE 11.3 ), openvpn didn't close some ressource and ssh
does fine.
But: should'nt kernel clean up after process when it exits?
And/or: Should'nt kernel clean up if last process in network namespace
exits - there is nothing left which might use that interface?!
--
MfG,
Michael Leun
^ permalink raw reply
* [PATCH] platform: Facilitate the creation of pseduo-platform busses
From: Patrick Pannuto @ 2010-08-04 22:14 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org
Cc: linux-arm-msm@vger.kernel.org, linux-omap@vger.kernel.org,
damm@opensource.se, lethal@linux-sh.org, rjw@sisk.pl,
eric.y.miao@gmail.com, netdev@vger.kernel.org, Greg Kroah-Hartman,
alan, zt.tmzt
Inspiration for this comes from:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31161.html
RFC: http://lkml.org/lkml/2010/8/3/496
Patch is unchanged from the RFC. Reviews seemed generally positive
and it seemed this was desired functionality.
INTRO
As SOCs become more popular, the desire to quickly define a simple,
but functional, bus type with only a few unique properties becomes
desirable. As they become more complicated, the ability to nest these
simple busses and otherwise orchestrate them to match the actual
topology also becomes desirable.
EXAMPLE USAGE
/arch/ARCH/MY_ARCH/my_bus.c:
#include <linux/device.h>
#include <linux/platform_device.h>
struct bus_type my_bus_type = {
.name = "mybus",
};
EXPORT_SYMBOL_GPL(my_bus_type);
struct platform_device sub_bus1 = {
.name = "sub_bus1",
.id = -1,
.dev.bus = &my_bus_type,
}
EXPORT_SYMBOL_GPL(sub_bus1);
struct platform_device sub_bus2 = {
.name = "sub_bus2",
.id = -1,
.dev.bus = &my_bus_type,
}
EXPORT_SYMBOL_GPL(sub_bus2);
static int __init my_bus_init(void)
{
int error;
platform_bus_type_init(&my_bus_type);
error = bus_register(&my_bus_type);
if (error)
return error;
error = platform_device_register(&sub_bus1);
if (error)
goto fail_sub_bus1;
error = platform_device_register(&sub_bus2);
if (error)
goto fail_sub_bus2;
return error;
fail_sub_bus2:
platform_device_unregister(&sub_bus1);
fail_sub_bus2:
bus_unregister(&my_bus_type);
return error;
}
postcore_initcall(my_bus_init);
EXPORT_SYMBOL_GPL(my_bus_init);
/drivers/my_driver.c
static struct platform_driver my_driver = {
.driver = {
.name = "my-driver",
.owner = THIS_MODULE,
.bus = &my_bus_type,
},
};
/somewhere/my_device.c
static struct platform_device my_device = {
.name = "my-device",
.id = -1,
.dev.bus = &my_bus_type,
.dev.parent = &sub_bus_1.dev,
};
Notice that for a device / driver, only 3 lines were added to
switch from the platform bus to the new my_bus. This is
especially valuable if we consider supporting a legacy SOCs
and new SOCs where the same driver is used, but may need to
be on either the platform bus or the new my_bus. The above
code then becomes:
(possibly in a header)
#ifdef CONFIG_MY_BUS
#define MY_BUS_TYPE &my_bus_type
#else
#define MY_BUS_TYPE NULL
#endif
/drivers/my_driver.c
static struct platform_driver my_driver = {
.driver = {
.name = "my-driver",
.owner = THIS_MODULE,
.bus = MY_BUS_TYPE,
},
};
Which will allow the same driver to easily to used on either
the platform bus or the newly defined bus type.
This will build a device tree that mirrors the actual configuration:
/sys/bus
|-- my_bus
| |-- devices
| | |-- sub_bus1 -> ../../../devices/platform/sub_bus1
| | |-- sub_bus2 -> ../../../devices/platform/sub_bus2
| | |-- my-device -> ../../../devices/platform/sub_bus1/my-device
| |-- drivers
| | |-- my-driver
Signed-off-by: Patrick Pannuto <ppannuto@codeaurora.org>
---
drivers/base/platform.c | 30 ++++++++++++++++++++++++++----
include/linux/platform_device.h | 2 ++
2 files changed, 28 insertions(+), 4 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 4d99c8b..c86be03 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -241,7 +241,8 @@ int platform_device_add(struct platform_device *pdev)
if (!pdev->dev.parent)
pdev->dev.parent = &platform_bus;
- pdev->dev.bus = &platform_bus_type;
+ if (!pdev->dev.bus)
+ pdev->dev.bus = &platform_bus_type;
if (pdev->id != -1)
dev_set_name(&pdev->dev, "%s.%d", pdev->name, pdev->id);
@@ -482,7 +483,8 @@ static void platform_drv_shutdown(struct device *_dev)
*/
int platform_driver_register(struct platform_driver *drv)
{
- drv->driver.bus = &platform_bus_type;
+ if (!drv->driver.bus)
+ drv->driver.bus = &platform_bus_type;
if (drv->probe)
drv->driver.probe = platform_drv_probe;
if (drv->remove)
@@ -539,12 +541,12 @@ int __init_or_module platform_driver_probe(struct platform_driver *drv,
* if the probe was successful, and make sure any forced probes of
* new devices fail.
*/
- spin_lock(&platform_bus_type.p->klist_drivers.k_lock);
+ spin_lock(&drv->driver.bus->p->klist_drivers.k_lock);
drv->probe = NULL;
if (code == 0 && list_empty(&drv->driver.p->klist_devices.k_list))
retval = -ENODEV;
drv->driver.probe = platform_drv_probe_fail;
- spin_unlock(&platform_bus_type.p->klist_drivers.k_lock);
+ spin_unlock(&drv->driver.bus->p->klist_drivers.k_lock);
if (code != retval)
platform_driver_unregister(drv);
@@ -1017,6 +1019,26 @@ struct bus_type platform_bus_type = {
};
EXPORT_SYMBOL_GPL(platform_bus_type);
+/** platform_bus_type_init - fill in a pseudo-platform-bus
+ * @bus: foriegn bus type
+ *
+ * This init is basically a selective memcpy that
+ * won't overwrite any user-defined attributes and
+ * only copies things that platform bus defines anyway
+ */
+void platform_bus_type_init(struct bus_type *bus)
+{
+ if (!bus->dev_attrs)
+ bus->dev_attrs = platform_bus_type.dev_attrs;
+ if (!bus->match)
+ bus->match = platform_bus_type.match;
+ if (!bus->uevent)
+ bus->uevent = platform_bus_type.uevent;
+ if (!bus->pm)
+ bus->pm = platform_bus_type.pm;
+}
+EXPORT_SYMBOL_GPL(platform_bus_type_init);
+
int __init platform_bus_init(void)
{
int error;
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index 5417944..fa8c35a 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -79,6 +79,8 @@ extern int platform_driver_probe(struct platform_driver *driver,
#define platform_get_drvdata(_dev) dev_get_drvdata(&(_dev)->dev)
#define platform_set_drvdata(_dev,data) dev_set_drvdata(&(_dev)->dev, (data))
+extern void platform_bus_type_init(struct bus_type *);
+
extern struct platform_device *platform_create_bundle(struct platform_driver *driver,
int (*probe)(struct platform_device *),
struct resource *res, unsigned int n_res,
--
1.7.2
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply related
* Re: [PATCH net-next 09/14] tg3: Improve small packet performance
From: Anton Blanchard @ 2010-08-04 22:27 UTC (permalink / raw)
To: Matt Carlson; +Cc: davem, netdev, andy, Michael Chan
In-Reply-To: <1280784368-4226-9-git-send-email-mcarlson@broadcom.com>
Hi,
Just saw this go in:
> static inline u32 tg3_tx_avail(struct tg3_napi *tnapi)
> {
> - smp_mb();
> + /* Tell compiler to fetch tx indices from memory. */
> + barrier();
> return tnapi->tx_pending -
> ((tnapi->tx_prod - tnapi->tx_cons) & (TG3_TX_RING_SIZE - 1));
> }
Which worries me. Are we sure we don't need any ordering (eg smp_rmb)?
A compiler barrier does nothing to ensure two loads are ordered.
Anton
^ permalink raw reply
* Re: [PATCH net-next 09/14] tg3: Improve small packet performance
From: Matt Carlson @ 2010-08-04 22:46 UTC (permalink / raw)
To: Anton Blanchard
Cc: Matthew Carlson, davem@davemloft.net, netdev@vger.kernel.org,
andy@greyhouse.net, Michael Chan
In-Reply-To: <20100804222741.GA18708@kryten>
On Wed, Aug 04, 2010 at 03:27:41PM -0700, Anton Blanchard wrote:
>
> Hi,
>
> Just saw this go in:
>
> > static inline u32 tg3_tx_avail(struct tg3_napi *tnapi)
> > {
> > - smp_mb();
> > + /* Tell compiler to fetch tx indices from memory. */
> > + barrier();
> > return tnapi->tx_pending -
> > ((tnapi->tx_prod - tnapi->tx_cons) & (TG3_TX_RING_SIZE - 1));
> > }
>
> Which worries me. Are we sure we don't need any ordering (eg smp_rmb)?
> A compiler barrier does nothing to ensure two loads are ordered.
>
> Anton
The compiler barrier makes sure the loads stay roughly in the same
location. In the places where the ordering really matters, we have the
memory barrier inlined into the calling code. In the rest of the
places, we can relax the ordering requirement because the final value is
just used as an estimate.
^ permalink raw reply
* Re: [PATCH net-next 09/14] tg3: Improve small packet performance
From: Michael Chan @ 2010-08-04 22:47 UTC (permalink / raw)
To: Anton Blanchard
Cc: Matthew Carlson, davem@davemloft.net, netdev@vger.kernel.org,
andy@greyhouse.net
In-Reply-To: <20100804222741.GA18708@kryten>
On Wed, 2010-08-04 at 15:27 -0700, Anton Blanchard wrote:
> Hi,
>
> Just saw this go in:
>
> > static inline u32 tg3_tx_avail(struct tg3_napi *tnapi)
> > {
> > - smp_mb();
> > + /* Tell compiler to fetch tx indices from memory. */
> > + barrier();
> > return tnapi->tx_pending -
> > ((tnapi->tx_prod - tnapi->tx_cons) & (TG3_TX_RING_SIZE - 1));
> > }
>
> Which worries me. Are we sure we don't need any ordering (eg smp_rmb)?
> A compiler barrier does nothing to ensure two loads are ordered.
We generally only get an estimate of the available tx ring size when we
call tg3_tx_avail(), so memory barriers are not generally needed. We
put a compiler barrier there to make sure that the compiler will fetch
the tx_prod and tx_cons from memory to give us a better estimate.
In specific cases detailed in the patch description, we do need memory
barriers when we call netif_tx_stop_queue() and then check for the tx
ring. We decided to put memory barriers exactly where they're needed
instead of inside tg3_tx_avail() which is an overkill.
Thanks.
^ permalink raw reply
* Re: Yet another bridge netfilter crash
From: Changli Gao @ 2010-08-04 23:00 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Herbert Xu, Stephen Hemminger, netdev
In-Reply-To: <4C5995C2.1010909@trash.net>
On Thu, Aug 5, 2010 at 12:30 AM, Patrick McHardy <kaber@trash.net> wrote:
> Am 23.07.2010 17:26, schrieb Herbert Xu:
>> On Fri, Jul 23, 2010 at 05:17:42PM +0200, Patrick McHardy wrote:
>>>
>>>> There's also the matter of fragments jumping between bridges.
>>>
>>> Conntrack zones can be used to avoid that, but that currently needs
>>> manual configuration.
>>
>> I think this is something that we need to fix. Because as it
>> stands, it can still crash if you get the wrong nf_bridge.
>>
>> The reason is that skb->dev does not hold a ref count. So the
>> reassembly code just throws it away and always uses the dev of
>> the last fragment.
>>
>> This breaks when two bridges combine to reassemble a single
>> packet, as the nf_bridge attribute of the reassembled packet
>> may come from an skb whose device is now dead. This is then
>> used to fill in the skb->dev (via nf_bridge->physindev).
>
> We could perform a new device lookup on reassembly as we do
> when expiring a fragment queue, but we probably shouldn't even
> be reassembling fragments from different bridges. One way to
> avoid this would be to automatically assign each bridge device
> to a different conntrack zone, but conntrack zones are limited
> to 2^16 and this might also have other unwanted side-effects.
>
> Until we come up with something better the best fix seems to
> be to perform the device lookup based on the iif.
How about holding physindev and physoutdev when queueing the skbs into
frag queue, and take the skb->dev(bridge NIC) as a key when queueing
the skbs from bridges?
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Using virtio as a physical (wire-level) transport
From: Ira W. Snyder @ 2010-08-04 23:04 UTC (permalink / raw)
To: Michael S. Tsirkin, Rusty Russell; +Cc: netdev, Zang Roy, virtualization
Hello Michael, Rusty,
I'm trying to figure out how to use virtio-net and vhost-net to
communicate over a physical transport (PCI bus) instead of shared
memory (for example, qemu/kvm guest).
We've talked about this several times in the past, and I currently have
some time to devote to this again. I'm trying to figure out if virtio is
still a viable solution, or if it has been evolved such that it is
unusable for this application.
I am trying to create a generic system to allow the type of
communications described below. I would like to create something that
can be easily ported to any slave computer which meets the following
requirements:
1) it is a PCI slave (agent) (it acts like any other PCI card)
2) it has an inter-processor communications mechanism
3) it has a DMA engine
There is a reasonable amount of demand for such a system. I get
inquiries about the prototype code I posted to linux-netdev at least
once a month. This sort of system is used regularly in the
telecommunications industry, among others.
Here is a quick drawing of the system I work with. Please forgive my
poor ascii art skills.
+-----------------+
| master computer |
| | +-------------------+
| PCI slot #1 | <-- physical connection --> | slave computer #1 |
| virtio-net if#1 | | vhost-net if#1 |
| | +-------------------+
| |
| | +-------------------+
| PCI slot #2 | <-- physical connection --> | slave computer #2 |
| virtio-net if#2 | | vhost-net if#2 |
| | +-------------------+
| |
| | +-------------------+
| PCI slot #n | <-- physical connection --> | slave computer #n |
| virtio-net if#n | | vhost-net if#n |
| | +-------------------+
+-----------------+
The reason for using vhost-net on the "slave" side is because vhost-net
is the component that performs data copies. In most cases, the slave
computers are non-x86 and have DMA controllers. DMA is an absolute
necessity when copying data across the PCI bus.
Do you think virtio is a viable solution to solve this problem? If not,
can you suggest anything else?
Another reason I ask this question is that I have previously invested
several months implementing a similar solution, only to have it outright
rejected for "not being the right way". If you don't think something
like this has any hope, I'd rather not waste another month of my life.
If you can think of a solution that is likely to be "the right way", I'd
rather you told me before I implement any code.
Making my life harder since the last time I tried this, mainline commit
7c5e9ed0c (virtio_ring: remove a level of indirection) has removed the
possibility of using an alternative virtqueue implementation. The commit
message suggests that you might be willing to add this capability back.
Would this be an option?
Thanks for your time,
Ira
^ permalink raw reply
* Re: [PATCH net-next 09/14] tg3: Improve small packet performance
From: Anton Blanchard @ 2010-08-04 23:08 UTC (permalink / raw)
To: Michael Chan
Cc: Matthew Carlson, davem@davemloft.net, netdev@vger.kernel.org,
andy@greyhouse.net
In-Reply-To: <1280962049.7554.25.camel@HP1>
Hi,
> We generally only get an estimate of the available tx ring size when we
> call tg3_tx_avail(), so memory barriers are not generally needed. We
> put a compiler barrier there to make sure that the compiler will fetch
> the tx_prod and tx_cons from memory to give us a better estimate.
>
> In specific cases detailed in the patch description, we do need memory
> barriers when we call netif_tx_stop_queue() and then check for the tx
> ring. We decided to put memory barriers exactly where they're needed
> instead of inside tg3_tx_avail() which is an overkill.
Thanks Matt and Michael. I was pretty sure you were thinking about
ordering issues but wanted to double check.
Anton
^ permalink raw reply
* GIT: net-*2.6 rebased...
From: David Miller @ 2010-08-04 23:21 UTC (permalink / raw)
To: netdev; +Cc: linux-wireless, sfr
Both net-2.6 and net-next-2.6 have been rebased.
To be honest, if you've been pulling from my tree you can just keep
doing so if you want, it will look just as if I had merged Linus's
tree into net-2.6 et al.
All work will go into net-2.6 for the time being, this means only
bug fixes and such.
Once -rc1 goes out, changes can start flowing into net-next-2.6
once more.
Please adhere to these rules, it helps keep the tree stable and
preserve the limited sanity still remaining in folks like Stephen
Rothwell. :-)
Thanks.
^ permalink raw reply
* bne2 rx packet drop?
From: Rusty Russell @ 2010-08-04 23:29 UTC (permalink / raw)
To: Michael Chan; +Cc: netdev
Hi Michael (and netdev!)
I've got a customer seeing ~1000 rx packets dropped per day (on a busy
interface, bonding) via 'netstat -ni' RX-DRP's field across their 4-node
cluster. The code seems to put checksum_discard and mac_discard into
that counter, so I'm not sure what the root cause is.
Any hints? What are the conditions which cause mac_discard?
Thanks!
Rusty.
^ permalink raw reply
* Re: bne2 rx packet drop?
From: Michael Chan @ 2010-08-04 23:47 UTC (permalink / raw)
To: Rusty Russell; +Cc: netdev@vger.kernel.org
In-Reply-To: <201008050859.57659.rusty@rustcorp.com.au>
On Wed, 2010-08-04 at 16:29 -0700, Rusty Russell wrote:
> Hi Michael (and netdev!)
>
> I've got a customer seeing ~1000 rx packets dropped per day (on a busy
> interface, bonding) via 'netstat -ni' RX-DRP's field across their 4-node
> cluster. The code seems to put checksum_discard and mac_discard into
> that counter, so I'm not sure what the root cause is.
>
> Any hints? What are the conditions which cause mac_discard?
>
Please ask the customer for ethtool -S ethx. It has a number of
different counters for rx dropped packets so we can get a better idea of
what's happening.
Thanks.
^ permalink raw reply
* [PATCH] net: use the nf_bridge of the last received skb in a fragment queue
From: Changli Gao @ 2010-08-04 23:53 UTC (permalink / raw)
To: Herbert Xu
Cc: David S. Miller, Alexey Kuznetsov, Pekka Savola (ipv6),
James Morris, Hideaki YOSHIFUJI, Patrick McHardy,
Stephen Hemminger, netdev, netfilter-devel, Changli Gao
As we don't hold references to net devices in nf_bridge_info to prevent the
net devices go, we should always use the nf_bridge of the last received skb
in a fragment queue.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
---
net/ipv4/ip_fragment.c | 11 ++++++++---
net/ipv6/netfilter/nf_conntrack_reasm.c | 10 ++++++++--
net/ipv6/reassembly.c | 11 ++++++++---
3 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c
index b7c4165..cd0a630 100644
--- a/net/ipv4/ip_fragment.c
+++ b/net/ipv4/ip_fragment.c
@@ -88,7 +88,7 @@ int ip_frag_mem(struct net *net)
}
static int ip_frag_reasm(struct ipq *qp, struct sk_buff *prev,
- struct net_device *dev);
+ struct net_device *dev, struct sk_buff *curr);
struct ip4_create_arg {
struct iphdr *iph;
@@ -478,7 +478,7 @@ found:
if (qp->q.last_in == (INET_FRAG_FIRST_IN | INET_FRAG_LAST_IN) &&
qp->q.meat == qp->q.len)
- return ip_frag_reasm(qp, prev, dev);
+ return ip_frag_reasm(qp, prev, dev, skb);
write_lock(&ip4_frags.lock);
list_move_tail(&qp->q.lru_list, &qp->q.net->lru_list);
@@ -494,7 +494,7 @@ err:
/* Build a new IP datagram from all its fragments. */
static int ip_frag_reasm(struct ipq *qp, struct sk_buff *prev,
- struct net_device *dev)
+ struct net_device *dev, struct sk_buff *curr)
{
struct net *net = container_of(qp->q.net, struct net, ipv4.frags);
struct iphdr *iph;
@@ -579,6 +579,11 @@ static int ip_frag_reasm(struct ipq *qp, struct sk_buff *prev,
head->next = NULL;
head->dev = dev;
head->tstamp = qp->q.stamp;
+#ifdef CONFIG_BRIDGE_NETFILTER
+ nf_bridge_get(curr->nf_bridge);
+ nf_bridge_put(head->nf_bridge);
+ head->nf_bridge = curr->nf_bridge;
+#endif
iph = ip_hdr(head);
iph->frag_off = 0;
diff --git a/net/ipv6/netfilter/nf_conntrack_reasm.c b/net/ipv6/netfilter/nf_conntrack_reasm.c
index 098a050..b5afad3 100644
--- a/net/ipv6/netfilter/nf_conntrack_reasm.c
+++ b/net/ipv6/netfilter/nf_conntrack_reasm.c
@@ -385,7 +385,8 @@ err:
* the last and the first frames arrived and all the bits are here.
*/
static struct sk_buff *
-nf_ct_frag6_reasm(struct nf_ct_frag6_queue *fq, struct net_device *dev)
+nf_ct_frag6_reasm(struct nf_ct_frag6_queue *fq, struct net_device *dev,
+ struct sk_buff *curr)
{
struct sk_buff *fp, *op, *head = fq->q.fragments;
int payload_len;
@@ -464,6 +465,11 @@ nf_ct_frag6_reasm(struct nf_ct_frag6_queue *fq, struct net_device *dev)
head->dev = dev;
head->tstamp = fq->q.stamp;
ipv6_hdr(head)->payload_len = htons(payload_len);
+#ifdef CONFIG_BRIDGE_NETFILTER
+ nf_bridge_get(curr->nf_bridge);
+ nf_bridge_put(head->nf_bridge);
+ head->nf_bridge = curr->nf_bridge;
+#endif
/* Yes, and fold redundant checksum back. 8) */
if (head->ip_summed == CHECKSUM_COMPLETE)
@@ -622,7 +628,7 @@ struct sk_buff *nf_ct_frag6_gather(struct sk_buff *skb, u32 user)
if (fq->q.last_in == (INET_FRAG_FIRST_IN | INET_FRAG_LAST_IN) &&
fq->q.meat == fq->q.len) {
- ret_skb = nf_ct_frag6_reasm(fq, dev);
+ ret_skb = nf_ct_frag6_reasm(fq, dev, clone);
if (ret_skb == NULL)
pr_debug("Can't reassemble fragmented packets\n");
}
diff --git a/net/ipv6/reassembly.c b/net/ipv6/reassembly.c
index 545c414..9ea4308 100644
--- a/net/ipv6/reassembly.c
+++ b/net/ipv6/reassembly.c
@@ -95,7 +95,7 @@ int ip6_frag_mem(struct net *net)
}
static int ip6_frag_reasm(struct frag_queue *fq, struct sk_buff *prev,
- struct net_device *dev);
+ struct net_device *dev, struct sk_buff *curr);
/*
* callers should be careful not to use the hash value outside the ipfrag_lock
@@ -429,7 +429,7 @@ found:
if (fq->q.last_in == (INET_FRAG_FIRST_IN | INET_FRAG_LAST_IN) &&
fq->q.meat == fq->q.len)
- return ip6_frag_reasm(fq, prev, dev);
+ return ip6_frag_reasm(fq, prev, dev, skb);
write_lock(&ip6_frags.lock);
list_move_tail(&fq->q.lru_list, &fq->q.net->lru_list);
@@ -453,7 +453,7 @@ err:
* the last and the first frames arrived and all the bits are here.
*/
static int ip6_frag_reasm(struct frag_queue *fq, struct sk_buff *prev,
- struct net_device *dev)
+ struct net_device *dev, struct sk_buff *curr)
{
struct net *net = container_of(fq->q.net, struct net, ipv6.frags);
struct sk_buff *fp, *head = fq->q.fragments;
@@ -548,6 +548,11 @@ static int ip6_frag_reasm(struct frag_queue *fq, struct sk_buff *prev,
head->tstamp = fq->q.stamp;
ipv6_hdr(head)->payload_len = htons(payload_len);
IP6CB(head)->nhoff = nhoff;
+#ifdef CONFIG_BRIDGE_NETFILTER
+ nf_bridge_get(curr->nf_bridge);
+ nf_bridge_put(head->nf_bridge);
+ head->nf_bridge = curr->nf_bridge;
+#endif
/* Yes, and fold redundant checksum back. 8) */
if (head->ip_summed == CHECKSUM_COMPLETE)
^ permalink raw reply related
* Re: bne2 rx packet drop?
From: Rusty Russell @ 2010-08-05 0:08 UTC (permalink / raw)
To: Michael Chan; +Cc: netdev
In-Reply-To: <201008050859.57659.rusty@rustcorp.com.au>
On Thu, 5 Aug 2010 08:59:57 am Rusty Russell wrote:
> Hi Michael (and netdev!)
Subject should read bnx2 of course...
More coffee...
Rusty.
^ 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