NetBSD Problem Report #31430

From simonb@thistledown.com.au  Fri Sep 30 14:41:53 2005
Return-Path: <simonb@thistledown.com.au>
Received: from thoreau.thistledown.com.au (thoreau.thistledown.com.au [203.217.30.154])
	by narn.netbsd.org (Postfix) with ESMTP id D377063B8C8
	for <gnats-bugs@gnats.NetBSD.org>; Fri, 30 Sep 2005 14:41:52 +0000 (UTC)
Message-Id: <20050930144145.AC59E23740@thoreau.thistledown.com.au>
Date: Sat,  1 Oct 2005 00:41:45 +1000 (EST)
From: Simon Burge <simonb@wasabisystems.com>
Reply-To: Simon Burge <simonb@wasabisystems.com>
To: gnats-bugs@netbsd.org
Subject: ttys aren't getting mtime right
X-Send-Pr-Version: 3.95

>Number:         31430
>Category:       kern
>Synopsis:       ttys aren't getting mtime right
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Sep 30 14:42:00 +0000 2005
>Last-Modified:  Sun Jan 20 02:35:02 +0000 2008
>Originator:     Simon Burge <simonb@wasabisystems.com>
>Release:        NetBSD 3.99.9, 29 Sep 2005 sources
>Organization:
Wasabi Systems
>Environment:
System: NetBSD euclid 3.99.9 NetBSD 3.99.9 (EUCLID) #504:
  Thu Sep 29 12:39:36 EST 2005
  simonb@euclid:/home/netbsd/obj/sys/arch/i386/compile/EUCLID i386
Architecture: i386
Machine: i386
>Description:
	It seems that ptyfs doesn't track the modification time of
	a pty until it has been queried at least once by stat(2).

	For example, on one pty:

    euclid 30> tty
    /dev/pts/2
    euclid 31> date
    Sat Oct  1 00:22:22 EST 2005

	and then on another pty:

    euclid 31> tty
    /dev/pts/1

    euclid 32> date ; ls -lT /dev/pts/[12]
    Sat Oct  1 00:32:07 EST 2005
    crw--w----  1 simonb  tty  5, 1 Oct  1 00:32:07 2005 /dev/pts/1
    crw--w----  1 simonb  tty  5, 2 Oct  1 00:32:07 2005 /dev/pts/2

    euclid 33> date ; ls -lT /dev/pts/[12]
    Sat Oct  1 00:32:17 EST 2005
    crw--w----  1 simonb  tty  5, 1 Oct  1 00:32:17 2005 /dev/pts/1
    crw--w----  1 simonb  tty  5, 2 Oct  1 00:32:07 2005 /dev/pts/2

    euclid 34> date ; ls -lT /dev/pts/[12]
    Sat Oct  1 00:37:38 EST 2005
    crw--w----  1 simonb  tty  5, 1 Oct  1 00:37:38 2005 /dev/pts/1
    crw--w----  1 simonb  tty  5, 2 Oct  1 00:32:07 2005 /dev/pts/2

	Notice that /dev/pts/2 says 00:32:07 (the time of the first
	ls) and then stays at that time, and not 00:22:22 like it
	should show?


>How-To-Repeat:
	Log in to a machine twice, leave one session idle.  Wait a
	little while, then type "w" in the other session and notice
	that both sessions have 0 idle time.

>Fix:
	None given.

>Release-Note:

>Audit-Trail:
From: "Zafer Aydogan" <zafer@gmx.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/31430: ptyfs isn't getting mtime right
Date: Fri, 30 Sep 2005 20:57:17 +0200 (MEST)

 I noticed something similar with bin/31072.

