public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Michal Simek <monstr@monstr.eu>
To: "Steven J. Magnani" <steve@digidescorp.com>
Cc: microblaze-uclinux@itee.uq.edu.au, linux-kernel@vger.kernel.org,
	stable@kernel.org
Subject: Re: [PATCH] microblaze: fix /dev/zero corruption from __clear_user()
Date: Tue, 15 Feb 2011 08:43:27 +0100	[thread overview]
Message-ID: <4D5A2E9F.4080702@monstr.eu> (raw)
In-Reply-To: <1297361533-24627-1-git-send-email-steve@digidescorp.com>

Steven J. Magnani wrote:
> A userland read of more than PAGE_SIZE bytes from /dev/zero results in
> (a) not all of the bytes returned being zero, and
> (b) memory corruption due to zeroing of bytes beyond the user buffer.
> 
> This is caused by improper constraints on the assembly __clear_user function.
> The constrints don't indicate to the compiler that the pointer argument is
> modified. Since the function is inline, this results in double-incrementing
> of the pointer when __clear_user() is invoked through a multi-page read() of
> /dev/zero. 
> 
> Signed-off-by: Steven J. Magnani <steve@digidescorp.com>

I wasn't able to reproduce this issue on MMU and noMMU systems (log below).
I think it is toolchain issue.

Anyway it will be the best not to increment "to" at all and use "n" as offset.
This could also speed it up this function.
There is also possibility to add sb to delay slot but it works from Microblaze 5.00.a and later.

I will add this patch to my next branch and will be good to get some statistic and then to write
some optimization for it.

Acked-by: Michal Simek <monstr@monstr.eu>

Thanks,
Michal


My log:
# dd if=/dev/zero of=/tmp/1 bs=64k count=1
1+0 records in
1+0 records out
~ # hexdump /tmp/1
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0010000
~ # md5sum /tmp/1
fcd6bcb56c1689fcef28b57c22475bad  /tmp/1
~ # cat /proc/cpuinfo
CPU-Family:     MicroBlaze
FPGA-Arch:      spartan6
CPU-Ver:        7.30.a, big endian
CPU-MHz:        90.00
BogoMips:       44.54
HW:
  Shift:         yes
  MSR:           yes
  PCMP:          yes
  DIV:           no
  MMU:           3
  MUL:           v2
  FPU:           no
  Exc:           ill
Icache:         16kB    line length:    16B
Dcache:         16kB    line length:    16B
                 write-through
HW-Debug:       yes
PVR-USR1:       00
PVR-USR2:       00000000
Page size:      16384
~ #

-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian

      reply	other threads:[~2011-02-15  7:43 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-10 18:12 [PATCH] microblaze: fix /dev/zero corruption from __clear_user() Steven J. Magnani
2011-02-15  7:43 ` Michal Simek [this message]

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=4D5A2E9F.4080702@monstr.eu \
    --to=monstr@monstr.eu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=microblaze-uclinux@itee.uq.edu.au \
    --cc=stable@kernel.org \
    --cc=steve@digidescorp.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox