Re: vn.ko load/unload/mount = panic

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Peter Edwards writes:

>After reading the rest of the discussion on this thread, and moving out
>of my depth a little, I assume vn should probably be using
>disk_create()/disk_destroy(), and attaching its softc to the disk object
>rather than the device object. (However, I suppose given the special
>nature of vn, there might be reasons for not using this interface).
>
>I'll gladly "disk"ify vn as a mini- junior-kernel-hacker task if someone
>indicates that it is needed, and if no one more qualified wants to do
>it.

Please go ahead, I'll review and test your patches.

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: vn.ko load/unload/mount = panic

[Peter Edwards]

Nick Hibma wrote:
> 
> Correct me if I am wrong, but I don't think you actually have to
> disassociate any dev_t's from the driver (by clearing the si_drv[12]
> fields) because we call destroy_dev and cdevsw_remove, so any later uses
> of dev_t's get an error because the device has gone away.
> 
> Apart from that I don't think we the calls to cdevsw_add/_destroy in the
> first place, because we create the cdevsw on demand (with make_dev).
> 
> Poul, is this correct?
> 
> nick

Hi,
For the specific case of vn, there is a one-to-many correspondance
between vn instances and dev_ts. The make_dev()/destroy_dev() pairs only
bracket one of the dev_ts. Opens on the same instances of the vn through
different dev_t's just assign the former's softc to the latter's si_drv1
field. There is no corresponding "make_dev()" or "destroy_dev()" call
for such dev_t in the vn driver, so the si_drv1 fields dangle after the
driver is unloaded

The cdevsw_remove only stops access to the offending dev_t's until the
driver is loaded again. After that, the old dev_ts' si_drv1 fields are
still dangling, and the vn driver ends up with a pointer to a free()d vn
softc, and bites the dust.

After reading the rest of the discussion on this thread, and moving out
of my depth a little, I assume vn should probably be using
disk_create()/disk_destroy(), and attaching its softc to the disk object
rather than the device object. (However, I suppose given the special
nature of vn, there might be reasons for not using this interface).

I'll gladly "disk"ify vn as a mini- junior-kernel-hacker task if someone
indicates that it is needed, and if no one more qualified wants to do
it.
--
Peter.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: vn.ko load/unload/mount = panic

[Mike Smith]

> In message , Nick Hibma wri
> tes:
> >
> >Correct me if I am wrong, but I don't think you actually have to
> >disassociate any dev_t's from the driver (by clearing the si_drv[12]
> >fields) because we call destroy_dev and cdevsw_remove, so any later uses
> >of dev_t's get an error because the device has gone away.
> 
> destroy_dev will clear the necessary fields in a dev_t, cdevsw_remove
> will not.

Is it correct to assume that destroy_dev() still isn't working correctly? 
(disk_destroy certainly isn't).

Also, while you still can, that should be dev_destroy().

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: vn.ko load/unload/mount = panic

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Mike Smith writes:
>> In message , Nick Hibma wri
>> tes:
>> >
>> >Correct me if I am wrong, but I don't think you actually have to
>> >disassociate any dev_t's from the driver (by clearing the si_drv[12]
>> >fields) because we call destroy_dev and cdevsw_remove, so any later uses
>> >of dev_t's get an error because the device has gone away.
>> 
>> destroy_dev will clear the necessary fields in a dev_t, cdevsw_remove
>> will not.
>
>Is it correct to assume that destroy_dev() still isn't working correctly? 
>(disk_destroy certainly isn't).

disk_destroy is different from destroy_dev, and I'll get to it real soon.

>Also, while you still can, that should be dev_destroy().

No, because the corresponding is called make_dev().

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: vn.ko load/unload/mount = panic

[Poul-Henning Kamp]

In message , Nick Hibma wri
tes:
>
>Correct me if I am wrong, but I don't think you actually have to
>disassociate any dev_t's from the driver (by clearing the si_drv[12]
>fields) because we call destroy_dev and cdevsw_remove, so any later uses
>of dev_t's get an error because the device has gone away.

destroy_dev will clear the necessary fields in a dev_t, cdevsw_remove
will not.

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: vn.ko load/unload/mount = panic

[Nick Hibma]

Correct me if I am wrong, but I don't think you actually have to
disassociate any dev_t's from the driver (by clearing the si_drv[12]
fields) because we call destroy_dev and cdevsw_remove, so any later uses
of dev_t's get an error because the device has gone away.

