Source-Changes-D archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src/sys/netinet6



hi,

> On Sun, May 10, 2009 at 8:44 AM, YAMAMOTO Takashi
> <yamt%mwd.biglobe.ne.jp@localhost> wrote:
> 
>>>> have you checked callers and ensure that the change from EACCES to EPERM
>>>> won't be a problem?
>>>
>>> Only ipsec_set_policy() returns EPERM instead of EACCES now, and I
>>> don't think it should be a problem.
>>
>> "don't think"?  why not?
>> i asked if you checked what the callers of ipsec_set_policy do with
>> the error number.  do you mean "yes, of course"?
>>
>>> As for calling context -- I did look at the callers and mostly I just
>>> moved the call inside instead of at the top. That's also why I didn't
>>> remove the last one in in6.c, where is obvious that it's done before
>>> splnet(), and still need to take care of it. :)
>>
>> i'm not sure what you mean.
>> my question was about the ipsec.c change.  sorry if it was not clear.
>>
>>> It's possible though that I've missed something. Do you see any problems?
>>
>> i don't know if there are problems or not.
>> i'm not familiar with the code in question.
>> i was just wondering about the implications of the error number change.
> 
> Okay, I misunderstood you. I thought you were asking about the calling
> context *and* the error value.
> 
> Anyway, the error value is just returned. The caller returns it if
> it's not zero. I could not find a place that checks specifically for
> EACCES, or documentation that says the user should check for it.
> Ioctl(4) doesn't mention it at all.

ok.

> That said, where we now return EPERM is where in the future we'll
> return the error value returned by kauth(9), like many many other
> places in the kernel. Other parts of the networking stacks (say,
> opening a raw socket) now return EPERM instead of EACCES

ip(4) and ip6(4) seem to document EACCES.

> -- if we're
> interested in checking whether this is a problem or not we should do
> so on a much larger scale, and not as a response to a specific change.

i'm not sure what you mean.
how can we check breakage without looking at each specific changes?

YAMAMOTO Takashi

> 
> Thanks,
> 
> -e.


Home | Main Index | Thread Index | Old Index