- 21 Apr, 2004 1 commit
-
-
Chris Wright authored
-
- 20 Apr, 2004 11 commits
-
-
David S. Miller authored
into nuts.davemloft.net:/disk1/BK/net-2.6
-
Jens Axboe authored
Remove bogus assert in CFQ and remove merge hints.
-
Andrew Morton authored
From: Ralf Baechle <ralf@linux-mips.org> - more work on resurrecting AMD Alchemy platforms - cleanup of unnecessary <asm/pgalloc.h> inclusions - update default config files - cleanup 32-bit compat ioctl code - support for Montum Jaguar ATX - workarounds for early revs of the RM9000 - fixes for RM5000 and RM7000 cache handling - add support for PMC-Sierra Yosemite eval board - further cleanup and bugfixes for SGI IP27 - make LASAT and VR41xx build and work in 2.6 - improved SGI IP32 support - plenty of small fixes
-
Andrew Morton authored
From: Ralf Baechle <ralf@linux-mips.org> The pending changes to the MIPS doc files, more changes needed...
-
Andrew Morton authored
From: Ralf Baechle <ralf@linux-mips.org> Limit the DZ driver to MIPS32 as the supported hardware is only present in R2k/R3k-based systems (unless someone sends Maciej a PMAC-A board for driver development).
-
Andrew Morton authored
From: Christoph Hellwig <hch@lst.de> We don't need a copy of COPYING down in fs/hfs. Roman said he didn't mind, so..
-
Andrew Morton authored
From: "Pedro Emanuel M. D. Pinto" <pepinto@student.dei.uc.pt> This currently-unused function is incorrectly implemented. Fix.
-
Andrew Morton authored
Remove a duplicated case which recently snuck in there.
-
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.)
-
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.
-
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.
-
- 19 Apr, 2004 28 commits
-
-
http://linux-lksctp.bkbits.net/lksctp-2.5.workDavid S. Miller authored
into nuts.davemloft.net:/disk1/BK/net-2.6
-
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.
-
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.
-
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)
-
Bartlomiej Zolnierkiewicz authored
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
bk://gkernel.bkbits.net/misc-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
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.)
-
bk://gkernel.bkbits.net/net-drivers-2.6Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
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.
-
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...
-
Andrew Morton authored
Used for sysfs support.
-
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.
-
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.
-
Javier Achirica authored
-
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.
-
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.
-
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(®s, addr, sizeof(regs))) > return -EFAULT; > e1000_ethtool_gregs(adapter, ®s, regs_buff); > if(copy_to_user(addr, ®s, 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.
-
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:
-
Jeff Garzik authored
They are now upstream, we don't need driver-local ones anymore.
-
Jeff Garzik authored
-
Jeff Garzik authored
Tangentially noticed by Stanford checker.
-
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.
-
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.
-
Jeff Garzik authored
Caught by Stanford checker.
-
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.
-