Re: bad networking related lag in v2.6.22-rc2

2007-05-23 Thread Linus Torvalds
On Wed, 23 May 2007, Patrick McHardy wrote: Yes, that looks better, thanks. There appear to be other obvious problems in the recent cleanups in this area.. Look at psched_tdiff_bounded(psched_time_t tv1, psched_time_t tv2, psched_time_t bound) { return

Re: [2/2] 2.6.22-rc4: known regressions v3

2007-06-15 Thread Linus Torvalds
On Wed, 13 Jun 2007, Michal Piotrowski wrote: Subject: hibernate(?) fails totally - regression References : http://lkml.org/lkml/2007/6/1/401 Submitter : David Greaves [EMAIL PROTECTED] Handled-By : Rafael J. Wysocki [EMAIL PROTECTED] Caused-By : Tejun Heo [EMAIL PROTECTED]

Re: [2/2] 2.6.22-rc6: known regressions with patches

2007-06-25 Thread Linus Torvalds
On Mon, 25 Jun 2007, Michal Piotrowski wrote: Memory management Subject: bug in i386 MTRR initialization References : http://lkml.org/lkml/2007/5/19/93 Submitter : Andrea Righi [EMAIL PROTECTED] Status : patch available This one wasn't a bug in the first place, it was just the

Re: [git patches] net driver fixes

2005-07-31 Thread Linus Torvalds
On Sun, 31 Jul 2005, Jeff Garzik wrote: Please pull from the 'upstream-fixes' branch of rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git to obtain the fixes described in the attached diffstat/changelog/patch. Could you please try to edit the emails you apply to

Re: [PATCH 00/20] vm deadlock avoidance for NFS, NBD and iSCSI (take 7)

2006-09-12 Thread Linus Torvalds
On Tue, 12 Sep 2006, Peter Zijlstra wrote: Linus, when I mentioned swap over network to you in Ottawa, you said it was a valid use case, that people actually do and want this. Can you agree with the approach taken in these patches? Well, in all honesty, I don't think I really said valid,

Re: [PATCH] sky2: revert IRQ dance on suspend/resume

2007-01-29 Thread Linus Torvalds
On Mon, 29 Jan 2007, Stephen Hemminger wrote: Signed-off-by: Stephen Hemminger [EMAIL PROTECTED](none) Mind if I fix your sign-off? ;) Linus - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at

Re: buggy IFB driver change

2007-01-30 Thread Linus Torvalds
On Tue, 30 Jan 2007, Jeff Garzik wrote: I'm about to crash, can you or Linus handle the correction? Reverted, pushed out. Davem, if you have any other issues, just push me any fixes. I'm going to do a final -rc7 today (way too many changes for me to be happy releasing a 2.6.20 without a

Re: [PATCH] r8169: fix a race between PCI probe and dev_open

2007-01-31 Thread Linus Torvalds
On Wed, 31 Jan 2007, Francois Romieu wrote: Call chain: - rtl8169_init_one - register_netdev (dev_open starts to race...) - rtl8169_init_phy - rtl8169_set_speed - tp-set_speed - mod_timer(tp-timer, ...) (if netif_running() is true) As

Re: Please pull upstream-fixes branch of wireless-2.6

2006-04-20 Thread Linus Torvalds
On Thu, 20 Apr 2006, Andrew Morton wrote: John W. Linville [EMAIL PROTECTED] wrote: At present, all the branches in wireless-2.6 only pull from linux-2.6. I am still pushing (i.e. requesting Jeff's pull) to netdev-2.6, if that matters. Maybe the current wireless-2.6 tree fits

Re: Please pull upstream-fixes branch of wireless-2.6

2006-05-05 Thread Linus Torvalds
On Fri, 5 May 2006, Andrew Morton wrote: On Fri, 5 May 2006 21:06:18 -0400 John W. Linville [EMAIL PROTECTED] wrote: These are fixes intended for 2.6.17...thanks! Jeff is offline for a couple of weeks. Please prepare a pull for Linus. Actually, while Jeff is off, Steve Hemminger is

Re: [git patches] net driver updates

2006-05-20 Thread Linus Torvalds
On Sat, 20 May 2006, Andrew Morton wrote: Jeff Garzik [EMAIL PROTECTED] wrote: Andrew Morton: revert forcedeth: fix multi irq issues Manfred just found the fix for this, so we should no longer need to revert. Hmm. I already pulled. I guess we can revert the revert and apply

Re: [RFT 0/5] sky2: suspend/resume patchlets

2006-06-13 Thread Linus Torvalds
[ Davem - see the final conclusion: this might not be a driver bug as much as a netconsole problem, where netconsole might perhaps continue sendign on a device that really can't take it any more? ] On Tue, 13 Jun 2006, Stephen Hemminger wrote: There were a several problems buried in

Re: 2.6.17: networking bug??

2006-06-13 Thread Linus Torvalds
On Tue, 13 Jun 2006, John Heffner wrote: The best thing you can do is try to find this broken box and inform its owner that it needs to be fixed. (If you can find out what it is, I'd be interested to know.) In the meantime, disabling window scaling will work around the problem for you.

Re: [FORCEDETH]: Fix xmit_lock/netif_tx_lock after merge

2006-06-20 Thread Linus Torvalds
On Tue, 20 Jun 2006, Herbert Xu wrote: [FORCEDETH]: Fix xmit_lock/netif_tx_lock after merge Btw, please don't use attachments in vain. Now I can't see it by default, I can reply and quote it etc etc. Linus - To unsubscribe from this list: send the line unsubscribe netdev in

Re: [PATCH] Endian-annotate struct iphdr

2006-01-07 Thread Linus Torvalds
On Sat, 7 Jan 2006, Al Viro wrote: [following is for people familiar with sparse internals; everybody else can safely skip it] ... Objections? Basically, from C POV any fouled value is int or unsigned int and we avoid generating a warning only if its upper bits will eventually be

Re: [git patches] 2.6.x net driver updates

2006-01-12 Thread Linus Torvalds
On Thu, 12 Jan 2006, Jeff Garzik wrote: dann frazier: CONFIG_AIRO needs CONFIG_CRYPTO I think this is done wrong. It should select CRYPTO rather than depends on CRYPTO. Otherwise people won't see it just because they don't have crypto enabled, which is not very user-friendly. Btw,

Re: [git patches] 2.6.x net driver updates

2006-01-12 Thread Linus Torvalds
On Thu, 12 Jan 2006, Andrew Morton wrote: Yes, I think that's much more Aunt-Nellie-friendly, but Roman considers it abuse of the Kconfig system in ways which I never completely understood? Hmm. If Roman dislikes it, he must dislike the fact that we already do exactly this for a ton of

Re: [PATCH] s2io ppc64 fix for readq/writeq

2006-11-06 Thread Linus Torvalds
On Mon, 6 Nov 2006, Jeff Garzik wrote: This seems a bit ugly. Could you add #define readq readq to your platform instead? Heartily agreed. MUCH better than adding unrelated #if defined() stuff, whether arch-related or otherwise. Linus - To unsubscribe from this

Re: [PATCH] s2io ppc64 fix for readq/writeq

2006-11-06 Thread Linus Torvalds
On Mon, 6 Nov 2006, Benjamin Herrenschmidt wrote: Anyway, what do you think of Jeff proposal to just implement them as two 32 bits operations ? My arch guy side screams at the idea, but if, indeed, drivers generally cope fine with it, I suppose that's ok. Last I saw, that's how normal PCI

Re: [BUG] CREDITS or CREDITS-YOURSELVES

2006-11-16 Thread Linus Torvalds
On Fri, 17 Nov 2006, Jarek Poplawski wrote: With great astonishment I've found none of these networking names in the CREDITS file: Stephen Hemminger, Thomas Graf, Alexey Kuznetsov, Andrew Morton, Pedro Roque, Jamal Hadi Salim, Herbert Xu etc. You should basically consider the CREDITS

Re: [1/3] 2.6.21-rc6: known regressions

2007-04-13 Thread Linus Torvalds
Note: Ingo also reports what looks like a memory corruption due to the 6b6b6b6b pattern on presumably the same box. The 6b6b6b6b pattern is POISON_FREE, implying some kind of slab misuse, most likely a use-after-free, although possibly just due to overrunning a slab into the next one or

Re: [Security] [PATCH] infinite recursion in netlink

2007-04-25 Thread Linus Torvalds
On Wed, 25 Apr 2007, Alexey Kuznetsov wrote: Reply to NETLINK_FIB_LOOKUP messages were misrouted back to kernel, which resulted in infinite recursion and stack overflow. So I assume it's this line that actually _fixes_ it: - pid = nlh-nlmsg_pid; /*pid of sending process */

Re: [PATCH netdev-2.6 00/19] e1000: driver update (fixes for 2.6.16)

2006-03-02 Thread Linus Torvalds
On Thu, 2 Mar 2006, Jeff Garzik wrote: The more I think about it, the less motivated I am to push these changes into 2.6.16 at the last minute. Comments? Absolutely. Considering what happened last time, I wouldn't pull from you even if you pushed. Linus - To unsubscribe

Re: [git patches] net driver fixes

2006-03-16 Thread Linus Torvalds
On Thu, 16 Mar 2006, Jeff Garzik wrote: Please pull from 'upstream-fixes' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git The commit comments for the Chelsio driver fix are a bit unfortunate. The array clearly _does_ have three elements, it's just that the code

Re: [git patches] net driver fixes

2007-03-01 Thread Linus Torvalds
Ok, here's an interesting one: my e1000 card no longer worked for a while. The green link-light blinks on/off once a second, and in time to that, my dmesg fills up with an endless supply of e1000: eth0: e1000_watchdog: NIC Link is Down e1000: eth0: e1000_watchdog: NIC Link is

Re: [git patches] net driver fixes

2007-03-02 Thread Linus Torvalds
On Thu, 1 Mar 2007, Kok, Auke wrote: Linus Torvalds wrote: Ok, here's an interesting one: my e1000 card no longer worked for a while. The green link-light blinks on/off once a second, and in time to that, my dmesg fills up with an endless supply of e1000: eth0

Re: [patch 097/101] revert drivers/net/tulip/dmfe: support basic carrier detection

2007-03-07 Thread Linus Torvalds
On Wed, 7 Mar 2007, Dan Williams wrote: Definitely right. If it doesn't work for your card, it needs to be fixed for your card. Well, regressions are regressions. And they are a *lot* more important than any new features. If it doesn't work, it gets reverted. Linus - To

Re: [PATCH 1/2] avoid OPEN_MAX in SCM_MAX_FD

2007-03-13 Thread Linus Torvalds
On Tue, 13 Mar 2007, Roland McGrath wrote: The OPEN_MAX constant is an arbitrary number with no useful relation to anything. Nothing should be using it. SCM_MAX_FD is just an arbitrary constant and it should be clear that its value is chosen in net/scm.h and not actually derived from

Re: [PATCH 1/2] avoid OPEN_MAX in SCM_MAX_FD

2007-03-13 Thread Linus Torvalds
On Tue, 13 Mar 2007, Roland McGrath wrote: Ok, fine. But PATH_MAX is a real constant that has some meaning in the kernel. It's perfectly correct to use PATH_MAX as a constant on a system like Linux that defines it and means what it says. Conversely, OPEN_MAX has no useful relationship

Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable

2007-03-19 Thread Linus Torvalds
On Mon, 19 Mar 2007, Eric W. Biederman wrote: True. You can use all of the call clobbered registers. Quite often, the biggest single win of inlining is not so much the code size (although if done right, that will be smaller too), but the fact that inlining DOES NOT CLOBBER AS MANY

Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable

2007-03-19 Thread Linus Torvalds
On Mon, 19 Mar 2007, Linus Torvalds wrote: So *please* don't believe that you can make it as cheap to have some automatic fixup of two sequences, one inlined and one as a call. It may look so when you look at the single instruction generated, but you're ignoring all the instructions

Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable

2007-03-19 Thread Linus Torvalds
On Mon, 19 Mar 2007, Andi Kleen wrote: Initially we had some bugs that accounted for near all failures, but they were all fixed in the latest version. No. The real bugs were that the people involved wouldn't even accept that unwinding information was inevitably buggy and/or incomplete.

Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable

2007-03-20 Thread Linus Torvalds
On Tue, 20 Mar 2007, Zachary Amsden wrote: void local_irq_restore(int enabled) { pda.intr_mask = enabled; /* * note there is a window here where softirqs are not processed by * the interrupt handler, but that is not a problem, since it will * get done here in the outer

Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable

2007-03-20 Thread Linus Torvalds
On Tue, 20 Mar 2007, Zachary Amsden wrote: Actually, I was thinking the irq handlers would just not mess around with eflags on the stack, just call the chip to ack the interrupt and re-enable hardware interrupts when they left, since that is free anyway with the iret. No can do. Think

Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable

2007-03-20 Thread Linus Torvalds
On Tue, 20 Mar 2007, Andi Kleen wrote: No, me and Jan fixed all reported bugs as far as I know. No you did not. You didn't fix the ones I reported. Which is why it got removed, and will not get added back until there is another maintainer. The ones I reported were all about trusting the

Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable

2007-03-20 Thread Linus Torvalds
On Tue, 20 Mar 2007, Andi Kleen wrote: The code never did that. In fact many of the problems we had initially especially came out of that -- the fallback code that would handle this case wasn't fully correct. I don't keep my emails any more, but you *never* fixed the problems in

Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable

2007-03-20 Thread Linus Torvalds
On Tue, 20 Mar 2007, Andi Kleen wrote: So what is your proposed alternative to handle long backtraces? You didn't answer that question. Please do, I'm curious about your thoughts in this area. the thing is, I'd rather see a long backtrace that is hard to decipher but that *never* *ever*

Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable

2007-03-20 Thread Linus Torvalds
On Tue, 20 Mar 2007, Andi Kleen wrote: On Tue, Mar 20, 2007 at 11:49:39AM -0700, Linus Torvalds wrote: the thing is, I'd rather see a long backtrace that is hard to decipher but that *never* *ever* causes any additional problems, over a pretty one. Well it causes additional problems

Re: [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable

2007-03-20 Thread Linus Torvalds
On Tue, 20 Mar 2007, Andi Kleen wrote: Linus is worried about the unwinder crashing -- that wouldn't help with that. And to make it clear: this is not a theoretical worry. It happened many times over the months the unwinder was in. It was supposed to help debugging, but it made bugs that

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

2007-07-23 Thread Linus Torvalds
On Mon, 23 Jul 2007, Andrew Morton wrote: It'd be nice to get a clean trace. Are you able to obtain the full trace with CONFIG_FRAME_POINTER=y? If you are talking about http://userweb.kernel.org/~akpm/dsc03659.jpg then I think that _is_ a full trace. It's certainly not very

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

2007-07-24 Thread Linus Torvalds
On Tue, 24 Jul 2007, Adrian Bunk wrote: buffered_rmqueue() and prep_new_page() are static functions with only one caller each, and for the normal non-debug case it's a really nice optimization to have them inlined automatically. I'm not at all sure I agree. Inlining big functions

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

2007-07-24 Thread Linus Torvalds
On Tue, 24 Jul 2007, Andrew Morton wrote: I guess this was the bug: Looks very likely to me. Mike, Alexey, does this fix things for you? Linus - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

2007-07-24 Thread Linus Torvalds
On Tue, 24 Jul 2007, Andrew Morton wrote: fwiw, -fno-inline-functions-called-once (who knew?) takes i386 allnoconfig vmlinux .text from 928360 up to 955362 bytes (27k larger). A surprisingly large increase - I wonder if it did something dumb. It appears to still correctly inline those

Re: 2.6.20-2.6.21 - networking dies after random time

2007-07-24 Thread Linus Torvalds
On Tue, 24 Jul 2007, Ingo Molnar wrote: please try the patch below instead. I'm hoping this is just a let's see if the behavior changes patch, not something that you think should be applied if it fixes something? This patch looks like it is trying to paper over (rather than fix) some

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

2007-07-24 Thread Linus Torvalds
On Tue, 24 Jul 2007, Andi Kleen wrote: There's probably a --param where it can be tweaked exactly. The problem is that --params tend to be very gcc version specific and might do something completely different on a newer or older version. So it's better not to use them. I agree

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

2007-07-24 Thread Linus Torvalds
On Tue, 24 Jul 2007, Adrian Bunk wrote: But do we care so much that it's worth inlining something like buffered_rmqueue()? ... Where is the problem with having buffered_rmqueue() inlined? In this case, it was a pain to just even try to find the call chain, or read the asm. I would

Re: 2.6.23-rc1: BUG_ON in kmap_atomic_prot()

2007-07-26 Thread Linus Torvalds
On Thu, 26 Jul 2007, Adrian Bunk wrote: So maybe I'm old-fashioned and crazy, but readability of the asm result actually is a worthwhile goal. Not because we care directly, but because I'd like to encourage people to do it, due to the *indirect* benefits. This would lead to people

Re: [PATCH] make atomic_t volatile on all architectures

2007-08-09 Thread Linus Torvalds
On Thu, 9 Aug 2007, Jerry Jiang wrote: and still not to said Why the *volatile-accesses-in-code* is acceptable I don't think volatile is necessarily wonderful in code _either_. So I think the atomic_read() issue would be even better off if we just made sure everybody behaves well and has

Re: [PATCH] make atomic_t volatile on all architectures

2007-08-09 Thread Linus Torvalds
On Thu, 9 Aug 2007, Chuck Ebbert wrote: You can use this forget() macro to make the compiler reread a variable: #define forget(var) asm volatile ( : =m(var)) No. That will also make the compiler forget any previous writes to it, so it changes behaviour. You'd have to use +m.

RE: [PATCH 9/24] make atomic_read() behave consistently on ia64

2007-08-10 Thread Linus Torvalds
On Fri, 10 Aug 2007, Luck, Tony wrote: Here are the functions in which they occur in the object file. You may have to chase down some inlining to find the function that actually uses atomic_*(). Could you just make the atomic_read() and atomic_set() functions be inline functions instead?

Re: [PATCH] make atomic_t volatile on all architectures

2007-08-12 Thread Linus Torvalds
On Sun, 12 Aug 2007, Segher Boessenkool wrote: Note that last line. Segher, how about you just accept that Linux uses gcc as per reality, and that sometimes the reality is different from your expectations? +m works. We use it. It's better than the alternatives. Pointing to stale

Re: [PATCH] make atomic_t volatile on all architectures

2007-08-12 Thread Linus Torvalds
On Sun, 12 Aug 2007, Martin Schwidefsky wrote: The duplication =m and m with the same constraint is rather annoying. It's not only annoying, it causes gcc to generate bad code too. At least certain versions of gcc will generate the address *twice*, even if there is obviously only one

Re: [PATCH] make atomic_t volatile on all architectures

2007-08-12 Thread Linus Torvalds
On Sun, 12 Aug 2007, Segher Boessenkool wrote: It works _most of the time_. It used to have problems. Gcc has had problems in various areas. Ask Martin. Oh you don't even have to, he told you two mails ago. My last mail simply pointed out that this isn't a GCC

Re: [PATCH] make atomic_t volatile on all architectures

2007-08-12 Thread Linus Torvalds
On Sun, 12 Aug 2007, Segher Boessenkool wrote: Yeah. Compiler errors are more annoying though I dare say ;-) Actually, compile-time errors are fine, and easy to work around. *Much* more annoying is when gcc actively generates subtly bad code. We've had use-after-free issues due to

Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures

2007-08-16 Thread Linus Torvalds
On Fri, 17 Aug 2007, Paul Mackerras wrote: Volatile doesn't mean it can't be reordered; volatile means the accesses can't be eliminated. It also does limit re-ordering. Of course, since *normal* accesses aren't necessarily limited wrt re-ordering, the question then becomes one of with

Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures

2007-08-16 Thread Linus Torvalds
On Fri, 17 Aug 2007, Paul Mackerras wrote: I'm really surprised it's as much as a few K. I tried it on powerpc and it only saved 40 bytes (10 instructions) for a G5 config. One of the things that volatile generally screws up is a simple volatile int i; i++; which a

Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures

2007-08-16 Thread Linus Torvalds
On Fri, 17 Aug 2007, Nick Piggin wrote: I'm surprised too. Numbers were from the ...use asm() like the other atomic operations already do thread. According to them, textdata bss dec hex filename 3434150 249176 176128 3859454 3ae3fe atomic_normal/vmlinux 3436203

Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures

2007-08-17 Thread Linus Torvalds
On Fri, 17 Aug 2007, Nick Piggin wrote: That's not obviously just taste to me. Not when the primitive has many (perhaps, the majority) of uses that do not require said barriers. And this is not solely about the code generation (which, as Paul says, is relatively minor even on x86). I

Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures

2007-08-17 Thread Linus Torvalds
On Sat, 18 Aug 2007, Satyam Sharma wrote: No code does (or would do, or should do): x.counter++; on an atomic_t x; anyway. That's just an example of a general problem. No, you don't use x.counter++. But you *do* use if (atomic_read(x) = 1) and loading into a register

Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures

2007-08-18 Thread Linus Torvalds
On Sat, 18 Aug 2007, Paul E. McKenney wrote: One of the gcc guys claimed that he thought that the two-instruction sequence would be faster on some x86 machines. I pointed out that there might be a concern about code size. I chose not to point out that people might also care about the

Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures

2007-08-20 Thread Linus Torvalds
On Mon, 20 Aug 2007, Chris Snook wrote: What about barrier removal? With consistent semantics we could optimize a fair amount of code. Whether or not that constitutes premature optimization is open to debate, but there's no question we could reduce our register wiping in some places. Why

Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures

2007-08-21 Thread Linus Torvalds
On Tue, 21 Aug 2007, Chris Snook wrote: Moore's law is definitely working against us here. Register counts, pipeline depths, core counts, and clock multipliers are all increasing in the long run. At some point in the future, barrier() will be universally regarded as a hammer too big for

Re: [PATCH] sky2: don't clear phy power bits

2007-08-21 Thread Linus Torvalds
On Tue, 21 Aug 2007, Stephen Hemminger wrote: There are special PHY settings available on Yukon EC-U chip that should not get cleared. This should solve mysterious errors on some motherboards (like Gigabyte DS-3). Ok, applied. However: - now all accesses to GPHY_CTRL are 8-bit (it used

Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures

2007-08-24 Thread Linus Torvalds
On Fri, 24 Aug 2007, Denys Vlasenko wrote: No, you don't use x.counter++. But you *do* use if (atomic_read(x) = 1) and loading into a register is stupid and pointless, when you could just do it as a regular memory-operand to the cmp instruction. It doesn't mean that (volatile

Re: [PATCH] i386: Fix a couple busy loops in mach_wakecpu.h:wait_for_init_deassert()

2007-08-24 Thread Linus Torvalds
On Fri, 24 Aug 2007, Denys Vlasenko wrote: So you are ok with compiler propagating n1 to n2 here: n1 += atomic_read(x); other_variable++; n2 += atomic_read(x); without accessing x second time. What's the point? Any sane coder will say that explicitly anyway: No. This is a common

Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures

2007-09-10 Thread Linus Torvalds
On Mon, 10 Sep 2007, Denys Vlasenko wrote: static inline int qla2x00_wait_for_loop_ready(scsi_qla_host_t *ha) { int return_status = QLA_SUCCESS; unsigned long loop_timeout ; scsi_qla_host_t *pha = to_qla_parent(ha); /* wait for 5 min at the max for

Re: tcp bw in 2.6

2007-10-01 Thread Linus Torvalds
On Mon, 1 Oct 2007, Larry McVoy wrote: but the client looks like connect(3, {sa_family=AF_INET, sin_port=htons(31235), sin_addr=inet_addr(10.3.9.1)}, 16) = 0 read(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 1048576) = 2896 read(3,

Re: tcp bw in 2.6

2007-10-02 Thread Linus Torvalds
On Tue, 2 Oct 2007, Larry McVoy wrote: Interesting data point. My test case is like this: server bind listen while (newsock = accept...) transfer() client connect transfer If the server side is the source of the data, i.e, it's

Re: tcp bw in 2.6

2007-10-02 Thread Linus Torvalds
On Tue, 2 Oct 2007, Larry McVoy wrote: tcpdump is a good idea, take a look at this. The window starts out at 46 and never opens up in my test case, but in the rsh case it starts out the same but does open up. Ideas? I don't think that's an issue, since you only send one way. The window

Re: tcp bw in 2.6

2007-10-02 Thread Linus Torvalds
On Tue, 2 Oct 2007, Larry McVoy wrote: No HP in the mix. It's got nothing to do with hp, nor to do with rsh, it has everything to do with the direction the data is flowing. Can you tcpdump both cases and send snippets (both of steady-state, and the initial connect)?

Re: tcp bw in 2.6

2007-10-02 Thread Linus Torvalds
On Tue, 2 Oct 2007, Wayne Scott wrote: The slow set was done like this: on ia64: netcat -l -p /dev/null on work: netcat ia64 /dev/zero That sounds wrong. Larry claims the slow case is when the side that did accept() does the sending, the above has the listener just

Re: Top 10 kernel oopses for the week ending January 5th, 2008

2008-01-07 Thread Linus Torvalds
On Mon, 7 Jan 2008, Kevin Winchester wrote: J. Bruce Fields wrote: Is there any good basic documentation on this to point people at? I would second this question. I see people decode oops on lkml often enough, but I've never been entirely sure how its done. Is it somewhere in

Re: Top 10 kernel oopses for the week ending January 5th, 2008

2008-01-08 Thread Linus Torvalds
On Tue, 8 Jan 2008, Arjan van de Ven wrote: I've made life easier for those using the www.kerneloops.org website; at least for x86 oopses the website now does this for you and shows the decoded Code: line in the raw oops data: http://www.kerneloops.org/raw.php?rawid=2716 Cool. One

Re: Top 10 kernel oopses for the week ending January 5th, 2008

2008-01-08 Thread Linus Torvalds
On Tue, 8 Jan 2008, Arjan van de Ven wrote: the database has the information so it's just a matter of slightly different php code ;) Before I do that... do you want the BUG's separate, part of the warnings or part of the oopses? (I rather make this change once ;) I'd like them all

Re: Top 10 kernel oopses for the week ending January 5th, 2008

2008-01-08 Thread Linus Torvalds
On Tue, 8 Jan 2008, Arjan van de Ven wrote: ok done; I had to fizzle a bit because some things aren't *exactly* a BUG() statement but I track them anyway (things like the sleeping in invalid context check), so I had to somewhat arbitrarily assign categories for those. I might fine tune

Re: [GIT] Networking

2015-06-24 Thread Linus Torvalds
On Wed, Jun 24, 2015 at 6:39 AM, David Miller da...@davemloft.net wrote: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master Just going through the conflicts, I see commit 7193a141eb74 (IB/mlx4: Set VF to read from QP counters), and wonder... Is that code really supposed

Fwd: [PATCH] net:usb:cdc_ncm: fix that tag Huawei devices as wwan

2015-06-14 Thread Linus Torvalds
Hmm. Oliver is marked as the maintainer of the USB CDC code, but others have touched it more recently. So I'm just wildly adding people to the cc to comment on this patch and maybe apply it. Oliver/David/Ben/Bjørn? Linus -- Forwarded message -- From: xiaomao

Re: [PULL] virtio/vhost: cross endian support

2015-07-01 Thread Linus Torvalds
On Wed, Jul 1, 2015 at 12:02 PM, Linus Torvalds torva...@linux-foundation.org wrote: Doing a unconditional byte swap is faster and simpler than the crazy conditionals. Unconditional endianness not only makes for simpler and faster code, it also ends up being easier to debug and add things like

Re: [PULL] virtio/vhost: cross endian support

2015-07-01 Thread Linus Torvalds
On Wed, Jul 1, 2015 at 2:31 AM, Michael S. Tsirkin m...@redhat.com wrote: virtio/vhost: cross endian support Ugh. Does this really have to be dynamic? Can't virtio do the sane thing, and just use a _fixed_ endianness? Doing a unconditional byte swap is faster and simpler than the crazy

Re: [PULL] virtio/vhost: cross endian support

2015-07-03 Thread Linus Torvalds
On Fri, Jul 3, 2015 at 12:59 AM, Michael S. Tsirkin m...@redhat.com wrote: Linus, could you please clarify whether making the feature depend on the cross-endian guest support would address your comment, and whether you think this can be merged as is, and the dependency added after -rc1?

rtnl_mutex deadlock?

2015-08-04 Thread Linus Torvalds
Sorry for the spamming of random rtnetlink people, but I just resumed my laptop at PDX, and networking was dead. It looks like a deadlock on rtnl_mutex, possibly due to some error path not releasing the lock. No network op was making any progress, and as you can see from the attached sysrq-w, it

Re: rtnl_mutex deadlock?

2015-08-05 Thread Linus Torvalds
On Wed, Aug 5, 2015 at 9:43 AM, Jiri Pirko j...@resnulli.us wrote: Indeed. Most probably, NETLINK_CB(skb).portid got zeroed. Linus, are you able to reproduce this or is it a one-time issue? I don't think I'm able to reproduce this, it's happened only once so far. Linus -- To

[FWD] PROBLEM: there exists a wrong return value of function mkiss_open()

2015-08-10 Thread Linus Torvalds
I don't know how many people care about hamradio, but the report that mkiss_open() returns success even when register_netdev() fails seems entirely true. The email was just not sent to the right people.. Linus On Sun, Aug 9, 2015 at 5:08 PM, RUC_Soft_Sec zy900...@163.com

Re: [GIT] Networking

2015-10-28 Thread Linus Torvalds
On Wed, Oct 28, 2015 at 3:32 PM, David Miller wrote: > > This may look a bit scary this late in the release cycle, but as is typically > the case it's predominantly small driver fixes all over the place. Christ people. This is just sh*t. The conflict I get is due to stupid

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-10-30 Thread Linus Torvalds
On Fri, Oct 30, 2015 at 2:23 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > On Fri, Oct 30, 2015 at 2:02 PM, Al Viro <v...@zeniv.linux.org.uk> wrote: >> >> Your variant has 1:64 ratio; obviously better than now, but we can actually >> do 1:bits-p

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-10-30 Thread Linus Torvalds
On Fri, Oct 30, 2015 at 2:02 PM, Al Viro wrote: > > Your variant has 1:64 ratio; obviously better than now, but we can actually > do 1:bits-per-cacheline quite easily. Ok, but in that case you end up needing a counter for each cacheline too (to count how many bits, in

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-10-30 Thread Linus Torvalds
On Fri, Oct 30, 2015 at 3:33 PM, Al Viro <v...@zeniv.linux.org.uk> wrote: > On Fri, Oct 30, 2015 at 02:50:46PM -0700, Linus Torvalds wrote: > >> Anyway. This is a pretty simple patch, and I actually think that we >> could just get rid of the "next_fd" logic enti

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-11-01 Thread Linus Torvalds
On Sun, Nov 1, 2015 at 4:24 PM, Al Viro wrote: > > This ought to be a bit cleaner. Eric, could you test the variant below on > your > setup? I'd love to see the numbers, but at the same time I really can't say I love your patch. I've merged my own two patches for now

Re: [GIT PULL] parisc architecture updates for v4.3

2015-11-03 Thread Linus Torvalds
On Tue, Nov 3, 2015 at 1:33 PM, David Miller wrote: > >> David: the issue wrt XPS is this: >> >>#define XPS_MIN_MAP_ALLOC ((L1_CACHE_BYTES - sizeof(struct xps_map)) \ >>/ sizeof(u16)) >> >> Comments? > > The PARISC folks did discuss this with us networking

Re: [GIT] Networking

2015-11-03 Thread Linus Torvalds
On Tue, Nov 3, 2015 at 4:53 AM, Hannes Frederic Sowa wrote: > > And furthermore we don't actually have to rely on CSE if we want to, our > overflow checks could look much more simpler as in "ordinary" C code > because we tell the compiler that signed overflow is

Re: [GIT] Networking

2015-11-03 Thread Linus Torvalds
On Tue, Nov 3, 2015 at 12:05 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > result = add_overflow( > mul_overflow(sec, SEC_CONVERSION, ), > mul_overflow(nsec, NSEC_CONVERSION, ), > ); > > return overflow ? MAX_JIFFIES : resu

Re: [GIT PULL] parisc architecture updates for v4.3

2015-11-03 Thread Linus Torvalds
On Sun, Oct 25, 2015 at 4:49 AM, Helge Deller wrote: > > please pull some patches for the parisc architecture for kernel v4.3 from: So no way was I going to pull that for 4.3, and I delayed it to the merge window. However, even now that we're in the merge window, and I look at it

Re: [GIT PULL] parisc architecture updates for v4.3

2015-11-03 Thread Linus Torvalds
On Tue, Nov 3, 2015 at 3:03 PM, Helge Deller wrote: > > Sadly it's nowhere clearly documented how big the L1 cacheline of parisc > really is. Wow. Particularly that "it might actually be 16 bytes" from the thread according to John David Anglin. I didn't expect anybody to really

Re: [GIT] Networking

2015-11-02 Thread Linus Torvalds
On Mon, Nov 2, 2015 at 1:16 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > On Mon, Nov 2, 2015 at 12:34 PM, Andy Lutomirski <l...@kernel.org> wrote: >> >> Getting overflow checking right in more complicated cases is a PITA. > > No it is not. Not for

Re: [GIT] Networking

2015-11-02 Thread Linus Torvalds
On Mon, Nov 2, 2015 at 12:34 PM, Andy Lutomirski <l...@kernel.org> wrote: > On 10/28/2015 02:39 AM, Linus Torvalds wrote: >> >> I'm sorry, but we don't add idiotic new interfaces like this for >> idiotic new code like that. > > > As one of the people who encour

Re: [GIT] Networking

2015-11-02 Thread Linus Torvalds
On Mon, Nov 2, 2015 at 2:14 PM, Hannes Frederic Sowa wrote: > > overflow_usub was part of a larger header I already prepared to offer > support for *all* overflow_* checking builtins. While fixing this IPv6 > bug I thought I could hopefully introduce this interface

Re: [GIT] Networking

2015-11-02 Thread Linus Torvalds
On Mon, Nov 2, 2015 at 4:56 PM, Benjamin Herrenschmidt wrote: > > Also how much of the problem is simply that the function signature > (naming and choice of arguments) just plain sucks ? Some of that is pretty much inevitable. C really has no good way to return

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-10-30 Thread Linus Torvalds
On Thu, Oct 29, 2015 at 5:35 AM, Eric Dumazet wrote: > > Well, I already tested the O_FD_FASTALLOC thing, and I can tell you > find_next_zero_bit() is nowhere to be found in kernel profiles anymore. > It also lowers time we hold the fd array spinlock while doing fd alloc.

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-10-31 Thread Linus Torvalds
On Sat, Oct 31, 2015 at 12:34 PM, Al Viro wrote: > > ... and here's the current variant of mine. Ugh. I really liked how simple mine ended up being. Yours is definitely not. And based on the profiles from Eric, finding the fd is no longer the problem even with my

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-10-31 Thread Linus Torvalds
On Sat, Oct 31, 2015 at 1:45 PM, Eric Dumazet wrote: > 13.84% opensock [kernel.kallsyms][k] queued_spin_lock_slowpath > | > --- queued_spin_lock_slowpath > | > |--99.97%--

  1   2   3   4   >