[PATCH] tmpfs work update (was tmpfs initial work)

[Naoya Sugioka]

Hello Matt and df users again,


Here is an update of my tmpfs porting. The filesystem is getting much
more robust than initial post,
but still I see same memory corruption issue.

Yet I feel it is a worth to share this update with community to catch
up recent vm_pager_getpage() / vm_pager_has_page() changes.

Any feedback and comments are welcome.

thank you,
-Naoya

On Mon, Dec 21, 2009 at 12:21 AM, Naoya Sugioka <naoya.sugioka at gmail.com> wrote:
> Hi Matt,
>
> Thank you very much for the res.  I'm going to look into this.
> -Naoya
>
>
>
> thank you again,
> -Naoya
>
> On Sat, Dec 19, 2009 at 12:09 PM, Matthew Dillon
> <dillon at apollo.backplane.com> wrote:
>>
>> :Hi,
>> :
>> :Now I'm trying to port NetBSD tmpfs to DragonFly, and I would like to
>> :share my progress with community.
>> :
>> :The attached patch is ported from Current NetBSD to master by myself,
>> :not the ones which post this mailing list before.
>> :It should be similar, but many parts should be different from.
>> :Please help me to finalize this tmpfs implementation, just apply the
>> :patch to current master git then report any issues you found.
>> :
>> : - add new vop APIs (ncreate nresolve etc)
>> : - passed initial test  mount, touch file, cp, ln, mknod ...
>> :
>> :todo:
>> : - still need to develop some sysctl to get swap page totals
>> :
>> :question:
>> :I see assertion error at kmalloc it say as following. Please give me
>> :some clues for this.
>> : panic: assertion: chunk->c_Next == NULL || ((intptr_t)chunk->c_Next &
>> :INSAME_PAGE_MASK) == ))intptr_t)chunk & IN_SAME_PAGE_MASK) in kmalloc
>> :mp_lock = 00000001; cpuid = 1
>> :
>> :thank you,
>> :-Naoya
>>
>>    Definitely memory corruption.  You are either using memory after you
>>    have freed it or you are using more memory then you allocated for
>>    a particular chunk.
>>
>>                                                -Matt
>>
>
Attachment:
0001-tmpfs-work-update-011810.patch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bin00000.bin
Type: application/octet-stream
Size: 148461 bytes
Desc: "Description: Binary data"
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20100118/acbf6375/attachment-0020.bin>