Kernel Traffic #318 For 27 Aug 2005

Since AIO development is gaining momentum once again, ocfs2 and samba both appear to be using AIO, NFS needs async semaphores etc, there appears to be an increase in interest in straightening out some of the pending work in this area. So this seems like a good time to re-post some of those patches for discussion and decision.

Just to help sync up, here is an initial list based on the pieces that have been in progress with patches in existence (please feel free to add/update ones I missed or reflected inaccurately here):

1. Updating AIO to use wait-bit based filtered wakeups (me/wli)
   Status: Updated to 2.6.12-rc6, needs review
2. Buffered filesystem AIO read/write (me/Ben)
   Status: aio write: Updated to 2.6.12-rc6, needs review
   Status: aio read : Needs rework against readahead changes in mainline
3. POSIX AIO support (Bull: Laurent/Sebastian or Oracle: Joel)
   Status: Needs review and discussion ?
4. AIO for pipes (Chris Mason)
   Status: Needs update to latest kernels
5. Asynchronous semaphore implementation (Ben/Trond?)
   Status: Posted - under development & discussion
6. epoll - AIO integration (Zach Brown/Feng Zhou/wli)
   Status: Needs resurrection ?
7. Vector AIO (aio readv/writev) (Yasushi Saito)
   Status: Needs resurrection ?

On my part, I'll start by re-posting (1) for discussion, and then move to (2).

Here is a little bit of background on the motivation behind this set of patches to update AIO for filtered wakeups:

1. Since the introduction of filtered wakeups support and the wait_bit_queue infrastructure in mainline, it is no longer sufficient to just embed a wait queue entry in the kiocb for AIO operations involving filtered wakeups.
2. Given that filesystem reads/writes use filtered wakeups underlying wait_on_page_bit, fixing this becomes a pre-req for buffered filesystem AIO.
3. The wait_bit_queue infrastructure actually enables a cleaner implementation of filesystem AIO because it already provides for an action routine intended to allow both blocking and non-blocking or asynchronous behaviour.

As I was rewriting the patches to address this, there is one other change I made to resolve one remaining ugliness in my earlier patchsets - special casing of the form

if (wait == NULL) wait = &local_wait

to switch to a stack based wait queue entry if not passed a wait queue entry associated with an iocb.

To avoid this, I have tried biting the bullet by including a default wait bit queue entry in the task structure, to be used instead of on-demand allocation of a wait bit queue entry on stack.

All in all, these changes have (hopefully) simplified the code, as well as made it more up-to-date. Comments (including better names etc as requested by Zach) are welcome !

Once devfs is out, it's out for good. It is for all intents and purposes impossible to maintain such a thing outside of mainline. You should know that, udev's kernel infrastructure was developed pretty much entirely within mainline and look how long it took to get even the present number of drivers working with it.

It's pretty hard to put effort into devfs when said patches won't get merged because it has already been decided by certain people that devfs is not the way to go. For example the quick death without comment of the earlier devfs-on-top-of-tmpfs patches.

Or, look at how hard of a time udev had gaining mindshare, how long it was around for until now. Only shock tactics like marking devfs OBSOLETE (at a time when udev was completely unready to replace devfs, making it far from obsolete) got people switching.

Old ISA/VESA systems sometimes put tertiary IDE controllers at addresses 0x1e8, 0x168, 0x1e0 or 0x160. Linux thus probes these addresses on x86 systems. Unfortunately some PCI systems now use these addresses for other purposes which leads to users seeing minute plus hangs during boot or even crashes.

The following patch (again has been in Fedora for a while) only probes the obscure legacy ISA ports on machinea that are pre-PCI. This seems to keep everyone happy and if there is someone with that utterly weird corner case the ide= command line still provides a get out of jail card. Unsurprisingly we've not found anyone so affected.

The primary/secondary ISA ports show up in PC systems because of the PCI IDE class devices being in compatibility mode not native mode (so you can still run old OS's). There are also a couple of older weird cases.

The PCI layer code is smart enough to figure out when a PCI and an ISA probe find the same device and to put the entire thing together properly so that aspect of it is ok.

For the 3rd and higher ports probing them isn't safe on a PCI box regardless of the presence of ISA bridges so I don't think we need the extra complexity - or am I missing something ?

The code is OK with me, but I've been wondering whether a more general approach would be possible. And poking blindly at any of these ports, including the "traditional" primary and secondary IDE interfaces, is unsafe if there is no legacy bridge in the system, because you either hit an innocent arbitrary device that happens to have a BAR configured for that range or get a master abort (I'm not sure what it results in for the i386 -- an NMI?) if nobody listens.

