From: gorcunov at gmail.com (Cyrill Gorcunov)
Subject: [PATCH] proc: fix proc-self-map-files selftest for arm
Date: Fri, 12 Oct 2018 01:00:09 +0300 [thread overview]
Message-ID: <20181011220009.GF2401@uranus.lan> (raw)
In-Reply-To: <20181011213006.GA13485@avx2>
On Fri, Oct 12, 2018 at 12:30:06AM +0300, Alexey Dobriyan wrote:
> On Fri, Oct 12, 2018 at 12:02:56AM +0300, Cyrill Gorcunov wrote:
> > On Thu, Oct 11, 2018 at 11:56:01PM +0300, Alexey Dobriyan wrote:
> > >
> > > As the comment in the beginning says this test is specifically for addresss 0.
> > > Maybe it should be ifdeffed with __arm__ then.
> >
> > Is there some other reason than allocating non-mergable VMA?
>
> IIRC the reason is to test address 0 as it is effectively banned
> for userspace so if it will be broken, it will be broken silently
> for a long time.
This is rather a side effect of the test because the primary reason
was to check procfs numbers conversion, right? Don't get me wrong,
I don't mind about __arm__ define or similar, this is fine for
one architecture, but if there comes more we will get a number
of #ifdefs which is unrelated to procfs numeric routines at all.
> As for "unmergeable" libc here doesn't map /dev/zero. I know how to
> avoid even theoretical breakage by creating binaries by hand but it
> will be probably too much.
Sure.
WARNING: multiple messages have this Message-ID (diff)
From: gorcunov@gmail.com (Cyrill Gorcunov)
Subject: [PATCH] proc: fix proc-self-map-files selftest for arm
Date: Fri, 12 Oct 2018 01:00:09 +0300 [thread overview]
Message-ID: <20181011220009.GF2401@uranus.lan> (raw)
Message-ID: <20181011220009.gabXZn3HmulYbEeCS93p3PemroGFl0tN9JNh1pX_mwM@z> (raw)
In-Reply-To: <20181011213006.GA13485@avx2>
On Fri, Oct 12, 2018@12:30:06AM +0300, Alexey Dobriyan wrote:
> On Fri, Oct 12, 2018@12:02:56AM +0300, Cyrill Gorcunov wrote:
> > On Thu, Oct 11, 2018@11:56:01PM +0300, Alexey Dobriyan wrote:
> > >
> > > As the comment in the beginning says this test is specifically for addresss 0.
> > > Maybe it should be ifdeffed with __arm__ then.
> >
> > Is there some other reason than allocating non-mergable VMA?
>
> IIRC the reason is to test address 0 as it is effectively banned
> for userspace so if it will be broken, it will be broken silently
> for a long time.
This is rather a side effect of the test because the primary reason
was to check procfs numbers conversion, right? Don't get me wrong,
I don't mind about __arm__ define or similar, this is fine for
one architecture, but if there comes more we will get a number
of #ifdefs which is unrelated to procfs numeric routines at all.
> As for "unmergeable" libc here doesn't map /dev/zero. I know how to
> avoid even theoretical breakage by creating binaries by hand but it
> will be probably too much.
Sure.
WARNING: multiple messages have this Message-ID (diff)
From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Rafael David Tinoco <rafael.tinoco@linaro.org>,
linux-kselftest@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
shuah@kernel.org
Subject: Re: [PATCH] proc: fix proc-self-map-files selftest for arm
Date: Fri, 12 Oct 2018 01:00:09 +0300 [thread overview]
Message-ID: <20181011220009.GF2401@uranus.lan> (raw)
In-Reply-To: <20181011213006.GA13485@avx2>
On Fri, Oct 12, 2018 at 12:30:06AM +0300, Alexey Dobriyan wrote:
> On Fri, Oct 12, 2018 at 12:02:56AM +0300, Cyrill Gorcunov wrote:
> > On Thu, Oct 11, 2018 at 11:56:01PM +0300, Alexey Dobriyan wrote:
> > >
> > > As the comment in the beginning says this test is specifically for addresss 0.
> > > Maybe it should be ifdeffed with __arm__ then.
> >
> > Is there some other reason than allocating non-mergable VMA?
>
> IIRC the reason is to test address 0 as it is effectively banned
> for userspace so if it will be broken, it will be broken silently
> for a long time.
This is rather a side effect of the test because the primary reason
was to check procfs numbers conversion, right? Don't get me wrong,
I don't mind about __arm__ define or similar, this is fine for
one architecture, but if there comes more we will get a number
of #ifdefs which is unrelated to procfs numeric routines at all.
> As for "unmergeable" libc here doesn't map /dev/zero. I know how to
> avoid even theoretical breakage by creating binaries by hand but it
> will be probably too much.
Sure.
next prev parent reply other threads:[~2018-10-11 22:00 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-11 18:43 [PATCH] proc: fix proc-self-map-files selftest for arm rafael.tinoco
2018-10-11 18:43 ` Rafael David Tinoco
2018-10-11 18:43 ` Rafael David Tinoco
2018-10-11 19:42 ` gorcunov
2018-10-11 19:42 ` Cyrill Gorcunov
2018-10-11 19:42 ` Cyrill Gorcunov
2018-10-11 20:56 ` adobriyan
2018-10-11 20:56 ` Alexey Dobriyan
2018-10-11 20:56 ` Alexey Dobriyan
2018-10-11 21:02 ` gorcunov
2018-10-11 21:02 ` Cyrill Gorcunov
2018-10-11 21:02 ` Cyrill Gorcunov
2018-10-11 21:30 ` adobriyan
2018-10-11 21:30 ` Alexey Dobriyan
2018-10-11 21:30 ` Alexey Dobriyan
2018-10-11 22:00 ` gorcunov [this message]
2018-10-11 22:00 ` Cyrill Gorcunov
2018-10-11 22:00 ` Cyrill Gorcunov
2018-10-15 16:55 ` rafael.tinoco
2018-10-15 16:55 ` Rafael David Tinoco
2018-10-15 16:55 ` Rafael David Tinoco
2018-10-15 17:21 ` gorcunov
2018-10-15 17:21 ` Cyrill Gorcunov
2018-10-15 17:21 ` Cyrill Gorcunov
2018-11-08 10:41 ` rafael.tinoco
2018-11-08 10:41 ` Rafael David Tinoco
2018-11-08 10:41 ` Rafael David Tinoco
2018-11-08 11:11 ` gorcunov
2018-11-08 11:11 ` Cyrill Gorcunov
2018-11-08 11:11 ` Cyrill Gorcunov
2018-11-09 11:30 ` [PATCH] proc: fix and merge proc-self-map-file tests rafael.tinoco
2018-11-09 11:30 ` Rafael David Tinoco
2018-11-09 11:30 ` Rafael David Tinoco
2018-11-09 11:41 ` gorcunov
2018-11-09 11:41 ` Cyrill Gorcunov
2018-11-09 11:41 ` Cyrill Gorcunov
2018-11-09 11:45 ` rafael.tinoco
2018-11-09 11:45 ` Rafael David Tinoco
2018-11-09 11:45 ` Rafael David Tinoco
2018-11-09 11:48 ` gorcunov
2018-11-09 11:48 ` Cyrill Gorcunov
2018-11-09 11:48 ` Cyrill Gorcunov
2018-11-09 12:01 ` rafael.tinoco
2018-11-09 12:01 ` Rafael David Tinoco
2018-11-09 12:01 ` Rafael David Tinoco
2018-11-09 18:04 ` gorcunov
2018-11-09 18:04 ` Cyrill Gorcunov
2018-11-09 18:04 ` Cyrill Gorcunov
2018-11-09 18:48 ` rafael.tinoco
2018-11-09 18:48 ` Rafael David Tinoco
2018-11-09 18:48 ` Rafael David Tinoco
2018-11-09 19:39 ` gorcunov
2018-11-09 19:39 ` Cyrill Gorcunov
2018-11-09 19:39 ` Cyrill Gorcunov
2018-11-10 17:47 ` adobriyan
2018-11-10 17:47 ` Alexey Dobriyan
2018-11-10 17:47 ` Alexey Dobriyan
2018-11-10 17:56 ` rafael.tinoco
2018-11-10 17:56 ` Rafael David Tinoco
2018-11-10 17:56 ` Rafael David Tinoco
2018-11-10 18:49 ` adobriyan
2018-11-10 18:49 ` Alexey Dobriyan
2018-11-10 18:49 ` Alexey Dobriyan
2018-11-11 2:50 ` rafael.tinoco
2018-11-11 2:50 ` Rafael David Tinoco
2018-11-11 2:50 ` Rafael David Tinoco
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=20181011220009.GF2401@uranus.lan \
--to=unknown@example.com \
/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.