Re: [PATCH v2 bpf-next 1/2] drm, bpf: Move drm_mm.c to lib to be used by bpf arena

On Tue, Nov 5, 2024 at 1:20 PM Alexei Starovoitov wrote: > > From: Alexei Starovoitov > > Move drm_mm.c to lib: > - The next commit will use drm_mm to manage memory regions > in bpf arena. > - Move drm_mm_print to drivers/gpu/drm/drm_print.c, since > it's not a

[PATCH v2 bpf-next 2/2] bpf: Switch bpf arena to use drm_mm instead of maple_tree

From: Alexei Starovoitov bpf arena is moving towards non-sleepable allocations in tracing context while maple_tree does kmalloc/kfree deep inside. Hence switch bpf arena to drm_mm algorithm that works with externally provided drm_mm_node-s. This patch kmalloc/kfree-s drm_mm_node-s, but the next

[PATCH v2 bpf-next 0/2] drm, bpf: User drm_mm in bpf

From: Alexei Starovoitov Hi DRM folks, we'd like to start using drm_mm in bpf arena. The drm_mm logic fits particularly well to bpf use case. See individual patches. objdump -h lib/drm_mm.o .text 12c7 So no vmlinux size concerns. v1->v2: - Fix build issues and add Acks.

[PATCH v2 bpf-next 1/2] drm, bpf: Move drm_mm.c to lib to be used by bpf arena

From: Alexei Starovoitov Move drm_mm.c to lib: - The next commit will use drm_mm to manage memory regions in bpf arena. - Move drm_mm_print to drivers/gpu/drm/drm_print.c, since it's not a core functionality of drm_mm and it depeneds on drm_printer while drm_mm is generic and usuable

[PATCH bpf-next 0/2] drm, bpf: User drm_mm in bpf

From: Alexei Starovoitov Hi DRM folks, we'd like to start using drm_mm in bpf arena. The drm_mm logic fits particularly well to bpf use case. See individual patches. objdump -h lib/drm_mm.o .text 12c7 So no vmlinux size concerns. Alexei Starovoitov (2): drm, bpf: Move drm

[PATCH bpf-next 2/2] bpf: Switch bpf arena to use drm_mm instead of maple_tree

From: Alexei Starovoitov bpf arena is moving towards non-sleepable allocations in tracing context while maple_tree does kmalloc/kfree deep inside. Hence switch bpf arena to drm_mm algorithm that works with externally provided drm_mm_node-s. This patch kmalloc/kfree-s drm_mm_node-s, but the next

[PATCH bpf-next 1/2] drm, bpf: Move drm_mm.c to lib to be used by bpf arena

From: Alexei Starovoitov Move drm_mm.c to lib. The next commit will use drm_mm to manage memory regions in bpf arena. Move drm_mm_print to drivers/gpu/drm/drm_print.c, since it's not a core functionality of drm_mm and it depeneds on drm_printer while drm_mm is generic and usuable as-is by

Re: [linux-next:master] BUILD REGRESSION 8568bb2ccc278f344e6ac44af6ed010a90aa88dc

On Fri, Apr 5, 2024 at 8:37 AM kernel test robot wrote: > > tree/branch: > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master > branch HEAD: 8568bb2ccc278f344e6ac44af6ed010a90aa88dc Add linux-next > specific files for 20240405 > > Error/Warning reports: > > https://lore.

Re: [PATCH 1/3] selftests/bpf: Update LLVM Phabricator links

On Thu, Jan 11, 2024 at 11:40 AM Nathan Chancellor wrote: > > Hi Yonghong, > > On Wed, Jan 10, 2024 at 08:05:36PM -0800, Yonghong Song wrote: > > > > On 1/9/24 2:16 PM, Nathan Chancellor wrote: > > > reviews.llvm.org was LLVM's Phabricator instances for code review. It > > > has been abandoned in

Re: [PATCH bpf v2] treewide: add missing includes masked by cgroup -> bpf dependency

On Thu, Dec 2, 2021 at 11:11 PM Greg KH wrote: > > On Thu, Dec 02, 2021 at 12:34:00PM -0800, Jakub Kicinski wrote: > > cgroup.h (therefore swap.h, therefore half of the universe) > > includes bpf.h which in turn includes module.h and slab.h. > > Since we're about to get rid of that dependency we n

Re: [PATCH V2] include: linux: Regularise the use of FIELD_SIZEOF macro

On Tue, Jun 11, 2019 at 5:00 PM Shyam Saini wrote: > > Currently, there are 3 different macros, namely sizeof_field, SIZEOF_FIELD > and FIELD_SIZEOF which are used to calculate the size of a member of > structure, so to bring uniformity in entire kernel source tree lets use > FIELD_SIZEOF and repl

Re: [PATCH 1/2] include: linux: Regularise the use of FIELD_SIZEOF macro

On Sun, Apr 14, 2019 at 2:15 AM Shyam Saini wrote: > > Currently, there are 3 different macros, namely sizeof_field, SIZEOF_FIELD > and FIELD_SIZEOF which are used to calculate the size of a member of > structure, so to bring uniformity in entire kernel source tree lets use > FIELD_SIZEOF and repl