On Thu, Jun 11, 2015 at 2:01 PM, Miklos Szeredi <mszeredi@xxxxxxx> wrote: > On 7 May 2015 at 15:49, Felix Fietkau <nbd@xxxxxxxxxxx> wrote: >> On 2015-05-07 08:01, Wojciech Dubowik wrote: >>> Try to boot with kernel locking enabled. I have seen jffs2 deadlocks on >>> readdir. As far as I remember >>> with this patch it went through but I don't know anymore whether I have >>> changed sth in config. >>> >>> Have a look at (search engine...) [PATCH] fs: jffs2: Add setup code for >>> spi nor flash. >>> >>> Even with this patch I got some possible dead lock warnings so it might >>> be just a partial cure. BTW it's >>> a bit scary for future use. Looks like jffs2 doesn't get enough care... >> I believe the locking issues are an overlayfs regression, maybe even >> the same one as this one (which I fixed years ago): >> http://linux-fsdevel.vger.kernel.narkive.com/XRtXLDlf/patch-1-2-overlayfs-fix-a-deadlock-in-ovl-dir-read-merged >> >> I believe this is the cause of the regression: >> >> commit 49c21e1cacd74a8c83407c70ad860c994e606e25 >> Author: Miklos Szeredi <mszeredi@xxxxxxx> >> Date: Sat Dec 13 00:59:42 2014 +0100 >> > > I'm working on 4.0 support for ar71xx and found that > /etc/rc.d/S00sysfixtime is not able to finish it's job after second > boot after flashing (t.i. after overlayfs is switched to jffs). I've > run strace and found that find hangs on the very last getdents64 call > (before calling it succesfully many times on previous > files/directories). > I've reverted every change up to > 49c21e1cacd74a8c83407c70ad860c994e606e25 to overlayfs and it started > working. Applying 49c21e1cacd74a8c83407c70ad860c994e606e25 back breaks > it. So this commit is indeed the cause of regression. > > Miklos, any ideas how to fix it in current tree? I'm using 4.0.5 now > but AFAIK there were no more changes to overlayfs. What's the full mount setup? (cat /proc/mounts) Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
