Re: sockets affected by IPsec always block (2.6.23)
From: Stefan Rompf [EMAIL PROTECTED] Date: Thu, 6 Dec 2007 09:49:01 +0100 If the connection cannot be established immediately and O_NONBLOCK is set for the file descriptor for the socket, connect() shall fail and set errno to [EINPROGRESS], but the connection request shall not be aborted, and the connection shall be established asynchronously. I think the words shall fail and immediately are quite clear. They are, but the context in which they apply is vague. I can equally generate examples where the non-blocking behavior you are a proponent of would break non-blocking UDP apps during a sendmsg() call when we hit IPSEC resolution. Yet similar language on blocking semantics exists for sendmsg() in the standards. The world is shades of gray, implying anything else is foolhardy and that's how I'm handling this. Well, the only reason this doesn't break on a daily basis is because the code isn't in the kernel that long and not many people run applications on an IPSEC gateway. This will change if kernel based IPSEC is used for roadwarrior connections or dnssec based anonymous IPSEC someday. Trust me, you will revert this misbehaviour in -stable then. I use IPSEC every single day in this fashion, and I haven't. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sockets affected by IPsec always block (2.6.23)
From: Stefan Rompf [EMAIL PROTECTED] Date: Thu, 6 Dec 2007 11:56:48 +0100 Am Donnerstag, 6. Dezember 2007 09:53 schrieb David Miller: I think the words shall fail and immediately are quite clear. They are, but the context in which they apply is vague. socket is connection-mode = SOCK_STREAM I meant whether immediately mean in reference to socket state or includes auxiliary things like route lookups. When you do a non-blocking write on a socket, things like memory allocations can block, potentially for a long time. It is an example where there are definite boundaries to where the non-blocking'ness applies. And therefore it is not so cut and dry and you present this issue. The reason why I'm pushing this issue another time is that I know quite a bit about system level application development. A very typical design pattern for non-naive single or multi threaded programs is that they set all communication sockets to be nonblocking and use a select()/epoll() based loop to dispatch IO. This often includes initiating a TCP connect() and asynchronously waiting for it to finish or fail from the main loop. The dangerous situation here is that in 99% of all cases things will just work because the phase 2 SA exists. In 0.8%, the SA will be established in 1 sec. However, in the rest of time the server application that you have considered to be stable will end up sleeping with all threads in a connect() call that is supposed to return immediatly. And that connect() call can hang for a long time due to any memory allocation done in the connect() path. You are not avoiding blocking by setting O_NONBLOCK on the socket, it is quite foolhardy to think that it does so unilaterally. And that's why this is a grey area. Why is waiting for memory allocation on a O_NONBLOCK socket OK but waiting for IPSEC route resolution is not? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch] net/xfrm/xfrm_policy.c: Some small improvements
From: WANG Cong [EMAIL PROTECTED] Date: Thu, 6 Dec 2007 19:01:23 +0800 This patch contains the following changes. - Use 'bool' instead of 'int' for booleans. - Use 'size_t' instead of 'int' for 'sizeof' return value. - Some style fixes. Cc: Herbert Xu [EMAIL PROTECTED] Cc: David Miller [EMAIL PROTECTED] Signed-off-by: WANG Cong [EMAIL PROTECTED] Normally I would let a patch like this sit in my mailbox for a week and then delete it. But this time I'll just let you know up front that I don't see much value in this patch. It is not a clear improvement to replace int's with bool's in my mind and the other changes are just whitespace changes. And thus I can delete the patch from my mailbox immediately :-) Sorry. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sockets affected by IPsec always block (2.6.23)
From: Stefan Rompf [EMAIL PROTECTED] Date: Thu, 6 Dec 2007 12:35:05 +0100 Because you just will put enough RAM modules into you server when setting up a scalable system. This suggestion is avoiding the important semantic issue, and won't lead to a real discussion of the core problem. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 27/47] Update CRISv10 rescue head.s
From: Jesper Nilsson [EMAIL PROTECTED] Date: Fri, 30 Nov 2007 16:13:29 +0100 ^^^ Any particular reason for the 6 day long delay in these mails going out or is your clock simply wrong? As co-postmaster, I am noticing that your postings are bouncing at a lot of sites because of this. There are several that impose things like 96-hour-old limits on date fields in received mails. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sockets affected by IPsec always block (2.6.23)
From: Stefan Rompf [EMAIL PROTECTED] Date: Thu, 6 Dec 2007 13:30:20 +0100 IMHO this is what developers expect, and is also consistent with the fact that POSIX does not define O_NONBLOCK behaviour for local files. You keep ignoring the fact that, as Herbert and I discussed, not blocking for IPSEC resolution will make some connect() cases fail that would otherwise not fail. There are two sides to this issue, and we need to consider them both. Long term a resolution-packet-queue provides a solution that handles both angles correctly, but we don't have that code yet. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch] net/xfrm/xfrm_policy.c: Some small improvements
From: Richard Knutsson [EMAIL PROTECTED] Date: Thu, 06 Dec 2007 15:37:46 +0100 David Miller wrote: But this time I'll just let you know up front that I don't see much value in this patch. It is not a clear improvement to replace int's with bool's in my mind and the other changes are just whitespace changes. Is it not an improvement to distinct booleans from actual values? Do you use integers for ASCII characters too? It can also avoid some potential bugs like the 'if (i == TRUE)'... What is wrong with 'size_t' (since it is unsigned, compared to (some) 'int')? When you say int found; is there any doubt in your mind that this integer is going to hold a 1 or a 0 depending upon whether we found something? That's the problem I have with these kinds of patches, they do not increase clarity, it's just pure mindless edits. In new code, fine, use booleans if you want. I would even accept that it helps to change to boolean for arguments to functions that are global in scope. But not for function local variables in cases like this. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sockets affected by IPsec always block (2.6.23)
From: Stefan Rompf [EMAIL PROTECTED] Date: Thu, 6 Dec 2007 15:31:53 +0100 as far as I've understood Herbert's patch, at least TCP connect can be fixed so that non blocking connect() will neither fail nor block, but just use the first or second retransmission of the SYN packet to complete the handshake after IPSEC is up. If IPSEC takes a long time to resolve, and we don't block, the connect() can hard fail (we will just keep dropping the outgoing SYN packet send attempts, eventually hitting the retry limit) in cases where if we did block it would not fail (because we wouldn't send the first SYN until IPSEC resolved). -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New Address Family: Inter Process Networking (IPN)
From: Chris Friesen [EMAIL PROTECTED] Date: Thu, 06 Dec 2007 14:36:54 -0600 One problem we ran into was that there are only 32 multicast groups per netlink protocol family. I'm pretty sure we've removed this limitation. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New Address Family: Inter Process Networking (IPN)
From: Chris Friesen [EMAIL PROTECTED] Date: Thu, 06 Dec 2007 22:21:39 -0600 David Miller wrote: From: Chris Friesen [EMAIL PROTECTED] Date: Thu, 06 Dec 2007 14:36:54 -0600 One problem we ran into was that there are only 32 multicast groups per netlink protocol family. I'm pretty sure we've removed this limitation. As of 2.6.23 nl_groups is a 32-bit bitmask with one bit per group. Also, it appears that only root is allowed to use multicast netlink. The kernel supports much more than 32 groups, see nlk-groups which is a bitmap which can be sized to arbitrary sizes. nlk-nl_groups is for backwards compatability only. netlink_change_ngroups() does the bitmap resizing when necessary. The root multicast listening restriction can be relaxed in some circumstances, whatever is needed to fill your needs. Stop making excuses, with minor adjustments we have the facilities to meet your needs. There is no need for yet-another-protocol to do what you're trying to do, we already have too much duplicated functionality. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 17/20] net/xfrm/xfrm_state.c: use LIST_HEAD instead of LIST_HEAD_INIT
From: Denis Cheng [EMAIL PROTECTED] Date: Fri, 7 Dec 2007 00:09:43 +0800 single list_head variable initialized with LIST_HEAD_INIT could almost always can be replaced with LIST_HEAD declaration, this shrinks the code and looks better. Signed-off-by: Denis Cheng [EMAIL PROTECTED] Applied. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 16/20] net/x25/: use LIST_HEAD instead of LIST_HEAD_INIT
From: Denis Cheng [EMAIL PROTECTED] Date: Fri, 7 Dec 2007 00:07:19 +0800 single list_head variable initialized with LIST_HEAD_INIT could almost always can be replaced with LIST_HEAD declaration, this shrinks the code and looks better. Signed-off-by: Denis Cheng [EMAIL PROTECTED] Applied. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 14/20] net/ipv4/cipso_ipv4.c: use LIST_HEAD instead of LIST_HEAD_INIT
From: Denis Cheng [EMAIL PROTECTED] Date: Fri, 7 Dec 2007 00:04:36 +0800 single list_head variable initialized with LIST_HEAD_INIT could almost always can be replaced with LIST_HEAD declaration, this shrinks the code and looks better. Signed-off-by: Denis Cheng [EMAIL PROTECTED] Applied. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 15/20] net/lapb/lapb_iface.c: use LIST_HEAD instead of LIST_HEAD_INIT
From: Denis Cheng [EMAIL PROTECTED] Date: Fri, 7 Dec 2007 00:07:18 +0800 single list_head variable initialized with LIST_HEAD_INIT could almost always can be replaced with LIST_HEAD declaration, this shrinks the code and looks better. Signed-off-by: Denis Cheng [EMAIL PROTECTED] Applied. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 13/20] net/core/dev.c: use LIST_HEAD instead of LIST_HEAD_INIT
From: Denis Cheng [EMAIL PROTECTED] Date: Fri, 7 Dec 2007 00:01:26 +0800 single list_head variable initialized with LIST_HEAD_INIT could almost always can be replaced with LIST_HEAD declaration, this shrinks the code and looks better. Signed-off-by: Denis Cheng [EMAIL PROTECTED] Applied. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 20/20] net/iucv/iucv.c: use LIST_HEAD instead of LIST_HEAD_INIT
From: Denis Cheng [EMAIL PROTECTED] Date: Fri, 7 Dec 2007 00:13:25 +0800 these three list_head are all local variables, but can also use LIST_HEAD. Signed-off-by: Denis Cheng [EMAIL PROTECTED] Applied. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI breakage on non-cache coherent architectures
From: Benjamin Herrenschmidt [EMAIL PROTECTED] Date: Tue, 20 Nov 2007 06:51:14 +1100 On Mon, 2007-11-19 at 00:38 -0800, David Miller wrote: From: Benjamin Herrenschmidt [EMAIL PROTECTED] Date: Mon, 19 Nov 2007 16:35:23 +1100 You could make a dma_cacheline_aligned and use that. It seems pretty reasonable. I was thinking about that. What archs would need it ? arm, mips, what else ? The sparc32 port would need it too. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 19/26] USB: mutual exclusion for EHCI init and port resets
From: David Brownell [EMAIL PROTECTED] Date: Mon, 19 Nov 2007 11:59:55 -0800 This addition certainly won't hurt. Did we ever get any feedback as to whether it actually helped? ISTR that davem refused to try it, after reporting an intermittent failure on the original patch (which only addresses one end of that hardware race). So, no ... but given we know that closing only one side of the race isn't quite enough, I think we need it anyway. I think we should put all these changes in because at a minimum it's a step in the right direction even if it doesn't close the hole %100. So please let's merge the mutex and the msleep() change in ASAP, thanks. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[EMAIL PROTECTED] created...
Because sourceforge just farted another bounce at me because someone CC:'d the sourceforge linux-usb-devel list on a thread I was a part of, I've created: [EMAIL PROTECTED] so we don't need to have a subscriber-only-posting mailing list for USB stuff. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [EMAIL PROTECTED] created...
From: Greg KH [EMAIL PROTECTED] Date: Mon, 19 Nov 2007 14:54:55 -0800 Woah, the [EMAIL PROTECTED] list is NOT a subscriber-only list at all. It's wide open with a bunch of mailman rule filter to try to handle the worst of the spam. It does complain if you try to add too many cc:s to it, but that's it, an admin (me or Stephen) will usually get around to aproving them within 24 hours. Ok, I stand corrected. But, I have no objection to moving to vger if you want to handle the admin load. If so, should I send you a list of addresses that were on the sf.net list so that people can be migrated? We don't do migrations like that, so that people: 1) Learn how to subscribe, and thus how to unsubscribe. 2) Don't get upset that they were added to a mailing list site they may not want to be one. So I'd ask that you send an announcement out to the old list, and during a transition period you can subscribe the old list onto the vger one. Neil B. did something similar recently for linux-nfs, perhaps you can ask him how he handled it. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI breakage on non-cache coherent architectures
From: Benjamin Herrenschmidt [EMAIL PROTECTED]
Date: Tue, 20 Nov 2007 11:34:24 +1100
Do you still think we should introduce this __dma_cacheline_aligned ? Do
you see other cases of drivers where it would be useful ? It tend to
agree with your earlier statement that drivers doing that are broken and
should be using a separate allocator for DMA'ble objects (in fact, on
non-cache coherent archs, kmalloc is just fine).
I don't care either way.
If we say that the DMA api works on DMA cacheline boundaries
(and in reality it does) we do need to either:
1) Require that entire buffers are commited by call sites,
and thus embedding DMA'd within non-DMA stuff isn't allowed
2) Add the __dma_cacheline_aligned tag.
But note that with #2 it could get quite ugly because the
alignment and size both have a minimum that needs to be
enforced, not just the alignment alone. So either:
struct foo {
unsigned int other_unrelated_stuff;
struct object dma_thing __dma_cacheline_aligned;
unsigned int more_nondma_stuff __dma_cacheline_aligned;
};
or:
struct foo {
unsigned int other_unrelated_stuff;
union {
struct object dma_thing __dma_cacheline_aligned;
char __pad[(sizeof(object) + DMA_CACHELINE_SIZE
~DMA_CACHELINE_SIZE)];
} u;
unsigned int more_nondma_stuff __dma_cacheline_aligned;
};
I hope you see what I'm trying to say.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [perfmon] Re: [perfmon2] perfmon2 merge news
From: Stephane Eranian [EMAIL PROTECTED] Date: Mon, 19 Nov 2007 12:53:30 -0800 In anycase, I would be happy to integrate your sparc64 patches. I sent these to Philip Mucci late last night, but in the meantime I finished implementing breakpoint support as well for pfmon. Let me clean up my diffs and I'll send it all out to you in a few hours. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI breakage on non-cache coherent architectures
From: Benjamin Herrenschmidt [EMAIL PROTECTED] Date: Tue, 20 Nov 2007 11:55:01 +1100 BTW. What is the status nowadays with skb's ? Good question. Some drivers are problematic (or were) because they put DMA descriptor chaining information at the head of the buffer, but those have been fixed either to use alternate descriptor ring facilities or make the proper DMA sync calls. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [perfmon] Re: [perfmon2] perfmon2 merge news
From: Stephane Eranian [EMAIL PROTECTED] Date: Mon, 19 Nov 2007 14:48:46 -0800 Looks like we will have to use bytes (u8) instead. This may have some performance impact as well. Several bitmaps are used in the context/interrupt routines. Even with u8, there is still a problem with the bitmap*() macros. Now, only a small subset of the bitmap() macros are used, so it may be okay to duplicate them for u8. I think it would be fine to just create a set of bitop interfaces that operate on u32 objects instead of unsigned long. Currently perfmon2 does not need the atomic variants at all, and those could thus be provided entirely under include/asm-generic/bitops/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rfc 00/45] [RFC] CPU ops and a rework of per cpu data handling on x86_64
From: [EMAIL PROTECTED]
Date: Mon, 19 Nov 2007 17:11:32 -0800
Before:
mov%gs:0x8,%rdx Get smp_processor_id
movtableoffset,%rax Get table base
incq varoffset(%rax,%rdx,1) Perform the operation with a complex lookup
adding the var offset
An interrupt or a reschedule action can move the execution thread to another
processor if interrupt or preempt is not disabled. Then the variable of
the wrong processor may be updated in a racy way.
After:
incq %gs:varoffset(%rip)
Single instruction that is safe from interrupts or moving of the execution
thread. It will reliably operate on the current processors data area.
Other platforms can also perform address relocation plus atomic ops on
a memory location. Exploiting of the atomicity of instructions vs interrupts
is therefore possible and will reduce the cpu op processing overhead.
F.e on IA64 we have per cpu virtual mapping of the per cpu area. If
we add an offset to the per cpu area variable address then we can guarantee
that we always hit the per cpu areas local to a processor.
Other platforms (SPARC?) have registers that can be used to form addresses.
If the cpu area address is in one of those then atomic per cpu modifications
can be generated for those platforms in the same way.
Although we have a per-cpu area base in a fixed global register
for addressing, the above isn't beneficial on sparc64 because
the atomic is much slower than doing a:
local_irq_disable();
nonatomic_percpu_memory_op();
local_irq_enable();
local_irq_{disable,enable}() together is about 18 cycles.
Just the cmpxchg() part of the atomic sequence is at least
32 cycles and requires a loop:
while (1) {
x = ld();
if (cmpxchg(x, op(x)))
break;
}
which bloats up the atomic version even more.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [EMAIL PROTECTED] created...
From: Kay Sievers [EMAIL PROTECTED] Date: Tue, 20 Nov 2007 02:33:43 +0100 Sounds all good. If that migration works well, please let us do the same for hotplug. Tell me what you'd like the list at vger to be named and I can create it now. THanks. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rfc 00/45] [RFC] CPU ops and a rework of per cpu data handling on x86_64
From: Christoph Lameter [EMAIL PROTECTED] Date: Mon, 19 Nov 2007 17:59:33 -0800 (PST) In that case the generic fallbacks can just provide what you already have. I understand, I was just letting you know why we probably won't take advantage of this new stuff :-) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rfc 37/45] x86_64: Support for fast per cpu operations
From: H. Peter Anvin [EMAIL PROTECTED] Date: Mon, 19 Nov 2007 18:00:23 -0800 Christoph Lameter wrote: Support fast cpu ops in x86_64 by providing a series of functions that generate the proper instructions. Define CONFIG_FAST_CPU_OPS so that core code can exploit the availability of fast per cpu operations. Signed-off-by: Christoph Lameter [EMAIL PROTECTED] There was, at some point, discussion about using the gcc TLS mechanism, which should permit even better code to be generated. Unfortunately, it would require gcc to be able to reference %gs instead of %fs (and vice versa for i386), which I don't think is available in anything except maybe the most cutting-edge version of gcc. You can't use __thread because GCC will cache __thread computed addresses across context switches and cpu changes. It's been tried before on powerpc, it doesn't work. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [EMAIL PROTECTED] created...
From: Greg KH [EMAIL PROTECTED] Date: Mon, 19 Nov 2007 18:29:15 -0800 [EMAIL PROTECTED] would be great to have. Created, enjoy. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [EMAIL PROTECTED] created...
From: Greg KH [EMAIL PROTECTED] Date: Mon, 19 Nov 2007 19:12:32 -0800 Actually, if we are going to stick with this new list, can we just call it [EMAIL PROTECTED] instead of the -devel stuff? Done. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rfc 00/45] [RFC] CPU ops and a rework of per cpu data handling on x86_64
From: Andi Kleen [EMAIL PROTECTED] Date: Tue, 20 Nov 2007 04:25:34 +0100 Although we have a per-cpu area base in a fixed global register for addressing, the above isn't beneficial on sparc64 because the atomic is much slower than doing a: local_irq_disable(); nonatomic_percpu_memory_op(); local_irq_enable(); Again might be pointing out the obvious, but you need of course save_flags()/restore_flags(), not disable/enable(). Right, but the cost is the same for that on sparc64 unlike x86 et al. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [EMAIL PROTECTED] created...
From: David Brownell [EMAIL PROTECTED] Date: Mon, 19 Nov 2007 19:26:02 -0800 On Monday 19 November 2007, David Miller wrote: From: Greg KH [EMAIL PROTECTED] Date: Mon, 19 Nov 2007 19:12:32 -0800 Actually, if we are going to stick with this new list, can we just call it [EMAIL PROTECTED] instead of the -devel stuff? Done. Subscribe/unsubscribe ... how? Just like any other list at vger.kernel.org: http://vger.kernel.org/majordomo-info.html or the quickeasy version: bash$ echo subscribe linux-usb | mail [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: build #337 failed for 2.6.24-rc1-gb1d08ac In function `usbnet_set_settings':
From: Adrian Bunk [EMAIL PROTECTED] Date: Thu, 8 Nov 2007 04:30:10 +0100 @davem: Please look at net/ipv4/arp.c:arp_process() Am I right that CONFIG_NET_ETHERNET=n and CONFIG_NETDEV_1000=y or CONFIG_NETDEV_1=y will not be handled correctly there? And the best solution is to nuke all #ifdef's in this function and make the code unconditionally available? I think removing those specific ifdefs in arp_process() is the best option, yes. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ipconfig.c : implement DHCP Class-identifier
From: Francois Romieu [EMAIL PROTECTED]
Date: Wed, 14 Nov 2007 23:11:19 +0100
Rainer Jochem [EMAIL PROTECTED] :
[...]
--- net/ipv4/ipconfig.c.orig2007-11-14 09:16:15.800566536 +0100
+++ net/ipv4/ipconfig.c 2007-11-14 10:34:22.471219274 +0100
@@ -139,6 +139,8 @@ __be32 ic_servaddr = NONE; /* Boot serve
__be32 root_server_addr = NONE;/* Address of NFS server */
u8 root_server_path[256] = { 0, }; /* Path to mount as root */
+static char vendor_class_identifier[253]; /* vendor class identifier */
+
ic_dhcp_init_options is __init. Should it not be __initdata ?
I think so and I've made that change in net-2.6.25, thanks.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is there any word about this bug in gcc ?
From: WANG Cong [EMAIL PROTECTED] Date: Tue, 20 Nov 2007 13:39:05 +0800 And you mean abs() is not in glibc, then where is it? Built in gcc? And what's more, why not put it in glibc? Because the compiler knows things about the inputs and can thus apply optimizations that a static implementation in glibc that has to handle all forms of inputs cannot. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: soft lockup detected on CPU#0! in 2.6.23.8
From: Erik de Castro Lopo [EMAIL PROTECTED] Date: Tue, 20 Nov 2007 16:22:25 +1100 I've just compiled 2.6.23.8 from kernel.org sources and I getting a bunch of these soft lockups detected. Yes, this is getting hit by everyone, a fix is in the works. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] arch/sparc64: Add missing pci_dev_put
From: Julia Lawall [EMAIL PROTECTED] Date: Mon, 19 Nov 2007 09:02:22 +0100 (CET) From: Julia Lawall [EMAIL PROTECTED] There should be a pci_dev_put when breaking out of a loop that iterates over calls to pci_get_device and similar functions. .. Signed-off-by: Julia Lawall [EMAIL PROTECTED] Patch applied, but something in your email client adds extra spaces to the second column of several lines in your your patch. Please correct this before making future patch submissions. Thank you. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/59] arch/sparc: Add missing space
From: Joe Perches [EMAIL PROTECTED] Date: Mon, 19 Nov 2007 23:48:36 -0800 On Mon, 2007-11-19 at 23:45 -0800, David Miller wrote: From: Joe Perches [EMAIL PROTECTED] Date: Mon, 19 Nov 2007 17:47:58 -0800 Signed-off-by: Joe Perches [EMAIL PROTECTED] Please check your patches, for trailing white space. Adds trailing whitespace. diff:10:prom_printf(PCIC: Error, cannot map Adds trailing whitespace. diff:19:prom_printf(PCIC: Error, cannot map warning: 2 lines add whitespace errors. I've fixed it up this time. It doesn't add whitespace, but it does keep the trailing whitespace that's already there. I know that, you should still do sanity checks and fix these kinds of things up because they trigger errors in my patch applying scripts and that of many other developers. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 54/59] net/irda: Add missing space
From: Joe Perches [EMAIL PROTECTED] Date: Mon, 19 Nov 2007 17:53:41 -0800 Signed-off-by: Joe Perches [EMAIL PROTECTED] Applied. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 55/59] net/sctp: Add missing space
From: Joe Perches [EMAIL PROTECTED] Date: Mon, 19 Nov 2007 17:53:42 -0800 Signed-off-by: Joe Perches [EMAIL PROTECTED] Applied. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 50/59] net/bridge: Add missing space
From: Joe Perches [EMAIL PROTECTED] Date: Mon, 19 Nov 2007 17:53:37 -0800 Signed-off-by: Joe Perches [EMAIL PROTECTED] Applied. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 51/59] net/dccp: Add missing space
From: Joe Perches [EMAIL PROTECTED] Date: Mon, 19 Nov 2007 17:53:38 -0800 Signed-off-by: Joe Perches [EMAIL PROTECTED] Applied. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/59] arch/sparc64: Add missing space
From: Joe Perches [EMAIL PROTECTED] Date: Mon, 19 Nov 2007 17:47:59 -0800 Signed-off-by: Joe Perches [EMAIL PROTECTED] Applied. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/59] arch/sparc: Add missing space
From: Joe Perches [EMAIL PROTECTED] Date: Mon, 19 Nov 2007 17:47:58 -0800 Signed-off-by: Joe Perches [EMAIL PROTECTED] Please check your patches, for trailing white space. Adds trailing whitespace. diff:10:prom_printf(PCIC: Error, cannot map Adds trailing whitespace. diff:19:prom_printf(PCIC: Error, cannot map warning: 2 lines add whitespace errors. I've fixed it up this time. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 52/59] net/ipv4: Add missing space
From: Joe Perches [EMAIL PROTECTED] Date: Mon, 19 Nov 2007 17:53:39 -0800 Signed-off-by: Joe Perches [EMAIL PROTECTED] Applied. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 53/59] net/ipv6: Add missing space
From: Joe Perches [EMAIL PROTECTED] Date: Mon, 19 Nov 2007 17:53:40 -0800 Signed-off-by: Joe Perches [EMAIL PROTECTED] Applied. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 56/59] net/sunrpc: Add missing space
From: Joe Perches [EMAIL PROTECTED] Date: Mon, 19 Nov 2007 17:53:43 -0800 Signed-off-by: Joe Perches [EMAIL PROTECTED] Applied. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net/ipv4/arp.c: Fix arp reply when sender ip 0
From: Bill Fink [EMAIL PROTECTED] Date: Tue, 20 Nov 2007 00:16:07 -0500 On Mon, 19 Nov 2007, Alexey Kuznetsov wrote: 2. What's about your suggestion, I thought about this and I am going to agree. Arguments, which convinced me are: - arping still works. - any piece of reasonable software should work. - if Windows understands DaD (is it really true? I cannot believe) and it is unhappy about our responce and does not block use of duplicate address only due to this, we _must_ accomodate ASAP. - if we do,we have to use 0 protocol address, no choice. I agree the target protocol address should be 0 in this case. Patches, someone :-) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv4 5/6] Allow setting O_NONBLOCK flag for new sockets
From: Ulrich Drepper [EMAIL PROTECTED] Date: Tue, 20 Nov 2007 01:53:14 -0500 FWIW, I think this indirect syscall stuff is the most ugly interface I've ever seen proposed for the kernel. And I agree with all of the objections raised by both H. Pater Anvin and Eric Dumazet. This patch adds support for setting the O_NONBLOCK flag of the file descriptors returned by socket, socketpair, and accept. ... - err = sock_attach_fd(sock1, newfile1); + err = sock_attach_fd(sock1, newfile1, + INDIRECT_PARAM(file_flags, flags)); Where does this INDIRECT_PARAM() macro get defined? I do not see it being defined anywhere in these patches. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is it useful testing __LINK_STATE_RX_SCHED in dev_close()?
From: [EMAIL PROTECTED] Date: Tue, 20 Nov 2007 18:26:26 +0800 cpu0 calling netif_rx_schedule_prep(), cpu1 calling dev_close(): cpu0: testing __LINK_STATE_START, already set cpu1: clear__LINK_STATE_START cpu1: testing __LINK_STATE_RX_SCHED, not set cpu0: set __LINK_STATE_RX_SCHED cpu0: enter net poll, ... when cpu1 return from dev_close(),__LINK_STATE_RX_SCHED is still set. You'll have better luck asking networking questions on [EMAIL PROTECTED] as that is the mailing list where the kernel networking developers are subscribed. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv4 5/6] Allow setting O_NONBLOCK flag for new sockets
From: Ulrich Drepper [EMAIL PROTECTED] Date: Tue, 20 Nov 2007 08:04:53 -0800 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Miller wrote: Where does this INDIRECT_PARAM() macro get defined? I do not see it being defined anywhere in these patches. Defined in linux/indirect.h: +#define INDIRECT_PARAM(set, name) current-indirect_params.set.name Not my idea, I was following one review comment. This was not in the patches you posted, I double checked before sending my reply. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv4 5/6] Allow setting O_NONBLOCK flag for new sockets
From: Zach Brown [EMAIL PROTECTED] Date: Tue, 20 Nov 2007 13:55:56 -0800 Not to belabor this point, but it was: http://lkml.org/lkml/2007/11/20/53 $ grep -l INDIRECT_PARAM .git/patches/master/* .git/patches/master/indirect-v4-4.patch .git/patches/master/indirect-v4-5.patch .git/patches/master/indirect-v4-6.patch Maybe the patches got to you out of order so you saw 5/ before 4/? Thanks for pointing this out, I stand corrected. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [stable] Soft lockups since stable kernel upgrade to 2.6.23.8
From: Ingo Molnar [EMAIL PROTECTED] Date: Tue, 20 Nov 2007 22:49:27 +0100 * Greg KH [EMAIL PROTECTED] wrote: On Tue, Nov 20, 2007 at 09:39:19PM +0100, Ingo Molnar wrote: * Greg KH [EMAIL PROTECTED] wrote: but we only have cpu_clock() from v2.6.23 onwards - so we should not apply the original patch to v2.6.22. (we should not have applied your patch that started the mess to begin with - but that's another matter.) Well, I can easily back that one out, if that is easier than adding 2 more patches to try to fix up the mess here. Let me know if you feel that would be best. i'd leave it alone - doing that we have in essence the softlockup detector turned off. Reverting to the older version might trigger false positives that need the new stuff. Ok, I'll see if the current round of patches fix up everyone complaints :) so just to reiterate, to make sure we have the same plans: lets leave v2.6.22 and earlier kernels alone - and lets strive for the latest patches and code for v2.6.23 (and v2.6.24, evidently). I've validated that those patches make 2.6.23 behave on my Niagara box. Thanks. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] SPARC64: check for possible NULL pointer dereference
From: Cyrill Gorcunov [EMAIL PROTECTED] Date: Tue, 20 Nov 2007 20:28:33 +0300 From: Cyrill Gorcunov [EMAIL PROTECTED] This patch adds checking for possible NULL pointer dereference if of_find_property() failed. Signed-off-by: Cyrill Gorcunov [EMAIL PROTECTED] Applied, thanks. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][v2] net/ipv4/arp.c: Fix arp reply when sender ip 0
From: Jonas Danielsson [EMAIL PROTECTED] Date: Tue, 20 Nov 2007 17:28:22 +0100 Fix arp reply when received arp probe with sender ip 0. Send arp reply with target ip address 0.0.0.0 and target hardware address set to hardware address of requester. Previously sent reply with target ip address and target hardware address set to same as source fields. Signed-off-by: Jonas Danielsson [EMAIL PROTECTED] Acked-by: Alexey Kuznetov [EMAIL PROTECTED] I'm applying this but you gmail folks really have to get your act together when submitting patches. The patches from gmail accounts come out corrupted 9 times out of 10. This time line breaks were added and all tab characters were turned into spaces. Please correct this before any future patch submissions. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH] SO_NO_CHECK for IPv6
From: Jeff Garzik [EMAIL PROTECTED] Date: Wed, 21 Nov 2007 07:45:32 -0500 SO_NO_CHECK support for IPv6 appeared to be missing. This is presented, based on a reading of net/ipv4/udp.c. I wonder if IPv4's CHECKSUM_PARTIAL check from udp_push_pending_frames() also needs to be copied to IPv6? Signed-off-by: Jeff Garzik [EMAIL PROTECTED] IPV6 specifies that, unlike ipv4, this no-checksum behavior is not allowed. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: network driver usage count
From: Wagner Ferenc [EMAIL PROTECTED] Date: Wed, 21 Nov 2007 23:16:59 +0100 Hmm, that would warrant nuking all the reference counts on every driver. That's not true. When packets are in flight, references go to the device and the device cannot be unloaded until those references get dropped. This behavior makes sense because otherwise you have to figure out the myriad of references (each ipv4 address, each ipv6 address, routes, ARP entries, etc.) just to perform such a simple operation. If you do not mean to unload the device, simply do not do it. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH] SO_NO_CHECK for IPv6
From: Jeff Garzik [EMAIL PROTECTED] Date: Wed, 21 Nov 2007 19:17:40 -0500 YOSHIFUJI Hideaki / 吉藤英明 wrote: In article [EMAIL PROTECTED] (at Wed, 21 Nov 2007 07:45:32 -0500), Jeff Garzik [EMAIL PROTECTED] says: SO_NO_CHECK support for IPv6 appeared to be missing. This is presented, based on a reading of net/ipv4/udp.c. Disagree. UDP checksum is mandatory in IPv6. Ah, you mean that I need to turn off UDP checksum on receive end as well in IPv6... true. For those interested, I am dealing with a UDP app that already does very strong checksumming and encryption, so additional software checksumming at the lower layers is quite simply a waste of CPU cycles. Hardware checksumming is fine, as long as its free. Regardless of whatever verifications your application is doing on the data, it is not checksumming the ports and that's what the pseudo-header is helping with. You cannot disable checksums in ipv6/UDP, they are not optional and with %99.999 of cards doing the checksum in hardware, and even if we do have to compute it it's free during the copy during recvmsg(). - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Documentation about unaligned memory access
Thanks you for working proactively on these problems. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AF_IPN: Inter Process Networking, try these...
From: [EMAIL PROTECTED] (Renzo Davoli) Date: Fri, 7 Dec 2007 22:18:05 +0100 I disagree. If you suspect we would be better using IP multicast, I think your suspects are not supported. Try the following exercises, please Can you provide better solutions without IPN? I personally have not purely advocated IP, although the performance differences UDP and AF_UNIX should be investigated. Instead I advocated using AF_NETLINK with some minor multicast permission modifications to suit your needs. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc4-mm1: some issues on sparc64
From: Andrew Morton [EMAIL PROTECTED] Date: Sat, 8 Dec 2007 10:22:39 -0800 That's J_ASSERT_BH(bh, !buffer_jbddirty(bh)); at the end of journal_unmap_buffer(). I don't recall seeing that before and I can't think of anything we've done recently which could cause it, sorry. If the per-cpu data patches are in the -mm tree that is the first place I would start looking at for possible cause. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] Fix use of skb after netif_rx
From: Julia Lawall [EMAIL PROTECTED] Date: Sun, 9 Dec 2007 21:02:31 +0100 (CET) From: Julia Lawall [EMAIL PROTECTED] Recently, Wang Chen submitted a patch (d30f53aeb31d453a5230f526bea592af07944564) to move a call to netif_rx(skb) after a subsequent reference to skb, because netif_rx may call kfree_skb on its argument. The same problem occurs in some other drivers as well. This was found using the following semantic match. (http://www.emn.fr/x-info/coccinelle/) ... Signed-off-by: Julia Lawall [EMAIL PROTECTED] Patch applied, thanks. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] Fix use of skb after netif_rx
From: Julia Lawall [EMAIL PROTECTED] Date: Sun, 9 Dec 2007 21:03:55 +0100 (CET) From: Julia Lawall [EMAIL PROTECTED] Recently, Wang Chen submitted a patch (d30f53aeb31d453a5230f526bea592af07944564) to move a call to netif_rx(skb) after a subsequent reference to skb, because netif_rx may call kfree_skb on its argument. The same problem occurs in some other drivers as well. This was found using the following semantic match. (http://www.emn.fr/x-info/coccinelle/) ... Signed-off-by: Julia Lawall [EMAIL PROTECTED] Also applied, thanks. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] Fix use of skb after netif_rx
From: Julia Lawall [EMAIL PROTECTED] Date: Sun, 9 Dec 2007 21:05:30 +0100 (CET) From: Julia Lawall [EMAIL PROTECTED] Recently, Wang Chen submitted a patch (d30f53aeb31d453a5230f526bea592af07944564) to move a call to netif_rx(skb) after a subsequent reference to skb, because netif_rx may call kfree_skb on its argument. netif_rx_ni calls netif_rx, so the same problem occurs in the files below. I have left the updating of dev-last_rx after the calls to netif_rx_ni because it seems time dependent, but moved the other field updates before. This was found using the following semantic match. (http://www.emn.fr/x-info/coccinelle/) ... Signed-off-by: Julia Lawall [EMAIL PROTECTED] Applied. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc4-mm1: undefined reference to `compat_sys_timerfd' on sparc64
From: Andrew Morton [EMAIL PROTECTED] Date: Fri, 7 Dec 2007 16:08:00 -0800 Or should this have been sys_nis_syscall()? sys_nis_syscall() was used in cases on sparc where we wanted to get a log of invocations of unimplemented syscalls, as it aided debugging and anaylsis. But the usefulness of such things I think is long gone, so what I'll likely do is kill the sys_nis_syscall stuff from the sparc ports. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [NET]: Fix Ooops of napi net_rx_action.
From: Joonwoo Park [EMAIL PROTECTED] Date: Tue, 11 Dec 2007 18:13:34 +0900 Joonwoo-ssi annyoung haseyo, [NET]: Fix Ooops of napi net_rx_action. Before doing list_move_tail napi poll_list, it should be ensured Signed-off-by: Joonwoo Park [EMAIL PROTECTED] --- diff --git a/net/core/dev.c b/net/core/dev.c index 86d6261..74bd5ab 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -2207,7 +2207,8 @@ static void net_rx_action(struct softirq_action *h) * still owns the NAPI instance and therefore can * move the instance around on the list at-will. */ - if (unlikely(work == weight)) + if (unlikely((test_bit(NAPI_STATE_SCHED, n-state)) + (work == weight))) list_move_tail(n-poll_list, list); netpoll_poll_unlock(have); How can the NAPI_STATE_SCHED bit be cleared externally yet we take this list_move_tail() code path? If NAPI_STATE_SCHED is cleared, work will be zero which will never be equal to 'weight', and this we'll never attempt the list_move_tail(). If something clears NAPI_STATE_SCHED meanwhile, we have a serious race and your patch is an incomplete bandaid. For example, if it can happen, then a case like: if (test_bit(NAPI_STATE_SCHED, n-state)) ... something clears NAPI_STATE_SCHED right now ... work = n-poll(n, weight); can crash too. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [NET]: Fix Ooops of napi net_rx_action.
From: Herbert Xu [EMAIL PROTECTED] Date: Tue, 11 Dec 2007 20:36:21 +0800 David Miller [EMAIL PROTECTED] wrote: How can the NAPI_STATE_SCHED bit be cleared externally yet we take this list_move_tail() code path? His driver is probably buggy. When we had two drivers beginning with e100 we often forgot to apply fixes to the both of them. Now that we have three it's even more confusing. I just checked and indeed e1000e seems to be missing the NAPI fix that was applied to e1000. Of course it doesn't rule out the possibility of another NAPI bug in e1000. Thanks for checking. Indeed I stuck the huge comment there in net_rx_action() above the list move to try and explain things to people, so that if you saw a crash in the list manipulation, you're go check the driver first. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Intel Management Engine Interface
From: Andi Kleen [EMAIL PROTECTED] Date: Tue, 11 Dec 2007 19:53:17 +0100 Ok but saving oops is such a useful facility that we'll probably need to think about implementing SOAP in the kernel. Ummm, no. UDP is stateless, a stripped down copy of TCP we simply do not need. We also do not need XML in the kernel either. If they want to support things like this they should do it in the firmware of the management entity like every other sane server platform does these days. The console and OOPS messages should go over an extremely resilient transport which is as simple as possible which usually means shared memory or I/O memory with some simple handshake or doorbell. This gets it to the management entity board or whatever, and how it gets from there to the remote system is it's business not that of the kernel. Not TCP, and definitely not this XML SOAP crap. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] net: napi fix
From: Stephen Hemminger [EMAIL PROTECTED] Date: Tue, 11 Dec 2007 21:46:34 -0800 Isn't this a better fix for all drivers, rather than peppering every driver with the special case. This is how the logic worked up until 2.6.24. Stephen this is not the problem. The problem is that the driver is doing a NAPI completion and re-enabling chip interrupts with work_done == weight, and that is illegal. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/7] [NETDEV]: tehuti Fix possible causing oops of net_rx_action
From: Stephen Hemminger [EMAIL PROTECTED] Date: Tue, 11 Dec 2007 21:39:39 -0800 On Wed, 12 Dec 2007 13:01:27 +0900 Joonwoo Park [EMAIL PROTECTED] wrote: [NETDEV]: tehuti Fix possible causing oops of net_rx_action Signed-off-by: Joonwoo Park [EMAIL PROTECTED] --- drivers/net/tehuti.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/net/tehuti.c b/drivers/net/tehuti.c index 21230c9..955e749 100644 --- a/drivers/net/tehuti.c +++ b/drivers/net/tehuti.c @@ -305,6 +305,8 @@ static int bdx_poll(struct napi_struct *napi, int budget) netif_rx_complete(dev, napi); bdx_enable_interrupts(priv); + if (unlikely(work_done == napi-weight)) + return work_done - 1; } return work_done; } A better fix would be not going over budget in the first place. That's not the problem. They are not going over the budget, rather, they are hitting the budget yet doing netif_rx_complete() as well which is illegal. Unless you strictly process less than weight packets, you must not netif_rx_complete() and re-enable chip interrupts. I can't believe people are trying to fix this bug like this. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/7] [NETDEV]: tehuti Fix possible causing oops of net_rx_action
From: Joonwoo Park [EMAIL PROTECTED] Date: Wed, 12 Dec 2007 13:01:27 +0900 @@ -305,6 +305,8 @@ static int bdx_poll(struct napi_struct *napi, int budget) netif_rx_complete(dev, napi); bdx_enable_interrupts(priv); + if (unlikely(work_done == napi-weight)) + return work_done - 1; } return work_done; } Any time your trying to make a caller happy by adjusting a return value forcefully, it's a hack. And I stated this in another reply about this issue. Please do not fix the problem this way. The correct way to fix this is, if we did process a full weight or work, we should not netif_rx_complete() and we should not re-enable chip interrupts. Instead we should return the true work_done value and allow the caller to thus poll us one more time. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [NET]: Fix Ooops of napi net_rx_action.
From: Brandeburg, Jesse [EMAIL PROTECTED] Date: Tue, 11 Dec 2007 16:38:37 -0800 @@ -3933,6 +3933,10 @@ quit_polling: e1000_set_itr(adapter); netif_rx_complete(poll_dev, napi); e1000_irq_enable(adapter); + if (work_done == weight) + return work_done - 1; + else + return work_done; Don't do this. If you processed weight worth of packets, return that exact value and do not netif_rx_complete() and do not re-enable interrupts. That is the only correct fix. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] net: napi fix
From: Joonwoo Park [EMAIL PROTECTED] Date: Wed, 12 Dec 2007 15:05:26 +0900 Could you explain how it fix the problem? IMHO I think your patch cannot solve the problem. The drivers can call netif_rx_complete and net_rx_action can do list_move_tail also. Stephen is confused about what the bug is in these drivers, that's all. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] net: napi fix
From: Andrew Gallatin [EMAIL PROTECTED] Date: Wed, 12 Dec 2007 12:29:23 -0500 Is the netif_running() check even required? No, it is not. When a device is brought down, one of the first things that happens is that we wait for all pending NAPI polls to complete, then block any new polls from starting. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Net: Remove FASTCALL macro
From: Harvey Harrison [EMAIL PROTECTED] Date: Wed, 12 Dec 2007 00:09:03 -0800 X86_32 was the last user of the FASTCALL macro, now that it uses regparm(3) by default, this macro expands to nothing. Signed-off-by: Harvey Harrison [EMAIL PROTECTED] Applied to net-2.6.25, thanks. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][NETDEV]: remove netif_running() check from myri10ge_poll()
From: Andrew Gallatin [EMAIL PROTECTED] Date: Wed, 12 Dec 2007 13:38:34 -0500 Remove the bogus netif_running() check from myri10ge_poll(). This eliminates any chance that myri10ge_poll() can trigger an oops by calling netif_rx_complete() and returning with work_done == budget. Signed-off-by: Andrew Gallatin [EMAIL PROTECTED] Acked-by: David S. Miller [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fbcon: fix sparse warning about shadowing 'p' symbol
From: Andrew Morton [EMAIL PROTECTED]
Date: Tue, 11 Dec 2007 16:57:00 -0800
On Sun, 9 Dec 2007 22:34:33 +0100
Marcin __lusarz [EMAIL PROTECTED] wrote:
fbcon: fix sparse warning about shadowing 'p' symbol
Please always quote error messages and warnings in the changelog when
fixing them, thanks.
---
drivers/video/console/fbcon.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index 0f32f4a..849e114 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -2795,7 +2795,7 @@ static int fbcon_scrolldelta(struct vc_data *vc, int
lines)
{
struct fb_info *info = registered_fb[con2fb_map[fg_console]];
struct fbcon_ops *ops = info-fbcon_par;
- struct display *p = fb_display[fg_console];
+ struct display *disp = fb_display[fg_console];
We have a global symbol called p? That would be bad. Where is it?
I'm curious about this too.
Ahh, I see, look down a few lines in fbcon_scrolldelta(), we have:
if (logo_shown == vc-vc_num) {
unsigned long p, q;
int i;
and that's where the warning is coming from.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/1] Convert the semaphore to a mutex in net/tipc/socket.c
From: Andrew Morton [EMAIL PROTECTED] Date: Tue, 11 Dec 2007 16:44:45 -0800 So I'd propose this: I've applied this to net-2.6, thanks Andrew. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/7] [NETDEV]: e1000 Fix possible causing oops of net_rx_action
From: Joonwoo Park [EMAIL PROTECTED] Date: Thu, 13 Dec 2007 19:18:56 +0900 Just blowing netif_running up is not best solution I think, it makes ifconfig down hang at least for e1000. It hangs because the packet receive rate is so high that NAPI poll never exits. I think we need a cheap solution to something so obscure and almost not worth explicitly even coding for. Really, if you setup silly situations like that, you get what you asked for. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] net: napi fix
From: Jarek Poplawski [EMAIL PROTECTED] Date: Thu, 13 Dec 2007 14:49:53 +0100 As a matter of fact, since it's unlikely() in net_rx_action() anyway, I wonder what is the main reason or gain of leaving such a tricky exception, instead of letting drivers to always decide which is the best moment for napi_complete()? (Or maybe even, in such a case, they should call some function with this list_move_tail() if it's so useful?) It is the only sane way to synchronize the list manipulations. There has to be a way for -poll() to tell net_rx_action() two things: 1) How much work was completed, so we can adjust 'budget' 2) Was the NAPI quota exhausted? So that we know that net_rx_action() still owns the polling context and thus can do the list manipulation safely. And these both need to be encoded into one single return value, thus the adopted convention that work == weight means that the device has not done a NAPI complete. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] net: napi fix
From: Andrew Gallatin [EMAIL PROTECTED] Date: Thu, 13 Dec 2007 09:13:54 -0500 If the netif_running() check is indeed required to make a device break out of napi polling and respond to an ifconfig down, then I think the netif_running() check should be moved up into net_rx_action() to avoid potential for driver complexity and bugs like the ones you found. That, or something like it, definitely sounds reasonable and much better than putting the check into every driver :-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix compiler warning noise with FORE200E driver
From: Tom \spot\ Callaway [EMAIL PROTECTED] Date: Thu, 13 Dec 2007 11:21:40 -0500 gcc throws these warnings with: CONFIG_ATM_FORE200E=m # CONFIG_ATM_FORE200E_PCA is not set drivers/atm/fore200e.c:2695: warning: 'fore200e_pca_detect' defined but not used drivers/atm/fore200e.c:2748: warning: 'fore200e_pca_remove_one' defined but not used By moving the #ifdef CONFIG_ATM_FORE200E_PCA around those two functions, the compiler warnings are silenced. (btw, I'm not subscribed to lkml, so please CC me on any responses, although this is a wholly trivial patch, so I'm not expecting any.) Signed-off-by: Tom spot Callaway [EMAIL PROTECTED] Applied, thanks Tom. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc5-mm1
From: Benjamin Thery [EMAIL PROTECTED] Date: Thu, 13 Dec 2007 16:01:34 +0100 The problem comes from the new macro UDPX_INC_STATS_BH introduced by Herbert, which was a nice addition to increment the correct UDP MIB depending on the socket family, but unfortunately the use of this macro from kernel code (I mean code not compiled as module) requires that IPv6 is also compiled in kernel (CONFIG_IPv6=y) in order to have udp_stats_in6 defined at link time. Herbert, please take a look at this, thanks! Benjamin Pierre Peiffer wrote: Hi, My config does not link any more: ... CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 net/built-in.o: In function `xs_udp_data_ready': /home/peifferp/containers/kernel/linux-2.6.24-rc5-mm1/net/sunrpc/xprtsock.c:842: undefined reference to `udp_stats_in6' /home/peifferp/containers/kernel/linux-2.6.24-rc5-mm1/net/sunrpc/xprtsock.c:846: undefined reference to `udp_stats_in6' make[1]: *** [.tmp_vmlinux1] Error 1 make: *** [sub-make] Error 2 After a first look, udp_stats_in6 seems to be defined in ipv6 (file net/ipv6/udp.c) but I have CONFIG_IPV6=m and CONFIG_SUNRPC=y So, SUNRPC uses something defined in a module in my case ? ... looking more, this dependency seems to have been introduced by the patch [UDP]: Restore missing inDatagrams increments ( http://thread.gmane.org/gmane.linux.network/79716/focus=79831 ) (I cc netdev) I don't know what is the right way to fix this ... ? P. Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc5/2.6.24-rc5-mm1/ - If something goes wrong with a PCI device's probing or initialisation, try reverting pci-disable-decoding-during-sizing-of-bars.patch. - git-sched was dropped due to breaking suspend-to-RAM. - git-block has been restored after having had a few problems - git-newsetup.patch was dropped due to conflicts with git-x86 - git-perfmon.patch is still dropped for the same reason - git-kgdb.patch is still dropped for the same reason - Please do try to cc the correct developer and mailing list when reporting problems - I'm just buried in bugs over here. Boilerplate: - See the `hot-fixes' directory for any important updates to this patchset. - To fetch an -mm tree using git, use (for example) git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git tag v2.6.16-rc2-mm1 git-checkout -b local-v2.6.16-rc2-mm1 v2.6.16-rc2-mm1 - -mm kernel commit activity can be reviewed by subscribing to the mm-commits mailing list. echo subscribe mm-commits | mail [EMAIL PROTECTED] - If you hit a bug in -mm and it is not obvious which patch caused it, it is most valuable if you can perform a bisection search to identify which patch introduced the bug. Instructions for this process are at http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt But beware that this process takes some time (around ten rebuilds and reboots), so consider reporting the bug first and if we cannot immediately identify the faulty patch, then perform the bisection search. - When reporting bugs, please try to Cc: the relevant maintainer and mailing list on any email. - When reporting bugs in this kernel via email, please also rewrite the email Subject: in some manner to reflect the nature of the bug. Some developers filter by Subject: when looking for messages to read. - Occasional snapshots of the -mm lineup are uploaded to ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ and are announced on the mm-commits list. These probably are at least compilable. - More-than-daily -mm snapshots may be found at http://userweb.kernel.org/~akpm/mmotm/. These are almost certainly not compileable. Changes since 2.6.24-rc4-mm1: origin.patch git-acpi.patch git-alsa.patch git-agpgart.patch git-arm.patch git-arm-master.patch git-avr32.patch git-cpufreq.patch git-powerpc.patch git-drm.patch git-dvb.patch git-hwmon.patch git-gfs2-nmw.patch git-hid.patch git-hrt.patch git-ieee1394.patch git-infiniband.patch git-input.patch git-jfs.patch git-kbuild.patch git-kvm.patch git-lblnet.patch git-leds.patch git-libata-all.patch git-md-accel.patch git-mips.patch git-mmc.patch git-mtd.patch git-ubi.patch git-net.patch git-netdev-all.patch git-battery.patch git-nfs.patch git-nfsd.patch git-ocfs2.patch git-s390.patch git-sh.patch git-scsi-misc.patch git-scsi-rc-fixes.patch git-block.patch git-unionfs.patch git-v9fs.patch git-watchdog.patch git-wireless.patch git-ipwireless_cs.patch git-x86.patch git-xfs.patch
Re: [RFC] net: napi fix
From: Andrew Gallatin [EMAIL PROTECTED] Date: Thu, 13 Dec 2007 14:02:25 -0500 Or perhaps we should just leave things as is. We should probably add a disabling state bit to the napi struct flags, this will be set by napi_disable() before it loops trying to set the sched bit. net_rx_action() can then check this. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] net: napi fix
From: Jarek Poplawski [EMAIL PROTECTED] Date: Thu, 13 Dec 2007 21:16:12 +0100 I see in a nearby thread you would prefer to save some work to drivers (like this netif_running() check), but I think this all is at the cost of flexibility, and there will probably appear new problems, when a driver simply can't wait till the next poll (which btw. looks strange with all these hotplugging, usb and powersaving). As someone who has actually had to edit the NAPI support of _EVERY_ single driver in the tree I can tell you that code duplication and subtle semantic differences are a huge issue. And when you talk about driver flexibility, it's wise to mention that this comes at the expense of flexibility in the core implmentation. For example, if we export the list handling widget into the -poll() routines, god help the person who wants to change how the poll list is managed in net_rx_action() :-/ So we don't want to export datastructure details like that to the driver. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] net: napi fix
From: Stephen Hemminger [EMAIL PROTECTED] Date: Thu, 13 Dec 2007 11:35:07 -0800 How about allowing a return value of -1 from napi_poll and letting device check itself. It doesn't avoid the code duplication in the -poll() fast paths. I don't care, on the other hand, if crap accumulates in non-critical slow paths like napi_disable() and dev_close(). That's why I'm suggesting solutions in that area. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: remove __read_mostly
From: Adrian Bunk [EMAIL PROTECTED] Date: Thu, 13 Dec 2007 23:20:44 +0100 My question is: Is there anywhere in the kernel a case where __read_mostly brings a measurable improvement or can it be removed? Yes, on SMP when read-mostly objects share cache lines with other objects which are frequently written to. That is the whole reason we created __read_mostly -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] net: napi fix
From: Jarek Poplawski [EMAIL PROTECTED] Date: Thu, 13 Dec 2007 23:28:41 +0100 ...I'm afraid I can't understand: I mean doing the same but without passing this info with 'work == weight': if driver sends this info, why it can't instead call something like napi_continue() with this list_move_tail() (and probably additional local_irq_disable()/ enble() - but since it's unlikely()?) which looks much more readable, and saves one whole unlikely if ()? Because the poll list is private to net_rx_action() and we don't want to expose implementation details like that to every -poll() implementation. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 08/12] PAT 64b: coherent mmap and sysfs bin ioctl
From: Greg KH [EMAIL PROTECTED] Date: Thu, 13 Dec 2007 16:19:32 -0800 On Thu, Dec 13, 2007 at 03:55:51PM -0800, [EMAIL PROTECTED] wrote: Forward port of coherent-mmap.patch and sysfs-bin-ioctl.patch to x86 tree. TBD: Do we need the ioctl interface to sysfs or get the type attribute through a different sysfs file. And then actually specify the attribute while doing pci_mmap_page_range ;-) Woah! No, no ioctls on sysfs files, sorry. Not going to happen, do this on a /dev file if you want to have ioctls... Well since we told people to move over to sysfs for PCI accesses, and that's where mmap() is done via too, it should be no surprise that we run into problems when people want to set attributes for the mmap() as was done for the procfs case. So you have two choices: 1) Balk on the sysfs pci usage, and erase years of effort of moving people over to sysfs. Tell them to go back to procfs so we can add the attribute setting via ioctl() which is absolutely needed. 2) Relax your restrictions a little bit and allow ioctl()'s for limited cases, like this one. Otherwise, propase a way to specify PCI device mmap attributes which works within your whole-universe sysfs theory of everything :-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] AS apple talk protocol register_snap_client failed
From: guanxun mu [EMAIL PROTECTED]
Date: Fri, 14 Dec 2007 14:03:05 +0800
[PACTH APPLETALK]
This patch update proto_init process when register_snap_client failed
Signed-off-by: Michale Moore [EMAIL PROTECTED]
diff --git a/net/appletalk/aarp.c b/net/appletalk/aarp.c
index 6c5c6dc..d6573f6 100644
--- a/net/appletalk/aarp.c
+++ b/net/appletalk/aarp.c
@@ -873,7 +873,10 @@ void __init aarp_proto_init(void)
{
aarp_dl = register_snap_client(aarp_snap_id, aarp_rcv);
if (!aarp_dl)
- printk(KERN_CRIT Unable to register AARP with SNAP.\n);
+ {
+ printk(KERN_CRIT Unable to register AARP with SNAP.\n);
+ return;
+ }
init_timer(aarp_timer);
aarp_timer.function = aarp_expire_timeout;
aarp_timer.data = 0;
Wrong coding style, the openning brace should be on the same line
as the if() check, see Documentation/CodingStyle Your email
client has also corrupted the tab characters into spaces, making
the patch unusable even if it were correct.
Next, if you are going to do this, you should modify aarp_proto_init()
to return error values, so that atalk_init() can see it and thus
undo the initialization it does and return an error for the module
load.
It is not useful to add error checks, without propagating them,
because an OOPS is just as good as a partially-initialized protocol
since that is likely to crash or malfunction as well.
The protocol is thus equally broken before and after your changes.
Please completely implement this fix, thank you.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc5-mm1
From: Herbert Xu [EMAIL PROTECTED] Date: Fri, 14 Dec 2007 10:08:07 +0800 [UDP]: Move udp_stats_in6 into net/ipv4/udp.c Now that external users may increment the counters directly, we need to ensure that udp_stats_in6 is always available. Otherwise we'd either have to requrie the external users to be built as modules or ipv6 to be built-in. This isn't too bad because udp_stats_in6 is just a pair of pointers plus an EXPORT, e.g., just 40 (16 + 24) bytes on x86-64. Signed-off-by: Herbert Xu [EMAIL PROTECTED] Applied. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [NET]: Fix Ooops of napi net_rx_action.
From: Stephen Hemminger [EMAIL PROTECTED] Date: Tue, 11 Dec 2007 15:42:22 -0800 Perhaps we should change the warning to identify the guilty device. Applied. Stephen, you often don't supply a proper signoff line for one-off changes like this and I find it very irritating. It doesn't cost you anything to hit one or two keys in your outgoing email editor to include the signoff line. So please do so, or I'll silently drop patches without them in the future. Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ipv4: Update ip command line processing (take II)
From: Simon Horman [EMAIL PROTECTED] Date: Wed, 26 Dec 2007 11:59:05 +0900 Recently the documentation in Documentation/nfsroot.txt was update to note that in fact ip=off and ip=::off as the latter is ignored and the default (on) is used. This was certainly a step in the direction of reducing confusion. But it seems to me that the code ought to be fixed up so that ip=::off actually turns off ip autoconfiguration. This patch also notes more specifically that ip=on (aka ip=::on) is the default. Cc: Amos Waterland [EMAIL PROTECTED] Signed-off-by: Simon Horman [EMAIL PROTECTED] I applied this to net-2.6 since I think it's a bug fix, and I also tailored the changelog header to more it clear this is a fix not just an Update. :-) Thanks! -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc6-mm1: some section mismatches on sparc64
From: Mariusz Kozlowski [EMAIL PROTECTED] Date: Wed, 26 Dec 2007 13:29:07 +0100 WARNING: vmlinux.o(.text+0x46b04): Section mismatch: reference to .init.text:sun4v_ktsb_register (between 'smp_callin' and 'smp_fill_in_sib_core_maps') Well known and I see them every build and so does everyone else on sparc64. They are harmless and as time allows I try to find ways to get rid of them but it's very low priority. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/10] percpu: Use a kconfig variable to signal arch specific percpu setup
From: [EMAIL PROTECTED] Date: Thu, 27 Dec 2007 16:10:47 -0800 V1-V2: - Use def_bool as suggested by Randy. The use of the __GENERIC_PERCPU is a bit problematic since arches may want to run their own percpu setup while using the generic percpu definitions. Replace it through a kconfig variable. Cc: Rusty Russell [EMAIL PROTECTED] Cc: Andi Kleen [EMAIL PROTECTED] Signed-off-by: Christoph Lameter [EMAIL PROTECTED] Signed-off-by: Mike Travis [EMAIL PROTECTED] Acked-by: David S. Miller [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/10] percpu: Move arch XX_PER_CPU_XX definitions into linux/percpu.h
From: [EMAIL PROTECTED] Date: Thu, 27 Dec 2007 16:10:48 -0800 V1-V2: - Special consideration for IA64: Add the ability to specify arch specific per cpu flags The arch definitions are all the same. So move them into linux/percpu.h. We cannot move DECLARE_PER_CPU since some include files just include asm/percpu.h to avoid include recursion problems. Cc: Rusty Russell [EMAIL PROTECTED] Cc: Andi Kleen [EMAIL PROTECTED] Signed-off-by: Christoph Lameter [EMAIL PROTECTED] Signed-off-by: Mike Travis [EMAIL PROTECTED] Acked-by: David S. Miller [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/10] percpu: Make the asm-generic/percpu.h more generic
From: [EMAIL PROTECTED] Date: Thu, 27 Dec 2007 16:10:49 -0800 V1-V2: - add support for PER_CPU_ATTRIBUTES Add the ability to use generic/percpu even if the arch needs to override several aspects of its operations. This will enable the use of generic percpu.h for all arches. An arch may define: __per_cpu_offset Do not use the generic pointer array. Arch must define per_cpu_offset(cpu) (used by x86_64, s390). __my_cpu_offset Can be defined to provide an optimized way to determine the offset for variables of the currently executing processor. Used by ia64, x86_64, x86_32, sparc64, s/390. SHIFT_PTR(ptr, offset)If an arch defines it then special handling of pointer arithmentic may be implemented. Used by s/390. (Some of these special percpu arch implementations may be later consolidated so that there are less cases to deal with.) Cc: Rusty Russell [EMAIL PROTECTED] Cc: Andi Kleen [EMAIL PROTECTED] Signed-off-by: Christoph Lameter [EMAIL PROTECTED] Signed-off-by: Mike Travis [EMAIL PROTECTED] Acked-by: David S. Miller [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/10] Sparc64: Use generic percpu
From: [EMAIL PROTECTED] Date: Thu, 27 Dec 2007 16:16:25 -0800 Sparc64 has a way of providing the base address for the per cpu area of the currently executing processor in a global register. Sparc64 also provides a way to calculate the address of a per cpu area from a base address instead of performing an array lookup. Cc: David Miller [EMAIL PROTECTED] Signed-off-by: Christoph Lameter [EMAIL PROTECTED] Signed-off-by: Mike Travis [EMAIL PROTECTED] Acked-by: David S. Miller [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: fib6_del_route has redundant code
From: Gui Jianfeng [EMAIL PROTECTED]
Date: Thu, 27 Dec 2007 15:26:46 +0800
I think the following code in fib6_del_route in the latest kernel is useless.
1125 if (fn-leaf == NULL fn-fn_flagsRTN_TL_ROOT)
1126 fn-leaf = ip6_null_entry;
ip6_null_entry will never be unlinked from fn-leaf now, that is,
fn-leaf == NULL will never meet.
I think you are right, but if it is true the next block of
code is dead too:
/* If it was last route, expunge its radix tree node */
if (fn-leaf == NULL) {
fn-fn_flags = ~RTN_RTINFO;
rt6_stats.fib_route_nodes--;
fn = fib6_repair_tree(fn);
}
But I am not completely convinced that all of these lines
of code can be removed :-)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: fib6_del_route has redundant code
From: Gui Jianfeng [EMAIL PROTECTED]
Date: Fri, 28 Dec 2007 13:58:21 +0800
I think the following code in fib6_del_route in the latest kernel is
useless.
1125 if (fn-leaf == NULL fn-fn_flagsRTN_TL_ROOT)
1126 fn-leaf = ip6_null_entry;
ip6_null_entry will never be unlinked from fn-leaf now, that is,
fn-leaf == NULL will never meet.
I think you are right, but if it is true the next block of
code is dead too:
/* If it was last route, expunge its radix tree node */
if (fn-leaf == NULL) {
fn-fn_flags = ~RTN_RTINFO;
rt6_stats.fib_route_nodes--;
fn = fib6_repair_tree(fn);
}
I think this block of code can't be removed, because just the
root(default route) fn-leaf always has ip6_null_entry on it. The
normal fn-leaf becomes NULL when last route has been deleted, the
radix tree should be expunged.
But you said (still quoted above) that fn-leaf == NULL will not
occur.
Do you mean this, only in the case that the RTN_TL_ROOT flag is set?
I thought you meant always when the function is called, fn-leaf
cannot ever be NULL.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
