DIRBLKSIZ differs between userland & kernel

[Brett Lymn <brett.lymn%baesystems.com@localhost>]

I have been tracking through a bug with Coda where, basically, getdents(2)
is not returning all the directory entries.  The files exist in the
directory but do not show up on a globbed listing.  After some digging I
found that things ended up in ufs_readdir() which was terminating early
due to a bad dirent.

What is happening is the userland part of Coda, venus, manufactures a
the dirents for a directory when a read request comes up from the
kernel.  It has code to carefully avoid a dirent spanning a DIRBLKSIZ
boundary by padding a dirent near the boundary.  This data is returned
to the kernel for processing.  Where things come unstuck is DIRBLKSIZ is
defined in /usr/include/dirent.h as 1024 bytes, inside the kernel ufs
code sys/ufs/ufs/dir.h DIRBLKSIZE is set to DEV_BSIZE which is 512
bytes.  This means that venus can produce a block of dirents that finish
before the 512 byte mark, the kernel code tries to align back to a 512
byte boundary and fails to find a valid dirent - the fact that ufs_readdir()
exits gracefully rather than causing a panic is more by luck than
anything else.

To fix it I think I have the following choices:

1) Patch venus so it ignores the userland DIRBLKSIZ and, instead, uses
DEV_BSIZE (if available) or just hard code in 512 bytes as the dirent
block size.

2) Change DIRBLKSIZ in dirent.h so it matches the kernel

3) Fix mount_coda so it updates the um_dirblksiz to match userland.

I have done 1 to test and a previously misbehaving directory does seem
to work a lot better.  I see both 1 & 3 being a bit dangerous in the
event that if the definitions change again.  I am not entirely sure
about the implications of 2 - a quick look only showed up initdir.c in
libc using the define but there may be others.

Does anyone have any views on which approach would be the most correct
way of fixing this?

-- 
Brett Lymn
"Warning:
The information contained in this email and any attached files is
confidential to BAE Systems Australia. If you are not the intended
recipient, any use, disclosure or copying of this email or any
attachments is expressly prohibited.  If you have received this email
in error, please notify us immediately. VIRUS: Every care has been
taken to ensure this email and its attachments are virus free,
however, any loss or damage incurred in using this email is not the
sender's responsibility.  It is your responsibility to ensure virus
checks are completed before installing any data sent in this email to
your computer."