call fsync on inode 1
it goes down to ext2_update_inode [update == 1]
it calls ll_rw_block at the end
ll_rw_block starts to write buffer
ext2_update_inode waits on buffer

while the buffer is writing, another process calls fsync on inode 2
it goes again to ext2_update_inode
it calls ll_rw_block
ll_rw_block sees buffer locked and exits immediatelly
ext2_update_inode waits for buffer
the first write finished, ext2_update_inode exits and changes made by
second proces to inode 2 ARE NOT WRITTEN TO DISK.

This bug causes that when you simultaneously fsync two inodes in the same
buffer, only the first will be really written to disk.

Andrew Morton confirmed this, and said,
"This
is a general weakness in the ll_rw_block() interface. It is not suitable
for data-integrity writeouts, as you've pointed out."
He proposed a
fix for 2.5, but Mikulas didn't think that would be satisfactory; and they
discussed the various implications. Elsehwere, Pavel Machek suggested the
bug should also be fixed in the 2.4 tree, but Mikulas said:

It should, but it is a hazard. The problem is that every use of
ll_rw_block has this bug, not only the one in ext2 fsync. The most clean
thing would be to modify ll_rw_block to wait until buffer becomes
unlocked, no one knows if it can produce some weird things.

Even Linus didn't know what he was doing, see this comment around the
buggy part in 2.2, 2.0 and previous kernels.

Last week I finally got access to a decent (but old) technical specification
for the ZT5550 redundant host controller. The document was published for
the ZT5550C, but I am hoping that newer versions of the RHC just add more
functionality to all the documented reserved bits in the document I am
looking at.

The following patch adds a sysfs interface to most of the bits accessible
via the indirect register (through the HCINDEX and HCDATA addresses in the
Command and Status Register (CSR). The only bits I did not add access to
were the ones that are cleared by reading. There are a lot of bits to get
access to, which makes this patch a little bigger then I first expected,
so I created a new config option so only people who actually want to mess
with the RHC would pay for it.

Enabling this code will cause a new directory called zt5550_rhc to be
created in the root of sysfs

He showed an extensive directory tree, saying:

This provides all kind of rope to hang yourself with, but it was fun
messing with it. This also points out other areas where an interested party
could further enable this particular board, for example adding the code to
respond to a fault condition (after enabling fault handling through sysfs).

This patch was generated off of today's bk tree with the previously posted
patch by Scott to fix the deadlock issue and the patch posted by Stanley to
add sysfs support. Both of these patches are attached as a single patch to
this email message.

Greg KH said that the root of sysfs was not the place for this directory,
and suggested
"putting this directory either under the
pci device that is the zt5550 (if it is a pci device), or at the least,
under the devices/ directory."
Rusty said he'd go with the former
location. Later, Rusty posted an updated patch with more advanced features, and
after a recommendation by Scott Murray, Greg accepted the patch, and aimed it up
to Linus.

I have it building relatively well within the kernel, and have modified
the usr/gen_init_cpio.c file to add files to the cpio "blob". That all
seems to work, but I don't seem to be able to extract the files properly
(or at least that's what I'm guessing is happening).

I've managed to mount the initramfs with MS_BIND into my root fs and
found why /sbin/hotplug cannot be run currently. There is some
off-by-one bug during file extraction that causes the first byte
of the file to get left out. I.e. the file starts with "ELF\001"
instead of "\577ELF".

This may or may not be related to another off-by-one bug that I'm
seeing sometime when unpacking initramfs on s390x ("panic: length
error").

The patch below is how I hacked prepare_namespace() to keep
initramfs visible after boot.

Later he explained,
"I found what kept initramfs
from working here: While creating of initramfs_data.cpio.gz, the padding
between a file header and the file contents was wrong, which can be verified
by unpacking the archive by hand. The trivial patch below fixed this for
me."
Greg liked that patch and incorporated it into his tree.

Jens Axboe said,
"The attached patch implements
write barrier operations in the block layer and for IDE, specifically. The
goal is to make the use of write back cache enabled ide drives safe with
journalled file systems. Patch is against 2.4.21-pre4-bk as of today, and
includes a small patch to enable it on ext3. Chris has a patch for reiserfs
as well."
Marc-Christian Petersen was happy about this, but asked if
Jens could make another patch against 2.4.20; Jens replied,
"Sure, I had that one already. BTW, I discovered that the default io
scheduler forgets to honor the cmd_flags, it's supposed to break like the
noop does (see very first hunk in very first file). Must have removed that
by mistake some time ago... This applies both to the 2.4.21-pre4 patch posted
and this one."

Marc tried out the new version and remarked,
"I don't have benchmarks handy yet but as far as I can _feel_,
this is a _MUST_ (I repeat: a _MUST_ for 2.4.21). And I am very good in
feeling slowdowns for interactivity :)"

Muli Ben-Yehuda announced,
"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 attempts 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."
He said:

syscalltrack-0.82, the 14th 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 platform.

This release containes several new features, bug fixes and cleanups.

New in version 0.82, "Minty Chinchilla"

This release adds support for matching and logging the current
working directory. "I feel that the '%cwd' macro in logging format
is really useful since it allows to know if 'open("passwd", ...)'
relates to '/etc/passwd/index.html' rather than '/home/joe/tmp/passwd/index.html'." Patch
from Simon Patarin.

This release allocates the memory for kernel logging buffer using
vmalloc, which allows you to allocate much more memory for them than
the previous version. Patch from Simon Patarin.

This release contains rewritten serialization/deserialization code
for the rules library. The new code fits better with the overall
design and is cleaner and more robust.

This release contains a bug fix when detecting whether the kernel
modules are loaded in the user space libraries. Modules should now
be correctly recognized as loaded/unloaded in all cases. Bug spotted
by Mike Shea.

This release contains a bug fix for sctrace where sctracing a
program with command line arguments could fail to find the program
to trace.

This release contains several testing improvements, including a new
regression test script, from Orna Agmon.

This release installs the syscalltrack binaries to
${prefix}/bin/name-version, to allow several syscalltrack versions
to coexist. Kernel modules are installed to
'/lib/modules/kernel-version/syscalltrack-version/index.html'.

The xfs patches for 2.4.20 have been respun as of 2003-02-05 23:39 UTC,
including kdb v3.0.

For some time the XFS group have been producing split patches for XFS,
separating the core XFS changes from additional patches such as kdb, xattr,
acl, dmapi. The split patches are released to the world with the hope that
developers and distributors will find them useful.

Read the README in each directory very carefully, the split patch format
has changed over a few kernel releases. Any questions that are covered by
the README will be ignored. There is even a 2.4.21/README for the terminally
impatient :).

