NetBSD Problem Report #38531

From jukka+moray@salmi.ch  Mon Apr 28 08:54:09 2008
Return-Path: <jukka+moray@salmi.ch>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id B963163B898
	for <gnats-bugs@gnats.NetBSD.org>; Mon, 28 Apr 2008 08:54:09 +0000 (UTC)
Message-Id: <20080428085405.C9D921A901@moray.salmi.ch>
Date: Mon, 28 Apr 2008 10:54:05 +0200 (CEST)
From: j+nbsd@2008.salmi.ch
Reply-To: j+nbsd@2008.salmi.ch
To: gnats-bugs@gnats.NetBSD.org
Subject: mmap(2) on ntfs should return MAP_FAILED but doesn't
X-Send-Pr-Version: 3.95

>Number:         38531
>Category:       kern
>Synopsis:       mmap(2) on ntfs should return MAP_FAILED but doesn't
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Apr 28 08:55:00 +0000 2008
>Closed-Date:    Fri Sep 04 10:59:14 +0000 2009
>Last-Modified:  Thu Sep 10 07:35:01 +0000 2009
>Originator:     Jukka Salmi
>Release:        NetBSD 4.99.60
>Organization:

>Environment:
System: NetBSD moray.salmi.ch 4.99.60 NetBSD 4.99.60 (MORAY.APM) #0: Mon Apr 21 20:50:44 CEST 2008 build@moray.salmi.ch:/b/build/nbsd/c/i386/sys/arch/i386/compile/MORAY.APM i386
Architecture: i386
Machine: i386
>Description:
mmap(2) on ntfs should return MAP_FAILED but it doesn't.

>How-To-Repeat:
$ mount
[...]
/dev/wd0n on /mnt/win type ntfs (read-only, local)
$ ls -l /mnt/win/BOOT.INI
-rwxr-xr-x  1 root  wheel  194 Sep 18  2006 /mnt/win/BOOT.INI
$ cp /mnt/win/BOOT.INI .
cp: ./BOOT.INI: Invalid argument

Tracing cp(1) shows:
[...]
   615      1 cp       CALL  open(0xbb907c00,0,0)
   615      1 cp       NAMI  "/mnt/win/BOOT.INI"
   615      1 cp       RET   open 3
   615      1 cp       CALL  open(0x804b208,0x601,0x81ed)
   615      1 cp       NAMI  "./BOOT.INI"
   615      1 cp       RET   open 4
   615      1 cp       CALL  mmap(0,0xc2,1,1,3,0,0,0)
   615      1 cp       RET   mmap -1146105856/0xbbafd000
   615      1 cp       CALL  madvise(0xbbafd000,0xc2,2)
   615      1 cp       RET   madvise 0
   615      1 cp       CALL  write(4,0xbbafd000,0xc2)
   615      1 cp       RET   write -1 errno 22 Invalid argument
[...]

>Fix:

>Release-Note:

>Audit-Trail:
From: Antti Kantee <pooka@cs.hut.fi>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/38531: mmap(2) on ntfs should return MAP_FAILED but doesn't
Date: Mon, 28 Apr 2008 12:24:02 +0300

 On Mon Apr 28 2008 at 08:55:00 +0000, j+nbsd@2008.salmi.ch wrote:
 > >Synopsis:       mmap(2) on ntfs should return MAP_FAILED but doesn't

 No, "mmio fails on ntfs".  Please don't jump to conclusions in the
 synopsis.  I don't see why it shouldn't work for PROT_READ mappings
 (apart from some bugs, of course).

 -- 
 Antti Kantee <pooka@iki.fi>                     Of course he runs NetBSD
 http://www.iki.fi/pooka/                          http://www.NetBSD.org/
     "la qualité la plus indispensable du cuisinier est l'exactitude"

State-Changed-From-To: open->feedback
State-Changed-By: pooka@NetBSD.org
State-Changed-When: Tue, 01 Sep 2009 18:22:47 +0300
State-Changed-Why:
does ntfs work to your liking with the latest -current?


From: Jukka Salmi <j+nbsd@2009.salmi.ch>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/38531 (mmap(2) on ntfs should return MAP_FAILED but doesn't)
Date: Tue, 1 Sep 2009 17:33:12 +0200

 pooka@NetBSD.org wrote:
 > does ntfs work to your liking with the latest -current?

 I can't test it ATM.  The system in question runs netbsd-5 now.  Let's
 assume current works fine and close the PR; if I ever see NTFS problems
 with HEAD again I'll send a new PR.


 Thanks & regards,

 Jukka

 -- 
 This email fills a much-needed gap in your mailbox.

From: Antti Kantee <pooka@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/38531 CVS commit: src/sys/fs/ntfs
Date: Tue, 1 Sep 2009 15:16:41 +0000

 Module Name:	src
 Committed By:	pooka
 Date:		Tue Sep  1 15:16:41 UTC 2009

 Modified Files:
 	src/sys/fs/ntfs: ntfs_subr.c ntfs_vfsops.c

 Log Message:
 Set vnode size after creation(*).  Fixes cp(1) from ntfs, the
 complaint in the "ntfs ubc_uiomove error" (ubc_uiomove error was
 not coming from ntfs but instead the "to" file system) and PR
 kern/38531 (well, I assume the submitter wanted cp(1) working on
 ntfs instead of mangling ntfs the way the PR title suggests).  Yes,
 mmap works on ntfs like it always has.

 *) well, um, and in other places too ... uuuh ... no comments.
 but I guess this works as long as in-kernel ntfs doesn't grow write
 support.


 To generate a diff of this commit:
 cvs rdiff -u -r1.42 -r1.43 src/sys/fs/ntfs/ntfs_subr.c
 cvs rdiff -u -r1.78 -r1.79 src/sys/fs/ntfs/ntfs_vfsops.c

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

