Re: Re: [VOTE] Introduce session.lock, session.lazy_write and session.lazy_destory

From: Date: Thu, 30 Jan 2014 07:17:58 +0000
Subject: Re: Re: [VOTE] Introduce session.lock, session.lazy_write and session.lazy_destory
References: 1 2 3 4 5 6  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
Hi Patrick,

On Thu, Jan 30, 2014 at 3:37 PM, Patrick Schaaf <[email protected]> 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 && errno
> == 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()
 ↓
read() - locked
↓
script execution
↓
write() - unlock
↓
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
[email protected]


Thread (42 messages)

« previous php.internals (#71782) next »