Re: [PATCH 5/8] sg: add free list, rework locking

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 :-)]

Doug Gilbert

P.S. Best to look at sg.c after each patch is applied, not the !@#$ing
stupid patches.



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux