Kernel Traffic #318 by Zack Brown

[email protected] Sat, 27 Aug 2005 20:20:30 -0700

Newsgroups	gmane.linux.kernel.kernel-traffic
Message-ID	<[email protected]>

Kernel Traffic #318 For 27 Aug

By Zack Brown

Table Of Contents

* Standard Format
* Text Format
* XML Source
* Mailing List Stats For This Week
* Threads Covered

1. 20 Jun - 24 Jun (23 Asynchronous I/O Gets A Boost
posts)
2. 20 Jun - 24 Jun (36 Struggling To Remove DevFS
posts)
3. 21 Jun - 27 Jun (15 Difficulties Probing For IDE Hardware
posts)
4. 23 Jun - 24 Jun (6 Status Of SPI Development
posts)
5. 24 Jun - 29 Jun (50 Abortive New ndevfs Replacement For DevFS
posts)
6. 24 Jun (9 Bug Hunting With git
posts)
7. 24 Jun - 26 Jun (7 New Oops Reporting Tool (ORT)
posts)
8. 26 Jun - 30 Jun (60 Linux 2.6.12-mm2 Released; Crash Bug
posts) Identified And Fixed
9. 26 Jun - 27 Jun (5 Dell Systems Management Base Driver
posts)
10. 27 Jun - 1 Jul (23 Patch Review For Upcoming 2.6.12.2 Stable
posts) Release; Some Dissent On Acceptance Policies
11. 28 Jun - 29 Jun (15 Linux 2.6.13-rc1 Released
posts)
12. 29 Jun (2 Linux 2.6.12.2 Released
posts)
13. 30 Jun - 4 Jul (78 Status Of Merging FUSE
posts)
14. 1 Jul - 4 Jul (23 Linux 2.6.13-rc1-mm1 Released
posts)
15. 4 Jul (1 Linux 2.4.32-pre1 Released
post)
16. 5 Jul - 6 Jul (33 Linux 2.6.13-rc2 Released
posts)
17. 6 Jul - 7 Jul (6 SecurityFS Generic Security Filesystem For
posts) Security Modules

Mailing List Stats For This Week

We looked at 3229 posts in 19MB.

There were 1050 different contributors. 404 posted more than once. The average
length of each message was 104 lines.

+-----------------------------------------------------------------------------+
|The top posters of the week| The top subjects of the week were: |
| were: | |
|---------------------------+-------------------------------------------------|
|93 posts in 430KB by andrew|68 posts in 282KB for "fuse merging?" |
|morton |50 posts in 216KB for "[announce] ndevfs - a |
|83 posts in 375KB by greg |"nano" devfs" |
|kh |49 posts in 202KB for "updated git howto for |
|63 posts in 634KB by |kernel hackers" |
|johannes stezenbach |42 posts in 183KB for "mercurial vs updated git |
|60 posts in 425KB by greg |howto for kernel hackers" |
|kh |35 posts in 171KB for "[git patch] remove devfs |
|54 posts in 395KB by |from 2.6.12-git" |
|christoph lameter | |
+-----------------------------------------------------------------------------+

Full Statistics generated by mboxstats version 2.8

1. Asynchronous I/O Gets A Boost
20 Jun - 24 Jun (23 posts) Archive Link: "Pending AIO work/patches"
Topics: FS: NFS, POSIX, Samba
People: Suparna Bhattacharya, Trond Myklebust, S?bastien Dugu?, Andi Kleen,
William Lee Irwin III, Jeremy Allison, Chris Mason, Zach Brown, Benjamin
LaHaise

Suparna Bhattacharya said:

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).

Trond Myklebust said of item 5, "I'm working on something that attempts to
define per-arch low-level primitives (essentially wrappers to the current arch
specific code). I expect to post something in the next 2 weeks (or at least
before the kernel summit)..."

S?bastien Dugu? said of item 3, "I'm currently running some benchmarks
(sysbench + MySQL) using AIO, results will be available soon. I will also
release libposix-aio V0.5 at the same time. (2) will sure help cleanup our
code."

Elsewhere, Suparna said:

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 !

Andi Kleen remarked, "I looked over the patches and they look all fine to me."
Benjamin LaHaise also liked Suparna's patches, though he had his own
suggestions. William Lee Irwin III added, "I'm going to keep going over these
until I get tired of it for general bulletproofing purposes, but all
indications thus far are good."

Later, Suparna said, "here are the patches that implement the changes to make
filesystem AIO read and write truly asynchronous even without O_DIRECT. With
these patches in place it will no longer be necessary for the POSIX AIO library
(from S?bastien et al) to force O_DIRECT and memcpy for alignment. (Samba
should find this useful)" And Jeremy Allison replied, "Wonderful ! That's
exactly what we need - thanks. I could have fixed this in userspace but it
would be rather ugly."

