JFFS2 & the write buffer patch

JFFS2 & the write buffer patch

[Artem Bityuckiy]

Dear JFFS2 maintainers,

I was recently fixed the problem with the JFFS2 write buffer races and 
have posted it to the MTD list. Unfortunately, maintainers did not 
comment the patch (only Estelle Hammache kindly responded).

Could any one who has the cvs access rights please commit this patch? If 
the patch is bad, we may discuss how we can change it.

The another possibility is to grant me the CVS access rights and I will 
commit the patch myself.

Thanks in Advance

-- 
Best regards, Artem B. Bityuckiy
Oktet Labs (St. Petersburg), Software Engineer.
+78124286709 (office) +79112449030 (mobile)
E-mail: dedekind@oktetlabs.ru, web: http://www.oktetlabs.ru

Re: JFFS2 & the write buffer patch

[David Woodhouse]

On Wed, 2004-11-10 at 16:54 +0300, Artem Bityuckiy wrote:
> Dear JFFS2 maintainers,
> 
> I was recently fixed the problem with the JFFS2 write buffer races and 
> have posted it to the MTD list. Unfortunately, maintainers did not 
> comment the patch (only Estelle Hammache kindly responded).

Sorry, I've been busy. Like you, I really don't like the extra locking.
I was trying to find time to stare really hard at it and find a way of
doing it without extra locks. 

> Could any one who has the cvs access rights please commit this patch? If 
> the patch is bad, we may discuss how we can change it.
> 
> The another possibility is to grant me the CVS access rights and I will 
> commit the patch myself.

Mail me a SSH public key and you can have an account to commit it
yourself. But please let's convince ourself the new lock _really_ is
necessary before we do that. I really don't like it.

-- 
dwmw2

Re: JFFS2 & the write buffer patch

[Artem Bityuckiy]

David Woodhouse wrote:
> On Wed, 2004-11-10 at 16:54 +0300, Artem Bityuckiy wrote:
> 
>>Dear JFFS2 maintainers,
>>
>>I was recently fixed the problem with the JFFS2 write buffer races and 
>>have posted it to the MTD list. Unfortunately, maintainers did not 
>>comment the patch (only Estelle Hammache kindly responded).
> 
> 
> Sorry, I've been busy. Like you, I really don't like the extra locking.
> I was trying to find time to stare really hard at it and find a way of
> doing it without extra locks.
The best way that I see is:
1. Introduce additional functions like jffs2_flash_read_nolock(), 
jffs2_flush_wbuf_pad_nolock(), etc. When the alloc_sem is locked, use 
these functions (i.e., from the GC, etc).

We will need to accurately scan the JFFS2 code and substitute these new 
calls instead of old ones.

2. (optional). change the alloc_sem type and make it read/write. The 
only possible problem is that there is no "down_interruptible" call for 
rw semaphore, only uninterruptible.

This will require a little bit more work, but no additional mutex is 
needed. I may do this.

> Mail me a SSH public key and you can have an account to commit it
> yourself. But please let's convince ourself the new lock _really_ is
> necessary before we do that. I really don't like it.
> 
Thanks, I'll sent it to you.

-- 
Best regards, Artem B. Bityuckiy
Oktet Labs (St. Petersburg), Software Engineer.
+78124286709 (office) +79112449030 (mobile)
E-mail: dedekind@oktetlabs.ru, web: http://www.oktetlabs.ru

Re: JFFS2 & the write buffer patch

[Artem B. Bityuckiy]

Hello guys.

Since nobody suggest something better than introducing new mutex, I 
think my patch is OK.

Just few thoughts.

There are the following semaphores in JFFS2 used:
1. c->alloc_sem
2. c->gc_thread_start
3. c->erase_free_sem

We may use only c->alloc_sem - but it is very inefficient since it is 
usually locked for a relatively long time by the GC and flash writers.

c->gc_thread_start - we may use this one - but we at least should rename 
it somehow.

c->erase_free_sem - very special semaphore which is used when the GC 
processes the deletion direntries.

So, I think the introduction of new RW semaphore is the best and most 
efficient solution. If nobody comment, I think we should commit by patch 
with new semaphore.

Artem Bityuckiy wrote:
> David Woodhouse wrote:
> 
>> On Wed, 2004-11-10 at 16:54 +0300, Artem Bityuckiy wrote:
>>
>>> Dear JFFS2 maintainers,
>>>
>>> I was recently fixed the problem with the JFFS2 write buffer races 
>>> and have posted it to the MTD list. Unfortunately, maintainers did 
>>> not comment the patch (only Estelle Hammache kindly responded).
>>
>>
>>
>> Sorry, I've been busy. Like you, I really don't like the extra locking.
>> I was trying to find time to stare really hard at it and find a way of
>> doing it without extra locks.
> 
> The best way that I see is:
> 1. Introduce additional functions like jffs2_flash_read_nolock(), 
> jffs2_flush_wbuf_pad_nolock(), etc. When the alloc_sem is locked, use 
> these functions (i.e., from the GC, etc).
> 
> We will need to accurately scan the JFFS2 code and substitute these new 
> calls instead of old ones.
> 
> 2. (optional). change the alloc_sem type and make it read/write. The 
> only possible problem is that there is no "down_interruptible" call for 
> rw semaphore, only uninterruptible.
> 
> This will require a little bit more work, but no additional mutex is 
> needed. I may do this.
> 
>> Mail me a SSH public key and you can have an account to commit it
>> yourself. But please let's convince ourself the new lock _really_ is
>> necessary before we do that. I really don't like it.
>>
> Thanks, I'll sent it to you.
> 

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.