* Re: [PATCH V5 2/6 net-next] netdevice.h: Add zero-copy flag in netdevice
From: Shirley Ma @ 2011-05-26 19:11 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Michał Mirosław, Ben Hutchings, David Miller,
Eric Dumazet, Avi Kivity, Arnd Bergmann, netdev, kvm,
linux-kernel
In-Reply-To: <20110526084916.GA17928@redhat.com>
On Thu, 2011-05-26 at 11:49 +0300, Michael S. Tsirkin wrote:
> >
> > > - SG support
> > > - HIGHDMA support (on arches where this makes sense)
> >
> > This can be checked by device flags.
>
> OK, but pls note that SG can get turned off dynamically.
Tested the patch w/i SG dynmically on/off and tcpdump suspended.
^ permalink raw reply
* Re: [patch] net/core/filter.c: Fix build error
From: Ingo Molnar @ 2011-05-26 19:09 UTC (permalink / raw)
To: David Miller; +Cc: joe, greearb, linux-kernel, linux-arch, arnd, netdev
In-Reply-To: <20110526.143843.205897228685761536.davem@davemloft.net>
* David Miller <davem@davemloft.net> wrote:
> From: Joe Perches <joe@perches.com>
> Date: Thu, 26 May 2011 08:31:06 -0700
>
> > My suggestion would be to see about again adding
> > #include <linux/ratelimit.h> somehow
> > back to kernel.h which commit 3fff4c42bd0a removed
> > in 2009 because of the spinlock issues.
> >
> > Any suggestion on how best to fix it generically?
>
> I don't think we want spinlock_t's definition being sucked
> into kernel.h's dependency food chain.
Agreed.
Also, i don't think it's unreasonable to require code that uses
DEFINE_RATELIMIT_STATE() to #include ratelimit.h. That's what we
require from DEFINE_MUTEX() and DEFINE_SPINLOCK() users and many
other users as well.
The only exception is printk_ratelimit() itself - that should not -
and currently does not - require the inclusion of ratelimit.h.
The *real* solution here would be to remove the spurious and .config
dependent inclusion of ratelimit.h in include/linux/net.h. It's fine
to provide the net_ratelimit() interface (it'sanalogous to
printk_ratelimit()), but it's not fine to declare net_ratelimit_state
in that header and include that header in half of all networking
code, bringing in ratelimit.h implicitly.
So no, i don't think your patch is the real solution. The problem was
that the .config's you tested had CONFIG_SYSCTL=y, which brought in
ratelimit.h into half of the networking code. That's unnecessary and
problematic - the interface between net/core/sysctl_net_core.c and
net/core/utils.c should be done via a dedicated header (not included
by other code), or via explicit extern declared in the .c file (more
dangerous, but used by pretty much all sysctl code in the kernel).
Thanks,
Ingo
^ permalink raw reply
* Re: [patch] net/core/filter.c: Fix build error
From: Joe Perches @ 2011-05-26 19:07 UTC (permalink / raw)
To: David Miller, Jiri Kosina
Cc: mingo, greearb, linux-kernel, linux-arch, arnd, netdev
In-Reply-To: <20110526.143843.205897228685761536.davem@davemloft.net>
On Thu, 2011-05-26 at 14:38 -0400, David Miller wrote:
> From: Joe Perches <joe@perches.com>
> Date: Thu, 26 May 2011 08:31:06 -0700
> > My suggestion would be to see about again adding
> > #include <linux/ratelimit.h> somehow
> > back to kernel.h which commit 3fff4c42bd0a removed
> > in 2009 because of the spinlock issues.
> > Any suggestion on how best to fix it generically?
> I don't think we want spinlock_t's definition being sucked
> into kernel.h's dependency food chain.
> Even if desirable, I think it'd be quite a bit of surgery,
> too much to do at this stage.
> So for now how about we make the ratelimit warn interfaces be a true,
> instead of a pseudo, dependency on ratelimit.h by moving those
> definitions into ratelimit.h?
Thanks, I suppose that's good enough for now.
Perhaps it'd also be good to move the pr_<level>_ratelimited
declarations from printk.h.
It seems that would not cause new compilation problems.
$ grep -rP --include=*.[ch] -wl "pr_[a-z]+_ratelimited" * | \
xargs grep -L "include.*ratelimit\.h"
include/linux/printk.h
And, though it's sure to cause some compilation problems:
$ grep -rP --include=*.[ch] -wl "printk_ratelimit" * | \
xargs grep -L "include.*ratelimit\.h" | wc -l
127
Perhaps it'd also be good to move the printk_ratelimit
block from printk.h into ratelimited.h and add
#include <linux/ratelimited.h> to the current source
files that use it in a later patchset.
Maybe Jiri could pick it up through trivial. Jiri?
^ permalink raw reply
* Re: linux-next: Tree for May 26 (drivers/net/caif)
From: Randy Dunlap @ 2011-05-26 19:07 UTC (permalink / raw)
To: Stephen Rothwell, netdev; +Cc: linux-next, LKML, Sjur Braendeland
In-Reply-To: <20110526163941.7dfcad1a.sfr@canb.auug.org.au>
On Thu, 26 May 2011 16:39:41 +1000 Stephen Rothwell wrote:
> Hi all,
>
> [The kernel.org mirroring is being slow today]
(not new)
drivers/net/caif/caif_serial.c:194: warning: 'return' with no value, in function returning non-void
drivers/net/caif/caif_serial.c:202: warning: 'return' with no value, in function returning non-void
I'm curious: how do warnings like this get overlooked?
too much noise in the build messages? or it wasn't overlooked, just ignored?
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH] sctp compilation failed due to lack of sctp_local_addr_free
From: Dmitry Kravkov @ 2011-05-26 19:07 UTC (permalink / raw)
To: David Miller
Cc: bruce.w.allan@intel.com, netdev@vger.kernel.org,
difrost.kernel@gmail.com
In-Reply-To: <20110526.144416.252997714470172705.davem@davemloft.net>
On Thu, 2011-05-26 at 11:44 -0700, David Miller wrote:
> From: "Allan, Bruce W" <bruce.w.allan@intel.com>
> Date: Thu, 26 May 2011 11:40:34 -0700
>
> >>-----Original Message-----
> >>From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
> >>Behalf Of David Miller
> >>Sent: Thursday, May 26, 2011 10:39 AM
> >>To: dmitry@broadcom.com
> >>Cc: netdev@vger.kernel.org; difrost.kernel@gmail.com
> >>Subject: Re: [PATCH] sctp compilation failed due to lack of sctp_local_addr_free
> >>
> >>
> >>This has been fixed for days.
> >
> > Fixed in net-2.6, yes, but not yet in net-next-2.6
>
> net-next-2.6 is not active and is just a dummy tree for Stephen
> Rothwell to pull into -next
>
> You should never be referencing or using net-next-2.6 during the
> merge window when new features changes are not being accepted.
> Only net-2.6 is active during this time.
>
Hmm, so how similar will be net-2.6 and net-next-2.6 when re-opened?
You apply a lot of fixes during this time...
And yes, i've hit the compilation error in net-next since i'm using it
as basis for future features submit
^ permalink raw reply
* Re: [stable] [PATCH] atm: expose ATM device index in sysfs
From: Greg KH @ 2011-05-26 19:06 UTC (permalink / raw)
To: Dan Williams; +Cc: netdev, Chas Williams, David Woodhouse, stable
In-Reply-To: <1306432057.3151.10.camel@dcbw.foobar.com>
On Thu, May 26, 2011 at 12:47:36PM -0500, Dan Williams wrote:
> It's current exposed only through /proc which besides requiring
> screen-scraping doesn't allow userspace to distinguish between two
> identical ATM adapters with different ATM indexes. The ATM device index
> is required when using PPPoATM on a system with multiple ATM adapters.
>
> Signed-off-by: Dan Williams <dcbw@redhat.com>
> ---
>
> PS: -> stable too since it's a minimal change with no backwards
> incompatibility and I'd like to rely on this attribute in NetworkManager
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read Documentation/stable_kernel_rules.txt
for how to do this properly.
</formletter>
^ permalink raw reply
* Re: [patch] net/core/filter.c: Fix build error
From: David Miller @ 2011-05-26 19:00 UTC (permalink / raw)
To: randy.dunlap; +Cc: joe, mingo, greearb, linux-kernel, linux-arch, arnd, netdev
In-Reply-To: <20110526115721.ee83aefc.randy.dunlap@oracle.com>
From: Randy Dunlap <randy.dunlap@oracle.com>
Date: Thu, 26 May 2011 11:57:21 -0700
> On Thu, 26 May 2011 14:38:43 -0400 (EDT) David Miller wrote:
>
>> From: Joe Perches <joe@perches.com>
>> Date: Thu, 26 May 2011 08:31:06 -0700
>>
>> > My suggestion would be to see about again adding
>> > #include <linux/ratelimit.h> somehow
>> > back to kernel.h which commit 3fff4c42bd0a removed
>> > in 2009 because of the spinlock issues.
>> >
>> > Any suggestion on how best to fix it generically?
>>
>> I don't think we want spinlock_t's definition being sucked
>> into kernel.h's dependency food chain.
>>
>> Even if desirable, I think it'd be quite a bit of surgery,
>> too much to do at this stage.
>>
>> So for now how about we make the ratelimit warn interfaces be a true,
>> instead of a pseudo, dependency on ratelimit.h by moving those
>> definitions into ratelimit.h?
>
> Works for me. Thanks.
>
> Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
Thanks for reviewing Randy, I've put this into net-2.6 and will
push it out to Linus soon.
^ permalink raw reply
* Re: [PATCH net-next-2.6] bonding: cleanup module option descriptions
From: David Miller @ 2011-05-26 18:57 UTC (permalink / raw)
To: andy; +Cc: netdev, panweiping3
In-Reply-To: <1306334519-20243-1-git-send-email-andy@greyhouse.net>
From: Andy Gospodarek <andy@greyhouse.net>
Date: Wed, 25 May 2011 10:41:59 -0400
> Weiping Pan noticed that the module option description for
> xmit_hash_policy was incorrect and was nice enough to post a patch to
> fix it. The text was correct, but created a line over 80 characters and
> I would rather not add those. I realized I could take a few minutes and
> clean up all the descriptions and things would look much better. This
> is the result.
>
> Based on patch from Weiping Pan <panweiping3@gmail.com>.
>
> Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
> CC: Weiping Pan <panweiping3@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [patch] net/core/filter.c: Fix build error
From: Randy Dunlap @ 2011-05-26 18:57 UTC (permalink / raw)
To: David Miller; +Cc: joe, mingo, greearb, linux-kernel, linux-arch, arnd, netdev
In-Reply-To: <20110526.143843.205897228685761536.davem@davemloft.net>
On Thu, 26 May 2011 14:38:43 -0400 (EDT) David Miller wrote:
> From: Joe Perches <joe@perches.com>
> Date: Thu, 26 May 2011 08:31:06 -0700
>
> > My suggestion would be to see about again adding
> > #include <linux/ratelimit.h> somehow
> > back to kernel.h which commit 3fff4c42bd0a removed
> > in 2009 because of the spinlock issues.
> >
> > Any suggestion on how best to fix it generically?
>
> I don't think we want spinlock_t's definition being sucked
> into kernel.h's dependency food chain.
>
> Even if desirable, I think it'd be quite a bit of surgery,
> too much to do at this stage.
>
> So for now how about we make the ratelimit warn interfaces be a true,
> instead of a pseudo, dependency on ratelimit.h by moving those
> definitions into ratelimit.h?
Works for me. Thanks.
Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
> diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
> index 9178484..dfb0ec6 100644
> --- a/include/asm-generic/bug.h
> +++ b/include/asm-generic/bug.h
> @@ -162,46 +162,6 @@ extern void warn_slowpath_null(const char *file, const int line);
> unlikely(__ret_warn_once); \
> })
>
> -#ifdef CONFIG_PRINTK
> -
> -#define WARN_ON_RATELIMIT(condition, state) \
> - WARN_ON((condition) && __ratelimit(state))
> -
> -#define __WARN_RATELIMIT(condition, state, format...) \
> -({ \
> - int rtn = 0; \
> - if (unlikely(__ratelimit(state))) \
> - rtn = WARN(condition, format); \
> - rtn; \
> -})
> -
> -#define WARN_RATELIMIT(condition, format...) \
> -({ \
> - static DEFINE_RATELIMIT_STATE(_rs, \
> - DEFAULT_RATELIMIT_INTERVAL, \
> - DEFAULT_RATELIMIT_BURST); \
> - __WARN_RATELIMIT(condition, &_rs, format); \
> -})
> -
> -#else
> -
> -#define WARN_ON_RATELIMIT(condition, state) \
> - WARN_ON(condition)
> -
> -#define __WARN_RATELIMIT(condition, state, format...) \
> -({ \
> - int rtn = WARN(condition, format); \
> - rtn; \
> -})
> -
> -#define WARN_RATELIMIT(condition, format...) \
> -({ \
> - int rtn = WARN(condition, format); \
> - rtn; \
> -})
> -
> -#endif
> -
> /*
> * WARN_ON_SMP() is for cases that the warning is either
> * meaningless for !SMP or may even cause failures.
> diff --git a/include/linux/ratelimit.h b/include/linux/ratelimit.h
> index 03ff67b..2f00715 100644
> --- a/include/linux/ratelimit.h
> +++ b/include/linux/ratelimit.h
> @@ -41,4 +41,44 @@ extern struct ratelimit_state printk_ratelimit_state;
> extern int ___ratelimit(struct ratelimit_state *rs, const char *func);
> #define __ratelimit(state) ___ratelimit(state, __func__)
>
> +#ifdef CONFIG_PRINTK
> +
> +#define WARN_ON_RATELIMIT(condition, state) \
> + WARN_ON((condition) && __ratelimit(state))
> +
> +#define __WARN_RATELIMIT(condition, state, format...) \
> +({ \
> + int rtn = 0; \
> + if (unlikely(__ratelimit(state))) \
> + rtn = WARN(condition, format); \
> + rtn; \
> +})
> +
> +#define WARN_RATELIMIT(condition, format...) \
> +({ \
> + static DEFINE_RATELIMIT_STATE(_rs, \
> + DEFAULT_RATELIMIT_INTERVAL, \
> + DEFAULT_RATELIMIT_BURST); \
> + __WARN_RATELIMIT(condition, &_rs, format); \
> +})
> +
> +#else
> +
> +#define WARN_ON_RATELIMIT(condition, state) \
> + WARN_ON(condition)
> +
> +#define __WARN_RATELIMIT(condition, state, format...) \
> +({ \
> + int rtn = WARN(condition, format); \
> + rtn; \
> +})
> +
> +#define WARN_RATELIMIT(condition, format...) \
> +({ \
> + int rtn = WARN(condition, format); \
> + rtn; \
> +})
> +
> +#endif
> +
> #endif /* _LINUX_RATELIMIT_H */
> diff --git a/net/core/filter.c b/net/core/filter.c
> index 0e3622f..36f975f 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -38,6 +38,7 @@
> #include <asm/unaligned.h>
> #include <linux/filter.h>
> #include <linux/reciprocal_div.h>
> +#include <linux/ratelimit.h>
>
> /* No hurry in this branch */
> static void *__load_pointer(const struct sk_buff *skb, int k, unsigned int size)
> --
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH v3]net:8021q:vlan.c Fix pr_info to just give the vlan fullname and version.
From: David Miller @ 2011-05-26 18:56 UTC (permalink / raw)
To: justinmattock; +Cc: netdev, linux-kernel, joe, greearb
In-Reply-To: <1306219428-11528-1-git-send-email-justinmattock@gmail.com>
From: "Justin P. Mattock" <justinmattock@gmail.com>
Date: Mon, 23 May 2011 23:43:48 -0700
> The below patch removes vlan_buggyright and vlan_copyright from vlan_proto_init,
> so that it prints out just the fullname of vlan and the version number.
>
> before:
>
> [ 30.438203] 802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
> [ 30.441542] All bugs added by David S. Miller <davem@redhat.com>
>
> after:
>
> [ 31.513910] 802.1Q VLAN Support v1.8
>
> Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
Applied, thanks Justin.
^ permalink raw reply
* Re: [PATCH] sctp compilation failed due to lack of sctp_local_addr_free
From: David Miller @ 2011-05-26 18:44 UTC (permalink / raw)
To: bruce.w.allan; +Cc: dmitry, netdev, difrost.kernel
In-Reply-To: <837A992BD1360242AE0C50C6BCB069C18415C8@orsmsx003.amr.corp.intel.com>
From: "Allan, Bruce W" <bruce.w.allan@intel.com>
Date: Thu, 26 May 2011 11:40:34 -0700
>>-----Original Message-----
>>From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
>>Behalf Of David Miller
>>Sent: Thursday, May 26, 2011 10:39 AM
>>To: dmitry@broadcom.com
>>Cc: netdev@vger.kernel.org; difrost.kernel@gmail.com
>>Subject: Re: [PATCH] sctp compilation failed due to lack of sctp_local_addr_free
>>
>>
>>This has been fixed for days.
>
> Fixed in net-2.6, yes, but not yet in net-next-2.6
net-next-2.6 is not active and is just a dummy tree for Stephen
Rothwell to pull into -next
You should never be referencing or using net-next-2.6 during the
merge window when new features changes are not being accepted.
Only net-2.6 is active during this time.
^ permalink raw reply
* RE: [PATCH] sctp compilation failed due to lack of sctp_local_addr_free
From: Allan, Bruce W @ 2011-05-26 18:40 UTC (permalink / raw)
To: David Miller, dmitry@broadcom.com
Cc: netdev@vger.kernel.org, difrost.kernel@gmail.com
In-Reply-To: <20110526.133929.1471692552076759601.davem@davemloft.net>
>-----Original Message-----
>From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
>Behalf Of David Miller
>Sent: Thursday, May 26, 2011 10:39 AM
>To: dmitry@broadcom.com
>Cc: netdev@vger.kernel.org; difrost.kernel@gmail.com
>Subject: Re: [PATCH] sctp compilation failed due to lack of sctp_local_addr_free
>
>
>This has been fixed for days.
Fixed in net-2.6, yes, but not yet in net-next-2.6
^ permalink raw reply
* Re: [patch] net/core/filter.c: Fix build error
From: David Miller @ 2011-05-26 18:38 UTC (permalink / raw)
To: joe; +Cc: mingo, greearb, linux-kernel, linux-arch, arnd, netdev
In-Reply-To: <1306423866.16087.10.camel@Joe-Laptop>
From: Joe Perches <joe@perches.com>
Date: Thu, 26 May 2011 08:31:06 -0700
> My suggestion would be to see about again adding
> #include <linux/ratelimit.h> somehow
> back to kernel.h which commit 3fff4c42bd0a removed
> in 2009 because of the spinlock issues.
>
> Any suggestion on how best to fix it generically?
I don't think we want spinlock_t's definition being sucked
into kernel.h's dependency food chain.
Even if desirable, I think it'd be quite a bit of surgery,
too much to do at this stage.
So for now how about we make the ratelimit warn interfaces be a true,
instead of a pseudo, dependency on ratelimit.h by moving those
definitions into ratelimit.h?
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 9178484..dfb0ec6 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -162,46 +162,6 @@ extern void warn_slowpath_null(const char *file, const int line);
unlikely(__ret_warn_once); \
})
-#ifdef CONFIG_PRINTK
-
-#define WARN_ON_RATELIMIT(condition, state) \
- WARN_ON((condition) && __ratelimit(state))
-
-#define __WARN_RATELIMIT(condition, state, format...) \
-({ \
- int rtn = 0; \
- if (unlikely(__ratelimit(state))) \
- rtn = WARN(condition, format); \
- rtn; \
-})
-
-#define WARN_RATELIMIT(condition, format...) \
-({ \
- static DEFINE_RATELIMIT_STATE(_rs, \
- DEFAULT_RATELIMIT_INTERVAL, \
- DEFAULT_RATELIMIT_BURST); \
- __WARN_RATELIMIT(condition, &_rs, format); \
-})
-
-#else
-
-#define WARN_ON_RATELIMIT(condition, state) \
- WARN_ON(condition)
-
-#define __WARN_RATELIMIT(condition, state, format...) \
-({ \
- int rtn = WARN(condition, format); \
- rtn; \
-})
-
-#define WARN_RATELIMIT(condition, format...) \
-({ \
- int rtn = WARN(condition, format); \
- rtn; \
-})
-
-#endif
-
/*
* WARN_ON_SMP() is for cases that the warning is either
* meaningless for !SMP or may even cause failures.
diff --git a/include/linux/ratelimit.h b/include/linux/ratelimit.h
index 03ff67b..2f00715 100644
--- a/include/linux/ratelimit.h
+++ b/include/linux/ratelimit.h
@@ -41,4 +41,44 @@ extern struct ratelimit_state printk_ratelimit_state;
extern int ___ratelimit(struct ratelimit_state *rs, const char *func);
#define __ratelimit(state) ___ratelimit(state, __func__)
+#ifdef CONFIG_PRINTK
+
+#define WARN_ON_RATELIMIT(condition, state) \
+ WARN_ON((condition) && __ratelimit(state))
+
+#define __WARN_RATELIMIT(condition, state, format...) \
+({ \
+ int rtn = 0; \
+ if (unlikely(__ratelimit(state))) \
+ rtn = WARN(condition, format); \
+ rtn; \
+})
+
+#define WARN_RATELIMIT(condition, format...) \
+({ \
+ static DEFINE_RATELIMIT_STATE(_rs, \
+ DEFAULT_RATELIMIT_INTERVAL, \
+ DEFAULT_RATELIMIT_BURST); \
+ __WARN_RATELIMIT(condition, &_rs, format); \
+})
+
+#else
+
+#define WARN_ON_RATELIMIT(condition, state) \
+ WARN_ON(condition)
+
+#define __WARN_RATELIMIT(condition, state, format...) \
+({ \
+ int rtn = WARN(condition, format); \
+ rtn; \
+})
+
+#define WARN_RATELIMIT(condition, format...) \
+({ \
+ int rtn = WARN(condition, format); \
+ rtn; \
+})
+
+#endif
+
#endif /* _LINUX_RATELIMIT_H */
diff --git a/net/core/filter.c b/net/core/filter.c
index 0e3622f..36f975f 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -38,6 +38,7 @@
#include <asm/unaligned.h>
#include <linux/filter.h>
#include <linux/reciprocal_div.h>
+#include <linux/ratelimit.h>
/* No hurry in this branch */
static void *__load_pointer(const struct sk_buff *skb, int k, unsigned int size)
^ permalink raw reply related
* Re: [PATCH] atm: expose ATM device index in sysfs
From: Dan Williams @ 2011-05-26 18:35 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Chas Williams, David Woodhouse, stable
In-Reply-To: <1306432509.2543.1.camel@edumazet-laptop>
On Thu, 2011-05-26 at 19:55 +0200, Eric Dumazet wrote:
> Le jeudi 26 mai 2011 à 12:47 -0500, Dan Williams a écrit :
> > It's current exposed only through /proc which besides requiring
> > screen-scraping doesn't allow userspace to distinguish between two
> > identical ATM adapters with different ATM indexes. The ATM device index
> > is required when using PPPoATM on a system with multiple ATM adapters.
> >
> > Signed-off-by: Dan Williams <dcbw@redhat.com>
> > ---
> >
> > PS: -> stable too since it's a minimal change with no backwards
> > incompatibility and I'd like to rely on this attribute in NetworkManager
> >
> > diff --git a/net/atm/atm_sysfs.c b/net/atm/atm_sysfs.c
> > index f7fa67c..e5edbde 100644
> > --- a/net/atm/atm_sysfs.c
> > +++ b/net/atm/atm_sysfs.c
> > @@ -59,6 +59,16 @@ static ssize_t show_atmaddress(struct device *cdev,
> > return pos - buf;
> > }
> >
> > +static ssize_t show_atmindex(struct device *cdev,
> > + struct device_attribute *attr, char *buf)
> > +{
> > + char *pos = buf;
> > + struct atm_dev *adev = to_atm_dev(cdev);
> > +
> > + pos += sprintf(pos, "%d\n", adev->number);
> > + return pos - buf;
> > +}
> > +
>
> What about :
>
> {
> struct atm_dev *adev = to_atm_dev(cdev);
>
> return sprintf(buf, "%d\n", adev->number);
> }
Sure, will send v2.
Dan
^ permalink raw reply
* Re: [PATCH] net: davinci_emac: fix dev_err use at probe
From: David Miller @ 2011-05-26 18:31 UTC (permalink / raw)
To: jhovold; +Cc: cyril, srk, netdev
In-Reply-To: <1306420652-30001-1-git-send-email-jhovold@gmail.com>
From: Johan Hovold <jhovold@gmail.com>
Date: Thu, 26 May 2011 16:37:32 +0200
> Use platform device rather than net device in dev_err calls before net
> device has been registered to avoid messages such as
>
> (null): DaVinci EMAC: Failed to get EMAC clock
>
> Also replace remaining printks in probe with dev_{err,warn}.
>
> Signed-off-by: Johan Hovold <jhovold@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [ANNOUNCE]: Release of iptables-1.4.11
From: Eric Dumazet @ 2011-05-26 18:28 UTC (permalink / raw)
To: Patrick McHardy
Cc: Netfilter Development Mailinglist, NetDev, netfilter-announce,
'netfilter@vger.kernel.org'
In-Reply-To: <4DDE857E.40807@trash.net>
Le jeudi 26 mai 2011 à 18:53 +0200, Patrick McHardy a écrit :
> The netfilter coreteam presents:
>
> iptables version 1.4.10
>
> the iptables release for the 2.6.39 kernels. Due to some mistakes
> on my side we didn't have a release for longer than expected, so
> this contains a rather large number of changes.
>
> Changes include:
>
...
> - a new iptables option "-C" to check for existance of a rules
Nice, but this still loads modules...
# lsmod | grep ipta
# ./iptables -C INPUT -p tcp
iptables: Bad rule (does a matching rule exist in that chain?).
# lsmod | grep ipta
iptable_filter 1730 0
ip_tables 15958 1 iptable_filter
x_tables 22998 3 iptable_filter,ip_tables,xt_tcpudp
^ permalink raw reply
* Re: can: convert to %pK for kptr_restrict support
From: David Miller @ 2011-05-26 18:24 UTC (permalink / raw)
To: socketcan; +Cc: netdev, drosenberg
In-Reply-To: <4DDE6A71.3080406@hartkopp.net>
From: Oliver Hartkopp <socketcan@hartkopp.net>
Date: Thu, 26 May 2011 16:57:53 +0200
> As these pointers have been printed without using %p they were missed in the
> big network kptr_restrict conversion patch %p -> %pK from Dan Rosenberg.
>
> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Applied.
^ permalink raw reply
* Re: [PATCH] af-packet: Use existing netdev reference for bound sockets.
From: David Miller @ 2011-05-26 18:22 UTC (permalink / raw)
To: greearb; +Cc: netdev
In-Reply-To: <1306365332-12105-1-git-send-email-greearb@candelatech.com>
From: greearb@candelatech.com
Date: Wed, 25 May 2011 16:15:32 -0700
> @@ -1161,6 +1168,7 @@ static int packet_snd(struct socket *sock,
>
> if (saddr == NULL) {
> ifindex = po->ifindex;
> + dev = po->prot_hook.dev;
> proto = po->num;
> addr = NULL;
> } else {
> @@ -1174,8 +1182,11 @@ static int packet_snd(struct socket *sock,
> addr = saddr->sll_addr;
> }
>
> + if (!dev) {
> + dev = dev_get_by_index(sock_net(sk), ifindex);
> + need_rls_dev = true;
> + }
>
Why don't you move this second hunk into the "saddr != NULL" code
block?
That way all you can:
1) Call dev_get_by_index() unconditionally from that spot.
2) Only have the dev==NULL check right afterwards inside of the
unbound case as well.
^ permalink raw reply
* Re: [RESEND PATCH net] net: fix ETHTOOL_SFEATURES compatibility with old ethtool_ops.set_flags
From: David Miller @ 2011-05-26 18:14 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev, bhutchings
In-Reply-To: <7bcc407f555d2fbbcd66d26e4b0195060cf8c063.1306405895.git.mirq-linux@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Thu, 26 May 2011 12:42:57 +0200 (CEST)
> Current code squashes flags to bool - this makes set_flags fail whenever
> some ETH_FLAG_* equivalent features are set. Fix this.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Applied.
^ permalink raw reply
* Re: [PATCH v3 resend] netfilter: nf_conntrack_sip: Handle Cisco 7941/7945 IP phones
From: Pablo Neira Ayuso @ 2011-05-26 18:08 UTC (permalink / raw)
To: Eric Dumazet
Cc: Kevin Cernekee, Patrick McHardy, David S. Miller, netfilter-devel,
netfilter, coreteam, linux-kernel, netdev
In-Reply-To: <1306432664.2543.2.camel@edumazet-laptop>
On 26/05/11 19:57, Eric Dumazet wrote:
> Le jeudi 26 mai 2011 à 18:50 +0200, Pablo Neira Ayuso a écrit :
>> Hi Eric,
>>
>> On 20/05/11 06:36, Kevin Cernekee wrote:
>>> Most SIP devices use a source port of 5060/udp on SIP requests, so the
>>> response automatically comes back to port 5060:
>>>
>>> phone_ip:5060 -> proxy_ip:5060 REGISTER
>>> proxy_ip:5060 -> phone_ip:5060 100 Trying
>>>
>>> The newer Cisco IP phones, however, use a randomly chosen high source
>>> port for the SIP request but expect the response on port 5060:
>>>
>>> phone_ip:49173 -> proxy_ip:5060 REGISTER
>>> proxy_ip:5060 -> phone_ip:5060 100 Trying
>>>
>>> Standard Linux NAT, with or without nf_nat_sip, will send the reply back
>>> to port 49173, not 5060:
>>>
>>> phone_ip:49173 -> proxy_ip:5060 REGISTER
>>> proxy_ip:5060 -> phone_ip:49173 100 Trying
>>>
>>> But the phone is not listening on 49173, so it will never see the reply.
>>>
>>> This patch modifies nf_*_sip to work around this quirk by extracting
>>> the SIP response port from the Via: header, iff the source IP in the
>>> packet header matches the source IP in the SIP request.
>>>
>>> Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
>>> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
>>> Cc: Patrick McHardy <kaber@trash.net>
>>
>> @Eric: could you please confirm that you ack'ed this patch? I don't find
>> the email with your explicit ack.
>
> Yes I did it ;)
>
> http://www.spinics.net/lists/netfilter/msg49632.html
>
> Thanks !
OK, applied, thanks!
--
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
* Re: [PATCH v3 resend] netfilter: nf_conntrack_sip: Handle Cisco 7941/7945 IP phones
From: Eric Dumazet @ 2011-05-26 17:57 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Kevin Cernekee, Patrick McHardy, David S. Miller, netfilter-devel,
netfilter, coreteam, linux-kernel, netdev
In-Reply-To: <4DDE84F2.7080706@netfilter.org>
Le jeudi 26 mai 2011 à 18:50 +0200, Pablo Neira Ayuso a écrit :
> Hi Eric,
>
> On 20/05/11 06:36, Kevin Cernekee wrote:
> > Most SIP devices use a source port of 5060/udp on SIP requests, so the
> > response automatically comes back to port 5060:
> >
> > phone_ip:5060 -> proxy_ip:5060 REGISTER
> > proxy_ip:5060 -> phone_ip:5060 100 Trying
> >
> > The newer Cisco IP phones, however, use a randomly chosen high source
> > port for the SIP request but expect the response on port 5060:
> >
> > phone_ip:49173 -> proxy_ip:5060 REGISTER
> > proxy_ip:5060 -> phone_ip:5060 100 Trying
> >
> > Standard Linux NAT, with or without nf_nat_sip, will send the reply back
> > to port 49173, not 5060:
> >
> > phone_ip:49173 -> proxy_ip:5060 REGISTER
> > proxy_ip:5060 -> phone_ip:49173 100 Trying
> >
> > But the phone is not listening on 49173, so it will never see the reply.
> >
> > This patch modifies nf_*_sip to work around this quirk by extracting
> > the SIP response port from the Via: header, iff the source IP in the
> > packet header matches the source IP in the SIP request.
> >
> > Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
> > Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
> > Cc: Patrick McHardy <kaber@trash.net>
>
> @Eric: could you please confirm that you ack'ed this patch? I don't find
> the email with your explicit ack.
Yes I did it ;)
http://www.spinics.net/lists/netfilter/msg49632.html
Thanks !
--
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
* Re: [PATCH 2/6] unicore32: add pkunity-v3 mac/net driver (umal)
From: Ben Hutchings @ 2011-05-26 17:56 UTC (permalink / raw)
To: GuanXuetao; +Cc: arnd, linux-kernel, linux-arch, greg, netdev
In-Reply-To: <556924396ee34f4af94a2f03767973f1cec35e22.1306408804.git.gxt@mprc.pku.edu.cn>
On Thu, 2011-05-26 at 11:36 +0000, GuanXuetao wrote:
[...]
> --- /dev/null
> +++ b/drivers/net/mac-puv3.c
[...]
> +/**********************************************************************
> + * Simple types
> + ********************************************************************* */
> +enum umal_speed {
> + umal_speed_none = 0,
> + umal_speed_10 = SPEED_10,
> + umal_speed_100 = SPEED_100,
> + umal_speed_1000 = SPEED_1000,
> +};
Just use the numbers directly: 0, 10, 100, 1000.
[...]
> +#define ETHER_ADDR_LEN 6
This is already called ETH_ALEN.
[...]
> +/**********************************************************************
> + * DMA Descriptor structure
> + ********************************************************************* */
> +struct umaldmadscr {
> + dma_addr_t PacketStartAddr;
> + int PacketSize;
> + dma_addr_t NextDescriptor;
> + struct umaldmadscr *NextDescriptor_Virt;
> +};
Linux naming convention for structure fields is words_with_underscores
not TitleCase.
[...]
> +/**********************************************************************
> + * UMAL_MII_RESET(bus)
> + *
> + * Reset MII bus.
> + *
> + * Input parameters:
> + * bus - MDIO bus handle
> + *
> + * Return value:
> + * 0 if ok
> + ********************************************************************* */
Function documentation comments must follow the kernel-doc format.
[...]
> +static int umaldma_add_rcvbuffer(struct umal_softc *sc, struct umaldma *d,
> + struct sk_buff *sb)
> +{
[...]
> + /*
> + * Allocate a sk_buff if we don't already have one.
> + * If we do have an sk_buff, reset it so that it's empty.
> + *
> + * Note: sk_buffs don't seem to be guaranteed to have any sort
> + * of alignment when they are allocated. Therefore, allocate enough
> + * extra space to make sure that:
> + *
> + * 1. the data does not start in the middle of a cache line.
> + * 2. The data does not end in the middle of a cache line
> + * 3. The buffer can be aligned such that the IP addresses are
> + * naturally aligned.
> + *
> + * Remember, the SOCs MAC writes whole cache lines at a time,
> + * without reading the old contents first. So, if the sk_buff's
> + * data portion starts in the middle of a cache line, the SOC
> + * DMA will trash the beginning (and ending) portions.
> + */
> + if (sb == NULL) {
> + sb_new = netdev_alloc_skb(dev, ENET_PACKET_SIZE +
> + SMP_CACHE_BYTES * 2 + NET_IP_ALIGN);
> + if (sb_new == NULL) {
> + pr_info("%s: sk_buff allocation failed\n",
> + d->umaldma_eth->umal_dev->name);
> + return -ENOBUFS;
Surely -ENOMEM.
> + }
> + skb_reserve(sb_new, 2);
This presumably needs to be:
skb_reserve(sb_new, SMP_CACHE_BYTES + NET_IP_ALIGN);
unless you assume that the skb allocator will always ensure cache line
alignment (in which case, why use padding of SMP_CACHE_BYTES * 2?).
[...]
> +static void umaldma_tx_process(struct umal_softc *sc, struct umaldma *d,
> + int poll)
> +{
> + struct net_device *dev = sc->umal_dev;
> + int curidx;
> + int hwidx;
> + struct umaldmadscr *dsc;
> + struct sk_buff *sb;
> + unsigned long flags;
> + int packets_handled = 0;
> + unsigned int int_status;
> +
> + spin_lock_irqsave(&(sc->umal_lock), flags);
> +
> + if (!netif_device_present(dev))
> + return;
[...]
This returns with the lock held!
(This is not by any means a thorough review.)
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] atm: expose ATM device index in sysfs
From: Eric Dumazet @ 2011-05-26 17:55 UTC (permalink / raw)
To: Dan Williams; +Cc: netdev, Chas Williams, David Woodhouse, stable
In-Reply-To: <1306432057.3151.10.camel@dcbw.foobar.com>
Le jeudi 26 mai 2011 à 12:47 -0500, Dan Williams a écrit :
> It's current exposed only through /proc which besides requiring
> screen-scraping doesn't allow userspace to distinguish between two
> identical ATM adapters with different ATM indexes. The ATM device index
> is required when using PPPoATM on a system with multiple ATM adapters.
>
> Signed-off-by: Dan Williams <dcbw@redhat.com>
> ---
>
> PS: -> stable too since it's a minimal change with no backwards
> incompatibility and I'd like to rely on this attribute in NetworkManager
>
> diff --git a/net/atm/atm_sysfs.c b/net/atm/atm_sysfs.c
> index f7fa67c..e5edbde 100644
> --- a/net/atm/atm_sysfs.c
> +++ b/net/atm/atm_sysfs.c
> @@ -59,6 +59,16 @@ static ssize_t show_atmaddress(struct device *cdev,
> return pos - buf;
> }
>
> +static ssize_t show_atmindex(struct device *cdev,
> + struct device_attribute *attr, char *buf)
> +{
> + char *pos = buf;
> + struct atm_dev *adev = to_atm_dev(cdev);
> +
> + pos += sprintf(pos, "%d\n", adev->number);
> + return pos - buf;
> +}
> +
What about :
{
struct atm_dev *adev = to_atm_dev(cdev);
return sprintf(buf, "%d\n", adev->number);
}
^ permalink raw reply
* [PATCH] atm: expose ATM device index in sysfs
From: Dan Williams @ 2011-05-26 17:47 UTC (permalink / raw)
To: netdev; +Cc: Chas Williams, David Woodhouse, stable
It's current exposed only through /proc which besides requiring
screen-scraping doesn't allow userspace to distinguish between two
identical ATM adapters with different ATM indexes. The ATM device index
is required when using PPPoATM on a system with multiple ATM adapters.
Signed-off-by: Dan Williams <dcbw@redhat.com>
---
PS: -> stable too since it's a minimal change with no backwards
incompatibility and I'd like to rely on this attribute in NetworkManager
diff --git a/net/atm/atm_sysfs.c b/net/atm/atm_sysfs.c
index f7fa67c..e5edbde 100644
--- a/net/atm/atm_sysfs.c
+++ b/net/atm/atm_sysfs.c
@@ -59,6 +59,16 @@ static ssize_t show_atmaddress(struct device *cdev,
return pos - buf;
}
+static ssize_t show_atmindex(struct device *cdev,
+ struct device_attribute *attr, char *buf)
+{
+ char *pos = buf;
+ struct atm_dev *adev = to_atm_dev(cdev);
+
+ pos += sprintf(pos, "%d\n", adev->number);
+ return pos - buf;
+}
+
static ssize_t show_carrier(struct device *cdev,
struct device_attribute *attr, char *buf)
{
@@ -99,6 +109,7 @@ static ssize_t show_link_rate(struct device *cdev,
static DEVICE_ATTR(address, S_IRUGO, show_address, NULL);
static DEVICE_ATTR(atmaddress, S_IRUGO, show_atmaddress, NULL);
+static DEVICE_ATTR(atmindex, S_IRUGO, show_atmindex, NULL);
static DEVICE_ATTR(carrier, S_IRUGO, show_carrier, NULL);
static DEVICE_ATTR(type, S_IRUGO, show_type, NULL);
static DEVICE_ATTR(link_rate, S_IRUGO, show_link_rate, NULL);
@@ -106,6 +117,7 @@ static DEVICE_ATTR(link_rate, S_IRUGO, show_link_rate, NULL);
static struct device_attribute *atm_attrs[] = {
&dev_attr_atmaddress,
&dev_attr_address,
+ &dev_attr_atmindex,
&dev_attr_carrier,
&dev_attr_type,
&dev_attr_link_rate,
^ permalink raw reply related
* Re: [PATCH] sctp compilation failed due to lack of sctp_local_addr_free
From: David Miller @ 2011-05-26 17:39 UTC (permalink / raw)
To: dmitry; +Cc: netdev, difrost.kernel
In-Reply-To: <1306427323.7510.2.camel@lb-tlvb-dmitry>
This has been fixed for days.
^ 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