Actually there should have always been a set of BARs for the (E)ISA in legacy bridges, which would have made the whole mess be avoided, sigh...

I'm glad to see that work is progressing on SPI core. I've worked on drivers on both ARM linux and Blackfin uclinux that use SPI and would prefer that they not be platform specific.

What I've found in my Blackfin work is that I need asynchronous SPI support. The driver starts an SPI transaction and receives a callback when the SPI transaction has completed. The operations are similar to what you've suggested, except that the message structure includes a pointer to a callback and a void *data pointer.

The driver I'm working on is for the Chipcon CC2420 802.15.4 radio, which uses SPI to access its registers and transmit and receive FIFOs. In my CC2420, it queues SPI requests and initiates the next one when an SPI transaction completes.

I worry about SPI at the moment because I can't see how it's being used from just this code.

The worry I have is that it appears to contain an algorithm layer. Would this be better as a library for drivers to use, or something like that?

The reason I bring up this point is that my L3 layer is over-complex for what it does (despite being about 378 lines) because it tried far too hard to look like the I2C layer - soo much so I'm not happy with it for mainline.

this is pretty much all I asked for. A simple kernel filesystem to export device nodes with names, rather than just the numbers as sysfs does. The "detecting non-existant device names" thing never meant anything to me personally, and if anyone does care this gives them a simple place to add such a hook - unlike device names I don't see why such a thing would be difficult to maintain as a patch.

It'll obviously need support for symlinks, directories and mknod. And I'm not sure you can change the mode/owner of those devices yet. Also, I have no idea what the device support is like yet (am currently in the middle of nowhere, getting the latest bk to test this patch with over my handphone would not be fun) but looking at the bit where it's getting the names from the device model I can see it encountering problems with oddly named devices. And any devices which aren't dynamic in udev obviously aren't going to work with this patch either.

You are so right, I am. I need to be pleasing me, and devfs in the kernel is not the correct solution. I knew this 4 years ago when Pat and I started working on the driver core (my main goal was to do it to support a udev-like solution), and I still know this today.

So no, I'm not going to be submitting this. But what it is, is a nice proof-of-concept for people who "just can't live without a in-kernel devfs" to show that it can be done in less than 300 lines of code, and only 6 hooks (2 functions in 3 different places) in the main kernel tree. That is managable outside of the main kernel for years, with almost little to no effort.

When building current git for ARM, I see:

  CC      arch/arm/mm/consistent.o
arch/arm/mm/consistent.c: In function `dma_free_coherent':
arch/arm/mm/consistent.c:357: error: `mem_map' undeclared (first use in this function)
arch/arm/mm/consistent.c:357: error: (Each undeclared identifier is reported only once
arch/arm/mm/consistent.c:357: error: for each function it appears in.)
make[2]: *** [arch/arm/mm/consistent.o] Error 1

How can I find what change elsewhere in the kernel tree caused this breakage?

With bk, you could ask for a per-file revision history of the likely candidates, and then find the changeset to view the other related changes.

With git... ? We don't have per-file revision history so...

Ahhah! A real-world example of what cool things git can do.

Anyway, the first starting point is _exactly_ the same as under BK, except the syntax is very different, and git does it better, in fact:

git-whatchanged -p arch/arm/mm/consistent.c

However, in this case nothing has changed in that file over the whole git history, so you get an empty answer. Let's go to phase two, but first a comment:

We don't _store_ changes as per-file revision histories, but we do store it in a way where finding out what happened is efficient even per-file. While a line-by-line "annotate" is not efficient, the "what changed" certainly is.

And git actually does better than BK (or _any_ per-file history thing), because "git-whatchanged" actually works over directories or multiple independent files too, and it works purely on pathnames, so you can say "git-whatchanged" for a file that has gone away to see _why_ it went away. In most other systems it's really hard to see what happened to something that isn't there any more..

Anyway, the problem clearly didn't happen because of any changes to that file at all, so here per-file history simply doesn't help. But never fear, we're not screwed yet. In particular, you will now obviously suspect that since it wasn't that _file_ that changed, and since you know what changed in the ARM code, it's going to be a generic linux header file change that screwed you over.

So phase #2 is to do

git-whatchanged -p include/linux

(which shows every commit that touches include/linux, and shows that part as a patch, thus the "-p"). That starts up a pager on the results by default, so we just be stupid about it and do a "/mem_map/index.html" to look for changes that mention mem_map. Maybe we'll be lucky.

Even that doesn't show a whole lot: but it does point a very suspicious finger to the recently merged sparse-mem stuff from Andy Whitcroft, though.

And now you have a commit to look at, namely the "sparsemem memory model" one, commit ID d41dee369bff3b9dcb6328d4d822926c28cc2594.

In fact, looking at it, I think it's simply config option changes, and probably the SPARSEMEM config option that has preempted your lack of DISCONTIGMEM support. But now you have somebody to blame and to ask for help from: Andy Whitcroft and Dave Hansen, whom I've cc'd.

I might start phase #3 with

git-whatchanged -p mm/Kconfig arch/arm/Kconfig

but at this point you may already have enough of a clue that you don't even care any more.

Here is our (see copyright section ;)) simple script that help to create a bug report:
http://stud.wsi.edu.pl/~piotrowskim/files/ort/beta/ort-b1.tar.bz2 <http://stud.wsi.edu.pl/%7Epiotrowskim/files/ort/ort-a5.tar.bz2>

Why do we do this?
Because many people don't have time to prepare a good (with all importrant pieces of information) bug report.

How does it work?
It creates file with information about your system (software, hardware, used modules etc.), add file with oops into it and in the future sends it to the chosen mainterner or lkml.

How can you help?
If you know something about bash scripting you can review it, add some useful features and make some optimalisations. Or just send me an idea.

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12/2.6.12-mm2/

