On Fri, 2018-10-19 at 15:55 -0400, Douglas Gilbert wrote:
> On 2018-10-19 11:22 a.m., Bart Van Assche wrote:
> > On Fri, 2018-10-19 at 02:24 -0400, Douglas Gilbert wrote:
> > > static void
> > > -sg_fill_request_table(struct sg_fd *sfp, struct sg_req_info *rinfo)
> > > +sg_fill_request_table(struct sg_fd *sfp, struct sg_req_info *rinfo,
> > > + int max_num)
> > > {
> > > struct sg_request *srp;
> > > int val;
> > > - unsigned int ms;
> > >
> > > val = 0;
> > > - list_for_each_entry(srp, &sfp->rq_list, entry) {
> > > - if (val >= SG_MAX_QUEUE)
> > > - break;
> > > - rinfo[val].req_state = srp->done + 1;
> > > + list_for_each_entry(srp, &sfp->rq_list, rq_entry) {
> > > + if (val >= max_num)
> > > + return;
> >
> > What protects the sfp->rq_list against concurrent changes? It seems to me
> > like all other code that iterates over or modifies that list protects that
> > list with rq_list_lock?
>
> Bart,
> The function is called from sg_ioctl() case SG_GET_REQUEST_TABLE and at the
> call point the read_lock is held on rq_list_lock. Maybe I can add a comment
> above the function about the lock being held. [At least it is as the end
> of the patch series, and that is all I care about :-)]
Hi Doug,
Thanks for the clarification. How about adding a __must_hold() annotation?
Bart.
