An error occurred fetching the project authors.
- 23 Nov, 2007 40 commits
-
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
> Compile this code > > ---- cut here ---- > #include <fcntlbits.h> > void main( int argc, char *argv[] ) { > open( argv[ 1 ], O_WRONLY|O_CREAT|O_TRUNC, 0666 ); > } > ---- and here ---- > > and run it like this > > strace ./a.out >(cat - ) > > with 2.0.36 & 2.2.0-pre[67] you get: > > open("/dev/fd/63", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3 > > with 2.2.0-pre[89] you get: > > open("/dev/fd/63", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT (No > such file or directory) Ok, this seems to be due to pre9 removing some rather bogus code that happened to hide another problem in open_namei(). I haven't actually tested this, but it looks really obvious, so does this patch fix it for you? (This should also fix a potential performance bogosity - there's absolutely no reason why we should get the directory lock when we don't need to for a normal open of an existing file). Linus
-
Linus Torvalds authored
Hoya, there's now a 2.2.0-pre9 on ftp.kernel.org, and when you compile it it will call itself 2.2.0-final. The reason is fairly obvious: enough is enough, and I can't make pre-kernels forever, it just dilutes the whole idea. The only reason the tar-file is not called 2.2.0 is that I want to avoid having any embarrassing typos that cause it to not compile under reasonable configurations or something like that. Unreasonable configurations I no longer care about. Every program has bugs, and I'm sure there are still bugs in this. Get over it - we've done our best, and nobody ever believed that there wouldn't be 2.2.x kernels to fix problems as they come up, and delaying 2.2.0 forever is not an option. I have a wedding anniversary and a company party coming up, so I'm taking a few days off - when I get back I expect to take this current 2.2.0-final and just remove the "-final" from the Makefile, and that will be it. I suspect somebody _will_ find something embarrassing enough that I would fix it too, but let's basically avoid planning on that. In short, before you post a bug-report about 2.2.0-final, I'd like you to have the following simple guidelines: "Is this something Linus would be embarrassed enough about that he would wear a brown paper bag over his head for a month?" and "Is this something that normal people would ever really care deeply about?" If the answer to either question is "probably not", then please consider just politely discussing it as a curiosity on the kernel mailing lists rather than even sending email about it to me: I've been too busy the last few weeks, and I'd really appreciate it if I could just forget the worries of a release for a few days.. But if you find something hilariously stupid I did, feel free to share it with me, and we'll laugh about it together (and I'll avoid wearing the brown paper bag on my head during the month of February). Do we have a deal? I've seen people working on a 2.2.0 announcement, and I'm happy - I've been too busy to think straight, much less worry about details like that. If everything turns out ok, I'll have a few memorable bloopers in my mailbox but nothing worse than that, and I can sit down and actually read the announcement texts that people have been discussing. ObFeatures: - m68k sync - various minor driver fixes (irda, net drivers, scsi, video, isdn) - SGI Visual Workstation support - adjtimex update to the latest standards - vfat silly buglet fix - semaphores work on alpha again - drop the inline strstr() that gcc got wrong whatever we did - kswapd needed to be a bit more aggressive - minor TCP retransmission and delack fixes Until Monday, Linus
-
Linus Torvalds authored
Oh, well.. Based on what the arca-[678] patches did, there's now a pre-5 out there. Not very similar, but it should incorporate the basic idea: namely much more aggressively asynchronous swap-outs from a process context. Comment away, Linus
-
Linus Torvalds authored
Ok, you know the drill by now. This fixes: - yes, people told me about the new and improved ksymoops. Much better, no need for C++, and this one actually seems to compile and work reliably. - ntfs fixes - the vfat thing _really_ works now - NFS fix for deleting files while writebacks active. - ppa/imm driver updated - minor mm balancing patches - Alan took the gauntlet and cleaned up some CONFIG_PROC_FS stuff. More on Monday, Linus
-
Linus Torvalds authored
-
Linus Torvalds authored
Well, some people obviously had problems with the first 2.2.0pre, so there's a second one there. Most of it is almost purely syntactic sugar: configuration issues and jiffies wraparound, but there were a few problems wrt some IDE disk geometry stuff in particular that made 2.2.0pre1 not boot for some people. Other real changes: - nfsd updated, and we have an official maintainer for knfsd (and I was happy by how many people were ready to stand up for it. Good show, guys!) - network driver updates (tulip/eepro) - some TCP fixes for occasional but nasty performance problems. - fix for an attack where you could cause a complete and utter lockup of the kernel as a normal user. Thanks to Michael Chastain for keeping the faith on this one and reminding me to fix it. If you haven't had problems with pre1, there should be no major cause to look at pre2. But if you haven't even looked at pre1 yet, please consider looking at the pre-2.2.0 kernels before it's too late. I'm going to be extremely rude to people who knew better but didn't test out the pre- kernels and then send me bug-reports on the released 2.2.0. Linus
-
Linus Torvalds authored
we're in the pre-2.2.0 series now, I'm all synched up with Alan, and I don't have anything pending any more. Over the internet nobody can hear you all scream in pain over all your favourite features that didn't make it. Linus "another year older and wise as hell by now" Torvalds
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
There's a new pre-patch on ftp.kernel.org. I've been waiting for a few other things, but the pre-patches are getting to be so big that it's getting unwieldly, so I'll probably make a real 2.1.132 real soon now. In the meantime, there's a pre-patch that people can verify for sanity (this one should have coda-fs back to working order, for example - patch craziness corrupted a simple update in pre-3). Linus
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
.. is out there now, and includes: - subtle fix for lazy FP save and restore on x86. The bug has been there for a long time, but was apparently triggered by the re-write of the low-level scheduling function. It could result in corrupted i387 state under certain (admittedly fairly unlikely) circumstances. - various networking updates. Some of the bugs fixed could result in kernel Oopses. None of them were common, though. - fixes for both filesystem accounting and quota handling. - the much-ado-about-little video driver merge. - PPC and Sparc updates - i386/SMP interrupt handling falls back on the safe mode.. Please tell me whether there are still machines with problems. - some new network drivers and updates - final (we hope) IP masquerade update I still have a problem with certain machines that apparently don't want to boot with the keyboard not plugged in even though they should. Kill me now. If you have problems with i386/SMP on a machine without a keyboard, plug one in and send me a report..
-
Linus Torvalds authored
-
Linus Torvalds authored
-