Re: [bpf-next,v3,1/2] bpftool: Accept symbolic map creation flags

[Tianyi Chen <diannaaav@gmail.com>]

Hi Kernel CI team,

Following up on the empty-patch reports: the affected PRs expired, and I
have now rebased and resubmitted the six pending topics with the remaining
review corrections. These are the current versions:

- cpumask v2:
  https://lore.kernel.org/r/20260911025029.190453-1-diannaaav@gmail.com
- batch-key validators v3:
  https://lore.kernel.org/r/20260911025036.190487-1-diannaaav@gmail.com
- symbolic map flags v4:
  https://lore.kernel.org/r/20260911025044.190540-1-diannaaav@gmail.com
- recursive dump v4:
  https://lore.kernel.org/r/20260911025100.190706-1-diannaaav@gmail.com
- ring buffer event_pipe v3:
  https://lore.kernel.org/r/20260911025114.190899-1-diannaaav@gmail.com
- batched dump v3:
  https://lore.kernel.org/r/20260911025130.191011-1-diannaaav@gmail.com

All ten patches apply cleanly to their current bpf or bpf-next base.
The 69 bpftool and 36 cpumask subtests passed in an x86-64 KVM guest
running the rebuilt bpf/master kernel (7.3.0-rc2); test_maps also passed,
with no skips in these runs. This was focused validation, not the full
BPF suite.

The emails were generated by git format-patch and sent using git
send-email, with a new thread for each version. The BPF test changes are
unchanged apart from rebasing; their previous "Patch is empty" reports
did not identify conflicting hunks.

Please use these versions for subsequent CI runs. If the empty-patch
failure recurs, please check the mailbox download/access path described
in my earlier report before treating it as a source conflict. I still
cannot inspect the daemon's downloaded payload directly.

Thanks,
Tianyi