All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] syscalls/shmctl05.c: Fix ENOSPC error
Date: Thu, 23 Aug 2018 21:27:02 -0700	[thread overview]
Message-ID: <20180824042701.GA12266@sol.localdomain> (raw)
In-Reply-To: <1533108893-13078-1-git-send-email-yangx.jy@cn.fujitsu.com>

Hi Xiao,

On Wed, Aug 01, 2018 at 03:34:53PM +0800, Xiao Yang wrote:
> Running shmctl05 got the following error on some distros(e.g. RHEL7.5):
> ------------------------------------------------------
> tst_safe_sysv_ipc.c:111: BROK: shmctl05.c:51: shmget(61455, 4096, 3c0) failed: ENOSPC
> shmctl05.c:104: WARN: pthread_join(..., (nil)) failed: EDEADLK
> tst_safe_sysv_ipc.c:111: BROK: shmctl05.c:81: shmget(61455, 4096, 3c0) failed: ENOSPC
> -------------------------------------------------------
> 
> From shmctl(2) manpage, shmctl(IPC_RMID) just marks a shm segment to
> be destroyed, and the segment will only actually be destroyed after
> the last process detaches it (i.e., when the shm_nattch member of the
> associated structure shmid_ds is zero).  So it is possible for the
> number of created shm segments to exceed the system-wide maximum number
> (e.g. shmmni is 4096) if only shmctl(IPC_RMID) has been called.
> 
> From shmdt(2) manpage, a successful shmdt(2) call will decrement
> the shm_nattch by one.  So we should call shmdt(2) to decrement
> the shm_nattch to zero before calling shmctl(IPC_RMID).
> 
> Add shmdt(2) to ensure that all shm segments are actually destroyed.
> 
> Signed-off-by: Xiao Yang <yangx.jy@cn.fujitsu.com>
> ---
>  testcases/kernel/syscalls/ipc/shmctl/shmctl05.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/testcases/kernel/syscalls/ipc/shmctl/shmctl05.c b/testcases/kernel/syscalls/ipc/shmctl/shmctl05.c
> index a960cc9..0eb0776 100644
> --- a/testcases/kernel/syscalls/ipc/shmctl/shmctl05.c
> +++ b/testcases/kernel/syscalls/ipc/shmctl/shmctl05.c
> @@ -92,6 +92,8 @@ static void do_test(void)
>  				"Unexpected remap_file_pages() error");
>  		}
>  		tst_fzsync_wait_a(&fzsync_pair);
> +		/* ensure that a shm segment will actually be destroyed */
> +		SAFE_SHMDT(addr);
>  	}
>  
>  	tst_res(TPASS, "didn't crash");
> -- 

I think you missed part of the explanation for why this test (apparently) fails
on old kernels.  On recent kernels, remap_file_pages() *is* unmapping the shm
segment, so the test passes.  Perhaps the behavior of remap_file_pages() changed
in v4.0 when its implementation was replaced with an emulation.

Calling shmdt() is probably the right fix for the test, but you shouldn't call
the SAFE_* version since shmdt() will fail with an error on recent kernels,
which with the SAFE_* version would fail the test.

- Eric

  reply	other threads:[~2018-08-24  4:27 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-01  7:34 [LTP] [PATCH] syscalls/shmctl05.c: Fix ENOSPC error Xiao Yang
2018-08-24  4:27 ` Eric Biggers [this message]
2018-08-28 11:27   ` Jan Stancek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180824042701.GA12266@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=ltp@lists.linux.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.