linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: viro@parcelfarce.linux.theplanet.co.uk
To: Christoph Hellwig <hch@infradead.org>
Cc: "Lever, Charles" <Charles.Lever@netapp.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Trond Myklebust <trond.myklebust@fys.uio.no>,
	Patrick Mochel <mochel@digitalimplant.org>,
	Linus Torvalds <torvalds@osdl.org>
Subject: Re: RFC: adding an "fs" directory under /sys
Date: Sat, 17 Apr 2004 23:12:45 +0100	[thread overview]
Message-ID: <20040417221245.GD17014@parcelfarce.linux.theplanet.co.uk> (raw)
In-Reply-To: <20040417225509.A21192@infradead.org>

On Sat, Apr 17, 2004 at 10:55:09PM +0100, Christoph Hellwig wrote:
> On Sat, Apr 17, 2004 at 02:51:48PM -0700, Lever, Charles wrote:
> > so, i take it you would prefer me to add a kobject to the
> > nfs_server struct for my purposes, rather than use the
> > unused kobject that is *already* embedded in the
> > super_block?

keyword being "unused".  It has no business being there in the first
place and yes, it should be removed.  And no, the way you are using it
is not safe - it creates a user-triggerable oops if you ever get an
NFS filesystem unmounted.
 
> I think Al wants you to understand what you're trying to do first.
> Please read up about the kobject lifetime rules first, if you can make
> the nfs_server lifetime work with kobjects expectation go for it, but
> don't think it's easy.

Precisely.  Add to that the lifetime rules for module itself and you are
in for fun.

Linus, could you apply the patch below - the field in question is
	a) unused
	b) damn next to impossible to use correctly, due to struct super_block
lifetime and locking rules.

diff -urN RC6-rc1-bk1/include/linux/fs.h RC6-rc1-bk1-current/include/linux/fs.h
--- RC6-rc1-bk1/include/linux/fs.h	Fri Apr 16 12:39:19 2004
+++ RC6-rc1-bk1-current/include/linux/fs.h	Sat Apr 17 18:09:34 2004
@@ -751,7 +751,6 @@
 
 	char s_id[32];				/* Informational name */
 
-	struct kobject           kobj;          /* anchor for sysfs */
 	void 			*s_fs_info;	/* Filesystem private info */
 
 	/*

  reply	other threads:[~2004-04-17 22:12 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-17 21:51 RFC: adding an "fs" directory under /sys Lever, Charles
2004-04-17 21:55 ` Christoph Hellwig
2004-04-17 22:12   ` viro [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-05-13 13:06 Lever, Charles
2004-05-11 17:20 Lever, Charles
2004-05-13  6:18 ` Neil Brown
2004-04-19 13:51 Lever, Charles
2004-05-11  5:54 ` Neil Brown
2004-04-19 13:24 Lever, Charles
2004-04-17 19:46 Lever, Charles
2004-04-17 20:07 ` viro

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=20040417221245.GD17014@parcelfarce.linux.theplanet.co.uk \
    --to=viro@parcelfarce.linux.theplanet.co.uk \
    --cc=Charles.Lever@netapp.com \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=mochel@digitalimplant.org \
    --cc=torvalds@osdl.org \
    --cc=trond.myklebust@fys.uio.no \
    /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).