* Re[2]: [RFC PATCH 00/18] netfilter: IPv6 NAT
From: Hans Schillstrom @ 2011-11-29 12:50 UTC (permalink / raw)
To: Patrick McHardy; +Cc: sclark46, netfilter-devel, netdev, ulrich.weber
>
>On 28.11.2011 18:14, Stephen Clark wrote:
>> On 11/24/2011 11:57 AM, kaber@trash.net wrote:
>>> The following patches contain the updated IPv6 NAT patchset forward
>>> ported
>>> to 3.2-rc3. ...
>>>
>>>
>>>
>> Probabably a dumb question but are these patches for natting ipv6 to
>> ipv6 or ipv4 to ipv6?
>
>IPv6 to IPv6. I haven't really considered IPv6 to IPv4 yet.
Have you ever tried ivi The IPv6 to IPv4 gateway ?
i.e address mapping and packet translation between IPv4 and IPv6 networks
I made a port to resent kernel in the begining of this year ( i think it was 2.6.36 ... ) and it seems to work.
(however there is some issues left....)
I like the idea of "ivi" for a larger scale of translation.
/Hans
^ permalink raw reply
* RE: [PATCH 4/5] NFS: remove RPC PipeFS mount point reference from blocklayout routines
From: tao.peng-mb1K0bWo544 @ 2011-11-29 12:40 UTC (permalink / raw)
To: skinsbursky-bzQdu9zFT3WakBO8gow8eQ
Cc: Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, xemul-bzQdu9zFT3WakBO8gow8eQ,
neilb-l3A5Bk7waGM, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
jbottomley-bzQdu9zFT3WakBO8gow8eQ, bfields-uC3wQj2KruNg9hUCZPvPmw,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, devel-GEFAQzZX7r8dnm+yROfE0A
In-Reply-To: <4ED4CDCE.9080804-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 4116 bytes --]
> -----Original Message-----
> From: Stanislav Kinsbursky [mailto:skinsbursky@parallels.com]
> Sent: Tuesday, November 29, 2011 8:19 PM
> To: Peng, Tao
> Cc: Trond.Myklebust@netapp.com; linux-nfs@vger.kernel.org; Pavel Emelianov; neilb@suse.de;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org; James Bottomley; bfields@fieldses.org;
> davem@davemloft.net; devel@openvz.org
> Subject: Re: [PATCH 4/5] NFS: remove RPC PipeFS mount point reference from blocklayout routines
>
> 29.11.2011 16:00, tao.peng@emc.com пишет:
> >> -----Original Message-----
> >> From: linux-nfs-owner@vger.kernel.org [mailto:linux-nfs-owner@vger.kernel.org] On Behalf Of
> Stanislav
> >> Kinsbursky
> >> Sent: Tuesday, November 29, 2011 6:11 PM
> >> To: Trond.Myklebust@netapp.com
> >> Cc: linux-nfs@vger.kernel.org; xemul@parallels.com; neilb@suse.de; netdev@vger.kernel.org; linux-
> >> kernel@vger.kernel.org; jbottomley@parallels.com; bfields@fieldses.org; davem@davemloft.net;
> >> devel@openvz.org
> >> Subject: [PATCH 4/5] NFS: remove RPC PipeFS mount point reference from blocklayout routines
> >>
> >> This is a cleanup patch. We don't need this reference anymore, because
> >> blocklayout pipes dentries now creates and destroys in per-net operations and
> >> on PipeFS mount/umount notification.
> >> Note that nfs4blocklayout_register_net() now returns 0 instead of -ENOENT in
> >> case of PipeFS superblock absence. This is ok, because blocklayout pipe dentry
> >> will be created on PipeFS mount event.
> > When is the "pipefs mount event" going to happen? When inserting kernel modules or when user issues
> mount command?
> >
>
> When user issues mount command.
> Kernel mounts of PipeFS has been removed with all these patch sets I've sent
> already.
Then it is going to break blocklayout user space program blkmapd, which is stared before mounting any file system and it tries to open the pipe file when started.
Not sure if you implement the same logic on nfs pipe as well. But if you do, then nfs client user space program idmapd will fail to start for the same reason.
Why not just fail to load module if you fail to initialize pipefs? When is rpc_get_sb_net() going to fail?
>
>
> > Thanks,
> > Tao
> >
> >>
> >> Signed-off-by: Stanislav Kinsbursky<skinsbursky@parallels.com>
> >>
> >> ---
> >> fs/nfs/blocklayout/blocklayout.c | 9 +--------
> >> 1 files changed, 1 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/fs/nfs/blocklayout/blocklayout.c b/fs/nfs/blocklayout/blocklayout.c
> >> index acf7ac9..8211ffd 100644
> >> --- a/fs/nfs/blocklayout/blocklayout.c
> >> +++ b/fs/nfs/blocklayout/blocklayout.c
> >> @@ -1032,7 +1032,7 @@ static struct dentry *nfs4blocklayout_register_net(struct net *net,
> >>
> >> pipefs_sb = rpc_get_sb_net(net);
> >> if (!pipefs_sb)
> >> - return ERR_PTR(-ENOENT);
> >> + return 0;
> >> dentry = nfs4blocklayout_register_sb(pipefs_sb, pipe);
> >> rpc_put_sb_net(net);
> >> return dentry;
> >> @@ -1083,7 +1083,6 @@ static struct pernet_operations nfs4blocklayout_net_ops = {
> >>
> >> static int __init nfs4blocklayout_init(void)
> >> {
> >> - struct vfsmount *mnt;
> >> int ret;
> >>
> >> dprintk("%s: NFSv4 Block Layout Driver Registering...\n", __func__);
> >> @@ -1093,12 +1092,6 @@ static int __init nfs4blocklayout_init(void)
> >> goto out;
> >>
> >> init_waitqueue_head(&bl_wq);
> >> -
> >> - mnt = rpc_get_mount();
> >> - if (IS_ERR(mnt)) {
> >> - ret = PTR_ERR(mnt);
> >> - goto out_remove;
> >> - }
> >> ret = rpc_pipefs_notifier_register(&nfs4blocklayout_block);
> >> if (ret)
> >> goto out_remove;
> >>
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
>
> --
> Best regards,
> Stanislav Kinsbursky
N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±û"žØ^n‡r¡ö¦zË\x1aëh™¨èÚ&¢îý»\x05ËÛÔØï¦v¬Îf\x1dp)¹¹br šê+€Ê+zf£¢·hšˆ§~††Ûiÿûàz¹\x1e®w¥¢¸?™¨èÚ&¢)ߢ^[f
^ permalink raw reply
* Re: [RFC PATCH 00/18] netfilter: IPv6 NAT
From: Patrick McHardy @ 2011-11-29 12:32 UTC (permalink / raw)
To: sclark46; +Cc: netfilter-devel, netdev, ulrich.weber
In-Reply-To: <4ED3C174.9030302@earthlink.net>
On 28.11.2011 18:14, Stephen Clark wrote:
> On 11/24/2011 11:57 AM, kaber@trash.net wrote:
>> The following patches contain the updated IPv6 NAT patchset forward
>> ported
>> to 3.2-rc3. ...
>>
>>
>>
> Probabably a dumb question but are these patches for natting ipv6 to
> ipv6 or ipv4 to ipv6?
IPv6 to IPv6. I haven't really considered IPv6 to IPv4 yet.
^ permalink raw reply
* Re: [RFC PATCH 00/18] netfilter: IPv6 NAT
From: Jan Engelhardt @ 2011-11-29 12:23 UTC (permalink / raw)
To: Ulrich Weber
Cc: Amos Jeffries, sclark46@earthlink.net, kaber@trash.net,
netfilter-devel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <4ED4A399.6090709@sophos.com>
On Tuesday 2011-11-29 10:19, Ulrich Weber wrote:
> On 28.11.2011 23:03, Amos Jeffries wrote:
>> I'm going to dare to call FUD on those statements...
>> * Load Balancing - what is preventing your routing rules or packet
>> marking using the same criteria as the NAT changer? nothing. Load
>> balancing works perfectly fine without NAT.
Source address selection, having to occur on the source, would
require that the source has to know all the parameters that a {what
would have been your NAT GW} would need to know, which means you have
to (a) collect and/or (b) distribute this information. Given two
uplinks that only allow a certain source network address (different
for each uplink), combined with the desire to balance on utilization,
(a) a client is not in the position to easily obtain this data unless
it is the router for all participants itself, (b) the clients needs
to cooperate, and one cannot always trust client devices, or hope for
their technical cooperation (firewalled themselves off).
Yes, NAT is evil, but if you actually think about it, policies are
best applied where [the policy] originates from. After all, we also
don't do LSRR, instead, routers do the routing, because they just
know much better.
> I fully agree. NAT can not replace your firewall rules.
>
> However with NAT you could get some kind of anonymity.
Same network prefix, some cookies, or a login form. Blam, identified,
or at least (Almost-)Uniquely Identified Visitor tagging.
Everybody should come out of their worshipping NAT for anonymity
now - at best, that is an Emperor's Clothes' kind of anonymity.
> Think of Tor: If your server/client operates with private IP addresses,
> your public IP address is still masked after a security breach.
If one's tor peer was busted, they would have the address.
^ permalink raw reply
* Re: [PATCH 4/5] NFS: remove RPC PipeFS mount point reference from blocklayout routines
From: Stanislav Kinsbursky @ 2011-11-29 12:19 UTC (permalink / raw)
To: tao.peng@emc.com
Cc: Trond.Myklebust@netapp.com, linux-nfs@vger.kernel.org,
Pavel Emelianov, neilb@suse.de, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, James Bottomley,
bfields@fieldses.org, davem@davemloft.net, devel@openvz.org
In-Reply-To: <F19688880B763E40B28B2B462677FBF805E3A4AFF2@MX09A.corp.emc.com>
29.11.2011 16:00, tao.peng@emc.com пишет:
>> -----Original Message-----
>> From: linux-nfs-owner@vger.kernel.org [mailto:linux-nfs-owner@vger.kernel.org] On Behalf Of Stanislav
>> Kinsbursky
>> Sent: Tuesday, November 29, 2011 6:11 PM
>> To: Trond.Myklebust@netapp.com
>> Cc: linux-nfs@vger.kernel.org; xemul@parallels.com; neilb@suse.de; netdev@vger.kernel.org; linux-
>> kernel@vger.kernel.org; jbottomley@parallels.com; bfields@fieldses.org; davem@davemloft.net;
>> devel@openvz.org
>> Subject: [PATCH 4/5] NFS: remove RPC PipeFS mount point reference from blocklayout routines
>>
>> This is a cleanup patch. We don't need this reference anymore, because
>> blocklayout pipes dentries now creates and destroys in per-net operations and
>> on PipeFS mount/umount notification.
>> Note that nfs4blocklayout_register_net() now returns 0 instead of -ENOENT in
>> case of PipeFS superblock absence. This is ok, because blocklayout pipe dentry
>> will be created on PipeFS mount event.
> When is the "pipefs mount event" going to happen? When inserting kernel modules or when user issues mount command?
>
When user issues mount command.
Kernel mounts of PipeFS has been removed with all these patch sets I've sent
already.
> Thanks,
> Tao
>
>>
>> Signed-off-by: Stanislav Kinsbursky<skinsbursky@parallels.com>
>>
>> ---
>> fs/nfs/blocklayout/blocklayout.c | 9 +--------
>> 1 files changed, 1 insertions(+), 8 deletions(-)
>>
>> diff --git a/fs/nfs/blocklayout/blocklayout.c b/fs/nfs/blocklayout/blocklayout.c
>> index acf7ac9..8211ffd 100644
>> --- a/fs/nfs/blocklayout/blocklayout.c
>> +++ b/fs/nfs/blocklayout/blocklayout.c
>> @@ -1032,7 +1032,7 @@ static struct dentry *nfs4blocklayout_register_net(struct net *net,
>>
>> pipefs_sb = rpc_get_sb_net(net);
>> if (!pipefs_sb)
>> - return ERR_PTR(-ENOENT);
>> + return 0;
>> dentry = nfs4blocklayout_register_sb(pipefs_sb, pipe);
>> rpc_put_sb_net(net);
>> return dentry;
>> @@ -1083,7 +1083,6 @@ static struct pernet_operations nfs4blocklayout_net_ops = {
>>
>> static int __init nfs4blocklayout_init(void)
>> {
>> - struct vfsmount *mnt;
>> int ret;
>>
>> dprintk("%s: NFSv4 Block Layout Driver Registering...\n", __func__);
>> @@ -1093,12 +1092,6 @@ static int __init nfs4blocklayout_init(void)
>> goto out;
>>
>> init_waitqueue_head(&bl_wq);
>> -
>> - mnt = rpc_get_mount();
>> - if (IS_ERR(mnt)) {
>> - ret = PTR_ERR(mnt);
>> - goto out_remove;
>> - }
>> ret = rpc_pipefs_notifier_register(&nfs4blocklayout_block);
>> if (ret)
>> goto out_remove;
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Best regards,
Stanislav Kinsbursky
^ permalink raw reply
* RE: [PATCH 4/5] NFS: remove RPC PipeFS mount point reference from blocklayout routines
From: tao.peng-mb1K0bWo544 @ 2011-11-29 12:00 UTC (permalink / raw)
To: skinsbursky-bzQdu9zFT3WakBO8gow8eQ,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA
Cc: linux-nfs-u79uwXL29TY76Z2rM5mHXA, xemul-bzQdu9zFT3WakBO8gow8eQ,
neilb-l3A5Bk7waGM, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
jbottomley-bzQdu9zFT3WakBO8gow8eQ, bfields-uC3wQj2KruNg9hUCZPvPmw,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, devel-GEFAQzZX7r8dnm+yROfE0A
In-Reply-To: <20111129091037.20730.59391.stgit-bi+AKbBUZKagILUCTcTcHdKyNwTtLsGr@public.gmane.org>
> -----Original Message-----
> From: linux-nfs-owner@vger.kernel.org [mailto:linux-nfs-owner@vger.kernel.org] On Behalf Of Stanislav
> Kinsbursky
> Sent: Tuesday, November 29, 2011 6:11 PM
> To: Trond.Myklebust@netapp.com
> Cc: linux-nfs@vger.kernel.org; xemul@parallels.com; neilb@suse.de; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; jbottomley@parallels.com; bfields@fieldses.org; davem@davemloft.net;
> devel@openvz.org
> Subject: [PATCH 4/5] NFS: remove RPC PipeFS mount point reference from blocklayout routines
>
> This is a cleanup patch. We don't need this reference anymore, because
> blocklayout pipes dentries now creates and destroys in per-net operations and
> on PipeFS mount/umount notification.
> Note that nfs4blocklayout_register_net() now returns 0 instead of -ENOENT in
> case of PipeFS superblock absence. This is ok, because blocklayout pipe dentry
> will be created on PipeFS mount event.
When is the "pipefs mount event" going to happen? When inserting kernel modules or when user issues mount command?
Thanks,
Tao
>
> Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
>
> ---
> fs/nfs/blocklayout/blocklayout.c | 9 +--------
> 1 files changed, 1 insertions(+), 8 deletions(-)
>
> diff --git a/fs/nfs/blocklayout/blocklayout.c b/fs/nfs/blocklayout/blocklayout.c
> index acf7ac9..8211ffd 100644
> --- a/fs/nfs/blocklayout/blocklayout.c
> +++ b/fs/nfs/blocklayout/blocklayout.c
> @@ -1032,7 +1032,7 @@ static struct dentry *nfs4blocklayout_register_net(struct net *net,
>
> pipefs_sb = rpc_get_sb_net(net);
> if (!pipefs_sb)
> - return ERR_PTR(-ENOENT);
> + return 0;
> dentry = nfs4blocklayout_register_sb(pipefs_sb, pipe);
> rpc_put_sb_net(net);
> return dentry;
> @@ -1083,7 +1083,6 @@ static struct pernet_operations nfs4blocklayout_net_ops = {
>
> static int __init nfs4blocklayout_init(void)
> {
> - struct vfsmount *mnt;
> int ret;
>
> dprintk("%s: NFSv4 Block Layout Driver Registering...\n", __func__);
> @@ -1093,12 +1092,6 @@ static int __init nfs4blocklayout_init(void)
> goto out;
>
> init_waitqueue_head(&bl_wq);
> -
> - mnt = rpc_get_mount();
> - if (IS_ERR(mnt)) {
> - ret = PTR_ERR(mnt);
> - goto out_remove;
> - }
> ret = rpc_pipefs_notifier_register(&nfs4blocklayout_block);
> if (ret)
> goto out_remove;
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH net-next] netxen: write IP address to firmware when using bonding
From: Rajesh Borundia @ 2011-11-29 11:58 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: David Miller, netdev, Sony Chacko
In-Reply-To: <20111128204326.GH25132@gospo.rdu.redhat.com>
Yes virt would be fine.
Thanks,
Rajesh
________________________________________
From: Andy Gospodarek [andy@greyhouse.net]
Sent: Tuesday, November 29, 2011 2:13 AM
To: Rajesh Borundia
Cc: David Miller; andy@greyhouse.net; netdev; Sony Chacko
Subject: Re: [PATCH net-next] netxen: write IP address to firmware when using bonding
On Mon, Nov 28, 2011 at 12:02:28AM -0600, Rajesh Borundia wrote:
> Hi Andy,
>
> We need to restore the ip address after the adapter reset.
> netxen_restore_indev_addr is the function that restores normal ip addresses
> and vlan ip addresses. If we could find bond device directly from slave then
> we can use netxen_config_indev_addr to add the ip address of the bond device.
> Otherwise we may need to cache the bond ip address in function netxen_list_config_vlan_ip
> and change the condition from
>
> if (!is_vlan_dev(dev))
> return;
>
> to
>
> if (!is_vlan_dev(dev) && !is_bond_dev(dev))
> return;
>
I don't think this was what you were originally intending, but what
about changing the name of the vlan_ip_list (and the vlan functions that
modify/read it) to something different and use it for all virtual or
stacked devices?
Something like 'virtual' or 'virt' might work instead of 'vlan.'
Something else that denotes that a device at a higher layer than just
the physical device has an IP address that we need to know about, but
that the device is not specific to VLANs.
> Some of the code in if and else part is repeated.
> If possible can we have small functions for that ?
> eg:
> if (!is_netxen_netdev(dev))
> + goto done;
> +
> + adapter = netdev_priv(dev);
> + if (!adapter)
> + goto done;
> +
> + if (adapter->is_up != NETXEN_ADAPTER_UP_MAGIC)
> + goto done;
> +
> + netxen_config_indev_addr(adapter, orig_dev, event);
>
>
I could change that. I started to look at sharing some code, but
decided against too much initial code churn. Since the fundamental idea
behind this chance seems acceptable, I can take a look at it more
closely.
I'll take a look at this and send a v2 of this patch.
> Rajesh
> ________________________________________
> From: David Miller [davem@davemloft.net]
> Sent: Thursday, November 24, 2011 11:08 AM
> To: andy@greyhouse.net
> Cc: netdev; Sony Chacko; Rajesh Borundia
> Subject: Re: [PATCH net-next] netxen: write IP address to firmware when using bonding
>
> From: Andy Gospodarek <andy@greyhouse.net>
> Date: Wed, 23 Nov 2011 22:24:27 -0500
>
> > Are you talking about adding a macro like this:
> >
> > for_each_dev_in_bond(bond,slave) {
> > [...]
> > }
> >
> > to replace the statements I added that were like this:
> >
> > for_each_netdev_rcu(&init_net, slave) {
> > if (slave->master == dev) {
> > [...]
> > }
> > }
> >
> > If so, that totally seems reasonable. If were requesting something
> > else, please let me know.
>
> Yes, some helper that walks the device list and tries to find
> a device whose ->master matches 'dev'.
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: pull request: wireless-next 2011-11-28
From: Kalle Valo @ 2011-11-29 11:58 UTC (permalink / raw)
To: David Miller
Cc: linville-2XuSBdqkA4R54TAoqtyWWQ,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20111128.195516.37800643865997337.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On 11/29/2011 02:55 AM, David Miller wrote:
> Pulled, but please push back on the ath6kl guys, they seem to have
> this disease where they add tons of debugfs files
Sorry about that. I was under impression that there are no strict rules
for debugfs files and drivers can add them without too much worries, but
it seems I was wrong.
> for controlling things like QoS from userspace instead of creating
> and using generic configuration machanisms via netlink or similar
> that any other driver could support too.
Adding a generic QoS interface would take some time to implement and I
doubt that we (=ath6kl team) can do that anytime soon as our first
challange has been to get ath6kl working properly with cfg80211. That's
why we ended up having a debugfs interface for qos as our first step.
Kalle
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Fix jump_label handling in dev.c
From: Eric Dumazet @ 2011-11-29 11:15 UTC (permalink / raw)
To: igorm; +Cc: netdev
In-Reply-To: <CAFdo_mWQzLQpgN0NjzXJ9HoeKCbzF9TLfC4-RZwp_=DFY25Gsg@mail.gmail.com>
Le mardi 29 novembre 2011 à 12:07 +0100, Igor Maravić a écrit :
> Please ignore this.
> My mistake.
OK ;)
One last thing : Dont top post on netdev, please.
^ permalink raw reply
* Re: [PATCH] Fix jump_label handling in dev.c
From: Igor Maravić @ 2011-11-29 11:07 UTC (permalink / raw)
To: netdev; +Cc: eric.dumazet, Igor Maravic
In-Reply-To: <1322562649-20876-1-git-send-email-igorm@etf.rs>
Please ignore this.
My mistake.
2011/11/29 <igorm@etf.rs>:
> From: Igor Maravic <igorm@etf.rs>
>
> static_branch instead of atomic_read.
> Eric forgot to replace that.
>
> Signed-off-by: Igor Maravic <igorm@etf.rs>
>
> :100644 100644 579ce33... d358088... M net/core/dev.c
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 579ce33..d358088 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -1482,12 +1482,12 @@ EXPORT_SYMBOL(net_disable_timestamp);
> static inline void net_timestamp_set(struct sk_buff *skb)
> {
> skb->tstamp.tv64 = 0;
> - if (atomic_read(&netstamp_needed))
> + if (static_branch(&netstamp_needed))
> __net_timestamp(skb);
> }
>
> #define net_timestamp_check(COND, SKB) \
> - if (atomic_read(&netstamp_needed)) { \
> + if (static_branch(&netstamp_needed)) { \
> if ((COND) && !(SKB)->tstamp.tv64) \
> __net_timestamp(SKB); \
> } \
> --
> 1.7.5.4
>
>
^ permalink raw reply
* Re: [PATCH net-next v4 0/4] can: cc770: add support for the Bosch CC770 and Intel AN82527
From: Wolfgang Grandegger @ 2011-11-29 11:03 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Wolfgang Zarre,
socketcan-users-0fE9KPoRgkgATYTw5x5z8w,
linux-can-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4ED4B93B.10709-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On 11/29/2011 11:51 AM, Marc Kleine-Budde wrote:
> On 11/29/2011 11:47 AM, Marc Kleine-Budde wrote:
>> On 11/29/2011 10:11 AM, Wolfgang Grandegger wrote:
>>> Already since a while we have support for the Bosch CC770 and Intel
>>> AN82527 CAN controllers in our out-of-tree Socket-CAN repository.
>>>
>>> In the meantime I found a TQM855L board with two AN82527 on it,
>>> which allowed me to provide and test a generic platform driver
>>> as well.
>>>
>>> Changes since v1:
>>>
>>> - remove version.h includes
>>> - some minor corrections in the ISA bus driver
>>> - add platform header file to the driver core
>>> - add generic platform driver
>>> - add and update device tree nodes for tqm8xx and tqm8548
>>>
>>> Changes since v2:
>>>
>>> - correct license text as suggest by Oliver Hartkopp
>>> - use the new module_platform_driver function
>>> - provide get_berr_counter callback for cc770
>>> - improve CAN error state change handling
>>> - more comprehensive cc770_isa driver description
>>>
>>> Changes since v3:
>>>
>>> - pre-define pr_fmt()
>>> - use KBUILD_MODNAME instead of DRV_NAME
>>> - use ARRAY_SIZE() whenever appropriate
>>> - use variable name "o" for message objects consistantly
>>> - use proper error code for cc770_probe_chip
>>> - remove unneeded member priv->open_time
>>> - remove unnecessary masking of u8 variables (with 0xff)
>>> - use "!skb" instead of "skb == NULL"
>>> - CC770_MSG_MAX now limits the number of messages read in the ISR
>>> - use "|" instead of "+" to combine bit masks
>>> - remove return code check of platform_get_resource() in remove function
>>> - remove postal address from GPL copyright text
>>> - fix WARNING: __packed is preferred over __attribute__((packed))
>>> - some more minor fixes (casts, white space, etc.)
>>
>> Feel free to add by Acked-by to patches 1 and 2.
> ^^
> my
Will do for the next version. You may also want to ack them explicitly.
Thanks,
Wolfgang.
^ permalink raw reply
* Re: [bug?] r8169: hangs under heavy load
From: Francois Romieu @ 2011-11-29 10:54 UTC (permalink / raw)
To: hayeswang
Cc: booster, 'Jonathan Nieder', 'Eric Dumazet',
netdev, 'nic_swsd', linux-kernel, 'Armin Kazmi'
In-Reply-To: <D95C09DB1A7E493E89FE5A0B3879CEB0@realtek.com.tw>
hayeswang <hayeswang@realtek.com> :
[...]
> For the 8168c and the later chips, our hardware engineer says that don't enable
> the RxFIFOOver of IntrMask and don't clear the RxFIFOOver of IntrStatus. The
> hardware will automatically escape Rx fifo full situation. Although you try to
> clear the RxFIFOOver of IntrStatus, maybe the bit wouldn't be cleared. Just
> disregard it.
Should "later" be understood as gigabit PCI-E only or is there a similar
difference of behavior between older fast-ethernet PCI-E and more recent
ones ?
Gerd, can you try the patch below ? It should match Haye's description.
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 6f06aa1..97b5593 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -4885,8 +4885,7 @@ static void rtl_hw_start_8168(struct net_device *dev)
RTL_W16(IntrMitigate, 0x5151);
/* Work around for RxFIFO overflow. */
- if (tp->mac_version == RTL_GIGA_MAC_VER_11 ||
- tp->mac_version == RTL_GIGA_MAC_VER_22) {
+ if (tp->mac_version == RTL_GIGA_MAC_VER_11) {
tp->intr_event |= RxFIFOOver | PCSTimeout;
tp->intr_event &= ~RxOverflow;
}
@@ -5804,6 +5803,10 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
*/
status = RTL_R16(IntrStatus);
while (status && status != 0xffff) {
+ status &= ~tp->intr_event;
+ if (!status)
+ break;
+
handled = 1;
/* Handle all of the error cases first. These will reset
@@ -5818,7 +5821,6 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
switch (tp->mac_version) {
/* Work around for rx fifo overflow */
case RTL_GIGA_MAC_VER_11:
- case RTL_GIGA_MAC_VER_22:
case RTL_GIGA_MAC_VER_26:
netif_stop_queue(dev);
rtl8169_tx_timeout(dev);
@@ -5828,6 +5830,7 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
case RTL_GIGA_MAC_VER_19:
case RTL_GIGA_MAC_VER_20:
case RTL_GIGA_MAC_VER_21:
+ case RTL_GIGA_MAC_VER_22:
case RTL_GIGA_MAC_VER_23:
case RTL_GIGA_MAC_VER_24:
case RTL_GIGA_MAC_VER_27:
^ permalink raw reply related
* Re: [PATCH net-next v4 0/4] can: cc770: add support for the Bosch CC770 and Intel AN82527
From: Marc Kleine-Budde @ 2011-11-29 10:51 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-can-u79uwXL29TY76Z2rM5mHXA,
socketcan-users-0fE9KPoRgkgATYTw5x5z8w, Wolfgang Zarre
In-Reply-To: <4ED4B838.2060307-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 2089 bytes --]
On 11/29/2011 11:47 AM, Marc Kleine-Budde wrote:
> On 11/29/2011 10:11 AM, Wolfgang Grandegger wrote:
>> Already since a while we have support for the Bosch CC770 and Intel
>> AN82527 CAN controllers in our out-of-tree Socket-CAN repository.
>>
>> In the meantime I found a TQM855L board with two AN82527 on it,
>> which allowed me to provide and test a generic platform driver
>> as well.
>>
>> Changes since v1:
>>
>> - remove version.h includes
>> - some minor corrections in the ISA bus driver
>> - add platform header file to the driver core
>> - add generic platform driver
>> - add and update device tree nodes for tqm8xx and tqm8548
>>
>> Changes since v2:
>>
>> - correct license text as suggest by Oliver Hartkopp
>> - use the new module_platform_driver function
>> - provide get_berr_counter callback for cc770
>> - improve CAN error state change handling
>> - more comprehensive cc770_isa driver description
>>
>> Changes since v3:
>>
>> - pre-define pr_fmt()
>> - use KBUILD_MODNAME instead of DRV_NAME
>> - use ARRAY_SIZE() whenever appropriate
>> - use variable name "o" for message objects consistantly
>> - use proper error code for cc770_probe_chip
>> - remove unneeded member priv->open_time
>> - remove unnecessary masking of u8 variables (with 0xff)
>> - use "!skb" instead of "skb == NULL"
>> - CC770_MSG_MAX now limits the number of messages read in the ISR
>> - use "|" instead of "+" to combine bit masks
>> - remove return code check of platform_get_resource() in remove function
>> - remove postal address from GPL copyright text
>> - fix WARNING: __packed is preferred over __attribute__((packed))
>> - some more minor fixes (casts, white space, etc.)
>
> Feel free to add by Acked-by to patches 1 and 2.
^^
my
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 191 bytes --]
_______________________________________________
Socketcan-users mailing list
Socketcan-users-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-users
^ permalink raw reply
* RE: ebtables on a stick
From: Greg Scott @ 2011-11-29 10:48 UTC (permalink / raw)
To: David Lamparter; +Cc: netdev
In-Reply-To: <20111129102338.GF589422@jupiter.n2.diac24.net>
Well this seems like the only way to get done what I need, so if our
votes count, we'll vote to leave it in. Let me get some sleep and I'll
try it and report back here later.
- Greg
-----Original Message-----
From: David Lamparter [mailto:equinox@diac24.net]
Sent: Tuesday, November 29, 2011 4:24 AM
To: Greg Scott
Cc: David Lamparter; netdev@vger.kernel.org
Subject: Re: ebtables on a stick
On Tue, Nov 29, 2011 at 04:05:18AM -0600, Greg Scott wrote:
> > We already had this discussion in July.
> >
> > "ip neigh add proxy" is independent of /proc/.../proxy_arp.
>
> We did discuss this back in July but never finished. I posted a bunch
> of questions about "ip neigh add proxy" because I haven't seen much in
> the way of documentation. When nobody answered, I left it alone for a
> while.
>
> I found a discussion starting here:
> http://lkml.indiana.edu/hypermail/linux/kernel/0110.2/0523.html
>
> where some of the kernel folks are suggesting "ip neigh add proxy" is
> deprecated. By now that discussion is 10 years old and it apparently
is
> still around. But for how long?
While the feature is still around after 10 years, Alexey isn't touching
the network stack much anymore. Funny, that.
> Appendix B of this 2007 document, http://linux-ip.net/html/index.html,
> by Martin Brown also says "ip neigh add proxy" is deprecated.
>
> So now, in addition to my paranoia about proxy ARP in general, I have
> this fear I will build a bunch of scripting around "ip neigh add
proxy"
> only to find it's gone in a future kernel, leaving me in a world of
hurt
> again.
>
> So humor me and convince me that "ip neigh add" is not on the chopping
> block so I can try it with a little bit of confidence.
I'll humor myself instead. I'm shipping this as a feature to customers,
so if it comes up for chopping I'll have to maintain it myself
worst-case.
(I wasn't actually aware that this is supposed to be deprecated. Yes,
it's buggy in that you need "arp" to show the entries, but that's exacly
that - a low-severity bug.)
-David
^ permalink raw reply
* Re: [PATCH net-next v4 0/4] can: cc770: add support for the Bosch CC770 and Intel AN82527
From: Marc Kleine-Budde @ 2011-11-29 10:47 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-can-u79uwXL29TY76Z2rM5mHXA,
socketcan-users-0fE9KPoRgkgATYTw5x5z8w, Wolfgang Zarre
In-Reply-To: <1322557890-6363-1-git-send-email-wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 3821 bytes --]
On 11/29/2011 10:11 AM, Wolfgang Grandegger wrote:
> Already since a while we have support for the Bosch CC770 and Intel
> AN82527 CAN controllers in our out-of-tree Socket-CAN repository.
>
> In the meantime I found a TQM855L board with two AN82527 on it,
> which allowed me to provide and test a generic platform driver
> as well.
>
> Changes since v1:
>
> - remove version.h includes
> - some minor corrections in the ISA bus driver
> - add platform header file to the driver core
> - add generic platform driver
> - add and update device tree nodes for tqm8xx and tqm8548
>
> Changes since v2:
>
> - correct license text as suggest by Oliver Hartkopp
> - use the new module_platform_driver function
> - provide get_berr_counter callback for cc770
> - improve CAN error state change handling
> - more comprehensive cc770_isa driver description
>
> Changes since v3:
>
> - pre-define pr_fmt()
> - use KBUILD_MODNAME instead of DRV_NAME
> - use ARRAY_SIZE() whenever appropriate
> - use variable name "o" for message objects consistantly
> - use proper error code for cc770_probe_chip
> - remove unneeded member priv->open_time
> - remove unnecessary masking of u8 variables (with 0xff)
> - use "!skb" instead of "skb == NULL"
> - CC770_MSG_MAX now limits the number of messages read in the ISR
> - use "|" instead of "+" to combine bit masks
> - remove return code check of platform_get_resource() in remove function
> - remove postal address from GPL copyright text
> - fix WARNING: __packed is preferred over __attribute__((packed))
> - some more minor fixes (casts, white space, etc.)
Feel free to add by Acked-by to patches 1 and 2.
Marc
>
> It would be nice if somebody else could test the driver, especially
> the ISA driver (I don't have hardware at hand).
>
> Wolfgang.
>
> Wolfgang Grandegger (4):
> can: cc770: add driver core for the Bosch CC770 and Intel AN82527
> can: cc770: add legacy ISA bus driver for the CC770 and AN82527
> can: cc770: add platform bus driver for the CC770 and AN82527
> powerpc: tqm8548/tqm8xx: add and update CAN device nodes
>
> .../devicetree/bindings/net/can/cc770.txt | 56 ++
> arch/powerpc/boot/dts/tqm8548-bigflash.dts | 19 +-
> arch/powerpc/boot/dts/tqm8548.dts | 19 +-
> arch/powerpc/boot/dts/tqm8xx.dts | 25 +
> drivers/net/can/Kconfig | 2 +
> drivers/net/can/Makefile | 1 +
> drivers/net/can/cc770/Kconfig | 21 +
> drivers/net/can/cc770/Makefile | 9 +
> drivers/net/can/cc770/cc770.c | 881 ++++++++++++++++++++
> drivers/net/can/cc770/cc770.h | 203 +++++
> drivers/net/can/cc770/cc770_isa.c | 366 ++++++++
> drivers/net/can/cc770/cc770_platform.c | 273 ++++++
> include/linux/can/platform/cc770.h | 33 +
> 13 files changed, 1898 insertions(+), 10 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/net/can/cc770.txt
> create mode 100644 drivers/net/can/cc770/Kconfig
> create mode 100644 drivers/net/can/cc770/Makefile
> create mode 100644 drivers/net/can/cc770/cc770.c
> create mode 100644 drivers/net/can/cc770/cc770.h
> create mode 100644 drivers/net/can/cc770/cc770_isa.c
> create mode 100644 drivers/net/can/cc770/cc770_platform.c
> create mode 100644 include/linux/can/platform/cc770.h
>
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 191 bytes --]
_______________________________________________
Socketcan-users mailing list
Socketcan-users-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-users
^ permalink raw reply
* Re: [PATCH 5/5] tcp: skip cwnd moderation in TCP_CA_Open in tcp_try_to_open
From: Ilpo Järvinen @ 2011-11-29 10:33 UTC (permalink / raw)
To: Yuchung Cheng; +Cc: Neal Cardwell, David Miller, Netdev, nanditad, therbert
In-Reply-To: <CAK6E8=dfjZ0tGnihL8cvrg0J=trj2UdB5s3ry+TvdG9Yhzf9jA@mail.gmail.com>
On Mon, 28 Nov 2011, Yuchung Cheng wrote:
> On Mon, Nov 28, 2011 at 9:35 AM, Neal Cardwell <ncardwell@google.com> wrote:
> > On Sun, Nov 27, 2011 at 7:01 PM, David Miller <davem@davemloft.net> wrote:
> >> I'm apply this patch to net-next now, but Neil and Yucheng are on the hook
> >> to fully look into the issues Ilpo has raised.
> >
> > Thanks! We will spend some time looking into these issues.
> >
> Ilpo do you know any report on these types of cheating? I did some
> literature search but didn't find any.
No I know of, however, I'm not too surprised as so far such attacks have
lacked a target at least among Linux endhosts. It is only possible to gain
something now after you have one by one removed all safeguards which
prevent such misuse :-). This possibility is certainly known to exists
(even RFC3708 mentions it).
Besides, DSACK adoption, not to speak of adoption of any DSACK undo
algorithm, is not that high as with SACK alone iirc.
> If the receiver simply responds DSACK on good (non-spurious)
> retransmits, the sender may increase dupthresh (tp->reordering) and
> slows down triggering fast-recovery? given the connection has real
> losses, the receiver may end up shooting his feet.
For some attack variants, yes. However, it is always "safe" to attack
the current Linux sender with something that is past the acknowledgment
number, there's only dummy counting done for that (trivial to arrange). If
the attacker plays safe, no tp->reordering effect is ever imposed but
attack eventually succeeds to hit the right number of undo_retrans no
matter what if one keeps trying. This is what you just asked us to
enable, unlimited attack window! Perhaps we could add a penalty of
misguessing the number of rexmits but knowing the right number is not that
hard anyway (and some caveats exist in such approach though to those who
are hit by HW/path duping).
Btw, another thing that should be auditted now that this was applied:
check that undo_marker checks do not behave bad due to 32-bit seqno
wrap-arounds since its needs-to-be-valid period got just extented way
beyond a single loss event.
--
i.
^ permalink raw reply
* Re: [PATCH 1/1] netstamp_needed shouldn't be jump_label_key
From: Igor Maravić @ 2011-11-29 10:32 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1322562450.2285.15.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Sorry,
just send another without using your remarks...
Thaks
Will listen to you in future.
BR
Igor
2011/11/29 Eric Dumazet <eric.dumazet@gmail.com>:
> Le mardi 29 novembre 2011 à 10:48 +0100, "Igor Maravić" a écrit :
>
>>
>> PS. Tested the patch - it works.
>>
>> [PATCH 1/1] Warning if_interrupt is true
>
> Few remarks, since you start to send official patches ;)
>
> - Since its not a serie of several patches, you dont need the 1/1
> - Since tree is net-next, not net, you should say it to David
> - We need a better title, with subsystem: tag, for example
>
> Here, it can be "net:"
>
> [PATCH net-next] net: check net_enable_timestamp() is not called in irq context
>
>>
>> Move warning on the top of function net_enable_timestamp,
>> so we would be also warn if we are going to use jump_label_dec in interrupt
>>
>> Signed-off-by: Igor Maravic <igorm@etf.rs>
>>
>> :100644 100644 45eab03... d358088... M net/core/dev.c
>>
>
> Missing "---" separator
>
> Please carefully read Documentation/SubmittingPatches
>
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index 45eab03..d358088 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -1451,16 +1451,18 @@ static atomic_t netstamp_needed_deferred;
>>
>> void net_enable_timestamp(void)
>> {
>> + WARN_ON(in_interrupt());
>> #ifdef HAVE_JUMP_LABEL
>> - int deferred = atomic_xchg(&netstamp_needed_deferred, 0);
>> -
>> - if (deferred) {
>> - while (--deferred)
>> - jump_label_dec(&netstamp_needed);
>> - return;
>> + {
>> + int deferred = atomic_xchg(&netstamp_needed_deferred, 0);
>> +
>> + if (deferred) {
>> + while (--deferred)
>> + jump_label_dec(&netstamp_needed);
>> + return;
>> + }
>> }
>> #endif
>> - WARN_ON(in_interrupt());
>> jump_label_inc(&netstamp_needed);
>> }
>> EXPORT_SYMBOL(net_enable_timestamp);
>
>
>
^ permalink raw reply
* [PATCH] Fix jump_label handling in dev.c
From: igorm @ 2011-11-29 10:30 UTC (permalink / raw)
To: netdev; +Cc: eric.dumazet, Igor Maravic
From: Igor Maravic <igorm@etf.rs>
static_branch instead of atomic_read.
Eric forgot to replace that.
Signed-off-by: Igor Maravic <igorm@etf.rs>
:100644 100644 579ce33... d358088... M net/core/dev.c
diff --git a/net/core/dev.c b/net/core/dev.c
index 579ce33..d358088 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1482,12 +1482,12 @@ EXPORT_SYMBOL(net_disable_timestamp);
static inline void net_timestamp_set(struct sk_buff *skb)
{
skb->tstamp.tv64 = 0;
- if (atomic_read(&netstamp_needed))
+ if (static_branch(&netstamp_needed))
__net_timestamp(skb);
}
#define net_timestamp_check(COND, SKB) \
- if (atomic_read(&netstamp_needed)) { \
+ if (static_branch(&netstamp_needed)) { \
if ((COND) && !(SKB)->tstamp.tv64) \
__net_timestamp(SKB); \
} \
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH 1/1] netstamp_needed shouldn't be jump_label_key
From: Eric Dumazet @ 2011-11-29 10:27 UTC (permalink / raw)
To: igorm; +Cc: netdev
In-Reply-To: <88caa73892721f74b81e72c1ff1a0be3.squirrel@kondor.etf.bg.ac.rs>
Le mardi 29 novembre 2011 à 10:48 +0100, "Igor Maravić" a écrit :
>
> PS. Tested the patch - it works.
>
> [PATCH 1/1] Warning if_interrupt is true
Few remarks, since you start to send official patches ;)
- Since its not a serie of several patches, you dont need the 1/1
- Since tree is net-next, not net, you should say it to David
- We need a better title, with subsystem: tag, for example
Here, it can be "net:"
[PATCH net-next] net: check net_enable_timestamp() is not called in irq context
>
> Move warning on the top of function net_enable_timestamp,
> so we would be also warn if we are going to use jump_label_dec in interrupt
>
> Signed-off-by: Igor Maravic <igorm@etf.rs>
>
> :100644 100644 45eab03... d358088... M net/core/dev.c
>
Missing "---" separator
Please carefully read Documentation/SubmittingPatches
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 45eab03..d358088 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -1451,16 +1451,18 @@ static atomic_t netstamp_needed_deferred;
>
> void net_enable_timestamp(void)
> {
> + WARN_ON(in_interrupt());
> #ifdef HAVE_JUMP_LABEL
> - int deferred = atomic_xchg(&netstamp_needed_deferred, 0);
> -
> - if (deferred) {
> - while (--deferred)
> - jump_label_dec(&netstamp_needed);
> - return;
> + {
> + int deferred = atomic_xchg(&netstamp_needed_deferred, 0);
> +
> + if (deferred) {
> + while (--deferred)
> + jump_label_dec(&netstamp_needed);
> + return;
> + }
> }
> #endif
> - WARN_ON(in_interrupt());
> jump_label_inc(&netstamp_needed);
> }
> EXPORT_SYMBOL(net_enable_timestamp);
^ permalink raw reply
* Re: ebtables on a stick
From: David Lamparter @ 2011-11-29 10:23 UTC (permalink / raw)
To: Greg Scott; +Cc: David Lamparter, netdev
In-Reply-To: <925A849792280C4E80C5461017A4B8A2A048BC@mail733.InfraSupportEtc.com>
On Tue, Nov 29, 2011 at 04:05:18AM -0600, Greg Scott wrote:
> > We already had this discussion in July.
> >
> > "ip neigh add proxy" is independent of /proc/.../proxy_arp.
>
> We did discuss this back in July but never finished. I posted a bunch
> of questions about "ip neigh add proxy" because I haven't seen much in
> the way of documentation. When nobody answered, I left it alone for a
> while.
>
> I found a discussion starting here:
> http://lkml.indiana.edu/hypermail/linux/kernel/0110.2/0523.html
>
> where some of the kernel folks are suggesting "ip neigh add proxy" is
> deprecated. By now that discussion is 10 years old and it apparently is
> still around. But for how long?
While the feature is still around after 10 years, Alexey isn't touching
the network stack much anymore. Funny, that.
> Appendix B of this 2007 document, http://linux-ip.net/html/index.html,
> by Martin Brown also says "ip neigh add proxy" is deprecated.
>
> So now, in addition to my paranoia about proxy ARP in general, I have
> this fear I will build a bunch of scripting around "ip neigh add proxy"
> only to find it's gone in a future kernel, leaving me in a world of hurt
> again.
>
> So humor me and convince me that "ip neigh add" is not on the chopping
> block so I can try it with a little bit of confidence.
I'll humor myself instead. I'm shipping this as a feature to customers,
so if it comes up for chopping I'll have to maintain it myself
worst-case.
(I wasn't actually aware that this is supposed to be deprecated. Yes,
it's buggy in that you need "arp" to show the entries, but that's exacly
that - a low-severity bug.)
-David
^ permalink raw reply
* [PATCH 5/5] SUNRPC: kernel PipeFS mount point creation routines removed
From: Stanislav Kinsbursky @ 2011-11-29 10:10 UTC (permalink / raw)
To: Trond.Myklebust
Cc: linux-nfs, xemul, neilb, netdev, linux-kernel, jbottomley,
bfields, davem, devel
In-Reply-To: <20111129090754.20730.64567.stgit@localhost6.localdomain6>
This patch removes static rpc_mnt variable and its creation and destruction
routines, because they are not used anymore.
Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
---
include/linux/sunrpc/rpc_pipe_fs.h | 2 --
net/sunrpc/rpc_pipe.c | 21 ---------------------
2 files changed, 0 insertions(+), 23 deletions(-)
diff --git a/include/linux/sunrpc/rpc_pipe_fs.h b/include/linux/sunrpc/rpc_pipe_fs.h
index 7eb0160..a28d2de 100644
--- a/include/linux/sunrpc/rpc_pipe_fs.h
+++ b/include/linux/sunrpc/rpc_pipe_fs.h
@@ -90,8 +90,6 @@ void rpc_destroy_pipe_data(struct rpc_pipe *pipe);
extern struct dentry *rpc_mkpipe_dentry(struct dentry *, const char *, void *,
struct rpc_pipe *);
extern int rpc_unlink(struct dentry *);
-extern struct vfsmount *rpc_get_mount(void);
-extern void rpc_put_mount(void);
extern int register_rpc_pipefs(void);
extern void unregister_rpc_pipefs(void);
diff --git a/net/sunrpc/rpc_pipe.c b/net/sunrpc/rpc_pipe.c
index e194e32..4b1d042 100644
--- a/net/sunrpc/rpc_pipe.c
+++ b/net/sunrpc/rpc_pipe.c
@@ -18,7 +18,6 @@
#include <linux/kernel.h>
#include <asm/ioctls.h>
-#include <linux/fs.h>
#include <linux/poll.h>
#include <linux/wait.h>
#include <linux/seq_file.h>
@@ -37,9 +36,6 @@
#define NET_NAME(net) ((net == &init_net) ? " (init_net)" : "")
-static struct vfsmount *rpc_mnt __read_mostly;
-static int rpc_mount_count;
-
static struct file_system_type rpc_pipe_fs_type;
@@ -430,23 +426,6 @@ struct rpc_filelist {
umode_t mode;
};
-struct vfsmount *rpc_get_mount(void)
-{
- int err;
-
- err = simple_pin_fs(&rpc_pipe_fs_type, &rpc_mnt, &rpc_mount_count);
- if (err != 0)
- return ERR_PTR(err);
- return rpc_mnt;
-}
-EXPORT_SYMBOL_GPL(rpc_get_mount);
-
-void rpc_put_mount(void)
-{
- simple_release_fs(&rpc_mnt, &rpc_mount_count);
-}
-EXPORT_SYMBOL_GPL(rpc_put_mount);
-
static int rpc_delete_dentry(const struct dentry *dentry)
{
return 1;
^ permalink raw reply related
* [PATCH 4/5] NFS: remove RPC PipeFS mount point reference from blocklayout routines
From: Stanislav Kinsbursky @ 2011-11-29 10:10 UTC (permalink / raw)
To: Trond.Myklebust
Cc: linux-nfs, xemul, neilb, netdev, linux-kernel, jbottomley,
bfields, davem, devel
In-Reply-To: <20111129090754.20730.64567.stgit@localhost6.localdomain6>
This is a cleanup patch. We don't need this reference anymore, because
blocklayout pipes dentries now creates and destroys in per-net operations and
on PipeFS mount/umount notification.
Note that nfs4blocklayout_register_net() now returns 0 instead of -ENOENT in
case of PipeFS superblock absence. This is ok, because blocklayout pipe dentry
will be created on PipeFS mount event.
Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
---
fs/nfs/blocklayout/blocklayout.c | 9 +--------
1 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/fs/nfs/blocklayout/blocklayout.c b/fs/nfs/blocklayout/blocklayout.c
index acf7ac9..8211ffd 100644
--- a/fs/nfs/blocklayout/blocklayout.c
+++ b/fs/nfs/blocklayout/blocklayout.c
@@ -1032,7 +1032,7 @@ static struct dentry *nfs4blocklayout_register_net(struct net *net,
pipefs_sb = rpc_get_sb_net(net);
if (!pipefs_sb)
- return ERR_PTR(-ENOENT);
+ return 0;
dentry = nfs4blocklayout_register_sb(pipefs_sb, pipe);
rpc_put_sb_net(net);
return dentry;
@@ -1083,7 +1083,6 @@ static struct pernet_operations nfs4blocklayout_net_ops = {
static int __init nfs4blocklayout_init(void)
{
- struct vfsmount *mnt;
int ret;
dprintk("%s: NFSv4 Block Layout Driver Registering...\n", __func__);
@@ -1093,12 +1092,6 @@ static int __init nfs4blocklayout_init(void)
goto out;
init_waitqueue_head(&bl_wq);
-
- mnt = rpc_get_mount();
- if (IS_ERR(mnt)) {
- ret = PTR_ERR(mnt);
- goto out_remove;
- }
ret = rpc_pipefs_notifier_register(&nfs4blocklayout_block);
if (ret)
goto out_remove;
^ permalink raw reply related
* [PATCH 3/5] NFS: blocklayout PipeFS notifier introduced
From: Stanislav Kinsbursky @ 2011-11-29 10:10 UTC (permalink / raw)
To: Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA
Cc: linux-nfs-u79uwXL29TY76Z2rM5mHXA, xemul-bzQdu9zFT3WakBO8gow8eQ,
neilb-l3A5Bk7waGM, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
jbottomley-bzQdu9zFT3WakBO8gow8eQ, bfields-uC3wQj2KruNg9hUCZPvPmw,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, devel-GEFAQzZX7r8dnm+yROfE0A
In-Reply-To: <20111129090754.20730.64567.stgit-bi+AKbBUZKagILUCTcTcHdKyNwTtLsGr@public.gmane.org>
This patch subscribes blocklayout pipes to RPC pipefs notifications. Notifier
is registering on blocklayout module load. This notifier callback is
responsible for creation/destruction of PipeFS blocklayout pipe dentry.
Note that no locking required in notifier callback because PipeFS superblock
pointer is passed as an argument from it's creation or destruction routine and
thus we can be sure about it's validity.
Signed-off-by: Stanislav Kinsbursky <skinsbursky-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
---
fs/nfs/blocklayout/blocklayout.c | 48 +++++++++++++++++++++++++++++++++++++-
1 files changed, 47 insertions(+), 1 deletions(-)
diff --git a/fs/nfs/blocklayout/blocklayout.c b/fs/nfs/blocklayout/blocklayout.c
index bf20187..acf7ac9 100644
--- a/fs/nfs/blocklayout/blocklayout.c
+++ b/fs/nfs/blocklayout/blocklayout.c
@@ -984,6 +984,46 @@ static void nfs4blocklayout_unregister_sb(struct super_block *sb,
rpc_unlink(pipe->dentry);
}
+static int rpc_pipefs_event(struct notifier_block *nb, unsigned long event,
+ void *ptr)
+{
+ struct super_block *sb = ptr;
+ struct net *net = sb->s_fs_info;
+ struct nfs_net *nn = net_generic(net, nfs_net_id);
+ struct dentry *dentry;
+ int ret = 0;
+
+ if (!try_module_get(THIS_MODULE))
+ return 0;
+
+ if (nn->bl_device_pipe == NULL)
+ return 0;
+
+ switch (event) {
+ case RPC_PIPEFS_MOUNT:
+ dentry = nfs4blocklayout_register_sb(sb, nn->bl_device_pipe);
+ if (IS_ERR(dentry)) {
+ ret = PTR_ERR(dentry);
+ break;
+ }
+ nn->bl_device_pipe->dentry = dentry;
+ break;
+ case RPC_PIPEFS_UMOUNT:
+ if (nn->bl_device_pipe->dentry)
+ nfs4blocklayout_unregister_sb(sb, nn->bl_device_pipe);
+ break;
+ default:
+ ret = -ENOTSUPP;
+ break;
+ }
+ module_put(THIS_MODULE);
+ return ret;
+}
+
+static struct notifier_block nfs4blocklayout_block = {
+ .notifier_call = rpc_pipefs_event,
+};
+
static struct dentry *nfs4blocklayout_register_net(struct net *net,
struct rpc_pipe *pipe)
{
@@ -1059,12 +1099,17 @@ static int __init nfs4blocklayout_init(void)
ret = PTR_ERR(mnt);
goto out_remove;
}
- ret = register_pernet_subsys(&nfs4blocklayout_net_ops);
+ ret = rpc_pipefs_notifier_register(&nfs4blocklayout_block);
if (ret)
goto out_remove;
+ ret = register_pernet_subsys(&nfs4blocklayout_net_ops);
+ if (ret)
+ goto out_notifier;
out:
return ret;
+out_notifier:
+ rpc_pipefs_notifier_unregister(&nfs4blocklayout_block);
out_remove:
pnfs_unregister_layoutdriver(&blocklayout_type);
return ret;
@@ -1075,6 +1120,7 @@ static void __exit nfs4blocklayout_exit(void)
dprintk("%s: NFSv4 Block Layout Driver Unregistering...\n",
__func__);
+ rpc_pipefs_notifier_unregister(&nfs4blocklayout_block);
unregister_pernet_subsys(&nfs4blocklayout_net_ops);
pnfs_unregister_layoutdriver(&blocklayout_type);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 2/5] NFS: blocklayout pipe creation per network namespace context introduced
From: Stanislav Kinsbursky @ 2011-11-29 10:10 UTC (permalink / raw)
To: Trond.Myklebust
Cc: linux-nfs, xemul, neilb, netdev, linux-kernel, jbottomley,
bfields, davem, devel
In-Reply-To: <20111129090754.20730.64567.stgit@localhost6.localdomain6>
This patch implements blocklayout pipe creation and registration per each
existent network namespace.
This was achived by registering NFS per-net operations, responsible for
blocklayout pipe allocation/register and unregister/destruction instead of
initialization and destruction of static "bl_device_pipe" pipe (this one was
removed).
Note, than pointer to network blocklayout pipe is stored in per-net "nfs_net"
structure, because allocating of one more per-net structure for blocklayout
module looks redundant.
This patch also changes dev_remove() function prototype (and all it's callers,
where it' requied) by adding network namespace pointer parameter, which is used
to discover proper blocklayout pipe for rpc_queue_upcall() call.
Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
---
fs/nfs/blocklayout/blocklayout.c | 49 ++++++++++++++++++++++++-----------
fs/nfs/blocklayout/blocklayout.h | 3 +-
fs/nfs/blocklayout/blocklayoutdev.c | 5 +++-
fs/nfs/blocklayout/blocklayoutdm.c | 7 +++--
fs/nfs/inode.c | 1 +
fs/nfs/netns.h | 1 +
6 files changed, 46 insertions(+), 20 deletions(-)
diff --git a/fs/nfs/blocklayout/blocklayout.c b/fs/nfs/blocklayout/blocklayout.c
index 50d5183..bf20187 100644
--- a/fs/nfs/blocklayout/blocklayout.c
+++ b/fs/nfs/blocklayout/blocklayout.c
@@ -46,7 +46,6 @@ MODULE_LICENSE("GPL");
MODULE_AUTHOR("Andy Adamson <andros@citi.umich.edu>");
MODULE_DESCRIPTION("The NFSv4.1 pNFS Block layout driver");
-struct rpc_pipe *bl_device_pipe;
wait_queue_head_t bl_wq;
static void print_page(struct page *page)
@@ -1011,6 +1010,37 @@ static void nfs4blocklayout_unregister_net(struct net *net,
}
}
+static int nfs4blocklayout_net_init(struct net *net)
+{
+ struct nfs_net *nn = net_generic(net, nfs_net_id);
+ struct dentry *dentry;
+
+ nn->bl_device_pipe = rpc_mkpipe_data(&bl_upcall_ops, 0);
+ if (IS_ERR(nn->bl_device_pipe))
+ return PTR_ERR(nn->bl_device_pipe);
+ dentry = nfs4blocklayout_register_net(net, nn->bl_device_pipe);
+ if (IS_ERR(dentry)) {
+ rpc_destroy_pipe_data(nn->bl_device_pipe);
+ return PTR_ERR(dentry);
+ }
+ nn->bl_device_pipe->dentry = dentry;
+ return 0;
+}
+
+static void nfs4blocklayout_net_exit(struct net *net)
+{
+ struct nfs_net *nn = net_generic(net, nfs_net_id);
+
+ nfs4blocklayout_unregister_net(net, nn->bl_device_pipe);
+ rpc_destroy_pipe_data(nn->bl_device_pipe);
+ nn->bl_device_pipe = NULL;
+}
+
+static struct pernet_operations nfs4blocklayout_net_ops = {
+ .init = nfs4blocklayout_net_init,
+ .exit = nfs4blocklayout_net_exit,
+};
+
static int __init nfs4blocklayout_init(void)
{
struct vfsmount *mnt;
@@ -1029,22 +1059,12 @@ static int __init nfs4blocklayout_init(void)
ret = PTR_ERR(mnt);
goto out_remove;
}
- bl_device_pipe = rpc_mkpipe_data(&bl_upcall_ops, 0);
- if (IS_ERR(bl_device_pipe)) {
- ret = PTR_ERR(bl_device_pipe);
+ ret = register_pernet_subsys(&nfs4blocklayout_net_ops);
+ if (ret)
goto out_remove;
- }
- bl_device_pipe->dentry = nfs4blocklayout_register_net(&init_net,
- bl_device_pipe);
- if (IS_ERR(bl_device_pipe->dentry)) {
- ret = PTR_ERR(bl_device_pipe->dentry);
- goto out_destroy_pipe;
- }
out:
return ret;
-out_destroy_pipe:
- rpc_destroy_pipe_data(bl_device_pipe);
out_remove:
pnfs_unregister_layoutdriver(&blocklayout_type);
return ret;
@@ -1055,9 +1075,8 @@ static void __exit nfs4blocklayout_exit(void)
dprintk("%s: NFSv4 Block Layout Driver Unregistering...\n",
__func__);
+ unregister_pernet_subsys(&nfs4blocklayout_net_ops);
pnfs_unregister_layoutdriver(&blocklayout_type);
- nfs4blocklayout_unregister_net(&init_net, bl_device_pipe);
- rpc_destroy_pipe_data(bl_device_pipe);
}
MODULE_ALIAS("nfs-layouttype4-3");
diff --git a/fs/nfs/blocklayout/blocklayout.h b/fs/nfs/blocklayout/blocklayout.h
index 5f30941..059d95a 100644
--- a/fs/nfs/blocklayout/blocklayout.h
+++ b/fs/nfs/blocklayout/blocklayout.h
@@ -37,6 +37,7 @@
#include <linux/sunrpc/rpc_pipe_fs.h>
#include "../pnfs.h"
+#include "../netns.h"
#define PAGE_CACHE_SECTORS (PAGE_CACHE_SIZE >> SECTOR_SHIFT)
#define PAGE_CACHE_SECTOR_SHIFT (PAGE_CACHE_SHIFT - SECTOR_SHIFT)
@@ -50,6 +51,7 @@ struct pnfs_block_dev {
struct list_head bm_node;
struct nfs4_deviceid bm_mdevid; /* associated devid */
struct block_device *bm_mdev; /* meta device itself */
+ struct net *net;
};
enum exstate4 {
@@ -159,7 +161,6 @@ struct bl_msg_hdr {
u16 totallen; /* length of entire message, including hdr itself */
};
-extern struct rpc_pipe *bl_device_pipe;
extern wait_queue_head_t bl_wq;
#define BL_DEVICE_UMOUNT 0x0 /* Umount--delete devices */
diff --git a/fs/nfs/blocklayout/blocklayoutdev.c b/fs/nfs/blocklayout/blocklayoutdev.c
index 79f4752..8893247 100644
--- a/fs/nfs/blocklayout/blocklayoutdev.c
+++ b/fs/nfs/blocklayout/blocklayoutdev.c
@@ -142,6 +142,8 @@ nfs4_blk_decode_device(struct nfs_server *server,
DECLARE_WAITQUEUE(wq, current);
struct bl_dev_msg *reply = &bl_mount_reply;
int offset, len, i;
+ struct net *net = server->nfs_client->net;
+ struct nfs_net *nn = net_generic(net, nfs_net_id);
dprintk("%s CREATING PIPEFS MESSAGE\n", __func__);
dprintk("%s: deviceid: %s, mincount: %d\n", __func__, dev->dev_id.data,
@@ -168,7 +170,7 @@ nfs4_blk_decode_device(struct nfs_server *server,
dprintk("%s CALLING USERSPACE DAEMON\n", __func__);
add_wait_queue(&bl_wq, &wq);
- if (rpc_queue_upcall(bl_device_pipe, &msg) < 0) {
+ if (rpc_queue_upcall(nn->bl_device_pipe, &msg) < 0) {
remove_wait_queue(&bl_wq, &wq);
goto out;
}
@@ -200,6 +202,7 @@ nfs4_blk_decode_device(struct nfs_server *server,
rv->bm_mdev = bd;
memcpy(&rv->bm_mdevid, &dev->dev_id, sizeof(struct nfs4_deviceid));
+ rv->net = net;
dprintk("%s Created device %s with bd_block_size %u\n",
__func__,
bd->bd_disk->disk_name,
diff --git a/fs/nfs/blocklayout/blocklayoutdm.c b/fs/nfs/blocklayout/blocklayoutdm.c
index 631f254..970490f 100644
--- a/fs/nfs/blocklayout/blocklayoutdm.c
+++ b/fs/nfs/blocklayout/blocklayoutdm.c
@@ -38,7 +38,7 @@
#define NFSDBG_FACILITY NFSDBG_PNFS_LD
-static void dev_remove(dev_t dev)
+static void dev_remove(struct net *net, dev_t dev)
{
struct rpc_pipe_msg msg;
struct bl_dev_msg bl_umount_request;
@@ -48,6 +48,7 @@ static void dev_remove(dev_t dev)
};
uint8_t *dataptr;
DECLARE_WAITQUEUE(wq, current);
+ struct nfs_net *nn = net_generic(net, nfs_net_id);
dprintk("Entering %s\n", __func__);
@@ -66,7 +67,7 @@ static void dev_remove(dev_t dev)
msg.len = sizeof(bl_msg) + bl_msg.totallen;
add_wait_queue(&bl_wq, &wq);
- if (rpc_queue_upcall(bl_device_pipe, &msg) < 0) {
+ if (rpc_queue_upcall(nn->bl_device_pipe, &msg) < 0) {
remove_wait_queue(&bl_wq, &wq);
goto out;
}
@@ -93,7 +94,7 @@ static void nfs4_blk_metadev_release(struct pnfs_block_dev *bdev)
printk(KERN_ERR "%s nfs4_blkdev_put returns %d\n",
__func__, rv);
- dev_remove(bdev->bm_mdev->bd_dev);
+ dev_remove(bdev->net, bdev->bm_mdev->bd_dev);
}
void bl_free_block_dev(struct pnfs_block_dev *bdev)
diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
index 84d8506..f48790c 100644
--- a/fs/nfs/inode.c
+++ b/fs/nfs/inode.c
@@ -1552,6 +1552,7 @@ static void nfsiod_stop(void)
}
int nfs_net_id;
+EXPORT_SYMBOL_GPL(nfs_net_id);
static int nfs_net_init(struct net *net)
{
diff --git a/fs/nfs/netns.h b/fs/nfs/netns.h
index 8c1f130..39ae4ca 100644
--- a/fs/nfs/netns.h
+++ b/fs/nfs/netns.h
@@ -6,6 +6,7 @@
struct nfs_net {
struct cache_detail *nfs_dns_resolve;
+ struct rpc_pipe *bl_device_pipe;
};
extern int nfs_net_id;
^ permalink raw reply related
* [PATCH 1/5] NFS: handle blocklayout pipe PipeFS dentry by network namespace aware routines
From: Stanislav Kinsbursky @ 2011-11-29 10:10 UTC (permalink / raw)
To: Trond.Myklebust
Cc: linux-nfs, xemul, neilb, netdev, linux-kernel, jbottomley,
bfields, davem, devel
In-Reply-To: <20111129090754.20730.64567.stgit@localhost6.localdomain6>
This patch makes blocklayout pipe dentry allocated and destroyed in network
namespace context by PipeFS network namespace aware routines.
Network namespace context is obtained from nfs_client structure.
Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
---
fs/nfs/blocklayout/blocklayout.c | 60 +++++++++++++++++++++++++++++++-------
1 files changed, 49 insertions(+), 11 deletions(-)
diff --git a/fs/nfs/blocklayout/blocklayout.c b/fs/nfs/blocklayout/blocklayout.c
index c26633e..50d5183 100644
--- a/fs/nfs/blocklayout/blocklayout.c
+++ b/fs/nfs/blocklayout/blocklayout.c
@@ -965,10 +965,55 @@ static const struct rpc_pipe_ops bl_upcall_ops = {
.destroy_msg = bl_pipe_destroy_msg,
};
+static struct dentry *nfs4blocklayout_register_sb(struct super_block *sb,
+ struct rpc_pipe *pipe)
+{
+ struct dentry *dir, *dentry;
+
+ dir = rpc_d_lookup_sb(sb, NFS_PIPE_DIRNAME);
+ if (dir == NULL)
+ return ERR_PTR(-ENOENT);
+ dentry = rpc_mkpipe_dentry(dir, "blocklayout", NULL, pipe);
+ dput(dir);
+ return dentry;
+}
+
+static void nfs4blocklayout_unregister_sb(struct super_block *sb,
+ struct rpc_pipe *pipe)
+{
+ if (pipe->dentry)
+ rpc_unlink(pipe->dentry);
+}
+
+static struct dentry *nfs4blocklayout_register_net(struct net *net,
+ struct rpc_pipe *pipe)
+{
+ struct super_block *pipefs_sb;
+ struct dentry *dentry;
+
+ pipefs_sb = rpc_get_sb_net(net);
+ if (!pipefs_sb)
+ return ERR_PTR(-ENOENT);
+ dentry = nfs4blocklayout_register_sb(pipefs_sb, pipe);
+ rpc_put_sb_net(net);
+ return dentry;
+}
+
+static void nfs4blocklayout_unregister_net(struct net *net,
+ struct rpc_pipe *pipe)
+{
+ struct super_block *pipefs_sb;
+
+ pipefs_sb = rpc_get_sb_net(net);
+ if (pipefs_sb) {
+ nfs4blocklayout_unregister_sb(pipefs_sb, pipe);
+ rpc_put_sb_net(net);
+ }
+}
+
static int __init nfs4blocklayout_init(void)
{
struct vfsmount *mnt;
- struct path path;
int ret;
dprintk("%s: NFSv4 Block Layout Driver Registering...\n", __func__);
@@ -984,20 +1029,13 @@ static int __init nfs4blocklayout_init(void)
ret = PTR_ERR(mnt);
goto out_remove;
}
-
- ret = vfs_path_lookup(mnt->mnt_root,
- mnt,
- NFS_PIPE_DIRNAME, 0, &path);
- if (ret)
- goto out_remove;
-
bl_device_pipe = rpc_mkpipe_data(&bl_upcall_ops, 0);
if (IS_ERR(bl_device_pipe)) {
ret = PTR_ERR(bl_device_pipe);
goto out_remove;
}
- bl_device_pipe->dentry = rpc_mkpipe_dentry(path.dentry, "blocklayout",
- NULL, bl_device_pipe);
+ bl_device_pipe->dentry = nfs4blocklayout_register_net(&init_net,
+ bl_device_pipe);
if (IS_ERR(bl_device_pipe->dentry)) {
ret = PTR_ERR(bl_device_pipe->dentry);
goto out_destroy_pipe;
@@ -1018,7 +1056,7 @@ static void __exit nfs4blocklayout_exit(void)
__func__);
pnfs_unregister_layoutdriver(&blocklayout_type);
- rpc_unlink(bl_device_pipe->dentry);
+ nfs4blocklayout_unregister_net(&init_net, bl_device_pipe);
rpc_destroy_pipe_data(bl_device_pipe);
}
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox