Kernel Traffic #179 For 11 Aug 2002

Here's the lastest version of the lockassert patch. It includes:

• MUST_HOLD for all architectures
• MUST_HOLD_RW for architectures implementing rwlock_is_locked (only ia64 at the moment, as part of this patch)
• MUST_HOLD_RWSEM for arcitectures that use rwsem-spinlock.h
• MUST_HOLD_SEM for ia64
• a call to MUST_HOLD(&inode_lock) in inode.c:__iget().

I'd be happy to take patches that implement the above routines for other architectures and/or patches that sprinkle the macros where they're needed.

I don't see there being an easy way to kill this off:

1. serial_struct is a userspace API.
2. old_serial_port glues asm/serial.h into 8250.c; asm/serial.h can't be changed because (mainly) ppc uses it elsewhere. Other architectures seem to do the same sort of thing.

Unless ppc and others are willing to put up with major breakage when I change asm/serial.h, I don't see this getting cleaned up. Comments on this area welcome.

1. Serial port initialisation

Firstly, one thing to bear in mind here is that, as Alan says "be nice to make sure it was much earlier". I guess Alan's right, so we can get oopsen out of the the kernel relatively easily, even when we're using framebuffer consoles.

I'm sure Alan will enlighten us with his specific reasons if required.

There have been several suggestions around on how to fix this table:

a. architectures provide a sub-module to 8250.c which contains the per-port details, rather than a table in serial.h. This would ideally mean removing serial.h completely. The relevant object would be linked into 8250.c when 8250.c is built as a module.

b. we create 8250_hub6.c, 8250_generic.c, 8250_multiport.c and friends each containing the parameters for the specific cards and handle it as above.

c. make it the responsibility of user space to tell the kernel about many serial ports, and leave just the ones necessary for serial console in the kernel. (see issue 2 below)

d. we keep serial.h, make it 8250-compatible ports only, and change CONFIG_SERIAL_MULTIPORT and friends to CONFIG_SERIAL_8250_MULTIPORT This is the simplest and least likely to break other code. On the other hand, we end up hauling the ISA table and struct old_serial_port into 2.6.

2. setserial API

This is actually tied closely into another issue; I'd like to get rid of this silly idea where we're able to open serial ports that don't exist (ie, their UART is "unknown"). This behaviour appears to be for the benefit of setserial to allow it to modify port base addresses and interrupt levels, etc. Removing this facility would require a new API for such things. The best suggestion made so far is to do something like:

# echo "add 0x2e8,3,autoconfig" >/dev/serialctl
# echo "remove 0x2e8" >/dev/serialctl

(or s,/dev/serialctl,/proc/tty/driver/serial, which pre-exists)

