Oleg Nesterov writes:
> On 07/26, Eric W. Biederman wrote:
>>
>> Are the earlier patches looking ok to you?
>
> I obviously like 1-15.
>
> "[PATCH 16/20] fork: Move and describe why the code examines PIDNS_ADDING"
> is "interesting". I mean it is fine, but at the end of this series it doesn't
> m
On 07/24, Eric W. Biederman wrote:
>
> Similarly the current code will also miss blocked
> signals that are delivered to multiple process, as those signals will
> not appear pending during fork.
Well, I still think this needs a separate change and discussion...
Let me repeat, I simply do not know
On 07/26, Eric W. Biederman wrote:
>
> Are the earlier patches looking ok to you?
I obviously like 1-15.
"[PATCH 16/20] fork: Move and describe why the code examines PIDNS_ADDING"
is "interesting". I mean it is fine, but at the end of this series it doesn't
matter what we check first, PIDNS_ADDIN
Oleg Nesterov writes:
> On 07/24, Eric W. Biederman wrote:
>>
>> @@ -1979,6 +1983,8 @@ static __latent_entropy struct task_struct
>> *copy_process(
>> attach_pid(p, PIDTYPE_TGID);
>> attach_pid(p, PIDTYPE_PGID);
>> attach_pid(p, PIDT
On 07/24, Eric W. Biederman wrote:
>
> @@ -1979,6 +1983,8 @@ static __latent_entropy struct task_struct
> *copy_process(
> attach_pid(p, PIDTYPE_TGID);
> attach_pid(p, PIDTYPE_PGID);
> attach_pid(p, PIDTYPE_SID);
> +
Wen Yang and majiang
report that a periodic signal received during fork can cause fork to
continually restart preventing an application from making progress.
The code was being overly pesimistic. Fork needs to guarantee that a
signal sent to multiple processes is logically delivered before th
6 matches
Mail list logo