AW: [ECOS] [PATCH] fix possible jffs2 deadlock (sync with mtd cvs)

AW: [ECOS] [PATCH] fix possible jffs2 deadlock (sync with mtd cvs)

[Neundorf, Alexander]

...
> > Another question:
> > 
> > The file jffs2/..../fs-ecos.c contains a check for gcc 
> 3.2.x and ARM_ARCH_4 -> #error This compiler is known to be broken
> > 
> > Does this also apply for ARM_ARCH_5 ?
> > It compiles here with -mcpu=xscale and gcc 3.2.1 ...
> 
> I don't know if the strongARM code is also broken. I suggest you take
> a look at the referenced discussion and look at the assembly language
> your compiler is generating. If it is also broken let me know and i
> will extend the #error for ARM_ARCH_5.
> 

Ok, I'll have a look.
What about the patch ?

Bye
Alex

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] [PATCH] fix possible jffs2 deadlock (sync with mtd cvs)

[Andrew Lunn]

On Mon, Aug 02, 2004 at 02:55:55PM +0200, Neundorf, Alexander wrote:
> 
> ...
> > > Another question:
> > > 
> > > The file jffs2/..../fs-ecos.c contains a check for gcc 
> > 3.2.x and ARM_ARCH_4 -> #error This compiler is known to be broken
> > > 
> > > Does this also apply for ARM_ARCH_5 ?
> > > It compiles here with -mcpu=xscale and gcc 3.2.1 ...
> > 
> > I don't know if the strongARM code is also broken. I suggest you take
> > a look at the referenced discussion and look at the assembly language
> > your compiler is generating. If it is also broken let me know and i
> > will extend the #error for ARM_ARCH_5.
> > 
> 
> Ok, I'll have a look.
> What about the patch ?

It was decided by the jffs2 maintainer to reject the patch. Its the
compiler that is broken, not JFFS2. Fixing the compiler is the proper
solution.

        Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] [PATCH] fix possible jffs2 deadlock (sync with mtd cvs)

[Andrew Lunn]

On Mon, Aug 02, 2004 at 03:09:51PM +0200, Neundorf, Alexander wrote:
> 
> ...
> > > Ok, I'll have a look.
> > > What about the patch ?
> > 
> > It was decided by the jffs2 maintainer to reject the patch. Its the
> > compiler that is broken, not JFFS2. Fixing the compiler is the proper
> > solution.
> > 
> >         Andrew
> 

> No, not that patch.  I mean the patch which is attached to my
> previous mail, which fixes the semaphore-unlocking problem (and
> which is taken from mtd cvs HEAD). This is unrelated to the arm-gcc
> problem.

Sorry, my mistake. 

I want to resync the eCos jffs2 code with dwnw2 repository which will
automatically pull in your patch. But its not as simple as that
becasue the last time this was done an eCos change was overwritten so
that needs putting back and then committing to the dwnw2 repository,
plus i have some other local changes in my tree for the reworked flash
API which should not be committed....

This will happen, but not today.

        Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] [PATCH] fix possible jffs2 deadlock (sync with mtd cvs)

[Andrew Lunn]

> Another question:
> 
> The file jffs2/..../fs-ecos.c contains a check for gcc 3.2.x and ARM_ARCH_4 -> #error This compiler is known to be broken
> 
> Does this also apply for ARM_ARCH_5 ?
> It compiles here with -mcpu=xscale and gcc 3.2.1 ...

I don't know if the strongARM code is also broken. I suggest you take
a look at the referenced discussion and look at the assembly language
your compiler is generating. If it is also broken let me know and i
will extend the #error for ARM_ARCH_5.

        Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] [PATCH] fix possible jffs2 deadlock (sync with mtd cvs)

[Neundorf, Alexander]

[-- Attachment #1: Type: text/plain, Size: 583 bytes --]

Hi,

the attached patch fixes a possible deadlock in the jffs2 garbage collection.
At the end of garbage_collect_pass() there are two error checks, each followed by a return. In these both cases releasing the alloc_sem semaphore was missing.
The patch fixes this and syncs gc.c with the version from mtd cvs.
Please apply.

Another question:

The file jffs2/..../fs-ecos.c contains a check for gcc 3.2.x and ARM_ARCH_4 -> #error This compiler is known to be broken

Does this also apply for ARM_ARCH_5 ?
It compiles here with -mcpu=xscale and gcc 3.2.1 ...

Bye
Alex

[-- Attachment #2: jffs2-gc.diff --]
[-- Type: application/octet-stream, Size: 1082 bytes --]

diff -rbup jffs2.orig/current/ChangeLog jffs2/current/ChangeLog
--- jffs2.orig/current/ChangeLog	Thu Apr 29 09:16:10 2004
+++ jffs2/current/ChangeLog	Fri Jul 30 09:20:43 2004
@@ -1,3 +1,7 @@
+2004-07-30 Alexander Neundorf <alexander.neundorf@jenoptik.com>
+       *src/gc.c: sync with mtd cvs: release the alloc_sem 
+       correctly in case of error, otherwise possible deadlock
+
 2004-04-19  Oyvind Harboe <oyvind.harboe@zylin.com>
 	
 	* src/build.c: JFFS2 can now be used as a write-once, read many mode
diff -rbup jffs2.orig/current/src/gc.c jffs2/current/src/gc.c
--- jffs2.orig/current/src/gc.c	Thu Apr  1 05:17:57 2004
+++ jffs2/current/src/gc.c	Fri Jul 30 09:19:30 2004
@@ -358,10 +358,14 @@ int jffs2_garbage_collect_pass(struct jf
 	spin_unlock(&c->inocache_lock);
 
 	f = jffs2_gc_fetch_inode(c, inum, nlink);
-	if (IS_ERR(f))
-		return PTR_ERR(f);
-	if (!f)
-		return 0;
+   if (IS_ERR(f)) {
+      ret = PTR_ERR(f);
+      goto release_sem;
+   }
+   if (!f) {
+       ret = 0;
+       goto release_sem;
+   }
 
 	ret = jffs2_garbage_collect_live(c, jeb, raw, f);
 

[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss