On Tue, Apr 18, 2017 at 05:05:06PM +, Maya Rashish wrote:
> XXX surrounding code seems fishy
>
> @@ -759,7 +759,6 @@ swcr_compdec(struct cryptodesc *crd, con
> if (result < crd->crd_len) {
> adj = result - crd->crd_len;
> if (outtype == CRYPTO_BUF_MBUF) {
> -
On Fri, 27 Nov 2015, Christos Zoulas wrote:
Module Name:src
Committed By: christos
Date: Sat Nov 28 03:40:43 UTC 2015
Modified Files:
src/sys/opencrypto: crypto.c
Log Message:
fix the build
Thanks, and sorry for the breakage.
+--+---
Date: Mon, 27 Jan 2014 05:45:32 -0800 (PST)
From: Paul Goyette
Taylor R Campbell wrote:
> Would it suffice to add an open count to struct bdevsw and struct
> cdevsw, to be maintained by {bdev,cdev}_{open,close}?
I think this would be sufficient.
Minor snag: all the bdevsw/cde
Taylor R Campbell wrote:
It seems to me that the crux of the problem is that devsw_detach
doesn't fail if the device is still in use, because we do keep no
books about which devsws are still in use, so there's nothing to stop
you from unloading a device's module before you've given a its close
r
Date: Sun, 26 Jan 2014 11:36:32 +
From: David Laight
It also sounds like manual unloads of drivers can happen when the
device is open - and that is also bad.
A manual unload probably isn't going to race with open or close though.
Disallowing unload completely would be a pai
On Sun, Jan 26, 2014 at 11:04:31AM +1100, matthew green wrote:
>
> > >>> phase one: disable auto-unload.
> > >
> > >> Phase 1 has been done.
> > >
> > > for the whole kernel?
> >
> > No. Only for this specific module.
>
> right - my suggestion was that since this problem affects a
> large clas
> >>> phase one: disable auto-unload.
> >
> >> Phase 1 has been done.
> >
> > for the whole kernel?
>
> No. Only for this specific module.
right - my suggestion was that since this problem affects a
large class of modules, until that is fixed, we should
disable auto unload globally.
.mrg.
On Sun, 26 Jan 2014, matthew green wrote:
phase one: disable auto-unload.
Phase 1 has been done.
for the whole kernel?
No. Only for this specific module.
-
| Paul Goyette | PGP Key fingerprint: | E-mail
> > phase one: disable auto-unload.
> Phase 1 has been done.
for the whole kernel?
Phase 1 has been done.
On Sat, 25 Jan 2014, matthew green wrote:
Implement in-module ref-counting, and do not allow auto-unload if there
are existing references.
Note that manual unloading is not prevented.
OK christos@
XXX Also note that there is still a small window where the ref-count c
> >> Implement in-module ref-counting, and do not allow auto-unload if there
> >> are existing references.
> >>
> >> Note that manual unloading is not prevented.
> >>
> >> OK christos@
> >>
> >> XXX Also note that there is still a small window where the ref-count can
> >> XXX be decremented, an
On Fri, 24 Jan 2014, Taylor R Campbell wrote:
Shouldn't devsw_detach or config_fini_component handle this? Why does
the crypto device need special reference counting that other devices
don't?
The crypto device isn't special in this regard. Pretty much all device
driver modules need this sor
Date: Fri, 24 Jan 2014 17:35:41 + (UTC)
From: chris...@astron.com (Christos Zoulas)
In article <7458.1390534...@splode.eterna.com.au>,
matthew green wrote:
>
>> Log Message:
>> XXX Also note that there is still a small window where the ref-count can
>> XXX be decremen
Some modules get auto-loaded by the syscall mechanism. We already have
a mechanism to determine if any lwp's are currently executing these
syscalls, and if yes we prevent auto-unload.
For device-driver modules, there is currently no equivalent mechanism.
They get auto-loaded from code in spec
In article <7458.1390534...@splode.eterna.com.au>,
matthew green wrote:
>
>> Log Message:
>> Implement in-module ref-counting, and do not allow auto-unload if there
>> are existing references.
>>
>> Note that manual unloading is not prevented.
>>
>> OK christos@
>>
>> XXX Also note that there
> Log Message:
> Implement in-module ref-counting, and do not allow auto-unload if there
> are existing references.
>
> Note that manual unloading is not prevented.
>
> OK christos@
>
> XXX Also note that there is still a small window where the ref-count can
> XXX be decremented, and then the p
On Sun, 19 Jan 2014, Christos Zoulas wrote:
On Jan 19, 3:04pm, p...@whooppee.com (Paul Goyette) wrote:
-- Subject: Re: CVS commit: src/sys/opencrypto
| The mere existence of a non-zero unit is a "reference" that needs to
| prevent unloading.
What if it is the last reference? Th
On Jan 19, 3:04pm, p...@whooppee.com (Paul Goyette) wrote:
-- Subject: Re: CVS commit: src/sys/opencrypto
| The mere existence of a non-zero unit is a "reference" that needs to
| prevent unloading.
What if it is the last reference? Then the ref count will go to zero after
clo
The mere existence of a non-zero unit is a "reference" that needs to
prevent unloading.
The two checks (unit# and ref-count) are equivalent and redundant, and
only one of them needs to be there.
On Sun, 19 Jan 2014, Christos Zoulas wrote:
In article ,
Paul Goyette wrote:
On Sun, 19 Jan
On Jan 19, 10:37am, Paul Goyette wrote:
} On Sun, 19 Jan 2014, Christos Zoulas wrote:
} > On Jan 19, 10:22am, p...@whooppee.com (Paul Goyette) wrote:
} >
} > | How about the following changes?
} >
} > You need to handle the regular open too, not justthe get (look for the
} > other fd_clone)
}
} Th
In article ,
Paul Goyette wrote:
>On Sun, 19 Jan 2014, John Nemeth wrote:
>
>> } Handled indirectly. The MODULE_CMD_FINI calls config_cfdata_detach()
>> } which attempts to detach each device instance. If a detach fails, then
>> } config_cfdata_detach fails, and the unload will fail.
>>
>>
On Sun, 19 Jan 2014, John Nemeth wrote:
} Handled indirectly. The MODULE_CMD_FINI calls config_cfdata_detach()
} which attempts to detach each device instance. If a detach fails, then
} config_cfdata_detach fails, and the unload will fail.
Does this mean that you'll end up with some devic
On Jan 19, 11:21am, p...@whooppee.com (Paul Goyette) wrote:
-- Subject: Re: CVS commit: src/sys/opencrypto
| > | Handled indirectly. The MODULE_CMD_FINI calls config_cfdata_detach()
| > | which attempts to detach each device instance. If a detach fails, then
| > | config_cfdata_det
On Sun, 19 Jan 2014, Christos Zoulas wrote:
On Jan 19, 10:37am, p...@whooppee.com (Paul Goyette) wrote:
-- Subject: Re: CVS commit: src/sys/opencrypto
| That's covered in cryptoopen() at line 1060
I missed that patch
No worry.
| Handled indirectly. The MODULE_CMD_FINI
On Jan 19, 10:37am, p...@whooppee.com (Paul Goyette) wrote:
-- Subject: Re: CVS commit: src/sys/opencrypto
| That's covered in cryptoopen() at line 1060
I missed that patch
| Handled indirectly. The MODULE_CMD_FINI calls config_cfdata_detach()
| which attempts to detach each device ins
On Sun, 19 Jan 2014, Christos Zoulas wrote:
On Jan 19, 10:22am, p...@whooppee.com (Paul Goyette) wrote:
-- Subject: Re: CVS commit: src/sys/opencrypto
| How about the following changes?
You need to handle the regular open too, not justthe get (look for the
other fd_clone)
That's cover
On Jan 19, 10:22am, p...@whooppee.com (Paul Goyette) wrote:
-- Subject: Re: CVS commit: src/sys/opencrypto
| How about the following changes?
You need to handle the regular open too, not justthe get (look for the
other fd_clone)
| @@ -143,6 +143,8 @@ static intcryptoread(dev_t dev
On Sun, 19 Jan 2014, Christos Zoulas wrote:
Module Name:src
Committed By: christos
Date: Sun Jan 19 18:16:13 UTC 2014
Modified Files:
src/sys/opencrypto: cryptodev.c
Log Message:
bail out unloading for now
How about the following changes?
@@ -143,6 +143,8 @@ static i
28 matches
Mail list logo