[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/sys/netinet6
> 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.
> 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?
Main Index |
Thread Index |