* Re: rndis gadget: Inconsistent locking
From: Neil Jones @ 2010-12-08 15:11 UTC (permalink / raw)
To: linux-usb, netdev
In-Reply-To: <AANLkTik=Uui7Xk9ZfFvQQKj94ZJUJ_n+bZbTQXbe+08i@mail.gmail.com>
Sorry, stupid gmail...
Hi,
Im getting another lockdep warning when using the RNDIS gadget:
WARNING: at kernel/softirq.c:98 ___local_bh_disable+0xc4/0xd0()
Modules linked in: g_ether
Call trace:
[<40003bf8>] _show_stack+0x68/0x7c
[<40003c20>] _dump_stack+0x14/0x28
[<40013c3c>] _warn_slowpath_common+0x5c/0x7c
[<40013c74>] _warn_slowpath_null+0x18/0x2c
[<4001b17c>] ___local_bh_disable+0xc0/0xd0
[<4001b1a0>] _local_bh_disable+0x14/0x28
[<402e57f8>] __raw_spin_lock_bh+0x18/0x54
[<40257f4c>] _dev_txq_stats_fold+0x7c/0x13c
[<402580c4>] _dev_get_stats+0xb8/0xc0
[<781d4e60>] _rndis_msg_parser+0x288/0xa04 [g_ether]
[<781d5600>] _rndis_command_complete+0x24/0x70 [g_ether]
[<401d66fc>] _dwc_otg_request_done+0xd8/0x220
[<401d928c>] _ep0_complete_request+0x3f4/0x578
[<401d95bc>] _handle_ep0+0x1ac/0x146c
[<401daf7c>] _dwc_otg_pcd_handle_in_ep_intr+0x1c0/0x8bc
[<401db8dc>] _dwc_otg_pcd_handle_intr+0x264/0x294
[<401d6288>] _dwc_otg_pcd_irq+0x10/0x30
[<40054cf4>] _handle_IRQ_event+0x4c/0x184
[<40057b4c>] _handle_level_irq+0xac/0x15c
[<4000b204>] _metag_soc_irq_demux+0xac/0xb4
[<40002dd4>] _do_IRQ+0x4c/0x78
[<40004000>] _trigger_handler+0x38/0xac
[<40000b18>] ___TBIBoingVec+0xc/0x10
[<40003588>] _cpu_idle+0x54/0x78
no locks held by swapper/0.
---[ end trace 77ac3cfee0ae5b25 ]---
It looks like we are calling spin_lock_bh in the completion function
which is running in hard_irq, I think the driver should defer handling
this msg (and maybe all requests) to a workqueue?
Cheers
Neil
On Wed, Dec 8, 2010 at 3:03 PM, Neil Jones <neiljay@gmail.com> wrote:
> Hi,
>
> Im getting another lockdep warning when using the RNDIS gadget:
>
> WARNING: at kernel/softirq.c:98 ___local_bh_disable+0xc4/0xd0()
> Modules linked in: g_ether
>
> Call trace:
> [<40003bf8>] _show_stack+0x68/0x7c
> [<40003c20>] _dump_stack+0x14/0x28
> [<40013c3c>] _warn_slowpath_common+0x5c/0x7c
> [<40013c74>] _warn_slowpath_null+0x18/0x2c
> [<4001b17c>] ___local_bh_disable+0xc0/0xd0
> [<4001b1a0>] _local_bh_disable+0x14/0x28
> [<402e57f8>] __raw_spin_lock_bh+0x18/0x54
> [<40257f4c>] _dev_txq_stats_fold+0x7c/0x13c
> [<402580c4>] _dev_get_stats+0xb8/0xc0
> [<781d4e60>] _rndis_msg_parser+0x288/0xa04 [g_ether]
> [<781d5600>] _rndis_command_complete+0x24/0x70 [g_ether]
> [<401d66fc>] _dwc_otg_request_done+0xd8/0x220
> [<401d928c>] _ep0_complete_request+0x3f4/0x578
> [<401d95bc>] _handle_ep0+0x1ac/0x146c
> [<401daf7c>] _dwc_otg_pcd_handle_in_ep_intr+0x1c0/0x8bc
> [<401db8dc>] _dwc_otg_pcd_handle_intr+0x264/0x294
> [<401d6288>] _dwc_otg_pcd_irq+0x10/0x30
> [<40054cf4>] _handle_IRQ_event+0x4c/0x184
> [<40057b4c>] _handle_level_irq+0xac/0x15c
> [<4000b204>] _metag_soc_irq_demux+0xac/0xb4
> [<40002dd4>] _do_IRQ+0x4c/0x78
> [<40004000>] _trigger_handler+0x38/0xac
> [<40000b18>] ___TBIBoingVec+0xc/0x10
> [<40003588>] _cpu_idle+0x54/0x78
>
> no locks held by swapper/0.
> ---[ end trace 77ac3cfee0ae5b25 ]---
>
> It
>
^ permalink raw reply
* Re: Polling on sockets in kernel space and struct file
From: Martin Lucina @ 2010-12-08 15:16 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Martin Sustrik, netdev
In-Reply-To: <1291820573.2883.56.camel@edumazet-laptop>
Hi Eric,
oddly enough our BUG at fs/inode.c seems to have gone away; may be a race
of some sort...
> you could call sock_map_fd() then :
>
>
> int fd = sock_map_fd(sock, flags);
> struct file *file = NULL;
>
> if (fd != -1) {
> file = fget(fd);
> sys_close(fd); /* still racy */
> }
>
> if (file) ...
>
> Take a look at net/9p/trans_fd.c
Interesting approach.
We're currently doing the following -- we add this function to
net/socket.c:
int sock_map_anon(struct socket *sock, const char *name, int flags)
{
struct file *newfile;
newfile = anon_inode_getfile(name, &socket_file_ops, sock, flags);
sock->file = newfile;
return 0;
}
and then call it instead of sock_map_fd() from our sock_create():
/* Create peer socket and associated file structure */
rc = sock_create_kern(PF_INET, SOCK_STREAM, IPPROTO_TCP, &sp->peer);
if (rc < 0)
goto out;
rc = sock_map_anon(sp->peer, "[sp]", 0);
if (rc < 0)
goto out_release;
Is this a valid approach to achieve the same thing?
It's not clear what, if anything special we need to do to correctly release
the anonymous inode when we are releasing our socket... is
sock_release(sp->peer) sufficient?
Also, I see in 9p/trans_fd.c that it's using get_file() to increment the
file refcount; do we need to do this for all sockets/files we create in
kernel space or is this only for the sys_close() hack?
Thanks,
-mato
^ permalink raw reply
* Re: [PATCH] ss: Change "do now" to "do not" in ss(8), -n option
From: Stephen Hemminger @ 2010-12-08 15:55 UTC (permalink / raw)
To: Petr Sabata; +Cc: netdev
In-Reply-To: <1291816149-15782-1-git-send-email-psabata@redhat.com>
On Wed, 8 Dec 2010 14:49:09 +0100
Petr Sabata <psabata@redhat.com> wrote:
> A small typo fix.
>
> ---
> man/man8/ss.8 | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/man/man8/ss.8 b/man/man8/ss.8
> index f261cf2..b309df2 100644
> --- a/man/man8/ss.8
> +++ b/man/man8/ss.8
> @@ -26,7 +26,7 @@ Show summary of options.
> Output version information.
> .TP
> .B \-n, \-\-numeric
> -Do now try to resolve service names.
> +Do not try to resolve service names.
> .TP
> .B \-r, \-\-resolve
> Try to resolve numeric address/ports.
applied
--
^ permalink raw reply
* Re: pull request: wireless-2.6 2010-12-03
From: David Miller @ 2010-12-08 16:14 UTC (permalink / raw)
To: linville; +Cc: linux-kernel, netdev, linux-wireless
In-Reply-To: <20101203201602.GE2348@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Fri, 3 Dec 2010 15:16:02 -0500
> This is a batch of fixes intended for 2.6.37. There are a number of
> small fixes that speak for themselves. Also included are a small patch
> for ar9170 to advertise Wi-Fi Peer-to-peer capability -- not truly a
> fix, but helpful for those developing the related userland bits and
> harmless to everyone else. There are also some endian related patches
> for ath9k from Felix that are a bit large, but they mostly just refactor
> some tables in order to fix an endian problem that can result in invalid
> regulatory settings on some boxes.
>
> Also includes are some Bluetooth patches via Gustavo Padovan:
>
> "Here goes 3 simple patches intended to 2.6.37. First one is from myself
> and fix some trivial return values. Then we also have a fix from Stefan
> Seyfried on btusb to avoid emitting an err when we USB is autosupended.
> Last, a patch from Bala Shanmugam that fix the firmware loading process
> for the ath3k driver."
>
> Please let me know if there are problems!
Pulled, thanks John.
^ permalink raw reply
* Re: (Lack of) specification for RX n-tuple filtering
From: Vladislav Zolotarov @ 2010-12-08 16:24 UTC (permalink / raw)
To: Ben Hutchings
Cc: Dimitris Michailidis, Peter Waskiewicz, netdev@vger.kernel.org,
David Miller
In-Reply-To: <1283870637.2270.10.camel@achroite.uk.solarflarecom.com>
> > It's a bit worse than that. Currently one can only append filters, not
> > insert at a given position, as ethtool_rx_ntuple doesn't have an index
> > field. For devices that use TCAMs, where position matters, it's quite an
> > obstacle. It also means one cannot modify an existing filter by specifying
> > a new filter for the same index.
>
> It looks like drivers for devices that use TCAMs should implement the
> RXNFC interface instead.
>
Ben, from ethtool manpage it sounds like RXNFC option defines the way
the RSS hash should be calculated, while SRXNTUPLE is meant to control
the destination Rx queue for a stream specified by a filter/filters. The
semantics for a specification of the steam is also quite different. For
instance, how do u define a rule to drop all packets with source IP
address 192.168.10.200 by means of RXNFC? While with SRXNTUPLE it's
straight forward. So, if I understood the semantics of both interfaces
correctly, there is a very limited range of functionality where they may
replace one another. Pls., correct me if I'm wrong.
I also agree with Dimitris: what we have here is an offload of some
Netfilter functionality to HW. Regardless the HW implementation (TCAM or
not) if it's allowed to configure more than one rule for the same
protocol the ordering of filtering rules is important: for instance if u
change the order of applying the rules in the example below the result
of the filtering for the traffic with both VLAN 4 and destination port
3000 will be different.
ethtool -U ethX flow-type tcp4 vlan 4 action 0
ethtool -U ethX flow-type tcp4 dst-port 3000 action 3
By the way it's also unclear from the ethtool man page if it's allowed
to configure more than one rule for the same protocol. If it's not then
the above example is void... ;) However, if we want to define a proper
filtering interface I think we shouldn't restrict the driver
implementation from defining a set of rules for the same protocol,
allowing not to though.
So, I think that attaching an index to each rule could be a good idea -
this would allow us both inserting rules at the desired positions in the
filtering rule table and editing the existing rules.
It's also unclear what is the relation between RXNFC and SRXNTUPLE. The
last in general may override the decision made based on the hash result.
So, it sounds like applying rules of SRXNTUPLE should come before
applying the RSS logic and only if there was no match RSS should be
applied to that frame. Do I get it right?
Pls., comment.
thanks,
vlad
^ permalink raw reply
* Re: [34/44] Limit sysctl_tcp_mem and sysctl_udp_mem initializers to prevent integer overflows.
From: David Miller @ 2010-12-08 16:25 UTC (permalink / raw)
To: eric.dumazet
Cc: gregkh, torvalds, linux-kernel, stable, stable-review, akpm, alan,
holt, w, netdev, linux-sctp, kuznet, pekkas, jmorris, yoshfuji,
kaber, vladislav.yasevich, sri
In-Reply-To: <1291787445.5324.64.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 08 Dec 2010 06:50:45 +0100
> Le mardi 07 décembre 2010 à 20:16 -0800, Greg KH a écrit :
>> On Tue, Dec 07, 2010 at 05:22:34PM -0800, Linus Torvalds wrote:
>> > On Tue, Dec 7, 2010 at 4:04 PM, Greg KH <gregkh@suse.de> wrote:
>> > >
>> > > From: Robin Holt <holt@sgi.com>
>> > >
>> > > [ Problem was fixed differently upstream. -DaveM ]
>> >
>> > Gaah. I'd really like to see more of a description for things like
>> > this. A commit ID for the alternate fix, or at least a few words about
>> > the different fix or reason why upstream doesn't need the stable
>> > commit.
>>
>> I'll let David confirm this, he's the one who sent it to me :)
>
> upstream uses commit 8d987e5c7510 (net: avoid limits overflow)
>
> This commit is a bit more untrusive for stable kernels :
>
> It depends on :
> a9febbb4bd13 (sysctl: min/max bounds are optional)
> 27b3d80a7b6a (sysctl: fix min/max handling in __do_proc_doulongvec_minmax())
Yep, this is the case. Greg, you can add a reference to:
a9febbb4bd13
27b3d80a7b6a
8d987e5c7510
in my "[ ... ]" in the commit message to clear this up.
^ permalink raw reply
* Re: (Lack of) specification for RX n-tuple filtering
From: David Miller @ 2010-12-08 16:39 UTC (permalink / raw)
To: vladz; +Cc: bhutchings, dm, peter.p.waskiewicz.jr, netdev
In-Reply-To: <1291825443.31064.193.camel@lb-tlvb-vladz>
From: "Vladislav Zolotarov" <vladz@broadcom.com>
Date: Wed, 8 Dec 2010 18:24:03 +0200
> I also agree with Dimitris: what we have here is an offload of some
> Netfilter functionality to HW. Regardless the HW implementation (TCAM or
> not) if it's allowed to configure more than one rule for the same
> protocol the ordering of filtering rules is important: for instance if u
> change the order of applying the rules in the example below the result
> of the filtering for the traffic with both VLAN 4 and destination port
> 3000 will be different.
It's not the same, this whole ordering thing you expect in netfilter
land is simply not present in these hardware implementations.
The hardware does a parallel TCAM match lookup, and whatever matches
is used.
Some hardware does link-level protocol lookups first, then L3/L4 later
in the RX path right before computing the hash and selecting an RX
queue.
There really is no ordering available, so let's not pretend it can be
used "just like" netfilter rules.
As per the difference between the various ethtool facilities, this
just represents the fact that whats available to offload differs
per device. The best we can do is encapsulate commonality as best
as we can, but each interface essentially represents what one
major chipset provides.
^ permalink raw reply
* Re: [PATCH net-2.6] CAIF: Fix U5500 compile error for shared memory driver
From: David Miller @ 2010-12-08 16:40 UTC (permalink / raw)
To: sjur.brandeland; +Cc: netdev, kim.xx.lilliestierna
In-Reply-To: <1291144282-2908-1-git-send-email-sjur.brandeland@stericsson.com>
From: sjur.brandeland@stericsson.com
Date: Tue, 30 Nov 2010 20:11:22 +0100
> From: Kim Lilliestierna XX <kim.xx.lilliestierna@stericsson.com>
>
> Rearrange pr_fmt so it compiles.
>
> Signed-off-by: Sjur Braendeland <sjur.brandeland@stericsson.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 2.6.36] vlan: Avoid hwaccel vlan packets when vid not used
From: David Miller @ 2010-12-08 16:47 UTC (permalink / raw)
To: eric.dumazet; +Cc: lkml20101129, greearb, linux-kernel, netdev, jesse, stable
In-Reply-To: <1291200914.2856.546.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 01 Dec 2010 11:55:14 +0100
Greg/-stable, please integrate this patch from Eric into 2.6.36 if you
haven't already done so.
Thanks!
> [PATCH v2 2.6.36] vlan: Avoid hwaccel vlan packets when vid not used.
>
> Normally hardware accelerated vlan packets are quickly dropped if
> there is no corresponding vlan device configured. The one exception
> is promiscuous mode, where we allow all of these packets through so
> they can be picked up by tcpdump. However, this behavior causes a
> crash if we actually try to receive these packets. This fixes that
> crash by ignoring packets with vids not corresponding to a configured
> device in the vlan hwaccel routines and then dropping them before they
> get to consumers in the network stack.
>
> Reported-by: Ben Greear <greearb@candelatech.com>
> Signed-off-by: Jesse Gross <jesse@nicira.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Tested-by: Michael Leun <lkml20101129@newton.leun.net>
> ---
> v2: survives to tcpdump :)
>
> net/core/dev.c | 10 ++++++++++
> net/8021q/vlan_core.c | 3 +++
> 2 files changed, 13 insertions(+)
>
> --- linux-2.6.36/net/core/dev.c.orig
> +++ linux-2.6.36/net/core/dev.c
> @@ -2891,6 +2891,15 @@
> ncls:
> #endif
>
> + /* If we got this far with a hardware accelerated VLAN tag, it means
> + * that we were put in promiscuous mode but nobody is interested in
> + * this vid. Drop the packet now to prevent it from getting propagated
> + * to other parts of the stack that won't know how to deal with packets
> + * tagged in this manner.
> + */
> + if (unlikely(vlan_tx_tag_present(skb)))
> + goto bypass;
> +
> /* Handle special case of bridge or macvlan */
> rx_handler = rcu_dereference(skb->dev->rx_handler);
> if (rx_handler) {
> @@ -2927,6 +2936,7 @@
> }
> }
>
> +bypass:
> if (pt_prev) {
> ret = pt_prev->func(skb, skb->dev, pt_prev, orig_dev);
> } else {
> --- linux-2.6.36/net/8021q/vlan_core.c.orig
> +++ linux-2.6.36/net/8021q/vlan_core.c
> @@ -43,6 +43,9 @@
> struct net_device *dev = skb->dev;
> struct vlan_rx_stats *rx_stats;
>
> + if (unlikely(!is_vlan_dev(dev)))
> + return 0;
> +
> skb->dev = vlan_dev_info(dev)->real_dev;
> netif_nit_deliver(skb);
>
>
>
^ permalink raw reply
* Re: [net-next-2.6 PATCH] enic: Bug Fix: Pass napi reference to the isr that services receive queue
From: David Miller @ 2010-12-08 16:52 UTC (permalink / raw)
To: vkolluri; +Cc: netdev, roprabhu, dwang2
In-Reply-To: <20101202070833.4213.8072.stgit@savbu-pc100.cisco.com>
From: Vasanthy Kolluri <vkolluri@cisco.com>
Date: Wed, 01 Dec 2010 23:08:33 -0800
> From: Vasanthy Kolluri <vkolluri@cisco.com>
>
> Pass reference to napi instead of enic device to the isr that services receive queue.
>
> Signed-off-by: Vasanthy Kolluri <vkolluri@cisco.com>
> Signed-off-by: Roopa Prabhu <roprabhu@cisco.com>
> Signed-off-by: David Wang <dwang2@cisco.com>
This is a pretty simple and real bug fix, so I'd rather you resubmit this
targetted for net-2.6 instead of net-next-2.6
It won't apply as-is to net-2.6 because the enic driver version number
is different there.
Thanks.
^ permalink raw reply
* Re: [PATCH 2/2] atm: lanai: use kernel's '%pM' format option to print MAC
From: David Miller @ 2010-12-08 16:53 UTC (permalink / raw)
To: andy.shevchenko; +Cc: linux-kernel, netdev, chas, linux-atm-general
In-Reply-To: <1291293908-29180-2-git-send-email-andy.shevchenko@gmail.com>
From: Andy Shevchenko <andy.shevchenko@gmail.com>
Date: Thu, 2 Dec 2010 14:45:08 +0200
> Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/1] arcvmac submit #4a.
From: David Miller @ 2010-12-08 17:00 UTC (permalink / raw)
To: andreas.fenkart; +Cc: netdev
In-Reply-To: <1291296112-27784-1-git-send-email-andreas.fenkart@streamunlimited.com>
From: Andreas Fenkart <andreas.fenkart@streamunlimited.com>
Date: Thu, 2 Dec 2010 14:21:52 +0100
>
> Signed-off-by: Andreas Fenkart <andreas.fenkart@streamunlimited.com>
Generates many warnings on 64-bit platforms, also doesn't build on any
platform because it uses interfaces we removed a long time ago
(multicast count and list).
If you want anyone to take your submission seriously, at the very
least you should at least test the build against current sources
before submitting.
drivers/net/arcvmac.c: In function ‘vmac_ioctl’:
drivers/net/arcvmac.c:333: warning: passing argument 2 of ‘phy_mii_ioctl’ from incompatible pointer type
include/linux/phy.h:511: note: expected ‘struct ifreq *’ but argument is of type ‘struct mii_ioctl_data *’
drivers/net/arcvmac.c: In function ‘vmacether_get_drvinfo’:
drivers/net/arcvmac.c:344: warning: format ‘%x’ expects type ‘unsigned int’, but argument 4 has type ‘resource_size_t’
drivers/net/arcvmac.c: In function ‘alloc_buffers_unlocked’:
drivers/net/arcvmac.c:966: warning: cast from pointer to integer of different size
drivers/net/arcvmac.c:966: warning: cast from pointer to integer of different size
drivers/net/arcvmac.c: In function ‘create_multicast_filter’:
drivers/net/arcvmac.c:1260: error: ‘struct net_device’ has no member named ‘mc_count’
drivers/net/arcvmac.c:1264: error: ‘struct net_device’ has no member named ‘mc_list’
drivers/net/arcvmac.c:1264: error: dereferencing pointer to incomplete type
drivers/net/arcvmac.c:1265: error: dereferencing pointer to incomplete type
drivers/net/arcvmac.c: In function ‘vmac_set_multicast_list’:
drivers/net/arcvmac.c:1293: error: ‘struct net_device’ has no member named ‘mc_count’
drivers/net/arcvmac.c: In function ‘vmac_probe’:
drivers/net/arcvmac.c:1438: warning: format ‘%08x’ expects type ‘unsigned int’, bu
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2] can: add slcan driver for serial/USB-serial CAN adapters
From: David Miller @ 2010-12-08 17:04 UTC (permalink / raw)
To: socketcan-fJ+pQTUTwRTk1uMJSBkQmQ
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
alan-qBU/x9rampVanCEyBjwyrvXRex20P6io
In-Reply-To: <4CF80857.1000903-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
From: Oliver Hartkopp <socketcan-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
Date: Thu, 02 Dec 2010 21:57:59 +0100
> This patch adds support for serial/USB-serial CAN adapters implementing the
> LAWICEL ASCII protocol for CAN frame transport over serial lines.
>
> The driver implements the SLCAN line discipline and is heavily based on the
> slip.c driver. Therefore the code style remains similar to slip.c to be able
> to apply changes of the SLIP driver to the SLCAN driver easily.
>
> For more details see the slcan Kconfig entry.
>
> Signed-off-by: Oliver Hartkopp <socketcan-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 0/2] New jhash function
From: David Miller @ 2010-12-08 17:09 UTC (permalink / raw)
To: kadlec; +Cc: linux-kernel, netdev, netfilter-devel, torvalds, rusty
In-Reply-To: <1291379941-31565-1-git-send-email-kadlec@blackhole.kfki.hu>
From: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Date: Fri, 3 Dec 2010 13:38:59 +0100
> The current jhash.h implements the lookup2() hash function by Bob Jenkins.
> However, lookup2() is outdated as Bob wrote a new hash function called
> lookup3(). There is a longer comparison of those two and other hash
> functions at http://burtleburtle.net/bob/hash/doobs.html.
>
> Please consider applying the following patches.
Patch #1 is already in the net-next-2.6 tree, and as long as there are
no major objections to the general crowd (including Rusty et al.) I am
happy to put patch #2 into my tree as well.
Rusty, does the current version of patch #2 look good to you?
Thanks!
^ permalink raw reply
* Re: rndis gadget: Inconsistent locking
From: Michał Nazarewicz @ 2010-12-08 17:15 UTC (permalink / raw)
To: linux-usb, netdev, Neil Jones
In-Reply-To: <AANLkTi==UqNNzokLcLWDpjM0cqM6aXjppsi4p6ogMAqX@mail.gmail.com>
On Wed, 08 Dec 2010 16:11:30 +0100, Neil Jones <neiljay@gmail.com> wrote:
> Im getting another lockdep warning when using the RNDIS gadget:
>
> WARNING: at kernel/softirq.c:98 ___local_bh_disable+0xc4/0xd0()
> Modules linked in: g_ether
>
> Call trace:
> [<40003bf8>] _show_stack+0x68/0x7c
> [<40003c20>] _dump_stack+0x14/0x28
> [<40013c3c>] _warn_slowpath_common+0x5c/0x7c
> [<40013c74>] _warn_slowpath_null+0x18/0x2c
> [<4001b17c>] ___local_bh_disable+0xc0/0xd0
> [<4001b1a0>] _local_bh_disable+0x14/0x28
> [<402e57f8>] __raw_spin_lock_bh+0x18/0x54
> [<40257f4c>] _dev_txq_stats_fold+0x7c/0x13c
> [<402580c4>] _dev_get_stats+0xb8/0xc0
> [<781d4e60>] _rndis_msg_parser+0x288/0xa04 [g_ether]
> [<781d5600>] _rndis_command_complete+0x24/0x70 [g_ether]
> [<401d66fc>] _dwc_otg_request_done+0xd8/0x220
> [<401d928c>] _ep0_complete_request+0x3f4/0x578
> [<401d95bc>] _handle_ep0+0x1ac/0x146c
> [<401daf7c>] _dwc_otg_pcd_handle_in_ep_intr+0x1c0/0x8bc
> [<401db8dc>] _dwc_otg_pcd_handle_intr+0x264/0x294
> [<401d6288>] _dwc_otg_pcd_irq+0x10/0x30
> [<40054cf4>] _handle_IRQ_event+0x4c/0x184
> [<40057b4c>] _handle_level_irq+0xac/0x15c
> [<4000b204>] _metag_soc_irq_demux+0xac/0xb4
> [<40002dd4>] _do_IRQ+0x4c/0x78
> [<40004000>] _trigger_handler+0x38/0xac
> [<40000b18>] ___TBIBoingVec+0xc/0x10
> [<40003588>] _cpu_idle+0x54/0x78
>
> no locks held by swapper/0.
> ---[ end trace 77ac3cfee0ae5b25 ]---
Known problem.
> It looks like we are calling spin_lock_bh in the completion function
> which is running in hard_irq, I think the driver should defer handling
> this msg (and maybe all requests) to a workqueue?
Does this help: <https://patchwork.kernel.org/patch/195562/>?
--
Best regards, _ _
| Humble Liege of Serenely Enlightened Majesty of o' \,=./ `o
| Computer Science, Michał "mina86" Nazarewicz (o o)
+----[mina86*mina86.com]---[mina86*jabber.org]----ooO--(_)--Ooo--
^ permalink raw reply
* Re: (Lack of) specification for RX n-tuple filtering
From: Ben Hutchings @ 2010-12-08 17:22 UTC (permalink / raw)
To: Vladislav Zolotarov
Cc: Dimitris Michailidis, Peter Waskiewicz, netdev@vger.kernel.org,
David Miller
In-Reply-To: <1291825443.31064.193.camel@lb-tlvb-vladz>
On Wed, 2010-12-08 at 18:24 +0200, Vladislav Zolotarov wrote:
> > > It's a bit worse than that. Currently one can only append filters, not
> > > insert at a given position, as ethtool_rx_ntuple doesn't have an index
> > > field. For devices that use TCAMs, where position matters, it's quite an
> > > obstacle. It also means one cannot modify an existing filter by specifying
> > > a new filter for the same index.
> >
> > It looks like drivers for devices that use TCAMs should implement the
> > RXNFC interface instead.
> >
>
> Ben, from ethtool manpage it sounds like RXNFC option defines the way
> the RSS hash should be calculated, while SRXNTUPLE is meant to control
> the destination Rx queue for a stream specified by a filter/filters.
By 'RXNFC interface' I mean ETHTOOL_{G,S}RXCLS* and not
ETHTOOL_{G,S}RXFH which wrongly share (part of) the same structure..
> The
> semantics for a specification of the steam is also quite different. For
> instance, how do u define a rule to drop all packets with source IP
> address 192.168.10.200 by means of RXNFC?
Something like this, I think:
struct ethtool_rxnfc insert_rule = {
.cmd = ETHTOOL_SRXCLSRLINS,
.flow_type = IP_USER_SPEC,
.fs = {
.flow_type = IP_USER_SPEC,
.h_u.usr_ip4_spec = {
.ip4src = inet_aton("192.168.10.200"),
.ip_ver = ETH_RX_NFC_IP4
},
.m_u.usr_ip4_spec = {
.ip4dst = 0xffffffff,
.l4_4_bytes = 0xffffffff,
.tos = 0xff,
.proto = 0xff
},
.ring_cookie = RX_CLS_FLOW_DISC,
.location = 0,
}
};
[...]
> I also agree with Dimitris: what we have here is an offload of some
> Netfilter functionality to HW. Regardless the HW implementation (TCAM or
> not) if it's allowed to configure more than one rule for the same
> protocol the ordering of filtering rules is important: for instance if u
> change the order of applying the rules in the example below the result
> of the filtering for the traffic with both VLAN 4 and destination port
> 3000 will be different.
Our hardware (and, I suspect, the ixgbe hardware) has hash tables for
specific types of matching. There is some control of precedence between
different types of match, but that's all.
> ethtool -U ethX flow-type tcp4 vlan 4 action 0
> ethtool -U ethX flow-type tcp4 dst-port 3000 action 3
>
> By the way it's also unclear from the ethtool man page if it's allowed
> to configure more than one rule for the same protocol. If it's not then
> the above example is void... ;)
It's allowed, but precedence is unspecified.
> However, if we want to define a proper
> filtering interface I think we shouldn't restrict the driver
> implementation from defining a set of rules for the same protocol,
> allowing not to though.
>
> So, I think that attaching an index to each rule could be a good idea -
> this would allow us both inserting rules at the desired positions in the
> filtering rule table and editing the existing rules.
This really sounds like the RXNFC interface.
> It's also unclear what is the relation between RXNFC and SRXNTUPLE. The
> last in general may override the decision made based on the hash result.
> So, it sounds like applying rules of SRXNTUPLE should come before
> applying the RSS logic and only if there was no match RSS should be
> applied to that frame. Do I get it right?
That's right.
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: (Lack of) specification for RX n-tuple filtering
From: Ben Hutchings @ 2010-12-08 17:29 UTC (permalink / raw)
To: David Miller; +Cc: vladz, dm, peter.p.waskiewicz.jr, netdev
In-Reply-To: <20101208.083921.71108761.davem@davemloft.net>
On Wed, 2010-12-08 at 08:39 -0800, David Miller wrote:
> From: "Vladislav Zolotarov" <vladz@broadcom.com>
> Date: Wed, 8 Dec 2010 18:24:03 +0200
>
> > I also agree with Dimitris: what we have here is an offload of some
> > Netfilter functionality to HW. Regardless the HW implementation (TCAM or
> > not) if it's allowed to configure more than one rule for the same
> > protocol the ordering of filtering rules is important: for instance if u
> > change the order of applying the rules in the example below the result
> > of the filtering for the traffic with both VLAN 4 and destination port
> > 3000 will be different.
>
> It's not the same, this whole ordering thing you expect in netfilter
> land is simply not present in these hardware implementations.
>
> The hardware does a parallel TCAM match lookup, and whatever matches
> is used.
I think the match with the lowest index wins, which is why it's possible
to specify the rule's index (location) with ETHTOOL_SRXCLSRLINS and why
Peter defined new commands without that for use with the ixgbe driver.
> Some hardware does link-level protocol lookups first, then L3/L4 later
> in the RX path right before computing the hash and selecting an RX
> queue.
>
> There really is no ordering available, so let's not pretend it can be
> used "just like" netfilter rules.
>
> As per the difference between the various ethtool facilities, this
> just represents the fact that whats available to offload differs
> per device. The best we can do is encapsulate commonality as best
> as we can, but each interface essentially represents what one
> major chipset provides.
I think the interfaces are actually somewhat more flexible than any of
the current implementations.
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: (Lack of) specification for RX n-tuple filtering
From: David Miller @ 2010-12-08 17:31 UTC (permalink / raw)
To: bhutchings; +Cc: vladz, dm, peter.p.waskiewicz.jr, netdev
In-Reply-To: <1291829364.2560.24.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 08 Dec 2010 17:29:24 +0000
> I think the interfaces are actually somewhat more flexible than any of
> the current implementations.
Yeah you're probably right.
^ permalink raw reply
* Re: (Lack of) specification for RX n-tuple filtering
From: Vladislav Zolotarov @ 2010-12-08 17:31 UTC (permalink / raw)
To: David Miller
Cc: bhutchings@solarflare.com, dm@chelsio.com,
peter.p.waskiewicz.jr@intel.com, netdev@vger.kernel.org
In-Reply-To: <20101208.083921.71108761.davem@davemloft.net>
> > I also agree with Dimitris: what we have here is an offload of some
> > Netfilter functionality to HW. Regardless the HW implementation (TCAM or
> > not) if it's allowed to configure more than one rule for the same
> > protocol the ordering of filtering rules is important: for instance if u
> > change the order of applying the rules in the example below the result
> > of the filtering for the traffic with both VLAN 4 and destination port
> > 3000 will be different.
>
> It's not the same, this whole ordering thing you expect in netfilter
> land is simply not present in these hardware implementations.
>
> The hardware does a parallel TCAM match lookup, and whatever matches
> is used.
So, u say that in scope of a single protocol all rules create a set
which ordering is a vendor specific and the same configuration of
n-tuple rules may generate different results for the same traffic on
NICs from different vendors? Don't u think it's confusing from the user
point of view? ;)
^ permalink raw reply
* Re: [PATCH net-2.6] cxgb4: fix MAC address hash filter
From: David Miller @ 2010-12-08 17:36 UTC (permalink / raw)
To: dm; +Cc: netdev
In-Reply-To: <1291408744-2392-1-git-send-email-dm@chelsio.com>
From: Dimitris Michailidis <dm@chelsio.com>
Date: Fri, 3 Dec 2010 12:39:04 -0800
> Fix the calculation of the inexact hash-based MAC address filter.
> It's 64 bits but current code is missing a ULL. Results in filtering out
> some legitimate packets.
>
> Signed-off-by: Dimitris Michailidis <dm@chelsio.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/1] TCP: Bug fix in initialization of receive window.
From: David Miller @ 2010-12-08 17:41 UTC (permalink / raw)
To: nanditad; +Cc: chavey, ycheng, netdev
In-Reply-To: <1291419224-20853-1-git-send-email-nanditad@google.com>
From: Nandita Dukkipati <nanditad@google.com>
Date: Fri, 3 Dec 2010 15:33:44 -0800
> The bug has to do with boundary checks on the initial receive window.
> If the initial receive window falls between init_cwnd and the
> receive window specified by the user, the initial window is incorrectly
> brought down to init_cwnd. The correct behavior is to allow it to
> remain unchanged.
>
> Signed-off-by: Nandita Dukkipati <nanditad@google.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-2.6] ifb: goto resched directly if error happens and dp->tq isn't empty
From: David Miller @ 2010-12-08 17:45 UTC (permalink / raw)
To: hadi; +Cc: xiaosuo, jarkao2, netdev
In-Reply-To: <1291559144.2159.682.camel@mojatatu>
From: jamal <hadi@cyberus.ca>
Date: Sun, 05 Dec 2010 09:25:44 -0500
> On Sun, 2010-12-05 at 08:09 +0800, Changli Gao wrote:
>> If we break the loop when there are still skbs in tq and no skb in
>> rq, the skbs will be left in txq until new skbs are enqueued into rq.
>> In rare cases, no new skb is queued, then these skbs will stay in rq
>> forever.
>>
>> After this patch, if tq isn't empty when we break the loop, we goto
>> resched directly.
>>
>> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
>
> Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
>
> Dave, this goes to stable as well.
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: ctnetlink loop
From: David Miller @ 2010-12-08 17:50 UTC (permalink / raw)
To: holger; +Cc: netfilter-devel, netdev, pablo
Holger, this replay -EAGAIN loop in nfnetlink processing was added by
Pablo to handle module loading properly, I think. So it might not be
safe to just unilaterally remove it.
See:
commit e6a7d3c04f8fe49099521e6dc9a46b0272381f2f
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Tue Oct 14 11:58:31 2008 -0700
netfilter: ctnetlink: remove bogus module dependency between ctnetlink and nf_nat
This patch removes the module dependency between ctnetlink and
nf_nat by means of an indirect call that is initialized when
nf_nat is loaded. Now, nf_conntrack_netlink only requires
nf_conntrack and nfnetlink.
This patch puts nfnetlink_parse_nat_setup_hook into the
nf_conntrack_core to avoid dependencies between ctnetlink,
nf_conntrack_ipv4 and nf_conntrack_ipv6.
This patch also introduces the function ctnetlink_change_nat
that is only invoked from the creation path. Actually, the
nat handling cannot be invoked from the update path since
this is not allowed. By introducing this function, we remove
the useless nat handling in the update path and we avoid
deadlock-prone code.
This patch also adds the required EAGAIN logic for nfnetlink.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/include/linux/netfilter/nfnetlink.h b/include/linux/netfilter/nfnetlink.h
index 0d8424f..7d8e045 100644
--- a/include/linux/netfilter/nfnetlink.h
+++ b/include/linux/netfilter/nfnetlink.h
@@ -78,6 +78,9 @@ extern int nfnetlink_send(struct sk_buff *skb, u32 pid, unsigned group,
int echo);
extern int nfnetlink_unicast(struct sk_buff *skb, u_int32_t pid, int flags);
+extern void nfnl_lock(void);
+extern void nfnl_unlock(void);
+
#define MODULE_ALIAS_NFNL_SUBSYS(subsys) \
MODULE_ALIAS("nfnetlink-subsys-" __stringify(subsys))
diff --git a/include/net/netfilter/nf_nat_core.h b/include/net/netfilter/nf_nat_core.h
index f29eeb9..5868406 100644
--- a/include/net/netfilter/nf_nat_core.h
+++ b/include/net/netfilter/nf_nat_core.h
@@ -25,4 +25,12 @@ static inline int nf_nat_initialized(struct nf_conn *ct,
else
return test_bit(IPS_DST_NAT_DONE_BIT, &ct->status);
}
+
+struct nlattr;
+
+extern int
+(*nfnetlink_parse_nat_setup_hook)(struct nf_conn *ct,
+ enum nf_nat_manip_type manip,
+ struct nlattr *attr);
+
#endif /* _NF_NAT_CORE_H */
diff --git a/net/ipv4/netfilter/nf_nat_core.c b/net/ipv4/netfilter/nf_nat_core.c
index 2ac9eaf..a65cf69 100644
--- a/net/ipv4/netfilter/nf_nat_core.c
+++ b/net/ipv4/netfilter/nf_nat_core.c
@@ -584,6 +584,98 @@ static struct nf_ct_ext_type nat_extend __read_mostly = {
.flags = NF_CT_EXT_F_PREALLOC,
};
+#if defined(CONFIG_NF_CT_NETLINK) || defined(CONFIG_NF_CT_NETLINK_MODULE)
+
+#include <linux/netfilter/nfnetlink.h>
+#include <linux/netfilter/nfnetlink_conntrack.h>
+
+static const struct nla_policy protonat_nla_policy[CTA_PROTONAT_MAX+1] = {
+ [CTA_PROTONAT_PORT_MIN] = { .type = NLA_U16 },
+ [CTA_PROTONAT_PORT_MAX] = { .type = NLA_U16 },
+};
+
+static int nfnetlink_parse_nat_proto(struct nlattr *attr,
+ const struct nf_conn *ct,
+ struct nf_nat_range *range)
+{
+ struct nlattr *tb[CTA_PROTONAT_MAX+1];
+ const struct nf_nat_protocol *npt;
+ int err;
+
+ err = nla_parse_nested(tb, CTA_PROTONAT_MAX, attr, protonat_nla_policy);
+ if (err < 0)
+ return err;
+
+ npt = nf_nat_proto_find_get(nf_ct_protonum(ct));
+ if (npt->nlattr_to_range)
+ err = npt->nlattr_to_range(tb, range);
+ nf_nat_proto_put(npt);
+ return err;
+}
+
+static const struct nla_policy nat_nla_policy[CTA_NAT_MAX+1] = {
+ [CTA_NAT_MINIP] = { .type = NLA_U32 },
+ [CTA_NAT_MAXIP] = { .type = NLA_U32 },
+};
+
+static int
+nfnetlink_parse_nat(struct nlattr *nat,
+ const struct nf_conn *ct, struct nf_nat_range *range)
+{
+ struct nlattr *tb[CTA_NAT_MAX+1];
+ int err;
+
+ memset(range, 0, sizeof(*range));
+
+ err = nla_parse_nested(tb, CTA_NAT_MAX, nat, nat_nla_policy);
+ if (err < 0)
+ return err;
+
+ if (tb[CTA_NAT_MINIP])
+ range->min_ip = nla_get_be32(tb[CTA_NAT_MINIP]);
+
+ if (!tb[CTA_NAT_MAXIP])
+ range->max_ip = range->min_ip;
+ else
+ range->max_ip = nla_get_be32(tb[CTA_NAT_MAXIP]);
+
+ if (range->min_ip)
+ range->flags |= IP_NAT_RANGE_MAP_IPS;
+
+ if (!tb[CTA_NAT_PROTO])
+ return 0;
+
+ err = nfnetlink_parse_nat_proto(tb[CTA_NAT_PROTO], ct, range);
+ if (err < 0)
+ return err;
+
+ return 0;
+}
+
+static int
+nfnetlink_parse_nat_setup(struct nf_conn *ct,
+ enum nf_nat_manip_type manip,
+ struct nlattr *attr)
+{
+ struct nf_nat_range range;
+
+ if (nfnetlink_parse_nat(attr, ct, &range) < 0)
+ return -EINVAL;
+ if (nf_nat_initialized(ct, manip))
+ return -EEXIST;
+
+ return nf_nat_setup_info(ct, &range, manip);
+}
+#else
+static int
+nfnetlink_parse_nat_setup(struct nf_conn *ct,
+ enum nf_nat_manip_type manip,
+ struct nlattr *attr)
+{
+ return -EOPNOTSUPP;
+}
+#endif
+
static int __net_init nf_nat_net_init(struct net *net)
{
net->ipv4.nat_bysource = nf_ct_alloc_hashtable(&nf_nat_htable_size,
@@ -654,6 +746,9 @@ static int __init nf_nat_init(void)
BUG_ON(nf_nat_seq_adjust_hook != NULL);
rcu_assign_pointer(nf_nat_seq_adjust_hook, nf_nat_seq_adjust);
+ BUG_ON(nfnetlink_parse_nat_setup_hook != NULL);
+ rcu_assign_pointer(nfnetlink_parse_nat_setup_hook,
+ nfnetlink_parse_nat_setup);
return 0;
cleanup_extend:
@@ -667,10 +762,12 @@ static void __exit nf_nat_cleanup(void)
nf_ct_l3proto_put(l3proto);
nf_ct_extend_unregister(&nat_extend);
rcu_assign_pointer(nf_nat_seq_adjust_hook, NULL);
+ rcu_assign_pointer(nfnetlink_parse_nat_setup_hook, NULL);
synchronize_net();
}
MODULE_LICENSE("GPL");
+MODULE_ALIAS("nf-nat-ipv4");
module_init(nf_nat_init);
module_exit(nf_nat_cleanup);
diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
index 27de3c7..622d7c6 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -38,9 +38,16 @@
#include <net/netfilter/nf_conntrack_core.h>
#include <net/netfilter/nf_conntrack_extend.h>
#include <net/netfilter/nf_conntrack_acct.h>
+#include <net/netfilter/nf_nat.h>
#define NF_CONNTRACK_VERSION "0.5.0"
+unsigned int
+(*nfnetlink_parse_nat_setup_hook)(struct nf_conn *ct,
+ enum nf_nat_manip_type manip,
+ struct nlattr *attr) __read_mostly;
+EXPORT_SYMBOL_GPL(nfnetlink_parse_nat_setup_hook);
+
DEFINE_SPINLOCK(nf_conntrack_lock);
EXPORT_SYMBOL_GPL(nf_conntrack_lock);
diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c
index cadfd15..08e82d6 100644
--- a/net/netfilter/nf_conntrack_netlink.c
+++ b/net/netfilter/nf_conntrack_netlink.c
@@ -689,71 +689,6 @@ ctnetlink_parse_tuple(struct nlattr *cda[], struct nf_conntrack_tuple *tuple,
return 0;
}
-#ifdef CONFIG_NF_NAT_NEEDED
-static const struct nla_policy protonat_nla_policy[CTA_PROTONAT_MAX+1] = {
- [CTA_PROTONAT_PORT_MIN] = { .type = NLA_U16 },
- [CTA_PROTONAT_PORT_MAX] = { .type = NLA_U16 },
-};
-
-static int nfnetlink_parse_nat_proto(struct nlattr *attr,
- const struct nf_conn *ct,
- struct nf_nat_range *range)
-{
- struct nlattr *tb[CTA_PROTONAT_MAX+1];
- const struct nf_nat_protocol *npt;
- int err;
-
- err = nla_parse_nested(tb, CTA_PROTONAT_MAX, attr, protonat_nla_policy);
- if (err < 0)
- return err;
-
- npt = nf_nat_proto_find_get(nf_ct_protonum(ct));
- if (npt->nlattr_to_range)
- err = npt->nlattr_to_range(tb, range);
- nf_nat_proto_put(npt);
- return err;
-}
-
-static const struct nla_policy nat_nla_policy[CTA_NAT_MAX+1] = {
- [CTA_NAT_MINIP] = { .type = NLA_U32 },
- [CTA_NAT_MAXIP] = { .type = NLA_U32 },
-};
-
-static inline int
-nfnetlink_parse_nat(struct nlattr *nat,
- const struct nf_conn *ct, struct nf_nat_range *range)
-{
- struct nlattr *tb[CTA_NAT_MAX+1];
- int err;
-
- memset(range, 0, sizeof(*range));
-
- err = nla_parse_nested(tb, CTA_NAT_MAX, nat, nat_nla_policy);
- if (err < 0)
- return err;
-
- if (tb[CTA_NAT_MINIP])
- range->min_ip = nla_get_be32(tb[CTA_NAT_MINIP]);
-
- if (!tb[CTA_NAT_MAXIP])
- range->max_ip = range->min_ip;
- else
- range->max_ip = nla_get_be32(tb[CTA_NAT_MAXIP]);
-
- if (range->min_ip)
- range->flags |= IP_NAT_RANGE_MAP_IPS;
-
- if (!tb[CTA_NAT_PROTO])
- return 0;
-
- err = nfnetlink_parse_nat_proto(tb[CTA_NAT_PROTO], ct, range);
- if (err < 0)
- return err;
-
- return 0;
-}
-#endif
-
static inline int
ctnetlink_parse_help(struct nlattr *attr, char **helper_name)
{
@@ -879,6 +814,34 @@ out:
}
static int
+ctnetlink_parse_nat_setup(struct nf_conn *ct,
+ enum nf_nat_manip_type manip,
+ struct nlattr *attr)
+{
+ typeof(nfnetlink_parse_nat_setup_hook) parse_nat_setup;
+
+ parse_nat_setup = rcu_dereference(nfnetlink_parse_nat_setup_hook);
+ if (!parse_nat_setup) {
+#ifdef CONFIG_KMOD
+ rcu_read_unlock();
+ nfnl_unlock();
+ if (request_module("nf-nat-ipv4") < 0) {
+ nfnl_lock();
+ rcu_read_lock();
+ return -EOPNOTSUPP;
+ }
+ nfnl_lock();
+ rcu_read_lock();
+ if (nfnetlink_parse_nat_setup_hook)
+ return -EAGAIN;
+#endif
+ return -EOPNOTSUPP;
+ }
+
+ return parse_nat_setup(ct, manip, attr);
+}
+
+static int
ctnetlink_change_status(struct nf_conn *ct, struct nlattr *cda[])
{
unsigned long d;
@@ -897,31 +860,6 @@ ctnetlink_change_status(struct nf_conn *ct, struct nlattr *cda[])
/* ASSURED bit can only be set */
return -EBUSY;
- if (cda[CTA_NAT_SRC] || cda[CTA_NAT_DST]) {
-#ifndef CONFIG_NF_NAT_NEEDED
- return -EOPNOTSUPP;
-#else
- struct nf_nat_range range;
-
- if (cda[CTA_NAT_DST]) {
- if (nfnetlink_parse_nat(cda[CTA_NAT_DST], ct,
- &range) < 0)
- return -EINVAL;
- if (nf_nat_initialized(ct, IP_NAT_MANIP_DST))
- return -EEXIST;
- nf_nat_setup_info(ct, &range, IP_NAT_MANIP_DST);
- }
- if (cda[CTA_NAT_SRC]) {
- if (nfnetlink_parse_nat(cda[CTA_NAT_SRC], ct,
- &range) < 0)
- return -EINVAL;
- if (nf_nat_initialized(ct, IP_NAT_MANIP_SRC))
- return -EEXIST;
- nf_nat_setup_info(ct, &range, IP_NAT_MANIP_SRC);
- }
-#endif
- }
-
/* Be careful here, modifying NAT bits can screw up things,
* so don't let users modify them directly if they don't pass
* nf_nat_range. */
@@ -929,6 +867,31 @@ ctnetlink_change_status(struct nf_conn *ct, struct nlattr *cda[])
return 0;
}
+static int
+ctnetlink_change_nat(struct nf_conn *ct, struct nlattr *cda[])
+{
+#ifdef CONFIG_NF_NAT_NEEDED
+ int ret;
+
+ if (cda[CTA_NAT_DST]) {
+ ret = ctnetlink_parse_nat_setup(ct,
+ IP_NAT_MANIP_DST,
+ cda[CTA_NAT_DST]);
+ if (ret < 0)
+ return ret;
+ }
+ if (cda[CTA_NAT_SRC]) {
+ ret = ctnetlink_parse_nat_setup(ct,
+ IP_NAT_MANIP_SRC,
+ cda[CTA_NAT_SRC]);
+ if (ret < 0)
+ return ret;
+ }
+ return 0;
+#else
+ return -EOPNOTSUPP;
+#endif
+}
static inline int
ctnetlink_change_helper(struct nf_conn *ct, struct nlattr *cda[])
@@ -1157,6 +1120,14 @@ ctnetlink_create_conntrack(struct nlattr *cda[],
}
}
+ if (cda[CTA_NAT_SRC] || cda[CTA_NAT_DST]) {
+ err = ctnetlink_change_nat(ct, cda);
+ if (err < 0) {
+ rcu_read_unlock();
+ goto err;
+ }
+ }
+
if (cda[CTA_PROTOINFO]) {
err = ctnetlink_change_protoinfo(ct, cda);
if (err < 0) {
diff --git a/net/netfilter/nfnetlink.c b/net/netfilter/nfnetlink.c
index b75c9c4..4739f9f 100644
--- a/net/netfilter/nfnetlink.c
+++ b/net/netfilter/nfnetlink.c
@@ -44,15 +44,17 @@ static struct sock *nfnl = NULL;
static const struct nfnetlink_subsystem *subsys_table[NFNL_SUBSYS_COUNT];
static DEFINE_MUTEX(nfnl_mutex);
-static inline void nfnl_lock(void)
+void nfnl_lock(void)
{
mutex_lock(&nfnl_mutex);
}
+EXPORT_SYMBOL_GPL(nfnl_lock);
-static inline void nfnl_unlock(void)
+void nfnl_unlock(void)
{
mutex_unlock(&nfnl_mutex);
}
+EXPORT_SYMBOL_GPL(nfnl_unlock);
int nfnetlink_subsys_register(const struct nfnetlink_subsystem *n)
{
@@ -132,6 +134,7 @@ static int nfnetlink_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
return 0;
type = nlh->nlmsg_type;
+replay:
ss = nfnetlink_get_subsys(type);
if (!ss) {
#ifdef CONFIG_KMOD
@@ -165,7 +168,10 @@ static int nfnetlink_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
} else
return -EINVAL;
- return nc->call(nfnl, skb, nlh, cda);
+ err = nc->call(nfnl, skb, nlh, cda);
+ if (err == -EAGAIN)
+ goto replay;
+ return err;
}
}
^ permalink raw reply related
* Re: [PATCH] net/9p/protocol.c: Remove duplicated macros.
From: David Miller @ 2010-12-08 17:56 UTC (permalink / raw)
To: tfransosi
Cc: linux-kernel, ericvh, sripathik, aneesh.kumar, jvrao, akpm,
netdev
In-Reply-To: <3300e3823b702d35658175ff6379a4f77fa9a5b0.1291512089.git.tfransosi@gmail.com>
From: Thiago Farina <tfransosi@gmail.com>
Date: Sat, 4 Dec 2010 23:22:46 -0200
> Use the macros already provided by kernel.h file.
>
> Signed-off-by: Thiago Farina <tfransosi@gmail.com>
I'll apply this, thanks!
^ permalink raw reply
* Re: [PATCH net-2.6] llc: fix a device refcount imbalance
From: David Miller @ 2010-12-08 17:59 UTC (permalink / raw)
To: eric.dumazet
Cc: maximlevitsky, linux1394-devel, stefanr, netdev, kuznet, jmorris,
kaber, opurdila, stable
In-Reply-To: <1291550606.2806.237.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 05 Dec 2010 13:03:26 +0100
> [PATCH net-2.6] llc: fix a device refcount imbalance
>
> commit abf9d537fea225 (llc: add support for SO_BINDTODEVICE) added one
> refcount imbalance in llc_ui_bind(), because dev_getbyhwaddr() doesnt
> take a reference on device, while dev_get_by_index() does.
>
> Fix this using RCU locking. And since an RCU conversion will be done for
> 2.6.38 for dev_getbyhwaddr(), put the rcu_read_lock/unlock exactly at
> their final place.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied and queued up for -stable.
^ 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