linux-kernel - Re: [patch 25/26] mount options: fix udf

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080125160726.GB1767@duck.suse.cz>
Date:	Fri, 25 Jan 2008 17:07:26 +0100
From:	Jan Kara <jack@...e.cz>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	gorcunov@...il.com, akpm@...ux-foundation.org,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [patch 25/26] mount options: fix udf

On Fri 25-01-08 16:50:15, Miklos Szeredi wrote:
> > > > | +	/* is this correct? */
> > > > | +	if (sbi->s_anchor[2] != 0)
> > > > | +		seq_printf(seq, ",anchor=%u", sbi->s_anchor[2]);
> > > > 
> > > > you know, I would prefer to use form UDF_SB_ANCHOR(sb)[2]
> > > > in sake of style unification but we should wait for Jan's
> > > > decision (i'm not the expert in this area ;)
> > > 
> > > I think UDF_SB_ANCHOR macro was removed by some patch in -mm.
> >   Yes, it's going to be removed so don't use it. Actually, basing this
> > patch on top of -mm is a good idea because there are quite some changes
> > in Andrew's queue.
> > 
> > > I'm more interested if the second element of the s_anchor array really
> > > does always have the value of the 'anchor=N' mount option.  I haven't
> > > been able to verify that fully.  Do you have some insight into that?
> >   As Cyrill wrote, it could be zeroed out in case there is no anchor in
> > the specified block. So I guess you have to store the passed value
> > somewhere else..
> 
> But in that case, would the value of the anchor= option matter?
  No, it would not.

> This is actually a somewhat philosophical question about what the
> mount options in /proc/mounts mean:
> 
>  1) Options _given_ by the user for the mount
>  2) Options which are _effective_ for the mount
> 
> If we take interpretation 2) and there was no anchor (whatever that
> means), then the anchor=N option wasn't effective, and not giving it
> would have had the same effect.
> 
> This could be confusing to the user, though...
  Hmm, given that options are modified by remount for some filesystems,
it's probably the best to display the effective state. So your code should
display the right thing as it is.

								Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/