Scott Rotondo [EMAIL PROTECTED] wrote:
Did you run a test with the original filesystem, or what do you like to
tell us
here?
I didn't test anything. I was just pointing out, based on simple
examination of the source code, that line 944 is sure to panic if fsp
contains random bits,
Joerg Schilling wrote:
Scott Rotondo [EMAIL PROTECTED] wrote:
Joerg Schilling wrote:
Does it help to intialize the pointers to NULL?
Sure. This code
943 if (fsp)
944 kmem_free(fsp, sizeof (*fsp));
945 if (svp)
946 kmem_free(svp,
to make this an end, the fix (btw, as mentioned by ScottR) has been putbacked 2
days ago under 6715049
driven by JuergenKeil and Dan.McDonald.
---
frankB
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Scott Rotondo [EMAIL PROTECTED] wrote:
Joerg Schilling wrote:
Juergen Keil [EMAIL PROTECTED] wrote:
Hmm, in usr/src/uts/common/fs/hsfs/hsfs_vfsops.c function hs_mountfs(),
whenever we use one of the first three |goto cleanup|, the local variables
|svp| and |jvp| are uninitialized.
Joerg Schilling wrote:
Juergen Keil [EMAIL PROTECTED] wrote:
Hmm, in usr/src/uts/common/fs/hsfs/hsfs_vfsops.c function hs_mountfs(),
whenever we use one of the first three |goto cleanup|, the local variables
|svp| and |jvp| are uninitialized. That should corrupt the kernel heap
when we
On Mon, 16 Jun 2008, Robert William Fuller wrote:
[EMAIL PROTECTED] wrote:
Hi Kyle,
given that what happens looks ever-so-slightly different each time, a
hardware glitch could be possible; to exclude this, would you happen to
know whether these panics occurred before build 78 as well ?
On Mon, 16 Jun 2008, Juergen Keil wrote:
Robert William Fuller wrote:
[EMAIL PROTECTED] wrote:
Hi Kyle,
given that what happens looks ever-so-slightly different each time, a
hardware glitch could be possible; to exclude this, would you happen to
know whether these panics occurred before
[EMAIL PROTECTED] wrote:
Hi Kyle,
given that what happens looks ever-so-slightly different each time, a
hardware glitch could be possible; to exclude this, would you happen to
know whether these panics occurred before build 78 as well ? If they occur
if you use the b77 hsfs module on
Robert William Fuller wrote:
[EMAIL PROTECTED] wrote:
Hi Kyle,
given that what happens looks ever-so-slightly different each time, a
hardware glitch could be possible; to exclude this, would you happen to
know whether these panics occurred before build 78 as well ? If they occur
Frank Hofmann wrote:
On Mon, 16 Jun 2008, Juergen Keil wrote:
IIRC a bug like ``kmem_free(NULL, size)'' somewhere in the kernel can have
the
effect that a subsequent ``kmem_alloc(size, KM_SLEEP)'' somewhere else in
the
kernel will return with a NULL pointer! (Assuming you run release
Juergen Keil [EMAIL PROTECTED] wrote:
kmem_alloc(0, flag) always returns NULL. kmem_free(NULL, 0)
is legal.
That's manpage - consider it a spec ...
Well, it says kmem_free with a ptr == NULL and size == 0 is legal;
but what about ptr == NULL and size 0?
We had the
Robert William Fuller [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Hi Kyle,
given that what happens looks ever-so-slightly different each time, a
hardware glitch could be possible; to exclude this, would you happen to
know whether these panics occurred before build 78 as well ?
Frank Hofmann wrote:
On Mon, 16 Jun 2008, Juergen Keil wrote:
For that reason I did suggest to Kyle to try to reproduce this hsfs mount
panic with kmem heap checking enabled.
Add the following line to /etc/system, reboot, retry to reproduce the hsfs
mount panic:
set
Hmm, in usr/src/uts/common/fs/hsfs/hsfs_vfsops.c function hs_mountfs(),
whenever we use one of the first three |goto cleanup|, the local variables
|svp| and |jvp| are uninitialized. That should corrupt the kernel heap
when we kmem_free() with an unitialized stack lock pointer in the
cleanup
I filed a bug at http://bugs.opensolaris.org/;
Bug-ID is not yet known.
Fix is obvious:
diff --git a/usr/src/uts/common/fs/hsfs/hsfs_vfsops.c
b/usr/src/uts/common/fs/hsfs/hsfs_vfsops.c
--- a/usr/src/uts/common/fs/hsfs/hsfs_vfsops.c
+++ b/usr/src/uts/common/fs/hsfs/hsfs_vfsops.c
@@ -596,8
Juergen Keil [EMAIL PROTECTED] wrote:
Hmm, in usr/src/uts/common/fs/hsfs/hsfs_vfsops.c function hs_mountfs(),
whenever we use one of the first three |goto cleanup|, the local variables
|svp| and |jvp| are uninitialized. That should corrupt the kernel heap
when we kmem_free() with an
16 matches
Mail list logo
