On Mon, Jun 26, 2023 at 12:04:45PM +0200, Florent Revest wrote:
On Mon, Jun 26, 2023 at 6:36 AM Sasha Levin <sashal@xxxxxxxxxx> wrote:
This is a note to let you know that I've just added the patch titled
seq_file: Add a seq_bprintf function
to the 5.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
seq_file-add-a-seq_bprintf-function.patch
and it can be found in the queue-5.10 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.
commit 9962e90152e5c0e33b72e397a9f68f2886ed063b
Author: Florent Revest <revest@xxxxxxxxxxxx>
Date: Tue Apr 27 19:43:12 2021 +0200
seq_file: Add a seq_bprintf function
[ Upstream commit 76d6a13383b8e3ff20a9cf52aa9c3de39e485632 ]
Similarly to seq_buf_bprintf in lib/seq_buf.c, this function writes a
printf formatted string with arguments provided in a "binary
representation" built by functions such as vbin_printf.
Signed-off-by: Florent Revest <revest@xxxxxxxxxxxx>
Signed-off-by: Alexei Starovoitov <ast@xxxxxxxxxx>
Link: https://lore.kernel.org/bpf/20210427174313.860948-2-revest@xxxxxxxxxxxx
Stable-dep-of: 935d44acf621 ("memfd: check for non-NULL file_seals in memfd_create() syscall")
Does this trailer mean that this patch has been automatically
identified as a direct dependency of that memfd change ? This doesn't
seem right. As far as I can tell, that memfd patch modifies other
files and doesn't call seq_bprintf.
I don't see anything wrong with backporting this but I don't see the
need either.
Yup, this was a mistake. The longer dependency chain for 5.10 was:
38d26d89b31d ("bpf: Lock bpf_trace_printk's tmp buf before it is written to")
76d6a13383b8 ("seq_file: Add a seq_bprintf function")
48cac3f4a96d ("bpf: Implement formatted output helpers with bstr_printf")
b24abcff918a ("bpf, kconfig: Add consolidated menu entry for bpf with core options")
08389d888287 ("bpf: Add kconfig knob for disabling unpriv bpf by default")
39c65a94cd96 ("mm/pagealloc: sysctl: change watermark_scale_factor max limit to 30%")
78e36f3b0dae ("sysctl: move some boundary constants from sysctl.c to sysctl_vals")
6fd7353829ca ("mm/memfd: add F_SEAL_EXEC")
105ff5339f49 ("mm/memfd: add MFD_NOEXEC_SEAL and MFD_EXEC")
935d44acf621 ("memfd: check for non-NULL file_seals in memfd_create() syscall")
We obviously we don't need all of these for the backport, but this patch
slipped in...
Coincidentally, I've noticed that another patch of mine ("bpf/btf
Accept function names that contain dots") which I expect to be
backported to all stable trees got queued at the same time to all
other stable kernels (5.15, 6.1, 6.3) but not this one (5.10). Could
it be a mix-up and the wrong patch got backported to 5.10 ? (apologies
if that's a naive question, I'm still new to stable and try to make
sense of it, I have no idea what sort of automation goes into it! :) )
Unrelated :)
I took a look, and the patch didn't apply cleanly on 5.10 and so it
didn't go in. If you'd want stronger guarantees in the future around the
process please tag those patches explicitly for stable rather than just
adding a Fixes tag (this way, for example, you would have gotten a mail
when the patch failed to apply).
Let me see if I can fix it up...
--
Thanks,
Sasha