mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Paul <set@pobox.com>
To: linux-kernel@vger.kernel.org
Subject: filldir() change broke my CFS -- any ideas?
Date: Thu, 7 Mar 2002 22:11:19 -0500	[thread overview]
Message-ID: <20020307221119.G218@squish.home.loc> (raw)


	Hi;

	CFS is a user space cryptographic filesystem that is
implemented by a daemon that acts as an nfs server.
	In 2.4.9-pre1 a little patch promoted the type of one of
the arguments to filldir from off_t to loff_t. (patch included
below). This has the effect of breaking directory listings for
CFS: I can only see the first 63 files in a dir. In order to
access the other files, I must delete some from the pool of 63.
	I have watched the routine in cfsd that gets called to
deliver the directories back to the client via whatever rpc
magic, and it looks like its doing the same thing with or without
this patch. (this routine gets called multiple times, until
all files have been read via readdir(3)-- 63 just happens to be
the number that fits in the buffer constraints for an
invocation-- and the 63 files I see are from the first
invocation.)
	I rebuilt glibc against 2.4.18 kernel headers, then
nfs-utils, then cfsd, but still the broken behaviour.
I dont know where the breakage is occuring, and would appreciate
any insight, while I continue to poke at this...

Thanks;
Paul
set@pobox.com

(the patch in question, culled from patch-2.4.9-pre1, arch i386
bits only)

diff -u --recursive --new-file v2.4.8/linux/fs/readdir.c linux/fs/readdir.c
--- v2.4.8/linux/fs/readdir.c	Mon Dec 11 13:45:42 2000
+++ linux/fs/readdir.c	Sun Aug 12 14:59:08 2001
@@ -122,7 +122,7 @@
 	int count;
 };
 
-static int fillonedir(void * __buf, const char * name, int namlen, off_t offset,
+static int fillonedir(void * __buf, const char * name, int namlen, loff_t offset,
 		      ino_t ino, unsigned int d_type)
 {
 	struct readdir_callback * buf = (struct readdir_callback *) __buf;
@@ -183,7 +183,7 @@
 	int error;
 };
 
-static int filldir(void * __buf, const char * name, int namlen, off_t offset,
+static int filldir(void * __buf, const char * name, int namlen, loff_t offset,
 		   ino_t ino, unsigned int d_type)
 {
 	struct linux_dirent * dirent;
@@ -261,7 +261,7 @@
 	int error;
 };
 
-static int filldir64(void * __buf, const char * name, int namlen, off_t offset,
+static int filldir64(void * __buf, const char * name, int namlen, loff_t offset,
 		     ino_t ino, unsigned int d_type)
 {
 	struct linux_dirent64 * dirent, d;
diff -u --recursive --new-file v2.4.8/linux/include/linux/fs.h linux/include/linux/fs.h
--- v2.4.8/linux/include/linux/fs.h	Sun Aug 12 13:28:01 2001
+++ linux/include/linux/fs.h	Sun Aug 12 14:58:26 2001
@@ -763,7 +763,7 @@
  * This allows the kernel to read directories into kernel space or
  * to have different dirent layouts depending on the binary type.
  */
-typedef int (*filldir_t)(void *, const char *, int, off_t, ino_t, unsigned);
+typedef int (*filldir_t)(void *, const char *, int, loff_t, ino_t, unsigned);
 
 struct block_device_operations {
 	int (*open) (struct inode *, struct file *);

                 reply	other threads:[~2002-03-08  3:09 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020307221119.G218@squish.home.loc \
    --to=set@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®