NetBSD Problem Report #57103

From mlelstv@arnold.localdomain  Sat Dec 10 16:22:27 2022
Return-Path: <mlelstv@arnold.localdomain>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 8740E1A921F
	for <gnats-bugs@gnats.NetBSD.org>; Sat, 10 Dec 2022 16:22:27 +0000 (UTC)
Message-Id: <20221210162225.4F35CBC15D@arnold.localdomain>
Date: Sat, 10 Dec 2022 17:22:25 +0100 (CET)
From: mlelstv@netbsd.org
Reply-To: mlelstv@netbsd.org
To: gnats-bugs@NetBSD.org
Subject: ls prints error message with autofs
X-Send-Pr-Version: 3.95

>Number:         57103
>Category:       bin
>Synopsis:       ls prints error message with autofs
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Dec 10 16:25:00 +0000 2022
>Last-Modified:  Sun Dec 11 16:05:01 +0000 2022
>Originator:     Michael van Elst
>Release:        NetBSD 9.99.104
>Organization:

>Environment:


System: NetBSD arnold 9.99.104 NetBSD 9.99.104 (EGGHED64) #63: Sun Oct 30 21:09:47 UTC 2022 mlelstv@slowpoke:/home/netbsd-current/obj.evbarm64-el/scratch/netbsd-current/src/sys/arch/evbarm/compile/EGGHED64 evbarm
Architecture: aarch64
Machine: evbarm
>Description:

/a is the mountpoint for autofs like:

map /etc/auto_arnold on /a type autofs

% ls -ld /a
ls: /a: Operation not supported
drwxr-xr-x  3 root  wheel  512 Dec 10 16:45 /a

This is a failing lpathconf() call that isn't implemented for autofs.

>How-To-Repeat:
Try to list a autofs mountpoint.
>Fix:
Either filter this error message in ls or teach autofs a VOP_PATHCONF method.

>Audit-Trail:
From: Tomohiro Kusumi <kusumi.tomohiro@gmail.com>
To: gnats-bugs@netbsd.org
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: bin/57103: ls prints error message with autofs
Date: Sun, 11 Dec 2022 01:49:05 -0800

 > % ls -ld /a
 > ls: /a: Operation not supported
 > drwxr-xr-x  3 root  wheel  512 Dec 10 16:45 /a

 Why do you want to use -d option in the first place ?
 That's simply not how autofs vnops triggers userspace daemon to mount
 target fs weather direct or indirect mapping...

 So no, this isn't a bug.


 2022=E5=B9=B412=E6=9C=8810=E6=97=A5(=E5=9C=9F) 8:25 <mlelstv@netbsd.org>:
 >
 > >Number:         57103
 > >Category:       bin
 > >Synopsis:       ls prints error message with autofs
 > >Confidential:   no
 > >Severity:       serious
 > >Priority:       low
 > >Responsible:    bin-bug-people
 > >State:          open
 > >Class:          sw-bug
 > >Submitter-Id:   net
 > >Arrival-Date:   Sat Dec 10 16:25:00 +0000 2022
 > >Originator:     Michael van Elst
 > >Release:        NetBSD 9.99.104
 > >Organization:
 >
 > >Environment:
 >
 >
 > System: NetBSD arnold 9.99.104 NetBSD 9.99.104 (EGGHED64) #63: Sun Oct 30=
  21:09:47 UTC 2022 mlelstv@slowpoke:/home/netbsd-current/obj.evbarm64-el/sc=
 ratch/netbsd-current/src/sys/arch/evbarm/compile/EGGHED64 evbarm
 > Architecture: aarch64
 > Machine: evbarm
 > >Description:
 >
 > /a is the mountpoint for autofs like:
 >
 > map /etc/auto_arnold on /a type autofs
 >
 > % ls -ld /a
 > ls: /a: Operation not supported
 > drwxr-xr-x  3 root  wheel  512 Dec 10 16:45 /a
 >
 > This is a failing lpathconf() call that isn't implemented for autofs.
 >
 > >How-To-Repeat:
 > Try to list a autofs mountpoint.
 > >Fix:
 > Either filter this error message in ls or teach autofs a VOP_PATHCONF met=
 hod.
 >
 > >Unformatted:
 >
 >

