Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96938
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 104.47.32.109 as permitted sender)
To: Dmitry Stogov <dmitry@zend.com>
CC: Julien Pauli <julienpauli@gmail.com>, Zeev Suraski <zeev@zend.com>,
	"Nikita Popov" <nikic@php.net>, "php-dev@coydogsoftware.net"
	<php-dev@coydogsoftware.net>, Joe Watkins <pthreads@pthreads.org>,
	"rasmus@lerdorf.com" <rasmus@lerdorf.com>, "internals@lists.php.net"
	<internals@lists.php.net>, Nikita Popov <nikita.ppv@gmail.com>, "Anatol
 Belski (ab@php.net)" <ab@php.net>
Thread-Topic: [PATCH] opcache bug #69090, prepend user identifier to keys
Thread-Index: AQHSQFACD4h3upkAiEqzeDgxtnu8Qg==
Date: Wed, 16 Nov 2016 21:30:23 +0000
Message-ID: <MWHPR02MB2477D7FCAFCACB3A7BCA8B4CBFBE0@MWHPR02MB2477.namprd02.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: zend.com does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_MWHPR02MB2477D7FCAFCACB3A7BCA8B4CBFBE0MWHPR02MB2477namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2016 21:30:23.0801
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 32210298-c08b-4829-8097-6b12c025a892
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR02MB2478
Subject: Re: [PATCH] opcache bug #69090, prepend user identifier to keys
From: dmitry@zend.com (Dmitry Stogov)

--_000_MWHPR02MB2477D7FCAFCACB3A7BCA8B4CBFBE0MWHPR02MB2477namp_
Content-Type: text/plain; charset="koi8-r"
Content-Transfer-Encoding: quoted-printable

I think, it's better to disable bits permutation for both 32 and 64 bit sys=
tems.
And also disable opcache for request if root inode exceeds 2^32 on 32-bit s=
ystems + emit warning.

This should be a robust solution. Right?

Thanks. Dmitry

On Nov 17, 2016 12:09 AM, Dmitry Stogov <dmitry@zend.com> wrote:

https://www.quora.com/What-is-the-maximum-number-of-inodes-in-Linux-filesys=
tems-I-found-suggestion-that-for-Ext4-it-is-4-billion-files-32-bit-number-I=
s-it-true-for-XFS-and-or-BtrFS

________________________________
From: Dmitry Stogov
Sent: Wednesday, November 16, 2016 11:56:45 PM
To: Nikita Popov
Cc: Dmitry Stogov; Julien Pauli; Zeev Suraski; Nikita Popov; php-dev@coydog=
software.net; Joe Watkins; internals@lists.php.net; rasmus@lerdorf.com; Ana=
tol Belski (ab@php.net)
Subject: Re: [PATCH] opcache bug #69090, prepend user identifier to keys


On Nov 16, 2016 8:03 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:
>
> On Tue, Nov 15, 2016 at 6:32 PM, Dmitry Stogov <dmitry@zend.com> wrote:
>>
>> On Nov 15, 2016 18:50, Nikita Popov <nikita.ppv@gmail.com> wrote:
>> >
>> > On Tue, Nov 15, 2016 at 4:19 PM, Dmitry Stogov <dmitry@zend.com> wrote=
:
>> >>
>> >> New patch, attached to bug report, should fix both problems.
>> >>
>> >> I'm going to commit it tomorrow, if no objections.
>> >>
>> >>
>> >> Thanks. Dmitry.
>> >
>> > For the new validate_root patch, wouldn't we still end up with inode c=
ollisions caused by the hash function? It looks like for inodes > 2^16 coll=
isions should be "common".
>> >
>> > Nikita
>>
>>
>> It's not a problem to add inode check, but I think we don't need it.
>>
>>
>> Let S1 and S2 strings, R1 and R2 root_hashes and F a hash function.
>>
>> You propose the following comparison for collision checks
>>
>>
>> F(S1) ^ R1 =3D=3D F(S2) ^ R2 && R1 =3D=3D R2 && S1 =3D=3D S2
>>
>>
>> R1 =3D=3D R2 seems useless. The existing condition:
>>
>>
>> F(S1) ^ R1 =3D=3D F(S2) ^ R2 && S1 =3D=3D S2
>>
>>
>> fails if S1 !=3D S2 independently on R1 and R2.
>>
>> If S1 and S2 are the same, than F(S1) equal to F(S2) and consequently, t=
o satisfy the whole condition, R1 should be equal to R2
>>
>>
>> Am I wrong?
>
> To clarify: My concern is not with the way the hash is compared, but that=
 the root hash itself could have collisions. That is, you have two root ino=
des I1 and I2 and two root hashes R1 =3D H(I1), R2 =3D H(I2). In that case =
it may be that R1 =3D=3D R2, but I1 !=3D I2. At least that's the way I unde=
rstood the patch -- it doesn't looks like there is anything explicitly prev=
enting this.

I see. Actually, for 64-bit systems it's better to eliminate bits permutati=
on at all, but for 32-bit we can't avoid possible collisions, even if we in=
clude high bits into hash.

The good thing, that inodes above 2^32 may make sense only on filesystems a=
bove 16TB with 4096 block sise (may be I'm wrong).

do you have any ideas?

Thanks. Dmitry.

>
> Nikita


--_000_MWHPR02MB2477D7FCAFCACB3A7BCA8B4CBFBE0MWHPR02MB2477namp_--