mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Herbert Poetzl <herbert@13thfloor.at>
To: Christoph Hellwig <hch@infradead.org>,
	Andrew Morton <akpm@osdl.org>,
	Al Viro <viro@parcelfarce.linux.theplanet.co.uk>,
	Linux Kernel ML <linux-kernel@vger.kernel.org>
Subject: Re: [Patch 6/6] Bind Mount Extensions 0.06
Date: Thu, 24 Feb 2005 22:29:32 +0100	[thread overview]
Message-ID: <20050224212932.GF4981@mail.13thfloor.at> (raw)
In-Reply-To: <20050223230659.GE21383@infradead.org>

On Wed, Feb 23, 2005 at 11:06:59PM +0000, Christoph Hellwig wrote:
> > +++ linux-2.6.11-rc4-bme0.06-bm0.01-at0.01-cc0.01-co0.01-xa0.01-ro0.01/fs/ext2/ioctl.c	2005-02-19 06:32:05 +0100
> > @@ -29,7 +29,8 @@ int ext2_ioctl (struct inode * inode, st
> >  	case EXT2_IOC_SETFLAGS: {
> >  		unsigned int oldflags;
> >  
> > -		if (IS_RDONLY(inode))
> > +		if (IS_RDONLY(inode) ||
> > +			(filp && MNT_IS_RDONLY(filp->f_vfsmnt)))
> 
> doing this in every filesystem ->ioctl is a really bad idea.  We need to
> add common handling for ext2-style file attributes first.

hmm, well, but the ioctls are somewhat mixed, i.e.
some of them do just read (only) like operations,
others do change stuff, and the test is just valid
for write/change ioctls ...

of course I could add a second switch/case block
which checks for 'write' type ioctls and blocks
them in the beginning ... 

but maybe I did misunderstood your comment, so let
me know what you consider appropriate ...

> Also please add a file_readonly() helper - when introduced it only checks
> IS_RDONLY(file->f_dentry->d_inode) and once you add per-mount flags it
> only needs to be added in a single place. Actually probably a lowelevel
> one taking inode,vfsmount and wrappers for a struct file * or
> struct nameidata * which would cover most of the cases.

actually I started the BME patches by extending the
IS_RDONLY() macro to take two arguments, the inode 
and the vfsmount (which sounded natural to me) but
that was shot down ... (don't remember why exactly)

no problem with a file_readonly() or nd_readonly()
if that makes folks happy ...

thanks,
Herbert

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

      reply	other threads:[~2005-02-24 21:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-22 12:13 Herbert Poetzl
2005-02-22 14:34 ` Trond Myklebust
2005-02-22 14:44   ` Herbert Poetzl
2005-02-22 14:58 ` Trond Myklebust
2005-02-23 20:00   ` Herbert Poetzl
2005-02-23 23:06 ` Christoph Hellwig
2005-02-24 21:29   ` Herbert Poetzl [this message]

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=20050224212932.GF4981@mail.13thfloor.at \
    --to=herbert@13thfloor.at \
    --cc=akpm@osdl.org \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@parcelfarce.linux.theplanet.co.uk \
    /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®