linux-kernel - Re: [EXT4 set 7][PATCH 1/1]Remove 32000 subdirs limit.

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: <1184322648.4315.2.camel@garfield.linsyssoft.com>
Date:	Fri, 13 Jul 2007 16:00:48 +0530
From:	Kalpak Shah <kalpak@...sterfs.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	cmm@...ibm.com, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-ext4@...r.kernel.org
Subject: Re: [EXT4 set 7][PATCH 1/1]Remove 32000 subdirs limit.

The updated patch is attached. comments inline...

On Tue, 2007-07-10 at 22:40 -0700, Andrew Morton wrote:
> > If we exceed 65000 subdirectories in an htree directory it sets the
> > inode link count to 1 and no longer counts subdirectories.  The
> > directory link count is not actually used when determining if a
> > directory is empty, as that only counts subdirectories and not regular
> > files that might be in there. 
> > 
> > A EXT4_FEATURE_RO_COMPAT_DIR_NLINK flag has been added and it is set if
> > the subdir count for any directory crosses 65000.
> > 
> 
> Would I be correct in assuming that a later fsck will clear
> EXT4_FEATURE_RO_COMPAT_DIR_NLINK if there are no longer any >65000 subdir
> directories?
> 
> If so, that is worth a mention in the changelog, perhaps?

The changelog has been updated to include this.

> >  
> > +static inline void ext4_inc_count(handle_t *handle, struct inode *inode)
> > +{
> > +	inc_nlink(inode);
> > +	if (is_dx(inode) && inode->i_nlink > 1) {
> > +		/* limit is 16-bit i_links_count */
> > +		if (inode->i_nlink >= EXT4_LINK_MAX || inode->i_nlink == 2) {
> > +			inode->i_nlink = 1;
> > +			EXT4_SET_RO_COMPAT_FEATURE(inode->i_sb,
> > +					      EXT4_FEATURE_RO_COMPAT_DIR_NLINK);
> > +		}
> > +	}
> > +}
> 
> Looks too big to be inlined.
> 
> Why do we set EXT4_FEATURE_RO_COMPAT_DIR_NLINK if i_nlink==2?

I have added a comment for this. (since it indicates that nlinks==1
previously).

> 
> > +static inline void ext4_dec_count(handle_t *handle, struct inode *inode)
> > +{
> > +	drop_nlink(inode);
> > +	if (S_ISDIR(inode->i_mode) && inode->i_nlink == 0)
> > +		inc_nlink(inode);
> > +}
> 
> Probably too big to inline.

Removed the inline.

> >  
> > -	if (inode->i_nlink >= EXT4_LINK_MAX)
> > +	if (EXT4_DIR_LINK_MAX(inode))
> >  		return -EMLINK;
> 
> argh.  WHY_IS_EXT4_FULL_OF_UPPER_CASE_MACROS_WHICH_COULD_BE_IMPLEMENTED
> as_lower_case_inlines?  Sigh.  It's all the old-timers, I guess.
> 
> EXT4_DIR_LINK_MAX() is buggy: it evaluates its arg twice.

#define EXT4_DIR_LINK_MAX(dir) (!is_dx(dir) && (dir)->i_nlink >= EXT4_LINK_MAX)

This just checks if directory has hash indexing in which case we need not worry about EXT4_LINK_MAX subdir limit. If directory is not hash indexed then we will need to enforce a max subdir limit. 

Sorry, I didn't understand what is the problem with this macro?

Thanks,
Kalpak.

View attachment "ext4_remove_subdirs_limit.patch" of type "text/x-patch" (6970 bytes)