Re: [CHECKER] free bugs in 2.4.4 and 2.4.4-ac8
On Thu, 24 May 2001, Dawson Engler wrote:
> Hi All,
>
> Enclosed are 24 bugs where code uses memory that has been freed. The
> good thing about these bugs is that they are easy to fix. (Note: About
> 5 of these have had patches submitted, so this list is a bit out of
> date.)
Enclosed is a patch for these. It's untested, as I don't have any of this
hardware, but all the fixes I made seemed relatively obvious. Of course, by
saying this, I've doomed myself to at least 1 stupid mistake.
There are 3 spots I didn't fix, just because I'm not sure what the appropriate
fix is. On in the ipv6 udp code, I'm unsure as to what the intent is. The 2
rio code spots require some more serious restructuring to fix the debug message.
Patch is against 2.4.4-ac16
-Justin
--- linux-2.4.4-ac16/drivers/atm/iphase.c Thu May 24 14:24:46 2001
+++ linux/drivers/atm/iphase.c Thu May 24 14:43:25 2001
@@ -1318,12 +1318,12 @@
if (ia_vcc == NULL)
{
atomic_inc(&vcc->stats->rx_err);
- dev_kfree_skb_any(skb);
#if LINUX_VERSION_CODE >= 0x20312
atm_return(vcc, atm_guess_pdu2truesize(skb->len));
#else
atm_return(vcc, atm_pdu2truesize(skb->len));
#endif
+ dev_kfree_skb_any(skb);
goto INCR_DLE;
}
// get real pkt length pwang_test
@@ -1334,7 +1334,6 @@
(skb->len - sizeof(struct cpcs_trailer
{
atomic_inc(&vcc->stats->rx_err);
- dev_kfree_skb_any(skb);
IF_ERR(printk("rx_dle_intr: Bad AAL5 trailer %d (skb len %d)",
length, skb->len);)
#if LINUX_VERSION_CODE >= 0x20312
@@ -1342,6 +1341,7 @@
#else
atm_return(vcc, atm_pdu2truesize(skb->len));
#endif
+ dev_kfree_skb_any(skb);
goto INCR_DLE;
}
skb_trim(skb, length);
diff -ru linux-2.4.4-ac16/drivers/block/cciss.c linux/drivers/block/cciss.c
--- linux-2.4.4-ac16/drivers/block/cciss.c Thu May 24 14:24:47 2001
+++ linux/drivers/block/cciss.c Thu May 24 14:28:26 2001
@@ -680,6 +680,7 @@
{
kfree(buff);
cmd_free(h, c, 0);
+ return ( -EFAULT);
}
}
kfree(buff);
diff -ru linux-2.4.4-ac16/drivers/char/drm/gamma_dma.c
linux/drivers/char/drm/gamma_dma.c
--- linux-2.4.4-ac16/drivers/char/drm/gamma_dma.c Mon Dec 11 12:39:44 2000
+++ linux/drivers/char/drm/gamma_dma.c Thu May 24 14:55:44 2001
@@ -555,12 +555,6 @@
current->state = TASK_RUNNING;
DRM_DEBUG("%d running\n", current->pid);
remove_wait_queue(&last_buf->dma_wait, &entry);
- if (!retcode
- || (last_buf->list==DRM_LIST_PEND && !last_buf->pending)) {
- if (!waitqueue_active(&last_buf->dma_wait)) {
- drm_free_buffer(dev, last_buf);
- }
- }
if (retcode) {
DRM_ERROR("ctx%d w%d p%d c%d i%d l%d %d/%d\n",
d->context,
@@ -571,6 +565,12 @@
last_buf->list,
last_buf->pid,
current->pid);
+ }
+ if (!retcode
+ || (last_buf->list==DRM_LIST_PEND && !last_buf->pending)) {
+ if (!waitqueue_active(&last_buf->dma_wait)) {
+ drm_free_buffer(dev, last_buf);
+ }
}
}
return retcode;
diff -ru linux-2.4.4-ac16/drivers/message/i2o/i2o_pci.c
linux/drivers/message/i2o/i2o_pci.c
--- linux-2.4.4-ac16/drivers/message/i2o/i2o_pci.c Thu May 24 14:24:52 2001
+++ linux/drivers/message/i2o/i2o_pci.c Thu May 24 14:40:17 2001
@@ -254,7 +254,6 @@
#else
i2o_delete_controller(c);
#endif /* MODULE */
- kfree(c);
iounmap(mem);
return -EBUSY;
}
diff -ru linux-2.4.4-ac16/drivers/net/hamradio/bpqether.c
linux/drivers/net/hamradio/bpqether.c
--- linux-2.4.4-ac16/drivers/net/hamradio/bpqether.cWed Apr 18 14:40:06 2001
+++ linux/drivers/net/hamradio/bpqether.c Thu May 24 14:48:02 2001
@@ -191,9 +191,9 @@
unregister_netdevice(&bpq->axdev);
kfree(bpq);
+ } else {
+ bpq_prev = bpq;
}
-
- bpq_prev = bpq;
}
restore_flags(flags);
diff -ru linux-2.4.4-ac16/drivers/net/wan/lapbether.c linux/drivers/net/wan/lapbether.c
--- linux-2.4.4-ac16/drivers/net/wan/lapbether.cWed Apr 18 14:40:07 2001
+++ linux/drivers/net/wan/lapbet
Re: CML2 design philosophy heads-up
On Fri, 18 May 2001, Jes Sorensen wrote: > Oh I don't, on the other hand I see you consistently ignoring the > needs and requirements of the users. So far I haven't heard a single > developer say something positive about CML2, the most positive I have > heard so far has been "whatever", "it's his choice", "I don't care", > "I want to hack". The majority are of the "NO!" and "you got to be > kiddin'". Perhaps your hearing has gone more than a bit selective. Please, allow me to be the first to get through: I think CML2 looks very interesting, and while it's not quite primetime yet, it's definitely a movement in the right direction. I'd even go sofar as to say I think CML2 is a GOOD THING. Or perhaps you have a more selective definition of developer? -Justin [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
SMP bug revealed by networking?
I'm working on a new SMP mips port, and tripped over a strange bug. Am not quite sure how to attack it. I'm running 2.4.2 from oss.sgi.com's cvs repositry, booting with the root filesystem being over NFS with two cores active in the system. The port is actually fairly stable at the moment, but just once, while trying to exec init during a boot, it locked up. Since I'm running in simulation (fun consequence of not porting to something for which silicon doesn't yet exist), I took a peek and saw this: CPU0 was in ip_defrag() trying to aquire the ipq spinlock CPU1 was idle. ip_defrag() being an exceedingly unlikely source of bugs at this moment, especially in terms of that simple locking, I'm thinking I must have a bug in the SMP handling; however, I don't see any likely candidates there either. I can't reproduce this bug, either; it seems to have been dependent on timing from the network. Has anyone run into anything remotely like this before? Any suggestions on where to look for bug or how to make this reproducable in order to track it down? Thanks, Justin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bug in the file attributes ?
On Thu, 29 Mar 2001, Xavier Ordoquy wrote: > Hi, > > I just made a manipulation that disturbs me. So I'm asking whether it's a > bug or a features. > > user> su > root> echo "test" > test > root> ls -l > -rw-r--r-- 1 root root5 Mar 29 19:14 test > root> exit > user> rm test > rm: remove write-protected file `test'? y > user> ls test > ls: test: No such file or directory > > This is in the user home directory. > Since the file is read only for the user, it should not be able to remove > it. Moreover, the user can't write to test. > So I think this is a bug. You don't need write perms on a file to remove it, you need write perms on the directory. If you've got write permissions on the directory, you can remove any file in the directory, regardless of the permissions. -Justin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Ramdisk root filesystem strangeness
Am in the midst of bringing up the kernel on a new MIPS variant, and I'm tryingthe
mount a statically linked ramdisk as the root filesystem.
Note, this is NOT using initrd support, I really want to use a ramdisk as my
final filesystem, not as an intermediate step in booting the system.
In blkdev_get(), called from mount_root(), there's some code that grabs
an empty inode, sets up i_rdev, and calls open() for the root device
with the caveat that open() must not examine anything except i_rdev.
in rd_open, though, there's this code snippet:
/*
* Immunize device against invalidate_buffers() and prune_icache().
*/
if (rd_inode[DEVICE_NR(inode->i_rdev)] == NULL) {
if (!inode->i_bdev)
return -ENXIO;
I'm hitting the -ENXIO return, which is based on an uninitialized field of the
inode structure.
Being relatively new to the code base, I'm not sure what this code is trying to
do, nor how to fix it. Any suggestions?
The code involved is from the MIPS CVS repository at oss.sgi.com, which was
synced in the past couple days from 2.4.0test11
-Justin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
