* RE: [PATCH] Export ACPI _DSM provided firmware instance number and string name to sysfs
From: Narendra_K @ 2011-01-10 18:48 UTC (permalink / raw)
To: jbarnes
Cc: Matt_Domsch, linux-pci, linux-hotplug, netdev, Jordan_Hargrave,
Charles_Rose, Vijay_Nijhawan
In-Reply-To: <20110107142750.21ea39f0@jbarnes-desktop>
> -----Original Message-----
> From: Jesse Barnes [mailto:jbarnes@virtuousgeek.org]
> Sent: Saturday, January 08, 2011 3:58 AM
> To: K, Narendra
> Cc: Domsch, Matt; linux-pci@vger.kernel.org; linux-
> hotplug@vger.kernel.org; netdev@vger.kernel.org; Hargrave, Jordan;
> Rose, Charles; Nijhawan, Vijay
> Subject: Re: [PATCH] Export ACPI _DSM provided firmware instance number
> and string name to sysfs
>
> On Thu, 23 Dec 2010 11:24:36 -0800
> <Narendra_K@Dell.com> wrote:
>
> > On Thu, Dec 23, 2010 at 08:02:03PM +0530, Domsch, Matt wrote:
> > > On Wed, Dec 22, 2010 at 08:42:39AM -0800, Narendra_K@Dell.com
> wrote:
> > > > Hello,
> > > >
> > > > This patch exports ACPI _DSM provided firmware instance number
> and
> > > > string name to sysfs.
> > > >
> > > > Please review -
> > >
> > > There are now two different meanings for the 'index' file:
> > >
> > > 1) SMBIOS-provided "type instance" value, which I've only seen in
> > > range [1..N] for N devices, monotonically stepwise increasing.
> > >
> > > 2) ACPI-provided "index" value, which per spec only needs to be a
> > > "sort key", not starting at 0 or 1, and while monotonically
> > > increasing, not necessarily stepwise. It's perfectly valid for
> the
> > > values to be (12, 16, 27, 29) if that's convenient for BIOS to
> > > generate.
> > >
> > > Therefore, a consumer of this value (such as biosdevname) must know
> > > which of the two it's dealing with, and either accept the value as-
> is,
> > > or sort the value list. While I suppose it could sort the value
> list
> > > in either case, I'd prefer the ACPI value to be exposed in its own
> > > file, perhaps 'acpi_index', to make this explicit rather than
> > > implicit.
> > >
> > > 'label' is fine for either case, with ACPI taking priority over
> > > SMBIOS if both happen to be present.
> > >
>
> Applied, thanks.
Jesse,
Thank you.
With regards,
Narendra K
^ permalink raw reply
* Re: [RFC] sched: CHOKe packet scheduler (v0.2)
From: Eric Dumazet @ 2011-01-10 17:45 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20110110093123.5431b368@nehalam>
Le lundi 10 janvier 2011 à 09:31 -0800, Stephen Hemminger a écrit :
> On Mon, 10 Jan 2011 14:46:50 +0100
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> > Le jeudi 06 janvier 2011 à 20:55 -0800, Stephen Hemminger a écrit :
> >
> > >
> > > The problem is that large tables of pointers in kernel require either
> > > contiguous allocation or some indirect table algorithm.
> > >
> >
> > Here is a v3 version with an array based queue for O(1) peek_random
> > complexity.
> >
> > Could you send the iproute2 patch so that I can test it ?
> >
> > Thanks !
> >
> >
> > diff --git a/net/sched/sch_choke.c b/net/sched/sch_choke.c
> > index e69de29..ea9db00 100644
> > --- a/net/sched/sch_choke.c
> > +++ b/net/sched/sch_choke.c
> > @@ -0,0 +1,388 @@
> > +/*
> > + * net/sched/sch_choke.c CHOKE scheduler
> > + *
> > + * Copyright (c) 2011 Stephen Hemminger <shemminger@vyatta.com>
> > + * Copyright (c) 2011 Eric Dumazet <eric.dumazet@gmail.com>
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License
> > + * version 2 as published by the Free Software Foundation.
> > + *
> > + */
> > +
> > +#include <linux/module.h>
> > +#include <linux/types.h>
> > +#include <linux/kernel.h>
> > +#include <linux/skbuff.h>
> > +#include <linux/reciprocal_div.h>
> > +#include <net/pkt_sched.h>
> > +#include <net/inet_ecn.h>
> > +#include <net/red.h>
> > +
> > +/* CHOKe stateless AQM for fair bandwidth allocation
> > + =================================================
> > +
> > + CHOKe (CHOose and Keep for responsive flows, CHOose and Kill for
> > + unresponsive flows) is a variant of RED that penalizes misbehaving flows but
> > + maintains no flow state. The difference from RED is an additional step
> > + during the enqueuing process. If average queue size is over the
> > + low threshold (qmin), a packet is chosen at random from the queue.
> > + If both the new and chosen packet are from the same flow, both
> > + are dropped. Unlike RED, CHOKe is not a "classful" qdisc because it
> > + needs to access packets in queue randomly.
> > +
> > + Source:
> > + R. Pan, B. Prabhakar, and K. Psounis, "CHOKe, A Stateless
> > + Active Queue Management Scheme for Approximating Fair Bandwidth Allocation",
> > + IEEE INFOCOM, 2000.
> > +
> > + A. Tang, J. Wang, S. Low, "Understanding CHOKe: Throughput and Spatial
> > + Characteristics", IEEE/ACM Transactions on Networking, 2004
> > +
> > + */
> > +
> > +struct choke_sched_data {
> > + u32 limit;
> > + unsigned char flags;
> > +
> > + struct red_parms parms;
> > + struct red_stats stats;
> > +
> > + unsigned int head;
> > + unsigned int tail;
> > + unsigned int holes;
> > + unsigned int tab_mask; /* size - 1 */
> > + struct sk_buff **tab;
> > +};
> > +
> > +static inline unsigned int choke_len(const struct choke_sched_data *q)
> > +{
> > + return (q->tail - q->head) & q->tab_mask;
> > +}
> > +
> > +/* deliver a random number between 0 and N - 1 */
> > +static inline u32 random_N(unsigned int N)
> > +{
> > + return reciprocal_divide(random32(), N);
> > +}
> > +
> > +/* Select a packet at random from the queue in O(1) */
> > +static struct sk_buff *choke_peek_random(struct choke_sched_data *q, unsigned int *pidx)
> > +{
> > + *pidx = (q->head + random_N(choke_len(q))) & q->tab_mask;
> > + return q->tab[*pidx];
> > +}
>
> I don't think this works right. The choke_peek_random could find a hole.
> Either the data structure has to change, or the peek_random has to retry,
> or if quick peek fails then compress the slot with memmove and retry.
>
>
Yes, this "compress only if peek_random() finds a hole seems good, I'll
try this.
As number of holes is known, we could have :
if (holes_proportion_is_less_than_20_percent())
try another random number X times
else
compress table to remove holes.
^ permalink raw reply
* [PATCH v1] TCPCT sysctl API update to draft -02
From: William Allen Simpson @ 2011-01-10 17:48 UTC (permalink / raw)
To: Linux Kernel Network Developers
Cc: Eric W. Biederman, Stephen Hemminger, Andi Kleen
In-Reply-To: <4D28D8EF.5010008@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 636 bytes --]
Circa 15 months ago, my first submitted patch was a sysctl, and there was a
conflict that appeared in a later merge of trees. Experts, am I in the right
ballpark this time around?
Later, I'll submit the manpage patch to linux-man@vger.kernel.org too.
===
Use most recently specified symbols of RFC-to-be-6013.
Allows different global s_data limits for SYN and SYN_ACK.
Signed-off-by: William.Allen.Simpson@gmail.com
---
include/net/tcp.h | 2 ++
net/ipv4/sysctl_net_ipv4.c | 25 ++++++++++++++++++++++++-
net/ipv4/tcp_output.c | 19 +++++++++++++++++--
3 files changed, 43 insertions(+), 3 deletions(-)
[-- Attachment #2: TCPCT+API-02u1+2.6.37.patch --]
[-- Type: text/plain, Size: 3327 bytes --]
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 38509f0..3ac2bca 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -241,6 +241,8 @@ extern int sysctl_tcp_workaround_signed_windows;
extern int sysctl_tcp_slow_start_after_idle;
extern int sysctl_tcp_max_ssthresh;
extern int sysctl_tcp_cookie_size;
+extern int sysctl_tcp_syn_data_limit;
+extern int sysctl_tcp_syn_ack_data_limit;
extern int sysctl_tcp_thin_linear_timeouts;
extern int sysctl_tcp_thin_dupack;
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index 1a45665..629f90b 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -30,6 +30,9 @@ static int tcp_adv_win_scale_min = -31;
static int tcp_adv_win_scale_max = 31;
static int ip_ttl_min = 1;
static int ip_ttl_max = 255;
+static int tcp_cookie_max = TCP_COOKIE_MAX;
+static int tcp_syn_data_max = TCP_MSS_DEFAULT - 40;
+static int tcp_syn_ack_data_max = TCP_MSS_DESIRED;
/* Update system visible IP port range */
static void set_local_port_range(int range[2])
@@ -588,7 +591,27 @@ static struct ctl_table ipv4_table[] = {
.data = &sysctl_tcp_cookie_size,
.maxlen = sizeof(int),
.mode = 0644,
- .proc_handler = proc_dointvec
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = &zero,
+ .extra2 = &tcp_cookie_max,
+ },
+ {
+ .procname = "tcp_syn_data_limit",
+ .data = &sysctl_tcp_syn_data_limit,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = &zero,
+ .extra2 = &tcp_syn_data_max,
+ },
+ {
+ .procname = "tcp_syn_ack_data_limit",
+ .data = &sysctl_tcp_syn_ack_data_limit,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = &zero,
+ .extra2 = &tcp_syn_ack_data_max,
},
{
.procname = "tcp_thin_linear_timeouts",
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index dc7c096..3bd3da5 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -63,6 +63,15 @@ int sysctl_tcp_slow_start_after_idle __read_mostly = 1;
int sysctl_tcp_cookie_size __read_mostly = 0; /* TCP_COOKIE_MAX */
EXPORT_SYMBOL_GPL(sysctl_tcp_cookie_size);
+int sysctl_tcp_syn_data_limit __read_mostly = TCP_MSS_DEFAULT - 40;
+EXPORT_SYMBOL_GPL(sysctl_tcp_syn_data_limit);
+
+/* As a matter of security policy, keep the initial setting small for most
+ * client systems to avoid their use in amplification DoS attacks.
+ */
+int sysctl_tcp_syn_ack_data_limit __read_mostly = 80; /* TCP_MSS_DESIRED */
+EXPORT_SYMBOL_GPL(sysctl_tcp_syn_ack_data_limit);
+
/* Account for new data that has been sent to the network. */
static void tcp_event_new_data_sent(struct sock *sk, struct sk_buff *skb)
@@ -2418,10 +2427,16 @@ struct sk_buff *tcp_make_synack(struct sock *sk, struct dst_entry *dst,
struct tcp_md5sig_key *md5;
int tcp_header_size;
int mss;
- int s_data_desired = 0;
+ int s_data_desired;
- if (cvp != NULL && cvp->s_data_constant && cvp->s_data_desired)
+ if (cvp != NULL &&
+ cvp->s_data_constant &&
+ cvp->s_data_desired > 0 &&
+ cvp->s_data_desired <= sysctl_tcp_syn_ack_data_limit)
s_data_desired = cvp->s_data_desired;
+ else
+ s_data_desired = 0;
+
skb = sock_wmalloc(sk, MAX_TCP_HEADER + 15 + s_data_desired, 1, GFP_ATOMIC);
if (skb == NULL)
return NULL;
--
1.7.1
^ permalink raw reply related
* Re: [RFC] sched: CHOKe packet scheduler (v0.2)
From: Stephen Hemminger @ 2011-01-10 17:31 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1294667210.3491.7.camel@edumazet-laptop>
On Mon, 10 Jan 2011 14:46:50 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le jeudi 06 janvier 2011 à 20:55 -0800, Stephen Hemminger a écrit :
>
> >
> > The problem is that large tables of pointers in kernel require either
> > contiguous allocation or some indirect table algorithm.
> >
>
> Here is a v3 version with an array based queue for O(1) peek_random
> complexity.
>
> Could you send the iproute2 patch so that I can test it ?
>
> Thanks !
>
>
> diff --git a/net/sched/sch_choke.c b/net/sched/sch_choke.c
> index e69de29..ea9db00 100644
> --- a/net/sched/sch_choke.c
> +++ b/net/sched/sch_choke.c
> @@ -0,0 +1,388 @@
> +/*
> + * net/sched/sch_choke.c CHOKE scheduler
> + *
> + * Copyright (c) 2011 Stephen Hemminger <shemminger@vyatta.com>
> + * Copyright (c) 2011 Eric Dumazet <eric.dumazet@gmail.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + *
> + */
> +
> +#include <linux/module.h>
> +#include <linux/types.h>
> +#include <linux/kernel.h>
> +#include <linux/skbuff.h>
> +#include <linux/reciprocal_div.h>
> +#include <net/pkt_sched.h>
> +#include <net/inet_ecn.h>
> +#include <net/red.h>
> +
> +/* CHOKe stateless AQM for fair bandwidth allocation
> + =================================================
> +
> + CHOKe (CHOose and Keep for responsive flows, CHOose and Kill for
> + unresponsive flows) is a variant of RED that penalizes misbehaving flows but
> + maintains no flow state. The difference from RED is an additional step
> + during the enqueuing process. If average queue size is over the
> + low threshold (qmin), a packet is chosen at random from the queue.
> + If both the new and chosen packet are from the same flow, both
> + are dropped. Unlike RED, CHOKe is not a "classful" qdisc because it
> + needs to access packets in queue randomly.
> +
> + Source:
> + R. Pan, B. Prabhakar, and K. Psounis, "CHOKe, A Stateless
> + Active Queue Management Scheme for Approximating Fair Bandwidth Allocation",
> + IEEE INFOCOM, 2000.
> +
> + A. Tang, J. Wang, S. Low, "Understanding CHOKe: Throughput and Spatial
> + Characteristics", IEEE/ACM Transactions on Networking, 2004
> +
> + */
> +
> +struct choke_sched_data {
> + u32 limit;
> + unsigned char flags;
> +
> + struct red_parms parms;
> + struct red_stats stats;
> +
> + unsigned int head;
> + unsigned int tail;
> + unsigned int holes;
> + unsigned int tab_mask; /* size - 1 */
> + struct sk_buff **tab;
> +};
> +
> +static inline unsigned int choke_len(const struct choke_sched_data *q)
> +{
> + return (q->tail - q->head) & q->tab_mask;
> +}
> +
> +/* deliver a random number between 0 and N - 1 */
> +static inline u32 random_N(unsigned int N)
> +{
> + return reciprocal_divide(random32(), N);
> +}
> +
> +/* Select a packet at random from the queue in O(1) */
> +static struct sk_buff *choke_peek_random(struct choke_sched_data *q, unsigned int *pidx)
> +{
> + *pidx = (q->head + random_N(choke_len(q))) & q->tab_mask;
> + return q->tab[*pidx];
> +}
I don't think this works right. The choke_peek_random could find a hole.
Either the data structure has to change, or the peek_random has to retry,
or if quick peek fails then compress the slot with memmove and retry.
--
^ permalink raw reply
* Re: [PATCH] Move an assert under DEBUG_KERNEL. (attempt 2)
From: Randy Dunlap @ 2011-01-10 17:19 UTC (permalink / raw)
To: Rob Landley; +Cc: Andrew Morton, trivial, linux-kernel, linux-embedded, netdev
In-Reply-To: <4D2AC4D5.5070503@parallels.com>
On Mon, 10 Jan 2011 02:35:33 -0600 Rob Landley wrote:
> On 01/06/2011 05:41 PM, Andrew Morton wrote:
> > Probably a worthwhile thing to do, IMO. If there's some net-specific
> > CONFIG_DEBUG_ setting then that wold be a better thing to use.
> >
> > However the patch was a) wordwrapped, b) space-stuffed and c) not cc'ed
> > to the networking list. So its prospects are dim.
>
> Ok, either I've beaten thunderbird into submission, or I'll be submitting a patch to Documentation/email-clients.txt. (Whether or not I need to find a different smtp server to send this through remains an open question.)
>
> (Confirming: I looked for a more specific DEBUG symbol, but couldn't find one. I can add one, but this seems a bit small to have its own symbol, and DEBUG_KERNEL is already used in a few *.c files.)
>
> From: Rob Landley <rlandley@parallels.com>
>
> Move an assert under DEBUG_KERNEL. (Minor cleanup to save a few bytes.)
>
> Signed-off-by: Rob Landley <rlandley@parallels.com>
> ---
>
> include/linux/rtnetlink.h | 4 ++++
> 1 file changed, 4 insertions(+)
Hm, cc to linux-net should be to netdev instead (so I changed it).
> diff --git a/include/linux/rtnetlink.h b/include/linux/rtnetlink.h
> index bbad657..28c4025 100644
> --- a/include/linux/rtnetlink.h
> +++ b/include/linux/rtnetlink.h
> @@ -782,6 +782,7 @@ extern struct netdev_queue *dev_ingress_queue_create(struct net_device *dev);
> extern void rtnetlink_init(void);
> extern void __rtnl_unlock(void);
>
> +#ifdef CONFIG_DEBUG_KERNEL
> #define ASSERT_RTNL() do { \
> if (unlikely(!rtnl_is_locked())) { \
> printk(KERN_ERR "RTNL: assertion failed at %s (%d)\n", \
> @@ -789,6 +790,9 @@ extern void __rtnl_unlock(void);
> dump_stack(); \
> } \
> } while(0)
> +#else
> +#define ASSERT_RTNL()
> +#endif
Empty macros in Linux usually take the (preferred) form of this one from kernel.h:
#define might_resched() do { } while (0)
although it's up to DaveM in this case.
>
> static inline u32 rtm_get_table(struct rtattr **rta, u8 table)
> {
> --
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH] Cleanup include/net/tcp.h include-files and coding-style
From: Alexey Dobriyan @ 2011-01-10 17:02 UTC (permalink / raw)
To: Randy Dunlap; +Cc: christoph.paasch, Ben Hutchings, davem, netdev, linux-kernel
In-Reply-To: <20110110083024.ab3bad25.rdunlap@xenotime.net>
On Mon, Jan 10, 2011 at 6:30 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
> If you just want to fix source files that are missing header files, then
> the patches should be accepted, even if they are not "needed" in some
> strong sense of that word.
This will create a lot of noise. As if we haven't seen enough before.
^ permalink raw reply
* Re: [PATCH V8 02/13] ntp: add ADJ_SETOFFSET mode bit
From: john stultz @ 2011-01-10 16:49 UTC (permalink / raw)
To: Kuwahara,T.
Cc: Richard Cochran, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Alan Cox, Arnd Bergmann, Christoph Lameter, David Miller,
Krzysztof Halasa, Peter Zijlstra, Rodolfo Giometti,
Thomas Gleixner
In-Reply-To: <AANLkTikigXGSACF6R6kfNHyKZ7GFWrUrCMxygvL3fUC6-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, 2011-01-10 at 06:07 +0900, Kuwahara,T. wrote:
> On Sun, Jan 9, 2011 at 2:50 AM, Richard Cochran
> <richardcochran-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > we want to be able to jump the clock arbitrarily.
>
> Another problem remains: How do you deal with leap seconds? I mean,
> given that 1 minute is not always 60 seconds, then what time was it
> XXXXX seconds ago? Maybe some kind of lookup table is necessary, but
> in such case, isn't it a better choice just to use the
> clock_settime/settimeofday syscall?
Leapsecond processing is done via an absolute hrtimer. Thus when the
time offset is set, the hrtimers that should have expired will fire
(just like with settimeofday) and the adjustment will then be made.
thanks
-john
^ permalink raw reply
* Re: [PATCH 0/3] iproute2: ip link: add support for network device groups
From: Stephen Hemminger @ 2011-01-10 16:47 UTC (permalink / raw)
To: Vlad Dogaru; +Cc: netdev, jamal, Octavian Purdila
In-Reply-To: <1294659559-22648-1-git-send-email-ddvlad@rosedu.org>
On Mon, 10 Jan 2011 13:39:16 +0200
Vlad Dogaru <ddvlad@rosedu.org> wrote:
> This patch series adds userspace support for network device groups.
> There is support for setting device groups, listing only interfaces of a
> specific group, and setting basic device parameters for all interfaces
> in a group.
>
> The patches use the IFLA_GROUP and IFLA_FILTERGROUP messages, for which
> I posted pathes in a different set.
>
>
> Vlad Dogaru (3):
> ip link: add support for setting device groups
> ip link: support listing devices by group
> ip link: support setting device parameters by group
>
> include/linux/if_link.h | 3 ++
> include/linux/netdevice.h | 2 +-
> include/utils.h | 3 +-
> ip/ipaddress.c | 14 +++++++++++
> ip/iplink.c | 54 +++++++++++++++++++++++++++++++++++++++++++-
> ip/link_veth.c | 3 +-
> 6 files changed, 74 insertions(+), 5 deletions(-)
I like the idea, but I wonder if we should take it farther?
Should it be hierarchal tree of groups?
Should slave devices (ppp, vlan, etc) be automatically assigned
to group of parent?
^ permalink raw reply
* Re: [PATCH] Cleanup include/net/tcp.h include-files and coding-style
From: Randy Dunlap @ 2011-01-10 16:30 UTC (permalink / raw)
To: christoph.paasch
Cc: Alexey Dobriyan, Ben Hutchings, davem, netdev, linux-kernel
In-Reply-To: <201101101724.46023.christoph.paasch@uclouvain.be>
On Mon, 10 Jan 2011 17:24:45 +0100 Christoph Paasch wrote:
>
> On Monday, January 10, 2011 wrote Randy Dunlap:
> > Documentation/SubmitChecklist, #1:
> >
> > 1: If you use a facility then #include the file that defines/declares
> > that facility. Don't depend on other header files pulling in ones
> > that you use.
> Ok, great. That was the answer I was looking for.
>
> So, there is a clear rule that defines the #include-policy.
>
> Now, should the missing #include's be added, or not?
>
> Alexey Dobriyan is against it, as he says in one of his previous mails.
> And, I'm nearly sure that the rule is not respected in plenty of other files
> of the Linux Kernel.
If a build fails on any $architecture due to a missing header file, then
the header file should be added.
If you just want to fix source files that are missing header files, then
the patches should be accepted, even if they are not "needed" in some
strong sense of that word.
Adding the header files adds documentation that some interface from that
header file is being used and it prevents failures that would happen
if an indirect #include were removed, so it's a good practice, but sure,
there are plenty of places that miss this. It was added as Rule #1
(explicity as Rule __#1__) due to so many build errors due to this
that were occurring in linux-next trees.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH] Cleanup include/net/tcp.h include-files and coding-style
From: Christoph Paasch @ 2011-01-10 16:24 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Alexey Dobriyan, Ben Hutchings, davem, netdev, linux-kernel
In-Reply-To: <20110110075032.e38955ef.rdunlap@xenotime.net>
On Monday, January 10, 2011 wrote Randy Dunlap:
> Documentation/SubmitChecklist, #1:
>
> 1: If you use a facility then #include the file that defines/declares
> that facility. Don't depend on other header files pulling in ones
> that you use.
Ok, great. That was the answer I was looking for.
So, there is a clear rule that defines the #include-policy.
Now, should the missing #include's be added, or not?
Alexey Dobriyan is against it, as he says in one of his previous mails.
And, I'm nearly sure that the rule is not respected in plenty of other files
of the Linux Kernel.
Cheers,
Christoph
--
Christoph Paasch
PhD Student
IP Networking Lab --- http://inl.info.ucl.ac.be
MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp
Université Catholique de Louvain
www.rollerbulls.be
--
^ permalink raw reply
* Re: [PATCH] Cleanup include/net/tcp.h include-files and coding-style
From: Randy Dunlap @ 2011-01-10 15:50 UTC (permalink / raw)
To: christoph.paasch
Cc: Alexey Dobriyan, Ben Hutchings, davem, netdev, linux-kernel
In-Reply-To: <201101101244.24932.christoph.paasch@uclouvain.be>
On Mon, 10 Jan 2011 12:44:24 +0100 Christoph Paasch wrote:
>
> On Monday, January 10, 2011 wrote Alexey Dobriyan:
> > >> linux/percpu_counter.h (needed for percpu_counter_sum_positive)
> > >
> > > Yes.
> >
> > Currently code compiles fine, so necessary headers are in place,
> > so simply adding new headers doesn't help anything.
>
> I totally agree with you.
> However we need a consistent coding style.
>
> Or we just include the minimum necessary headers (as originally proposed by
> me).
> Or we include every header whose structs/functions are referenced.
>
> In my opinion the current "mixed" state is not ok, because some includes are
> there because there *are* references (even if these includes could be omitted,
> e.g., linux/list.h).
> Other includes (like linux/percpu_counter.h) are not there, because they are
> indirectly included by another header and thus the code compiles. Even if
> there are references.
> And there are no rules/guidelines to identify the headers that should be
> included and those that should not.
Documentation/SubmitChecklist, #1:
1: If you use a facility then #include the file that defines/declares
that facility. Don't depend on other header files pulling in ones
that you use.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2 1/2] can: add driver for Softing card
From: Kurt Van Dijck @ 2011-01-10 14:40 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4D2B1245.9060303-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
On Mon, Jan 10, 2011 at 03:05:57PM +0100, Wolfgang Grandegger wrote:
> On 01/10/2011 02:31 PM, Kurt Van Dijck wrote:
> > On Wed, Jan 05, 2011 at 09:57:16PM +0100, Wolfgang Grandegger wrote:
> OK, another good reason to make softing_cs depend on CONFIG_CAN_SOFTING.
> Does it make sense to compile softing_cs without CONFIG_CAN_SOFTING for
> the *real* user?
>
Good point.
I will add in Kconfig:
config CAN_SOFTING_CS
tristate "Softing CAN pcmcia cards"
depends on PCMCIA
+ select CAN_SOFTING
---help---
Thanks,
Kurt
^ permalink raw reply
* Re: [PATCH 0/3] net: add device groups
From: Johannes Berg @ 2011-01-10 14:38 UTC (permalink / raw)
To: hadi; +Cc: Vlad Dogaru, Octavian Purdila, netdev
In-Reply-To: <1294669450.6063.319.camel@mojatatu>
On Mon, 2011-01-10 at 09:24 -0500, jamal wrote:
> > It also means the
> > grouping is entirely user-space controlled. In this case, the idea of
> > automatically grouping based on the device structure seems pointless.
>
> You still havent said what you want this grouping for. What is your
> use case? ;->
I don't have a use case. I was just wondering if there's any benefit in
grouping virtual devices that belong to a single physical device, but I
suppose there isn't.
johannes
^ permalink raw reply
* Re: [PATCH 0/3] net: add device groups
From: jamal @ 2011-01-10 14:24 UTC (permalink / raw)
To: Johannes Berg; +Cc: Vlad Dogaru, Octavian Purdila, netdev
In-Reply-To: <1294668505.3583.9.camel@jlt3.sipsolutions.net>
On Mon, 2011-01-10 at 15:08 +0100, Johannes Berg wrote:
>
> Right, but where would you want to use it -- what's the use case right
> now? Your ppp example here makes me think the use case is some PPP
> endpoint server that has lots of these interfaces.
That was just an example because someone mentioned PPP earlier.
Originally, this came from someone (Octavian?) trying to setup
a gazillion netdevs for testing purposes and then needing to
do "ip link ls dummy*" which causes a gazillion messages between
kernel and user space and all the filtering of what dummy* being
done in user space.
> It also means the
> grouping is entirely user-space controlled. In this case, the idea of
> automatically grouping based on the device structure seems pointless.
You still havent said what you want this grouping for. What is your
use case? ;->
cheers,
jamal
^ permalink raw reply
* Re: [patch v2] phonet: some signedness bugs
From: Rémi Denis-Courmont @ 2011-01-10 14:12 UTC (permalink / raw)
To: ext Dan Carpenter; +Cc: netdev, kernel-janitors, dan.j.rosenberg
In-Reply-To: <20110110140658.GB2721@bicker>
On Monday 10 January 2011 16:06:58 ext Dan Carpenter, you wrote:
> Dan Rosenberg pointed out that there were some signed comparison bugs
> in the phonet protocol.
>
> http://marc.info/?l=full-disclosure&m=129424528425330&w=2
>
> The problem is that we check for array overflows but "protocol" is
> signed and we don't check for array underflows. If you have already
> have CAP_SYS_ADMIN then you could use the bugs to get root, or someone
> could cause an oops by mistake.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
--
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki
^ permalink raw reply
* Re: [patch] phonet: some signedness bugs
From: Rémi Denis-Courmont @ 2011-01-10 14:08 UTC (permalink / raw)
To: ext Dan Carpenter
Cc: David S. Miller, netdev, kernel-janitors, dan.j.rosenberg
In-Reply-To: <20110110140141.GA2721@bicker>
On Monday 10 January 2011 16:01:41 ext Dan Carpenter, you wrote:
> I would like to keep the change to phonet_proto_register() because the
> check in there isn't right and it's similar to phonet_proto_get(). We
> may as well keep phonet_proto_unregister() as well so it's symmetric.
> Let me know if you disagree and I'll redo it.
Sounds sensible to me.
--
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki
^ permalink raw reply
* Re: [PATCH 0/3] net: add device groups
From: Johannes Berg @ 2011-01-10 14:08 UTC (permalink / raw)
To: hadi; +Cc: Vlad Dogaru, Octavian Purdila, netdev
In-Reply-To: <1294668021.6063.315.camel@mojatatu>
On Mon, 2011-01-10 at 09:00 -0500, jamal wrote:
> On Mon, 2011-01-10 at 14:41 +0100, Johannes Berg wrote:
>
> > Can you explain the purpose of this? I'm wondering if it would make
> > sense to automatically group all virtual interfaces belonging to a
> > single 802.11 device, for instance.
>
> It depends what you want to do with that grouping.
> In a nutshell, this greatly reduces the amount of kernel-user netlink
> traffic in presence of multi interfaces.
> you can do things like:
>
> ip link set dev ppp0 group 1
> ...
> ...
> ip link set dev pppN group 1
>
> ip link ls group 1
> ip link set down group 1
> ip link set mtu 512 group 1
> etc
Right, but where would you want to use it -- what's the use case right
now? Your ppp example here makes me think the use case is some PPP
endpoint server that has lots of these interfaces. It also means the
grouping is entirely user-space controlled. In this case, the idea of
automatically grouping based on the device structure seems pointless.
johannes
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2 1/2] can: add driver for Softing card
From: Wolfgang Grandegger @ 2011-01-10 14:07 UTC (permalink / raw)
To: Kurt Van Dijck
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4D2B1245.9060303-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
On 01/10/2011 03:05 PM, Wolfgang Grandegger wrote:
> On 01/10/2011 02:31 PM, Kurt Van Dijck wrote:
>> Wolfgang,
>>
>> A few thoughts ...
>>
>> On Wed, Jan 05, 2011 at 09:57:16PM +0100, Wolfgang Grandegger wrote:
>>>>
>>>> obj-y += usb/
>>>> +obj-y += softing/
>>>
>>> Please use "obj-$(CONFIG_CAN_SOFTING)" here.
>> As I explained, softing does not depend on softing_cs or vice versa,
>> which makes "obj-$(CONFIG_CAN_SOFTING)" not right.
>
> OK, another good reason to make softing_cs depend on CONFIG_CAN_SOFTING.
> Does it make sense to compile softing_cs without CONFIG_CAN_SOFTING for
> the *real* user?
>
> ...
>
>>>> + priv->can.ctrlmode_supported =
>>>> + CAN_CTRLMODE_3_SAMPLES;/* | CAN_CTRLMODE_BERR_REPORTING */;
>>>
>>> Hm, any chance to support CAN_CTRLMODE_BERR_REPORTING? If not, please
>>> remove the comment.
>>
>> I think I better try to write it properly without, and add error reporting
>> later, after serious testing of the error reporting on a softing card.
>
> OK, then just cleanup properly.
>
>> The primary goal now is get this driver in mainline kernel since PCMCIA
>> has been changing recently, and I found it hard to keep up. So, first things
>> first ...
>
> Fine for me. You can then add my:
>
> Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Is there a mailing list for the PCMCIA interface? If yes, please add it
to the CC as well.
Wolfgang.
^ permalink raw reply
* [patch v2] phonet: some signedness bugs
From: Dan Carpenter @ 2011-01-10 14:06 UTC (permalink / raw)
To: Rémi Denis-Courmont
Cc: David S. Miller, netdev, kernel-janitors, dan.j.rosenberg
In-Reply-To: <201101100958.32549.remi.denis-courmont@nokia.com>
Dan Rosenberg pointed out that there were some signed comparison bugs
in the phonet protocol.
http://marc.info/?l=full-disclosure&m=129424528425330&w=2
The problem is that we check for array overflows but "protocol" is
signed and we don't check for array underflows. If you have already
have CAP_SYS_ADMIN then you could use the bugs to get root, or someone
could cause an oops by mistake.
Signed-off-by: Dan Carpenter <error27@gmail.com>
---
v2: in v1 I changed pn_socket_create() but that change caused a
compiler warning. That part of the patch wasn't needed so I've just
dropped.
diff --git a/include/net/phonet/phonet.h b/include/net/phonet/phonet.h
index d5df797..5395e09 100644
--- a/include/net/phonet/phonet.h
+++ b/include/net/phonet/phonet.h
@@ -107,8 +107,8 @@ struct phonet_protocol {
int sock_type;
};
-int phonet_proto_register(int protocol, struct phonet_protocol *pp);
-void phonet_proto_unregister(int protocol, struct phonet_protocol *pp);
+int phonet_proto_register(unsigned int protocol, struct phonet_protocol *pp);
+void phonet_proto_unregister(unsigned int protocol, struct phonet_protocol *pp);
int phonet_sysctl_init(void);
void phonet_sysctl_exit(void);
diff --git a/net/phonet/af_phonet.c b/net/phonet/af_phonet.c
index fd95beb..1072b2c 100644
--- a/net/phonet/af_phonet.c
+++ b/net/phonet/af_phonet.c
@@ -37,7 +37,7 @@
/* Transport protocol registration */
static struct phonet_protocol *proto_tab[PHONET_NPROTO] __read_mostly;
-static struct phonet_protocol *phonet_proto_get(int protocol)
+static struct phonet_protocol *phonet_proto_get(unsigned int protocol)
{
struct phonet_protocol *pp;
@@ -458,7 +458,7 @@ static struct packet_type phonet_packet_type __read_mostly = {
static DEFINE_MUTEX(proto_tab_lock);
-int __init_or_module phonet_proto_register(int protocol,
+int __init_or_module phonet_proto_register(unsigned int protocol,
struct phonet_protocol *pp)
{
int err = 0;
@@ -481,7 +481,7 @@ int __init_or_module phonet_proto_register(int protocol,
}
EXPORT_SYMBOL(phonet_proto_register);
-void phonet_proto_unregister(int protocol, struct phonet_protocol *pp)
+void phonet_proto_unregister(unsigned int protocol, struct phonet_protocol *pp)
{
mutex_lock(&proto_tab_lock);
BUG_ON(proto_tab[protocol] != pp);
^ permalink raw reply related
* Re: [PATCH net-next-2.6 v2 1/2] can: add driver for Softing card
From: Wolfgang Grandegger @ 2011-01-10 14:05 UTC (permalink / raw)
To: Kurt Van Dijck; +Cc: socketcan-core, netdev
In-Reply-To: <20110110133112.GA324@e-circ.dyndns.org>
On 01/10/2011 02:31 PM, Kurt Van Dijck wrote:
> Wolfgang,
>
> A few thoughts ...
>
> On Wed, Jan 05, 2011 at 09:57:16PM +0100, Wolfgang Grandegger wrote:
>>>
>>> obj-y += usb/
>>> +obj-y += softing/
>>
>> Please use "obj-$(CONFIG_CAN_SOFTING)" here.
> As I explained, softing does not depend on softing_cs or vice versa,
> which makes "obj-$(CONFIG_CAN_SOFTING)" not right.
OK, another good reason to make softing_cs depend on CONFIG_CAN_SOFTING.
Does it make sense to compile softing_cs without CONFIG_CAN_SOFTING for
the *real* user?
...
>>> + priv->can.ctrlmode_supported =
>>> + CAN_CTRLMODE_3_SAMPLES;/* | CAN_CTRLMODE_BERR_REPORTING */;
>>
>> Hm, any chance to support CAN_CTRLMODE_BERR_REPORTING? If not, please
>> remove the comment.
>
> I think I better try to write it properly without, and add error reporting
> later, after serious testing of the error reporting on a softing card.
OK, then just cleanup properly.
> The primary goal now is get this driver in mainline kernel since PCMCIA
> has been changing recently, and I found it hard to keep up. So, first things
> first ...
Fine for me. You can then add my:
Acked-by: Wolfgang Grandegger <wg@grandegger.com>
Thanks.
Wolfgang.
^ permalink raw reply
* Re: [patch] phonet: some signedness bugs
From: Dan Carpenter @ 2011-01-10 14:01 UTC (permalink / raw)
To: Rémi Denis-Courmont
Cc: David S. Miller, netdev, kernel-janitors, dan.j.rosenberg
In-Reply-To: <201101100958.32549.remi.denis-courmont@nokia.com>
On Mon, Jan 10, 2011 at 09:58:32AM +0200, Rémi Denis-Courmont wrote:
> On Friday 07 January 2011 22:37:55 ext Dan Carpenter, you wrote:
> > Dan Rosenberg pointed out that there were some signed comparison bugs
> > in the phonet protocol.
>
> There are two ways to solve this: change *only* the proto_get function to use
> an unsigned parameter, or cast the protocol to unsigned in the comparison.
>
> As David pointed out, your patch breaks the socket() callback prototype.
>
Yes. I really appologize for that. I'll send version 2 with that create()
change dropped. It's not needed.
I would like to keep the change to phonet_proto_register() because the
check in there isn't right and it's similar to phonet_proto_get(). We
may as well keep phonet_proto_unregister() as well so it's symmetric.
Let me know if you disagree and I'll redo it.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH 0/3] net: add device groups
From: jamal @ 2011-01-10 14:00 UTC (permalink / raw)
To: Johannes Berg; +Cc: Vlad Dogaru, Octavian Purdila, netdev
In-Reply-To: <1294666875.3583.6.camel@jlt3.sipsolutions.net>
On Mon, 2011-01-10 at 14:41 +0100, Johannes Berg wrote:
> Can you explain the purpose of this? I'm wondering if it would make
> sense to automatically group all virtual interfaces belonging to a
> single 802.11 device, for instance.
It depends what you want to do with that grouping.
In a nutshell, this greatly reduces the amount of kernel-user netlink
traffic in presence of multi interfaces.
you can do things like:
ip link set dev ppp0 group 1
...
...
ip link set dev pppN group 1
ip link ls group 1
ip link set down group 1
ip link set mtu 512 group 1
etc
Although now that i am thinking of it,
I am not sure whether it would be a legit thing to change
the MAC address of a group of devices - we may need to put
some restrictions.
Note: this grouping thing can also be potentially used in
packet policies etc (but i dont want to distract the simple
requirement we have at the moment).
cheers,
jamal
^ permalink raw reply
* Re: [RFC] sched: CHOKe packet scheduler (v0.2)
From: Eric Dumazet @ 2011-01-10 13:46 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20110106205549.0de56de1@nehalam>
Le jeudi 06 janvier 2011 à 20:55 -0800, Stephen Hemminger a écrit :
>
> The problem is that large tables of pointers in kernel require either
> contiguous allocation or some indirect table algorithm.
>
Here is a v3 version with an array based queue for O(1) peek_random
complexity.
Could you send the iproute2 patch so that I can test it ?
Thanks !
diff --git a/net/sched/sch_choke.c b/net/sched/sch_choke.c
index e69de29..ea9db00 100644
--- a/net/sched/sch_choke.c
+++ b/net/sched/sch_choke.c
@@ -0,0 +1,388 @@
+/*
+ * net/sched/sch_choke.c CHOKE scheduler
+ *
+ * Copyright (c) 2011 Stephen Hemminger <shemminger@vyatta.com>
+ * Copyright (c) 2011 Eric Dumazet <eric.dumazet@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <linux/skbuff.h>
+#include <linux/reciprocal_div.h>
+#include <net/pkt_sched.h>
+#include <net/inet_ecn.h>
+#include <net/red.h>
+
+/* CHOKe stateless AQM for fair bandwidth allocation
+ =================================================
+
+ CHOKe (CHOose and Keep for responsive flows, CHOose and Kill for
+ unresponsive flows) is a variant of RED that penalizes misbehaving flows but
+ maintains no flow state. The difference from RED is an additional step
+ during the enqueuing process. If average queue size is over the
+ low threshold (qmin), a packet is chosen at random from the queue.
+ If both the new and chosen packet are from the same flow, both
+ are dropped. Unlike RED, CHOKe is not a "classful" qdisc because it
+ needs to access packets in queue randomly.
+
+ Source:
+ R. Pan, B. Prabhakar, and K. Psounis, "CHOKe, A Stateless
+ Active Queue Management Scheme for Approximating Fair Bandwidth Allocation",
+ IEEE INFOCOM, 2000.
+
+ A. Tang, J. Wang, S. Low, "Understanding CHOKe: Throughput and Spatial
+ Characteristics", IEEE/ACM Transactions on Networking, 2004
+
+ */
+
+struct choke_sched_data {
+ u32 limit;
+ unsigned char flags;
+
+ struct red_parms parms;
+ struct red_stats stats;
+
+ unsigned int head;
+ unsigned int tail;
+ unsigned int holes;
+ unsigned int tab_mask; /* size - 1 */
+ struct sk_buff **tab;
+};
+
+static inline unsigned int choke_len(const struct choke_sched_data *q)
+{
+ return (q->tail - q->head) & q->tab_mask;
+}
+
+/* deliver a random number between 0 and N - 1 */
+static inline u32 random_N(unsigned int N)
+{
+ return reciprocal_divide(random32(), N);
+}
+
+/* Select a packet at random from the queue in O(1) */
+static struct sk_buff *choke_peek_random(struct choke_sched_data *q, unsigned int *pidx)
+{
+ *pidx = (q->head + random_N(choke_len(q))) & q->tab_mask;
+ return q->tab[*pidx];
+}
+
+
+static inline int use_ecn(const struct choke_sched_data *q)
+{
+ return q->flags & TC_RED_ECN;
+}
+
+static inline int use_harddrop(const struct choke_sched_data *q)
+{
+ return q->flags & TC_RED_HARDDROP;
+}
+
+static inline void choke_zap_head_holes(struct choke_sched_data *q)
+{
+ while (q->holes && q->tab[q->head] == NULL) {
+ q->head = (q->head + 1) & q->tab_mask;
+ q->holes--;
+ }
+}
+
+static inline void choke_zap_tail_holes(struct choke_sched_data *q)
+{
+ while (q->holes && q->tab[q->tail - 1] == NULL) {
+ q->tail = (q->tail - 1) & q->tab_mask;
+ q->holes--;
+ }
+}
+
+static void choke_drop_by_idx(struct choke_sched_data *q, unsigned int idx)
+{
+ q->tab[idx] = NULL;
+ q->holes++;
+ choke_zap_head_holes(q);
+ choke_zap_tail_holes(q);
+}
+
+
+static int choke_enqueue(struct sk_buff *skb, struct Qdisc *sch)
+{
+ struct choke_sched_data *q = qdisc_priv(sch);
+ struct red_parms *p = &q->parms;
+
+ p->qavg = red_calc_qavg(p, choke_len(q) - q->holes);
+ if (red_is_idling(p))
+ red_end_of_idle_period(p);
+
+ if (p->qavg <= p->qth_min)
+ p->qcount = -1;
+ else {
+ struct sk_buff *oskb;
+ unsigned int idx;
+
+ /* Draw a packet at random from queue */
+ oskb = choke_peek_random(q, &idx);
+
+ /* Both packets from same flow ? */
+ if (oskb && skb_get_rxhash(oskb) == skb_get_rxhash(skb)) {
+ /* Drop both packets */
+ choke_drop_by_idx(q, idx);
+ qdisc_drop(oskb, sch);
+ goto congestion_drop;
+ }
+
+ if (p->qavg > p->qth_max) {
+ p->qcount = -1;
+
+ sch->qstats.overlimits++;
+ if (use_harddrop(q) || !use_ecn(q) ||
+ !INET_ECN_set_ce(skb)) {
+ q->stats.forced_drop++;
+ goto congestion_drop;
+ }
+
+ q->stats.forced_mark++;
+ }
+
+ if (++p->qcount) {
+ if (red_mark_probability(p, p->qavg)) {
+ p->qcount = 0;
+ p->qR = red_random(p);
+
+ sch->qstats.overlimits++;
+ if (!use_ecn(q) || !INET_ECN_set_ce(skb)) {
+ q->stats.prob_drop++;
+ goto congestion_drop;
+ }
+
+ q->stats.prob_mark++;
+ }
+ } else
+ p->qR = red_random(p);
+ }
+
+ /* Admit new packet */
+ if (likely(choke_len(q) < q->limit)) {
+ q->tab[q->tail] = skb;
+ q->tail = (q->tail + 1) & q->tab_mask;
+ sch->qstats.backlog += qdisc_pkt_len(skb);
+ __qdisc_update_bstats(sch, qdisc_pkt_len(skb));
+ return NET_XMIT_SUCCESS;
+ }
+ q->stats.pdrop++;
+ sch->qstats.drops++;
+ kfree_skb(skb);
+ return NET_XMIT_DROP;
+
+ congestion_drop:
+ qdisc_drop(skb, sch);
+ return NET_XMIT_CN;
+}
+
+static struct sk_buff *choke_dequeue(struct Qdisc *sch)
+{
+ struct choke_sched_data *q = qdisc_priv(sch);
+ struct sk_buff *skb;
+
+ if (q->head == q->tail) {
+ if (!red_is_idling(&q->parms))
+ red_start_of_idle_period(&q->parms);
+ return NULL;
+ }
+ skb = q->tab[q->head];
+ q->tab[q->head] = NULL; /* not really needed */
+ q->head = (q->head + 1) & q->tab_mask;
+ choke_zap_head_holes(q);
+ sch->qstats.backlog -= qdisc_pkt_len(skb);
+
+ return skb;
+}
+
+static unsigned int choke_drop(struct Qdisc *sch)
+{
+ struct choke_sched_data *q = qdisc_priv(sch);
+ unsigned int len;
+
+ len = qdisc_queue_drop(sch);
+
+ if (len > 0)
+ q->stats.other++;
+ else {
+ if (!red_is_idling(&q->parms))
+ red_start_of_idle_period(&q->parms);
+ }
+
+ return len;
+}
+
+static void choke_reset(struct Qdisc* sch)
+{
+ struct choke_sched_data *q = qdisc_priv(sch);
+
+ red_restart(&q->parms);
+}
+
+static const struct nla_policy choke_policy[TCA_RED_MAX + 1] = {
+ [TCA_RED_PARMS] = { .len = sizeof(struct tc_red_qopt) },
+ [TCA_RED_STAB] = { .len = RED_STAB_SIZE },
+};
+
+
+static void choke_free(void *addr)
+{
+ if (addr) {
+ if (is_vmalloc_addr(addr))
+ vfree(addr);
+ else
+ kfree(addr);
+ }
+}
+
+static int choke_change(struct Qdisc *sch, struct nlattr *opt)
+{
+ struct choke_sched_data *q = qdisc_priv(sch);
+ struct nlattr *tb[TCA_RED_MAX + 1];
+ struct tc_red_qopt *ctl;
+ int err;
+ struct sk_buff **old = NULL;
+ unsigned int mask;
+
+ if (opt == NULL)
+ return -EINVAL;
+
+ err = nla_parse_nested(tb, TCA_RED_MAX, opt, choke_policy);
+ if (err < 0)
+ return err;
+
+ if (tb[TCA_RED_PARMS] == NULL ||
+ tb[TCA_RED_STAB] == NULL)
+ return -EINVAL;
+
+ ctl = nla_data(tb[TCA_RED_PARMS]);
+
+ mask = roundup_pow_of_two(ctl->limit + 1) - 1;
+ if (mask != q->tab_mask) {
+ struct sk_buff **ntab = kcalloc(mask + 1, sizeof(struct sk_buff *),
+ GFP_KERNEL);
+ if (!ntab)
+ ntab = vzalloc((mask + 1) * sizeof(struct sk_buff *));
+ if (!ntab)
+ return -ENOMEM;
+ sch_tree_lock(sch);
+ old = q->tab;
+ if (old) {
+ unsigned int tail = 0;
+
+ while (q->head != q->tail) {
+ ntab[tail++] = q->tab[q->head];
+ q->head = (q->head + 1) & q->tab_mask;
+ }
+ q->head = 0;
+ q->tail = tail;
+ }
+ q->tab_mask = mask;
+ q->holes = 0;
+ } else
+ sch_tree_lock(sch);
+ q->flags = ctl->flags;
+ q->limit = ctl->limit;
+
+ red_set_parms(&q->parms, ctl->qth_min, ctl->qth_max, ctl->Wlog,
+ ctl->Plog, ctl->Scell_log,
+ nla_data(tb[TCA_RED_STAB]));
+
+ if (q->head == q->tail)
+ red_end_of_idle_period(&q->parms);
+
+ sch_tree_unlock(sch);
+ choke_free(old);
+ return 0;
+}
+
+static int choke_init(struct Qdisc* sch, struct nlattr *opt)
+{
+ return choke_change(sch, opt);
+}
+
+static int choke_dump(struct Qdisc *sch, struct sk_buff *skb)
+{
+ struct choke_sched_data *q = qdisc_priv(sch);
+ struct nlattr *opts = NULL;
+ struct tc_red_qopt opt = {
+ .limit = q->limit,
+ .flags = q->flags,
+ .qth_min = q->parms.qth_min >> q->parms.Wlog,
+ .qth_max = q->parms.qth_max >> q->parms.Wlog,
+ .Wlog = q->parms.Wlog,
+ .Plog = q->parms.Plog,
+ .Scell_log = q->parms.Scell_log,
+ };
+
+ sch->q.qlen = choke_len(q) - q->holes;
+ opts = nla_nest_start(skb, TCA_OPTIONS);
+ if (opts == NULL)
+ goto nla_put_failure;
+
+ NLA_PUT(skb, TCA_RED_PARMS, sizeof(opt), &opt);
+ return nla_nest_end(skb, opts);
+
+nla_put_failure:
+ nla_nest_cancel(skb, opts);
+ return -EMSGSIZE;
+}
+
+static int choke_dump_stats(struct Qdisc *sch, struct gnet_dump *d)
+{
+ struct choke_sched_data *q = qdisc_priv(sch);
+ struct tc_red_xstats st = {
+ .early = q->stats.prob_drop + q->stats.forced_drop,
+ .pdrop = q->stats.pdrop,
+ .other = q->stats.other,
+ .marked = q->stats.prob_mark + q->stats.forced_mark,
+ };
+
+ return gnet_stats_copy_app(d, &st, sizeof(st));
+}
+
+static void choke_destroy(struct Qdisc *sch)
+{
+ struct choke_sched_data *q = qdisc_priv(sch);
+
+ choke_free(q->tab);
+}
+
+static struct Qdisc_ops choke_qdisc_ops __read_mostly = {
+ .id = "choke",
+ .priv_size = sizeof(struct choke_sched_data),
+
+ .enqueue = choke_enqueue,
+ .dequeue = choke_dequeue,
+ .peek = qdisc_peek_head,
+ .drop = choke_drop,
+ .init = choke_init,
+ .destroy = choke_destroy,
+ .reset = choke_reset,
+ .change = choke_change,
+ .dump = choke_dump,
+ .dump_stats = choke_dump_stats,
+ .owner = THIS_MODULE,
+};
+
+static int __init choke_module_init(void)
+{
+ return register_qdisc(&choke_qdisc_ops);
+}
+
+static void __exit choke_module_exit(void)
+{
+ unregister_qdisc(&choke_qdisc_ops);
+}
+
+module_init(choke_module_init)
+module_exit(choke_module_exit)
+
+MODULE_LICENSE("GPL");
^ permalink raw reply related
* Re: [PATCH net-next-2.6 v2 1/2] can: add driver for Softing card
From: Kurt Van Dijck @ 2011-01-10 13:44 UTC (permalink / raw)
To: Wolfram Sang
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, Wolfgang Grandegger
In-Reply-To: <20110110134006.GC31011-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On Mon, Jan 10, 2011 at 02:40:06PM +0100, Wolfram Sang wrote:
> > > > + if (type != 0xffff) {
> > > > + dev_alert(&card->pdev->dev, "firware starts with type 0x%04x\n",
> > >
> > > Typo?
> > >
> > ??
>
> I think he means "fir[m]ware"
>
Thanks. Can't imagine anymore how I couldn't see it.
Kurt
^ permalink raw reply
* Re: [PATCH 0/3] net: add device groups
From: Johannes Berg @ 2011-01-10 13:41 UTC (permalink / raw)
To: Vlad Dogaru; +Cc: jamal, Octavian Purdila, netdev
In-Reply-To: <1294659524-22509-1-git-send-email-ddvlad@rosedu.org>
On Mon, 2011-01-10 at 13:38 +0200, Vlad Dogaru wrote:
> This patchset implements network device grouping and simple manipulation
> of groups. Netlink has been update to provide group information and
> means of applying changes to members of a specific group via a single
> message.
Can you explain the purpose of this? I'm wondering if it would make
sense to automatically group all virtual interfaces belonging to a
single 802.11 device, for instance.
johannes
^ 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