[lkml]   [2012]   [May]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [Patch 3/4] ipc/mqueue: strengthen checks on mqueue creation
    (5/1/12 7:02 PM), Doug Ledford wrote:
    > On 5/1/2012 4:18 PM, KOSAKI Motohiro wrote:
    >>>> But ENOMEM is more inaccurate. It almostly is used for kmalloc failure.
    >>> I chose ENOMEM for that particular error because above there we have
    >>> checked the passed in arguments to make sure that they don't violate our
    >>> allowances for max message or max message size. If we violate either of
    >>> those items, we return EINVAL. In this case, neither of the values is
    >>> invalid, it's just that together they make an overly large allocation.
    >>> I would see that as more helpful to a programmer than EINVAL when the
    >>> values are within the maximums allowed. At least with ENOMEM the
    >>> programmer knows they have to reduce their combined message size and
    >>> message count in order to get things working.
    >> Incorrect. When ENOMEM is returned, programmers can't know
    >> which problem was happen 1) kernel has real memory starvation
    >> or 2) queue limitation exceed was happen. The problem is, you
    >> introduced new overloaded error code for avoiding overload error code.
    >> It doesn't make sense. My question was, why can't you choose no
    >> overload error code if you want accurate one?
    > OK, then would EOVERFLOW suit things better?

    I have no seen to any confusion source this. thank you.

    then, ack all of this series.
    Acked-by: KOSAKI Motohiro <>

    > All this reminds me that when this is taken into Linus' kernel, we need
    > to coordinate a man page update for the mq subsystem.

     \ /
      Last update: 2012-05-02 01:21    [W:0.022 / U:6.216 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site