* Re: [net-next 8/9] ixgbe: add interface to export thermal data
From: Francois Romieu @ 2011-12-23 20:45 UTC (permalink / raw)
To: Skidmore, Donald C
Cc: Kirsher, Jeffrey T, davem@davemloft.net, netdev@vger.kernel.org,
gospo@redhat.com, sassmann@redhat.com, Waskiewicz Jr, Peter P
In-Reply-To: <F6FB0E698C9B3143BDF729DF22286646E087@ORSMSX102.amr.corp.intel.com>
Skidmore, Donald C <donald.c.skidmore@intel.com> :
[...]
> I like all your suggestions and will do the clean up.
>
> Thanks again for the great review. :)
Depending on how you plan to use ixgbe_init_thermal_sensor_thresh_generic,
the memset(..., 0, ...) may be removed since it is applied within the
device own kzalloced struct ixgbe_hw.
I must confess I have not looked too closely at the sysfs code.
--
Ueimor
^ permalink raw reply
* Re: SFQ on HFSC leaf does not seem to work
From: John A. Sullivan III @ 2011-12-23 21:10 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1324661727.10184.617.camel@denise.theartistscloset.com>
On Fri, 2011-12-23 at 12:35 -0500, John A. Sullivan III wrote:
> On Fri, 2011-12-23 at 12:33 -0500, John A. Sullivan III wrote:
> > On Fri, 2011-12-23 at 18:17 +0100, Eric Dumazet wrote:
> > > Le vendredi 23 décembre 2011 à 18:06 +0100, Eric Dumazet a écrit :
> > >
> > > > Maybe I was not clear :
> > > >
> > > > netem currently uses a fifo queue, you cant change this, without
> > > > patching kernel.
> > > >
> > >
> > > An other way would be to patch sch_tbf, adding delay, if its all you
> > > want to do.
> > >
> > > (Or adding delay capability to ifb)
> > >
> > >
> > >
> > >
> > <grin> that's just a little outside by skill set ;) - John
> >
> <snip>
> And I should mention seriously, that we are viewing our learning curve
> as something we will use in production so we'd like to accomplish our
> goals using stock distribution code. Thanks, though - John
<snip>
Should I guess that, from the flood of subsequent emails about patching
netem that it is not currently possible to do netem and hfsc/sfq on
ingress traffic using the currently available tools?
It's definitely netem on the ingress. When I run it on egress and
disable it on ingress, I do not have the problem. But, I see no what of
getting the netem traffic into or out of SFQ. Thanks - John
^ permalink raw reply
* Re: [PATCH net-next] sch_hfsc: report backlog information
From: David Miller @ 2011-12-23 21:52 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, jsullivan
In-Reply-To: <1324653560.2223.37.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 23 Dec 2011 16:19:20 +0100
> Add backlog (byte count) information in hfsc classes and qdisc, so that
> "tc -s" can report it to user, instead of 0 values :
>
> qdisc hfsc 1: root refcnt 6 default 20
> Sent 45141660 bytes 30545 pkt (dropped 0, overlimits 91751 requeues 0)
> rate 1492Kbit 126pps backlog 103226b 74p requeues 0
> ...
> class hfsc 1:20 parent 1:1 leaf 1201: rt m1 0bit d 0us m2 400000bit ls m1 0bit d 0us m2 200000bit
> Sent 49534912 bytes 33519 pkt (dropped 0, overlimits 0 requeues 0)
> backlog 81822b 56p requeues 0
> period 23 work 49451576 bytes rtwork 13277552 bytes level 0
> ...
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [patch] usb: pegasus: cleanup a couple conditions
From: David Miller @ 2011-12-23 21:52 UTC (permalink / raw)
To: dan.carpenter; +Cc: petkan, gregkh, linux-usb, netdev, kernel-janitors
In-Reply-To: <20111223104436.GA8592@elgon.mountain>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Fri, 23 Dec 2011 13:44:36 +0300
> We recently made loopback a bool type instead of an int, so the bitwise
> AND is redundent.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied.
^ permalink raw reply
* Re: [PATCH 0/4] skb paged fragment destructors
From: David Miller @ 2011-12-23 21:52 UTC (permalink / raw)
To: Ian.Campbell; +Cc: eric.dumazet, jesse.brandeburg, netdev
In-Reply-To: <1324633155.7877.106.camel@zakaz.uk.xensource.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 23 Dec 2011 09:39:14 +0000
> Subject: [PATCH] net: only use a single page of slop in MAX_SKB_FRAGS
>
> In order to accommodate a 64K buffer we need 64K/PAGE_SIZE plus one more page
> in order to allow for a buffer which does not start on a page boundary.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2] drivers/net/usb/asix: fixed asix_get_wol reported wrong wol status issue
From: David Miller @ 2011-12-23 21:53 UTC (permalink / raw)
To: allan; +Cc: netdev, linux-kernel, freddy, grundler, elubarsky, louis
In-Reply-To: <005001ccc13d$8c9850e0$a5c8f2a0$@com.tw>
From: "allan" <allan@asix.com.tw>
Date: Fri, 23 Dec 2011 14:38:51 +0800
> Fixed the asix_get_wol() routine reported wrong wol status issue.
>
> Signed-off-by: Allan Chou <allan@asix.com.tw>
> Tested-by: Eugene <elubarsky@gmail.com>; Allan Chou <allan@asix.com.tw>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] packet: fix typo in packet_mmap.txt
From: David Miller @ 2011-12-23 21:53 UTC (permalink / raw)
To: weiyj.lk; +Cc: netdev
In-Reply-To: <CAPgLHd-YqSvDKDpsgyL5UJx1wK4MUOGw=LpMbWkENti=7MdkgA@mail.gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Fri, 23 Dec 2011 11:47:54 +0800
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> Just fixed typo of sample code in packet_mmap.txt
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Applied.
^ permalink raw reply
* Re: [PATCH 0/2] bna: Enable ethtool flash management and debugfs interface.
From: David Miller @ 2011-12-23 21:53 UTC (permalink / raw)
To: kgudipat; +Cc: netdev, adapter_linux_open_src_team, rmody
In-Reply-To: <1324596547-7646-1-git-send-email-kgudipat@brocade.com>
From: <kgudipat@Brocade.com>
Date: Thu, 22 Dec 2011 15:29:07 -0800
> The following patch-set enhances BNA ethtool to support flash management
> using eeprom entry points and also enables debugfs support for BNA driver to
> collect firmware traces, saved firmware trace in the flash on an IOC crash and to
> perform register reads/writes.
>
> The patch is compiled and tested against latest net-next kernel.
Both applied, thanks.
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2011-12-23 22:11 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) If no options are provided to mqprio packet scheduler config operation,
which is valid, we crash. Fix from Thomas Graf.
2) The bridge layer's fake route entry needs to provide a ->mtu()
method in it's fake_dst_ops, fix from Eric Dumazet.
3) Add a DST_NOPEER flag for cases like the bridge fake route entry so
that we elide inetpeer based operations on such objects, also from
Eric Dumazet.
4) More careful skb->trusize and socket buffer allotment tracking caused
regressions f.e. when a device at jumbo MTU doesn't do copybreak and
we try to perform a ping using busybox. Busybox sets the socket send
buffer real low, to something like 6K, and therefore the full 9K buffer
(only a small amount of which is actually used) won't fit in the socket
limits.
Fix this using a compromise. Always allow one packet to be queued to
the socket, regardless of the buffer limits.
From Eric Dumazet.
5) xt_connbytes netfilter module implements negation of rules incorrectly,
fix from Florian Westphal.
Please pull, thanks a lot!
The following changes since commit b3b1b70e62a603f473619dbebc3b3d23f535e6f8:
Merge branch 'usb-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb (2011-12-22 12:59:47 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master
David S. Miller (1):
Merge branch 'nf' of git://1984.lsi.us.es/net
Eric Dumazet (3):
bridge: provide a mtu() method for fake_dst_ops
net: introduce DST_NOPEER dst flag
net: relax rcvbuf limits
Florian Westphal (1):
netfilter: xt_connbytes: handle negation correctly
Thomas Graf (1):
mqprio: Avoid panic if no options are provided
Xi Wang (1):
rps: fix insufficient bounds checking in store_rps_dev_flow_table_cnt()
include/net/dst.h | 1 +
include/net/sock.h | 4 +++-
net/bridge/br_netfilter.c | 8 +++++++-
net/core/net-sysfs.c | 7 +++++--
net/core/sock.c | 6 +-----
net/ipv4/route.c | 4 ++--
net/ipv6/ip6_output.c | 2 +-
net/netfilter/xt_connbytes.c | 6 +++---
net/packet/af_packet.c | 6 ++----
net/sched/sch_mqprio.c | 2 +-
10 files changed, 26 insertions(+), 20 deletions(-)
^ permalink raw reply
* Re: netem: loss model API sizes
From: David Miller @ 2011-12-23 22:11 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20111223111630.52f9f6d7@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Fri, 23 Dec 2011 11:16:30 -0800
> The new netem loss model is configured with nested netlink messages.
> This code is being overly strict about sizes, and is easily confused
> by padding (or possible future expansion). Also message
> for gemodel is incorrect.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: SFQ on HFSC leaf does not seem to work
From: Eric Dumazet @ 2011-12-23 22:24 UTC (permalink / raw)
To: John A. Sullivan III; +Cc: netdev
In-Reply-To: <1324674615.10184.631.camel@denise.theartistscloset.com>
Le vendredi 23 décembre 2011 à 16:10 -0500, John A. Sullivan III a
écrit :
> Should I guess that, from the flood of subsequent emails about patching
> netem that it is not currently possible to do netem and hfsc/sfq on
> ingress traffic using the currently available tools?
>
Yep... current netem is a bit limited.
> It's definitely netem on the ingress. When I run it on egress and
> disable it on ingress, I do not have the problem. But, I see no what of
> getting the netem traffic into or out of SFQ. Thanks - John
>
It'll be possible, after a few patches, but only using net-next, or
waiting a backport to a 3.2 kernel somehow...
^ permalink raw reply
* [PATCH] netlink: Undo const marker in netlink_is_kernel().
From: David Miller @ 2011-12-23 22:33 UTC (permalink / raw)
To: netdev; +Cc: shemminger
We can't do this without propagating the const to nlk_sk()
too, otherwise:
net/netlink/af_netlink.c: In function ‘netlink_is_kernel’:
net/netlink/af_netlink.c:103:2: warning: passing argument 1 of ‘nlk_sk’ discards ‘const’ qualifier from pointer target type [enabled by default]
net/netlink/af_netlink.c:96:36: note: expected ‘struct sock *’ but argument is of type ‘const struct sock *’
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/netlink/af_netlink.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 86a258d..629b061 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -98,7 +98,7 @@ static inline struct netlink_sock *nlk_sk(struct sock *sk)
return container_of(sk, struct netlink_sock, sk);
}
-static inline int netlink_is_kernel(const struct sock *sk)
+static inline int netlink_is_kernel(struct sock *sk)
{
return nlk_sk(sk)->flags & NETLINK_KERNEL_SOCKET;
}
--
1.7.7.4
^ permalink raw reply related
* Questioning about DM9000 and link up delay
From: Jean-Baptiste Théou @ 2011-12-23 23:46 UTC (permalink / raw)
To: netdev
Hello everyone,
I am working on a fast boot project and i have a "trouble" and i would
know if someone know more about this topic.
I have improve my boot time . But now i would like to add dhcp
capacity and i have a delay (~2 sec) between dm9000 loading and link
up message. I use kernel ip autoconfig (ip=dhcp on boot cmd) to get
the IP adress.
I have try lot of things (Force media type, trace initcall, etc), but
i cannot find the source of this delay. I think it's a hardware delay,
but 2 second sound like to much for me.
Have you any idea where i can search ?
Hardware configuration :
Mini2440 board
Linux 2.6.32.2
DM9000 driver
Thanking you in advance.
--
Jean-Baptiste Théou,
^ permalink raw reply
* [PATCH iproute2] netem: fix a typo in explain()
From: Eric Dumazet @ 2011-12-24 4:39 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
tc/q_netem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tc/q_netem.c b/tc/q_netem.c
index e9a601b..b1fd452 100644
--- a/tc/q_netem.c
+++ b/tc/q_netem.c
@@ -38,7 +38,7 @@ static void explain(void)
" [ loss random PERCENT [CORRELATION]]\n" \
" [ loss state P13 [P31 [P32 [P23 P14]]]\n" \
" [ loss gemodel PERCENT [R [1-H [1-K]]]\n" \
-" [ reorder PRECENT [CORRELATION] [ gap DISTANCE ]]\n");
+" [ reorder PERCENT [CORRELATION] [ gap DISTANCE ]]\n");
}
static void explain1(const char *arg)
^ permalink raw reply related
* Re: A sysadmin's understanding of HFSC and IFB
From: John A. Sullivan III @ 2011-12-24 5:20 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1323417599.2529.18.camel@edumazet-laptop>
On Fri, 2011-12-09 at 08:59 +0100, Eric Dumazet wrote:
> Le vendredi 09 décembre 2011 à 02:17 -0500, John A. Sullivan III a
> écrit :
> > Hello, all. I've been trying to summarize my last week's worth of
> > research into HFSC and IFB. Being neither a developer nor a
> > mathematician, I found most of the existing documentation daunting and
> > am truly grateful for the help I received on this list to understand the
> > technologies.
> >
> > I do not currently have a blog to post this research and so was thinking
> > of posting it to this list so that it could be archived and searchable
> > for other poor sysadmin types like me to save them the days of
> > struggling to get their practical heads around the concepts.
> >
> > However, since this is probably a 15 page or so document, I realized
> > this could be quite rude to those on dial up or metered connections.
> > Would it be appropriate to post my summary here? Thanks - John
> >
>
> Please post here, thats definitely a good idea.
>
> I am pretty sure your contribution could serve to add a page to
>
> http://www.linuxfoundation.org/collaborate/workgroups/networking/group
>
> I believe we lack documentation. A lot.
<snip>
Well . . . it's finally done but, it required so many non-ascii graphics
that it turned into a 25 page PDF. Would that be appropriate to post to
this list? I don't know if it allows attachments?
Would it be considered rude to cross post it to the new LARTC list?
Also, if it is of any help, I have a far less structured document - 12
pages of my notes on building a test WAN environment with IFB, HFSC, and
netem. If that is of any interest, I can post that, too. I do not want
to be presumptuous and they are far from perfect but I also know how
much I struggled to find documentation. Thanks - John
^ permalink raw reply
* [PATCH] netem: dont call vfree() under spinlock and BH disabled
From: Eric Dumazet @ 2011-12-24 5:28 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Stephen Hemminger
commit 6373a9a286 (netem: use vmalloc for distribution table) added a
regression, since vfree() is called while holding a spinlock and BH
being disabled.
Fix this by doing the pointers swap in critical section, and freeing
after spinlock release.
Also add __GFP_NOWARN to the kmalloc() try, since we fallback to
vmalloc().
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/sched/sch_netem.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/sched/sch_netem.c b/net/sched/sch_netem.c
index eb3b9a8..a4ab207 100644
--- a/net/sched/sch_netem.c
+++ b/net/sched/sch_netem.c
@@ -488,7 +488,7 @@ static int get_dist_table(struct Qdisc *sch, const struct nlattr *attr)
return -EINVAL;
s = sizeof(struct disttable) + n * sizeof(s16);
- d = kmalloc(s, GFP_KERNEL);
+ d = kmalloc(s, GFP_KERNEL | __GFP_NOWARN);
if (!d)
d = vmalloc(s);
if (!d)
@@ -501,9 +501,10 @@ static int get_dist_table(struct Qdisc *sch, const struct nlattr *attr)
root_lock = qdisc_root_sleeping_lock(sch);
spin_lock_bh(root_lock);
- dist_free(q->delay_dist);
- q->delay_dist = d;
+ swap(q->delay_dist, d);
spin_unlock_bh(root_lock);
+
+ dist_free(d);
return 0;
}
^ permalink raw reply related
* Re: [PATCH] Micrel KS8995MA 5-ports 10/100 managed Ethernet switch support added
From: Frederic LAMBERT @ 2011-12-24 8:44 UTC (permalink / raw)
To: netdev; +Cc: Gabor Juhos
In-Reply-To: <1324229621-2054-1-git-send-email-frdrc66@gmail.com>
Hi,
Is something still wrong with this driver or is it acceptable in this
state, now?
2011/12/18 Frederic LAMBERT <frdrc66@gmail.com>
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
> Signed-off-by: Frederic Lambert <frdrc66@gmail.com>
> ---
> drivers/net/phy/Kconfig | 5 +
> drivers/net/phy/Makefile | 1 +
> drivers/net/phy/spi_ks8995.c | 376 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 382 insertions(+), 0 deletions(-)
> create mode 100644 drivers/net/phy/spi_ks8995.c
>
> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> index a702443..050f069 100644
> --- a/drivers/net/phy/Kconfig
> +++ b/drivers/net/phy/Kconfig
> @@ -131,3 +131,8 @@ config MDIO_OCTEON
> If in doubt, say Y.
>
> endif # PHYLIB
> +
> +config MICREL_KS8995MA
> + tristate "Micrel KS8995MA 5-ports 10/100 managed Ethernet switch"
> + depends on SPI
> +
> diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
> index 2333215..e15c83f 100644
> --- a/drivers/net/phy/Makefile
> +++ b/drivers/net/phy/Makefile
> @@ -23,3 +23,4 @@ obj-$(CONFIG_DP83640_PHY) += dp83640.o
> obj-$(CONFIG_STE10XP) += ste10Xp.o
> obj-$(CONFIG_MICREL_PHY) += micrel.o
> obj-$(CONFIG_MDIO_OCTEON) += mdio-octeon.o
> +obj-$(CONFIG_MICREL_KS8995MA) += spi_ks8995.o
> diff --git a/drivers/net/phy/spi_ks8995.c b/drivers/net/phy/spi_ks8995.c
> new file mode 100644
> index 0000000..e9ce085
> --- /dev/null
> +++ b/drivers/net/phy/spi_ks8995.c
> @@ -0,0 +1,376 @@
> +/*
> + * SPI driver for Micrel/Kendin KS8995M ethernet switch
> + *
> + * Copyright (C) 2008 Gabor Juhos <juhosg at openwrt.org>
> + *
> + * This file was based on: drivers/spi/at25.c
> + * Copyright (C) 2006 David Brownell
> + *
> + * 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/types.h>
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/module.h>
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +
> +#include <linux/spi/spi.h>
> +
> +#define DRV_VERSION "0.1.1"
> +#define DRV_DESC "Micrel KS8995 Ethernet switch SPI driver"
> +
> +/* ------------------------------------------------------------------------ */
> +
> +#define KS8995_REG_ID0 0x00 /* Chip ID0 */
> +#define KS8995_REG_ID1 0x01 /* Chip ID1 */
> +
> +#define KS8995_REG_GC0 0x02 /* Global Control 0 */
> +#define KS8995_REG_GC1 0x03 /* Global Control 1 */
> +#define KS8995_REG_GC2 0x04 /* Global Control 2 */
> +#define KS8995_REG_GC3 0x05 /* Global Control 3 */
> +#define KS8995_REG_GC4 0x06 /* Global Control 4 */
> +#define KS8995_REG_GC5 0x07 /* Global Control 5 */
> +#define KS8995_REG_GC6 0x08 /* Global Control 6 */
> +#define KS8995_REG_GC7 0x09 /* Global Control 7 */
> +#define KS8995_REG_GC8 0x0a /* Global Control 8 */
> +#define KS8995_REG_GC9 0x0b /* Global Control 9 */
> +
> +#define KS8995_REG_PC(p, r) ((0x10 * p) + r) /* Port Control */
> +#define KS8995_REG_PS(p, r) ((0x10 * p) + r + 0xe) /* Port Status */
> +
> +#define KS8995_REG_TPC0 0x60 /* TOS Priority Control 0 */
> +#define KS8995_REG_TPC1 0x61 /* TOS Priority Control 1 */
> +#define KS8995_REG_TPC2 0x62 /* TOS Priority Control 2 */
> +#define KS8995_REG_TPC3 0x63 /* TOS Priority Control 3 */
> +#define KS8995_REG_TPC4 0x64 /* TOS Priority Control 4 */
> +#define KS8995_REG_TPC5 0x65 /* TOS Priority Control 5 */
> +#define KS8995_REG_TPC6 0x66 /* TOS Priority Control 6 */
> +#define KS8995_REG_TPC7 0x67 /* TOS Priority Control 7 */
> +
> +#define KS8995_REG_MAC0 0x68 /* MAC address 0 */
> +#define KS8995_REG_MAC1 0x69 /* MAC address 1 */
> +#define KS8995_REG_MAC2 0x6a /* MAC address 2 */
> +#define KS8995_REG_MAC3 0x6b /* MAC address 3 */
> +#define KS8995_REG_MAC4 0x6c /* MAC address 4 */
> +#define KS8995_REG_MAC5 0x6d /* MAC address 5 */
> +
> +#define KS8995_REG_IAC0 0x6e /* Indirect Access Control 0 */
> +#define KS8995_REG_IAC1 0x6f /* Indirect Access Control 0 */
> +#define KS8995_REG_IAD7 0x70 /* Indirect Access Data 7 */
> +#define KS8995_REG_IAD6 0x71 /* Indirect Access Data 6 */
> +#define KS8995_REG_IAD5 0x72 /* Indirect Access Data 5 */
> +#define KS8995_REG_IAD4 0x73 /* Indirect Access Data 4 */
> +#define KS8995_REG_IAD3 0x74 /* Indirect Access Data 3 */
> +#define KS8995_REG_IAD2 0x75 /* Indirect Access Data 2 */
> +#define KS8995_REG_IAD1 0x76 /* Indirect Access Data 1 */
> +#define KS8995_REG_IAD0 0x77 /* Indirect Access Data 0 */
> +
> +#define KS8995_REGS_SIZE 0x80
> +
> +#define ID1_CHIPID_M 0xf
> +#define ID1_CHIPID_S 4
> +#define ID1_REVISION_M 0x7
> +#define ID1_REVISION_S 1
> +#define ID1_START_SW 1 /* start the switch */
> +
> +#define FAMILY_KS8995 0x95
> +#define CHIPID_M 0
> +
> +#define KS8995_CMD_WRITE 0x02U
> +#define KS8995_CMD_READ 0x03U
> +
> +#define KS8995_RESET_DELAY 10 /* usec */
> +
> +struct ks8995_pdata {
> + /* not yet implemented */
> +};
> +
> +struct ks8995_switch {
> + struct spi_device *spi;
> + struct mutex lock;
> + struct ks8995_pdata *pdata;
> +};
> +
> +static inline u8 get_chip_id(u8 val)
> +{
> + return (val >> ID1_CHIPID_S) & ID1_CHIPID_M;
> +}
> +
> +static inline u8 get_chip_rev(u8 val)
> +{
> + return (val >> ID1_REVISION_S) & ID1_REVISION_M;
> +}
> +
> +/* ------------------------------------------------------------------------ */
> +static int ks8995_read(struct ks8995_switch *ks, char *buf,
> + unsigned offset, size_t count)
> +{
> + u8 cmd[2];
> + struct spi_transfer t[2];
> + struct spi_message m;
> + int err;
> +
> + spi_message_init(&m);
> +
> + memset(&t, 0, sizeof(t));
> +
> + t[0].tx_buf = cmd;
> + t[0].len = sizeof(cmd);
> + spi_message_add_tail(&t[0], &m);
> +
> + t[1].rx_buf = buf;
> + t[1].len = count;
> + spi_message_add_tail(&t[1], &m);
> +
> + cmd[0] = KS8995_CMD_READ;
> + cmd[1] = offset;
> +
> + mutex_lock(&ks->lock);
> + err = spi_sync(ks->spi, &m);
> + mutex_unlock(&ks->lock);
> +
> + return err ? err : count;
> +}
> +
> +
> +static int ks8995_write(struct ks8995_switch *ks, char *buf,
> + unsigned offset, size_t count)
> +{
> + u8 cmd[2];
> + struct spi_transfer t[2];
> + struct spi_message m;
> + int err;
> +
> + spi_message_init(&m);
> +
> + memset(&t, 0, sizeof(t));
> +
> + t[0].tx_buf = cmd;
> + t[0].len = sizeof(cmd);
> + spi_message_add_tail(&t[0], &m);
> +
> + t[1].tx_buf = buf;
> + t[1].len = count;
> + spi_message_add_tail(&t[1], &m);
> +
> + cmd[0] = KS8995_CMD_WRITE;
> + cmd[1] = offset;
> +
> + mutex_lock(&ks->lock);
> + err = spi_sync(ks->spi, &m);
> + mutex_unlock(&ks->lock);
> +
> + return err ? err : count;
> +}
> +
> +static inline int ks8995_read_reg(struct ks8995_switch *ks, u8 addr, u8 *buf)
> +{
> + return (ks8995_read(ks, buf, addr, 1) != 1);
> +}
> +
> +static inline int ks8995_write_reg(struct ks8995_switch *ks, u8 addr, u8 val)
> +{
> + char buf = val;
> +
> + return (ks8995_write(ks, &buf, addr, 1) != 1);
> +}
> +
> +/* ------------------------------------------------------------------------ */
> +
> +static int ks8995_stop(struct ks8995_switch *ks)
> +{
> + return ks8995_write_reg(ks, KS8995_REG_ID1, 0);
> +}
> +
> +static int ks8995_start(struct ks8995_switch *ks)
> +{
> + return ks8995_write_reg(ks, KS8995_REG_ID1, 1);
> +}
> +
> +static int ks8995_reset(struct ks8995_switch *ks)
> +{
> + int err;
> +
> + err = ks8995_stop(ks);
> + if (err)
> + return err;
> +
> + udelay(KS8995_RESET_DELAY);
> +
> + return ks8995_start(ks);
> +}
> +
> +/* ------------------------------------------------------------------------ */
> +
> +static ssize_t ks8995_registers_read(struct file *filp, struct kobject *kobj,
> + struct bin_attribute *bin_attr, char *buf, loff_t off, size_t count)
> +{
> + struct device *dev;
> + struct ks8995_switch *ks8995;
> +
> + dev = container_of(kobj, struct device, kobj);
> + ks8995 = dev_get_drvdata(dev);
> +
> + if (unlikely(off > KS8995_REGS_SIZE))
> + return 0;
> +
> + if ((off + count) > KS8995_REGS_SIZE)
> + count = KS8995_REGS_SIZE - off;
> +
> + if (unlikely(!count))
> + return count;
> +
> + return ks8995_read(ks8995, buf, off, count);
> +}
> +
> +
> +static ssize_t ks8995_registers_write(struct file *filp, struct kobject *kobj,
> + struct bin_attribute *bin_attr, char *buf, loff_t off, size_t count)
> +{
> + struct device *dev;
> + struct ks8995_switch *ks8995;
> +
> + dev = container_of(kobj, struct device, kobj);
> + ks8995 = dev_get_drvdata(dev);
> +
> + if (unlikely(off >= KS8995_REGS_SIZE))
> + return -EFBIG;
> +
> + if ((off + count) > KS8995_REGS_SIZE)
> + count = KS8995_REGS_SIZE - off;
> +
> + if (unlikely(!count))
> + return count;
> +
> + return ks8995_write(ks8995, buf, off, count);
> +}
> +
> +
> +static struct bin_attribute ks8995_registers_attr = {
> + .attr = {
> + .name = "registers",
> + .mode = S_IRUSR | S_IWUSR,
> + },
> + .size = KS8995_REGS_SIZE,
> + .read = ks8995_registers_read,
> + .write = ks8995_registers_write,
> +};
> +
> +/* ------------------------------------------------------------------------ */
> +
> +static int __devinit ks8995_probe(struct spi_device *spi)
> +{
> + struct ks8995_switch *ks;
> + struct ks8995_pdata *pdata;
> + u8 ids[2];
> + int err;
> +
> + /* Chip description */
> + pdata = spi->dev.platform_data;
> +
> + ks = kzalloc(sizeof(*ks), GFP_KERNEL);
> + if (!ks) {
> + dev_err(&spi->dev, "no memory for private data\n");
> + return -ENOMEM;
> + }
> +
> + mutex_init(&ks->lock);
> + ks->pdata = pdata;
> + ks->spi = spi_dev_get(spi);
> + dev_set_drvdata(&spi->dev, ks);
> +
> + spi->mode = SPI_MODE_0;
> + spi->bits_per_word = 8;
> + err = spi_setup(spi);
> + if (err) {
> + dev_err(&spi->dev, "spi_setup failed, err=%d\n", err);
> + goto err_drvdata;
> + }
> +
> + err = ks8995_read(ks, ids, KS8995_REG_ID0, sizeof(ids));
> + if (err < 0) {
> + dev_err(&spi->dev, "unable to read id registers, err=%d\n",
> + err);
> + goto err_drvdata;
> + }
> +
> + switch (ids[0]) {
> + case FAMILY_KS8995:
> + break;
> + default:
> + dev_err(&spi->dev, "unknown family id:%02x\n", ids[0]);
> + err = -ENODEV;
> + goto err_drvdata;
> + }
> +
> + err = ks8995_reset(ks);
> + if (err)
> + goto err_drvdata;
> +
> + err = sysfs_create_bin_file(&spi->dev.kobj, &ks8995_registers_attr);
> + if (err) {
> + dev_err(&spi->dev, "unable to create sysfs file, err=%d\n",
> + err);
> + goto err_drvdata;
> + }
> +
> + dev_info(&spi->dev, "KS89%02X device found, Chip ID:%01x, "
> + "Revision:%01x\n", ids[0],
> + get_chip_id(ids[1]), get_chip_rev(ids[1]));
> +
> + return 0;
> +
> +err_drvdata:
> + dev_set_drvdata(&spi->dev, NULL);
> + kfree(ks);
> + return err;
> +}
> +
> +static int __devexit ks8995_remove(struct spi_device *spi)
> +{
> + struct ks8995_data *ks8995;
> +
> + ks8995 = dev_get_drvdata(&spi->dev);
> + sysfs_remove_bin_file(&spi->dev.kobj, &ks8995_registers_attr);
> +
> + dev_set_drvdata(&spi->dev, NULL);
> + kfree(ks8995);
> +
> + return 0;
> +}
> +
> +/* ------------------------------------------------------------------------ */
> +
> +static struct spi_driver ks8995_driver = {
> + .driver = {
> + .name = "spi-ks8995",
> + .bus = &spi_bus_type,
> + .owner = THIS_MODULE,
> + },
> + .probe = ks8995_probe,
> + .remove = __devexit_p(ks8995_remove),
> +};
> +
> +static int __init ks8995_init(void)
> +{
> + printk(KERN_INFO DRV_DESC " version " DRV_VERSION"\n");
> +
> + return spi_register_driver(&ks8995_driver);
> +}
> +module_init(ks8995_init);
> +
> +static void __exit ks8995_exit(void)
> +{
> + spi_unregister_driver(&ks8995_driver);
> +}
> +module_exit(ks8995_exit);
> +
> +MODULE_DESCRIPTION(DRV_DESC);
> +MODULE_VERSION(DRV_VERSION);
> +MODULE_AUTHOR("Gabor Juhos <juhosg at openwrt.org>");
> +MODULE_LICENSE("GPL v2");
> +
> --
> 1.7.4.1
>
BR,
--
Fred
^ permalink raw reply
* RE: [PATCH 1/2] bna: Added flash sub-module and ethtool eeprom entry points.
From: Ben Hutchings @ 2011-12-24 10:08 UTC (permalink / raw)
To: Krishna Gudipati
Cc: 'davem@davemloft.net', 'netdev@vger.kernel.org',
Adapter Linux Open SRC Team, Rasesh Mody
In-Reply-To: <B5EE62D80D50B84BB9E5174F7FCCE80A206BE39A24@HQ1-EXCH02.corp.brocade.com>
On Fri, 2011-12-23 at 07:09 -0800, Krishna Gudipati wrote:
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On Behalf Of Ben Hutchings
> Sent: Friday, December 23, 2011 1:44 AM
> To: Krishna Gudipati
> Cc: davem@davemloft.net; netdev@vger.kernel.org; Adapter Linux Open SRC Team; Rasesh Mody
> Subject: Re: [PATCH 1/2] bna: Added flash sub-module and ethtool eeprom entry points.
>
> On Thu, 2011-12-22 at 15:29 -0800, kgudipat@brocade.com wrote:
> > From: Krishna Gudipati <kgudipat@brocade.com>
> >
> > Change details:
> > - The patch adds flash sub-module to the bna driver.
> > - Added ethtool set_eeprom() and get_eeprom() entry points to
> > support flash partition read/write operations.
> [...]
>
> I'm not going to say this is wrong, but we didn't find the EEPROM
> operations suitable for firmware upgrade. I have a couple of questions:
>
> 1. How long can a single set_eeprom() operation take?
> 2. Have you considered implementing the flash_device() operation or an
> MTD driver?
>
> -----
>
> Thanks Ben for reviewing.
>
> For 1: Considering the max size of the flash image chunk passed to the set_eeprom() entry point
> at a time is 4Kbytes, it takes a little around ~3min for the firmware upgrade as the
> operation involves a flash write for each 4Kbytes of the total 461Kbytes which is our fwimg size.
I asked how long a single call would take, because the RTNL lock will be
held for this time. Presumably it doesn't take very long to write a 4K
chunk, so this shouldn't be a problem.
> Please note that we use the same entry point to do flash update for other flash partitions as well,
> for which the flash image size is much lesser than the firmware image.
>
> For 2: No, we noticed that flash_device() entry point is listed as obsolete in the RHEL6.2 kernel source,
> so we did not want to implement using it.
I don't know what makes you think it's obsolete. It was actually added
recently, so it's not present in RHEL 6.2 (based on Linux 2.6.32).
If you're concerned about how to support this in backports to older
kernel versions, MTD has been around for a very long time and is
available in basically every distribution kernel (but with some
limitations).
Ben.
--
Ben Hutchings, Staff 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: [net-next 8/9] ixgbe: add interface to export thermal data
From: Ben Hutchings @ 2011-12-24 10:22 UTC (permalink / raw)
To: Michał Mirosław
Cc: Jeff Kirsher, davem, Don Skidmore, netdev, gospo, sassmann,
Peter P Waskiewicz Jr
In-Reply-To: <CAHXqBFL_44T5nQVA=n03aT9Q1QpsLCY2dn9o6GE-9Rm66DSt-A@mail.gmail.com>
On Fri, 2011-12-23 at 18:58 +0100, Michał Mirosław wrote:
> 2011/12/23 Jeff Kirsher <jeffrey.t.kirsher@intel.com>:
> > From: Don Skidmore <donald.c.skidmore@intel.com>
> >
> > Some of our adapters have thermal data available, this patch exports this
> > data via a read-only sysfs interface.
>
> Just curious: can't this use the hwmon subsystem to be consistent with
> other system monitoring devices?
That would certainly be the proper way to expose this...
Ben.
--
Ben Hutchings, Staff 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: tcp_mtu_probe implementation details
From: John Heffner @ 2011-12-24 15:03 UTC (permalink / raw)
To: Anatoly Sivov; +Cc: netdev
In-Reply-To: <op.v6t2ygnyfzo5me@stalin>
TCP doesn't operate as well with a small window, and below some point
there isn't really a justification for increasing the MTU size. 11 is
something of a magic number, but here's the reasoning:
A cwnd of 11 pre-probe will result in a cwnd of 6 after a successful
probe. (By the time the probe succeeds, cwnd will have been increased
to 12, then doubling MSS will halve cwnd to 6.) A window size smaller
than this makes TCP more vulnerable to double loss events and
increases the likeliness of timeouts.
-John
2011/12/21 Anatoly Sivov <mm05@mail.ru>:
> Hello Vijay,
>
> Thank you for your response.
>
>
>>> The other question is about size_needed variable.
>>> It is assigned to value probe_size + (tp->reordering + 1) * tp->mss_cache
>>> And that is not clear for me.
>>> What is this "(tp->reordering + 1) * tp->mss_cache" addition?
>>>
>>
>> I think the idea is that you want enough bytes in the write_queue so
>> that even if the probe is lost, the sender will get an ack even if
>> there is reordering in the network. Without sufficient bytes, the
>> probe will not be sent. This is what I make of the code but I could be
>> wrong.
>
>
> I believe, I found the explanation of this addition in RFC 4821:
> "TCP Fast Retransmit is not robust unless there are
> sufficient segments following a probe; that is, the sender SHOULD
> have enough data queued and sufficient receiver window to send the
> probe plus at least Tcprexmtthresh [RFC2760] additional segments."
>
> However, I'm still confused with magic number 11 in "tp->snd_cwnd < 11"
> check.
>
> Thanks.
>
> --
> 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: tcp_mtu_probe implementation details
From: Anatoly Sivov @ 2011-12-24 16:15 UTC (permalink / raw)
To: John Heffner; +Cc: netdev
In-Reply-To: <CABrhC0mhuY75Y0Q_dkkPMH4si1OinM3bvpK_cHhOwQRpAAFu2A@mail.gmail.com>
Hello John,
Thanks for clarifications.
> A cwnd of 11 pre-probe will result in a cwnd of 6 after a successful
> probe. (By the time the probe succeeds, cwnd will have been increased
> to 12, then doubling MSS will halve cwnd to 6.) A window size smaller
> than this makes TCP more vulnerable to double loss events and
> increases the likeliness of timeouts.
Perhaps, it's worth of being mentioned in comment inside of tcp_mtu_probe.
^ permalink raw reply
* [PATCH net-next] rfs: better sizing of dev_flow_table
From: Eric Dumazet @ 2011-12-24 16:56 UTC (permalink / raw)
To: David Miller; +Cc: Tom Herbert, netdev, Laurent Chavey, Xi Wang
In-Reply-To: <C6E2C6E1-A4DA-45F8-A94F-D3B78AFA018F@gmail.com>
Aim of this patch is to provide full range of rps_flow_cnt on 64bit arches.
Theorical limit on number of flows is 2^32
Fix some buggy RPS/RFS macros as well.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Tom Herbert <therbert@google.com>
CC: Xi Wang <xi.wang@gmail.com>
CC: Laurent Chavey <chavey@google.com>
---
include/linux/netdevice.h | 8 +++---
net/core/net-sysfs.c | 44 ++++++++++++++++++++++--------------
2 files changed, 31 insertions(+), 21 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 6037308..a776a67 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -597,7 +597,7 @@ struct rps_map {
struct rcu_head rcu;
u16 cpus[0];
};
-#define RPS_MAP_SIZE(_num) (sizeof(struct rps_map) + (_num * sizeof(u16)))
+#define RPS_MAP_SIZE(_num) (sizeof(struct rps_map) + ((_num) * sizeof(u16)))
/*
* The rps_dev_flow structure contains the mapping of a flow to a CPU, the
@@ -621,7 +621,7 @@ struct rps_dev_flow_table {
struct rps_dev_flow flows[0];
};
#define RPS_DEV_FLOW_TABLE_SIZE(_num) (sizeof(struct rps_dev_flow_table) + \
- (_num * sizeof(struct rps_dev_flow)))
+ ((_num) * sizeof(struct rps_dev_flow)))
/*
* The rps_sock_flow_table contains mappings of flows to the last CPU
@@ -632,7 +632,7 @@ struct rps_sock_flow_table {
u16 ents[0];
};
#define RPS_SOCK_FLOW_TABLE_SIZE(_num) (sizeof(struct rps_sock_flow_table) + \
- (_num * sizeof(u16)))
+ ((_num) * sizeof(u16)))
#define RPS_NO_CPU 0xffff
@@ -684,7 +684,7 @@ struct xps_map {
struct rcu_head rcu;
u16 queues[0];
};
-#define XPS_MAP_SIZE(_num) (sizeof(struct xps_map) + (_num * sizeof(u16)))
+#define XPS_MAP_SIZE(_num) (sizeof(struct xps_map) + ((_num) * sizeof(u16)))
#define XPS_MIN_MAP_ALLOC ((L1_CACHE_BYTES - sizeof(struct xps_map)) \
/ sizeof(u16))
diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index 4b4d0b0..abf4393 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -622,15 +622,15 @@ static ssize_t show_rps_dev_flow_table_cnt(struct netdev_rx_queue *queue,
char *buf)
{
struct rps_dev_flow_table *flow_table;
- unsigned int val = 0;
+ unsigned long val = 0;
rcu_read_lock();
flow_table = rcu_dereference(queue->rps_flow_table);
if (flow_table)
- val = flow_table->mask + 1;
+ val = (unsigned long)flow_table->mask + 1;
rcu_read_unlock();
- return sprintf(buf, "%u\n", val);
+ return sprintf(buf, "%lu\n", val);
}
static void rps_dev_flow_table_release_work(struct work_struct *work)
@@ -654,36 +654,46 @@ static ssize_t store_rps_dev_flow_table_cnt(struct netdev_rx_queue *queue,
struct rx_queue_attribute *attr,
const char *buf, size_t len)
{
- unsigned int count;
- char *endp;
+ unsigned long mask, count;
struct rps_dev_flow_table *table, *old_table;
static DEFINE_SPINLOCK(rps_dev_flow_lock);
+ int rc;
if (!capable(CAP_NET_ADMIN))
return -EPERM;
- count = simple_strtoul(buf, &endp, 0);
- if (endp == buf)
- return -EINVAL;
+ rc = kstrtoul(buf, 0, &count);
+ if (rc < 0)
+ return rc;
if (count) {
- int i;
-
- if (count > INT_MAX)
+ mask = count - 1;
+ /* mask = roundup_pow_of_two(count) - 1;
+ * without overflows...
+ */
+ while ((mask | (mask >> 1)) != mask)
+ mask |= (mask >> 1);
+ /* On 64 bit arches, must check mask fits in table->mask (u32),
+ * and on 32bit arches, must check RPS_DEV_FLOW_TABLE_SIZE(mask + 1)
+ * doesnt overflow.
+ */
+#if BITS_PER_LONG > 32
+ if (mask > (unsigned long)(u32)mask)
return -EINVAL;
- count = roundup_pow_of_two(count);
- if (count > (ULONG_MAX - sizeof(struct rps_dev_flow_table))
+#else
+ if (mask > (ULONG_MAX - RPS_DEV_FLOW_TABLE_SIZE(1))
/ sizeof(struct rps_dev_flow)) {
/* Enforce a limit to prevent overflow */
return -EINVAL;
}
- table = vmalloc(RPS_DEV_FLOW_TABLE_SIZE(count));
+#endif
+ table = vmalloc(RPS_DEV_FLOW_TABLE_SIZE(mask + 1));
if (!table)
return -ENOMEM;
- table->mask = count - 1;
- for (i = 0; i < count; i++)
- table->flows[i].cpu = RPS_NO_CPU;
+ table->mask = mask;
+ for (count = 0; count <= mask; count++)
+ table->flows[count].cpu = RPS_NO_CPU;
} else
table = NULL;
^ permalink raw reply related
* route classifiers and mirred actions
From: John A. Sullivan III @ 2011-12-24 17:47 UTC (permalink / raw)
To: netdev
Hello, all. I may have a workaround for the problem we have using netem
with ingress filters but I have hit a roadblock in implementing it. It
appears I cannot use an action with a route classifier. Specifically:
root@testswitch01:~# tc filter add dev eth0 parent ffff: protocol ip prio 50 route fromif eth1 action mirred egress redirect dev ifb1
What is "action"?
Usage: ... route [ from REALM | fromif TAG ] [ to REALM ]
[ flowid CLASSID ] [ police POLICE_SPEC ]
POLICE_SPEC := ... look at TBF
CLASSID := X:Y
NOTE: CLASSID is parsed as hexadecimal input.
root@testswitch01:~# tc action add action mirred help
Usage: mirred <DIRECTION> <ACTION> [index INDEX] <dev DEVICENAME>
where:
DIRECTION := <ingress | egress>
ACTION := <mirror | redirect>
INDEX is the specific policy instance id
DEVICENAME is the devicename
Yet, this works:
root@testswitch01:~# tc filter add dev eth0 parent ffff: protocol ip prio 50 u32 match u32 0 0 action mirred egress redirect dev ifb1
and this works:
root@testswitch01:~# tc filter add dev eth0 parent ffff: protocol ip prio 1 route fromif eth1 classid 1:10
So why does the u32 classifier work with actions, the route classifier
work with classids, but the route classifier does not work with actions?
Thanks - John
^ permalink raw reply
* [PATCH 0/2] late fixes for netfilter's ctnetlink
From: pablo @ 2011-12-24 18:52 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
From: Pablo Neira Ayuso <pablo@netfilter.org>
Hi Dave,
These are a couple of late fixes for ctnetlink.
You can pull them from:
git://1984.lsi.us.es/net nf
Please, apply!
Thanks.
Pablo Neira Ayuso (2):
netfilter: ctnetlink: fix return value of ctnetlink_get_expect()
netfilter: ctnetlink: fix scheduling while atomic if helper is
autoloaded
net/netfilter/nf_conntrack_netlink.c | 18 +++++++++++++-----
1 files changed, 13 insertions(+), 5 deletions(-)
--
1.7.2.5
^ permalink raw reply
* [PATCH 1/2] netfilter: ctnetlink: fix return value of ctnetlink_get_expect()
From: pablo @ 2011-12-24 18:52 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1324752768-5853-1-git-send-email-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
This fixes one bogus error that is returned to user-space:
libnetfilter_conntrack/utils# ./expect_get
TEST: get expectation (-1)(Unknown error 18446744073709551504)
This patch includes the correct handling for EAGAIN (nfnetlink
uses this error value to restart the operation after module
auto-loading).
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nf_conntrack_netlink.c | 15 ++++++++++-----
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c
index ef21b22..3d7ea7a 100644
--- a/net/netfilter/nf_conntrack_netlink.c
+++ b/net/netfilter/nf_conntrack_netlink.c
@@ -1869,25 +1869,30 @@ ctnetlink_get_expect(struct sock *ctnl, struct sk_buff *skb,
err = -ENOMEM;
skb2 = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
- if (skb2 == NULL)
+ if (skb2 == NULL) {
+ nf_ct_expect_put(exp);
goto out;
+ }
rcu_read_lock();
err = ctnetlink_exp_fill_info(skb2, NETLINK_CB(skb).pid,
nlh->nlmsg_seq, IPCTNL_MSG_EXP_NEW, exp);
rcu_read_unlock();
+ nf_ct_expect_put(exp);
if (err <= 0)
goto free;
- nf_ct_expect_put(exp);
+ err = netlink_unicast(ctnl, skb2, NETLINK_CB(skb).pid, MSG_DONTWAIT);
+ if (err < 0)
+ goto out;
- return netlink_unicast(ctnl, skb2, NETLINK_CB(skb).pid, MSG_DONTWAIT);
+ return 0;
free:
kfree_skb(skb2);
out:
- nf_ct_expect_put(exp);
- return err;
+ /* this avoids a loop in nfnetlink. */
+ return err == -EAGAIN ? -ENOBUFS : err;
}
static int
--
1.7.2.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox