linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Potentially unbounded allocations in seq_read?
Date: Wed, 11 Dec 2013 17:59:57 +0000	[thread overview]
Message-ID: <1386784797.6066.63.camel@tursulin-linux.isw.intel.com> (raw)
In-Reply-To: <20131211174909.GW10323@ZenIV.linux.org.uk>

On Wed, 2013-12-11 at 17:49 +0000, Al Viro wrote:
> On Wed, Dec 11, 2013 at 05:04:41PM +0000, Tvrtko Ursulin wrote:
> > Hi all,
> > 
> > It seems that the buffer allocation in seq_read can double in size
> > indefinitely, at least I've seen that in practice with /proc/<pid>/smaps
> > (attempting to double m->size to 4M on a read of 1000 bytes). This
> > produces an ugly WARN_ON_ONCE, which should perhaps be avoided? (given
> > that it can be triggered by userspace at will)
> 
> An entry in /proc/<pid>/smaps that did not fit into 2Mb?  Seriously?
> How in hell has that happened?  If you can trigger that at will, please
> post the reproducer.

Yeah, no, wrong assumption. It was not about the size but the number of
reads. For example:

open("/proc/3131/smaps", O_RDONLY|O_LARGEFILE) = 3
fstat64(1, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 3), ...}) = 0
brk(0xf9019000)                         = 0xf9019000
read(3, "be483000-be4ab000 rw-s 00000000 "..., 4096) = 4054
write(1, "be483000-be4ab000 rw-s 00000000 "..., 4054) = 4054
read(3, "be5c3000-be5c5000 rw-s 10da3f000"..., 4096) = 3656
write(1, "be5c3000-be5c5000 rw-s 10da3f000"..., 3656) = 3656
read(3, "be6b1000-be6b2000 rw-s 10da48000"..., 4096) = 3661
write(1, "be6b1000-be6b2000 rw-s 10da48000"..., 3661) = 3661
read(3, "be6b9000-be6ba000 rw-s 10da38000"..., 4096) = 3599
write(1, "be6b9000-be6ba000 rw-s 10da38000"..., 3599) = 3599
read(3, "be6d6000-be7b6000 rw-s 10d889000"..., 4096) = 3599
write(1, "be6d6000-be7b6000 rw-s 10d889000"..., 3599) = 3599
read(3, "be884000-be885000 rw-s 10d85c000"..., 4096) = 3661
write(1, "be884000-be885000 rw-s 10d85c000"..., 3661) = 3661
read(3, "be88d000-be8de000 rw-p 00000000 "..., 4096) = 4007
write(1, "be88d000-be8de000 rw-p 00000000 "..., 4007) = 4007
read(3, "bea29000-bea4d000 r-xp 00000000 "..., 4096) = 4057
write(1, "bea29000-bea4d000 r-xp 00000000 "..., 4057) = 4057
read(3, "beab3000-bead0000 r--p 00000000 "..., 4096) = 2092
write(1, "beab3000-bead0000 r--p 00000000 "..., 2092) = 2092
read(3, 0xf9017030, 4096)               = -1 ENOMEM (Out of memory)

Regards,
Tvrtko

  reply	other threads:[~2013-12-11 17:59 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-11 17:04 Potentially unbounded allocations in seq_read? Tvrtko Ursulin
2013-12-11 17:48 ` Tvrtko Ursulin
2013-12-11 18:00   ` Al Viro
2013-12-11 17:49 ` Al Viro
2013-12-11 17:59   ` Tvrtko Ursulin [this message]
2013-12-11 18:07     ` Al Viro
2013-12-12 13:40       ` Tvrtko Ursulin
2013-12-12 13:49         ` Al Viro
2013-12-12 13:59           ` Tvrtko Ursulin
2013-12-12 14:21             ` Al Viro
2013-12-12 14:52               ` Tvrtko Ursulin

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=1386784797.6066.63.camel@tursulin-linux.isw.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=akpm@linux-foundation.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 NNTP newsgroup(s).