On Tue, May 6, 2025 at 5:10 PM T.J. Mercier wrote:
>
> +/**
> + * get_first_dmabuf - begin iteration through global list of DMA-bufs
> + *
> + * Returns the first buffer in the global list of DMA-bufs that's not in the
> + * process of being destroyed. Increments that buffer's reference count to
>
On Mon, May 5, 2025 at 10:08 AM T.J. Mercier wrote:
>
>
> Sounds good, will do. Thanks.
looks like the majority of the code will be touching various bpf bits,
so let's route the first 5 patches via bpf-next.
When you respin, please mention [PATCH bpf-next] in the subject,
so that CI can pick it u
On Tue, Apr 22, 2025 at 12:57 PM T.J. Mercier wrote:
>
> On Mon, Apr 21, 2025 at 4:39 PM Alexei Starovoitov
> wrote:
> >
> > On Mon, Apr 21, 2025 at 1:40 PM T.J. Mercier wrote:
> > >
> > > > > new file mode 100644
> > > > &
On Mon, Apr 21, 2025 at 1:40 PM T.J. Mercier wrote:
>
> > > new file mode 100644
> > > index ..b4b8be1d6aa4
> > > --- /dev/null
> > > +++ b/kernel/bpf/dmabuf_iter.c
> >
> > Maybe we should add this file to drivers/dma-buf. I would like to
> > hear other folks thoughts on this.
>
> This
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
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
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.
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
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
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
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
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.
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
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
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
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
16 matches
Mail list logo
