kern/55775: Coda client, its in-kernel part, opens wrong files instead of cache containers

[support%chalmers.se@localhost]

>Number:         55775
>Category:       kern
>Synopsis:       Coda client, its in-kernel part, opens wrong files instead of cache containers
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Nov 02 09:55:00 +0000 2020
>Originator:     CDAL (to Subject please add "#2562547%chalmers.se@localhost")
>Release:        8.0 - 9.1
>Organization:
ITA
>Environment:
i386, tested with out-of-the-box CDROM-install of NetBSD-RELEASE 7.1, 8.0, 8.2, 9.1
>Description:
Venus (Coda filesystem cache manager) properly creates container files and their contents and passes correct device+inode information to the kernel in its downcalls.

Nevertheless the kernel passes to the user space process (at open() on a directory at or below /coda) a file descriptor of some unrelated file on a local file system, instead of the file descriptor of the container file of the directory contents. At the same time /proc/<pid>/fd/<n> of the user process points to the correct venus container cache file, with correct contents.

Some time it is possible to identify the files being erroneously involved, by looking at output of "ls" or at its trace.

NetBSD-7.1 works flawlessly, 8.0 and above are broken in the described way.

The problem seems to be related to some in-kernel caching (?), because sometimes accesses work as supposed.
>How-To-Repeat:
# cd /usr/pkgsrc/net/coda && make install

-- create prerequisites for a local-only Coda server
# sed -i '/127\.0\.0\.1/s/$/ localhost.localdomain/' /etc/hosts
# cp /usr/pkg/share/examples/coda/server.conf /usr/pkg/etc/coda/server.conf.ex
# sed -i '/^#ipaddress=/s//ipaddress=127.0.0.1/' /usr/pkg/etc/coda/server.conf.ex

-- setup and start a local-only Coda server (same results with external ones)
# vice-setup
localdomain
yes
yes
/vice
y
rAndOmT1
RaNdOmT2
randOMT3
y
1
111111
realmadm
y
/vice/LOG
20M
/vice/DATA
32M
y
/vicepa
y
1M
y
=> ...
=> / Coda file server (startserver)
=> ...
=> ... creating the root volume ...
=> Backed Up?
n

-- check
# cat /vice/srv/SrvLog
=> ...
=> File Server started

-- [if the root volume were not created above, then]
# createvol_rep / localhost.localdomain
=> ...
=> Backed Up?
n

-- [to start the server manually]
# codastart
-- [to stop the server manually]
# volutil shutdown

-- setup and start a Coda client
# venus-setup localhost.localdomain
# venus
=> ...
=>  /coda now mounted

-- [to start the client manually]
# venus
-- [to stop the client manually]
# vutil --shutdown

-- get credentials for access to the created realm
-- they expire in 25 hours and also disappear at venus restarts
# clog realmadm
changeme

-- try to access the top level directory (behaves similarly for any level)
# ls -al /coda
=> (hangs with 100% CPU or possibly shows a line from an unrelated local file)

-- to see the actual directory contents:
# od -c /var/lib/coda/cache/00/00/00/01
=> (a directory with . .. localhost.localdomain)

-- venus itself does not have problems to handle directories and pathnames
mkdir /coda/localhost.localdomain/testdir
od -c /var/lib/coda/cache/00/00/00/05
od -c /var/lib/coda/cache/00/00/00/07

-- the problem is possibly limited to directories,
-- but this is unclear, because the results vary in general
echo testdata > /coda/localhost.localdomain/testdir/testfile
od -c /var/lib/coda/cache/00/00/00/09
cat /coda/localhost.localdomain/testdir/testfile
=> testdata
>Fix:
No