* [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 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
* 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
* 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
* [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: 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
* 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 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: 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: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: [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: 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: [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] 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: 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 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: [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 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: [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: [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: [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[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 v4 02/10] net: Add queue state xoff flag for stack
From: jamal @ 2011-11-29 13:12 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <alpine.DEB.2.00.1111281816540.24308@pokey.mtv.corp.google.com>
On Mon, 2011-11-28 at 18:32 -0800, Tom Herbert wrote:
>
> enum netdev_queue_state_t {
> - __QUEUE_STATE_XOFF,
> + __QUEUE_STATE_DRV_XOFF,
> + __QUEUE_STATE_STACK_XOFF,
> __QUEUE_STATE_FROZEN,
QUEUE_STATE_DRV_XOFF seems to be a rename of __QUEUE_STATE_XOFF
no issues there.
Is inserting __QUEUE_STATE_STACK_XOFF going to cause any issues?
Typically, you should insert new things at the end.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 4/5] NFS: remove RPC PipeFS mount point reference from blocklayout routines
From: Stanislav Kinsbursky @ 2011-11-29 13:13 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: <F19688880B763E40B28B2B462677FBF805E3A4AFFD@MX09A.corp.emc.com>
29.11.2011 16:40, tao.peng@emc.com пишет:
>> -----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.
Sorry, but I don't get it. Probably we have misunderstanding here.
You said, that "blkmapd ... tries to open the pipe file when started". This pipe
file is located on PipeFS, isn't it?
If yes, then PipeFS have to be mounted already in user-space. And if it has been
mounted - then pipe dentry is present.
IOW, pipe (without dentry) will be created on module load. Pipe dentry will be
created right after that (like it was before) if PipeFS was mounted from
user-space. If not - then pipe dentry will be created on PipeFS (!) mount (not
NFS or pNFS mount) from user-space.
Or I'm missing something in your reply?
> 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.
>
The same logic here.
> Why not just fail to load module if you fail to initialize pipefs? When is rpc_get_sb_net() going to fail?
>
Sorry, but I don't understand, what is your idea. And why do we need to fail at all.
BTW, rpc_get_sb_net() just checks, was PipeFS mounted in passed net, or not. If
not - not a problem. Dentries will be created on mount event. If yes, then it
returns locked PipeFS sb and the next step is dentry creation.
>>
>>
>>> 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
>
--
Best regards,
Stanislav Kinsbursky
^ permalink raw reply
* Re: [RFC PATCH 00/18] netfilter: IPv6 NAT
From: Amos Jeffries @ 2011-11-29 13:24 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Ulrich Weber, sclark46@earthlink.net, kaber@trash.net,
netfilter-devel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <alpine.LNX.2.01.1111291255200.20965@frira.zrqbmnf.qr>
On 30/11/2011 1:23 a.m., Jan Engelhardt wrote:
> 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,
There you are adding a straw-man component into the mix. "Given two
uplinks that only allow a certain source network address ", yes I agree,
NAT is the sugar that makes these uplinks work. Irrelevant of load
balancing.
In the same way the security != NAT, so too load balancing != NAT. As
I'm sure you are all well aware.
Looking back at Ulrichs' original statement after reading yours it's
clear he probably meant that (I hope so at least). The first reading
though was that NAT by itself provided easy load balancing and DMZ. I
argue neither for or against validity of NAT. Just the Fuzziness
Uncertainty and Doubt created by the particular statement was of a high
amount.
> (b) the clients needs
> to cooperate, and one cannot always trust client devices, or hope for
> their technical cooperation (firewalled themselves off).
>
>
>> 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.
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter-devel" 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
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