�
Kernel Traffic
Latest�|�Archives�|�People�|�Topics 		Wine
Latest�|�Archives�|�People�|�Topics 		GNUe
Latest�|�Archives�|�People�|�Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic
�

Kernel Traffic #262 For 11�Jun�2004

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

We looked at 932 posts in 5313K.

There were 324 different contributors. 156 posted more than once. 93 posted last week too.

The top posters of the week were:

1. sym53c500_cs PCMCIA SCSI Driver Released

9�Apr�2004�-�25�Apr�2004 (16 posts) Archive Link: "[PATCH] sym53c500_cs PCMCIA SCSI driver (new)"

Topics: Disks: SCSI

People: Bob Tracy,�Christoph Hellwig,�Russell King,�Bill Davidsen

Bob Tracy said:

The attached patch set implements a PCMCIA SCSI driver for host adapters based on the Symbios 53c500 chip. The original driver for this chip was written by Thomas Corner and available only as an add-on to the pcmcia-cs package. I've been maintaining the add-on driver on an infrequent basis for the past several years, and the release of the 2.6 kernel "forced" a long overdue update.

The only host adapter I'm aware of that uses the sym53c500 controller chip is the "new" version of the New Media Bus Toaster (circa 1996), and the attached driver has been tested using this particular adapter on a 2.6.4 kernel. The patch set applies cleanly to 2.6.4 and 2.6.5.

Christoph Hellwig replied:

I've given it a short spin and here's a bunch of comments:

  1. the split into three source files is supserflous, one file should do it
  2. please don't use host.h or scsi.h from drivers/scsi/. The defintions not present in include/scsi/ are deprecated and shall not be used (the most prominent example in your driver are the Scsi_<Foo> typedefs that have been replaced by struct scsi_foo
  3. the driver doesn't even try to deal with multiple HBAs
  4. your detection logic could be streamlined a little, e.g. the request/release resource mess

Regarding collecting everything into a single file, Bob was skeptical. He said that currently it was true, the driver only supported PCMCIA implementations, so there was no real need for multiple files. But he added, "My thinking was if someone comes up with a host adapter that isn't PCMCIA, the SYM53C500.c file is to the sym53c500_cs driver what the qlogicfas.c file is to the qlogic_cs driver, that is, core functions that could support multiple types of host adapters." Bill Davidsen thought this made enough sense to justify the split, especially given that Bob had split the files along the lines that other drivers had already used; but Christoph said it would be better to wait until the need actually arose before splitting the file. Otherwise the danger was that the split as currently designed might not be quite right, and it tended to add unnecessary complexity just by having more files than was actually necessary.

In response to Christoph's objection in his original post, to Bob's detection logic, Bob said he'd try to clean it up, adding, "the goal for the initial port was to replicate the functionality I already had in older kernel versions. It appears I faithfully replicated the deficiencies of the old driver as well :-)." Christoph explained, "Any 2.6 driver is better than none and your looks quite okay from the functional standpoint. We just need to have a little higher bars for new drivers as we already have lots of maintaince overhead for old and sloppy written drivers." Bob replied, "Attached is the second attempt at a 2.6 PCMCIA driver for SCSI cards based on the Symbios 53c500 controller. The patch set was tested with (and applies cleanly to) 2.6.5. As requested, the driver source has been consolidated into a single file. All remnants of code that might have supported non-PCMCIA host adapters have been ripped out, which allowed for the requested streamlining of the detection logic: Card Services is doing most of the heavy lifting in that area anyway :-)." After some detailed technical criticism by Christoph going line-by-line through the patch, Bob posted a third update, saying:

here's the latest attempt at a 2.6 driver for PCMCIA SCSI cards using the Symbios 53c500 controller. This includes (at least) "newer" versions of the New Media Bus Toaster (circa 1997). The attached patch set applies cleanly to 2.6.5.

In addition to all the concerns Christoph raised in response to the previous two submissions, there was an issue with the code for handling a CS_EVENT_CARD_RESET event: the event handler was calling the bus_reset function with a NULL scsi_cmnd argument. The potential problem was masked by the fact my bus_reset function was a trivial reimplementation of the default behavior in the absence of a bus_reset function. Folks using the qlogic_cs driver are hereby warned: if the event handler tries to process a CS_EVENT_CARD_RESET event (probably following a "resume"), qlogicfas_bus_reset() will be called with a NULL scsi_cmnd argument, and the next thing you'll see will be the "oops" resulting from a null pointer dereference. For what it's worth, someone besides me has noted this can happen: see the comment block above qlogicfas_bus_reset() in linux/drivers/scsi/qlogicfas.c.

