linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Urban Widmark <urban@teststation.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: smbfs writepage & struct file
Date: Wed, 6 Dec 2000 00:25:37 +0100 (CET)	[thread overview]
Message-ID: <Pine.LNX.4.21.0012051959090.3205-100000@cola.svenskatest.se> (raw)
In-Reply-To: <Pine.LNX.4.10.10012041906510.2047-100000@penguin.transmeta.com>

On Mon, 4 Dec 2000, Linus Torvalds wrote:

> Who works on smbfs these days? I see two ways of fixing smbfs now that

That would be me, I guess. This stuff is a bit over my current level of
understanding so try not to laugh too hard ... :)

Maybe it is best to just disable it for now. Below is a patch that passes
a simple 5 minute test. Included for comments/corrections.

Note that MAP_SHARED doesn't seem to work anyway for smbfs (at least my
testprogram fails to actually write anything in 2.4.0-test11, works vs
ext2). I'll look into that later. I'm not even sure this code is being
called (where is my oops?!).

>  - fetch the dentry that writepage needs by just looking at the
>    inode->i_dentry list and/or just make the smbfs page cache host be the
>    dentry instead of the inode like other filesystems. The first approach
>    assumes that all paths are equal for writeout, the second one assumes
>    that there are no hard linking going on in smbfs.

Hardlinks are not supported by smbfs, but they may be supported on the
server side (ntfs). Haven't looked if smb has anything on this. Not sure
if there are any implications on caching and such for smbfs. (If hardlinks
need to be handled, smbfs is probably broken anyway wrt those).

inode->i_dentry is a list of dentries that relate to this inode? When
would there be >1? (Except hardlinks, we don't have those here.) Is it
guaranteed to always be at least one entry in that list?

The write ends up needing 'dentry->d_inode->u.smbfs_i.fileid' to find the
id to tell the server. I can't now think of a case where the dentry
doesn't map to the one inode we have for this fileid.


I was "borrowing" stuff from the nfs code and this looked strange:

nfs_writepage_sync:
        struct dentry   *dentry = file->f_dentry;
        struct rpc_cred *cred = nfs_file_cred(file);

yet it is called like this from nfs_writepage:
        err = nfs_writepage_sync(NULL, inode, page, 0, offset);

where file is the 1st argument. Oh, it calls nfs_writepage_async most of
the time. All of the time?

/Urban


diff -ur -X exclude linux-2.4.0-test12-pre5-orig/fs/smbfs/file.c linux-2.4.0-test12-pre5-smbfs/fs/smbfs/file.c
--- linux-2.4.0-test12-pre5-orig/fs/smbfs/file.c	Sun Aug  6 20:43:18 2000
+++ linux-2.4.0-test12-pre5-smbfs/fs/smbfs/file.c	Tue Dec  5 23:43:30 2000
@@ -82,7 +82,7 @@
 }
 
 /*
- * We are called with the page locked and the caller unlocks.
+ * We are called with the page locked and we unlock it when done.
  */
 static int
 smb_readpage(struct file *file, struct page *page)
@@ -147,17 +147,33 @@
  * Write a page to the server. This will be used for NFS swapping only
  * (for now), and we currently do this synchronously only.
  *
- * We are called with the page locked and the caller unlocks.
+ * We are called with the page locked and we unlock it when done.
  */
 static int
-smb_writepage(struct file *file, struct page *page)
+smb_writepage(struct page *page)
 {
-	struct dentry *dentry = file->f_dentry;
-	struct inode *inode = dentry->d_inode;
-	unsigned long end_index = inode->i_size >> PAGE_CACHE_SHIFT;
+	struct address_space *mapping = page->mapping;
+	struct dentry *dentry;
+	struct inode *inode;
+	struct list_head *head;
+	unsigned long end_index;
 	unsigned offset = PAGE_CACHE_SIZE;
 	int err;
 
+	if (!mapping)
+		BUG();
+	inode = (struct inode *)mapping->host;
+	if (!inode)
+		BUG();
+
+	/* Pick the first dentry for this inode. */
+	head = &inode->i_dentry;
+	if (list_empty(head))
+		BUG();	/* We need one, are we guaranteed to have one?  */
+	dentry = list_entry(head->next, struct dentry, d_alias);
+
+	end_index = inode->i_size >> PAGE_CACHE_SHIFT;
+
 	/* easy case */
 	if (page->index < end_index)
 		goto do_it;
@@ -170,6 +186,7 @@
 	get_page(page);
 	err = smb_writepage_sync(dentry, page, 0, offset);
 	SetPageUptodate(page);
+	UnlockPage(page);
 	put_page(page);
 	return err;
 }

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

  parent reply	other threads:[~2000-12-05 23:56 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-12-05  3:20 test12-pre5 Linus Torvalds
2000-12-05  3:42 ` test12-pre5 Alexander Viro
2000-12-05  4:00   ` test12-pre5 Linus Torvalds
2000-12-05  4:25     ` test12-pre5 Alexander Viro
2000-12-05 17:09     ` test12-pre5 Stephen C. Tweedie
2000-12-05 17:28       ` test12-pre5 Alexander Viro
2000-12-05 17:48       ` test12-pre5 Linus Torvalds
2000-12-05 18:14         ` test12-pre5 Alexander Viro
2000-12-05 18:33           ` test12-pre5 Linus Torvalds
2000-12-05 18:59             ` test12-pre5 Alexander Viro
2000-12-05 19:48               ` test12-pre5 Linus Torvalds
2000-12-05 20:17                 ` test12-pre5 Alexander Viro
2000-12-05 23:15                   ` test12-pre5 Stephen C. Tweedie
2000-12-05 18:50         ` test12-pre5 Stephen C. Tweedie
2000-12-05  5:30 ` test12-pre5 Mohammad A. Haque
2000-12-05  7:51 ` test12-pre5 Andrew Morton
2000-12-05 15:48 ` test12-pre5 Daniel Phillips
2000-12-05 23:25 ` Urban Widmark [this message]
2000-12-05 23:57   ` smbfs writepage & struct file Linus Torvalds
2000-12-10 13:43     ` Urban Widmark
2000-12-06 10:05   ` Trond Myklebust
2000-12-06 13:18 ` test12-pre5 Panu Matilainen

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=Pine.LNX.4.21.0012051959090.3205-100000@cola.svenskatest.se \
    --to=urban@teststation.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    /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;
as well as URLs for NNTP newsgroup(s).