Kernel Traffic #6 For 18 Feb 1999

There were 384 different contributors. 163 posted more than once. 134 posted last week too.

Someone posted an ad on the list. Mike A. Harris expressed what was probably a unanimous feeling of fury, to which Kevin L. Mitchell replied, "I've gotten several copies of it. It originated from a block of addresses which seem to belong to UUNET...I don't have high hopes of them doing anything about it, but maybe they'll suprise me... or maybe MicroSloth will sue them :)"

B. James Phillippe confirmed Kev's post, with, "This is correct. They are originating from dialup banks at uu.net. And correct again, UUNet has no interest in taking action (eg. blocking port 25 TCP outgoing at the router from dialup banks). A workaround that I propose for anyone who wishes to cut down on their UCE, is to block email from dialup uu.net subdomains: block all mail originating from .da.uu.net. You will still be able to receive email from legitimate UUNet customers, as they do not send email directly from their currently dialed system. Unfortunately, little can be done when the mail is laundered through some other brainless middle-man system, such as MSD in these cases."

Steven N. Hirsch also responded to Mike, with, "For reasons unknown, uu.net have become the masters of mass-mail spam relay over the past three weeks. Most messages have forged return addresses. Anyone else seeing this?"

Brandon S. Allbery added, "This is nothing new for uunet; they've been threatened with UDP at least twice over this kind of thing --- they clean up their act a little, briefly, but soon are back in the spam game again. No doubt there's a lot of profit in it for them."

But Gerhard Mack pointed out, "Check for wingate before you guys open fire. This could be an innocent yet stupid user who left it on it's default (no security) settings. Windows machines with 1080 open and/or 23 that answers with "wingate>" It's seems a lot of spammers are using somone else's to do their nasties."

There followed some discussion about WinGate, and Gerhard explained, "Its a broken modem sharing package (all security off by default), though I've seen it used as a firewall for some Japanese bank (they took it down REAL fast). It's telnet redirector has the same problem ... you simply connect and type in the address of the host you want, no password required. With hundreds of these damn things in use, it's become a popular means of causing trouble without being traced. To top it off logging is only available in the registered version. Since the user never sees a problem until somone terminates their account for something they didn't do they just happily go on using it. Wingate software has ignored any complaints that their software is a hazard to the internet and have refused to fix it."

Ian Stirling had a problem with 2.2.1, where compiling native language support (NLS) as a separate module wouldn't give working NLS. Bradley Baetz took this to 2.2.2-pre2 and caught a missed dependency: "make modules does not depend on include/config/MARKER. This means that changing the config, then just running make modules without make *Image doesn't regenerate the smartconfig stuff - ie this problem occurs."

Michael Elizabeth Chastain came in and had a small staircase with Bradley. There were problems finding the proper place to put the dependency. What looked good at first turned out to be just a fluke. Something else would break parallel builds. After just a day, what appeared to be the right dependency was found. Time will tell.

While this was going on, Bradley pointed out that "the help fails to mention that CONFIG_SMB_95 has side effects when used on NT. Documentation/filesystems/smbfs.txt states this, but it should be in Configure.help as well. I'd do a patch, but I'm not sure if this option is safe WRT win98. Anyone?"

This thread continued from last week, but it died shortly thereafter. Most people had their own ideas about what inodes do and what to do with them, so it made for an interesting discussion. Alexander Viro and Andrea Arcangeli were the most vocal participants. Wish I Understood More (tm).

Most of the discussion this week branched off of whether clearing (or cleaning) an inode freed any memory. Andrea didn't see where in the code such an operation took place. Finally Alexander got the upper hand on the misunderstanding, with, "it doesn't free inode memory per se. But for some inodes it informs filesystems that they should free their internal data associated with said inodes."

Part of the problem behind the whole question seems to be the memory inodes eat in the first place. Alexander vented a bit on the inefficiency of inode memory allocation, and suggested moving parts of the code into filesystem-specific areas to allow a cleaner implementation.

At one point in the discussion, several developers converged on a single desire: Alexander asked, "is there a decent way to create a cache from module?" Andrea felt it could be done, but Matti Aarnio pointed out that it was not as easy as it looked. He went on, "I have tried to resort to such esoteric tricks as having separate permanently loaded submodule that just allocates the damn cache.. Please add that kmem_cache_delete() routine, and the world will be better place to be," and Alexander added, "Exactly. If it is possible it would be really nice."

