27 Aug, 2005

17 commits

  • This patch fixes several instances of hwmon drivers kfree'ing the "wrong"
    pointer; the existing code works somewhat by accident.

    (akpm: plucked from Greg's queue based on lkml discussion. Finishes off the
    patch from Jon Corbet)

    Signed-off-by: Mark M. Hoffman
    Signed-off-by: Jean Delvare
    Signed-off-by: Greg Kroah-Hartman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mark M. Hoffman
     
  • I recently had a BUG_ON() go off spuriously on a gcc 4.0 compiled kernel.
    It turns out gcc-4.0 was removing a sign extension while earlier gcc
    versions would not. Thinking this to be a compiler bug, I submitted a
    report:

    http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23422

    It turns out we need to cast the input in order to tell gcc to sign extend
    it.

    Thanks to Andrew Pinski for his help on this bug.

    Signed-off-by: Anton Blanchard
    Cc: Paul Mackerras
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Anton Blanchard
     
  • At the suggestion of Nick Piggin and Dinakar, totally disable
    the facility to allow cpu_exclusive cpusets to define dynamic
    sched domains in Linux 2.6.13, in order to avoid problems
    first reported by John Hawkes (corrupt sched data structures
    and kernel oops).

    This has been built for ppc64, i386, ia64, x86_64, sparc, alpha.
    It has been built, booted and tested for cpuset functionality
    on an SN2 (ia64).

    Dinakar or Nick - could you verify that it for sure does avoid
    the problems Hawkes reported. Hawkes is out of town, and I don't
    have the recipe to reproduce what he found.

    Signed-off-by: Paul Jackson
    Acked-by: Nick Piggin
    Signed-off-by: Linus Torvalds

    Paul Jackson
     
  • The partial disabling of Dinakar's new facility to allow
    cpu_exclusive cpusets to define dynamic sched domains
    doesn't go far enough. At the suggestion of Nick Piggin
    and Dinakar, let us instead totally disable this facility
    for 2.6.13, in order to avoid problems first reported
    by John Hawkes (corrupt sched data structures and kernel oops).

    This patch removes the partial disabling code in 2.6.13-rc7,
    in anticipation of the next patch, which will totally disable
    it instead.

    Signed-off-by: Paul Jackson
    Signed-off-by: Linus Torvalds

    Paul Jackson
     
  • Linus Torvalds
     
  • Coverity uncovered an off-by-one error in the fscpos driver, in function
    set_temp_reset(). Writing to the temp3_reset sysfs file will lead to an
    array overrun, in turn causing an I2C write to a random register of the
    FSC Poseidon chip. Additionally, writing to temp1_reset and temp2_reset
    will not work as expected. The fix is straightforward.

    Signed-off-by: Jean Delvare
    Signed-off-by: Linus Torvalds

    Jean Delvare
     
  • Be more precise on deciding whether to call m8xx_ide_init() at
    m8xx_setup.c:platform_init().

    Compilation fails if CONFIG_BLK_DEV_IDE is defined but
    CONFIG_BLK_DEV_MPC8xx_IDE isnt.

    Signed-off-by: Marcelo Tosatti
    Signed-off-by: Linus Torvalds

    Marcelo Tosatti
     
  • spinlock used in irq handler should be initialized before registering
    irq, even if we know that our device has interrupts disabled; handler
    is registered shared and taking spinlock is done unconditionally. As
    it is, we can and do get oopsen on boot for some configuration, depending
    on irq routing - I've got a reproducer.

    Signed-off-by: Al Viro
    Signed-off-by: Ben Collins
    Signed-off-by: Linus Torvalds

    Al Viro
     
  • In qdio_get_micros() volatile in return type is plain noise (even with old
    gccisms it would make no sense - noreturn function returning __u64 is a
    bit odd ;-)

    Signed-off-by: Al Viro
    Signed-off-by: Linus Torvalds

    Al Viro
     
  • Dumb typo: iounmap(&local_pointer_variable).

    Signed-off-by: Al Viro
    Signed-off-by: Linus Torvalds

    Al Viro
     
  • The adm9240 driver, in adm9240_detect(), allocates a structure. The
    error path attempts to kfree() ->client field of it (second one),
    resulting in an oops (or slab corruption) if the hardware is not present.

    ->client field in adm1026, adm1031, smsc47b397 and smsc47m1 is the first in
    ${HWMON}_data structure, but fix them too.

    Signed-off-by: Jonathan Corbet
    Signed-off-by: Linus Torvalds

    Alexey Dobriyan
     
  • The recent change to locks_remove_flock code in fs/locks.c changes how
    byte range locks are removed from closing files, which shows up a bug in
    cifs.

    The assumption in the cifs code was that the close call sent to the
    server would remove any pending locks on the server on this file, but
    that is no longer safe as the fs/locks.c code on the client wants unlock
    of 0 to PATH_MAX to remove all locks (at least from this client, it is
    not possible AFAIK to remove all locks from other clients made to the
    server copy of the file).

    Note that cifs locks are different from posix locks - and it is not
    possible to map posix locks perfectly on the wire yet, due to
    restrictions of the cifs network protocol, even to Samba without adding
    a new request type to the network protocol (which we plan to do for
    Samba 3.0.21 within a few months), but the local client will have the
    correct, posix view, of the lock in most cases.

    The correct fix for cifs for this would involve a bigger change than I
    would like to do this late in the 2.6.13-rc cycle - and would involve
    cifs keeping track of all unmerged (uncoalesced) byte range locks for
    each remote inode and scanning that list to remove locks that intersect
    or fall wholly within the range - locks that intersect may have to be
    reaquired with the smaller, remaining range.

    Signed-off-by: Steve French
    Signed-off-by: Dave Kleikamp
    Signed-off-by: Linus Torvalds

    Steve French
     
  • While touching this code I noticed the error handling is bogus, so I
    fixed it up.

    I've removed the IS_ERR(proc_dentry) check, which will never trigger and
    is clearly a typo: we must check proc_file instead.

    Signed-off-by: Paolo 'Blaisorblade' Giarrusso
    Signed-off-by: Linus Torvalds

    Paolo 'Blaisorblade' Giarrusso
     
  • Update hppfs for the symlink functions prototype change.

    Yes, I know the code I leave there is still _bogus_, see next patch for
    this.

    Signed-off-by: Paolo 'Blaisorblade' Giarrusso
    Signed-off-by: Linus Torvalds

    Paolo 'Blaisorblade' Giarrusso
     
  • There is an off by one problem with idr_get_new_above.

    The comment and function name suggest that it will return an id >
    starting_id, but it actually returned an id >= starting_id, and kernel
    callers other than inotify treated it as such.

    The patch below fixes the comment, and fixes inotifys usage. The
    function name still doesn't match the behaviour, but it never did.

    Signed-off-by: John McCutchan
    Signed-off-by: Linus Torvalds

    John McCutchan
     
  • Writing even a disabled value seems to mess up some matrox graphics
    cards. It may be a card-related issue, but we may also be writing
    reserved low bits in the result.

    This was a fall-out of switching x86 over to the generic PCI resource
    allocation code, and needs more debugging. In particular, the old x86
    code defaulted to not doing any resource allocations at all for ROM
    resources.

    In the meantime, this has been reported to make X happier by Helge
    Hafting .

    Signed-off-by: Linus Torvalds

    Linus Torvalds
     
  • It may seem small, but most cards need much less, if any, and this not
    only makes the code adhere to the comment, it seems to fix a boot-time
    lockup on a ThinkPad 380XD laptop reported by Tero Roponen

    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