From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/57103: ls prints error message with autofs
Date: Sun, 11 Dec 2022 10:09:02 -0000 (UTC)

 kusumi.tomohiro@gmail.com (Tomohiro Kusumi) writes:

 >> % ls -ld /a
 >> ls: /a: Operation not supported
 >> drwxr-xr-x  3 root  wheel  512 Dec 10 16:45 /a

 >Why do you want to use -d option in the first place ?

 This was to avoid listing the content and _only_ show the message.
 The message occurs with and without -d.


 >That's simply not how autofs vnops triggers userspace daemon to mount
 >target fs weather direct or indirect mapping...
 >So no, this isn't a bug.

 The bug is that ls calls lpathconf() to identify ACL capabilities,
 fails on autofs and prints this as an error.


 >> >Fix:
 >> Either filter this error message in ls or teach autofs a VOP_PATHCONF met=
 >hod.

 Either autofs should learn the pathconf operation or ls should learn
 that the error EOPNOTSUPP for this operation should be handled silently.


From: Tomohiro Kusumi <kusumi.tomohiro@gmail.com>
To: gnats-bugs@netbsd.org
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, mlelstv@netbsd.org
Subject: Re: bin/57103: ls prints error message with autofs
Date: Sun, 11 Dec 2022 02:15:43 -0800

 -d doesn't mean anything for autofs, and that's not a bug.
 Same with FreeBSD and DragonFly autofs.

 Without -d it worked fine for me for both direct and indirect.
 If you paste exact /etc/auto_xxx contents, I could try that.

From: "J. Hannken-Illjes" <hannken@mailbox.org>
To: NetBSD GNATS <gnats-bugs@netbsd.org>
Cc: 
Subject: Re: bin/57103: ls prints error message with autofs
Date: Sun, 11 Dec 2022 11:33:24 +0100

 > On 11. Dec 2022, at 11:10, Michael van Elst <mlelstv@serpens.de> wrote:
 > 
 > Either autofs should learn the pathconf operation or ls should learn
 > that the error EOPNOTSUPP for this operation should be handled silently.

 Sure, autofs has to support VOP_PATHCONF(), either as a stub returning
 EINVAL like FreeBSD does or as genfs_pathconf().

 Both should work with "ls" while EOPNOTSUPP is not ok here.

 --
 J. Hannken-Illjes - hannken@mailbox.org

From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/57103: ls prints error message with autofs
Date: Sun, 11 Dec 2022 10:44:00 -0000 (UTC)

 kusumi.tomohiro@gmail.com (Tomohiro Kusumi) writes:

 >-d doesn't mean anything for autofs, and that's not a bug.
 >Same with FreeBSD and DragonFly autofs.

 >Without -d it worked fine for me for both direct and indirect.
 >If you paste exact /etc/auto_xxx contents, I could try that.


 It does work fine, just ls prints an error.

