* [PATCH 2/2] can: sja1000: fix/add miniPCIe/cPCI PC/104Plus PCI/104e PEAK-System boards
From: Marc Kleine-Budde @ 2012-10-24 9:06 UTC (permalink / raw)
To: David Miller
Cc: Linux Netdev List, linux-can, Stephane Grosjean,
Marc Kleine-Budde
In-Reply-To: <1351069576-20790-1-git-send-email-mkl@pengutronix.de>
From: Stephane Grosjean <s.grosjean@peak-system.com>
This patch adds the support for 4 new PCI boards based on the SJA1000 CAN
controller, from PEAK-System Technik:
. PCAN-miniPCIe (PCI-Express Mini slots, available as single or dual-channel)
. PCAN-cPCI (CompactPCI format, available as single or dual-channel)
. PCAN-PC/104-Plus (PC/104-Plus system, av. as 1, 2 or 4 channels)
. PCAN-PCI/104-Express (PCI/104-Express system, av. as 1 or 2 channels)
This patch also fixes a typo in existing "PEAK_MPCI_DEVICE_ID" identifier
(missing "e" for Express). Finally, it also changes the author as well as it
updates the module supported devices list.
Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Acked-by: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/sja1000/peak_pci.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/can/sja1000/peak_pci.c b/drivers/net/can/sja1000/peak_pci.c
index f5b82ae..6525dbc 100644
--- a/drivers/net/can/sja1000/peak_pci.c
+++ b/drivers/net/can/sja1000/peak_pci.c
@@ -30,9 +30,10 @@
#include "sja1000.h"
-MODULE_AUTHOR("Wolfgang Grandegger <wg@grandegger.com>");
+MODULE_AUTHOR("Stephane Grosjean <s.grosjean@peak-system.com>");
MODULE_DESCRIPTION("Socket-CAN driver for PEAK PCAN PCI family cards");
MODULE_SUPPORTED_DEVICE("PEAK PCAN PCI/PCIe/PCIeC miniPCI CAN cards");
+MODULE_SUPPORTED_DEVICE("PEAK PCAN miniPCIe/cPCI PC/104+ PCI/104e CAN Cards");
MODULE_LICENSE("GPL v2");
#define DRV_NAME "peak_pci"
@@ -64,7 +65,11 @@ struct peak_pci_chan {
#define PEAK_PCI_DEVICE_ID 0x0001 /* for PCI/PCIe slot cards */
#define PEAK_PCIEC_DEVICE_ID 0x0002 /* for ExpressCard slot cards */
#define PEAK_PCIE_DEVICE_ID 0x0003 /* for nextgen PCIe slot cards */
-#define PEAK_MPCI_DEVICE_ID 0x0008 /* The miniPCI slot cards */
+#define PEAK_CPCI_DEVICE_ID 0x0004 /* for nextgen cPCI slot cards */
+#define PEAK_MPCI_DEVICE_ID 0x0005 /* for nextgen miniPCI slot cards */
+#define PEAK_PC_104P_DEVICE_ID 0x0006 /* PCAN-PC/104+ cards */
+#define PEAK_PCI_104E_DEVICE_ID 0x0007 /* PCAN-PCI/104 Express cards */
+#define PEAK_MPCIE_DEVICE_ID 0x0008 /* The miniPCIe slot cards */
#define PEAK_PCI_CHAN_MAX 4
@@ -76,6 +81,10 @@ static DEFINE_PCI_DEVICE_TABLE(peak_pci_tbl) = {
{PEAK_PCI_VENDOR_ID, PEAK_PCI_DEVICE_ID, PCI_ANY_ID, PCI_ANY_ID,},
{PEAK_PCI_VENDOR_ID, PEAK_PCIE_DEVICE_ID, PCI_ANY_ID, PCI_ANY_ID,},
{PEAK_PCI_VENDOR_ID, PEAK_MPCI_DEVICE_ID, PCI_ANY_ID, PCI_ANY_ID,},
+ {PEAK_PCI_VENDOR_ID, PEAK_MPCIE_DEVICE_ID, PCI_ANY_ID, PCI_ANY_ID,},
+ {PEAK_PCI_VENDOR_ID, PEAK_PC_104P_DEVICE_ID, PCI_ANY_ID, PCI_ANY_ID,},
+ {PEAK_PCI_VENDOR_ID, PEAK_PCI_104E_DEVICE_ID, PCI_ANY_ID, PCI_ANY_ID,},
+ {PEAK_PCI_VENDOR_ID, PEAK_CPCI_DEVICE_ID, PCI_ANY_ID, PCI_ANY_ID,},
#ifdef CONFIG_CAN_PEAK_PCIEC
{PEAK_PCI_VENDOR_ID, PEAK_PCIEC_DEVICE_ID, PCI_ANY_ID, PCI_ANY_ID,},
#endif
--
1.7.10
^ permalink raw reply related
* pull-request: can 2012-10-24
From: Marc Kleine-Budde @ 2012-10-24 9:06 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, linux-can
Hello David,
here are two patches for the v3.7 release cycle. A patch by Wolfgang Grandegger
for the flexcan driver, which switches off a workaround on the imx6q that is
not needed, because the hardware is not affected by that bug. And a patch by
Stephane Grosjean which updates the pci device table for the peak pci sja1000
driver.
regards, Marc
--
The following changes since commit 37561f68bd527ec39076e32effdc7b1dcdfb17ea:
tcp: Reject invalid ack_seq to Fast Open sockets (2012-10-23 02:42:56 -0400)
are available in the git repository at:
git://gitorious.org/linux-can/linux-can.git fixes-for-3.7
for you to fetch changes up to fc09e3672ed623f9c8e73ded3cbcd2cfcf304aac:
can: sja1000: fix/add miniPCIe/cPCI PC/104Plus PCI/104e PEAK-System boards (2012-10-24 10:53:49 +0200)
----------------------------------------------------------------
Stephane Grosjean (1):
can: sja1000: fix/add miniPCIe/cPCI PC/104Plus PCI/104e PEAK-System boards
Wolfgang Grandegger (1):
can: flexcan: disable bus error interrupts for the i.MX6q
drivers/net/can/flexcan.c | 19 ++++++++++++++++---
drivers/net/can/sja1000/peak_pci.c | 13 +++++++++++--
2 files changed, 27 insertions(+), 5 deletions(-)
^ permalink raw reply
* RE: [RFC PATCH v2 2/6] PM / Runtime: introduce pm_runtime_set_memalloc_noio()
From: David Laight @ 2012-10-24 9:06 UTC (permalink / raw)
To: Ming Lei, Alan Stern
Cc: linux-kernel, Oliver Neukum, Minchan Kim, Greg Kroah-Hartman,
Rafael J. Wysocki, Jens Axboe, David S. Miller, Andrew Morton,
netdev, linux-usb, linux-pm, linux-mm
In-Reply-To: <CACVXFVN+=XH_f5BmRkXeagTNowz0o0-Pd7GcxCneO0FSq8xqEw@mail.gmail.com>
> Looks the problem is worse than above, not only bitfields are affected, the
> adjacent fields might be involved too, see:
>
> http://lwn.net/Articles/478657/
Not mentioned in there is that even with x86/amd64 given
a struct with the following adjacent fields:
char a;
char b;
char c;
then foo->b |= 0x80; might do a 32bit RMW cycle.
This will (well might - but probably does) happen
if compiled to a 'BTS' instruction.
The x86 instruction set docs are actually unclear
as to whether the 32bit cycle might even be misaligned!
amd64 might do a 64bit cycle (not checked the docs).
David
^ permalink raw reply
* Re: Incorrect ARP behavior when multiple/none IPv4 address assigned to interface
From: Sergey Popovich @ 2012-10-24 10:37 UTC (permalink / raw)
To: netdev
In-Reply-To: <alpine.LFD.2.00.1210241106080.1616@ja.ssi.bg>
Julian Anastasov пишет:
> dummy module is usually used as blackhole for
> traffic or to hide addresses from other interfaces with
> some sysctl interface flags.
>
> For example, can it work in this way?:
>
> eth0: addr 10.0.1.1/24
> ip route 10.0.1.2/32 dev eth0 src 10.0.1.1
>
> eth1: addr 10.0.1.1/24
> ip route 10.0.1.3/32 dev eth1 src 10.0.1.1
>
> eth2: addr 10.0.2.1/24
> ip route 10.0.2.2/32 dev eth2 src 10.0.2.1
>
> By this way we have subnet on every device and
> we can prefer local IP from such subnet in inet_select_addr.
> May be arp_ignore=1/2 and arp_announce=1/2 can help here
> to put the needed restrictions, i.e. we should not expose
> addresses from other devices. It should not cause problem
> for proxy_arp because we have more specific /32 routes.
>
Yes, just apply proposed configuration to lab schema.
Everything works as expected with no extra arp_ignore/arp_announce
configuration. Even if I add second primary address 192.168.1.1/24 to
eth2, and introduce pc4 in same broadcast domain as pc3 (eth2).
Well, configuration with 3000 subinterfaces looks worse, but it works
with no extra patches/configuration.
Thank you for your help.
--
SP5474-RIPE
Sergey Popovich
^ permalink raw reply
* [BUG] checkpatch.pl with commit 058806007450489bb8f457b275e5cb5c946320c1
From: Jeff Kirsher @ 2012-10-24 11:00 UTC (permalink / raw)
To: Joe Perches; +Cc: netdev, LKML
[-- Attachment #1: Type: text/plain, Size: 718 bytes --]
With the recent commit to checkpatch.pl:
commit 058806007450489bb8f457b275e5cb5c946320c1
Author: Joe Perches <joe@perches.com>
Date: Thu Oct 4 17:13:35 2012 -0700
checkpatch: check networking specific block comment style
We are seeing false positive warnings. Here is an example of the
code the would generate a false warning:
#define foo 0x0000 /* foo comment */
checkpatch.pl generates a warnings that the */ should be on a separate
line, which in this case is incorrect.
I apologize for not digging into the checkpatch.pl code to provide a
fix, I figure Joe (or anyone else with great checkpatch kung fu) can
figure out the issue and fix it faster than I could. :-)
Cheers,
Jeff
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] net: allow configuration of the size of page in __netdev_alloc_frag
From: Ian Campbell @ 2012-10-24 11:42 UTC (permalink / raw)
To: netdev; +Cc: Ian Campbell, Eric Dumazet, Konrad Rzeszutek Wilk, xen-devel
The commit 69b08f62e174 "net: use bigger pages in __netdev_alloc_frag"
lead to 70%+ packet loss under Xen when transmitting from physical (as
opposed to virtual) network devices.
This is because under Xen pages which are contiguous in the physical
address space may not be contiguous in the DMA space, in fact it is
very likely that they are not. I think there are other architectures
where this is true, although perhaps non quite so aggressive as to
have this property at a per-order-0-page granularity.
The real underlying bug here most likely lies in the swiotlb not
correctly handling compound pages, and Konrad is investigating this.
However even with the swiotlb issue fixed the current arrangement
seems likely to result in a lot of bounce buffering which seems likely
to more than offset any benefit from the use of larger pages.
Therefore make NETDEV_FRAG_PAGE_MAX_ORDER configurable at runtime and
use this to request order-0 frags under Xen. Also expose this setting
via sysctl.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: netdev@vger.kernel.org
Cc: xen-devel@lists.xen.org
---
arch/x86/xen/setup.c | 7 +++++++
include/linux/skbuff.h | 2 ++
net/core/skbuff.c | 7 ++++---
net/core/sysctl_net_core.c | 7 +++++++
4 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 8971a26..ad14d46 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -11,6 +11,7 @@
#include <linux/memblock.h>
#include <linux/cpuidle.h>
#include <linux/cpufreq.h>
+#include <linux/skbuff.h>
#include <asm/elf.h>
#include <asm/vdso.h>
@@ -555,6 +556,12 @@ void __init xen_arch_setup(void)
MAX_GUEST_CMDLINE > COMMAND_LINE_SIZE ?
COMMAND_LINE_SIZE : MAX_GUEST_CMDLINE);
+ /*
+ * Xen cannot handle DMA to/from compound pages so avoid
+ * bounce buffering by not allocating large network frags.
+ */
+ netdev_frag_page_max_order = 0;
+
/* Set up idle, making sure it calls safe_halt() pvop */
#ifdef CONFIG_X86_32
boot_cpu_data.hlt_works_ok = 1;
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 6a2c34e..a3a748f 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1719,6 +1719,8 @@ static inline void __skb_queue_purge(struct sk_buff_head *list)
kfree_skb(skb);
}
+extern int netdev_frag_page_max_order;
+
extern void *netdev_alloc_frag(unsigned int fragsz);
extern struct sk_buff *__netdev_alloc_skb(struct net_device *dev,
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 6e04b1f..88cbe5f 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -348,8 +348,9 @@ struct netdev_alloc_cache {
};
static DEFINE_PER_CPU(struct netdev_alloc_cache, netdev_alloc_cache);
-#define NETDEV_FRAG_PAGE_MAX_ORDER get_order(32768)
-#define NETDEV_FRAG_PAGE_MAX_SIZE (PAGE_SIZE << NETDEV_FRAG_PAGE_MAX_ORDER)
+int netdev_frag_page_max_order __read_mostly = get_order(32768);
+
+#define NETDEV_FRAG_PAGE_MAX_SIZE (PAGE_SIZE << netdev_frag_page_max_order)
#define NETDEV_PAGECNT_MAX_BIAS NETDEV_FRAG_PAGE_MAX_SIZE
static void *__netdev_alloc_frag(unsigned int fragsz, gfp_t gfp_mask)
@@ -363,7 +364,7 @@ static void *__netdev_alloc_frag(unsigned int fragsz, gfp_t gfp_mask)
nc = &__get_cpu_var(netdev_alloc_cache);
if (unlikely(!nc->frag.page)) {
refill:
- for (order = NETDEV_FRAG_PAGE_MAX_ORDER; ;) {
+ for (order = netdev_frag_page_max_order; ;) {
gfp_t gfp = gfp_mask;
if (order)
diff --git a/net/core/sysctl_net_core.c b/net/core/sysctl_net_core.c
index a7c3684..e5ab6df 100644
--- a/net/core/sysctl_net_core.c
+++ b/net/core/sysctl_net_core.c
@@ -129,6 +129,13 @@ static struct ctl_table net_core_table[] = {
.mode = 0644,
.proc_handler = proc_dointvec
},
+ {
+ .procname = "netdev_frag_page_max_order",
+ .data = &netdev_frag_page_max_order,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec
+ },
#ifdef CONFIG_BPF_JIT
{
.procname = "bpf_jit_enable",
--
1.7.2.5
^ permalink raw reply related
* Re: [RFC PATCH v2 2/6] PM / Runtime: introduce pm_runtime_set_memalloc_noio()
From: Alan Cox @ 2012-10-24 12:26 UTC (permalink / raw)
To: David Laight
Cc: Ming Lei, Alan Stern, linux-kernel, Oliver Neukum, Minchan Kim,
Greg Kroah-Hartman, Rafael J. Wysocki, Jens Axboe,
David S. Miller, Andrew Morton, netdev, linux-usb, linux-pm,
linux-mm
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B7060@saturn3.aculab.com>
On Wed, 24 Oct 2012 10:06:36 +0100
"David Laight" <David.Laight@ACULAB.COM> wrote:
> > Looks the problem is worse than above, not only bitfields are affected, the
> > adjacent fields might be involved too, see:
> >
> > http://lwn.net/Articles/478657/
>
> Not mentioned in there is that even with x86/amd64 given
> a struct with the following adjacent fields:
> char a;
> char b;
> char c;
> then foo->b |= 0x80; might do a 32bit RMW cycle.
There are processors that will do this for the char case at least as they
do byte ops by a mix of 32bit ops and rotate.
> This will (well might - but probably does) happen
> if compiled to a 'BTS' instruction.
> The x86 instruction set docs are actually unclear
> as to whether the 32bit cycle might even be misaligned!
> amd64 might do a 64bit cycle (not checked the docs).
Even with a suitably aligned field the compiler is at liberty to generate
things like
reg = 0x80
reg |= foo->b
foo->b = reg;
One reason it's a good idea to use set_bit/test_bit and friends.
Alan
--
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: [PATCH] net: allow configuration of the size of page in __netdev_alloc_frag
From: Eric Dumazet @ 2012-10-24 12:28 UTC (permalink / raw)
To: Ian Campbell; +Cc: netdev, Eric Dumazet, Konrad Rzeszutek Wilk, xen-devel
In-Reply-To: <1351078936-14159-1-git-send-email-ian.campbell@citrix.com>
On Wed, 2012-10-24 at 12:42 +0100, Ian Campbell wrote:
> The commit 69b08f62e174 "net: use bigger pages in __netdev_alloc_frag"
> lead to 70%+ packet loss under Xen when transmitting from physical (as
> opposed to virtual) network devices.
>
> This is because under Xen pages which are contiguous in the physical
> address space may not be contiguous in the DMA space, in fact it is
> very likely that they are not. I think there are other architectures
> where this is true, although perhaps non quite so aggressive as to
> have this property at a per-order-0-page granularity.
>
> The real underlying bug here most likely lies in the swiotlb not
> correctly handling compound pages, and Konrad is investigating this.
> However even with the swiotlb issue fixed the current arrangement
> seems likely to result in a lot of bounce buffering which seems likely
> to more than offset any benefit from the use of larger pages.
>
> Therefore make NETDEV_FRAG_PAGE_MAX_ORDER configurable at runtime and
> use this to request order-0 frags under Xen. Also expose this setting
> via sysctl.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: netdev@vger.kernel.org
> Cc: xen-devel@lists.xen.org
> ---
I understand your concern, but this seems a quick/dirty hack at this
moment. After setting the sysctl to 0, some tasks may still have some
order-3 pages in their cache.
Your driver must already cope with skb->head being split on several
pages.
So what fundamental difference exists with frags ?
^ permalink raw reply
* Re: [PATCH] net: allow configuration of the size of page in __netdev_alloc_frag
From: Ian Campbell @ 2012-10-24 13:16 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev@vger.kernel.org, Eric Dumazet, Konrad Rzeszutek Wilk,
xen-devel@lists.xen.org
In-Reply-To: <1351081703.6537.99.camel@edumazet-glaptop>
On Wed, 2012-10-24 at 13:28 +0100, Eric Dumazet wrote:
> On Wed, 2012-10-24 at 12:42 +0100, Ian Campbell wrote:
> > The commit 69b08f62e174 "net: use bigger pages in __netdev_alloc_frag"
> > lead to 70%+ packet loss under Xen when transmitting from physical (as
> > opposed to virtual) network devices.
> >
> > This is because under Xen pages which are contiguous in the physical
> > address space may not be contiguous in the DMA space, in fact it is
> > very likely that they are not. I think there are other architectures
> > where this is true, although perhaps non quite so aggressive as to
> > have this property at a per-order-0-page granularity.
> >
> > The real underlying bug here most likely lies in the swiotlb not
> > correctly handling compound pages, and Konrad is investigating this.
> > However even with the swiotlb issue fixed the current arrangement
> > seems likely to result in a lot of bounce buffering which seems likely
> > to more than offset any benefit from the use of larger pages.
> >
> > Therefore make NETDEV_FRAG_PAGE_MAX_ORDER configurable at runtime and
> > use this to request order-0 frags under Xen. Also expose this setting
> > via sysctl.
> >
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Eric Dumazet <edumazet@google.com>
> > Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Cc: netdev@vger.kernel.org
> > Cc: xen-devel@lists.xen.org
> > ---
>
> I understand your concern, but this seems a quick/dirty hack at this
> moment. After setting the sysctl to 0, some tasks may still have some
> order-3 pages in their cache.
Right, the sysctl thing might be overkill, I just figured it was useful
for debugging. When booting in a Xen VM the patch sets it to zero very
early on, during setup_arch(), which is before any tasks even exist.
> Your driver must already cope with skb->head being split on several
> pages.
>
> So what fundamental difference exists with frags ?
The issue here is with drivers for physical network devices when running
under Xen not with the Xen paravirtualised network drivers (AKA
netback/netfront).
The problem is that pages which are contiguous in the physical address
space may not be contiguous in the DMA address space. With order>0 pages
this becomes a problem when you poke down the DMA address and length of
a compound page into the hardware registers. The DMA address will be
right for the head of the page but once the hardware steps off the end
of that it'll get the wrong page.
I don't think this non-contiguousness between physical and DMA addresses
is specific to Xen, although it is more frequent under Xen than any real
hardware platform. (Xen has often been a good canary for these sorts of
issues which turn out later on to impact other arches too.)
In theory this could be fixed in all the drivers for physical network
devices, but that would be a lot of effort (and probably a fair bit of
ugliness in the drivers) for a gain which was only relevant to Xen.
Ian.
^ permalink raw reply
* Re: [PATCH RESEND net-next] bluetooth: hci_core: Replace list_for_each with list_for_each_entry() helper
From: Gustavo Padovan @ 2012-10-24 13:22 UTC (permalink / raw)
To: Denis Kirjanov
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1350912121-24171-1-git-send-email-kirjanov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Denis,
* Denis Kirjanov <kirjanov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [2012-10-22 17:22:01 +0400]:
> Replace list_for_each with list_for_each_entry() helper
>
> Signed-off-by: Denis Kirjanov <kirjanov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> include/net/bluetooth/hci_core.h | 20 ++++++++------------
> 1 files changed, 8 insertions(+), 12 deletions(-)
Patch has been applied to bluetooth-next. Thanks.
Gustavo
^ permalink raw reply
* [PATCH net-next] packet: minor: remove unused err assignment
From: Daniel Borkmann @ 2012-10-24 13:27 UTC (permalink / raw)
To: davem; +Cc: netdev
This tiny patch removes two unused err assignments. In those two cases the
err variable is either overwritten with another value at a later point in
time without having read the previous assigment, or it is assigned and the
function returns without using/reading err after the assignment.
Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
---
net/packet/af_packet.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 94060ed..9034f52 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1907,7 +1907,6 @@ static int tpacket_fill_skb(struct packet_sock *po, struct sk_buff *skb,
to_write -= dev->hard_header_len;
}
- err = -EFAULT;
offset = offset_in_page(data);
len_max = PAGE_SIZE - offset;
len = ((to_write > len_max) ? len_max : to_write);
@@ -1957,7 +1956,6 @@ static int tpacket_snd(struct packet_sock *po, struct msghdr *msg)
mutex_lock(&po->pg_vec_lock);
- err = -EBUSY;
if (saddr == NULL) {
dev = po->prot_hook.dev;
proto = po->num;
^ permalink raw reply related
* Re: [PATCH] net: allow configuration of the size of page in __netdev_alloc_frag
From: Eric Dumazet @ 2012-10-24 13:30 UTC (permalink / raw)
To: Ian Campbell
Cc: netdev@vger.kernel.org, Eric Dumazet, Konrad Rzeszutek Wilk,
xen-devel@lists.xen.org
In-Reply-To: <1351084618.18035.27.camel@zakaz.uk.xensource.com>
On Wed, 2012-10-24 at 14:16 +0100, Ian Campbell wrote:
> On Wed, 2012-10-24 at 13:28 +0100, Eric Dumazet wrote:
> > On Wed, 2012-10-24 at 12:42 +0100, Ian Campbell wrote:
> > > The commit 69b08f62e174 "net: use bigger pages in __netdev_alloc_frag"
> > > lead to 70%+ packet loss under Xen when transmitting from physical (as
> > > opposed to virtual) network devices.
> > >
> > > This is because under Xen pages which are contiguous in the physical
> > > address space may not be contiguous in the DMA space, in fact it is
> > > very likely that they are not. I think there are other architectures
> > > where this is true, although perhaps non quite so aggressive as to
> > > have this property at a per-order-0-page granularity.
> > >
> > > The real underlying bug here most likely lies in the swiotlb not
> > > correctly handling compound pages, and Konrad is investigating this.
> > > However even with the swiotlb issue fixed the current arrangement
> > > seems likely to result in a lot of bounce buffering which seems likely
> > > to more than offset any benefit from the use of larger pages.
> > >
> > > Therefore make NETDEV_FRAG_PAGE_MAX_ORDER configurable at runtime and
> > > use this to request order-0 frags under Xen. Also expose this setting
> > > via sysctl.
> > >
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > Cc: Eric Dumazet <edumazet@google.com>
> > > Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > Cc: netdev@vger.kernel.org
> > > Cc: xen-devel@lists.xen.org
> > > ---
> >
> > I understand your concern, but this seems a quick/dirty hack at this
> > moment. After setting the sysctl to 0, some tasks may still have some
> > order-3 pages in their cache.
>
> Right, the sysctl thing might be overkill, I just figured it was useful
> for debugging. When booting in a Xen VM the patch sets it to zero very
> early on, during setup_arch(), which is before any tasks even exist.
>
> > Your driver must already cope with skb->head being split on several
> > pages.
> >
> > So what fundamental difference exists with frags ?
>
> The issue here is with drivers for physical network devices when running
> under Xen not with the Xen paravirtualised network drivers (AKA
> netback/netfront).
>
> The problem is that pages which are contiguous in the physical address
> space may not be contiguous in the DMA address space. With order>0 pages
> this becomes a problem when you poke down the DMA address and length of
> a compound page into the hardware registers. The DMA address will be
> right for the head of the page but once the hardware steps off the end
> of that it'll get the wrong page.
>
> I don't think this non-contiguousness between physical and DMA addresses
> is specific to Xen, although it is more frequent under Xen than any real
> hardware platform. (Xen has often been a good canary for these sorts of
> issues which turn out later on to impact other arches too.)
>
> In theory this could be fixed in all the drivers for physical network
> devices, but that would be a lot of effort (and probably a fair bit of
> ugliness in the drivers) for a gain which was only relevant to Xen.
I still have concerns about skb->head that you dint really answered.
Why skb->head can be on order-1 or order-2 pages and this is working ?
It seems to me its a driver issue, for example
drivers/net/xen-netfront.c has assumptions that can be easily fixed.
^ permalink raw reply
* Re: [PATCH] net: allow configuration of the size of page in __netdev_alloc_frag
From: Ian Campbell @ 2012-10-24 14:02 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev@vger.kernel.org, Eric Dumazet, Konrad Rzeszutek Wilk,
xen-devel@lists.xen.org
In-Reply-To: <1351085403.6537.102.camel@edumazet-glaptop>
On Wed, 2012-10-24 at 14:30 +0100, Eric Dumazet wrote:
> It seems to me its a driver issue, for example
> drivers/net/xen-netfront.c has assumptions that can be easily fixed.
The netfront ->head thing is a separate (although perhaps related)
issue, I intended to fix along the same lines as the previous netback
except for some unfathomable reason I haven't been able to reproduce the
problem with netfront -- I've no idea why though since it seems like it
should be a no brainer!
> Why skb->head can be on order-1 or order-2 pages and this is working ?
skb->head being order 1 or 2 isn't working for me. The driver I'm having
issues with which caused me to create this particular patch is the tg3
driver (although I don't think this is by any means specific to tg3).
For the ->head the tg3 driver does:
mapping = pci_map_single(tp->pdev, skb->data, len, PCI_DMA_TODEVICE);
while for the frags it does:
mapping = skb_frag_dma_map(&tp->pdev->dev, frag, 0, len, DMA_TO_DEVICE);
This ought to do the Right Thing but doesn't seem to be working. Konrad
suspected an issue with the swiotlb's handling of order>0 pages in some
cases. As I said in the commit message he is looking into this issue.
My concern however was that even once the swiotlb is fixed to work right
the effect of pci_map_single on a order>0 page is going to be that the
data gets bounced into contiguous memory -- that is a memcpy which would
undo the benefit of having allocating large pages to start with. So I
figured that in such cases we'd be better off just using order 0
allocations to start with.
Ian.
^ permalink raw reply
* Re: [BUG] checkpatch.pl with commit 058806007450489bb8f457b275e5cb5c946320c1
From: Joe Perches @ 2012-10-24 14:12 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, LKML
In-Reply-To: <1351076421.25066.14.camel@jtkirshe-mobl>
On Wed, 2012-10-24 at 04:00 -0700, Jeff Kirsher wrote:
> With the recent commit to checkpatch.pl:
>
> commit 058806007450489bb8f457b275e5cb5c946320c1
> Author: Joe Perches <joe@perches.com>
> Date: Thu Oct 4 17:13:35 2012 -0700
>
> checkpatch: check networking specific block comment style
>
> We are seeing false positive warnings. Here is an example of the
> code the would generate a false warning:
>
> #define foo 0x0000 /* foo comment */
>
> checkpatch.pl generates a warnings that the */ should be on a separate
> line, which in this case is incorrect.
Sorry 'bout that. I believe it's fixed by:
https://lkml.org/lkml/2012/10/14/267
^ permalink raw reply
* Re: Bug#690845: ethtool: incorrect WoL detection on Broadcom NX II rev < 12
From: Ben Hutchings @ 2012-10-24 14:23 UTC (permalink / raw)
To: Michael Chan; +Cc: 690845, Teodor MICU, netdev
In-Reply-To: <1350958687.8764.170.camel@LTIRV-MCHAN1.corp.ad.broadcom.com>
[-- Attachment #1: Type: text/plain, Size: 1150 bytes --]
On Mon, 2012-10-22 at 19:18 -0700, Michael Chan wrote:
> On Tue, 2012-10-23 at 02:45 +0100, Ben Hutchings wrote:
> > Well we knew that much! Is the problem that the system firmware 'owns'
> > the WoL control registers so the host can't safely change them? Is it
> > possible to *read* the WoL configuration, if not to change it?
>
> It's a hardware problem and I don't understand all the details. There
> is an internal PCIX to PCIE bridge on this chip and it gates the NIC's
> PME event. During S5 reset, the bridge gets reset by the BIOS and the
> WoL setting done by the driver will no longer work. Newer chip revs
> have fixed the problem in hardware.
>
> The driver reads the pre-boot WoL setting from NVRAM and it becomes the
> ethtool WoL default setting. Apparently, it is also not working in this
> case. I know that it doesn't work on some LOM designs as the setting is
> actually in BIOS NVRAM as opposed to NIC NVRAM.
Thanks for the explanation. This does seem to be unfixable, then,
unfortunately.
Ben.
--
Ben Hutchings
Never attribute to conspiracy what can adequately be explained by stupidity.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH] Make hmac algorithm selection for cookie generation dynamic
From: Vlad Yasevich @ 2012-10-24 14:32 UTC (permalink / raw)
To: Neil Horman; +Cc: linux-sctp, David S. Miller, netdev
In-Reply-To: <1350661926-8312-1-git-send-email-nhorman@tuxdriver.com>
On 10/19/2012 11:52 AM, Neil Horman wrote:
> Currently sctp allows for the optional use of md5 of sha1 hmac algorithms to
> generate cookie values when establishing new connections via two build time
> config options. Theres no real reason to make this a static selection. We can
> add a sysctl that allows for the dynamic selection of these algorithms at run
> time, with the default value determined by the corresponding crypto library
> config options. It saves us two needless configuration settings and enables the
> freedom for administrators to select which algorithm a particular system uses.
> This comes in handy when, for example running a system in FIPS mode, where use
> of md5 is disallowed, but SHA1 is permitted.
>
> Note: This new sysctl has no corresponding socket option to select the cookie
> hmac algorithm. I chose not to implement that intentionally, as RFC 6458
> contains no option for this value, and I opted not to pollute the socket option
> namespace.
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> CC: Vlad Yasevich <vyasevich@gmail.com>
> CC: "David S. Miller" <davem@davemloft.net>
> CC: netdev@vger.kernel.org
> ---
> Documentation/networking/ip-sysctl.txt | 14 ++++++++
> include/net/netns/sctp.h | 3 ++
> include/net/sctp/constants.h | 8 -----
> include/net/sctp/structs.h | 1 +
> net/sctp/Kconfig | 30 -----------------
> net/sctp/protocol.c | 9 ++++++
> net/sctp/socket.c | 11 ++++---
> net/sctp/sysctl.c | 59 ++++++++++++++++++++++++++++++++++
> 8 files changed, 93 insertions(+), 42 deletions(-)
>
> diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
> index c7fc107..98ac0d7 100644
> --- a/Documentation/networking/ip-sysctl.txt
> +++ b/Documentation/networking/ip-sysctl.txt
> @@ -1514,6 +1514,20 @@ cookie_preserve_enable - BOOLEAN
>
> Default: 1
>
> +cookie_hmac_alg - STRING
> + Select the hmac algorithm used when generating the cookie value sent by
> + a listening sctp socket to a connecting client in the INIT-ACK chunk.
> + Valid values are:
> + * md5
> + * sha1
> + * none
> + Ability to assign md5 or sha1 as the selected alg is predicated on the
> + configuarion of those algorithms at build time (CONFIG_CRYPTO_MD5 and
> + CONFIG_CRYPTO_SHA1).
> +
> + Default: Dependent on configuration. MD5 if available, else SHA1 if
> + available, else none.
> +
> rcvbuf_policy - INTEGER
> Determines if the receive buffer is attributed to the socket or to
> association. SCTP supports the capability to create multiple
> diff --git a/include/net/netns/sctp.h b/include/net/netns/sctp.h
> index 5e5eb1f..3573a81 100644
> --- a/include/net/netns/sctp.h
> +++ b/include/net/netns/sctp.h
> @@ -62,6 +62,9 @@ struct netns_sctp {
> /* Whether Cookie Preservative is enabled(1) or not(0) */
> int cookie_preserve_enable;
>
> + /* The namespace default hmac alg */
> + char *sctp_hmac_alg;
> +
> /* Valid.Cookie.Life - 60 seconds */
> unsigned int valid_cookie_life;
>
> diff --git a/include/net/sctp/constants.h b/include/net/sctp/constants.h
> index d053d2e..c29707d 100644
> --- a/include/net/sctp/constants.h
> +++ b/include/net/sctp/constants.h
> @@ -312,14 +312,6 @@ enum { SCTP_MAX_GABS = 16 };
> * functions simpler to write.
> */
>
> -#if defined (CONFIG_SCTP_HMAC_MD5)
> -#define SCTP_COOKIE_HMAC_ALG "hmac(md5)"
> -#elif defined (CONFIG_SCTP_HMAC_SHA1)
> -#define SCTP_COOKIE_HMAC_ALG "hmac(sha1)"
> -#else
> -#define SCTP_COOKIE_HMAC_ALG NULL
> -#endif
> -
> /* These return values describe the success or failure of a number of
> * routines which form the lower interface to SCTP_outqueue.
> */
> diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
> index 0fef00f..ce5f957 100644
> --- a/include/net/sctp/structs.h
> +++ b/include/net/sctp/structs.h
> @@ -177,6 +177,7 @@ struct sctp_sock {
>
> /* Access to HMAC transform. */
> struct crypto_hash *hmac;
> + char *sctp_hmac_alg;
>
> /* What is our base endpointer? */
> struct sctp_endpoint *ep;
> diff --git a/net/sctp/Kconfig b/net/sctp/Kconfig
> index 126b014..44ffd3e 100644
> --- a/net/sctp/Kconfig
> +++ b/net/sctp/Kconfig
> @@ -9,7 +9,6 @@ menuconfig IP_SCTP
> select CRYPTO
> select CRYPTO_HMAC
> select CRYPTO_SHA1
> - select CRYPTO_MD5 if SCTP_HMAC_MD5
> select LIBCRC32C
> ---help---
> Stream Control Transmission Protocol
> @@ -68,33 +67,4 @@ config SCTP_DBG_OBJCNT
>
> If unsure, say N
>
> -choice
> - prompt "SCTP: Cookie HMAC Algorithm"
> - default SCTP_HMAC_MD5
Did you intend to change the default algorithm to SHA1? Seems a bit
unintended and undocumented.
Would it make more sense to to change from a choice to sub-menu and
allow selection of multiple algorithms? Then use the interface you have
to change the default.
-vlad
> - help
> - HMAC algorithm to be used during association initialization. It
> - is strongly recommended to use HMAC-SHA1 or HMAC-MD5. See
> - configuration for Cryptographic API and enable those algorithms
> - to make usable by SCTP.
> -
> -config SCTP_HMAC_NONE
> - bool "None"
> - help
> - Choosing this disables the use of an HMAC during association
> - establishment. It is advised to use either HMAC-MD5 or HMAC-SHA1.
> -
> -config SCTP_HMAC_SHA1
> - bool "HMAC-SHA1"
> - help
> - Enable the use of HMAC-SHA1 during association establishment. It
> - is advised to use either HMAC-MD5 or HMAC-SHA1.
> -
> -config SCTP_HMAC_MD5
> - bool "HMAC-MD5"
> - help
> - Enable the use of HMAC-MD5 during association establishment. It is
> - advised to use either HMAC-MD5 or HMAC-SHA1.
> -
> -endchoice
> -
> endif # IP_SCTP
> diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
> index 2d51842..456bc3d 100644
> --- a/net/sctp/protocol.c
> +++ b/net/sctp/protocol.c
> @@ -1190,6 +1190,15 @@ static int sctp_net_init(struct net *net)
> /* Whether Cookie Preservative is enabled(1) or not(0) */
> net->sctp.cookie_preserve_enable = 1;
>
> + /* Default sctp sockets to use md5 as their hmac alg */
> +#if defined (CONFIG_CRYPTO_MD5)
> + net->sctp.sctp_hmac_alg = "md5";
> +#elif defined (CONFIG_CRYPTO_SHA1)
> + net->sctp.sctp_hmac_alg = "sha1";
> +#else
> + net->sctp.sctp_hmac_alg = NULL;
> +#endif
> +
> /* Max.Burst - 4 */
> net->sctp.max_burst = SCTP_DEFAULT_MAX_BURST;
>
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index d37d24f..c388262 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -109,7 +109,6 @@ static int sctp_do_bind(struct sock *, union sctp_addr *, int);
> static int sctp_autobind(struct sock *sk);
> static void sctp_sock_migrate(struct sock *, struct sock *,
> struct sctp_association *, sctp_socket_type_t);
> -static char *sctp_hmac_alg = SCTP_COOKIE_HMAC_ALG;
>
> extern struct kmem_cache *sctp_bucket_cachep;
> extern long sysctl_sctp_mem[3];
> @@ -3889,6 +3888,8 @@ SCTP_STATIC int sctp_init_sock(struct sock *sk)
> sp->default_rcv_context = 0;
> sp->max_burst = net->sctp.max_burst;
>
> + sp->sctp_hmac_alg = net->sctp.sctp_hmac_alg;
> +
> /* Initialize default setup parameters. These parameters
> * can be modified with the SCTP_INITMSG socket option or
> * overridden by the SCTP_INIT CMSG.
> @@ -5966,13 +5967,15 @@ SCTP_STATIC int sctp_listen_start(struct sock *sk, int backlog)
> struct sctp_sock *sp = sctp_sk(sk);
> struct sctp_endpoint *ep = sp->ep;
> struct crypto_hash *tfm = NULL;
> + char alg[32];
>
> /* Allocate HMAC for generating cookie. */
> - if (!sctp_sk(sk)->hmac && sctp_hmac_alg) {
> - tfm = crypto_alloc_hash(sctp_hmac_alg, 0, CRYPTO_ALG_ASYNC);
> + if (!sp->hmac && sp->sctp_hmac_alg) {
> + sprintf(alg, "hmac(%s)", sp->sctp_hmac_alg);
> + tfm = crypto_alloc_hash(alg, 0, CRYPTO_ALG_ASYNC);
> if (IS_ERR(tfm)) {
> net_info_ratelimited("failed to load transform for %s: %ld\n",
> - sctp_hmac_alg, PTR_ERR(tfm));
> + sp->sctp_hmac_alg, PTR_ERR(tfm));
> return -ENOSYS;
> }
> sctp_sk(sk)->hmac = tfm;
> diff --git a/net/sctp/sysctl.c b/net/sctp/sysctl.c
> index 70e3ba5..043889a 100644
> --- a/net/sctp/sysctl.c
> +++ b/net/sctp/sysctl.c
> @@ -62,6 +62,11 @@ extern long sysctl_sctp_mem[3];
> extern int sysctl_sctp_rmem[3];
> extern int sysctl_sctp_wmem[3];
>
> +static int proc_sctp_do_hmac_alg(ctl_table *ctl,
> + int write,
> + void __user *buffer, size_t *lenp,
> +
> + loff_t *ppos);
> static ctl_table sctp_table[] = {
> {
> .procname = "sctp_mem",
> @@ -147,6 +152,12 @@ static ctl_table sctp_net_table[] = {
> .proc_handler = proc_dointvec,
> },
> {
> + .procname = "cookie_hmac_alg",
> + .maxlen = 8,
> + .mode = 0644,
> + .proc_handler = proc_sctp_do_hmac_alg,
> + },
> + {
> .procname = "valid_cookie_life",
> .data = &init_net.sctp.valid_cookie_life,
> .maxlen = sizeof(unsigned int),
> @@ -289,6 +300,54 @@ static ctl_table sctp_net_table[] = {
> { /* sentinel */ }
> };
>
> +static int proc_sctp_do_hmac_alg(ctl_table *ctl,
> + int write,
> + void __user *buffer, size_t *lenp,
> + loff_t *ppos)
> +{
> + struct net *net = current->nsproxy->net_ns;
> + char tmp[8];
> + ctl_table tbl;
> + int ret;
> + int changed = 0;
> + char *none = "none";
> +
> + memset(&tbl, 0, sizeof(struct ctl_table));
> +
> + if (write) {
> + tbl.data = tmp;
> + tbl.maxlen = 8;
> + } else {
> + tbl.data = net->sctp.sctp_hmac_alg ? : none;
> + tbl.maxlen = strlen(tbl.data);
> + }
> + ret = proc_dostring(&tbl, write, buffer, lenp, ppos);
> +
> + if (write) {
> +#ifdef CONFIG_CRYPTO_MD5
> + if (!strncmp(tmp, "md5", 3)) {
> + net->sctp.sctp_hmac_alg = "md5";
> + changed = 1;
> + }
> +#endif
> +#ifdef CONFIG_CRYPTO_SHA1
> + if (!strncmp(tmp, "sha1", 4)) {
> + net->sctp.sctp_hmac_alg = "sha1";
> + changed = 1;
> + }
> +#endif
> + if (!strncmp(tmp, "none", 4)) {
> + net->sctp.sctp_hmac_alg = NULL;
> + changed = 1;
> + }
> +
> + if (!changed)
> + ret = -EINVAL;
> + }
> +
> + return ret;
> +}
> +
> int sctp_sysctl_net_register(struct net *net)
> {
> struct ctl_table *table;
>
^ permalink raw reply
* [PATCH] ixgbe: reduce PTP rx path overhead
From: Jiri Benc @ 2012-10-24 15:17 UTC (permalink / raw)
To: netdev
Cc: e1000-devel, Jeff Kirsher, Jesse Brandeburg, John Ronciak,
Andy Gospodarek
Hw timestamping code caused performance regression in ixgbe driver when the
timestamping is not enabled. The culprit is IXGBE_READ_REG call in the rx
path which is executed for every received skb. This call is not needed when
the timestamping is disabled or for non-ptp packets.
netperf results:
The ixge side of the connection was acting as a server, the netperf command
line on the other side was:
netperf -H 192.168.1.23 -T0,0 -t UDP_STREAM -l 20
The values below mean throughput as reported by netperf (local/remote), for
3 runs, with timestamping not enabled.
3.7.0-rc1+ with CONFIG_IXGBE_PTP off:
5373.83 / 3329.32
5721.88 / 3033.89
5653.42 / 3112.38
3.7.0-rc1+ with CONFIG_IXGBE_PTP on:
5233.64 / 1226.85
5448.67 / 1039.32
5421.36 / 1095.66
Patched 3.7.0-rc1+ with CONFIG_IXGBE_PTP on:
5594.72 / 2942.53
5428.95 / 3110.16
5343.56 / 3200.48
Reported-by: Jesper Brouer <jbrouer@redhat.com>
Signed-off-by: Jiri Benc <jbenc@redhat.com>
Signed-off-by: Andy Gospodarek <gospo@redhat.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c
index 5e71ddb..842ba15 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c
@@ -554,12 +554,14 @@ void ixgbe_ptp_rx_hwtstamp(struct ixgbe_q_vector *q_vector,
adapter = q_vector->adapter;
hw = &adapter->hw;
+ if (likely(!ixgbe_ptp_match(skb, adapter->rx_hwtstamp_filter)))
+ return;
+
tsyncrxctl = IXGBE_READ_REG(hw, IXGBE_TSYNCRXCTL);
/* Check if we have a valid timestamp and make sure the skb should
* have been timestamped */
- if (likely(!(tsyncrxctl & IXGBE_TSYNCRXCTL_VALID) ||
- !ixgbe_ptp_match(skb, adapter->rx_hwtstamp_filter)))
+ if (!(tsyncrxctl & IXGBE_TSYNCRXCTL_VALID))
return;
/*
--
1.7.6.5
^ permalink raw reply related
* Re: [PATCH] net: allow configuration of the size of page in __netdev_alloc_frag
From: Eric Dumazet @ 2012-10-24 15:21 UTC (permalink / raw)
To: Ian Campbell
Cc: netdev@vger.kernel.org, Eric Dumazet, Konrad Rzeszutek Wilk,
xen-devel@lists.xen.org
In-Reply-To: <1351087326.18035.50.camel@zakaz.uk.xensource.com>
On Wed, 2012-10-24 at 15:02 +0100, Ian Campbell wrote:
> On Wed, 2012-10-24 at 14:30 +0100, Eric Dumazet wrote:
> > It seems to me its a driver issue, for example
> > drivers/net/xen-netfront.c has assumptions that can be easily fixed.
>
> The netfront ->head thing is a separate (although perhaps related)
> issue, I intended to fix along the same lines as the previous netback
> except for some unfathomable reason I haven't been able to reproduce the
> problem with netfront -- I've no idea why though since it seems like it
> should be a no brainer!
>
> > Why skb->head can be on order-1 or order-2 pages and this is working ?
>
> skb->head being order 1 or 2 isn't working for me. The driver I'm having
> issues with which caused me to create this particular patch is the tg3
> driver (although I don't think this is by any means specific to tg3).
>
> For the ->head the tg3 driver does:
> mapping = pci_map_single(tp->pdev, skb->data, len, PCI_DMA_TODEVICE);
> while for the frags it does:
> mapping = skb_frag_dma_map(&tp->pdev->dev, frag, 0, len, DMA_TO_DEVICE);
>
> This ought to do the Right Thing but doesn't seem to be working. Konrad
> suspected an issue with the swiotlb's handling of order>0 pages in some
> cases. As I said in the commit message he is looking into this issue.
>
> My concern however was that even once the swiotlb is fixed to work right
> the effect of pci_map_single on a order>0 page is going to be that the
> data gets bounced into contiguous memory -- that is a memcpy which would
> undo the benefit of having allocating large pages to start with. So I
> figured that in such cases we'd be better off just using order 0
> allocations to start with.
I am really confused.
If you really have such problems, why locally generated TCP traffic
doesnt also have it ?
Your patch doesnt touch sk_page_frag_refill(), does it ?
^ permalink raw reply
* [PATCH] gianfar_ptp: use iomem, not ioports resource tree in probe
From: Paul Gortmaker @ 2012-10-24 15:21 UTC (permalink / raw)
To: netdev; +Cc: Wei Yang, Claudiu Manoil, Timur Tabi, Paul Gortmaker
From: Wei Yang <Wei.Yang@windriver.com>
When using a 36 bit dtb file, the driver complains "resource busy".
Investigating the source of the message leads one to the
gianfar_ptp_probe function.
Since the type of the device resource requested in this function
is IORESOURCE_MEM, it should use "iomem_resource" instead of
"ioports_resource".
Signed-off-by: Wei Yang <Wei.Yang@windriver.com>
Cc: Claudiu Manoil <claudiu.manoil@freescale.com>
Cc: Timur Tabi <timur@freescale.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
drivers/net/ethernet/freescale/gianfar_ptp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/gianfar_ptp.c b/drivers/net/ethernet/freescale/gianfar_ptp.c
index b9db0e0..2e5daee 100644
--- a/drivers/net/ethernet/freescale/gianfar_ptp.c
+++ b/drivers/net/ethernet/freescale/gianfar_ptp.c
@@ -478,7 +478,7 @@ static int gianfar_ptp_probe(struct platform_device *dev)
pr_err("no resource\n");
goto no_resource;
}
- if (request_resource(&ioport_resource, etsects->rsrc)) {
+ if (request_resource(&iomem_resource, etsects->rsrc)) {
pr_err("resource busy\n");
goto no_resource;
}
--
1.7.11.1
^ permalink raw reply related
* [RFC PATCH net-next v2 0/5] Allow to monitor protocol configuration
From: Nicolas Dichtel @ 2012-10-24 16:02 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <20121023.132940.1732325493436273627.davem@davemloft.net>
This patch serie aims to advertising via netlink any change in the network
configuration of a protocol (network or transport). For example the announcement
when ip forwarding parameter is toggled.
It adds a new kind of messages, RTM_NEWNETCONF/RTM_GETNETCONF.
The patch which adds the support of netconf messages in iproute2 will be sent
when the feature will be included. If someone is interested to get it before,
just tell me!
v2: rename functions to be consistent
specify type of the attribute to notify when calling
inet[6]_netconf_notify_devconf(), goal is to notify only thinks that
changed.
add RTM_GETNETCONF support
Comments are welcome.
Regards,
Nicolas
^ permalink raw reply
* [RFC PATCH net-next v2 1/5] rtnl: add a new type of msg to advertise protocol configuration
From: Nicolas Dichtel @ 2012-10-24 16:02 UTC (permalink / raw)
To: davem; +Cc: netdev, Nicolas Dichtel
In-Reply-To: <1351094579-3911-1-git-send-email-nicolas.dichtel@6wind.com>
A new type is added to allow userland to monitor protocol configuration, like
IPv4 or IPv6.
For example, monitoring the state of the forwarding status of an interface of
the system.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
include/uapi/linux/netconf.h | 22 ++++++++++++++++++++++
include/uapi/linux/rtnetlink.h | 5 +++++
2 files changed, 27 insertions(+)
create mode 100644 include/uapi/linux/netconf.h
diff --git a/include/uapi/linux/netconf.h b/include/uapi/linux/netconf.h
new file mode 100644
index 0000000..d051372
--- /dev/null
+++ b/include/uapi/linux/netconf.h
@@ -0,0 +1,22 @@
+#ifndef _UAPI_LINUX_NETCONF_H_
+#define _UAPI_LINUX_NETCONF_H_
+
+#include <linux/types.h>
+#include <linux/netlink.h>
+
+struct netconfmsg {
+ __u8 ncm_family;
+};
+
+enum {
+ NETCONFA_UNSPEC,
+ NETCONFA_IFINDEX,
+ NETCONFA_FORWARDING,
+ __NETCONFA_MAX
+};
+#define NETCONFA_MAX (__NETCONFA_MAX - 1)
+
+#define NETCONFA_IFINDEX_ALL -1
+#define NETCONFA_IFINDEX_DEFAULT -2
+
+#endif /* _UAPI_LINUX_NETCONF_H_ */
diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h
index fcd768b..0043b41 100644
--- a/include/uapi/linux/rtnetlink.h
+++ b/include/uapi/linux/rtnetlink.h
@@ -120,6 +120,11 @@ enum {
RTM_SETDCB,
#define RTM_SETDCB RTM_SETDCB
+ RTM_NEWNETCONF = 80,
+#define RTM_NEWNETCONF RTM_NEWNETCONF
+ RTM_GETNETCONF = 82,
+#define RTM_GETNETCONF RTM_GETNETCONF
+
__RTM_MAX,
#define RTM_MAX (((__RTM_MAX + 3) & ~3) - 1)
};
--
1.7.12
^ permalink raw reply related
* [RFC PATCH net-next v2 2/5] rtnl/ipv6: use netconf msg to advertise forwarding status
From: Nicolas Dichtel @ 2012-10-24 16:02 UTC (permalink / raw)
To: davem; +Cc: netdev, Nicolas Dichtel
In-Reply-To: <1351094579-3911-1-git-send-email-nicolas.dichtel@6wind.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
include/uapi/linux/rtnetlink.h | 2 ++
net/ipv6/addrconf.c | 77 ++++++++++++++++++++++++++++++++++++++++++
2 files changed, 79 insertions(+)
diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h
index 0043b41..a4d75ea 100644
--- a/include/uapi/linux/rtnetlink.h
+++ b/include/uapi/linux/rtnetlink.h
@@ -592,6 +592,8 @@ enum rtnetlink_groups {
#define RTNLGRP_PHONET_ROUTE RTNLGRP_PHONET_ROUTE
RTNLGRP_DCB,
#define RTNLGRP_DCB RTNLGRP_DCB
+ RTNLGRP_IPV6_NETCONF,
+#define RTNLGRP_IPV6_NETCONF RTNLGRP_IPV6_NETCONF
__RTNLGRP_MAX
};
#define RTNLGRP_MAX (__RTNLGRP_MAX - 1)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 0424e4e..9bf4d1b 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -81,6 +81,7 @@
#include <net/pkt_sched.h>
#include <linux/if_tunnel.h>
#include <linux/rtnetlink.h>
+#include <linux/netconf.h>
#ifdef CONFIG_IPV6_PRIVACY
#include <linux/random.h>
@@ -460,6 +461,72 @@ static struct inet6_dev *ipv6_find_idev(struct net_device *dev)
return idev;
}
+static inline int inet6_netconf_msgsize_devconf(int type)
+{
+ int size = NLMSG_ALIGN(sizeof(struct netconfmsg))
+ + nla_total_size(4); /* NETCONFA_IFINDEX */
+
+ if (type == NETCONFA_FORWARDING)
+ size += nla_total_size(4);
+
+ return size;
+}
+
+static int inet6_netconf_fill_devconf(struct sk_buff *skb, int ifindex,
+ struct ipv6_devconf *devconf, u32 portid,
+ u32 seq, int event, unsigned int flags,
+ int type)
+{
+ struct nlmsghdr *nlh;
+ struct netconfmsg *ncm;
+
+ nlh = nlmsg_put(skb, portid, seq, event, sizeof(struct netconfmsg),
+ flags);
+ if (nlh == NULL)
+ return -EMSGSIZE;
+
+ ncm = nlmsg_data(nlh);
+ ncm->ncm_family = AF_INET6;
+
+ if (nla_put_s32(skb, NETCONFA_IFINDEX, ifindex) < 0)
+ goto nla_put_failure;
+
+ if (type == NETCONFA_FORWARDING &&
+ nla_put_s32(skb, NETCONFA_FORWARDING, devconf->forwarding) < 0)
+ goto nla_put_failure;
+
+ return nlmsg_end(skb, nlh);
+
+nla_put_failure:
+ nlmsg_cancel(skb, nlh);
+ return -EMSGSIZE;
+}
+
+static void inet6_netconf_notify_devconf(struct net *net, int type, int ifindex,
+ struct ipv6_devconf *devconf)
+{
+ struct sk_buff *skb;
+ int err = -ENOBUFS;
+
+ skb = nlmsg_new(inet6_netconf_msgsize_devconf(type), GFP_ATOMIC);
+ if (skb == NULL)
+ goto errout;
+
+ err = inet6_netconf_fill_devconf(skb, ifindex, devconf, 0, 0,
+ RTM_NEWNETCONF, 0, type);
+ if (err < 0) {
+ /* -EMSGSIZE implies BUG in inet6_netconf_msgsize_devconf() */
+ WARN_ON(err == -EMSGSIZE);
+ kfree_skb(skb);
+ goto errout;
+ }
+ rtnl_notify(skb, net, 0, RTNLGRP_IPV6_NETCONF, NULL, GFP_ATOMIC);
+ return;
+errout:
+ if (err < 0)
+ rtnl_set_sk_err(net, RTNLGRP_IPV6_NETCONF, err);
+}
+
#ifdef CONFIG_SYSCTL
static void dev_forward_change(struct inet6_dev *idev)
{
@@ -486,6 +553,8 @@ static void dev_forward_change(struct inet6_dev *idev)
else
addrconf_leave_anycast(ifa);
}
+ inet6_netconf_notify_devconf(dev_net(dev), NETCONFA_FORWARDING,
+ dev->ifindex, &idev->cnf);
}
@@ -518,6 +587,10 @@ static int addrconf_fixup_forwarding(struct ctl_table *table, int *p, int newf)
*p = newf;
if (p == &net->ipv6.devconf_dflt->forwarding) {
+ if ((!newf) ^ (!old))
+ inet6_netconf_notify_devconf(net, NETCONFA_FORWARDING,
+ NETCONFA_IFINDEX_DEFAULT,
+ net->ipv6.devconf_dflt);
rtnl_unlock();
return 0;
}
@@ -525,6 +598,10 @@ static int addrconf_fixup_forwarding(struct ctl_table *table, int *p, int newf)
if (p == &net->ipv6.devconf_all->forwarding) {
net->ipv6.devconf_dflt->forwarding = newf;
addrconf_forward_change(net, newf);
+ if ((!newf) ^ (!old))
+ inet6_netconf_notify_devconf(net, NETCONFA_FORWARDING,
+ NETCONFA_IFINDEX_ALL,
+ net->ipv6.devconf_all);
} else if ((!newf) ^ (!old))
dev_forward_change((struct inet6_dev *)table->extra1);
rtnl_unlock();
--
1.7.12
^ permalink raw reply related
* [RFC PATCH net-next v2 3/5] rtnl/ipv6: add support of RTM_GETNETCONF
From: Nicolas Dichtel @ 2012-10-24 16:02 UTC (permalink / raw)
To: davem; +Cc: netdev, Nicolas Dichtel
In-Reply-To: <1351094579-3911-1-git-send-email-nicolas.dichtel@6wind.com>
This message allows to get the devconf for an interface.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
net/ipv6/addrconf.c | 75 +++++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 73 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 9bf4d1b..dbab3ad 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -466,7 +466,8 @@ static inline int inet6_netconf_msgsize_devconf(int type)
int size = NLMSG_ALIGN(sizeof(struct netconfmsg))
+ nla_total_size(4); /* NETCONFA_IFINDEX */
- if (type == NETCONFA_FORWARDING)
+ /* type -1 is used for ALL */
+ if (type == -1 || type == NETCONFA_FORWARDING)
size += nla_total_size(4);
return size;
@@ -491,7 +492,8 @@ static int inet6_netconf_fill_devconf(struct sk_buff *skb, int ifindex,
if (nla_put_s32(skb, NETCONFA_IFINDEX, ifindex) < 0)
goto nla_put_failure;
- if (type == NETCONFA_FORWARDING &&
+ /* type -1 is used for ALL */
+ if ((type == -1 || type == NETCONFA_FORWARDING) &&
nla_put_s32(skb, NETCONFA_FORWARDING, devconf->forwarding) < 0)
goto nla_put_failure;
@@ -527,6 +529,73 @@ errout:
rtnl_set_sk_err(net, RTNLGRP_IPV6_NETCONF, err);
}
+static const struct nla_policy devconf_ipv6_policy[NETCONFA_MAX+1] = {
+ [NETCONFA_IFINDEX] = { .len = sizeof(int) },
+ [NETCONFA_FORWARDING] = { .len = sizeof(int) },
+};
+
+static int inet6_netconf_get_devconf(struct sk_buff *in_skb,
+ struct nlmsghdr *nlh,
+ void *arg)
+{
+ struct net *net = sock_net(in_skb->sk);
+ struct nlattr *tb[NETCONFA_MAX+1];
+ struct netconfmsg *ncm;
+ struct sk_buff *skb;
+ struct ipv6_devconf *devconf;
+ struct inet6_dev *in6_dev;
+ struct net_device *dev;
+ int ifindex;
+ int err;
+
+ err = nlmsg_parse(nlh, sizeof(*ncm), tb, NETCONFA_MAX,
+ devconf_ipv6_policy);
+ if (err < 0)
+ goto errout;
+
+ err = EINVAL;
+ if (!tb[NETCONFA_IFINDEX])
+ goto errout;
+
+ ifindex = nla_get_s32(tb[NETCONFA_IFINDEX]);
+ switch (ifindex) {
+ case NETCONFA_IFINDEX_ALL:
+ devconf = net->ipv6.devconf_all;
+ break;
+ case NETCONFA_IFINDEX_DEFAULT:
+ devconf = net->ipv6.devconf_dflt;
+ break;
+ default:
+ dev = __dev_get_by_index(net, ifindex);
+ if (dev == NULL)
+ goto errout;
+ in6_dev = __in6_dev_get(dev);
+ if (in6_dev == NULL)
+ goto errout;
+ devconf = &in6_dev->cnf;
+ break;
+ }
+
+ err = -ENOBUFS;
+ skb = nlmsg_new(inet6_netconf_msgsize_devconf(-1), GFP_ATOMIC);
+ if (skb == NULL)
+ goto errout;
+
+ err = inet6_netconf_fill_devconf(skb, ifindex, devconf,
+ NETLINK_CB(in_skb).portid,
+ nlh->nlmsg_seq, RTM_NEWNETCONF, 0,
+ -1);
+ if (err < 0) {
+ /* -EMSGSIZE implies BUG in inet6_netconf_msgsize_devconf() */
+ WARN_ON(err == -EMSGSIZE);
+ kfree_skb(skb);
+ goto errout;
+ }
+ err = rtnl_unicast(skb, net, NETLINK_CB(in_skb).portid);
+errout:
+ return err;
+}
+
#ifdef CONFIG_SYSCTL
static void dev_forward_change(struct inet6_dev *idev)
{
@@ -4861,6 +4930,8 @@ int __init addrconf_init(void)
inet6_dump_ifmcaddr, NULL);
__rtnl_register(PF_INET6, RTM_GETANYCAST, NULL,
inet6_dump_ifacaddr, NULL);
+ __rtnl_register(PF_INET6, RTM_GETNETCONF, inet6_netconf_get_devconf,
+ NULL, NULL);
ipv6_addr_label_rtnl_register();
--
1.7.12
^ permalink raw reply related
* [RFC PATCH net-next v2 4/5] rtnl/ipv4: use netconf msg to advertise forwarding status
From: Nicolas Dichtel @ 2012-10-24 16:02 UTC (permalink / raw)
To: davem; +Cc: netdev, Nicolas Dichtel
In-Reply-To: <1351094579-3911-1-git-send-email-nicolas.dichtel@6wind.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
include/uapi/linux/rtnetlink.h | 2 +
net/ipv4/devinet.c | 93 ++++++++++++++++++++++++++++++++++++++++--
2 files changed, 91 insertions(+), 4 deletions(-)
diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h
index a4d75ea..3dee071 100644
--- a/include/uapi/linux/rtnetlink.h
+++ b/include/uapi/linux/rtnetlink.h
@@ -592,6 +592,8 @@ enum rtnetlink_groups {
#define RTNLGRP_PHONET_ROUTE RTNLGRP_PHONET_ROUTE
RTNLGRP_DCB,
#define RTNLGRP_DCB RTNLGRP_DCB
+ RTNLGRP_IPV4_NETCONF,
+#define RTNLGRP_IPV4_NETCONF RTNLGRP_IPV4_NETCONF
RTNLGRP_IPV6_NETCONF,
#define RTNLGRP_IPV6_NETCONF RTNLGRP_IPV6_NETCONF
__RTNLGRP_MAX
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 2a6abc1..845fe48 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -55,6 +55,7 @@
#include <linux/sysctl.h>
#endif
#include <linux/kmod.h>
+#include <linux/netconf.h>
#include <net/arp.h>
#include <net/ip.h>
@@ -1442,6 +1443,73 @@ static int inet_set_link_af(struct net_device *dev, const struct nlattr *nla)
return 0;
}
+static inline int inet_netconf_msgsize_devconf(int type)
+{
+ int size = NLMSG_ALIGN(sizeof(struct netconfmsg))
+ + nla_total_size(4); /* NETCONFA_IFINDEX */
+
+ if (type == NETCONFA_FORWARDING)
+ size += nla_total_size(4);
+
+ return size;
+}
+
+static int inet_netconf_fill_devconf(struct sk_buff *skb, int ifindex,
+ struct ipv4_devconf *devconf, u32 portid,
+ u32 seq, int event, unsigned int flags,
+ int type)
+{
+ struct nlmsghdr *nlh;
+ struct netconfmsg *ncm;
+
+ nlh = nlmsg_put(skb, portid, seq, event, sizeof(struct netconfmsg),
+ flags);
+ if (nlh == NULL)
+ return -EMSGSIZE;
+
+ ncm = nlmsg_data(nlh);
+ ncm->ncm_family = AF_INET;
+
+ if (nla_put_s32(skb, NETCONFA_IFINDEX, ifindex) < 0)
+ goto nla_put_failure;
+
+ if (type == NETCONFA_FORWARDING &&
+ nla_put_s32(skb, NETCONFA_FORWARDING,
+ IPV4_DEVCONF(*devconf, FORWARDING)) < 0)
+ goto nla_put_failure;
+
+ return nlmsg_end(skb, nlh);
+
+nla_put_failure:
+ nlmsg_cancel(skb, nlh);
+ return -EMSGSIZE;
+}
+
+static void inet_netconf_notify_devconf(struct net *net, int type, int ifindex,
+ struct ipv4_devconf *devconf)
+{
+ struct sk_buff *skb;
+ int err = -ENOBUFS;
+
+ skb = nlmsg_new(inet_netconf_msgsize_devconf(type), GFP_ATOMIC);
+ if (skb == NULL)
+ goto errout;
+
+ err = inet_netconf_fill_devconf(skb, ifindex, devconf, 0, 0,
+ RTM_NEWNETCONF, 0, type);
+ if (err < 0) {
+ /* -EMSGSIZE implies BUG in inet_netconf_msgsize_devconf() */
+ WARN_ON(err == -EMSGSIZE);
+ kfree_skb(skb);
+ goto errout;
+ }
+ rtnl_notify(skb, net, 0, RTNLGRP_IPV4_NETCONF, NULL, GFP_ATOMIC);
+ return;
+errout:
+ if (err < 0)
+ rtnl_set_sk_err(net, RTNLGRP_IPV4_NETCONF, err);
+}
+
#ifdef CONFIG_SYSCTL
static void devinet_copy_dflt_conf(struct net *net, int i)
@@ -1467,6 +1535,12 @@ static void inet_forward_change(struct net *net)
IPV4_DEVCONF_ALL(net, ACCEPT_REDIRECTS) = !on;
IPV4_DEVCONF_DFLT(net, FORWARDING) = on;
+ inet_netconf_notify_devconf(net, NETCONFA_FORWARDING,
+ NETCONFA_IFINDEX_ALL,
+ net->ipv4.devconf_all);
+ inet_netconf_notify_devconf(net, NETCONFA_FORWARDING,
+ NETCONFA_IFINDEX_DEFAULT,
+ net->ipv4.devconf_dflt);
for_each_netdev(net, dev) {
struct in_device *in_dev;
@@ -1474,8 +1548,11 @@ static void inet_forward_change(struct net *net)
dev_disable_lro(dev);
rcu_read_lock();
in_dev = __in_dev_get_rcu(dev);
- if (in_dev)
+ if (in_dev) {
IN_DEV_CONF_SET(in_dev, FORWARDING, on);
+ inet_netconf_notify_devconf(net, NETCONFA_FORWARDING,
+ dev->ifindex, &in_dev->cnf);
+ }
rcu_read_unlock();
}
}
@@ -1527,15 +1604,23 @@ static int devinet_sysctl_forward(ctl_table *ctl, int write,
}
if (valp == &IPV4_DEVCONF_ALL(net, FORWARDING)) {
inet_forward_change(net);
- } else if (*valp) {
+ } else {
struct ipv4_devconf *cnf = ctl->extra1;
struct in_device *idev =
container_of(cnf, struct in_device, cnf);
- dev_disable_lro(idev->dev);
+ if (*valp)
+ dev_disable_lro(idev->dev);
+ inet_netconf_notify_devconf(net,
+ NETCONFA_FORWARDING,
+ idev->dev->ifindex,
+ cnf);
}
rtnl_unlock();
rt_cache_flush(net);
- }
+ } else
+ inet_netconf_notify_devconf(net, NETCONFA_FORWARDING,
+ NETCONFA_IFINDEX_DEFAULT,
+ net->ipv4.devconf_dflt);
}
return ret;
--
1.7.12
^ permalink raw reply related
* [RFC PATCH net-next v2 5/5] rtnl/ipv4: add support of RTM_GETNETCONF
From: Nicolas Dichtel @ 2012-10-24 16:02 UTC (permalink / raw)
To: davem; +Cc: netdev, Nicolas Dichtel
In-Reply-To: <1351094579-3911-1-git-send-email-nicolas.dichtel@6wind.com>
This message allows to get the devconf for an interface.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
net/ipv4/devinet.c | 75 ++++++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 73 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 845fe48..2f522970 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -1448,7 +1448,8 @@ static inline int inet_netconf_msgsize_devconf(int type)
int size = NLMSG_ALIGN(sizeof(struct netconfmsg))
+ nla_total_size(4); /* NETCONFA_IFINDEX */
- if (type == NETCONFA_FORWARDING)
+ /* type -1 is used for ALL */
+ if (type == -1 || type == NETCONFA_FORWARDING)
size += nla_total_size(4);
return size;
@@ -1473,7 +1474,8 @@ static int inet_netconf_fill_devconf(struct sk_buff *skb, int ifindex,
if (nla_put_s32(skb, NETCONFA_IFINDEX, ifindex) < 0)
goto nla_put_failure;
- if (type == NETCONFA_FORWARDING &&
+ /* type -1 is used for ALL */
+ if ((type == -1 || type == NETCONFA_FORWARDING) &&
nla_put_s32(skb, NETCONFA_FORWARDING,
IPV4_DEVCONF(*devconf, FORWARDING)) < 0)
goto nla_put_failure;
@@ -1510,6 +1512,73 @@ errout:
rtnl_set_sk_err(net, RTNLGRP_IPV4_NETCONF, err);
}
+static const struct nla_policy devconf_ipv4_policy[NETCONFA_MAX+1] = {
+ [NETCONFA_IFINDEX] = { .len = sizeof(int) },
+ [NETCONFA_FORWARDING] = { .len = sizeof(int) },
+};
+
+static int inet_netconf_get_devconf(struct sk_buff *in_skb,
+ struct nlmsghdr *nlh,
+ void *arg)
+{
+ struct net *net = sock_net(in_skb->sk);
+ struct nlattr *tb[NETCONFA_MAX+1];
+ struct netconfmsg *ncm;
+ struct sk_buff *skb;
+ struct ipv4_devconf *devconf;
+ struct in_device *in_dev;
+ struct net_device *dev;
+ int ifindex;
+ int err;
+
+ err = nlmsg_parse(nlh, sizeof(*ncm), tb, NETCONFA_MAX,
+ devconf_ipv4_policy);
+ if (err < 0)
+ goto errout;
+
+ err = EINVAL;
+ if (!tb[NETCONFA_IFINDEX])
+ goto errout;
+
+ ifindex = nla_get_s32(tb[NETCONFA_IFINDEX]);
+ switch (ifindex) {
+ case NETCONFA_IFINDEX_ALL:
+ devconf = net->ipv4.devconf_all;
+ break;
+ case NETCONFA_IFINDEX_DEFAULT:
+ devconf = net->ipv4.devconf_dflt;
+ break;
+ default:
+ dev = __dev_get_by_index(net, ifindex);
+ if (dev == NULL)
+ goto errout;
+ in_dev = __in_dev_get_rtnl(dev);
+ if (in_dev == NULL)
+ goto errout;
+ devconf = &in_dev->cnf;
+ break;
+ }
+
+ err = -ENOBUFS;
+ skb = nlmsg_new(inet_netconf_msgsize_devconf(-1), GFP_ATOMIC);
+ if (skb == NULL)
+ goto errout;
+
+ err = inet_netconf_fill_devconf(skb, ifindex, devconf,
+ NETLINK_CB(in_skb).portid,
+ nlh->nlmsg_seq, RTM_NEWNETCONF, 0,
+ -1);
+ if (err < 0) {
+ /* -EMSGSIZE implies BUG in inet_netconf_msgsize_devconf() */
+ WARN_ON(err == -EMSGSIZE);
+ kfree_skb(skb);
+ goto errout;
+ }
+ err = rtnl_unicast(skb, net, NETLINK_CB(in_skb).portid);
+errout:
+ return err;
+}
+
#ifdef CONFIG_SYSCTL
static void devinet_copy_dflt_conf(struct net *net, int i)
@@ -1894,5 +1963,7 @@ void __init devinet_init(void)
rtnl_register(PF_INET, RTM_NEWADDR, inet_rtm_newaddr, NULL, NULL);
rtnl_register(PF_INET, RTM_DELADDR, inet_rtm_deladdr, NULL, NULL);
rtnl_register(PF_INET, RTM_GETADDR, NULL, inet_dump_ifaddr, NULL);
+ rtnl_register(PF_INET, RTM_GETNETCONF, inet_netconf_get_devconf,
+ NULL, NULL);
}
--
1.7.12
^ 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