NetBSD Problem Report #44807

From jruohone@gmail.com  Wed Mar 30 18:14:57 2011
Return-Path: <jruohone@gmail.com>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id 08C1963BC20
	for <gnats-bugs@gnats.netbsd.org>; Wed, 30 Mar 2011 18:14:57 +0000 (UTC)
Message-Id: <20110330181448.3AF1056C5@marx.bitnet>
Date: Wed, 30 Mar 2011 21:14:48 +0300 (EEST)
From: Jukka Ruohonen <jruohonen@iki.fi>
Sender: a b <jruohone@gmail.com>
Reply-To: jruohonen@iki.fi
To: gnats-bugs@gnats.NetBSD.org
Subject: something broken in stat(2)
X-Send-Pr-Version: 3.95

>Number:         44807
>Category:       lib
>Synopsis:       something broken in stat(2)
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    hannken
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Mar 30 18:15:00 +0000 2011
>Closed-Date:    Sun Jul 24 09:59:09 +0000 2011
>Last-Modified:  Sun Jul 24 09:59:09 +0000 2011
>Originator:     Jukka Ruohonen
>Release:        5.1 - 5.99.48
>Organization:
-
>Environment:

>Description:

Another one caught by automated tests.

Something related to stat(2) is seriously broken somewhere. For instance,
opening "/dev/bpf" and stat'ing it either fails or reports odd results.

While I haven't done any analysis, it seems that this might be related to
the old, closed, bugs:

	PR kern/37550: fstat(1) not reporting open descriptors properly
	PR kern/37878: fdclone(9) suspected of not working well with fstat(1)

Given that those were fixed, it seems that this is again a regression.

>How-To-Repeat:

To add more weirdness, the following program prints a value 0 on 5.99.48,
but the fstat(2) fails on 5.1.

#include <sys/stat.h>

#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

int
main(void)
{
	struct stat st;
	int fd, rv;

	(void)memset(&st, 0, sizeof(struct stat));

	fd = open("/dev/bpf", O_RDONLY);

	if (fd < 0)
		return EXIT_FAILURE;

	rv = fstat(fd, &st);

	if (rv < 0)
		return EXIT_FAILURE;

	(void)printf("mode = %u\n", st.st_mode);
	(void)close(fd);

	return EXIT_SUCCESS;
}

>Fix:

Unknown.

>Release-Note:

