From: Nicolas Pitre <nicolas.pitre@linaro.org>
To: Chris Brandt <Chris.Brandt@renesas.com>
Cc: Al Viro <viro@ZenIV.linux.org.uk>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-embedded@vger.kernel.org" <linux-embedded@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v2 4/5] cramfs: add mmap support
Date: Tue, 29 Aug 2017 16:00:26 -0400 (EDT) [thread overview]
Message-ID: <nycvar.YSQ.7.76.1708291552240.2606@knanqh.ubzr> (raw)
In-Reply-To: <SG2PR06MB1165FE414425AFD1C64E7CD78A9F0@SG2PR06MB1165.apcprd06.prod.outlook.com>
On Tue, 29 Aug 2017, Chris Brandt wrote:
> On Monday, August 28, 2017, Nicolas Pitre wrote:
> > OK I moved the lock promotion right at the beginning _before_ validating
> > the split point. Also got a reference on the file to make sure that
> > hasn't changed too.
> >
> > > While we are at it, what happens if you mmap 120Kb, then munmap() the
> > middle
> > > 40Kb. Leaving two 40Kb VMAs with 40Kb gap between them, that is. Will
> > your
> > > ->vm_private_data be correct for both?
> >
> > It wouldn't, but I now changed it to contain absolute values so now it
> > will. And if the split point lands in the hole then the code just
> > readjusts the pgoff at the beginning of the remaining part.
> >
> > Here's the revised patch:
>
>
> For whatever it's worth, as soon as I moved to 4.13-rc7,
> CONFIG_CRAMFS_PHYSMEM=y crashes my XIP_KERNEL system before it can even
> get to any console output.
>
> (both the old patch and the new patch)
>
> If CONFIG_CRAMFS_PHYSMEM is not set, my XIP system boots fine.
>
> However, if I boot -rc7 as a uImage, the new patch works just as good as
> the old patch.
When not a uImage, do you mean by that a XIP kernel? If so you should
know by now from that other thread on LAK that the XIP linker script is
broken and probably just worked by luck till now. Still, if you could
bisect between -rc4 and -rc7 and pinpoint the change that makes it not
work that would be better than speculations.
Nicolas
next prev parent reply other threads:[~2017-08-29 20:00 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-16 17:35 [PATCH v2 0/5] cramfs refresh for embedded usage Nicolas Pitre
2017-08-16 17:35 ` [PATCH v2 1/5] cramfs: direct memory access support Nicolas Pitre
2017-08-16 18:28 ` Chris Brandt
2017-08-16 19:44 ` Nicolas Pitre
2017-08-16 17:35 ` [PATCH v2 2/5] cramfs: make cramfs_physmem usable as root fs Nicolas Pitre
2017-08-16 17:35 ` [PATCH v2 3/5] cramfs: implement uncompressed and arbitrary data block positioning Nicolas Pitre
2017-08-16 18:28 ` Chris Brandt
2017-08-16 17:35 ` [PATCH v2 4/5] cramfs: add mmap support Nicolas Pitre
2017-08-16 18:28 ` Chris Brandt
2017-08-28 6:46 ` Al Viro
2017-08-28 13:29 ` Nicolas Pitre
2017-08-28 14:23 ` Al Viro
2017-08-28 19:17 ` Nicolas Pitre
2017-08-29 19:38 ` Chris Brandt
2017-08-29 20:00 ` Nicolas Pitre [this message]
2017-08-29 20:11 ` Chris Brandt
2017-08-31 2:29 ` Chris Brandt
2017-08-16 17:35 ` [PATCH v2 5/5] cramfs: rehabilitate it Nicolas Pitre
2017-08-31 2:30 ` [PATCH v2 0/5] cramfs refresh for embedded usage Chris Brandt
2017-08-31 3:03 ` Nicolas Pitre
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=nycvar.YSQ.7.76.1708291552240.2606@knanqh.ubzr \
--to=nicolas.pitre@linaro.org \
--cc=Chris.Brandt@renesas.com \
--cc=linux-embedded@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@ZenIV.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).