[PATCH] increase the upper limit of sg_io64.dxfer_len to make "sg_logs -p=0x0f /dev/sgN" happy

[Martin Schwenke]

>>>>> "David" == David Howells <dhowells at redhat.com> writes:

    David> Woody Zhou <zhouwoody at yahoo.com> wrote:

    >> Index: 2.4.21-15.EL/arch/ppc64/kernel/ioctl32.c
    >> ===================================================================
    >> --- arch/ppc64/kernel/ioctl32.c.orig    2004-05-25
    >> 15:18:46.000000000 +0800
    >> +++ arch/ppc64/kernel/ioctl32.c 2004-05-25 15:20:33.000000000 +0800
    >> @@ -1301,7 +1301,7 @@
    >> goto out;
    >> }
    >> } else {
    >> -               if (sg_io64.dxfer_len > 4*PAGE_SIZE) {
    >> +               if (sg_io64.dxfer_len > 8*PAGE_SIZE) {

    David> I'm not sure that this patch is the best way to do
    David> things. The larger the kmalloc() call made, the harder it
    David> is for the kernel to honour it. The kernel needs to find
    David> enough contiguous and properly aligned memory to be able to
    David> do this, and the larger the request, the harder it will be.

You're undoubtedly right, but the goal of this patch isn't to fix the
problem you're talking about - that problem has always been there!
:-)

Some time last year (or the year before?) the above condition was
added as an anti-denial-of-service measure.  However, the limit in the
condition is too small, causing a particular ioctl to fail (by only a
few bytes, simply due to the arbitrariness of the limit).  All that
the above patch does is increase the limit (by another arbitrary
amount :-) to make that ioctl work again...  or work at least as well
as it did before the arbitrary limit was introduced.

So, the patch that introduced the limit was flawed and we're trying to
fix a regression via a minimal patch.

In that context, could this patch go in until the code is fixed
properly?

peace & happiness,
martin