Kernel Traffic #258 by Zack Brown
[email protected] Sun, 18 Apr 2004 18:56:01 -0700
| Newsgroups | gmane.linux.kernel.kernel-traffic |
|---|---|
| Message-ID | <[email protected]> |
Kernel Traffic #258 For 18 Apr
By Zack Brown
Table Of Contents
* Standard Format
* Text Format
* XML Source
* Mailing List Stats For This Week
* Threads Covered
1. 24 Feb - 26 Feb (2 Marc-Christian Petersen New 2.2 Maintainer;
posts) Linux 2.2.26 Released
2. 3 Mar - 18 Mar (17 New PRAMFS RAM-Based Filesystem; Free For
posts) GPLed Projects
3. 12 Mar - 18 Mar (17 Status Of Software Suspend
posts)
4. 14 Mar - 23 Mar (89 Linux 2.6.4-mm2 Released
posts)
5. 14 Mar - 18 Mar (7 bkbits.net Improvements
posts)
6. 15 Mar - 18 Mar (14 Trying To Clarify Software Suspend
posts)
7. 17 Mar - 22 Mar (40 Status Of fsync()
posts)
8. 17 Mar - 19 Mar (4 Linux 2.6.5-rc1-mm2 Released
posts)
9. 18 Mar - 19 Mar (4 libata Update Against 2.6
posts)
10. 19 Mar - 24 Mar (14 Linux 2.6.5-rc2 Released
posts)
11. 19 Mar - 21 Mar (4 Linux 2.4.26-pre5 Released
posts)
12. 21 Mar - 23 Mar (6 Linux 2.6.5-rc2-mm1 Released
posts)
13. 22 Mar - 24 Mar (21 Status Of OSS
posts)
14. 23 Mar - 24 Mar (28 Setting A Non-Executable Stack For ELF
posts) Binaries
15. 24 Mar (1 Linux 2.2.27-pre1 Released
post)
Mailing List Stats For This Week
We looked at 1917 posts in 9538K.
There were 478 different contributors. 245 posted more than once. 192 posted
last week too.
The top posters of the week were:
* 105 posts in 483K by Andrea Arcangeli
* 98 posts in 445K by Andrew Morton
* 50 posts in 236K by Greg KH
* 45 posts in 197K by Jeff Garzik
* 43 posts in 275K by Vojtech Pavlik
* Full Stats
1. Marc-Christian Petersen New 2.2 Maintainer; Linux 2.2.26 Released
24 Feb - 26 Feb (2 posts) Archive Link: "Linux 2.2.26 aka "2.2 is not dead"
released"
People: Marc-Christian Petersen, Alan Cox
Marc-Christian Petersen, taking over from Alan Cox as 2.2 maintainer, released
2.2.26, saying:
I am very proud to announce this because it fixes several of security bugs
including the last mremap() bug, the longer known hashing exploit
possibility in the network stack and /dev/rtc leakage.
I encourage all 2.2 kernel users to update.
Please send me all fixes/patches/etc. I've forgotton for 2.2.27-pre/rc
inclusion.
2. New PRAMFS RAM-Based Filesystem; Free For GPLed Projects
3 Mar - 18 Mar (17 posts) Archive Link: "new special filesystem for
consideration in 2.6/2.7"
Topics: FS: ramfs, Patents, Small Systems
People: Steve Longerbeam, Dave Jones, Mike Fedyk
Steve Longerbeam said:
MontaVista Software has developed a new filesystem targeted for embedded
systems that we would like to have considered for inclusion in 2.6 or 2.7.
It is called the Protected and Persistent RAM Special Filesystem (PRAMFS).
It was originally developed for three major consumer electronics companies
for use in their smart cell phones and other consumer devices.
An intro to PRAMFS along with a technical specification is at the
SourceForge project web page at http://pramfs.sourceforge.net/. A patch for
2.6.3 has been released at the SF project site.
PRAMFS can be tested on a desktop by reserving some portion of physical
memory with "mem=". For example, a machine with 512M could reserve the top
32M with "mem=480M". PRAMFS would then be mounted with:
mount -t pramfs -o physaddr=0x1e000000,init=0x2000000 none /mnt/pramfs
He posted some introductory docs, and Dave Jones pointed out, "the biggest
thing holding back inclusion of this is likely the comment about there likely
being patents held on parts of that code." Steve replied, "MV has a patent
pending, but it would only affect any future use of the technology in a _non
GPL_ operating system. Used in Linux or any future GPL software, no patent
licenses or royalties are involved at all." Mike Fedyk said that this should be
put into legal terms, and included in the patch itself. Tim Bird pointed out
that there was such a notice at the top of every file in the patch, reading:
"This software is being distributed under the terms of the GNU General
Public License version 2. Some or all of the technology encompassed by this
software may be subject to one or more patents pending as of the date of
this notice. No additional patent license will be required for GPL
implementations of the technology. If you want to create a non-GPL
implementation of the technology encompassed by this software, please
contact [email protected] for details including licensing terms and fees."
3. Status Of Software Suspend
12 Mar - 18 Mar (17 posts) Archive Link: "Dealing with swsusp vs. pmdisk"
Topics: Big Memory Support, Software Suspend
People: Pavel Machek, Theodore Ts'o, Jan Rychter, Benjamin Herrenschmidt
Pavel Machek said:
I don't really like having two implementations of same code in kernel.
There are two ways to deal with it:
+ remove pmdisk from kernel
o its easy
+ remove swsusp from kernel, rename pmdisk to swsusp, fix all bugs that
were fixed in swsusp but not in pmdisk
o people seem to like pmdisk code more
o will need some testing in -mm series
Which one do you prefer? I can do both...
Theodore Ts'o replied:
2.6 is allegedly the stable kernel series, so if swsusp is the more stable
code base at this point, my vote would be to keep swsusp and remove pmdisk
from the kernel. If someone wants to maintain a separate BK-tree that
contains pmdisk renamed to swsusp and fix all the bugs, that's great. On
the other hand, there are a group of people of are busy doing something
very similar with swsusp2, and that effort seems to have a fair number of
people working on the patch and testing it.
So if we can somehow go from *three* idependent software suspend
implementations implementations to something less than three, and increase
the testing and effort devoting to remaining software suspend code bases,
this would be a good thing.
Pavel, what do you think of the swsusp2 patch, BTW? My biggest complaint
about it is that since it's maintained outside of the kernel, it's
constantly behind about 0.75 revisions behind the latest 2.6 release. The
feature set of swsusp2, if they can ever get it completely bugfree(tm) is
certainly impressive.
Pavel replied, "My biggest problem with swsusp2 is that it is big. Also last
time I looked it had some ugly hooks sprinkled all over the kernel. Then there
are some features I don't like (graphical screens with progress,
escape-to-abort) and ithasvariableslikethis. OTOH it supports highmem and smp."
Jan Rychter replied:
It also has the advantage of working extremely reliably on 2.4 (and a large
part of the code base is shared, so that's a significant data point). I
couldn't get it to crash or do anything bad for months now, and I'm doing
at least several suspend/resumes a day on my laptop.
Also, thanks to the excellent compression feature, suspend/resume times are
very short and in fact competitive with suspend-to-ram schemes.
I think it's better not to mix personal preferences (such as the
escape-to-abort thing) with technical discussions. On a practical level,
swsusp2 is the only implementation which works reliably, does its job very
well, and has a responsive maintainer willing to fix problems as they
arise.
Elsewhere, Benjamin Herrenschmidt said he also supported getting swsusp2 into
the main kernel tree. He said:
It may have problems, rough edges, whatever, but keeping out of tree is
more or less a guarantee that none of us will look & fix them ;)
If it gets upstream, I'll gladly finish the pmac support for it that I
quickly hacked recently for pmdisk as a proof of concept and help figure
out some of the remaining problems. I don't feel like doing that with an
out-of-tree project.
Pavel asked if Benjamin thought the merge should take place during 2.6, or
should wait until 2.7 opened up. Benjamin replied, "2.6. I don't see any
problem merging it at this point as long as it's not invasive (I haven't looked
at the code though). If it's self-contained, it's more/less like adding a
driver." Pavel looked over the code, and found it to be very invasive. He
thought it would be hard to get it into 2.6, and even the 2.7 timeframe looked
iffy to him now; and folks started discussing ways of taking out some of the
most invasive changes, to make the rest more palatable.
4. Linux 2.6.4-mm2 Released
14 Mar - 23 Mar (89 posts) Archive Link: "2.6.4-mm2"
Topics: FS: NFS, FS: ReiserFS
People: Andrew Morton
Andrew Morton announced Linux 2.6.4-mm2, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.4/
2.6.4-mm2/
+ Added the new per-address_space block unplugging code. This is designed
to reduce the locking contention against the global plug list's lock
and it also allows us to avoid unplugging all the queues in the machine
when we want just a single queue to kick off its I/O.
+ Reiserfs updates: mainly new features.
+ Some significant NFS client enhancements: reads smaller than PAGE_SIZE
are no longer synchronous, support for smaller-than-PAGE_SIZE reads,
etc.
5. bkbits.net Improvements
14 Mar - 18 Mar (7 posts) Archive Link: "BK/Web improvements (includes patch
server)"
People: Larry McVoy, Erik Andersen, David Woodhouse, Andy Isaacson
Larry McVoy said:
I've made a few changes to the BK/Web service on BK/Bits. There are some
cosmetic changes but the substantial changes are as follows:
+ Traditional diff -Nur style patches served as text/plain. You can now
wget your favorite patch. I fully expect that the BK users in the
kernel will start including URLs to the patches as part of the
submission process. For the BK users, the URL you want is
bk changes -r+ -nd'http://$proj.bkbits.net/$repo/gnupatch@:MD5KEY:'
where you fill in $proj and $repo and this assumes that you want to
include a pointer to the most recent changeset.
+ Bookmarkable changeset and patch links. When you navigate to a
changeset you'll see a link that says "Bookmarkable link". If you click
on that you'll see the URL change from [email protected] to cset@<MD5KEY>. If
you use the latter in your mail messages to your friends that URL will
always work; the first one won't.
+ Added sorting to the stats page, now you can see who is busy faster.
The definition of "recent" on the stats page is the last 3 months.
+ fixed searching (it works, it's still slow on large trees)
+ cleaned up some bugs in the advertising (we're looking for people so I
stuck ads up on the web pages).
Check it out at http://www.bkbits.net and let me know if you find a bug.
Erik Andersen replied:
Hey thats cool, I know I will use this often to slurp down patches of
interest.
<obligitory request for yet more stuff which is almost certain to piss
you off since you just gave me yet-another-something-for-free>
I'm curious if you might consider adding a diff -Nur style patch vs the
last tagged version? I often go to:
http://www.kernel.org/pub/linux/kernel/v2.4/testing/cset/
and
http://www.kernel.org/pub/linux/kernel/v2.5/testing/cset/
to obtain this sortof a patch, for example when I want to submit a patch
that is relevant to the current kernel tree, rather than 1000 patches
behind. Sadly, these are often rather out of touch with reality. Check out
for example the 2.4 one, which has been stuck since March 8th. :-(
Right now I can go to, for example:
http://linux.bkbits.net:8080/linux-2.4/[email protected]..?nav=index.html|
tags
and see the list of patches, and thanks to your latest update, I can now
click on each patch one-by-one to suck down a diff. I would sure love to be
able to obtain the lot as cumulative patch of everything after the last
tagged version.
I do not know if that is something you might consider, if doing so suites
your business model, if doing so would make unreasonable demands on your
donated bandwidth, cpu power, etc, etc, etc. But such a thing would
certainly come in handy, if you felt so inclined.
Of course, an alternative solution would be for someone to fix the
kernel.org testing/cset/ scripts to not get wedged...
David Woodhouse remarked, "The 'bk pull' was stuck in recv() and seems to have
been that way for days. I've killed it."
Andy Isaacson said that people should send requests to him rather than Larry;
and added regarding getting a cumulative patch since the last tagged version:
This is most profitably done outside of bkbits -- the kernel.org URLs you
point to should work (there's no reason they can't be made to go) and it's
hard to see the payoff to bkbits to providing it internally.
Gotta remember, bkbits is more than just kernel stuff. We're probably not
going to add code that is only useful to the kernel project.
The stuff larry added this weekend, by comparison, is stuff that makes our
lives better and has a payoff for us and our customers, while
simultaneously making life better for bkbits users. Win-win. (Or is that
win-win-win?)
6. Trying To Clarify Software Suspend
15 Mar - 18 Mar (14 posts) Archive Link: "Remove pmdisk from kernel"
Topics: Software Suspend
People: Pavel Machek, Andrew Morton
Pavel Machek posted a patch to remove pmdisk from the kernel; Andrew Morton
asked if pmdisk was still being maintained; and also asked if swsusp2 should be
accepted into the kernel. Pavel said he didn't think pmdisk was still being
maintained, and he added that swsusp2 had "hooks all over the place" , making
it very invasive; but Fedor Karpelevitch suggested that this might be the very
reason it worked well for so many people. There was no real resolution during
the thread.
7. Status Of fsync()
17 Mar - 22 Mar (40 posts) Archive Link: "True fsync() in Linux (on IDE)"
Topics: Disks: IDE
People: Peter Zaitsev, Jens Axboe
Peter Zaitsev asked:
is there any way in Linux to do proper fsync(), which makes sure data is
written to the disk.
Currently on IDE devices one can see, fsync() only flushes data to the
drive cache which is not enough for ACID guaranties database server must
give.
There is solution just to disable drive write cache, but it seems to
slowdown performance way to much.
I would be also happy enough with some global kernel option which would
enable drive cache flush on fsync :)
Jens Axboe said, "Chris and I have working real fsync() with the barrier
patches. I'll clean it up and post a patch for vanilla 2.6.5-rc today." Peter
and others were happy to hear about this.
8. Linux 2.6.5-rc1-mm2 Released
17 Mar - 19 Mar (4 posts) Archive Link: "2.6.5-rc1-mm2"
People: Andrew Morton
Andrew Morton announced Linux 2.6.5-rc1-mm2, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.5-rc1/
2.6.5-rc1-mm2/
+ Dropped the early-x86-cpu-detection patches, as these appear to be the
source of recent early-crash problems.
+ Several fixes against the new writeback code.
+ Several fixes against the new block unplugging code.
9. libata Update Against 2.6
18 Mar - 19 Mar (4 posts) Archive Link: "[PATCH,RFT] latest libata (includes
Silicon Image work)"
Topics: BSD: FreeBSD, Serial ATA
People: Jeff Garzik
Jeff Garzik said:
Attached is the latest libata patch against 2.6.x mainline. Although not
100% of content, most of this patch resolves around getting Silicon Image
into better shape. As I mentioned in my last post, this patch affects all
libata users, so plenty of testing is requested.
Silicon Image-related changes:
+ Only set/clear the BMDMA bits we care about (got a report last night
this fixed 3114 for him)
+ mask all SATA interrupts
+ after determining drive speed, write that information to a special SII
register Data Transfer Mode
+ (style) make port base address setup a loop, shortening the code and
making the code more readable
+ limit SII to UDMA5 (reading info on FreeBSD lists and source code
scared me about chip errata), mainly related to PATA->SATA bridges.
10. Linux 2.6.5-rc2 Released
19 Mar - 24 Mar (14 posts) Archive Link: "Linux 2.6.5-rc2"
Topics: Hot-Plugging, Sound: ALSA, USB
People: Linus Torvalds
Linus Torvalds announced 2.6.5-rc2, saying that it contained patches for
"Hotplug CPU's, USB, ALSA, input layer updates. And various random things."
11. Linux 2.4.26-pre5 Released
19 Mar - 21 Mar (4 posts) Archive Link: "Linux 2.4.26-pre5"
Topics: Disks: SCSI, Power Management: ACPI, USB
People: Marcelo Tosatti, Bert Kammerer, Doug Ledford
Marcelo Tosatti said:
Here goes the fifth -pre of 2.4.26.
It includes a number of USB bugfixes/updates, SCSI driver/stack fixes from
Doug Ledford, another ACPI update, amongst others.
This is probably the last -pre of 2.4.26 series.
Bert Kammerer said:
Ever since 2.4.25, when compiling it in to any RedHat 7.3 machine, the
following appears in dmesg:
attempt to access beyond end of device
03:02: rw=0, want=1020128, limit=1020127
I traced this to the mount version that ships with RedHat 7.3
(mount-2.11n). Upgrading mount to a newer version gets rid of the messages,
but I am unsure as to whether or not the errors are really going away. Do
you have any comments/suggestions concerning this issue?
Marcelo replied, "This error is harmless: Dont worry. It will be fixed in -rc1
(which should be out Monday or so)." Bert thanked him, and the thread ended.
12. Linux 2.6.5-rc2-mm1 Released
21 Mar - 23 Mar (6 posts) Archive Link: "2.6.5-rc2-mm1"
Topics: FS: ext2, FS: ext3
People: Andrew Morton, Dave Jones
Andrew Morton announced Linux 2.6.5-rc2-mm1, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.5-rc2/
2.6.5-rc2-mm1/
+ Dave Jones's agpgart and cpufreq trees will henceforth be included in
-mm kernels.
+ Various speedups, cleanups and fixes to the writeback, ext2 and ext3
code.
+ The usual bunch of random fixes
13. Status Of OSS
22 Mar - 24 Mar (21 posts) Archive Link: "OSS: cleanup or throw away"
Topics: Sound: ALSA, Sound: OSS
People: Jos Hulzink, Adrian Bunk, Diego Calleja Garcia, Bill Davidsen
Jos Hulzink said, "While fixing some "deprecated" issues in the OSS drivers, I
wondered whether this makes sense, as entire OSS is marked deprecated. Will OSS
make it until 2.7, or will it be dropped soon ? (In other words, should I take
care of the OSS drivers or not bother about them)" Adrian Bunk replied:
OSS will stay in 2.6 (2.6 is a stable kernel series) but it will most
likely be removed in 2.7.
I wouldn't spend time to fix deprecated warnings in OSS code, such cleanups
are wasted time for code that will most likely be removed in 2.7.
Diego Calleja Garcia replied, "Personally, as an user, I'd like to have the OSS
drivers which don't have a ALSA equivalent for my old hardware. There're
several sound cards with both ALSA and OSS drivers where ALSA works much better
99% of the time. Those could be safely removed (even in the 2.6 timeframe, I'd
argue) but I'd like to keep the ones without an alsa equivalent for my old
hardware (specially now that we have a -tiny tree ;) however I can understand
that if they don't have a maintainer they'll get removed..." Bill Davidsen
replied:
The real issue with removing OSS from a stable kernel is that a kernel
update should not break existing system software (at least compliant
software). As of early 2.6 it seemed that you had to update to the ALSA
mixer and {something I don't remember} if you used the OSS emulation. I
just used OSS and it worked. Based on only two systems, so it may not
apply.
Stable and install new sound software don't seem to mix well. I suggest
that the current course is a good one, keep both systems in the stable
kernel.
14. Setting A Non-Executable Stack For ELF Binaries
23 Mar - 24 Mar (28 posts) Archive Link: "Non-Exec stack patches"
Topics: Executable File Format
People: Kurt Garloff, Andrew Morton, Ingo Molnar
Kurt Garloff said:
find attached a patch to parse the elf binaries for a PT_GNU_STACK section
to set the stack non-executable if possible. Most parts have been
shamelessly stolen from Ingo Molnar's more ambitious stackshield http://
people.redhat.com/mingo/exec-shield/exec-shield-2.6.4-C9
The toolchain has meainwhile support for marking the binaries with a
PT_GNU_STACK section with ot without x bit as needed.
If no such section is found, we leave the stack to whatever the arch
defaults to. If there is one, we explicitly disabled the VM_EXEC bit if no
x bit is found, otherwise explicitly enable.
I believe this part should be merged into official mainstream kernels.
Ingo, what do you think?
Ingo Molnar liked the patch, and Andrew Morton said:
This patch propagates the PT_GNU_STACK setting into the vma flags, allowing
the architecture to set the stack permissions non-executable if the
architecture chooses to do that, yes?
Which architectures are currently making their pre-page execute permissions
depend upon VM_EXEC? Would additional arch patches be needed for this?
This may not get past Linus of course. It doesn't even get past me with
that magical undocumented -1/0/+1 value of the executable_stack argument.
Please replace that with a proper, commented, #defined-or-enumerated value,
thanks.
Kurt updated the patch, and the discussion skewed off and petered out.
15. Linux 2.2.27-pre1 Released
24 Mar (1 post) Archive Link: "Linux 2.2.27-pre1 released"
People: Marc-Christian Petersen
Marc-Christian Petersen announced, "now some more fixes with 2.2.27-pre1.
Please test. Have fun :)"
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.