Re: [PATCH v2 00/19] prevent bounds-check bypass via speculative execution

2018-01-18 Thread Laurent Pinchart
s > > masking if those users already integrate the limit check, and lfence > > they don't." > > > > ...which translates to narrow the pointer for get_user() and use a > > barrier for __get_user(). > > Great, that matches my thinking re set_fs but I'm still worried about > finding all the places where the bound is conditional for other users > of the macro. Then again, finding the places that need this macro in the > first place is tough enough so perhaps analysing the bound calculation > doesn't make it much worse. It might not now, but if the bound calculation changes later, I'm pretty sure we'll forget to update the speculation barrier macro at least in some cases. Without the help of static (or possibly dynamic) code analysis I think we're bound to reintroduce problems over time, but that's true for finding places where the barrier is needed, not just for barrier selection based on bound calculation. -- Regards, Laurent Pinchart

Re: [PATCH v2 02/15] usb: gadget: make config_item_type structures const

2017-10-19 Thread Laurent Pinchart
think that's a good idea. > > But I'm about to slurp up this whole series into my tree, how about making > that an incremental patch? I'm fine with that. Bhumika, would you like to submit an incremental patch, or should I do it ? -- Regards, Laurent Pinchart

Re: [PATCH v2 02/15] usb: gadget: make config_item_type structures const

2017-10-18 Thread Laurent Pinchart
+static const struct config_item_type uvcg_streaming_class_grp_type = { > .ct_owner = THIS_MODULE, > }; > > @@ -2104,7 +2104,7 @@ static void uvcg_streaming_class_drop_link(struct > config_item *src, struct config_group group; > } uvcg_streaming_grp; > > -static struct config_item_type uvcg_streaming_grp_type = { > +static const struct config_item_type uvcg_streaming_grp_type = { > .ct_owner = THIS_MODULE, > }; Now we have 9 const instances of the config_item_type structure that are identical, with only the .ct_owner field set. Should they be all merged into a single structure ? > @@ -2190,7 +2190,7 @@ static void uvc_attr_release(struct config_item *item) > NULL, > }; > > -static struct config_item_type uvc_func_type = { > +static const struct config_item_type uvc_func_type = { > .ct_item_ops= &uvc_item_ops, > .ct_attrs = uvc_attrs, > .ct_owner = THIS_MODULE, -- Regards, Laurent Pinchart

Re: [PATCH 31/51] DMA-API: media: omap3isp: use dma_coerce_mask_and_coherent()

2013-09-26 Thread Laurent Pinchart
(32); > bypasses the architectures check on the DMA mask. It can be replaced > with dma_coerce_mask_and_coherent(), avoiding the direct initialization > of this mask. > > Signed-off-by: Russell King Acked-by: Laurent Pinchart > --- > drivers/media/platform/omap3isp/isp.c