* 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: 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: [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
* [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 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
* 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 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: 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: 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
* [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: [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
* 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: [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] 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: [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 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: 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
* [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: [PATCH net-next-2.6] mac80211: Speedup ieee80211_remove_interfaces()
From: David Miller @ 2009-11-06 8:44 UTC (permalink / raw)
To: johannes; +Cc: eric.dumazet, netdev, linville
In-Reply-To: <1257446408.29454.4.camel@johannes.local>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Thu, 05 Nov 2009 19:40:07 +0100
> On Thu, 2009-11-05 at 11:06 +0100, Eric Dumazet wrote:
>> Speedup ieee80211_remove_interfaces() by factorizing synchronize_rcu() calls
>
> Jouni will be pleased for his testing... :)
>
> Looks good to me. Nice simplification too.
>
> Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
>
I'll leave it to John to integrate this, thanks guys.
^ permalink raw reply
* Re: netfilter 02/02: xt_connlimit: fix regression caused by zero family value
From: David Miller @ 2009-11-06 8:44 UTC (permalink / raw)
To: jengelh; +Cc: kaber, netfilter-devel, netdev
In-Reply-To: <alpine.LSU.2.00.0911051943130.25147@obet.zrqbmnf.qr>
From: Jan Engelhardt <jengelh@medozas.de>
Date: Thu, 5 Nov 2009 19:45:25 +0100 (CET)
> On Thursday 2009-11-05 19:23, Patrick McHardy wrote:
>>
>> netfilter: xt_connlimit: fix regression caused by zero family value
>>
>> Commit v2.6.28-rc1~7172~1092~2 was slightly incomplete; not all
>> instances of par->match->family were changed to par->family.
>>
>> Netfilter bugzilla #610.
>
> Hold it.
> git would never output ~7172~1092~2 because ~8266 would be much simpler.
>
> I originally wrote "Commit v2.6.28-rc1~717^2~109^2~2", but one of your
> programs seems to eat commit messages or more.
Guys, please sort this out so I can add this fix to net-2.6
Thanks.
^ permalink raw reply
* Re: WARNING: at net/ipv4/af_inet.c:154 inet_sock_destruct
From: Francis Moreau @ 2009-11-06 8:45 UTC (permalink / raw)
To: Eric Dumazet
Cc: Linux Kernel Mailing List, Linux Netdev List, David S. Miller
In-Reply-To: <4AEB0059.1050400@gmail.com>
On Fri, Oct 30, 2009 at 4:03 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
[...]
>
> [PATCH take2] net: fix sk_forward_alloc corruption
>
With this patch applied 4 days ago, I haven't got any oops so far.
--
Francis
^ permalink raw reply
* Re: WARNING: at net/ipv4/af_inet.c:154 inet_sock_destruct
From: Eric Dumazet @ 2009-11-06 8:47 UTC (permalink / raw)
To: Francis Moreau
Cc: Linux Kernel Mailing List, Linux Netdev List, David S. Miller
In-Reply-To: <38b2ab8a0911060045hb6ebab8p43bf8aa838eabfd3@mail.gmail.com>
Francis Moreau a écrit :
> On Fri, Oct 30, 2009 at 4:03 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> [...]
>
>> [PATCH take2] net: fix sk_forward_alloc corruption
>>
>
> With this patch applied 4 days ago, I haven't got any oops so far.
Thanks a lot for testing and report Francis, I believe David will push it for stable
(if not already done)
^ permalink raw reply
* Re: PATCH: Network Device Naming mechanism and policy
From: Marco d'Itri @ 2009-11-06 8:49 UTC (permalink / raw)
To: Narendra_K
Cc: bryan, dannf, bhutchings, netdev, linux-hotplug, Matt_Domsch,
Jordan_Hargrave, Charles_Rose, Sandeep_K_Shandilya
In-Reply-To: <EDA0A4495861324DA2618B4C45DCB3EE5896D2@blrx3m08.blr.amer.dell.com>
On Nov 04, Narendra_K@Dell.com wrote:
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
> ATTR{smbios_name}=="Embedded_NIC_1", ATTR{type}=="1", KERNEL=="eth*",
> NAME="eth0".
As a distribution developer I highly value solutions like this which do
not require patching every application which deals with interface names
and then teaching users about aliases which only work in some places and
are unknown to the kernel.
--
ciao,
Marco
^ permalink raw reply
* Re: [RFC] netlink: add socket destruction notification
From: Johannes Berg @ 2009-11-06 8:55 UTC (permalink / raw)
To: David Miller; +Cc: netdev, j, tgraf
In-Reply-To: <20091105.210806.40981707.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 939 bytes --]
On Thu, 2009-11-05 at 21:08 -0800, David Miller wrote:
> > When we want to keep track of resources associated with applications, we
> > need to know when an app is going away. Add a notification function to
> > netlink that tells us that, and also hook it up to generic netlink so
> > generic netlink can notify the families. Due to the way generic netlink
> > works though, we need to notify all families and they have to sort out
> > whatever resources some commands associated with the socket themselves.
> No fundamental objections.
:)
> However, as a followup, netlink_kernel_create() is becomming
> function_that_takes_too_many_arguments().
>
> At this point it's better to just pass two arguments, the network
> namespace pointer, and a pointer to a "const struct netlink_kern_info"
> that holds the rest of the parameters.
>
> Could you make that change too?
Yeah, I agree -- will change.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: WARNING: at net/ipv4/af_inet.c:154 inet_sock_destruct
From: David Miller @ 2009-11-06 8:58 UTC (permalink / raw)
To: eric.dumazet; +Cc: francis.moro, linux-kernel, netdev
In-Reply-To: <4AF3E2A9.2020601@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 06 Nov 2009 09:47:37 +0100
> Francis Moreau a écrit :
>> On Fri, Oct 30, 2009 at 4:03 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>
>> [...]
>>
>>> [PATCH take2] net: fix sk_forward_alloc corruption
>>>
>>
>> With this patch applied 4 days ago, I haven't got any oops so far.
>
> Thanks a lot for testing and report Francis, I believe David will
> push it for stable (if not already done)
I'm pretty sure it's already in Greg's current batch, but if it
doesn't show up in his next -stable release I'll make sure to
submit it.
^ 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