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: <E1JIQop-0002AW-TW@pomaz-ex.szeredi.hu>
Date:	Fri, 25 Jan 2008 16:50:15 +0100
From:	Miklos Szeredi <miklos@...redi.hu>
To:	jack@...e.cz
CC:	miklos@...redi.hu, gorcunov@...il.com, akpm@...ux-foundation.org,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	jack@...e.cz
Subject: Re: [patch 25/26] mount options: fix udf

> > > | +	/* 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?

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...

Thanks,
Miklos
--
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/