2. Struggling To Remove DevFS
20 Jun - 24 Jun (36 posts) Archive Link: "[GIT PATCH] Remove devfs from
2.6.12-git"
Topics: FS: devfs, FS: initramfs, FS: ramfs, Hot-Plugging, Small Systems
People: Andrew Morton, Greg KH, Bill Gatliff, Mike Bell, David Brownell, Miles
Bader, Russell King, Arjan van de Ven

Greg KH posted a patch to entirely remove DevFS from the 2.6 kernel. Andrew
Morton replied, "Whimper. Maybe we should cook this in -mm for a bit, get a
feeling for how many users hate us, and how much?" Greg replied, "There might
be some complaints. But I doubt they would be from anyone running a -mm tree as
those people kind of know the current status of things in the kernel. There
have been numerous warnings as to the fact that this was going away, and I
waited a _year_ to do this. Also, no disto uses devfs only (gentoo is close,
but offers users udev and a static /dev also.)" Andrew said, "What happens if
we merge it and then the storm of complaints over the ensuing four weeks makes
us say "whoops, shouldna done that [yet]"?" Arjan van de Ven suggested simply
disabling the configuration option for a few weeks and see what that kicked up;
and Andrew and Greg both agreed this would be a good test of the waters.

Some folks spoke up in favor of keeping DevFS, because of the amount of work it
would be to switch to udev or some other solution. But other folks who had once
been pro-DevFS also spoke in favor of removing it now. For these folks, they
said the transition had been difficult, but as Bill Gatliff put it, "I've come
this far somewhat reluctantly, but can see that udev is a better long-term
solution. Once devfs is gone, it's easier for me to justify doing the work to
go fully over to udev."

Mike Bell made an impassioned plea to keep DevFS. He said:

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.

He also remarked somewhat bitterly, "It breaks a lot of my embedded setups
which have read-only storage only and thus need /dev on devfs or tmpfs. With
early-userspace-udev-on-tmpfs being - in my experience - still unready. Not to
mention the general bother of having to change dozens of desktop/server systems
to work with udev, but I doubt you care about that." Andrew spoke up to thank
Mike for his input. Andrew agreed that "that's quite a problem. We're certainly
causing people such as yourself to take on quite a lot of work. But on the
other hand we do want the kernel to progress sanely, and that sometimes
involves taking things out. I don't have enough info to know whether the world
would be a better place if we keep devfs, remove devfs or remove devfs even
later on. I don't think anyone knows, which is why we're taking this little
disable-it-and-see-who-shouts approach."

Close by, David Brownell remarked, "I'd agree that embedded setups are the ones
that have been slowest to switch over, for various reasons. One of them is that
many LKML folk ignore embedded systems issues; "just PC class or better".
Another has been that the basic hotplug scripts never worked well with "ash",
and who's going to want to ship "bash" and friends? :) Those problems seem
resolved with 2.6.12 and current modutils and udev. Leaving basically an
"upgrade your userspace" requirement." Miles Bader had to take issue with
David's statement that LKML folks didn't care about embedded systems. He said,
"maybe the average LKMLer doesn't actively worry so much about embedded issues,
I've found many of them are very friendly and helpful in getting patches for
embedded/small-system functionality cleaned up and merged into the mainstream
kernel." Russell King also agreed with this.

Greg pointed out to Mike that DevFS had been on the chopping block for over a
year, and folks who used it should have been preparing for its eventual demise.
He said if people hadn't been planning ahead, it was pretty much their own
fault if they ended up with a lot of work now. He added, "for embedded systems,
there are packages to build it and put it in initramfs. People have already
done the work for you."

Mike defended his position, and a flamewar seem imminent, but Greg said, "I've
taken the time that I would have spent responding to this email thread, and to
other people who for some reason don't like to respond to mailing lists but
want to pester me privatly with "don't delete devfs" type emails, and written
ndevfs, a replacement in less than 300 lines (including all needed hooks in the
kernel). If this does not meet your needs to keep devfs for your embedded
systems, please respond to the ndevfs post with the patch on lkml." And that
was it. The thread was over.

3. Difficulties Probing For IDE Hardware
21 Jun - 27 Jun (15 posts) Archive Link: "PATCH: IDE - sensible probing for
PCI systems"
Topics: Disks: IDE, PCI
People: Alan Cox, Maciej W. Rozycki

Alan Cox said:

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.

Maciej W. Rozycki remarked, "FYI, for MIPS for machines with a PCI bus we only
probe for ISA IDE ports on if there's a PCI-ISA or PCI-EISA bridge somewhere
there. This might be a good idea for the i386 and probably any platform using
PCI as well." Alan replied:

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 ?

