Date: Sat, 15 Nov 2003 21:30:53 +0000
From: viro@parcelfarce.linux.theplanet.co.uk
To: Tigran Aivazian <tigran@aivazian.fsnet.co.uk>
Cc: Harald Welte <laforge@netfilter.org>, linux-kernel@vger.kernel.org
Subject: Re: seq_file and exporting dynamically allocated data
Message-ID: <20031115213053.GQ24159@parcelfarce.linux.theplanet.co.uk>
References: <20031115201444.GO24159@parcelfarce.linux.theplanet.co.uk> <Pine.LNX.4.44.0311152031590.743-100000@einstein.homenet>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.44.0311152031590.743-100000@einstein.homenet>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1482
Lines: 32

On Sat, Nov 15, 2003 at 08:41:45PM +0000, Tigran Aivazian wrote:
> in fs/seq_file.c:seq_read()
> 
>         if (!m->buf) {
>                 m->buf = kmalloc(m->size = PAGE_SIZE, GFP_KERNEL);

... and below
                m->buf = kmalloc(m->size <<= 1, GFP_KERNEL);

> are you saying that it is possible for userspace to request, say, 256K and 
> say 250K of available data could be returned (with seq_file API) on a 
> single read(2) call? I thought this is impossible and hence in the 

> So, as soon as ->show() is asked to display an element which didn't fit in
> the m->buf page it returns -1 and so the user gets a page (or almost a
> page, i.e.  as many entries as fit in there).

a) it's not a page; if any ->show() will need more, buffer will grow.

b) unless you are willing to allocate 250Kb per read(), you *can't* do
what you are asking for.  Regardless of implementation.  Which is an
immediate DoS (again, regardless of implementation).

read() is not atomic.  Never had been.  With seq_file you are guaranteed
that what you get will consist of entire entries (IOW, if previous read()
had ended inside the entry, the rest will be preserved for the next read()).
There are no stronger warranties and there never had been.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/