* [PATCH] decnet: netdevice refcount leak
From: Eric Dumazet @ 2009-11-06 8:43 UTC (permalink / raw)
To: David S. Miller; +Cc: Linux Netdev List
David, if you accept the following patch for net-2.6, it would help me
if you also can pull it in net-next-2.6
Thanks
[PATCH] decnet: netdevice refcount leak
While working on device refcount stuff, I found a device refcount leak
through DECNET.
This nasty bug can be used to hold refcounts on any !DECNET netdevice.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/decnet/sysctl_net_decnet.c | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/net/decnet/sysctl_net_decnet.c b/net/decnet/sysctl_net_decnet.c
index 26b0ab1..2036568 100644
--- a/net/decnet/sysctl_net_decnet.c
+++ b/net/decnet/sysctl_net_decnet.c
@@ -263,11 +263,10 @@ static int dn_def_dev_strategy(ctl_table *table,
return -ENODEV;
rv = -ENODEV;
- if (dev->dn_ptr != NULL) {
+ if (dev->dn_ptr != NULL)
rv = dn_dev_set_default(dev, 1);
- if (rv)
- dev_put(dev);
- }
+ if (rv)
+ dev_put(dev);
}
return rv;
^ permalink raw reply related
* Re: netfilter 01/02: nf_nat: fix NAT issue in 2.6.30.4+
From: David Miller @ 2009-11-06 8:43 UTC (permalink / raw)
To: kaber; +Cc: netfilter-devel, netdev
In-Reply-To: <4AF31832.1070701@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Thu, 05 Nov 2009 19:23:46 +0100
> netfilter: nf_nat: fix NAT issue in 2.6.30.4+
...
> Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
> Signed-off-by: Patrick McHardy <kaber@trash.net>
Applied to net-2.6
^ permalink raw reply
* Re: [PATCH 1/2] udp: cleanup __udp4_lib_mcast_deliver
From: David Miller @ 2009-11-06 8:42 UTC (permalink / raw)
To: lgrijincu; +Cc: netdev, opurdila
In-Reply-To: <200911052033.21964.lgrijincu@ixiacom.com>
From: Lucian Adrian Grijincu <lgrijincu@ixiacom.com>
Date: Thu, 5 Nov 2009 20:33:21 +0200
>
> __udp4_lib_mcast_deliver always returned 0.
> It's caller can return 0 explicitly to make things clearer.
>
> Also, we don't need the spin_lock() on the hslot to free the skb.
>
> Signed-off-by: Lucian Adrian Grijincu <lgrijincu@ixiacom.com>
I think the current code is much easier to understand than
your version.
Getting rid of the useless return value is fine, but the
new do{}while() loop et al. is less readable to me.
I'm not applying these two patches, sorry.
^ permalink raw reply
* Re: [PATCH net-next]atl1c:change atl1c_buffer struct and restructure clean atl1c_buffer procedure
From: David Miller @ 2009-11-06 8:32 UTC (permalink / raw)
To: jie.yang; +Cc: netdev, linux-kernel
In-Reply-To: <12574319533672-git-send-email-jie.yang@atheros.com>
From: <jie.yang@atheros.com>
Date: Thu, 5 Nov 2009 22:39:13 +0800
> change atl1c_buffer struct, use "u16 flags" instead of "u16 state"
> to store more infomation for atl1c_buffer, and restructure clean
> atl1c_buffer procedure, add common api atl1c_clean_buffer.
>
> Signed-off-by: Jie Yang <jie.yang@atheros.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] be2net: Fix CQE_STATUS_EXTD_SHIFT define
From: David Miller @ 2009-11-06 8:31 UTC (permalink / raw)
To: sathyap; +Cc: netdev
In-Reply-To: <20091106071746.GA27296@serverengines.com>
From: Sathya Perla <sathyap@serverengines.com>
Date: Fri, 6 Nov 2009 12:47:46 +0530
>
> Signed-off-by: Sathya Perla <sathyap@serverengines.com>
Applied to net-2.6, thanks.
^ permalink raw reply
* Re: [atl1-devel] [Bugme-new] [Bug 14431] New: atl1 eth0 link continuously down up
From: Luca Tettamanti @ 2009-11-06 8:26 UTC (permalink / raw)
To: johan vdp; +Cc: jcliburn, atl1-devel, netdev
In-Reply-To: <SNT116-W4337ADB53BF93D60518EFD90AF0@phx.gbl>
On Fri, Nov 6, 2009 at 1:02 AM, johan vdp <johan_vdp@hotmail.com> wrote:
> As a workaround I have added an Intel e1000 PCI card.
> And it is showing the same messages in the logs...
> To me this shows that the atl1 driver can be excluded as the cause. No need
> to reply again to the atl1 mailing list.
>
> I am tempted to buy a new 1Gbps switch. But I can not believe that my old
> dusty hub is broken in the same way that my switch is.
I've seen this behaviour with a broken cable...
L
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: sock_bindtodevice() RCU-ification
From: David Miller @ 2009-11-06 8:17 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4AF3CB8B.2090206@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 06 Nov 2009 08:08:59 +0100
> Thanks David, which gcc version are you using ?
I'm using "gcc-4.2.4 (Ubuntu 4.2.4-1ubuntu3)" on sparc.
^ permalink raw reply
* Re: [announce] new rt2800 drivers for Ralink wireless & project tree
From: Pavel Machek @ 2009-11-06 7:46 UTC (permalink / raw)
To: Ivo van Doorn
Cc: Ingo Molnar, Bartlomiej Zolnierkiewicz,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Randy Dunlap, Luis Correia,
John W. Linville, Johannes Berg, Jarek Poplawski, Pekka Enberg,
David Miller
In-Reply-To: <200911042251.23506.IvDoorn-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Look at the diffstat of Bart's driver:
> >
> > 15 files changed, 4036 insertions(+), 7158 deletions(-)
> >
> > He reduced your 5.2 KLOC non-working driver into a 1.8 KLOC _working_
> > driver.
>
> Bullshit, read the mails again.
This was uncalled for, right?
...
> Some people actually require sleep during the night, perhaps that you don't need
> that and can hence review 41 patches which changes thousands of lines on the
> same day the patches were submitted.
If you lack time, "Really start reading my mails" sentence you used at
the start of email is *not* user-friendly way to say that.
> > And _still_ your complaint about Bart's series is that he updated the
> > MAINTAINERS entry and added an entry for rt2800? Heck _sure_ he should
> > update it, he is the one doing the hard work of trying to bring it to
> > users, trying to clean up a messy driver space, trying to turn crap into
> > gold.
>
> So if I want to focus on something different in the kernel, I just send 1 patch,
> and a second to claim the maintainership of it even though there is an active
> maintainer available?
What about listing yourself as a maintainer for a start?
> > The thing is, if you dont have the time or interest to listen to and act
> > upon review feedback, be constructive about it and fix (obvious)
> > structural problems in your rt2800 code, you should just step aside and
> > let Bart maintain what he is apparently more capable of maintaining than
> > you are.
> >
> > What you are doing here is a thinly veiled land-grab: you did a minimal
> > token driver for rt2800 that doesnt work, kept it in your private tree
> > for _1.5 years_, and the moment someone _else_ came along and did
> > something better and more functional in drivers/staging/, you discovered
> > your sudden interest for it and moved the crappy driver upstream at
> > lightning's speed (it is already in net-next AFAICS, despite negative
> > test and review feedback) - ignoring and throwing away all the work that
> > Bart has done.
>
> Get your facts straight, the bullshit level in your mail is staggering.
>
> You have no fucking clue who wrote the rt2800 driver which is in
> drivers/staging/,
Perhaps you should not be a maintainer if you can't behave yourself?
> Because a lot of people prefer looking from the sideline,
> contributing _nothing_
Given your behaviour, I'm not suprised people are not too eager to
work with you.
> As for "throwing away that work" I ACKED 10 of his patches, and said I would review
> the rest later! But like I said, apparently it is a bad habit for people to sleep during
> the night.
Read your email again. It was quite far from 'acked 10, asked for
time'. You flamed him first.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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] be2net: Fix CQE_STATUS_EXTD_SHIFT define
From: Sathya Perla @ 2009-11-06 7:17 UTC (permalink / raw)
To: netdev
Signed-off-by: Sathya Perla <sathyap@serverengines.com>
---
drivers/net/benet/be_cmds.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/benet/be_cmds.h b/drivers/net/benet/be_cmds.h
index 4995378..e5f9676 100644
--- a/drivers/net/benet/be_cmds.h
+++ b/drivers/net/benet/be_cmds.h
@@ -68,7 +68,7 @@ enum {
#define CQE_STATUS_COMPL_MASK 0xFFFF
#define CQE_STATUS_COMPL_SHIFT 0 /* bits 0 - 15 */
#define CQE_STATUS_EXTD_MASK 0xFFFF
-#define CQE_STATUS_EXTD_SHIFT 0 /* bits 0 - 15 */
+#define CQE_STATUS_EXTD_SHIFT 16 /* bits 16 - 31 */
struct be_mcc_compl {
u32 status; /* dword 0 */
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH net-next-2.6] net: sock_bindtodevice() RCU-ification
From: Eric Dumazet @ 2009-11-06 7:08 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20091105.223921.83639611.davem@davemloft.net>
David Miller a écrit :
> From: David Miller <davem@davemloft.net>
> Date: Thu, 05 Nov 2009 21:08:30 -0800 (PST)
>
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Wed, 04 Nov 2009 23:36:44 +0100
>>
>>> Avoid dev_hold()/dev_put() in sock_bindtodevice()
>>>
>>> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>> Applied to net-next-2.6, thanks.
>
> Eric I had to add the following patch to cure a build
> warning after this, just FYI:
>
> net: Fix build warning in sock_bindtodevice().
>
> net/core/sock.c: In function 'sock_setsockopt':
> net/core/sock.c:396: warning: 'index' may be used uninitialized in this function
> net/core/sock.c:396: note: 'index' was declared here
>
> GCC can't see that all paths initialize index, so just
> set it to the default (0) and eliminate the specific
> code block that handles the null device name string.
>
Thanks David, which gcc version are you using ?
^ permalink raw reply
* Re: [PATCH 19/25] mlx4: Randomizing mac addresses for slaves
From: Simon Horman @ 2009-11-06 7:07 UTC (permalink / raw)
To: Roland Dreier
Cc: Liran Liss, Or Gerlitz, Yevgeny Petrilin,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Tziporet Koren
In-Reply-To: <adaeiocyykl.fsf-BjVyx320WGW9gfZ95n9DRSW4+XlvGpQz@public.gmane.org>
On Thu, Nov 05, 2009 at 10:08:58PM -0800, Roland Dreier wrote:
>
> > > igb uses the full output of random_ether_addr(). I'd be fine with
> > > that. However setting the OUI means you only get 24 bits of randomness
> > > which makes a collision a lot more likely.
> >
> > IIRC that was precisely why the OUI isn't used for the igb driver.
> >
> > Perhaps some infrastructure (by which I mean a random_mac() function)
> > is warranted so at least this discussion can be concentrated around that
> > rather than repeating it for each driver that needs random mac addresses.
>
> What would be the difference between random_mac() and the existing
> random_ether_addr() function?
Sorry, I was mistaken. igb is using random_ether_addr(),
which is what I had in mind.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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
* Re: [PATCH net-next-2.6] net: sock_bindtodevice() RCU-ification
From: David Miller @ 2009-11-06 6:39 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <20091105.210830.108657873.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Thu, 05 Nov 2009 21:08:30 -0800 (PST)
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Wed, 04 Nov 2009 23:36:44 +0100
>
>> Avoid dev_hold()/dev_put() in sock_bindtodevice()
>>
>> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> Applied to net-next-2.6, thanks.
Eric I had to add the following patch to cure a build
warning after this, just FYI:
net: Fix build warning in sock_bindtodevice().
net/core/sock.c: In function 'sock_setsockopt':
net/core/sock.c:396: warning: 'index' may be used uninitialized in this function
net/core/sock.c:396: note: 'index' was declared here
GCC can't see that all paths initialize index, so just
set it to the default (0) and eliminate the specific
code block that handles the null device name string.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/core/sock.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/core/sock.c b/net/core/sock.c
index 38820ea..76ff58d 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -417,9 +417,8 @@ static int sock_bindtodevice(struct sock *sk, char __user *optval, int optlen)
if (copy_from_user(devname, optval, optlen))
goto out;
- if (devname[0] == '\0') {
- index = 0;
- } else {
+ index = 0;
+ if (devname[0] != '\0') {
struct net_device *dev;
rcu_read_lock();
--
1.6.5.2
^ permalink raw reply related
* Re: [PATCH 19/25] mlx4: Randomizing mac addresses for slaves
From: Roland Dreier @ 2009-11-06 6:08 UTC (permalink / raw)
To: Simon Horman
Cc: Liran Liss, Or Gerlitz, Yevgeny Petrilin,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Tziporet Koren
In-Reply-To: <20091106040624.GA6629-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
> > igb uses the full output of random_ether_addr(). I'd be fine with
> > that. However setting the OUI means you only get 24 bits of randomness
> > which makes a collision a lot more likely.
>
> IIRC that was precisely why the OUI isn't used for the igb driver.
>
> Perhaps some infrastructure (by which I mean a random_mac() function)
> is warranted so at least this discussion can be concentrated around that
> rather than repeating it for each driver that needs random mac addresses.
What would be the difference between random_mac() and the existing
random_ether_addr() function?
If one chooses a random address with a given OUI, then with only 24 bits
of randomness, the birthday paradox says it takes only a few thousand
addresses to get a collision (easy to hit given even a modest-sized
virtualization setup). With the 46 bits that random_ether_addr() gives
it takes millions of addresses to be likely to get a collision, which is
probably comfortable for most ethernets.
So it seems that random_ether_addr() is exactly what we should be using
for VFs -- the only alternative I see is for the manufacturer to
allocate N extra ethernet addresses for a NIC that supports N virtual
functions, and use those assigned addresses. But if the kernel is
making up ethernet addresses then we better use all the bits we can.
- R.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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
* Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2
From: Tobias Diedrich @ 2009-11-06 6:03 UTC (permalink / raw)
To: Mel Gorman
Cc: Frans Pop, Jiri Kosina, Sven Geggus, Karol Lewandowski,
Tobias Oetiker, Rafael J. Wysocki, David Miller, Reinette Chatre,
Kalle Valo, David Rientjes, KOSAKI Motohiro, Mohamed Abbas,
Jens Axboe, John W. Linville, Pekka Enberg,
Bartlomiej Zolnierkiewicz, Greg Kroah-Hartman,
Stephan von Krawczynski, Kernel Testers List, netdev,
linux-kernel, linux-mm@kvack.org
In-Reply-To: <1256221356-26049-1-git-send-email-mel@csn.ul.ie>
Mel Gorman wrote:
> [No BZ ID] Kernel crash on 2.6.31.x (kcryptd: page allocation failure..)
> This apparently is easily reproducible, particular in comparison to
> the other reports. The point of greatest interest is that this is
> order-0 GFP_ATOMIC failures. Sven, I'm hoping that you in particular
> will be able to follow the tests below as you are the most likely
> person to have an easily reproducible situation.
I've also seen order-0 failures on 2.6.31.5:
Note that this is with a one process hogging and mlocking memory and
min_free_kbytes reduced to 100 to reproduce the problem more easily.
I tried bisecting the issue, but in the end without memory pressure
I can't reproduce it reliably and with the above mentioned pressure
I get allocation failures even on 2.6.30.o
Initially the issue was that the machine hangs after the allocation
failure, but that seems to be a netconsole related issue, since I
didn't get a hang on 2.6.31 compiled without netconsole.
http://lkml.org/lkml/2009/11/1/66
http://lkml.org/lkml/2009/11/5/100
[ 375.398423] swapper: page allocation failure. order:0, mode:0x20
[ 375.398483] Pid: 0, comm: swapper Not tainted 2.6.31.5-nokmem-tomodachi #3
[ 375.398519] Call Trace:
[ 375.398566] [<c10395a8>] ? __alloc_pages_nodemask+0x40f/0x453
[ 375.398613] [<c104e988>] ? cache_alloc_refill+0x1f3/0x382
[ 375.398648] [<c104eb76>] ? __kmalloc+0x5f/0x97
[ 375.398690] [<c1228003>] ? __alloc_skb+0x44/0x101
[ 375.398723] [<c12289b5>] ? dev_alloc_skb+0x11/0x25
[ 375.398760] [<c11a53a1>] ? tulip_refill_rx+0x3c/0x115
[ 375.398793] [<c11a57f7>] ? tulip_poll+0x37d/0x416
[ 375.398832] [<c122cf56>] ? net_rx_action+0x3a/0xdb
[ 375.398874] [<c101d8b0>] ? __do_softirq+0x5b/0xcb
[ 375.398908] [<c101d855>] ? __do_softirq+0x0/0xcb
[ 375.398937] <IRQ> [<c1003e0b>] ? do_IRQ+0x66/0x76
[ 375.398989] [<c1002d70>] ? common_interrupt+0x30/0x38
[ 375.399026] [<c100725c>] ? default_idle+0x25/0x38
[ 375.399058] [<c1001a1e>] ? cpu_idle+0x64/0x7a
[ 375.399102] [<c14105ff>] ? start_kernel+0x251/0x258
[ 375.399133] Mem-Info:
[ 375.399159] DMA per-cpu:
[ 375.399184] CPU 0: hi: 0, btch: 1 usd: 0
[ 375.399214] Normal per-cpu:
[ 375.399241] CPU 0: hi: 90, btch: 15 usd: 28
[ 375.399276] Active_anon:6709 active_file:1851 inactive_anon:6729
[ 375.399278] inactive_file:2051 unevictable:40962 dirty:998 writeback:914 unstable:0
[ 375.399281] free:232 slab:1843 mapped:1404 pagetables:613 bounce:0
[ 375.399391] DMA free:924kB min:4kB low:4kB high:4kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:15028kB present:15872kB pages_scanned:0 all_unreclaimable? yes
[ 375.399465] lowmem_reserve[]: 0 230 230
[ 375.399537] Normal free:4kB min:92kB low:112kB high:136kB active_anon:26836kB inactive_anon:26916kB active_file:7404kB inactive_file:8204kB unevictable:148820kB present:235648kB pages_scanned:32 all_unreclaimable? no
[ 375.399615] lowmem_reserve[]: 0 0 0
[ 375.399681] DMA: 1*4kB 1*8kB 1*16kB 0*32kB 0*64kB 1*128kB 1*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 924kB
[ 375.399850] Normal: 1*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 4kB
[ 375.400016] 4412 total pagecache pages
[ 375.400041] 494 pages in swap cache
[ 375.400041] Swap cache stats: add 8110, delete 7616, find 139/205
[ 375.400041] Free swap = 494212kB
[ 375.400041] Total swap = 524280kB
[ 375.400041] 63472 pages RAM
[ 375.400041] 1742 pages reserved
[ 375.400041] 14429 pages shared
[ 375.400041] 56917 pages non-shared
[ 378.306631] swapper: page allocation failure. order:0, mode:0x20
[ 378.306686] Pid: 0, comm: swapper Not tainted 2.6.31.5-nokmem-tomodachi #3
[ 378.306722] Call Trace:
[ 378.306769] [<c10395a8>] ? __alloc_pages_nodemask+0x40f/0x453
[ 378.306817] [<c104e988>] ? cache_alloc_refill+0x1f3/0x382
[ 378.306853] [<c104eb76>] ? __kmalloc+0x5f/0x97
[ 378.306894] [<c1228003>] ? __alloc_skb+0x44/0x101
[ 378.306927] [<c12289b5>] ? dev_alloc_skb+0x11/0x25
[ 378.306964] [<c11a53a1>] ? tulip_refill_rx+0x3c/0x115
[ 378.306996] [<c11a57f7>] ? tulip_poll+0x37d/0x416
[ 378.307035] [<c122cf56>] ? net_rx_action+0x3a/0xdb
[ 378.307079] [<c101d8b0>] ? __do_softirq+0x5b/0xcb
[ 378.307112] [<c101d855>] ? __do_softirq+0x0/0xcb
[ 378.307142] <IRQ> [<c1003e0b>] ? do_IRQ+0x66/0x76
[ 378.307193] [<c1002d70>] ? common_interrupt+0x30/0x38
[ 378.307232] [<c100725c>] ? default_idle+0x25/0x38
[ 378.307263] [<c1001a1e>] ? cpu_idle+0x64/0x7a
[ 378.307306] [<c14105ff>] ? start_kernel+0x251/0x258
[ 378.307338] Mem-Info:
[ 378.307364] DMA per-cpu:
[ 378.307389] CPU 0: hi: 0, btch: 1 usd: 0
[ 378.307420] Normal per-cpu:
[ 378.307446] CPU 0: hi: 90, btch: 15 usd: 70
[ 378.307480] Active_anon:6231 active_file:2340 inactive_anon:6283
[ 378.307483] inactive_file:2445 unevictable:40962 dirty:989 writeback:1024 unstable:0
[ 378.307485] free:232 slab:1872 mapped:1408 pagetables:613 bounce:0
[ 378.307595] DMA free:924kB min:4kB low:4kB high:4kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:15028kB present:15872kB pages_scanned:0 all_unreclaimable? yes
[ 378.307668] lowmem_reserve[]: 0 230 230
[ 378.307739] Normal free:4kB min:92kB low:112kB high:136kB active_anon:24924kB inactive_anon:25132kB active_file:9360kB inactive_file:9780kB unevictable:148820kB present:235648kB pages_scanned:32 all_unreclaimable? no
[ 378.307816] lowmem_reserve[]: 0 0 0
[ 378.307882] DMA: 1*4kB 1*8kB 1*16kB 0*32kB 0*64kB 1*128kB 1*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 924kB
[ 378.308052] Normal: 1*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 4kB
[ 378.308219] 5866 total pagecache pages
[ 378.308247] 1065 pages in swap cache
[ 378.308277] Swap cache stats: add 9651, delete 8586, find 152/220
[ 378.308308] Free swap = 488152kB
[ 378.308334] Total swap = 524280kB
[ 378.310030] 63472 pages RAM
[ 378.310030] 1742 pages reserved
[ 378.310030] 15289 pages shared
[ 378.310030] 56019 pages non-shared
--
Tobias PGP: http://8ef7ddba.uguu.de
--
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
* [PATCH net-next]atl1c:change atl1c_buffer struct and restructure clean atl1c_buffer procedure
From: jie.yang @ 2009-11-05 14:39 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, Jie Yang
change atl1c_buffer struct, use "u16 flags" instead of "u16 state"
to store more infomation for atl1c_buffer, and restructure clean
atl1c_buffer procedure, add common api atl1c_clean_buffer.
Signed-off-by: Jie Yang <jie.yang@atheros.com>
---
drivers/net/atl1c/atl1c.h | 22 +++++++++-
drivers/net/atl1c/atl1c_main.c | 84 ++++++++++++++++++++--------------------
2 files changed, 61 insertions(+), 45 deletions(-)
diff --git a/drivers/net/atl1c/Makefile b/drivers/net/atl1c/Makefile
diff --git a/drivers/net/atl1c/atl1c.h b/drivers/net/atl1c/atl1c.h
index 2a1120a..a348a22 100644
--- a/drivers/net/atl1c/atl1c.h
+++ b/drivers/net/atl1c/atl1c.h
@@ -470,12 +470,28 @@ struct atl1c_ring_header {
struct atl1c_buffer {
struct sk_buff *skb; /* socket buffer */
u16 length; /* rx buffer length */
- u16 state; /* state of buffer */
-#define ATL1_BUFFER_FREE 0
-#define ATL1_BUFFER_BUSY 1
+ u16 flags; /* information of buffer */
+#define ATL1C_BUFFER_FREE 0x0001
+#define ATL1C_BUFFER_BUSY 0x0002
+#define ATL1C_BUFFER_STATE_MASK 0x0003
+
+#define ATL1C_PCIMAP_SINGLE 0x0004
+#define ATL1C_PCIMAP_PAGE 0x0008
+#define ATL1C_PCIMAP_TYPE_MASK 0x000C
+
dma_addr_t dma;
};
+#define ATL1C_SET_BUFFER_STATE(buff, state) do { \
+ ((buff)->flags) &= ~ATL1C_BUFFER_STATE_MASK; \
+ ((buff)->flags) |= (state); \
+ } while (0)
+
+#define ATL1C_SET_PCIMAP_TYPE(buff, type) do { \
+ ((buff)->flags) &= ~ATL1C_PCIMAP_TYPE_MASK; \
+ ((buff)->flags) |= (type); \
+ } while (0)
+
/* transimit packet descriptor (tpd) ring */
struct atl1c_tpd_ring {
void *desc; /* descriptor ring virtual address */
diff --git a/drivers/net/atl1c/atl1c_main.c b/drivers/net/atl1c/atl1c_main.c
index 3b8801a..5ef9e23 100644
--- a/drivers/net/atl1c/atl1c_main.c
+++ b/drivers/net/atl1c/atl1c_main.c
@@ -710,6 +710,29 @@ static int __devinit atl1c_sw_init(struct atl1c_adapter *adapter)
return 0;
}
+static inline void atl1c_clean_buffer(struct pci_dev *pdev,
+ struct atl1c_buffer *buffer_info, int in_irq)
+{
+ if (buffer_info->flags & ATL1C_BUFFER_FREE)
+ return;
+ if (buffer_info->dma) {
+ if (buffer_info->flags & ATL1C_PCIMAP_SINGLE)
+ pci_unmap_single(pdev, buffer_info->dma,
+ buffer_info->length, PCI_DMA_TODEVICE);
+ else if (buffer_info->flags & ATL1C_PCIMAP_PAGE)
+ pci_unmap_page(pdev, buffer_info->dma,
+ buffer_info->length, PCI_DMA_TODEVICE);
+ }
+ if (buffer_info->skb) {
+ if (in_irq)
+ dev_kfree_skb_irq(buffer_info->skb);
+ else
+ dev_kfree_skb(buffer_info->skb);
+ }
+ buffer_info->dma = 0;
+ buffer_info->skb = NULL;
+ ATL1C_SET_BUFFER_STATE(buffer_info, ATL1C_BUFFER_FREE);
+}
/*
* atl1c_clean_tx_ring - Free Tx-skb
* @adapter: board private structure
@@ -725,22 +748,12 @@ static void atl1c_clean_tx_ring(struct atl1c_adapter *adapter,
ring_count = tpd_ring->count;
for (index = 0; index < ring_count; index++) {
buffer_info = &tpd_ring->buffer_info[index];
- if (buffer_info->state == ATL1_BUFFER_FREE)
- continue;
- if (buffer_info->dma)
- pci_unmap_single(pdev, buffer_info->dma,
- buffer_info->length,
- PCI_DMA_TODEVICE);
- if (buffer_info->skb)
- dev_kfree_skb(buffer_info->skb);
- buffer_info->dma = 0;
- buffer_info->skb = NULL;
- buffer_info->state = ATL1_BUFFER_FREE;
+ atl1c_clean_buffer(pdev, buffer_info, 0);
}
/* Zero out Tx-buffers */
memset(tpd_ring->desc, 0, sizeof(struct atl1c_tpd_desc) *
- ring_count);
+ ring_count);
atomic_set(&tpd_ring->next_to_clean, 0);
tpd_ring->next_to_use = 0;
}
@@ -760,16 +773,7 @@ static void atl1c_clean_rx_ring(struct atl1c_adapter *adapter)
for (i = 0; i < adapter->num_rx_queues; i++) {
for (j = 0; j < rfd_ring[i].count; j++) {
buffer_info = &rfd_ring[i].buffer_info[j];
- if (buffer_info->state == ATL1_BUFFER_FREE)
- continue;
- if (buffer_info->dma)
- pci_unmap_single(pdev, buffer_info->dma,
- buffer_info->length,
- PCI_DMA_FROMDEVICE);
- if (buffer_info->skb)
- dev_kfree_skb(buffer_info->skb);
- buffer_info->state = ATL1_BUFFER_FREE;
- buffer_info->skb = NULL;
+ atl1c_clean_buffer(pdev, buffer_info, 0);
}
/* zero out the descriptor ring */
memset(rfd_ring[i].desc, 0, rfd_ring[i].size);
@@ -796,7 +800,8 @@ static void atl1c_init_ring_ptrs(struct atl1c_adapter *adapter)
atomic_set(&tpd_ring[i].next_to_clean, 0);
buffer_info = tpd_ring[i].buffer_info;
for (j = 0; j < tpd_ring->count; j++)
- buffer_info[i].state = ATL1_BUFFER_FREE;
+ ATL1C_SET_BUFFER_STATE(&buffer_info[i],
+ ATL1C_BUFFER_FREE);
}
for (i = 0; i < adapter->num_rx_queues; i++) {
rfd_ring[i].next_to_use = 0;
@@ -805,7 +810,7 @@ static void atl1c_init_ring_ptrs(struct atl1c_adapter *adapter)
rrd_ring[i].next_to_clean = 0;
for (j = 0; j < rfd_ring[i].count; j++) {
buffer_info = &rfd_ring[i].buffer_info[j];
- buffer_info->state = ATL1_BUFFER_FREE;
+ ATL1C_SET_BUFFER_STATE(buffer_info, ATL1C_BUFFER_FREE);
}
}
}
@@ -1447,6 +1452,7 @@ static bool atl1c_clean_tx_irq(struct atl1c_adapter *adapter,
struct atl1c_tpd_ring *tpd_ring = (struct atl1c_tpd_ring *)
&adapter->tpd_ring[type];
struct atl1c_buffer *buffer_info;
+ struct pci_dev *pdev = adapter->pdev;
u16 next_to_clean = atomic_read(&tpd_ring->next_to_clean);
u16 hw_next_to_clean;
u16 shift;
@@ -1462,16 +1468,7 @@ static bool atl1c_clean_tx_irq(struct atl1c_adapter *adapter,
while (next_to_clean != hw_next_to_clean) {
buffer_info = &tpd_ring->buffer_info[next_to_clean];
- if (buffer_info->state == ATL1_BUFFER_BUSY) {
- pci_unmap_page(adapter->pdev, buffer_info->dma,
- buffer_info->length, PCI_DMA_TODEVICE);
- buffer_info->dma = 0;
- if (buffer_info->skb) {
- dev_kfree_skb_irq(buffer_info->skb);
- buffer_info->skb = NULL;
- }
- buffer_info->state = ATL1_BUFFER_FREE;
- }
+ atl1c_clean_buffer(pdev, buffer_info, 1);
if (++next_to_clean == tpd_ring->count)
next_to_clean = 0;
atomic_set(&tpd_ring->next_to_clean, next_to_clean);
@@ -1587,7 +1584,7 @@ static int atl1c_alloc_rx_buffer(struct atl1c_adapter *adapter, const int ringid
buffer_info = &rfd_ring->buffer_info[rfd_next_to_use];
next_info = &rfd_ring->buffer_info[next_next];
- while (next_info->state == ATL1_BUFFER_FREE) {
+ while (next_info->flags & ATL1C_BUFFER_FREE) {
rfd_desc = ATL1C_RFD_DESC(rfd_ring, rfd_next_to_use);
skb = dev_alloc_skb(adapter->rx_buffer_len);
@@ -1603,12 +1600,13 @@ static int atl1c_alloc_rx_buffer(struct atl1c_adapter *adapter, const int ringid
* the 14 byte MAC header is removed
*/
vir_addr = skb->data;
- buffer_info->state = ATL1_BUFFER_BUSY;
+ ATL1C_SET_BUFFER_STATE(buffer_info, ATL1C_BUFFER_BUSY);
buffer_info->skb = skb;
buffer_info->length = adapter->rx_buffer_len;
buffer_info->dma = pci_map_single(pdev, vir_addr,
buffer_info->length,
PCI_DMA_FROMDEVICE);
+ ATL1C_SET_PCIMAP_TYPE(buffer_info, ATL1C_PCIMAP_SINGLE);
rfd_desc->buffer_addr = cpu_to_le64(buffer_info->dma);
rfd_next_to_use = next_next;
if (++next_next == rfd_ring->count)
@@ -1653,7 +1651,8 @@ static void atl1c_clean_rfd(struct atl1c_rfd_ring *rfd_ring,
RRS_RX_RFD_INDEX_MASK;
for (i = 0; i < num; i++) {
buffer_info[rfd_index].skb = NULL;
- buffer_info[rfd_index].state = ATL1_BUFFER_FREE;
+ ATL1C_SET_BUFFER_STATE(&buffer_info[rfd_index],
+ ATL1C_BUFFER_FREE);
if (++rfd_index == rfd_ring->count)
rfd_index = 0;
}
@@ -1967,7 +1966,8 @@ static void atl1c_tx_map(struct atl1c_adapter *adapter,
buffer_info->length = map_len;
buffer_info->dma = pci_map_single(adapter->pdev,
skb->data, hdr_len, PCI_DMA_TODEVICE);
- buffer_info->state = ATL1_BUFFER_BUSY;
+ ATL1C_SET_BUFFER_STATE(buffer_info, ATL1C_BUFFER_BUSY);
+ ATL1C_SET_PCIMAP_TYPE(buffer_info, ATL1C_PCIMAP_SINGLE);
mapped_len += map_len;
use_tpd->buffer_addr = cpu_to_le64(buffer_info->dma);
use_tpd->buffer_len = cpu_to_le16(buffer_info->length);
@@ -1987,8 +1987,8 @@ static void atl1c_tx_map(struct atl1c_adapter *adapter,
buffer_info->dma =
pci_map_single(adapter->pdev, skb->data + mapped_len,
buffer_info->length, PCI_DMA_TODEVICE);
- buffer_info->state = ATL1_BUFFER_BUSY;
-
+ ATL1C_SET_BUFFER_STATE(buffer_info, ATL1C_BUFFER_BUSY);
+ ATL1C_SET_PCIMAP_TYPE(buffer_info, ATL1C_PCIMAP_SINGLE);
use_tpd->buffer_addr = cpu_to_le64(buffer_info->dma);
use_tpd->buffer_len = cpu_to_le16(buffer_info->length);
}
@@ -2008,8 +2008,8 @@ static void atl1c_tx_map(struct atl1c_adapter *adapter,
frag->page_offset,
buffer_info->length,
PCI_DMA_TODEVICE);
- buffer_info->state = ATL1_BUFFER_BUSY;
-
+ ATL1C_SET_BUFFER_STATE(buffer_info, ATL1C_BUFFER_BUSY);
+ ATL1C_SET_PCIMAP_TYPE(buffer_info, ATL1C_PCIMAP_PAGE);
use_tpd->buffer_addr = cpu_to_le64(buffer_info->dma);
use_tpd->buffer_len = cpu_to_le16(buffer_info->length);
}
^ permalink raw reply related
* Re: [PATCH 2/3] net: pass kern to net_proto_family create function
From: David Miller @ 2009-11-06 5:39 UTC (permalink / raw)
To: acme; +Cc: eparis, netdev, nhorman, dwalsh, linux-security-module
In-Reply-To: <20091105.210800.162780369.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Thu, 05 Nov 2009 21:08:00 -0800 (PST)
> From: Arnaldo Carvalho de Melo <acme@infradead.org>
> Date: Wed, 4 Nov 2009 15:31:47 -0200
>
>> Em Wed, Nov 04, 2009 at 11:32:17AM -0500, Eric Paris escreveu:
>>> The generic __sock_create function has a kern argument which allows the
>>> security system to make decisions based on if a socket is being created by
>>> the kernel or by userspace. This patch passes that flag to the
>>> net_proto_family specific create function, so it can do the same thing.
>>>
>>> Signed-off-by: Eric Paris <eparis@redhat.com>
>>
>> Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
>
> Applied to net-next-2.6
Eric, you missed Bluetooth and ATM in this change, breaking the build.
I'll fix this up, but next time...
^ permalink raw reply
* Re: Using netconsole and getting double prints
From: Matt Mackall @ 2009-11-06 5:17 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-kernel, netdev
In-Reply-To: <43e72e890911051654i19c18bf3nd397662ed79712c4@mail.gmail.com>
On Thu, 2009-11-05 at 16:54 -0800, Luis R. Rodriguez wrote:
> I'm getting double prints when using netconsole. This used to happen
> to me and then I just enable debugging log level manually (dmesg -n 8)
> but now no matter what I try I always get double prints.
This is the first report I've seen of that. Recommend investigating with
wireshark.
> I capture my data with netcat script (I call it netlog):
>
> #!/bin/bash
> echo "You should now run in another window: tail -f $HOME/log"
> while true; do
> /bin/nc -u -l -p 6666 >> $HOME/log
> done
>
> This also just doesn't work if I run the nc manually without a redirect:
>
> while true; do /bin/nc -u -l -p 6666; done
That really shouldn't make any difference.
--
http://selenic.com : development and support for Mercurial and Linux
^ permalink raw reply
* Re: [RFC PATCH] net: add dataref destructor to sk_buff
From: David Miller @ 2009-11-06 5:08 UTC (permalink / raw)
To: ghaskins; +Cc: netdev, linux-kernel
In-Reply-To: <20091002141407.30224.54207.stgit@dev.haskins.net>
From: Gregory Haskins <ghaskins@novell.com>
Date: Fri, 02 Oct 2009 10:20:00 -0400
> The following is an RFC for an attempt at addressing a zero-copy solution.
>
> To be perfectly honest, I have no idea if this is the best solution, or if
> there is truly a problem with skb->destructor that requires an alternate
> mechanism. What I do know is that this patch seems to work, and I would
> like to see some kind of solution available upstream. So I thought I would
> send my hack out as at least a point of discussion. FWIW: This has been
> tested heavily in my rig and is technically suitable for inclusion after
> review as is, if that is decided to be the optimal path forward here.
>
> Thanks for your review and consideration,
I have no fundamental objections, but when you submit this for
real can you show the code that uses it so we can get a better
idea about things?
Thanks.
^ permalink raw reply
* Re: [PATCH net-next-2.6] pktgen: tx_bytes might be slightly wrong
From: David Miller @ 2009-11-06 5:08 UTC (permalink / raw)
To: eric.dumazet; +Cc: greearb, netdev
In-Reply-To: <4AF260BB.6070607@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 05 Nov 2009 06:20:59 +0100
> [PATCH net-next-2.6] pktgen: tx_bytes might be slightly wrong
>
> cur_pkt_size can be changed in proc fs while pktgen is running,
> we better use a private field to get precise tx-bytes counter.
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: sock_bindtodevice() RCU-ification
From: David Miller @ 2009-11-06 5:08 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4AF201FC.3040908@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 04 Nov 2009 23:36:44 +0100
> Avoid dev_hold()/dev_put() in sock_bindtodevice()
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [PATCH 3/3] net: check kern before calling security subsystem
From: David Miller @ 2009-11-06 5:08 UTC (permalink / raw)
To: acme; +Cc: eparis, netdev, nhorman, dwalsh, linux-security-module
In-Reply-To: <20091104173220.GH2603@ghostprotocols.net>
From: Arnaldo Carvalho de Melo <acme@infradead.org>
Date: Wed, 4 Nov 2009 15:32:20 -0200
> Em Wed, Nov 04, 2009 at 11:32:24AM -0500, Eric Paris escreveu:
>> Before calling capable(CAP_NET_RAW) check if this operations is on behalf
>> of the kernel or on behalf of userspace. Do not do the security check if
>> it is on behalf of the kernel.
>>
>> Signed-off-by: Eric Paris <eparis@redhat.com>
>
> Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH net-next-2.6] ip_frag:
From: David Miller @ 2009-11-06 5:08 UTC (permalink / raw)
To: eric.dumazet; +Cc: joe, netdev
In-Reply-To: <4AF1FC25.9090006@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 04 Nov 2009 23:11:49 +0100
> [PATCH net-next-2.6] ip_frag: dont touch device refcount
>
> When sending fragmentation expiration ICMP V4/V6 messages,
> we can avoid touching device refcount, thanks to RCU
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied to net-next-2.6
Although I was worried a little bit initially about the
ipv4 case, as we're assigning the device pointer to
"skb->dev" and I thought it might be troublesome for
that reference to escape.
But that seems ok, because icmp_send() doesn't do anything interesting
with it's 'skb_in' arg other than look at the attached route, the
packet contents, and things like that.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next-2.6] net_cls: Use __dev_get_by_index()
From: David Miller @ 2009-11-06 5:08 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4AF1F30B.2030705@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 04 Nov 2009 22:32:59 +0100
> We hold RTNL in tc_dump_tfilter(), we can avoid dev_hold()/dev_put()
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH net-next-2.6] sctp: ipv6: avoid touching device refcount
From: David Miller @ 2009-11-06 5:08 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4AF1ECBA.6070301@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 04 Nov 2009 22:06:02 +0100
> Avoid touching device refcount in sctp/ipv6, thanks to RCU
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH] rose: device refcount leak
From: David Miller @ 2009-11-06 5:08 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4AF1E4A9.7050404@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 04 Nov 2009 21:31:37 +0100
> While hunting dev_put() for net-next-2.6, I found a device refcount
> leak in ROSE, ioctl(SIOCADDRT) error path.
>
> Fix is to not touch device refcount, as we hold RTNL
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied to net-2.6, thanks.
^ 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