1. 03 Jun, 2003 7 commits
  2. 04 Jun, 2003 6 commits
  3. 03 Jun, 2003 6 commits
  4. 02 Jun, 2003 21 commits
    • David S. Miller's avatar
      Merge davem@nuts.ninka.net:/home/davem/src/BK/net-2.5 · eba85e7b
      David S. Miller authored
      into kernel.bkbits.net:/home/davem/net-2.5
      eba85e7b
    • David S. Miller's avatar
      [NET]: Typo in iph5527.c driver changes. · dc79bfba
      David S. Miller authored
      dc79bfba
    • David S. Miller's avatar
    • David S. Miller's avatar
      Merge davem@nuts.ninka.net:/home/davem/src/BK/net-2.5 · 3eb8c6c0
      David S. Miller authored
      into kernel.bkbits.net:/home/davem/net-2.5
      3eb8c6c0
    • David S. Miller's avatar
      [IPV6]: In ipv6_add_dev dont call __ipv6_regen_rndid without initial reference held. · 528c1988
      David S. Miller authored
      Based upon a report from Andrew Morton.
      528c1988
    • David S. Miller's avatar
    • David S. Miller's avatar
      bea71ef2
    • David S. Miller's avatar
    • David S. Miller's avatar
      [NET]: Fix CONFIG_HIPPI build. · e0bbada8
      David S. Miller authored
      e0bbada8
    • Alexander Viro's avatar
      [NET]: Eliminate init_fddidev. · 3c54d14f
      Alexander Viro authored
      3c54d14f
    • David S. Miller's avatar
    • Alexander Viro's avatar
      [NET]: Convert most tokenring drivers away from... · 73098660
      Alexander Viro authored
      [NET]: Convert most tokenring drivers away from {init,register,unregister}_trdev, only ibmtr remains.
      73098660
    • Alexander Viro's avatar
    • Alexander Viro's avatar
      25e4e938
    • Linus Torvalds's avatar
      Merge penguin:v2.5/linux · 9e319251
      Linus Torvalds authored
      into home.transmeta.com:/home/torvalds/v2.5/linux
      9e319251
    • Jim Houston's avatar
      [PATCH] preallocate signal queue resource - Posix timers · d1791d31
      Jim Houston authored
      This adds a new interface to kernel/signal.c which allows signals to be
      sent using preallocated sigqueue structures.  It also modifies
      kernel/posix-timers.c to use this interface.
      
      The current timer code may fail to deliver a timer expiry signal if
      there are no sigqueue structures available at the time of the expiry.
      The Posix specification is clear that the signal queuing resource should
      be allocated at timer_create time.  This allows the error to be returned
      to the application rather than silently losing the signal.
      
      This patch does not change the sigqueue structure allocation policy.  I
      hope to revisit that in another patch.
      
      Here is the definition for the new interface:
      
      struct sigqueue *sigqueue_alloc(void)
      	Preallocate a sigqueue structure for use with the functions
      	described below.
      
      void sigqueue_free(struct sigqueue *q)
      	Free a preallocated sigqueue structure.  If the sigqueue
      	structure being freed is still queued, it will be removed
      	from the queue.  I currently leave the signal pending.
      	It may be delivered without the siginfo structure.
      
      int send_sigqueue(int sig, struct sigqueue *q, struct task_struct *p)
      	This function is equivalent to send_sig_info().  It queues
      	a signal to the specified thread using  the supplied sigqueue
      	structure.  The caller is expected to fill in the siginfo_t
      	which is part of the sigqueue structure.
      
      int send_group_sigqueue(int sig, struct sigqueue *q, struct task_struct *p)
      	This function is equivalent to send_group_sig_info().  It queues
      	the signal to a process allowing the system to select which thread
      	will receive the signal in a multi-threaded process.
      	Again, the sigqueue structure is used to queue the signal.
      
      Both send_sigqueue() and send_group_sigqueue() return 0 if the signal
      is queued. They return 1 if the signal was not queued because the
      process is ignoring the signal.
      
      Both versions include code to increment the si_overrun count if the
      sigqueue entry is for a Posix timer and they are called while the
      sigqueue entry is still queued.  Yes, I know that the current code
      doesn't rearm the timer until the signal is delivered.  Having this
      extra bit of code doesn't do any harm, and I plan to use it.
      
      These routines do not check if there already is a legacy (non-realtime)
      signal pending.  They always queue the signal.  This requires that
      collect_signal() always checks if there is another matching siginfo
      before clearing the signal bit.
      d1791d31
    • Andrew Morton's avatar
      [PATCH] remove 16-bit pid assumption from ipc/sem.c · 76621ec6
      Andrew Morton authored
      From: Manfred Spraul <manfred@colorfullife.com>
      
      SysV sem operations that involve multiple semaphores can fail in the
      middle, and then sempid (pid of the last successful operation) must be
      restored.  This happens with "sempid >>= 16" - broken due to the 32-bit pid
      values.  The attached patch fixes that by reordering the updates of the
      semaphore fields.
      
      Additionally, the patch fixes the corruption of the sempid value that occurs
      if a wait-for-zero operation fails.
      
      The patch is more than two years old, and was in -dj and -ak kernels.
      76621ec6
    • Andrew Morton's avatar
      [PATCH] /proc/kcore fixes · 9243548a
      Andrew Morton authored
      From: Tony Luck <tony.luck@intel.com>
      
      /proc/kcore has been broken on some architectures for a long time.  Problems
      surround the fact that some architectures allocate memory for vmalloc() and
      thus modules at addresses below PAGE_OFFSET, which results in negative file
      offsets in the virtual core file image provided by /proc/kcore.  There are
      also pending problems for discontig memory systems as /proc/kcore just
      pretends that there are no holes between "PAGE_OFFSET" and "high_memory", so
      an unwary user (ok super-user) can read non-existant memory which may do bad
      things.  There may also be kernel objects that would be nice to view in
      /proc/kcore, but do not show up there.
      
      A pending change on ia64 to allow booting on machines that don't have
      physical memory in any convenient pre-determined place will make things even
      worse, because the kernel itself won't show up in the current implementation
      of /proc/kcore!
      
      The patch attached provides enough hooks that each architecture should be
      able to make /proc/kcore useful.  The patch is INCOMPLETE in that *use* of
      those hooks is ONLY PROVIDED FOR IA64.
      
      Here's how it works.  The default code in fs/proc/kcore.c doesn't set up any
      "elf_phdr" sections ...  it is left to each architecture to make appropriate
      calls to "kclist_add()" to specify a base address and size for each piece of
      kernel virtual address space that needs to be made accessible through
      /proc/kcore.  To get the old functionality, you'll need two calls that look
      something like:
      
       kclist_add(&kcore_mem, __va(0),
                   max_low_pfn * PAGE_SIZE);
       kclist_add(&kcore_vmem, (void *)VMALLOC_START,
                   VMALLOC_END-VMALLOC_START);
      
      The first makes all of memory visible (__i386__, __mc68000__ and __x86_64__
      should use __va(PAGE_SIZE) to duplicate the original lack of access to page
      0).  The second provides a single map for all "vmalloc" space (the code still
      searches the vmlist to see what actually exists before accessing it).
      
      Other blocks of kernel virtual space can be added as needed, and removed
      again (with kclist_del()).  E.g.  discontiguous memory machines can add an
      entry for each block of memory.  Architectures that allocate memory for
      modules someplace outside of vmalloc-land can add/remove entries on module
      insert and remove.
      
      The second piece of abstraction is the kc_vaddr_to_offset() and
      kc_offset_to_vaddr() macros.  These provide mappings from kernel virtual
      addresses to offsets in the virtual file that /proc/kcore instantiates.  I
      hope they are sufficient to avoid negative offset problems that plagued the
      old /proc/kcore.  Default versions are provided for the old behaviour
      (mapping simply adds/subtracts PAGE_OFFSET).  For ia64 I just need to use a
      different offset as all kernel virtual allocations are in the high 37.5% of
      the 64-bit virtual address space.  x86_64 was the other architecture with
      this problem.  I don't know enough (anything) about the kernel memory map on
      x86_64, so I hope these provide a big enough hook.  I'm hoping that you have
      some low stuff, and some high stuff with a big hole in the middle ...  in
      which case the macros might look something like:
      
      #define kc_vaddr_to_offset(v) ((v) < 0x1000000000000000 ? (v) : \
                                    ((v) - 0xF000000000000000))
      
      But if you have interesting stuff scattered across *every* part of the
      unsigned address range, then you won't be able to squeeze it all into a
      signed file offset.
      
      There are a couple of bug fixes too:
      1) get_kcore_size() didn't account for the elf_prstatus, elf_prpsinfo
         and task_struct that are placed in the PT_NOTE section that is
         part of the header.  We were saved on most configurations by the
         round-up to PAGE_SIZE ... but it's possible that some architectures
         or machines corrupted memory beyond the space allocated for the
         header.
      
      2) The size of the PT_NOTES section was incorrectly set to the size
         of the last note, rather than the sum of the sizes of all the notes.
      9243548a
    • Andrew Morton's avatar
      [PATCH] ext3: fix for blocksize < PAGE_CACHE_SIZE · 32b5fa26
      Andrew Morton authored
      If a buffer_head is outside i_size, block_write_full_page() will leave it
      !buffer_mapped().  We shouldn't attach that buffer to the transaction for
      writeout!
      
      This bug has been in 2.5 for some time.
      32b5fa26
    • Andrew Morton's avatar
      [PATCH] improved core support for time-interpolation · 18783bfd
      Andrew Morton authored
      From: David Mosberger <davidm@napali.hpl.hp.com>
      
      Basically, what the patch does is provide two hooks such that platforms
      (and subplatforms) can provide time-interpolation in a way that guarantees
      that two causally related gettimeofday() calls will never see time going
      backwards (unless there is a settimeofday() call, of course).
      
      There is some evidence that the current scheme does work: we use it on ia64
      both for cycle-counter-based interpolation and the SGI folks use it with a
      chipset-based high-performance counter.
      
      
      It seems like enough platforms do this sort of thing to provide _some_
      support in the core, especially because it's rather tricky to guarantee
      that time never goes backwards (short of a settimeofday, of course).
      
      This patch is based on something Jes Sorensen wrote for the SGI Itanium 2
      platform (which has a chipset-internal high-res clock).  I adapted it so it
      can be used for cycle-counter interpolation also.  The net effect is that
      "last_time_offset" can be removed completely from the kernel.
      
      The basic idea behind the patch is simply: every time you advance xtime by
      N nanoseconds, you call update_wall_time_hook(NSEC).  Every time the time
      gets set (i.e., discontinuity is OK), reset_wall_time_hook() is called.
      18783bfd
    • Andrew Morton's avatar
      [PATCH] MTD build fix · ae871bc9
      Andrew Morton authored
      From: Adrian Bunk <bunk@fs.tum.de>
      
      Fix this:
      
      drivers/mtd/maps/map_funcs.c: In function `simple_map_read64':
      drivers/mtd/maps/map_funcs.c:38: warning: implicit declaration of
      function `__raw_readll'
      ae871bc9