All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: madhuparnabhowmik10@gmail.com
Cc: hariprasad.kelam@gmail.com, colin.king@canonical.com,
	tony.olech@elandigitalsystems.com, linux-usb@vger.kernel.org,
	linux-kernel@vger.kernel.org, andrianov@ispras.ru
Subject: Re: Possible data-race related bug in u132_hcd module.
Date: Mon, 30 Mar 2020 14:02:07 +0200	[thread overview]
Message-ID: <20200330120207.GA2807@kroah.com> (raw)
In-Reply-To: <20200330115243.11107-1-madhuparnabhowmik10@gmail.com>

On Mon, Mar 30, 2020 at 05:22:43PM +0530, madhuparnabhowmik10@gmail.com wrote:
> Hi,
> 
> This bug is found by  Linux Driver Verification project (linuxtesting.org).
> 
> The bug is related to the parallel execution of u132_probe() function and u132_hcd_exit() function in u132_hcd.c. In case the module is unloaded when the probe function is executing there can be data race as the mutex lock u132_module_lock is not used properly. 

Please note that module unloading, while a nice thing to have, is never
something that happens automatically :)

> i) Usage of mutex lock only when writing into the u132_exiting variable in u132_hcd_exit(). The lock is not used when this variable is read in u132_probe().
> 
> Moreover, this variable does not serve its purpose, as even if locking is used while the u132_exiting variable is read in probe(), the function may still miss that exit function is executing if it acquires the mutex before exit() function does.
> 
> How to fix this?
> 
> ii) Usage of mutex while adding entries in u132_static_list in probe function but not in exit function while unregistering.
> This should be easy to fix by holding the mutex in the exit function as well.
> 
> There can be other synchronization problems related to the usage of u132_module_lock in this module, I have only spotted these so far.
> 
> Please let me know if this bug report is helpful and I can send a patch fixing it.

Please just send a patch, no need to ever ask if you should, that's the
best way to report and fix anything.

thanks,

greg k-h

  reply	other threads:[~2020-03-30 12:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-30 11:52 Possible data-race related bug in u132_hcd module madhuparnabhowmik10
2020-03-30 12:02 ` Greg KH [this message]
2020-03-30 12:25   ` Madhuparna Bhowmik
2020-03-30 16:03 ` Alan Stern
2020-03-30 17:20   ` Madhuparna Bhowmik

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=20200330120207.GA2807@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=andrianov@ispras.ru \
    --cc=colin.king@canonical.com \
    --cc=hariprasad.kelam@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=madhuparnabhowmik10@gmail.com \
    --cc=tony.olech@elandigitalsystems.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.