* bitkeeper comments
@ 2003-09-01 4:15 Albert Cahalan
2003-09-01 14:07 ` Larry McVoy
0 siblings, 1 reply; 18+ messages in thread
From: Albert Cahalan @ 2003-09-01 4:15 UTC (permalink / raw)
To: linux-kernel mailing list; +Cc: Linus Torvalds, ak, lm
This just got into BitKeeper, about 10 hours ago:
> [PATCH] x86-64 update
>
> Make everything compile and boot again.
>
> The earlier third party ioport.c changes unfortunately
> didn't even compile, fix that too.
>
> - Update defconfig
> - Some minor cleanup
> - Introduce physid_t for APIC masks (fixes UP kernels)
> - Finish ioport.c merge and fix compilation
Several days ago, I mailed Andi Kleen a build log which
showed that ioport.c builds perfectly well on x86-64.
The whole 2.6.0-test4 kernel does in fact, as downloaded
from kernel.org. Andi Kleen agreed...
...and now this comment gets submitted to Linus, ending
up in BitKeeper. I'd like this changed. I realize that
it may be a rather difficult thing to change at this point,
but it is clearly wrong.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: bitkeeper comments 2003-09-01 4:15 bitkeeper comments Albert Cahalan @ 2003-09-01 14:07 ` Larry McVoy 2003-09-01 15:26 ` Albert Cahalan 0 siblings, 1 reply; 18+ messages in thread From: Larry McVoy @ 2003-09-01 14:07 UTC (permalink / raw) To: Albert Cahalan; +Cc: linux-kernel mailing list, Linus Torvalds, ak, lm On Mon, Sep 01, 2003 at 12:15:30AM -0400, Albert Cahalan wrote: > This just got into BitKeeper, about 10 hours ago: > > > [PATCH] x86-64 update > > > > Make everything compile and boot again. > > > > The earlier third party ioport.c changes unfortunately > > didn't even compile, fix that too. > > > > - Update defconfig > > - Some minor cleanup > > - Introduce physid_t for APIC masks (fixes UP kernels) > > - Finish ioport.c merge and fix compilation > > Several days ago, I mailed Andi Kleen a build log which > showed that ioport.c builds perfectly well on x86-64. > The whole 2.6.0-test4 kernel does in fact, as downloaded > from kernel.org. Andi Kleen agreed... > > ...and now this comment gets submitted to Linus, ending > up in BitKeeper. I'd like this changed. I realize that > it may be a rather difficult thing to change at this point, > but it is clearly wrong. If you want the comments changed I can do that on bkbits.net and anyone who grabs the update from there will get the new comments. If you want the patch gone out of BK anyone can do that with a cset -x. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: bitkeeper comments 2003-09-01 14:07 ` Larry McVoy @ 2003-09-01 15:26 ` Albert Cahalan 2003-09-01 15:46 ` Larry McVoy 0 siblings, 1 reply; 18+ messages in thread From: Albert Cahalan @ 2003-09-01 15:26 UTC (permalink / raw) To: Larry McVoy Cc: lm, Albert Cahalan, linux-kernel mailing list, Linus Torvalds, ak On Mon, 2003-09-01 at 10:07, Larry McVoy wrote: > On Mon, Sep 01, 2003 at 12:15:30AM -0400, Albert Cahalan wrote: > > This just got into BitKeeper, about 10 hours ago: > > > > > [PATCH] x86-64 update > > > > > > Make everything compile and boot again. > > > > > > The earlier third party ioport.c changes unfortunately > > > didn't even compile, fix that too. > > > > > > - Update defconfig > > > - Some minor cleanup > > > - Introduce physid_t for APIC masks (fixes UP kernels) > > > - Finish ioport.c merge and fix compilation > > > > Several days ago, I mailed Andi Kleen a build log which > > showed that ioport.c builds perfectly well on x86-64. > > The whole 2.6.0-test4 kernel does in fact, as downloaded > > from kernel.org. Andi Kleen agreed... > > > > ...and now this comment gets submitted to Linus, ending > > up in BitKeeper. I'd like this changed. I realize that > > it may be a rather difficult thing to change at this point, > > but it is clearly wrong. > > If you want the comments changed I can do that on bkbits.net and anyone > who grabs the update from there will get the new comments. If you want > the patch gone out of BK anyone can do that with a cset -x. The code itself is OK I guess; the physid_t changes may well be important, although they could be redone. It's the comment that bugs me, specifically: "Make everything compile and boot again." "The earlier third party ioport.c changes unfortunately didn't even compile, fix that too." "Finish ioport.c merge and fix compilation" (BTW, there's a bit more beyond the end of what I quoted) I'm OK with whatever ensures that somebody looking back through the BitKeeper logs isn't going to come to the conclusion that I broke something. Um, not everybody will grab updates from bkbits.net, right? Pardon me for being clueless about BitKeeper, but is there some command Andi or Linus could run? ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: bitkeeper comments 2003-09-01 15:26 ` Albert Cahalan @ 2003-09-01 15:46 ` Larry McVoy 2003-09-01 15:56 ` Christoph Hellwig ` (2 more replies) 0 siblings, 3 replies; 18+ messages in thread From: Larry McVoy @ 2003-09-01 15:46 UTC (permalink / raw) To: Albert Cahalan; +Cc: Larry McVoy, linux-kernel mailing list, Linus Torvalds, ak On Mon, Sep 01, 2003 at 11:26:55AM -0400, Albert Cahalan wrote: > I'm OK with whatever ensures that somebody looking back > through the BitKeeper logs isn't going to come to the > conclusion that I broke something. > > Um, not everybody will grab updates from bkbits.net, > right? Pardon me for being clueless about BitKeeper, > but is there some command Andi or Linus could run? Unfortunately the checkin comments themselves are not revision controlled. You have to run a command on each repository that needs to be fixed, if you send me the desired comments I'll post the command. Then if Linus or Marcelo says do it I'll do it on bkbits.net. That should be good enough, the logs there are what people tend to browse. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: bitkeeper comments 2003-09-01 15:46 ` Larry McVoy @ 2003-09-01 15:56 ` Christoph Hellwig 2003-09-01 15:59 ` Larry McVoy 2003-09-01 16:59 ` Bug in linux-2.6.0-test4 ? dada1 2003-09-01 18:08 ` bitkeeper comments Albert Cahalan 2 siblings, 1 reply; 18+ messages in thread From: Christoph Hellwig @ 2003-09-01 15:56 UTC (permalink / raw) To: Larry McVoy, Albert Cahalan, Larry McVoy, linux-kernel mailing list, Linus Torvalds, ak On Mon, Sep 01, 2003 at 08:46:46AM -0700, Larry McVoy wrote: > Unfortunately the checkin comments themselves are not revision controlled. > You have to run a command on each repository that needs to be fixed, > if you send me the desired comments I'll post the command. Then if > Linus or Marcelo says do it I'll do it on bkbits.net. That should be good > enough, the logs there are what people tend to browse. WTF? Andi probably had a reason to put this in. If Albert feels pissed of he should shred his repo instead of doing stupid censorship crap. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: bitkeeper comments 2003-09-01 15:56 ` Christoph Hellwig @ 2003-09-01 15:59 ` Larry McVoy 2003-09-01 16:02 ` Christoph Hellwig 2003-09-01 16:33 ` Alan Cox 0 siblings, 2 replies; 18+ messages in thread From: Larry McVoy @ 2003-09-01 15:59 UTC (permalink / raw) To: Christoph Hellwig, Albert Cahalan, Larry McVoy, linux-kernel mailing list, Linus Torvalds, ak On Mon, Sep 01, 2003 at 04:56:58PM +0100, Christoph Hellwig wrote: > On Mon, Sep 01, 2003 at 08:46:46AM -0700, Larry McVoy wrote: > > Unfortunately the checkin comments themselves are not revision controlled. > > You have to run a command on each repository that needs to be fixed, > > if you send me the desired comments I'll post the command. Then if > > Linus or Marcelo says do it I'll do it on bkbits.net. That should be good > > enough, the logs there are what people tend to browse. > > WTF? Andi probably had a reason to put this in. If Albert feels pissed > of he should shred his repo instead of doing stupid censorship crap. Hey, I'm not in the middle of this because I don't understand who is right and it's not my place to make that call. I said "if Linus or Marcelo says do it" specifically for the case that there is some hanky panky going on. On the other hand, it's perfectly possible that the wrong comment got stuck in there and if that's the case why shouldn't it get fixed? -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: bitkeeper comments 2003-09-01 15:59 ` Larry McVoy @ 2003-09-01 16:02 ` Christoph Hellwig 2003-09-01 16:11 ` Larry McVoy ` (2 more replies) 2003-09-01 16:33 ` Alan Cox 1 sibling, 3 replies; 18+ messages in thread From: Christoph Hellwig @ 2003-09-01 16:02 UTC (permalink / raw) To: Larry McVoy, Albert Cahalan, Larry McVoy, linux-kernel mailing list, Linus Torvalds, ak On Mon, Sep 01, 2003 at 08:59:15AM -0700, Larry McVoy wrote: > Hey, I'm not in the middle of this because I don't understand who is right > and it's not my place to make that call. I doesn't matter who's actually right. If Andi was wrong Albert can demand a apology from him or sue him or whater (not that his name is actually mentioned in the message). But we're not going to retroactively censor commit messages. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: bitkeeper comments 2003-09-01 16:02 ` Christoph Hellwig @ 2003-09-01 16:11 ` Larry McVoy 2003-09-01 16:22 ` Geert Uytterhoeven 2003-09-01 16:15 ` Andi Kleen 2003-09-01 16:59 ` Linus Torvalds 2 siblings, 1 reply; 18+ messages in thread From: Larry McVoy @ 2003-09-01 16:11 UTC (permalink / raw) To: Christoph Hellwig, Albert Cahalan, Larry McVoy, linux-kernel mailing list, Linus Torvalds, ak On Mon, Sep 01, 2003 at 05:02:18PM +0100, Christoph Hellwig wrote: > On Mon, Sep 01, 2003 at 08:59:15AM -0700, Larry McVoy wrote: > > Hey, I'm not in the middle of this because I don't understand who is right > > and it's not my place to make that call. > > I doesn't matter who's actually right. If Andi was wrong Albert can > demand a apology from him or sue him or whater (not that his name is > actually mentioned in the message). > > But we're not going to retroactively censor commit messages. I'm confused, I thought Linus/Marcelo/Andrew were the tree maintainers. As long as they are they get to make the call, not you (or me or whoever). -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: bitkeeper comments 2003-09-01 16:11 ` Larry McVoy @ 2003-09-01 16:22 ` Geert Uytterhoeven 0 siblings, 0 replies; 18+ messages in thread From: Geert Uytterhoeven @ 2003-09-01 16:22 UTC (permalink / raw) To: Larry McVoy Cc: Christoph Hellwig, Albert Cahalan, linux-kernel mailing list, Linus Torvalds, ak On Mon, 1 Sep 2003, Larry McVoy wrote: > On Mon, Sep 01, 2003 at 05:02:18PM +0100, Christoph Hellwig wrote: > > On Mon, Sep 01, 2003 at 08:59:15AM -0700, Larry McVoy wrote: > > > Hey, I'm not in the middle of this because I don't understand who is right > > > and it's not my place to make that call. > > > > I doesn't matter who's actually right. If Andi was wrong Albert can > > demand a apology from him or sue him or whater (not that his name is > > actually mentioned in the message). > > > > But we're not going to retroactively censor commit messages. > > I'm confused, I thought Linus/Marcelo/Andrew were the tree maintainers. > As long as they are they get to make the call, not you (or me or whoever). Retroactively changing a commit message may be a dangerous precedent. While there may be legitimate reasons (E.g. plain wrong comments or `actually this part was not written by x but by y'), one day The Evil Empire may claim we changed the evidence of who did what. Putting comments under revision control is another option, but may be too deep-involving... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: bitkeeper comments 2003-09-01 16:02 ` Christoph Hellwig 2003-09-01 16:11 ` Larry McVoy @ 2003-09-01 16:15 ` Andi Kleen 2003-09-01 16:59 ` Linus Torvalds 2 siblings, 0 replies; 18+ messages in thread From: Andi Kleen @ 2003-09-01 16:15 UTC (permalink / raw) To: Christoph Hellwig, Larry McVoy, Albert Cahalan, Larry McVoy, linux-kernel mailing list, Linus Torvalds, ak On Mon, Sep 01, 2003 at 05:02:18PM +0100, Christoph Hellwig wrote: > On Mon, Sep 01, 2003 at 08:59:15AM -0700, Larry McVoy wrote: > > Hey, I'm not in the middle of this because I don't understand who is right > > and it's not my place to make that call. > > I doesn't matter who's actually right. If Andi was wrong Albert can > demand a apology from him or sue him or whater (not that his name is > actually mentioned in the message). I was wrong in this case, although I partly blame Albert because he sneaked in x86-64 patches behind my back directly to Linus, which caused merging problems and resulted in this comment. -Andi ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: bitkeeper comments 2003-09-01 16:02 ` Christoph Hellwig 2003-09-01 16:11 ` Larry McVoy 2003-09-01 16:15 ` Andi Kleen @ 2003-09-01 16:59 ` Linus Torvalds 2003-09-01 17:23 ` Jakob Oestergaard 2 siblings, 1 reply; 18+ messages in thread From: Linus Torvalds @ 2003-09-01 16:59 UTC (permalink / raw) To: Christoph Hellwig Cc: Larry McVoy, Albert Cahalan, Larry McVoy, linux-kernel mailing list, ak On Mon, 1 Sep 2003, Christoph Hellwig wrote: > > But we're not going to retroactively censor commit messages. Actually, I do that all the time. In fact, it was I who asked Larry to add the "bk comment" command in to make it easy to do so. The thing is, it's hard to do after the message has already gone out into the public - but I fix up peoples email commentary by hand both in the email and often later after it has hit my BK tree too. I try to fix obvious typos, and just generally make the things more readable. And if the comment was wrong, then it should be fixed. Not because of any "censorship", but because it's misleading if the comment says it fixes something it doesn't fix - and that might make people overlook the _real_ thing the change does. Linus ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: bitkeeper comments 2003-09-01 16:59 ` Linus Torvalds @ 2003-09-01 17:23 ` Jakob Oestergaard 2003-09-01 17:28 ` Christoph Hellwig 0 siblings, 1 reply; 18+ messages in thread From: Jakob Oestergaard @ 2003-09-01 17:23 UTC (permalink / raw) To: Linus Torvalds Cc: Christoph Hellwig, Larry McVoy, Albert Cahalan, Larry McVoy, linux-kernel mailing list, ak On Mon, Sep 01, 2003 at 09:59:58AM -0700, Linus Torvalds wrote: > > On Mon, 1 Sep 2003, Christoph Hellwig wrote: > > > > But we're not going to retroactively censor commit messages. > > Actually, I do that all the time. In fact, it was I who asked Larry to add > the "bk comment" command in to make it easy to do so. > > The thing is, it's hard to do after the message has already gone out into > the public - but I fix up peoples email commentary by hand both in the > email and often later after it has hit my BK tree too. I try to fix > obvious typos, and just generally make the things more readable. > > And if the comment was wrong, then it should be fixed. Not because of any > "censorship", but because it's misleading if the comment says it fixes > something it doesn't fix - and that might make people overlook the _real_ > thing the change does. There is an important difference. If I send you a mail saying "X" and you change it to say "Y" and put "Y" in the source tree, fine. It was a mail between us, noone except you and me will know. If I think it's wrong, maybe I can make you submit "X" to the source tree instead, with an explanation. Everything that was ever publicly visible, stays publicly visible, even with the the revised comments, thanks to the revision history. But changing the source tree revision history retroactively, that's bad. It defies the purpose of revision control itself. The source tree is a public record. People will remember "this said 'Y' I'm sure, but now it says 'X', why is that?" - and noone can answer. History forgotten. It's your call, but I can certainly see why some feel bad about this. After all, we wouldn't want to edit the e-mail archives to remove all trace of what happened, either, would we? ;) Cheers, -- ................................................................ : jakob@unthought.net : And I see the elder races, : :.........................: putrid forms of man : : Jakob Østergaard : See him rise and claim the earth, : : OZ9ABN : his downfall is at hand. : :.........................:............{Konkhra}...............: ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: bitkeeper comments 2003-09-01 17:23 ` Jakob Oestergaard @ 2003-09-01 17:28 ` Christoph Hellwig 2003-09-01 17:40 ` Larry McVoy 0 siblings, 1 reply; 18+ messages in thread From: Christoph Hellwig @ 2003-09-01 17:28 UTC (permalink / raw) To: Jakob Oestergaard, Christoph Hellwig, Larry McVoy, Albert Cahalan, Larry McVoy, linux-kernel mailing list, ak On Mon, Sep 01, 2003 at 07:23:34PM +0200, Jakob Oestergaard wrote: > There is an important difference. > > If I send you a mail saying "X" and you change it to say "Y" and put "Y" > in the source tree, fine. It was a mail between us, noone except you > and me will know. If I think it's wrong, maybe I can make you submit > "X" to the source tree instead, with an explanation. > > Everything that was ever publicly visible, stays publicly visible, even > with the the revised comments, thanks to the revision history. > > But changing the source tree revision history retroactively, that's bad. > It defies the purpose of revision control itself. > > The source tree is a public record. People will remember "this said 'Y' > I'm sure, but now it says 'X', why is that?" - and noone can answer. > History forgotten. Yupp, that's what I meant. I certainly don't want a thought police on my source trees. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: bitkeeper comments 2003-09-01 17:28 ` Christoph Hellwig @ 2003-09-01 17:40 ` Larry McVoy 0 siblings, 0 replies; 18+ messages in thread From: Larry McVoy @ 2003-09-01 17:40 UTC (permalink / raw) To: Christoph Hellwig, Jakob Oestergaard, Albert Cahalan, Larry McVoy, linux-kernel mailing list, ak On Mon, Sep 01, 2003 at 06:28:27PM +0100, Christoph Hellwig wrote: > On Mon, Sep 01, 2003 at 07:23:34PM +0200, Jakob Oestergaard wrote: > > There is an important difference. > > > > If I send you a mail saying "X" and you change it to say "Y" and put "Y" > > in the source tree, fine. It was a mail between us, noone except you > > and me will know. If I think it's wrong, maybe I can make you submit > > "X" to the source tree instead, with an explanation. > > > > Everything that was ever publicly visible, stays publicly visible, even > > with the the revised comments, thanks to the revision history. > > > > But changing the source tree revision history retroactively, that's bad. > > It defies the purpose of revision control itself. > > > > The source tree is a public record. People will remember "this said 'Y' > > I'm sure, but now it says 'X', why is that?" - and noone can answer. > > History forgotten. > > Yupp, that's what I meant. I certainly don't want a thought police > on my source trees. Trivial w/ the current BK because the comments aren't versioned. Just have someone be elected as the archiver and have them have a cron job which pulls bkbits.net every 20 minutes or so. Then if the comments are ever changed your archive will have the originals. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: bitkeeper comments 2003-09-01 15:59 ` Larry McVoy 2003-09-01 16:02 ` Christoph Hellwig @ 2003-09-01 16:33 ` Alan Cox 2003-09-01 16:36 ` Larry McVoy 1 sibling, 1 reply; 18+ messages in thread From: Alan Cox @ 2003-09-01 16:33 UTC (permalink / raw) To: Larry McVoy Cc: Christoph Hellwig, Albert Cahalan, Linux Kernel Mailing List, Linus Torvalds, ak On Llu, 2003-09-01 at 16:59, Larry McVoy wrote: > Hey, I'm not in the middle of this because I don't understand who is right > and it's not my place to make that call. I said "if Linus or Marcelo says > do it" specifically for the case that there is some hanky panky going on. > On the other hand, it's perfectly possible that the wrong comment got > stuck in there and if that's the case why shouldn't it get fixed? Presumably in the abstract "if you care" case you can generate this change globally by excluding that changeset and all after, then reapplying it with a different comment then reapplying all that follow ? ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: bitkeeper comments 2003-09-01 16:33 ` Alan Cox @ 2003-09-01 16:36 ` Larry McVoy 0 siblings, 0 replies; 18+ messages in thread From: Larry McVoy @ 2003-09-01 16:36 UTC (permalink / raw) To: Alan Cox Cc: Larry McVoy, Christoph Hellwig, Albert Cahalan, Linux Kernel Mailing List, Linus Torvalds, ak On Mon, Sep 01, 2003 at 05:33:40PM +0100, Alan Cox wrote: > On Llu, 2003-09-01 at 16:59, Larry McVoy wrote: > > Hey, I'm not in the middle of this because I don't understand who is right > > and it's not my place to make that call. I said "if Linus or Marcelo says > > do it" specifically for the case that there is some hanky panky going on. > > On the other hand, it's perfectly possible that the wrong comment got > > stuck in there and if that's the case why shouldn't it get fixed? > > Presumably in the abstract "if you care" case you can generate this > change globally by excluding that changeset and all after, then > reapplying it with a different comment then reapplying all that follow ? Yup, that would work just fine. Anyone can do this. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ^ permalink raw reply [flat|nested] 18+ messages in thread
* Bug in linux-2.6.0-test4 ? 2003-09-01 15:46 ` Larry McVoy 2003-09-01 15:56 ` Christoph Hellwig @ 2003-09-01 16:59 ` dada1 2003-09-01 18:08 ` bitkeeper comments Albert Cahalan 2 siblings, 0 replies; 18+ messages in thread From: dada1 @ 2003-09-01 16:59 UTC (permalink / raw) To: linux-kernel, linux-net [-- Attachment #1: Type: text/plain, Size: 3849 bytes --] Hi all I have an annoying problem with a network server (TCP sockets) On some stress situation, LowMemory goes close to 0, and the whole machine freezes. When the sockets receive a lot of data, and the server is busy, the TCP stack just can use too many buffers (in LowMem). TCP stack uses "size-4096" buffers to store the datas, even if only one byte is coming from the network. I tried to change /proc/sys/net/ipv4/tcp_mem, without results. # echo "1000 10000 15000" >/proc/sys/net/ipv4/tcp_mem You can reproduce the problem with the test program attached. # gcc -o crash crash.c # ulimit -n 20000 # ./crash listen 8888 & # ./crash call 127.0.0.1:8888 & grep "size-4096 " /proc/slabinfo size-4096 40015 40015 4096 1 1 : tunables 24 12 0 : slabdata 40015 40015 0 (thats is 160 Mo, far more than the limit given in /proc/sys/net/ipv4/tcp_mem) grep TCP /proc/net/sockstat TCP: inuse 39996 orphan 0 tw 0 alloc 39997 mem 79986 What is the unit of 'mem' field ? Unless it is 2Ko, the numbers are wrong. How may I ask the kernel NOT to use more than 'X Mo' to store TCP messages ? Thanks Eric Dumazet /* * Program to freeze a linux box, by using all the LOWMEM * A bug on the tcp stack may be the reason * Use at your own risk !! */ /* Principles : A listener accepts incoming tcp sockets, write 40 bytes, and does nothing with them (no reading) A writer establish TCP sockets, sends some data (40 bytes), no more reading/writing */ #include <stdio.h> # include <sys/socket.h> # include <netinet/tcp.h> # include <arpa/inet.h> # include <netdb.h> # include <unistd.h> # include <string.h> /* * Usage : * crash listen port * crash call IP:port */ void usage(int code) { fprintf(stderr, "Usages :\n") ; fprintf(stderr, " crash listen port\n") ; fprintf(stderr, " crash call IP:port\n") ; exit(code) ; } const char some_data[40] = "some data.... just some data" ; void do_listener(const char *string) { int port = atoi(string) ; struct sockaddr_in host, from ; int fdlisten ; unsigned int total ; socklen_t fromlen ; memset(&host,0, sizeof(host)); host.sin_family = AF_INET; host.sin_port = htons(port); fdlisten = socket(AF_INET, SOCK_STREAM, 0) ; if (bind(fdlisten, (struct sockaddr *)&host, sizeof(host)) == -1) { perror("bind") ; return ; } listen(fdlisten, 10) ; for (total=0;;total++) { int nfd ; fromlen = sizeof(from) ; nfd = accept(fdlisten, (struct sockaddr *)&from, &fromlen) ; if (nfd == -1) break ; write(nfd, some_data, sizeof(some_data)) ; } printf("total=%u\n", total) ; pause() ; } void do_caller(const char *string) { union { int i ; char c[4] ; } u ; struct sockaddr_in dest; int a1, a2, a3, a4, port ; unsigned int total ; sscanf(string, "%d.%d.%d.%d:%d", &a1, &a2, &a3, &a4, &port) ; u.c[0] = a1 ; u.c[1] = a2 ; u.c[2] = a3 ; u.c[3] = a4 ; for (total=0;;total++) { int fd ; memset(&dest, 0, sizeof(dest)) ; dest.sin_family = AF_INET ; dest.sin_port = htons(port) ; dest.sin_addr.s_addr = u.i ; fd = socket(AF_INET, SOCK_STREAM, 0) ; if (fd == -1) break ; if (connect(fd, (struct sockaddr *)&dest, sizeof(dest)) == -1) { perror("connect") ; break ; } write(fd, some_data, sizeof(some_data)) ; } printf("total=%u\n", total) ; pause() ; } int main(int argc, char *argv[]) { int listener ; int caller ; if (argc != 3) { usage(1); } listener = !strcmp(argv[1], "listen") ; caller = !strcmp(argv[1], "call") ; if (listener) { do_listener(argv[2]) ; } else if (caller) { do_caller(argv[2]) ; } else usage(2) ; return 0 ; } /********************************************************************/ [-- Attachment #2: crash.c --] [-- Type: text/plain, Size: 2624 bytes --] /* * Program to freeze a linux box, by using all the LOWMEM * A bug on the tcp stack may be the reason * Use at your own risk !! */ /* Principles : A listener accepts incoming tcp sockets, write 40 bytes, and does nothing with them (no reading) A writer establish TCP sockets, sends some data (40 bytes), no more reading/writing */ #include <stdio.h> # include <sys/socket.h> # include <netinet/tcp.h> # include <arpa/inet.h> # include <netdb.h> # include <unistd.h> # include <string.h> /* * Usage : * crash listen port * crash call IP:port */ void usage(int code) { fprintf(stderr, "Usages :\n") ; fprintf(stderr, " crash listen port\n") ; fprintf(stderr, " crash call IP:port\n") ; exit(code) ; } const char some_data[40] = "some data.... just some data" ; void do_listener(const char *string) { int port = atoi(string) ; struct sockaddr_in host, from ; int fdlisten ; unsigned int total ; socklen_t fromlen ; memset(&host,0, sizeof(host)); host.sin_family = AF_INET; host.sin_port = htons(port); fdlisten = socket(AF_INET, SOCK_STREAM, 0) ; if (bind(fdlisten, (struct sockaddr *)&host, sizeof(host)) == -1) { perror("bind") ; return ; } listen(fdlisten, 10) ; for (total=0;;total++) { int nfd ; fromlen = sizeof(from) ; nfd = accept(fdlisten, (struct sockaddr *)&from, &fromlen) ; if (nfd == -1) break ; write(nfd, some_data, sizeof(some_data)) ; } printf("total=%u\n", total) ; pause() ; } void do_caller(const char *string) { union { int i ; char c[4] ; } u ; struct sockaddr_in dest; int a1, a2, a3, a4, port ; unsigned int total ; sscanf(string, "%d.%d.%d.%d:%d", &a1, &a2, &a3, &a4, &port) ; u.c[0] = a1 ; u.c[1] = a2 ; u.c[2] = a3 ; u.c[3] = a4 ; for (total=0;;total++) { int fd ; memset(&dest, 0, sizeof(dest)) ; dest.sin_family = AF_INET ; dest.sin_port = htons(port) ; dest.sin_addr.s_addr = u.i ; fd = socket(AF_INET, SOCK_STREAM, 0) ; if (fd == -1) break ; if (connect(fd, (struct sockaddr *)&dest, sizeof(dest)) == -1) { perror("connect") ; break ; } write(fd, some_data, sizeof(some_data)) ; } printf("total=%u\n", total) ; pause() ; } int main(int argc, char *argv[]) { int listener ; int caller ; if (argc != 3) { usage(1); } listener = !strcmp(argv[1], "listen") ; caller = !strcmp(argv[1], "call") ; if (listener) { do_listener(argv[2]) ; } else if (caller) { do_caller(argv[2]) ; } else usage(2) ; return 0 ; } /********************************************************************/ ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: bitkeeper comments 2003-09-01 15:46 ` Larry McVoy 2003-09-01 15:56 ` Christoph Hellwig 2003-09-01 16:59 ` Bug in linux-2.6.0-test4 ? dada1 @ 2003-09-01 18:08 ` Albert Cahalan 2 siblings, 0 replies; 18+ messages in thread From: Albert Cahalan @ 2003-09-01 18:08 UTC (permalink / raw) To: Larry McVoy; +Cc: Albert Cahalan, linux-kernel mailing list, Linus Torvalds, ak On Mon, 2003-09-01 at 11:46, Larry McVoy wrote: > On Mon, Sep 01, 2003 at 11:26:55AM -0400, Albert Cahalan wrote: > > I'm OK with whatever ensures that somebody looking back > > through the BitKeeper logs isn't going to come to the > > conclusion that I broke something. > > > > Um, not everybody will grab updates from bkbits.net, > > right? Pardon me for being clueless about BitKeeper, > > but is there some command Andi or Linus could run? > > Unfortunately the checkin comments themselves are not revision controlled. > You have to run a command on each repository that needs to be fixed, > if you send me the desired comments I'll post the command. Then if > Linus or Marcelo says do it I'll do it on bkbits.net. That should be good > enough, the logs there are what people tend to browse. ============ as a patch ============= --- old 2003-09-01 14:04:46.000000000 -0400 +++ new 2003-09-01 14:05:18.000000000 -0400 @@ -2,13 +2,9 @@ Make everything compile and boot again. -The earlier third party ioport.c changes unfortunately didn't even -compile, fix that too. - - Update defconfig - Some minor cleanup - Introduce physid_t for APIC masks (fixes UP kernels) - - Finish ioport.c merge and fix compilation - Add bandaid for CardBus bridges and broken BIOS (Vojtech) - Add bandaid for unsynchronized TSCs (Vojtech) - Fix ffs(0) return value (fixes XFS) =========== old content ============ [PATCH] x86-64 update Make everything compile and boot again. The earlier third party ioport.c changes unfortunately didn't even compile, fix that too. - Update defconfig - Some minor cleanup - Introduce physid_t for APIC masks (fixes UP kernels) - Finish ioport.c merge and fix compilation - Add bandaid for CardBus bridges and broken BIOS (Vojtech) - Add bandaid for unsynchronized TSCs (Vojtech) - Fix ffs(0) return value (fixes XFS) - Fix compilation with software suspend =========== new content ============ [PATCH] x86-64 update Make everything compile and boot again. - Update defconfig - Some minor cleanup - Introduce physid_t for APIC masks (fixes UP kernels) - Add bandaid for CardBus bridges and broken BIOS (Vojtech) - Add bandaid for unsynchronized TSCs (Vojtech) - Fix ffs(0) return value (fixes XFS) - Fix compilation with software suspend ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2003-09-01 18:20 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-09-01 4:15 bitkeeper comments Albert Cahalan 2003-09-01 14:07 ` Larry McVoy 2003-09-01 15:26 ` Albert Cahalan 2003-09-01 15:46 ` Larry McVoy 2003-09-01 15:56 ` Christoph Hellwig 2003-09-01 15:59 ` Larry McVoy 2003-09-01 16:02 ` Christoph Hellwig 2003-09-01 16:11 ` Larry McVoy 2003-09-01 16:22 ` Geert Uytterhoeven 2003-09-01 16:15 ` Andi Kleen 2003-09-01 16:59 ` Linus Torvalds 2003-09-01 17:23 ` Jakob Oestergaard 2003-09-01 17:28 ` Christoph Hellwig 2003-09-01 17:40 ` Larry McVoy 2003-09-01 16:33 ` Alan Cox 2003-09-01 16:36 ` Larry McVoy 2003-09-01 16:59 ` Bug in linux-2.6.0-test4 ? dada1 2003-09-01 18:08 ` bitkeeper comments Albert Cahalan
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).