From: Simon Burge <simonb@wasabisystems.com>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: kern/31430: ptyfs isn't getting mtime right 
Date: Sat, 01 Oct 2005 17:38:43 +1000

 Simon Burge wrote:

 > >Number:         31430
 > >Category:       kern
 > >Synopsis:       ptyfs isn't getting mtime right

 I've changed the synopsis of this to

 	tty's aren't getting mtime right

 as the problem isn't specific to ptyfs - it also affects serial ports
 and older bsd-style ptys.

 The problem also seems to go back at least as far a 1.6.1:

   way:~ 8> date
   Sat Oct  1 17:18:01 EST 2005

 and

   way:~ 11> ls -lT /dev/ttyp[01]
   crw--w----  1 simonb  tty  5, 0 Oct  1 17:18:13 2005 /dev/ttyp0
   crw--w----  1 simonb  tty  5, 1 Oct  1 17:18:35 2005 /dev/ttyp1

 but note there the tty mtime is about 12 seconds late, but at least older
 than the other tty used for the ls command.

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

From: Simon Burge <simonb@wasabisystems.com>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: kern/31430: ptyfs isn't getting mtime right 
Date: Sat, 01 Oct 2005 17:31:05 +1000

 "Zafer Aydogan" wrote:

 > The following reply was made to PR kern/31430; it has been noted by GNATS.
 > 
 > From: "Zafer Aydogan" <zafer@gmx.org>
 > To: gnats-bugs@netbsd.org
 > Cc: 
 > Subject: Re: kern/31430: ptyfs isn't getting mtime right
 > Date: Fri, 30 Sep 2005 20:57:17 +0200 (MEST)
 > 
 >  I noticed something similar with bin/31072.

 bin/31072 seems to be more related to login time than tty modtime (which is
 where the idle time is obtained).

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

