* Re: [PATCH 3.8-rc] net: mvneta: fix driver operation in SMP context
From: Ben Hutchings @ 2013-01-07 16:53 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: David S. Miller, netdev, Jason Cooper, Andrew Lunn,
Gregory Clement, linux-arm-kernel, Lior Amsalem, Maen Suleiman,
Dmitri Epshtein
In-Reply-To: <1357576074-24245-1-git-send-email-thomas.petazzoni@free-electrons.com>
On Mon, 2013-01-07 at 17:27 +0100, Thomas Petazzoni wrote:
> From: Dmitri Epshtein <dima@marvell.com>
>
> In order for the driver to behave properly in a SMP context, the same
> transmit queue should be used by the kernel in dev_queue_xmit() and in
> the driver's mvneta_tx() function. To achieve that, the driver now
> implements the ->ndo_select_txq() operation.
>
> For now, it always returns the same transmit queue, txq_def, until the
> driver is expanded to properly take advantage of the multiqueue
> capabilities of the hardware.
[...]
Well it looks like the driver already sets up multiple TX queues, and
you just need to call skb_get_queue_mapping(skb) to look up the TX queue
in mvneta_tx().
Also since the numbers of queues are variable you should be calling
alloc_etherdev_mqs(sizeof(struct mvneta_port), txq_number, rxq_number)
instead of alloc_etherdev_mq(..., 8) in mvneta_probe().
If for some reason the current hardware initialisation doesn't actually
work for more than 1 TX queue then change the number you pass to
alloc_etherdev_mqs().
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: [PATCH 3.8-rc] net: mvneta: fix driver operation in SMP context
From: Gregory CLEMENT @ 2013-01-07 17:14 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: David S. Miller, Lior Amsalem, Andrew Lunn, Jason Cooper, netdev,
Maen Suleiman, Dmitri Epshtein, linux-arm-kernel
In-Reply-To: <1357576074-24245-1-git-send-email-thomas.petazzoni@free-electrons.com>
On 01/07/2013 05:27 PM, Thomas Petazzoni wrote:
> From: Dmitri Epshtein <dima@marvell.com>
>
> In order for the driver to behave properly in a SMP context, the same
> transmit queue should be used by the kernel in dev_queue_xmit() and in
> the driver's mvneta_tx() function. To achieve that, the driver now
> implements the ->ndo_select_txq() operation.
>
> For now, it always returns the same transmit queue, txq_def, until the
> driver is expanded to properly take advantage of the multiqueue
> capabilities of the hardware.
>
> Without this patch, the network driver crashes the kernel almost
> immediately on Armada XP platforms, if the network load is at least a
> little bit parallel (i.e several threads).
>
> [Thomas Petazzoni: reword commit message]
> Signed-off-by: Dmitri Epshtein <dima@marvell.com>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
I have tested this patch on my Armada XP DB board and on the
OpenBlocks AX3 board. I confirmed that it fixes the problem when
multiple thread are used.
You can add my
Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
and also my
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Or a combination of the two if you prefer!
> ---
> This is 3.8-rc material.
> ---
> drivers/net/ethernet/marvell/mvneta.c | 17 +++++++++++++++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
> index b6025c3..af2c421 100644
> --- a/drivers/net/ethernet/marvell/mvneta.c
> +++ b/drivers/net/ethernet/marvell/mvneta.c
> @@ -1310,6 +1310,17 @@ static u32 mvneta_skb_tx_csum(struct mvneta_port *pp, struct sk_buff *skb)
> return MVNETA_TX_L4_CSUM_NOT;
> }
>
> +static u16 mvneta_tx_policy(struct mvneta_port *pp, struct sk_buff *skb)
> +{
> + return (u16)txq_def;
> +}
> +
> +static u16 mvneta_select_txq(struct net_device *dev, struct sk_buff *skb)
> +{
> + struct mvneta_port *pp = netdev_priv(dev);
> + return mvneta_tx_policy(pp, skb);
> +}
> +
> /* Returns rx queue pointer (find last set bit) according to causeRxTx
> * value
> */
> @@ -1476,7 +1487,8 @@ error:
> static int mvneta_tx(struct sk_buff *skb, struct net_device *dev)
> {
> struct mvneta_port *pp = netdev_priv(dev);
> - struct mvneta_tx_queue *txq = &pp->txqs[txq_def];
> + u16 txq_id = mvneta_tx_policy(pp, skb);
> + struct mvneta_tx_queue *txq = &pp->txqs[txq_id];
> struct mvneta_tx_desc *tx_desc;
> struct netdev_queue *nq;
> int frags = 0;
> @@ -1486,7 +1498,7 @@ static int mvneta_tx(struct sk_buff *skb, struct net_device *dev)
> goto out;
>
> frags = skb_shinfo(skb)->nr_frags + 1;
> - nq = netdev_get_tx_queue(dev, txq_def);
> + nq = netdev_get_tx_queue(dev, txq_id);
>
> /* Get a descriptor for the first part of the packet */
> tx_desc = mvneta_txq_next_desc_get(txq);
> @@ -2550,6 +2562,7 @@ static const struct net_device_ops mvneta_netdev_ops = {
> .ndo_change_mtu = mvneta_change_mtu,
> .ndo_tx_timeout = mvneta_tx_timeout,
> .ndo_get_stats64 = mvneta_get_stats64,
> + .ndo_select_queue = mvneta_select_txq,
> };
>
> const struct ethtool_ops mvneta_eth_tool_ops = {
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH repost] net,wireless: check against default_ethtool_ops
From: Michał Mirosław @ 2013-01-07 17:20 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: netdev, David S. Miller, Eric Dumazet, Ben Greear,
Bjørn Mork, linux-wireless, Ben Hutchings
In-Reply-To: <20130107095548.GA6931@redhat.com>
2013/1/7 Stanislaw Gruszka <sgruszka@redhat.com>:
> Since:
>
> commit 2c60db037034d27f8c636403355d52872da92f81
> Author: Eric Dumazet <edumazet@google.com>
> Date: Sun Sep 16 09:17:26 2012 +0000
>
> net: provide a default dev->ethtool_ops
>
> wireless core does not correctly assign ethtool_ops. In order to fix
> the problem, and avoid assigning ethtool_ops on each individual cfg80211
> drivers, we check against default_ethool_ops pointer instead of NULL in
> wireless core.
[...]
You could instead move the assignment of default ethtool_ops to just after
call_netdevice_notifiers(NETDEV_REGISTER) in register_netdevice() or
just after call_netdevice_notifiers(NETDEV_POST_INIT) and initialize the default
wireless ethtool_ops in NETDEV_POST_INIT hook. That will avoid the export.
Either way is good because register_netdevice() is called under RTNL, so
ethtool_ops can't be called until it returns. NETDEV_POST_INIT seams more
natural to me, but it's not a strong opinion.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [RFC PATCH] vsprintf: Add %p*D extension for 80211 SSIDs
From: Joe Perches @ 2013-01-07 17:22 UTC (permalink / raw)
To: Johannes Berg
Cc: John W. Linville, Chen Gang, stas.yakovlev, linux-wireless,
netdev
In-Reply-To: <1357544828.9912.0.camel@jlt4.sipsolutions.net>
On Mon, 2013-01-07 at 08:47 +0100, Johannes Berg wrote:
> On Sun, 2013-01-06 at 20:49 -0800, Joe Perches wrote:
> > On Sun, 2013-01-06 at 19:19 -0800, Joe Perches wrote:
> > > Maybe these days this should be another vsprintf %p extension
> > > like %pM when the DECLARE_MAC_BUF/print_mac uses were converted.
> > >
> > > (or maybe extend %ph for ssids with %*phs, length, array)
> >
> > Maybe like this:
>
> > + * - 'D' For a 80211 SSID, it prints the SSID escaping any non-printable
> > + characters with a leading \ and octal or [0nrt\]
>
> Honestly, I'm not sure it's worth it.
Neither am I really, the only value I see in it is the
reduction in stack consumption by 100 bytes or so per use.
> print_ssid() is used in two or
> three legacy drivers only, not in any modern driver, and is unlikely to
> be used in the more modern drivers due to tracing etc.
Swell. It was just another way to correct those overrun
errors Chen Gang found.
^ permalink raw reply
* Re: [patch net] ethtool: set addr_assign_type to NET_ADDR_SET when addr is passed on create
From: Jiri Pirko @ 2013-01-07 17:52 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, davem, shemminger, sassmann
In-Reply-To: <1357576565.2658.6.camel@bwh-desktop.uk.solarflarecom.com>
Mon, Jan 07, 2013 at 05:36:05PM CET, bhutchings@solarflare.com wrote:
>On Sun, 2013-01-06 at 23:38 +0100, Jiri Pirko wrote:
>> In case user passed address via netlink during create, NET_ADDR_PERM was set.
>> That is not correct so fix this by setting NET_ADDR_SET.
>>
>> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>
>Not sure what this has to do with ethtool...
Should have been "netlink" ...
>
>> ---
>> net/core/rtnetlink.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
>> index 9969afb..9a419b0 100644
>> --- a/net/core/rtnetlink.c
>> +++ b/net/core/rtnetlink.c
>> @@ -1667,9 +1667,11 @@ struct net_device *rtnl_create_link(struct net *net,
>>
>> if (tb[IFLA_MTU])
>> dev->mtu = nla_get_u32(tb[IFLA_MTU]);
>> - if (tb[IFLA_ADDRESS])
>> + if (tb[IFLA_ADDRESS]) {
>> memcpy(dev->dev_addr, nla_data(tb[IFLA_ADDRESS]),
>> nla_len(tb[IFLA_ADDRESS]));
>> + dev->addr_assign_type = NET_ADDR_SET;
>> + }
>> if (tb[IFLA_BROADCAST])
>> memcpy(dev->broadcast, nla_data(tb[IFLA_BROADCAST]),
>> nla_len(tb[IFLA_BROADCAST]));
>
>But if the address is not specified for this new device,
>addr_assign_type remains NET_ADD_PERM, right? That sort of makes sense
>in that the 'permanent address' of a software device is all-zeroes. I
>would prefer to have a way for devices to deny having a permanent
>address, but it's a bit late to change that now.
Well if soft-dev uses eth_hw_addr_random() (like team, bridge,
macvlan, etc) it is set to NET_ADDR_RANDOM
And that is exactly the right way to deny having perm address.
>
>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: [patch net-next] ethtool: consolidate work with ethtool_ops
From: Jiri Pirko @ 2013-01-07 18:11 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, davem, richardcochran, greearb, jeffrey.t.kirsher
In-Reply-To: <1357575542.2658.1.camel@bwh-desktop.uk.solarflarecom.com>
Mon, Jan 07, 2013 at 05:19:02PM CET, bhutchings@solarflare.com wrote:
>On Mon, 2013-01-07 at 13:26 +0100, Jiri Pirko wrote:
>> No need to check if ethtool_ops == NULL since it can't be.
>> Use local variable "ops" in functions where it is present
>> instead of dev->ethtool_ops
>> Introduce local variable "ops" in functions where dev->ethtool_ops is used
>> many times.
>>
>> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>> ---
>> net/core/ethtool.c | 45 +++++++++++++++++++++------------------------
>> 1 file changed, 21 insertions(+), 24 deletions(-)
>>
>> diff --git a/net/core/ethtool.c b/net/core/ethtool.c
>> index a870543..08c213e 100644
>> --- a/net/core/ethtool.c
>> +++ b/net/core/ethtool.c
>[...]
>> @@ -1082,9 +1083,10 @@ static int ethtool_phys_id(struct net_device *dev, void __user *useraddr)
>> {
>> struct ethtool_value id;
>> static bool busy;
>> + const struct ethtool_ops *ops = dev->ethtool_ops;
>> int rc;
>>
>> - if (!dev->ethtool_ops->set_phys_id)
>> + if (ops->set_phys_id)
>> return -EOPNOTSUPP;
>[...]
>
>This condition is inverted.
Thanks, will fix this in v2
>
>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
* [RFC/PATCH net-next 0/1] Delete obsolete 8390 EISA drivers
From: Paul Gortmaker @ 2013-01-07 18:16 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Paul Gortmaker
I'd like to propose that we get rid of these old 8390 EISA drivers.
Of the five deleted here, I wrote four -- and while that doesn't give
me any authority for deletion above anyone else, it does at least
allow me to comment on the absolute absence of anyone reaching
out to the driver author for assistance in the last dozen years.
Eventually we'll probably get rid of EISA bus support, since in
x86, the hardware is close to 20 years old and already too resource
constrained to be useful today. However there might still be
a few DEC Alpha enthusiasts with old EISA machines kept alive,
and so I expect we'll have to wait a bit longer to get unanimous
agreement to proceed with the full EISA removal (although I'd
love to be proven wrong on that).
Most of the DEC Alpha machines shipped in a PCI configuration, and
even the few that were EISA had DEC tulip based ethernet and no
reason to be needing the inferior 8390 technology. So the interest
here for any possible DEC enthusiasts with EISA boxes about these
old 8390 drivers should be nil.
These really were rare cards -- in fact the smc-ultra32 is the only
one that I'd ever seen in person. Even back in the mid 90's when
the drivers were written, I would guess that the user base was less
than 10 people across all of them.
The following patch was created with --irreversible-delete for
ease of review (it skips showing the content of files that are
deleted); however the complete patch can be pulled as per below.
Paul.
---
The following changes since commit 483f777266f5da205459c290994bd3cda5f1f6bc:
drivers/net: remove orphaned references to micro channel (2013-01-06 21:13:33 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux.git delete-8390-EISA
for you to fetch changes up to bca94cffabf5c9f2399da34eab00bd534bf3735b:
drivers/net: delete 8390 based EISA drivers. (2013-01-07 10:24:26 -0500)
----------------------------------------------------------------
Paul Gortmaker (1):
drivers/net: delete 8390 based EISA drivers.
drivers/net/ethernet/8390/Kconfig | 66 +----
drivers/net/ethernet/8390/Makefile | 5 -
drivers/net/ethernet/8390/ac3200.c | 431 -----------------------------
drivers/net/ethernet/8390/es3210.c | 445 ------------------------------
drivers/net/ethernet/8390/lne390.c | 433 -----------------------------
drivers/net/ethernet/8390/ne3210.c | 346 ------------------------
drivers/net/ethernet/8390/smc-ultra32.c | 463 --------------------------------
7 files changed, 2 insertions(+), 2187 deletions(-)
delete mode 100644 drivers/net/ethernet/8390/ac3200.c
delete mode 100644 drivers/net/ethernet/8390/es3210.c
delete mode 100644 drivers/net/ethernet/8390/lne390.c
delete mode 100644 drivers/net/ethernet/8390/ne3210.c
delete mode 100644 drivers/net/ethernet/8390/smc-ultra32.c
^ permalink raw reply
* [PATCH net-next 1/1] drivers/net: delete 8390 based EISA drivers.
From: Paul Gortmaker @ 2013-01-07 18:16 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Paul Gortmaker
In-Reply-To: <1357582618-17183-1-git-send-email-paul.gortmaker@windriver.com>
The NS8390 chip was essentially the 1st widespread PC ethernet
chip, starting its life on 8 bit ISA cards in the late 1980s.
Even with better technologies available (bus mastering etc)
the 8390 managed to get used on a few rare EISA cards in the
early to mid 1990s.
The EISA bus in the x86 world was largely confined to systems
ranging from 486 to 586 (essentially 200MHz or lower, and less
than 100MB RAM) -- i.e. machines unlikely to be still in service,
and even less likely to be running a 3.9+ kernel.
On top of that, only one of the five really ever was considered
non-experimental; the smc-ultra32 was the one -- since it was
largely just an EISA version of the popular smc-ultra ISA card.
All the others had such a tiny user base that they simply never
could be considered anything more than experimental.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
drivers/net/ethernet/8390/Kconfig | 66 +----
drivers/net/ethernet/8390/Makefile | 5 -
drivers/net/ethernet/8390/ac3200.c | 431 -----------------------------
drivers/net/ethernet/8390/es3210.c | 445 ------------------------------
drivers/net/ethernet/8390/lne390.c | 433 -----------------------------
drivers/net/ethernet/8390/ne3210.c | 346 ------------------------
drivers/net/ethernet/8390/smc-ultra32.c | 463 --------------------------------
7 files changed, 2 insertions(+), 2187 deletions(-)
delete mode 100644 drivers/net/ethernet/8390/ac3200.c
delete mode 100644 drivers/net/ethernet/8390/es3210.c
delete mode 100644 drivers/net/ethernet/8390/lne390.c
delete mode 100644 drivers/net/ethernet/8390/ne3210.c
delete mode 100644 drivers/net/ethernet/8390/smc-ultra32.c
diff --git a/drivers/net/ethernet/8390/Kconfig b/drivers/net/ethernet/8390/Kconfig
index 8801217..e49a442 100644
--- a/drivers/net/ethernet/8390/Kconfig
+++ b/drivers/net/ethernet/8390/Kconfig
@@ -6,7 +6,7 @@ config NET_VENDOR_8390
bool "National Semi-conductor 8390 devices"
default y
depends on NET_VENDOR_NATSEMI && (AMIGA_PCMCIA || PCI || SUPERH || \
- ISA || EISA || MAC || M32R || MACH_TX49XX || \
+ ISA || MAC || M32R || MACH_TX49XX || \
H8300 || ARM || MIPS || ZORRO || PCMCIA || \
EXPERIMENTAL)
---help---
@@ -33,18 +33,6 @@ config EL2
To compile this driver as a module, choose M here. The module
will be called 3c503.
-config AC3200
- tristate "Ansel Communications EISA 3200 support (EXPERIMENTAL)"
- depends on PCI && (ISA || EISA) && EXPERIMENTAL
- select CRC32
- ---help---
- If you have a network (Ethernet) card of this type, say Y and read
- the Ethernet-HOWTO, available from
- <http://www.tldp.org/docs.html#howto>.
-
- To compile this driver as a module, choose M here. The module
- will be called ac3200.
-
config PCMCIA_AXNET
tristate "Asix AX88190 PCMCIA support"
depends on PCMCIA
@@ -86,18 +74,6 @@ config E2100
To compile this driver as a module, choose M here. The module
will be called e2100.
-config ES3210
- tristate "Racal-Interlan EISA ES3210 support (EXPERIMENTAL)"
- depends on PCI && EISA && EXPERIMENTAL
- select CRC32
- ---help---
- If you have a network (Ethernet) card of this type, say Y and read
- the Ethernet-HOWTO, available from
- <http://www.tldp.org/docs.html#howto>.
-
- To compile this driver as a module, choose M here. The module
- will be called es3210.
-
config HPLAN_PLUS
tristate "HP PCLAN+ (27247B and 27252A) support"
depends on ISA
@@ -140,18 +116,6 @@ config ARM_ETHERH
If you have an Acorn system with one of these network cards, you
should say Y to this option if you wish to use it with Linux.
-config LNE390
- tristate "Mylex EISA LNE390A/B support (EXPERIMENTAL)"
- depends on PCI && EISA && EXPERIMENTAL
- select CRC32
- ---help---
- If you have a network (Ethernet) card of this type, say Y and read
- the Ethernet-HOWTO, available from
- <http://www.tldp.org/docs.html#howto>.
-
- To compile this driver as a module, choose M here. The module
- will be called lne390.
-
config MAC8390
bool "Macintosh NS 8390 based ethernet cards"
depends on MAC
@@ -187,8 +151,7 @@ config NE2000
without a specific driver are compatible with NE2000.
If you have a PCI NE2000 card however, say N here and Y to "PCI
- NE2000 and clone support" under "EISA, VLB, PCI and on board
- controllers" below.
+ NE2000 and clone support" below.
To compile this driver as a module, choose M here. The module
will be called ne.
@@ -223,19 +186,6 @@ config APNE
To compile this driver as a module, choose M here: the module
will be called apne.
-config NE3210
- tristate "Novell/Eagle/Microdyne NE3210 EISA support (EXPERIMENTAL)"
- depends on PCI && EISA && EXPERIMENTAL
- select CRC32
- ---help---
- If you have a network (Ethernet) card of this type, say Y and read
- the Ethernet-HOWTO, available from
- <http://www.tldp.org/docs.html#howto>. Note that this driver
- will NOT WORK for NE3200 cards as they are completely different.
-
- To compile this driver as a module, choose M here. The module
- will be called ne3210.
-
config PCMCIA_PCNET
tristate "NE2000 compatible PCMCIA support"
depends on PCMCIA
@@ -285,18 +235,6 @@ config ULTRA
To compile this driver as a module, choose M here. The module
will be called smc-ultra.
-config ULTRA32
- tristate "SMC Ultra32 EISA support"
- depends on EISA
- select CRC32
- ---help---
- If you have a network (Ethernet) card of this type, say Y and read
- the Ethernet-HOWTO, available from
- <http://www.tldp.org/docs.html#howto>.
-
- To compile this driver as a module, choose M here. The module
- will be called smc-ultra32.
-
config WD80x3
tristate "WD80*3 support"
depends on ISA
diff --git a/drivers/net/ethernet/8390/Makefile b/drivers/net/ethernet/8390/Makefile
index 8fb462c..e8bb97c 100644
--- a/drivers/net/ethernet/8390/Makefile
+++ b/drivers/net/ethernet/8390/Makefile
@@ -3,26 +3,21 @@
#
obj-$(CONFIG_MAC8390) += mac8390.o
-obj-$(CONFIG_AC3200) += ac3200.o 8390.o
obj-$(CONFIG_APNE) += apne.o 8390.o
obj-$(CONFIG_ARM_ETHERH) += etherh.o
obj-$(CONFIG_AX88796) += ax88796.o
obj-$(CONFIG_E2100) += e2100.o 8390.o
obj-$(CONFIG_EL2) += 3c503.o 8390p.o
-obj-$(CONFIG_ES3210) += es3210.o 8390.o
obj-$(CONFIG_HPLAN_PLUS) += hp-plus.o 8390p.o
obj-$(CONFIG_HPLAN) += hp.o 8390p.o
obj-$(CONFIG_HYDRA) += hydra.o 8390.o
-obj-$(CONFIG_LNE390) += lne390.o 8390.o
obj-$(CONFIG_MCF8390) += mcf8390.o 8390.o
obj-$(CONFIG_NE2000) += ne.o 8390p.o
obj-$(CONFIG_NE2K_PCI) += ne2k-pci.o 8390.o
-obj-$(CONFIG_NE3210) += ne3210.o 8390.o
obj-$(CONFIG_NE_H8300) += ne-h8300.o 8390.o
obj-$(CONFIG_PCMCIA_AXNET) += axnet_cs.o 8390.o
obj-$(CONFIG_PCMCIA_PCNET) += pcnet_cs.o 8390.o
obj-$(CONFIG_STNIC) += stnic.o 8390.o
obj-$(CONFIG_ULTRA) += smc-ultra.o 8390.o
-obj-$(CONFIG_ULTRA32) += smc-ultra32.o 8390.o
obj-$(CONFIG_WD80x3) += wd.o 8390.o
obj-$(CONFIG_ZORRO8390) += zorro8390.o 8390.o
diff --git a/drivers/net/ethernet/8390/ac3200.c b/drivers/net/ethernet/8390/ac3200.c
deleted file mode 100644
index ccf0794..0000000
diff --git a/drivers/net/ethernet/8390/es3210.c b/drivers/net/ethernet/8390/es3210.c
deleted file mode 100644
index ba1b5c9..0000000
diff --git a/drivers/net/ethernet/8390/lne390.c b/drivers/net/ethernet/8390/lne390.c
deleted file mode 100644
index 479409b..0000000
diff --git a/drivers/net/ethernet/8390/ne3210.c b/drivers/net/ethernet/8390/ne3210.c
deleted file mode 100644
index ebcdb52..0000000
diff --git a/drivers/net/ethernet/8390/smc-ultra32.c b/drivers/net/ethernet/8390/smc-ultra32.c
deleted file mode 100644
index 923e42a..0000000
--
1.8.1
^ permalink raw reply related
* [patch net-next v2] ethtool: consolidate work with ethtool_ops
From: Jiri Pirko @ 2013-01-07 19:02 UTC (permalink / raw)
To: netdev; +Cc: davem, bhutchings, richardcochran, greearb, jeffrey.t.kirsher
No need to check if ethtool_ops == NULL since it can't be.
Use local variable "ops" in functions where it is present
instead of dev->ethtool_ops
Introduce local variable "ops" in functions where dev->ethtool_ops is used
many times.
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
v1->v2:
- fixed negation spotted by Ben
net/core/ethtool.c | 45 +++++++++++++++++++++------------------------
1 file changed, 21 insertions(+), 24 deletions(-)
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index a870543..d9d5520 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -175,7 +175,7 @@ static int __ethtool_get_sset_count(struct net_device *dev, int sset)
if (sset == ETH_SS_FEATURES)
return ARRAY_SIZE(netdev_features_strings);
- if (ops && ops->get_sset_count && ops->get_strings)
+ if (ops->get_sset_count && ops->get_strings)
return ops->get_sset_count(dev, sset);
else
return -EOPNOTSUPP;
@@ -311,7 +311,7 @@ int __ethtool_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
{
ASSERT_RTNL();
- if (!dev->ethtool_ops || !dev->ethtool_ops->get_settings)
+ if (!dev->ethtool_ops->get_settings)
return -EOPNOTSUPP;
memset(cmd, 0, sizeof(struct ethtool_cmd));
@@ -355,7 +355,7 @@ static noinline_for_stack int ethtool_get_drvinfo(struct net_device *dev,
memset(&info, 0, sizeof(info));
info.cmd = ETHTOOL_GDRVINFO;
- if (ops && ops->get_drvinfo) {
+ if (ops->get_drvinfo) {
ops->get_drvinfo(dev, &info);
} else if (dev->dev.parent && dev->dev.parent->driver) {
strlcpy(info.bus_info, dev_name(dev->dev.parent),
@@ -370,7 +370,7 @@ static noinline_for_stack int ethtool_get_drvinfo(struct net_device *dev,
* this method of obtaining string set info is deprecated;
* Use ETHTOOL_GSSET_INFO instead.
*/
- if (ops && ops->get_sset_count) {
+ if (ops->get_sset_count) {
int rc;
rc = ops->get_sset_count(dev, ETH_SS_TEST);
@@ -383,9 +383,9 @@ static noinline_for_stack int ethtool_get_drvinfo(struct net_device *dev,
if (rc >= 0)
info.n_priv_flags = rc;
}
- if (ops && ops->get_regs_len)
+ if (ops->get_regs_len)
info.regdump_len = ops->get_regs_len(dev);
- if (ops && ops->get_eeprom_len)
+ if (ops->get_eeprom_len)
info.eedump_len = ops->get_eeprom_len(dev);
if (copy_to_user(useraddr, &info, sizeof(info)))
@@ -590,13 +590,14 @@ static noinline_for_stack int ethtool_set_rxfh_indir(struct net_device *dev,
struct ethtool_rxnfc rx_rings;
u32 user_size, dev_size, i;
u32 *indir;
+ const struct ethtool_ops *ops = dev->ethtool_ops;
int ret;
- if (!dev->ethtool_ops->get_rxfh_indir_size ||
- !dev->ethtool_ops->set_rxfh_indir ||
- !dev->ethtool_ops->get_rxnfc)
+ if (!ops->get_rxfh_indir_size || !ops->set_rxfh_indir ||
+ !ops->get_rxnfc)
return -EOPNOTSUPP;
- dev_size = dev->ethtool_ops->get_rxfh_indir_size(dev);
+
+ dev_size = ops->get_rxfh_indir_size(dev);
if (dev_size == 0)
return -EOPNOTSUPP;
@@ -613,7 +614,7 @@ static noinline_for_stack int ethtool_set_rxfh_indir(struct net_device *dev,
return -ENOMEM;
rx_rings.cmd = ETHTOOL_GRXRINGS;
- ret = dev->ethtool_ops->get_rxnfc(dev, &rx_rings, NULL);
+ ret = ops->get_rxnfc(dev, &rx_rings, NULL);
if (ret)
goto out;
@@ -639,7 +640,7 @@ static noinline_for_stack int ethtool_set_rxfh_indir(struct net_device *dev,
}
}
- ret = dev->ethtool_ops->set_rxfh_indir(dev, indir);
+ ret = ops->set_rxfh_indir(dev, indir);
out:
kfree(indir);
@@ -1082,9 +1083,10 @@ static int ethtool_phys_id(struct net_device *dev, void __user *useraddr)
{
struct ethtool_value id;
static bool busy;
+ const struct ethtool_ops *ops = dev->ethtool_ops;
int rc;
- if (!dev->ethtool_ops->set_phys_id)
+ if (!ops->set_phys_id)
return -EOPNOTSUPP;
if (busy)
@@ -1093,7 +1095,7 @@ static int ethtool_phys_id(struct net_device *dev, void __user *useraddr)
if (copy_from_user(&id, useraddr, sizeof(id)))
return -EFAULT;
- rc = dev->ethtool_ops->set_phys_id(dev, ETHTOOL_ID_ACTIVE);
+ rc = ops->set_phys_id(dev, ETHTOOL_ID_ACTIVE);
if (rc < 0)
return rc;
@@ -1118,7 +1120,7 @@ static int ethtool_phys_id(struct net_device *dev, void __user *useraddr)
i = n;
do {
rtnl_lock();
- rc = dev->ethtool_ops->set_phys_id(dev,
+ rc = ops->set_phys_id(dev,
(i & 1) ? ETHTOOL_ID_OFF : ETHTOOL_ID_ON);
rtnl_unlock();
if (rc)
@@ -1133,7 +1135,7 @@ static int ethtool_phys_id(struct net_device *dev, void __user *useraddr)
dev_put(dev);
busy = false;
- (void)dev->ethtool_ops->set_phys_id(dev, ETHTOOL_ID_INACTIVE);
+ (void) ops->set_phys_id(dev, ETHTOOL_ID_INACTIVE);
return rc;
}
@@ -1275,7 +1277,7 @@ static int ethtool_get_dump_flag(struct net_device *dev,
struct ethtool_dump dump;
const struct ethtool_ops *ops = dev->ethtool_ops;
- if (!dev->ethtool_ops->get_dump_flag)
+ if (!ops->get_dump_flag)
return -EOPNOTSUPP;
if (copy_from_user(&dump, useraddr, sizeof(dump)))
@@ -1299,8 +1301,7 @@ static int ethtool_get_dump_data(struct net_device *dev,
const struct ethtool_ops *ops = dev->ethtool_ops;
void *data = NULL;
- if (!dev->ethtool_ops->get_dump_data ||
- !dev->ethtool_ops->get_dump_flag)
+ if (!ops->get_dump_data || !ops->get_dump_flag)
return -EOPNOTSUPP;
if (copy_from_user(&dump, useraddr, sizeof(dump)))
@@ -1346,13 +1347,9 @@ static int ethtool_get_ts_info(struct net_device *dev, void __user *useraddr)
info.cmd = ETHTOOL_GET_TS_INFO;
if (phydev && phydev->drv && phydev->drv->ts_info) {
-
err = phydev->drv->ts_info(phydev, &info);
-
- } else if (dev->ethtool_ops && dev->ethtool_ops->get_ts_info) {
-
+ } else if (ops->get_ts_info) {
err = ops->get_ts_info(dev, &info);
-
} else {
info.so_timestamping =
SOF_TIMESTAMPING_RX_SOFTWARE |
--
1.8.1
^ permalink raw reply related
* [PATCH net-next] net: introduce skb_transport_header_was_set()
From: Eric Dumazet @ 2013-01-07 19:28 UTC (permalink / raw)
To: Jamal Hadi Salim, David Miller; +Cc: netdev
In-Reply-To: <50D5B8BA.9010808@mojatatu.com>
From: Eric Dumazet <edumazet@google.com>
On Sat, 2012-12-22 at 08:42 -0500, Jamal Hadi Salim wrote:
> On 12-12-21 10:45 AM, Eric Dumazet wrote:
> > On Fri, 2012-12-21 at 15:35 +0100, Jan Engelhardt wrote:
> >
>
> > This reminds me this might be the reason we have
> > skb_reset_transport_header(skb);
> > in __netif_receive_skb(), while its not very logical.
> >
>
> You seem to have nailed the egress part finally. That has
> been a constant battle. At one point the standard answer
> was "turn off TSO" ;->
>
> > (Yes, sorry for being off topic, but I am referring to
> > http://www.spinics.net/lists/netdev/msg214662.html )
>
>
> I think the skb_reset_transport_header() when Acme made
> a major overhaul to replace direct pointer access.
> For this reason i think your second option seems preferable.
It seems we already have a special case for mac_header, with the
skb_mac_header_was_set() helper.
We could have same logic for transport_header
Something like :
[PATCH net-next] net: introduce skb_transport_header_was_set()
We have skb_mac_header_was_set() helper to tell if mac_header
was set on a skb. We would like the same for transport_header.
__netif_receive_skb() doesn't reset the transport header if already
set by GRO layer.
Note that network stacks usually reset the transport header anyway,
after pulling the network header, so this change only allows
a followup patch to have more precise qdisc pkt_len computation
for GSO packets at ingress side.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
---
include/linux/skbuff.h | 10 ++++++++++
net/core/dev.c | 3 ++-
net/core/skbuff.c | 2 ++
3 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 320e976..8b2256e 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1492,6 +1492,11 @@ static inline void skb_set_inner_network_header(struct sk_buff *skb,
skb->inner_network_header += offset;
}
+static inline bool skb_transport_header_was_set(const struct sk_buff *skb)
+{
+ return skb->transport_header != ~0U;
+}
+
static inline unsigned char *skb_transport_header(const struct sk_buff *skb)
{
return skb->head + skb->transport_header;
@@ -1580,6 +1585,11 @@ static inline void skb_set_inner_network_header(struct sk_buff *skb,
skb->inner_network_header = skb->data + offset;
}
+static inline bool skb_transport_header_was_set(const struct sk_buff *skb)
+{
+ return skb->transport_header != NULL;
+}
+
static inline unsigned char *skb_transport_header(const struct sk_buff *skb)
{
return skb->transport_header;
diff --git a/net/core/dev.c b/net/core/dev.c
index a51ccf4..2e24482 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3352,7 +3352,8 @@ static int __netif_receive_skb(struct sk_buff *skb)
orig_dev = skb->dev;
skb_reset_network_header(skb);
- skb_reset_transport_header(skb);
+ if (!skb_transport_header_was_set(skb))
+ skb_reset_transport_header(skb);
skb_reset_mac_len(skb);
pt_prev = NULL;
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index b03fc0c..1e1b9ea 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -260,6 +260,7 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask,
skb->end = skb->tail + size;
#ifdef NET_SKBUFF_DATA_USES_OFFSET
skb->mac_header = ~0U;
+ skb->transport_header = ~0U;
#endif
/* make sure we initialize shinfo sequentially */
@@ -328,6 +329,7 @@ struct sk_buff *build_skb(void *data, unsigned int frag_size)
skb->end = skb->tail + size;
#ifdef NET_SKBUFF_DATA_USES_OFFSET
skb->mac_header = ~0U;
+ skb->transport_header = ~0U;
#endif
/* make sure we initialize shinfo sequentially */
^ permalink raw reply related
* [PATCH] sunrpc: verbs: Avoid 1kb stack
From: Joe Perches @ 2013-01-07 19:41 UTC (permalink / raw)
To: J. Bruce Fields, Trond Myklebust
Cc: David S. Miller, linux-nfs, netdev, linux-kernel
16 * 64 is a bit much.
Use kmalloc_array instead.
Signed-off-by: Joe Perches <joe@perches.com>
---
net/sunrpc/xprtrdma/verbs.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/net/sunrpc/xprtrdma/verbs.c b/net/sunrpc/xprtrdma/verbs.c
index 745973b..9cfebb4 100644
--- a/net/sunrpc/xprtrdma/verbs.c
+++ b/net/sunrpc/xprtrdma/verbs.c
@@ -1736,8 +1736,13 @@ rpcrdma_register_default_external(struct rpcrdma_mr_seg *seg,
int mem_priv = (writing ? IB_ACCESS_REMOTE_WRITE :
IB_ACCESS_REMOTE_READ);
struct rpcrdma_mr_seg *seg1 = seg;
- struct ib_phys_buf ipb[RPCRDMA_MAX_DATA_SEGS];
int len, i, rc = 0;
+ struct ib_phys_buf *ipb = kmalloc_array(RPCRDMA_MAX_DATA_SEGS,
+ sizeof(*ipb),
+ GFP_KERNEL);
+
+ if (!ipb)
+ return -ENOMEM;
if (*nsegs > RPCRDMA_MAX_DATA_SEGS)
*nsegs = RPCRDMA_MAX_DATA_SEGS;
@@ -1770,6 +1775,9 @@ rpcrdma_register_default_external(struct rpcrdma_mr_seg *seg,
seg1->mr_len = len;
}
*nsegs = i;
+
+ kfree(ipb);
+
return rc;
}
^ permalink raw reply related
* Re: [patch net-next v2] ethtool: consolidate work with ethtool_ops
From: Ben Hutchings @ 2013-01-07 19:42 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem, richardcochran, greearb, jeffrey.t.kirsher
In-Reply-To: <1357585328-3405-1-git-send-email-jiri@resnulli.us>
On Mon, 2013-01-07 at 20:02 +0100, Jiri Pirko wrote:
> No need to check if ethtool_ops == NULL since it can't be.
> Use local variable "ops" in functions where it is present
> instead of dev->ethtool_ops
> Introduce local variable "ops" in functions where dev->ethtool_ops is used
> many times.
>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
[...]
Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>
--
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
* [PATCH 1/3] netfilter: ip6t_NPT: fix IPv6 NTP checksum calculation
From: pablo @ 2013-01-07 20:04 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1357589047-3373-1-git-send-email-pablo@netfilter.org>
From: Ulrich Weber <ulrich.weber@sophos.com>
csum16_add() has a broken carry detection, should be:
sum += sum < (__force u16)b;
Instead of fixing csum16_add, remove the custom checksum
functions and use the generic csum_add/csum_sub ones.
Signed-off-by: Ulrich Weber <ulrich.weber@sophos.com>
Acked-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/ipv6/netfilter/ip6t_NPT.c | 33 +++++++--------------------------
1 file changed, 7 insertions(+), 26 deletions(-)
diff --git a/net/ipv6/netfilter/ip6t_NPT.c b/net/ipv6/netfilter/ip6t_NPT.c
index e948691..7302b0b 100644
--- a/net/ipv6/netfilter/ip6t_NPT.c
+++ b/net/ipv6/netfilter/ip6t_NPT.c
@@ -14,42 +14,23 @@
#include <linux/netfilter_ipv6/ip6t_NPT.h>
#include <linux/netfilter/x_tables.h>
-static __sum16 csum16_complement(__sum16 a)
-{
- return (__force __sum16)(0xffff - (__force u16)a);
-}
-
-static __sum16 csum16_add(__sum16 a, __sum16 b)
-{
- u16 sum;
-
- sum = (__force u16)a + (__force u16)b;
- sum += (__force u16)a < (__force u16)b;
- return (__force __sum16)sum;
-}
-
-static __sum16 csum16_sub(__sum16 a, __sum16 b)
-{
- return csum16_add(a, csum16_complement(b));
-}
-
static int ip6t_npt_checkentry(const struct xt_tgchk_param *par)
{
struct ip6t_npt_tginfo *npt = par->targinfo;
- __sum16 src_sum = 0, dst_sum = 0;
+ __wsum src_sum = 0, dst_sum = 0;
unsigned int i;
if (npt->src_pfx_len > 64 || npt->dst_pfx_len > 64)
return -EINVAL;
for (i = 0; i < ARRAY_SIZE(npt->src_pfx.in6.s6_addr16); i++) {
- src_sum = csum16_add(src_sum,
- (__force __sum16)npt->src_pfx.in6.s6_addr16[i]);
- dst_sum = csum16_add(dst_sum,
- (__force __sum16)npt->dst_pfx.in6.s6_addr16[i]);
+ src_sum = csum_add(src_sum,
+ (__force __wsum)npt->src_pfx.in6.s6_addr16[i]);
+ dst_sum = csum_add(dst_sum,
+ (__force __wsum)npt->dst_pfx.in6.s6_addr16[i]);
}
- npt->adjustment = csum16_sub(src_sum, dst_sum);
+ npt->adjustment = (__force __sum16) csum_sub(src_sum, dst_sum);
return 0;
}
@@ -85,7 +66,7 @@ static bool ip6t_npt_map_pfx(const struct ip6t_npt_tginfo *npt,
return false;
}
- sum = csum16_add((__force __sum16)addr->s6_addr16[idx],
+ sum = (__force __sum16) csum_add((__force __wsum)addr->s6_addr16[idx],
npt->adjustment);
if (sum == CSUM_MANGLED_0)
sum = 0;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 3/3] netfilter: xt_recent: avoid high order page allocations
From: pablo @ 2013-01-07 20:04 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1357589047-3373-1-git-send-email-pablo@netfilter.org>
From: Eric Dumazet <edumazet@google.com>
xt_recent can try high order page allocations and this can fail.
iptables: page allocation failure: order:9, mode:0xc0d0
It also wastes about half the allocated space because of kmalloc()
power-of-two roundups and struct recent_table layout.
Use vmalloc() instead to save space and be less prone to allocation
errors when memory is fragmented.
Reported-by: Miroslav Kratochvil <exa.exa@gmail.com>
Reported-by: Dave Jones <davej@redhat.com>
Reported-by: Harald Reindl <h.reindl@thelounge.net>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/xt_recent.c | 23 ++++++++++++++++++-----
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/net/netfilter/xt_recent.c b/net/netfilter/xt_recent.c
index dab053e..978efc9 100644
--- a/net/netfilter/xt_recent.c
+++ b/net/netfilter/xt_recent.c
@@ -29,6 +29,7 @@
#include <linux/skbuff.h>
#include <linux/inet.h>
#include <linux/slab.h>
+#include <linux/vmalloc.h>
#include <net/net_namespace.h>
#include <net/netns/generic.h>
@@ -310,6 +311,14 @@ out:
return ret;
}
+static void recent_table_free(void *addr)
+{
+ if (is_vmalloc_addr(addr))
+ vfree(addr);
+ else
+ kfree(addr);
+}
+
static int recent_mt_check(const struct xt_mtchk_param *par,
const struct xt_recent_mtinfo_v1 *info)
{
@@ -322,6 +331,7 @@ static int recent_mt_check(const struct xt_mtchk_param *par,
#endif
unsigned int i;
int ret = -EINVAL;
+ size_t sz;
if (unlikely(!hash_rnd_inited)) {
get_random_bytes(&hash_rnd, sizeof(hash_rnd));
@@ -360,8 +370,11 @@ static int recent_mt_check(const struct xt_mtchk_param *par,
goto out;
}
- t = kzalloc(sizeof(*t) + sizeof(t->iphash[0]) * ip_list_hash_size,
- GFP_KERNEL);
+ sz = sizeof(*t) + sizeof(t->iphash[0]) * ip_list_hash_size;
+ if (sz <= PAGE_SIZE)
+ t = kzalloc(sz, GFP_KERNEL);
+ else
+ t = vzalloc(sz);
if (t == NULL) {
ret = -ENOMEM;
goto out;
@@ -377,14 +390,14 @@ static int recent_mt_check(const struct xt_mtchk_param *par,
uid = make_kuid(&init_user_ns, ip_list_uid);
gid = make_kgid(&init_user_ns, ip_list_gid);
if (!uid_valid(uid) || !gid_valid(gid)) {
- kfree(t);
+ recent_table_free(t);
ret = -EINVAL;
goto out;
}
pde = proc_create_data(t->name, ip_list_perms, recent_net->xt_recent,
&recent_mt_fops, t);
if (pde == NULL) {
- kfree(t);
+ recent_table_free(t);
ret = -ENOMEM;
goto out;
}
@@ -435,7 +448,7 @@ static void recent_mt_destroy(const struct xt_mtdtor_param *par)
remove_proc_entry(t->name, recent_net->xt_recent);
#endif
recent_table_flush(t);
- kfree(t);
+ recent_table_free(t);
}
mutex_unlock(&recent_mutex);
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 0/3] Netfilter fixes for 3.8-rc2
From: pablo @ 2013-01-07 20:04 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
From: Pablo Neira Ayuso <pablo@netfilter.org>
Hi David,
The following batch contains Netfilter fixes for 3.8-rc2, they are:
* Fix IPv6 stateless network/port translation (NPT) checksum
calculation, from Ulrich Weber.
* Fix for xt_recent to avoid memory allocation failures if large
hashtables are used, from Eric Dumazet.
* Fix missing dependencies in Kconfig for the deprecated NOTRACK,
from myself.
You can pull these changes from:
git://1984.lsi.us.es/nf master
Thanks!
Eric Dumazet (1):
netfilter: xt_recent: avoid high order page allocations
Pablo Neira Ayuso (1):
netfilter: fix missing dependencies for the NOTRACK target
Ulrich Weber (1):
netfilter: ip6t_NPT: fix IPv6 NTP checksum calculation
net/ipv6/netfilter/ip6t_NPT.c | 33 +++++++--------------------------
net/netfilter/Kconfig | 3 +++
net/netfilter/xt_recent.c | 23 ++++++++++++++++++-----
3 files changed, 28 insertions(+), 31 deletions(-)
--
1.7.10.4
^ permalink raw reply
* [PATCH 2/3] netfilter: fix missing dependencies for the NOTRACK target
From: pablo @ 2013-01-07 20:04 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <1357589047-3373-1-git-send-email-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
warning: (NETFILTER_XT_TARGET_NOTRACK) selects NETFILTER_XT_TARGET_CT which has unmet direct
+dependencies (NET && INET && NETFILTER && NETFILTER_XTABLES && NF_CONNTRACK && (IP_NF_RAW ||
+IP6_NF_RAW) && NETFILTER_ADVANCED)
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/Kconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig
index 390f96c..49e96df 100644
--- a/net/netfilter/Kconfig
+++ b/net/netfilter/Kconfig
@@ -682,6 +682,9 @@ config NETFILTER_XT_TARGET_NFQUEUE
config NETFILTER_XT_TARGET_NOTRACK
tristate '"NOTRACK" target support (DEPRECATED)'
+ depends on NF_CONNTRACK
+ depends on IP_NF_RAW || IP6_NF_RAW
+ depends on NETFILTER_ADVANCED
select NETFILTER_XT_TARGET_CT
config NETFILTER_XT_TARGET_RATEEST
--
1.7.10.4
^ permalink raw reply related
* Re: [patch net-next v2] ethtool: consolidate work with ethtool_ops
From: Flavio Leitner @ 2013-01-07 20:06 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, bhutchings, richardcochran, greearb,
jeffrey.t.kirsher
In-Reply-To: <1357585328-3405-1-git-send-email-jiri@resnulli.us>
On Mon, Jan 07, 2013 at 08:02:08PM +0100, Jiri Pirko wrote:
> No need to check if ethtool_ops == NULL since it can't be.
> Use local variable "ops" in functions where it is present
> instead of dev->ethtool_ops
> Introduce local variable "ops" in functions where dev->ethtool_ops is used
> many times.
>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> ---
Reviewed-by: Flavio Leitner <fbl@redhat.com>
^ permalink raw reply
* Re: [RFC PATCH 0/3] Make rfc3686 template work with asynchronous block ciphers
From: Herbert Xu @ 2013-01-07 20:18 UTC (permalink / raw)
To: Steffen Klassert; +Cc: David Miller, jussi.kivilinna, linux-crypto, netdev
In-Reply-To: <20130107070036.GP18940@secunet.com>
On Mon, Jan 07, 2013 at 08:00:36AM +0100, Steffen Klassert wrote:
> On Sat, Dec 29, 2012 at 11:08:12AM +1100, Herbert Xu wrote:
> > On Fri, Dec 28, 2012 at 03:23:11PM -0800, David Miller wrote:
> > > From: Herbert Xu <herbert@gondor.apana.org.au>
> > > Date: Sat, 29 Dec 2012 09:42:49 +1100
> > >
> > > > On Fri, Dec 28, 2012 at 12:04:48PM +0200, Jussi Kivilinna wrote:
> > > >> I'm not sure how this patchset should be dealt with (should 1st patch go
> > > >> through different tree than 2nd and 3rd?), so therefore it's RFC.
> > > >>
> > > >> Second patch makes rfc3686 template work with asynchronous block ciphers and
> > > >> third patch changes aesni-intel to use this template. First patch fixed problem
> > > >> in xfrm_algo found with help of 2nd and 3rd patches and without 1st patch
> > > >> 2nd patch breaks aes-ctr with IPSEC.
> > > >
> > > > I think the easiest way is to have these patches go through Dave's
> > > > tree.
> > >
> > > Better yet, Steffen's IPSEC tree :-)
> >
> > Of course :)
>
> Herbert, can I add your Ack to the crypto patches?
Sure.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [RFC PATCH net-next] can-gw: add a variable limit for CAN frame routings
From: Oliver Hartkopp @ 2013-01-07 21:51 UTC (permalink / raw)
To: Linux Netdev List, Linux CAN List, Marc Kleine-Budde
To prevent a possible misconfiguration (e.g. circular CAN frame routings)
limit the number of routings of a single CAN frame to a small variable value.
The limit can be specified by the module parameter 'max_hops' (1..6).
The default value is 1 (one hop), according to the original can-gw behaviour.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
---
Having the possibility of only a single CAN frame routing (one hop) hinders
use-cases for some complex application setups. To enable more than one CAN
frame routing process with a single CAN frame (skb) a counter needed to be
implemented to prevent an endless frame processing (e.g. due to some kind of
misconfiguration).
As the skb control buffer (cb) potentially gets modified by net/sched in the
tx path the csum element for IP checksums is re-used for the counter, as CAN
frame skbs (ARPHRD_CAN) never contain any kind of checksums (see src comment).
@Marc: I wanted to sent this patch on netdev ML to see if there are any
objections of using skb->csum in the way i proposed here. When the patch is
fine please take it via can-next for this net-next cycle then. Tnx.
diff --git a/include/uapi/linux/can/gw.h b/include/uapi/linux/can/gw.h
index 8e1db18..ba87697 100644
--- a/include/uapi/linux/can/gw.h
+++ b/include/uapi/linux/can/gw.h
@@ -44,6 +44,7 @@ enum {
CGW_SRC_IF, /* ifindex of source network interface */
CGW_DST_IF, /* ifindex of destination network interface */
CGW_FILTER, /* specify struct can_filter on source CAN device */
+ CGW_DELETED, /* number of deleted CAN frames (see max_hops param) */
__CGW_MAX
};
diff --git a/net/can/gw.c b/net/can/gw.c
index 574dda78e..20d5a7d 100644
--- a/net/can/gw.c
+++ b/net/can/gw.c
@@ -57,15 +57,23 @@
#include <net/net_namespace.h>
#include <net/sock.h>
-#define CAN_GW_VERSION "20101209"
+#define CAN_GW_VERSION "20130107"
static __initconst const char banner[] =
- KERN_INFO "can: netlink gateway (rev " CAN_GW_VERSION ")\n";
+ KERN_INFO "can: netlink gateway (rev " CAN_GW_VERSION ")";
MODULE_DESCRIPTION("PF_CAN netlink gateway");
MODULE_LICENSE("Dual BSD/GPL");
MODULE_AUTHOR("Oliver Hartkopp <oliver.hartkopp@volkswagen.de>");
MODULE_ALIAS("can-gw");
+#define CAN_GW_MAX_HOPS 6
+
+static unsigned int max_hops __read_mostly = 1;
+module_param(max_hops, uint, S_IRUGO);
+MODULE_PARM_DESC(max_hops,
+ "maximum can-gw routing hops for CAN frames "
+ "(valid values: 1-6 hops, default: 1)");
+
static HLIST_HEAD(cgw_list);
static struct notifier_block notifier;
@@ -118,6 +126,7 @@ struct cgw_job {
struct rcu_head rcu;
u32 handled_frames;
u32 dropped_frames;
+ u32 deleted_frames;
struct cf_mod mod;
union {
/* CAN frame data source */
@@ -338,9 +347,27 @@ static void can_can_gw_rcv(struct sk_buff *skb, void *data)
struct sk_buff *nskb;
int modidx = 0;
- /* do not handle already routed frames - see comment below */
- if (skb_mac_header_was_set(skb))
+ /*
+ * Do not handle CAN frames routed more than 'max_hops' times.
+ * In general we should never catch this delimiter which is intended
+ * to cover a misconfiguration protection (e.g. circular CAN routes).
+ *
+ * The Controller Area Network controllers only accept CAN frames with
+ * correct CRCs - which are not visible in the controller registers.
+ * According to skbuff.h documentation the csum element for IP checksums
+ * is undefined/unsued when ip_summed == CHECKSUM_UNNECESSARY. Only
+ * CAN skbs can be processed here which already have this property.
+ */
+
+#define cgw_hops(skb) ((skb)->csum)
+
+ BUG_ON(skb->ip_summed != CHECKSUM_UNNECESSARY);
+
+ if (cgw_hops(skb) >= max_hops) {
+ /* indicate deleted frames due to misconfiguration */
+ gwj->deleted_frames++;
return;
+ }
if (!(gwj->dst.dev->flags & IFF_UP)) {
gwj->dropped_frames++;
@@ -363,15 +390,8 @@ static void can_can_gw_rcv(struct sk_buff *skb, void *data)
return;
}
- /*
- * Mark routed frames by setting some mac header length which is
- * not relevant for the CAN frames located in the skb->data section.
- *
- * As dev->header_ops is not set in CAN netdevices no one is ever
- * accessing the various header offsets in the CAN skbuffs anyway.
- * E.g. using the packet socket to read CAN frames is still working.
- */
- skb_set_mac_header(nskb, 8);
+ /* put the incremented hop counter in the cloned skb */
+ cgw_hops(nskb) = cgw_hops(skb) + 1;
nskb->dev = gwj->dst.dev;
/* pointer to modifiable CAN frame */
@@ -472,6 +492,11 @@ static int cgw_put_job(struct sk_buff *skb, struct cgw_job *gwj, int type,
goto cancel;
}
+ if (gwj->deleted_frames) {
+ if (nla_put_u32(skb, CGW_DELETED, gwj->deleted_frames) < 0)
+ goto cancel;
+ }
+
/* check non default settings of attributes */
if (gwj->mod.modtype.and) {
@@ -771,6 +796,7 @@ static int cgw_create_job(struct sk_buff *skb, struct nlmsghdr *nlh,
gwj->handled_frames = 0;
gwj->dropped_frames = 0;
+ gwj->deleted_frames = 0;
gwj->flags = r->flags;
gwj->gwtype = r->gwtype;
@@ -895,7 +921,14 @@ static int cgw_remove_job(struct sk_buff *skb, struct nlmsghdr *nlh, void *arg)
static __init int cgw_module_init(void)
{
- printk(banner);
+ /* sanitize given module parameter */
+ if (max_hops < 1)
+ max_hops = 1;
+
+ if (max_hops > CAN_GW_MAX_HOPS)
+ max_hops = CAN_GW_MAX_HOPS;
+
+ printk("%s max_hops=%d\n", banner, max_hops);
cgw_cache = kmem_cache_create("can_gw", sizeof(struct cgw_job),
0, 0, NULL);
^ permalink raw reply related
* Re: ppoll() stuck on POLLIN while TCP peer is sending
From: Eric Dumazet @ 2013-01-07 22:38 UTC (permalink / raw)
To: Mel Gorman
Cc: Eric Wong, linux-mm, netdev, linux-kernel, Rik van Riel,
Minchan Kim, Andrew Morton, Linus Torvalds
In-Reply-To: <20130107122516.GC3885@suse.de>
On Mon, 2013-01-07 at 12:25 +0000, Mel Gorman wrote:
>
> > ===> 28014[28017]/stack <===
> > [<ffffffff8129fc1d>] release_sock+0xe5/0x11b
> > [<ffffffff812a642c>] sk_stream_wait_memory+0x1f7/0x1fc
> > [<ffffffff81040d5e>] autoremove_wake_function+0x0/0x2a
> > [<ffffffff812d8fc3>] tcp_sendmsg+0x710/0x86d
> > [<ffffffff8129a33e>] sock_sendmsg+0x7b/0x93
> > [<ffffffff8129a642>] sys_sendto+0xee/0x145
> > [<ffffffff8129a3bc>] sockfd_lookup_light+0x1a/0x50
> > [<ffffffff8129a668>] sys_sendto+0x114/0x145
> > [<ffffffff81000e34>] __switch_to+0x235/0x3c5
> > [<ffffffff81322769>] system_call_fastpath+0x16/0x1b
> > [<ffffffffffffffff>] 0xffffffffffffffff
>
> This seems to be the guy that's stuck. It's waiting for more memory for
> the socket but who or what is allocating that memory? There are a few other
> bugs from over the weekend that I want to take a look at so I did not dig
> further or try to reproduce this bug yet. I'm adding Eric Dumazet back to
> the cc in case he has the quick answer.
Thanks Mel
It would not surprise me if sk_stream_wait_memory() have plain bug(s) or
race(s).
In 2010, in commit 482964e56e132 Nagendra Tomar fixed a pretty severe
long standing bug.
This path is not taken very often on most machines.
I would try the following patch :
diff --git a/net/core/stream.c b/net/core/stream.c
index f5df85d..6f09979 100644
--- a/net/core/stream.c
+++ b/net/core/stream.c
@@ -126,6 +126,7 @@ int sk_stream_wait_memory(struct sock *sk, long *timeo_p)
while (1) {
set_bit(SOCK_ASYNC_NOSPACE, &sk->sk_socket->flags);
+ set_bit(SOCK_NOSPACE, &sk->sk_socket->flags);
prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);
@@ -139,7 +140,6 @@ int sk_stream_wait_memory(struct sock *sk, long *timeo_p)
if (sk_stream_memory_free(sk) && !vm_wait)
break;
- set_bit(SOCK_NOSPACE, &sk->sk_socket->flags);
sk->sk_write_pending++;
sk_wait_event(sk, ¤t_timeo, sk->sk_err ||
(sk->sk_shutdown & SEND_SHUTDOWN) ||
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* Re: ppoll() stuck on POLLIN while TCP peer is sending
From: Eric Wong @ 2013-01-07 22:38 UTC (permalink / raw)
To: Mel Gorman
Cc: linux-mm, netdev, linux-kernel, Rik van Riel, Minchan Kim,
Eric Dumazet, Andrew Morton, Linus Torvalds
In-Reply-To: <20130107122516.GC3885@suse.de>
Mel Gorman <mgorman@suse.de> wrote:
> Right now it's difficult to see how the capture could be the source of
> this bug but I'm not ruling it out either so try the following (untested
> but should be ok) patch. It's not a proper revert, it just disables the
> capture page logic to see if it's at fault.
Things look good so far with your change.
It's been running 2 hours on a VM and 1 hour on my regular machine.
Will update again in a few hours (or sooner if it's stuck again).
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* PROBLEM: Software injected vlan tagged packets are unable to be identified using recent BPF modifications
From: Paul Pearce @ 2013-01-08 0:05 UTC (permalink / raw)
To: netdev, tcpdump-workers; +Cc: davem, edumazet, jpirko, Ani Sinha
Hello folks,
PROBLEM:
vlan tagged packets that are injected via software are not picked up
by filters using recent (kernel commit
f3335031b9452baebfe49b8b5e55d3fe0c4677d1)
BPF vlan modifications. I suspect this is a problem with the Linux
kernel.
linux-netdev and tcpdump-workers are both cc'd.
BACKGROUND:
Kernel commit bcc6d47903612c3861201cc3a866fb604f26b8b2 (Jiri
Pirko/David S. Miller) removed vlan headers on rx packets prior to
them reaching the packet filters. This broke BPF/libpcap's ability to
do kernel-level packet filtering based on vlan tag information (the
'vlan' keyword).
Kernel commit f3335031b9452baebfe49b8b5e55d3fe0c4677d1 (Eric
Dumazet/David S. Miller, just merged into Linus's tree
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=f3335031b9452baebfe49b8b5e55d3fe0c4677d1)
added the ability to use BPF to once again filter based on vlan
tags. Related bpf jit commit:
http://www.spinics.net/lists/netdev/msg214759.html
libpcap (Ani Sinha) recently RFC'd a patch to use Eric/David's BPF
modifications to restore vlan filtering to libpcap.
http://www.mail-archive.com/tcpdump-workers@lists.tcpdump.org/msg06810.html
I'm using this patch and it works.
DETAILS:
Under these patches vlan tagged packets received from mediam (actual
packets from the wire) can be identified based on vlan tag information
using the new BPF functionality.This is good.
However, raw vlan tagged packets that are *injected* into the
interface using libpcap's pcap_inject() (which is just a fancy wrapper
for the send() syscall) are not identified by filters using the recent
BPF modifications.
The bug manifests itself if you attempt to use the new BPF
modifications to filter vlan tagged packets on a live interface. All
packets from the medium show up, but all injected packets are dropped.
Prior to commit bcc6d47 both medium and injected packets could both be
identified using BPFs.
These injected packets can however still be identified using the
previous, now incorrect "offset into the header" technique. Given
this, I suspect what's going on is the kernel code path for these
injected packets is not setting skb->vlan_tci correctly (at all?).
Since the vlan tag is not in the skb data structure the new BPF
modifications don't identify the packets as having a vlan tag,
despite it being in the packet header.
I'm not sure exactly where the bug exists so I'm reaching out to both
netdev and tcpdump-workers. Although, as I said, I suspect this is on
the kernel side.
SOFTWARE:
kernel-3.6.11-1.fc16.x86_64, with both kernel commits
f3335031b9452baebfe49b8b5e55d3fe0c4677d1 and the related commit
http://www.spinics.net/lists/netdev/msg214759.html backported.
tcpdump version 4.4.0-PRE-GIT_2013_01_06 (commit
05bf602ef684d5b75c0ac71be04212d909c37834)
libpcap version 1.4.0-PRE-GIT_2013_01_06 (commit
713034fc4b3a2c14ae81e44dca34d998db8d0795 with patch specified above)
Thanks.
-Paul Pearce
Security Graduate Student
Computer Science
University of California, Berkeley
^ permalink raw reply
* Re: ppoll() stuck on POLLIN while TCP peer is sending
From: Eric Wong @ 2013-01-08 0:21 UTC (permalink / raw)
To: Eric Dumazet
Cc: Mel Gorman, linux-mm, netdev, linux-kernel, Rik van Riel,
Minchan Kim, Andrew Morton, Linus Torvalds
In-Reply-To: <1357598315.6919.3969.camel@edumazet-glaptop>
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> It would not surprise me if sk_stream_wait_memory() have plain bug(s) or
> race(s).
>
> In 2010, in commit 482964e56e132 Nagendra Tomar fixed a pretty severe
> long standing bug.
>
> This path is not taken very often on most machines.
>
> I would try the following patch :
With your patch alone (on top of 3.8-rc2) running on my VM,
I was able to get toosleepy stuck within a few minutes.
===> /proc/vmstat <===
nr_free_pages 3251
nr_inactive_anon 3974
nr_active_anon 3638
nr_inactive_file 100973
nr_active_file 4669
nr_unevictable 0
nr_mlock 0
nr_anon_pages 7515
nr_mapped 2328
nr_file_pages 105739
nr_dirty 6
nr_writeback 0
nr_slab_reclaimable 1703
nr_slab_unreclaimable 5465
nr_page_table_pages 735
nr_kernel_stack 161
nr_unstable 0
nr_bounce 0
nr_vmscan_write 0
nr_vmscan_immediate_reclaim 17
nr_writeback_temp 0
nr_isolated_anon 0
nr_isolated_file 0
nr_shmem 115
nr_dirtied 1575304
nr_written 95797
nr_anon_transparent_hugepages 0
nr_free_cma 0
nr_dirty_threshold 22988
nr_dirty_background_threshold 11494
pgpgin 61164
pgpgout 385372
pswpin 0
pswpout 0
pgalloc_dma 123943
pgalloc_dma32 15694247
pgalloc_normal 0
pgalloc_movable 0
pgfree 15823064
pgactivate 6119
pgdeactivate 5134
pgfault 1439865
pgmajfault 495
pgrefill_dma 1230
pgrefill_dma32 3904
pgrefill_normal 0
pgrefill_movable 0
pgsteal_kswapd_dma 22875
pgsteal_kswapd_dma32 1272136
pgsteal_kswapd_normal 0
pgsteal_kswapd_movable 0
pgsteal_direct_dma 3351
pgsteal_direct_dma32 187467
pgsteal_direct_normal 0
pgsteal_direct_movable 0
pgscan_kswapd_dma 22879
pgscan_kswapd_dma32 1273059
pgscan_kswapd_normal 0
pgscan_kswapd_movable 0
pgscan_direct_dma 3351
pgscan_direct_dma32 187566
pgscan_direct_normal 0
pgscan_direct_movable 0
pgscan_direct_throttle 0
pginodesteal 8
slabs_scanned 14336
kswapd_inodesteal 91
kswapd_low_wmark_hit_quickly 2797
kswapd_high_wmark_hit_quickly 65
kswapd_skip_congestion_wait 3
pageoutrun 18900
allocstall 3350
pgrotated 10
pgmigrate_success 278
pgmigrate_fail 0
compact_migrate_scanned 68864
compact_free_scanned 118486
compact_isolated 6958
compact_stall 306
compact_fail 128
compact_success 178
unevictable_pgs_culled 1063
unevictable_pgs_scanned 0
unevictable_pgs_rescued 1669
unevictable_pgs_mlocked 1669
unevictable_pgs_munlocked 1666
unevictable_pgs_cleared 3
unevictable_pgs_stranded 0
thp_fault_alloc 0
thp_fault_fallback 0
thp_collapse_alloc 0
thp_collapse_alloc_failed 0
thp_split 0
thp_zero_page_alloc 0
thp_zero_page_alloc_failed 0
===> 6018[6018]/stack <===
[<ffffffff81077300>] futex_wait_queue_me+0xc0/0xf0
[<ffffffff81077a9d>] futex_wait+0x17d/0x280
[<ffffffff8107988c>] do_futex+0x11c/0xae0
[<ffffffff8107a2d8>] sys_futex+0x88/0x180
[<ffffffff813b06a9>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
===> 6018[6019]/stack <===
[<ffffffff810f5904>] poll_schedule_timeout+0x44/0x60
[<ffffffff810f6d54>] do_sys_poll+0x374/0x4b0
[<ffffffff810f718e>] sys_ppoll+0x19e/0x1b0
[<ffffffff813b06a9>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
===> 6018[6020]/stack <===
[<ffffffff810f5904>] poll_schedule_timeout+0x44/0x60
[<ffffffff810f6d54>] do_sys_poll+0x374/0x4b0
[<ffffffff810f718e>] sys_ppoll+0x19e/0x1b0
[<ffffffff813b06a9>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
===> 6018[6021]/stack <===
[<ffffffff81310058>] sk_stream_wait_memory+0x1b8/0x250
[<ffffffff8134be67>] tcp_sendmsg+0x697/0xd80
[<ffffffff81370cce>] inet_sendmsg+0x5e/0xa0
[<ffffffff81300a77>] sock_sendmsg+0x87/0xa0
[<ffffffff81303a59>] sys_sendto+0x119/0x160
[<ffffffff813b06a9>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
===> 6018[6022]/stack <===
[<ffffffff810400b8>] do_wait+0x1f8/0x220
[<ffffffff81040ea0>] sys_wait4+0x70/0xf0
[<ffffffff813b06a9>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
SysRq : Show Memory
Mem-Info:
DMA per-cpu:
CPU 0: hi: 0, btch: 1 usd: 0
CPU 1: hi: 0, btch: 1 usd: 0
DMA32 per-cpu:
CPU 0: hi: 186, btch: 31 usd: 156
CPU 1: hi: 186, btch: 31 usd: 158
active_anon:3546 inactive_anon:3645 isolated_anon:0
active_file:4327 inactive_file:101560 isolated_file:0
unevictable:0 dirty:1 writeback:0 unstable:0
free:3057 slab_reclaimable:1435 slab_unreclaimable:5441
mapped:2308 shmem:115 pagetables:798 bounce:0
free_cma:0
DMA free:2080kB min:84kB low:104kB high:124kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:13428kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15644kB managed:15900kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:32kB slab_unreclaimable:84kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 488 488 488
DMA32 free:10148kB min:2784kB low:3480kB high:4176kB active_anon:14184kB inactive_anon:14580kB active_file:17308kB inactive_file:392812kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:499960kB managed:491256kB mlocked:0kB dirty:4kB writeback:0kB mapped:9232kB shmem:460kB slab_reclaimable:5708kB slab_unreclaimable:21680kB kernel_stack:1352kB pagetables:3192kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
DMA: 10*4kB (UR) 0*8kB 2*16kB (U) 3*32kB (R) 2*64kB (R) 0*128kB 1*256kB (R) 1*512kB (R) 1*1024kB (R) 0*2048kB 0*4096kB = 2088kB
DMA32: 370*4kB (UEM) 194*8kB (UM) 72*16kB (UM) 33*32kB (UM) 25*64kB (UEM) 18*128kB (EM) 4*256kB (M) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 10168kB
105998 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap = 392188kB
Total swap = 392188kB
131054 pages RAM
3820 pages reserved
276280 pages shared
118656 pages non-shared
SysRq : Show Memory
Mem-Info:
DMA per-cpu:
CPU 0: hi: 0, btch: 1 usd: 0
CPU 1: hi: 0, btch: 1 usd: 0
DMA32 per-cpu:
CPU 0: hi: 186, btch: 31 usd: 158
CPU 1: hi: 186, btch: 31 usd: 176
active_anon:3376 inactive_anon:3666 isolated_anon:0
active_file:4331 inactive_file:101207 isolated_file:0
unevictable:0 dirty:0 writeback:38 unstable:0
free:3683 slab_reclaimable:1460 slab_unreclaimable:5398
mapped:2306 shmem:115 pagetables:762 bounce:0
free_cma:0
DMA free:2168kB min:84kB low:104kB high:124kB active_anon:0kB inactive_anon:16kB active_file:0kB inactive_file:13348kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15644kB managed:15900kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:40kB slab_unreclaimable:76kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 488 488 488
DMA32 free:12564kB min:2784kB low:3480kB high:4176kB active_anon:13504kB inactive_anon:14648kB active_file:17324kB inactive_file:391480kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:499960kB managed:491256kB mlocked:0kB dirty:0kB writeback:152kB mapped:9224kB shmem:460kB slab_reclaimable:5800kB slab_unreclaimable:21516kB kernel_stack:1368kB pagetables:3048kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
DMA: 25*4kB (MR) 1*8kB (R) 3*16kB (R) 3*32kB (R) 2*64kB (R) 0*128kB 1*256kB (R) 1*512kB (R) 1*1024kB (R) 0*2048kB 0*4096kB = 2172kB
DMA32: 427*4kB (UM) 336*8kB (UEM) 126*16kB (UEM) 49*32kB (UEM) 40*64kB (UEM) 10*128kB (UM) 3*256kB (M) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 12588kB
105658 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap = 392188kB
Total swap = 392188kB
131054 pages RAM
3820 pages reserved
275229 pages shared
118788 pages non-shared
SysRq : Show Memory
Mem-Info:
DMA per-cpu:
CPU 0: hi: 0, btch: 1 usd: 0
CPU 1: hi: 0, btch: 1 usd: 0
DMA32 per-cpu:
CPU 0: hi: 186, btch: 31 usd: 108
CPU 1: hi: 186, btch: 31 usd: 166
active_anon:3022 inactive_anon:3664 isolated_anon:0
active_file:4405 inactive_file:69838 isolated_file:0
unevictable:0 dirty:5 writeback:4813 unstable:0
free:34429 slab_reclaimable:1723 slab_unreclaimable:5522
mapped:2322 shmem:115 pagetables:748 bounce:0
free_cma:0
DMA free:3616kB min:84kB low:104kB high:124kB active_anon:0kB inactive_anon:20kB active_file:0kB inactive_file:10480kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15644kB managed:15900kB mlocked:0kB dirty:0kB writeback:560kB mapped:0kB shmem:0kB slab_reclaimable:108kB slab_unreclaimable:328kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 488 488 488
DMA32 free:134100kB min:2784kB low:3480kB high:4176kB active_anon:12088kB inactive_anon:14636kB active_file:17620kB inactive_file:268872kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:499960kB managed:491256kB mlocked:0kB dirty:20kB writeback:18692kB mapped:9288kB shmem:460kB slab_reclaimable:6784kB slab_unreclaimable:21760kB kernel_stack:1328kB pagetables:2992kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
DMA: 136*4kB (UEMR) 89*8kB (UMR) 42*16kB (UMR) 7*32kB (UMR) 3*64kB (R) 0*128kB 1*256kB (R) 0*512kB 1*1024kB (R) 0*2048kB 0*4096kB = 3624kB
DMA32: 4839*4kB (UEM) 4648*8kB (UEM) 2853*16kB (UEM) 868*32kB (UEM) 65*64kB (UEM) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 134124kB
74344 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap = 392188kB
Total swap = 392188kB
131054 pages RAM
3820 pages reserved
285651 pages shared
82395 pages non-shared
SysRq : Show Memory
Mem-Info:
DMA per-cpu:
CPU 0: hi: 0, btch: 1 usd: 0
CPU 1: hi: 0, btch: 1 usd: 0
DMA32 per-cpu:
CPU 0: hi: 186, btch: 31 usd: 166
CPU 1: hi: 186, btch: 31 usd: 28
active_anon:3729 inactive_anon:3974 isolated_anon:0
active_file:4669 inactive_file:101127 isolated_file:0
unevictable:0 dirty:6 writeback:0 unstable:0
free:3244 slab_reclaimable:1703 slab_unreclaimable:5465
mapped:2328 shmem:115 pagetables:754 bounce:0
free_cma:0
DMA free:2360kB min:84kB low:104kB high:124kB active_anon:0kB inactive_anon:4kB active_file:20kB inactive_file:9756kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15644kB managed:15900kB mlocked:0kB dirty:12kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:368kB slab_unreclaimable:324kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 488 488 488
DMA32 free:10616kB min:2784kB low:3480kB high:4176kB active_anon:14916kB inactive_anon:15892kB active_file:18656kB inactive_file:394752kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:499960kB managed:491256kB mlocked:0kB dirty:12kB writeback:0kB mapped:9312kB shmem:460kB slab_reclaimable:6444kB slab_unreclaimable:21536kB kernel_stack:1288kB pagetables:3016kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
DMA: 43*4kB (UMR) 16*8kB (UMR) 19*16kB (MR) 23*32kB (UR) 8*64kB (R) 2*128kB (R) 1*256kB (R) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 2364kB
DMA32: 634*4kB (UEM) 615*8kB (UEM) 199*16kB (UEM) 1*32kB (M) 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 10672kB
105892 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap = 392188kB
Total swap = 392188kB
131054 pages RAM
3820 pages reserved
274934 pages shared
119600 pages non-shared
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: why does kernel 3.8-rc1 put all TAP devices into state RUNNING during boot
From: Max Krasnyansky @ 2013-01-08 0:27 UTC (permalink / raw)
To: Toralf Förster; +Cc: Linux Kernel, netdev
In-Reply-To: <50E7FD79.1080605@gmx.de>
On 01/05/2013 02:16 AM, Toralf Förster wrote:
> At my stable Gentoo Linux I'm observed a change behaviour for the
> configured TAP devices after the boot process.
>
> $ diff 3.7.1 3.8.0-rc1+ | grep UP
>- br0: flags=4355<UP,BROADCAST,PROMISC,MULTICAST> mtu 1500
>+ br0: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST> mtu 1500
>- tap0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
>+ tap0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
>
> May I ask you if this changed behaviour is intended ?
I'm not aware of any changes in this behavior.
btw Looks like it changed for your bridge interfaces as well. So it's not really
specific to the TAP devices.
Someone from netdev would know :)
Max
^ permalink raw reply
* Re: PROBLEM: Software injected vlan tagged packets are unable to be identified using recent BPF modifications
From: Ani Sinha @ 2013-01-08 1:25 UTC (permalink / raw)
To: Paul Pearce
Cc: jpirko, netdev, Francesco Ruggeri, edumazet, tcpdump-workers,
David Miller
In-Reply-To: <CAOUgPvQP2RrngPPf=hYxpPdGSQ4L-Db0T-BMDwVg6iy8LTAu=Q@mail.gmail.com>
On Mon, Jan 7, 2013 at 4:05 PM, Paul Pearce <pearce@cs.berkeley.edu> wrote:
> Hello folks,
>
> PROBLEM:
>
> vlan tagged packets that are injected via software are not picked up
> by filters using recent (kernel commit
> f3335031b9452baebfe49b8b5e55d3fe0c4677d1)
> BPF vlan modifications. I suspect this is a problem with the Linux
> kernel.
>
> linux-netdev and tcpdump-workers are both cc'd.
>
Just to be clear, up until now we did not see this issue because the
BPF filter code generated by libpcap would always look into packet
offsets for vlan tag information. With the patch that I submitted to
tcpdump-workers a day ago, it no longer looks into the packet but in
the skb meta data (which is the right thing to do going forward). This
breaks raw packets. We will have to handle this in the kernel to fix
it.
ani
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
^ 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