[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <d87e5f8c-c221-f5cb-0ae7-969867fbc9b5@acm.org>
Date: Mon, 3 Oct 2022 17:24:03 -0700
From: Bart Van Assche <bvanassche@....org>
To: Luis Chamberlain <mcgrof@...nel.org>
Cc: Mauro Carvalho Chehab <mchehab@...nel.org>,
"Martin K . Petersen" <martin.petersen@...cle.com>,
linux-scsi@...r.kernel.org, Christoph Hellwig <hch@....de>,
Ming Lei <ming.lei@...hat.com>, Hannes Reinecke <hare@...e.de>,
John Garry <john.garry@...wei.com>,
Mike Christie <michael.christie@...cle.com>,
Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-modules@...r.kernel.org, linux-kernel@...r.kernel.org,
"James E.J. Bottomley" <jejb@...ux.ibm.com>,
Tejun Heo <tj@...nel.org>
Subject: Re: [PATCH v5 6/7] module: Improve support for asynchronous module
exit code
On 10/3/22 16:56, Luis Chamberlain wrote:
> Yeah I've gone ahead and re-read your original patch again the issue
> with that is it waits *once* for the refcnt to go to 0, but that does
> not forbit it from going back up, at which point you have a race which
> can still create the situation. Every subsystem is different, but for
> instance simply running a loop opening a device block file should
> suffice to bump the refcnt of a respective block driver module. So
> at least the patch itself won't ultimately address this issue I'm
> afraid.
Hi Luis,
Thanks for the feedback. I will try to find a solution that does not
require to modify the kernel module code.
Bart.
Powered by blists - more mailing lists