26 Aug, 2005

1 commit

  • The tg3_abort_hw() call in tg3_test_loopback() is causing lockups on
    some devices. tg3_abort_hw() disables the memory arbiter, causing
    tg3_reset_hw() to hang when it tries to write the pre-reset signature.
    tg3_abort_hw() should only be called after the pre-reset signature has
    been written. This is all done in tg3_reset_hw() so the tg3_abort_hw()
    call is unnecessary and can be removed.

    [ Also bump driver version and release date. -DaveM ]

    Signed-off-by: Michael Chan
    Signed-off-by: David S. Miller

    Michael Chan
     

25 Aug, 2005

6 commits

  • One critical fix and two minor fixes for 2.6.13-rc7:

    - Max depth must currently be 2 to allow barriers to function on SCSI
    - Prefer sync request over async in choosing the next request
    - Never allow async request to preempt or disturb the "anticipation" for
    a single cfq process context. This is as-designed, the code right now
    is buggy in that area.

    Signed-off-by: Jens Axboe
    Signed-off-by: Linus Torvalds

    Jens Axboe
     
  • pcibios_bus_to_resource is exported on all architectures except ia64
    and sparc. Add exports for the two missing architectures. Needed when
    Yenta socket support is compiled as a module.

    Signed-off-by: Keith Owens
    Signed-off-by: Linus Torvalds

    Keith Owens
     
  • I mistakedly disabled fusion support in an earlier update. Fusion
    is commonly used on many x86-64 systems, so this was a problem.
    This patch fixes that.

    Signed-off-by: And Kleen
    Signed-off-by: Linus Torvalds

    Andi Kleen
     
  • This patch puts back the export of machine_power_off() that was removed
    by some janitor as it's used for emergency shutdown by the G5 thermal
    control driver. Wether that driver should use kernel_power_off() instead
    is debatable and a post-2.6.13 decision. In the meantime, please commit
    that patch that fixes the driver for now.

    Signed-off-by: Benjamin Herrenschmidt
    Signed-off-by: Linus Torvalds

    Benjamin Herrenschmidt
     
  • As reported by Paul Mackerras , the previous patch
    "cpu_exclusive sched domains fix" broke the ppc64 build with
    CONFIC_CPUSET, yielding error messages:

    kernel/cpuset.c: In function 'update_cpu_domains':
    kernel/cpuset.c:648: error: invalid lvalue in unary '&'
    kernel/cpuset.c:648: error: invalid lvalue in unary '&'

    On some arch's, the node_to_cpumask() is a function, returning
    a cpumask_t. But the for_each_cpu_mask() requires an lvalue mask.

    The following patch fixes this build failure by making a copy
    of the cpumask_t on the stack.

    Signed-off-by: Paul Jackson
    Signed-off-by: Linus Torvalds

    Paul Jackson
     
  • Add parens around macro parameters.

    Signed-off-by: Andreas Schwab
    Signed-off-by: Linus Torvalds

    Andreas Schwab
     

24 Aug, 2005

16 commits