On 10 March 2015 at 18:51, Kees Cook <keescook@xxxxxxxxxxxx> wrote: > On Tue, Mar 10, 2015 at 10:46 AM, Michael Kerrisk (man-pages) > <mtk.manpages@xxxxxxxxx> wrote: >> Hi Kees, >> >> On 10 March 2015 at 18:41, Kees Cook <keescook@xxxxxxxxxxxx> wrote: >>> On Tue, Mar 10, 2015 at 10:24 AM, Michael Kerrisk (man-pages) >>> <mtk.manpages@xxxxxxxxx> wrote: >>>> Hi Kees, >>>> >>>> I was looking further at the seccomp(2) man page we put togetehr a >>>> while ago, and in particular at the example [1]. I realized that from >>>> a readability view, the order of the statements is rather contorted, >>>> so that we have branches to the end of the code (labels 5 and 6) to >>>> handle the syscall and arch mismatch cases, rather than swapping the >>>> branch order on the statements labeled 0 and 1, and having the kill >>>> statements immediately follow the test statements. >>>> >>>> However, I presume the ordering is as it is for efficiency reasons, so >>>> that the common case involves no branch forward (i.e., a branch offset >>>> of 0). Is that the case? If so, probably something should be said in >>>> the man page. >>> >>> I've never attempting timing tests to see if branching in the common >>> path is actually any more expensive, but it's not unreasonable. I >> >> Okay. >> >>> think the main reason it was written this way was actually for size. >>> There's 1 kill statement, which avoids repeating it, and (I think) is >>> more readable. >> >> FWIW, I find it less readable ;-). That's because one has to count the >> BPF statements to branch over (that's why I added the "[n]" labels to >> the code). Also, it makes the code trickier to maintain, since, if one >> adds some code in the branched over region, then the branch offset >> needs to be modified. Just my 2¢. > > Yeah, that does become a pain. :) I wonder if maybe some mention of > libseccomp should be made, since it operates as a front-end for > generating seccomp filters, which makes most of this pain go away. Good point. I'll add mention of libseccomp to the page. Cheers, Michael -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
