1. 20 Apr, 2004 3 commits
    • Andrew Morton's avatar
      [PATCH] fix madvise(MADV_DONTNEED) for nonlinear vmas · d614d315
      Andrew Morton authored
      From: Hugh Dickins <hugh@veritas.com>
      
      Jamie points out that madvise(MADV_DONTNEED) should unmap pages from a
      nonlinear area in such a way that the nonlinear offsets are preserved if the
      pages do turn out to be needed later after all, instead of reverting them to
      linearity: needs to pass down a zap_details block.
      
      (But this still leaves mincore unaware of nonlinear vmas: bigger job.)
      d614d315
    • Andrew Morton's avatar
      [PATCH] reiserfs use-after-free fix · e8b338d6
      Andrew Morton authored
      From: Chris Mason <mason@suse.com>
      
      reiserfs-delayed-work started using queue_delayed_work, but did not make sure
      the timer was finished before it freed the work queue structs during unmount. 
      This leads to timer oopsen if you unmount at just the right time.
      e8b338d6
    • Roland McGrath's avatar
      [PATCH] fix for potential deadlock after posix-timers change · f3276a18
      Roland McGrath authored
      Ulrich has been working on the glibc code using posix-timers and
      stressing it more now than it has before.  He ran into an SMP deadlock
      on process exit in the case there are pending queued signals from a
      timer.
      
      The deadlock arises because in the path through exit_itimers, the
      tasklist_lock is already held (for writing).  When a timer is being
      deleted, sigqueue_free will try to take it (for reading) in the case
      where that timer has a pending signal queued on somebody's queue.  This
      patch avoids the problem by making sure the queues are flushed before
      calling exit_itimers, thus ensuring its code path won't try to take
      tasklist_lock.
      f3276a18
  2. 19 Apr, 2004 37 commits
    • Benjamin Herrenschmidt's avatar
      [PATCH] ppc64: siginfo conversion fix · b4389817
      Benjamin Herrenschmidt authored
      My message queue patch fixes the 64 bits -> 32 bits conversion of
      siginfo, but didn't change the 32 -> 64 bits conversion done in
      sys32_rt_sigqueueinfo() which was apparently bogus as well.
      
      After much discussion & debate on the right way of converting that
      structure, I decided to go the sparc64 / s390 way, and not the x86_64
      way, that is to copy the various unions data "as is". This guarantees
      that whatever a 32 bist app passes there, another 32 bits app will
      understand it. Crossover between 32 and 64 bits apps on such things
      as home-made userland siginfo isn't something we can help with anyway.
      
      The x86_64 choice of converting as if it was an RT signal, thus
      converting the sigval, cannot easily be applied to big endian archs
      since the sigval is a union of a ptr and an int, on BE, the int
      happens to be on the wrong half of the 64 bits ptr, thus  we can't
      do a simple conversion.
      b4389817
    • Bartlomiej Zolnierkiewicz's avatar
      [PATCH] generic ide_init_hwif_ports() · 38fc4e8b
      Bartlomiej Zolnierkiewicz authored
      Add generic ide_init_hwif_ports() to <linux/ide.h> and remove arch specific
      versions except arm26, arm, h8300, i386-pc9800, m68k and m68knommu ones.
      38fc4e8b
    • Bartlomiej Zolnierkiewicz's avatar
      [PATCH] ide_init_default_hwifs() -> ide_init_default_irq() · c407acc1
      Bartlomiej Zolnierkiewicz authored
      init_ide_data() initializes default IDE interfaces but without default IRQ
      (hwif->irq and hwif->hw.irq fields) so introduce ide_init_default_irq() and
      remove redundant ide_init_default_hwifs() (except arm26 and arm ones).
      
      As a side-effect it fixes:
      - CONFIG_BLK_DEV_HD_IDE if !CONFIG_BLK_DEV_IDEPCI (i386)
      - hwif->noprobe shouldn't be 0 if !hwif->io_ports[IDE_DATA_OFFSET]
        (alpha, i386, ia64, mips, sh, x86_64)
      c407acc1
    • Bartlomiej Zolnierkiewicz's avatar
    • Linus Torvalds's avatar
    • Linus Torvalds's avatar
      b35a6769
    • Linus Torvalds's avatar
      Merge master.kernel.org:/home/davem/BK/net-2.6 · dfb9c436
      Linus Torvalds authored
      into ppc970.osdl.org:/home/torvalds/v2.6/linux
      dfb9c436
    • Linus Torvalds's avatar
      Merge bk://gkernel.bkbits.net/misc-2.6 · 299b664a
      Linus Torvalds authored
      into ppc970.osdl.org:/home/torvalds/v2.6/linux
      299b664a
    • Bjorn Helgaas's avatar
      [PATCH] Fix hw_random build on ia64 · 36377f61
      Bjorn Helgaas authored
      The following patch allows hw_random.c to build on ia64.  (The problem
      was just that the VIA stuff has i386 assembly in it.  The current code
      only probes for VIA on i386 anyway, so this patch just adds more ifdefs
      so the VIA code is only built for i386.)
      36377f61
    • Linus Torvalds's avatar
      Merge bk://gkernel.bkbits.net/net-drivers-2.6 · 1e6ad211
      Linus Torvalds authored
      into ppc970.osdl.org:/home/torvalds/v2.6/linux
      1e6ad211
    • Pavel Roskin's avatar
      [PATCH] Tulip endianess fix · d86d6aaa
      Pavel Roskin authored
      My tulip ethernet card doesn't work on Blue&White G3 PowerMac with Linux
      2.6.5-rc2.  The card is shown by lspci as
      
      01:03.0 Ethernet controller: Linksys Network Everywhere Fast Ethernet
      10/100 model NC100 (rev 11)
      
      The kernel detects it as "ADMtek Comet rev 17".
      
      The MAC address reported by the kernel looked obviously wrong.  Also, I
      could only ping the system successfully if the interface was in promiscuous
      mode (running Ethereal).
      
      Those two symptoms indicated two different problems - one for reading the
      MAC address from the card on module load (tulip_init_one), and the other
      for writing the address to the card when the interface was brought up
      (tulip_up).  I have fixed both, and here's the explanation:
      
      tulip_init_one:
      
      When reading the first 4 bytes of the address, inl() returns the same data
      to the CPU on all platforms, interpreting the data from the lowest port
      address as the least significant byte.  In other words, I/O is little
      endian on all platforms; it's the memory that differs across platforms.
      We want to write the data to memory preserving little-endianness of the
      PCI bus.  To force little endian write to the memory, the data should be
      converted to the little endian format.
      
      When reading the remaining 2 bytes, the CPU gets them in 2 least
      significant bytes.  To write those 2 bytes to the memory in a 16-bit
      operation, they should be byte-swapped for the 16-bit operation.
      
      tulip_up:
      
      The first 4 bytes are processed correctly, but the code is confusing.
      Reading from memory needs conversion to CPU format, while writing to I/O
      ports doesn't.  So I replaced cpu_to_le32() to le32_to_cpu().
      
      The second 2 bytes are read in a 16-bit memory operation, so they should
      be passed to le16_to_cpu() rather than cpu_to_le32() to make them CPU
      independent and suitable for outl().
      
      
      All those conversions do nothing on little-endian machines, so they should
      not be affected.
      
      The patch has been tested.  The driver is working fine.  ping is OK, ssh
      is OK, X11 over ssh is OK.  Even netconsole is working fine.
      d86d6aaa
    • Daniel Ritz's avatar
      [PATCH] missing s/dev->priv/netdev_priv(dev) in drivers/net/pcmcia/ · 0d61de3f
      Daniel Ritz authored
      On Wednesday 24 March 2004 23:25, Jeff Garzik wrote:
      > Daniel Ritz wrote:
      > > clean up the last two instances of dev->priv in drivers/net/pcmcia.
      > > against 2.6.5-rc2-bk.
      > >
      > > --- 1.27/drivers/net/pcmcia/3c589_cs.c	Wed Mar  3 01:03:51 2004
      > > +++ edited/drivers/net/pcmcia/3c589_cs.c	Wed Mar 24 22:29:35 2004
      > > @@ -716,7 +716,7 @@
      > >  	  "status %4.4x.\n", dev->name, (long)skb->len,
      > >  	  inw(ioaddr + EL3_STATUS));
      > >
      > > -    ((struct el3_private *)dev->priv)->stats.tx_bytes += skb->len;
      > > +    ((struct el3_private *)netdev_priv(dev))->stats.tx_bytes += skb->len;
      > >
      > >      /* Put out the doubleword header... */
      > >      outw(skb->len, ioaddr + TX_FIFO);
      > > --- 1.24/drivers/net/pcmcia/ibmtr_cs.c	Wed Mar  3 01:06:03 2004
      > > +++ edited/drivers/net/pcmcia/ibmtr_cs.c	Wed Mar 24 22:29:51 2004
      > > @@ -444,7 +444,7 @@
      > >          link->state &= ~DEV_PRESENT;
      > >          if (link->state & DEV_CONFIG) {
      > >  	    /* set flag to bypass normal interrupt code */
      > > -	    ((struct tok_info *)dev->priv)->sram_virt |= 1;
      > > +	    ((struct tok_info *)netdev_priv(dev))->sram_virt |= 1;
      > >  	    netif_device_detach(dev);
      > >  	    ibmtr_release(link);
      >
      >
      > although the patch is OK, the code itself is a bit yucky.
      >
      > Can you please create a temporary variable, of struct el3_private or
      > tok_info type, and eliminate that cast?
      >
      > struct el3_private *priv = netdev_priv(dev);
      > priv->stats.tx_bytes += skb->len;
      >
      > Much nicer :)
      >
      
      agreed. here we go...
      0d61de3f
    • Andrew Morton's avatar
      [PATCH] Call SET_NETDEV_DEV() in a bunch of net drivers · 513f042e
      Andrew Morton authored
      Used for sysfs support.
      513f042e
    • Don Fry's avatar
      [PATCH] pcnet32.c add support for 79C976 · ece91eb2
      Don Fry authored
      Please apply the following patch to 2.6.5-rc2-bk9 and 2.4.26-rc1 to
      include support for the 79C976. Tested on IA32.
      ece91eb2
    • Stephen Hemminger's avatar
      [PATCH] remove 8139too ring size option. · 4e21d3f5
      Stephen Hemminger authored
      On Wed, 31 Mar 2004 15:05:16 -0500
      Jeff Garzik <jgarzik@pobox.com> wrote:
      
      > I really should remove the ability to configure 8139_RXBUF_IDX=3.
      4e21d3f5
    • Javier Achirica's avatar
      [PATCH] airo: Fix suspend support · d54bf49a
      Javier Achirica authored
      d54bf49a
    • Russell King's avatar
      [PATCH] fix arm/etherh.c · eb659532
      Russell King authored
      On Tue, Apr 13, 2004 at 02:35:40PM -0400, Jeff Garzik wrote:
      > Russell,
      >
      > Would you be willing to provide an updated diff of this?
      
      I didn't particularly like the PRIV() method implemented previously -
      gcc appears to want to avoid some optimisations it if its an inline
      function rather than a macro.
      
      Also, 'ei_local' may look unused in some functions, but it's your
      typical hidden-use-in-a-macro crap which 8390 likes.
      eb659532
    • Stephen Hemminger's avatar
      [PATCH] Mixed PCI/ISA device name conflicts · 66dbee35
      Stephen Hemminger authored
      In systems with mixed network cards, and all drivers compiled into
      the kernel; the PCI device (eth0) will get probed first, before the ISA.
      
      The problem is that the ISA device can mistakenly try to probe
      for eth0.  The problem is that the ISA driver will not detect the failure
      until it goes to call register_netdevice, and not all drivers have
      perfect error unwind code.
      
      This patch short circuits the device probe, so it won't bother
      looking for devices that already are registered.
      66dbee35
    • Chris Wright's avatar
      [PATCH] e1000: fix probable security hole · bf31652c
      Chris Wright authored
      * Ken Ashcraft (ken@coverity.com) wrote:
      > [BUG]
      > /home/kash/linux/linux-2.6.5/drivers/net/e1000/e1000_ethtool.c:1494:e1000_ethtool_ioctl: ERROR:TAINT: 1487:1494:Passing unbounded user value "(regs).len" as arg 2 to function "copy_to_user", which uses it unsafely in model [SOURCE_MODEL=(lib,copy_from_user,user,taintscalar)] [SINK_MODEL=(lib,copy_to_user,user,trustingsink)]    [PATH=]
      > 	}
      > 	case ETHTOOL_GREGS: {
      > 		struct ethtool_regs regs = {ETHTOOL_GREGS};
      > 		uint32_t regs_buff[E1000_REGS_LEN];
      >
      > Start --->
      > 		if(copy_from_user(&regs, addr, sizeof(regs)))
      > 			return -EFAULT;
      > 		e1000_ethtool_gregs(adapter, &regs, regs_buff);
      > 		if(copy_to_user(addr, &regs, sizeof(regs)))
      > 			return -EFAULT;
      >
      > 		addr += offsetof(struct ethtool_regs, data);
      > Error --->
      > 		if(copy_to_user(addr, regs_buff, regs.len))
      > 			return -EFAULT;
      >
      > 		return 0;
      
      Looks like a bug.  Possible patch below zeros the buffer (since it's not
      filled completely by e1000_ethtool_gregs()), and truncates len.
      bf31652c
    • Adrian Bunk's avatar
      [PATCH] fix warning in drivers/net/tulip/timer.c · 27de7466
      Adrian Bunk authored
      I get the following warning in 2.6.5-mm6 and 2.6.6-rc1:
      
      <--  snip  -->
      
      ...
        CC      drivers/net/tulip/timer.o
      drivers/net/tulip/timer.c: In function `comet_timer':
      drivers/net/tulip/timer.c:156: warning: unused variable `ioaddr'
      ...
      
      <--  snip  -->
      
      
      Since the
         [netdrvr tulip] add MII support for Comet chips
      patch has removed the only use of this variable, the fix is simple:
      27de7466
    • Jeff Garzik's avatar
      [netdrvr r8169] remove driver-local DMA_xxBIT_MASK definitions · 35fd5c4b
      Jeff Garzik authored
      They are now upstream, we don't need driver-local ones anymore.
      35fd5c4b
    • Jeff Garzik's avatar
      96f2c4a4
    • Jeff Garzik's avatar
      [hamradio baycom] Remove bogus check in interrupt handler · 62424348
      Jeff Garzik authored
      Tangentially noticed by Stanford checker.
      62424348
    • Chris Wright's avatar
      [PATCH] remove redundant check in de2104x ->get_regs() · 395ac660
      Chris Wright authored
      Trivial patchlet...ethtool core already caps regs.len at a max of
      ->get_regs_len():
      
      	reglen = ops->get_regs_len(dev);
      	if (regs.len > reglen)
      		regs.len = reglen;
      
      So doing the same in the in de2104x driver ->get_regs() is redundant.
      Patch below simply removes it to clarify the guarantee of the API.
      395ac660
    • Chris Wright's avatar
      [PATCH] wan sdla: fix probable security hole · 98cd917c
      Chris Wright authored
      > [BUG] minor
      > /home/kash/linux/linux-2.6.5/drivers/net/wan/sdla.c:1206:sdla_xfer:
      > ERROR:TAINT: 1201:1206:Passing unbounded user value "(mem).len" as arg 0
      > to function "kmalloc", which uses it unsafely in model
      > [SOURCE_MODEL=(lib,copy_from_user,user,taintscalar)]
      > [SINK_MODEL=(lib,kmalloc,user,trustingsink)]  [MINOR]  [PATH=] [Also
      > used at, line 1219 in argument 0 to function "kmalloc"]
      > static int sdla_xfer(struct net_device *dev, struct sdla_mem *info, int
      > read)
      > {
      > 	struct sdla_mem mem;
      > 	char	*temp;
      >
      > Start --->
      > 	if(copy_from_user(&mem, info, sizeof(mem)))
      > 		return -EFAULT;
      >
      > 	if (read)
      > 	{
      > Error --->
      > 		temp = kmalloc(mem.len, GFP_KERNEL);
      > 		if (!temp)
      > 			return(-ENOMEM);
      > 		sdla_read(dev, mem.addr, temp, mem.len);
      
      Hrm, I believe you could use this to read 128k of kernel memory.
      sdla_read() takes len as a short, whereas mem.len is an int.  So,
      if mem.len == 0x20000, the allocation could still succeed.  When cast
      to short, len will be 0x0, causing the read loop to copy nothing into
      the buffer.  At least it's protected by a capable() check.  I don't
      know what proper upper bound is for this hardware, or how much it's
      used/cared about.  Simple memset() is trivial fix.
      98cd917c
    • Jeff Garzik's avatar
      [wireless orinoco] Remove bogus !dev check · 3ce12aab
      Jeff Garzik authored
      Caught by Stanford checker.
      3ce12aab
    • Andrew Morton's avatar
      [PATCH] 3c509 oops fix · e059aa85
      Andrew Morton authored
      If __ISAPNP__ and CONFIG_X86_PC9800 are not set, we forget to link the device
      into the global chain and el3_init_module dereferences NULL.
      e059aa85
    • Olaf Hering's avatar
      [PATCH] mace register_netdev printk · 0847467e
      Olaf Hering authored
      small cosmetic fix for powermac mace network driver.
      
      eth%d: MACE at 00:05:02:f4:1b:1d, chip revision 25.64
      vs.
      eth0: MACE at 00:05:02:f4:1b:1d, chip revision 25.64
      0847467e
    • Linus Torvalds's avatar
      Merge master.kernel.org:/home/davem/BK/sparc-2.6 · ce4e5cd4
      Linus Torvalds authored
      into ppc970.osdl.org:/home/torvalds/v2.6/linux
      ce4e5cd4
    • Andrew Morton's avatar
      [PATCH] Warn if module_param and MODULE_PARM mixed · 517acd7f
      Andrew Morton authored
      From: Rusty Russell <rusty@rustcorp.com.au>
      
      From: Pavel Roskin <proski@gnu.org>
      
      If you use both module_param (new) and MODULE_PARM (obsolete) in a module,
      only the second gets recognised.  Warn.
      517acd7f
    • Andrew Morton's avatar
      [PATCH] nfs token table can be __initdata · 5acb7574
      Andrew Morton authored
      nfs token table can be  __initdata
      5acb7574
    • Andrew Morton's avatar
      [PATCH] sparc32 stack bounds checking · 2901f6ba
      Andrew Morton authored
      From: William Lee Irwin III <wli@holomorphy.com>
      
      The stack is now shared with struct thread_info on most arches, not task_t.
      This mostly affects get_wchan() and stack usage debug.
      2901f6ba
    • Andrew Morton's avatar
      [PATCH] ppc32 stack bounds checking · 7bad0e6d
      Andrew Morton authored
      From: William Lee Irwin III <wli@holomorphy.com>
      
      The stack is now shared with struct thread_info on most arches, not task_t.
      This mostly affects get_wchan() and stack usage debug.
      7bad0e6d
    • Andrew Morton's avatar
      [PATCH] m68knommu stack bounds checking · 34f77ac0
      Andrew Morton authored
      From: William Lee Irwin III <wli@holomorphy.com>
      
      The stack is now shared with struct thread_info on most arches, not task_t.
      This mostly affects get_wchan() and stack usage debug.
      34f77ac0
    • Andrew Morton's avatar
      [PATCH] m68k stack bounds checking · 6fd0e105
      Andrew Morton authored
      From: William Lee Irwin III <wli@holomorphy.com>
      
      The stack is now shared with struct thread_info on most arches, not task_t.
      This mostly affects get_wchan() and stack usage debug.
      6fd0e105
    • Andrew Morton's avatar
      [PATCH] h8300 stack bounds checking · 8e9b32e7
      Andrew Morton authored
      From: William Lee Irwin III <wli@holomorphy.com>
      
      The stack is now shared with struct thread_info on most arches, not task_t.
      This mostly affects get_wchan() and stack usage debug.
      8e9b32e7
    • Andrew Morton's avatar
      [PATCH] From: David Gibson <david@gibson.dropbear.id.au> · 49c18faa
      Andrew Morton authored
      hugepage_vma() is both misleadingly named and unnecessary.  On most archs it
      always returns NULL, and on IA64 the vma it returns is never used.  The
      function's real purpose is to determine whether the address it is passed is a
      special hugepage address which must be looked up in hugepage pagetables,
      rather than being looked up in the normal pagetables (which might have
      specially marked hugepage PMDs or PTEs).
      
      This patch kills off hugepage_vma() and folds the logic it really needs into
      follow_huge_addr().  That now returns a (page *) if called on a special
      hugepage address, and an error encoded with ERR_PTR otherwise.  This also
      requires tweaking the IA64 code to check that the hugepage PTE is present in
      follow_huge_addr() - previously this was guaranteed, since it was only called
      if the address was in an existing hugepage VMA, and hugepages are always
      prefaulted.
      49c18faa