1. 06 Feb, 2003 40 commits
    • Frank Davis's avatar
      [PATCH] 2.5.59 : drivers/media/video/bt819.c · 8673d7da
      Frank Davis authored
      This patch for bt819.c addresses buzilla bug #169 (compile error).
      8673d7da
    • Frank Davis's avatar
      [PATCH] 2.5.59 : drivers/media/video/saa7185.c · 06abcac6
      Frank Davis authored
      This patch to saa7185 to resolves buzilla bug #168 (compile error).  It
      has been sent to l-k and has received no objections.
      06abcac6
    • Frank Davis's avatar
      [PATCH] 2.5.59 : drivers/media/video/bt856.c · d41710a0
      Frank Davis authored
      This fixes a bt856.c compile error.  The driver now compiles.  Its a
      straightforward patch and have emailed l-k and no objections have been
      reported.
      d41710a0
    • Christoph Hellwig's avatar
      [PATCH] fix leaks in vxfs_read_fshead() · 24b8c8bc
      Christoph Hellwig authored
      The Stanford checker disclose that vxfs_read_fshead was missing any
      unwinding in the error cases..
      24b8c8bc
    • Andries E. Brouwer's avatar
      [PATCH] Doc fix · 365e2b77
      Andries E. Brouwer authored
      365e2b77
    • Andries E. Brouwer's avatar
      [PATCH] Remove dead code · 6b932555
      Andries E. Brouwer authored
      In struct char_dev the fields openers and sem are unused.
      The file char_dev.c claims that it is called differently.
      6b932555
    • Andrew Morton's avatar
      [PATCH] revert extra sendfile security hook patch · 1dbb976e
      Andrew Morton authored
      hm.  It seems that I sent this patch twice.
      
      After resyncing with your tree I go through and try to reapply all the sent
      patches, throwing out the ones which get a lot of rejects.  Just to make sure
      that everything got through OK.
      
      But it appears that that particular patch happily applied on top of itself,
      so I assumed it was not applied...
      1dbb976e
    • Roland McGrath's avatar
      [PATCH] Make sys_wait4() more readable · 202b74eb
      Roland McGrath authored
      I cleaned up sys_wait4; it was straightforward and I think a definite
      improvement.  While at it, I noticed that one of the races I fixed in the
      TASK_STOPPED case actually can happen earlier.  Between read_unlock and
      write_lock_irq, another thread could reap the process and make P invalid,
      so now I do get_task_struct before read_unlock and then the existing race
      checks catch all scenarios.
      
      Aside from the aforementioned race tweak, the code should be the same as
      in the previous patch (that Ingo and I have tested more thoroughly)
      modulo being moved into functions and some reformatting and comment
      changes.
      
      Oh, my old patch had one case where it failed to retake the read lock after
      a race bailout that I just noticed reading over it.  That's fixed too.
      
      These exit fixes were something I noticed incidentally and spent less time
      on than the signals changes.  Another few passes of eyeballs over them are
      certainly warranted.  (In particular, there are code paths like that one
      that check for specific races that have probably never been seen in
      practice, so those code paths have never run once.)
      202b74eb
    • Steven Cole's avatar
      [PATCH] Spelling fixes · 477c16ff
      Steven Cole authored
      OK, here is the diff against 2.5.59-bk2, now up to 880 lines due to an
      additional misspelling which crept in the -bk2 snapshot.
      
      Fixes 'seperate' -> 'separate' and 'definate' -> 'definite'.
      
      Kernal codrs cna't spel.
      477c16ff
    • Matthew Dobson's avatar
      [PATCH] Broken CLEAR_BITMAP() macro · ea4e0b5b
      Matthew Dobson authored
      The CLEAR_BITMAP() macro in include/linux/types.h is broken and doesn't
      round the bitmap size to the proper 'long' boundary.
      
      This fixes it by creating a macro BITS_TO_LONGS that just rounds a
      number of bits up to the closest number of unsigned longs.  This makes
      the DECLARE & CLEAR _BITMAP macros more readable and fixes the bug.
      ea4e0b5b
    • Mark Haverkamp's avatar
      [PATCH] fix megaraid driver compile error · 3fa327f8
      Mark Haverkamp authored
      This moves access of the host element to device since host has been
      removed from struct scsi_cmnd.
      3fa327f8
    • Ingo Molnar's avatar
      [PATCH] signal-fixes-2.5.59-A4 · ebf5ebe3
      Ingo Molnar authored
      this is the current threading patchset, which accumulated up during the
      past two weeks. It consists of a biggest set of changes from Roland, to
      make threaded signals work. There were still tons of testcases and
      boundary conditions (mostly in the signal/exit/ptrace area) that we did
      not handle correctly.
      
      Roland's thread-signal semantics/behavior/ptrace fixes:
      
       - fix signal delivery race with do_exit() => signals are re-queued to the
         'process' if do_exit() finds pending unhandled ones. This prevents
         signals getting lost upon thread-sys_exit().
      
       - a non-main thread has died on one processor and gone to TASK_ZOMBIE,
         but before it's gotten to release_task a sys_wait4 on the other
         processor reaps it.  It's only because it's ptraced that this gets
         through eligible_child.  Somewhere in there the main thread is also
         dying so it reparents the child thread to hit that case.  This means
         that there is a race where P might be totally invalid.
      
       - forget_original_parent is not doing the right thing when the group
         leader dies, i.e. reparenting threads to init when there is a zombie
         group leader.  Perhaps it doesn't matter for any practical purpose
         without ptrace, though it makes for ppid=1 for each thread in core
         dumps, which looks funny. Incidentally, SIGCHLD here really should be
         p->exit_signal.
      
       - one of the gdb tests makes a questionable assumption about what kill
         will do when it has some threads stopped by ptrace and others running.
      
      exit races:
      
      1. Processor A is in sys_wait4 case TASK_STOPPED considering task P.
         Processor B is about to resume P and then switch to it.
      
         While A is inside that case block, B starts running P and it clears
         P->exit_code, or takes a pending fatal signal and sets it to a new
         value. Depending on the interleaving, the possible failure modes are:
              a. A gets to its put_user after B has cleared P->exit_code
                 => returns with WIFSTOPPED, WSTOPSIG==0
              b. A gets to its put_user after B has set P->exit_code anew
                 => returns with e.g. WIFSTOPPED, WSTOPSIG==SIGKILL
      
         A can spend an arbitrarily long time in that case block, because
         there's getrusage and put_user that can take page faults, and
         write_lock'ing of the tasklist_lock that can block.  But even if it's
         short the race is there in principle.
      
      2. This is new with NPTL, i.e. CLONE_THREAD.
         Two processors A and B are both in sys_wait4 case TASK_STOPPED
         considering task P.
      
         Both get through their tests and fetches of P->exit_code before either
         gets to P->exit_code = 0.  => two threads return the same pid from
         waitpid.
      
         In other interleavings where one processor gets to its put_user after
         the other has cleared P->exit_code, it's like case 1(a).
      
      
      3. SMP races with stop/cont signals
      
         First, take:
      
              kill(pid, SIGSTOP);
              kill(pid, SIGCONT);
      
         or:
      
              kill(pid, SIGSTOP);
              kill(pid, SIGKILL);
      
         It's possible for this to leave the process stopped with a pending
         SIGCONT/SIGKILL.  That's a state that should never be possible.
         Moreover, kill(pid, SIGKILL) without any repetition should always be
         enough to kill a process.  (Likewise SIGCONT when you know it's
         sequenced after the last stop signal, must be sufficient to resume a
         process.)
      
      4. take:
      
              kill(pid, SIGKILL);     // or any fatal signal
              kill(pid, SIGCONT);     // or SIGKILL
      
          it's possible for this to cause pid to be reaped with status 0
          instead of its true termination status.  The equivalent scenario
          happens when the process being killed is in an _exit call or a
          trap-induced fatal signal before the kills.
      
      plus i've done stability fixes for bugs that popped up during
      beta-testing, and minor tidying of Roland's changes:
      
       - a rare tasklist corruption during exec, causing some very spurious and
         colorful crashes.
      
       - a copy_process()-related dereference of already freed thread structure
         if hit with a SIGKILL in the wrong moment.
      
       - SMP spinlock deadlocks in the signal code
      
      this patchset has been tested quite well in the 2.4 backport of the
      threading changes - and i've done some stresstesting on 2.5.59 SMP as
      well, and did an x86 UP testcompile + testboot as well.
      ebf5ebe3
    • David Jeffery's avatar
      [PATCH] ips driver 4/4: error messages · 44a5a59c
      David Jeffery authored
      This small patch does 2 things.  It reworks the firmware/driver
      versioning messages to make them more understandable, and it
      fixes one case where the 64bit addressing changes caused
      error/success to not be properly reported to the serveraid tools.
      44a5a59c
    • David Jeffery's avatar
      [PATCH] ips driver 3/4: 64bit dma addressing · d31bb16c
      David Jeffery authored
      This large patch adds support for using 64bit addressing.
      
      Special thanks goes to Mike Anderson who did the initial
      versions of this patch.
      d31bb16c
    • David Jeffery's avatar
      [PATCH] ips driver 2/4: initialization reordering · 836f40cb
      David Jeffery authored
      This large patch reworks much of the adapter initialization
      code.
      
      It splits the scsi initialization code from the pci
      initialization.  It adds support for working with some
      future cards.  It also removes the use of multiple pci_driver
      registrations and instead does its own adapter ordering.
      836f40cb
    • David Jeffery's avatar
      [PATCH] ips driver 1/4: fix struct length and remove dead code · 9d252c21
      David Jeffery authored
      This small patch fixes the length of the IPS_ENQ
      struct.  It was too short which can cause the adapter
      to write beyond the the end of the struct during
      driver initialization and corrupt part of memory.
      9d252c21
    • Linus Torvalds's avatar
      Merge http://linux-scsi.bkbits.net/scsi-for-linus-2.5 · bd15d114
      Linus Torvalds authored
      into home.transmeta.com:/home/torvalds/v2.5/linux
      bd15d114
    • James Bottomley's avatar
      Merge raven.il.steeleye.com:/home/jejb/BK/scsi-misc-2.5 · 35766eb7
      James Bottomley authored
      into raven.il.steeleye.com:/home/jejb/BK/scsi-for-linus-2.5
      35766eb7
    • Christoph Hellwig's avatar
      [PATCH] coding style updates for scsi_lib.c · 78ef52ec
      Christoph Hellwig authored
      I just couldn't see the mess anymore..  Nuke the ifdefs and use sane
      variable names.  Some more small nitpicks but no behaviour changes at
      all.
      78ef52ec
    • Rusty Russell's avatar
      [PATCH] 2.5.59 add two help texts to drivers_scsi_Kconfig · baaf76dd
      Rusty Russell authored
      From:  Steven Cole <elenstev@mesatop.com>
      
        Here are some help texts from 2.4.21-pre3 Configure.help which are
        needed in 2.5.59 drivers/scsi/Kconfig.
      
        Steven
      baaf76dd
    • Rusty Russell's avatar
      [PATCH] [patch, 2.5] scsi_qla1280.c free on error path · f8646d20
      Rusty Russell authored
      From:  Marcus Alanen <maalanen@ra.abo.fi>
      
        Remove check_region in favour of request_region. Free resources
        properly on error path. Horribly subtle ioremap/iounmap lurks here I
        think, in qla1280_pci_config(), which the below patch should take care
        of.
      
        I'm wondering if there couldn't / shouldn't be a better way to
        allocate resources. Obviously lots of drivers have broken error paths.
        Is this even necessary?
      
        Marcus
      
      
        #
        # create_patch: qla1280_release_on_error_path-2002-12-08-A.patch
        # Date: Sun Dec  8 22:32:33 EET 2002
        #
      f8646d20
    • Christoph Hellwig's avatar
      [SCSI] Remove host_active · d30a24be
      Christoph Hellwig authored
      It isn't used anywhere anymore
      d30a24be
    • Linus Torvalds's avatar
      Merge http://linux-acpi.bkbits.net/linux-acpi · 26d987a7
      Linus Torvalds authored
      into home.transmeta.com:/home/torvalds/v2.5/linux
      26d987a7
    • Andy Grover's avatar
      ACPI: Enable compilation w/o cpufreq · 32dbc81b
      Andy Grover authored
      32dbc81b
    • Randy Dunlap's avatar
      [PATCH] quota memleak · a2dd1464
      Randy Dunlap authored
      The Stanford Checker found a memleak.
      a2dd1464
    • Linus Torvalds's avatar
      Merge bk://kernel.bkbits.net/vojtech/x86-64 · d0d3f1f0
      Linus Torvalds authored
      into home.transmeta.com:/home/torvalds/v2.5/linux
      d0d3f1f0
    • Vojtech Pavlik's avatar
    • Andrew Morton's avatar
      [PATCH] Fix signed use of i_blocks in ext3 truncate · 9a3e1a96
      Andrew Morton authored
      Patch from "Stephen C. Tweedie" <sct@redhat.com>
      
      Fix "h_buffer_credits<0" assert failure during truncate.
      
      The bug occurs when the "i_blocks" count in the file's inode overflows
      past 2^31.  That works fine most of the time, because i_blocks is an
      unsigned long, and should go up to 2^32; but there's a place in truncate
      where ext3 calculates the size of the next transaction chunk for the
      delete, and that mistakenly uses a signed long instead.  Because the
      huge i_blocks gets cast to a negative value, ext3 does not reserve
      enough credits for the transaction and the above error results.
      
      This is usually only possible on filesystems corrupted for other
      reasons, but it is reproducible if you create a single, non-sparse file
      larger than 1TB on ext3 and then try to delete it.
      9a3e1a96
    • Andrew Morton's avatar
      [PATCH] CPU Hotplug mm/slab.c CPU_UP_CANCELED fix · 4f1cb3ff
      Andrew Morton authored
      Patch from Manfred Spraul.
      
      Fixes a bug which was exposed by Zwane's hotplug CPU work.  The
      cache_cache.array pointer is initially given a temp bootstrap area, which is
      later converted over to the final value after the CPU is brought up.
      
      But if slab is enhanced to permit cancellation of a CPU bringup, this pointer
      ends up pointing at stale memory.  So reinitialise it by hand when
      kmem_cache_init() is run.
      4f1cb3ff
    • Andrew Morton's avatar
      [PATCH] spinlock debugging on uniprocessors · ecd2d220
      Andrew Morton authored
      Patch from Manfred Spraul <manfred@colorfullife.com>
      
      This enables spinlock debuggng on uniprocessor builds, under
      CONFIG_DEBUG_SPINLOCK.
      
      The reason I want this is that one day we'll need to pull out the debugging
      support from the timer code which detects uninitialised timers.  And once
      that has gone, uniprocessor developers and testers have no way of detecting
      uninitialised timers - there will be mysterious deadlocks on SMP machines.
      And there will surely be more uninitialised timers
      
      The patch also removes the last pieces of the support for including
      <asm/spinlock.h> directly.  Doesn't work since (IIRC) 2.3.x
      ecd2d220
    • Andrew Morton's avatar
      [PATCH] mm/mremap.c whitespace cleanup · 32738fbf
      Andrew Morton authored
      - Not everyone uses 160-column xterms.
      
      - Coding style consistency
      32738fbf
    • Andrew Morton's avatar
      [PATCH] hugetlb mremap fix · df79ea40
      Andrew Morton authored
      If you attempt to perform a relocating 4k-aligned mremap and the new address
      for the map lands on top of a hugepage VMA, do_mremap() will attempt to
      perform a 4k-aligned unmap inside the hugetlb VMA.  The hugetlb layer goes
      BUG.
      
      Fix that by trapping the poorly-aligned unmap attempt in do_munmap().
      do_remap() will then fall through without having done anything to the place
      where it tests for a hugetlb VMA.
      
      It would be neater to perform these checks on entry to do_mremap(), but that
      would incur another VMA lookup.
      
      Also, if you attempt to perform a 4k-aligned and/or sized munmap() inside a
      hugepage VMA the same BUG happens.  This patch fixes that too.
      
      This all means that an mremap attempt against a hugetlb area will fail, but
      only after having unmapped the source pages.  That's a bit messy, but
      supporting hugetlb mremap doesn't seem worth it, and completely disallowing
      it will add overhead to normal mremaps.
      df79ea40
    • Andrew Morton's avatar
      [PATCH] Fix hugetlb_vmtruncate_list() · 8a1335e9
      Andrew Morton authored
      This function is quite wrong - has an "=" where it should have a "-" and
      confuses PAGE_SIZE and HPAGE_SIZE in its address and file offset arithmetic.
      8a1335e9
    • Andrew Morton's avatar
      [PATCH] ia32 hugetlb cleanup · a20d5200
      Andrew Morton authored
      - whitespace
      
      - remove unneeded spinlocking no-op.
      a20d5200
    • Andrew Morton's avatar
      [PATCH] Fix hugetlbfs faults · 8b5111ec
      Andrew Morton authored
      If the underlying mapping was truncated and someone references the
      now-unmapped memory the kernel will enter handle_mm_fault() and will start
      instantiating PAGE_SIZE pte's inside the hugepage VMA.  Everything goes
      generally pear-shaped.
      
      So trap this in handle_mm_fault().  It adds no overhead to non-hugepage
      builds.
      
      Another possible fix would be to not unmap the huge pages at all in truncate
      - just anonymise them.
      
      But I think we want full ftruncate semantics for hugepages for management
      purposes.
      8b5111ec
    • Andrew Morton's avatar
      [PATCH] Give all architectures a hugetlb_nopage(). · 08a1cc4e
      Andrew Morton authored
      If someone maps a hugetlbfs file, then truncates it, then references the part
      of the mapping outside the truncation point, they take a pagefault and we end
      up hitting hugetlb_nopage().
      
      We want to prevent this from ever happening.  This patch just makes sure that
      all architectures have a goes-BUG hugetlb_nopage() to trap it.
      08a1cc4e
    • Andrew Morton's avatar
      [PATCH] hugetlbfs cleanups · 3cc33271
      Andrew Morton authored
      - Remove quota code.
      
      - Remove extraneous copy-n-paste code from truncate: that's only for
        physically-backed filesystems.
      
      - Whitespace changes.
      3cc33271
    • Andrew Morton's avatar
      [PATCH] hugetlbfs i_size fixes · 05732657
      Andrew Morton authored
      We're expanding hugetlbfs i_size in the wrong place.  If someone attempts to
      mmap more pages than are available, i_size is updated to reflect the
      attempted mapping size.
      
      So set i_size only when pages are successfully added to the mapping.
      
      i_size handling at truncate time is still a bit wrong - if the mapping has
      pages at (say) page offset 100-200 and the mappng is truncated to (say) page
      offset 50, i_size should be set to zero.  But it is instead set to
      50*HPAGE_SIZE.  That's harmless.
      05732657
    • Andrew Morton's avatar
      [PATCH] hugetlbfs: fix truncate · 136963d1
      Andrew Morton authored
      - Opening a hugetlbfs file O_TRUNC calls the generic vmtruncate() functions
        and nukes the kernel.
      
        Give S_ISREG hugetlbfs files a inode_operations, and hence a setattr
        which know how to handle these files.
      
      - Don't permit the user to truncate hugetlbfs files to sizes which are not
        a multiple of HPAGE_SIZE.
      
      - We don't support expanding in ftruncate(), so remove that code.
      136963d1
    • Andrew Morton's avatar
      [PATCH] get_unmapped_area for hugetlbfs · 8ca8cd5b
      Andrew Morton authored
      Having to specify the mapping address is a pain.  Give hugetlbfs files a
      file_operations.get_unmapped_area().
      
      The implementation is in hugetlbfs rather than in arch code because it's
      probably common to several architectures.  If the architecture has special
      needs it can define HAVE_ARCH_HUGETLB_UNMAPPED_AREA and go it alone.  Just
      like HAVE_ARCH_UNMAPPED_AREA.
      8ca8cd5b