Major differences between this version and prior ones:

  1. Support for multiple HBAs should now be in place. The only global host variable affects the PIO speed, and that's affected by a compile- time define.
  2. Although proc_info is officially obsolete in 2.6, I didn't delete the associated code: it can be enabled by defining PROC_INFO at compile time (for people like me who find it useful).
  3. Cleanup/consolidation of multiple functions, including deletion of code rendered superfluous by new 2.6 ways of doing things.

Barring any remaining issues (Christoph?), I think we're finally ready for prime time :-).

Russell King had an objection to offer. He said:

what happens if you're in the middle of a transaction, and you receive a CS_EVENT_CARD_RESET. What happens to the command in progress ?

Sure, the hardware is reset to a sane state, but what about the software state in the driver?

Bob admitted he didn't know what would happen in that case; Russell remarked, "From the brief look I had, it didn't look like it - I suspect things will go gaga if someone ever invoked "cardctl reset"." Bob replied that maybe this was a case of just telling the user to avoid doing that... but there was no further discussion.

2. Per-User Signal-Pending And Message-Queue Limits In 2.6 And 2.4

19�Apr�2004�-�27�Apr�2004 (12 posts) Archive Link: "[PATCH] per-user signal pending and message queue limits"

Topics: POSIX, Security

People: Marcelo Tosatti,�Jakub Jelinek,�Manfred Spraul,�Andrew Morton

Marcelo Tosatti, in addition to maintaining the 2.4 kernel, has also been doing a bit of 2.6 work as well. He submitted a patch to Andrew Morton, saying:

Here goes the signal pending & POSIX mqueue's per-uid limit patch.

Initialization has been moved to include/asm-i386/resource.h, as you suggested.

The global mqueue limit has been increased to 256 (64 per user), and the global signal pending limit to 4096 (1024 per user).

This has been well tested.

If you are OK with it for inclusion (-mm) I'll generate the arch-dependant changes for the other architectures.

Andrew approved the patch and encouraged Marcelo to do the architecture-dependent code as well. Jakub Jelinek, close by, observed, "I wonder if it is a good idea to base mqueue limitation on the number of message queues and not take into account how big they are. 64 message queues with 1 byte msgsize and 1 maxmsg is certainly quite harmless and the system could have even more queues for such a user, while 64 message queues with 16K msgsize (current default) and 40 maxmsg (also default) eats ~ 40M of kernel memory." Marcelo agreed with this, saying the the amount of memory actually used would be a better yardstick. Manfred Spraul cautioned, "I agree, but note that there is one hidden problem: There can be one notification for each registered message queue. If there are more than ~560 queues and one process wants to install SIGEV_THREAD notification handlers for all of them, then the netfilter code will run against the socket rmem limit and mq_notify will block. _If_ there are users that do that we'll have to bypass the normal sk_rmem_alloc and add an mqueue specific limit." Andrew put it a little differently, saying to Marcelo:

But we still have the global mq and signal limits? These permit local denials of service attacks. See http://seclists.org/lists/linux-kernel/2004/Apr/2065.html

The major advantage of your work is that we can now remove those limits. You'll be needing a 2.4 backport ;)

Marcelo agreed with the DoS attack and the need for a 2.4 backport; though he did add that actually it required 4 users acting in concert to successfully do the attack. He also said, "currently root is allowed to allocate infinite number of mqueues. We want to remove that and calculate on the amount of memory allocated. I'll also think about it and come with an implementation." Along with the kernel part of the port, he also added, "we also need to do the userspace part. ulimit is part of bash, so probably all shell's should be awared of this?" To that last, Andrew replied:

