Kernel Traffic #249 by Zack Brown
[email protected] Tue, 27 Jan 2004 15:25:19 -0800
| Newsgroups | gmane.linux.kernel.kernel-traffic |
|---|---|
| Message-ID | <[email protected]> |
Kernel Traffic #249 For 27 Jan
By Zack Brown
Table Of Contents
* Standard Format
* Text Format
* XML Source
* Introduction
* Mailing List Stats For This Week
* Threads Covered
1. 26 Dec 2003 - 7 Jan (17 ide-scsi Maintainership And Status; The
posts) Saga Continues
2. 30 Dec 2003 - 7 Jan (37 New kthread Threading Functions
posts)
3. 31 Dec 2003 - 4 Jan (16 Linux 2.6.0-rc1-mm1
posts)
4. 1 Jan - 5 Jan (14 Some Problems With SuSE gcc 3.3 Prereleases
posts)
5. 2 Jan (14 Some Filesystem Comparisons
posts)
6. 2 Jan - 10 Jan (11 Minimizing The Kernel
posts)
7. 3 Jan - 4 Jan (19 New Set Of Input Patches
posts)
8. 4 Jan (2 kernel.org Web Page HTML Validity
posts)
9. 4 Jan (1 Usagi Stable Version 5 Released
post)
10. 4 Jan - 5 Jan (8 Status Of HPT372 And HPT374 IDE Controller
posts) Support
11. 5 Jan - 7 Jan (8 Linux 2.6.1-rc1-mm2 Released
posts)
(11 Linux 2.4.24 To Be Serious Bugfix Only;
12. 5 Jan - 6 Jan posts) mremap Exploit Plugged; XFS Inclusion
Delayed
13. 5 Jan - 8 Jan (22 mremap Security Patch For 2.6
posts)
14. 5 Jan (5 Hotplug Scripts Version 2004_01_05 Released
posts)
15. 6 Jan - 9 Jan (12 Linux 2.4.24-pre4 Released; htree Code Not
posts) Yet Merged
16. 6 Jan (16 Linus Talks About Declaring 'volatile'
posts) Variables
17. 7 Jan (1 FUSE 1.1-pre1 Released
post)
18. 7 Jan (1 kgdb 2.0 For 2.6.0
post)
19. 7 Jan (1 iostat 2.0 Released
post)
20. 7 Jan (6 Using Floating Point Operations In Kernel
posts) Code
21. 7 Jan - 8 Jan (2 Linux 2.6.1-rc3 Released
posts)
22. 7 Jan - 9 Jan (19 Linux 2.6.1-rc2-mm1 Released; Also Uptodate
posts) Against 2.6.1-rc3
23. 7 Jan - 9 Jan (5 RAM Hotplugging And Allocation
posts)
24. 8 Jan (1 Linux Test Project January Version Released
post)
25. 8 Jan - 9 Jan (2 Keycode Problems In Recent Kernels
posts)
Introduction
DVD CCA has surrendered in the Bunner case (http://www.eff.org/IP/Video/
DVDCCA_case/20040122_eff_pr.php) , probably due in large part to the Jon
Johansen decision (http://www.eff.org/news/breaking/archives/2004_01.php#001162
) . As a result of this, the author of the DeCSS Haiku (http://www-2.cs.cmu.edu
/~dst/DeCSS/Gallery/decss-haiku.txt) has decided to step forward and
acknowledge his authorship. If he had done so before now, he would almost
certainly have become the target of a terrible lawsuit.
The true author of the DeCSS Haiku is in reality Seth David Schoen (http://
www.loyalty.org/~schoen/) , the Staff Technologist of the Electronic Frontier
Foundation (http://eff.org/) . Now that he's stepping out of the shadows, he's
written a really great article (http://www.loyalty.org/~schoen/haiku.html)
about what he did and why. Don't miss the easter egg!
Mailing List Stats For This Week
We looked at 1877 posts in 9836K.
There were 581 different contributors. 288 posted more than once. 180 posted
last week too.
The top posters of the week were:
* 60 posts in 237K by Andrew Morton
* 43 posts in 146K by Linus Torvalds
* 32 posts in 186K by Rusty Russell
* 32 posts in 101K by Mike Fedyk
* 28 posts in 118K by Jesper Juhl
* Full Stats
1. ide-scsi Maintainership And Status; The Saga Continues
26 Dec 2003 - 7 Jan (17 posts) Archive Link: "The survival of ide-scsi in
2.6.x"
Topics: Disks: IDE, Disks: SCSI, USB
People: Willem Riede, Pete Zaitcev, Mikael Pettersson, Bartlomiej
Zolnierkiewicz, James Bottomley, Bill Davidsen, Jens Axboe, Wakko Warner,
Stephen Tweedie, Linus Torvalds
Back in November, Linus Torvalds had some pretty harsh words to say about
ide-scsi, covered in Issue #242, Section #1 (3 Nov 2003: Status Of IDE-SCSI
Maintainance) .
This week, Willem Riede said:
I know that many feel that ide-scsi is useless, and should go away. And you
are probably tired of message threads talking about it. Yet I ask
respectfully that you hear me out, and give me feedback.
I need ide-scsi to survive. Why? I maintain osst, a driver for OnStream
tape drives, which need special handling. These drives exist in SCSI,
ATAPI, USB and IEEE1394 versions.
One high-level driver, osst, handles all of them, and that's how it should
be, right? For ATAPI, it relies on ide-scsi.
(By the way, ide-tape contains code for the ATAPI version, the DI-30, but
that code is old and has serveral known problems - I'd like to see it
removed - or at least deprecated - I will do that myself later if people
want me to.)
So can we agree to keep ide-scsi? I know it is not desired any more for cd
writers. To avoid the problem reports from people who don't realize that
and select ide-scsi anyway, we can refuse to attach to a cd-type device
(today it just warns). And/or make a new explicit module parameter to tell
ide-scsi exactly which drives to attach to.
Today, ide-scsi is buggy, and that needs fixing. The underlying problem is
that ide-scsi stands with one leg in the IDE world and one leg in the SCSI
world, which creates the challenge to make the IDE error recovery work in
sync with, and under the direction of the SCSI error handler.
Example bug reports are [1], [2], [3], [4], [5], and [6].
A recurring problem is scheduling while atomic, see [1], [5], [7]. Linus
points bluntly to the problem in [7]. I plead guilty to having introduced
that code segment in [8]. I later attempted to improve on the error
handling in [9], but that patch was not accepted (and wouldn't have fixed
that particular problem).
[6] is different, and has me baffled - what can evoke a page fault in
idescsi_transfer_pc?
In the spirit of cleaning up one's own mess, I am working on a new patch,
to hopefully alleviate the problems. I've made liberal use of the
attachments to the osdl bug reports [1]-[4] created by Mike Christie and a
patch from Philip Auld [10], to give credit where it is due. I've also
looked at ide-cd to see what it does differently.
Please look at the attachment (looking past the touch-ups that I made while
I was at it...). Am I moving in the right direction? Specific changes I
need advise on:
1. timer expiry
attachments to [1]-[4] and [10] suggest using it. Is it useful to buy
some more time? I don't see the point to wait longer. By returning 0, I
let ide_timer_expiry do its thing to handle lost (dma) interrupts. By
seeting the PC_TIMEDOUT flag, I tell our end_request function to return
DID_TIME_OUT to the scsi system.
2. ide (atapi) abort/error
By providing ide-scsi's own error/abort functions, I defer all errror
handling to the scsi error handlers. I have nagging doubts about
totally removing ide_do_reset() calls from them though :-(
3. scsi (eh) abort/error
These take much inspiration from Mike Christie's work on [1]-[4] The
eh_abort gets called first, and takes an opportunistic approach (if the
problem resolves itslf, great). The eh_error pulls the carpet from
under the request, and does the ide_do_reset(). I hope I've not
introduced any new locking/scheduling issues :-)
I've tested the patched ide-scsi with 2.6.0 - and it works fine. Too good
actually, meaning the new error routines have not been adequately
exercised. Any hints as to how to simulate errors at the ide subsystem
level? Something like Stephen Tweedie's testdrive [11] perhaps (if
applicable to char device), but for 2.6?
Linus states in [7] that ide-scsi needs a maintainer. I haven't seen anyone
step forward, so that leads me to believe I may be the only person that
depends enough on ide-scsi to be motivated?
If people will have me, I am prepared to take on that responsibility. I am
just concerned that I may not have enough of a variety of devices to be
able to thoroughly test it (unless the DI-30 is the only one :-)). What do
people see as the requirements to be able to maintain ide-scsi?
OK, let me have it... Thanks, Willem Riede.
References:
[1] http://bugme.osdl.org/show_bug.cgi?id=393
[2] http://bugme.osdl.org/show_bug.cgi?id=829
[3] http://bugme.osdl.org/show_bug.cgi?id=1335
[4] http://bugme.osdl.org/show_bug.cgi?id=1381
[5] http://marc.theaimsgroup.com/?l=linux-kernel&m=107103475609592&w=2
[6] http://marc.theaimsgroup.com/?l=linux-scsi&m=105334942001271&w=2
[7] http://marc.theaimsgroup.com/?l=linux-kernel&m=107150176124047&w=2
[8] http://marc.theaimsgroup.com/?l=linux-scsi&m=104051080518591&w=2
[9] http://marc.theaimsgroup.com/?l=linux-scsi&m=104361480527780&w=2
[10] http://marc.theaimsgroup.com/?l=linux-scsi&m=107115248030218&w=2
[11] http://people.redhat.com/sct/patches/testdrive/
Wakko Warner suggested, half-seriously, just getting rid of both the IDE and
the SCSI layers entirely, and replacing them with a generic layer that both
could share. Short of that, he felt the IDE layer at least had always been
ugly, and could be replaced by an IDE-to-SCSI converter, so all IDE devices
would appear to be SCSI to the system.
Pete Zaitcev also replied to Willem, saying, "Based on my expirience with
ide-tape, I would rather have it killed instead. One neat trick to appease
enemies of ide-scsi might be to rename it into ide-scsi into ide-tape-bis.
Might even add DSC bit handling... But the ide-tape is too ugly to live for
sure." Willem agreed in principal, but asked, "are there any IDE tape drives
currently supported by ide-tape, that are not compatble with ide-scsi plus st?"
Mikael Pettersson offered, "My Seagate STT8000A works better with ide-scsi+st
than with ide-tape. As long as a working ide-scsi is around, I couldn't care
less about the ide-tape abomination." At this point, Bartlomiej Zolnierkiewicz
said, "Both ide-tape and ide-scsi are to stay in 2.6.x and die in 2.7.x."
Elsewhere, James Bottomley also replied to Willem's initial post, saying that
since no one else was interested, Willem was certainly welcome to start sending
in patches; and James would look at them. He added, "In the long term, I think
libata will end up assuming much of the role that ide-scsi does now, but since
it doesn't interface to a lot of existing motherboard chipsets, we're going to
need ide-scsi around for a while at least." Willem thanked him, adding that
Linus had asked Jens Axboe to look over Willem's original patch; and Jens said
he hadn't gotten to it yet, but would look it over soon.
Elsewhere, Bill Davidsen also thought it would be fine for Willem to do what he
could with ide-scsi. Bill said, "here we have someone who has the need, the
ambition, and the time to do this. Users of tape and MO still have need for
ide-scsi, and would be happy to help test at least."
2. New kthread Threading Functions
30 Dec 2003 - 7 Jan (37 posts) Archive Link: "[PATCH 1/2] kthread_create"
Topics: Hot-Plugging
People: Rusty Russell, Jeff Garzik, Andrew Morton
Rusty Russell posted a patch, saying:
The hotplug CPU code introduces two major problems:
1. Threads which previously never stopped (migration thread, ksoftirqd,
keventd) have to be stopped cleanly as CPUs go offline.
2. Threads which previously never had to be created now have to be created
when a CPU goes online.
Unfortunately, stopping a thread is fairly baroque, involving memory
barriers, a completion and spinning until the task is actually dead.
There are also three problems in starting a thread:
1. Doing it from a random process context risks environment contamination:
better to do it from keventd to guarantee a clean environment, a-la
call_usermodehelper.
2. Getting the task struct without races is a hard: see kernel/sched.c
migration_call(), kernel/workqueue.c create_workqueue_thread().
3. There are races in starting a thread for a CPU which is not yet online:
migration thread does a complex dance at the moment for a similar
reason (there may be no migration thread to migrate us).
Place all this logic in some primitives to make life easier: kthread_create
(), kthread_start() and kthread_destroy(). These primitives require no
extra data-structures in the caller: they operate on normal "struct
task_struct"s.
Other changes:
+ Expose keventd_up(), as keventd and migration threads will use kthread
to launch, and kthread normally uses workqueues and must recognize this
case.
Andrew Morton suggested putting all the hotplugging patches in one location for
easy review, and Rusty said, "I've had this on kernel.org for a few years now.
It's even at the top of the page: http://www.kernel.org/pub/linux/kernel/people
/rusty"
Elsewhere, Jeff Garzik really liked Rusty's work, and said:
there are two mechanisms I (and some others) felt were missing from the
equally nifty workqueue stuff:
1. one-shot threads
2. keventd overflow
For #1, your patch seems to cover that nicely.
For #2, that's to be used for situations where (a) you need a thread
context _and_ (b) you simply cannot wait for keventd to become available
(since there are no time guarantees).
Rusty replied, regarding Jeff's item 1, "It's really for persistent threads,
but you can use it as one-shot by either (1) calling exit() in the core
function (and noone calls kthread_destroy), or (2) not having a core function
and just having an init function. I used this in a test patch."
3. Linux 2.6.0-rc1-mm1
31 Dec 2003 - 4 Jan (16 posts) Archive Link: "2.6.0-rc1-mm1"
Topics: Version Control
People: Matthias Urlichs, Andrew Morton
Andrew Morton posted 2.6.1-rc1-mm1 (ftp://ftp.kernel.org/pub/linux/kernel/
people/akpm/patches/2.6/2.6.1-rc1/2.6.1-rc1-mm1/) , primarily to resync with
the mainline 2.6 tree. Various folks posted fixes, and Matthias Urlichs also
said Andrew's release was
available via Bitkeeper at <bk://smurf.bkbits.net/linux-2.6-mm>.
If you use this tree, please consider dropping me a note or whatever; I
don't like to work in a vacuum...
The way I've built this, in case anybody's curious:
+ undo all the changes in 2.6.0-mm2 but not in 2.6.1-rc1-mm1.
+ merge with 2.6.1-rc1, resolved nine conflicts.
+ Apply all patches in 2.6.1-rc1-mm2 but not in 2.6.0-mm2. Some didn't
apply fully, for whatever reason.
+ Generate a diff between 2.6.1-rc1 and top-of-tree. Use interdiff -p1 to
compare that to Andrew's official patch. (There were none, which was
somewhat surprising.)
Oh yes, I've stopped prefixing the patch tags with mm[12]; that would get
too confusing in the long run.
4. Some Problems With SuSE gcc 3.3 Prereleases
1 Jan - 5 Jan (14 posts) Archive Link: "[PATCH] disable gcc warnings of sign/
unsigned comparison"
People: Paul Jackson, Adrian Bunk, Trond Myklebust, Andrew Morton
Paul Jackson posted a patch to disable gcc warnings on comparing signed and
unsigned numbers, because he was seeing a lot of these when using gcc 3.3 under
SuSE. In a later post he said:
Right now, compiling a 2.6.0-mm1 (what I had handy) with the 3.3 gcc on my
Pentium system for arch i386 generates 1386 signed and unsigned warnings,
of the two kinds:
warning: signed and unsigned type in conditional expression
warning: comparison between signed and unsigned
A patch that resolved these 1386 warnings would (1) generate more crap than
it cleaned up, (2) immediately result in adding more bugs than removed, and
(3) due to the crap level rising, generate more bugs long term than it
avoided.
Andrew Morton was revolted by this, and was all set to go with Paul's path, in
spite of the fact that Trond Myklebust and others felt it would be better to
just fix the kernel code causing the warnings instead. But before Andrew could
add the patch to his tree, Paul discovered that "the only place I can find the
gcc with this bug (that -Wall implies -Wsign-compare) is the gcc 3.3 that came
with my SuSE Linux 8.2 distribution. Each of the 3.3, 3.3.1 and 3.3.2 versions
available at ftp.gnu.org/gnu/gcc are ok - no such bug." Some folks began to
speculate that the bug was in 3.3, and that is had been fixed subsequently; but
elsewhere in the thread, Adrian Bunk also said, "It was _not_ a bug in gcc 3.3
. It was a bug in some _prerelease_ versions of gcc 3.3 SuSE decided to ship in
a release of their distribution. There is no officially released version of gcc
with this problem."
5. Some Filesystem Comparisons
2 Jan (14 posts) Archive Link: "file system technical comparisons"
Topics: FS: JFS, FS: NTFS, FS: ReiserFS, FS: ext3
People: Randy Dunlap
Steve Glines asked for a technical comparison between ext3, reiserfs, xfs jfs,
and if possible any other supported filesystems. Stewart Smith said he'd done
some comparisons of a number of filesystems in his honor's thesis (http://
www.flamingspork.com/honors/) , notable exceptions being JFS and NTFS. Someone
else also gave a link to a Linux Magazine article (http://www.linux-mag.com/
2002-10/jfs_01.html) . Randy Dunlap also gave a pointer to a comparison he'd
done (http://developer.osdl.org/rddunlap/journal_fs/lwe-jgfs.pdf) in the 2.4
era, which he said was quite dated and probably not so accurate anymore.
6. Minimizing The Kernel
2 Jan - 10 Jan (11 posts) Archive Link: "2.6.1-rc1-tiny1 tree for small
systems"
Topics: FS: ext2, Networking, Small Systems
People: Matt Mackall, Eric W. Biederman, Andi Kleen
Matt Mackall announced:
This is the third release of the -tiny kernel tree. The aim of this tree is
to collect patches that reduce kernel disk and memory footprint as well as
tools for working on small systems. Target users are things like embedded
systems, small or legacy desktop folks, and handhelds.
Latest release includes:
+ sync against 2.6.1-rc1
+ latest netdrvr patchkit
+ SLOB allocator
+ Andi Kleen's bloat-o-meter
+ configurable tcpdiag, inetpeer, dnotify, ptrace, sysenter/vsyscall
+ configurable X86 CPU feature detection
+ ability to override arch CFLAGS from Kconfig
+ optional uninlining of current and thread_info
+ other minor tweaks
The big bit here is SLOB, which optionally replaces the SLAB allocator and
kmalloc wrappers with a traditional malloc arena and a SLAB emulation
layer. SLOB is less than a tenth the size of the SLAB code and is
considerably more space efficient with its allocations, but is not as fast
and may prove less resistant to long-term fragmentation.
Thanks to Andi Kleen, Magnus Naeslund, and various others for their
contributions and suggestions.
The patch can be found at:
http://selenic.com/tiny/2.6.1-rc1-tiny1.patch.bz2
http://selenic.com/tiny/2.6.1-rc1-tiny1-broken-out.tar.bz2
Contributions and suggestions are encouraged. In particular, it would be
helpful if people with non-x86 hardware could take a stab at extending some
of the stuff that's currently only been done for X86 to other
architectures.
Eric W. Biederman gave it a try, and found that he was able to create a 220K
compressed kernel, which he felt was a huge reduction compared with other
kernels. He also felt there was a lot of room for improvement, because there
were many non-optional features still in Matt's tree. Matt said, "Suggestions?
I'm rapidly exhausting a lot of the obvious candidates. My target build at the
moment is ide + ext2 + proc + ipv4 + console, and that's currently at around
800K uncompressed, booting in a little less than 2.5MB. Hoping to get that
under 2." Eric replied:
I have a 386 I really should try this out on.
Of note IPv4 is about 90K compressed. And I know you can do a minimal IPv4
stack in about 8K compressed.
My target is a minimal kernel that can be used as a bootloader. But what I
am looking for at first is to be able to turn as many things off as
possible so that we can test to see how much individual pieces add.
If you look at ELKS or one of the old unix like kernels you can get those
down to 64K and still be usable.
I'm currently looking at removing the buffer cache, since I most of the
time I don't care about disks. This is complicated by the fact that many of
the default paths in the kernel when they don't have a better
implementation use buffer cache methods. But I'm making headway.
Proc is one of things that frequently has loads of crap that are not needed
in a minimal setup.
Until I find more candidates to turn off I can't see any low hanging fruit
for shrinking in size.
Later, Eric posted a patch to remove block device support from Matt's kernel.
This brought his compiled bzImage down to 191K. After some feedback, he posted
a cleaner patch that also did more, and Matt merged it into his tree.
7. New Set Of Input Patches
3 Jan - 4 Jan (19 posts) Archive Link: "New set of input patches"
People: Dmitry Torokhov, Vojtech Pavlik
Dmitry Torokhov said to Vojtech Pavlik:
I have a new set of input patches, could you take look at them?
1. i8042-suspend.patch
Add suspend methods to i8042 to restore BIOS settings on suspend and
kill polling timer which sometimes prevents APM suspend
2. i8042-options-parsing.patch
psmouse-options-parsing.patch
atkbd-options.parsing
Complete conversion to the new way of parsing parameters. Drop
"i8042_", "psmouse_" and "atkbd_" prefixes from option names when
compiled as a module and require "i8042.", "psmouse." and "atkbd."
prefixes if built into the kernel.
3. missing-module-license.patch
Maple and newton keyboard drivers were missing MODULE_LICENSE("GPL")
4. kconfig-synaptics-help.patch
Suggest psmouse.proto=imps to Synaptics users who do not want install
native XFree Synaptics driver so taps would still work
5. sis-aux-port.patch
Do not ignore AUX port if chipset fails to disable it when we do probes
as SiS is having trouble disabling but otherwise mouse works fine.
The patches are on top of 2 other input patches (remove jitter and ps2
emulation) that I have sent to the list earlier. You can find the complete
set of patches at http://www.geocities.com/dt_or/input/2_6_0-rc1/ and http:
//www.geocities.com/dt_or/input/2_6_0-rc1-mm1/
After some discussion and typo-hunting, Vojtech said, "Andrew, please apply
these patches to your tree and/or schedule them for inclusion into mainline."
8. kernel.org Web Page HTML Validity
4 Jan (2 posts) Archive Link: "Kernel.org: Webpage validator and Web
accessibility."
People: Tim Cambrant
Someone pointed out that if one were to run http://www.kernel.org through the
http://validator.w3.org/ W3C HTML validator, the page would turn out invalid.
Tim Cambrant replied, "You should contact the webmaster of http://kernel.org at
[email protected] about this, since it isn't a kernel-development issue. I
agree though, standards should be followed, and making it valid really doesn't
take long."
9. Usagi Stable Version 5 Released
4 Jan (1 post) Archive Link: "USAGI STABLE Release 5"
Topics: Networking
People: Yuji Sekiya
Yuji Sekiya announced:
We are glad to announce the USAGI STABLE RELEASE 5, dated on January 4th,
2004. This is the last major STABLE release based on linux-2.4 kernel from
USAGI Project. Our primary target of development is moved to linux-2.6
kernel.
Changes from the STABLE RELEASE 4.1 are:
+ based on linux-2.4.21,
+ IPsec transport/tunnel mode support,
+ Mobile IPv6 support,
+ fixed interaction between IPsec and Mobile IPv6,
+ Default Router Preference Support, and
+ Route Information Option Support.
However, the IPsec and Mobile IPv6 implementations included in this STABLE
release may not developed further. Because the IPsec stack was written for
linux-2.4 kernel by USAGI Project and currently we have rewritten NEW IPsec
stack for linux-2.6 kernel and the stack is included linux-2.6 mainline
kernel. The IPsec stack included linux-2.6 kernel is implemented based on
"xfrm" architecture and we will continue developing based on the NEW IPsec
stack.
The Mobile IPv6 stack is the same situation as the IPsec. The Mobile IPv6
stack included in this release is developed by HUT GO Project and the stack
is mainly written for linux-2.4 kernel. Currently USAGI Project and GO
Project have started joint project for developing new Mobile IPv6 stack
based on linux-2.6 kernel.
You can get our complete kit which includes kernel tree, library and
applications from <ftp://ftp.linux-ipv6.org/pub/usagi/stable/kit/>.
We also provide separate patches against the main-line kernel and the tools
<ftp://ftp.linux-ipv6.org/pub/usagi/stable/split/>.
Many of our efforts are already in mainline kernel tree. We will continue
making reasonable size patches and trying to merge it into mainline kernel
tree.
We announce the latest information on our web pages. Please check our web
site <http://www.linux-ipv6.org>.
We also manage the mailing lists for USAGI users. If you have questions,
please join the mailing list. Comments and advises are also welcome on that
mailing list. Please visit <http://www.linux-ipv6.org/ml/> for further
information.
10. Status Of HPT372 And HPT374 IDE Controller Support
4 Jan - 5 Jan (8 posts) Archive Link: "Any hope for HPT372/HPT374 IDE
controller?"
Topics: Disks: IDE
People: Andre Hedrick
Tom Wallard asked if the Highpoint HPT372 and HPT374 IDE controllers had been
fixed yet. As reported way back in Issue #216, Section #3 (29 Apr 2003:
'Must-Fix' Bug List For 2.6 (Or 3.0)) , at least the HPT372N would "eat disks"
in 2.5; Andre Hedrick replied:
I have a version stable for the KT400 chipset, it is the KT600 which is
unstable now. As soon as I finish resolving the issues one of my customers
is having with the KT600, it will be released shortly there after.
Some of the problems appear with the APIC routing and interrupts being lost
and not begin processed.
Various reports followed Tom's, including some claiming to work perfectly, and
others claiming to exhibit problems.
11. Linux 2.6.1-rc1-mm2 Released
5 Jan - 7 Jan (8 posts) Archive Link: "2.6.1-rc1-mm2"
Topics: Version Control
People: Andrew Morton, Matthias Urlichs
Andrew Morton announced 2.6.1-rc1-mm2 (ftp://ftp.kernel.org/pub/linux/kernel/
people/akpm/patches/2.6/2.6.1-rc1/2.6.1-rc1-mm2) , saying, "Many new fixes, all
over the place." Matthias Urlichs said that this release "will be bitkeeperized
shortly, in fact as soon as anything-non-kernel.bkbits.net is again reachable.
:-/"
12. Linux 2.4.24 To Be Serious Bugfix Only; mremap Exploit Plugged; XFS
Inclusion Delayed
5 Jan - 6 Jan (11 posts) Archive Link: "Linux 2.4.24-rc1"
Topics: FS: XFS
People: Marcelo Tosatti, Martin Knoblauch
Marcelo Tosatti announced 2.4.24-rc1, saying:
This release fixes a few critical problems in 2.4.23, including fixes for
two security bugs.
Upgrade is recommended.
The release dealt with a recently discovered mremap vulnerability (http://
isec.pl/vulnerabilities/isec-0013-mremap.txt) . Martin Knoblauch asked if this
release postponed other changes that had already been accepted into the 2.4
pre-releases; things like XFS, in particular. Marcelo explained, "Yes. The
2.4.24-pre tree with all its modifications becomes 2.4.25-pre."
13. mremap Security Patch For 2.6
5 Jan - 8 Jan (22 posts) Archive Link: "[patchlet link] Re: 2.6.1-rc1
affected?"
People: Linus Torvalds, Bastiaan Spandaw, Tomas Szepe
Markus Hastbacka asked if there would be a patch against 2.6 to fix the
recently discovered mremap security hold (http://isec.pl/vulnerabilities/
isec-0013-mremap.txt) . Linus Torvalds replied, "Yup. I'd actually personally
prefer a stronger test than the one in 2.4.24, and my personal preference would
be for just disallowing the degenerate cases entirely. I don't see a "mremap
away" as being a valid thing to do, since if that is what you want, why not
just do a "munmap()"?" Marcus asked why there wasn't already a new -rc release
for 2.6; and Linus replied, "Because nobody actually contacted me about the
problem and I read about it on linux-kernel like everybody else? Because I just
got up and created the patch? And because nobody has an exploit yet, and one
may be hard or impossible to create? And because people who care about these
things tend to not update to x.0 kernels anyway?" He added, "They'll get a
2.6.1 soonish. The patch is in the current BK tree, will be in -rc2, and will
be in 2.6.1. Let's just make sure we don't screw up the release due to being
too much in a hurry either.."
At some point, Tomas Szepe asked for some sample code to prove that an exploit
was possible, and Bastiaan Spandaw said, "According to a slashdot comment this
is proof of concept code. http://linuxfromscratch.org/~devine/mremap_poc.c" .
Several folks tested this on a few kernels and found it to successfully exploit
the hole.
14. Hotplug Scripts Version 2004_01_05 Released
5 Jan (5 posts) Archive Link: "[ANNOUNCE] 2004-01-05 release of hotplug
scripts"
Topics: Backward Compatibility, Hot-Plugging
People: Greg KH
Greg KH announced:
I've just packaged up the latest Linux hotplug scripts into a release,
which can be found at:
http://sourceforge.net/project/showfiles.php?group_id=17679
Or from your favorite kernel.org mirror at:
(http://www.kernel.org/pub/linux/utils/kernel/hotplug/
hotplug-2004_01_05.tar.gz) kernel.org/pub/linux/utils/kernel/hotplug/
hotplug-2004_01_05.tar.gz
or for those who like bz2 packages:
kernel.org/pub/linux/utils/kernel/hotplug/hotplug-2004_01_05.tar.bz2 (http:
//www.kernel.org/pub/linux/utils/kernel/hotplug/hotplug-2004_01_05.tar.bz2)
I've also packaged up some pre-built (and signed) Red Hat FC 1 based rpms:
kernel.org/pub/linux/utils/kernel/hotplug/hotplug-2004_01_05-1.noarch.rpm (
http://www.kernel.org/pub/linux/utils/kernel/hotplug/
hotplug-2004_01_05-1.noarch.rpm)
kernel.org/pub/linux/utils/kernel/hotplug/
hotplug-base-2004_01_05-1.noarch.rpm (http://www.kernel.org/pub/linux/utils
/kernel/hotplug/hotplug-base-2004_01_05-1.noarch.rpm)
The source rpm is available if you want to rebuild it for other distros or
versions of Red Hat at:
kernel.org/pub/linux/utils/kernel/hotplug/hotplug-2004_01_05-1.src.rpm (
http://www.kernel.org/pub/linux/utils/kernel/hotplug/
hotplug-2004_01_05-1.src.rpm)
kernel.org/pub/linux/utils/kernel/hotplug/hotplug-2004_01_05-1.src.rpm (
http://www.kernel.org/pub/linux/utils/kernel/hotplug/
hotplug-2004_01_05-1.src.rpm)
The main web site for the linux-hotplug project can be found at:
http://linux-hotplug.sf.net/
which contains lots of documentation on the whole linux-hotplug process.
This release is recommended for _anyone_ using the 2.6.0 and beyond kernels
who is still using hotplug scripts older than 2003_08_05, as a number of
changes have been made in order to support the 2.6 kernel properly.
The release is still backwards compatible with 2.4, so there is no need to
worry about upgrading.
15. Linux 2.4.24-pre4 Released; htree Code Not Yet Merged
6 Jan - 9 Jan (12 posts) Archive Link: "Linux 2.4.25-pre4"
Topics: FS: ext2
People: Marcelo Tosatti, Mike Fedyk
Marcelo Tosatti said:
Moving on with the 2.4.24-pre tree, here is 2.4.25-pre4.
It contains an ext2/3 update (mostly forward compatibility related), the
usual architecture updates (this time S390, PPC64/32, SH), osst update, TG3
bugfixes, amongst others.
Some of the fixes listed in this changelog (the rtc fixes, the IrDA "log
buster" fix and the netfilter MASQUERADE oops) were already in other
-pre's, they got removed and re added for technical BK reasons.
Mike Fedyk asked if Marcelo planned to merge the htree code, and Marcelo said
yes, in the next -pre release.
16. Linus Talks About Declaring 'volatile' Variables
6 Jan (16 posts) Archive Link: "[PATCH] fix get_jiffies_64 to work on voyager"
Topics: Assembly, SMP
People: Linus Torvalds
In the course of discussion, during which the suggestion was made to declare a
variable 'volatile', Linus Torvalds said:
we should _never_ make anything volatile. There just isn't any reason to.
The compiler will never do any "better" with a volatile, it will only ever
do worse.
If there are memory ordering constraints etc, the compiler won't be able to
handle them anyway, and volatile will be a no-op. That's why we have
"barrier()" and "mb()" and friends.
The _only_ acceptable use of "volatile" is basically:
+ in _code_ (not data structures), where we might mark a place as making
a special type of access. For example, in the PCI MMIO read functions,
rather than use inline assembly to force the particular access (which
would work equally well), we can force the pointer to a volatile type.
Similarly, we force this for "test_bit()" macros etc, because they are
documented to work on SMP-safe. But it's the _code_ that works that
way, not the data structures.
And this is an important distinctions: there are specific pieces of
_code_ that may be SMP-safe (for whatever reasons the writer thinks).
Data structures themselves are never SMP safe.
Ergo: never mark data structures "volatile". It's a sure sign of a bug
if the thing isn't a memory-mapped IO register (and even then it's
likely a bug, since you really should be using the proper functions).
(Some driver writers use "volatile" for mailboxes that are updated by
DMA from the hardware. It _can_ be correct there, but the fact is, you
might as well put the "volatile" in the code just out of principle).
That said, the "sure sign of a bug" case has one specific sub-case:
+ to paste over bugs that you really don't tink are worth fixing any
other way. This is why "jiffies" itself is declared volatile: just to
let people write code that does "while (time_before(xxx, jiffies))".
But the "jiffies" case is safe only _exactly_ because it's an atomic read.
You always get a valid value - so it's actually "safe" to mark jiffies as
baing volatile. It allows people to be sloppy (bad), but at least it allows
people to be sloppy in a safe way.
In contrast, "jiffies_64" is _not_ an area where you can safely let the
compiler read a unstable value, so "volatile" is fundamentally wrong for
it. You need to have some locking, or to explicitly say "we don't care in
this case", and in both cases it would be wrong to call the thing
"volatile". With locking, it _isn't_ volatile, and with "we don't care", it
had better not make any difference. In either case the "volatile" is wrong.
We had absolutely _tons_ of bugs in the original networking code, where
clueless people thougth that "volatile" somehow means that you don't need
locking. EVERY SINGLE CASE, and I mean EVERY ONE, was a bug.
There are some other cases where the "volatile" keyword is fine, notably
inline asm has a specific meaning that is pretty well-defined and very
useful. But in all other cases I'd suggest having the volatile be part of
the code, possibly with an explanation _why_ it is ok to use volatile there
unless it is obvious.
17. FUSE 1.1-pre1 Released
7 Jan (1 post) Archive Link: "[ANNOUNCE] Filesystem in Userspace (FUSE)
1.1-pre1"
People: Miklos Szeredi
Miklos Szeredi announced FUSE (Filesystem in User SpacE) version 1.1-pre1, and
said:
I did a release at long last, it's got proper 2.6 kernel support and all
the rest of the stuff that people contributed since 1.0.
It can be downloaded from the usual place:
http://sourceforge.net/projects/avf
18. kgdb 2.0 For 2.6.0
7 Jan (1 post) Archive Link: "kgdb 2.0 for kernel 2.6.0"
People: Amit S. Kale, George Anzinger, Andi Kleen, Andrew Morton
Amit S. Kale said:
I have released kgdb 2.0 for kernel 2.6.0 for i386 and x86_64 architectures
at http://kgdb.sourceforge.net.
This version of kgdb has been supported by TimeSys Corporation and Storad
Inc. It contains code from kgdb patches maintained by Andrew Morton (George
Anzinger), Andi Kleen and Jim Housten.
Significant changes since previous version:
1. This version contains three patches: architecture specific patches for
i386 and x86_64 and a common patch.
2. Automatic loading of modules in gdb is available on x86_64 platform
now. Debugging of modules, including those in initrd, should be trivial
with this feature.
3. Hasslefree detach and reconnect from gdb possible on x86_64 platform
also.
4. New format of kgdb kernel command line options: kgdbwait, kgdb8250.
5. Shadow thread to get backtraces lost when gdb can't go beyond do_IRQ.
6. Uses new thread list packet qf instead of qL. This fixes the thread
information loss previous versions of kgdb had.
19. iostat 2.0 Released
7 Jan (1 post) Archive Link: "iostat - Linux I/O performance monitoring
utility"
People: Zlatko Calusic
Zlatko Calusic said:
iostat v2.0 is out!
It works flawlessly on both 2.4 & 2.6, compiles on Debian, Redhat, you name
it... IOW, it's perfect. :)
Looks something like this:
extended device statistics
device mgr/s mgw/s r/s w/s kr/s kw/s size queue wait svc_t %b
hde 0 3530 5.0 92.0 20.2 14597.8 150.6 68.1 563.2 6.0 58
hdg 0 0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0
hda 0 105 159.6 69.4 637.7 812.9 6.3 56.0 176.4 4.1 95
Find it on: http://linux.inet.hr/
20. Using Floating Point Operations In Kernel Code
7 Jan (6 posts) Archive Link: "Use of floating point in the kernel"
People: H. Peter Anvin, Linus Torvalds
Pekka Pietikainen found some cases of floating point math operations inside
kernel code, which is not supposed to be allowed; H. Peter Anvin said, "Has
anyone considered asking the gcc people to add an -fno-fpu (or -mno-fpu)
option, throwing an error if any FP instructions are used?" Linus Torvalds
replied:
We really should, but there really are some rare cases where it is actually
ok.
In particular, you _can_ do math, if you just do the proper
"kernel_fpu_begin()"/"kernel_fpu_end()" around it, and you have reason to
believe that you can assume a math processor exists.
Is it needed? I dunno. I'd frown on it in general, but I don't see it being
fundamentally wrong under the rigth circumstances.
21. Linux 2.6.1-rc3 Released
7 Jan - 8 Jan (2 posts) Archive Link: "2.6.1-rc3"
People: Linus Torvalds
Linus Torvalds announced kernel 2.6.1-rc3, saying, "Not a lot to say, the
ChangeLog says it all (and I include the -rc2 log too, since I forgot to
actually ever post it). Mostly random smaller stuff all over. The big merges
were all in rc1 and do not seem to have caused any huge headaches."
22. Linux 2.6.1-rc2-mm1 Released; Also Uptodate Against 2.6.1-rc3
7 Jan - 9 Jan (19 posts) Archive Link: "2.6.1-rc2-mm1"
Topics: Disk Arrays: RAID, FS: ext2, Framebuffer, Power Management: ACPI,
Security, User-Mode Linux, Version Control
People: Andrew Morton
Andrew Morton announced:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1-rc2/
2.6.1-rc2-mm1/
+ Some rework to the mt-ranier CDROM support and ATAPI access to MO
drives. Could anyone who uses these please retest.
+ A fix for loop-on-ext2-on-cdrom. Also needs testing please.
+ A significant amount of work on remap_file_pages() from Ingo. Most
notably, we now support per-page protections within a single VMA. This
is aimed at UML and similar specialised applications which are
presently forced to allocate one VMA per page.
Anyone who is interested in remap_file_pages(), please test.
This adds a new syscall and breaks all non-ia32 architectures.
Instructions as to how to unbreak them is in the
remap_file_pages-prot-2.6.1-H2 patch.
+ The remap_file_pages non-blocking infrastructure has been used to
implement prefaulting of minor faults for mappings. This will reduce
the kernel's minor fault rate by up to a factor of eight and has been
shown to offer a few percent speedup on some things.
This needs serious benchmarking please. Tests which involve short-lived
processes.
The remap_file_pages work will probably live in -mm for a while. It
needs careful review - alterations to largely unused code paths are a
concern because of the potential for long-lived security and DoS holes.
+ Added an implementation of RAID6 from Peter Anvin. Usage information is
available in the Kconfig help for the feature. I'm sure he'd like to
hear of testing results.
+ There's a fix for the Radeon framebuffer card here which we're a bit
wobbly about. if you have such a thing, please send a report.
+ Significant amount of rework of the ACPI PM timer source patch. I'm not
sure that I got all the right patches in the right place. John and
Dominik, please double-check.
+ Added the latest code drop from DRM CVS. People who use DRM, please
test it.
He replied to himself, having noticed that Linus had put out 2.6.1-rc3 just
moment's before Andrew's own release. He said, "2.6.1-rc2-mm1 contains
everything which is in 2.6.1-rc3."
23. RAM Hotplugging And Allocation
7 Jan - 9 Jan (5 posts) Archive Link: "a new version of memory hotremove
patch"
Topics: Big Memory Support, Hot-Plugging
People: Toshihiro Iwamoto, Hirokazu Takahashi
Toshihiro Iwamoto said:
This is an update of the memory hot removal patch. As I'll merge this patch
over Goto-san's hotplug patch (http://marc.theaimsgroup.com/?l=linux-kernel
&m=107214532922184&w=2), this will be the final version in this standalone
form. When that is done, there will be no more zone_active checks in page
allocation code.
Changes from the previous version (dated 20031126) are:
+ Implemented remapping of mlock()'d pages. This is done by adding an
argument to try_to_unmap() function to be able to ignore VM_LOCKED bit.
+ Hacks to make kswapd more aggressive on disabled zones were removed.
Remapping and swapping out should be used together to make system
performance impact caused by memory hot removal low. I think switching
remapping and swapping out based on whether pages are on active lists
or inactive lists is an easy and acceptable solution. There may be
better threshold, and the above idea may be inappropriate for systems
where the cost of memcpy is very high.
+ Bugfixes. truncate detection, page dirty bit handling, more PageAgain
handling.
Known problems:
+ If a page is in mapping->io_pages when remap happens, it will be moved
to dirty_pages. Tracking page->list to find out the list which page is
connected to would be too expensive, and I have no other idea.
+ It seems there's a very small possibility of race between remap and
move_from_swap_cache. I've added some code for this, but it is
essentially untested.
I guess many of you think this patch has no use for yourselves, but it was
at least useful for finding some kind of kernel memory leaks. :)
http://people.valinux.co.jp/~iwamoto/mh.html contains some patch
explaination and usage info. This page hasn't changed much since the last
post.
Hirokazu Takahashi replied:
I just implemented a patch which allow us to allocate huge continuous pages
easily. As We know it's very hard to allocate them on demand, since free
memory on system may be fragmented. My approach is that I let annoying
pages move to another place so that we can make free coninuous space on
memory. Iwamoto's memory-hot-removal patch will help to do it.
I believe moving pages approach will be much better than random swaping
page out approach for this purpose.
iwamoto> This is an update of the memory hot removal patch.
iwamoto> http://people.valinux.co.jp/~iwamoto/mh.html
My patch needs the iwamoto's memory-hot-removeval patch. You should apply
both of them against linux-2.6.0.
Known problems:
+ This patch doesn't work if CONFIG_HUGETLB_PAGE isn't set. Does anybody
have good idea to solve it, since it's difficult to know whether a
specified page is free or a part of a large continuous page without
PG_compound flag.
ToDos:
+ It's hard to allocate HugePages for hugetlbfs on a box which dosen't
have HighMem zones yet.
+ We will make some continuous pages allocation work at the same time.
24. Linux Test Project January Version Released
8 Jan (1 post) Archive Link: "[ANNOUNCE] Linux Test Project January Release
Announcement"
People: Robert Williamson, Randy Hron, Erik Andersen
Robert Williamson said:
The Linux Test Project test suite <http://www.linuxtestproject.org> has
been released. The latest version of the testsuite contains 2100+ tests for
the Linux OS. Our web 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.
Developers from the Linux Test Project co-authored the whitepaper, "Putting
Linux Reliability to the Test". This article documents the test results and
analysis of the Linux kernel and other core OS components, including
everything from libraries and device drivers to file systems and
networking, all under some fairly adverse conditions, over a period of 60
days. You can find the paper at: http://www.ibm.com/developerworks/linux/
library/l-rel
Release Highlights:
+ Code cleanups by Erik Andersen, Glen Foster, Jay Turner, and Ming Gao.
+ Removal of a memory leak in one of the test harness libraries by Randy
Hron.
+ Improvements to allow tests to build and execute under more
environments and distributions.
We encourage the community to post results to [email protected], and
patches, new tests, or comments/questions to [email protected].
25. Keycode Problems In Recent Kernels
8 Jan - 9 Jan (2 posts) Archive Link: "Broken keycodes in recent kernels"
Topics: Microsoft, USB
People: Andries Brouwer, Vojtech Pavlik
Andries Brouwer said:
Just received my tenth complaint this year about the fact that kbd and
recent kernels disagree as to what the right keycodes are. Since I maintain
kbd it follows that recent kernels are broken.
What is right?
The old Linux convention is that for 1-88 keycode equals scancode. Above
that things are a bit messy, mainly because the 128 scancodes xx and the
128 escaped scancodes e0 xx and the single combination e1 1d 45 are put
into 127 keycodes, and that doesnt fit.
OK. So we want at least to preserve this 1-88 range, and may worry about
the rest later. All common keys should keep their keycode. See also
setkeycodes(8).
2.6 does first an untranslate and then a map to keycode, so the fact that
keycode equals (translated) scancode now becomes atkbd_set2_keycode
[atkbd_unxlate_table[i]] == i for i=1,...,88.
Looking at 2.6.0 we see a single mistake: scancode 84 is translated
incorrectly. And many Japanese complained. Looking at 2.6.1-rc1 we see two
mistakes: also scancode 85 is now mistranslated.
So, I think the change of 2.6.1-rc1 was not necessarily an improvement, but
2.6.0 needs a fix.
I can look at the details, but perhaps Vojtech wants to comment.
Vojtech Pavlik replied:
I won't argue that the 2.6.1-rc situation is correct, but I'll describe it
and the difference from 2.4:
1. Keycode 84.
On 2.4, keycode 84 is the SysRq keycode, since historically AT
keyboards do emit a different keycode for SysRq than form PrintScreen,
although they're on the same key.
On 2.6, there is only one keycode for PrintScreen, in an attempt to be
a bit saner, and that is 99. And here comes my mistake - since 84 was
not used anymore, I used it for the "103rd" European key.
The 103rd key usually produces either backslash-bar or hash-tilde, or
other national combo. I believe that 2.4 did emit keycode 43 for it,
since this keyboard is treated the same as backslash by AT Set 2
keyboards, in hardware.
USB keyboards, and Set 3 keyboards, however differentiate between this
key and the real backslash, and since there also can be the real
backslash in addition to this key on the keyboard, it makes sense to
allocate a scancode to it.
Now my snafu was that I allocated a 2.4-used scancode to it, and one
that is mapped to SAK in 2.4 keymaps usually.
This bites French, British and probably Brazilian people, too.
I'm open to suggestions about how to fix it.
2. Keycode 85.
Scancode 85 (translated, set2) at the moment is not mapped to any
keycode. There are other scancodes that are not mapped at all, only
known scancodes are mapped, the rest should be changed by the user.
Keycode 85 is defined as F13 (in keymaps), and is mapped to scancode 93
(both in atkbd.c and keyboard.c), which is F13, according to Microsoft
documentation, which was used as reference, since that's what keyboard
manufacturers tend to follow nowadays.
3. Japanese and Korean keys.
2.6 has unified support for Japanese and Korean keys on both USB and PS
/2 keyboards.
The keycodes are defined as:
KEY_INTL1 181 /* Romanji */
KEY_INTL2 182 /* Hiragana / Katakana */
KEY_INTL3 183 /* Yen */
KEY_INTL4 184 /* Henkan */
KEY_INTL5 185 /* Muhenkan */
KEY_INTL6 186 /* PC9800 KP , */
KEY_LANG1 190 /* Hanguel */
KEY_LANG2 191 /* Hanja */
KEY_LANG3 192 /* Katakana */
KEY_LANG4 193 /* Hiragana */
KEY_LANG5 194 /* Zenkaku / Hankaku */
These keycodes are translated back to the PS/2 scancodes in raw mode.
The problem here lies in that that all the keycodes are above 128, and
are different from what 2.4 used for these keys on an AT keyboard.
We could go back to the 2.4 layout, where the keycodes are scattered
where there was space in the translated set2 scancode list, and not
even all fit there, but I think that way lies madness. The 2.6 layout
is based on the USB HUT definition.
We Hope You Enjoy Kernel Traffic
Kernel Traffic is hosted by the generous folks at Tux.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.