On Fri, 10 Nov 2023 18:27:08 -0800 Mina Almasry wrote:
> Thanks for the clear requirement. I clearly had something different in mind.
>
> Might be dumb suggestions, but instead of creating a new ndo that we
> maybe end up wanting to deprecate once the queue API is ready, how
> about we use either
On Fri, Nov 10, 2023 at 3:13 PM Jakub Kicinski wrote:
>
> My brain is slightly fried after trying to catch up on the thread
> for close to 2h. So forgive me if I'm missing something.
> This applies to all emails I'm about to send :)
>
> On Sun, 5 Nov 2023 18:44:11 -0800 Mina Almasry wrote:
> > +
On Fri, Nov 10, 2023 at 3:20 PM Jakub Kicinski wrote:
>
> On Sun, 5 Nov 2023 18:44:03 -0800 Mina Almasry wrote:
> > --- a/include/linux/netdevice.h
> > +++ b/include/linux/netdevice.h
> > @@ -52,6 +52,8 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> >
> > struct
On Sun, 5 Nov 2023 18:44:03 -0800 Mina Almasry wrote:
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -52,6 +52,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> struct netpoll_info;
> struct device;
> @@ -808,6 +810,84 @@ bool
On Sun, 5 Nov 2023 18:44:07 -0800 Mina Almasry wrote:
> #include
> #include
> +#include
> +#include
> /**
> * DOC: skb checksums
> @@ -3402,15 +3404,38 @@ static inline void skb_frag_off_copy(skb_frag_t
> *fragto,
> fragto->bv_offset = fragfrom->bv_offset;
> }
>
> +/* Returns
On Sun, 5 Nov 2023 18:44:09 -0800 Mina Almasry wrote:
> + if (!skb_frags_not_readable(skb)) {
nit: maybe call the helper skb_frags_readable() and flip
the polarity, avoid double negatives.
On Sun, 5 Nov 2023 18:44:11 -0800 Mina Almasry wrote:
> + if (ynl_subscribe(*ys, "mgmt"))
> + goto err_close;
Why? :)
On Tue, 7 Nov 2023 14:23:20 -0800 Stanislav Fomichev wrote:
> Can we mark a socket as devmem-only? Do we have any use-case for those
> hybrid setups? Or, let me put it that way: do we expect API callers
> to handle both linear and non-linear cases correctly?
> As a consumer of the previous
On Sun, 5 Nov 2023 18:44:02 -0800 Mina Almasry wrote:
> + -
> +name: queues
> +doc: receive queues to bind the dma-buf to.
> +type: u32
> +multi-attr: true
I think that you should throw in the queue type.
I know you made the op imply RX:
> +-
> +
On Sun, 5 Nov 2023 18:44:05 -0800 Mina Almasry wrote:
> +static int mp_dmabuf_devmem_init(struct page_pool *pool)
> +{
> + struct netdev_dmabuf_binding *binding = pool->mp_priv;
> +
> + if (!binding)
> + return -EINVAL;
> +
> + if (pool->p.flags & PP_FLAG_DMA_MAP ||
> +
On Thu, 09 Nov 2023 12:05:37 +0100 Paolo Abeni wrote:
> > I suppose we just disagree on the elegance of the API.
>
> FWIW, I think sockopt +cmsg is the right API.
FWIW it's fine by me as well.
My brain is slightly fried after trying to catch up on the thread
for close to 2h. So forgive me if I'm missing something.
This applies to all emails I'm about to send :)
On Sun, 5 Nov 2023 18:44:11 -0800 Mina Almasry wrote:
> + trigger_device_reset();
The user space must not be
In order to pass functions to kunit_add_action(), they need to be of the
kunit_action_t type. While casting the function pointer can work, it
will break control-flow integrity.
drm_kunit_helpers already defines wrappers, but we now have a macro
which does this automatically. Using this greatly
In order to pass functions to kunit_add_action(), they need to be of the
kunit_action_t type. While casting the function pointer can work, it
will break control-flow integrity.
vc4_mock already defines such a wrapper for drm_dev_unregister(), but it
involves less boilerplate to use the new macro,
KUnit's deferred action API accepts a void(*)(void *) function pointer
which is called when the test is exited. However, we very frequently
want to use existing functions which accept a single pointer, but which
may not be of type void*. While this is probably dodgy enough to be on
the wrong side
On Fri, Nov 10, 2023 at 01:51:44PM -0500, Konstantin Ryabitsev wrote:
> This list is being migrated to new vger infrastructure. No action is required
> on your part and there will be no change in how you interact with this list
> after the migration is completed.
>
> There will be a short
On 11/5/23 15:40, Sergio González Collado wrote:
[...]
diff --git a/lib/Makefile b/lib/Makefile
index 740109b6e2c8..82ac084b6bc6 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -402,6 +402,7 @@ obj-$(CONFIG_FORTIFY_KUNIT_TEST) += fortify_kunit.o
obj-$(CONFIG_STRCAT_KUNIT_TEST) +=
On 11/7/23 23:03, Mina Almasry wrote:
On Tue, Nov 7, 2023 at 2:55 PM David Ahern wrote:
On 11/7/23 3:10 PM, Mina Almasry wrote:
On Mon, Nov 6, 2023 at 3:44 PM David Ahern wrote:
On 11/5/23 7:44 PM, Mina Almasry wrote:
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
On Thu, 9 Nov 2023 at 23:37, Krister Johansen wrote:
> Either should do, but I wasn't sure which approach was preferable.
An incremental is better in this situation. Applied and pushed.
> Thanks, and my apologies for the inconvenience.
Really no need to apologize, this happens and the best
On 2023/11/10 10:59, Mina Almasry wrote:
> On Thu, Nov 9, 2023 at 12:30 AM Paolo Abeni wrote:
>>
>> I'm trying to wrap my head around the whole infra... the above line is
>> confusing. Why do you increment dma_addr? it will be re-initialized in
>> the next iteration.
>>
>
> That is just a
On November 9, 2023 6:03:02 AM PST, Mark Brown wrote:
>On Thu, Nov 09, 2023 at 06:57:08PM +0530, Naresh Kamboju wrote:
>> Following kernel panic noticed while running selftests: exec: load_address
>> on Fastmodels (FVP) running Linux next-20231109.
>>
>
>Copying in Kees and Eric who maintain
On Thu, Nov 9, 2023 at 1:15 AM Paolo Abeni wrote:
>
> On Sun, 2023-11-05 at 18:44 -0800, Mina Almasry wrote:
> [...]
> > @@ -3421,7 +3446,7 @@ static inline struct page *skb_frag_page(const
> > skb_frag_t *frag)
> > */
> > static inline void __skb_frag_ref(skb_frag_t *frag)
> > {
> > -
On Thu, Nov 9, 2023 at 11:38 PM Yunsheng Lin wrote:
>
> On 2023/11/10 10:59, Mina Almasry wrote:
> > On Thu, Nov 9, 2023 at 12:30 AM Paolo Abeni wrote:
> >>
> >> I'm trying to wrap my head around the whole infra... the above line is
> >> confusing. Why do you increment dma_addr? it will be
On Fri, Nov 10, 2023, Xin3 Li wrote:
> > > >+if (cpu_feature_enabled(X86_FEATURE_FRED) &&
> > > >+!(_vmentry_control & VM_ENTRY_LOAD_IA32_FRED)) {
> > > >+pr_warn_once("FRED enabled but no VMX VM-Entry
> > LOAD_IA32_FRED control: %x\n",
> > > >+
24 matches
Mail list logo
