Hi Manfred,
(2012-08-07 20:10), Manfred Spraul wrote:
> Hi Seiichi,
>
> 2012/8/6 Seiichi Ikarashi
>>
>>
>> A real case was as follows.
>> semget(IPC_PRIVATE, 7, IPC_CREAT | IPC_EXCL);
>> sops[0].sem_num = 0;
>> sops[0].sem_op = 1;
>> sops[0].sem_flg = SEM_UNDO;
>>
Hi Seiichi,
2012/8/6 Seiichi Ikarashi
>
>
> A real case was as follows.
> semget(IPC_PRIVATE, 7, IPC_CREAT | IPC_EXCL);
> sops[0].sem_num = 0;
> sops[0].sem_op = 1;
> sops[0].sem_flg = SEM_UNDO;
> semop(semid, sops, 1);
>
I think this can't work: sops[].sem_num is
Hi Manfred,
(2012-08-04 02:39), Manfred Spraul wrote:
> Hi Seiichi,
>
> On 08/03/2012 02:49 PM, Seiichi Ikarashi wrote:
>> semop() with SEM_UNDO sem_flg can result in ENOMEM even after
>> succeeding semget() with large nsems.
> How large is nsems, what is the use case?
> Which kind of operations
Hi Seiichi,
On 08/03/2012 02:49 PM, Seiichi Ikarashi wrote:
> semop() with SEM_UNDO sem_flg can result in ENOMEM even after
> succeeding semget() with large nsems.
How large is nsems, what is the use case?
Which kind of operations are performed?
Only simple semop(,,1) calls?
still documents ~800
semop() with SEM_UNDO sem_flg can result in ENOMEM even after
succeeding semget() with large nsems. This is because
semop() uses kzalloc() via find_alloc_undo() though
semget() uses vmalloc() via ipc_rcu_alloc().
This patch makes semop() be able to use vmalloc() via ipc_alloc().
Signed-off-by: Sei
5 matches
Mail list logo