On Fri, Apr 26, 2024 at 10:47 AM wrote:
>
> From: Peilin He
>
> Introduce a tracepoint for icmp_send, which can help users to get more
> detail information conveniently when icmp abnormal events happen.
>
> 1. Giving an usecase example:
> =
> When an application
st=x state=x reason=NOT_SPECIFIED
> -0 [002] ..s1. 1830.262425: tcp_send_reset: skbaddr=x
> skaddr=x src=x dest=x state=x reason=NO_SOCKET
>
> [1]
> Link:
> https://lore.kernel.org/all/CANn89iJw8x-LqgsWOeJQQvgVg6DnL5aBRLi10QN2WBdr+X4k=w...@mail.gmail.com/
Reviewed-by: Eric Dumazet
Thanks !
tate=TCP_ESTABLISHED reason=NOT_SPECIFIED
>
> Signed-off-by: Jason Xing
> Reviewed-by: Steven Rostedt (Google)
> ---
Reviewed-by: Eric Dumazet
ason.
>
> Note: using SK_RST_REASON_NOT_SPECIFIED is the same as
> SK_RST_REASON_MPTCP_RST_EUNSPEC. They are both unknown. So we can convert
> it directly.
>
> Suggested-by: Paolo Abeni
> Signed-off-by: Jason Xing
> Reviewed-by: Matthieu Baerts (NGI0)
Reviewed-by: Eric Dumazet
: Jason Xing
> Reviewed-by: Matthieu Baerts (NGI0)
Reviewed-by: Eric Dumazet
On Thu, Apr 25, 2024 at 5:14 AM Jason Xing wrote:
>
> From: Jason Xing
>
> Like what we did to passive reset:
> only passing possible reset reason in each active reset path.
>
> No functional changes.
>
> Signed-off-by: Jason Xing
> Acked-by: Matthieu Baerts (NGI0)
Reviewed-by: Eric Dumazet
On Thu, Apr 25, 2024 at 5:14 AM Jason Xing wrote:
>
> From: Jason Xing
>
> Adjust the parameter and support passing reason of reset which
> is for now NOT_SPECIFIED. No functional changes.
>
> Signed-off-by: Jason Xing
> Acked-by: Matthieu Baerts (NGI0)
Reviewed-by: Eric Dumazet
fter this series applied, it will have the ability to open a new
> gate to let other people contribute more reasons into it :)
>
> Signed-off-by: Jason Xing
> Acked-by: Matthieu Baerts (NGI0)
Reviewed-by: Eric Dumazet
On Fri, Apr 19, 2024 at 9:29 AM Jason Xing wrote:
>
> On Fri, Apr 19, 2024 at 3:02 PM Eric Dumazet wrote:
> >
> > On Fri, Apr 19, 2024 at 4:31 AM Jason Xing
> > wrote:
> > >
> > > On Fri, Apr 19, 2024 at 7:26 AM Jason Xing
> > > wrote:
> + tcp_v4_send_reset(NULL, skb, rst_reason);
> }
>
> discard_it:
>
> As you can see, we need to add a new 'rst_reason' variable which
> actually is the same as drop reason. They are the same except for the
> enum type... Such rst_reasons/drop_reasons are all over th
ted', until now I don't think I need to change something.
> > >
> > > Should I repost this series (keeping the v6 tag) and then wait for
> > > more comments?
> >
> > If Eric doesn't like it - it's not getting merged.
>
> I'm not a English native speaker. If I un
On Wed, Apr 17, 2024 at 10:51 AM Jason Xing wrote:
>
> From: Jason Xing
>
> Add a new standalone file for the easy future extension to support
> both active reset and passive reset in the TCP/DCCP/MPTCP protocols.
>
> This patch only does the preparations for reset reason mechanism,
> nothing
On Fri, Mar 29, 2024 at 11:23 AM Jason Xing wrote:
>
> On Fri, Mar 29, 2024 at 5:07 PM Eric Dumazet wrote:
> >
> > On Fri, Mar 29, 2024 at 4:43 AM Jason Xing
> > wrote:
> > >
> > > From: Jason Xing
> > >
> > > Prior to this pat
On Fri, Mar 29, 2024 at 4:43 AM Jason Xing wrote:
>
> From: Jason Xing
>
> In addition to knowing the 4-tuple of the flow which generates RST,
> the reason why it does so is very important because we have some
> cases where the RST should be sent and have no clue which one
> exactly.
>
> Adding
On Fri, Mar 29, 2024 at 4:43 AM Jason Xing wrote:
>
> From: Jason Xing
>
> Prior to this patch, what we can see by enabling trace_tcp_send is
> only happening under two circumstances:
> 1) active rst mode
> 2) non-active rst mode and based on the full socket
>
> That means the inconsistency
igned-off-by: Jason Xing
Reviewed-by: Eric Dumazet
On Tue, Mar 26, 2024 at 11:44 AM Jason Xing wrote:
> Well, it's a pity that it seems that we are about to abandon this
> method but it's not that friendly to the users who are unable to
> deploy BPF...
It is a pity these tracepoint patches are consuming a lot of reviewer
time, just because
some
On Thu, Mar 21, 2024 at 4:09 AM wrote:
>
> From: he peilin
>
> Introduce a tracepoint for icmp_send, which can help users to get more
> detail information conveniently when icmp abnormal events happen.
>
> 1. Giving an usecase example:
> =
> When an application
On Mon, Mar 4, 2024 at 10:29 AM Jason Xing wrote:
>
> From: Jason Xing
>
> Use the existing parameter and print the address of skbaddr
> as other trace functions do.
>
> Signed-off-by: Jason Xing
Reviewed-by: Eric Dumazet
nd it will print like below:
>
> ...tcp_retransmit_skb: skbaddr=XXX skaddr=XXX family=AF_INET...
>
> Signed-off-by: Jason Xing
Reviewed-by: Eric Dumazet
On Thu, Feb 29, 2024 at 6:10 PM Jason Xing wrote:
>
> From: Jason Xing
>
> Prio to this patch, the trace function doesn't print addresses
> which might be forgotten. As we can see, it already fetches
> those, use it directly and it will print like below:
>
> ...tcp_retransmit_skb: skbaddr=XXX
On Mon, Mar 4, 2024 at 8:01 AM Jason Xing wrote:
>
> On Fri, Mar 1, 2024 at 1:10 AM Jason Xing wrote:
> >
> > From: Jason Xing
> >
> > When I reviewed other people's patch [1], I noticed that similar thing
> > also happens in tcp_event_skb class and tcp_event_sk_skb class. They
> > don't print
On Mon, Mar 4, 2024 at 4:46 AM fuyuanli wrote:
>
> It is useful to expose skb addr and sock addr to user in tracepoint
> tcp_probe, so that we can get more information while monitoring
> receiving of tcp data, by ebpf or other ways.
>
> For example, we need to identify a packet by seq and end_seq
On Tue, Feb 27, 2024 at 3:50 AM wrote:
>
> From: xu xin
>
> Introduce a tracepoint for icmp_send, which can help users to get more
> detail information conveniently when icmp abnormal events happen.
>
> 1. Giving an usecase example:
> =
> When an application
oesn't have to bother with error
> handling (allocation failure checking, making sure free happens in the
> right spot, etc). This is core responsibility now.
>
> Remove the allocation in the vsockmon driver and leverage the network
> core allocation instead.
>
> Signed-off-by: Breno Leitao
Reviewed-by: Eric Dumazet
On Fri, Feb 23, 2024 at 12:58 PM Breno Leitao wrote:
>
> Do not set rtnl_link_stats64 fields to zero, since they are zeroed
> before ops->ndo_get_stats64 is called in core dev_get_stats() function.
>
> Signed-off-by: Breno Leitao
Reviewed-by: Eric Dumazet
false positive reports in
> > W+X checking, and the rcu synchronization is unnecessary which can
> > introduce significant delay.
> >
> > Eric Chanudet reports that the rcu_barrier introduces ~0.1s delay on a
> > PREEMPT_RT kernel.
> > [0.291444] Freeing unused kern
ng 0 # 1
systemd-1 [002] . 0.413351: rcu_barrier: rcu_preempt
Inc2 cpu -1 remaining 0 # 1
With this patch the delay is no longer there:
[0.377662] Freeing unused kernel memory: 14080K
[0.377767] Run /sbin/init as init process
AFAIU, for the race to happen, module_alloc() needs to create a W+X
mapping (neither x86 nor arm64 does) and debug_checkwx() has to happen
before module_enable_nx() in complete_formation(), I didn't get a
reproducer so far.
Best,
--
Eric Chanudet
On Wed, Feb 14, 2024 at 5:49 PM Breno Leitao wrote:
>
> On Wed, Feb 14, 2024 at 04:41:36PM +0100, Eric Dumazet wrote:
> > On Wed, Feb 14, 2024 at 3:45 PM Breno Leitao wrote:
> > >
> > > On Tue, Feb 13, 2024 at 10:04:57AM -0800, Jakub Kicinski wrote:
> > &g
On Wed, Feb 14, 2024 at 3:45 PM Breno Leitao wrote:
>
> On Tue, Feb 13, 2024 at 10:04:57AM -0800, Jakub Kicinski wrote:
> > On Tue, 13 Feb 2024 14:57:49 +0100 Eric Dumazet wrote:
> > > Please note that adding other sysfs entries is expensive for workloads
> > > crea
On Fri, Feb 2, 2024 at 5:55 PM Breno Leitao wrote:
>
> From: Jakub Kicinski
>
> softnet_data->time_squeeze is sometimes used as a proxy for
> host overload or indication of scheduling problems. In practice
> this statistic is very noisy and has hard to grasp units -
> e.g. is 10 squeezes a
On Tue, Dec 5, 2023 at 3:11 AM Xuan Zhuo wrote:
>
> On Mon, 4 Dec 2023 13:28:21 +0100, Eric Dumazet wrote:
> > On Mon, Dec 4, 2023 at 12:43 PM Philo Lu wrote:
> > >
> > > Add 3 tracepoints, namely tcp_data_send/tcp_data_recv/tcp_data_acked,
> > > whi
On Mon, Dec 4, 2023 at 12:43 PM Philo Lu wrote:
>
> Add 3 tracepoints, namely tcp_data_send/tcp_data_recv/tcp_data_acked,
> which will be called every time a tcp data packet is sent, received, and
> acked.
> tcp_data_send: called after a data packet is sent.
> tcp_data_recv: called after a data
On Mon, Oct 9, 2023 at 11:43 AM Yajun Deng wrote:
>
>
> On 2023/10/9 17:30, Eric Dumazet wrote:
> > On Mon, Oct 9, 2023 at 10:36 AM Yajun Deng wrote:
> >>
> >> On 2023/10/9 16:20, Eric Dumazet wrote:
> >>> On Mon, Oct 9, 2023 at 10:14 AM Yajun Deng w
On Mon, Oct 9, 2023 at 10:36 AM Yajun Deng wrote:
>
>
> On 2023/10/9 16:20, Eric Dumazet wrote:
> > On Mon, Oct 9, 2023 at 10:14 AM Yajun Deng wrote:
> >>
> >> On 2023/10/9 15:53, Eric Dumazet wrote:
> >>> On Mon, Oct 9, 2023 at 5:07 AM Y
On Mon, Oct 9, 2023 at 10:14 AM Yajun Deng wrote:
>
>
> On 2023/10/9 15:53, Eric Dumazet wrote:
> > On Mon, Oct 9, 2023 at 5:07 AM Yajun Deng wrote:
> >
> >> 'this_cpu_read + this_cpu_write' and 'pr_info + this_cpu_inc' will make
> >> the trace
On Mon, Oct 9, 2023 at 5:07 AM Yajun Deng wrote:
> 'this_cpu_read + this_cpu_write' and 'pr_info + this_cpu_inc' will make
> the trace work well.
>
> They all have 'pop' instructions in them. This may be the key to making
> the trace work well.
>
> Hi all,
>
> I need your help on percpu and
> On Sep 12, 2023, at 4:47 PM, Mimi Zohar wrote:
>
> On Tue, 2023-09-12 at 17:11 +0000, Eric Snowberg wrote:
>>
>>> On Sep 12, 2023, at 5:54 AM, Mimi Zohar wrote:
>>>
>>> On Tue, 2023-09-12 at 02:00 +, Eric Snowberg wrote:
>>>>
> On Sep 12, 2023, at 5:54 AM, Mimi Zohar wrote:
>
> On Tue, 2023-09-12 at 02:00 +0000, Eric Snowberg wrote:
>>
>>> On Sep 11, 2023, at 5:08 PM, Mimi Zohar wrote:
>>>
>>> On Mon, 2023-09-11 at 22:17 +, Eric Snowberg wrote:
>>>>
>
> On Sep 11, 2023, at 5:08 PM, Mimi Zohar wrote:
>
> On Mon, 2023-09-11 at 22:17 +0000, Eric Snowberg wrote:
>>
>>> On Sep 11, 2023, at 10:51 AM, Mickaël Salaün wrote:
>>>
>>> On Mon, Sep 11, 2023 at 09:29:07AM -0400, Mimi Zohar wrote:
>>&g
> On Sep 11, 2023, at 4:04 PM, Jarkko Sakkinen wrote:
>
> On Mon Sep 11, 2023 at 4:29 PM EEST, Mimi Zohar wrote:
>> Hi Eric,
>>
>> On Fri, 2023-09-08 at 17:34 -0400, Eric Snowberg wrote:
>>> Currently root can dynamically update the blacklist keyring i
> On Sep 11, 2023, at 10:51 AM, Mickaël Salaün wrote:
>
> On Mon, Sep 11, 2023 at 09:29:07AM -0400, Mimi Zohar wrote:
>> Hi Eric,
>>
>> On Fri, 2023-09-08 at 17:34 -0400, Eric Snowberg wrote:
>>> Currently root can dynamically update the blacklist keyring i
hat can sleep in page faults so any
nearly any requirement except a thread local use is invalidated.
As you have described kmap_local above it does not sound like kmap_local
is safe in this context, but that could just be a problem in description
that my poor memory does is not recalling the ne
On 4/20/21 5:41 PM, Kuniyuki Iwashima wrote:
> The SO_REUSEPORT option allows sockets to listen on the same port and to
> accept connections evenly. However, there is a defect in the current
> implementation [1]. When a SYN packet is received, the connection is tied
> to a listening socket.
On Tue, Apr 20, 2021 at 3:45 PM Naresh Kamboju
wrote:
>
> Following kernel BUG reported on qemu-arm64 running linux next 20210420
> the config is enabled with KASAN.
>
> steps to reproduce:
>
> - Build the arm64 kernel with KASAN enabled.
> - boot it with below
On Tue, Apr 20, 2021 at 2:00 PM zhaoya wrote:
>
> When using syncookie, since $MSSID is spliced into cookie and
> the legal index of msstab is 0,1,2,3, this gives client 3 bytes
> of freedom, resulting in at most 3 bytes of silent loss.
>
> C seq=12345-> S
> C
On Tue, Apr 20, 2021 at 9:54 AM AceLan Kao wrote:
>
> From: "Chia-Lin Kao (AceLan)"
>
> The rtnl_lock() has been called in rtnetlink_rcv_msg(), and then in
> __dev_open() it calls pm_runtime_resume() to resume devices, and in
> some devices' resume function(igb_resum,igc_resume) they calls
uot;Fixes" line shouldn't be line-wrapped.
Otherwise this looks fine. The explanation in the commit message still isn't
great, but it's much better than it was before.
You can add:
Reviewed-by: Eric Biggers
- Eric
eth = skb_gro_header_slow(skb, hlen, 0);
> --
> 2.31.1
>
>
Good catch, thanks.
This has the unfortunate effect of increasing code length on x86,
maybe we should have an exception to
normal rules so that skb_gro_reset_offset() is inlined.
Reviewed-by: Eric Dumazet
On Sun, Apr 18, 2021 at 4:31 PM Matt Corallo
wrote:
>
> Should the default, though, be so low? If someone is still using a old modem
> they can crank up the sysctl, it does seem
> like such things are pretty rare these days :). Its rather trivial to,
> without any kind of attack, hit 1Mbps of
se problems as is, I will be
surprised.
Eric
"Serge E. Hallyn" writes:
> A process running as uid 0 but without cap_setfcap currently can simply
> unshare a new user namespace with uid 0 mapped to 0. While this task
> will not have new capabilities against the parent namespac
On Sat, Apr 17, 2021 at 6:03 PM Linus Torvalds
wrote:
>
> On Fri, Apr 16, 2021 at 12:24 PM Eric Dumazet wrote:
> >
> > From: Eric Dumazet
> >
> > We have to loop only to copy u64 values.
> > After this first loop, we copy at most one u32, one u16 and one
On Sat, Apr 17, 2021 at 12:45 AM 赵亚 wrote:
>
> On Fri, Apr 16, 2021 at 7:52 PM Eric Dumazet wrote:
> >
> > On Fri, Apr 16, 2021 at 12:52 PM zhaoya wrote:
> > >
> > > When syncookie is triggered, since $MSSID is spliced into cookie and
> > > the
kb".
> This patch also fixes it.
>
> Fixes: b4b9e3558508 ("netvm: set PF_MEMALLOC as appropriate during SKB
> processing")
> Cc: Mel Gorman
> Cc: David S. Miller
> Cc: Neil Brown
> Cc: Peter Zijlstra
> Cc: Jiri Slaby
> Cc: Mike Christie
>
On Sat, Apr 17, 2021 at 2:31 AM David Ahern wrote:
>
> [ cc author of 648700f76b03b7e8149d13cc2bdb3355035258a9 ]
I think this has been discussed already. There is no strategy that
makes IP reassembly units immune to DDOS attacks.
We added rb-tree and sysctls to let admins choose to use GB of
On Fri, Apr 16, 2021 at 10:11 PM Eric Dumazet wrote:
>
> On Fri, Apr 16, 2021 at 9:44 PM Al Viro wrote:
> >
> > On Fri, Apr 16, 2021 at 12:24:13PM -0700, Eric Dumazet wrote:
> > > From: Eric Dumazet
> > >
> > > We have to loop only to copy u64
On Fri, Apr 16, 2021 at 9:44 PM Al Viro wrote:
>
> On Fri, Apr 16, 2021 at 12:24:13PM -0700, Eric Dumazet wrote:
> > From: Eric Dumazet
> >
> > We have to loop only to copy u64 values.
> > After this first loop, we copy at most one u32, one u16 and one byte.
>
From: Eric Dumazet
We have to loop only to copy u64 values.
After this first loop, we copy at most one u32, one u16 and one byte.
Signed-off-by: Eric Dumazet
---
arch/x86/include/asm/uaccess.h | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include
Hi Jason,
On 4/16/21 4:34 PM, Jason Gunthorpe wrote:
> On Fri, Apr 16, 2021 at 04:26:19PM +0200, Auger Eric wrote:
>
>> This was largely done during several confs including plumber, KVM forum,
>> for several years. Also API docs were shared on the ML. I don't remember
>&
Hi,
On 4/16/21 4:05 PM, Jason Gunthorpe wrote:
> On Fri, Apr 16, 2021 at 03:38:02PM +0200, Auger Eric wrote:
>
>> The redesign requirement came pretty late in the development process.
>> The iommu user API is upstream for a while, the VFIO interfaces have
>> been s
Hi Jason,
On 4/16/21 1:07 AM, Jason Gunthorpe wrote:
> On Thu, Apr 15, 2021 at 03:11:19PM +0200, Auger Eric wrote:
>> Hi Jason,
>>
>> On 4/1/21 6:03 PM, Jason Gunthorpe wrote:
>>> On Thu, Apr 01, 2021 at 02:08:17PM +, Liu, Yi L wrote:
>>>
>>>>
On Fri, Apr 16, 2021 at 12:52 PM zhaoya wrote:
>
> When syncookie is triggered, since $MSSID is spliced into cookie and
> the legal index of msstab is 0,1,2,3, this gives client 3 bytes
> of freedom, resulting in at most 3 bytes of silent loss.
>
> C seq=12345-> S
> C
On Fri, Apr 16, 2021 at 10:49 AM Balazs Nemeth wrote:
>
> On Thu, 2021-04-15 at 16:46 +0200, Greg Kroah-Hartman wrote:
> > From: Eric Dumazet
> >
> > commit 61431a5907fc36d0738e9a547c7e1556349a03e9 upstream.
> >
> > Commit 924a9bc362a
hould be updated, in arch/x86/kernel/e820.c.
- Eric
t;= 0);
> BUG_ON(sectors >= bio_sectors(bio));
> + WARN_ON(!IS_ALIGNED(sectors, bio_required_sector_alignment(bio)));
If this warning triggers, shouldn't the function return NULL to indicate a
failure rather than proceeding on?
- Eric
if (blk_integrity_queue_supports_integrity(q)) {
> pr_warn("Integrity and hardware inline encryption are not
> supported together. Disabling hardware inline encryption.\n");
> return false;
> }
> +
> + blk_ksm_restrict_dus_to_queue_limits(ksm, >limits);
> +
> + if (blk_ksm_is_empty(ksm))
> + return false;
> +
> q->ksm = ksm;
> return true;
> }
Adding a kerneldoc comment to this function would be helpful. Especially to
explain what a return value of false means, exactly.
- Eric
umstances?
- Eric
On Thu, Mar 25, 2021 at 09:26:05PM +, Satya Tangirala wrote:
> This function returns the required alignment for the number of sectors in
> a bio. In particular, the number of sectors passed to bio_split() must be
> aligned to this value.
>
> Signed-off-by: Satya Tangirala
> ---
>
aximum
> required.
I don't see how that would work here, as the required alignment is a per-bio
thing which depends on whether the bio has an encryption context or not, and (if
it does) also the data_unit_size the submitter of the bio selected.
We could just always assume the worst-case scenario, but that seems
unnecessarily pessimistic?
- Eric
ata unit size that was
selected by the submitter of the bio, which is the granularity of
encryption/decryption. Keep in mind that people reading this code won't
necessarily be familiar with inline encryption.
- Eric
earing UFSHCD_CAP_CRYPTO or MMC_CAP2_CRYPTO doesn't really make sense
here because those capabilities apply to the whole UFS or MMC host controller,
not just to the individual request_queue which failed. (A host controller can
control multiple devices, each of which has its own request_queue.) Isn't
blk_ksm_register() failing already enough to ensure that the inline crypto
support isn't used on that particular request_queue? What is the benefit of
clearing UFSHCD_CAP_CRYPTO and MMC_CAP2_CRYPTO too?
- Eric
l blk_ksm_is_empty(struct blk_keyslot_manager *ksm);
> +
It's easier to read if declarations are kept in the same order as the
definitions.
- Eric
On Thu, Apr 15, 2021 at 5:47 PM Gong, Sishuai wrote:
>
> Hi,
>
> We found a data race between tcp_set_default_congestion_control() and
> tcp_set_congestion_control() in linux-5.12-rc3.
> In general, when tcp_set_congestion_control() is reading ca->flags with a
> lock grabbed,
-PCI QEMU device. this latter retrives
the faault from the mmapped circ buffer, it knowns which vIOMMU it is
attached to, and passes the fault to the vIOMMU.
Then the vIOMMU triggers and IRQ in the guest.
We are reusing the existing concepts from VFIO, region, IRQ to do that.
For that use case, would
The following commit has been merged into the sched/core branch of tip:
Commit-ID: 60af388d23889636011488c42763876bcdda3eab
Gitweb:
https://git.kernel.org/tip/60af388d23889636011488c42763876bcdda3eab
Author:Eric Dumazet
AuthorDate:Tue, 13 Apr 2021 13:33:50 -07:00
The following commit has been merged into the sched/core branch of tip:
Commit-ID: 0ed96051531ecc6965f6456d25b19b9b6bdb5c28
Gitweb:
https://git.kernel.org/tip/0ed96051531ecc6965f6456d25b19b9b6bdb5c28
Author:Eric Dumazet
AuthorDate:Tue, 13 Apr 2021 13:33:51 -07:00
The following commit has been merged into the sched/core branch of tip:
Commit-ID: 5e0ccd4a3b01c5a71732a13186ca110a138516ea
Gitweb:
https://git.kernel.org/tip/5e0ccd4a3b01c5a71732a13186ca110a138516ea
Author:Eric Dumazet
AuthorDate:Tue, 13 Apr 2021 13:33:52 -07:00
On Wed, Apr 14, 2021 at 10:09 PM Shakeel Butt wrote:
>
> I will let TCP RX zerocopy experts respond to this but from my high
> level code inspection, I didn't see page->private usage.
Indeed, we do not use page->private, since we do not own the page(s).
On Wed, Apr 14, 2021 at 10:15 PM Arjun Roy wrote:
>
> On Wed, Apr 14, 2021 at 10:35 AM Eric Dumazet wrote:
> >
> > On Wed, Apr 14, 2021 at 7:15 PM Arjun Roy wrote:
> > >
> > > On Wed, Apr 14, 2021 at 9:10 AM Eric Dumazet wrote:
> > > >
>
On Wed, Apr 14, 2021 at 11:53:51AM -0700, Nick Terrell wrote:
> On Wed, Apr 14, 2021 at 11:35 AM Eric Biggers wrote:
> >
> > On Wed, Apr 14, 2021 at 11:01:29AM -0700, Nick Terrell wrote:
> > > Hi all,
> > >
> > > I would really like to ma
import zstd directly from upstream so we don't fall 3
> years out of date again
>
> Thanks,
> Nick
>
I think it would help get it merged if someone actually volunteered to maintain
it. As-is there is no entry in MAINTAINERS for this code.
- Eric
On Wed, Apr 14, 2021 at 7:15 PM Arjun Roy wrote:
>
> On Wed, Apr 14, 2021 at 9:10 AM Eric Dumazet wrote:
> >
> > On Wed, Apr 14, 2021 at 6:08 PM David Laight
> > wrote:
> > >
> > > From: Eric Dumazet
> > > > Sent: 14 April 2021 17:0
From: Eric Dumazet
Removes this annoying warning:
arch/sh/kernel/traps.c: In function ‘nmi_trap_handler’:
arch/sh/kernel/traps.c:183:15: warning: unused variable ‘cpu’
[-Wunused-variable]
183 | unsigned int cpu = smp_processor_id();
Fixes: fe3f1d5d7cd3 ("sh: Get rid of nmi_count()&quo
On Wed, Apr 14, 2021 at 6:08 PM David Laight wrote:
>
> From: Eric Dumazet
> > Sent: 14 April 2021 17:00
> ...
> > > Repeated unsafe_get_user() calls are crying out for an optimisation.
> > > You get something like:
> > > failed = 0;
> >
On Wed, Apr 14, 2021 at 9:55 AM David Laight wrote:
>
> From: Arjun Roy
> > Sent: 13 April 2021 23:04
> >
> > On Tue, Apr 13, 2021 at 2:19 PM David Laight
> > wrote:
> > >
> > > > If we're special-casing 64-bit architectures anyways - unrolling the
> > > > 32B copy_from_user() for struct
Hallo,
Ich biete Kredite an Personen an, die Geld für ihre benötigen
kleine Finanzierungsprobleme, um endlich den Stillstand zu überwinden
provozieren Sie die Banken, indem Sie Ihre Bewerbungsunterlagen für ablehnen
Anerkennung. Ich bin ein französischer Staatsbürger, der Ihnen einen Kredit
From: Eric Dumazet
After commit 8f2817701492 ("rseq: Use get_user/put_user rather
than __get_user/__put_user") we no longer need
an access_ok() call from __rseq_handle_notify_resume()
Mathieu pointed out the same cleanup can be done
in rseq_syscall().
Signed-off-by: Eric Dumazet
C
From: Eric Dumazet
Commit ec9c82e03a74 ("rseq: uapi: Declare rseq_cs field as union,
update includes") added regressions for our servers.
Using copy_from_user() and clear_user() for 64bit values
is suboptimal.
We can use faster put_user() and get_user() on 64bit arches.
Signed-of
From: Eric Dumazet
rseq is a heavy user of copy to/from user data in fast paths.
This series tries to reduce the cost.
v3: Third patch going back to v1 (only deal with 64bit arches)
v2: Addressed Peter and Mathieu feedbacks, thanks !
Eric Dumazet (3):
rseq: optimize rseq_update_cpu_id
From: Eric Dumazet
Two put_user() in rseq_update_cpu_id() are replaced
by a pair of unsafe_put_user() with appropriate surroundings.
This removes one stac/clac pair on x86 in fast path.
Signed-off-by: Eric Dumazet
Cc: Mathieu Desnoyers
Cc: Peter Zijlstra
Cc: "Paul E. McKenney"
nsigned long jump_address_phys;
> unsigned long cr3;
> unsigned long magic;
> - u8 e820_digest[MD5_DIGEST_SIZE];
> + unsigned long e820_digest;
> };
This field should probably be renamed to 'e820_crc' or 'e820_checksum', since
"digest" normally means a cryptographic digest.
- Eric
header_restore(void *addr)
> jump_address_phys = rdr->jump_address_phys;
> restore_cr3 = rdr->cr3;
>
> - if (hibernation_e820_mismatch(rdr->e820_digest)) {
> + if (hibernation_e820_mismatch(>e820_digest)) {
Likewise, this should be just
if (rdr->e820_digest != compute_e820_crc32(e820_table_firmware)) {
- Eric
On Tue, Apr 13, 2021 at 8:00 PM Mathieu Desnoyers
wrote:
>
> As long as the ifdefs are localized within clearly identified wrappers in the
> rseq code I don't mind doing the special-casing there.
>
> The point which remains is that I don't think we want to optimize for speed
> on 32-bit
On Tue, Apr 13, 2021 at 7:20 PM Mathieu Desnoyers
wrote:
>
> - On Apr 13, 2021, at 1:07 PM, Eric Dumazet eduma...@google.com wrote:
>
> > On Tue, Apr 13, 2021 at 7:01 PM Eric Dumazet wrote:
> >>
> >> On Tue, Apr 13, 2021 at 6:57 PM Eric Dumazet wrote:
> &
On Tue, Apr 13, 2021 at 7:01 PM Eric Dumazet wrote:
>
> On Tue, Apr 13, 2021 at 6:57 PM Eric Dumazet wrote:
> >
> > On Tue, Apr 13, 2021 at 6:54 PM Mathieu Desnoyers
> > wrote:
> > >
> > > - On Apr 13, 2021, at 12:22 PM, Eric Dumazet eric.duma...@
On Tue, Apr 13, 2021 at 6:57 PM Eric Dumazet wrote:
>
> On Tue, Apr 13, 2021 at 6:54 PM Mathieu Desnoyers
> wrote:
> >
> > - On Apr 13, 2021, at 12:22 PM, Eric Dumazet eric.duma...@gmail.com
> > wrote:
> >
> > > From: Eric Dumazet
> > &
On Tue, Apr 13, 2021 at 6:54 PM Mathieu Desnoyers
wrote:
>
> - On Apr 13, 2021, at 12:22 PM, Eric Dumazet eric.duma...@gmail.com wrote:
>
> > From: Eric Dumazet
> >
> > Commit ec9c82e03a74 ("rseq: uapi: Declare rseq_cs field as union,
> > update includ
From: Eric Dumazet
Commit ec9c82e03a74 ("rseq: uapi: Declare rseq_cs field as union,
update includes") added regressions for our servers.
Using copy_from_user() and clear_user() for 64bit values
is suboptimal.
We can use faster put_user() and get_user().
32bit arches can be chan
From: Eric Dumazet
After commit 8f2817701492 ("rseq: Use get_user/put_user rather
than __get_user/__put_user") we no longer need
an access_ok() call from __rseq_handle_notify_resume()
Mathieu pointed out the same cleanup can be done
in rseq_syscall().
Signed-off-by: Eric Dumazet
C
From: Eric Dumazet
Two put_user() in rseq_update_cpu_id() are replaced
by a pair of unsafe_put_user() with appropriate surroundings.
This removes one stac/clac pair on x86 in fast path.
Signed-off-by: Eric Dumazet
Cc: Mathieu Desnoyers
Cc: Peter Zijlstra
Cc: "Paul E. McKenney"
1 - 100 of 29760 matches
Mail list logo
