17 Apr, 2005

40 commits

  • These have been deprecated since ->compat_ioctl when in, thus only a short
    deprecation period. There's four users left: i2o_config, s390/z90crypy,
    s390/dasd and s390/zfcp and for the first two patches are about to be
    submitted to get rid of it.

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

    Christoph Hellwig
     
  • Now that no architectures defines HAVE_ARCH_GET_SIGNAL_TO_DELIVER anymore
    this can go away. It was a transitional hack only.

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

    Christoph Hellwig
     
  • Don't put root block of quota tree to the free list (when quota file is
    completely empty). That should not actually happen anyway (somebody should
    get accounted for the filesystem root and so quota file should never be
    empty) but better prevent it here than solve magical quota file
    corruption.

    Signed-off-by: Jan Kara
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Niu YaWei
     
  • Remove dquot structures from quota file on quotaon - quota code does not
    expect them to be there.

    Signed-off-by: Jan Kara
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jan Kara
     
  • Whilst trying to stress test a Promise SX8 card, we stumbled across
    some nasty filesystem corruption in ext2. Our tests involved
    creating an ext2 partition, mounting, running several concurrent
    fsx's over it, umounting, and fsck'ing, all scripted[1]. The fsck
    would always return with errors.

    This regression was traced back to a change between 2.6.9 and
    2.6.10, which moves the functionality of ext2_put_inode into
    ext2_clear_inode. The attached patch reverses this change, and
    eliminated the source of corruption.

    Mingming Cao said:

    I think his patch for ext2 is correct. The corruption on ext3 is not the same
    issue he saw on ext2. I believe that's the race between discard reservation
    and reservation in-use that we already fixed it in 2.6.12- rc1.

    For the problem related to ext2, at the time when we design reservation for
    ext3, we decide we only need to discard the reservation at the last file
    close, so we have ext3_discard_reservation on iput_final- >ext3_clear_inode.

    The ext2 handle discard preallocation differently at that time, it discard the
    preallocation at each iput(), not in input_final(), so we think it's
    unnecessary to thrash it so frequently, and the right thing to do, as we did
    for ext3 reservation, discard preallocation on last iput(). So we moved the
    ext2_discard_preallocation from ext2_put_inode(0 to ext2_clear_inode.

    Since ext2 preallocation is doing pre-allocation on disk, so it is possible
    that at the unmount time, someone is still hold the reference of the inode, so
    the preallocation for a file is not discard yet, so we still mark those blocks
    allocated on disk, while they are not actually in the inode's block map, so
    fsck will catch/fix that error later.

    This is not a issue for ext3, as ext3 reservation(pre-allocation) is done in
    memory.

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

    Bernard Blackham
     
  • - plug various leaks and use after frees in the remove and
    initialization failure path (some still left)
    - remove useless global list of boards and use pci_set_drvdata instead
    - unobsfucate init path by merging functions together
    - kill various totally useless state variables
    - .. probably more I forgot

    Note that the tty part still generates lots of sparse warnings and there's
    still a totally useless layer of function pointer indirections, but maybe
    someone else will fix that bit up.

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

    Christoph Hellwig
     
  • In function __generic_unplug_device(), kernel can use a cheaper function
    elv_queue_empty() instead of more expensive elv_next_request to find
    whether the queue is empty or not. blk_run_queue can also made conditional
    on whether queue's emptiness before calling request_fn().

    Signed-off-by: Jens Axboe
    Signed-off-by: Ken Chen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ken Chen
     
  • This patch fix 3 calls to module_param_string() in
    driver/media/video/tuner-core.c and drivers/media/video/tda9887.c. In all
    three places, the len and the perm parameter was switched.

    Signed-off-by: Bert Wesarg
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Bert Wesarg
     
  • there seems to be a bug, at least for me, in kernel/param.c for arrays with
    .num == NULL. If .num == NULL, the function param_array_set() uses &.max
    for the call to param_array(), wich alters the .max value to the number of
    arguments. The result is, you can't set more array arguments as the last
    time you set the parameter.

    example:

    # a module 'example' with
    # static int array[10] = { 0, };
    # module_param_array(array, int, NULL, 0644);

    $ insmod example.ko array=1,2,3
    $ cat /sys/module/example/parameters/array
    1,2,3
    $ echo "4,3,2,1" > /sys/module/example/parameters/array
    $ dmesg | tail -n 1
    kernel: array: can take only 3 arguments

    Signed-off-by: Bert Wesarg
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Bert Wesarg
     
  • A question on sigwaitinfo based IO mechanism in multithreaded applications.

    I am trying to use RT signals to notify me of IO events using RT signals
    instead of SIGIO in a multithreaded applications. I noticed that there was
    some discussion on lkml during november 1999 with the subject of the
    discussion as "Signal driven IO". In the thread I noticed that RT signals
    were being delivered to the worker thread. I am running 2.6.10 kernel and
    I am trying to use the very same mechanism and I find that only SIGIO being
    propogated to the worker threads and RT signals only being propogated to
    the main thread and not the worker threads where I actually want them to be
    propogated too. On further inspection I found that the following patch
    which I have attached solves the problem.

    I am not sure if this is a bug or feature in the kernel.

    Roland McGrath said:

    This relates only to fcntl F_SETSIG, which is a Linux extension. So there is
    no POSIX issue. When changing various things like the normal SIGIO signalling
    to do group signals, I was concerned strictly with the POSIX semantics and
    generally avoided touching things in the domain of Linux inventions. That's
    why I didn't change this when I changed the call right next to it. There is
    no reason I can see that F_SETSIG-requested signals shouldn't use a group
    signal like normal SIGIO does. I'm happy to ACK this patch, there is nothing
    wrong with its change to the semantics in my book. But neither POSIX nor I
    care a whit what F_SETSIG does.

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

    Bharath Ramesh
     
  • There is a possibility that a bio will be accessed after it has been freed
    on SCSI. It happens if you submit a bio with BIO_SYNC marked and the
    auto-unplugging kicks the request_fn, SCSI re-enables interrupts in-between
    so if the request completes between the add_request() in __make_request()
    and the bio_sync() call, we could be looking at a dead bio. It's a slim
    race, but it has been triggered in the Real World.

    So assign bio_sync() to a local variable instead.

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

    Jens Axboe
     
  • I had added the __CHOOSE_MODE syntax to fix some warnings with newer GCC's
    in the uml-fix-cond-expr-as-lvalues-warning patch.

    Here is the update from the version I sent to make it work also when only
    one mode (TT or SKAS) is enabled.

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

    Paolo 'Blaisorblade' Giarrusso
     
  • Fix some smp_processor_id-in-preemptible warnings

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

    Alexander Nyberg
     
  • This fixes remaining u32 vs. pm_message_t confusions in -rc2-mm3. [There
    are usb changes, too; they went to Greg on his request.]

    Signed-off-by: Pavel Machek
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Pavel Machek
     
  • This fixes u32 vs. pm_message_t confusion in remaining places. Fortunately
    there's few of them.

    Signed-off-by: Pavel Machek
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Pavel Machek
     
  • This fixes u32 vs. pm_message_t confusion in drivers/video. Should change no
    code.

    Signed-off-by: Pavel Machek
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Pavel Machek
     
  • -rc2-mm1 still contains few places where u32 and pm_message_t. This fixes
    drivers/serial [should change no code].

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

    Pavel Machek
     
  • This updates video.txt documentation with information about few more
    systems.

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

    Pavel Machek
     
  • This fixes pm_message_t vs. u32 confusion in ppc and aty (I *hope* that's
    basically radeon code...). I was not able to test most of these, but I'm
    not really changing anything, so it should be okay.

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

    Pavel Machek
     
  • This fixes drivers/pci (mostly pcie stuff).

    Signed-off-by: Pavel Machek
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Pavel Machek
     
  • I thought I'm done with fixing u32 vs. pm_message_t ... unfortunately that
    turned out not to be the case as Russel King pointed out. Here are fixes for
    drivers/macintosh.

    Signed-off-by: Pavel Machek
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Pavel Machek
     
  • I thought I'm done with fixing u32 vs. pm_message_t ... unfortunately that
    turned out not to be the case... Here are fixes x86-64.

    Signed-off-by: Pavel Machek
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Pavel Machek
     
  • I thought I'm done with fixing u32 vs. pm_message_t ... unfortunately that
    turned out not to be the case as Russel King pointed out. This fixes last few
    bits in alsa.

    Signed-off-by: Pavel Machek
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Pavel Machek
     
  • This fixes u32 vs. pm_message_t in drivers/mmc, drivers/mtd and
    drivers/scsi.

    Signed-off-by: Pavel Machek
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Pavel Machek
     
  • This fixes u32 vs. pm_message_t in drivers/message.

    Signed-off-by: Pavel Machek
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Pavel Machek
     
  • Here are fixes for drivers/media.

    Signed-off-by: Pavel Machek
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Pavel Machek
     
  • This fixes u32 vs. pm_message_t in pcmcia.

    Signed-off-by: Pavel Machek
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Pavel Machek
     
  • This fixes remaining u32s in drivers/ net.

    Signed-off-by: Pavel Machek
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Pavel Machek
     
  • Here are fixes for drivers/char.

    Signed-off-by: Pavel Machek
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Pavel Machek
     
  • I thought I'm done with fixing u32 vs. pm_message_t ... unfortunately
    that turned out not to be the case as Russel King pointed out. Here are
    fixes for Documentation and common code (mainly system devices).

    Signed-off-by: Pavel Machek
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Pavel Machek
     
  • - page.h: fix build error
    - unistd.h: _syscall macro cleanup.

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

    Yoshinori Sato
     
  • - broken sibling_map setup in x86_64

    - grouping all the core and HT related cpuinfo fields.
    We are reasonably sure that adding new cpuinfo fields after "siblings" field,
    will not cause any app failure. Thats because today's /proc/cpuinfo
    format is completely different on x86, x86_64 and we haven't heard of any
    x86 app breakage because of this issue. Grouping these fields will
    result in more or less common format on all architectures (ia64, x86 and
    x86_64) and will cause less confusion.

    Signed-off-by: Suresh Siddha
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Siddha, Suresh B
     
  • This will allow hotplug CPU in the future and in general cleans up a lot of
    crufty code. It also should plug some races that the old hackish way
    introduces. Remove one old race workaround in NMI watchdog setup that is not
    needed anymore.

    I removed the old total sum of bogomips reporting code. The brag value of
    BogoMips has been greatly devalued in the last years on the open market.

    Real CPU hotplug will need some more work, but the infrastructure for it is
    there now.

    One drawback: the new TSC sync algorithm is less accurate than before. The
    old way of zeroing TSCs is too intrusive to do later. Instead the TSC of the
    BP is duplicated now, which is less accurate.

    akpm:

    - sync_tsc_bp_init seems to have the sense of `init' inverted.

    - SPIN_LOCK_UNLOCKED is deprecated - use DEFINE_SPINLOCK.

    Cc:
    Cc:
    Signed-off-by: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andi Kleen
     
  • It was confusingly named.

    Signed-off-by: Andi Kleen
    DESC
    x86_64: Switch SMP bootup over to new CPU hotplug state machine
    EDESC
    From: "Andi Kleen"

    This will allow hotplug CPU in the future and in general cleans up a lot of
    crufty code. It also should plug some races that the old hackish way
    introduces. Remove one old race workaround in NMI watchdog setup that is not
    needed anymore.

    I removed the old total sum of bogomips reporting code. The brag value of
    BogoMips has been greatly devalued in the last years on the open market.

    Real CPU hotplug will need some more work, but the infrastructure for it is
    there now.

    One drawback: the new TSC sync algorithm is less accurate than before. The
    old way of zeroing TSCs is too intrusive to do later. Instead the TSC of the
    BP is duplicated now, which is less accurate.

    Cc:
    Cc:
    Signed-off-by: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andi Kleen
     
  • Add acpi_skip_timer_override option. It was missing previously.

    Signed-off-by: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andi Kleen
     
  • Exceptions and hardware interrupts can, to a certain degree, nest, so when
    attempting to follow the sequence of stacks used in order to dump their
    contents this has to be accounted for. Also, IST stacks have their tops
    stored in the TSS, so there's no need to add the stack size to get to their
    ends.

    Minor changes from AK.

    Signed-off-by: Jan Beulich
    Signed-off-by: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andi Kleen
     
  • Clean up the code greatly. Now uses the infrastructure from the Intel dual
    core patch Should fix a final bug noticed by Tyan of not detecting the nodes
    correctly in some corner cases.

    Patch for x86-64 and i386

    Signed-off-by: Andi Kleen
    Signed-off-by: Rafael J. Wysocki
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andi Kleen
     
  • Appended patch adds the support for Intel dual-core detection and displaying
    the core related information in /proc/cpuinfo.

    It adds two new fields "core id" and "cpu cores" to x86 /proc/cpuinfo and the
    "core id" field for x86_64("cpu cores" field is already present in x86_64).

    Number of processor cores in a die is detected using cpuid(4) and this is
    documented in IA-32 Intel Architecture Software Developer's Manual (vol 2a)
    (http://developer.intel.com/design/pentium4/manuals/index_new.htm#sdm_vol2a)

    This patch also adds cpu_core_map similar to cpu_sibling_map.

    Slightly hacked by AK.

    Signed-off-by: Suresh Siddha
    Signed-off-by: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andi Kleen
     
  • Signed-off-by: Paolo 'Blaisorblade' Giarrusso
    Signed-off-by: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andi Kleen
     
  • Calling a notifier three times in the debug handler does not make much sense,
    because a debugger can figure out the various conditions by itself. Remove
    the additional calls to DIE_DEBUG and DIE_DEBUGSTEP completely.

    This matches what i386 does now.

    This also makes sure interrupts are always still disabled when calling a
    debugger, which prevents:

    BUG: using smp_processor_id() in preemptible [00000001] code: tpopf/1470
    caller is post_kprobe_handler+0x9/0x70

    Call Trace:{smp_processor_id+191} {post_kpro
    be_handler+9}
    {kprobe_exceptions_notify+58}
    {notifier_call_chain+32} {do_debug+335}
    {debug+127}

    on preemptible debug kernels with kprobes when single stepping in user space.

    This was probably a bug even on non preempt kernels, this function was
    supposed to be running with interrupts off according to a comment there.

    Note to third part debugger maintainers: please double check your debugger can
    still single step.

    Cc:
    Cc:
    Cc:
    Cc:
    Cc:
    Signed-off-by: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andi Kleen