01 Jul, 2006

1 commit


22 Jun, 2006

1 commit

  • Like the SUBSYTEM= key we find in the environment of the uevent, this
    creates a generic "subsystem" link in sysfs for every device. Userspace
    usually doesn't care at all if its a "class" or a "bus" device. This
    provides an unified way to determine the subsytem of a device, regardless
    of the way the driver core has created it.

    Signed-off-by: Kay Sievers
    Signed-off-by: Greg Kroah-Hartman

    Kay Sievers
     

13 May, 2006

1 commit

  • This reverts commit 56cf6504fc1c0c221b82cebc16a444b684140fb7.

    Both Erik Mouw and Andrew Vasquez independently pinpointed this commit
    as causing problems, where the slab cache for a driver is never released
    (most obviously causing problems when immediately re-loading that
    driver, resulting in a "kmem_cache_create: duplicate cache "
    message, but it can also cause other trouble).

    James Bottomley dug into it, and reports:

    "OK, here's the scoop. The problem patch adds a get of driverfs_dev in
    add_disk(), but doesn't put it again until disk_release() (which occurs
    on final put_disk() of the gendisk).

    However, in SCSI, the driverfs_dev is the sdev_gendev. That means
    there's a reference held on sdev_gendev until final disk put.
    Unfortunately, we use the driver model driver_remove to trigger
    del_gendisk (which removes the gendisk from visibility and decrements
    the refcount), so we've introduced an unbreakable deadlock in the
    reference counting with this.

    I suggest simply reversing this patch at the moment. If Russell and
    Jens can tell me what they're trying to do I'll see if there's another
    way to do it."

    so hereby the patch gets reverted, waiting for a better fix.

    Cc: Jens Axboe
    Cc: Russell King
    Cc: James Bottomley
    Cc: Erik Mouw
    Cc: Andrew Vasquez
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

06 May, 2006

1 commit

  • The block layer keeps a reference (driverfs_dev) to the struct
    device associated with the block device, and uses it internally
    for generating uevents in block_uevent.

    Block device uevents include umounting the partition, which can
    occur after the backing device has been removed.

    Unfortunately, this reference is not counted. This means that
    if the struct device is removed from the device tree, the block
    layers reference will become stale.

    Guard against this by holding a reference to the struct device
    in add_disk(), and only drop the reference when we're releasing
    the gendisk kobject - in other words when we can be sure that no
    further uevents will be generated for this block device.

    Signed-off-by: Russell King
    Acked-by: Jens Axboe

    Russell King
     

01 Apr, 2006

1 commit

  • Make baby-simple the code for /proc/devices. Based on the proven design
    for /proc/interrupts.

    This also fixes the early-termination regression 2.6.16 introduced, as
    demonstrated by:

    # dd if=/proc/devices bs=1
    Character devices:
    1 mem
    27+0 records in
    27+0 records out

    This should also work (but is untested) when /proc/devices >4096 bytes,
    which I believe is what the original 2.6.16 rewrite fixed.

    [akpm@osdl.org: cleanups, simplifications]
    Signed-off-by: Joe Korty
    Cc: Neil Horman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Joe Korty
     

27 Mar, 2006

1 commit

  • The kernel's representation of the disk statistics uses the type unsigned
    which is 32b on both 32b and 64b platforms. Unfortunately, most system
    tools that work with these numbers that are exported in /proc/diskstats
    including iostat read these numbers into unsigned longs. This works fine
    on 32b platforms and when the number of IO transactions are small on 64b
    platforms. However, when the numbers wrap on 64b platforms & you read the
    numbers into unsigned longs, and compare the numbers to previous readings,
    then you get an unsigned representation of a negative number. This looks
    like a very large 64b number & gives you bizarre readouts in iostat:

    ilc4: Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
    ilc4: sda 5.50 0.00 143.96 0.00 307496983987862656.00 0.00 153748491993931328.00 0.00 2136028725038430.00 7.94 55.12 5.59 80.42

    Though fixing iostat in user space is possible, and a quick survey
    indicates that several other similar tools also use unsigned longs when
    processing /proc/diskstats. Therefore, it seems like a better approach
    would be to extend the length of the disk_stats structure on 64b
    architectures to 64b. The following patch does that. It should not affect
    the operation on 32b platforms.

    Signed-off-by: Ben Woodard
    Cc: Rick Lindsley
    Signed-off-by: Andrew Morton
    Signed-off-by: Jens Axboe

    Ben Woodard
     

21 Mar, 2006

1 commit


15 Jan, 2006

1 commit

  • A Christoph suggested that the /proc/devices file be converted to use the
    seq_file interface. This patch does that.

    I've obxerved one or two installation that had sufficiently large sans that
    they overran the 4k limit on /proc/devices.

    Signed-off-by: Neil Horman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Neil Horman
     

05 Jan, 2006

1 commit


12 Nov, 2005

1 commit


04 Nov, 2005

1 commit