Re: [PATCH v13 39/45] sg: add mmap_sz tracking

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

 



On 1/13/21 11:45 PM, Douglas Gilbert wrote:
Track mmap_sz from prior mmap(2) call, per sg file descriptor. Also
reset this value whenever munmap(2) is called. Fail SG_FLAG_MMAP_IO
uses if mmap(2) hasn't been called or the memory associated with it
is not large enough for the current request.

Signed-off-by: Douglas Gilbert <dgilbert@xxxxxxxxxxxx>
---
  drivers/scsi/sg.c | 11 +++++++++--
  1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index c5533bbaf0d5..d0f25f8f572b 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -232,6 +232,7 @@ struct sg_fd {		/* holds the state of a file descriptor */
  	atomic_t waiting;	/* number of requests awaiting receive */
  	atomic_t req_cnt;	/* number of requests */
  	int sgat_elem_sz;	/* initialized to scatter_elem_sz */
+	int mmap_sz;		/* byte size of previous mmap() call */
  	unsigned long ffd_bm[1];	/* see SG_FFD_* defines above */
  	pid_t tid;		/* thread id when opened */
  	u8 next_cmd_len;	/* 0: automatic, >0: use on next write() */
@@ -725,10 +726,14 @@ sg_write(struct file *filp, const char __user *p, size_t count, loff_t *ppos)
  static inline int
  sg_chk_mmap(struct sg_fd *sfp, int rq_flags, int len)
  {
+	if (!test_bit(SG_FFD_MMAP_CALLED, sfp->ffd_bm))
+		return -EBADFD;
  	if (atomic_read(&sfp->submitted) > 0)
  		return -EBUSY;  /* already active requests on fd */
  	if (len > sfp->rsv_srp->sgat_h.buflen)
  		return -ENOMEM; /* MMAP_IO size must fit in reserve */
+	if (unlikely(len > sfp->mmap_sz))
+		return -ENOMEM; /* MMAP_IO size can't exceed mmap() size */
  	if (rq_flags & SG_FLAG_DIRECT_IO)
  		return -EINVAL; /* not both MMAP_IO and DIRECT_IO */
  	return 0;
@@ -2262,6 +2267,8 @@ sg_vma_close(struct vm_area_struct *vma)
  		pr_warn("%s: sfp null\n", __func__);
  		return;
  	}
+	sfp->mmap_sz = 0;
+	clear_bit(SG_FFD_MMAP_CALLED, sfp->ffd_bm);
  	kref_put(&sfp->f_ref, sg_remove_sfp); /* get in: sg_vma_open() */
  }
@@ -2383,6 +2390,7 @@ sg_mmap(struct file *filp, struct vm_area_struct *vma)
  			goto fini;
  		}
  	}
+	sfp->mmap_sz = req_sz;
  	vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP;
  	vma->vm_private_data = sfp;
  	vma->vm_ops = &sg_mmap_vm_ops;
@@ -4048,8 +4056,7 @@ sg_proc_debug_fd(struct sg_fd *fp, char *obp, int len, unsigned long idx)
  		       (int)test_bit(SG_FFD_FORCE_PACKID, fp->ffd_bm),
  		       (int)test_bit(SG_FFD_KEEP_ORPHAN, fp->ffd_bm),
  		       fp->ffd_bm[0]);
-	n += scnprintf(obp + n, len - n, "   mmap_called=%d\n",
-		       test_bit(SG_FFD_MMAP_CALLED, fp->ffd_bm));
+	n += scnprintf(obp + n, len - n, "   mmap_sz=%d\n", fp->mmap_sz);
  	n += scnprintf(obp + n, len - n,
  		       "   submitted=%d waiting=%d   open thr_id=%d\n",
  		       atomic_read(&fp->submitted),

What is the point of having the SG_FFD_MMAP_CALLED bit now?
Doesn't the new 'mmap_sz' value carry the same information?

Cheers,

Hannes
--
Dr. Hannes Reinecke                Kernel Storage Architect
hare@xxxxxxx                              +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer



[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