fa.netbsd.tech.kern
[Top] [All Lists]

Re: PR 36963

Subject: Re: PR 36963
From: Adam Hamsik
Date: Wed, 19 Sep 2007 09:54:40 UTC
Newsgroups: fa.netbsd.tech.kern


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Sep 19, 2007, at 3:55 AM, Jan Danielsson wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

David Holland wrote:
On Wed, Sep 19, 2007 at 02:39:02AM +0200, Jan Danielsson wrote:
http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=36963
[...]

Are you running a multiprocessor kernel?

   No; just a single processor. Unfortunately.

(And if you haven't yet, try turning on DIAGNOSTIC and LOCKDEBUG.)

   I haven't done that; I'll be sure to do that on next rebuild.

   I would just like to check if anyone has any interest in this
problem.

Definitely - the more information you can collect, the better.

Good; I just wanted to know that I'm not wasting my time posting all
this information to the PR.

One useful thing to find out would be whether, after things stop
working, the process credentials stored in the kernel are still
correct or if they've been garbaged.

   As far as I can tell, they aren't garbled I'm pretty sure I've done
this: I open a terminal window, su to my pkgsrc user, run "ls -l", which
will fail, then run the "jan" login/logout procedure, return to the
(still open) pkgsrc terminal window, and run "ls -l" without any
problems. I'm not 100% sure that I have done this; although I'm pretty
sure. I believe that behavior would be unlikely to work if the
permissions have been garbled. (I can't test it right now, because I
just logged in/out with my normal user, so the permission problem is not
"active"). I'll be sure to try when it appears again.

When things break, does running
"id" print right or wrong information?

   "id" returns the correct information even when the problem is
"active". As does "user info".

So we have permission denied error even we have good information.
Also, does ls -l (or
stat(2)/fstat(2) if necessary(*)) return the right owner/group and
permissions for the affected files?

What the fork? This is a behavior I hadn't noticed before (though I'm very certain it has always been there -- I just haven't seen it until now):

nl102-238-202# su - pkgsrc
$ ls -l
ls: .: Permission denied
$ ls -l update_wip
- -rwx------  1 pkgsrc  users  158 Jun 18 05:15 update_wip
$ ls -l
ls: .: Permission denied
$ ls -l upda*
ls: upda*: No such file or directory
$ ls -l *
ls: *: No such file or directory
$ ls -l .
ls: .: Permission denied
$ ls -l ..
ls: ..: Permission denied
$ ls -l /
ls: /: Permission denied
$ pwd
/home/pkgsrc
<Here I logged in, and then logged out, my "jan" user>
$ ls -l
total 152
- -rwx------     1 pkgsrc  users    219 Sep  8 20:51 checkout_pkgsrc
- -rwx------     1 pkgsrc  users    282 Jun 18 04:31 checkout_wip
- -rwx------     1 pkgsrc  users    173 Sep  8 20:51 update_pkgsrc
- -rwx------     1 pkgsrc  users    158 Jun 18 05:15 update_wip
drwxr-xr-x  1797 pkgsrc  users  68608 Aug 11 16:41 wip
$ ls -l /
total 18411
drwxr-xr-x   2 root  wheel      512 Sep  5 14:42 altroot
drwxr-xr-x   2 root  wheel     1024 Sep  5 16:57 bin
[---]

What about kauth(9) ? Can be this some unfound kauth issue lfs was not used too much when elad written kauth? Can you ktrace/ktruss failing ls ?

It's actually only the first few commands which are interesting (the
rest is old news -- I just wanted to show my cool problem off some
more). Notice that "ls" works when I specify an exact file name(!). I'll start working on my speech for when I accept the yearly "wtf?!"- prize. :(

Also, this is what happens when I run "cvs update -dP" in pkgsrc (it
appears to actually update the repsitory, although I don't think it
manages to create new directories), but it ends with:

[---]
cvs update: cannot open directory archivers/arc/files for empty check:
Permission denied
cvs update: cannot open directory archivers/arc for empty check:
Permission denied
cvs update: cannot open directory archivers/afio/patches for empty
check: Permission denied
cvs update: cannot open directory archivers/afio for empty check:
Permission denied
cvs update: cannot open directory archivers/advancecomp/patches for
empty check: Permission denied
cvs update: cannot open directory archivers/advancecomp for empty check:
Permission denied
cvs update: cannot open directory archivers/9e/patches for empty check:
Permission denied
cvs update: cannot open directory archivers/9e for empty check:
Permission denied
cvs update: cannot open directory archivers for empty check: Permission
denied


(*) E.g., if once it breaks you can't ls -l, or even call stat()
successfully, you can write a program that opens the file (or
directory) before things break, waits until they do, and then uses
fstat() on that file handle. This should get past any broken
permissions checks. It might also conceivably prevent the problem from
affecting the file in question...

   I'll do that. But I'm pretty sure that it's only file/directory
_enumerations_ which fail. Hmm... I'll try to write a program which runs opendir(), lists a few files, and then calls readdir() (or whatever it's called), and pauses before continuing. Then I'll instruct it to continue
once the bug reappears.

Did you see the program I posted in the PR? It show that opendir (".") fails when the "bug" is "active"; but I can "cat" files I know to exist without problems. I think that's a good place to start looking. Though I
may be staring myself blind on the opendir() issue. :/


- --
Kind regards,
Jan Danielsson

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)

iD8DBQFG8IGKuPlHKFfKXTYRCkoZAJ4rGFG9RJDFJNWGMmcc6Kg1Uw72NACfcmNr
2uiH/wQ9dru4AOq1thFZeBY=
=bq1C
-----END PGP SIGNATURE-----

Regards
- -----------------------------------------
Adam Hamsik
jabber: haad@xxxxxxxxxx
icq: 249727910

Proud NetBSD user.

We program to have fun.
Even when we program for money, we want to have fun as well.
~ Yukihiro Matsumoto




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFG8PA9lIxPgX3Go0MRApliAKCE0orpVYSlUhqYK7Sq4u+7THc7/wCeP1JP
nBRSswJ771Vlrz/fQU0Ndpk=
=CEaX
-----END PGP SIGNATURE-----

<Prev in Thread] Current Thread [Next in Thread>