* Re: [patch 2.6.12-rc5] tg3: add bcm5752 entry to pci.ids
From: David S. Miller @ 2005-05-27 20:41 UTC (permalink / raw)
To: jgarzik; +Cc: mchan, linville, linux-kernel, netdev
In-Reply-To: <429785B5.6020705@pobox.com>
From: Jeff Garzik <jgarzik@pobox.com>
Date: Fri, 27 May 2005 16:40:21 -0400
> pci.ids is only used in one location -- deprecated /proc/pci -- and will
> be removed in the next year or so, I imagine. Further, pci.ids is
> periodically sync'd en masse from sourceforge into the kernel by janitors.
Good point.
^ permalink raw reply
* Re: [patch 2.6.12-rc5] tg3: add bcm5752 entry to pci.ids
From: David S. Miller @ 2005-05-27 20:40 UTC (permalink / raw)
To: mchan; +Cc: linville, linux-kernel, netdev, jgarzik
In-Reply-To: <1117221859.4310.6.camel@rh4>
From: "Michael Chan" <mchan@broadcom.com>
Date: Fri, 27 May 2005 12:24:19 -0700
> So in the future, do we need to patch this file or just let sourceforge
> take care of it?
I think the proper procedure is to send it to sourceforge.
But there is some latency in the changes making it back
into the kernel.
Either way, if it is submitted to the kernel or sourceforge (or even
both), it ends up getting merged together in the end.
^ permalink raw reply
* Re: [patch 2.6.12-rc5] tg3: add bcm5752 entry to pci.ids
From: Jeff Garzik @ 2005-05-27 20:40 UTC (permalink / raw)
To: Michael Chan; +Cc: David S. Miller, linville, linux-kernel, netdev
In-Reply-To: <1117221859.4310.6.camel@rh4>
Michael Chan wrote:
> On Fri, 2005-05-27 at 12:30 -0700, David S. Miller wrote:
>
>
>>I'll apply this, thanks John.
>>
>>pci.ids needs several updates for tg3 in fact, and it
>>also now needs entries for bnx2 as well.
>>
>
>
> The bnx2 IDs are already in, probably from sourceforge. And the tg3 IDs
> look reasonably complete to me.
>
> So in the future, do we need to patch this file or just let sourceforge
> take care of it?
Honestly, pci.ids is such a non-critical file, unless DaveM disagrees I
would strongly encourage people to -only- send pci.ids updates to
sourceforge.
pci.ids is only used in one location -- deprecated /proc/pci -- and will
be removed in the next year or so, I imagine. Further, pci.ids is
periodically sync'd en masse from sourceforge into the kernel by janitors.
Users should be using 'lspci' not /proc/pci, and lspci takes it data
from sourceforge database not the kernel.
Jeff
^ permalink raw reply
* Re: RFC: NAPI packet weighting patch
From: Mitch Williams @ 2005-05-27 20:27 UTC (permalink / raw)
To: netdev, Stephen Hemminger, hadi, Robert.Olsson
Cc: Ronciak, John, Venkatesan, Ganesh, Brandeburg, Jesse
In-Reply-To: <20050527085055.79da3d75@dxpl.pdx.osdl.net>
Stephen, Robert, and Jamal all replied to my original message, and all
said approximately the same thing: "Why don't you just reduce the weight
in the driver? It does the same thing."
To which I reply, respectfully, I know that. And no it doesn't, not
exactly.
My primary reason for adding this setting is to allow for runtime tweaking
-- just like max_backlog has right now. Driver weight is a compile-time
setting, and has to be changed for every driver that you run.
This setting allows you to scale the weight of all your drivers, at
runtime, in one place. It's complimentary to Stephen's max_weight idea --
his patch affects how long you spend in any individual softirq; my patch
affects how long you spend in any driver's individual NAPI poll routine,
as well as how long the softirq lasts.
Perhaps we can merge the two patches to come up with some Ultimate
Tweakable Network Goodness. I'd be happy to do that (on Tuesday; I'm
heading home early today) if anybody's interested.
-Mitch
NB:
I've got a white paper that I wrote up for internal consumption. I plan
to post it to our Sourceforge archive, but I need to do a bunch of
scrubbing first, lest our lawyers go into convulsions.
Meanwhile, I can give away the ending: for my performance tests, on a
pure Gigabit network, I saw consistently better performance by a) using my
patch, b) reducing max_backlog, and c) using a nonzero value for
packet_weight.
^ permalink raw reply
* [patch linux-2.6.12-rc5 1/1] e1000: revert watchdog task
From: John W. Linville @ 2005-05-27 20:26 UTC (permalink / raw)
To: netdev; +Cc: jgarzik, ganesh.venkatesan, john.ronciak, cramerj
Undo the previous addition of the e1000_watchdog_task workqueue.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
After some discussion w/ the e1000 maintainers, we came to the
conclusion that the e1000_watchdog_task was at best unnecessary and
at worst caused more problems than it might solve.
This patch reverst the patch which created that workqueue (posted
3/14/2005).
drivers/net/e1000/e1000.h | 1 -
drivers/net/e1000/e1000_main.c | 15 ++-------------
2 files changed, 2 insertions(+), 14 deletions(-)
--- linux-2.6.12-rc5/drivers/net/e1000/e1000.h.orig 2005-05-27 16:15:47.478498035 -0400
+++ linux-2.6.12-rc5/drivers/net/e1000/e1000.h 2005-05-27 16:15:55.004463809 -0400
@@ -220,7 +220,6 @@ struct e1000_adapter {
spinlock_t stats_lock;
atomic_t irq_sem;
struct work_struct tx_timeout_task;
- struct work_struct watchdog_task;
uint8_t fc_autoneg;
struct timer_list blink_timer;
--- linux-2.6.12-rc5/drivers/net/e1000/e1000_main.c.orig 2005-05-27 16:15:47.480497760 -0400
+++ linux-2.6.12-rc5/drivers/net/e1000/e1000_main.c 2005-05-27 16:15:55.006463534 -0400
@@ -123,7 +123,6 @@ static void e1000_clean_rx_ring(struct e
static void e1000_set_multi(struct net_device *netdev);
static void e1000_update_phy_info(unsigned long data);
static void e1000_watchdog(unsigned long data);
-static void e1000_watchdog_task(struct e1000_adapter *adapter);
static void e1000_82547_tx_fifo_stall(unsigned long data);
static int e1000_xmit_frame(struct sk_buff *skb, struct net_device *netdev);
static struct net_device_stats * e1000_get_stats(struct net_device *netdev);
@@ -641,9 +640,6 @@ e1000_probe(struct pci_dev *pdev,
adapter->watchdog_timer.function = &e1000_watchdog;
adapter->watchdog_timer.data = (unsigned long) adapter;
- INIT_WORK(&adapter->watchdog_task,
- (void (*)(void *))e1000_watchdog_task, adapter);
-
init_timer(&adapter->phy_info_timer);
adapter->phy_info_timer.function = &e1000_update_phy_info;
adapter->phy_info_timer.data = (unsigned long) adapter;
@@ -1752,20 +1748,13 @@ e1000_82547_tx_fifo_stall(unsigned long
/**
* e1000_watchdog - Timer Call-back
- * @data: pointer to adapter cast into an unsigned long
+ * @data: pointer to netdev cast into an unsigned long
**/
+
static void
e1000_watchdog(unsigned long data)
{
struct e1000_adapter *adapter = (struct e1000_adapter *) data;
-
- /* Do the rest outside of interrupt context */
- schedule_work(&adapter->watchdog_task);
-}
-
-static void
-e1000_watchdog_task(struct e1000_adapter *adapter)
-{
struct net_device *netdev = adapter->netdev;
struct e1000_desc_ring *txdr = &adapter->tx_ring;
uint32_t link;
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: [patch 2.6.12-rc5] tg3: add bcm5752 entry to pci.ids
From: David S. Miller @ 2005-05-27 19:30 UTC (permalink / raw)
To: linville; +Cc: linux-kernel, netdev, jgarzik, mchan
In-Reply-To: <20050527184750.GB11592@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Fri, 27 May 2005 14:47:52 -0400
> Update pci.ids for BCM5752
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
I'll apply this, thanks John.
pci.ids needs several updates for tg3 in fact, and it
also now needs entries for bnx2 as well.
^ permalink raw reply
* Re: [patch 2.6.12-rc5] tg3: add bcm5752 entry to pci.ids
From: Michael Chan @ 2005-05-27 19:24 UTC (permalink / raw)
To: David S. Miller; +Cc: linville, linux-kernel, netdev, jgarzik
In-Reply-To: <20050527.123037.68041200.davem@davemloft.net>
On Fri, 2005-05-27 at 12:30 -0700, David S. Miller wrote:
> I'll apply this, thanks John.
>
> pci.ids needs several updates for tg3 in fact, and it
> also now needs entries for bnx2 as well.
>
The bnx2 IDs are already in, probably from sourceforge. And the tg3 IDs
look reasonably complete to me.
So in the future, do we need to patch this file or just let sourceforge
take care of it?
^ permalink raw reply
* Re: [PATCH 2.6.12-rc4] IPv4/IPv6: UDP Large Send Offload feature
From: David S. Miller @ 2005-05-27 19:03 UTC (permalink / raw)
To: shemminger
Cc: ravinandan.arakali, jgarzik, netdev, raghavendra.koushik,
leonid.grossman, ananda.raju, rapuru.sriram
In-Reply-To: <20050527085713.373d702a@dxpl.pdx.osdl.net>
From: Stephen Hemminger <shemminger@osdl.org>
Date: Fri, 27 May 2005 08:57:13 -0700
> The only downside is that it might encourage continued use of NFS over UDP.
> Perhaps we need a big fat warning in NFS that says:
>
> *** Your using NFS over UDP, your data integrity is no longer guaranteed;
> *** you have been warned.
I agree, I think the NFS client should print out something
like this when it mounts a volume over UDP for the first
time.
^ permalink raw reply
* Re: [PATCH 2.6.12-rc4] IPv4/IPv6: UDP Large Send Offload feature
From: David S. Miller @ 2005-05-27 19:02 UTC (permalink / raw)
To: ravinandan.arakali
Cc: jgarzik, netdev, raghavendra.koushik, leonid.grossman,
ananda.raju, rapuru.sriram
In-Reply-To: <000a01c562d9$9b661130$3910100a@pc.s2io.com>
From: "Ravinandan Arakali" <ravinandan.arakali@neterion.com>
Date: Fri, 27 May 2005 09:32:00 -0700
> Thanks for the quick feedback.
> At that time when we considered using skb_shinfo(skb)->fraglist,
> it contained fragments of MTU size. So, for a 60k udp datagram
> and 1500 MTU we will have 60k/1500 = 45 fragments which is
> more than MAX_SKB_FRAGS(18).
>
> However we will relook at fraglist for the possibility of increasing
> frag size to >MTU.
MAX_SKB_FRAGS controls the limit of skb_shinfo(skb)->frags[]
entries, not how many SKBs may be chained via
skb_shinfo(skb)->fraglist, there is no limit on the latter.
Note that there is much coalescing that can be performed on
the SKB list data areas, particularly if UDP sendfile() is
being used.
But such coalescing is messy to be performing inside of the
drivers. It may end up being the case that your approach
ends up being a better one for these reasons.
^ permalink raw reply
* Re: [patch 2.6.12-rc5] tg3: add bcm5752 entry to pci.ids
From: Christoph Hellwig @ 2005-05-27 19:02 UTC (permalink / raw)
To: Christoph Hellwig, David S. Miller, linux-kernel, netdev, jgarzik,
mchan
In-Reply-To: <20050527190000.GC11592@tuxdriver.com>
On Fri, May 27, 2005 at 03:00:00PM -0400, John W. Linville wrote:
> On Fri, May 27, 2005 at 07:53:35PM +0100, Christoph Hellwig wrote:
> > On Fri, May 27, 2005 at 02:47:52PM -0400, John W. Linville wrote:
>
> > > + 1600 NetXtreme BCM5752 Gigabit Ethernet PCI Express
> >
> > I don't think you should mention "PCI Express" here. That can trivially
> > befound it looking at the configuration header.
>
> I'm just following what is at pciids.sourceforge.net. Plus, it is
> already like that for nine other IDs:
>
> 1659 NetXtreme BCM5721 Gigabit Ethernet PCI Express
> 1677 NetXtreme BCM5751 Gigabit Ethernet PCI Express
> 167d NetXtreme BCM5751M Gigabit Ethernet PCI Express
> 167e NetXtreme BCM5751F Fast Ethernet PCI Express
> 169d NetLink BCM5789 Gigabit Ethernet PCI Express
> 16dd NetLink BCM5781 Gigabit Ethernet PCI Express
> 16f7 NetXtreme BCM5753 Gigabit Ethernet PCI Express
> 16fd NetXtreme BCM5753M Gigabit Ethernet PCI Express
> 16fe NetXtreme BCM5753F Fast Ethernet PCI Express
>
> The Broadcom guys can speak-up, but I figure they know if "PCI Express"
> is appropriate for their device... :-)
ok, it should be an all or nothing. I still think it's more than silly..
^ permalink raw reply
* Re: [patch 2.6.12-rc5] tg3: add bcm5752 entry to pci.ids
From: John W. Linville @ 2005-05-27 19:00 UTC (permalink / raw)
To: Christoph Hellwig, David S. Miller, linux-kernel, netdev, jgarzik,
mchan
In-Reply-To: <20050527185334.GA7417@infradead.org>
On Fri, May 27, 2005 at 07:53:35PM +0100, Christoph Hellwig wrote:
> On Fri, May 27, 2005 at 02:47:52PM -0400, John W. Linville wrote:
> > + 1600 NetXtreme BCM5752 Gigabit Ethernet PCI Express
>
> I don't think you should mention "PCI Express" here. That can trivially
> befound it looking at the configuration header.
I'm just following what is at pciids.sourceforge.net. Plus, it is
already like that for nine other IDs:
1659 NetXtreme BCM5721 Gigabit Ethernet PCI Express
1677 NetXtreme BCM5751 Gigabit Ethernet PCI Express
167d NetXtreme BCM5751M Gigabit Ethernet PCI Express
167e NetXtreme BCM5751F Fast Ethernet PCI Express
169d NetLink BCM5789 Gigabit Ethernet PCI Express
16dd NetLink BCM5781 Gigabit Ethernet PCI Express
16f7 NetXtreme BCM5753 Gigabit Ethernet PCI Express
16fd NetXtreme BCM5753M Gigabit Ethernet PCI Express
16fe NetXtreme BCM5753F Fast Ethernet PCI Express
The Broadcom guys can speak-up, but I figure they know if "PCI Express"
is appropriate for their device... :-)
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: [patch 2.6.12-rc5] tg3: add bcm5752 entry to pci.ids
From: Christoph Hellwig @ 2005-05-27 18:53 UTC (permalink / raw)
To: David S. Miller, linux-kernel, netdev, jgarzik, mchan
In-Reply-To: <20050527184750.GB11592@tuxdriver.com>
On Fri, May 27, 2005 at 02:47:52PM -0400, John W. Linville wrote:
> Update pci.ids for BCM5752
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> ---
>
> drivers/pci/pci.ids | 1 +
> 1 files changed, 1 insertion(+)
>
> --- tg3-pci/drivers/pci/pci.ids.orig 2005-05-27 14:41:25.243607911 -0400
> +++ tg3-pci/drivers/pci/pci.ids 2005-05-27 14:43:45.553326412 -0400
> @@ -7173,6 +7173,7 @@
> 080f Sentry5 DDR/SDR RAM Controller
> 0811 Sentry5 External Interface Core
> 0816 BCM3302 Sentry5 MIPS32 CPU
> + 1600 NetXtreme BCM5752 Gigabit Ethernet PCI Express
I don't think you should mention "PCI Express" here. That can trivially
befound it looking at the configuration header.
^ permalink raw reply
* [patch 2.6.12-rc5] tg3: add bcm5752 entry to pci.ids
From: John W. Linville @ 2005-05-27 18:47 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel, netdev, jgarzik, mchan
In-Reply-To: <20050421165956.55bdcb14.davem@davemloft.net>
Update pci.ids for BCM5752
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/pci/pci.ids | 1 +
1 files changed, 1 insertion(+)
--- tg3-pci/drivers/pci/pci.ids.orig 2005-05-27 14:41:25.243607911 -0400
+++ tg3-pci/drivers/pci/pci.ids 2005-05-27 14:43:45.553326412 -0400
@@ -7173,6 +7173,7 @@
080f Sentry5 DDR/SDR RAM Controller
0811 Sentry5 External Interface Core
0816 BCM3302 Sentry5 MIPS32 CPU
+ 1600 NetXtreme BCM5752 Gigabit Ethernet PCI Express
1644 NetXtreme BCM5700 Gigabit Ethernet
1014 0277 Broadcom Vigil B5700 1000Base-T
1028 00d1 Broadcom BCM5700
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: [patch 2.6.12-rc5] tg3: add bcm5752 entry to pci.ids
From: Michael Chan @ 2005-05-27 18:12 UTC (permalink / raw)
To: John W. Linville
Cc: Christoph Hellwig, David S. Miller, linux-kernel, netdev, jgarzik,
lusinsky
In-Reply-To: <20050527190000.GC11592@tuxdriver.com>
On Fri, 2005-05-27 at 15:00 -0400, John W. Linville wrote:
> On Fri, May 27, 2005 at 07:53:35PM +0100, Christoph Hellwig wrote:
> > On Fri, May 27, 2005 at 02:47:52PM -0400, John W. Linville wrote:
>
> > > + 1600 NetXtreme BCM5752 Gigabit Ethernet PCI Express
> >
> > I don't think you should mention "PCI Express" here. That can trivially
> > befound it looking at the configuration header.
>
> I'm just following what is at pciids.sourceforge.net. Plus, it is
> already like that for nine other IDs:
>
> 1659 NetXtreme BCM5721 Gigabit Ethernet PCI Express
> 1677 NetXtreme BCM5751 Gigabit Ethernet PCI Express
> 167d NetXtreme BCM5751M Gigabit Ethernet PCI Express
> 167e NetXtreme BCM5751F Fast Ethernet PCI Express
> 169d NetLink BCM5789 Gigabit Ethernet PCI Express
> 16dd NetLink BCM5781 Gigabit Ethernet PCI Express
> 16f7 NetXtreme BCM5753 Gigabit Ethernet PCI Express
> 16fd NetXtreme BCM5753M Gigabit Ethernet PCI Express
> 16fe NetXtreme BCM5753F Fast Ethernet PCI Express
>
> The Broadcom guys can speak-up, but I figure they know if "PCI Express"
> is appropriate for their device... :-)
>
Yes, "PCI Express" is appropriate. Thanks John.
^ permalink raw reply
* Re: A new driver for Broadcom bcm5706
From: Christoph Hellwig @ 2005-05-27 17:15 UTC (permalink / raw)
To: Michael Chan; +Cc: Christoph Hellwig, davem, jgarzik, netdev, ffan, lusinsky
In-Reply-To: <1117209503.4584.11.camel@rh4>
On Fri, May 27, 2005 at 08:58:23AM -0700, Michael Chan wrote:
> > These defintions overlap older 10MB/s defintions. I don't think the number
> > space is scare enough to need this hack. If we absolutely want to keep it
> > you should at least add some big comments explaining it.
> >
> >
> Yes they do. But these overlapping bit definitions are defined by the
> 802.3 standard for 1000Base-X. These are not Broadcom proprietary
> definitions.
Ok, makes a lot of sense. Now just mention that in a nice comment in
ethtool.h :)
^ permalink raw reply
* [PATCH 2/2] [NETLINK] Correctly set NLM_F_MULTI without checking the pid
From: Thomas Graf @ 2005-05-27 17:01 UTC (permalink / raw)
To: jamal; +Cc: David S. Miller, netdev
In-Reply-To: <20050527165935.GC15391@postel.suug.ch>
This patch rectifies some rtnetlink message builders that derive the
flags from the pid. It is now explicit like the other cases
which get it right. Also fixes half a dozen dumpers which did not
set NLM_F_MULTI at all.
Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
Signed-off-by: Thomas Graf <tgraf@suug.ch>
---
commit b20a9fb4f28c4397096cf3c745c42cf045c36a7a
tree 5144b4dc6ffa4fb1821eb758838f63c5e210bc34
parent 1eb85f52f4e0d23996f6aa49009ce02fc0579658
author Thomas Graf <tgraf@suug.ch> Fri, 27 May 2005 18:58:48 +0200
committer Thomas Graf <tgraf@suug.ch> Fri, 27 May 2005 18:58:48 +0200
net/core/neighbour.c | 14 ++++++-------
net/core/rtnetlink.c | 13 +++++++-----
net/decnet/dn_dev.c | 9 ++++----
net/decnet/dn_route.c | 11 +++++-----
net/decnet/dn_rules.c | 7 +++---
net/decnet/dn_table.c | 8 +++----
net/ipv4/devinet.c | 9 +++-----
net/ipv4/fib_hash.c | 3 +-
net/ipv4/fib_lookup.h | 3 +-
net/ipv4/fib_rules.c | 7 +++---
net/ipv4/fib_semantics.c | 6 ++---
net/ipv4/route.c | 11 ++++------
net/ipv6/addrconf.c | 49 ++++++++++++++++++++++-------------------------
net/ipv6/route.c | 11 +++++-----
14 files changed, 83 insertions(+), 78 deletions(-)
Index: net/core/neighbour.c
===================================================================
--- debb58e5f900a6551f751b457226250cfccc3c75/net/core/neighbour.c (mode:100644)
+++ 5144b4dc6ffa4fb1821eb758838f63c5e210bc34/net/core/neighbour.c (mode:100644)
@@ -1857,18 +1857,17 @@
}
static int neigh_fill_info(struct sk_buff *skb, struct neighbour *n,
- u32 pid, u32 seq, int event)
+ u32 pid, u32 seq, int event, unsigned int flags)
{
unsigned long now = jiffies;
unsigned char *b = skb->tail;
struct nda_cacheinfo ci;
int locked = 0;
u32 probes;
- struct nlmsghdr *nlh = NLMSG_PUT(skb, pid, seq, event,
- sizeof(struct ndmsg));
+ struct nlmsghdr *nlh = NLMSG_NEW(skb, pid, seq, event,
+ sizeof(struct ndmsg), flags);
struct ndmsg *ndm = NLMSG_DATA(nlh);
- nlh->nlmsg_flags = pid ? NLM_F_MULTI : 0;
ndm->ndm_family = n->ops->family;
ndm->ndm_flags = n->flags;
ndm->ndm_type = n->type;
@@ -1918,7 +1917,8 @@
continue;
if (neigh_fill_info(skb, n, NETLINK_CB(cb->skb).pid,
cb->nlh->nlmsg_seq,
- RTM_NEWNEIGH) <= 0) {
+ RTM_NEWNEIGH,
+ NLM_F_MULTI) <= 0) {
read_unlock_bh(&tbl->lock);
rc = -1;
goto out;
@@ -2327,7 +2327,7 @@
if (!skb)
return;
- if (neigh_fill_info(skb, n, 0, 0, RTM_GETNEIGH) < 0) {
+ if (neigh_fill_info(skb, n, 0, 0, RTM_GETNEIGH, 0) < 0) {
kfree_skb(skb);
return;
}
@@ -2346,7 +2346,7 @@
if (!skb)
return;
- if (neigh_fill_info(skb, n, 0, 0, RTM_NEWNEIGH) < 0) {
+ if (neigh_fill_info(skb, n, 0, 0, RTM_NEWNEIGH, 0) < 0) {
kfree_skb(skb);
return;
}
Index: net/core/rtnetlink.c
===================================================================
--- debb58e5f900a6551f751b457226250cfccc3c75/net/core/rtnetlink.c (mode:100644)
+++ 5144b4dc6ffa4fb1821eb758838f63c5e210bc34/net/core/rtnetlink.c (mode:100644)
@@ -178,14 +178,14 @@
static int rtnetlink_fill_ifinfo(struct sk_buff *skb, struct net_device *dev,
- int type, u32 pid, u32 seq, u32 change)
+ int type, u32 pid, u32 seq, u32 change,
+ unsigned int flags)
{
struct ifinfomsg *r;
struct nlmsghdr *nlh;
unsigned char *b = skb->tail;
- nlh = NLMSG_PUT(skb, pid, seq, type, sizeof(*r));
- if (pid) nlh->nlmsg_flags |= NLM_F_MULTI;
+ nlh = NLMSG_NEW(skb, pid, seq, type, sizeof(*r), flags);
r = NLMSG_DATA(nlh);
r->ifi_family = AF_UNSPEC;
r->ifi_type = dev->type;
@@ -275,7 +275,10 @@
for (dev=dev_base, idx=0; dev; dev = dev->next, idx++) {
if (idx < s_idx)
continue;
- if (rtnetlink_fill_ifinfo(skb, dev, RTM_NEWLINK, NETLINK_CB(cb->skb).pid, cb->nlh->nlmsg_seq, 0) <= 0)
+ if (rtnetlink_fill_ifinfo(skb, dev, RTM_NEWLINK,
+ NETLINK_CB(cb->skb).pid,
+ cb->nlh->nlmsg_seq, 0,
+ NLM_F_MULTI) <= 0)
break;
}
read_unlock(&dev_base_lock);
@@ -449,7 +452,7 @@
if (!skb)
return;
- if (rtnetlink_fill_ifinfo(skb, dev, type, 0, 0, change) < 0) {
+ if (rtnetlink_fill_ifinfo(skb, dev, type, 0, 0, change, 0) < 0) {
kfree_skb(skb);
return;
}
Index: net/decnet/dn_dev.c
===================================================================
--- debb58e5f900a6551f751b457226250cfccc3c75/net/decnet/dn_dev.c (mode:100644)
+++ 5144b4dc6ffa4fb1821eb758838f63c5e210bc34/net/decnet/dn_dev.c (mode:100644)
@@ -716,13 +716,13 @@
}
static int dn_dev_fill_ifaddr(struct sk_buff *skb, struct dn_ifaddr *ifa,
- u32 pid, u32 seq, int event)
+ u32 pid, u32 seq, int event, unsigned int flags)
{
struct ifaddrmsg *ifm;
struct nlmsghdr *nlh;
unsigned char *b = skb->tail;
- nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*ifm));
+ nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*ifm), flags);
ifm = NLMSG_DATA(nlh);
ifm->ifa_family = AF_DECnet;
@@ -755,7 +755,7 @@
netlink_set_err(rtnl, 0, RTMGRP_DECnet_IFADDR, ENOBUFS);
return;
}
- if (dn_dev_fill_ifaddr(skb, ifa, 0, 0, event) < 0) {
+ if (dn_dev_fill_ifaddr(skb, ifa, 0, 0, event, 0) < 0) {
kfree_skb(skb);
netlink_set_err(rtnl, 0, RTMGRP_DECnet_IFADDR, EINVAL);
return;
@@ -790,7 +790,8 @@
if (dn_dev_fill_ifaddr(skb, ifa,
NETLINK_CB(cb->skb).pid,
cb->nlh->nlmsg_seq,
- RTM_NEWADDR) <= 0)
+ RTM_NEWADDR,
+ NLM_F_MULTI) <= 0)
goto done;
}
}
Index: net/decnet/dn_route.c
===================================================================
--- debb58e5f900a6551f751b457226250cfccc3c75/net/decnet/dn_route.c (mode:100644)
+++ 5144b4dc6ffa4fb1821eb758838f63c5e210bc34/net/decnet/dn_route.c (mode:100644)
@@ -1465,7 +1465,8 @@
return dn_route_input_slow(skb);
}
-static int dn_rt_fill_info(struct sk_buff *skb, u32 pid, u32 seq, int event, int nowait)
+static int dn_rt_fill_info(struct sk_buff *skb, u32 pid, u32 seq,
+ int event, int nowait, unsigned int flags)
{
struct dn_route *rt = (struct dn_route *)skb->dst;
struct rtmsg *r;
@@ -1473,9 +1474,8 @@
unsigned char *b = skb->tail;
struct rta_cacheinfo ci;
- nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*r));
+ nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*r), flags);
r = NLMSG_DATA(nlh);
- nlh->nlmsg_flags = (nowait && pid) ? NLM_F_MULTI : 0;
r->rtm_family = AF_DECnet;
r->rtm_dst_len = 16;
r->rtm_src_len = 0;
@@ -1596,7 +1596,7 @@
NETLINK_CB(skb).dst_pid = NETLINK_CB(in_skb).pid;
- err = dn_rt_fill_info(skb, NETLINK_CB(in_skb).pid, nlh->nlmsg_seq, RTM_NEWROUTE, 0);
+ err = dn_rt_fill_info(skb, NETLINK_CB(in_skb).pid, nlh->nlmsg_seq, RTM_NEWROUTE, 0, 0);
if (err == 0)
goto out_free;
@@ -1644,7 +1644,8 @@
continue;
skb->dst = dst_clone(&rt->u.dst);
if (dn_rt_fill_info(skb, NETLINK_CB(cb->skb).pid,
- cb->nlh->nlmsg_seq, RTM_NEWROUTE, 1) <= 0) {
+ cb->nlh->nlmsg_seq, RTM_NEWROUTE,
+ 1, NLM_F_MULTI) <= 0) {
dst_release(xchg(&skb->dst, NULL));
rcu_read_unlock_bh();
goto done;
Index: net/decnet/dn_rules.c
===================================================================
--- debb58e5f900a6551f751b457226250cfccc3c75/net/decnet/dn_rules.c (mode:100644)
+++ 5144b4dc6ffa4fb1821eb758838f63c5e210bc34/net/decnet/dn_rules.c (mode:100644)
@@ -342,14 +342,15 @@
.notifier_call = dn_fib_rules_event,
};
-static int dn_fib_fill_rule(struct sk_buff *skb, struct dn_fib_rule *r, struct netlink_callback *cb)
+static int dn_fib_fill_rule(struct sk_buff *skb, struct dn_fib_rule *r,
+ struct netlink_callback *cb, unsigned int flags)
{
struct rtmsg *rtm;
struct nlmsghdr *nlh;
unsigned char *b = skb->tail;
- nlh = NLMSG_PUT(skb, NETLINK_CREDS(cb->skb)->pid, cb->nlh->nlmsg_seq, RTM_NEWRULE, sizeof(*rtm));
+ nlh = NLMSG_NEW_ANSWER(skb, cb, RTM_NEWRULE, sizeof(*rtm), flags);
rtm = NLMSG_DATA(nlh);
rtm->rtm_family = AF_DECnet;
rtm->rtm_dst_len = r->r_dst_len;
@@ -394,7 +395,7 @@
for(r = dn_fib_rules, idx = 0; r; r = r->r_next, idx++) {
if (idx < s_idx)
continue;
- if (dn_fib_fill_rule(skb, r, cb) < 0)
+ if (dn_fib_fill_rule(skb, r, cb, NLM_F_MULTI) < 0)
break;
}
read_unlock(&dn_fib_rules_lock);
Index: net/decnet/dn_table.c
===================================================================
--- debb58e5f900a6551f751b457226250cfccc3c75/net/decnet/dn_table.c (mode:100644)
+++ 5144b4dc6ffa4fb1821eb758838f63c5e210bc34/net/decnet/dn_table.c (mode:100644)
@@ -270,13 +270,13 @@
static int dn_fib_dump_info(struct sk_buff *skb, u32 pid, u32 seq, int event,
u8 tb_id, u8 type, u8 scope, void *dst, int dst_len,
- struct dn_fib_info *fi)
+ struct dn_fib_info *fi, unsigned int flags)
{
struct rtmsg *rtm;
struct nlmsghdr *nlh;
unsigned char *b = skb->tail;
- nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*rtm));
+ nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*rtm), flags);
rtm = NLMSG_DATA(nlh);
rtm->rtm_family = AF_DECnet;
rtm->rtm_dst_len = dst_len;
@@ -345,7 +345,7 @@
if (dn_fib_dump_info(skb, pid, nlh->nlmsg_seq, event, tb_id,
f->fn_type, f->fn_scope, &f->fn_key, z,
- DN_FIB_INFO(f)) < 0) {
+ DN_FIB_INFO(f), 0) < 0) {
kfree_skb(skb);
return;
}
@@ -377,7 +377,7 @@
tb->n,
(f->fn_state & DN_S_ZOMBIE) ? 0 : f->fn_type,
f->fn_scope, &f->fn_key, dz->dz_order,
- f->fn_info) < 0) {
+ f->fn_info, NLM_F_MULTI) < 0) {
cb->args[3] = i;
return -1;
}
Index: net/ipv4/devinet.c
===================================================================
--- debb58e5f900a6551f751b457226250cfccc3c75/net/ipv4/devinet.c (mode:100644)
+++ 5144b4dc6ffa4fb1821eb758838f63c5e210bc34/net/ipv4/devinet.c (mode:100644)
@@ -1015,14 +1015,13 @@
};
static int inet_fill_ifaddr(struct sk_buff *skb, struct in_ifaddr *ifa,
- u32 pid, u32 seq, int event)
+ u32 pid, u32 seq, int event, unsigned int flags)
{
struct ifaddrmsg *ifm;
struct nlmsghdr *nlh;
unsigned char *b = skb->tail;
- nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*ifm));
- if (pid) nlh->nlmsg_flags |= NLM_F_MULTI;
+ nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*ifm), flags);
ifm = NLMSG_DATA(nlh);
ifm->ifa_family = AF_INET;
ifm->ifa_prefixlen = ifa->ifa_prefixlen;
@@ -1075,7 +1074,7 @@
continue;
if (inet_fill_ifaddr(skb, ifa, NETLINK_CB(cb->skb).pid,
cb->nlh->nlmsg_seq,
- RTM_NEWADDR) <= 0) {
+ RTM_NEWADDR, NLM_F_MULTI) <= 0) {
rcu_read_unlock();
goto done;
}
@@ -1098,7 +1097,7 @@
if (!skb)
netlink_set_err(rtnl, 0, RTMGRP_IPV4_IFADDR, ENOBUFS);
- else if (inet_fill_ifaddr(skb, ifa, 0, 0, event) < 0) {
+ else if (inet_fill_ifaddr(skb, ifa, 0, 0, event, 0) < 0) {
kfree_skb(skb);
netlink_set_err(rtnl, 0, RTMGRP_IPV4_IFADDR, EINVAL);
} else {
Index: net/ipv4/fib_hash.c
===================================================================
--- debb58e5f900a6551f751b457226250cfccc3c75/net/ipv4/fib_hash.c (mode:100644)
+++ 5144b4dc6ffa4fb1821eb758838f63c5e210bc34/net/ipv4/fib_hash.c (mode:100644)
@@ -703,7 +703,8 @@
&f->fn_key,
fz->fz_order,
fa->fa_tos,
- fa->fa_info) < 0) {
+ fa->fa_info,
+ NLM_F_MULTI) < 0) {
cb->args[3] = i;
return -1;
}
Index: net/ipv4/fib_lookup.h
===================================================================
--- debb58e5f900a6551f751b457226250cfccc3c75/net/ipv4/fib_lookup.h (mode:100644)
+++ 5144b4dc6ffa4fb1821eb758838f63c5e210bc34/net/ipv4/fib_lookup.h (mode:100644)
@@ -30,7 +30,8 @@
struct kern_rta *rta, struct fib_info *fi);
extern int fib_dump_info(struct sk_buff *skb, u32 pid, u32 seq, int event,
u8 tb_id, u8 type, u8 scope, void *dst,
- int dst_len, u8 tos, struct fib_info *fi);
+ int dst_len, u8 tos, struct fib_info *fi,
+ unsigned int);
extern void rtmsg_fib(int event, u32 key, struct fib_alias *fa,
int z, int tb_id,
struct nlmsghdr *n, struct netlink_skb_parms *req);
Index: net/ipv4/fib_rules.c
===================================================================
--- debb58e5f900a6551f751b457226250cfccc3c75/net/ipv4/fib_rules.c (mode:100644)
+++ 5144b4dc6ffa4fb1821eb758838f63c5e210bc34/net/ipv4/fib_rules.c (mode:100644)
@@ -367,13 +367,14 @@
static __inline__ int inet_fill_rule(struct sk_buff *skb,
struct fib_rule *r,
- struct netlink_callback *cb)
+ struct netlink_callback *cb,
+ unsigned int flags)
{
struct rtmsg *rtm;
struct nlmsghdr *nlh;
unsigned char *b = skb->tail;
- nlh = NLMSG_PUT(skb, NETLINK_CREDS(cb->skb)->pid, cb->nlh->nlmsg_seq, RTM_NEWRULE, sizeof(*rtm));
+ nlh = NLMSG_NEW_ANSWER(skb, cb, RTM_NEWRULE, sizeof(*rtm), flags);
rtm = NLMSG_DATA(nlh);
rtm->rtm_family = AF_INET;
rtm->rtm_dst_len = r->r_dst_len;
@@ -422,7 +423,7 @@
for (r=fib_rules, idx=0; r; r = r->r_next, idx++) {
if (idx < s_idx)
continue;
- if (inet_fill_rule(skb, r, cb) < 0)
+ if (inet_fill_rule(skb, r, cb, NLM_F_MULTI) < 0)
break;
}
read_unlock(&fib_rules_lock);
Index: net/ipv4/fib_semantics.c
===================================================================
--- debb58e5f900a6551f751b457226250cfccc3c75/net/ipv4/fib_semantics.c (mode:100644)
+++ 5144b4dc6ffa4fb1821eb758838f63c5e210bc34/net/ipv4/fib_semantics.c (mode:100644)
@@ -286,7 +286,7 @@
if (fib_dump_info(skb, pid, n->nlmsg_seq, event, tb_id,
fa->fa_type, fa->fa_scope, &key, z,
fa->fa_tos,
- fa->fa_info) < 0) {
+ fa->fa_info, 0) < 0) {
kfree_skb(skb);
return;
}
@@ -932,13 +932,13 @@
int
fib_dump_info(struct sk_buff *skb, u32 pid, u32 seq, int event,
u8 tb_id, u8 type, u8 scope, void *dst, int dst_len, u8 tos,
- struct fib_info *fi)
+ struct fib_info *fi, unsigned int flags)
{
struct rtmsg *rtm;
struct nlmsghdr *nlh;
unsigned char *b = skb->tail;
- nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*rtm));
+ nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*rtm), flags);
rtm = NLMSG_DATA(nlh);
rtm->rtm_family = AF_INET;
rtm->rtm_dst_len = dst_len;
Index: net/ipv4/route.c
===================================================================
--- debb58e5f900a6551f751b457226250cfccc3c75/net/ipv4/route.c (mode:100644)
+++ 5144b4dc6ffa4fb1821eb758838f63c5e210bc34/net/ipv4/route.c (mode:100644)
@@ -2581,7 +2581,7 @@
}
static int rt_fill_info(struct sk_buff *skb, u32 pid, u32 seq, int event,
- int nowait)
+ int nowait, unsigned int flags)
{
struct rtable *rt = (struct rtable*)skb->dst;
struct rtmsg *r;
@@ -2591,9 +2591,8 @@
#ifdef CONFIG_IP_MROUTE
struct rtattr *eptr;
#endif
- nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*r));
+ nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*r), flags);
r = NLMSG_DATA(nlh);
- nlh->nlmsg_flags = (nowait && pid) ? NLM_F_MULTI : 0;
r->rtm_family = AF_INET;
r->rtm_dst_len = 32;
r->rtm_src_len = 0;
@@ -2744,7 +2743,7 @@
NETLINK_CB(skb).dst_pid = NETLINK_CB(in_skb).pid;
err = rt_fill_info(skb, NETLINK_CB(in_skb).pid, nlh->nlmsg_seq,
- RTM_NEWROUTE, 0);
+ RTM_NEWROUTE, 0, 0);
if (!err)
goto out_free;
if (err < 0) {
@@ -2781,8 +2780,8 @@
continue;
skb->dst = dst_clone(&rt->u.dst);
if (rt_fill_info(skb, NETLINK_CB(cb->skb).pid,
- cb->nlh->nlmsg_seq,
- RTM_NEWROUTE, 1) <= 0) {
+ cb->nlh->nlmsg_seq, RTM_NEWROUTE,
+ 1, NLM_F_MULTI) <= 0) {
dst_release(xchg(&skb->dst, NULL));
rcu_read_unlock_bh();
goto done;
Index: net/ipv6/addrconf.c
===================================================================
--- debb58e5f900a6551f751b457226250cfccc3c75/net/ipv6/addrconf.c (mode:100644)
+++ 5144b4dc6ffa4fb1821eb758838f63c5e210bc34/net/ipv6/addrconf.c (mode:100644)
@@ -2621,15 +2621,14 @@
}
static int inet6_fill_ifaddr(struct sk_buff *skb, struct inet6_ifaddr *ifa,
- u32 pid, u32 seq, int event)
+ u32 pid, u32 seq, int event, unsigned int flags)
{
struct ifaddrmsg *ifm;
struct nlmsghdr *nlh;
struct ifa_cacheinfo ci;
unsigned char *b = skb->tail;
- nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*ifm));
- if (pid) nlh->nlmsg_flags |= NLM_F_MULTI;
+ nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*ifm), flags);
ifm = NLMSG_DATA(nlh);
ifm->ifa_family = AF_INET6;
ifm->ifa_prefixlen = ifa->prefix_len;
@@ -2671,15 +2670,14 @@
}
static int inet6_fill_ifmcaddr(struct sk_buff *skb, struct ifmcaddr6 *ifmca,
- u32 pid, u32 seq, int event)
+ u32 pid, u32 seq, int event, unsigned flags)
{
struct ifaddrmsg *ifm;
struct nlmsghdr *nlh;
struct ifa_cacheinfo ci;
unsigned char *b = skb->tail;
- nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*ifm));
- if (pid) nlh->nlmsg_flags |= NLM_F_MULTI;
+ nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*ifm), flags);
ifm = NLMSG_DATA(nlh);
ifm->ifa_family = AF_INET6;
ifm->ifa_prefixlen = 128;
@@ -2708,15 +2706,14 @@
}
static int inet6_fill_ifacaddr(struct sk_buff *skb, struct ifacaddr6 *ifaca,
- u32 pid, u32 seq, int event)
+ u32 pid, u32 seq, int event, unsigned int flags)
{
struct ifaddrmsg *ifm;
struct nlmsghdr *nlh;
struct ifa_cacheinfo ci;
unsigned char *b = skb->tail;
- nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*ifm));
- if (pid) nlh->nlmsg_flags |= NLM_F_MULTI;
+ nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*ifm), flags);
ifm = NLMSG_DATA(nlh);
ifm->ifa_family = AF_INET6;
ifm->ifa_prefixlen = 128;
@@ -2785,7 +2782,8 @@
continue;
if ((err = inet6_fill_ifaddr(skb, ifa,
NETLINK_CB(cb->skb).pid,
- cb->nlh->nlmsg_seq, RTM_NEWADDR)) <= 0)
+ cb->nlh->nlmsg_seq, RTM_NEWADDR,
+ NLM_F_MULTI)) <= 0)
goto done;
}
/* temp addr */
@@ -2796,7 +2794,8 @@
continue;
if ((err = inet6_fill_ifaddr(skb, ifa,
NETLINK_CB(cb->skb).pid,
- cb->nlh->nlmsg_seq, RTM_NEWADDR)) <= 0)
+ cb->nlh->nlmsg_seq, RTM_NEWADDR,
+ NLM_F_MULTI)) <= 0)
goto done;
}
#endif
@@ -2809,7 +2808,8 @@
continue;
if ((err = inet6_fill_ifmcaddr(skb, ifmca,
NETLINK_CB(cb->skb).pid,
- cb->nlh->nlmsg_seq, RTM_GETMULTICAST)) <= 0)
+ cb->nlh->nlmsg_seq, RTM_GETMULTICAST,
+ NLM_F_MULTI)) <= 0)
goto done;
}
break;
@@ -2821,7 +2821,8 @@
continue;
if ((err = inet6_fill_ifacaddr(skb, ifaca,
NETLINK_CB(cb->skb).pid,
- cb->nlh->nlmsg_seq, RTM_GETANYCAST)) <= 0)
+ cb->nlh->nlmsg_seq, RTM_GETANYCAST,
+ NLM_F_MULTI)) <= 0)
goto done;
}
break;
@@ -2871,7 +2872,7 @@
netlink_set_err(rtnl, 0, RTMGRP_IPV6_IFADDR, ENOBUFS);
return;
}
- if (inet6_fill_ifaddr(skb, ifa, 0, 0, event) < 0) {
+ if (inet6_fill_ifaddr(skb, ifa, 0, 0, event, 0) < 0) {
kfree_skb(skb);
netlink_set_err(rtnl, 0, RTMGRP_IPV6_IFADDR, EINVAL);
return;
@@ -2906,7 +2907,7 @@
}
static int inet6_fill_ifinfo(struct sk_buff *skb, struct inet6_dev *idev,
- u32 pid, u32 seq, int event)
+ u32 pid, u32 seq, int event, unsigned int flags)
{
struct net_device *dev = idev->dev;
__s32 *array = NULL;
@@ -2917,8 +2918,7 @@
__u32 mtu = dev->mtu;
struct ifla_cacheinfo ci;
- nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*r));
- if (pid) nlh->nlmsg_flags |= NLM_F_MULTI;
+ nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*r), flags);
r = NLMSG_DATA(nlh);
r->ifi_family = AF_INET6;
r->ifi_type = dev->type;
@@ -2985,7 +2985,7 @@
if ((idev = in6_dev_get(dev)) == NULL)
continue;
err = inet6_fill_ifinfo(skb, idev, NETLINK_CB(cb->skb).pid,
- cb->nlh->nlmsg_seq, RTM_NEWLINK);
+ cb->nlh->nlmsg_seq, RTM_NEWLINK, NLM_F_MULTI);
in6_dev_put(idev);
if (err <= 0)
break;
@@ -3007,7 +3007,7 @@
netlink_set_err(rtnl, 0, RTMGRP_IPV6_IFINFO, ENOBUFS);
return;
}
- if (inet6_fill_ifinfo(skb, idev, 0, 0, event) < 0) {
+ if (inet6_fill_ifinfo(skb, idev, 0, 0, event, 0) < 0) {
kfree_skb(skb);
netlink_set_err(rtnl, 0, RTMGRP_IPV6_IFINFO, EINVAL);
return;
@@ -3017,18 +3017,15 @@
}
static int inet6_fill_prefix(struct sk_buff *skb, struct inet6_dev *idev,
- struct prefix_info *pinfo, u32 pid, u32 seq, int event)
+ struct prefix_info *pinfo, u32 pid, u32 seq,
+ int event, unsigned int flags)
{
struct prefixmsg *pmsg;
struct nlmsghdr *nlh;
unsigned char *b = skb->tail;
struct prefix_cacheinfo ci;
- nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*pmsg));
-
- if (pid)
- nlh->nlmsg_flags |= NLM_F_MULTI;
-
+ nlh = NLMSG_NEW(skb, pid, seq, event, sizeof(*pmsg), flags);
pmsg = NLMSG_DATA(nlh);
pmsg->prefix_family = AF_INET6;
pmsg->prefix_ifindex = idev->dev->ifindex;
@@ -3067,7 +3064,7 @@
netlink_set_err(rtnl, 0, RTMGRP_IPV6_PREFIX, ENOBUFS);
return;
}
- if (inet6_fill_prefix(skb, idev, pinfo, 0, 0, event) < 0) {
+ if (inet6_fill_prefix(skb, idev, pinfo, 0, 0, event, 0) < 0) {
kfree_skb(skb);
netlink_set_err(rtnl, 0, RTMGRP_IPV6_PREFIX, EINVAL);
return;
Index: net/ipv6/route.c
===================================================================
--- debb58e5f900a6551f751b457226250cfccc3c75/net/ipv6/route.c (mode:100644)
+++ 5144b4dc6ffa4fb1821eb758838f63c5e210bc34/net/ipv6/route.c (mode:100644)
@@ -1570,7 +1570,8 @@
struct in6_addr *src,
int iif,
int type, u32 pid, u32 seq,
- struct nlmsghdr *in_nlh, int prefix)
+ struct nlmsghdr *in_nlh, int prefix,
+ unsigned int flags)
{
struct rtmsg *rtm;
struct nlmsghdr *nlh;
@@ -1588,7 +1589,7 @@
pid = in_nlh->nlmsg_pid;
}
- nlh = NLMSG_PUT(skb, pid, seq, type, sizeof(*rtm));
+ nlh = NLMSG_NEW(skb, pid, seq, type, sizeof(*rtm), flags);
rtm = NLMSG_DATA(nlh);
rtm->rtm_family = AF_INET6;
rtm->rtm_dst_len = rt->rt6i_dst.plen;
@@ -1674,7 +1675,7 @@
return rt6_fill_node(arg->skb, rt, NULL, NULL, 0, RTM_NEWROUTE,
NETLINK_CB(arg->cb->skb).pid, arg->cb->nlh->nlmsg_seq,
- NULL, prefix);
+ NULL, prefix, NLM_F_MULTI);
}
static int fib6_dump_node(struct fib6_walker_t *w)
@@ -1822,7 +1823,7 @@
&fl.fl6_dst, &fl.fl6_src,
iif,
RTM_NEWROUTE, NETLINK_CB(in_skb).pid,
- nlh->nlmsg_seq, nlh, 0);
+ nlh->nlmsg_seq, nlh, 0, 0);
if (err < 0) {
err = -EMSGSIZE;
goto out_free;
@@ -1848,7 +1849,7 @@
netlink_set_err(rtnl, 0, RTMGRP_IPV6_ROUTE, ENOBUFS);
return;
}
- if (rt6_fill_node(skb, rt, NULL, NULL, 0, event, 0, 0, nlh, 0) < 0) {
+ if (rt6_fill_node(skb, rt, NULL, NULL, 0, event, 0, 0, nlh, 0, 0) < 0) {
kfree_skb(skb);
netlink_set_err(rtnl, 0, RTMGRP_IPV6_ROUTE, EINVAL);
return;
^ permalink raw reply
* [PATCH 1/2] [NETLINK] Introduce NLMSG_NEW macro to better handle netlink flags
From: Thomas Graf @ 2005-05-27 17:00 UTC (permalink / raw)
To: jamal; +Cc: David S. Miller, netdev
In-Reply-To: <20050527165935.GC15391@postel.suug.ch>
Introduces a new macro NLMSG_NEW which extends NLMSG_PUT but takes
a flags argument. NLMSG_PUT stays there for compatibility but now
calls NLMSG_NEW with flags == 0. NLMSG_PUT_ANSWER is renamed to
NLMSG_NEW_ANSWER which now also takes a flags argument.
Also converts the users of NLMSG_PUT_ANSWER to use NLMSG_NEW_ANSWER
and fixes the two direct users of __nlmsg_put to either provide
the flags or use NLMSG_NEW(_ANSWER).
Signed-off-by: Thomas Graf <tgraf@suug.ch>
---
commit 1eb85f52f4e0d23996f6aa49009ce02fc0579658
tree debb58e5f900a6551f751b457226250cfccc3c75
parent fde09d4989b6c7b5183ffb3ec2076ff53dd6fa78
author Thomas Graf <tgraf@suug.ch> Fri, 27 May 2005 17:43:09 +0200
committer Thomas Graf <tgraf@suug.ch> Fri, 27 May 2005 17:43:09 +0200
include/linux/netlink.h | 17 ++++++++++-------
net/core/neighbour.c | 8 ++++----
net/netlink/af_netlink.c | 8 +++++---
3 files changed, 19 insertions(+), 14 deletions(-)
Index: include/linux/netlink.h
===================================================================
--- b032d0d440d93aac252e656bd41df32ff5461e3a/include/linux/netlink.h (mode:100644)
+++ debb58e5f900a6551f751b457226250cfccc3c75/include/linux/netlink.h (mode:100644)
@@ -156,7 +156,7 @@
};
static __inline__ struct nlmsghdr *
-__nlmsg_put(struct sk_buff *skb, u32 pid, u32 seq, int type, int len)
+__nlmsg_put(struct sk_buff *skb, u32 pid, u32 seq, int type, int len, int flags)
{
struct nlmsghdr *nlh;
int size = NLMSG_LENGTH(len);
@@ -164,20 +164,23 @@
nlh = (struct nlmsghdr*)skb_put(skb, NLMSG_ALIGN(size));
nlh->nlmsg_type = type;
nlh->nlmsg_len = size;
- nlh->nlmsg_flags = 0;
+ nlh->nlmsg_flags = flags;
nlh->nlmsg_pid = pid;
nlh->nlmsg_seq = seq;
return nlh;
}
-#define NLMSG_PUT(skb, pid, seq, type, len) \
+#define NLMSG_NEW(skb, pid, seq, type, len, flags) \
({ if (skb_tailroom(skb) < (int)NLMSG_SPACE(len)) \
goto nlmsg_failure; \
- __nlmsg_put(skb, pid, seq, type, len); })
+ __nlmsg_put(skb, pid, seq, type, len, flags); })
+
+#define NLMSG_PUT(skb, pid, seq, type, len) \
+ NLMSG_NEW(skb, pid, seq, type, len, 0)
-#define NLMSG_PUT_ANSWER(skb, cb, type, len) \
- NLMSG_PUT(skb, NETLINK_CB((cb)->skb).pid, \
- (cb)->nlh->nlmsg_seq, type, len)
+#define NLMSG_NEW_ANSWER(skb, cb, type, len, flags) \
+ NLMSG_NEW(skb, NETLINK_CB((cb)->skb).pid, \
+ (cb)->nlh->nlmsg_seq, type, len, flags)
#define NLMSG_END(skb, nlh) \
({ (nlh)->nlmsg_len = (skb)->tail - (unsigned char *) (nlh); \
Index: net/core/neighbour.c
===================================================================
--- b032d0d440d93aac252e656bd41df32ff5461e3a/net/core/neighbour.c (mode:100644)
+++ debb58e5f900a6551f751b457226250cfccc3c75/net/core/neighbour.c (mode:100644)
@@ -1588,8 +1588,8 @@
struct nlmsghdr *nlh;
struct ndtmsg *ndtmsg;
- nlh = NLMSG_PUT_ANSWER(skb, cb, RTM_NEWNEIGHTBL, sizeof(struct ndtmsg));
- nlh->nlmsg_flags |= NLM_F_MULTI;
+ nlh = NLMSG_NEW_ANSWER(skb, cb, RTM_NEWNEIGHTBL, sizeof(struct ndtmsg),
+ NLM_F_MULTI);
ndtmsg = NLMSG_DATA(nlh);
@@ -1673,8 +1673,8 @@
struct ndtmsg *ndtmsg;
struct nlmsghdr *nlh;
- nlh = NLMSG_PUT_ANSWER(skb, cb, RTM_NEWNEIGHTBL, sizeof(struct ndtmsg));
- nlh->nlmsg_flags |= NLM_F_MULTI;
+ nlh = NLMSG_NEW_ANSWER(skb, cb, RTM_NEWNEIGHTBL, sizeof(struct ndtmsg),
+ NLM_F_MULTI);
ndtmsg = NLMSG_DATA(nlh);
Index: net/netlink/af_netlink.c
===================================================================
--- b032d0d440d93aac252e656bd41df32ff5461e3a/net/netlink/af_netlink.c (mode:100644)
+++ debb58e5f900a6551f751b457226250cfccc3c75/net/netlink/af_netlink.c (mode:100644)
@@ -1095,8 +1095,7 @@
return 0;
}
- nlh = __nlmsg_put(skb, NETLINK_CB(cb->skb).pid, cb->nlh->nlmsg_seq, NLMSG_DONE, sizeof(int));
- nlh->nlmsg_flags |= NLM_F_MULTI;
+ nlh = NLMSG_NEW_ANSWER(skb, cb, NLMSG_DONE, sizeof(len), NLM_F_MULTI);
memcpy(NLMSG_DATA(nlh), &len, sizeof(len));
skb_queue_tail(&sk->sk_receive_queue, skb);
sk->sk_data_ready(sk, skb->len);
@@ -1107,6 +1106,9 @@
netlink_destroy_callback(cb);
return 0;
+
+nlmsg_failure:
+ return -ENOBUFS;
}
int netlink_dump_start(struct sock *ssk, struct sk_buff *skb,
@@ -1178,7 +1180,7 @@
}
rep = __nlmsg_put(skb, NETLINK_CB(in_skb).pid, nlh->nlmsg_seq,
- NLMSG_ERROR, sizeof(struct nlmsgerr));
+ NLMSG_ERROR, sizeof(struct nlmsgerr), 0);
errmsg = NLMSG_DATA(rep);
errmsg->error = err;
memcpy(&errmsg->msg, nlh, err ? nlh->nlmsg_len : sizeof(struct nlmsghdr));
^ permalink raw reply
* Re: PATCH: rtnetlink explicit flags setting
From: Thomas Graf @ 2005-05-27 16:59 UTC (permalink / raw)
To: jamal; +Cc: David S. Miller, netdev
In-Reply-To: <1117209466.6383.106.camel@localhost.localdomain>
* jamal <1117209466.6383.106.camel@localhost.localdomain> 2005-05-27 11:57
> On Fri, 2005-27-05 at 17:19 +0200, Thomas Graf wrote:
>
> > Sure, I can come up with a patchset today which will include:
> > o the new NLMSG_NEW macro
> > o your patch adopted to use the new NLMSG_NEW macro
> > o small patch to rename NLMSG_PUT_ANSWER usages into NLMSG_NEW_ANSWER
> > o a small fallout from the new neighbour table code which gcc didn't
> > warn me about when it should.
> >
> > OK?
>
> Sounds reasonable.
I took your patch, converted it to use NLMSG_NEW and finished
converting all the modules that you started. Yet unconverted
are: netfilter, net/sched/ tcp_diag, xfrm, kernel/audit.
I also fixed some uses of NL_CREDS() to fetch the pid for
message generation which is wrong. Various dumping procedures
did not set the multi flag at all, I fixed all of them.
Do not apply these patches yet, they're way too intrusive
^ permalink raw reply
* Re: [PATCH 3/4] [NEIGH] neighbour table configuration and statistics via rtnetlink
From: Thomas Graf @ 2005-05-27 16:35 UTC (permalink / raw)
To: jamal; +Cc: David S. Miller, netdev
In-Reply-To: <1117209411.6383.104.camel@localhost.localdomain>
* jamal <1117209411.6383.104.camel@localhost.localdomain> 2005-05-27 11:56
> On Fri, 2005-27-05 at 17:16 +0200, Thomas Graf wrote:
> > Sorry but this is just one big hack:
>
> It maybe in the user space representation, but not in the kernel
> abstraction which is what i was refering to.
> In other words look at struct in_device;
Yes, it references the arp device specific parameters and so
does inet6_dev for the ndisc cache. But this repsents only the
current state, we might have neighbour table parameter sets
which are not bound to inetdevs in the future. However, I
regard this as minor and I can agree on moving the device
specific parameters into a inetdev based architecture but
I do NOT agree on moving gc_ into this architecture as well,
it doesn't belong there.
Nitpicking for a bit, although inet6_dev and in_device hold
reference to the their arp respectively ndisc parameter set,
the sysctl interface does not use this reference but stores
the ifindex of the netdevice, _which_ is correct I think
because parameter sets are _not_ limited to inetdevs in terms
of architecture but only in terms of current use.
> The deafult can be overriden by devX. So they dont need to sync.
> But this is a separate topic
I was not talking about in-sync but rather that gc_* only
appears in default/ but not in devX/. What I expect is that
every default parameter can be overwritten in devX which
is not true for gc_*. Which is the reason why I implemented
them outside of the NDTPA_PARMS nested TLV.
> I am afraid you are looking at this from the wrong angle (user space),
> Thomas ;->
> The abstraction in the kernel is proper.
>
> To redraw that model again with the exact structure names:
>
> netdevice ->
> L2 config stuff
> config stuff
> more config stuff
> ..
> ..
> netdevice protocol config:
> -> v4 specific (struct in_device)
> ----> IPV4 addresses (ifa_list), ARP params(arp_parms),etc
> -> v6 specific (struct inet6_dev)
> ----> IPV6 addresses(addr_list), ndisc params (nd_parms), etc
>
> There are a few more items but i am leaving them out for brevity.
> I hope it makes more sense now.
I understand your architecture and if we follow this thought
we'd have a "default" netdevice which repesents all default
settings. I do agree with this architecture but the problematic
question remains: Do we want parameters in "default" which are
not available in devX? I think this question is what it gets
down to in the end. If we say, yes we do want this, then we
can implement all generic settings, such as tcp_, using this
scheme as well. I don't disagree with this completely but I
find it not very intuitive from a user perspective.
^ permalink raw reply
* RE: [PATCH 2.6.12-rc4] IPv4/IPv6: UDP Large Send Offload feature
From: Ravinandan Arakali @ 2005-05-27 16:32 UTC (permalink / raw)
To: 'David S. Miller'
Cc: jgarzik, netdev, raghavendra.koushik, leonid.grossman,
ananda.raju, rapuru.sriram
In-Reply-To: <20050526.164217.45745005.davem@davemloft.net>
Hi David,
Thanks for the quick feedback.
At that time when we considered using skb_shinfo(skb)->fraglist,
it contained fragments of MTU size. So, for a 60k udp datagram
and 1500 MTU we will have 60k/1500 = 45 fragments which is
more than MAX_SKB_FRAGS(18).
However we will relook at fraglist for the possibility of increasing
frag size to >MTU.
Thanks,
Ravi
-----Original Message-----
From: David S. Miller [mailto:davem@davemloft.net]
Sent: Thursday, May 26, 2005 4:42 PM
To: ravinandan.arakali@neterion.com
Cc: jgarzik@pobox.com; netdev@oss.sgi.com;
raghavendra.koushik@neterion.com; leonid.grossman@neterion.com;
ananda.raju@neterion.com; rapuru.sriram@neterion.com
Subject: Re: [PATCH 2.6.12-rc4] IPv4/IPv6: UDP Large Send Offload
feature
sock_append_data() seems like a lot of wasted work.
We already pass around the fragmented SKB as a list chained by
skb_shinfo(skb)->fraglist, just pass this thing to the device and in
this way you'll avoid all of that work sock_append_data() does
entirely.
Or is there a reason you did not implement it this
way?
This is one of the uses the skb_shinfo(skb)->fraglist was intended
for.
IN FACT, this fragmentation offload you are implementing here is what
the feature bit NETIF_F_FRAGLIST was meant to indicate.
^ permalink raw reply
* Re: [Bridge] Re: [PATCH] (6/6) bridge: receive path optimization
From: Stephen Hemminger @ 2005-05-27 15:59 UTC (permalink / raw)
To: Atul Sabharwal; +Cc: David S. Miller, netdev, bridge
In-Reply-To: <009201c56280$e9b7cd00$0202a8c0@ATULSPC>
On Thu, 26 May 2005 22:57:05 -0700
"Atul Sabharwal" <iamatul@comcast.net> wrote:
> I have a question about using the 802.1d driver with a switch. I have a
> managed switch
> which connects to the Xscale MAC using a Reverse MII interface.
>
> It seems that the 802.1d bridge puts the interface into promiscuous mode and
> needs multiple
> ethernet devices to work with. Can it work with a single ethernet device
> which is connected
> to a BCM5338 ( broadcomm 8 port switch chip ).
Why? what would you gain?
> I understand that I would have to change the STP configuration component to
> write to the
> broadcomm chip.
You would be better off writing a different driver, the amount of shared
logic would be less than the per hardware logic.
^ permalink raw reply
* Re: A new driver for Broadcom bcm5706
From: Michael Chan @ 2005-05-27 15:58 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: davem, jgarzik, netdev, ffan, lusinsky
In-Reply-To: <20050527074115.GA28208@infradead.org>
On Fri, 2005-05-27 at 08:41 +0100, Christoph Hellwig wrote:
> On Fri, May 20, 2005 at 10:15:29AM -0700, Michael Chan wrote:
> > A new driver bnx2 for Broadcom bcm5706 is available. Since the patch is
> > over 500K, I've put it on the ftp server:
> >
> > ftp://Net_sys_anon@ftp1.broadcom.com/bnx2-2.patch
> >
> > The patch also includes new 1000BASE-X advertisement bit definitions in
> > mii.h
>
> These defintions overlap older 10MB/s defintions. I don't think the number
> space is scare enough to need this hack. If we absolutely want to keep it
> you should at least add some big comments explaining it.
>
>
Yes they do. But these overlapping bit definitions are defined by the
802.3 standard for 1000Base-X. These are not Broadcom proprietary
definitions.
^ permalink raw reply
* Re: PATCH: rtnetlink explicit flags setting
From: jamal @ 2005-05-27 15:57 UTC (permalink / raw)
To: Thomas Graf; +Cc: David S. Miller, netdev
In-Reply-To: <20050527151913.GA15391@postel.suug.ch>
On Fri, 2005-27-05 at 17:19 +0200, Thomas Graf wrote:
> Sure, I can come up with a patchset today which will include:
> o the new NLMSG_NEW macro
> o your patch adopted to use the new NLMSG_NEW macro
> o small patch to rename NLMSG_PUT_ANSWER usages into NLMSG_NEW_ANSWER
> o a small fallout from the new neighbour table code which gcc didn't
> warn me about when it should.
>
> OK?
Sounds reasonable.
cheers,
jamal
PS:- Have to disappear for a few hours so they maybe latency in further
responses.
^ permalink raw reply
* Re: [PATCH 2.6.12-rc4] IPv4/IPv6: UDP Large Send Offload feature
From: Stephen Hemminger @ 2005-05-27 15:57 UTC (permalink / raw)
To: ravinandan.arakali
Cc: davem, jgarzik, netdev, raghavendra.koushik, ravinandan.arakali,
leonid.grossman, ananda.raju, rapuru.sriram
In-Reply-To: <20050526232006.60E6365005@linux.site>
On Thu, 26 May 2005 16:20:06 -0700 (PDT)
ravinandan.arakali@neterion.com wrote:
> Hi,
> Attached below is a kernel patch to provide UDP LSO(Large Send Offload)
> feature.
> This is the UDP counterpart of TSO. Basically, an oversized packet
> (less than or equal to 65535) is handed to the NIC. The adapter then
> produces IP fragments in conformance with RFC791(IPv4) or RFC2460(IPv6).
>
> Very much like TCP TSO, UDP LSO provides significant reduction in CPU
> utilization, especially with 1500 MTU frames. For 10GbE traffic,
> these extra CPU cycles translate into significant throughput increase
> on most server platforms.
>
> Reasonable amount of testing has been done on the patch using Neterion's
> 10G Xframe-II adapter to ensure code stability.
>
> Please review the patch.
>
> Also, below is a "how-to" on changes required in network drivers to use
> the UDP LSO interface.
The only downside is that it might encourage continued use of NFS over UDP.
Perhaps we need a big fat warning in NFS that says:
*** Your using NFS over UDP, your data integrity is no longer guaranteed;
*** you have been warned.
^ permalink raw reply
* Re: [PATCH 3/4] [NEIGH] neighbour table configuration and statistics via rtnetlink
From: jamal @ 2005-05-27 15:56 UTC (permalink / raw)
To: Thomas Graf; +Cc: David S. Miller, netdev
In-Reply-To: <20050527151608.GZ15391@postel.suug.ch>
On Fri, 2005-27-05 at 17:16 +0200, Thomas Graf wrote:
> * jamal <1117205822.6383.68.camel@localhost.localdomain> 2005-05-27 10:57
> > The thresholds etc are there - just not netlink accessible. Example, the
> > default values for V4 are settable or queriable via:
> >
> > /proc/sys/net/ipv4/neigh/default/gc_thresh3
> > /proc/sys/net/ipv4/neigh/default/gc_thresh2
> > /proc/sys/net/ipv4/neigh/default/gc_thresh1
> > /proc/sys/net/ipv4/neigh/default/gc_interval
>
> Sorry but this is just one big hack:
It maybe in the user space representation, but not in the kernel
abstraction which is what i was refering to.
In other words look at struct in_device;
> a) they do not belong there, the first implication a user does when
> he sees default/, dev1/, dev2/, devN is that default/ covers
> the same set of parameters as devX/. Therefore he expects all
> parameters in default/ to be also in devX/.
>
The deafult can be overriden by devX. So they dont need to sync.
But this is a separate topic
> b) struct neigh_parms parms;
> /* HACK. gc_* shoul follow parms without a gap! */
> int gc_interval;
> int gc_thresh1;
> int gc_thresh2;
> int gc_thresh3;
>
> ...
>
> if (dev) {
> dev_name_source = dev->name;
> t->neigh_dev[0].ctl_name = dev->ifindex;
> t->neigh_vars[12].procname = NULL; <- gc_interval
> t->neigh_vars[13].procname = NULL; <- gc_thresh1
> t->neigh_vars[14].procname = NULL; <- gc_thresh2
> t->neigh_vars[15].procname = NULL; <- gc_thresh3
> } else {
> dev_name_source = t->neigh_dev[0].procname;
> t->neigh_vars[12].data = (int *)(p + 1);
> t->neigh_vars[13].data = (int *)(p + 1) + 1;
> t->neigh_vars[14].data = (int *)(p + 1) + 2;
> t->neigh_vars[15].data = (int *)(p + 1) + 3;
> }
>
> I will not push along these hacks into my code ;->
>
I am afraid you are looking at this from the wrong angle (user space),
Thomas ;->
The abstraction in the kernel is proper.
To redraw that model again with the exact structure names:
netdevice ->
L2 config stuff
config stuff
more config stuff
..
..
netdevice protocol config:
-> v4 specific (struct in_device)
----> IPV4 addresses (ifa_list), ARP params(arp_parms),etc
-> v6 specific (struct inet6_dev)
----> IPV6 addresses(addr_list), ndisc params (nd_parms), etc
There are a few more items but i am leaving them out for brevity.
I hope it makes more sense now.
> Some more notes on the devconfig idea: I'm not sure if you are still
> implying devconfig as devinet but if so: although we only have neighbour
> tables on devinets so far there might be neighbour table on other
> interfaces for whatever reason.
in_devxxx types; sorry, I created the confusion by mentioning devconf in
the sweep.
> A protocol might allocate a neighbour
> parameter set on any netdevice which makes me think that the netlink
> neighbour code should be open for this as well. It depends on how we
> do the devconfig thing, so what I suggest it so leave this as-is for
> the moment and make a decision once we know more about how the devconfig
> thing will look like. Reasonable?
Take a look at what i said above and see if it makes sense.
Note, I am not objecting to the patch like i said - I think some of
those items are must put in that patch. Whatever simplifies life for
you. I am not exactly a purist but at times i like getting it right from
the beggining.
cheers,
jamal
^ 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