NetBSD Problem Report #41068

From www@NetBSD.org  Tue Mar 24 22:00:03 2009
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id 6519A63B8DE
	for <gnats-bugs@gnats.netbsd.org>; Tue, 24 Mar 2009 22:00:03 +0000 (UTC)
Message-Id: <20090324220003.34DD063B8BA@www.NetBSD.org>
Date: Tue, 24 Mar 2009 22:00:03 +0000 (UTC)
From: joerg@NetBSD.org
Reply-To: joerg@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: tmpfs assertion "cookie != TMPFS_DIRCOOKIE_DOT"
X-Send-Pr-Version: www-1.0

>Number:         41068
>Category:       kern
>Synopsis:       tmpfs assertion "cookie != TMPFS_DIRCOOKIE_DOT"
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    rmind
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Mar 24 22:05:00 +0000 2009
>Closed-Date:    Fri Nov 08 15:59:32 +0000 2013
>Last-Modified:  Fri Nov 08 15:59:32 +0000 2013
>Originator:     Joerg Sonnenberger
>Release:        NetBSD 5.0rc2
>Organization:
TNF
>Environment:
NetBSD testpkgbuild.ssr.univ-paris7.fr 5.0_RC2 NetBSD 5.0_RC2 (GENERIC) #3: Wed Mar  4 14:07:00 CET 2009  root@testpkgbuild.ssr.univ-paris7.fr:/stable/src/sys/arch/amd64/compile/GENERIC amd64

>Description:
kernel diagnostic assertion "cookie != TMPFS_DIRCOOKIE_DOT" failed: file "../../../../fs/tmpfs/tmpfs.h", line 144

__kernassert() at netbsd:__kernassert+0x2d
tmpfs_dir_getdotdotdent() at netbsd:tmpfs_dir_getdotdotdent+0x1a4
tmpfs_readdir() at netbsd:tmpfs_readdir+0x2ed
VOP_READDIR() at netbsd:VOP_READDIR+0x75
vn_readdir() at netbsd:vn_readdir+0x110
sys___getdents30() at netbsd:sys___getdents30+0x89
syscall() at netbsd:syscall+0xb6
>How-To-Repeat:
Unknown, happened during bulk build. This is the first time this has appeared.
>Fix:

>Release-Note:

