From mboxrd@z Thu Jan 1 00:00:00 1970 From: Felix Fietkau Subject: Re: [OpenWrt-Devel] Device tree issues with TL-WDR4900 (mpc85xx) and kernel 4.0.1 Date: Mon, 15 Jun 2015 10:24:28 +0200 Message-ID: <557E8BBC.8090901@openwrt.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: Received: from arrakis.dune.hu ([78.24.191.176]:43655 "EHLO arrakis.dune.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751554AbbFOIZe (ORCPT ); Mon, 15 Jun 2015 04:25:34 -0400 In-Reply-To: Sender: linux-unionfs-owner@vger.kernel.org List-Id: linux-unionfs@vger.kernel.org To: Miklos Szeredi , Roman Yeryomin Cc: Wojciech Dubowik , Heiner Kallweit , OpenWrt Development List , "linux-unionfs@vger.kernel.org" On 2015-06-15 10:20, Miklos Szeredi wrote: > On Thu, Jun 11, 2015 at 2:01 PM, Miklos Szeredi wrote: >> On 7 May 2015 at 15:49, Felix Fietkau 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 >>> 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) /dev/root /rom squashfs ro,relatime 0 0 proc /proc proc rw,noatime 0 0 sysfs /sys sysfs rw,noatime 0 0 tmpfs /tmp tmpfs rw,nosuid,nodev,noatime 0 0 /dev/mtdblock8 /overlay jffs2 rw,noatime 0 0 overlayfs:/overlay / overlay rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work 0 0 tmpfs /dev tmpfs rw,relatime,size=512k,mode=755 0 0 devpts /dev/pts devpts rw,relatime,mode=600 0 0 debugfs /sys/kernel/debug debugfs rw,noatime 0 0 - Felix