From: Antti Kantee <pooka@cs.hut.fi>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/38531
Date: Tue, 1 Sep 2009 18:45:19 +0300

 --EeQfGwPcQSOJBaQU
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline

 Attached is a patch against netbsd-5.

 --EeQfGwPcQSOJBaQU
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: attachment; filename="ntfs.mmap.5.patch"

 Index: ntfs_subr.c
 ===================================================================
 RCS file: /cvsroot/src/sys/fs/ntfs/ntfs_subr.c,v
 retrieving revision 1.37
 diff -p -u -r1.37 ntfs_subr.c
 --- ntfs_subr.c	16 May 2008 09:21:59 -0000	1.37
 +++ ntfs_subr.c	1 Sep 2009 15:45:11 -0000
 @@ -1065,6 +1065,7 @@ ntfs_ntlookupfile(
  				nfp->f_size = iep->ie_fsize;
  				nfp->f_allocated = iep->ie_fallocated;
  				nfp->f_flag |= FN_PRELOADED;
 +				uvm_vnp_setsize(nvp, iep->ie_fsize);
  			} else {
  				error = ntfs_filesize(ntmp, nfp,
  					    &nfp->f_size, &nfp->f_allocated);
 @@ -1072,6 +1073,7 @@ ntfs_ntlookupfile(
  					vput(nvp);
  					goto fail;
  				}
 +				uvm_vnp_setsize(nvp, nfp->f_size);
  			}

  			nfp->f_flag &= ~FN_VALID;
 Index: ntfs_vfsops.c
 ===================================================================
 RCS file: /cvsroot/src/sys/fs/ntfs/ntfs_vfsops.c,v
 retrieving revision 1.72
 diff -p -u -r1.72 ntfs_vfsops.c
 --- ntfs_vfsops.c	28 Jun 2008 01:34:05 -0000	1.72
 +++ ntfs_vfsops.c	1 Sep 2009 15:45:14 -0000
 @@ -824,7 +824,7 @@ ntfs_vgetex(
  		}
  	}

 -	uvm_vnp_setsize(vp, 0); /* XXX notused */
 +	uvm_vnp_setsize(vp, fp->f_size); /* XXX: mess, cf. ntfs_lookupfile() */
  	VREF(ip->i_devvp);
  	*vpp = vp;
  	return (0);

 --EeQfGwPcQSOJBaQU--

State-Changed-From-To: feedback->closed
State-Changed-By: pooka@NetBSD.org
State-Changed-When: Fri, 04 Sep 2009 13:59:14 +0300
State-Changed-Why:
submitter is happy with the fix


From: Soren Jacobsen <snj@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/38531 CVS commit: [netbsd-5] src/sys/fs/ntfs
Date: Thu, 10 Sep 2009 07:33:24 +0000

 Module Name:	src
 Committed By:	snj
 Date:		Thu Sep 10 07:33:24 UTC 2009

 Modified Files:
 	src/sys/fs/ntfs [netbsd-5]: ntfs_subr.c ntfs_vfsops.c

 Log Message:
 Pull up following revision(s) (requested by pooka in ticket #942):
 	sys/fs/ntfs/ntfs_subr.c: revision 1.43
 	sys/fs/ntfs/ntfs_vfsops.c: revision 1.79
 Set vnode size after creation(*).  Fixes cp(1) from ntfs, the
 complaint in the "ntfs ubc_uiomove error" (ubc_uiomove error was
 not coming from ntfs but instead the "to" file system) and
 PR kern/38531 (well, I assume the submitter wanted cp(1) working on
 ntfs instead of mangling ntfs the way the PR title suggests).  Yes,
 mmap works on ntfs like it always has.
 *) well, um, and in other places too ... uuuh ... no comments.
 but I guess this works as long as in-kernel ntfs doesn't grow write
 support.


 To generate a diff of this commit:
 cvs rdiff -u -r1.37 -r1.37.8.1 src/sys/fs/ntfs/ntfs_subr.c
 cvs rdiff -u -r1.72 -r1.72.6.1 src/sys/fs/ntfs/ntfs_vfsops.c

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

>Unformatted:

Home	PR Database Search