[Click] ToUserDevice IOCTL

Bobby Longpocket bobbylongpocket at yahoo.com
Wed Feb 2 16:03:39 EST 2011


Hi Joonwoo,

I think it doesn't matter whether the filp is shared by multiple threads or not. The mutex is only protecting the assignment, and the assignment can differ only in the least-significant bit.  No matter how many threads call at once, the stored value will be valid.  There's a race condition as to which thread wins, but that's true even with the mutex.

Regards,
BBL


--- On Wed, 2/2/11, Joonwoo Park <joonwpark81 at gmail.com> wrote:

> From: Joonwoo Park <joonwpark81 at gmail.com>
> Subject: Re: [Click] click Digest, Vol 92, Issue 4
> To: "Bobby Longpocket" <bobbylongpocket at yahoo.com>
> Cc: click at pdos.csail.mit.edu
> Date: Wednesday, February 2, 2011, 11:20 AM
> Bobby,
> 
> On Wed, Feb 2, 2011 at 11:04 AM, Joonwoo Park <joonwpark81 at gmail.com>
> wrote:
> >> In ToUserDevice:  It looks like the existing
> IOCTL isn't doing anything that requires locking, so you
> should be able to leave out the mutex.
> >
> > I don't think so...  filp->private_data is not
> atomic on every platform.
> >
> 
> I have to double check tonight (I'm not accessing click
> source code at
> work) but I think it's possible I was wrong.
> I was thinking that filp->private_data is shared between
> different
> userspace open.  But it's probably not true.
> I'll have look again.
> 
> Thanks!
> Joonwoo
> 


      



More information about the click mailing list