linux-kernel - Re: [PATCH 005 of 9] md: Replace magic numbers in sb

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] [day] [month] [year] [list]

Message-Id: <1154559143.2725.418.camel@fc5.xsintricity.com>
Date:	Wed, 02 Aug 2006 18:52:23 -0400
From:	Doug Ledford <dledford@...hat.com>
To:	Bill Davidsen <davidsen@....com>
Cc:	Ingo Oeser <ioe-lkml@...eria.de>, NeilBrown <neilb@...e.de>,
	Andrew Morton <akpm@...l.org>, linux-raid@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 005 of 9] md: Replace magic numbers in sb_dirty with
	well defined bit flags

On Tue, 2006-08-01 at 13:12 -0400, Bill Davidsen wrote:
> Ingo Oeser wrote:
> 
> >Hi Neil,
> >
> >I think the names in this patch don't match the description at all.
> >May I suggest different ones?
> >
> >On Monday, 31. July 2006 09:32, NeilBrown wrote:
> >  
> >
> >>Instead of magic numbers (0,1,2,3) in sb_dirty, we have
> >>some flags instead:
> >>MD_CHANGE_DEVS
> >>   Some device state has changed requiring superblock update
> >>   on all devices.
> >>    
> >>
> >
> >MD_SB_STALE or MD_SB_NEED_UPDATE
> >  
> >
> I think STALE is better, it is unambigous.
> >  
> >
> >>MD_CHANGE_CLEAN
> >>   The array has transitions from 'clean' to 'dirty' or back,
> >>   requiring a superblock update on active devices, but possibly
> >>   not on spares
> >>    
> >>
> >
> >Maybe split this into MD_SB_DIRTY and MD_SB_CLEAN ?
> >  
> >
> I don't think the split is beneficial, but I don't care for the name 
> much. Some name like SB_UPDATE_NEEDED or the like might be better.

Yeah, no split.  The absence of a dirty flag denotes clean.

> >  
> >
> >>MD_CHANGE_PENDING
> >>   A superblock update is underway.  
> >>    
> >>
> >
> >MD_SB_PENDING_UPDATE
> >
> >  
> >
> I would have said UPDATE_PENDING, but either is more descriptive than 
> the original.
> 
> Neil - the logic in this code is pretty complex, all the help you can 
> give the occasional reader, by using very descriptive names for things, 
> is helpful to the reader and reduces your "question due to 
> misunderstanding" load.

Well, if you don't mind the length you could do:

MD_SB_WRITEOUT_ALL	/* we need to flush all superblocks due
                         * to a device change. */
MD_SB_WRITEOUT_SOME	/* we need to flush the active devices
                         * superblocks due to normal write operations */
MD_SB_WRITEOUT_PENDING	/* the flush is underway */

In trying to come up with descriptive names for this, it really points
out how having both the "I need something" and "I'm handling something"
flags in the same name space sucks.

Anyway, I don't think Neil's original names were that bad, just
obviously the names describe the condition that precipitated the state,
not the current state, implying that a reader of that code should
probably be thinking about what caused the state more than the state
when determining the appropriate course of action.  It may be preferable
to leave them that way to push readers towards that sort of analysis,
whatever Neil thinks is best on that.

-- 
Doug Ledford <dledford@...hat.com>
              GPG KeyID: CFBFF194
              http://people.redhat.com/dledford

Infiniband specific RPMs available at
              http://people.redhat.com/dledford/Infiniband

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)