Here's a series of PCI Hotplug patches, a few related PCI core patches,
and two small, related sysfs patches.

The hotplug driver patches consist of a lot of bug fixes due to problems
found by the smatch and checker projects, and a big patch to remove pcihpfs
and use sysfs instead from Stanley Wang. I've also moved the few functions
in drivers/hotplug/pci_hotplug_util.c to drivers/pci/hotplug.c which is a
better place for them.

There are some sysfs updates for pci devices from Dan Stekloff and a
new function was added to sysfs to support the move from pcihpfs to sysfs.
This sysfs patch was blessed by Pat Mochel.

This patch provides discontigmem support for the IBM x440. This code has
passed through the hands of several developers: Chandra Seetharaman, James
Cleverdon, John Stultz, and last to touch it, me :-) This patch requires
full acpi support.

I've tested this patch on an 8 way x440 16 GB of RAM with and without HT
(acpi=off).

Andrew Grover pointed out that part of her patch broke ACPI event handling,
and that it would need to be fixed; but remarked,
"Other than that, thumbs up. SRAT support is a good thing to
have."

The Linux Test Project test suite
LTP-20030206.tgz has been released. Visit our website (http://ltp.sourceforge.net)
to download the latest version of the testsuite that contains 950+
tests for the Linux OS. The site also contains other information
such as: test results, a Linux test tools matrix, technical papers and
HowTos on Linux testing, and a code coverage analysis tool. There is
also a list of test cases that are expected to fail, located at (http://ltp.sourceforge.net/expected-errors.php)

Inclusion of all submitted and accepted patches/fixes through 02/05/03.

We encourage the community to post results, patches, or new tests on our
mailing list, and to use the CVS bug tracking facility to report problems
that you might encounter. More details available at our web-site.

As of the next release, we will be adding the option to license the ACPI
AML interpreter (drivers/acpi/*/*.c) under the BSD license, as well as the
current, GPL license.

While this will nominally increase your rights w.r.t. the code, the
real reason for this is for us to more easily accept external contributor's
changes into the interpreter's code (a good thing for everyone).

The Linux-specific ACPI code (drivers/acpi/*.c) is not affected by this
change (i.e. it is still GPL-only).

This was mentioned a couple of months ago, but we're now finally getting
around to doing it. :)

(I can't get to kernel.org right now, sorry) and there's a bk tree at:

bk://kernel.bkbits.net/gregkh/linux/klibc-2.5

I'd really like to send this to Linus now, but I'm going to be away from
email for about a week, so I'll wait will I get back. If anyone has any
issues with this patch, please let me know.

H. Peter Anvin was happy for the delay, since it meant more time to pound
on it, and asked what version of klibc it was based on. Greg replied,
"klibc-0.72. Ugh, I see you've now released a few versions
since then :( I'll sync up to the latest version before sending the patch
on to Linus, thanks for making me look."

Adam's cleanup and cutdown of devfs has been put back in again. We
really need devfs users to test this and to report, please. (And not just
to me! I'll only bounce it to Adam J. Richter <adam@yggdrasil.com (mailto:adam@yggdrasil.com)
>
anyway)

I've been using it on the desktop for a week. Certain operations are
noticeably different; for example a big `cvs co' would previously have had
several-second stalls every 20 seconds or so. Now, things slow down but it
keeps going. I'm sure the overall runtime will be slightly increased, but
overall the decreased read latency is good.

dcache_rcu has been put back.

An hour or so later, he took the patch down, and reported,
"there's something bad in the signal changes in Linus's
current tree. mozilla won't display, and is unkillable."
Daniel
Jacobowitz confirmed,
"Yeah, I'm seeing hangs in
rt_sigsuspend under GDB also. Thanks for saying that they show up without
ptrace; I hadn't been able to reproduce them without it. Something is
causing realtime signals to drop."
Later that day, Andrew said:

OK. Looks like Linus is hot on the trail.

BTW, some nice people have been sending in smalldevfs testing results
(successful). I've put that patch back up at

I'm afraid that I have to bring this news to linux-kernel; people who
have written code for the Linux kernel need to know about this, and we need
to come to a decision about the action we wish to take. Taking no action
sends a message that "we don't care what you do with kernel code, even if
you violate the terms of the license."

It would appear that Castle Technology Limited, UK, have taken some of
the Linux kernel 2.5 code, and incorporated it into their own product, "RISC
OS", which is distributed in binary ROM form built into machines they sell.
This code is linked with other proprietary code.

I have a detailed description which shows how the Linux source code can be
slightly modified to produce the disputed code, with reasons each modification.
This will be provided to people upon private email request.

Having discussed this with Linus, Linus is of the opinion that a public
letter should be written to Castle Technology Ltd, copied to lkml and various
news sites. However, I'd like to get this issue into the minds of people
who have touched any of the following code:

PCI subsystem

IO resource allocation

The guy who reported the problem to me has already tried to contact
the company concerned to ask for the source under the terms of the GPL,
and this resulted in the "function signatures" being removed in the next
version of the product, while the actual code remained. No other response
was forthcoming.

Subsequently, during the first week of January, the guy has contacted
the company again asking for the source covering the disputed code, this
time copying me with the email. Again, no repsonse from Castle Technology
has been forthcoming to date.

Someone pointed out the following quote from Castle Technology's web site (http://www.iyonix.com/32bit/PCI_API.shtml)
: "Note that the
source code for many of the Linux PCI device drivers is publicly available
on the Internet and may be useful in developing the corresponding RISC OS
device driver." Alan J. Wylie also pointed out:

I'd like to point out, however, that Pace sub-license RISC OS. As far
as I am aware at present, RISCOS Ltd do not distribute the code in question,
and neither does Pace Microtechnology Ltd.

It has come to my attention that some people are trying to implicate the
above companies in this.

I would strongly suggest people do not start to make (unfounded) claims
against neither RISCOS Ltd nor Pace Microtechnology Ltd unless they have
proof, in which case such proof should first contact the appropriate copyright
holders concerned.

A couple days later, Russell said,
"Castle
Technology Limited ask me to post this press release to the Linux Kernel
mailing list. By posting this press release, I wish to make it absolutely
clear that I am not expressing any views either way with respect to this
press release, merely passing the information on as requested."
He included the press release:

PRESS RELEASE

10th February 2003

Castle Technology Limited note with interest the recent discussion
regarding their IYONIX computer, the world's first desktop computer
to use the Intel XScale processor.

Following discussions with Russell King and with this in mind, Castle
should like to respond to claims originally proposed in Justin Fletcher's
"/kernel-traffic/ReadMe.txt" file and Russell King's subsequent posting to the Linux
Kernel Mailing List.

The RISC OS 5.00 kernel did not contain work taken from or derived from
the ARM-Linux or Linux kernel.

The RISC OS 5.01 kernel did not contain work taken from or derived from
the ARM-Linux or Linux kernel.

The RISC OS 5.02 kernel does not contain work taken from or derived from
the ARM-Linux or Linux kernel.

There are no plans to use GPL derived code in any part of the RISC OS
kernel in the future.

For the avoidance of doubt, the hardware abstraction layer (roughly
analogous to a PC's BIOS) has it's PCI allocation and bridge setup
based in part on the following functions from the Linux kernel sources:

enclosing a formatted 3.5" floppy diskette and return postage stamps,
or international reply coupons for those outside the United Kingdom.

These sources will also form an integral part of a forthcoming Linux
port to the IYONIX.

With the tough goal of fitting all of the supporting software and
applications for the IYONIX computer into just 4Mbytes of ROM, later
issues of the supporting software have had to have function names
removed (along with a strategy of tokenising textual messages and
compressing binaries) to make room for, in particular, the support
for the 'boot keyboard' USB drivers.

Here's a simple stochastic fairness queueing disk scheduler, for current
2.5.59-BK. It has known limitations right now, mainly because I didn't bother
making it complete. But it should suffice for some rudimentary testing,
at least.

I'm not going to go into great detail about how it works, see Andrea's
initial post of the paper referenced. This version may not be completely true
to the SFQ concept, but should be close enough I think. It divides traffic
into a fixed number of buckets (64 per default), and perturbs the hash every
5 seconds (hash shamelessly borrowed from networking atm, see comment).

To avoid too many disk seeks, when it's time to dispatch requests to the
driver, we round robin all non-empty buckets and grab a single request from
each. These requests are sorted into the dispatch queue.

For performance reasons, io scheduler request merging is still a per-queue
function (and not per-bucket).

In closing, let me stress that this version has not really been tested
all that much. It passes simple SCSI and IDE testing, should work on any
hardware basically.

He and Andrea Arcangeli talked it over briefly, and the Jens said:

In the nature of taking this concept to the extreme, here's a CFQ disk
scheduler (it should be obvious by now, that I'm simply making up a TLA
as I see fit :-), or Complete Fair Queueing. It never suffers from queue
collisions.

So how does it work? As with SFQ, a hash of busy queues is maintained.
If a queue for a given queue doesn't exist, one is simply allocated. The
actual queueing of requests works like the SFQ scheduler I sent out yesterday,
with little twist: we try to put at least cfq_quantum number of requests on
the dispatch queue. If only a small number of processes are waiting for io,
then this significantly helps throughput by minimizing the time spent between
finishing one request and starting a new one.

Other changes/fixes from SFQ:

Leave request mergeable even while on the dispatch list, to make the
merge window as big as possible.

The dispatch_sort() would sometimes not order requests correctly.

Various small fixes.

Interestingly, dbench results show little variance between runs with this
CFQ scheduler. Another point of interesting to folks may be that it would be
trivial to add process io priorities on top of CFQ (or SFQ for that matter,
but I consider CFQ to be the superiour scheduler).

If you play with this, let me know how it fares. Patch is against
2.5.60.

Release 0.2.0 of the Open POSIX Test Suite is now available at http://posixtest.sourceforge.net.
This second release contains POSIX conformance tests for 50-80% of the POSIX
functions of threads, signals, and semaphores. It also contains the full
timers suite (tags TMR and CS) released in 0.1.0 with bug fixes.

The release notes that appear on download describe how to compile and
run these tests.

The README page and the Open POSIX Test Suite website (above) give more
information on the project goals and progress as well as information on how
to contribute or contact us if you are interested.

Many thanks to Jim Houston and other members of the POSIX testing community
for their bug fixes, patches, and suggestions on how to improve the 0.1.0
suite.

The Open POSIX Test Suite is an open source test suite with the goal
of creating conformance test suites, as well as potentially functional and
stress test suites, to the functions described in the IEEE Std 1003.1-2001
System Interfaces specification. Initial work is focusing on timers, threads,
semaphores, signals, and message queues.