All of lore.kernel.org
 help / color / mirror / Atom feed
From: DervishD <raul@pleyades.net>
To: "David S. Miller" <davem@redhat.com>
Cc: linux-kernel@vger.kernel.org, marcelo@conectiva.com.br
Subject: Re: [BK-2.4] [PATCH] Small do_mmap_pgoff correction
Date: Tue, 10 Dec 2002 21:59:06 +0100	[thread overview]
Message-ID: <20021210205906.GA82@DervishD> (raw)
In-Reply-To: <20021210.124740.86261163.davem@redhat.com>

    Hi David :)

>    >    + *	NOTE: in this function we rely on TASK_SIZE being lower than
>    >    + *	SIZE_MAX-PAGE_SIZE at least. I'm pretty sure that it is.
>    > This assumption is wrong.
>        OK, then another way of fixing the corner case that exists in
>    do_mmap_pgoff is needed. You cannot mmap a chunk of memory whose size
>    is bigger than SIZE_MAX-PAGE_SIZE, because 'PAGE_ALIGN' will return 0
>    when page-aligning the size.
> And after your patch, we'd use a zero length.  That is a bug.

    With my patch, we don't use a zero length :?? My patch sees if
PAGE_ALIGN will f*ck the length, and if so, it returns EINVAL. This
is better than getting '0' as a valid address when specifying a large
size, don't you think so?

> Look at what happens, you PAGE_ALIGN(len) after all the range checks
> then we use a len of '0' for the rest of the function.  How is that
> supposed to be better?

    Because PAGE_ALIGN won't return 0? I don't see your assumption of
'len' going to zero due to my patch :?? With my patch, if the
requested size is '0', then the hint address is returned, and if the
size is so high that PAGE_ALIGN will barf at it, returning 0 when it
shouldn't, mmap will return EINVAL. The function never uses a 'len'
of 0. Never.

    Raúl

  reply	other threads:[~2002-12-10 20:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200212101931.gBAJV1K10639@hera.kernel.org>
2002-12-10 20:19 ` [BK-2.4] [PATCH] Small do_mmap_pgoff correction David S. Miller
2002-12-10 20:45   ` DervishD
2002-12-10 20:47     ` David S. Miller
2002-12-10 20:59       ` DervishD [this message]
2002-12-10 21:22         ` David S. Miller
2002-12-10 18:52           ` Marcelo Tosatti
2002-12-10 22:13           ` DervishD
2002-12-10 22:14             ` David S. Miller
2002-12-10 22:28               ` DervishD
2002-12-11  1:06                 ` David S. Miller
2002-12-11 12:32                   ` DervishD
2002-12-10 20:50 [BK-2.4] [Patch] " DervishD

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=20021210205906.GA82@DervishD \
    --to=raul@pleyades.net \
    --cc=davem@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo@conectiva.com.br \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.