NetBSD Problem Report #25118

Received: (qmail 11726 invoked by uid 605); 9 Apr 2004 19:51:06 -0000
Message-Id: <20040409195104.014071115F@narn.netbsd.org>
Date: Fri,  9 Apr 2004 19:51:04 +0000 (UTC)
From: steven@qcr.com
Sender: gnats-bugs-owner@NetBSD.org
Reply-To: steven@qcr.com
To: gnats-bugs@gnats.NetBSD.org
Subject: semop() fails with EINVAL even when SEMUME is increased
X-Send-Pr-Version: www-1.0

>Number:         25118
>Category:       kern
>Synopsis:       semop() fails with EINVAL even when SEMUME is increased
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Apr 09 19:52:00 +0000 2004
>Closed-Date:    
>Last-Modified:  Sat Apr 10 23:43:00 +0000 2004
>Originator:     Steven Beard
>Release:        1.6.1, 1.6.2
>Organization:
QCR
>Environment:
NetBSD netbsd 1.6.1 NetBSD 1.6.1 (GENERIC) #0: Tue Apr  8 12:05:52 UTC 2003     autobuild@tgm.daemon.org:/autobuild/netbsd-1-6/i386/OBJ/autobuild/netbsd-1-6/src/sys/arch/i386/compile/GENERIC i386

>Description:
The semop() system call will fail and return EINVAL if more than
10 undo structures are needed. Normally the kernel parameter SEMUME
is used to increase the max # of undo entries per process which
allows semop() succeed. Unfortunately setting the SEMUME value
has no effect on NetBSD 1.6.1.
>How-To-Repeat:

>Fix:
The code in kern/sysv_sem.c incorrectly uses the older SEMUME
#define instead of reading the value from the seminfo structure.

Line 248 of kern/sysv_sem.c

Current code:
	if (suptr->un_cnt == SEMUME)

Correct code:
	if (suptr->un_cnt >= seminfo.semume)
>Release-Note:
>Audit-Trail:

From: Allen Briggs <briggs@wasabisystems.com>
To: steven@qcr.com
Cc: gnats-bugs@gnats.NetBSD.org
Subject: Re: kern/25118: semop() fails with EINVAL even when SEMUME is increased
Date: Fri, 9 Apr 2004 16:25:10 -0400

 On Fri, Apr 09, 2004 at 07:51:04PM +0000, steven@qcr.com wrote:
 > The code in kern/sysv_sem.c incorrectly uses the older SEMUME
 > #define instead of reading the value from the seminfo structure.

 This does not appear to be the entire story, but I've not looked
 much at this code before.  There appears to still be some dependence
 on SEMUSZ in SEMU(ix), which are defined as

 #define SEMU(ix)        ((struct sem_undo *)(((long)semu)+ix * SEMUSZ))
 #define SEMUSZ  (sizeof(struct sem_undo)+sizeof(struct undo)*SEMUME)

 I think there may also be some handling of the "undo structure
 pool" when the # of undos is dynamically increased by changing
 seminfo.semume.

 -allen

 -- 
  Allen Briggs                     briggs@wasabisystems.com
  Wasabi Systems, Inc.             http://www.wasabisystems.com/

From: Simon Burge <simonb@wasabisystems.com>
To: steven@qcr.com
Cc: gnats-bugs@gnats.NetBSD.org, netbsd-bugs@netbsd.org,
  Allen Briggs <briggs@wasabisystems.com>
Subject: Re: kern/25118: semop() fails with EINVAL even when SEMUME is increased 
Date: Sat, 10 Apr 2004 13:44:32 +1000

 Allen Briggs wrote:

 > This does not appear to be the entire story, but I've not looked
 > much at this code before.  There appears to still be some dependence
 > on SEMUSZ in SEMU(ix), which are defined as
 > 
 > #define SEMU(ix)        ((struct sem_undo *)(((long)semu)+ix * SEMUSZ))
 > #define SEMUSZ  (sizeof(struct sem_undo)+sizeof(struct undo)*SEMUME)
 > 
 > I think there may also be some handling of the "undo structure
 > pool" when the # of undos is dynamically increased by changing
 > seminfo.semume.

 It appears that seminfo.semume isn't changable (unless you mean changing
 it with say gdb --write).  I think the original patch in the PR has the
 right effect otherwise.  That said, it looks like changing SEMU to use
 seminfo.semume instead of SEMUME would be a good idea.

 Simon.
 --
 Simon Burge                            <simonb@wasabisystems.com>
 NetBSD Support and Service:         http://www.wasabisystems.com/

From: enami tsugutomo <enami@but-b.or.jp>
To: Simon Burge <simonb@wasabisystems.com>
Cc: gnats-bugs@gnats.NetBSD.org, netbsd-bugs@netbsd.org,
  Allen Briggs <briggs@wasabisystems.com>, steven@qcr.com
Subject: Re: kern/25118: semop() fails with EINVAL even when SEMUME is increased 
Date: Sat, 10 Apr 2004 13:12:22 +0900 (JST)

 > It appears that seminfo.semume isn't changable (unless you mean changing
 > it with say gdb --write).  I think the original patch in the PR has the
 > right effect otherwise.  That said, it looks like changing SEMU to use
 > seminfo.semume instead of SEMUME would be a good idea.

 Simply sysv_sem.c wasn't recompiled since it doesn't include
 opt_sysvparam.h, was it?

 enami.

From: Simon Burge <simonb@wasabisystems.com>
To: enami tsugutomo <enami@but-b.or.jp>
Cc: gnats-bugs@gnats.NetBSD.org, netbsd-bugs@netbsd.org,
  Allen Briggs <briggs@wasabisystems.com>, steven@qcr.com
Subject: Re: kern/25118: semop() fails with EINVAL even when SEMUME is increased 
Date: Sat, 10 Apr 2004 14:20:20 +1000

 enami tsugutomo wrote:

 > > It appears that seminfo.semume isn't changable (unless you mean changing
 > > it with say gdb --write).  I think the original patch in the PR has the
 > > right effect otherwise.  That said, it looks like changing SEMU to use
 > > seminfo.semume instead of SEMUME would be a good idea.
 > 
 > Simply sysv_sem.c wasn't recompiled since it doesn't include
 > opt_sysvparam.h, was it?

 I thought about that too.  I think technically param.c is meant to have
 the changable parameters, and sysv_sem.c should just use what is in
 seminfo and not look at predefined constants.

 This gets back to the "do we want a somehow modified seminfo" to work
 (with "gdb --write" or a newly introduced system call or possibly a
 superuser-only semctl command)?

 Simon.
 --
 Simon Burge                            <simonb@wasabisystems.com>
 NetBSD Support and Service:         http://www.wasabisystems.com/

From: enami tsugutomo <enami@but-b.or.jp>
To: Simon Burge <simonb@wasabisystems.com>
Cc: gnats-bugs@gnats.NetBSD.org, netbsd-bugs@netbsd.org,
  Allen Briggs <briggs@wasabisystems.com>, steven@qcr.com
Subject: Re: kern/25118: semop() fails with EINVAL even when SEMUME is increased 
Date: Sun, 11 Apr 2004 08:42:05 +0900 (JST)

 > I thought about that too.

 I was just wanted to know the original cause of bug.

 > This gets back to the "do we want a somehow modified seminfo" to
 > work (with "gdb --write" or a newly introduced system call or
 > possibly a superuser-only semctl command)?

 ... or, want to remove static limit?

 enami.
>Unformatted:

Home	PR Database Search