From: John Garry <email@example.com>
To: Krzysztof Kozlowski <firstname.lastname@example.org>,
Christoph Hellwig <email@example.com>
Cc: "Ewan D. Milne" <firstname.lastname@example.org>,
"James E.J. Bottomley" <email@example.com>,
"Martin K. Petersen" <firstname.lastname@example.org>,
"Alim Akhtar" <email@example.com>,
Avri Altman <firstname.lastname@example.org>,
"Doug Gilbert" <email@example.com>,
Subject: Re: [PATCH 1/4] scsi: core: constify pointer to scsi_host_template
Date: Mon, 9 May 2022 15:50:33 +0100 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On 09/05/2022 14:20, Krzysztof Kozlowski wrote:
> On 09/05/2022 13:28, John Garry wrote:
>> For some reason I cannot fetch your git due to "error: RPC failed ..."
>> which I think is a timeout. I seem to have this problem recently
>> whenever a linux.git clone has branches based on linux-next.git . Maybe
>> a git config issue for me...
> Just to be sure - the link was not a git remote, but direct link for a
> web browser. The repo is:
> branch: n/qcom-ufs-opp-cleanups-v2
OK, I'll double check. Regardless I'll sort my own IT issues :)
>>> However this does not solve the problem. The SHT has "module" which gets
>>> incremented/decremented. Exactly like in case of other drivers
>> Ah, I missed that this could be a problem. So we have this member to
>> stop the SCSI host driver being removed when we have disks mounted, etc.
>> But isn't scsi_host_template.module just a pointer to the local driver
>> module data (and that data gets incremented/decremented)? I am looking
>> at the THIS_MODULE definition in export.h:
> Yes, it is just a pointer, just like 'struct device_driver.owner' is.
>> extern stuct module __this_module;
>> #define THIS_MODULE(&__this_module)
>> However I do see scsi_device_dev_release(), which does:
>> sdp->host->hostt->module = NULL
>> I am not sure how necessary that really is. I would need to check further.
>> Did you see if there other places which set hostt->module dynamically?
> I think all SHT set it statically.
Incidentally I did notice that the ata ahci driver does not set sht->module.
> Then it is being dynamically
> incremented when needed and in scsi_device_dev_release() is being
> nullified (as you mentioned above).
> I guess this SHT->module is actually duplicating what most of drivers
> (e.g. PCI, platform, USB) are doing. If I understand correctly, the
> Scsi_Host is instantiated by the probe of a driver (pci_driver,
> virtio_driver etc), therefore the SHT->module could be simply stored in
If you check scsi_device_dev_release(), we try to do a 'get' - if it
fails, then we nullify hostt->module. I think that is important as then
we call execute_in_process_context(), whose worker does the 'put'.
However, the 'put' will get upset if the refcnt was 0, which it would be
if the earlier 'get' fails - hence the nullify is to avoid that
possibility. So whatever you do needs to handle that. Details are in
next prev parent reply other threads:[~2022-05-09 14:49 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-08 10:30 [PATCH 1/4] scsi: core: constify pointer to scsi_host_template Krzysztof Kozlowski
2022-04-08 10:30 ` [PATCH 2/4] scsi: core: fix white-spaces Krzysztof Kozlowski
2022-05-04 8:47 ` Krzysztof Kozlowski
2022-04-08 10:30 ` [PATCH 3/4] scsi: ufs: ufshcd-pltfrm: constify pointed data Krzysztof Kozlowski
2022-04-08 10:30 ` [PATCH 4/4] scsi: ufs: ufshcd: " Krzysztof Kozlowski
2022-04-08 14:35 ` Bart Van Assche
2022-04-08 12:14 ` [PATCH 1/4] scsi: core: constify pointer to scsi_host_template John Garry
2022-04-08 12:32 ` Krzysztof Kozlowski
2022-04-08 12:57 ` John Garry
2022-04-08 19:31 ` Ewan D. Milne
2022-04-12 7:57 ` John Garry
2022-04-20 7:03 ` Christoph Hellwig
2022-04-25 8:58 ` John Garry
2022-04-25 9:22 ` Krzysztof Kozlowski
2022-04-25 13:04 ` John Garry
2022-04-26 1:16 ` Bart Van Assche
2022-04-26 1:54 ` Douglas Gilbert
2022-04-26 4:13 ` Bart Van Assche
2022-04-27 1:47 ` Douglas Gilbert
2022-05-06 16:42 ` Krzysztof Kozlowski
2022-05-09 11:28 ` John Garry
2022-05-09 13:20 ` Krzysztof Kozlowski
2022-05-09 14:50 ` John Garry [this message]
2022-05-11 8:31 ` Christoph Hellwig
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.