Kernel Traffic #262 by Zack Brown

                        Kernel Traffic #262 For 11 Jun 

                                 By Zack Brown

Table Of Contents

  * Standard Format
  * Text Format
  * XML Source
  * Mailing List Stats For This Week
  * Threads Covered

    1.  9 Apr  - 25 Apr   (16     sym53c500_cs PCMCIA SCSI Driver Released
                          posts)
    2.  19 Apr  - 27 Apr  (12     Per-User Signal-Pending And Message-Queue
                          posts)  Limits In 2.6 And 2.4
    3.  19 Apr  - 27 Apr  (11     Crypto CRC32C Module
                          posts)
    4.  21 Apr  - 26 Apr  (11     Status Of IDE Module Unloading; IDE And
                          posts)  libata
    5.  22 Apr  - 25 Apr  (5      Linux 2.4.27-pre1 Released
                          posts)
    6.  25 Apr  - 26 Apr  (2      SiS Driver Fixes
                          posts)
    7.  25 Apr            (2      AHCI Driver; Open Hardware Specifications
                          posts)
    8.  26 Apr  - 27 Apr  (26     Linux 2.6.6-rc2-mm2 Released
                          posts)
    9.  26 Apr            (2      LinuxAnt Deceptive In License Reporting
                          posts)
    10. 27 Apr            (1      Linux 2.6.6-rc3 Released
                          post)

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:

  * 24 posts in 112K by Andrew Morton
  * 21 posts in 151K by Andreas Gruenbacher
  * 21 posts in 95K by Len Brown
  * 20 posts in 66K by Greg KH
  * 17 posts in 51K by Pavel Machek
  * Full Stats

 

1. sym53c500_cs PCMCIA SCSI Driver Released
9 Apr  - 25 Apr  (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  - 27 Apr  (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:

      + Create per-user signal limits, remove global limit
      + Create per-user message queue limits, accounting is now done on
        memory-allocated (queue creation and message allocation). Note: it
        might be nice to move deaccounting inside free_msg().

    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  - 27 Apr  (11 posts) Archive Link: "[PATCH] crypto/crc32c
implementation, updated 040419"
People: Clay Haapala, David S. Miller, James Morris

Clay Haapala said, "This patch against 2.6.6-rc1-bk implements the CRC32C
algorithm (http://www.haifa.il.ibm.com/satran/ips/Vince-Luben-crc32c-01.pdf) 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  - 26 Apr  (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, 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  - 25 Apr  (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  - 26 Apr  (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  (2 posts) Archive Link: "[sata] new driver -- AHCI"
Topics: Disks: IDE, Disks: SCSI, Hot-Plugging, Networking, 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  - 27 Apr  (26 posts) Archive Link: "2.6.6-rc2-mm2"
Topics: FS: ReiserFS, FS: ext3, Framebuffer, Hot-Plugging
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/

      + Largeish reiserfs feature update. The biggest change is probably the
        new block allocation algorithm. See the changelog inside
        reiserfs-group-alloc-9.patch for details.
      + Added the ia64 CPU hotplug support patch
      + More work against the ext3 block allocator.
      + Several more framebuffer driver update, some quite substantial.
      + Lots of fixes, mostly minor.

 

9. LinuxAnt Deceptive In License Reporting
26 Apr  (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  (1 post) Archive Link: "Linux 2.6.6-rc3"
Topics: 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.

 

 

 

 

 

 

                       We Hope You Enjoy Kernel Traffic
                                        

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.