Hugh Dickins <[EMAIL PROTECTED]> wrote:
> > > Under precisely what NOMMU conditions?
> >
> > CONFIG_MMU=n.
>
> Believe it or not, I had just about grasped that subtlety. I was
> rather expecting some helpful response along the lines of "we share
> all the vmas across a fork" or "whenever we
Hugh Dickins [EMAIL PROTECTED] wrote:
Under precisely what NOMMU conditions?
CONFIG_MMU=n.
Believe it or not, I had just about grasped that subtlety. I was
rather expecting some helpful response along the lines of we share
all the vmas across a fork or whenever we go to allocate a
On Sat, 3 Mar 2007, David Howells wrote:
> Hugh Dickins <[EMAIL PROTECTED]> wrote:
>
> > > VMAs are a shared resource under NOMMU conditions.
> >
> > That's a disturbing remark.
>
> Why? No-one complained when I first put up my rewrite patches three years
> ago.
Never mind whether anyone
On Sat, 3 Mar 2007, David Howells wrote:
Hugh Dickins [EMAIL PROTECTED] wrote:
VMAs are a shared resource under NOMMU conditions.
That's a disturbing remark.
Why? No-one complained when I first put up my rewrite patches three years
ago.
Never mind whether anyone read your patches
Hugh Dickins <[EMAIL PROTECTED]> wrote:
> > VMAs are a shared resource under NOMMU conditions.
>
> That's a disturbing remark.
Why? No-one complained when I first put up my rewrite patches three years ago.
> Under precisely what NOMMU conditions?
CONFIG_MMU=n.
> I had thought Robin's
Hugh Dickins [EMAIL PROTECTED] wrote:
VMAs are a shared resource under NOMMU conditions.
That's a disturbing remark.
Why? No-one complained when I first put up my rewrite patches three years ago.
Under precisely what NOMMU conditions?
CONFIG_MMU=n.
I had thought Robin's suggestion
On Fri, 16 Feb 2007, David Howells wrote:
> Robin Holt <[EMAIL PROTECTED]> wrote:
>
> > How about:
> > if (vma->vm_mm->coredump_omit_anon_shared) {
> >
> > Then the calls to maydump() would be unchanged:
>
> VMAs are a shared resource under NOMMU conditions.
That's a disturbing
On Fri, 16 Feb 2007, David Howells wrote:
Robin Holt [EMAIL PROTECTED] wrote:
How about:
if (vma-vm_mm-coredump_omit_anon_shared) {
Then the calls to maydump() would be unchanged:
VMAs are a shared resource under NOMMU conditions.
That's a disturbing remark. Under
This patch enables to omit anonymous shared memory from an ELF-FDPIC
formatted core file when it is generated.
The debug messages from maydump() in fs/binfmt_elf_fdpic.c are changed
appropriately so that we can know what kind of memory segments are
dumped or not.
Signed-off-by: Hidehiro Kawai
This patch enables to omit anonymous shared memory from an ELF-FDPIC
formatted core file when it is generated.
The debug messages from maydump() in fs/binfmt_elf_fdpic.c are changed
appropriately so that we can know what kind of memory segments are
dumped or not.
Signed-off-by: Hidehiro Kawai
Kawai, Hidehiro <[EMAIL PROTECTED]> wrote:
> Okay, the probability that the process is blocked in the proc handler seems
> to be small. But I'm not sure if problems never occur in enterprise use.
> So I'd like to use down_write_trylock() as Robin said before. And if it
> fails to acquire the
Kawai, Hidehiro [EMAIL PROTECTED] wrote:
Okay, the probability that the process is blocked in the proc handler seems
to be small. But I'm not sure if problems never occur in enterprise use.
So I'd like to use down_write_trylock() as Robin said before. And if it
fails to acquire the lock, it
Hi David and Robin,
Thank you for your reply.
Robin Holt wrote:
> On Wed, Feb 21, 2007 at 11:33:31AM +, David Howells wrote:
>
>>Kawai, Hidehiro <[EMAIL PROTECTED]> wrote:
>>
>>>Is coredump_setting_sem a global semaphore? If so, it prevents concurrent
>>>core dumping.
>>
>>No, it doesn't.
On Wed, Feb 21, 2007 at 11:33:31AM +, David Howells wrote:
> Kawai, Hidehiro <[EMAIL PROTECTED]> wrote:
>
> > Is coredump_setting_sem a global semaphore? If so, it prevents concurrent
> > core dumping.
>
> No, it doesn't. Look again:
>
> int do_coredump(long signr, int exit_code,
Kawai, Hidehiro <[EMAIL PROTECTED]> wrote:
> Is coredump_setting_sem a global semaphore? If so, it prevents concurrent
> core dumping.
No, it doesn't. Look again:
int do_coredump(long signr, int exit_code, struct pt_regs * regs)
{
Hi,
Thank you for your reply.
David Howells wrote:
>>I think that locking makes codes complex and generates overhead.
>>So I wouldn't like to use lock as far as possible. I think passing
>>the flag as an extra argument is the simplest implementation to
>>avoid the core file corruption.
>
>
Hi,
Thank you for your reply.
David Howells wrote:
I think that locking makes codes complex and generates overhead.
So I wouldn't like to use lock as far as possible. I think passing
the flag as an extra argument is the simplest implementation to
avoid the core file corruption.
Actually, I
Kawai, Hidehiro [EMAIL PROTECTED] wrote:
Is coredump_setting_sem a global semaphore? If so, it prevents concurrent
core dumping.
No, it doesn't. Look again:
int do_coredump(long signr, int exit_code, struct pt_regs * regs)
{
setup vars
On Wed, Feb 21, 2007 at 11:33:31AM +, David Howells wrote:
Kawai, Hidehiro [EMAIL PROTECTED] wrote:
Is coredump_setting_sem a global semaphore? If so, it prevents concurrent
core dumping.
No, it doesn't. Look again:
int do_coredump(long signr, int exit_code, struct pt_regs
Hi David and Robin,
Thank you for your reply.
Robin Holt wrote:
On Wed, Feb 21, 2007 at 11:33:31AM +, David Howells wrote:
Kawai, Hidehiro [EMAIL PROTECTED] wrote:
Is coredump_setting_sem a global semaphore? If so, it prevents concurrent
core dumping.
No, it doesn't. Look again:
On Tue, Feb 20, 2007 at 10:58:17AM +, David Howells wrote:
> Kawai, Hidehiro <[EMAIL PROTECTED]> wrote:
> Actually, I don't think the locking is that hard or that complex.
>
> int do_coredump(long signr, int exit_code, struct pt_regs * regs)
> {
>
>
>
Kawai, Hidehiro <[EMAIL PROTECTED]> wrote:
> Core dumping is separated two phases, one is the phase of writing
> headers, the other is the phase of writing memory segments. If the
> coredump_omit_anon_shared setting is changed between these two phases,
> a corrupted core file will be generated
Hi,
Thank you for your comments.
David Howells wrote:
>> static int elf_fdpic_dump_segments(struct file *file, struct mm_struct *mm,
>>-size_t *size, unsigned long *limit)
>>+size_t *size, unsigned long *limit,
>>+
Hi,
Thank you for your comments.
David Howells wrote:
static int elf_fdpic_dump_segments(struct file *file, struct mm_struct *mm,
-size_t *size, unsigned long *limit)
+size_t *size, unsigned long *limit,
+
Kawai, Hidehiro [EMAIL PROTECTED] wrote:
Core dumping is separated two phases, one is the phase of writing
headers, the other is the phase of writing memory segments. If the
coredump_omit_anon_shared setting is changed between these two phases,
a corrupted core file will be generated because
On Tue, Feb 20, 2007 at 10:58:17AM +, David Howells wrote:
Kawai, Hidehiro [EMAIL PROTECTED] wrote:
Actually, I don't think the locking is that hard or that complex.
int do_coredump(long signr, int exit_code, struct pt_regs * regs)
{
setup vars
Robin Holt <[EMAIL PROTECTED]> wrote:
> How about:
> if (vma->vm_mm->coredump_omit_anon_shared) {
>
> Then the calls to maydump() would be unchanged:
VMAs are a shared resource under NOMMU conditions.
David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Fri, Feb 16, 2007 at 03:05:35PM +, David Howells wrote:
> Actually, I think I would just pass the mm pointer you have into maydump() and
> let that dereference it here:
>
> > + if (omit_anon_shared) {
>
> which would then be:
>
> if (mm->coredump_omit_anon_shared)
Kawai, Hidehiro <[EMAIL PROTECTED]> wrote:
> static int elf_fdpic_dump_segments(struct file *file, struct mm_struct *mm,
> -size_t *size, unsigned long *limit)
> +size_t *size, unsigned long *limit,
> +
This patch enables to omit anonymous shared memory from an ELF-FDPIC
formatted core file when it is generated.
The debug messages from maydump() in fs/binfmt_elf_fdpic.c are changed
appropriately so that we can know what kind of memory segments are
dumped or not.
Signed-off-by: Hidehiro Kawai
This patch enables to omit anonymous shared memory from an ELF-FDPIC
formatted core file when it is generated.
The debug messages from maydump() in fs/binfmt_elf_fdpic.c are changed
appropriately so that we can know what kind of memory segments are
dumped or not.
Signed-off-by: Hidehiro Kawai
Kawai, Hidehiro [EMAIL PROTECTED] wrote:
static int elf_fdpic_dump_segments(struct file *file, struct mm_struct *mm,
-size_t *size, unsigned long *limit)
+size_t *size, unsigned long *limit,
+
On Fri, Feb 16, 2007 at 03:05:35PM +, David Howells wrote:
Actually, I think I would just pass the mm pointer you have into maydump() and
let that dereference it here:
+ if (omit_anon_shared) {
which would then be:
if (mm-coredump_omit_anon_shared) {
How
Robin Holt [EMAIL PROTECTED] wrote:
How about:
if (vma-vm_mm-coredump_omit_anon_shared) {
Then the calls to maydump() would be unchanged:
VMAs are a shared resource under NOMMU conditions.
David
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
34 matches
Mail list logo
