Messages in this thread | | | From | Alexandre Courbot <> | Date | Tue, 12 Feb 2013 11:27:54 +0900 | Subject | Re: [PATCH] gpiolib: Fix locking on gpio debugfs files |
| |
On Mon, Feb 11, 2013 at 8:31 PM, Grant Likely <grant.likely@secretlab.ca> wrote: > On Mon, Feb 11, 2013 at 4:28 AM, Alex Courbot <acourbot@nvidia.com> wrote: >> Just wondering: if we manage to change this spinlock into a mutex in the >> future, wouldn't it be better to acquire it only once in gpiolib_seq_start() >> and release it in gpiolib_seq_stop()? >> >> Even though the protection introduced by this patch definitely improves the >> situation, it seems to me that chips could still be removed while being >> displayed by gpiolib_seq_show(). > > Probably, but need to first verify that the mutex won't end up getting > held between read() syscalls. Otherwise it would be possible to block > addition/removal by holding the file open. I cursory read of seq_file > looks like ->stop() is always called, but I would appreciate someone > more cluefull to give an opinion here.
While not cluefull in any way, I nonetheless had a quick look at all the control paths of seq_read(), and indeed op->stop() seems to be called in each of them.
> I've also got a draft patch that turns gpio chips into first-class > kobjects which means we can do proper reference counting on them and > prevent the structure from actually disappearing while other drivers > still hold references.
Oooh. Looking forward to seeing this. :)
Alex.
| |