Apart from that I don't think we the calls to cdevsw_add/_destroy in the
first place, because we create the cdevsw on demand (with make_dev).

Poul, is this correct?

nick

On Fri, 28 Apr 2000, Peter Edwards wrote:

> I had a longer look at this, and a more complete patch is logged as PR
> kern/18270 (try at your own risk: it works for me).
> I'd appreciate someone more experienced having a look at it and
> commenting.
> Cheers,
> Peter.
> 
> 
> Wilko Bulte wrote:
> > 
> > On Wed, Apr 26, 2000 at 04:25:46PM +0100, Peter Edwards (local) wrote:
> > 
> > How about send-pr ing this stuff?
> > 
> > Wilko
> > 
> > > Hi,
> > > After a (very) quick look at the source it looks like there's a missing
> > > cdevsw_remove() missing from the MOD_UNLOAD/MOD_SHUTDOWN event handling
> > > I haven't time to test it, but try this:
> > >
> > > *** vn.c.oldWed Apr 26 16:23:03 2000
> > > --- vn.cWed Apr 26 16:24:06 2000
> > > ***
> > > *** 762,767 
> > > --- 762,768 
> > > case MOD_UNLOAD:
> > > /* fall through */
> > > case MOD_SHUTDOWN:
> > > +   cdevsw_remove(&vn_cdevsw);
> > > for (;;) {
> > > vn = SLIST_FIRST(&vn_list);
> > > if (!vn)
> > >
> > >
> > > Maxim Sobolev wrote:
> > > >
> > > > Hi,
> > > >
> > > > I've already submitted this crash report earlier but it seems that developers
> > > > in -current list are too busy discussing whether Matt allowed to commit his SMP
> > > > work into 4.0 to pay attention to "ordinary" panic reports :-(. Following is
> > > > slightly simplified course of actions which is known to produce kernel panic on
> > > > both 4.0 and 5.0:
> > > >
> > > > root@notebook# kldstat
> > > > Id Refs AddressSize Name
> > > >  12 0xc010 1c2f48   kernel
> > > >  21 0xc02c3000 30c8 splash_bmp.ko
> > > > root@notebook# mount /dev/vn0c /mnt
> > > > mount: Device not configured
> > > > root@notebook# kldload /modules/vn.ko
> > > > root@notebook# kldstat
> > > > Id Refs AddressSize Name
> > > >  13 0xc010 1c2f48   kernel
> > > >  21 0xc02c3000 30c8 splash_bmp.ko
> > > >  31 0xc0823000 3000 vn.ko
> > > > root@notebook# kldunload -i 3
> > > > root@notebook# mount /dev/vn0c /mnt
> > > > [BINGO]
> > > > Fatal trap 12: page fault while in kernel mode
> > > > [...]
> > > >
> > > > -Maxim
> > 
> > --
> > Wilko Bulte Powered by FreeBSD  http://www.freebsd.org
> > http://www.tcja.nl
> > 
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-current" in the body of the message
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 

--
[EMAIL PROTECTED]
[EMAIL PROTECTED]  USB project
http://www.etla.net/~n_hibma/



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: vn.ko load/unload/mount = panic

[Peter Edwards]

I had a longer look at this, and a more complete patch is logged as PR
kern/18270 (try at your own risk: it works for me).
I'd appreciate someone more experienced having a look at it and
commenting.
Cheers,
Peter.


Wilko Bulte wrote:
> 
> On Wed, Apr 26, 2000 at 04:25:46PM +0100, Peter Edwards (local) wrote:
> 
> How about send-pr ing this stuff?
> 
> Wilko
> 
> > Hi,
> > After a (very) quick look at the source it looks like there's a missing
> > cdevsw_remove() missing from the MOD_UNLOAD/MOD_SHUTDOWN event handling
> > I haven't time to test it, but try this:
> >
> > *** vn.c.oldWed Apr 26 16:23:03 2000
> > --- vn.cWed Apr 26 16:24:06 2000
> > ***
> > *** 762,767 
> > --- 762,768 
> > case MOD_UNLOAD:
> > /* fall through */
> > case MOD_SHUTDOWN:
> > +   cdevsw_remove(&vn_cdevsw);
> > for (;;) {
> > vn = SLIST_FIRST(&vn_list);
> > if (!vn)
> >
> >
> > Maxim Sobolev wrote:
> > >
> > > Hi,
> > >
> > > I've already submitted this crash report earlier but it seems that developers
> > > in -current list are too busy discussing whether Matt allowed to commit his SMP
> > > work into 4.0 to pay attention to "ordinary" panic reports :-(. Following is
> > > slightly simplified course of actions which is known to produce kernel panic on
> > > both 4.0 and 5.0:
> > >
> > > root@notebook# kldstat
> > > Id Refs AddressSize Name
> > >  12 0xc010 1c2f48   kernel
> > >  21 0xc02c3000 30c8 splash_bmp.ko
> > > root@notebook# mount /dev/vn0c /mnt
> > > mount: Device not configured
> > > root@notebook# kldload /modules/vn.ko
> > > root@notebook# kldstat
> > > Id Refs AddressSize Name
> > >  13 0xc010 1c2f48   kernel
> > >  21 0xc02c3000 30c8 splash_bmp.ko
> > >  31 0xc0823000 3000 vn.ko
> > > root@notebook# kldunload -i 3
> > > root@notebook# mount /dev/vn0c /mnt
> > > [BINGO]
> > > Fatal trap 12: page fault while in kernel mode
> > > [...]
> > >
> > > -Maxim
> 
> --
> Wilko Bulte Powered by FreeBSD  http://www.freebsd.org
> http://www.tcja.nl
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: vn.ko load/unload/mount = panic

[Wilko Bulte]

On Wed, Apr 26, 2000 at 04:25:46PM +0100, Peter Edwards (local) wrote:

How about send-pr ing this stuff? 

Wilko

> Hi,
> After a (very) quick look at the source it looks like there's a missing
> cdevsw_remove() missing from the MOD_UNLOAD/MOD_SHUTDOWN event handling
> I haven't time to test it, but try this:
> 
> *** vn.c.oldWed Apr 26 16:23:03 2000
> --- vn.cWed Apr 26 16:24:06 2000
> ***
> *** 762,767 
> --- 762,768 
> case MOD_UNLOAD:
> /* fall through */
> case MOD_SHUTDOWN:
> +   cdevsw_remove(&vn_cdevsw);
> for (;;) {
> vn = SLIST_FIRST(&vn_list);
> if (!vn)
> 
> 
> Maxim Sobolev wrote:
> > 
> > Hi,
> > 
> > I've already submitted this crash report earlier but it seems that developers
> > in -current list are too busy discussing whether Matt allowed to commit his SMP
> > work into 4.0 to pay attention to "ordinary" panic reports :-(. Following is
> > slightly simplified course of actions which is known to produce kernel panic on
> > both 4.0 and 5.0:
> > 
> > root@notebook# kldstat
> > Id Refs AddressSize Name
> >  12 0xc010 1c2f48   kernel
> >  21 0xc02c3000 30c8 splash_bmp.ko
> > root@notebook# mount /dev/vn0c /mnt
> > mount: Device not configured
> > root@notebook# kldload /modules/vn.ko
> > root@notebook# kldstat
> > Id Refs AddressSize Name
> >  13 0xc010 1c2f48   kernel
> >  21 0xc02c3000 30c8 splash_bmp.ko
> >  31 0xc0823000 3000 vn.ko
> > root@notebook# kldunload -i 3
> > root@notebook# mount /dev/vn0c /mnt
> > [BINGO]
> > Fatal trap 12: page fault while in kernel mode
> > [...]
> > 
> > -Maxim

-- 
Wilko Bulte Powered by FreeBSD  http://www.freebsd.org
http://www.tcja.nl


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: vn.ko load/unload/mount = panic

[Peter Edwards (local)]

Sorry, I think that fix is incomplete (though it'll prolly stop the
crashes). I think there should be a destroy_dev() call for each created
device in the MOD_UNLOAD case also.
I'll make a patch and send-pr it once I get back to my home machine,
unless someone more experienced feels the need to do it.
--
Peter.


"Peter Edwards (local)" wrote:
> 
> Hi,
> After a (very) quick look at the source it looks like there's a missing
> cdevsw_remove() missing from the MOD_UNLOAD/MOD_SHUTDOWN event handling
> I haven't time to test it, but try this:
> 
> *** vn.c.oldWed Apr 26 16:23:03 2000
> --- vn.cWed Apr 26 16:24:06 2000
> ***
> *** 762,767 
> --- 762,768 
> case MOD_UNLOAD:
> /* fall through */
> case MOD_SHUTDOWN:
> +   cdevsw_remove(&vn_cdevsw);
> for (;;) {
> vn = SLIST_FIRST(&vn_list);
> if (!vn)
> 
> Maxim Sobolev wrote:
> >
> > Hi,
> >
> > I've already submitted this crash report earlier but it seems that developers
> > in -current list are too busy discussing whether Matt allowed to commit his SMP
> > work into 4.0 to pay attention to "ordinary" panic reports :-(. Following is
> > slightly simplified course of actions which is known to produce kernel panic on
> > both 4.0 and 5.0:
> >
> > root@notebook# kldstat
> > Id Refs AddressSize Name
> >  12 0xc010 1c2f48   kernel
> >  21 0xc02c3000 30c8 splash_bmp.ko
> > root@notebook# mount /dev/vn0c /mnt
> > mount: Device not configured
> > root@notebook# kldload /modules/vn.ko
> > root@notebook# kldstat
> > Id Refs AddressSize Name
> >  13 0xc010 1c2f48   kernel
> >  21 0xc02c3000 30c8 splash_bmp.ko
> >  31 0xc0823000 3000 vn.ko
> > root@notebook# kldunload -i 3
> > root@notebook# mount /dev/vn0c /mnt
> > [BINGO]
> > Fatal trap 12: page fault while in kernel mode
> > [...]
> >
> > -Maxim
> >
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-current" in the body of the message
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: vn.ko load/unload/mount = panic

[Peter Edwards (local)]

Hi,
After a (very) quick look at the source it looks like there's a missing
cdevsw_remove() missing from the MOD_UNLOAD/MOD_SHUTDOWN event handling
I haven't time to test it, but try this:

*** vn.c.oldWed Apr 26 16:23:03 2000
--- vn.cWed Apr 26 16:24:06 2000
***
*** 762,767 
--- 762,768 
case MOD_UNLOAD:
/* fall through */
case MOD_SHUTDOWN:
+   cdevsw_remove(&vn_cdevsw);
for (;;) {
vn = SLIST_FIRST(&vn_list);
if (!vn)


Maxim Sobolev wrote:
> 
> Hi,
> 
> I've already submitted this crash report earlier but it seems that developers
> in -current list are too busy discussing whether Matt allowed to commit his SMP
> work into 4.0 to pay attention to "ordinary" panic reports :-(. Following is
> slightly simplified course of actions which is known to produce kernel panic on
> both 4.0 and 5.0:
> 
> root@notebook# kldstat
> Id Refs AddressSize Name
>  12 0xc010 1c2f48   kernel
>  21 0xc02c3000 30c8 splash_bmp.ko
> root@notebook# mount /dev/vn0c /mnt
> mount: Device not configured
> root@notebook# kldload /modules/vn.ko
> root@notebook# kldstat
> Id Refs AddressSize Name
>  13 0xc010 1c2f48   kernel
>  21 0xc02c3000 30c8 splash_bmp.ko
>  31 0xc0823000 3000 vn.ko
> root@notebook# kldunload -i 3
> root@notebook# mount /dev/vn0c /mnt
> [BINGO]
> Fatal trap 12: page fault while in kernel mode
> [...]
> 
> -Maxim
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

vn.ko load/unload/mount = panic

[Maxim Sobolev]

Hi,

I've already submitted this crash report earlier but it seems that developers
in -current list are too busy discussing whether Matt allowed to commit his SMP
work into 4.0 to pay attention to "ordinary" panic reports :-(. Following is
slightly simplified course of actions which is known to produce kernel panic on
both 4.0 and 5.0:

root@notebook# kldstat
Id Refs AddressSize Name
 12 0xc010 1c2f48   kernel
 21 0xc02c3000 30c8 splash_bmp.ko
root@notebook# mount /dev/vn0c /mnt
mount: Device not configured
root@notebook# kldload /modules/vn.ko
root@notebook# kldstat
Id Refs AddressSize Name
 13 0xc010 1c2f48   kernel
 21 0xc02c3000 30c8 splash_bmp.ko
 31 0xc0823000 3000 vn.ko
root@notebook# kldunload -i 3
root@notebook# mount /dev/vn0c /mnt
[BINGO]
Fatal trap 12: page fault while in kernel mode
[...]

-Maxim



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message