Kernel Traffic #257 by Zack Brown
[email protected] Tue, 06 Apr 2004 14:49:04 -0700
| Newsgroups | gmane.linux.kernel.kernel-traffic |
|---|---|
| Message-ID | <[email protected]> |
Kernel Traffic #257 For 6 Apr
By Zack Brown
Table Of Contents
* Standard Format
* Text Format
* XML Source
* Mailing List Stats For This Week
* Threads Covered
1. 26 Feb - 11 Mar (18 Status Of Lan Media's WAN Card Driver In 2.6
posts)
2. 2 Mar - 11 Mar (37 Status Of kgdb_serial And Run-Time Selection
posts) Of KGDB Communication Channels
3. 2 Mar - 13 Mar (38 udev 021 Released; Status Of Module Loading
posts) And Unloading
4. 5 Mar - 13 Mar (5 OpenIB InfiniBand Driver; Some Intellectual
posts) Property Encumberance
5. 7 Mar - 10 Mar (30 Linux 2.6.4-rc2-mm1 Released
posts)
6. 8 Mar - 16 Mar (9 LVM2 Benchmarking Under 2.6
posts)
7. 9 Mar - 11 Mar (23 New Intel PRO/Wireless 2100 802.11b Driver
posts)
8. 9 Mar - 12 Mar (12 Status Of Support For Intel's ICC Compiler
posts)
9. 10 Mar - 14 Mar (31 Block Device Hotplugging Improvements
posts)
10. 10 Mar - 12 Mar (4 Linux 2.6.4 Released
posts)
11. 10 Mar - 15 Mar (67 Linux 2.6.4-mm1 Released
posts)
12. 11 Mar - 17 Mar (9 Lightweight System Call Auditing
posts)
13. 11 Mar - 15 Mar (4 Fan Driver Expanded Coverage And New Name
posts)
14. 11 Mar - 13 Mar (17 Status Of Rootkit Attacks Against 2.6
posts)
15. 11 Mar (1 Hotplug Scripts Update Released
post)
16. 11 Mar - 14 Mar (2 UML Updated To Support 2.6.4
posts)
17. 12 Mar (2 New "Umbrella" Security Project For Linux On
posts) Handheld Devices
18. 12 Mar (1 udev 022 Released
post)
19. 13 Mar (1 Linux 2.4.26-pre3 Released
post)
20. 14 Mar (1 Highpoint-Tech Plugin 0.0.1 For EVMS 2.3.0
post)
21. 15 Mar - 16 Mar (8 Status Of Software Suspend
posts)
22. 15 Mar - 17 Mar (15 Linux 2.6.5-rc1 Released
posts)
23. 16 Mar - 17 Mar (13 Linux 2.6.5-rc1-mm1 Released
posts)
24. 16 Mar (1 Linux 2.4.26-pre4 Released
post)
Mailing List Stats For This Week
We looked at 1911 posts in 9942K.
There were 528 different contributors. 259 posted more than once. 176 posted
last week too.
The top posters of the week were:
* 87 posts in 594K by Greg KH
* 83 posts in 324K by Andrew Morton
* 61 posts in 359K by Andrea Arcangeli
* 43 posts in 201K by Nick Piggin
* 33 posts in 635K by Martin Schwidefsky
* Full Stats
1. Status Of Lan Media's WAN Card Driver In 2.6
26 Feb - 11 Mar (18 posts) Archive Link: "What happened to LAN Media
Corporation?"
People: Daniel Egger, Adrian Bunk, Marcelo Tosatti, Sam Ravnborg, Muli
Ben-Yehuda, Dave Jones, Horst von Brand
Adrian Bunk noticed that Lan Media's WAN card driver was listed in the
MAINTAINERS file as being maintained by Andrew Stanley-Jones of that company;
but that the Lan Media website, http://www.lanmedia.com/, was listed as being
for sale. He asked what was up, and Dave Jones queries Google, coming up with
an acquisition notice by SBE (http://www.sbei.net/archive/prs/2000/071400.htm)
as the first hit. Daniel Egger added that after the acquisition:
the first cool action they placed on the market was to substitute all
occurrences of LMC in the driver by SBE and make some other incompatible
changes to make sure that the old tools wouldn't work with the "new" driver
and vice versa. Surprisingly the kernel maintainers did not like this very
much so the drivers in the latest kernels are somewhat old and conflicting
with the "real" drivers.
What's more, their driver version 3.2 doesn't compile with 2.4.21 and up,
so unless they've eventually released their highquality patch/driver/tool/
utilities/extras + telnet and more bundle in version 4.0 version which will
probably only work up to 2.4.24 anyway (due to the latest HDLC changes),
one has to stick to an old version of the driver, which works somewhat but
given the extraordinary code quality I would be very surprised if that's a
synonym for a nice uptime.
There's something about WAN card manufacturers that seems to say: If you
hate us for the sad driver quality, check back with our competition and
then come back later...
Adrian asked if, in this case, the MAINTAINERS entry could be removed, and
Daniel replied, "This one for sure. The same is probably sensible for the
drivers, too. It's just too confusing to have several versions of the driver
floating around which need different tools. And since the manufacturer
propagates their own version, the linux one should go..." He said he'd post a
patch for this soon. Adrian said that removing a driver from a stable kernel
series didn't seem like a great idea, though he agreed the MAINTAINERS entry
should definitely go. Sam Ravnborg suggested just marking the thing as
unmaintained, instead of gutting the entry entirely, but Adrian replied:
In 2.6.4-rc1-mm2, there's exactly one entry marked "Unmaintained" (PCMCIA
SUBSYSTEM) and there are very few marked "Orphan".
I don't have a strong opinion on this, but my impresion was that usually
unmaintained device drivers are not listed in MAINTAINERS.
Elsewhere, Marcelo Tosatti also thought it would be proper to mark the driver
as unmaintained, and Horst von Brand agreed. Hideaki Yoshifuji replied that
typically, "Orphan" or "Obsolete" would be used instead of "Unmaintained". Muli
Ben-Yehuda suggested adding the "Unmaintained" possibility to the list of
possible states for a given driver, but Hideaki felt thta "Orphan" was the
proper and traditional term.
The thread ended inconclusively.
2. Status Of kgdb_serial And Run-Time Selection Of KGDB Communication Channels
2 Mar - 11 Mar (37 posts) Archive Link: "[PATCH] Kill kgdb_serial"
Topics: Networking
People: Tom Rini, George Anzinger, Pavel Machek, Andrew Morton
Tom Rini said, "The following interdiff kills kgdb_serial in favor of function
names. This only adds a weak function for kgdb_flush_io, and documents when it
would need to be provided." George Anzinger remarked, "It looks like you are
also dumping any notion of building a kernel that can choose which method of
communication to use for kgdb at run time. Is this so?" Tom replied, "Yes, as
this is how Andrew suggested we do it. It becomes quite ugly if you try and
allow for any 2 of 3 methods." Pavel Machek objected, "I do not think that
having kgdb_serial is so ugly. Are there any other uglyness associated with
that?" Tom gave a link to a February posting (http://lkml.org/lkml/2004/2/11/
224) where the issue had been discussed, in which Andrew Morton had said, "I
don't think runtime selection is very important, personally. You tend to get
things set up with a serial cable or ethernet and just leave it that way. Given
that you need to recompile the kernel anyway, I'd say that Kconfig-time
selection is acceptable." Pavel said that this only showed that Andrew didn't
care very much. He went on, "having both serial and ethernet support *is* good
idea after all... I have few machines here, some of them do not have serial,
and some of them do not have supported ethernet. It would be nice to use same
kernel on all of them. Also distribution wants to have "debugging kernel", but
does _not_ want to have 10 of them." After some discussion, Tom decided to give
up on killing kgdb_serial, and there was some implementation discussion on how
to do things cleanly.
3. udev 021 Released; Status Of Module Loading And Unloading
2 Mar - 13 Mar (38 posts) Archive Link: "[ANNOUNCE] udev 021 release"
Topics: FS: devfs, FS: sysfs, Hot-Plugging, Networking, USB, Version Control
People: Greg KH, Michael Weiser, Alex Goddard, Marco d'Itri
Greg KH said:
I've released the 021 version of udev. It can be found at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-021.tar.gz (http://
www.kernel.org/pub/linux/utils/kernel/hotplug/udev-021.tar.gz)
(Yes, there was no 020 release announcement, that tarball had a number of
build issues that prevented rpms from being generated, hence the need for a
021 release. A certain new Ximian/SuSE/Novell employee owes me some beer
now that he broke the build and I had to fix it...)
rpms built against Red Hat FC2-test1 are available at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-021-1.i386.rpm (http://
www.kernel.org/pub/linux/utils/kernel/hotplug/udev-021-1.i386.rpm)
with the source rpm at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-021-1.src.rpm (http://
www.kernel.org/pub/linux/utils/kernel/hotplug/udev-021-1.src.rpm)
udev allows users to have a dynamic /dev and provides the ability to have
persistent device names. It uses sysfs and /sbin/hotplug and runs entirely
in userspace. It requires a 2.6 kernel with CONFIG_HOTPLUG enabled to run.
Please see the udev FAQ for any questions about it:
kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ (http://www.kernel.org/
pub/linux/utils/kernel/hotplug/udev-FAQ)
For any udev vs devfs questions anyone might have, please see:
kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs (http://
www.kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs)
I think udev is pretty much mature now. The TODO list is pretty much empty,
and I've integrated in all of the assorted patches that the different
distros were using. If there's anything missing from udev, or any patches
that I've missed, please let me and the people at the linux-hotplug-devel
mailing list know about it.
Major changes from the 019 version:
+ new variable $local for the udev.permission file allows permissions to
be set for the currently logged in user.
+ new binary, udevstart, to help out people with distros that needed the
udev_start program to have a few /dev entries be created before it
could run.
+ new udevinfo functionality (can handle the symlinks correctly now.)
+ number of other small fixes.
Thanks to everyone who has send me patches for this release, a full list of
everyone, and their changes is below.
udev development is done in a BitKeeper repository located at:
bk://linuxusb.bkbits.net/udev
Daily snapshots of udev from the BitKeeper tree can be found at:
http://www.codemonkey.org.uk/projects/bitkeeper/udev/
If anyone ever wants a tarball of the current bk tree, just email me.
He replied to himself a few minutes later, to add:
Two other things about this release that Kay just reminded me about:
+ if you have been using the tarballs, please delete /sbin/udevinfo by
hand, as it is now placed in /usr/bin/udevinfo. Users who use the rpm
or some other kind of package system will have no problems with this.
+ the old style %2c format has now been removed in favor of the %c{2}
style. Any old udev.rules files will need to be converted (you had a
few releases to do this...)
And another one I just remembered:
+ we now support multiple symlink rules. They aren't really documented
well, but hopefully the author of that patch will fix this soon...
Michael Weiser said, regarding the ability to set permissions for the currently
logged in user, "Yay, just the other day I thought that might be a nice feature
in concert with RedHat's/Fedora's pam_console module. Am I right in assuming
that the current utmp based code will give the file to the user that most
recently logged into the local console? This could cause some confusion with
the pam_console-method which gives files to the user that logged in *first* on
a local console." Greg wasn't sure of the answer to this, and asked Michael to
test it out and report back; Michael did so, and reported:
It's even worse. The user logged into the lowest-numbered console will get
owner of the newly created file when using $local.
So if I log into tty2 and plug in my USB stick I will be owner of /dev/
sda1. If another guy comes along, logs into tty1, unplugs my USB stick and
replugs it, he'll be owner of /dev/sda1. But if I log out now, re-login on
tty2 and replug the stick again, I won't get the owner of /dev/sda1 but the
other guy again. This will certainly break things - at least on Fedora Core
1. Maybe it's different with other distributions/glibc/utmp variants/
versions.
Greg replied:
Ick, well you are describing a pretty pathalogical situation. I suspect for
99.9% of the users who would use this option, it will work just fine, as
they only have 1 user on the system at a time.
So, if you have multiple users on the physical system, then don't use
$local :)
Feel free to send a update to the documentation that illustrates this
limitation of the feature.
Elsewhere, in the course of discussion, some question of driver loading and
unloading came up; to which Greg said:
the kernel is changing models from one which automatically loaded modules
when userspace tried to access the device, to one where the proper modules
are loaded when the hardware is found.
Note that this is a much more sane model due to removable devices, and
instances of multiple types of the same kind of devices in the same system.
So no, udev is not going to handle this "issue" except in the case of
removable devices and their partitions. Which is already working in udev
today.
To the outcry that module unloading was a really great feature, Alex Goddard
said, "See past linux-kernel threads on how problematic module unloading is
(and how insanely hard it'd be to fix those problems). You really shouldn't be
using rmmod unless you're a developer as it is." And Greg added, "rmmod -a has
not been a wise thing to do since 2.2 came out. It can easily take down a
working box..."
Close by, Marco d'Itri objected, "This does not solve the problem of drivers
which do not have matching hardware, like PPP and loop device. I do not mind
unconditionally loading these modules at boot, but there has to be a way to
recognize them: I do not think it is acceptable to load *all* modules available
on the system (what is the point of having a modular kernel then?)." Greg said,
"Then have your "use the loop device" or "use the ppp device" load the module
before it is used. Or manually create the dev node and hope that kmod and its
aliases work..." But Michael said, "AFAICS both require root privileges and the
latter will break with dynamic device numbers issued by the kernel. The
previous model enabled normal users to have the kernel adjust to their current
requirements dynamically without the need of being root." There was no reply.
4. OpenIB InfiniBand Driver; Some Intellectual Property Encumberance
5 Mar - 13 Mar (5 posts) Archive Link: "ANNOUCE: OpenIB InfiniBand software"
Topics: BSD, Disks: SCSI, FS: sysfs, Ioctls, Microsoft, Virtual Memory
People: Roland Dreier
Roland Dreier said:
OPENIB.ORG INFINIBAND DRIVERS RELEASE -- 2004-03-05
We are proud to announce the initial availability of the OpenIB.org
InfiniBand stack. This is a fully open source (See the section on SDP
intellectual property for some important information, though.) InfiniBand
stack that includes a low-level driver for Mellanox HCA hardware, a
midlayer, and a number of useful upper-layer protocols including
IP-over-InfiniBand, SCSI RDMA Protocol, Sockets Direct Protocol, uDAPL and
MPI. In addition userspace utilities are available, including the OpenSM
subnet manager.
An initial drop of this source is available from <http://openib.org>.
Additional protocols and further enhancements will be added in upcoming
releases. In the next few days, we will also be bringing up mailing lists,
source code control, and so on.
We look forward to working with the entire Linux community to continue to
develop these drivers.
TODO
We are fully aware that our code is far from being acceptable for inclusion
in the Linux kernel, and we are very committed to doing the hard work
required to clean up the source. We believe that in addition to the
benefits of being in the standard kernel, we will find huge improvements in
the quality, performance and robustness of our drivers.
As a starting point, here is a list of some of the tasks we believe must be
completed before these drivers can be seriously considered for inclusion in
the kernel. We would welcome any suggestions of tasks that we have
forgotten. Of course patches would be even better!
+ Use a more standard naming convention (tTS_IB_TYPE_NAME ->
ib_type_name, tsIbFunctionName -> ib_function_name, etc)
+ Get rid of bizarro types such as tUINT32 -- replace with Linux standard
u32 etc.
+ Run source through scripts/Lindent (and then fix by hand, since lots of
things will no longer line up)
+ Get rid of XXX_exports.c files and move EXPORT_SYMBOL next to
definition in source.
+ Change MODULE_PARM -> module_param
+ Use DMA mapping API so we work properly with non-coherent caches,
IOMMUs etc. Add a function to get struct device * for an IB device so
ULPs can call sync functions (embed struct device in struct
ib_device?). (How do we handle systems with limited DMA mapping
capacity?)
+ Fix up ioctls, userspace interface so that 32-bit userspace works with
a 64-bit kernel.
+ Get rid of ib_poll module; move all timers to standard Linux timers (CM
can use a work queue plus schedule_delayed_work).
+ Get rid of ib_services module (move TS_TRACE etc. to dev_printk)
+ Add missing pieces of API for currently unused IB features: deal with
RD (EECs, etc -- including CM support), verbs extensions.
+ Get rid of IPoIB address hash and just use native 20-byte addresses
(keep 6-byte hash as an option for compatibility with existing
applications?)
+ Rewrite client query support (SA and DM) to be more extensible,
simpler, deal with component mask.
+ Add sysfs support.
+ In Mellanox HCA driver, clean up mosal. Some obvious targets (there's
lots more though):
o Grunging through kernel code to find the mlock/munlock pointers
especially has to go (mosal_mlock.c). We need to get VM experts
from LKML to tell us how to handle memory translation and locking.
o Turn MT_KERNEL back to __KERNEL__
o Use native spinlocks.
o Turn driver into a real PCI driver (rather than reimplementing a
worse version of PCI bus scan).
SDP intellectual property
Microsoft believes that they own certain intellectual property relating to
the Sockets Direct Protocol (SDP) (http://www.microsoft.com/mscorp/ip/
standards/) . Therefore, we are including the following disclaimer required
by Microsoft's license in SDP source that relates to the implementation of
the protocol:
"This source code may incorporate intellectual property owned by
Microsoft Corporation. Our provision of this source code does not
include any licenses or any other rights to you under any Microsoft
intellectual property. If you would like a license from Microsoft
(e.g., to rebrand, redistribute), you need to contact Microsoft
directly."
We realize that this is incompatible with open source licensing, and we are
working to find a more satisfactory solution, but for the time being we are
forced to comply with Microsoft's license.
Please make sure you have fully understood the implications of Microsoft's
claims before you redistribute any of the SDP source that contains the
above disclaimer.
The next day he replied to himself:
Several people have requested that we split the possibly-encumbered SDP
code into a separate package so that they don't have to download it to get
the free code. To allow that, I have split the kernel code into two
packages:
infiniband-kernel-2004-03-05.tar.bz2
infiniband-kernel-sdp-2004-03-05.tar.bz2
If you wish to build SDP, you will need to download both packages and move
the SDP files into the appropriate place in the tree. For all other
protocols, only the first package (containing only pure dual GPL/BSD code)
is required.
The new snapshot is available now from <http://openib.org/downloads>. (It
also contains a few fixes and code cleanups as compared to the 2004-02-26
drop)
5. Linux 2.6.4-rc2-mm1 Released
7 Mar - 10 Mar (30 posts) Archive Link: "2.6.4-rc2-mm1"
Topics: Disks: IDE, FS: ext3, User-Mode Linux
People: Andrew Morton
Andrew Morton announced Linux 2.6.4-rc2-mm1, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.4-rc2/
2.6.4-rc2-mm1/
+ Added Jens's patch which teaches the kernel to use DMA when reading
audio from IDE CDROM drives. These devices tend to be flakey, and we
need lots of testing please.
+ Re-added the device mapper update
+ Brought back Ingo's patch which permits remap_file_pages() to set the
memory access permissions on a per-page basis. This is mainly
interesting for its very significant performance benefits to UML.
Breaks the build on most architectures. There are how-to-fix-it
instructions in the changelog.
+ A new version of the patch which permits ext3 quota updates to be fully
journalled.
6. LVM2 Benchmarking Under 2.6
8 Mar - 16 Mar (9 posts) Archive Link: "lvm2 performance data with linux-2.6"
Topics: Disk Arrays: LVM, FS: ext2
People: Mark Wong, Miquel van Smoorenburg, Bill Davidsen
Mark Wong said:
I've started collecting various data (including oprofile) using our DBT-2
(OLTP) workload with lvm2 on linux 2.6.2 and 2.6.3 on ia32 and ia64
platforms:
http://developer.osdl.org/markw/lvm2/
So far I've only varied the stripe width with lvm, from 8 KB to 512 KB, for
PostgreSQL that is using 8 KB sized blocks with ext2. It appears that a
stripe width of 16 KB through 128KB on the ia64 system gives the best
throughput for the DBT-2 workload on a volume that should be doing mostly
sequential writes.
I'm going to run through more tests varying the block size that PostgreSQL
uses, but I wanted to share what I had so far in case there were other
suggestions or recommendations.
Miquel van Smoorenburg suggested, "For write-heavy loads, you might want to see
if 2.6.4-rc2-mm1 makes any difference. It fixes a case where both pdflush and a
writing process itself would queue writes to an LVM device, resulting in less
than optimal I/O ordering for some cases. The fix will probably be in 2.6.4
proper as well."
Bill Davidsen also said to Mark:
Here's one thought: look at the i/o rates on individual drives using each
stripe size. You *might* see that one size does far fewer seeks than
others, which is a secondary thing to optimize after throughput IMHO.
If you don't have a tool for this I can send you the latest diorate which
does stuff like this, io rate perdrive or per partition, something I
occasionally find revealing.
Mark said he'd been using 'iostat -x' so far, and would definitely like to see
the diorate script. Chris Croswhite asked if it were available to all, and Bill
replied, "I stuck it on the page I use to avoid beating my fractional T1 to
death. http://pages.prodigy.net/davidsen/diorate.pl. Enjoy, any misfeatures
please feed back to me."
7. New Intel PRO/Wireless 2100 802.11b Driver
9 Mar - 11 Mar (23 posts) Archive Link: "[Announce] Intel PRO/Wireless 2100
802.11b driver"
People: James Ketrenos, Dax Kelson, Arjan van de Ven, Timothy Miller
James Ketrenos of Intel, said:
I am pleased to announce the launch of an open source development project
for the Intel PRO/Wireless 2100 miniPCI network adapter. The project has
been created and is hosted at http://ipw2100.sf.net.
The driver, as it currently stands, is able to associate and communicate in
Infrastructure mode. Support for both 2.4 and 2.6 is available. We are
releasing this driver now as "early beta" code to get feedback and help in
the development, so expect bugs (and please report them)! Of course Intel
will continue the effort (as part of this Open Source project). We are
planning to add support of all key wireless features (adhoc, WEP, etc) over
the next few months, quicker with help from others in the community.
NOTE: Let me reiterate -- this driver is in active development. Features
and capabilities available on other operating systems have not all been
implemented at this time. This includes wireless features (adhoc, wep) as
well as performance and power savings.
I look forward to working with the community to improve and enhance the
driver.
So if you have an Intel wireless 802.11b miniPCI network adapter in your
laptop... download the bits, give it a whirl, and let me know how it goes.
Please also let us know if you encounter any problems that may be related
to specific distributions.
Later, he added that Intel had set up a mailing list, at http://
lists.sourceforge.net/lists/listinfo/ipw2100-devel.
Arjan van de Ven, Timothy Miller, Dax Kelson and others were very happy to see
this. Dax also said:
I took a look at the website and see the GPL driver and the closed
firmware.
Is it really *firmware*, in that it loads and executes purely within the
Intel PRO/Wireless 2100 itself and not in the linux kernel on the main CPU?
If so, bravo!
Does a similar effort exist for the upcoming Sonoma 802.11a/b/g component?
Will Linux support be available for Sonoma at launch?
Regarding the firmware question, James confirmed, "Yes, it is really firmware.
It is loaded from disk as a block of data and passed to the card. The system
CPU doesn't execute anything out of the firmware, nor does the firmware know
anything about the kernel." And regarding the upcoming Sonoma 802.11a/b/g, he
added, "It is our intention to support a/b/g WLAN with a driver for Linux, but
details are being worked out so we have no dates or commitment at this time."
8. Status Of Support For Intel's ICC Compiler
9 Mar - 12 Mar (12 posts) Archive Link: "Kernel 2.6.3 patch for Intel
Compiler 8.0"
People: Ingo Kubbilun
Ingo Kubbilun said, "please have a look at http://www.pyrillion.org/
linuxkernelpatch.html for a working 2.6.3 patch to compile the kernel with
Intel Compiler 8.0 for Linux." Norberto Bensa asked how the speed of a kernel
compiled with that compiler compared with one compiled with GCC, and Ingo
replied:
I used the patch to compile two identical kernels with gcc 3.3.3 and icc
8.0 with oprofile support built in.
The optimization switches were chosen quite conservative, i.e. "-O2 -Ob1",
no IPO, and of course: no MMX, SSE, and SSE2 stuff inside the kernel (thus
disabling Intel's great vectorizer).
Profiling: lmbench ran ten times but time measurements were taken from
oprofile (on Pentium 4, GLOBAL_POWER_EVENTS in kernel space only, counter
overflow: 3.000).
Results: 33% of the lmbench procs faster on icc, 66% faster on gcc.
Thus, take the kernel patch as a good basis for modifying the compiler
switches and other things to get more performance gains. As I know, a lot
of people are looking for a patch.
Please check the patch file; you have to modify a lot of things in 2.6.3 to
create a quite stable working version of the kernel. The patch is not just
about changing some minor Makefile things...
9. Block Device Hotplugging Improvements
10 Mar - 14 Mar (31 posts) Archive Link: "[PATCH] backing dev unplugging"
Topics: Hot-Plugging
People: Jens Axboe, Andrew Morton
Jens Axboe said:
Here's a first cut at killing global plugging of block devices to reduce
the nasty contention blk_plug_lock caused. This introduceds per-queue
plugging, controlled by the backing_dev_info. Observations:
+ Most uses of blk_run_queues() without a specific context was bogus.
Usually the act of kicking the targets in question should be (and
already are) performed by other activities, such as making the vm
flushing run to free memory.
+ Some use of blk_run_queues() really just want to kick the final queue
where the bio goes to. I've added bio_sync() (BIO_RW_SYNC) to manage
those, if the queue needs unplugging we'll do it when holding the lock
for the queue already.
+ The dm bit needs careful examination and checking of Joe. It could be
more clever and maintain plug state of each target, I just added a
dm_table unplug all functionality.
Patch is against 2.6.4-rc2-mm1.
Various folks liked this, and Andrew Morton said, "This is such an improvement
over what we have now it isn't funny."
10. Linux 2.6.4 Released
10 Mar - 12 Mar (4 posts) Archive Link: "Linux 2.6.4"
People: Linus Torvalds, Jan De Luyck, Pavel Machek
Linus Torvalds announced 2.6.4, saying:
A few small fixes since -rc3, most notably an OHCI bug that would corrupt
memory and seems to have been the reason for the "Bad page flags" bug at
least on ppc64 (it's not been reported on x86, as far as I know, but I
don't see why the corruption couldn't have happened there too).
The full changelog from 2.6.3 is on the ftp-sites along with the patches
and tar-balls, and the BK trees have been updated.
Jan De Luyck asked, "The new -mregparm=3 support, how likely is it to totally
break one's system?" Pavel Machek replied, "There were some problems with that,
but they should be fixed. If you are using binary-only drivers, stay away from
that."
11. Linux 2.6.4-mm1 Released
10 Mar - 15 Mar (67 posts) Archive Link: "2.6.4-mm1"
Topics: FS: XFS, FS: ext2, Hot-Plugging
People: Andrew Morton
Andrew Morton announced 2.6.4-mm1, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.4/
2.6.4-mm1/
+ The CPU scheduler changes in -mm (sched-domains) have been hanging
about for too long. I had been hoping that the people who care about
SMT and NUMA performance would have some results by now but all seems
to be silent.
I do not wish to merge these up until the big-iron guys can say that
they suit their requirements, with a reasonable expectation that we
will not need to churn this code later in the 2.6 series.
So. If you have been testing, please speak up. If you have not been
testing, please do so.
+ Major surgery against the pagecache, radix-tree and writeback code.
This work is to address the O_DIRECT-vs-buffered data exposure horrors
which we've been struggling with for months.
As a side-effect, 32 bytes are saved from struct inode and eight bytes
are removed from struct page.
This change will break any arch code which is using page->list and will
also break any arch code which is using page->lru of memory which was
obtained from slab.
It seems to work OK here, but I suggest people not rush out and convert
all of the corporate finance department's servers to 2.6.4-mm1.
The basic problem which we (mainly Daniel McNeil) have been struggling
with is in getting a really reliable fsync() across the page lists
while other processes are performing writeback against the same file.
It's like juggling four bars of wet soap with your eyes shut while
someone is whacking you with a baseball bat. Daniel pretty much has the
problem plugged but I suspect that's just because we don't have
testcases to trigger the remaining problems. The complexity and
additional locking which those patches add is worrisome.
So the approach taken here is to remove the page lists altogether and
replace the list-based writeback and wait operations with in-order
radix-tree walks.
The radix-tree code has been enhanced to support "tagging" of pages,
for later searches for pages which have a particular tag set. This
means that we can ask the radix tree code "find me the next 16 dirty
pages starting at pagecache index N" and it will do that in O(log64(N))
time.
This affects I/O scheduling potentially quite significantly. It is no
longer the case that the kernel will submit pages for I/O in the order
in which the application dirtied them. We instead submit them in
file-offset order all the time.
This is likely to be advantageous when applications are seeking all
over a large file randomly writing small amounts of data. I haven't
performed much benchmarking, but tiobench random write throughput seems
to be increased by 30%. Other tests appear to be unaltered. dbench may
have got 10-20% quicker, but it's variable.
There is one large file which everyone seeks all over randomly writing
small amounts of data: the blockdev mapping which caches filesystem
metadata. The kernel's IO submission patterns for this are now ideal.
Because writeback and wait-for-writeback use a tree walk instead of a
list walk they are no longer livelockable. This probably means that we
no longer need to hold i_sem across O_SYNC writes and perhaps fsync()
and fdatasync(). This may be beneficial for databases: multiple
processes writing and syncing different parts of the same file at the
same time can now all submit and wait upon writes to just their own
little bit of the file, so we can get a lot more data into the queues.
It is trivial to implement a part-file-fdatasync() as well, so
applications can say "sync the file from byte N to byte M", and
multiple applications can do this concurrently. This is easy for ext2
filesystems, but probably needs lots of work for data-journalled
filesystems and XFS and it probably doesn't offer much benefit over an
i_semless O_SYNC write.
+ Dropped the hotplug CPU patches: bits of them were merged into Linus's
kernel and things broke.
+ Various little fixes as usual.
12. Lightweight System Call Auditing
11 Mar - 17 Mar (9 posts) Archive Link: "[PATCH] Light-weight Auditing
Framework"
People: Rik Faith, Stephen Smalley
Rik Faith said:
Below is a patch against 2.6.4 that provides a low-overhead system-call
auditing framework for Linux that is usable by LSM components (e.g.,
SELinux). This is an update of the patch discussed in this thread:
http://marc.theaimsgroup.com/?t=107815888100001&r=1&w=2
In brief, it provides for netlink-based logging of audit records that have
been generated in other parts of the kernel (e.g., SELinux) as well as the
ability to audit system calls, either independently (using simple
filtering) or as a compliment to the audit record that another part of the
kernel generated.
The main goals were to provide system call auditing with 1) as low overhead
as possible, and 2) without duplicating functionality that is already
provided by SELinux (and/or other security infrastructures). This framework
will work "stand-alone", but is not designed to provide, e.g., CAPP
functionality without another security component in place.
This updated patch includes changes from feedback I have received,
including the ability to compile without CONFIG_NET (and better use of
tabs, so use -w if you diff against the older patch).
Please see http://people.redhat.com/faith/audit/ for an early example
user-space client (auditd-0.4.tar.gz) and instructions on how to try it.
My future intentions at the kernel level include improving filtering (e.g.,
syscall personality/exit codes) and syscall support for more architectures.
First, though, I'm going to work on documentation, a (real) audit daemon,
and patches for other user-space tools so that people can play with the
framework and understand how it can be used with and without SELinux.
Stephen Smalley remarked, "FYI, I have no objection to the changes in this
patch to the SELinux module; we would be glad to have SELinux use this auditing
framework if it is accepted into the mainline kernel. I suppose we can
separately submit a patch to remove the avc_ratelimit code from the SELinux
avc, as that should be handled by the audit framework itself."
13. Fan Driver Expanded Coverage And New Name
11 Mar - 15 Mar (4 posts) Archive Link: "[PATCH] therm_adt7467 update"
People: Colin Leroy, Benjamin Herrenschmidt
Colin Leroy said, "the fan driver I wrote for adt746x looks like it only
handles the adt7467 chip found in iBooks G4; but it also handles the adt7460
chip found in the Powerbook G4 Alu. Here's a patch that renames the file to
therm_adt746x.c and updates Kconfig and Makefile." Benjamin Herrenschmidt
replied, "Ok, I'll look into getting that upstream. Renaming things is a bit
nasty (makes big patch for little changes) unless Linus does directly a "bk mv"
in his tree.."
14. Status Of Rootkit Attacks Against 2.6
11 Mar - 13 Mar (17 posts) Archive Link: "LKM rootkits in 2.6.x"
Topics: Security
People: Pete Smith, Horst von Brand, Dave Jones, Jirka Kosina, Dax Kelson,
Valdis Kletnieks, Christophe Saout
Pete Smith asked, "Any thoughts on the future of LKM rootkits in the 2.6 kernel
branch ? In the last few years I've become quite interested in them (from a
defensive point of view), but with the 2.6 kernel no longer exporting the
syscall table, intercepting system calls would appear to be a non-starter now."
Horst von Brand replied, "If you get to load a module, you are in-kernel. Once
there, you can either use what you know are the offsets for
$distro-$version-$arch kernel and be in business as usual, or fool around on
your own. Harder than before, yes. Impossible, by no means." Valdis Kletnieks
also gave a pointer to a 2.6 port of the adore-ng rootkit (http://
stealth.7350.org/rootkits/adore-ng-0.41.tgz) that had been mentioned by an
anonymous poster on BugTraq. The poster had said, "All of the stuff you know
from earlier kernel 2.4 versions such as socket-, process- and file-hiding,
syslog- and [uw]tmp filtering has been ported. Additionally since version 0.32
a buffer overflow has been fixed (doh!) which could lead to crashes when a lot
of network connections exist." Paul Rolland took a look at this, and noticed
that the rootkit no longer used the system call layer, but did its work via the
Virtual Filesystem. Paul suggested hiding the VFS now, as well. Elsewhere, Dave
Jones also pointed out that rootkit authors could also "start doing what
binary-only driver vendors have been doing for months.. If the table isn't
exported, they find a symbol that is exported, and grovel around in memory near
there until they find something that looks like it, and patch accordingly."
Jirka Kosina replied, "Why bother .. just find any symbol (function name) which
is exported to modules and also being frequently called somehow indirectly from
userland (VFS layer functions, vm functions, ...) and use this function as an
open-backdoor spell. It is easy to patch existing rootkits this way."
Christophe Saout asked if it was really true that binary driver vendors were
using the method Dave described, and Dax Kelson asked which vendors and modules
did this. Dave replied, "Most recent one I saw was some 'antivirus'
filescanning module. The name escapes me. It was mentioned on l-k at the time.
It wasn't the first by any means however. This trick has been used since
vendors stopped exporting sys_call_table."
15. Hotplug Scripts Update Released
11 Mar (1 post) Archive Link: "[ANNOUNCE] 2004-03-11 release of hotplug
scripts"
Topics: Hot-Plugging
People: Greg KH
Greg KH said:
I've just packaged up the latest Linux hotplug scripts into a release,
which can be found at:
kernel.org/pub/linux/utils/kernel/hotplug/hotplug-2004_03_11.tar.gz (http:/
/www.kernel.org/pub/linux/utils/kernel/hotplug/hotplug-2004_03_11.tar.gz)
or for those who like bz2 packages:
kernel.org/pub/linux/utils/kernel/hotplug/hotplug-2004_03_11.tar.bz2 (http:
//www.kernel.org/pub/linux/utils/kernel/hotplug/hotplug-2004_03_11.tar.bz2)
This is a snapshot of the recent development in the scripts, and should be
used by anyone who has reported a bug or sent me a patch against the last
release, to check if your fix is in or not.
If I have missed any changes, please let me know and send the patch to me
and the linux-hotplug-devel mailing list. I'll collect them all and make a
"official" release afterwards.
Sorry for delaying so long since the last hotplug release.
16. UML Updated To Support 2.6.4
11 Mar - 14 Mar (2 posts) Archive Link: "uml-patch-2.6.4-1"
Topics: User-Mode Linux
People: Jeff Dike
Jeff Dike said:
This patch updates UML to 2.6.4. Besides the update, there were the
following changes since the last patch:
+ a bug which caused either a crash in the kernel or a BUG at exit.c:793
was fixed
+ a bug which caused a crash when a process tried to dump core was fixed
+ the hang early in boot on GHz hosts is gone
+ various other
The 2.6.4-1 UML patch is available at
http://www.user-mode-linux.org/mirror/uml-patch-2.6.4-1.bz2
BK users can pull my 2.5 repository from
http://www.user-mode-linux.org:5000/uml-2.5
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
17. New "Umbrella" Security Project For Linux On Handheld Devices
12 Mar (2 posts) Archive Link: "[ANNOUNCE] Umbrella - process based mandatory
access control"
People: Kristian Soerensen
Kristian Soerensen said:
I am proud to announce the official launch of the Umbrella security project
for Linux on handheld devices.
Umbrella implements a combination of process based mandatory access control
and authentication of files. Umbrella relies on the efford of developers,
in order to implement a secure system. It is our philosophy that it is not
possible to make a secure Linux system without involving the developers of
the various applications used on the system!
The design of Umbrella is aimed to be very simple for developers to use and
understand. It is not possible to make an ambiguous security configuration
for Umbrella - unlike more complex security mechanisms like e.g.
Security-Enhanced Linux.
You may find more details below and on our web site:
http://umbrella.sourceforge.net
-- UMBRELLA INTRODUCTION --
In designing Umbrella for handheld devices, there are several criteria that
differ from that of regular computer systems. The most important are the
available resources and the fact that heavy change in software do not
occur. Furthermore the PDA, used for test purposes in this project, is not
a development tool only a computer intended to do specific tasks such as
organizer, email, games, communication etc.
Though resources on handhelds are limited, the devices has become
increasingly more powerful and able to run a wide range of programs from
different vendors. Umbrella is designed, such that software can be executed
in a secure manner and thereby protecting the system against malicious code
and viruses.
The overall structure of Umbrella is a mandatory access control scheme for
running processes together with an authentication of files and run time
integrity checking of the executables.
-- PROCESS BASED MAC --
The idea of processes based mandatory access control is strongly supported
by the tree structure for processes in Linux.
Umbrella gives every process in Linux a set of restrictions. The rule is
that every process must be at least as restricted as it parent. In
practice, this works as inheritance: When forking a new process, it
immediately gets the restrictions of it's parent, and if the parent have
specified more restrictions for it's child(ren) then the "child
restrictions" and the restrictions of the parent are combined (a union of
the two sets of restrictions).
-- WHAT IS RESTRICTIONS? --
A restriction is just a string, e.g. "/etc". These strings can represent a
path in the file system e.g. "/etc/passwd" or "/etc" or the restriction can
represent a special ability e.g. "net" or "fork".
A path restriction restricts the process from the specified directory and
everything below it. If the path-restriction is a file, nothing below
exists, and the process is thus restricted from that single file only.
Ability restrictions is used to restrict from special operations, that
cannot be restricted through files. An example of this is the network,
which is only handled through the kernel. The restrictions for the network,
the ability to fork new processes and others is handled within Umbrella.
It will be very easy to add new path restrictions to the system, as the way
they are handled within the kernel are the same. From a user/programmer
point of view, the interface will be made very simple (not implemented
yet). Adding more ability restrictions require small modifications of the
Umbrella code (hook implementations). At first we aim to implement the
general, but simple, ability restrictions (like net and fork). However it
is fairly easy to extend these to implement more fine grained restrictions.
In a subsequent post, he said:
Umbrella-0.2 can be downloaded from:
http://prdownloads.sourceforge.net/umbrella/umbrella-0.2.tar.bz2?download
The tarball includes detailed instructions for how to try out Umbrella.
18. udev 022 Released
12 Mar (1 post) Archive Link: "[ANNOUNCE] udev 022 release"
Topics: FS: devfs, FS: sysfs, Hot-Plugging, Version Control
People: Greg KH
Greg KH said:
I've released the 022 version of udev. It can be found at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-022.tar.gz (http://
www.kernel.org/pub/linux/utils/kernel/hotplug/udev-022.tar.gz)
rpms built against Red Hat FC2-test1 are available at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-022-1.i386.rpm (http://
www.kernel.org/pub/linux/utils/kernel/hotplug/udev-022-1.i386.rpm)
with the source rpm at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-022-1.src.rpm (http://
www.kernel.org/pub/linux/utils/kernel/hotplug/udev-022-1.src.rpm)
udev allows users to have a dynamic /dev and provides the ability to have
persistent device names. It uses sysfs and /sbin/hotplug and runs entirely
in userspace. It requires a 2.6 kernel with CONFIG_HOTPLUG enabled to run.
Please see the udev FAQ for any questions about it:
kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ (http://www.kernel.org/
pub/linux/utils/kernel/hotplug/udev-FAQ)
For any udev vs devfs questions anyone might have, please see:
kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs (http://
www.kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs)
There are a few minor bugfixes in this release, and a few new features.
Which pretty much seems to prove my "udev is mature" statement I made for
the last release :)
Oh, I'd like to thank OSDL for doing some preliminary speed tests (as well
as functionality tests) on udev. Unofficially it looks like it only took 7
seconds extra to use udev to name 1000 scsi disks (and the rule was calling
out to scsi_id for every disk, and then parsing over 1000 rules.) Note that
is 7 seconds extra to name _all_ of the disks at once using the scsi_debug
module. That's not too shabby at all.
Where are those "hotplug is too slow to do device naming" whiners now...
Major changes from the 021 version:
+ lots of security audits in libsysfs and the remaining udev files.
+ fixes for the foo-%c{N} type rules
+ add foo-%c{N+} type rule option (see the manpage for info).
+ allow node permissions to be specified in the rules file.
+ more tests added to the test scripts
+ number of other small fixes.
Again a big thanks to Kay Sievers for sending me patches faster than I can
integrate them. udev is a viable program due to his excellent work.
Thanks also to everyone else who has send me patches for this release, a
full list of everyone, and their changes is below.
udev development is done in a BitKeeper repository located at:
bk://linuxusb.bkbits.net/udev
Daily snapshots of udev from the BitKeeper tree can be found at:
http://www.codemonkey.org.uk/projects/bitkeeper/udev/
If anyone ever wants a tarball of the current bk tree, just email me.
19. Linux 2.4.26-pre3 Released
13 Mar (1 post) Archive Link: "Linux 2.4.26-pre3"
Topics: FS: NFS
People: Marcelo Tosatti
Marcelo Tosatti announced 2.4.26-pre3, saying:
Here goes the third pre release of 2.4.26.
It contains a bunch of NFS client fixes, IA64/32-bit PPC updates, sisfb
update, amongst others.
20. Highpoint-Tech Plugin 0.0.1 For EVMS 2.3.0
14 Mar (1 post) Archive Link: "[ANNOUNCE] Highpoint-Tech Plugin 0.0.1 for EVMS
2.3.0"
Topics: Disk Arrays: EVMS, FS: sysfs
People: Wilfried Weissmann, Kevin Corry
Wilfried Weissmann announced:
...so here comes 0.0.1! i have changed the device manager id to 3 because
of Kevin Corry suggested this and also added more pci-ids. you can override
the id scan be setting "biosraid.ignore_pci_ids" to "1". but you still need
the proper raid signatures on your disks to get a raid volume.
basic read/write tests on a fat partition worked fine, but i cannot do more
right now. the fan of my graphiccard is broken and i replaced the cooler
with cpu heatsink and attached it with a string to the board. looks pretty
crude!
Changelog:
+ use new list API
+ migrate to evms 2.3.0
+ support for HPT 370, 370A, 302, 371, 375, 372N chipsets
+ remove disk if it cannot be added the discover() output_list
+ make all global variables static
+ add boolean "biosraid.ignore_pci_ids" config option to optionally
ignore the pci vendor and device ids of the ide controllers
+ changed EVMS_DEVICE_MANAGER ID to 3
TODOs:
+ access to the last sector (kernel 2.6 only)
+ add mode raid levels
+ create "whole disk" volume (currently only under .nodes)
+ use sysfs for scanning
+ more modular design to make it easier to add code for other controllers
+ more testing
the next thing that i want to do is to implement the "whole disk" volume.
it might be handy to have such a device for the grub bootloader and stuff.
this also is a start for the last sector problem fix. the problem is that i
should protect the sector #9 which contains the volume configuration. i do
not think that it is possible to only write protect that sector but this
would be a nice thing to do. the patch that applies against evms 2.3.0 is
attached...
21. Status Of Software Suspend
15 Mar - 16 Mar (8 posts) Archive Link: "The verdict on the future of
suspending to disk?"
Topics: Software Suspend
People: Nigel Cunningham, Karol Kozimor, Pavel Machek
Nigel Cunningham asked:
Just wanting clarification; what are we thinking about the future of
suspend implementations? Let me throw my current understanding/suggestion
in for starters:
+ Drop PM_DISK?
+ Apply patches making swsusp into suspend2, leaving out freezer changes
until people are convinced the current solution is insufficient.
+ Pavel keeps maintaining the end result? (I'm happy to maintain it if he
wants; I'm assuming when I say this he'll still be dealing with S3 and
Patrick will be deal with PM support proper).
Karol Kozimor said, "Patrick has been silent for months, which apart from
further complicating matters makes any assumptions not quite right :)" . Pavel
Machek said he didn't care which implementation was dropped as long as one
remained. He also said to Nigel, "I do not think Patrick is going to maintain
anything. If you want to maintain it, you can have it. Big plus if you are able
to deal with Patrick." There followed a bit of an implementation discussion,
which petered out quickly.
22. Linux 2.6.5-rc1 Released
15 Mar - 17 Mar (15 posts) Archive Link: "Linux 2.6.5-rc1"
Topics: Serial ATA, Sound: ALSA, Version Control
People: Linus Torvalds
Linus Torvalds announced 2.6.5-rc1, saying:
Here's the current set of patches I've merged from various poeple..
Merging from Andrew, but also i2c updates, ALSA CVS merge, netconsole,
prism54 driver merge, sata updates, carmel driver, pcmcia and nfs client
updates..
And a few architectures updated: ia64, ppc32, sparc32, arm.
23. Linux 2.6.5-rc1-mm1 Released
16 Mar - 17 Mar (13 posts) Archive Link: "2.6.5-rc1-mm1"
People: Andrew Morton
Andrew Morton announced 2.6.5-rc1-mm1, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.5-rc1/
2.6.5-rc1-mm1/
+ A small update, mainly trying to get things stabilised after some
problems with the disk unplugging and early x86 boot code. We may still
have a problem with the latter.
+ A PNP subsystem update
24. Linux 2.4.26-pre4 Released
16 Mar (1 post) Archive Link: "Linux 2.4.26-pre4"
Topics: Disk Arrays: RAID, Disks: IDE
People: Marcelo Tosatti
Marcelo Tosatti announced Linux 2.4.26-pre4, saying:
Here goes the fourth -pre of 2.4.26.
Pretty small (great!), containing a few network updates, SPARC64 fixes,
Bluetooth fixes, IDE update (fixes for AMD chipset driver and inclusion of
Medley software RAID driver by Thomas Horsten), amongst others.
We Hope You Enjoy Kernel Traffic
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.