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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 2 Feb 2010 16:43:41 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Matthew Wilcox <matthew@....cx>
Cc:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH][RFC] %pd - for printing dentry name

On Tue, Feb 02, 2010 at 06:32:31AM -0700, Matthew Wilcox wrote:
> How about doing this:
> 
>  struct qstr {
> -	const unsigned char *name;
> +	const unsigned char name[0];
>  }
> 
>  struct dentry {
> -	struct qstr d_name;
> +	struct qstr *d_name;
> -	unsigned char d_iname[DNAME_INLINE_LEN_MIN];    /* small names */
> +	union {
> +		struct qstr d_iname;
> +		char pad[DNAME_INLINE_LEN_MIN];
> +	};
>  }
> 
> Doesn't increase the size of struct dentry, and puts the hash and len
> with the name.  Increases long name allocations by 8 bytes each.
> 
> I think reusing the d_iname is OK.  As long as we always limit the
> number of characters printed to the 'len' element, we should never get
> an overrun.  At worst, we get a mixture of the previous name and the
> next name ... and that's a significant canary in itself.

You are creating an extra deref in normal case.  Inline names are common.
Putting len and hash with the name probably not a win - most of the time
you don't look at actual characters and rely on mismatches in other
components to skip the candidate during search.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