On 30/08/2024 10:18 am, Roger Pau Monné wrote: > On Thu, Aug 29, 2024 at 09:04:37AM +0200, Jan Beulich wrote: >> On 29.08.2024 02:35, Stefano Stabellini wrote: >>> On Mon, 29 Jul 2024, Stefano Stabellini wrote: >>>> On Mon, 29 Jul 2024, Federico Serafini wrote: >>>>> Add defensive return statement at the end of an unreachable >>>>> default case. Other than improve safety, this meets the requirements >>>>> to deviate a violation of MISRA C Rule 16.3: "An unconditional `break' >>>>> statement shall terminate every switch-clause". >>>>> >>>>> Signed-off-by: Federico Serafini <federico.seraf...@bugseng.com> >>>> Reviewed-by: Stefano Stabellini <sstabell...@kernel.org> >>>> >>>>> --- >>>>> No changes from v3 and v4, further feedback on this thread would be >>>>> appreciated: >>>>> https://lists.xenproject.org/archives/html/xen-devel/2024-07/msg00474.html >>> Looking at the older threads, I looks like Jan suggested EACCES, I also >>> think it is marginally better. My R-b stands also for EACCES. Jan, I >>> think you should go ahead and fix on commit >> No, I very definitely want a 2nd x86 maintainer opinion here. Or a better >> suggestion for the error code to use by anyone. After all, as you confirm, >> EACCES is only marginally better. > Hm, the only alternative I could suggest is using ERANGE, to signal > the value of opt_mmio_relax is out of the expected range, however that > could be confusing for the callers? > > One benefit of using ERANGE is that there's currently no return path > in get_page_from_l1e() with that error code, so it would be very easy > to spot when an unexpected value of opt_mmio_relax is found. However > there are no guarantees that further error paths might use that error > code.
EPERM and EACCES are both very wrong here. They imply something that is simply not appropriate in this context. We use EILSEQ elsewhere for believed-impossible conditions where we need an errno of some kind. I suggest we use it here too. ~Andrew