Meanwhile, Mark Hemment had the idea (also in response to Alexander's request) of making cache pointers resident (i.e. created at bootup by the kernel). When loaded, a module could access and grow its cache, then shrink it when unloaded.

Alexander didn't like that idea. "Mark, sorry, but requiring modules to *have* a resident part is what makes life unpleasant," he said, and added, "think of modules debugging, where you may have the size of cache elements changing across the rmmod/insmod and definitely do not want to reboot after recompiling. And keeping stubs for all filesystems would be ugly."

Mark explained that in his idea, unloading a module would "release all the memory associated with the cache _except_ for the cache structure itself. Mark it as deallocated, and put it on a free-list. When destroying a cache, there may be allocated objects not freed (a bug in the consumer), and keeping the cache struct around would allow later releasing of these objs (accompied by warning messages). Cache structs on the free-list would be re-used if there are no unreleased objects associated with it, but the short time they are on the list would allow some races to be caught."

Alexander replied with the alternative of marking slabs of memory on creation as belonging to particular modules. That was the end of the thread.

This thread had a number of interesting qualities. For one, most of this week's portion of the discussion took place in a single day, which means the participants were probably longitudinally close (at least it wasn't the middle of the night for one and high noon for another). This would seem to be a Law of the bazaar. For instance, when Linus Torvalds moved from Finland to Silicon Valley, the developers he could have such one-day conversations with (and who could have such conversations with him) changed radically.

Mike A. Harris pointed out that no one was maintaining the modutils package. Good patches were going to seed and other developers were complaining as well. He asked anyone who could, to please take up the job of maintaining that package.

Some folks raised the objection that Richard Henderson (who did not participate in this thread) was the legitimate maintainer, and should be consulted before any decisions were made. At the same time, a number of folks volunteered to be the new maintainer.

At this point the 'Subject:' of the thread turned into "New snapshot of modutils". Bjorn Ekwall spoke to Richard H. outside of linux-kernel, and they agreed Bjorn would help produce an updated modutils package. Bjorn announced that the package had been produced and was available. This was within 24 hours of Mike's original post. Since then there's been one new snapshot per day.

One part of Bjorn's announcement was bound to cause trouble, and it did. He said, "Please note that the depmod and modprobe utilities are back to C++. This is a result of a discussion in linux-kernel last week, and this is the way it has to be, in consideration of all involved." His phrasing was poorly chosen, as Oliver Xymoron later clarified. In the intervening day or so, some developers argued in favor of staying with C.

As pointed out by H. Peter Anvin, "The big problem with using C++ for modutils is that the modutils is one of the programs that you might need on an initrd or boot floppy. Needing the C++ library is a *big* deal."

Fred Reimer suggested, "Link static. Is that too much space?" , but Jakub Jelinek replied, "Definitely. You fight for each single byte there..." , and Michael H. Warfield elaborated with, "That might even cost you MORE space because you would also include other libraries that are already somewhere else. Or are you proposing a "partial static / partial dynamic" build? Static link with only those libraries you want to use in only that program and dynamic link against all the rest? I've tried that. That's a butt ugly build complication like you would not believe."

At this point, Oliver Xymoron clarified the situation with, "the problem is there's some concern about the copyright status of the C code fork. Read the archives. Hence the regression to a known state, which happens to be C++. Movement back to C is in progress."

The person who starts a thread often takes no part in the ensuing discussion. In this case (one of the largest threads of the week), Alan Curry pointed out that removing the current working directory under Linux, and then trying to access that directory, always used to give an ENOENT ("A directory component in pathname does not exist or is a dangling symbolic link." -- 'man 2 rmdir'); but under 2.2, no error occurs and the directory just appears empty. He added that attempts using 2.2 to create a directory under the nonexistent directory gave an EPERM ("The directory containing pathname has the sticky-bit (S_ISVTX) set and the process's effective uid is neither the uid of the file to be deleted nor that of the directory containing it.")

The discussion centered around the correct behaviour of rmdir, so other OS's and POSIX came into the mix. Ralf Corsepius said that 'mkdir <somedir>;cd <somedir>; rmdir .' produced an error on all OS's he tried it on (Alexander Viro piped up, "You never tried 4.4BSD, right?" ), while on Linux 2.1.124, the rmdir silently succeeded.

Ralf added the following important tidbit: "BTW, this behaviour breaks building egcs/gcc/fixincludes for cross-compilers under linux, because fixincludes (egcs-1.1b and egcs-1.1.1) contain a fragment which rely on "rmdir ." failing."

Alexander replied, "Then egcs/gcc is broken. Period. POSIX doesn't mandate failure on such operation. All *BSD do the same as Linux. And this behaviour is consistent with unlink(). Notice that it may be even fs-dependent." He added, "Final word belongs Linus, indeed, but IMO reverting to -EBUSY on rmdir() is *wrong*." (EBUSY means "pathname is the current working directory or root directory of some process.")

