All of lore.kernel.org
 help / color / mirror / Atom feed
From: Estelle HAMMACHE <estelle.hammache@st.com>
To: "Artem B. Bityuckiy" <abityuckiy@yandex.ru>
Cc: linux-mtd@lists.infradead.org, David Woodhouse <dwmw2@infradead.org>
Subject: Re: JFFS2 & SMP
Date: Thu, 04 Nov 2004 10:03:59 +0100	[thread overview]
Message-ID: <4189F07F.6495F568@st.com> (raw)
In-Reply-To: 41890762.9030901@yandex.ru

Hello Artem,

as I mentionned before I don't have linux so I can't really test
your patch right now. I agree with the principle of your patch.
I believe it should work this way.
I was hoping the problem could be solved without introducing
a new mutex, however I didn't check all the functions which
modify the wbuf variables so I don't know whether it is a 
realistic idea or not.
bye
Estelle

"Artem B. Bityuckiy" wrote:
> 
> Hello Estelle.
> 
> It seems I now what is the problem. Thank you for your message.
> 
> The wbuf is protected by the alloc_sem because of all the writes go
> through the space reservation (or in case of GC, it also holds the
> alloc_sem).
> 
> When JFFS2 reads the flash, it also looks to the write buffer and if the
> NAND page which should be read is currently in the wbuf, it reads some
> data from the wbuf too. But there is no any protection there.
> 
> I've introduced the new read/write semaphore (wbuf_sem). It seems the
> problem is fixed, but I'm not sure yet.
> 
> Please, could you try the attached patch? The patch was made against the
> MTD snapshot of date 20041008
> (ftp://ftp.uk.linux.org/pub/people/dwmw2/mtd/cvs/mtd-snapshot-20041008.tar.bz2).
> 
> David, could you comment this?
>

  reply	other threads:[~2004-11-04  9:04 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-27 12:35 JFFS2 & SMP Artem B. Bityuckiy
2004-10-27 12:59 ` David Woodhouse
2004-10-27 13:19   ` Artem B. Bityuckiy
2004-10-27 13:35   ` Artem B. Bityuckiy
2004-10-27 13:45     ` David Woodhouse
2004-10-27 14:09       ` Artem B. Bityuckiy
2004-10-27 14:59       ` Artem B. Bityuckiy
2004-10-27 15:07         ` Artem B. Bityuckiy
2004-10-28 12:14           ` Artem B. Bityuckiy
2004-10-28 12:33       ` Artem B. Bityuckiy
2004-10-28 13:57         ` Artem B. Bityuckiy
2004-11-02 14:31           ` Estelle HAMMACHE
2004-11-03 16:29             ` Artem B. Bityuckiy
2004-11-04  9:03               ` Estelle HAMMACHE [this message]
2004-11-04  9:36                 ` Artem B. Bityuckiy
     [not found]                   ` <418A591C.A4D46C9E@st.com>
2004-11-04 17:17                     ` Artem B. Bityuckiy
2004-11-05  9:06                       ` Estelle HAMMACHE
2004-11-05 11:51                         ` Artem B. Bityuckiy
2004-11-03 16:39             ` Artem B. Bityuckiy

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=4189F07F.6495F568@st.com \
    --to=estelle.hammache@st.com \
    --cc=abityuckiy@yandex.ru \
    --cc=dwmw2@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.