From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/57103: ls prints error message with autofs
Date: Sun, 11 Dec 2022 17:44:26 +0700

     Date:        Sun, 11 Dec 2022 10:10:01 +0000 (UTC)
     From:        mlelstv@serpens.de (Michael van Elst)
     Message-ID:  <20221211101001.62C331A9239@mollari.NetBSD.org>

   |  Either autofs should learn the pathconf operation or ls should learn
   |  that the error EOPNOTSUPP for this operation should be handled silently.

 Probably both.

 The following should fix the ls issue, but I'm unable to test it,
 I have nothing that uses ACLs (to verify they can still be obtained)
 nor do I use autofs to encounter the error case.

 Perhaps someone who does have either one of those abilities could test
 this, and if it works, it can be committed.   (Note: it is not needed that
 anyone be able to test both aspects).

 The patch includes a small amount of code reordering so line wrapping can
 be avoided...

 kre

 Index: print.c
 ===================================================================
 RCS file: /cvsroot/src/bin/ls/print.c,v
 retrieving revision 1.57
 diff -u -r1.57 print.c
 --- print.c	17 May 2020 23:34:11 -0000	1.57
 +++ print.c	11 Dec 2022 10:37:25 -0000
 @@ -542,21 +542,22 @@
  		supports_acls = 0;

  		ret = lpathconf(name, _PC_ACL_NFS4);
 -		if (ret > 0) {
 -			type = ACL_TYPE_NFS4;
 -			supports_acls = 1;
 -		} else if (ret < 0 && errno != EINVAL) {
 +		f (ret < 0 && errno != EINVAL && errno != EOPNOTSUPP) {
  			warn("%s", name);
  			return;
  		}
 -		if (supports_acls == 0) {
 +		if (ret > 0) {
 +			type = ACL_TYPE_NFS4;
 +			supports_acls = 1;
 +		} else {
  			ret = lpathconf(name, _PC_ACL_EXTENDED);
 +			if (ret < 0 && errno != EINVAL && errno != EOPNOTSUPP) {
 +				warn("%s", name);
 +				return;
 +			}
  			if (ret > 0) {
  				type = ACL_TYPE_ACCESS;
  				supports_acls = 1;
 -			} else if (ret < 0 && errno != EINVAL) {
 -				warn("%s", name);
 -				return;
  			}
  		}
  	}


From: Michael van Elst <mlelstv@serpens.de>
To: gnats-bugs@netbsd.org
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, mlelstv@netbsd.org
Subject: Re: bin/57103: ls prints error message with autofs
Date: Sun, 11 Dec 2022 14:03:51 +0100

 On Sun, Dec 11, 2022 at 12:45:01PM +0000, Robert Elz wrote:
 > 
 >      Date:        Sun, 11 Dec 2022 10:10:01 +0000 (UTC)
 >      From:        mlelstv@serpens.de (Michael van Elst)
 >      Message-ID:  <20221211101001.62C331A9239@mollari.NetBSD.org>
 >  
 >    |  Either autofs should learn the pathconf operation or ls should learn
 >    |  that the error EOPNOTSUPP for this operation should be handled silently.
 >  
 >  Probably both.

 I've committed a fix to autofs to use genfs_pathconf().

 Unlike FreeBSD, we fall back to return EOPNOSUPP if a filesystem
 hasn't implemented a method. FreeBSD has individual defaults for
 each method (mostly the 'generic' implementations) and the
 default for vop_pathconf is to return EINVAL unconditionally.

 N.B. mfs calls genfs_badop, i.e. triggers a panic. This should probably
 be changed.

 Greetings,
 -- 
                                 Michael van Elst
 Internet: mlelstv@serpens.de
                                 "A potential Snark may lurk in every tree."

From: "John D. Baker" <jdbaker@consolidated.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/57103: ls prints error message with autofs
Date: Sun, 11 Dec 2022 09:57:45 -0600 (CST)

 I see this problem when autofs-managed filesystems have not yet been
 accessed (auto-mounted), but one performs an 'ls' of the directory in
 which the autofs parent resides.

 Say "/x" is an autofs-managed directory.  If no access has been made to
 "/x" specifically, 'ls /' will display "Operation not supported" right
 after "x" is displayed in the 'ls' output.

 Once one accesses content residing in "/x", say 'ls /x/foo', then a
 subsequent 'ls /' no-longer reports a error when "/x" is encountered.

 If the fix works on -HEAD, it should be pulled up to -9 as well.

 -- 
 |/"\ John D. Baker, KN5UKS               NetBSD     Darwin/MacOS X
 |\ / jdbaker[snail]consolidated[flyspeck]net  OpenBSD            FreeBSD
 | X  No HTML/proprietary data in email.   BSD just sits there and works!
 |/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645

>Unformatted:

Home	PR Database Search