|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH] xen/scsiback: don't call scsiback_free_translation_entry() under lock
On 28.03.23 17:47, Oleksandr Tyshchenko wrote: On 28.03.23 11:46, Juergen Gross wrote: Hello Juergenscsiback_free_translation_entry() shouldn't be called under spinlock, as it can sleep. This requires to split removing a translation entry from the v2p list from actually calling kref_put() for the entry. Reported-by: Dan Carpenter <error27@xxxxxxxxx> Link: https://urldefense.com/v3/__https://lore.kernel.org/lkml/Y*JUIl64UDmdkboh@kadam/__;Kw!!GF_29dbcQIUBPA!23IKdVhamoFq8ptUnprd_TubDMObj-0QAalsGiffBHCeEdOuwrq7z4ohg92Sj0olgl0nh73oXvSr-i1zqXhY$ [lore[.]kernel[.]org] Signed-off-by: Juergen Gross <jgross@xxxxxxxx> --- drivers/xen/xen-scsiback.c | 27 ++++++++++++++------------- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/drivers/xen/xen-scsiback.c b/drivers/xen/xen-scsiback.c index 954188b0b858..294f29cdc7aa 100644 --- a/drivers/xen/xen-scsiback.c +++ b/drivers/xen/xen-scsiback.c @@ -1010,12 +1010,6 @@ static int scsiback_add_translation_entry(struct vscsibk_info *info, return err; }-static void __scsiback_del_translation_entry(struct v2p_entry *entry) There is no need to initialize it, so I think I will keep it as is.
Correct. spin_unlock_irqrestore(&info->v2p_lock, flags);... when the lock is not held, ok Patch LGTM, but one (maybe stupid) question to clarify. Why do we need to use a lock here in the first place? The scsiback_release_translation_entry() gets called when the driver instance is about to be removed and *after* the disconnection from otherend (so no requests are expected), so what else might cause this list to be accessed concurrently? Maybe nothing, but I think it is good practice to keep the lock in order to avoid future code changes to cause problems. Juergen Attachment:
OpenPGP_0xB0DE9DD628BF132F.asc Attachment:
OpenPGP_signature
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |