> Complete fucking bullshit. Over the last several months, I've been
> sending a steady stream of bugfix patches to Linus and the list, and
> if you'd been paying attention, you'd notice that in time they've been
OK, _now_ I'm really pissed off. As far as I can see there is only
one way to get you fix anything - posting to l-k. This "steady
stream" consists of what? Let's see:
0.118: buffer underrun in try_modload(). Source: some Al Viro had hit
the function in question in grep over tree and took a couple of minutes
to read it.
0.118: moving down_read() - yes, it had fixed the instance of deadlock
pointed to you by, damn, what a coincidence, same bastard. Come to think
of that, let me grep for down_read()... Aha.
static int devfs_follow_link (struct dentry *dentry, struct nameidata *nd)
struct devfs_entry *de;
de = get_devfs_entry_from_vfs_inode (dentry->d_inode, TRUE);
if (!de) return -ENODEV;
err = de->registered ? vfs_follow_link (nd,
de->u.symlink.linkname) : -ENODEV;
} /* End Function devfs_follow_link */
Umm... Hadn't we just been there? Recursive down_read(&symlink_rwsem)...
0.117: oh, wow - finally. devfs_link() is gone.
0.116: reverted previous broken patch, but result contained a deadlock instead
of race. Result of race scenario described on l-k by... damn, this asshole
0.115: bogus fix for breakage introduced by blkdev-in-pagecache patch. Hadn't
got into Linus' tree, actually.
0.114: introduced broken refcounting for symlinks (see 0.116)
0.113: "quick and dirty hack" to protect symlink bodies. Broken, at that.
BTW, breakage in 0.113 and 0.114 hadn't stopped Mandrake from deciding that
it fixed readlink() race and shipping the thing. Funny, but race it was
supposed to fix had been described in private email several months before.
Then it was described on l-k. Then description had been forwarded to Mandrake
- after a question about potential breakage. _Then_ (and I assume that it
was a coincidence) said patches had appeared.
0.111, 0.112: not a fix by any stretch of imagination.
Oh, and before that we have a (finally, only after a year of mentioning
the crap in question, heavy-weight rant on l-k when I've finally ran out
of patience _and_ detailed discussion on the possible fixes) fix for
So far all I see is that beating you hard enough in public can make you
fix the bugs explicitly pointed to you. That's it. As far as I can
see you don't read your own code, judging by the fact that every damn
look at fs/devfs/base.c shows a new hole within a couple of minutes
_and_ said holes stay until posted on l-k. Private mail doesn't work.
You read it, reply and ignore. About hundred kilobytes of evidence
available at request.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/