>Audit-Trail:
From: "Jukka Ruohonen" <jruoho@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/44807 CVS commit: src/tests/include
Date: Wed, 30 Mar 2011 18:31:16 +0000

 Module Name:	src
 Committed By:	jruoho
 Date:		Wed Mar 30 18:31:15 UTC 2011

 Modified Files:
 	src/tests/include: t_paths.c

 Log Message:
 Another proof that even the naive test cases are worth it;
 expect a failure with fstat(2) and bpf(4), PR lib/44807.


 To generate a diff of this commit:
 cvs rdiff -u -r1.1 -r1.2 src/tests/include/t_paths.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, lib-bug-people@netbsd.org, 
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc: 
Subject: Re: lib/44807: something broken in stat(2)
Date: Wed, 30 Mar 2011 14:38:39 -0400

 On Mar 30,  6:15pm, jruohonen@iki.fi (Jukka Ruohonen) wrote:
 -- Subject: lib/44807: something broken in stat(2)

 | >Number:         44807
 | >Category:       lib
 | >Synopsis:       something broken in stat(2)
 | >Confidential:   no
 | >Severity:       serious
 | >Priority:       high
 | >Responsible:    lib-bug-people
 | >State:          open
 | >Class:          sw-bug
 | >Submitter-Id:   net
 | >Arrival-Date:   Wed Mar 30 18:15:00 +0000 2011
 | >Originator:     Jukka Ruohonen
 | >Release:        5.1 - 5.99.48
 | >Organization:
 | -
 | >Description:
 | 
 | Another one caught by automated tests.
 | 
 | Something related to stat(2) is seriously broken somewhere. For instance,
 | opening "/dev/bpf" and stat'ing it either fails or reports odd results.
 | 
 | While I haven't done any analysis, it seems that this might be related to
 | the old, closed, bugs:
 | 
 | 	PR kern/37550: fstat(1) not reporting open descriptors properly
 | 	PR kern/37878: fdclone(9) suspected of not working well with fstat(1)
 | 
 | Given that those were fixed, it seems that this is again a regression.
 | 
 | >How-To-Repeat:
 | 
 | To add more weirdness, the following program prints a value 0 on 5.99.48,
 | but the fstat(2) fails on 5.1.

 It works as expected. /dev/bpf is a cloner, so you get a new instance each
 time you run. The instance does not have a place in the filesystem, so you
 get the "right" information as far as that is concerned.

 $ ./a.out
 dev=[23, 12761]	# major 23 always
 mode=0	# correct
 ino=0	# correct
 nlink=0	# correct
 uid=0	# correct
 gid=0	# correct
 rdev=[0, 0]	# irrelevant
 a=[1301510133, 111864879] Wed Mar 30 14:35:33 2011 # correct times
 m=[1301510133, 111864879] Wed Mar 30 14:35:33 2011 # correct times
 c=[1301510133, 111864879] Wed Mar 30 14:35:33 2011 # correct times
 birth=[1301510133, 111864879] Wed Mar 30 14:35:33 2011 # correct times
 size=0	# correct
 blocks=0	# correct
 blksize=0	# correct
 flags=0	# correct
 gen=0	# correct

 Now fchown on the fd does not work, so :-)


 christos

 ----

 #include <sys/types.h>
 #include <sys/stat.h>
 #include <stdio.h>
 #include <time.h>
 #include <string.h>
 #include <fcntl.h>
 #include <stdlib.h>
 int
 main(void)
 {
         struct stat st;
         int fd, rv;

         (void)memset(&st, 0, sizeof(struct stat));

         fd = open("/dev/bpf", O_RDONLY);

         if (fd < 0)
                 return EXIT_FAILURE;

         rv = fstat(fd, &st);
         (void)close(fd);

         if (rv < 0)
                 return EXIT_FAILURE;

 #define PR(t,f) printf(#f "=%ll" #t "\n", \
     (long long)st.st_ ## f)
 #define PRT(f)  printf(#f "=[%llu, %llu] %s", \
     (long long)st.st_ ## f ## timespec.tv_sec, \
     (long long)st.st_ ## f ## timespec.tv_nsec, \
     ctime(&st.st_ ## f ## timespec.tv_sec))
 #define PRD(f)  printf(#f "=[%llu, %llu]\n", \
     (long long)major(st.st_ ## f), \
     (long long)minor(st.st_ ## f))

         PRD(dev);
         PR(o,mode);
         PR(d,ino);
         PR(d,nlink);
         PR(u,uid);
         PR(u,gid);
         PRD(rdev);
         PRT(a);
         PRT(m);
         PRT(c);
         PRT(birth);
         PR(u,size);
         PR(u,blocks);
         PR(u,blksize);
         PR(x,flags);
         PR(u,gen);

         return EXIT_SUCCESS;
 }


From: Antti Kantee <pooka@cs.hut.fi>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: lib/44807
Date: Wed, 30 Mar 2011 21:49:51 +0300

 His problem is that bpf_stat does not set S_IFCHR in mode.

From: Jukka Ruohonen <jruohonen@iki.fi>
To: gnats-bugs@NetBSD.org
Cc: lib-bug-people@NetBSD.org, gnats-admin@NetBSD.org,
	netbsd-bugs@NetBSD.org, jruohonen@iki.fi
Subject: Re: lib/44807: something broken in stat(2)
Date: Wed, 30 Mar 2011 21:51:08 +0300

 On Wed, Mar 30, 2011 at 06:40:12PM +0000, Christos Zoulas wrote:
 >  It works as expected. /dev/bpf is a cloner, so you get a new instance each
 >  time you run. The instance does not have a place in the filesystem, so you
 >  get the "right" information as far as that is concerned.

 Ah, right. Does this imply that decades old UNIX semantics are no longer
 valid in NetBSD; I can not open a "/dev/FOO", stat(2) it, and see whether it
 is a block or character device? How do I know whether "/dev/FOO" is a cloner
 and "/dev/BAR" is not? Is this not a bug?

 - Jukka.

From: christos@zoulas.com (Christos Zoulas)
To: jruohonen@iki.fi, gnats-bugs@NetBSD.org
Cc: lib-bug-people@NetBSD.org, gnats-admin@NetBSD.org, 
	netbsd-bugs@NetBSD.org
Subject: Re: lib/44807: something broken in stat(2)
Date: Wed, 30 Mar 2011 17:30:34 -0400

 On Mar 30,  9:51pm, jruohonen@iki.fi (Jukka Ruohonen) wrote:
 -- Subject: Re: lib/44807: something broken in stat(2)

 | On Wed, Mar 30, 2011 at 06:40:12PM +0000, Christos Zoulas wrote:
 | >  It works as expected. /dev/bpf is a cloner, so you get a new instance each
 | >  time you run. The instance does not have a place in the filesystem, so you
 | >  get the "right" information as far as that is concerned.
 | 
 | Ah, right. Does this imply that decades old UNIX semantics are no longer
 | valid in NetBSD; I can not open a "/dev/FOO", stat(2) it, and see whether it
 | is a block or character device? How do I know whether "/dev/FOO" is a cloner
 | and "/dev/BAR" is not? Is this not a bug?

 Ok, i did not get that part. I will make it set char.

 christos

State-Changed-From-To: open->closed
State-Changed-By: jruoho@NetBSD.org
State-Changed-When: Wed, 30 Mar 2011 22:27:46 +0000
State-Changed-Why:

Fixed, thanks.



State-Changed-From-To: closed->open
State-Changed-By: jruoho@NetBSD.org
State-Changed-When: Fri, 01 Apr 2011 04:14:15 +0000
State-Changed-Why:

It seems that this was closed prematurely. The issue is still present.



From: "Juergen Hannken-Illjes" <hannken@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/44807 CVS commit: src
Date: Sat, 23 Jul 2011 14:28:29 +0000

 Module Name:	src
 Committed By:	hannken
 Date:		Sat Jul 23 14:28:28 UTC 2011

 Modified Files:
 	src/sys/dev/putter: putter.c
 	src/tests/include: t_paths.c

 Log Message:
 putter_fop_stat(): set st_mode to S_IFCHR.

 Fixes PR #44807: something broken in stat(2).


 To generate a diff of this commit:
 cvs rdiff -u -r1.31 -r1.32 src/sys/dev/putter/putter.c
 cvs rdiff -u -r1.6 -r1.7 src/tests/include/t_paths.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

Responsible-Changed-From-To: lib-bug-people->hannken
Responsible-Changed-By: hannken@NetBSD.org
Responsible-Changed-When: Sun, 24 Jul 2011 09:59:09 +0000
Responsible-Changed-Why:
Take.


State-Changed-From-To: open->closed
State-Changed-By: hannken@NetBSD.org
State-Changed-When: Sun, 24 Jul 2011 09:59:09 +0000
State-Changed-Why:
Fixed with rev. 1.32 of sys/dev/putter/putter.c - include/t_paths passed.


>Unformatted:

Home	PR Database Search