Re: [RFC PATCH 8/8] Jhash in too big for inlining, move under lib/
On Wed, 20 Feb 2008 15:47:18 +0200 Ilpo Järvinen [EMAIL PROTECTED] wrote: vmlinux.o: 62 functions changed, 66 bytes added, 10935 bytes removed, diff: -10869 ...+ these to lib/jhash.o: jhash_3words: 112 jhash2: 276 jhash: 475 select for networking code might need a more fine-grained approach. It should be possible to use a modular jhash.ko. The things which you have identified as clients of the jhash library are usually loaded as modules. But in the case where someone does (say) NFSD=y we do need jhash.o linked into vmlinux also. This is doable in Kconfig but I always forget how. Adrian, Sam and Randy are the repositories of knowledge here ;) -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/8]: uninline uninline
On Wed, 20 Feb 2008 15:47:10 +0200 Ilpo J__rvinen [EMAIL PROTECTED] wrote: Ok, here's the top of the list (1+ bytes): This is good stuff - thanks. -41525 2066 f, 3370 +, 44895 -, diff: -41525 IS_ERR This is a surprise. I expect that the -mm-only profile-likely-unlikely-macros.patch is the cause of this and mainline doesn't have this problem. If true, then this likely/unlikely bloat has probably spread into a lot of your other results and it all should be redone against mainline, sorry :( (I'm not aware of anyone having used profile-likely-unlikely-macros.patch in quite some time. That's unfortunate because it has turned up some fairly flagrant code deoptimisations) -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WARNING: at net/ipv4/tcp_input.c:2054 tcp_mark_head_lost()
(cc netdev) On Wed, 20 Feb 2008 20:04:39 -0800 (PST) Giangiacomo Mariotti [EMAIL PROTECTED] wrote: This is what I got with dmesg : [ 266.978695] WARNING: at net/ipv4/tcp_input.c:2054 tcp_mark_head_lost() [ 266.978701] Pid: 0, comm: swapper Not tainted 2.6.24.2-my001 #1 [ 266.978703] [ 266.978704] Call Trace: [ 266.978706] IRQ [80426981] tcp_ack+0x16d8/0x197f [ 266.978721] [8022e72f] __wake_up+0x38/0x4e [ 266.978727] [804295ef] tcp_rcv_established+0xe2/0x8cb [ 266.978732] [8042f56f] tcp_v4_do_rcv+0x30/0x39c [ 266.978738] [80431d29] tcp_v4_rcv+0x99b/0xa06 [ 266.978743] [803f2c95] __netdev_alloc_skb+0x29/0x43 [ 266.978749] [80416d21] ip_local_deliver_finish+0x152/0x212 [ 266.978753] [80416bac] ip_rcv_finish+0x2f8/0x31b [ 266.978758] [803f6c42] netif_receive_skb+0x3ae/0x3d1 [ 266.978763] [8037398f] rtl8169_rx_interrupt+0x45f/0x53e [ 266.978768] [8037405b] rtl8169_poll+0x36/0x16a [ 266.978773] [803f8ca7] net_rx_action+0xb7/0x1f3 [ 266.978778] [8023a3a5] __do_softirq+0x65/0xce [ 266.978782] [8020b0d2] default_idle+0x0/0x3d [ 266.978786] [8020d09c] call_softirq+0x1c/0x28 [ 266.978789] [8020e4f0] do_softirq+0x2c/0x7d [ 266.978792] [8023a2fb] irq_exit+0x3f/0x84 [ 266.978794] [8020e729] do_IRQ+0xb6/0xd5 [ 266.978797] [8020b0d2] default_idle+0x0/0x3d [ 266.978800] [8020c421] ret_from_intr+0x0/0xa [ 266.978801] EOI [8020b0fb] default_idle+0x29/0x3d [ 266.978809] [8020b1a2] cpu_idle+0x93/0xbb [ 266.978813] [805cfa4b] start_kernel+0x2bb/0x2c7 [ 266.978818] [805cf123] _sinittext+0x123/0x12a [ 266.978821] This though didn't cause any user-visible problem. .config file : -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/28] mm: __GFP_MEMALLOC
On Wed, 20 Feb 2008 15:46:19 +0100 Peter Zijlstra [EMAIL PROTECTED] wrote: __GFP_MEMALLOC will allow the allocation to disregard the watermarks, much like PF_MEMALLOC. 'twould be nice if the changelog had some explanation of the reason for this change. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/28] mm: emergency pool
On Wed, 20 Feb 2008 15:46:17 +0100 Peter Zijlstra [EMAIL PROTECTED] wrote:
@@ -213,7 +213,7 @@ enum zone_type {
struct zone {
/* Fields commonly accessed by the page allocator */
- unsigned long pages_min, pages_low, pages_high;
+ unsigned long pages_emerg, pages_min, pages_low, pages_high;
It would be nice to make these one-per-line, then document them.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/28] mm: allow PF_MEMALLOC from softirq context
On Wed, 20 Feb 2008 15:46:15 +0100 Peter Zijlstra [EMAIL PROTECTED] wrote:
Allow PF_MEMALLOC to be set in softirq context. When running softirqs from
a borrowed context save current-flags, ksoftirqd will have its own
task_struct.
The second sentence doesn't make sense.
This is needed to allow network softirq packet processing to make use of
PF_MEMALLOC.
...
+#define tsk_restore_flags(p, pflags, mask) \
+ do {(p)-flags = ~(mask); \
+ (p)-flags |= ((pflags) (mask)); } while (0)
+
Does it need to be a macro?
If so, it really should cook up a temporary to avoid referencing p twice -
the children might be watching.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/28] Swap over NFS -v16
On Wed, 20 Feb 2008 15:46:10 +0100 Peter Zijlstra [EMAIL PROTECTED] wrote: Another posting of the full swap over NFS series. Well I looked. There's rather a lot of it and I wouldn't pretend to understand it. What is the NFS and net people's take on all of this? -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/28] mm: kmem_estimate_pages()
On Wed, 20 Feb 2008 15:46:14 +0100 Peter Zijlstra [EMAIL PROTECTED] wrote: Provide a method to get the upper bound on the pages needed to allocate a given number of objects from a given kmem_cache. This lays the foundation for a generic reserve framework as presented in a later patch in this series. This framework needs to convert object demand (kmalloc() bytes, kmem_cache_alloc() objects) to pages. ... /* + * return the max number of pages required to allocated count + * objects from the given cache + */ +unsigned kmem_estimate_pages(struct kmem_cache *s, gfp_t flags, int objects) You might want to have another go at that comment. +/* + * return the max number of pages required to allocate @bytes from kmalloc + * in an unspecified number of allocation of heterogeneous size. + */ +unsigned kestimate(gfp_t flags, size_t bytes) And its pal. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/28] mm: system wide ALLOC_NO_WATERMARK
On Wed, 20 Feb 2008 15:46:18 +0100 Peter Zijlstra [EMAIL PROTECTED] wrote:
Change ALLOC_NO_WATERMARK page allocation such that the reserves are system
wide - which they are per setup_per_zone_pages_min(), when we scrape the
barrel, do it properly.
The changelog is fairly incomprehensible.
mm/page_alloc.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-2.6/mm/page_alloc.c
===
--- linux-2.6.orig/mm/page_alloc.c
+++ linux-2.6/mm/page_alloc.c
@@ -1552,6 +1552,12 @@ restart:
rebalance:
if (alloc_flags ALLOC_NO_WATERMARKS) {
nofail_alloc:
+ /*
+ * break out of mempolicy boundaries
+ */
+ zonelist = NODE_DATA(numa_node_id())-node_zonelists +
+ gfp_zone(gfp_mask);
+
/* go through the zonelist yet again, ignoring mins */
page = get_page_from_freelist(gfp_mask, order, zonelist,
ALLOC_NO_WATERMARKS);
As is the patch. People who care about mempolicies will want a better
explanation, please, so they can check that we're not busting their stuff.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/28] netvm: network reserve infrastructure
On Wed, 20 Feb 2008 15:46:25 +0100 Peter Zijlstra [EMAIL PROTECTED] wrote:
Provide the basic infrastructure to reserve and charge/account network memory.
We provide the following reserve tree:
1) total network reserve
2)network TX reserve
3) protocol TX pages
4)network RX reserve
5) SKB data reserve
[1] is used to make all the network reserves a single subtree, for easy
manipulation.
[2] and [4] are merely for eastetic reasons.
The TX pages reserve [3] is assumed bounded by it being the upper bound of
memory that can be used for sending pages (not quite true, but good enough)
The SKB reserve [5] is an aggregate reserve, which is used to charge SKB data
against in the fallback path.
The consumers for these reserves are sockets marked with:
SOCK_MEMALLOC
Such sockets are to be used to service the VM (iow. to swap over). They
must be handled kernel side, exposing such a socket to user-space is a BUG.
+/**
+ * sk_adjust_memalloc - adjust the global memalloc reserve for critical RX
+ * @socks: number of new %SOCK_MEMALLOC sockets
+ * @tx_resserve_pages: number of pages to (un)reserve for TX
+ *
+ * This function adjusts the memalloc reserve based on system demand.
+ * The RX reserve is a limit, and only added once, not for each socket.
+ *
+ * NOTE:
+ * @tx_reserve_pages is an upper-bound of memory used for TX hence
+ * we need not account the pages like we do for RX pages.
+ */
+int sk_adjust_memalloc(int socks, long tx_reserve_pages)
+{
+ int nr_socks;
+ int err;
+
+ err = mem_reserve_pages_add(net_tx_pages, tx_reserve_pages);
+ if (err)
+ return err;
+
+ nr_socks = atomic_read(memalloc_socks);
+ if (!nr_socks socks 0)
+ err = mem_reserve_connect(net_reserve, mem_reserve_root);
This looks like it should have some locking?
+ nr_socks = atomic_add_return(socks, memalloc_socks);
+ if (!nr_socks socks)
+ err = mem_reserve_disconnect(net_reserve);
Or does that try to make up for it? Still looks fishy.
+ if (err)
+ mem_reserve_pages_add(net_tx_pages, -tx_reserve_pages);
+
+ return err;
+}
+
+/**
+ * sk_set_memalloc - sets %SOCK_MEMALLOC
+ * @sk: socket to set it on
+ *
+ * Set %SOCK_MEMALLOC on a socket and increase the memalloc reserve
+ * accordingly.
+ */
+int sk_set_memalloc(struct sock *sk)
+{
+ int set = sock_flag(sk, SOCK_MEMALLOC);
+#ifndef CONFIG_NETVM
+ BUG();
+#endif
?? #error, maybe?
+ if (!set) {
+ int err = sk_adjust_memalloc(1, 0);
+ if (err)
+ return err;
+
+ sock_set_flag(sk, SOCK_MEMALLOC);
+ sk-sk_allocation |= __GFP_MEMALLOC;
+ }
+ return !set;
+}
+EXPORT_SYMBOL_GPL(sk_set_memalloc);
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 17/28] netvm: hook skb allocation to reserves
On Wed, 20 Feb 2008 15:46:27 +0100 Peter Zijlstra [EMAIL PROTECTED] wrote:
Change the skb allocation api to indicate RX usage and use this to fall back
to
the reserve when needed. SKBs allocated from the reserve are tagged in
skb-emergency.
Teach all other skb ops about emergency skbs and the reserve accounting.
Use the (new) packet split API to allocate and track fragment pages from the
emergency reserve. Do this using an atomic counter in page-index. This is
needed because the fragments have a different sharing semantic than that
indicated by skb_shinfo()-dataref.
Note that the decision to distinguish between regular and emergency SKBs
allows
the accounting overhead to be limited to the later kind.
...
+static inline void skb_get_page(struct sk_buff *skb, struct page *page)
+{
+ get_page(page);
+ if (skb_emergency(skb))
+ atomic_inc(page-frag_count);
+}
+
+static inline void skb_put_page(struct sk_buff *skb, struct page *page)
+{
+ if (skb_emergency(skb) atomic_dec_and_test(page-frag_count))
+ rx_emergency_put(PAGE_SIZE);
+ put_page(page);
+}
I'm thinking we should do `#define slowcall inline' then use that in the future.
static void skb_release_data(struct sk_buff *skb)
{
if (!skb-cloned ||
!atomic_sub_return(skb-nohdr ? (1 SKB_DATAREF_SHIFT) + 1 : 1,
skb_shinfo(skb)-dataref)) {
+ int size;
+
+#ifdef NET_SKBUFF_DATA_USES_OFFSET
+ size = skb-end;
+#else
+ size = skb-end - skb-head;
+#endif
The patch adds rather a lot of ifdefs.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/28] mm: memory reserve management
On Wed, 20 Feb 2008 15:46:20 +0100 Peter Zijlstra [EMAIL PROTECTED] wrote:
Generic reserve management code.
It provides methods to reserve and charge. Upon this, generic alloc/free style
reserve pools could be build, which could fully replace mempool_t
functionality.
It should also allow for a Banker's algorithm replacement of __GFP_NOFAIL.
Generally: the comments in this code are a bit straggly and hard to follow.
They'd be worth a revisit.
+/*
+ * Simple output of the reserve tree in: /proc/reserve_info
+ * Example:
+ *
+ * localhost ~ # cat /proc/reserve_info
+ * total reserve 8156K (0/544817)
+ * total network reserve 8156K (0/544817)
+ * network TX reserve 196K (0/49)
+ * protocol TX pages 196K (0/49)
+ * network RX reserve 7960K (0/544768)
+ * IPv6 route cache 1372K (0/4096)
+ * IPv4 route cache 5468K (0/16384)
+ * SKB data reserve 1120K (0/524288)
+ * IPv6 fragment cache560K (0/262144)
+ * IPv4 fragment cache560K (0/262144)
+ */
Well, Simple was a freudian typo. Not designed for programmatic parsing,
I see.
+static __init int mem_reserve_proc_init(void)
+{
+ struct proc_dir_entry *entry;
+
+ entry = create_proc_entry(reserve_info, S_IRUSR, NULL);
I think we're supposed to use proc_create(). Blame Alexey.
+ if (entry)
+ entry-proc_fops = mem_reserve_opterations;
+
+ return 0;
+}
+
+__initcall(mem_reserve_proc_init);
module_init() is more trendy.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] alloc_percpu() fails to allocate percpu data
On Thu, 21 Feb 2008 19:00:03 +0100 Eric Dumazet [EMAIL PROTECTED] wrote: +#ifndef cache_line_size +#define cache_line_size()L1_CACHE_BYTES +#endif argh, you made me look. Really cache_line_size() should be implemented in include/linux/cache.h. Then we tromp the stupid private implementations in slob.c and slub.c. Then we wonder why x86 uses a custom cache_line_size(), but still uses L1_CACHE_BYTES for its L1_CACHE_ALIGN(). Once we've answered that, we look at your + /* +* We should make sure each CPU gets private memory. +*/ + size = roundup(size, cache_line_size()); and wonder whether it should have used L1_CACHE_ALIGN(). I think I'd better stop looking. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] alloc_percpu() fails to allocate percpu data
On Friday 22 February 2008 09:26, Peter Zijlstra wrote: On Thu, 2008-02-21 at 19:00 +0100, Eric Dumazet wrote: Some oprofile results obtained while using tbench on a 2x2 cpu machine were very surprising. For example, loopback_xmit() function was using high number of cpu cycles to perform the statistic updates, supposed to be real cheap since they use percpu data pcpu_lstats = netdev_priv(dev); lb_stats = per_cpu_ptr(pcpu_lstats, smp_processor_id()); lb_stats-packets++; /* HERE : serious contention */ lb_stats-bytes += skb-len; struct pcpu_lstats is a small structure containing two longs. It appears that on my 32bits platform, alloc_percpu(8) allocates a single cache line, instead of giving to each cpu a separate cache line. Using the following patch gave me impressive boost in various benchmarks ( 6 % in tbench) (all percpu_counters hit this bug too) Long term fix (ie = 2.6.26) would be to let each CPU allocate their own block of memory, so that we dont need to roudup sizes to L1_CACHE_BYTES, or merging the SGI stuff of course... Note : SLUB vs SLAB is important here to *show* the improvement, since they dont have the same minimum allocation sizes (8 bytes vs 32 bytes). This could very well explain regressions some guys reported when they switched to SLUB. I've complained about this false sharing as well, so until we get the new and improved percpu allocators, What I don't understand is why the slab allocators have something like this in it: if ((flags SLAB_HWCACHE_ALIGN) size cache_line_size() / 2) return max_t(unsigned long, align, cache_line_size()); If you ask for HWCACHE_ALIGN, then you should get it. I don't understand, why do they think they knows better than the caller? Things like this are just going to lead to very difficult to track performance problems. Possibly correctness problems in rare cases. There could be another flag for maybe align. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Error on ip route replace command
- Original Message - From: Joonwoo Park [EMAIL PROTECTED] To: Francesco Saverio Giudice [EMAIL PROTECTED] Cc: netdev@vger.kernel.org Sent: Saturday, February 23, 2008 7:44 AM Subject: Re: Error on ip route replace command Francesco, It was fixed by 936f6f8e1bc46834bbb3e3fa3ac13ab44f1e7ba6 and c18865f39276435abb9286f9a816cb5b66c99a00. Please try with lastest git source Joonwoo. Joonwoo, I will give a try. Thank you Francesco -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 8/8] Jhash in too big for inlining, move under lib/
On Sat, 23 Feb 2008, Andrew Morton wrote: On Wed, 20 Feb 2008 15:47:18 +0200 Ilpo Järvinen [EMAIL PROTECTED] wrote: vmlinux.o: 62 functions changed, 66 bytes added, 10935 bytes removed, diff: -10869 ...+ these to lib/jhash.o: jhash_3words: 112 jhash2: 276 jhash: 475 select for networking code might need a more fine-grained approach. It should be possible to use a modular jhash.ko. The things which you have identified as clients of the jhash library are usually loaded as modules. But in the case where someone does (say) NFSD=y we do need jhash.o linked into vmlinux also. This is doable in Kconfig but I always forget how. Ok, even though its not that likely that one lives without e.g. net/ipv4/inet_connection_sock.c or net/netlink/af_netlink.c? But maybe some guys really know what they are doing and can come up with config that would be able to build it as module (for other than proof-of-concept uses I mean)... :-/ Adrian, Sam and Randy are the repositories of knowledge here ;) Thanks, I'll consult them in this. I've never needed to do any Kconfig stuff so far so it's no surprise I have very little clue... :-) I've one question for you Andrew, how would you like this kind of cross-subsys toucher to be merged, through you directly I suppose? -- i.
Re: [RFC PATCH 0/8]: uninline uninline
On Sat, 23 Feb 2008, Andrew Morton wrote: On Wed, 20 Feb 2008 15:47:10 +0200 Ilpo J__rvinen [EMAIL PROTECTED] wrote: -41525 2066 f, 3370 +, 44895 -, diff: -41525 IS_ERR This is a surprise. It surprised me as well, there were something like 10 bytes I just couldn't explain in IS_ERR size (kernel/uninlined.c: IS_ERR | +25). I was to look into it deeper but didn't have the .o's at hand right away, not so trivial to store results of 5000+ build results except some carefully picked textual output :-)... Hmm, I'll add logging for the disassembly of the uninlined stuff into the next run, that won't cost too much... I expect that the -mm-only profile-likely-unlikely-macros.patch is the cause of this and mainline doesn't have this problem. Ahaa, this explain it, I suspected that there was something (un)likely related elsewhere as well, no wonder why I couldn't reproduce the 25 bytes result in my quick copy-pasted non-kernel test... If true, then this likely/unlikely bloat has probably spread into a lot of your other results and it all should be redone against mainline, sorry :( It isn't that troublesome to redo them, it's mainly automatic combined with impatient waiting from my behalf :-)... The spreading problem is probably true, to some extent. I did some runs also with carefully selected CONFIG.*DEBUG.* off under include/net/ earlier, in general it made very little difference, if something bloats, it usually does that regardless of .config. There are probably couple of exceptions when the size is on the boundary where it's very close of being useful to uninline it. One interesting thing in there was that the largest offenders are quite small per call-site but due to vast number of them even a small benefit buys off a lot in kernel wide results. I suspect the differences due to (un)likely will be negligle, because the IS_ERR with all its trivialness is now mostly -15, so anything clearly larger than that will likely still be a win x n (where n is quite large). Anyway, I'll see when I get the new set of tests running... :-) I'd prefer with CONFIG.*DEBUG off to get larger picture about non-debug builds too (especially the scatterlist.h things interest me a lot), do you think that would do as well? Thanks for your comments, I found them very useful. -- i. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 8/8] Jhash in too big for inlining, move under lib/
Andrew Morton [EMAIL PROTECTED] writes: It should be possible to use a modular jhash.ko. The things which you have identified as clients of the jhash library are usually loaded as modules. For very small functions like this own modules are quite expensive. First everything gets rounded up to at least one 4K page (or worse on architectures with larger pages). That just wastes some memory. But then since modules live in vmalloc space they also need an own TLB entry, which are notouriously scarce in the kernel because often user space wants to monopolize them all. So if you're unlucky and user space is thrashing the TLB just a single call to this hash function will be an own TLB miss and quite expensive. It would be better to just always link it in for this case. -Andi -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/8]: uninline uninline
Andrew Morton [EMAIL PROTECTED] writes: -41525 2066 f, 3370 +, 44895 -, diff: -41525 IS_ERR This is a surprise. I expect that the -mm-only profile-likely-unlikely-macros.patch is the cause of this and mainline doesn't have this problem. Shouldn't they only have overhead when the respective CONFIG is enabled? If true, then this likely/unlikely bloat has probably spread into a lot of your other results and it all should be redone against mainline, sorry :( (I'm not aware of anyone having used profile-likely-unlikely-macros.patch in quite some time. That's unfortunate because it has turned up some fairly flagrant code deoptimisations) Is there any reason they couldn't just be merged to mainline? I think it's a useful facility. -Andi -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2]via-rhine.c: Use-register-offset-definition-for-WOLcgClr
Use register offset definition for WOLcgClr. This patch does not
change the driver behaviour.
Signed-off-by: Laura Garcia Liebana [EMAIL PROTECTED]
modified: drivers/net/via-rhine.c
---
drivers/net/via-rhine.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/via-rhine.c b/drivers/net/via-rhine.c
index 7c851b1..8c9d6ae 100644
--- a/drivers/net/via-rhine.c
+++ b/drivers/net/via-rhine.c
@@ -1893,7 +1893,7 @@ static void rhine_shutdown (struct pci_dev *pdev)
/* Make sure we use pattern 0, 1 and not 4, 5 */
if (rp-quirks rq6patterns)
- iowrite8(0x04, ioaddr + 0xA7);
+ iowrite8(0x04, ioaddr + WOLcgClr);
if (rp-wolopts WAKE_MAGIC) {
iowrite8(WOLmagic, ioaddr + WOLcrSet);
--
1.5.3.8
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2]via-rhine.c: Write-Wake-on-LAN-options-in-_real-time_-not-at-shutdown
Write Wake-on-LAN options in _real time_ not at shutdown. It might
be safe in case of power outage.
Signed-off-by: Laura Garcia Liebana [EMAIL PROTECTED]
modified: drivers/net/via-rhine.c
---
drivers/net/via-rhine.c | 76 +-
1 files changed, 41 insertions(+), 35 deletions(-)
diff --git a/drivers/net/via-rhine.c b/drivers/net/via-rhine.c
index 8c9d6ae..7723ec0 100644
--- a/drivers/net/via-rhine.c
+++ b/drivers/net/via-rhine.c
@@ -418,6 +418,7 @@ static void rhine_tx(struct net_device *dev);
static int rhine_rx(struct net_device *dev, int limit);
static void rhine_error(struct net_device *dev, int intr_status);
static void rhine_set_rx_mode(struct net_device *dev);
+static void rhine_write_wol(struct net_device *dev);
static struct net_device_stats *rhine_get_stats(struct net_device *dev);
static int netdev_ioctl(struct net_device *dev, struct ifreq *rq, int cmd);
static const struct ethtool_ops netdev_ethtool_ops;
@@ -1772,7 +1773,7 @@ static void rhine_get_wol(struct net_device *dev, struct
ethtool_wolinfo *wol)
struct rhine_private *rp = netdev_priv(dev);
if (!(rp-quirks rqWOL))
- return;
+ return; /* Nothing to do for non-WOL adapters */
spin_lock_irq(rp-lock);
wol-supported = WAKE_PHY | WAKE_MAGIC |
@@ -1788,7 +1789,7 @@ static int rhine_set_wol(struct net_device *dev, struct
ethtool_wolinfo *wol)
WAKE_UCAST | WAKE_MCAST | WAKE_BCAST; /* Untested */
if (!(rp-quirks rqWOL))
- return -EINVAL;
+ return -EINVAL; /* Nothing to do for non-WOL adapters */
if (wol-wolopts ~support)
return -EINVAL;
@@ -1797,9 +1798,47 @@ static int rhine_set_wol(struct net_device *dev, struct
ethtool_wolinfo *wol)
rp-wolopts = wol-wolopts;
spin_unlock_irq(rp-lock);
+ rhine_write_wol(dev);
+
return 0;
}
+static void rhine_write_wol(struct net_device *dev)
+{
+ struct rhine_private *rp = netdev_priv(dev);
+ void __iomem *ioaddr = rp-base;
+
+ rhine_power_init(dev);
+
+ /* Make sure we use pattern 0, 1 and not 4, 5 */
+ if (rp-quirks rq6patterns)
+ iowrite8(0x04, ioaddr + WOLcgClr);
+
+ if (rp-wolopts WAKE_MAGIC) {
+ iowrite8(WOLmagic, ioaddr + WOLcrSet);
+ /*
+* Turn EEPROM-controlled wake-up back on -- some hardware may
+* not cooperate otherwise.
+*/
+ iowrite8(ioread8(ioaddr + ConfigA) | 0x03, ioaddr + ConfigA);
+ }
+
+ if (rp-wolopts (WAKE_BCAST|WAKE_MCAST))
+ iowrite8(WOLbmcast, ioaddr + WOLcgSet);
+
+ if (rp-wolopts WAKE_PHY)
+ iowrite8(WOLlnkon | WOLlnkoff, ioaddr + WOLcrSet);
+
+ if (rp-wolopts WAKE_UCAST)
+ iowrite8(WOLucast, ioaddr + WOLcrSet);
+
+ if (rp-wolopts) {
+ /* Enable legacy WOL (for old motherboards) */
+ iowrite8(0x01, ioaddr + PwcfgSet);
+ iowrite8(ioread8(ioaddr + StickyHW) | 0x04, ioaddr + StickyHW);
+ }
+}
+
static const struct ethtool_ops netdev_ethtool_ops = {
.get_drvinfo= netdev_get_drvinfo,
.get_settings = netdev_get_settings,
@@ -1886,39 +1925,6 @@ static void rhine_shutdown (struct pci_dev *pdev)
struct rhine_private *rp = netdev_priv(dev);
void __iomem *ioaddr = rp-base;
- if (!(rp-quirks rqWOL))
- return; /* Nothing to do for non-WOL adapters */
-
- rhine_power_init(dev);
-
- /* Make sure we use pattern 0, 1 and not 4, 5 */
- if (rp-quirks rq6patterns)
- iowrite8(0x04, ioaddr + WOLcgClr);
-
- if (rp-wolopts WAKE_MAGIC) {
- iowrite8(WOLmagic, ioaddr + WOLcrSet);
- /*
-* Turn EEPROM-controlled wake-up back on -- some hardware may
-* not cooperate otherwise.
-*/
- iowrite8(ioread8(ioaddr + ConfigA) | 0x03, ioaddr + ConfigA);
- }
-
- if (rp-wolopts (WAKE_BCAST|WAKE_MCAST))
- iowrite8(WOLbmcast, ioaddr + WOLcgSet);
-
- if (rp-wolopts WAKE_PHY)
- iowrite8(WOLlnkon | WOLlnkoff, ioaddr + WOLcrSet);
-
- if (rp-wolopts WAKE_UCAST)
- iowrite8(WOLucast, ioaddr + WOLcrSet);
-
- if (rp-wolopts) {
- /* Enable legacy WOL (for old motherboards) */
- iowrite8(0x01, ioaddr + PwcfgSet);
- iowrite8(ioread8(ioaddr + StickyHW) | 0x04, ioaddr + StickyHW);
- }
-
/* Hit power state D3 (sleep) */
if (!avoid_D3)
iowrite8(ioread8(ioaddr + StickyHW) | 0x03, ioaddr + StickyHW);
--
1.5.3.8
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Re: [RFC PATCH 0/8]: uninline uninline
On Sat, 23 Feb 2008, Andi Kleen wrote: Andrew Morton [EMAIL PROTECTED] writes: -41525 2066 f, 3370 +, 44895 -, diff: -41525 IS_ERR This is a surprise. I expect that the -mm-only profile-likely-unlikely-macros.patch is the cause of this and mainline doesn't have this problem. Shouldn't they only have overhead when the respective CONFIG is enabled? I uninlined those with allyesconfig. I'll anyway try later on without a number of debug related CONFIGs. -- i. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 8/8] Jhash in too big for inlining, move under lib/
On Sat, 23 Feb 2008 12:05:36 +0200 (EET) Ilpo Järvinen [EMAIL PROTECTED] wrote: On Sat, 23 Feb 2008, Andrew Morton wrote: On Wed, 20 Feb 2008 15:47:18 +0200 Ilpo Järvinen [EMAIL PROTECTED] wrote: vmlinux.o: 62 functions changed, 66 bytes added, 10935 bytes removed, diff: -10869 ...+ these to lib/jhash.o: jhash_3words: 112 jhash2: 276 jhash: 475 select for networking code might need a more fine-grained approach. It should be possible to use a modular jhash.ko. The things which you have identified as clients of the jhash library are usually loaded as modules. But in the case where someone does (say) NFSD=y we do need jhash.o linked into vmlinux also. This is doable in Kconfig but I always forget how. Ok, even though its not that likely that one lives without e.g. net/ipv4/inet_connection_sock.c or net/netlink/af_netlink.c? Sure, the number of people who will want CONFIG_JHASH=n is very small. But maybe some guys really know what they are doing and can come up with config that would be able to build it as module (for other than proof-of-concept uses I mean)... :-/ Adrian, Sam and Randy are the repositories of knowledge here ;) Thanks, I'll consult them in this. I've never needed to do any Kconfig stuff so far so it's no surprise I have very little clue... :-) Thanks. If it gets messy I'd just put lib/jhash.o in obj-y. I assume it's pretty small. I've one question for you Andrew, how would you like this kind of cross-subsys toucher to be merged, through you directly I suppose? Sure, I can scrounge around for appropriate reviews and acks and can make sure that nobody's pending work gets disrupted. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/8]: uninline uninline
On Sat, 23 Feb 2008 14:15:06 +0100 Andi Kleen [EMAIL PROTECTED] wrote: Andrew Morton [EMAIL PROTECTED] writes: -41525 2066 f, 3370 +, 44895 -, diff: -41525 IS_ERR This is a surprise. I expect that the -mm-only profile-likely-unlikely-macros.patch is the cause of this and mainline doesn't have this problem. Shouldn't they only have overhead when the respective CONFIG is enabled? yup. If true, then this likely/unlikely bloat has probably spread into a lot of your other results and it all should be redone against mainline, sorry :( (I'm not aware of anyone having used profile-likely-unlikely-macros.patch in quite some time. That's unfortunate because it has turned up some fairly flagrant code deoptimisations) Is there any reason they couldn't just be merged to mainline? I think it's a useful facility. ummm, now why did we made that decision... I think we decided that it's the sort of thing which one person can run once per few months and that will deliver its full value. I can maintain it in -mm and we're happy - no need to add it to mainline. No strong feelings either way really. It does have the downside that the kernel explodes if someone adds unlikely or likely to the vdso code and I need to occasionally hunt down new additions and revert them in that patch. That makes it a bit of a maintenance burden. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [PS3] gelic wireless driver needs MAC80211 support
so select it. Signed-off-by: Sebastian Siewior [EMAIL PROTECTED] --- drivers/net/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index f337800..a116056 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -2363,6 +2363,7 @@ config GELIC_NET config GELIC_WIRELESS bool PS3 Wireless support depends on GELIC_NET + select MAC80211 help This option adds the support for the wireless feature of PS3. If you have the wireless-less model of PS3 or have no plan to -- 1.5.3.8 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [PS3] gelic wireless driver needs MAC80211 support
On Saturday 23 February 2008, Sebastian Siewior wrote: so select it. Signed-off-by: Sebastian Siewior [EMAIL PROTECTED] --- drivers/net/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index f337800..a116056 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -2363,6 +2363,7 @@ config GELIC_NET config GELIC_WIRELESS bool PS3 Wireless support depends on GELIC_NET + select MAC80211 help This option adds the support for the wireless feature of PS3. If you have the wireless-less model of PS3 or have no plan to Is there any particular reason why this driver is in drivers/net instead of drivers/net/wireless (along with all other wireless drivers? Additionally, all other mac80211 drivers depend on mac80211 instead of selecting it. So I think for consistency it might be better to also make this driver depend on it, rather then selecting. Ivo -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [PS3] gelic wireless driver needs MAC80211 support
On Saturday 23 February 2008, Ivo van Doorn wrote: On Saturday 23 February 2008, Sebastian Siewior wrote: so select it. Signed-off-by: Sebastian Siewior [EMAIL PROTECTED] --- drivers/net/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index f337800..a116056 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -2363,6 +2363,7 @@ config GELIC_NET config GELIC_WIRELESS bool PS3 Wireless support depends on GELIC_NET + select MAC80211 help This option adds the support for the wireless feature of PS3. If you have the wireless-less model of PS3 or have no plan to Is there any particular reason why this driver is in drivers/net instead of drivers/net/wireless (along with all other wireless drivers? Additionally, all other mac80211 drivers depend on mac80211 instead of selecting it. So I think for consistency it might be better to also make this driver depend on it, rather then selecting. Additionally, what part of the driver actually uses mac80211? I just browsed to the code, and it seems to work completely without using mac80211. Instead it seems to work directly by registering a net_device structure... Ivo -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC PATCH 0/8]: uninline uninline
Is there any reason they couldn't just be merged to mainline? I think it's a useful facility. ummm, now why did we made that decision... I think we decided that it's the sort of thing which one person can run once per few months and that will deliver its full value. I can maintain it in -mm and we're happy - no need to add it to mainline. No strong feelings either way really. Apparently nobody has been doing it for a while. :-) Last time I did it it was around the submission time and I actually patched it into mainline kernel to do so. Not particularly hard to do, but sitting in mm-only does make it a bit harder, and there are the vdso problem you just mentioned that one has to fix for himself if it exists in mainline. It does have the downside that the kernel explodes if someone adds unlikely or likely to the vdso code and I need to occasionally hunt down new additions and revert them in that patch. That makes it a bit of a maintenance burden. Is it possible to catch this automatically, like, by re-defining likely/unlikely to the raw form in specific file(s)? Hua -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [PS3] gelic wireless driver needs MAC80211 support
* Sebastian Siewior | 2008-02-23 21:06:37 [+0100]: I add this to the patch desctiption and post a depends on patach ARGH, this was CONFIG_WIRELESS_EXT and not MAC80211. You would like to see a select or depend statement on that one? Ivo Sebastian -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [PS3] gelic wireless driver needs MAC80211 support
On Saturday 23 February 2008, Sebastian Siewior wrote: * Ivo van Doorn | 2008-02-23 20:50:34 [+0100]: Additionally, what part of the driver actually uses mac80211? I just browsed to the code, and it seems to work completely without using mac80211. Instead it seems to work directly by registering a net_device structure... CC drivers/net/ps3_gelic_wireless.o /home/bigeasy/git/linux-2.6/drivers/net/ps3_gelic_wireless.c: In function 'gelic_wl_setup_netdev_ops': /home/bigeasy/git/linux-2.6/drivers/net/ps3_gelic_wireless.c:2660: error: 'struct net_device' has no member named 'wireless_data' /home/bigeasy/git/linux-2.6/drivers/net/ps3_gelic_wireless.c:2661: error: 'struct net_device' has no member named 'wireless_handlers' make[3]: *** [drivers/net/ps3_gelic_wireless.o] Error 1 make[2]: *** [drivers/net] Error 2 make[1]: *** [drivers] Error 2 make[1]: *** Waiting for unfinished jobs make: *** [sub-make] Error 2 I add this to the patch desctiption and post a depends on patach Looking at include/linux/netdevice.h: #ifdef CONFIG_WIRELESS_EXT /* List of functions to handle Wireless Extensions (instead of ioctl). * See net/iw_handler.h for details. Jean II */ const struct iw_handler_def * wireless_handlers; /* Instance data managed by the core of Wireless Extensions. */ struct iw_public_data * wireless_data; #endif There is no dependency on mac80211 but on WIRELESS_EXT. That is a config option most other drivers select, so you best change your patch to select WIRELESS_EXT instead of MAC80211. Ivo -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [PS3] gelic wireless driver needs MAC80211 support
* Ivo van Doorn | 2008-02-23 20:44:59 [+0100]: Is there any particular reason why this driver is in drivers/net instead of drivers/net/wireless (along with all other wireless drivers? My understanding is/was that the wireless device and the eth device are exposed by the hypervisor to the system and they share ressources. Sebastian -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [PS3] gelic wireless driver needs MAC80211 support
* Ivo van Doorn | 2008-02-23 20:50:34 [+0100]: Additionally, what part of the driver actually uses mac80211? I just browsed to the code, and it seems to work completely without using mac80211. Instead it seems to work directly by registering a net_device structure... CC drivers/net/ps3_gelic_wireless.o /home/bigeasy/git/linux-2.6/drivers/net/ps3_gelic_wireless.c: In function 'gelic_wl_setup_netdev_ops': /home/bigeasy/git/linux-2.6/drivers/net/ps3_gelic_wireless.c:2660: error: 'struct net_device' has no member named 'wireless_data' /home/bigeasy/git/linux-2.6/drivers/net/ps3_gelic_wireless.c:2661: error: 'struct net_device' has no member named 'wireless_handlers' make[3]: *** [drivers/net/ps3_gelic_wireless.o] Error 1 make[2]: *** [drivers/net] Error 2 make[1]: *** [drivers] Error 2 make[1]: *** Waiting for unfinished jobs make: *** [sub-make] Error 2 I add this to the patch desctiption and post a depends on patach Ivo Sebastian -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [PS3] gelic wireless driver needs MAC80211 support
On Saturday 23 February 2008, Sebastian Siewior wrote: * Sebastian Siewior | 2008-02-23 21:06:37 [+0100]: I add this to the patch desctiption and post a depends on patach ARGH, this was CONFIG_WIRELESS_EXT and not MAC80211. You would like to see a select or depend statement on that one? Other drivers do a select on WIRELESS_EXT, so selecting it would be fine. Ivo -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [PS3] gelic wireless driver needs MAC80211 support
On Saturday 23 February 2008, Sebastian Siewior wrote: * Ivo van Doorn | 2008-02-23 20:44:59 [+0100]: Is there any particular reason why this driver is in drivers/net instead of drivers/net/wireless (along with all other wireless drivers? My understanding is/was that the wireless device and the eth device are exposed by the hypervisor to the system and they share ressources. Ah ok, makes sense. :) Thanks. Ivo -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [NET] [PS3] gelic wireless driver needs WIRELESS_EXT support
| CC drivers/net/ps3_gelic_wireless.o | /home/bigeasy/git/linux-2.6/drivers/net/ps3_gelic_wireless.c: In function 'gelic_wl_setup_netdev_ops': | /home/bigeasy/git/linux-2.6/drivers/net/ps3_gelic_wireless.c:2660: error: 'struct net_device' has no member named 'wireless_data' | /home/bigeasy/git/linux-2.6/drivers/net/ps3_gelic_wireless.c:2661: error: 'struct net_device' has no member named 'wireless_handlers' | make[3]: *** [drivers/net/ps3_gelic_wireless.o] Error 1 | make[2]: *** [drivers/net] Error 2 | make[1]: *** [drivers] Error 2 | make[1]: *** Waiting for unfinished jobs | make: *** [sub-make] Error 2 Signed-off-by: Sebastian Siewior [EMAIL PROTECTED] --- drivers/net/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index f337800..e0a06e9 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -2363,6 +2363,7 @@ config GELIC_NET config GELIC_WIRELESS bool PS3 Wireless support depends on GELIC_NET + select WIRELESS_EXT help This option adds the support for the wireless feature of PS3. If you have the wireless-less model of PS3 or have no plan to -- 1.5.3.8 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [PS3] gelic wireless driver needs MAC80211 support
Sebastian Siewior wrote: so select it. Signed-off-by: Sebastian Siewior [EMAIL PROTECTED] --- drivers/net/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index f337800..a116056 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -2363,6 +2363,7 @@ config GELIC_NET config GELIC_WIRELESS bool PS3 Wireless support depends on GELIC_NET + select MAC80211 Given that this is straying clearly into wireless territory, I think the linux-wireless folks and John Linville (wireless maintainer) are appropriate patch targets. Jeff -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [PS3] gelic wireless driver needs MAC80211 support
* Jeff Garzik | 2008-02-23 15:26:07 [-0500]: Given that this is straying clearly into wireless territory, I think the linux-wireless folks and John Linville (wireless maintainer) are appropriate patch targets. Okey, I'm going to forward the pach. Jeff Sebastian -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/8]: uninline uninline
Is it possible to catch this automatically, like, by re-defining likely/unlikely to the raw form in specific file(s)? Sure it would be possible to define a IN_VDSO symbol in all vdso related files and then do that. Might be useful for other things too. vdso has some very specific requirements. -Andi -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG][AX25] spinlock lockup
Hello, I got a spinlock lockup using the latest Kernel 2.6.24.2 with recent patches from Jarek Poplawski applied. ppp_deflate nf_nat zlib_deflateBUG: unable to handle kernel NULL pointer dereference zlib_inflate nf_conntrack_ipv4 bsd_comp slhc ppp_async xt_state tun ppp_genericprinting eip: c02338c2 nf_conntrack bitrev ipt_REJECT*pde = iptable_filter crc32 iptable_mangle mkiss xt_MARK at virtual address 0004 ax25 ipv6Oops: 0002 [#1] SMP ipip crc16 tunnel4Modules linked in: iptable_nat ide_cd cdrom aic7xxx scsi_transport_spi parport_serial parport_pc parport i2c_piix4 netconsole genrtc Pid: 3032, comm: linuxnet Not tainted (2.6.24.2-dg8ngn-p02 #1) EIP: 0060:[c02338c2] EFLAGS: 00010092 CPU: 0 EIP is at skb_append+0x1b/0x30 EAX: 0292 EBX: c9318980 ECX: c0466a80 EDX: ESI: c9e085c0 EDI: f40846ac EBP: f40846b8 ESP: f72cbd04 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process linuxnet (pid: 3032, ti=f72ca000 task=f7d08030 task.ti=f72ca000) Stack: c9318980 c9e085c0 f4084600 f8a0e2a3 f4084600 0005 0010 BUG: spinlock lockup on CPU#1, bcm/12213, f40846b8 Pid: 12213, comm: bcm Tainted: G D 2.6.24.2-dg8ngn-p02 #1 [c01cb96f] _raw_spin_lock+0xbb/0xdc [c0299fdc] _spin_lock_irqsave+0x39/0x41 [c02339bf] skb_dequeue+0xf/0x3f [c02339bf] skb_dequeue+0xf/0x3f [f8a0c998] ax25_kick+0x14f/0x18c [ax25] [f8a10a26] ax25_sendmsg+0x35f/0x49a [ax25] [c01473d1] file_read_actor+0x7d/0xd5 [c0147c35] do_generic_mapping_read+0x1d5/0x3b2 [c0147354] file_read_actor+0x0/0xd5 [c022e404] sock_aio_write+0xbf/0xcb [c01494ba] generic_file_aio_read+0x161/0x19c [c01627bb] do_sync_write+0xc7/0x10a [c0130ea9] autoremove_wake_function+0x0/0x35 [c0162f48] vfs_write+0x9e/0x10c [c01634b0] sys_write+0x41/0x67 [c0103ea2] syscall_call+0x7/0xb === -- Jann Traschewski, Drosselstr.1, D-90513 Zirndorf, Germany Tel.: +49-911-696971, Mobile: +49-170-1045937, EMail: [EMAIL PROTECTED] Ham: DG8NGN / DB0VOX, http://www.qsl.net/db0fhn, ICQ UIN: 4130182 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3][BNX2]: More 5706S link down workaround.
From: Michael Chan [EMAIL PROTECTED] Date: Fri, 22 Feb 2008 11:49:38 -0800 [BNX2]: More 5706S link down workaround. The previous patches to workaround the 5706S on an HP blade were not sufficient. The link state still does not change properly in some cases. This patch adds polling to make it completely reliable. Signed-off-by: Michael Chan [EMAIL PROTECTED] Applied, thanks. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3][BNX2]: Disable parallel detect on an HP blade.
From: Michael Chan [EMAIL PROTECTED] Date: Fri, 22 Feb 2008 11:50:11 -0800 [BNX2]: Disable parallel detect on an HP blade. Because of some board issues, we need to disable parallel detect on an HP blade. Without this patch, the link state can become stuck when it goes into parallel detect mode. Signed-off-by: Michael Chan [EMAIL PROTECTED] Applied, thanks. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3][BNX2]: Update version to 1.7.4.
From: Michael Chan [EMAIL PROTECTED] Date: Fri, 22 Feb 2008 11:50:32 -0800 [BNX2]: Update version to 1.7.4. Signed-off-by: Michael Chan [EMAIL PROTECTED] Also applied, thanks a lot. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tg3: ethtool phys_id default (rev2)
From: Michael Chan [EMAIL PROTECTED] Date: Fri, 22 Feb 2008 11:16:42 -0800 On Fri, 2008-02-22 at 10:24 -0800, Stephen Hemminger wrote: When asked to blink LEDs the tg3 driver behaves when using: ethtool -p ethX The default value for data is zero, and other drivers interpret this as blink forever (or at least a really long time). The tg3 driver interprets this as blink once. All drivers should have the same behaviour. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] Acked-by: Michael Chan [EMAIL PROTECTED] Applied. We should do this across the board for bnx2, bnx2x, and niu as well. Agreed. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RTNL]: Validate hardware and broadcast address attribute for RTM_NEWLINK
From: Patrick McHardy [EMAIL PROTECTED] Date: Fri, 22 Feb 2008 14:33:26 +0100 Thomas Graf wrote: The reason I did it this way is to keep validate_linkmsg() generic and make it possible to put validation code which must also apply to new links (dev==NULL) into that function. OK, thanks for the explanation. Patch applied, thanks. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][NEIGH]: Fix race between neighbor lookup and table's hash_rnd update.
From: Pavel Emelyanov [EMAIL PROTECTED] Date: Fri, 22 Feb 2008 12:37:03 +0300 The neigh_hash_grow() may update the tbl-hash_rnd value, which is used in all tbl-hash callbacks to calculate the hashval. Two lookup routines may race with this, since they call the -hash callback without the tbl-lock held. Since the hash_rnd is changed with this lock write-locked moving the calls to -hash under this lock read-locked closes this gap. Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED] Applied, thanks. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sungem triggers NAPI warning
From: Benjamin Herrenschmidt [EMAIL PROTECTED] Date: Fri, 22 Feb 2008 09:50:27 +1100 I still think the change is obviously correct, so I'll give a second close look at the code and produce a patch. Patch coming soon? :) -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix multicast on VLAN interfaces
From: Phil Oester [EMAIL PROTECTED] Date: Thu, 21 Feb 2008 14:05:42 -0800 diff --git a/net/core/dev.c b/net/core/dev.c index 908f07c..999af2e 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -2905,6 +2905,7 @@ int __dev_addr_add(struct dev_addr_list **list, int *count, return -ENOMEM; memcpy(da-da_addr, addr, alen); da-da_addrlen = alen; + da-da_synced = 0; da-da_users = 1; da-da_gusers = glbl ? 1 : 0; da-next = *list; da is kzalloc()'d, how can da-da_synced not be zero? -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel BUG at net/core/skbuff.c:95!
From: Jim Westfall [EMAIL PROTECTED] Date: Thu, 21 Feb 2008 11:13:52 -0800 2) Second, skb_realloc_headroom() is called on 'skb' with a second argument of 'dsize'. This suggestion escapes me. The skb_put() call in the above code would increase skb-tail. Wont skb_realloc_headroom() create additional space between skb-head and skb-data when we really want it between skb-tail and skb-end? My bad, you need to increase the tailroom not the headroom. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New sparse warning in net/mac80211/debugfs_sta.c
From: Patrick McHardy [EMAIL PROTECTED] Date: Thu, 21 Feb 2008 19:00:03 +0100 And adds back the overhead of two completely unnecessary function calls to the VLAN fastpath. How about just stopping this idiocy and reverting the appropriate patches to bring back MAC_FMT and use it where appropriate? Agreed, I'll do that. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IPv6 Add more initializations of the new nl_info.nl_net field
From: [EMAIL PROTECTED] Date: Thu, 21 Feb 2008 17:51:50 +0100 Add more missing initializations of the new nl_info.nl_net field in IPv6 stack. This field will be used when network namespaces are fully supported. Signed-off-by: Benjamin Thery [EMAIL PROTECTED] Initializations to zero are not necessary nor usually done in these kinds of cases. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND] libertas: Remove unused exports
Any chance of getting this applied? It seems the build is still
broken on ia64 at least due to the export of static functions.
---
The libertas driver exports a number of symbols with no in-tree
users; remove these unused exports. lbs_reset_device() is completely
unused, with no callers at all, so remove the function completely.
A couple of these unused exported symbols are static, which causes the
following build error on ia64 with gcc 4.2.3:
drivers/net/wireless/libertas/main.c:1375: error: __ksymtab_lbs_remove_mesh
causes a section type conflict
drivers/net/wireless/libertas/main.c:1354: error: __ksymtab_lbs_add_mesh
causes a section type conflict
This patch fixes this problem. I don't have hardware, so this is not
run-tested, but I tested the build with
CONFIG_LIBERTAS=y
CONFIG_LIBERTAS_USB=m
CONFIG_LIBERTAS_CS=m
CONFIG_LIBERTAS_SDIO=m
and there were no problems with undefined symbols.
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
---
diff --git a/drivers/net/wireless/libertas/cmd.c
b/drivers/net/wireless/libertas/cmd.c
index eab0203..b3c1acb 100644
--- a/drivers/net/wireless/libertas/cmd.c
+++ b/drivers/net/wireless/libertas/cmd.c
@@ -1040,7 +1040,6 @@ int lbs_mesh_access(struct lbs_private *priv, uint16_t
cmd_action,
lbs_deb_leave(LBS_DEB_CMD);
return ret;
}
-EXPORT_SYMBOL_GPL(lbs_mesh_access);
int lbs_mesh_config(struct lbs_private *priv, uint16_t enable, uint16_t chan)
{
@@ -1576,7 +1575,6 @@ done:
lbs_deb_leave_args(LBS_DEB_HOST, ret %d, ret);
return ret;
}
-EXPORT_SYMBOL_GPL(lbs_prepare_and_send_command);
/**
* @brief This function allocates the command buffer and link
diff --git a/drivers/net/wireless/libertas/decl.h
b/drivers/net/wireless/libertas/decl.h
index aaacd9b..4e22341 100644
--- a/drivers/net/wireless/libertas/decl.h
+++ b/drivers/net/wireless/libertas/decl.h
@@ -69,7 +69,6 @@ struct lbs_private *lbs_add_card(void *card, struct device
*dmdev);
int lbs_remove_card(struct lbs_private *priv);
int lbs_start_card(struct lbs_private *priv);
int lbs_stop_card(struct lbs_private *priv);
-int lbs_reset_device(struct lbs_private *priv);
void lbs_host_to_card_done(struct lbs_private *priv);
int lbs_update_channel(struct lbs_private *priv);
diff --git a/drivers/net/wireless/libertas/main.c
b/drivers/net/wireless/libertas/main.c
index 84fb49c..1eaf6af 100644
--- a/drivers/net/wireless/libertas/main.c
+++ b/drivers/net/wireless/libertas/main.c
@@ -1351,8 +1350,6 @@ done:
lbs_deb_leave_args(LBS_DEB_MESH, ret %d, ret);
return ret;
}
-EXPORT_SYMBOL_GPL(lbs_add_mesh);
-
static void lbs_remove_mesh(struct lbs_private *priv)
{
@@ -1372,7 +1369,6 @@ static void lbs_remove_mesh(struct lbs_private *priv)
free_netdev(mesh_dev);
lbs_deb_leave(LBS_DEB_MESH);
}
-EXPORT_SYMBOL_GPL(lbs_remove_mesh);
/**
* @brief This function finds the CFP in
@@ -1458,20 +1454,6 @@ void lbs_interrupt(struct lbs_private *priv)
}
EXPORT_SYMBOL_GPL(lbs_interrupt);
-int lbs_reset_device(struct lbs_private *priv)
-{
- int ret;
-
- lbs_deb_enter(LBS_DEB_MAIN);
- ret = lbs_prepare_and_send_command(priv, CMD_802_11_RESET,
- CMD_ACT_HALT, 0, 0, NULL);
- msleep_interruptible(10);
-
- lbs_deb_leave_args(LBS_DEB_MAIN, ret %d, ret);
- return ret;
-}
-EXPORT_SYMBOL_GPL(lbs_reset_device);
-
static int __init lbs_init_module(void)
{
lbs_deb_enter(LBS_DEB_MAIN);
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Don't limit the number of tunnels with generic name explicitly.
From: Pavel Emelyanov [EMAIL PROTECTED] Date: Thu, 21 Feb 2008 15:38:16 +0300 Changelog: Use the added dev_alloc_name() call to create tunnel device name, rather than iterate in a hand-made loop with an artificial limit. Thanks Patrick for noticing this. Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED] Applied, but I had to rework this in two places that didn't apply cleanly. The ip_gre.c and ipip.c changes remove a failed label but that can't be done in the current tree as there are other existing references. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [NETFILTER]: fix ebtable targets return
From: Patrick McHardy [EMAIL PROTECTED] Date: Thu, 21 Feb 2008 11:50:07 +0100 Good catch indeed, thanks. Signed-off-by: Patrick McHardy [EMAIL PROTECTED] Applied, thanks. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sungem triggers NAPI warning
On Sat, 2008-02-23 at 19:58 -0800, David Miller wrote: From: Benjamin Herrenschmidt [EMAIL PROTECTED] Date: Fri, 22 Feb 2008 09:50:27 +1100 I still think the change is obviously correct, so I'll give a second close look at the code and produce a patch. Patch coming soon? :) Yup, when I get a chance to double check and test instead of slacking off at the pub, at home, or out and about with the kid :-) Heh, it's the week-end here ! Ben. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.25 2/4]S2io: Multiqueue network device support - FIFO selection based on L4 ports
David Miller wrote: From: Patrick McHardy [EMAIL PROTECTED] Date: Thu, 21 Feb 2008 00:08:52 +0100 Ramkrishna Vepa wrote: Sreenivasa Honnur wrote: - Resubmit #2 - Transmit fifo selection based on TCP/UDP ports. - Added tx_steering_type loadable parameter for transmit fifo selection. 0x0 NO_STEERING: Default FIFO is selected. 0x1 TX_PRIORITY_STEERING: FIFO is selected based on skb-priority. 0x2 TX_DEFAULT_STEERING: FIFO is selected based on L4 Ports. Why duplicate the generic multiqueue classification? [Ram] Could you be more specific? The generic multiqueue support classifies packets by setting skb-queue_mapping using qdisc classifiers, which is more flexible and avoids using module parameters. But it doesn't do what these multiqueue TX queue hardware devices want. These devices don't want packet scheduler classification, they want load balancing using some key (current cpu number, hashing on the packet headers, etc.) And that's not what our packet scheduler classifiers do or should do. We don't want to have to tell people you have to run 'tc' magic foo to use all of the TX queues on your network card. That's completely unreasonable and stupid. We have to resolve this somehow, and there have been many discussions about this a month or so ago. So where does that leave this patch? :) Jeff -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2]via-rhine.c: Use-register-offset-definition-for-WOLcgClr
Laura Garcia wrote: Use register offset definition for WOLcgClr. This patch does not change the driver behaviour. Signed-off-by: Laura Garcia Liebana [EMAIL PROTECTED] modified: drivers/net/via-rhine.c --- drivers/net/via-rhine.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) applied, after making the following manual edits: - removed modified: ... line, that is redundant to the diffstat, and being before the --- separator, it is included in the changelog by automated tools - removed all the silly dashes from the subject line. we want something readable, not a filename. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sky2: fix LED management
Stephen Hemminger wrote: Fix problems in LED management, so ethtool -p works correctly on Yukon-EC and other chips. The driver was incorrectly setting the PHY LED overide bits. Moral: read the spec sheet, not the vendor driver. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] --- drivers/net/sky2.c | 99 + drivers/net/sky2.h | 21 +-- 2 files changed, 44 insertions(+), 76 deletions(-) applied -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/7] e1000e: remove unused read value in ASPM disable code.
Auke Kok wrote:
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000e/netdev.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index 7824bc2..fc5c63f 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -3490,7 +3490,6 @@ static int e1000_suspend(struct pci_dev *pdev,
pm_message_t state)
static void e1000e_disable_l1aspm(struct pci_dev *pdev)
{
int pos;
- u32 cap;
u16 val;
/*
@@ -3505,7 +3504,6 @@ static void e1000e_disable_l1aspm(struct pci_dev *pdev)
* active.
*/
pos = pci_find_capability(pdev, PCI_CAP_ID_EXP);
- pci_read_config_dword(pdev, pos + PCI_EXP_LNKCAP, cap);
pci_read_config_word(pdev, pos + PCI_EXP_LNKCTL, val);
if (val 0x2) {
applied 1-7
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tg3: ethtool phys_id default (rev2)
On Sat, 2008-02-23 at 19:52 -0800, David Miller wrote: From: Michael Chan [EMAIL PROTECTED] Date: Fri, 22 Feb 2008 11:16:42 -0800 On Fri, 2008-02-22 at 10:24 -0800, Stephen Hemminger wrote: When asked to blink LEDs the tg3 driver behaves when using: ethtool -p ethX The default value for data is zero, and other drivers interpret this as blink forever (or at least a really long time). The tg3 driver interprets this as blink once. All drivers should have the same behaviour. ... We should do this across the board for bnx2, bnx2x, and niu as well. Agreed. Doesn't this mean that ethtool -p will hold the RTNL lock forever? Is this a good idea? For example on the Red Hat machine I have here if you do: ethtool -p eth2 10 reboot Various things the shutdown scripts try to do will fail because of the held RTNL lock. in the end the script dies and the machine does not reboot. Eliezer -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git patches] net driver fixes
David Miller wrote: Jeff, I really don't want to pull that tree in. Please trust me as your upstream to handle merging issues, as needed. I trust you... Otherwise I wouldn't have volunteered to move my upstream from Linus to you :) My main issues/motivations were: * quite simply, just force of habit: I'm used to basing off of a recent Linus tree, to guarantee buildboot testing against the latest. * worry about testing against a too-old tree, where non-networking fixes may have a relevant impact on my to-be-pushed netdrvr fixes. But in this case it's fair to say there are no such issues, and it was mainly just out of habit. So (as you saw in last email)... rebased and resend. Jeff -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.25 0/8][BNX2X]: bugfixes and updates
This patch-set updates several sections of the bnx2x driver. It is not appropriate to be adding features at this time to the 2.6.25 tree. Please wait for the opportunity to submit 2.6.26 bound patches for new features. I encourage you to split out just the bug fixes from this series and resubmit, thank you. I will resubmit the bug fixes only. Can I keep the spelling fixes in? Thanks Eliezer -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git patches] net driver fixes
From: Jeff Garzik [EMAIL PROTECTED] Date: Sun, 24 Feb 2008 00:48:54 -0500 I trust you... Otherwise I wouldn't have volunteered to move my upstream from Linus to you :) ... So (as you saw in last email)... rebased and resend. Thanks :) -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.25 0/8][BNX2X]: bugfixes and updates
From: Eliezer Tamir [EMAIL PROTECTED] Date: Sun, 24 Feb 2008 07:50:31 +0200 I will resubmit the bug fixes only. Can I keep the spelling fixes in? Sure. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix multicast on VLAN interfaces
On Sat, Feb 23, 2008 at 08:00:18PM -0800, David Miller wrote: da is kzalloc()'d, how can da-da_synced not be zero? Because it was originally kmalloc'd, not kzalloc'd. It was fixed about 2 days prior to my patch submission, here: http://marc.info/?l=linux-netdevm=120343348811767w=2 which I missed. Phil -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/28] netvm: network reserve infrastructure
On Wed, Feb 20, 2008 at 9:46 AM, Peter Zijlstra [EMAIL PROTECTED] wrote:
Provide the basic infrastructure to reserve and charge/account network memory.
...
Index: linux-2.6/net/core/sock.c
===
--- linux-2.6.orig/net/core/sock.c
+++ linux-2.6/net/core/sock.c
...
+/**
+ * sk_adjust_memalloc - adjust the global memalloc reserve for critical
RX
+ * @socks: number of new %SOCK_MEMALLOC sockets
+ * @tx_resserve_pages: number of pages to (un)reserve for TX
+ *
+ * This function adjusts the memalloc reserve based on system demand.
+ * The RX reserve is a limit, and only added once, not for each socket.
+ *
+ * NOTE:
+ *@tx_reserve_pages is an upper-bound of memory used for TX hence
+ *we need not account the pages like we do for RX pages.
+ */
+int sk_adjust_memalloc(int socks, long tx_reserve_pages)
+{
+ int nr_socks;
+ int err;
+
+ err = mem_reserve_pages_add(net_tx_pages, tx_reserve_pages);
+ if (err)
+ return err;
+
+ nr_socks = atomic_read(memalloc_socks);
+ if (!nr_socks socks 0)
+ err = mem_reserve_connect(net_reserve, mem_reserve_root);
+ nr_socks = atomic_add_return(socks, memalloc_socks);
+ if (!nr_socks socks)
+ err = mem_reserve_disconnect(net_reserve);
+
+ if (err)
+ mem_reserve_pages_add(net_tx_pages, -tx_reserve_pages);
+
+ return err;
+}
EXPORT_SYMBOL_GPL(sk_adjust_memalloc); is needed here to build sunrpc
as a module.
Mike
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
