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 going to do this in the next version.
>>>
>>>No, I do not think that is enough. At minimum, you'd need atomic_t
>>>variable. But I'd recomend against it. Playing with locking is tricky.
>>
>>Why do you think it is not enough? I think that any locking is not
>>needed.
>
> You are wrong.
>
>> unsigned int mask = current->mm->coremask;
>
> Not a valid C; coremask can change from another cpu.
Sure. Although I thought it was no problem because coremask uses only
1 bit, it will be problematic when coremask grows beyond byte alignment.
>>>No, I do not think that is enough. At minimum, you'd need atomic_t
>>>variable. But I'd recomend against it. Playing with locking is tricky.
But Andrew proposed:
> Regarding the implementation: if we add
>
> unsigned char coredump_omit_anon_memory:1;
>
> into the mm_struct right next to `dumpable' then we avoid increasing the
> size of the mm_struct, and the code gets neater.
So I'm going to use a bit field to store the bitmask. Because of this,
I can't use an atomic_t variable.
Instead, I'll use a spin lock to read/write atomically.
Best regards,
--
Hidehiro Kawai
Hitachi, Ltd., Systems Development Laboratory
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
