Text something like this might help?
"If chain A calls into chain B and B executes goto C then when C is finished execution does not return back to continue in B but rather returns all the way to A as if B had decided whatever C decides. If B chooses to jump to C however, when C is finished, B will continue forward from the location where the jump occurred."
The labels make it unambiguous but also adds complexity to follow.
Nov 14, 2024 2:07:23 PM Kerin Millar <kfm@xxxxxxxxxxxxx>:
> On Thu, 14 Nov 2024, at 8:47 PM, Pablo Neira Ayuso wrote:
>> On Thu, Nov 14, 2024 at 04:26:42PM +0000, Kerin Millar wrote:
>>> On Thu, 14 Nov 2024, at 3:51 PM, Kerin Millar wrote:
>>>> On Thu, 14 Nov 2024, at 2:01 PM, Thomas Köller wrote:
>>>>> The nft manpage states that if the end of a chain invoked via 'goto' is
>>>>> reached without a verdict, 'evaluation will continue at the last chain
>>>>> instead of the one containing the goto statement'. I cannot make sense
>>>>> of this; what is the 'last chain'?
>>>>
>>>> To say "last chain" is highly ambiguous. I suggest that it be rewritten
>>>> as "evaluation will continue as if the invoking rule had instead
>>>> specified 'return' as its verdict." Such would be simple, coherent and
>>>> correct.
>>>
>>> I just re-read the relevant section of the manual, which is as follows.
>>>
>>> goto chain Similar to jump, but the current position is not pushed to
>>> the call stack, meaning that after the new chain evaluation
>>> will continue at the last chain instead of the one
>>> containing the goto statement.
>>>
>>> I think that the language is reasonably clear as it stands, though it is lacking in punctuation. However, I can see how some readers would be thrown by the use of the world "last", particularly those that do not understand the concept of a call stack.
>>>
>>> Perhaps the following would be clearer, without unduly diminishing the technical nature of the language.
>>>
>>> goto chain Similar to jump, only the current position is not pushed to
>>> the call stack. Consequently, once the evaluation of the new
>>> new chain has concluded, evaluation shall continue as if the
>>> the invoking rule had instead specified 'return' as its
>>> verdict.
>>
>> This extract is very similar to what there is in the iptables manpage:
>>
>> goto chain Similar to jump, only the current position is not
>> pushed to
>> the call stack. This specifies that the evaluation
>> should
>> continue in the specified chain. Unlike jump,
>> return will
>> not continue evaluating in this chain but instead
>> in the chain
>> that called us via jump.
>
> To my mind, there are some issues with the above.
>
> Firstly, "this chain" might be ambiguous. Such a phrase could be construed as being a reference to the just-mentioned "specified chain" in the preceding sentence. The likes of you or I already know that such an interpretation would make little sense but this may not be apparent to the first-time reader. Ideally, there should be only one possible interpretation.
>
> Secondly, proceeding to use "return" as a noun rather than a verb could be construed as implying that a return verdict statement must be involved, which is untrue. Also, return where? Compare and contrast to something like "Unlike jump, if the specified chain is returned from, evaluation will not continue in the calling chain but instead [...]"
>
> Thirdly, to say that the "return will continue [...] in the chain that called us via jump" implies that a jump verdict statement had to have been involved, which is untrue. It fails to account for the control flow of the following ruleset, for example.
>
> table ip filter {
> chain INPUT {
> # This chain was never jumped to.
> type filter hook input priority filter; policy accept;
>
> # There is still a difference caused by using goto rather than jump here.
> iifname "eth0" goto input_eth0
> iifname "eth1" goto input_eth1
> }
>
> # There are no return statements.
> chain input_eth0 { }
> chain input_eth1 { }
> }
>
> Fourthly, referring to a chain - any chain - as "us" is not something that I would expect to see in a technical manual.
>
> While by no means perfect, the wording that I proposed tries to explain that, if the specified chain returns - whether implicitly or explicitly - the behaviour is as if processing a return verdict statement in the calling chain. The idea was to encourage the reader to cross-reference the description of return, which accounts for both scenarios:
>
> - returning from a chain that was jumped to
> - returning from a 'base' chain and thereby being subjected to the policy specified by a hook
>
> Put another way, it tries to leverage a definition that already exists elsewhere. Although, the description of return also uses the same phrase that threw the OP. There is only so much one can do, I suppose.
>
> --
> Kerin Millar
