Re: [LTP] [PATCH] mprotect04: fix powerpc crash when copying exec_func
- Original Message - > From: "Cyril Hrubis" <chru...@suse.cz> > To: "Jan Stancek" <jstan...@redhat.com> > Cc: ltp-list@lists.sourceforge.net > Sent: Wednesday, 9 September, 2015 3:26:42 PM > Subject: Re: [LTP] [PATCH] mprotect04: fix powerpc crash when copying > exec_func > > Hi! > > > > I'm seeing this on RHEL6.7 kernel, I haven't tried latest upstream yet. > > > > > > Ah, you are right, the memory is not touched in the write_null() > > > function at all. > > > > Right, I got confused by "access_ok(VERIFY_READ, buf, count)" > > in vfs_write(), but after reading code and comments it's clear it > > only checks if range _may_ be valid: > > * access_ok: - Checks if a user space pointer is valid > > ... > > * Returns true (nonzero) if the memory block may be valid, false (zero) > > * if it is definitely invalid. > > * > > * Note that, depending on architecture, this function probably just > > * checks that the pointer is in the user space range - after calling > > * this function, memory access functions may still return -EFAULT. > > I do not have further questions. Acked. Pushed. Regards, Jan > > -- > Cyril Hrubis > chru...@suse.cz > -- Monitor Your Dynamic Infrastructure at Any Scale With Datadog! Get real-time metrics from all of your servers, apps and tools in one place. SourceForge users - Click here to start your Free Trial of Datadog now! http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140 ___ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list
Re: [LTP] [PATCH] mprotect04: fix powerpc crash when copying exec_func
Hi!
> Testcase tried to copy page size area starting at _func.
> This results in crash on powerpc, because _func is too close
> to end of page and subsequent page is not mapped:
I was wondering about this problem when I was fixing the test, but could
not actually hit it.
> -static void *get_func(void *mem)
> +static int page_present(void *p)
> {
> - memcpy(mem, exec_func, getpagesize());
> + int fd;
> +
> + fd = SAFE_OPEN(cleanup, "page_present", O_WRONLY|O_CREAT, 0644);
Why don't we use "/dev/null"?
The rest looks good to me.
--
Cyril Hrubis
chru...@suse.cz
--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
___
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
Re: [LTP] [PATCH] mprotect04: fix powerpc crash when copying exec_func
- Original Message -
> From: "Cyril Hrubis" <chru...@suse.cz>
> To: "Jan Stancek" <jstan...@redhat.com>
> Cc: ltp-list@lists.sourceforge.net
> Sent: Wednesday, 9 September, 2015 3:09:34 PM
> Subject: Re: [LTP] [PATCH] mprotect04: fix powerpc crash when copying
> exec_func
>
> Hi!
> > It doesn't seem reliable:
> >
> > open("/dev/null", O_WRONLY|O_CREAT, 0644) = 3
> > write(3, NULL, 1) = 1
> > close(3)= 0
> >
> > I'm seeing this on RHEL6.7 kernel, I haven't tried latest upstream yet.
>
> Ah, you are right, the memory is not touched in the write_null()
> function at all.
Right, I got confused by "access_ok(VERIFY_READ, buf, count)"
in vfs_write(), but after reading code and comments it's clear it
only checks if range _may_ be valid:
* access_ok: - Checks if a user space pointer is valid
...
* Returns true (nonzero) if the memory block may be valid, false (zero)
* if it is definitely invalid.
*
* Note that, depending on architecture, this function probably just
* checks that the pointer is in the user space range - after calling
* this function, memory access functions may still return -EFAULT.
Regards,
Jan
>
> drivers/char/mem.c:
>
> static ssize_t write_null(struct file *file, const char __user *buf,
> size_t count, loff_t *ppos)
> {
> return count;
> }
>
> --
> Cyril Hrubis
> chru...@suse.cz
>
--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
___
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
Re: [LTP] [PATCH] mprotect04: fix powerpc crash when copying exec_func
- Original Message -
> From: "Cyril Hrubis" <chru...@suse.cz>
> To: "Jan Stancek" <jstan...@redhat.com>
> Cc: ltp-list@lists.sourceforge.net
> Sent: Wednesday, 9 September, 2015 2:37:37 PM
> Subject: Re: [LTP] [PATCH] mprotect04: fix powerpc crash when copying
> exec_func
>
> Hi!
> > Testcase tried to copy page size area starting at _func.
> > This results in crash on powerpc, because _func is too close
> > to end of page and subsequent page is not mapped:
>
> I was wondering about this problem when I was fixing the test, but could
> not actually hit it.
>
> > -static void *get_func(void *mem)
> > +static int page_present(void *p)
> > {
> > - memcpy(mem, exec_func, getpagesize());
> > + int fd;
> > +
> > + fd = SAFE_OPEN(cleanup, "page_present", O_WRONLY|O_CREAT, 0644);
>
> Why don't we use "/dev/null"?
It doesn't seem reliable:
open("/dev/null", O_WRONLY|O_CREAT, 0644) = 3
write(3, NULL, 1) = 1
close(3)= 0
I'm seeing this on RHEL6.7 kernel, I haven't tried latest upstream yet.
Regards,
Jan
>
>
> The rest looks good to me.
>
> --
> Cyril Hrubis
> chru...@suse.cz
>
--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
___
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
Re: [LTP] [PATCH] mprotect04: fix powerpc crash when copying exec_func
Hi!
> It doesn't seem reliable:
>
> open("/dev/null", O_WRONLY|O_CREAT, 0644) = 3
> write(3, NULL, 1) = 1
> close(3)= 0
>
> I'm seeing this on RHEL6.7 kernel, I haven't tried latest upstream yet.
Ah, you are right, the memory is not touched in the write_null()
function at all.
drivers/char/mem.c:
static ssize_t write_null(struct file *file, const char __user *buf,
size_t count, loff_t *ppos)
{
return count;
}
--
Cyril Hrubis
chru...@suse.cz
--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
___
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
