svn commit: r356537 - head/sys/kern

[Kyle Evans]

Author: kevans
Date: Thu Jan  9 04:03:17 2020
New Revision: 356537
URL: https://svnweb.freebsd.org/changeset/base/356537

Log:
  shmfd: posix_fallocate(2): only take rangelock for section we need
  
  Other mechanisms that resize the shmfd grab a write lock from 0 to OFF_MAX
  for safety, so we still get proper synchronization of shmfd->shm_size in
  effect. There's no need to block readers/writers of earlier segments when
  we're just reserving more space, so narrow the scope -- it would likely be
  safe to narrow it completely to just the section of the range that extends
  beyond our current size, but this likely isn't worth it since the size isn't
  stable until the writelock is granted the first time.
  
  Suggested by:	cem (passing comment)

Modified:
  head/sys/kern/uipc_shm.c

Modified: head/sys/kern/uipc_shm.c
==============================================================================
--- head/sys/kern/uipc_shm.c	Thu Jan  9 03:52:50 2020	(r356536)
+++ head/sys/kern/uipc_shm.c	Thu Jan  9 04:03:17 2020	(r356537)
@@ -1451,7 +1451,17 @@ shm_fallocate(struct file *fp, off_t offset, off_t len
 	error = 0;
 	shmfd = fp->f_data;
 	size = offset + len;
-	rl_cookie = rangelock_wlock(&shmfd->shm_rl, 0, OFF_MAX,
+
+	/*
+	 * Just grab the rangelock for the range that we may be attempting to
+	 * grow, rather than blocking read/write for regions we won't be
+	 * touching while this (potential) resize is in progress.  Other
+	 * attempts to resize the shmfd will have to take a write lock from 0 to
+	 * OFF_MAX, so this being potentially beyond the current usable range of
+	 * the shmfd is not necessarily a concern.  If other mechanisms are
+	 * added to grow a shmfd, this may need to be re-evaluated.
+	 */
+	rl_cookie = rangelock_wlock(&shmfd->shm_rl, offset, size,
 	    &shmfd->shm_mtx);
 	if (size > shmfd->shm_size) {
 		VM_OBJECT_WLOCK(shmfd->shm_object);