Maciej replied:

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...

4. Status Of SPI Development
23 Jun - 24 Jun (6 posts) Archive Link: "[RFC] SPI core -- revisited"
Topics: I2C
People: dmitry pervushin, Jamey Hicks, Russell King

Dmitry Pervushin said, "we finally decided to rework the SPI core and now it
its ready for your comments.. Here we have several boards equipped with SPI
bus, and use this spi core with these boards; Drivers for them are available by
request (...and if community approve this patch)" Jamey Hicks replied:

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.

Russell King replied:

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.

Jamey thought a library could be a good idea. He said, "I think the only
algorithm that really gets shared is the bitbanging one, which could be a
library, and otherwise it is controller specific and might as well be in the
adapter."

5. Abortive New ndevfs Replacement For DevFS
24 Jun - 29 Jun (50 posts) Archive Link: "[ANNOUNCE] ndevfs - a "nano" devfs"
Topics: FS: devfs, FS: sysfs, Version Control
People: Greg KH, Mike Bell, Matt Mackall, J.A. Magallon

Greg KH created ndevfs, a very small replacement for DevFS. He said, "It
doesn't allow subdirectories, and only uses LSB compliant names. But it works,
and should be enough for people to use, if they just can't wean themselves off
of the idea of an in-kernel fs to provide device nodes. Now, with this, is
there still anyone out there who just can't live without devfs in their kernel?
" Mike Bell replied:

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.

He added, "If devfs could be left alone (disabled, if necessary) until
something like this was working, I would be completely mollified."

J.A. Magallon also liked Greg's implementation. But Matt Mackall said to Greg,
"Hmm. I'm not pleased. Perhaps you're pleasing the wrong people?"

And Greg replied:

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.

He added, "Thanks for calling me on this, I appreciate it. You weren't the only
one either, which is a good thing."

6. Bug Hunting With git
24 Jun (9 posts) Archive Link: "Finding what change broke ARM"
Topics: Version Control
People: Russell King, Linus Torvalds, Dave Hansen

Russell King said:

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...

Linus Torvalds replied:

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:

He went on, regarding Russell's comment about per-file history, saying:

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" 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.

7. New Oops Reporting Tool (ORT)
24 Jun - 26 Jun (7 posts) Archive Link: "[ANNOUNCE] ORT - Oops Reporting Tool
"
People: Michal Piotrowski

Michal Piotrowski said:

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.

There was a generally positive reaction, and various folks offered small
suggestions for improvements.

8. Linux 2.6.12-mm2 Released; Crash Bug Identified And Fixed
26 Jun - 30 Jun (60 posts) Archive Link: "2.6.12-mm2"
Topics: Hyperthreading, Kernel Release Announcement, PCI, SMP
People: Andrew Morton, Reuben Farrelly, Ingo Molnar

Andrew Morton announced Linux 2.6.12-mm2, saying:

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 [email protected]'

+ 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.

Reuben Farrelly identified a reproducible bug introduced with this release. An
oops "seems to happen at slightly different places in the bootup, especially at
the end." Andrew replied, "Why do you keep breaking my kernel?"

Andrew asked Reuben to send in his .config file, which he did; and Andrew
replied, "The bug is in the new spinlock debugging code itself. Ingo, can you
test that .config please? Reuben, I guess disabling CONFIG_DEBUG_SPINLOCK will
get you going."

Ingo Molnar banged away at this configuration, and finally reported:

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.

Reuben confirmed that Ingo's patch fixed the problem.

9. Dell Systems Management Base Driver
26 Jun - 27 Jun (5 posts) Archive Link: "[PATCH][RFC 2] char: Add Dell
Systems Management Base driver"
Topics: Ioctls
People: Doug Warzecha

Doug Warzecha said:

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.

10. Patch Review For Upcoming 2.6.12.2 Stable Release; Some Dissent On
Acceptance Policies
27 Jun - 1 Jul (23 posts) Archive Link: "[00/07] -stable review"
People: Chris Wright, Andrew Morton, Jean Delvare

Chris Wright said:

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 [email protected] 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.

Most of the patches were quite small, but one was larger, and Jean Delvare had
some objections. First of all, the description of the patch was, "Return to
previous held-logic of calling scsi_add_host() only after the board has been
completely initialized. Also return pci_*() error-codes during probe failure
paths. This also corrects an issue where only lun 0 is being scanned for a
given port." Jean felt this was not complete enough, and didn't identify any
critical bugs to fix. He also went over the patch piece by piece, and found
several areas that he felt did not belong in the -stable tree. But Andrew
Morton said, "The threshold for "what belongs in -stable" is a) set too high
and b) over-zealously enforced." He added that the patch was "obviously safe",
and went on, "Let's use our brains on these patches and not become beholden to
doctrine, OK?" Chris agreed with these sentiments. But Jean replied, "Why did
we write down and discuss rules for -stable (http://kerneltraffic.org/
kernel-traffic/kt20050403_303.html#9) in the first place then? Of the 9 rules
Greg first listed as conditions for a patch to be accepted in -stable, this
patch breaks 4 (it is bigger than 100 lines, if fixes more than one thing,
including one that doesn't bother people as far as I can see, and it has
trivial fixes in it.) So I don't think I am actually splitting hair as you
seemed to suggest."

11. Linux 2.6.13-rc1 Released
28 Jun - 29 Jun (15 posts) Archive Link: "Linux 2.6.13-rc1"
Topics: Digital Video Broadcasting, Kernel Release Announcement, Networking
People: Linus Torvalds, Bill Davidsen

Linus Torvalds announced Linux 2.6.13-rc1, saying:

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.

Bill Davidsen remarked:

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.

12. Linux 2.6.12.2 Released
29 Jun (2 posts) Archive Link: "Linux 2.6.12.2"
People: Chris Wright

Chris Wright announced Linux 2.6.12.2, saying:

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/ (http://www.kernel.org/git/)

13. Status Of Merging FUSE
30 Jun - 4 Jul (78 posts) Archive Link: "FUSE merging?"
Topics: FS: NFS, Security
People: Andrew Morton, Bert Hubert, Anton Altaparmakov, Miklos Szeredi

Miklos Szeredi asked about the status of merging FUSE into the mainline kernel.
There started to be a bit of an argument over various ugly security aspects,
but at one point Andrew Morton said:

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.

A bunch of folks started hashing out a better implementation; elsewhere, Andrew
asked, "dumb question: what does FUSE offer over simply using NFS protocol to
talk to the userspace filesystem driver?" Bert Hubert replied, "NFS currently
does not currently engender warm feelings wrt ease of programming and quality
in general - especially under Linux sadly enough. It is also a narrow window
through which to speak to the rich set of options, flags, attributes and
features the Linux kernel offers. I think Solaris used to implement bind mounts
through loopback NFS, but that went out of fashion as well."

Miklos also started listing benefits, but at one point Andrew remarked, "Sorry,
but I'm not buying it. I still don't see a solid reason why all this could not
be done with nfs/v9fs, some kernel tweaks and the rest in userspace. It would
take some effort, but that effort would end up strengthening existing kernel
capabilities rather than adding brand new things, which is good." Anton
Altaparmakov replied:

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...

He added in a subsequent post:

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. (-;

The discussion did not result in any concrete yay or nay on FUSE.

14. Linux 2.6.13-rc1-mm1 Released
1 Jul - 4 Jul (23 posts) Archive Link: "2.6.13-rc1-mm1"
Topics: Bug Tracking, Kernel Release Announcement, Power Management: ACPI
People: 2.6.13-rc1-mm1, Andrew Morton

Andrew Morton announced Linux 2.6.13-rc1-mm1, saying:

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 [email protected].

15. Linux 2.4.32-pre1 Released
4 Jul (1 post) Archive Link: "Linux 2.4.32-pre1"
Topics: Security
People: Marcelo Tosatti

Marcelo Tosatti announced Linux 2.4.32-pre1, saying:

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)

16. Linux 2.6.13-rc2 Released
5 Jul - 6 Jul (33 posts) Archive Link: "Linux 2.6.13-rc2"
Topics: Compression, Kernel Release Announcement, SMP
People: Linus Torvalds

Linus Torvalds announced Linux 2.6.13-rc2, saying:

Ok, -rc3 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.

17. SecurityFS Generic Security Filesystem For Security Modules
6 Jul - 7 Jul (6 posts) Archive Link: "[PATCH] add securityfs for all LSMs to
use"
Topics: FS: sysfs
People: Greg KH, Mike Waychison

Greg KH said, "Here's a small patch against 2.6.13-rc2 that adds securityfs, a
virtual fs that all LSMs can use instead of creating their own. The fs should
be mounted at /sys/kernel/security, and the fs creates that mount point. This
will make the LSB people happy that we aren't creating a new /my_lsm_fs
directory in the root for every different LSM." Mike Waychison asked, "How are
LSM modules supposed to use these files? or is that forthcoming?" Greg replied,
"It's up to them to use it. See the patches from Serge that convert seclvl to
use it instead of sysfs."

Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor
Greg Benson and Professor Allan Cruse in the Department of Computer Science at
the University of San Francisco. This is the same department that invented
FlashMob Computing. Kernel Traffic is hosted by the generous folks at
kernel.org. All pages on this site are copyright their original authors, and
distributed under the terms of the GNU General Public License, version 2.0.