public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Kawai, Hidehiro" <hidehiro.kawai.ez@hitachi.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org, gregkh@suse.de,
	james.bottomley@steeleye.com, Satoshi OSHIMA <soshima@redhat.com>,
	"Hideo AOKI@redhat" <haoki@redhat.com>,
	sugita <yumiko.sugita.yf@hitachi.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: [PATCH] binfmt_elf: core dump masking support
Date: Fri, 12 Jan 2007 17:49:13 +0900	[thread overview]
Message-ID: <45A74B89.4040100@hitachi.com> (raw)
In-Reply-To: <20070109143912.GC19787@elf.ucw.cz>

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 when
>>the -cmask option is given to ulimit?
>>Or, 2) it is good to change ulimit and get/setrlimit so that shell
>>programs will invoke get/setrlimit with new parameter?

>>But the second approach is problematic because the bitmask doesn't
>>conform to the usage of setrlimit.  You know, setrlimit controls amount
>>of resources the system can use by the soft limit and hard limit.
>>These limitations don't suit for the bitmask.
> 
> 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.
Additionaly, this approach needs a modification of each shell
command.
What do you think about these demerits?

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.

So I'm going to post the 2nd version patchset with /proc/<pid>/
interface.  If the 2nd version has crucial problems, I'll try
the ulimit approach.

Best regards,
-- 
Hidehiro Kawai
Hitachi, Ltd., Systems Development Laboratory




  reply	other threads:[~2007-01-12  8:50 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-13  7:14 [PATCH] binfmt_elf: core dump masking support Kawai, Hidehiro
2006-12-13 21:23 ` Andrew Morton
2006-12-18  8:08   ` Kawai, Hidehiro
2006-12-20 15:40   ` Pavel Machek
2007-01-09  1:07     ` Kawai, Hidehiro
2007-01-09 14:39       ` Pavel Machek
2007-01-12  8:49         ` Kawai, Hidehiro [this message]
2007-01-14 20:01           ` Pavel Machek
2007-01-19  0:40             ` Kawai, Hidehiro
2007-01-19  0:45               ` Pavel Machek
2007-01-22  2:29                 ` Kawai, Hidehiro
2007-01-22 10:06                   ` Pavel Machek
2007-01-23  4:42                     ` Kawai, Hidehiro
2007-01-23  9:08                       ` Pavel Machek
2007-01-23 12:17                         ` Kawai, Hidehiro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45A74B89.4040100@hitachi.com \
    --to=hidehiro.kawai.ez@hitachi.com \
    --cc=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=gregkh@suse.de \
    --cc=haoki@redhat.com \
    --cc=james.bottomley@steeleye.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=pavel@ucw.cz \
    --cc=soshima@redhat.com \
    --cc=yumiko.sugita.yf@hitachi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox