linux-kernel - Re: [RFC][PATCH] Mount problem with the GFS2 code

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: <1164877538.3752.93.camel@quoit.chygwyn.com>
Date:	Thu, 30 Nov 2006 09:05:38 +0000
From:	Steven Whitehouse <swhiteho@...hat.com>
To:	Andrew Morton <akpm@...l.org>
Cc:	Srinivasa Ds <srinivasa@...ibm.com>, linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...l.org>, fabbione@...ntu.com,
	bunk@...sta.de, aarora@...ux.vnet.ibm.com, aarora@...ibm.com
Subject: Re: [RFC][PATCH] Mount problem with the GFS2 code

Hi,

On Thu, 2006-11-30 at 00:29 -0800, Andrew Morton wrote:
> On Thu, 30 Nov 2006 15:04:55 +0530
> Srinivasa Ds <srinivasa@...ibm.com> wrote:
> 
> > ==========================================================================
> > On debugging further we found that problem is while reading the super 
> > block(gfs2_read_super) and comparing the magic number in it.
> > When I  replace the submit_bio() call(present in gfs2_read_super) with 
> > the sb_getblk() and ll_rw_block(), mount operation succeded.
> 
> umm, why on earth does gfs2_read_super() go direct-to-BIO?
> 
We want to make 100% certain that we are not reading cached data in
either of the two cases in which we read the sb. It is read from disk
exactly twice on each mount of a GFS2 filesystem and is never touched
again while the fs is mounted. GFS2 never writes the sb, it is created
by mkfs and never changes.

The reason its read twice, is that the first time its read to get the
details of the locking protocol, the second time its called under a lock
in order to discover the location of various bits of metadata on the
disk.

> Switching to sb_getblk()+ll_rw_blk() sounds like a preferable fix.
> 
> Even better would be switching to a bare sb_bread().   If sb->s_blocksize
> isn't set up by then then either set it up or, if you must, use __bread().
> 
I'm not convinced yet... I'd be happy to take the patch as posted
assuming that the reason you are suggesting using sb_bread() or similar
is that you expected us to want to cache the sb. Was there another
reason for not using the bio routines?

Steve.


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