public inbox for ltp@lists.linux.it
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox