On Wed, Sep 4, 2024 at 5:18 PM Mina Almasry wrote:
>
> On Tue, Sep 3, 2024 at 2:40 PM Jakub Kicinski wrote:
> >
> > On Sat, 31 Aug 2024 00:43:08 + Mina Almasry wrote:
> > > static inline bool tcp_skb_can_collapse_to(const struct sk_buff *skb)
> > > {
> > > - return likely(!TCP_SKB_CB(sk
ol != IPPROTO_TCP)
> + return -EBADF;
This might use sk_is_tcp() helper.
> +
> + if (optlen % sizeof(struct dmabuf_token) ||
> + optlen > sizeof(*tokens) * 128)
> + return -EINVAL;
> +
> + tokens = kvmalloc_array(128, sizeof(*tokens), GFP_KERNEL);
This allocates 8192 bytes even for small optlen ?
Probably no big deal, no need to send a new version.
Reviewed-by: Eric Dumazet
g this page. All pages are released when the socket is
> destroyed.
>
> Signed-off-by: Willem de Bruijn
> Signed-off-by: Kaiyuan Zhang
> Signed-off-by: Mina Almasry
Reviewed-by: Eric Dumazet
b1->unreadable = skb->unreadable;
> skb_shinfo(skb)->nr_frags = 0;
> skb1->data_len = skb->data_len;
> skb1->len += skb1->data_len;
> @@ -4071,6 +4099,7 @@ static inline void skb_split_no_header(struct sk_buff
> *skb,
> {
> int i, k = 0;
> const int nfrags = skb_shinfo(skb)->nr_frags;
> + const int unreadable = skb->unreadable;
>
> skb_shinfo(skb)->nr_frags = 0;
> skb1->len = skb1->data_len = skb->len - len;
> @@ -4104,6 +4133,12 @@ static inline void skb_split_no_header(struct sk_buff
> *skb,
> pos += size;
> }
> skb_shinfo(skb1)->nr_frags = k;
> +
Minor point : skb->unreadable can be left as is ?
> + if (skb_shinfo(skb)->nr_frags)
> + skb->unreadable = unreadable;
Minor point : skb_shinfo(skb1)->nr_frags can't be zero at this point.
> +
> + if (skb_shinfo(skb1)->nr_frags)
> + skb1->unreadable = unreadable;
> }
This means we probably could remove the unreadable variable and
skb1->unreadable = skb->unreadable;
No need to send a new version, this can be incrementally changed later.
Reviewed-by: Eric Dumazet
On Fri, Jun 28, 2024 at 2:33 AM Mina Almasry wrote:
>
> Make skb_frag_page() fail in the case where the frag is not backed
> by a page, and fix its relevant callers to handle this case.
>
> Signed-off-by: Mina Almasry
>
Reviewed-by: Eric Dumazet
On Tue, Nov 7, 2023 at 10:05 PM Stanislav Fomichev wrote:
>
> I don't understand. We require an elaborate setup to receive devmem cmsgs,
> why would some random application receive those?
A TCP socket can receive 'valid TCP packets' from many different sources,
especially with BPF hooks...
Thi
On Tue, Apr 25, 2023 at 12:06 AM Andrzej Hajda wrote:
>
> Similar to stack_(depot|trace)_snprint the patch
> adds helper to printing stats to memory buffer.
> It will be helpful in case of debugfs.
>
> Signed-off-by: Andrzej Hajda
> Reviewed-by: Andi Shyti
Reviewed-by: Eric Dumazet
ed-off-by: Andrzej Hajda
> Reviewed-by: Andi Shyti
Reviewed-by: Eric Dumazet
th this lock taken.
> As a bonus we can reuse this helper in ref_tracker_dir_exit.
>
> Signed-off-by: Andrzej Hajda
> Reviewed-by: Andi Shyti
> ---
SGTM, thanks.
Reviewed-by: Eric Dumazet
t;
> Signed-off-by: Andrzej Hajda
> Reviewed-by: Andi Shyti
> ---
Reviewed-by: Eric Dumazet
Thanks.
On Fri, Apr 21, 2023 at 1:35 PM Andrzej Hajda wrote:
>
> In case the library is tracking busy subsystem, simply
> printing stack for every active reference will spam log
> with long, hard to read, redundant stack traces. To improve
> readabilty following changes have been made:
> - reports are pri
On Wed, Dec 14, 2022 at 1:34 PM Stanislaw Gruszka
wrote:
>
> On Mon, Dec 12, 2022 at 03:35:20PM +0100, Jason A. Donenfeld wrote:
> > Please CC me on future revisions.
> >
> > As of 6.2, the prandom namespace is *only* for predictable randomness.
> > There's no need to rename anything. So nack on t
On 08/01/2018 03:34 AM, Dmitry Vyukov wrote:
> On Wed, Aug 1, 2018 at 12:23 PM, Eric Dumazet wrote:
>> On 08/01/2018 02:03 AM, Andrey Ryabinin wrote:
>>
>>> I can't think of any advantage in not having the constructor.
>>
>> I can't see any
On Wed, Aug 1, 2018 at 8:15 AM Christopher Lameter wrote:
>
> On Wed, 1 Aug 2018, Dmitry Vyukov wrote:
>
> > But we are trading 1 indirect call for comparable overhead removed
> > from much more common path. The path that does ctors is also calling
> > into page alloc, which is much more expensive
On 08/01/2018 09:22 AM, Christopher Lameter wrote:
> On Wed, 1 Aug 2018, Eric Dumazet wrote:
>
>> The idea of having a ctor() would only be a win if all the fields that
>> can be initialized in the ctor are contiguous and fill an integral
>> number of cache lines.
&g
On 08/01/2018 02:03 AM, Andrey Ryabinin wrote:
> I can't think of any advantage in not having the constructor.
>
I can't see any advantage adding another indirect call,
in RETPOLINE world.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
On Tue, Jul 31, 2018 at 10:10 AM Florian Westphal wrote:
>
> Andrey Ryabinin wrote:
> > Guys, it seems that we have a lot of code using SLAB_TYPESAFE_BY_RCU cache
> > without constructor.
> > I think it's nearly impossible to use that combination without having bugs.
> > It's either you don't re
On Tue, Jul 31, 2018 at 10:51 AM Dmitry Vyukov wrote:
>
>
> Is it OK to overwrite ct->status? It seems that are some read and
> writes to it right after atomic_inc_not_zero.
If it is after a (successful) atomic_inc_not_zero(),
the object is guaranteed to be alive (not freed or about to be freed).
On Tue, Jul 31, 2018 at 10:36 AM Christopher Lameter wrote:
>
> If there is refcounting going on then why use SLAB_TYPESAFE_BY_RCU?
To allow fast reuse of objects, without going through call_rcu() and
reducing cache efficiency.
I believe this is mentioned in Documentation/RCU/rculist_nulls.txt
On Wed, Aug 1, 2018 at 9:47 AM Dmitry Vyukov wrote:
>
> Proving with numbers is required for a claimed performance improvement
> at the cost of code degradation/increase. For a win-win change there
> is really nothing to prove.
You have to _prove_ it is a win-win.
It is not sufficient to claim i
20 matches
Mail list logo
