All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shuah Khan <skhan@linuxfoundation.org>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
	shuah@kernel.org, valentina.manea.m@gmail.com,
	gregkh@linuxfoundation.org
Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	Shuah Khan <skhan@linuxfoundation.org>
Subject: Re: [PATCH 4/6] usbip: fix stub_dev usbip_sockfd_store() races leading to gpf
Date: Tue, 9 Mar 2021 16:52:22 -0700	[thread overview]
Message-ID: <05e8e744-0847-cde2-b978-0bfd7ef93a9f@linuxfoundation.org> (raw)
In-Reply-To: <7b9465aa-213e-a513-d033-12c048df15d6@i-love.sakura.ne.jp>

On 3/9/21 4:40 PM, Tetsuo Handa wrote:
> On 2021/03/10 4:50, Shuah Khan wrote:
>> On 3/9/21 4:04 AM, Tetsuo Handa wrote:
>>> On 2021/03/09 1:27, Shuah Khan wrote:
>>>> Yes. We might need synchronization between events, threads, and shutdown
>>>> in usbip_host side and in connection polling and threads in vhci.
>>>>
>>>> I am also looking at the shutdown sequences closely as well since the
>>>> local state is referenced without usbip_device lock in these paths.
>>>>
>>>> I am approaching these problems as peeling the onion an expression so
>>>> we can limit the changes and take a spot fix approach. We have the
>>>> goal to address these crashes and not introduce regressions.
>>>
>>> I think my [PATCH v4 01/12]-[PATCH v4 06/12] simplify your further changes
>>> without introducing regressions. While ud->lock is held when checking ud->status,
>>> current attach/detach code is racy about read/update of ud->status . I think we
>>> can close race in attach/detach code via a simple usbip_event_mutex serialization.
>>>
>>
>> Do you mean patches 1,2,3,3,4,5,6?
> 
> Yes, my 1,2,3,4,5,6.
> 
> Since you think that usbip_prepare_threads() does not worth introducing, I'm fine with
> replacing my 7,8,9,10,11,12 with your "[PATCH 0/6] usbip fixes to crashes found by syzbot".
> 

Using event lock isn't the right approach to solve the race. It is a
large grain lock. I am not looking to replace patches.

I still haven't seen any response from you about if you were able to
verify the fixes I sent in fix the problem you are seeing.

thanks,
-- Shuah



  reply	other threads:[~2021-03-09 23:53 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-08  3:53 [PATCH 0/6] usbip fixes to crashes found by syzbot Shuah Khan
2021-03-08  3:53 ` [PATCH 1/6] usbip: fix stub_dev to check for stream socket Shuah Khan
2021-03-08  3:53 ` [PATCH 2/6] usbip: fix vhci_hcd " Shuah Khan
2021-03-08  3:53 ` [PATCH 3/6] usbip: fix vudc " Shuah Khan
2021-03-08  3:53 ` [PATCH 4/6] usbip: fix stub_dev usbip_sockfd_store() races leading to gpf Shuah Khan
2021-03-08  7:35   ` Tetsuo Handa
2021-03-08 10:10     ` Tetsuo Handa
2021-03-08 16:27       ` Shuah Khan
2021-03-09 11:04         ` Tetsuo Handa
2021-03-09 13:56           ` Tetsuo Handa
2021-03-09 19:50           ` Shuah Khan
2021-03-09 23:40             ` Tetsuo Handa
2021-03-09 23:52               ` Shuah Khan [this message]
2021-03-10  0:03                 ` Tetsuo Handa
2021-03-10  0:29                   ` Shuah Khan
2021-03-10  1:02                     ` Tetsuo Handa
2021-03-10  2:07                       ` Shuah Khan
2021-03-10 10:38                         ` Tetsuo Handa
2021-03-09 15:22         ` Shuah Khan
2021-03-08  3:53 ` [PATCH 5/6] usbip: fix vhci_hcd attach_store() " Shuah Khan
2021-03-08  3:53 ` [PATCH 6/6] usbip: fix vudc usbip_sockfd_store " Shuah Khan
2021-03-10 18:33 ` [PATCH 0/6] usbip fixes to crashes found by syzbot Greg KH
2021-03-11 12:34   ` Tetsuo Handa
2021-03-11 12:57     ` Greg KH
2021-03-11 13:24       ` Tetsuo Handa
2021-03-12  5:44         ` Tetsuo Handa
2021-03-13  0:48           ` Tetsuo Handa
2021-03-14 11:38             ` Tetsuo Handa
2021-03-17  6:21               ` Tetsuo Handa
2021-03-17 15:06                 ` Shuah Khan
2021-03-17 15:38                   ` Tetsuo Handa
2021-03-17 17:09                     ` Shuah Khan
2021-03-18 13:13                   ` Shuah Khan
2021-03-18 13:39                     ` Tetsuo Handa

Reply instructions:

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=05e8e744-0847-cde2-b978-0bfd7ef93a9f@linuxfoundation.org \
    --to=skhan@linuxfoundation.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=shuah@kernel.org \
    --cc=valentina.manea.m@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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.