Ralf answered Alexander's several points. He admitted not having tried 4.4BSD, but said, "I checked against SunOS, Solaris (2.4-2.6), linux-2.0.3X, Irix-<something> and hpux-<something> when 2.1.124 was new. AFAIK from other persons' reports, Cygwin32/NT, FreeBSD and Next also report error messages." He added, "the new behaviour of "rmdir" seems arkward to me: After excuting the command sequence above you can still "ls" in <somedir>, but "ls .." doesn't show <somedir>, bash's command prompt also reports to be still in <somedir>."

Alexander replied with a confession that his "4.4BSD" comment was misguided--Ralf's command sequence produced an error there as well. He also included a patch for Linus Torvalds: "IMHO it makes sense - it explicitly forbids rmdir of one's pwd. Current directory of anybody else is still fair game."

Andreas Schwab complained, "This patch is wrong, it also forbids 'rmdir ../foo'. Only a path ending in '.' is special. Think about it: to find out the real name of the entry to unlink you'll have find its link in the parent directory. With '.' you simply don't have enough information about what to unlink."

Two main branches sprouted off of that; The first was primarily a discussion of rmdir's behaviour; while in the second, Linus (in his only post in the thread) replied to Andreas,

Actually, you do.

_I_ think "." just means "current working directory".

It's not my fault that other systems can't do this, Linux has the information, and will happily remove the current working directory. I don't think it's a bug, I think it's just very logical.

Show me POSIX or other standards that say that you can't do it, and I guess I have to work around a standards problem, but right now I say that if programs ask for 'rmdir(".")', then they had better get it. I don't think the OS should second-guess anybody.

The reason '.' doesn't work on other UNIXes is that they don't have the complete path information that Linux has.

Ralf argued in favor of a de facto standard, since so many other OS's produced the error, and egcs/gcc was broken by linux's change. Andreas Schwab quoted SUS2 (Single UNIX Specification, version 2): ""If the directory is the root directory or the current working directory of any process, it is unspecified whether the function succeeds, or whether it fails and sets errno to [EBUSY].""

- { 0xb900, "Play operation oborted (sic)" },
+ { 0xb900, "Play operation aborted (sic)" },

Gregory Maxwell replied, "Do you see the "(sic)" That usually stands for "Spelling is Correct"."

I think what we have here is an ironic double typo. The message is actually indicating the drive is not feeling very good:

+ { 0xb900, "Play operation aborted (sick)" },

Hopefully this very important change will make it into 2.2.2.

"sic" doesn't stand for "spelling is correct", or even "stated in context" (yech!).

In fact, it stands for "yes, I know it looks funny, but that's how I want it". But people got tired of typing Y,IKILF,BTHIWI so they abbreviated it to SIC. Then they got tired of pressing caps lock or shift, as is common on the internet (i see it all the time), and started writing it as "sic".

Someone said it was Latin for "thus" or "so", but that's just plain outlandish - anyone who knew Latin could probably take some time to learn to spell too.

This was a long and involved thread, but here's part of a post from Linus Torvalds:

I don't think I'll ever allow concurrent writes to the same file.

The basic reason is simple: we have more filesystems than can reasonably be maintained if it happens. The same way I don't want driver writers to have to know about more than the bare minimum basic rules about SMP (because 99% of all people don't understand race conditions), I don't want FS people having to know more than the bare minimum about race conditions in filesystems.

Why? Simply because I certainly understand races better than most people out there, and even _I_ get confused.

Performance comes second in this case, especially as I don't believe there is any strong argument for performance in the first place. And don't bother telling me about databases, I know about databases, and I think it's a complete red herring. We get more performance by having a simple locking scheme and good caching than by adding complexity - and that's been true historically forever.

Eventually some hungry programmer will decide that Linux has too much cruft, and he'll want to take over the world, and he'll come up with a system called Davix or something. That's how these things go, and that's how things _should_ work.

The only thing I can aim at is to minimize the amount of cruft, and pushing out the inevitable as far into the future as humanly possible.

Alan, the _only_ beef I ever have about you as a developer is that you're looking about a year into the future - not ten.

Start thinking ten years down the road, and think "how do I avoid the complexity issue"? Then, after you've given that some serious thouhgt, come back to me about this all.


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	11 Feb 1999 - 15 Feb 1999	(14 posts)	Spam On linux-kernel
2.	10 Jan 1999 - 11 Jan 1999	(5 posts)	Native Language Support Bug Hunt
3.	10 Feb 1999 - 11 Feb 1999	(16 posts)	Inode Memory; Module Access To Cache
4.	13 Feb 1999 - 14 Feb 1999	(8 posts)	modutil Ownership Dispute; C Vs. C++
5.	15 Feb 1999	(11 posts)	Behavior Of rmdir()
6.	16 Feb 1999	(13 posts)	Light Humor
7.	12 Feb 1999 - 24 Feb 1999	(135 posts)	Concurrent File Writes; The Future Of Linux

Kernel Traffic #6 For 18 Feb 1999

By Zack Brown