yup, the shells need to be changed, which is really awkward. I was wrong about how bash and zsh handle `ulimit 4 1024'.

Really the shells _should_ permit ulimit-by-number for this very reason.

Adding new ulimits is nice - it's a shame that the shells make it hard to use.

The next day Marcelo was hard at work again and posted a technical question; and a few posts later said:

Here goes the latest signal/mqueue per-uid limits patch. It now does:

I added an int to mqueue inode and to "struct msg_msg" (to save the UID of inode creator, to guarantee deaccounting is done correctly if another UID deletes the entries (eg root)). I wonder about cache locality. Has anyone cared enough to align the mqueue structures? Dont think so... Does it impact performance?

Thanks Andrew, Manfred and Jakub for their comments.

Attached are "mqsend.c" and "mqrec.c", two simple programs (copied from libmqueue) which I used for testing, in case anyone is interested.

Manfred had a technical criticism, but there was no discussion of this updated patch.

3. Crypto CRC32C Module

19�Apr�2004�-�27�Apr�2004 (11 posts) Archive Link: "[PATCH] crypto/crc32c implementation, updated 040419"

Topics: Version Control

People: Clay Haapala,�David S. Miller,�James Morris

Clay Haapala said, "This patch against 2.6.6-rc1-bk implements the CRC32C algorithm as a type of digest. It is implemented as a wrapper for libcrc32c, available in a separate patch. The crypto CRC32C module will be used by the iscsi-sfnet driver." David S. Miller and James Morris approved of the patch; Clay rediffed the patches against the official 2.6.6-rc1 tree, and after clearing up a few small objections, David applied it.

4. Status Of IDE Module Unloading; IDE And libata

21�Apr�2004�-�26�Apr�2004 (11 posts) Archive Link: "[PATCH] prevent module unloading for legacy IDE chipset drivers"

Topics: Disks: IDE, Disks: SCSI, FS: rootfs, Sound: ALSA, Sound: OSS

People: Erik Andersen,�Erik Mouw,�Bartlomiej Zolnierkiewicz

Bartlomiej Zolnierkiewicz posted a patch to disable module unloading for legacy IDE chipset drivers. This involved just removing the module_exit() call from the drivers. Erik Andersen asked, "Out of curiosity, what would be needed to make it safe to unload all ide modules from a system with a scsi rootfs?" Bartlomiej said that it made no difference, because the user could regardless end up unloading modules that were still in use. Erik Mouw said he'd been successfully unloading IDE modules for years; he asked, "What makes IDE sufficiently different from SCSI that we can't unload IDE host drivers?" Bartlomiej replied that a lack of reference counting, as well as insufficient locking and other technical details accounted for this. Erik M. asked, "Do you plan to fix the module unloading in the current code, or is it easier to write a new driver based on libata (assuming it has been fixed in libata)? If I understood Jeff's latest libata update correctly, it should be possible Real Soon Now [tm], right?" Bartlomiej replied, "I'm going to fix it but doing it properly requires major changes in IDE code." He added:

I think there is a common misunderstanding about libata: it will not replace IDE drivers any time soon.

I want to rewrite+merge current IDE code with libata during 2.7 (and yes, legacy naming and ordering will be preserved!).

I hope nobody starts rewriting existing IDE drivers for libata and pushing them upstream -> it will mean maintenance problems much bigger than OSS+ALSA.

However writing _new_ libata driver for 'exotic' PATA hardware is OK.

5. Linux 2.4.27-pre1 Released

22�Apr�2004�-�25�Apr�2004 (5 posts) Archive Link: "Linux 2.4.27-pre1"

Topics: FS: procfs, Serial ATA, USB

People: Marcelo Tosatti,�David S. Miller,�Geert Uytterhoeven

Marcelo Tosatti announced Linux 2.4.27-pre1, saying:

Most importantly it contains the addition of SATA drivers backport from v2.6.

Also network driver updates, USB updates, etc.

Geert Uytterhoeven posted a one-liner patch to the config scripts, saying that the Packet Generator (an experimental feature) wouldn't compile unless ProcFS was also included. David S. Miller accepted the patch gratefully, asking if 2.6 also needed a similar patch; but Geert confirmed that 2.6 already included the necessary dependencies.

6. SiS Driver Fixes

25�Apr�2004�-�26�Apr�2004 (2 posts) Archive Link: "[sata] SiS driver fixes"

Topics: Serial ATA

People: Jeff Garzik,�Robin Parker

Jeff Garzik said:

Attached is a patch, and the full 2.6.x version of the SiS driver, for testing.

This should address the problem where people were having their SATA drives not recognized at probe time.

Any feedback, including "you didn't break anything", would be great, as I don't have any SiS test hardware up and running.

Robin Parker gave it a whirl and said, "What can I say?? It worked like a charm."

7. AHCI Driver; Open Hardware Specifications

25�Apr�2004 (2 posts) Archive Link: "[sata] new driver -- AHCI"

Topics: Disks: IDE, Disks: SCSI, Hot-Plugging, Networking, PCI, Serial ATA

People: Jeff Garzik,�Sven K�hler

Jeff Garzik said:

So, finally ATA has joined modern times. People familiar with ATA know the host controller interfaces have always been slow, often requiring 8+ io writes per command. The SCSI and ethernet controller folks have been rolling their eyes for years.

The current wave of SATA controllers make a big leap... into the present. Either DMA rings or queues of depths ~32 are becoming the norm. All very hotplug-friendly, with highly optimized fast paths.

Of course, as is the unfortunate norm in the storage industry, all of these are covered by NDAs, except for Intel's ICH6, which conforms the to the fully-open AHCI specification. In order to support such a controller, all you need are PCI ids, and the following specifications:

AHCI: http://www.intel.com/technology/serialata/pdf/rev1_0.pdf
SATA 1: http://www.serialata.org/collateral/zipdownloads/serialata10a.ZIP
SATA 2: http://www.serialata.org/collateral/pdf/S2Ext_1_1_Gold.pdf
ATA 1: http://www.t13.org/docs2004/d1532v1r4b ATA-ATAPI-7.pdf
ATA 2: http://www.t13.org/docs2004/d1532v1r4b ATA-ATAPI-7.pdf
ATA 3: http://www.t13.org/docs2004/d1532v1r4b ATA-ATAPI-7.pdf

In addition to being an open architecture, it has all the things you would expect of a modern controller: 64-bit DMA support everywhere (no bank switching), queueing support, trivial PIO and ATAPI support, access to the low-level SATA FIS, and more.

So kudos to the AHCI folks (mainly at Intel), for making a decent, open controller. I always prefer to work on drivers for decent hardware, whose hardware specification is open and public.

Sven K�hler replied, "seems like SiS is going to use AHCI too: http://www.sis.com/products/chipsets/oa/athlon64/756Presentation.pdf"

8. Linux 2.6.6-rc2-mm2 Released

26�Apr�2004�-�27�Apr�2004 (26 posts) Archive Link: "2.6.6-rc2-mm2"

Topics: FS: ReiserFS, FS: ext3, Framebuffer, Hot-Plugging, Kernel Release Announcement

People: Andrew Morton

Andrew Morton announced 2.6.6-rc2-mm2, saying:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.6-rc2/2.6.6-rc2-mm2/

9. LinuxAnt Deceptive In License Reporting

26�Apr�2004 (2 posts) Archive Link: "hsf modem drivers lying about their license"

Topics: Modems

People: Jon DeVree,�Chris Friesen

Jon DeVree reported:

Someone needs to take a look at the MODULE_LICENSE string reported by the HSF modem drivers made by LinuxAnt.

http://www.linuxant.com/drivers/hsf/full/downloads.php

They creatively inserted a \0 character in it. MODULE_LICENSE("GPL\0for files in the \"GPL\" directory; for others, only LICENSE file applies");

Runnning modinfo -F license on the compiled driver gives: GPL because of their creative null character. The actual license for most of the files is NOT GPL.

Chris Friesen remarked, "Ewww...that's evil. Maybe we need to store the size of the license string for modinfo, so it doesn't stop at the first null?"

10. Linux 2.6.6-rc3 Released

27�Apr�2004 (1 post) Archive Link: "Linux 2.6.6-rc3"

Topics: Digital Video Broadcasting, Kernel Release Announcement, USB

People: Linus Torvalds

Linus Torvalds announced 2.6.6-rc3, saying:

s390, cifs, ntfs, ppc, ppc64, cpufreq upates. Oh, and DVB and USB.

I'm hoping to do a final 2.6.6 later this week, so I'm hoping as many people as possible will test this.

�

�

�

�

�

�

Sharon And Joy
�

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