>Audit-Trail:
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/41068: tmpfs assertion
Date: Sun, 5 Apr 2009 05:02:56 +0000

 On Tue, Mar 24, 2009 at 10:05:00PM +0000, joerg@NetBSD.org wrote:
  > kernel diagnostic assertion "cookie != TMPFS_DIRCOOKIE_DOT" failed: file "../../../../fs/tmpfs/tmpfs.h", line 144

 from the code:

  : #define	TMPFS_DIRCOOKIE_DOT	0
  :   :
  : 
  : static __inline
  : off_t
  : tmpfs_dircookie(struct tmpfs_dirent *de)
  : {
  :         off_t cookie;
  : 
  :         cookie = ((off_t)(uintptr_t)de >> 1) & 0x7FFFFFFF;
  :         KASSERT(cookie != TMPFS_DIRCOOKIE_DOT);

 This cookie scheme is clearly not workable.

 Why doesn't it just assign sequence numbers to each node or something?

 -- 
 David A. Holland
 dholland@netbsd.org

From: Joerg Sonnenberger <joerg@britannica.bec.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/41068: tmpfs assertion
Date: Mon, 6 Apr 2009 01:07:12 +0200

 On Sun, Apr 05, 2009 at 05:05:05AM +0000, David Holland wrote:
 >   : static __inline
 >   : off_t
 >   : tmpfs_dircookie(struct tmpfs_dirent *de)
 >   : {
 >   :         off_t cookie;
 >   : 
 >   :         cookie = ((off_t)(uintptr_t)de >> 1) & 0x7FFFFFFF;
 >   :         KASSERT(cookie != TMPFS_DIRCOOKIE_DOT);
 >  
 >  This cookie scheme is clearly not workable.
 >  
 >  Why doesn't it just assign sequence numbers to each node or something?

 Because Linux compat would fall apart with that rather badly.

 Joerg

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/41068: tmpfs assertion
Date: Wed, 8 Apr 2009 02:44:29 +0000

 On Mon, Apr 06, 2009 at 02:00:07PM +0000, Joerg Sonnenberger wrote:
  >>  This cookie scheme is clearly not workable.
  >>  
  >>  Why doesn't it just assign sequence numbers to each node or something?
  >  
  > Because Linux compat would fall apart with that rather badly.

 Linux compat would fall over on small integers? What on earth are they
 doing? 

 -- 
 David A. Holland
 dholland@netbsd.org

From: Joerg Sonnenberger <joerg@britannica.bec.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/41068: tmpfs assertion
Date: Wed, 8 Apr 2009 12:05:05 +0200

 On Wed, Apr 08, 2009 at 02:45:02AM +0000, David Holland wrote:
 > The following reply was made to PR kern/41068; it has been noted by GNATS.
 > 
 > From: David Holland <dholland-bugs@netbsd.org>
 > To: gnats-bugs@NetBSD.org
 > Cc: 
 > Subject: Re: kern/41068: tmpfs assertion
 > Date: Wed, 8 Apr 2009 02:44:29 +0000
 > 
 >  On Mon, Apr 06, 2009 at 02:00:07PM +0000, Joerg Sonnenberger wrote:
 >   >>  This cookie scheme is clearly not workable.
 >   >>  
 >   >>  Why doesn't it just assign sequence numbers to each node or something?
 >   >  
 >   > Because Linux compat would fall apart with that rather badly.
 >  
 >  Linux compat would fall over on small integers? What on earth are they
 >  doing? 

 What small numbers do you have in mind? If you don't want to do all the
 dance with checking for duplicates, you have to use 64bit numbers.
 ...and those are a problem for 32bit readdir applications.

 Joerg

From: Andrew Doran <ad@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/41068: tmpfs assertion
Date: Wed, 8 Apr 2009 19:16:26 +0000

 On Wed, Apr 08, 2009 at 10:10:05AM +0000, Joerg Sonnenberger wrote:

 >  >  On Mon, Apr 06, 2009 at 02:00:07PM +0000, Joerg Sonnenberger wrote:
 >  >   >>  This cookie scheme is clearly not workable.
 >  >   >>  
 >  >   >>  Why doesn't it just assign sequence numbers to each node or something?
 >  >   >  
 >  >   > Because Linux compat would fall apart with that rather badly.
 >  >  
 >  >  Linux compat would fall over on small integers? What on earth are they
 >  >  doing? 
 >  
 >  What small numbers do you have in mind? If you don't want to do all the
 >  dance with checking for duplicates, you have to use 64bit numbers.
 >  ...and those are a problem for 32bit readdir applications.

 It could be solved by creating a vmem. See subr_percpu.c. This would give
 mostly lockless allocation of IDs and could also be used for inode numbers.

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/41068: tmpfs assertion
Date: Wed, 15 Apr 2009 15:23:27 +0000

 On Wed, Apr 08, 2009 at 10:10:05AM +0000, Joerg Sonnenberger wrote:
  >>>>  This cookie scheme is clearly not workable.
  >>>>  
  >>>>  Why doesn't it just assign sequence numbers to each node or something?
  >>>  
  >>> Because Linux compat would fall apart with that rather badly.
  >>  
  >>  Linux compat would fall over on small integers? What on earth are they
  >>  doing? 
  >  
  >  What small numbers do you have in mind? If you don't want to do all the
  >  dance with checking for duplicates, you have to use 64bit numbers.
  >  ...and those are a problem for 32bit readdir applications.

 Small integers starting at 3 and incrementing by 1?

 In the worst case you'd have to run some compaction code once each
 time 2 billion files were cycled through a directory.

 I don't see what the problem is.

 -- 
 David A. Holland
 dholland@netbsd.org

From: "Mindaugas Rasiukevicius" <rmind@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/41068 CVS commit: src/sys/fs/tmpfs
Date: Fri, 8 Nov 2013 15:44:23 +0000

 Module Name:	src
 Committed By:	rmind
 Date:		Fri Nov  8 15:44:23 UTC 2013

 Modified Files:
 	src/sys/fs/tmpfs: tmpfs.h tmpfs_rename.c tmpfs_subr.c tmpfs_vfsops.c
 	    tmpfs_vnops.c

 Log Message:
 tmpfs: replace the broken tmpfs_dircookie() logic which uses the node
 address truncated to 31 bits (required for 32-bit readdir compatibility,
 e.g. linux32).  Instead, assign 2^31 range using the following logic:
 - The first half of the 2^31 is assigned incrementally (the fast path).
 - When exceeded, use the second half of 2^31, but manage with vmem(9).

 It will require 2 billion files per-directory to trigger vmem(9) usage.
 Also, while here, add some fixes for tmpfs_unmount().

 Should fix PR/47739, PR/47480, PR/46088 and PR/41068.
 Thanks to wiz@ for stress testing.


 To generate a diff of this commit:
 cvs rdiff -u -r1.45 -r1.46 src/sys/fs/tmpfs/tmpfs.h
 cvs rdiff -u -r1.4 -r1.5 src/sys/fs/tmpfs/tmpfs_rename.c
 cvs rdiff -u -r1.82 -r1.83 src/sys/fs/tmpfs/tmpfs_subr.c
 cvs rdiff -u -r1.52 -r1.53 src/sys/fs/tmpfs/tmpfs_vfsops.c
 cvs rdiff -u -r1.105 -r1.106 src/sys/fs/tmpfs/tmpfs_vnops.c

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

Responsible-Changed-From-To: kern-bug-people->rmind
Responsible-Changed-By: rmind@NetBSD.org
Responsible-Changed-When: Fri, 08 Nov 2013 15:59:32 +0000
Responsible-Changed-Why:


State-Changed-From-To: open->closed
State-Changed-By: rmind@NetBSD.org
State-Changed-When: Fri, 08 Nov 2013 15:59:32 +0000
State-Changed-Why:
Should be fixed in -current.  Please let us know if you will ever see a
similar problem again.


>Unformatted:

Home	PR Database Search