* Re: [net-next PATCH] etherdevice.h: random_ether_addr update
From: Mark Smith @ 2009-09-13 6:39 UTC (permalink / raw)
To: Joe Perches
Cc: Stephen Hemminger, David Miller, jeffrey.t.kirsher, netdev, gospo,
gregory.v.rose, donald.c.skidmore
In-Reply-To: <1252822152.4400.108.camel@Joe-Laptop.home>
On Sat, 12 Sep 2009 23:09:12 -0700
Joe Perches <joe@perches.com> wrote:
> On Sun, 2009-09-13 at 13:17 +0930, Mark Smith wrote:
> > On Sat, 12 Sep 2009 17:44:46 -0700
> > Joe Perches <joe@perches.com> wrote:
> > > Avoiding an initial octet of "02", which is partially
> > > assigned to 3Com and others, might be useful.
> > I wouldn't necessarily disagree. I would say that if that path was
> > taken, then you'd probably also want to be avoiding all the other
> > well known mac addresses that do or can fall within the locally
> > assigned range e.g. DECnet 0xAA addresses, Microsoft's use of
> > 02:01:00:00:00:00 and similar addresses for their Network Load
> > Balancing software, the unicast version of the CF:00:00:00:00:00
> > multicast address use for ECTP, the unicast version of the
> > 33:33:xx:xx:xx:xx IPv6 ND multicast ranges etc.
>
> The existing code already has the first wire bit cleared so it
> is not multicast
Agreed. However I think that if there is a well-known multicast address
that has 0x02 set, there is a future, slight possibility that unicast
addresses might be assigned out of that same LA space, and so they're
worth avoiding. It probably seems a bit paranoid, but LAs are supposed
to be private use only in the first place, and not supposed to be seen
outside of the organisation or entity assigning them (e.g. Microsoft
should have got an OUI to use with their NLB product). If people are
crossing those privacy boundaries with LA multicast addresses, I'd
suggest they might be willing to do it with LA unicast addresses in the
future too - and hopefully they'd restrict themselves to the OUI bytes
they've used for their multicast addresses.
> and has the locally assigned bit set so the
> first octet is a multiple of 2.
>
> The suggested patch requires an initial octet >= 0x04.
>
> Skipping AA seems a good idea.
>
> > Having thought about this issue a bit before, another thought might be
> > to have somebody get the Linux kernel its own OUI,
>
> That's been suggested.
>
> > > Not drawing from entropy I think useful, but it's debatable.
> > I'm guessing there are other things in the kernel that would be taking
> > away far more entropy, far more often. IIRC, TCP connection initial
> > sequence number selection would be one example.
>
> These MAC assignments are generally done at system startup
> when entropy often isn't available and possibly should be
> conserved.
>
> Maybe this:
>
I'd suggest documenting in the comment why 0x02 or 0xaa are special
values that have been avoided.
> Signed-off-by: Joe Perches <joe@perches.com>
>
> diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
> index 3d7a668..40233db 100644
> --- a/include/linux/etherdevice.h
> +++ b/include/linux/etherdevice.h
> @@ -118,12 +118,30 @@ static inline int is_valid_ether_addr(const u8 *addr)
> *
> * Generate a random Ethernet address (MAC) that is not multicast
> * and has the local assigned bit set.
> + * Does not assign a leading octet of 0x02 or 0xaa.
> */
> static inline void random_ether_addr(u8 *addr)
> {
> - get_random_bytes (addr, ETH_ALEN);
> - addr [0] &= 0xfe; /* clear multicast bit */
> - addr [0] |= 0x02; /* set local assignment bit (IEEE802) */
> + u32 val;
> +
> + /* not calling get_random_bytes to avoid using entropy */
> + do {
> + val = random32();
> + addr[0] = val;
> + addr[0] &= 0xfe; /* clear multicast bit */
> + addr[0] |= 0x02; /* set local assignment bit (IEEE802) */
> + } while (addr[0] == 0x02 || addr[0] == 0xaa);
> +
> + val >>= 8;
> + addr[1] = val;
> + val >>= 8;
> + addr[2] = val;
> + val >>= 8;
> + addr[3] = val;
> + val = random32();
> + addr[4] = val;
> + val >>= 8;
> + addr[5] = val;
> }
>
> /**
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ppp: ppp_generic.c initialize flen before it get used
From: David Miller @ 2009-09-13 6:17 UTC (permalink / raw)
To: jaswinder; +Cc: gabriele.paoloni, paulus, linux-ppp, netdev
In-Reply-To: <1252773691.3687.5.camel@ht.satnam>
Already dealt with in net-next-2.6, please act against the
active networking development trees when fixing warnings and
doing cleanups.
Thank you.
commit 886f9fe68310168358f55028a03553ae154dfeb6
Author: David S. Miller <davem@davemloft.net>
Date: Wed Aug 19 13:55:55 2009 -0700
ppp_generic: Help GCC see that 'flen' is always initialized.
It's too stupid to see that we always set flen to something
before we use it in ppp_mp_explode():
drivers/net/ppp_generic.c: In function 'ppp_push':
drivers/net/ppp_generic.c:1314: warning: 'flen' may be used uninitialized in this function
drivers/net/ppp_generic.c:1314: note: 'flen' was declared here
This started warning after commit a53a8b56827cc429c6d9f861ad558beeb5f6103f
("ppp: fix lost fragments in ppp_mp_explode() (resubmit)")
So just put an explicit unconditional initialization there to
hush it up.
Signed-off-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [net-next PATCH] etherdevice.h: random_ether_addr update
From: Joe Perches @ 2009-09-13 6:09 UTC (permalink / raw)
To: Mark Smith
Cc: Stephen Hemminger, David Miller, jeffrey.t.kirsher, netdev, gospo,
gregory.v.rose, donald.c.skidmore
In-Reply-To: <20090913131752.462abc01@opy.nosense.org>
On Sun, 2009-09-13 at 13:17 +0930, Mark Smith wrote:
> On Sat, 12 Sep 2009 17:44:46 -0700
> Joe Perches <joe@perches.com> wrote:
> > Avoiding an initial octet of "02", which is partially
> > assigned to 3Com and others, might be useful.
> I wouldn't necessarily disagree. I would say that if that path was
> taken, then you'd probably also want to be avoiding all the other
> well known mac addresses that do or can fall within the locally
> assigned range e.g. DECnet 0xAA addresses, Microsoft's use of
> 02:01:00:00:00:00 and similar addresses for their Network Load
> Balancing software, the unicast version of the CF:00:00:00:00:00
> multicast address use for ECTP, the unicast version of the
> 33:33:xx:xx:xx:xx IPv6 ND multicast ranges etc.
The existing code already has the first wire bit cleared so it
is not multicast and has the locally assigned bit set so the
first octet is a multiple of 2.
The suggested patch requires an initial octet >= 0x04.
Skipping AA seems a good idea.
> Having thought about this issue a bit before, another thought might be
> to have somebody get the Linux kernel its own OUI,
That's been suggested.
> > Not drawing from entropy I think useful, but it's debatable.
> I'm guessing there are other things in the kernel that would be taking
> away far more entropy, far more often. IIRC, TCP connection initial
> sequence number selection would be one example.
These MAC assignments are generally done at system startup
when entropy often isn't available and possibly should be
conserved.
Maybe this:
Signed-off-by: Joe Perches <joe@perches.com>
diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
index 3d7a668..40233db 100644
--- a/include/linux/etherdevice.h
+++ b/include/linux/etherdevice.h
@@ -118,12 +118,30 @@ static inline int is_valid_ether_addr(const u8 *addr)
*
* Generate a random Ethernet address (MAC) that is not multicast
* and has the local assigned bit set.
+ * Does not assign a leading octet of 0x02 or 0xaa.
*/
static inline void random_ether_addr(u8 *addr)
{
- get_random_bytes (addr, ETH_ALEN);
- addr [0] &= 0xfe; /* clear multicast bit */
- addr [0] |= 0x02; /* set local assignment bit (IEEE802) */
+ u32 val;
+
+ /* not calling get_random_bytes to avoid using entropy */
+ do {
+ val = random32();
+ addr[0] = val;
+ addr[0] &= 0xfe; /* clear multicast bit */
+ addr[0] |= 0x02; /* set local assignment bit (IEEE802) */
+ } while (addr[0] == 0x02 || addr[0] == 0xaa);
+
+ val >>= 8;
+ addr[1] = val;
+ val >>= 8;
+ addr[2] = val;
+ val >>= 8;
+ addr[3] = val;
+ val = random32();
+ addr[4] = val;
+ val >>= 8;
+ addr[5] = val;
}
/**
^ permalink raw reply related
* Re: [PATCHv5 3/3] vhost_net: a kernel-level virtio server
From: Michael S. Tsirkin @ 2009-09-13 5:46 UTC (permalink / raw)
To: Xin, Xiaohui
Cc: Ira W. Snyder, netdev@vger.kernel.org,
virtualization@lists.linux-foundation.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, mingo@elte.hu, linux-mm@kvack.org,
akpm@linux-foundation.org, hpa@zytor.com,
gregory.haskins@gmail.com, Rusty Russell, s.hetze@linux-ag.com,
avi
In-Reply-To: <C85CEDA13AB1CF4D9D597824A86D2B9006AECB9C1D@PDSMSX501.ccr.corp.intel.com>
On Fri, Sep 11, 2009 at 11:17:33PM +0800, Xin, Xiaohui wrote:
> Michael,
> We are very interested in your patch and want to have a try with it.
> I have collected your 3 patches in kernel side and 4 patches in queue side.
> The patches are listed here:
>
> PATCHv5-1-3-mm-export-use_mm-unuse_mm-to-modules.patch
> PATCHv5-2-3-mm-reduce-atomic-use-on-use_mm-fast-path.patch
> PATCHv5-3-3-vhost_net-a-kernel-level-virtio-server.patch
>
> PATCHv3-1-4-qemu-kvm-move-virtio-pci[1].o-to-near-pci.o.patch
> PATCHv3-2-4-virtio-move-features-to-an-inline-function.patch
> PATCHv3-3-4-qemu-kvm-vhost-net-implementation.patch
> PATCHv3-4-4-qemu-kvm-add-compat-eventfd.patch
>
> I applied the kernel patches on v2.6.31-rc4 and the qemu patches on latest kvm qemu.
> But seems there are some patches are needed at least irqfd and ioeventfd patches on
> current qemu. I cannot create a kvm guest with "-net nic,model=virtio,vhost=vethX".
>
> May you kindly advice us the patch lists all exactly to make it work?
> Thanks a lot. :-)
>
> Thanks
> Xiaohui
The irqfd/ioeventfd patches are part of Avi's kvm.git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git
I expect them to be merged by 2.6.32-rc1 - right, Avi?
--
MST
--
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: [net-next PATCH] etherdevice.h: random_ether_addr update
From: Mark Smith @ 2009-09-13 3:47 UTC (permalink / raw)
To: Joe Perches
Cc: Stephen Hemminger, David Miller, jeffrey.t.kirsher, netdev, gospo,
gregory.v.rose, donald.c.skidmore
In-Reply-To: <1252802686.4400.19.camel@Joe-Laptop.home>
On Sat, 12 Sep 2009 17:44:46 -0700
Joe Perches <joe@perches.com> wrote:
> On Sun, 2009-09-13 at 10:03 +0930, Mark Smith wrote:
> > Hmm, probably didn't make my point all that clear. IOW, anything that
> > can contribute to avoiding duplicate mac addresses is worth it in my
> > opinion, when compared to the time (usually hours) involved in
> > troubleshooting duplicate mac addresses.
>
> Avoiding an initial octet of "02", which is partially
> assigned to 3Com and others, might be useful.
>
I wouldn't necessarily disagree. I would say that if that path was
taken, then you'd probably also want to be avoiding all the other
well known mac addresses that do or can fall within the locally
assigned range e.g. DECnet 0xAA addresses, Microsoft's use of
02:01:00:00:00:00 and similar addresses for their Network Load
Balancing software, the unicast version of the CF:00:00:00:00:00
multicast address use for ECTP, the unicast version of the
33:33:xx:xx:xx:xx IPv6 ND multicast ranges etc.
Having thought about this issue a bit before, another thought might be
to have somebody get the Linux kernel it's own OUI, and then have
addresses randomly selected out of that. As my day job is networking,
I'd find some value in being able to see a well known OUI for Linux
randomly generated addresses, rather than the complete randomness that
is the case now.
The drawback there is that there are then only 24 bits octets of
randomness in the addresses that each host can independently choose to
use, which isn't anywhere near the as random as the 2^46 the LA address
space provides. For most ethernet segments, 24 bits of randomness might
be ok, however some of the very large metro ethernet networks are
starting to carry 16000+ MAC addresses, all within the same, very
controlled broadcast domain.
> Not drawing from entropy I think useful, but it's debatable.
>
>
I'm guessing there are other things in the kernel that would be taking
away far more entropy, far more often. IIRC, TCP connection initial
sequence number selection would be one example.
^ permalink raw reply
* Info
From: Irish News Centre @ 2009-09-13 0:58 UTC (permalink / raw)
You have won £ 750,000 pounds. Send the required information: name, age, country
^ permalink raw reply
* Re: [net-next PATCH] etherdevice.h: random_ether_addr update
From: Joe Perches @ 2009-09-13 0:44 UTC (permalink / raw)
To: Mark Smith
Cc: Stephen Hemminger, David Miller, jeffrey.t.kirsher, netdev, gospo,
gregory.v.rose, donald.c.skidmore
In-Reply-To: <20090913100342.4f6a2417@opy.nosense.org>
On Sun, 2009-09-13 at 10:03 +0930, Mark Smith wrote:
> Hmm, probably didn't make my point all that clear. IOW, anything that
> can contribute to avoiding duplicate mac addresses is worth it in my
> opinion, when compared to the time (usually hours) involved in
> troubleshooting duplicate mac addresses.
Avoiding an initial octet of "02", which is partially
assigned to 3Com and others, might be useful.
Not drawing from entropy I think useful, but it's debatable.
^ permalink raw reply
* Re: [net-next PATCH] etherdevice.h: random_ether_addr update
From: Mark Smith @ 2009-09-13 0:33 UTC (permalink / raw)
To: Mark Smith
Cc: Joe Perches, Stephen Hemminger, David Miller, jeffrey.t.kirsher,
netdev, gospo, gregory.v.rose, donald.c.skidmore
In-Reply-To: <20090913094409.2dd88212@opy.nosense.org>
On Sun, 13 Sep 2009 09:44:09 +0930
Mark Smith <lk-netdev@lk-netdev.nosense.org> wrote:
> On Fri, 11 Sep 2009 17:57:47 -0700
> Joe Perches <joe@perches.com> wrote:
>
> > On Fri, 2009-09-11 at 14:15 -0700, Stephen Hemminger wrote:
> > > On Fri, 2009-09011 at 13:20 -0700 Joe Perches wrote:
> > > > Do not use get_random_bytes to avoid drawing down entropy pool.
> > > Getting 6 bytes once is not going to be enough of a problem
> > > to drain the pool. I prefer not to weaken the randomness here.
> >
> > I see no reason to draw down the entropy pool.
> >
> > I have a hard time imagining that a random mac address
> > needs more than reasonably random values.
> >
>
> One factor to consider is the amount of effort involved in
> troubleshooting duplicate mac address problems. They don't happen
> very often, and most people won't encounter them at all. That means
> they're very low on the list of things you suspect when
> troubleshooting, so you spend a lot of time investigating other things
> first, without that time providing any value once you work out what the
> actual fault it. Once you work out what the problem is, working out
> which devices are causing it can also be an effort, as, of course, they
> now don't have unique identifiers.
>
Hmm, probably didn't make my point all that clear. IOW, anything that
can contribute to avoiding duplicate mac addresses is worth it in my
opinion, when compared to the time (usually hours) involved in
troubleshooting duplicate mac addresses.
>
>
> > Why do you think it's reasonable to draw from the
> > entropy pool?
> >
> > cheers, Joe
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [net-next PATCH] etherdevice.h: random_ether_addr update
From: Mark Smith @ 2009-09-13 0:14 UTC (permalink / raw)
To: Joe Perches
Cc: Stephen Hemminger, David Miller, jeffrey.t.kirsher, netdev, gospo,
gregory.v.rose, donald.c.skidmore
In-Reply-To: <1252717067.29420.22.camel@Joe-Laptop.home>
On Fri, 11 Sep 2009 17:57:47 -0700
Joe Perches <joe@perches.com> wrote:
> On Fri, 2009-09-11 at 14:15 -0700, Stephen Hemminger wrote:
> > On Fri, 2009-09011 at 13:20 -0700 Joe Perches wrote:
> > > Do not use get_random_bytes to avoid drawing down entropy pool.
> > Getting 6 bytes once is not going to be enough of a problem
> > to drain the pool. I prefer not to weaken the randomness here.
>
> I see no reason to draw down the entropy pool.
>
> I have a hard time imagining that a random mac address
> needs more than reasonably random values.
>
One factor to consider is the amount of effort involved in
troubleshooting duplicate mac address problems. They don't happen
very often, and most people won't encounter them at all. That means
they're very low on the list of things you suspect when
troubleshooting, so you spend a lot of time investigating other things
first, without that time providing any value once you work out what the
actual fault it. Once you work out what the problem is, working out
which devices are causing it can also be an effort, as, of course, they
now don't have unique identifiers.
> Why do you think it's reasonable to draw from the
> entropy pool?
>
> cheers, Joe
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] pcnet_cs: add cis of Linksys multifunction pcmcia card
From: Ken Kawasaki @ 2009-09-12 22:22 UTC (permalink / raw)
To: netdev; +Cc: ken_kawasaki
In-Reply-To: <20090426162929.3d036f26.ken_kawasaki@spring.nifty.jp>
pcnet_cs,serial_cs:
add cis of Linksys lan&modem mulitifunction pcmcia card
and some modem card(MT5634ZLX, RS-COM-2P).
Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
---
drivers/net/pcmcia/pcnet_cs.c | 10 +++++-----
drivers/serial/serial_cs.c | 14 +++++++-------
firmware/Makefile | 3 ++-
firmware/WHENCE | 12 ++++++++++++
firmware/cis/MT5634ZLX.cis.ihex | 11 +++++++++++
firmware/cis/PCMLM28.cis.ihex | 18 ++++++++++++++++++
firmware/cis/RS-COM-2P.cis.ihex | 10 ++++++++++
7 files changed, 65 insertions(+), 13 deletions(-)
diff -uprN linux-2.6.31.orig/drivers/net/pcmcia/pcnet_cs.c linux-2.6.31/drivers/net/pcmcia/pcnet_cs.c
--- linux-2.6.31.orig/drivers/net/pcmcia/pcnet_cs.c 2009-09-10 07:13:59.000000000 +0900
+++ linux-2.6.31/drivers/net/pcmcia/pcnet_cs.c 2009-09-12 19:59:57.000000000 +0900
@@ -1751,11 +1751,11 @@ static struct pcmcia_device_id pcnet_ids
PCMCIA_DEVICE_PROD_ID2("EN-6200P2", 0xa996d078),
/* too generic! */
/* PCMCIA_DEVICE_PROD_ID12("PCMCIA", "10/100 Ethernet Card", 0x281f1c5d, 0x11b0ffc0), */
- PCMCIA_PFC_DEVICE_CIS_PROD_ID12(0, "PCMCIA", "EN2218-LAN/MODEM", 0x281f1c5d, 0x570f348e, "PCMLM28.cis"),
- PCMCIA_PFC_DEVICE_CIS_PROD_ID12(0, "PCMCIA", "UE2218-LAN/MODEM", 0x281f1c5d, 0x6fdcacee, "PCMLM28.cis"),
- PCMCIA_PFC_DEVICE_CIS_PROD_ID12(0, "Psion Dacom", "Gold Card V34 Ethernet", 0xf5f025c2, 0x338e8155, "PCMLM28.cis"),
- PCMCIA_PFC_DEVICE_CIS_PROD_ID12(0, "Psion Dacom", "Gold Card V34 Ethernet GSM", 0xf5f025c2, 0x4ae85d35, "PCMLM28.cis"),
- PCMCIA_PFC_DEVICE_CIS_PROD_ID12(0, "LINKSYS", "PCMLM28", 0xf7cb0b07, 0x66881874, "PCMLM28.cis"),
+ PCMCIA_PFC_DEVICE_CIS_PROD_ID12(0, "PCMCIA", "EN2218-LAN/MODEM", 0x281f1c5d, 0x570f348e, "cis/PCMLM28.cis"),
+ PCMCIA_PFC_DEVICE_CIS_PROD_ID12(0, "PCMCIA", "UE2218-LAN/MODEM", 0x281f1c5d, 0x6fdcacee, "cis/PCMLM28.cis"),
+ PCMCIA_PFC_DEVICE_CIS_PROD_ID12(0, "Psion Dacom", "Gold Card V34 Ethernet", 0xf5f025c2, 0x338e8155, "cis/PCMLM28.cis"),
+ PCMCIA_PFC_DEVICE_CIS_PROD_ID12(0, "Psion Dacom", "Gold Card V34 Ethernet GSM", 0xf5f025c2, 0x4ae85d35, "cis/PCMLM28.cis"),
+ PCMCIA_PFC_DEVICE_CIS_PROD_ID12(0, "LINKSYS", "PCMLM28", 0xf7cb0b07, 0x66881874, "cis/PCMLM28.cis"),
PCMCIA_MFC_DEVICE_CIS_PROD_ID12(0, "DAYNA COMMUNICATIONS", "LAN AND MODEM MULTIFUNCTION", 0x8fdf8f89, 0xdd5ed9e8, "DP83903.cis"),
PCMCIA_MFC_DEVICE_CIS_PROD_ID4(0, "NSC MF LAN/Modem", 0x58fc6056, "DP83903.cis"),
PCMCIA_MFC_DEVICE_CIS_MANF_CARD(0, 0x0175, 0x0000, "DP83903.cis"),
diff -uprN linux-2.6.31.orig/drivers/serial/serial_cs.c linux-2.6.31/drivers/serial/serial_cs.c
--- linux-2.6.31.orig/drivers/serial/serial_cs.c 2009-09-10 07:13:59.000000000 +0900
+++ linux-2.6.31/drivers/serial/serial_cs.c 2009-09-12 20:02:33.000000000 +0900
@@ -868,11 +868,11 @@ static struct pcmcia_device_id serial_id
PCMCIA_DEVICE_PROD_ID12("PCMCIA ", "C336MX ", 0x99bcafe9, 0xaa25bcab),
PCMCIA_DEVICE_PROD_ID12("Quatech Inc", "PCMCIA Dual RS-232 Serial Port Card", 0xc4420b35, 0x92abc92f),
PCMCIA_DEVICE_PROD_ID12("Quatech Inc", "Dual RS-232 Serial Port PC Card", 0xc4420b35, 0x031a380d),
- PCMCIA_PFC_DEVICE_CIS_PROD_ID12(1, "PCMCIA", "EN2218-LAN/MODEM", 0x281f1c5d, 0x570f348e, "PCMLM28.cis"),
- PCMCIA_PFC_DEVICE_CIS_PROD_ID12(1, "PCMCIA", "UE2218-LAN/MODEM", 0x281f1c5d, 0x6fdcacee, "PCMLM28.cis"),
- PCMCIA_PFC_DEVICE_CIS_PROD_ID12(1, "Psion Dacom", "Gold Card V34 Ethernet", 0xf5f025c2, 0x338e8155, "PCMLM28.cis"),
- PCMCIA_PFC_DEVICE_CIS_PROD_ID12(1, "Psion Dacom", "Gold Card V34 Ethernet GSM", 0xf5f025c2, 0x4ae85d35, "PCMLM28.cis"),
- PCMCIA_PFC_DEVICE_CIS_PROD_ID12(1, "LINKSYS", "PCMLM28", 0xf7cb0b07, 0x66881874, "PCMLM28.cis"),
+ PCMCIA_PFC_DEVICE_CIS_PROD_ID12(1, "PCMCIA", "EN2218-LAN/MODEM", 0x281f1c5d, 0x570f348e, "cis/PCMLM28.cis"),
+ PCMCIA_PFC_DEVICE_CIS_PROD_ID12(1, "PCMCIA", "UE2218-LAN/MODEM", 0x281f1c5d, 0x6fdcacee, "cis/PCMLM28.cis"),
+ PCMCIA_PFC_DEVICE_CIS_PROD_ID12(1, "Psion Dacom", "Gold Card V34 Ethernet", 0xf5f025c2, 0x338e8155, "cis/PCMLM28.cis"),
+ PCMCIA_PFC_DEVICE_CIS_PROD_ID12(1, "Psion Dacom", "Gold Card V34 Ethernet GSM", 0xf5f025c2, 0x4ae85d35, "cis/PCMLM28.cis"),
+ PCMCIA_PFC_DEVICE_CIS_PROD_ID12(1, "LINKSYS", "PCMLM28", 0xf7cb0b07, 0x66881874, "cis/PCMLM28.cis"),
PCMCIA_MFC_DEVICE_CIS_PROD_ID12(1, "DAYNA COMMUNICATIONS", "LAN AND MODEM MULTIFUNCTION", 0x8fdf8f89, 0xdd5ed9e8, "DP83903.cis"),
PCMCIA_MFC_DEVICE_CIS_PROD_ID4(1, "NSC MF LAN/Modem", 0x58fc6056, "DP83903.cis"),
PCMCIA_MFC_DEVICE_CIS_MANF_CARD(1, 0x0101, 0x0556, "cis/3CCFEM556.cis"),
@@ -883,10 +883,10 @@ static struct pcmcia_device_id serial_id
PCMCIA_DEVICE_CIS_MANF_CARD(0x0192, 0x0710, "SW_7xx_SER.cis"), /* Sierra Wireless AC710/AC750 GPRS Network Adapter R1 */
PCMCIA_DEVICE_CIS_MANF_CARD(0x0192, 0xa555, "SW_555_SER.cis"), /* Sierra Aircard 555 CDMA 1xrtt Modem -- pre update */
PCMCIA_DEVICE_CIS_MANF_CARD(0x013f, 0xa555, "SW_555_SER.cis"), /* Sierra Aircard 555 CDMA 1xrtt Modem -- post update */
- PCMCIA_DEVICE_CIS_PROD_ID12("MultiTech", "PCMCIA 56K DataFax", 0x842047ee, 0xc2efcf03, "MT5634ZLX.cis"),
+ PCMCIA_DEVICE_CIS_PROD_ID12("MultiTech", "PCMCIA 56K DataFax", 0x842047ee, 0xc2efcf03, "cis/MT5634ZLX.cis"),
PCMCIA_DEVICE_CIS_PROD_ID12("ADVANTECH", "COMpad-32/85B-4", 0x96913a85, 0xcec8f102, "COMpad4.cis"),
PCMCIA_DEVICE_CIS_PROD_ID123("ADVANTECH", "COMpad-32/85", "1.0", 0x96913a85, 0x8fbe92ae, 0x0877b627, "COMpad2.cis"),
- PCMCIA_DEVICE_CIS_PROD_ID2("RS-COM 2P", 0xad20b156, "RS-COM-2P.cis"),
+ PCMCIA_DEVICE_CIS_PROD_ID2("RS-COM 2P", 0xad20b156, "cis/RS-COM-2P.cis"),
PCMCIA_DEVICE_CIS_MANF_CARD(0x0013, 0x0000, "GLOBETROTTER.cis"),
PCMCIA_DEVICE_PROD_ID12("ELAN DIGITAL SYSTEMS LTD, c1997.","SERIAL CARD: SL100 1.00.",0x19ca78af,0xf964f42b),
PCMCIA_DEVICE_PROD_ID12("ELAN DIGITAL SYSTEMS LTD, c1997.","SERIAL CARD: SL100",0x19ca78af,0x71d98e83),
diff -uprN linux-2.6.31.orig/firmware/cis/MT5634ZLX.cis.ihex linux-2.6.31/firmware/cis/MT5634ZLX.cis.ihex
--- linux-2.6.31.orig/firmware/cis/MT5634ZLX.cis.ihex 1970-01-01 09:00:00.000000000 +0900
+++ linux-2.6.31/firmware/cis/MT5634ZLX.cis.ihex 2009-09-12 19:58:04.000000000 +0900
@@ -0,0 +1,11 @@
+:100000000101FF152204014D756C74695465636824
+:100010000050434D4349412035364B2044617461C3
+:10002000466178000000FF20040002010021020266
+:10003000001A05012780FF671B0FCF418B01550177
+:10004000550155AA60F80307281B08970108AA6004
+:10005000F802071B089F0108AA60E803071B08A70E
+:0B0060000108AA60E802071400FF007E
+:00000001FF
+#
+# Replacement CIS for Multitech MT5634ZLX modems
+#
diff -uprN linux-2.6.31.orig/firmware/cis/PCMLM28.cis.ihex linux-2.6.31/firmware/cis/PCMLM28.cis.ihex
--- linux-2.6.31.orig/firmware/cis/PCMLM28.cis.ihex 1970-01-01 09:00:00.000000000 +0900
+++ linux-2.6.31/firmware/cis/PCMLM28.cis.ihex 2009-09-12 19:57:29.000000000 +0900
@@ -0,0 +1,18 @@
+:1000000001030000FF151504014C494E4B53595391
+:100010000050434D4C4D3238000000FF2004430196
+:10002000ABC0210200001A05012FF803031B10E4E6
+:1000300001190155E06100031FF8020730FFFF1BA3
+:100040000BA50108E06120031FF802071B0BA601A6
+:1000500008E06140031FF802071B0BA70108E061DD
+:1000600060031FF802071B0BA80108E06100031FD3
+:10007000E803071B0BA90108E06120031FE8030741
+:100080001B0BAA0108E06140031FE803071B0BAB31
+:100090000108E06160031FE803071B0BAC0108E0E7
+:1000A0006100031FE802071B0BAD0108E06120039C
+:1000B0001FE802071B0BAE0108E06140031FE802C6
+:1000C000071B0BAF0108E06160031FE80207140083
+:0200D000FF002F
+:00000001FF
+#
+# The on-card CIS says it is MFC-compliant, but it is not
+#
diff -uprN linux-2.6.31.orig/firmware/cis/RS-COM-2P.cis.ihex linux-2.6.31/firmware/cis/RS-COM-2P.cis.ihex
--- linux-2.6.31.orig/firmware/cis/RS-COM-2P.cis.ihex 1970-01-01 09:00:00.000000000 +0900
+++ linux-2.6.31/firmware/cis/RS-COM-2P.cis.ihex 2009-09-12 19:58:12.000000000 +0900
@@ -0,0 +1,10 @@
+:1000000001030000FF1516040150434D4349410010
+:1000100052532D434F4D203250000000FF21020269
+:10002000011A0501030001011B0EC18118AA61E834
+:100030000307E8020730B89E1B0B820108AA615033
+:1000400002075802071B0B830108AA6160020768B8
+:0600500002071400FF008E
+:00000001FF
+#
+# Replacement CIS for dual-serial-port IO card
+#
diff -uprN linux-2.6.31.orig/firmware/Makefile linux-2.6.31/firmware/Makefile
--- linux-2.6.31.orig/firmware/Makefile 2009-09-10 07:13:59.000000000 +0900
+++ linux-2.6.31/firmware/Makefile 2009-09-12 20:12:11.000000000 +0900
@@ -47,9 +47,10 @@ fw-shipped-$(CONFIG_DVB_TTUSB_BUDGET) +=
fw-shipped-$(CONFIG_E100) += e100/d101m_ucode.bin e100/d101s_ucode.bin \
e100/d102e_ucode.bin
fw-shipped-$(CONFIG_MYRI_SBUS) += myricom/lanai.bin
-fw-shipped-$(CONFIG_PCMCIA_PCNET) += cis/LA-PCM.cis
+fw-shipped-$(CONFIG_PCMCIA_PCNET) += cis/LA-PCM.cis cis/PCMLM28.cis
fw-shipped-$(CONFIG_PCMCIA_3C589) += cis/3CXEM556.cis
fw-shipped-$(CONFIG_PCMCIA_3C574) += cis/3CCFEM556.cis
+fw-shipped-$(CONFIG_SERIAL_8250_CS) += cis/MT5634ZLX.cis cis/RS-COM-2P.cis
fw-shipped-$(CONFIG_PCMCIA_SMC91C92) += ositech/Xilinx7OD.bin
fw-shipped-$(CONFIG_SCSI_ADVANSYS) += advansys/mcode.bin advansys/38C1600.bin \
advansys/3550.bin advansys/38C0800.bin
diff -uprN linux-2.6.31.orig/firmware/WHENCE linux-2.6.31/firmware/WHENCE
--- linux-2.6.31.orig/firmware/WHENCE 2009-09-10 07:13:59.000000000 +0900
+++ linux-2.6.31/firmware/WHENCE 2009-09-12 20:09:40.000000000 +0900
@@ -579,6 +579,7 @@ Found in hex form in kernel source.
Driver: PCMCIA_PCNET - NE2000 compatible PCMCIA adapter
File: cis/LA-PCM.cis
+ cis/PCMLM28.cis
Licence: GPL
@@ -606,6 +607,17 @@ Originally developed by the pcmcia-cs pr
--------------------------------------------------------------------------
+Driver: SERIAL_8250_CS - Serial PCMCIA adapter
+
+File: cis/MT5634ZLX.cis
+ cis/RS-COM-2P.cis
+
+Licence: GPL
+
+Originally developed by the pcmcia-cs project
+
+--------------------------------------------------------------------------
+
Driver: PCMCIA_SMC91C92 - SMC 91Cxx PCMCIA
File: ositech/Xilinx7OD.bin
^ permalink raw reply
* Re: [iproute2] tc action mirred question
From: jamal @ 2009-09-12 21:49 UTC (permalink / raw)
To: Xiaofei Wu; +Cc: linux netdev
In-Reply-To: <463375.95638.qm@web111612.mail.gq1.yahoo.com>
On Sat, 2009-09-12 at 09:01 -0700, Xiaofei Wu wrote:
> I can mirror the packets (A -> B) to D. Node D forwards them to C.
> Sometimes the same packets through the path A-B-C, A-D-C are not lost. Node C will receive the
> same packets twice. How to handle the duplicate packet on node C ?
>
> Maybe the duplicate packets have side effects to TCP.
>
I will leave this to you. This is where you go and do interesting
things, publish your results and maybe write a paper.
I dont think its a big deal to receive duplicate packets.
cheers,
jamal
^ permalink raw reply
* Re: [Bug #13328] b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear.
From: Francis Moreau @ 2009-09-12 19:27 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List, netdev
In-Reply-To: <hKF51Pczj6N.A.1CB.q5BpKB@chimera>
On Sun, Sep 6, 2009 at 8:11 PM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> This message has been generated automatically as a part of a report
> of regressions introduced between 2.6.29 and 2.6.30.
>
> The following bug entry is on the current list of known regressions
> introduced between 2.6.29 and 2.6.30. Please verify if it still should
> be listed and let me know (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13328
> Subject : b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear.
> Submitter : Francis Moreau <francis.moro-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date : 2009-05-03 16:22 (127 days old)
> References : http://marc.info/?l=linux-kernel&m=124136778012280&w=4
>
still in 2.6.31
--
Francis
^ permalink raw reply
* [RFC][PATCH] pcmcia: pcnet_cs.c removing useless condition
From: Jaswinder Singh Rajput @ 2009-09-12 19:08 UTC (permalink / raw)
To: David Miller, Jeff Garzik, netdev, linux-pcmcia,
Dominik Brodowski
[This is untested]
'if (i < NR_INFO)' will only true if we breaks from 'for (i = 0; i < NR_INFO; i++)'
So removing useless 'if (i < NR_INFO)'
This also fixed following compilation warning :
CC [M] drivers/net/pcmcia/pcnet_cs.o
drivers/net/pcmcia/pcnet_cs.c: In function ‘get_hwinfo’:
drivers/net/pcmcia/pcnet_cs.c:321: warning: ‘base’ may be used uninitialized in this function
Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
---
drivers/net/pcmcia/pcnet_cs.c | 11 +++++------
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/net/pcmcia/pcnet_cs.c b/drivers/net/pcmcia/pcnet_cs.c
index 9ef1c1b..6a60227 100644
--- a/drivers/net/pcmcia/pcnet_cs.c
+++ b/drivers/net/pcmcia/pcnet_cs.c
@@ -339,12 +339,11 @@ static hw_info_t *get_hwinfo(struct pcmcia_device *link)
base = &virt[hw_info[i].offset & (req.Size-1)];
if ((readb(base+0) == hw_info[i].a0) &&
(readb(base+2) == hw_info[i].a1) &&
- (readb(base+4) == hw_info[i].a2))
- break;
- }
- if (i < NR_INFO) {
- for (j = 0; j < 6; j++)
- dev->dev_addr[j] = readb(base + (j<<1));
+ (readb(base+4) == hw_info[i].a2)) {
+ for (j = 0; j < 6; j++)
+ dev->dev_addr[j] = readb(base + (j<<1));
+ break;
+ }
}
iounmap(virt);
--
1.6.4.2
^ permalink raw reply related
* Re: [PATCH 1/5] First Patch on TFRC-SP. Copy base files from TFRC
From: Gerrit Renker @ 2009-09-12 18:32 UTC (permalink / raw)
To: Ivo Calado; +Cc: dccp, netdev
In-Reply-To: <4AA6A25A.5040508@embedded.ufcg.edu.br>
Hi Ivo,
you have made a really good job of sticking to code conventions (see other
posting). There are a few things that needed tending to in the first patch.
(1) Version changes
===================
It seems that you applied something like s/\*\*/*/g to the first instance of
the patch, in order to remove duplicate asterisks. This caused a problem:
--- tfrc_sp_receiver_01.patch 2009/09/12 08:37:12 1.1
+++ tfrc_sp_receiver_01.patch 2009/09/08 17:34:40
@@ -1001,8 +1001,8 @@ Index: dccp_tree_work4/net/dccp/ccids/li
+
+#endif
+
-+extern int tfrc_sp_tx_hist_add(struct tfrc_tx_hist_entry **headp, u64 seqno);
-+extern void tfrc_sp_tx_hist_purge(struct tfrc_tx_hist_entry **headp);
++extern int tfrc_sp_tx_hist_add(struct tfrc_tx_hist_entry *headp, u64 seqno);
++extern void tfrc_sp_tx_hist_purge(struct tfrc_tx_hist_entry *headp);
I have reverted the bug, also to minimise the difference to the existing (non
TFRC-SP) files.
(2) Other changes that I edited out
===================================
(Other than whitespace changes.)
net/dccp/ccids/lib/loss_interval_sp.c
-------------------------------------
I replaced the following dead code
if ((tfrc_lh_slab != NULL))
return 0;
if (tfrc_lh_slab != NULL) {
kmem_cache_destroy(tfrc_lh_slab);
tfrc_lh_slab = NULL;
}
return -ENOBUFS;
with
return tfrc_lh_slab == NULL ? -ENOBUFS : 0;
Also separated the conditions
+ if ((len <= 0) ||
+ (!tfrc_lh_closed_check(cur, cong_evt->tfrchrx_ccval))) {
back into
if (len <= 0)
return false;
if (!tfrc_lh_closed_check(cur, cong_evt->tfrchrx_ccval))
return false;
I removed the following unnecessary inclusion:
+#include <linux/random.h>
The following function pokes a hole in thei so far "abstract" data type;
the convention has been to access the internals of the struct only via
get-functions:
static inline struct tfrc_loss_interval
*tfrc_lh_get_loss_interval(struct tfrc_loss_hist *lh, const u8 i)
{
BUG_ON(i >= lh->counter);
return lh->ring[LIH_INDEX(lh->counter - i - 1)];
}
(You use it in patch 3/5 to gain access to li_ccval and li_losses.
Better would be to have two separate accessor functions.)
net/dccp/ccids/lib/tfrc_equation_sp.c
-------------------------------------
This is a prime candidate for removal. After editing out the whitespace
differences, I found that it is 100% identical with tfrc_equation.c.
The result of this editing has been uploaded to
http://eden-feed.erg.abdn.ac.uk/tfrc_sp_receiver_01.patch
^ permalink raw reply
* Re: mac80211: NOHZ: local_softirq_pending 08
From: Oliver Hartkopp @ 2009-09-12 18:07 UTC (permalink / raw)
To: Michael Buesch
Cc: Kalle Valo, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Johannes Berg, John W. Linville
In-Reply-To: <200909121851.46002.mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org>
Michael Buesch wrote:
> On Saturday 12 September 2009 18:41:12 Oliver Hartkopp wrote:
>> Michael Buesch wrote:
>>
>>>> As there are several users in the kernel do exact this test and call the
>>>> appropriate netif_rx() function, i would suggest to create a static inline
>>>> function:
>>>>
>>>> static inline int netif_rx_ti(struct sk_buff *skb)
>>>> {
>>>> if (in_interrupt())
>>>> return netif_rx(skb);
>>>> return netif_rx_ni(skb);
>>>> }
>>>>
>>>> ('ti' for test in_interrupt())
>>>>
>>>> in include/linux/netdevice.h
>>>>
>>>> What do you think about that?
>>> Yeah, I'm fine with that.
>>>
>> Hi Michael,
>>
>> i cooked a patch that introduces netif_rx_ti() and fixes up the problems in
>> mac80211 and the CAN subsystem.
>>
>> Currently i'm pondering whether netif_rx_ti() is needed in all cases or if
>> there are code sections that'll never be executed from irq-context.
>>
>> In theses cases netif_rx_ni() should be prefered to netif_rx_ti() to prevent
>> the obsolete check ...
>>
>> Is there any of your changes that should better use netif_rx_ni() ?
>>
>> Regards,
>> Oliver
>>
>
> Well, I'd say this check does not cost much at all.
> If I were the net maintainer, I'd get rid of netif_rx_ni() _and_ netif_rx_ti() and
> do the check internally in netif_rx().
> But as I don't have to decide that, I just want the mac80211 issue fixed.
>
Like this?
int netif_rx(struct sk_buff *skb)
{
int err;
if (likely(in_interrupt()))
err = __netif_rx(skb);
else {
preempt_disable();
err = __netif_rx(skb);
if (local_softirq_pending())
do_softirq();
preempt_enable();
}
return err;
}
I don't know how expensive in_interrupt() is ... checking the code does not
give any answers to *me* ;-)
But i found
356 netif_rx()
but only
18 netif_rx_ni()
in the kernel tree.
And three of them check for in_interrupt() before using netif_rx() or
netif_rx_ni() ...
Finally i would tend to introduce netif_rx_ti() in include/linux/netdevice.h
as described above, for the rare code that can be used inside and outside the
irq context.
I assume the affected code in the CAN stuff has to use netif_rx_ni() - but i
will doublecheck that (and prepare a separate CAN patch).
For the mac80211 i would suggest to check whether you really need
netif_rx()/netif_rx_ni()/netif_rx_ti() in all the regarded cases.
I assume always using netif_rx_ti() (as you proposed in the original patch) is
not the most efficient approach.
Best regards,
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* net-next-2.6 [PATCH 1/1] dccp: ccids whitespace-cleanup / CodingStyle
From: Gerrit Renker @ 2009-09-12 17:47 UTC (permalink / raw)
To: netdev; +Cc: dccp, ivocalado
dccp: ccid whitespace/CodingStyle cleanup
No code change, cosmetical changes only:
* whitespace cleanup via scripts/cleanfile,
* remove self-references to filename at top of files,
* fix coding style (extraneous brackets),
* fix documentation style (kernel-doc-nano-HOWTO).
Thanks are due to Ivo Augusto Calado who raised these issues by
submitting good-quality patches.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
net/dccp/ccids/Kconfig | 6 ++--
net/dccp/ccids/ccid2.c | 2 -
net/dccp/ccids/ccid2.h | 8 ++---
net/dccp/ccids/ccid3.c | 5 +--
net/dccp/ccids/ccid3.h | 50 +++++++++++++++++-------------------
net/dccp/ccids/lib/loss_interval.c | 7 ++---
net/dccp/ccids/lib/loss_interval.h | 2 -
net/dccp/ccids/lib/packet_history.c | 4 --
net/dccp/ccids/lib/packet_history.h | 1
net/dccp/ccids/lib/tfrc.h | 4 --
net/dccp/ccids/lib/tfrc_equation.c | 26 +++++++-----------
11 files changed, 48 insertions(+), 67 deletions(-)
--- a/net/dccp/ccids/lib/packet_history.c
+++ b/net/dccp/ccids/lib/packet_history.c
@@ -1,6 +1,4 @@
/*
- * net/dccp/packet_history.c
- *
* Copyright (c) 2007 The University of Aberdeen, Scotland, UK
* Copyright (c) 2005-7 The University of Waikato, Hamilton, New Zealand.
*
@@ -128,7 +126,7 @@ u32 tfrc_tx_hist_rtt(struct tfrc_tx_hist
/*
- * Receiver History Routines
+ * Receiver History Routines
*/
static struct kmem_cache *tfrc_rx_hist_slab;
--- a/net/dccp/ccids/lib/tfrc_equation.c
+++ b/net/dccp/ccids/lib/tfrc_equation.c
@@ -1,6 +1,4 @@
/*
- * net/dccp/ccids/lib/tfrc_equation.c
- *
* Copyright (c) 2005 The University of Waikato, Hamilton, New Zealand.
* Copyright (c) 2005 Ian McDonald <ian.mcdonald@jandi.co.nz>
* Copyright (c) 2005 Arnaldo Carvalho de Melo <acme@conectiva.com.br>
@@ -79,10 +77,10 @@
}
With the given configuration, we have, with M = TFRC_CALC_X_ARRSIZE-1,
- lookup[0][0] = g(1000000/(M+1)) = 1000000 * f(0.2%)
- lookup[M][0] = g(1000000) = 1000000 * f(100%)
- lookup[0][1] = g(TFRC_SMALLEST_P) = 1000000 * f(0.01%)
- lookup[M][1] = g(TFRC_CALC_X_SPLIT) = 1000000 * f(5%)
+ lookup[0][0] = g(1000000/(M+1)) = 1000000 * f(0.2%)
+ lookup[M][0] = g(1000000) = 1000000 * f(100%)
+ lookup[0][1] = g(TFRC_SMALLEST_P) = 1000000 * f(0.01%)
+ lookup[M][1] = g(TFRC_CALC_X_SPLIT) = 1000000 * f(5%)
In summary, the two columns represent f(p) for the following ranges:
* The first column is for 0.002 <= p <= 1.0
@@ -610,11 +608,10 @@ static inline u32 tfrc_binsearch(u32 fva
/**
* tfrc_calc_x - Calculate the send rate as per section 3.1 of RFC3448
- *
- * @s: packet size in bytes
- * @R: RTT scaled by 1000000 (i.e., microseconds)
- * @p: loss ratio estimate scaled by 1000000
- * Returns X_calc in bytes per second (not scaled).
+ * @s: packet size in bytes
+ * @R: RTT scaled by 1000000 (i.e., microseconds)
+ * @p: loss ratio estimate scaled by 1000000
+ * Returns X_calc in bytes per second (not scaled).
*/
u32 tfrc_calc_x(u16 s, u32 R, u32 p)
{
@@ -630,17 +627,17 @@ u32 tfrc_calc_x(u16 s, u32 R, u32 p)
return ~0U;
}
- if (p <= TFRC_CALC_X_SPLIT) { /* 0.0000 < p <= 0.05 */
+ if (p <= TFRC_CALC_X_SPLIT) { /* 0.0000 < p <= 0.05 */
if (p < TFRC_SMALLEST_P) { /* 0.0000 < p < 0.0001 */
DCCP_WARN("Value of p (%d) below resolution. "
"Substituting %d\n", p, TFRC_SMALLEST_P);
index = 0;
- } else /* 0.0001 <= p <= 0.05 */
+ } else /* 0.0001 <= p <= 0.05 */
index = p/TFRC_SMALLEST_P - 1;
f = tfrc_calc_x_lookup[index][1];
- } else { /* 0.05 < p <= 1.00 */
+ } else { /* 0.05 < p <= 1.00 */
index = p/(1000000/TFRC_CALC_X_ARRSIZE) - 1;
f = tfrc_calc_x_lookup[index][0];
@@ -661,7 +658,6 @@ u32 tfrc_calc_x(u16 s, u32 R, u32 p)
/**
* tfrc_calc_x_reverse_lookup - try to find p given f(p)
- *
* @fvalue: function value to match, scaled by 1000000
* Returns closest match for p, also scaled by 1000000
*/
--- a/net/dccp/ccids/lib/loss_interval.c
+++ b/net/dccp/ccids/lib/loss_interval.c
@@ -1,6 +1,4 @@
/*
- * net/dccp/ccids/lib/loss_interval.c
- *
* Copyright (c) 2007 The University of Aberdeen, Scotland, UK
* Copyright (c) 2005-7 The University of Waikato, Hamilton, New Zealand.
* Copyright (c) 2005-7 Ian McDonald <ian.mcdonald@jandi.co.nz>
@@ -21,7 +19,7 @@ static const int tfrc_lh_weights[NINTERV
/* implements LIFO semantics on the array */
static inline u8 LIH_INDEX(const u8 ctr)
{
- return (LIH_SIZE - 1 - (ctr % LIH_SIZE));
+ return LIH_SIZE - 1 - (ctr % LIH_SIZE);
}
/* the `counter' index always points at the next entry to be populated */
@@ -129,7 +127,8 @@ static inline u8 tfrc_lh_is_new_loss(str
(cur->li_is_closed || SUB16(new_loss->tfrchrx_ccval, cur->li_ccval) > 4);
}
-/** tfrc_lh_interval_add - Insert new record into the Loss Interval database
+/**
+ * tfrc_lh_interval_add - Insert new record into the Loss Interval database
* @lh: Loss Interval database
* @rh: Receive history containing a fresh loss event
* @calc_first_li: Caller-dependent routine to compute length of first interval
--- a/net/dccp/ccids/lib/loss_interval.h
+++ b/net/dccp/ccids/lib/loss_interval.h
@@ -1,8 +1,6 @@
#ifndef _DCCP_LI_HIST_
#define _DCCP_LI_HIST_
/*
- * net/dccp/ccids/lib/loss_interval.h
- *
* Copyright (c) 2007 The University of Aberdeen, Scotland, UK
* Copyright (c) 2005-7 The University of Waikato, Hamilton, New Zealand.
* Copyright (c) 2005-7 Ian McDonald <ian.mcdonald@jandi.co.nz>
--- a/net/dccp/ccids/lib/tfrc.h
+++ b/net/dccp/ccids/lib/tfrc.h
@@ -1,8 +1,6 @@
#ifndef _TFRC_H_
#define _TFRC_H_
/*
- * net/dccp/ccids/lib/tfrc.h
- *
* Copyright (c) 2007 The University of Aberdeen, Scotland, UK
* Copyright (c) 2005-6 The University of Waikato, Hamilton, New Zealand.
* Copyright (c) 2005-6 Ian McDonald <ian.mcdonald@jandi.co.nz>
@@ -32,7 +30,7 @@ extern int tfrc_debug;
/* integer-arithmetic divisions of type (a * 1000000)/b */
static inline u64 scaled_div(u64 a, u64 b)
{
- BUG_ON(b==0);
+ BUG_ON(b == 0);
return div64_u64(a * 1000000, b);
}
--- a/net/dccp/ccids/Kconfig
+++ b/net/dccp/ccids/Kconfig
@@ -66,9 +66,9 @@ config IP_DCCP_CCID3_RTO
A value of 0 disables this feature by enforcing the value specified
in RFC 3448. The following values have been suggested as bounds for
experimental use:
- * 16-20ms to match the typical multimedia inter-frame interval
- * 100ms as a reasonable compromise [default]
- * 1000ms corresponds to the lower TCP RTO bound (RFC 2988, 2.4)
+ * 16-20ms to match the typical multimedia inter-frame interval
+ * 100ms as a reasonable compromise [default]
+ * 1000ms corresponds to the lower TCP RTO bound (RFC 2988, 2.4)
The default of 100ms is a compromise between a large value for
efficient DCCP implementations, and a small value to avoid disrupting
--- a/net/dccp/ccids/ccid2.c
+++ b/net/dccp/ccids/ccid2.c
@@ -1,6 +1,4 @@
/*
- * net/dccp/ccids/ccid2.c
- *
* Copyright (c) 2005, 2006 Andrea Bittau <a.bittau@cs.ucl.ac.uk>
*
* Changes to meet Linux coding standards, and DCCP infrastructure fixes.
--- a/net/dccp/ccids/ccid2.h
+++ b/net/dccp/ccids/ccid2.h
@@ -1,6 +1,4 @@
/*
- * net/dccp/ccids/ccid2.h
- *
* Copyright (c) 2005 Andrea Bittau <a.bittau@cs.ucl.ac.uk>
*
* This program is free software; you can redistribute it and/or modify
@@ -40,14 +38,14 @@ struct ccid2_seq {
#define CCID2_SEQBUF_LEN 1024
#define CCID2_SEQBUF_MAX 128
-/** struct ccid2_hc_tx_sock - CCID2 TX half connection
- *
+/**
+ * struct ccid2_hc_tx_sock - CCID2 TX half connection
* @ccid2hctx_{cwnd,ssthresh,pipe}: as per RFC 4341, section 5
* @ccid2hctx_packets_acked - Ack counter for deriving cwnd growth (RFC 3465)
* @ccid2hctx_lastrtt -time RTT was last measured
* @ccid2hctx_rpseq - last consecutive seqno
* @ccid2hctx_rpdupack - dupacks since rpseq
-*/
+ */
struct ccid2_hc_tx_sock {
u32 ccid2hctx_cwnd;
u32 ccid2hctx_ssthresh;
--- a/net/dccp/ccids/ccid3.c
+++ b/net/dccp/ccids/ccid3.c
@@ -1,6 +1,4 @@
/*
- * net/dccp/ccids/ccid3.c
- *
* Copyright (c) 2007 The University of Aberdeen, Scotland, UK
* Copyright (c) 2005-7 The University of Waikato, Hamilton, New Zealand.
* Copyright (c) 2005-7 Ian McDonald <ian.mcdonald@jandi.co.nz>
@@ -750,7 +748,8 @@ static int ccid3_hc_rx_insert_options(st
return 0;
}
-/** ccid3_first_li - Implements [RFC 3448, 6.3.1]
+/**
+ * ccid3_first_li - Implements [RFC 5348, 6.3.1]
*
* Determine the length of the first loss interval via inverse lookup.
* Assume that X_recv can be computed by the throughput equation
--- a/net/dccp/ccids/ccid3.h
+++ b/net/dccp/ccids/ccid3.h
@@ -1,6 +1,4 @@
/*
- * net/dccp/ccids/ccid3.h
- *
* Copyright (c) 2005-7 The University of Waikato, Hamilton, New Zealand.
* Copyright (c) 2007 The University of Aberdeen, Scotland, UK
*
@@ -75,8 +73,8 @@ enum ccid3_hc_tx_states {
TFRC_SSTATE_TERM,
};
-/** struct ccid3_hc_tx_sock - CCID3 sender half-connection socket
- *
+/**
+ * struct ccid3_hc_tx_sock - CCID3 sender half-connection socket
* @ccid3hctx_x - Current sending rate in 64 * bytes per second
* @ccid3hctx_x_recv - Receive rate in 64 * bytes per second
* @ccid3hctx_x_calc - Calculated rate in bytes per second
@@ -119,9 +117,9 @@ struct ccid3_hc_tx_sock {
static inline struct ccid3_hc_tx_sock *ccid3_hc_tx_sk(const struct sock *sk)
{
- struct ccid3_hc_tx_sock *hctx = ccid_priv(dccp_sk(sk)->dccps_hc_tx_ccid);
- BUG_ON(hctx == NULL);
- return hctx;
+ struct ccid3_hc_tx_sock *hctx = ccid_priv(dccp_sk(sk)->dccps_hc_tx_ccid);
+ BUG_ON(hctx == NULL);
+ return hctx;
}
/* TFRC receiver states */
@@ -131,22 +129,22 @@ enum ccid3_hc_rx_states {
TFRC_RSTATE_TERM = 127,
};
-/** struct ccid3_hc_rx_sock - CCID3 receiver half-connection socket
- *
- * @ccid3hcrx_x_recv - Receiver estimate of send rate (RFC 3448 4.3)
- * @ccid3hcrx_rtt - Receiver estimate of rtt (non-standard)
- * @ccid3hcrx_p - Current loss event rate (RFC 3448 5.4)
- * @ccid3hcrx_last_counter - Tracks window counter (RFC 4342, 8.1)
- * @ccid3hcrx_state - Receiver state, one of %ccid3_hc_rx_states
- * @ccid3hcrx_bytes_recv - Total sum of DCCP payload bytes
- * @ccid3hcrx_x_recv - Receiver estimate of send rate (RFC 3448, sec. 4.3)
- * @ccid3hcrx_rtt - Receiver estimate of RTT
- * @ccid3hcrx_tstamp_last_feedback - Time at which last feedback was sent
- * @ccid3hcrx_tstamp_last_ack - Time at which last feedback was sent
- * @ccid3hcrx_hist - Packet history (loss detection + RTT sampling)
- * @ccid3hcrx_li_hist - Loss Interval database
- * @ccid3hcrx_s - Received packet size in bytes
- * @ccid3hcrx_pinv - Inverse of Loss Event Rate (RFC 4342, sec. 8.5)
+/**
+ * struct ccid3_hc_rx_sock - CCID3 receiver half-connection socket
+ * @ccid3hcrx_x_recv - Receiver estimate of send rate (RFC 3448 4.3)
+ * @ccid3hcrx_rtt - Receiver estimate of rtt (non-standard)
+ * @ccid3hcrx_p - Current loss event rate (RFC 3448 5.4)
+ * @ccid3hcrx_last_counter - Tracks window counter (RFC 4342, 8.1)
+ * @ccid3hcrx_state - Receiver state, one of %ccid3_hc_rx_states
+ * @ccid3hcrx_bytes_recv - Total sum of DCCP payload bytes
+ * @ccid3hcrx_x_recv - Receiver estimate of send rate (RFC 3448, sec. 4.3)
+ * @ccid3hcrx_rtt - Receiver estimate of RTT
+ * @ccid3hcrx_tstamp_last_feedback - Time at which last feedback was sent
+ * @ccid3hcrx_tstamp_last_ack - Time at which last feedback was sent
+ * @ccid3hcrx_hist - Packet history (loss detection + RTT sampling)
+ * @ccid3hcrx_li_hist - Loss Interval database
+ * @ccid3hcrx_s - Received packet size in bytes
+ * @ccid3hcrx_pinv - Inverse of Loss Event Rate (RFC 4342, sec. 8.5)
*/
struct ccid3_hc_rx_sock {
u8 ccid3hcrx_last_counter:4;
@@ -163,9 +161,9 @@ struct ccid3_hc_rx_sock {
static inline struct ccid3_hc_rx_sock *ccid3_hc_rx_sk(const struct sock *sk)
{
- struct ccid3_hc_rx_sock *hcrx = ccid_priv(dccp_sk(sk)->dccps_hc_rx_ccid);
- BUG_ON(hcrx == NULL);
- return hcrx;
+ struct ccid3_hc_rx_sock *hcrx = ccid_priv(dccp_sk(sk)->dccps_hc_rx_ccid);
+ BUG_ON(hcrx == NULL);
+ return hcrx;
}
#endif /* _DCCP_CCID3_H_ */
--- a/net/dccp/ccids/lib/packet_history.h
+++ b/net/dccp/ccids/lib/packet_history.h
@@ -70,7 +70,6 @@ struct tfrc_rx_hist_entry {
/**
* tfrc_rx_hist - RX history structure for TFRC-based protocols
- *
* @ring: Packet history for RTT sampling and loss detection
* @loss_count: Number of entries in circular history
* @loss_start: Movable index (for loss detection)
--
^ permalink raw reply
* Re: mac80211: NOHZ: local_softirq_pending 08
From: Michael Buesch @ 2009-09-12 16:51 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: Kalle Valo, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Johannes Berg, John W. Linville
In-Reply-To: <4AABCF28.6090505-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
On Saturday 12 September 2009 18:41:12 Oliver Hartkopp wrote:
> Michael Buesch wrote:
>
> >> As there are several users in the kernel do exact this test and call the
> >> appropriate netif_rx() function, i would suggest to create a static inline
> >> function:
> >>
> >> static inline int netif_rx_ti(struct sk_buff *skb)
> >> {
> >> if (in_interrupt())
> >> return netif_rx(skb);
> >> return netif_rx_ni(skb);
> >> }
> >>
> >> ('ti' for test in_interrupt())
> >>
> >> in include/linux/netdevice.h
> >>
> >> What do you think about that?
> >
> > Yeah, I'm fine with that.
> >
>
> Hi Michael,
>
> i cooked a patch that introduces netif_rx_ti() and fixes up the problems in
> mac80211 and the CAN subsystem.
>
> Currently i'm pondering whether netif_rx_ti() is needed in all cases or if
> there are code sections that'll never be executed from irq-context.
>
> In theses cases netif_rx_ni() should be prefered to netif_rx_ti() to prevent
> the obsolete check ...
>
> Is there any of your changes that should better use netif_rx_ni() ?
>
> Regards,
> Oliver
>
Well, I'd say this check does not cost much at all.
If I were the net maintainer, I'd get rid of netif_rx_ni() _and_ netif_rx_ti() and
do the check internally in netif_rx().
But as I don't have to decide that, I just want the mac80211 issue fixed.
--
Greetings, Michael.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] ppp: ppp_generic.c initialize flen before it get used
From: Jaswinder Singh Rajput @ 2009-09-12 16:41 UTC (permalink / raw)
To: David Miller, Gabriele Paoloni, Paul Mackerras, linux-ppp, netdev
When while loop runs first time flen is used uninitialized for nfree <= 0
This also fixed compilation warning :
CC [M] drivers/net/ppp_generic.o
drivers/net/ppp_generic.c: In function ‘ppp_mp_explode’:
drivers/net/ppp_generic.c:1314: warning: ‘flen’ may be used uninitialized in this function
Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
---
drivers/net/ppp_generic.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ppp_generic.c b/drivers/net/ppp_generic.c
index cd37d73..b1a1a06 100644
--- a/drivers/net/ppp_generic.c
+++ b/drivers/net/ppp_generic.c
@@ -1311,7 +1311,7 @@ static int ppp_mp_explode(struct ppp *ppp, struct sk_buff *skb)
{
int len, totlen;
int i, bits, hdrlen, mtu;
- int flen;
+ int flen = 0;
int navail, nfree, nzero;
int nbigger;
int totspeed;
--
1.6.4.2
^ permalink raw reply related
* Re: mac80211: NOHZ: local_softirq_pending 08
From: Oliver Hartkopp @ 2009-09-12 16:41 UTC (permalink / raw)
To: Michael Buesch
Cc: Kalle Valo, linux-wireless, netdev, Johannes Berg,
John W. Linville
In-Reply-To: <200909111813.35810.mb@bu3sch.de>
[-- Attachment #1: Type: text/plain, Size: 932 bytes --]
Michael Buesch wrote:
>> As there are several users in the kernel do exact this test and call the
>> appropriate netif_rx() function, i would suggest to create a static inline
>> function:
>>
>> static inline int netif_rx_ti(struct sk_buff *skb)
>> {
>> if (in_interrupt())
>> return netif_rx(skb);
>> return netif_rx_ni(skb);
>> }
>>
>> ('ti' for test in_interrupt())
>>
>> in include/linux/netdevice.h
>>
>> What do you think about that?
>
> Yeah, I'm fine with that.
>
Hi Michael,
i cooked a patch that introduces netif_rx_ti() and fixes up the problems in
mac80211 and the CAN subsystem.
Currently i'm pondering whether netif_rx_ti() is needed in all cases or if
there are code sections that'll never be executed from irq-context.
In theses cases netif_rx_ni() should be prefered to netif_rx_ti() to prevent
the obsolete check ...
Is there any of your changes that should better use netif_rx_ni() ?
Regards,
Oliver
[-- Attachment #2: net-NOHZ-local_softirq_pending-08.patch --]
[-- Type: text/x-patch, Size: 3612 bytes --]
diff --git a/drivers/net/can/vcan.c b/drivers/net/can/vcan.c
index 6971f6c..899f3d3 100644
--- a/drivers/net/can/vcan.c
+++ b/drivers/net/can/vcan.c
@@ -80,7 +80,7 @@ static void vcan_rx(struct sk_buff *skb, struct net_device *dev)
skb->dev = dev;
skb->ip_summed = CHECKSUM_UNNECESSARY;
- netif_rx(skb);
+ netif_rx_ti(skb);
}
static netdev_tx_t vcan_tx(struct sk_buff *skb, struct net_device *dev)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index a44118b..b34c05d 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1503,6 +1503,18 @@ extern int netdev_budget;
extern void netdev_run_todo(void);
/**
+ * netif_rx_ti - test for irq context and post buffer to the network code
+ * @skb: buffer to post
+ *
+ */
+static inline int netif_rx_ti(struct sk_buff *skb)
+{
+ if (in_interrupt())
+ return netif_rx(skb);
+ return netif_rx_ni(skb);
+}
+
+/**
* dev_put - release reference to device
* @dev: network device
*
diff --git a/net/can/af_can.c b/net/can/af_can.c
index ef1c43a..c21e7f4 100644
--- a/net/can/af_can.c
+++ b/net/can/af_can.c
@@ -278,7 +278,7 @@ int can_send(struct sk_buff *skb, int loop)
}
if (newskb)
- netif_rx(newskb);
+ netif_rx_ti(newskb);
/* update statistics */
can_stats.tx_frames++;
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 5608f6c..bbcb4cb 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -606,7 +606,7 @@ static void ieee80211_send_layer2_update(struct sta_info *sta)
skb->dev = sta->sdata->dev;
skb->protocol = eth_type_trans(skb, sta->sdata->dev);
memset(skb->cb, 0, sizeof(skb->cb));
- netif_rx(skb);
+ netif_rx_ti(skb);
}
static void sta_apply_parameters(struct ieee80211_local *local,
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 797f539..1109f99 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -591,7 +591,7 @@ void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb)
skb2 = skb_clone(skb, GFP_ATOMIC);
if (skb2) {
skb2->dev = prev_dev;
- netif_rx(skb2);
+ netif_rx_ti(skb2);
}
}
@@ -600,7 +600,7 @@ void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb)
}
if (prev_dev) {
skb->dev = prev_dev;
- netif_rx(skb);
+ netif_rx_ti(skb);
skb = NULL;
}
rcu_read_unlock();
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index c01588f..5bb7c04 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -309,7 +309,7 @@ ieee80211_rx_monitor(struct ieee80211_local *local, struct sk_buff *origskb,
skb2 = skb_clone(skb, GFP_ATOMIC);
if (skb2) {
skb2->dev = prev_dev;
- netif_rx(skb2);
+ netif_rx_ti(skb2);
}
}
@@ -320,7 +320,7 @@ ieee80211_rx_monitor(struct ieee80211_local *local, struct sk_buff *origskb,
if (prev_dev) {
skb->dev = prev_dev;
- netif_rx(skb);
+ netif_rx_ti(skb);
} else
dev_kfree_skb(skb);
@@ -1349,7 +1349,7 @@ ieee80211_deliver_skb(struct ieee80211_rx_data *rx)
/* deliver to local stack */
skb->protocol = eth_type_trans(skb, dev);
memset(skb->cb, 0, sizeof(skb->cb));
- netif_rx(skb);
+ netif_rx_ti(skb);
}
}
@@ -1943,7 +1943,7 @@ static void ieee80211_rx_cooked_monitor(struct ieee80211_rx_data *rx)
skb2 = skb_clone(skb, GFP_ATOMIC);
if (skb2) {
skb2->dev = prev_dev;
- netif_rx(skb2);
+ netif_rx_ti(skb2);
}
}
@@ -1954,7 +1954,7 @@ static void ieee80211_rx_cooked_monitor(struct ieee80211_rx_data *rx)
if (prev_dev) {
skb->dev = prev_dev;
- netif_rx(skb);
+ netif_rx_ti(skb);
skb = NULL;
} else
goto out_free_skb;
^ permalink raw reply related
* Re: [iproute2] tc action mirred question
From: Xiaofei Wu @ 2009-09-12 16:01 UTC (permalink / raw)
To: hadi; +Cc: linux netdev
In-Reply-To: <1252704524.25158.42.camel@dogo.mojatatu.com>
> I think you are doing something wrong. Are there really packets
>being generated with that source address.
I made a mistake. I changed it to 'match ip src 192.168.1.0/24' . Now it works.
I can mirror the packets (A -> B) to D. Node D forwards them to C.
Sometimes the same packets through the path A-B-C, A-D-C are not lost. Node C will receive the
same packets twice. How to handle the duplicate packet on node C ?
Maybe the duplicate packets have side effects to TCP.
regards,
wu
^ permalink raw reply
* [PATCH v2] genetlink: fix netns vs. netlink table locking
From: Johannes Berg @ 2009-09-12 13:03 UTC (permalink / raw)
To: netdev; +Cc: linux-wireless
In-Reply-To: <1252425578.3806.22.camel@johannes.local>
Since my commits introducing netns awareness into
genetlink we can get this problem:
BUG: scheduling while atomic: modprobe/1178/0x00000002
2 locks held by modprobe/1178:
#0: (genl_mutex){+.+.+.}, at: [<ffffffff8135ee1a>] genl_register_mc_grou
#1: (rcu_read_lock){.+.+..}, at: [<ffffffff8135eeb5>] genl_register_mc_g
Pid: 1178, comm: modprobe Not tainted 2.6.31-rc8-wl-34789-g95cb731-dirty #
Call Trace:
[<ffffffff8103e285>] __schedule_bug+0x85/0x90
[<ffffffff81403138>] schedule+0x108/0x588
[<ffffffff8135b131>] netlink_table_grab+0xa1/0xf0
[<ffffffff8135c3a7>] netlink_change_ngroups+0x47/0x100
[<ffffffff8135ef0f>] genl_register_mc_group+0x12f/0x290
because I overlooked that netlink_table_grab() will
schedule, thinking it was just the rwlock. However,
in the contention case, that isn't actually true.
Fix this by letting the code grab the netlink table
lock first and then the RCU for netns protection.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
v2: rebase over removal of netlink_change_ngroups EXPORT_SYMBOL
include/linux/netlink.h | 4 +++
net/netlink/af_netlink.c | 51 ++++++++++++++++++++++++++---------------------
net/netlink/genetlink.c | 5 +++-
3 files changed, 37 insertions(+), 23 deletions(-)
--- wireless-testing.orig/include/linux/netlink.h 2009-09-12 06:58:44.000000000 -0600
+++ wireless-testing/include/linux/netlink.h 2009-09-12 06:58:53.000000000 -0600
@@ -176,12 +176,16 @@ struct netlink_skb_parms
#define NETLINK_CREDS(skb) (&NETLINK_CB((skb)).creds)
+extern void netlink_table_grab(void);
+extern void netlink_table_ungrab(void);
+
extern struct sock *netlink_kernel_create(struct net *net,
int unit,unsigned int groups,
void (*input)(struct sk_buff *skb),
struct mutex *cb_mutex,
struct module *module);
extern void netlink_kernel_release(struct sock *sk);
+extern int __netlink_change_ngroups(struct sock *sk, unsigned int groups);
extern int netlink_change_ngroups(struct sock *sk, unsigned int groups);
extern void netlink_clear_multicast_users(struct sock *sk, unsigned int group);
extern void netlink_ack(struct sk_buff *in_skb, struct nlmsghdr *nlh, int err);
--- wireless-testing.orig/net/netlink/af_netlink.c 2009-09-12 06:58:46.000000000 -0600
+++ wireless-testing/net/netlink/af_netlink.c 2009-09-12 06:58:53.000000000 -0600
@@ -177,9 +177,11 @@ static void netlink_sock_destruct(struct
* this, _but_ remember, it adds useless work on UP machines.
*/
-static void netlink_table_grab(void)
+void netlink_table_grab(void)
__acquires(nl_table_lock)
{
+ might_sleep();
+
write_lock_irq(&nl_table_lock);
if (atomic_read(&nl_table_users)) {
@@ -200,7 +202,7 @@ static void netlink_table_grab(void)
}
}
-static void netlink_table_ungrab(void)
+void netlink_table_ungrab(void)
__releases(nl_table_lock)
{
write_unlock_irq(&nl_table_lock);
@@ -1549,37 +1551,21 @@ static void netlink_free_old_listeners(s
kfree(lrh->ptr);
}
-/**
- * netlink_change_ngroups - change number of multicast groups
- *
- * This changes the number of multicast groups that are available
- * on a certain netlink family. Note that it is not possible to
- * change the number of groups to below 32. Also note that it does
- * not implicitly call netlink_clear_multicast_users() when the
- * number of groups is reduced.
- *
- * @sk: The kernel netlink socket, as returned by netlink_kernel_create().
- * @groups: The new number of groups.
- */
-int netlink_change_ngroups(struct sock *sk, unsigned int groups)
+int __netlink_change_ngroups(struct sock *sk, unsigned int groups)
{
unsigned long *listeners, *old = NULL;
struct listeners_rcu_head *old_rcu_head;
struct netlink_table *tbl = &nl_table[sk->sk_protocol];
- int err = 0;
if (groups < 32)
groups = 32;
- netlink_table_grab();
if (NLGRPSZ(tbl->groups) < NLGRPSZ(groups)) {
listeners = kzalloc(NLGRPSZ(groups) +
sizeof(struct listeners_rcu_head),
GFP_ATOMIC);
- if (!listeners) {
- err = -ENOMEM;
- goto out_ungrab;
- }
+ if (!listeners)
+ return -ENOMEM;
old = tbl->listeners;
memcpy(listeners, old, NLGRPSZ(tbl->groups));
rcu_assign_pointer(tbl->listeners, listeners);
@@ -1597,8 +1583,29 @@ int netlink_change_ngroups(struct sock *
}
tbl->groups = groups;
- out_ungrab:
+ return 0;
+}
+
+/**
+ * netlink_change_ngroups - change number of multicast groups
+ *
+ * This changes the number of multicast groups that are available
+ * on a certain netlink family. Note that it is not possible to
+ * change the number of groups to below 32. Also note that it does
+ * not implicitly call netlink_clear_multicast_users() when the
+ * number of groups is reduced.
+ *
+ * @sk: The kernel netlink socket, as returned by netlink_kernel_create().
+ * @groups: The new number of groups.
+ */
+int netlink_change_ngroups(struct sock *sk, unsigned int groups)
+{
+ int err;
+
+ netlink_table_grab();
+ err = __netlink_change_ngroups(sk, groups);
netlink_table_ungrab();
+
return err;
}
--- wireless-testing.orig/net/netlink/genetlink.c 2009-09-12 06:58:46.000000000 -0600
+++ wireless-testing/net/netlink/genetlink.c 2009-09-12 06:58:53.000000000 -0600
@@ -176,9 +176,10 @@ int genl_register_mc_group(struct genl_f
if (family->netnsok) {
struct net *net;
+ netlink_table_grab();
rcu_read_lock();
for_each_net_rcu(net) {
- err = netlink_change_ngroups(net->genl_sock,
+ err = __netlink_change_ngroups(net->genl_sock,
mc_groups_longs * BITS_PER_LONG);
if (err) {
/*
@@ -188,10 +189,12 @@ int genl_register_mc_group(struct genl_f
* increased on some sockets which is ok.
*/
rcu_read_unlock();
+ netlink_table_ungrab();
goto out;
}
}
rcu_read_unlock();
+ netlink_table_ungrab();
} else {
err = netlink_change_ngroups(init_net.genl_sock,
mc_groups_longs * BITS_PER_LONG);
^ permalink raw reply
* Re: [PATCH 1/8] networking/fanotify: declare fanotify socket numbers
From: Evgeniy Polyakov @ 2009-09-12 9:47 UTC (permalink / raw)
To: Jamie Lokier
Cc: jamal, Eric Paris, David Miller, linux-kernel, linux-fsdevel,
netdev, viro, alan, hch, balbir
In-Reply-To: <20090911214254.GB19901@shareable.org>
On Fri, Sep 11, 2009 at 10:42:54PM +0100, Jamie Lokier (jamie@shareable.org) wrote:
> While skbs and netlink aren't that slow, I suspect they're an order of
> magnitude or two slower than, say, epoll or inotify at passing events
> around.
Skbs are those tiny bits which allow 100 Gbit/s forwarding between multiple
interfaces. But of course it can not be as fast as plain memory copy :)
Having one skb allocation per IO syscall will be challenging but after
all we have this for send/recv calls and achieve high performance
numbers. Idea with merging events in the same skb will be also very non-trivial.
--
Evgeniy Polyakov
^ permalink raw reply
* Re: [PATCH 1/8] networking/fanotify: declare fanotify socket numbers
From: Evgeniy Polyakov @ 2009-09-12 9:41 UTC (permalink / raw)
To: Eric Paris
Cc: Jamie Lokier, David Miller, linux-kernel, linux-fsdevel, netdev,
viro, alan, hch
In-Reply-To: <1252705902.2305.83.camel@dhcp231-106.rdu.redhat.com>
On Fri, Sep 11, 2009 at 05:51:42PM -0400, Eric Paris (eparis@redhat.com) wrote:
> For some things yes, some things no. I'd have to understand where loss
> can happen to know if it's feasible. If I know loss happens in the
> sender context that's great. If it's somewhere in the middle and the
> sender doesn't immediately know it'll never be delivered, yes, I don't
> think it can solve all my needs. How many places can and skb get lost
> between the sender and the receiver?
When queue is full or you do not have enough RAM. Both are reported at
'sending' time.
As of your description of netlink/socket usage - you will have to peek
skb queue, which is rather error-prone operation. Also you will have to
implement own skb destructor to mess with private reference counters and
netlink bits.
--
Evgeniy Polyakov
^ permalink raw reply
* Re: [PATCH 2/2] cdc-phonet: autoconfigure Phonet address
From: Rémi Denis-Courmont @ 2009-09-12 9:20 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20090911.123835.218761422.davem@davemloft.net>
Le vendredi 11 septembre 2009 22:38:35 David Miller, vous avez écrit :
> From: Rémi Denis-Courmont <remi@remlab.net>
> Date: Wed, 9 Sep 2009 13:00:06 +0300
>
> > From: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
> >
> > Signed-off-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
>
> Applied.
THanks and oops, I just had an updated patch set coming. I guess I will rebase
it then.
--
Rémi Denis-Courmont
http://www.remlab.net/
^ permalink raw reply
* [PATCH 08/13] TProxy: added tproxy sockopt interface in the IPV6 layer
From: Balazs Scheidler @ 2009-09-12 8:53 UTC (permalink / raw)
To: netfilter-devel, netdev
Support for IPV6_RECVORIGDSTADDR sockopt for UDP sockets were contributed by
Harry Mason.
Signed-off-by: Balazs Scheidler <bazsi@balabit.hu>
---
include/linux/in6.h | 5 +++++
include/linux/ipv6.h | 4 +++-
net/ipv6/datagram.c | 19 +++++++++++++++++++
net/ipv6/ipv6_sockglue.c | 22 ++++++++++++++++++++++
4 files changed, 49 insertions(+), 1 deletions(-)
diff --git a/include/linux/in6.h b/include/linux/in6.h
index 718bf21..1bfaac8 100644
--- a/include/linux/in6.h
+++ b/include/linux/in6.h
@@ -268,6 +268,11 @@ struct in6_flowlabel_req
#define IPV6_PREFER_SRC_CGA 0x0008
#define IPV6_PREFER_SRC_NONCGA 0x0800
+#define IPV6_ORIGDSTADDR 73
+#define IPV6_RECVORIGDSTADDR IPV6_ORIGDSTADDR
+#define IPV6_TRANSPARENT 74
+
+
/*
* Multicast Routing:
* see include/linux/mroute6.h.
diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
index be4c9c6..6d71614 100644
--- a/include/linux/ipv6.h
+++ b/include/linux/ipv6.h
@@ -333,7 +333,9 @@ struct ipv6_pinfo {
dstopts:1,
odstopts:1,
rxflow:1,
- rxtclass:1;
+ rxtclass:1,
+ rxorigdstaddr:1;
+ /* 3 bits hole */
} bits;
__u16 all;
} rxopt;
diff --git a/net/ipv6/datagram.c b/net/ipv6/datagram.c
index e2bdc6d..fec931a 100644
--- a/net/ipv6/datagram.c
+++ b/net/ipv6/datagram.c
@@ -492,6 +492,25 @@ int datagram_recv_ctl(struct sock *sk, struct msghdr *msg, struct sk_buff *skb)
u8 *ptr = nh + opt->dst1;
put_cmsg(msg, SOL_IPV6, IPV6_2292DSTOPTS, (ptr[1]+1)<<3, ptr);
}
+ if (np->rxopt.bits.rxorigdstaddr) {
+ struct sockaddr_in6 sin6;
+ u16 *ports = (u16 *) skb_transport_header(skb);
+
+ if (skb_transport_offset(skb) + 4 <= skb->len) {
+ /* All current transport protocols have the port numbers in the
+ * first four bytes of the transport header and this function is
+ * written with this assumption in mind.
+ */
+
+ sin6.sin6_family = AF_INET6;
+ ipv6_addr_copy(&sin6.sin6_addr, &ipv6_hdr(skb)->daddr);
+ sin6.sin6_port = ports[1];
+ sin6.sin6_flowinfo = 0;
+ sin6.sin6_scope_id = 0;
+
+ put_cmsg(msg, SOL_IPV6, IPV6_ORIGDSTADDR, sizeof(sin6), &sin6);
+ }
+ }
return 0;
}
diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
index a7fdf9a..0f70cd1 100644
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -333,6 +333,20 @@ static int do_ipv6_setsockopt(struct sock *sk, int level, int optname,
retv = 0;
break;
+ case IPV6_TRANSPARENT:
+ if (optlen < sizeof(int))
+ goto e_inval;
+ /* we don't have a separate transparent bit for IPV6 we use the one in the IPv4 socket */
+ inet_sk(sk)->transparent = valbool;
+ break;
+
+ case IPV6_RECVORIGDSTADDR:
+ if (optlen < sizeof(int))
+ goto e_inval;
+ np->rxopt.bits.rxorigdstaddr = valbool;
+ retv = 0;
+ break;
+
case IPV6_HOPOPTS:
case IPV6_RTHDRDSTOPTS:
case IPV6_RTHDR:
@@ -1049,6 +1063,14 @@ static int do_ipv6_getsockopt(struct sock *sk, int level, int optname,
val = np->rxopt.bits.rxflow;
break;
+ case IPV6_TRANSPARENT:
+ val = inet_sk(sk)->transparent;
+ break;
+
+ case IPV6_RECVORIGDSTADDR:
+ val = np->rxopt.bits.rxorigdstaddr;
+ break;
+
case IPV6_UNICAST_HOPS:
case IPV6_MULTICAST_HOPS:
{
--
1.6.0.4
^ 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