From: Simon Burge <simonb@wasabisystems.com>
To: christos@netbsd.org
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org,
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/31430: ptyfs isn't getting mtime right 
Date: Wed, 12 Oct 2005 22:23:19 +1000

 Simon Burge wrote:

 > Simon Burge wrote:
 > 
 > > >Number:         31430
 > > >Category:       kern
 > > >Synopsis:       ptyfs isn't getting mtime right
 > 
 > I've changed the synopsis of this to
 > 
 > 	tty's aren't getting mtime right
 > 
 > as the problem isn't specific to ptyfs - it also affects serial ports
 > and older bsd-style ptys.
 > 
 > The problem also seems to go back at least as far a 1.6.1:
 > 
 >   way:~ 8> date
 >   Sat Oct  1 17:18:01 EST 2005
 > 
 > and
 > 
 >   way:~ 11> ls -lT /dev/ttyp[01]
 >   crw--w----  1 simonb  tty  5, 0 Oct  1 17:18:13 2005 /dev/ttyp0
 >   crw--w----  1 simonb  tty  5, 1 Oct  1 17:18:35 2005 /dev/ttyp1
 > 
 > but note there the tty mtime is about 12 seconds late, but at least older
 > than the other tty used for the ls command.
 > 
 > Simon.
 > --
 > Simon Burge                            <simonb@wasabisystems.com>
 > NetBSD Support and Service:         http://www.wasabisystems.com/
 > 

 At least in the ptyfs case, I've worked out that a call to ptyfs_write
 sets the "mtime modified" flag, but the mtime itself isn't modified
 until ptyfs_itimes is called, usually during a call to ptyfs_getattr.
 This explains why the mtime is the same as the next call to (say)
 stat(2) after the pty is modified.

 The patch below is a result of a discussion off-line with Christos.
 The granularity of the mtime doesn't need to be down to the nanosecond
 - using the kernel "time" variable (which is updated on each
 hardclock call) saves a potentially relatively expensive call to
 microtime/nanotime for each write, and is more than accurate enough to
 track pty idle times.

 For the old-style ptys I suspect the mtime is updated when the inode
 will be synced to disk.

 Christos - OK to commit the below patch?

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


 Index: ptyfs_vnops.c
 ===================================================================
 RCS file: /cvsroot/src/sys/fs/ptyfs/ptyfs_vnops.c,v
 retrieving revision 1.9
 diff -d -p -u -r1.9 ptyfs_vnops.c
 --- ptyfs_vnops.c	12 Sep 2005 16:42:09 -0000	1.9
 +++ ptyfs_vnops.c	12 Oct 2005 09:29:43 -0000
 @@ -800,11 +800,16 @@ ptyfs_read(void *v)
  		int  a_ioflag;
  		struct ucred *a_cred;
  	} */ *ap = v;
 +	struct timespec ts;
  	struct vnode *vp = ap->a_vp;
  	struct ptyfsnode *ptyfs = VTOPTYFS(vp);
  	int error;

  	ptyfs->ptyfs_flag |= PTYFS_ACCESS;
 +	/* hardclock() resolution is good enough for ptyfs */
 +	TIMEVAL_TO_TIMESPEC(&time, &ts);
 +	(void)VOP_UPDATE(vp, &ts, &ts, 0);
 +
  	switch (ptyfs->ptyfs_type) {
  	case PTYFSpts:
  		VOP_UNLOCK(vp, 0);
 @@ -832,11 +837,16 @@ ptyfs_write(void *v)
  		int  a_ioflag;
  		struct ucred *a_cred;
  	} */ *ap = v;
 -	int error;
 +	struct timespec ts;
  	struct vnode *vp = ap->a_vp;
  	struct ptyfsnode *ptyfs = VTOPTYFS(vp);
 +	int error;

  	ptyfs->ptyfs_flag |= PTYFS_MODIFY;
 +	/* hardclock() resolution is good enough for ptyfs */
 +	TIMEVAL_TO_TIMESPEC(&time, &ts);
 +	(void)VOP_UPDATE(vp, &ts, &ts, 0);
 +
  	switch (ptyfs->ptyfs_type) {
  	case PTYFSpts:
  		VOP_UNLOCK(vp, 0);

From: christos@zoulas.com (Christos Zoulas)
To: Simon Burge <simonb@wasabisystems.com>
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org,
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/31430: ptyfs isn't getting mtime right
Date: Wed, 12 Oct 2005 08:53:43 -0400

 On Oct 12, 10:23pm, simonb@wasabisystems.com (Simon Burge) wrote:
 -- Subject: Re: kern/31430: ptyfs isn't getting mtime right

 | At least in the ptyfs case, I've worked out that a call to ptyfs_write
 | sets the "mtime modified" flag, but the mtime itself isn't modified
 | until ptyfs_itimes is called, usually during a call to ptyfs_getattr.
 | This explains why the mtime is the same as the next call to (say)
 | stat(2) after the pty is modified.
 | 
 | The patch below is a result of a discussion off-line with Christos.
 | The granularity of the mtime doesn't need to be down to the nanosecond
 | - using the kernel "time" variable (which is updated on each
 | hardclock call) saves a potentially relatively expensive call to
 | microtime/nanotime for each write, and is more than accurate enough to
 | track pty idle times.
 | 
 | For the old-style ptys I suspect the mtime is updated when the inode
 | will be synced to disk.
 | 
 | Christos - OK to commit the below patch?

 Please do, and thanks for working on this. We should let juan know that
 he might need the same for tmpfs.

 christos

From: Simon Burge <simonb@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: PR/31430 CVS commit: src/sys/fs/ptyfs
Date: Wed, 12 Oct 2005 15:23:33 +0000 (UTC)

 Module Name:	src
 Committed By:	simonb
 Date:		Wed Oct 12 15:23:33 UTC 2005

 Modified Files:
 	src/sys/fs/ptyfs: ptyfs_vnops.c

 Log Message:
 Update the mod and access times directly from ptyfs_read() and
 ptyfs_write() rather than setting a flag and updating these times
 through ptyfs_itimes() at some indeterminate time in the future.
 However, just use the "time" variable to set the times instead of
 using a potentially expensive call to nanotime().  A HZ resolution
 on these timestamps is more than enough.

 (Possibly incomplete) fix for PR kern/31430.
 OK'd be christos@.


 To generate a diff of this commit:
 cvs rdiff -r1.9 -r1.10 src/sys/fs/ptyfs/ptyfs_vnops.c

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

From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
To: simonb@wasabisystems.com
Cc: christos@netbsd.org, gnats-bugs@netbsd.org,
	kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: kern/31430: ptyfs isn't getting mtime right 
Date: Thu, 13 Oct 2005 01:00:50 +0900

 > The patch below is a result of a discussion off-line with Christos.
 > The granularity of the mtime doesn't need to be down to the nanosecond
 > - using the kernel "time" variable (which is updated on each
 > hardclock call) saves a potentially relatively expensive call to
 > microtime/nanotime for each write, and is more than accurate enough to
 > track pty idle times.

 it isn't good to mix "time" and nanotime
 because it can make timestamps go backward sometimes.

 YAMAMOTO Takashi

From: Simon Burge <simonb@wasabisystems.com>
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
Cc: christos@netbsd.org, gnats-bugs@netbsd.org,
	kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: kern/31430: ptyfs isn't getting mtime right 
Date: Thu, 13 Oct 2005 02:36:20 +1000

 YAMAMOTO Takashi wrote:

 > > The patch below is a result of a discussion off-line with Christos.
 > > The granularity of the mtime doesn't need to be down to the nanosecond
 > > - using the kernel "time" variable (which is updated on each
 > > hardclock call) saves a potentially relatively expensive call to
 > > microtime/nanotime for each write, and is more than accurate enough to
 > > track pty idle times.
 > 
 > it isn't good to mix "time" and nanotime
 > because it can make timestamps go backward sometimes.

 You're suggesting that ptyfs_itimes() use "time" as well if any of the
 timespec pointers are NULL then?  Or a different solution?

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

From: christos@zoulas.com (Christos Zoulas)
To: Simon Burge <simonb@wasabisystems.com>,
	YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org,
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/31430: ptyfs isn't getting mtime right
Date: Wed, 12 Oct 2005 12:40:11 -0400

 On Oct 13,  2:36am, simonb@wasabisystems.com (Simon Burge) wrote:
 -- Subject: Re: kern/31430: ptyfs isn't getting mtime right

 | YAMAMOTO Takashi wrote:
 | 
 | > > The patch below is a result of a discussion off-line with Christos.
 | > > The granularity of the mtime doesn't need to be down to the nanosecond
 | > > - using the kernel "time" variable (which is updated on each
 | > > hardclock call) saves a potentially relatively expensive call to
 | > > microtime/nanotime for each write, and is more than accurate enough to
 | > > track pty idle times.
 | > 
 | > it isn't good to mix "time" and nanotime
 | > because it can make timestamps go backward sometimes.
 | 
 | You're suggesting that ptyfs_itimes() use "time" as well if any of the
 | timespec pointers are NULL then?  Or a different solution?

 He is saying that there are other callers of ptyfs_itime() that call it
 with nanotime() or NULL, so the results can be inconsistent. I don't think
 that this is very important in this case (considering that ptyfs is not
 even enabled by default, and right now times are completely off). I do
 think that we should work towards making everything in the kernel use
 timespecs, so that we don't have this problem.

 christos

From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
To: simonb@wasabisystems.com
Cc: christos@netbsd.org, gnats-bugs@netbsd.org,
	kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: kern/31430: ptyfs isn't getting mtime right 
Date: Thu, 13 Oct 2005 01:59:02 +0900

 > You're suggesting that ptyfs_itimes() use "time" as well if any of the
 > timespec pointers are NULL then?

 yes, if you want to use time(9).

 YAMAMOTO Takashi

From: David Holland <dholland@eecs.harvard.edu>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/31430: ttys aren't getting mtime right
Date: Sat, 19 Jan 2008 21:32:13 -0500

 For the (or a) non-ptyfs case, see kern/37126.

 -- 
    - David A. Holland / dholland@eecs.harvard.edu

>Unformatted:

Home	PR Database Search