W dniu 07.12.2014 o 21:25, Laurent Pinchart pisze:
Hi Andrzej,
<snip>
+ mutex_lock(&opts->lock);
What does the mutex protect against ? Modifications of opts->
uvc_*_streaming_cls by configfs ? You only copy pointers around, what
prevents the descriptors from being modified after you unlock the mutex ?
+ if (opts->uvc_fs_streaming_cls) {
+ strm_cls = opts->uvc_fs_streaming_cls;
+ opts->fs_streaming =
+ (const struct uvc_descriptor_header * const *)strm_cls;
+ }
+ if (opts->uvc_hs_streaming_cls) {
+ strm_cls = opts->uvc_hs_streaming_cls;
+ opts->hs_streaming =
+ (const struct uvc_descriptor_header * const *)strm_cls;
+ }
+ if (opts->uvc_ss_streaming_cls) {
+ strm_cls = opts->uvc_ss_streaming_cls;
+ opts->ss_streaming =
+ (const struct uvc_descriptor_header * const *)strm_cls;
+ }
+
Also modifications of opts->fs_streaming & friends.
My point is that the above code only copies pointers to descriptors created
through configfs, not their content. There doesn't seem to be anything
preventing the user from modifying the descriptors after the pointers have
been copied. Maybe I'm missing something obvious.
The mutex protects opts->fs_streaming & friends from concurrent writes.
As far as the contents of the descriptors created through configfs is
concerned, in the above critical section opts->refcnt is incremented.
Whenever a user wants to modify the descriptors contents, the same
opts->refctnt is looked up (also under the same mutex) and if nonzero,
the modification is refused with -EBUSY.
AP
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
