Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71782
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.182 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAJ26g5TnAqeU4mpSfav7j+CDwBrfL_XRuzNrXpBuc6xrN14ewA@mail.gmail.com>
References: <CAGa2bXZEXx7H+atr3LK8OLLQGSd9a-6+Gey+RhPwP0d7EvTBmw@mail.gmail.com>
 <52E9A631.5050808@sugarcrm.com> <CAGa2bXYn8i9R2+FGMUeyrr00MjRMug5QhheLa=gLKSOc+0j-CA@mail.gmail.com>
 <18069656.FoN8fZuO6C@rofl> <CAJ26g5TtWDjoB3heP1n3JRmakrxWn622PiiBb4z5ruR=GO5Rcw@mail.gmail.com>
 <CAJ26g5TnAqeU4mpSfav7j+CDwBrfL_XRuzNrXpBuc6xrN14ewA@mail.gmail.com>
Date: Thu, 30 Jan 2014 16:17:58 +0900
Message-ID: <CAGa2bXY+9sEnBTi2s9kXDWSAONGvMywGoxRcOEyrFG5ODoKTsw@mail.gmail.com>
To: Patrick Schaaf <bof@bof.de>
Cc: internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c3733ecdb10f04f12add4f
Subject: Re: [PHP-DEV] Re: [VOTE] Introduce session.lock, session.lazy_write
 and session.lazy_destory
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c3733ecdb10f04f12add4f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Patrick,

On Thu, Jan 30, 2014 at 3:37 PM, Patrick Schaaf <bof@bof.de> wrote:

> Unrelated to the previous discussion, and applicable to the base PHP code
> in mod_files.c too, another observation:
>
> Some syscalls can fail with EINTR, when a signal hits while within the
> kernel. This is especially true for flock(LOCK_EX) because in the
> already-locked case the second call will go to sleep for a while waiting
> for the lock to clear. But it is also possible, I think, for the
> pread/read/write calls. The usual handling for the case (-1 return && err=
no
> =3D=3D EINTR) is to just repeat the call in a while loop. I think that at=
 least
> doing so for the LOCK_EX calls, would be prudent.
>
> best regards
>
I also notice other issue when closely looking at current code.
It does

open()
 =E2=86=93
read() - locked
=E2=86=93
script execution
=E2=86=93
write() - unlock
=E2=86=93
close()

However, when write() is called, it always close opened fd to address
changed session ID.
This logic will likely to create race condition that reads old session data
before writing.

I'll address this issue as other issue to be fixed.

In short, session data access is not serialized like serializable
transaction isolation level.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11c3733ecdb10f04f12add4f--