Messages in this thread | | | Date | Tue, 01 May 2012 19:04:53 -0400 | From | KOSAKI Motohiro <> | Subject | Re: [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 <kosaki.motohiro@jp.fujitsu.com>
> > All this reminds me that when this is taken into Linus' kernel, we need > to coordinate a man page update for the mq subsystem.
| |