Messages in this thread |  | | Date | Wed, 27 Oct 2021 07:27:48 -0700 | From | Luis Chamberlain <> | Subject | Re: [PATCH v8 11/12] zram: fix crashes with cpu hotplug multistate |
| |
On Wed, Oct 27, 2021 at 01:57:40PM +0200, Miroslav Benes wrote: > On Tue, 26 Oct 2021, Luis Chamberlain wrote: > > > On Tue, Oct 26, 2021 at 11:37:30PM +0800, Ming Lei wrote: > > > OK, then Luis shouldn't consider livepatching as one such issue to solve > > > with one generic solution. > > > > It's not what I was told when the deadlock was found with zram, so I was > > informed quite the contrary. > > From my perspective, it is quite easy to get it wrong due to either a lack > of generic support, or missing rules/documentation.
Indeed. I agree some level of guidence is needed, even if subtle, rather than tribal knowledge. I'll start off with the test_sysfs demo'ing what not to do and documenting this there. I don't think it makes sense to formalize yet documentation for "though shalt not do this" generically until a full depth search is done with Coccinelle.
> So if this thread > leads to "do not share locks between a module removal and a sysfs > operation" strict rule, it would be at least something.
I think that's where we are at. I'll wait to complete my coccinelle deadlock hunt patch to complete the full search, and that could be useful to *warn* aboute new use cases, so to prevent this deadlock in the future. Until then I agree that the complexity introduced is not worth it given the evidence of users, but the full evidence of actual users still remains to be determined. A perfect job left to advances with Coccinelle.
> In the same > manner as Luis proposed to document try_module_get() expectations.
Right and so sysfs ops using try_module_get() *still* remains safe, and so will keep that patch in my next iteration because there *are* *many* uses cases for that.
Luis
|  |