re: devsw_detach is failing -- is this a manifestation of PR kern/56962?
hello Matthew. That line assures that if a device driver has unloaded
and reloaded its
bdevw or cdevw interfaces, it gets assigned the same major numbers that they
had when they
were first loaded on the system. If a device driver has never loaded its
bdevsw or cdevsw
interfaces on a system and the major number is dynamically assigned, this works
as well because
execution of the for loop exits due to there being an insufficient number of
conv structures
available when the device driver loads for the first time, so this test is
never executed.
Once the driver loads for the first time, the conv structure is initialized
with the correct
major numbers and this test will pass the next time the device driver loads its
bdevsw or
cdevsw interfaces. There is one caveat here that was always true, but will
absolutely be
enforced with this patch. That is, the caller of devsw_attach() should ensure
the bmajor and
cmajor numbers they pass into the function point to different variables in
their function, even
if they do not implement the bdevsw interface. If they fail to do this,
they'll get EINVAL
back from the devsw_attach call if they load their bdevsw or cdevsw interfaces
on the system
more than once.
-thanks
-Brian
On Feb 13, 2:47pm, matthew green wrote:
} Subject: re: devsw_detach is failing -- is this a manifestation of PR kern
} your change seems to fix a clear but to me.
}
} > - if (*bmajor < 0)
} > + if ((bdev != NULL) && (*bmajor < 0))
} > *bmajor = conv->d_bmajor;
}
} there's also this line i'm curious about, just below:
}
} if (*bmajor != conv->d_bmajor || *cmajor != conv->d_cmajor) {
} error = EINVAL;
} goto out;
}
} should the first part also depend upon either bdev != NULL or
} perhaps (*bmajor >= 0 && bdev == NULL) as the following code
} uses...
}
}
} .mrg.
>-- End of excerpt from matthew green
re: devsw_detach is failing -- is this a manifestation of PR kern/56962?
your change seems to fix a clear but to me.
> - if (*bmajor < 0)
> + if ((bdev != NULL) && (*bmajor < 0))
> *bmajor = conv->d_bmajor;
there's also this line i'm curious about, just below:
if (*bmajor != conv->d_bmajor || *cmajor != conv->d_cmajor) {
error = EINVAL;
goto out;
should the first part also depend upon either bdev != NULL or
perhaps (*bmajor >= 0 && bdev == NULL) as the following code
uses...
.mrg.
Re: devsw_detach is failing -- is this a manifestation of PR kern/56962?
hello. Following up on this issue, I've discovered the problem with devsw_attach is that if one is reattaching a previously detached driver and that driver does not implementa bdev interface, devsw_attach returns an EINVAL error. The following patch fixes this problem. Any reason I should not commit this change and request pullups for NetBSD-9 and NetBSD-10? -thanks -Brian Index: subr_devsw.c === RCS file: /cvsroot/src/sys/kern/subr_devsw.c,v retrieving revision 1.49 diff -u -r1.49 subr_devsw.c --- subr_devsw.c29 Oct 2022 10:52:36 - 1.49 +++ subr_devsw.c10 Feb 2023 19:11:24 - @@ -1,4 +1,4 @@ -/* $NetBSD$*/ +/* $NetBSD: subr_devsw.c,v 1.49 2022/10/29 10:52:36 riastradh Exp $ */ /*- * Copyright (c) 2001, 2002, 2007, 2008 The NetBSD Foundation, Inc. @@ -69,7 +69,7 @@ */ #include -__KERNEL_RCSID(0, "$NetBSD$"); +__KERNEL_RCSID(0, "$NetBSD: subr_devsw.c,v 1.49 2022/10/29 10:52:36 riastradh Exp $"); #ifdef _KERNEL_OPT #include "opt_dtrace.h" @@ -397,7 +397,7 @@ if (conv->d_name == NULL || strcmp(devname, conv->d_name) != 0) continue; - if (*bmajor < 0) + if ((bdev != NULL) && (*bmajor < 0)) *bmajor = conv->d_bmajor; if (*cmajor < 0) *cmajor = conv->d_cmajor;
Re: devsw_detach is failing -- is this a manifestation of PR kern/56962?
> Date: Wed, 1 Feb 2023 23:24:53 -0800 > From: Brian Buhrow > > I'm runing NetBSD-9.99.77, which predates the pr kern/56962 > fixes. Is this behavior expected prior to the fix for this bug or > am I running into something else? I don't recall the details and don't have time to think through it right now but that's certainly plausible. Please update to a more recent kernel and try again!