• A reminder that there is a vger mailing list for tracking patches which are added to -mm. Do

  `echo subscribe mm-commits | mail majordomo@vger.kernel.org'

• Lots of merges. I'm holding off on the 80-odd pcmcia patches until we get the recent PCI breakage sorted out.
• Big arch/cris update.

couldnt reproduce it on an UP box, nor on an SMP/HT 2/4-way box, but it finally triggered on a 2-way SMP box.

the bug is that current->pid is not a unique identifier on SMP (doh!).

The patch below fixes the bug - which also happens to be a speedup for the debugging code, as the ->pid dereferencing does not have to be done anymore. Also, i've disabled the panicing for now.

This patch adds the Dell Systems Management Base driver.

The Dell Systems Management Base driver is a character driver that implements ioctls for Dell systems management software to use to communicate with the driver. The driver provides support for Dell systems management software to manage the following Dell PowerEdge systems: 300, 1300, 1400, 400SC, 500SC, 1500SC, 1550, 600SC, 1600SC, 650, 1655MC, 700, and 750.

By making a contribution to this project, I certify that: The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file.

This is the start of the stable review cycle for the 2.6.12.2 release. There are 7 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let us know. If anyone is a maintainer of the proper subsystem, and wants to add a signed-off-by: line to the patch, please respond with it. These patches are sent out with a number of different people on the Cc: line. If you wish to be a reviewer, please email stable@kernel.org to add your name to the list. If you want to be off the reviewer list, also email us. Responses should be made by Wed, Jun 29, 23:00 UTC. Anything received after that time, might be too late.

There was a lot of stuff pending after 2.6.12, and in the week and a half since the release, the current diff against it has grown to almost three megabytes compressed.

Which is actually normal for a -rc1 release judging by the two last ones, but it usually takes us longer than ten days to get there. Which just shows that 2.6.12 was brewing for too long, but we can also think positively and say that perhaps it also seems to imply that this git thing is working out and not slowing people down.

Anyway, I really don't want to drag out 2.6.13 as long as 2.6.12 took, and we don't have any reason to anyway, so let's try to see if we can calm things down again, and people who are thinking about writing new code might think about spending some quality time looking at the existing code and patches instead.

Now, that big patch ends up being spread out over 2069 commits, and a noticeable chunk of it is actually the new xtensa architecture that got merged, but that still leaves a lot of patches all over the place (things like a few new console fonts, for example ;). The shortlog is over 100kB in size, which means that I think linux-kernel won't take it if I include it here, so I won't. Similarly, the diffstat is 200kB, partly because of the spread out nature of the pacthes.

ARM, x86[-64], ppc, sparc updates, networking, sound, infiniband, input layer, ISDN, MD, DVB, V4L, network drivers, pcmcia, isofs, jfs, nfs, xfs, knfsd.. You name it.

Git trees and traditional patches/tar-balls are out there, or at least slowly mirroring out.

Can't comment on git slowing things down, but I have to think that the time it took, and was ALLOWED to take, is a result of the -stable fixes working very well indeed. The fact that the 2.6.11.X was available to take the presure off to get something out of the door.

My big thank you to the stable folks, I personally think this idea is working as intended.

We (the -stable team) are announcing the release of the 2.6.12.2 kernel.

The diffstat and short summary of the fixes are below.

I'll also be replying to this message with a copy of the patch between 2.6.12.1 and 2.6.12.2, as it is small enough to do so.

The updated 2.6.12.y git tree can be found at:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/gregkh/linux-2.6.12.y.git
and can be browsed at the normal kernel.org git web browser:
www.kernel.org/git/

I believe that the requirement which fuse_allow_task() attempts to satisfy is legitimate and is useful to FUSE users.

The fact that, AFAIK, nobody as found a way to implement it more nicely is a Linux problem, not a FUSE problem.

Given that the actual amount of code involved is small, centralised and well known about we can easily fix it up later if/when new infrastructure or new ideas become available.

So unless someone is able to come up with a better approach in the next few days I'm inclined to say "we suck" and merge the thing as-is.

However, a few things:

• is there anything in the current implementation of the permission stuff which might tie our hands if it is later reimplemented? IOW: does the current FUSE user interface in any way lock us into the current FUSE implementation (fuse_allow_task())?
• the fuse mount options don't seem to be documented
• aren't we going to remove the nfs semi-server feature?
• Frank points out that a user can send a sigstop to his own setuid(0) task and he intimates that this could cause DoS problems with FUSE. More details needed please?
• I don't recall seeing an exhaustive investigation of how an unprivileged user could use a FUSE mount to implement DoS attacks against other users or against root.

FUSE is a generic FS API which is _very_ easy to write an FS for (learning curve is about 10-15 minutes starting after you have unpacked the fuse source code, at least it took me that long to start writing an FS based on the example one provided). NFS is not anything like that.

Also can the NFS approach provide me with different content depending on the uid of the accessing process? With FUSE that is easy as pie. Even easier than that actually...

I forgot: And doesn't NFS require stable inode numbers and other "invariables" like that for it to work? FUSE doesn't and those requirements are a real PITA in a lot of cases where there simply are no inodes and the numbers are synthetic and change on each remount or even on each access after the dentry has expired...

And I always thought that doing FS in userspace via NFS is considered an ugly hack. I didn't have the impression that that had changed recently. (-;

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc1/2.6.13-rc1-mm1/

• The ACPI devel tree is back, and it's huge. Please report ACPI bugs using kernel bugzilla at http://bugme.osdl.org. If that's all too much hassle then please at least cc acpi-devel@lists.sourceforge.net.

Here goes the first -pre of v2.4.32.

It contains a small amount of fixes, most notably x86_64 security updates.

Check for canonical addresses in ptrace (CAN-2005-1762)
Fix canonical checking for segment registers in ptrace (CAN-2005-0756)
Fix buffer overflow in 32bit execve on x86-64/ia64 (CAN-2005-1768)

Ok, -rc2 is pretty small, with the bulk of the diff being some defconfig updates, and cleanup of xtensa (notably removal of another copy of zlib).

But there are ia64/arm/ppc64 updates and the TSO update from Davem is probably worth pointing out to people. And various smaller things which are more easily just seen from the shortlog.

Among the one-liners of note is the silly block level spinlock bugfix that obviously hit -rc1 and made itself felt on SMP and preempt under moderate IO loads.