Hi,
>(run echo 1 > coremask, echo 0 > coremask in a loop while dumping
>core. Do you have enough locking to make it work as expected?)
Currently, any lock isn't acquired. But I think the kernel only
have to preserve the coremask setting in a local variable at the
On Tue 2007-01-23 13:42:00, Kawai, Hidehiro wrote:
> Hi,
>
> >>>(run echo 1 > coremask, echo 0 > coremask in a loop while dumping
> >>>core. Do you have enough locking to make it work as expected?)
> >>
> >>Currently, any lock isn't acquired. But I think the kernel only
> >>have to preserve the
On Tue 2007-01-23 13:42:00, Kawai, Hidehiro wrote:
Hi,
(run echo 1 coremask, echo 0 coremask in a loop while dumping
core. Do you have enough locking to make it work as expected?)
Currently, any lock isn't acquired. But I think the kernel only
have to preserve the coremask setting in a
Hi,
(run echo 1 coremask, echo 0 coremask in a loop while dumping
core. Do you have enough locking to make it work as expected?)
Currently, any lock isn't acquired. But I think the kernel only
have to preserve the coremask setting in a local variable at the
begining of core dumping. I'm
Hi,
>>>(run echo 1 > coremask, echo 0 > coremask in a loop while dumping
>>>core. Do you have enough locking to make it work as expected?)
>>
>>Currently, any lock isn't acquired. But I think the kernel only
>>have to preserve the coremask setting in a local variable at the
>>begining of core
On Mon 2007-01-22 11:29:40, Kawai, Hidehiro wrote:
> Hi Pavel,
>
> The /proc// approach doesn't have these demerits, and it
> has an advantage that users can change the bitmask of any process
> at anytime.
> >>>
> >>>Well... not sure if it is advantage.
> >>
> >>For example, consider
On Mon 2007-01-22 11:29:40, Kawai, Hidehiro wrote:
Hi Pavel,
The /proc/pid/ approach doesn't have these demerits, and it
has an advantage that users can change the bitmask of any process
at anytime.
Well... not sure if it is advantage.
For example, consider the following case:
a
Hi,
(run echo 1 coremask, echo 0 coremask in a loop while dumping
core. Do you have enough locking to make it work as expected?)
Currently, any lock isn't acquired. But I think the kernel only
have to preserve the coremask setting in a local variable at the
begining of core dumping. I'm
Hi Pavel,
The /proc// approach doesn't have these demerits, and it
has an advantage that users can change the bitmask of any process
at anytime.
>>>
>>>Well... not sure if it is advantage.
>>
>>For example, consider the following case:
>> a process forks many children and system
Hi Pavel,
The /proc/pid/ approach doesn't have these demerits, and it
has an advantage that users can change the bitmask of any process
at anytime.
Well... not sure if it is advantage.
For example, consider the following case:
a process forks many children and system administrator wants to
On Fri 2007-01-19 09:40:39, Kawai, Hidehiro wrote:
> Hi Pavel,
>
> >>>Well, you can have it as set of 0-1 "limits"...
> >>
> >>I have come up with a similar idea of regarding the ulimit
> >>value as a bitmask, and I think it may work.
> >>But it will be confusable for users to add the new
Hi Pavel,
>>>Well, you can have it as set of 0-1 "limits"...
>>
>>I have come up with a similar idea of regarding the ulimit
>>value as a bitmask, and I think it may work.
>>But it will be confusable for users to add the new concept of
>>0-1 limitation into the traditional resouce limitation
Hi Pavel,
Well, you can have it as set of 0-1 limits...
I have come up with a similar idea of regarding the ulimit
value as a bitmask, and I think it may work.
But it will be confusable for users to add the new concept of
0-1 limitation into the traditional resouce limitation feature.
On Fri 2007-01-19 09:40:39, Kawai, Hidehiro wrote:
Hi Pavel,
Well, you can have it as set of 0-1 limits...
I have come up with a similar idea of regarding the ulimit
value as a bitmask, and I think it may work.
But it will be confusable for users to add the new concept of
0-1 limitation
Hi!
> > Well, you can have it as set of 0-1 "limits"...
>
> I have come up with a similar idea of regarding the ulimit
> value as a bitmask, and I think it may work.
> But it will be confusable for users to add the new concept of
> 0-1 limitation into the traditional resouce limitation feature.
Hi!
Well, you can have it as set of 0-1 limits...
I have come up with a similar idea of regarding the ulimit
value as a bitmask, and I think it may work.
But it will be confusable for users to add the new concept of
0-1 limitation into the traditional resouce limitation feature.
Hi,
$ echo 1 > /proc/self/coremask
$ ./some_program
>>>
>>>User can already ulimit -c 0 on himself, perhaps we want to use same
>>>interface here? ulimit -cmask=(bitmask)?
>>
>>Are you saying that 1) it is good to change ulimit (shell programs)
>>so that shell programs will read/write
Hi,
$ echo 1 /proc/self/coremask
$ ./some_program
User can already ulimit -c 0 on himself, perhaps we want to use same
interface here? ulimit -cmask=(bitmask)?
Are you saying that 1) it is good to change ulimit (shell programs)
so that shell programs will read/write /proc/self/coremask
Hi!
> > > When a new process is created, the process inherits the coremask
> > > setting from its parent. It is useful to set the coremask before
> > > the program runs. For example:
> > >
> > > $ echo 1 > /proc/self/coremask
> > > $ ./some_program
> >
> > User can already ulimit -c 0 on
Hi!
When a new process is created, the process inherits the coremask
setting from its parent. It is useful to set the coremask before
the program runs. For example:
$ echo 1 /proc/self/coremask
$ ./some_program
User can already ulimit -c 0 on himself, perhaps we want
Hi, Pavel
Pavel Machek wrote:
> > When a new process is created, the process inherits the coremask
> > setting from its parent. It is useful to set the coremask before
> > the program runs. For example:
> >
> > $ echo 1 > /proc/self/coremask
> > $ ./some_program
>
> User can already ulimit
Hi, Pavel
Pavel Machek wrote:
When a new process is created, the process inherits the coremask
setting from its parent. It is useful to set the coremask before
the program runs. For example:
$ echo 1 /proc/self/coremask
$ ./some_program
User can already ulimit -c 0 on
Hi!
> > When a new process is created, the process inherits the coremask
> > setting from its parent. It is useful to set the coremask before
> > the program runs. For example:
> >
> > $ echo 1 > /proc/self/coremask
> > $ ./some_program
>
> The requirement makes sense, I guess.
>
>
Hi!
When a new process is created, the process inherits the coremask
setting from its parent. It is useful to set the coremask before
the program runs. For example:
$ echo 1 /proc/self/coremask
$ ./some_program
The requirement makes sense, I guess.
Regarding the
Hello Andrew,
Thank you for your reply and advice.
I'll send the revised patchset after I fix what you pointed out.
Andrew Morton wrote:
> Regarding the implementation: if we add
>
> unsigned char coredump_omit_anon_memory:1;
>
> into the mm_struct right next to `dumpable' then we
Hello Andrew,
Thank you for your reply and advice.
I'll send the revised patchset after I fix what you pointed out.
Andrew Morton wrote:
Regarding the implementation: if we add
unsigned char coredump_omit_anon_memory:1;
into the mm_struct right next to `dumpable' then we avoid
On Wed, 13 Dec 2006 16:14:08 +0900
"Kawai, Hidehiro" <[EMAIL PROTECTED]> wrote:
> This patch provides a feature which enables you to specify the memory
> segment types you don't want to dump into a core file. You can specify
> them per process via /proc//coremask file. This file represents
> the
On Wed, 13 Dec 2006 16:14:08 +0900
Kawai, Hidehiro [EMAIL PROTECTED] wrote:
This patch provides a feature which enables you to specify the memory
segment types you don't want to dump into a core file. You can specify
them per process via /proc/pid/coremask file. This file represents
the
Hi,
This patch provides a feature which enables you to specify the memory
segment types you don't want to dump into a core file. You can specify
them per process via /proc//coremask file. This file represents
the bitmask of memory segment types which are not written out when the
process is
Hi,
This patch provides a feature which enables you to specify the memory
segment types you don't want to dump into a core file. You can specify
them per process via /proc/pid/coremask file. This file represents
the bitmask of memory segment types which are not written out when the
pid process is
30 matches
Mail list logo
