Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 7 Feb 2022 18:24:59 -0800
From:   Alexei Starovoitov <alexei.starovoitov@gmail.com>
To:     Song Liu <song@kernel.org>
Cc:     bpf@vger.kernel.org, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net,
        andrii@kernel.org, kernel-team@fb.com, peterz@infradead.org,
        x86@kernel.org, iii@linux.ibm.com, Song Liu <songliubraving@fb.com>
Subject: Re: [PATCH v9 bpf-next 9/9] bpf, x86_64: use
 bpf_jit_binary_pack_alloc
Message-ID: <20220208022459.ufooz7cjbk6u3k6o@ast-mbp.dhcp.thefacebook.com>
References: <20220204185742.271030-1-song@kernel.org>
 <20220204185742.271030-10-song@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220204185742.271030-10-song@kernel.org>
Precedence: bulk

On Fri, Feb 04, 2022 at 10:57:42AM -0800, Song Liu wrote:
>  	if (image) {
>  		if (!prog->is_func || extra_pass) {
> +			/*
> +			 * bpf_jit_binary_pack_finalize fails in two scenarios:
> +			 *   1) header is not pointing to proper module memory;
> +			 *   2) the arch doesn't support bpf_arch_text_copy().
> +			 *
> +			 * Both cases are serious bugs that we should not continue.
> +			 */
> +			BUG_ON(bpf_jit_binary_pack_finalize(prog, header, rw_header));
>  			bpf_tail_call_direct_fixup(prog);
> -			bpf_jit_binary_lock_ro(header);

BUG_ON is discouraged.
It should only be used when the kernel absolutely cannot continue.
Here ro/rw_headers will be freed. We can WARN and goto out_addrs without drama.
Please send a follow up.

The rest looks great. Applied to bpf-next.