where we have "add ioport,irq,flags" and "remove ioport" (note that mmio ports aren't covered here since they require ioremap games which tends to be card specific!)

Why make this change? Well, we have quite a lot of baggage being dragged around to support configuration of an open port and being able to open a non-existent port. I'd really like to get rid of this excess baggage.

3. /dev/ttyS*, /dev/ttySA*, /dev/ttyCL*, /dev/ttyAM*, etc

All the above are serial ports of various types. It has been expressed several times that people would like to see all of them appear as /dev/ttyS* (indeed, there was an, erm, rather heated discussion about it a couple of years ago.) I'm going to be neutral on this point here.

There are several issues surrounding this:

a. The serial core.c is very almost capable of handling this abstraction, with one exception - a registered port can only be in one group at one time. This restriction is brought about because of the way the tty layer handles its tty ports.

(Handling dual registrations in two different majors gets _really_ messy - eg, you two built-in 16550A ports and two SA1100 ports taking up ttyS0 to ttyS3. You then add a 16550A PCMCIA modem, which becomes ttyS4. Oh, and the SA1100 ports are also appearing as ttySA0 and ttySA1. _really_ messy. No thanks.)

b. serial consoles. Each hardware driver handles its serial consoles by itself, and if you have two or more hardware drivers built in with serial console support, you need to be able to tell them apart with the console= kernel parameter.

Again, this could be solvable if we have one "ttyS" view of everything (core.c would then be responsible for registering the console with printk.c and passing the various methods off to the relevant hardware).

c. People with many serial ports. We _could_ change the device number allocations such that ttyS gobbles up the ttySA, ttyCL, ttyAM, etc device numbers so we end up with the same number of port slots available for those with many many serial ports in their machines.

Hmm.

If you're doing these kinds of Lindent changes, you might as well also fix another non-linuxism:

        return (x);     ->      return x;

I don't know why some people seem to think that "return" is a function with an argument..

I guess that one isn't mentioned in the CodingStyles thing. I'm lazy. Bad Bad Linus.

POSIX is a hobbled standard, and does not matter.

We're not making a "POSIX-compliant OS". People have done that before: see all the RT-OS's out there, and see even the NT POSIX subsystem.

They are uninteresting.

Linux is a _real_ OS, not some "we filled in the paperwork and it is now standards compliant".

And being a real OS means taking the real world into account.

And the real world says that it's not acceptable to make up your own semantics, unless you have some _damn_ good reason for doing so.

Linus's objections are threefold: it expands struct page, 64 bit arith is slow and gcc tends to get it wrong. And I would add "most developers won't test 64-bit pgoff_t, and it'll get broken regularly".

The expansion of struct page and the performance impact is just a cost which you'll have to balance against the benefits. For a few people, 32-bit pagecache index is a showstopper and they'll accept that tradeoff.

Sprinkling `pgoff_t' everywhere is, IMO, not a bad thing - it aids code readability because it tells you what the variable is used for.

As for broken gcc, well, the proponents of 64-bit pgoff_t would have to work to identify the correct gcc version and generally get gcc doing the right thing.

• Integrate patches by Adam J. Richter, Alan Cox and Andre Hedrick for CMD640 PCI configuration space register access.
• cs5530 patches by Adam J. Richter. Small indent style adjustments.
• qd65xx cli()/sti() adjustments.
• Fix bogous command in ide.c pointed out by Peter Vendroviec.
• Eliminate ide_stall_queue(). For those worried: we didn't sleep at all.
• Eliminate support for "sector remapping". loop devices can handle stuff like that. All the custom DOS high system memmory loaded BIOS workaround tricks are obsolete right now. If anywhere it should be the FAT filesystem code which should be clever enough to deal with it by adjusting it's read/write methods.
• PCI "scather gather" allocation handling revamp by Adam J. Richter.
• Simplify do_ide_request after ->sleep removal.
• Make do_ide_request preferr to handle the device matching the request queue it was called for first. RQ-queues are unique for devices. In a next step queuedata will be changed to point to the device not the channel.

The EVMS team is announcing the next stable release of the Enterprise Volume Management System, which will eventually become EVMS 2.0. Package 1.1.0 is now available for download at the project web site:
http://www.sf.net/projects/evms

EVMS 1.1.0 has full support for the 2.4 kernel, and includes patches for most kernels up to 2.4.19-rc3. It also has nearly full support for the 2.5 kernel, and includes patches for kernels 2.5.25 and 2.5.27.

**** Important Note ****

As of this release, EVMS has been assigned a new, permanent major number: 117. The previous major number, 63, was reserved for experimental drivers. Before using 1.1.0, please read the README_Upgrade_To_1.1.0 file included in the source package for details on how you might be affected by the major number change. You can also view these instructions on the EVMS web site at
http://evms.sourceforge.net/new_major.html.

************************

For on-going performance testing and analysis results for EVMS, please visit the Linux Scalability Effort site at:
http://lse.sourceforge.net/benchmarks/evms/

Please send any questions, problem reports or bugs to the EVMS mailing list:
evms-devel@lists.sf.net.

syscalltrack-0.73, the 9th _alpha_ release of the Linux kernel system call tracker, is now available. syscalltrack supports version 2.4.x of the Linux kernel on the i386 and UML architectures. Kernel versions 2.2.x and 2.5.x should work as well, but did not receive the same extensive testing. The current release contains a new experimental strace compatible tool, sctrace, a logging device file, several bug fixes and many new system calls, including all of the IPC syscalls. More details below.

* What is syscalltrack?

syscalltrack is made of a pair of Linux kernel modules and supporting user space environment which allow interception, logging and possibly taking action upon system calls that match user defined criteria. syscalltrack can operate either in "tweezers mode", where only very specific operations are tracked, such as "only track and log to delete /etc/passwd", or in strace(1) compatible mode, where all of the supported system calls are traced. syscalltrack can do things that are impossible to do with the ptrace mechanism, because its core operates in kernel space.

* Where can I get it?

Information on syscalltrack is available on the project's homepage: http://syscalltrack.sourceforge.net, and in the project's file release.

The source for the latest version can be downloaded directly from: http://osdn.dl.sourceforge.net/sourceforge/syscalltrack/syscalltrack-0.73.tar.gz or any of the other sourceforge mirrors.

* Call for developers:

The syscalltrack project is looking for developers, both for kernel space and user space. If you want to join in on the fun, get in touch with us on the syscalltrack-hackers mailing list (http://lists.sourceforge.net/lists/listinfo/syscalltrack-hackers).

Tons of stuff all over the map again. Lots of merging with various people.

The most noticeable fix (for me personally) was Trond fixing a nasty RPC problem that caused the NFS client to return bogus dentry pointers that hung the VFS layer hard on SMP machines.

But as you can see from the "short" changelog version (the full one is 63kB), there's a lot of other stuff there.

linux-2.5.30/include/linux/serialP.h needs struct async_icount, which is defined in <linux/serial.h>, causing linux-2.5.30/drivers/serial/8250.c not to compile, among other problems. In linux-2.5.30, you cannot compile a file that includes <linux/serialP.h> without including <linux/serial.h>. So, I think the solution is for serialP.h to #include serial.h. I have attached a patch that does this.

From the comments in serialP.h, it looks like there was some effort in linux-2.2 to allow inclusion of serialP.h without serial.h, but I see no indication of what benefit that was supposed to provide.

Ted (or whowever gathers drivers/serial patches for Linus), do you want to shepherd this change to Linus, do you want me to submit it directly, or do you want to do something else?

Ack. I've just found why I and many other people can build it, and other people can't. I can tell you that you're building 8250.c as a module.

Why?

When I build 8250.c into the kernel, linux/module.h doesn't include linux/version.h, so when we include linux/serialP.h, the compiler assumes that LINUX_VERSION_CODE is zero. So we end up including linux/serial.h.

However, when building as a module, linux/module.h does include linux/version.h, so when we don't include linux/serial.h.

Oh, the problems of trying to reduce the includes... I think we should re-include linux/serial.h and eliminate linux/serialP.h.

Hmm, I wonder how many other oddities like this are in the tree today. It sounds like we want to create a rule similar to the one for using CONFIG_* symbols. Does this sound reasonable: if you use LINUX_VERSION_CODE, you must include linux/version.h into that very same file to guarantee that it is defined.

Well, I took checkconfig.pl and created checkversion.pl (attached). Oh god, can I please put the worms back in the can? Now? I think there's lots of work to do here; lots of stuff including linux/version.h for the hell of it, and a comparitively small number not including it when they use LINUX_VERSION_CODE.

I have a new set of uClinux (MMU-less) patches for 2.5.30 at:

http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/

I have coded a generic MTD map driver to replace the old crufty blkmem driver. The blkmem driver will be going away in future patches.

Other than that it is still all working nicely.

there is actually a lot in common. Probably something like 70%. This is really a question of organization.

I would much prefer to see the non-mmu support in with mm. But it would mean a few #ifdef's in there to allow for the differences.

The is a slightly updated version of the patch that I've resent twice split up into 3 chunks, and 3 times as a single patch. The only changes this time are support for a 64bit kernel and a 32bit userland, from the parisc group, as well as include/asm-parisc/rtc.h, both from Randolph Chung.

Patch 1 is the current version of the driver (switched to C99-style initializers, done in the current m68k CVS tree) and needed changes to select/compile it in general. I had previously asked the m68k community if anyone objected to this being submitted by me, and I got Richard Zidlicky's (who's at the top of the file) approval, as well as Geert Uytterhoeven's approval.

Patch 2 is the PPC portion of the patch, which creates include/asm-ppc/rtc.h. This has been in the PPC bitkeeper tree for over a month now. I can have Paul Mackerras send this to you instead, if you prefer.

Patch 3 is my own slight bit of work, as well as some work by Randolph Chung. This changes set_rtc_time(struct *rtc_time) to return an int instead of void. This was done so that the arch-specific code here could do additional checks on the time and return an error if needed. This then introduces include/asm-generic/rtc.h, include/asm-i386/rtc.h and include/asm-alpha/rtc.h. include/asm-generic/rtc.h contains the get_rtc_time and set_rtc_time logic that is in drivers/char/rtc.c and has been tested on SMP i386. This also modifies include/asm-ppc/rtc.h to return -ENODEV if no rtc hardware is present.

Additionally, Dave Jones pointed out to me a place where we might not be safe when jiffies wraps, so this switches that to time_after().

From Randolph Chung, is supprt for a 64bit kernel and a 32bit userland.

And now onto the history of this driver.

This has been in the m68k tree for a number of years now, so the general code behind it is quite sound. This has also been abstracted to the point where it works on other archs (mainly due to m68k/PPC hybrid machines). This is quite useful since a number of archs cannot use drivers/char/rtc.c because they have very different hardware, or other issues.

This should also be useful on MIPS, who at one point in the past were about to copy the PPC rtc driver (drivers/macintosh/rtc.c) and quite probably useful on other archs as well.

This has been in use by the parisc-linux people as well for some time, and a version similar to this has been tested by them in 2.5.

Based on some private feedback, I believe with some additional enhancements, ia64 will make use of this as well. And if the MIPS community ever did make an rtc driver similar to drivers/macintosh/rtc.c, they should be able to use this one rather trivially.

UML has been updated to 2.5.30 and UML 2.4.18-49. Most of the UML-specific stuff has been in hppfs, which isn't in this patch. The exception is a fix for a crash caused by killing a UML xterm.

Since UML didn't make 2.5.30, I'll be sending this patch in to Linus.

The patch is available at http://uml-pub.ists.dartmouth.edu/uml/uml-patch-2.5.30-1.bz2

For the other UML mirrors and other downloads, see http://user-mode-linux.sourceforge.net/dl-sf.html

Other links of interest:

The UML project home page : http://user-mode-linux.sourceforge.net
The UML Community site : http://usermodelinux.org

A new linux/x86-64 snapshot based on linux 2.4.19 has been released. For more information on x86-64 see http://www.x86-64.org

Full tar ball: ftp://ftp.x86-64.org/pub/linux/v2.4/linux-x86_64-2.4.19-1.tar.bz2 (still uploading, will soon appear on server)

Patch against normal 2.4.19 from kernel.org ftp://ftp.x86-64.org/pub/linux/v2.4/x86_64-2.4.19-1.bz2
55331b0973fe86549102b0ca720be109 x86_64-2.4.19-1.bz2

Changes:

• Merge to 2.4.19 final.
• Some minor bugfixes and cleanups.

I just sent you 6 bitkeeper patches for the i8xx series chipsets. The patches are:

1. ftp://medelec.uia.ac.be/pub/linux/kernel-patches/i8xx-patch-against-2.5.30-patch-1.txt This patch contains pci.ids updates for the i8xx chipsets
2. ftp://medelec.uia.ac.be/pub/linux/kernel-patches/i8xx-patch-against-2.5.30-patch-2.txt This patch makes the i810_rng Documentation the same as it is in 2.4.19
3. ftp://medelec.uia.ac.be/pub/linux/kernel-patches/i8xx-patch-against-2.5.30-patch-3.txt This patch adds a set of defines to pci_ids.h for 82801E and 82801DB I/O Controller Hub PCI-IDS. I could not add them all since two of them existed allready for the IDE controllers, but the naming was not ideal. That's why patch 5 and 6 corrects this.
4. ftp://medelec.uia.ac.be/pub/linux/kernel-patches/i8xx-patch-against-2.5.30-patch-4.txt This patch updates the i810-tco module to the same level as it is in 2.4.19 now.
5. ftp://medelec.uia.ac.be/pub/linux/kernel-patches/i8xx-patch-against-2.5.30-patch-5.txt This patch corrects the PCI-ID define for the 82801DB IDE controller.
6. ftp://medelec.uia.ac.be/pub/linux/kernel-patches/i8xx-patch-against-2.5.30-patch-6.txt This patch corrects the PCI-ID define for the 82801E IDE controller.

New version of the NTFS-TNG backport is out. This version syncs with both: the latest NTFS driver -- 2.0.22 and the latest Linux kernel -- 2.4.19.

You can get the patch from the sourceforge servers. See the detailes at http://linux-ntfs.sf.net/downloads.html

Linus, please do a

bk pull http://linux-ntfs.bkbits.net/ntfs-tng-2.5

Thanks!

This is quite a massive bug fix update. I have a dual athlon with 3G RAM to play with at the moment so have been able to iron out a lot of races, recursive locking, and subsequent deadlocks.

This should also fix the reported ntfs over loopback i/o error problems. At least I can no longer reproduce the errors after I added the optimization barrier() in fs/ntfs/compress.c. I suspect gcc screws up without it...

The attached patch is updating the Maestro3 OSS sound chip driver to

1. The changes in IRQ handling.
2. C99 standard conformant initializers.

The Linux Security Modules project provides a lightweight, general purpose framework for access control. The LSM interface enables security policies to be developed as loadable kernel modules. See http://lsm.immunix.org for more information.

2.5.30-lsm1 patch released. This is a rebase to 2.5.30 as well as the continuation of merging LSM with mainline.

Full lsm-2.5 patch (LSM + all modules) is available at: http://lsm.immunix.org/patches/2.5/2.5.30/patch-2.5.30-lsm1.gz

The whole ChangeLog for this release is at: http://lsm.immunix.org/patches/2.5/2.5.30/ChangeLog-2.5.30-lsm1

The LSM 2.5 BK tree can be pulled from: bk://lsm.bkbits.net/lsm-2.5

2.5.30-lsm1

• merge with 2.5.27 (Greg KH)
• merge with 2.5.28-30 (me)
• bk file merging to handle changes from mainline (Greg KH)
• removed BUS_ISA declaration (Greg KH)
• add settime hook (Robb Romans)
• SELinux: Bug fixes for the PSID mapping code. (Stephen Smalley)
• update initlialized to C99 sytle for cap and dummy modules. (Adam)
• Fix memory leaks in IPC LSM hooking. (Stephen Smalley)
• Fix file_lock hooks. (Matthew Wilcox)
• update modules according to file_lock hook change (me)
• DTE: logic cleanups (Serge Hallyn)
• SELinux: cleanup sysctl table (Chris Vance)
• __FUNCTION__ cleanup (Anton Blanchard)
• remove __exit attribute from selinux_nf_ip_exit (me)

2.4.19 lsm patch released. This is includes bugfixes and merging up to the current stable 2.4 Linux tree.

Full lsm-2.4 patch (LSM + all modules) is available at: http://lsm.immunix.org/patches/2.4/2.4.19/patch-2.4.19-lsm1.gz

The whole ChangeLog for this release is at: http://lsm.immunix.org/patches/2.4/2.4.19/ChangeLog-2.4.19-lsm1

The LSM 2.4 stable BK tree can be pulled from: bk://lsm.bkbits.net/lsm-2.4

2.4.19-lsm1

• merge through 2.4.19-rc5 (me)
• merge with 2.4.19 final (James Morris)
• SELinux: Bug fixes for the PSID mapping code. (Stephen Smalley)
• Fix memory leaks in IPC LSM hooking. (Stephen Smalley)
• Fix file_lock hooks. (Matthew Wilcox)
• update modules according to file_lock hook change (me)
• add settime() hook (Robb Romans)
• remove __exit attribute from selinux_nf_ip_exit (me)

I just sent changeset below to the Linus. If you are using my patches for TV-Out from ftp://platan.vc.cvut.cz/pub/linux/matrox-latest, please note that V4L2 support for setting brightness/contrast and other features is NOT part of this patch. I'll send it to Linus after V4L2 interface finds its way into the 2.5 kernel.

And also, as you may guess, driver is not ported to the new fbdev API.

Patch and bkpatch were removed from this copy of message - it is 129KB file. You can download it from ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/bkpatch-for-linus-2.5.30, or you can look at http://matroxfb.bkbits.net, or you can pull from bk://matroxfb.bkbits.net/linux-2.5 or ... It applies cleanly to the currently available 2.5 tree.