gt;>
>> Signed-off-by: Ganapatrao Kulkarni
>
> I'm interested in testing this, but is this series against kvmarm? which
> branch I can cleanly do git am?
I gave it a try on kvm-next. There is a minor conflict to resolve when
applying.
Thanks
Eric
>
> Thanks,
> Itaru.
&
arrival error margin (in us) of the guest
> timer (default: %u)\n",
> TIMER_TEST_ERR_MARGIN_US);
> + pr_info("\t-g: Enable Nested Virtualization, run guest code as guest
> hypervisor (default: Disabled)\n");
I would recommend "default: 0&quo
64_CORE_REG(sp_el1), stack_vaddr +
> stack_size);
> +
> return vcpu;
> }
>
> @@ -457,7 +487,10 @@ void vcpu_init_descriptor_tables(struct kvm_vcpu *vcpu)
> {
> extern char vectors;
>
> - vcpu_set_reg(vcpu, KVM_ARM64_SYS_REG(SYS_VBAR_EL1), (uint64_t)&vectors);
> + if (is_vcpu_nested(vcpu))
> + vcpu_set_reg(vcpu, KVM_ARM64_SYS_REG(SYS_VBAR_EL2),
> (uint64_t)&vectors);
> + else
> + vcpu_set_reg(vcpu, KVM_ARM64_SYS_REG(SYS_VBAR_EL1),
> (uint64_t)&vectors);
> }
>
> void route_exception(struct ex_regs *regs, int vector)
> diff --git a/tools/testing/selftests/kvm/lib/arm64/vgic.c
> b/tools/testing/selftests/kvm/lib/arm64/vgic.c
> index 4427f43f73ea..67822b803d0f 100644
> --- a/tools/testing/selftests/kvm/lib/arm64/vgic.c
> +++ b/tools/testing/selftests/kvm/lib/arm64/vgic.c
> @@ -79,6 +79,14 @@ int vgic_v3_setup(struct kvm_vm *vm, unsigned int
> nr_vcpus, uint32_t nr_irqs)
> return gic_fd;
> }
>
> +void vgic_v3_close(int gic_fd)
> +{
> + if (gic_fd < 0)
> + return;
> +
> + close(gic_fd);
> +}
> +
> /* should only work for level sensitive interrupts */
> int _kvm_irq_set_level_info(int gic_fd, uint32_t intid, int level)
> {
Thanks
Eric
ld add in the coverletter that for all tests
enhanced with vEL2 testing "-g 1" option shall be added to force that mode.
I don't really get how you chose tests capable to run at vEL2 and
excluded others? Wouldn't it make sense to have a way to run all tests
in either mode?
Thank
On Wed, May 14, 2025 at 08:11:40AM +0200, Thomas Gleixner wrote:
> On Tue, May 13 2025 at 22:24, Eric Biggers wrote:
>
> > From: Eric Biggers
> >
> > lib/crc32.c and include/linux/crc32.h got missed by the bulk SPDX
> > conversion because of the nonstand
From: Eric Biggers
lib/crc32.c and include/linux/crc32.h got missed by the bulk SPDX
conversion because of the nonstandard explanation of the license.
However, crc32.c clearly states that it's licensed under the GNU General
Public License, Version 2. And the comment in crc32.h clearly indi
Hi Michael,
On 2/24/25 8:31 PM, Michael S. Tsirkin wrote:
> On Mon, Feb 24, 2025 at 08:49:09AM +0100, Eric Auger wrote:
>> Hi Michael,
>>
>> On 2/21/25 12:42 AM, Michael S. Tsirkin wrote:
>>> Hongyu reported a hang on kexec in a VM. QEMU reported invalid memor
te at addr 0x102877A44, size 2, region '(null)', reason:
> rejected
> ...
>
> It was traced down to virtio-console. Kexec works fine if virtio-console
> is not in use.
>
> The issue is that virtio-console continues to write to the MMIO even after
> underlyi
Hi Michael,
On 2/17/25 10:25 AM, Eric Auger wrote:
> Hi Michael, Hongyu,
>
> On 2/14/25 1:16 PM, Michael S. Tsirkin wrote:
>> On Fri, Feb 14, 2025 at 08:56:56AM +0100, Eric Auger wrote:
>>> Hi,
>>>
>>> On 2/14/25 8:21 AM, Ning, Hongyu wrote:
>>
Hi Michael, Hongyu,
On 2/14/25 1:16 PM, Michael S. Tsirkin wrote:
> On Fri, Feb 14, 2025 at 08:56:56AM +0100, Eric Auger wrote:
>> Hi,
>>
>> On 2/14/25 8:21 AM, Ning, Hongyu wrote:
>>>
>>>
>>> On 2025/2/6 16:59, Eric Auger wrote:
>>>>
Hi,
On 2/14/25 8:21 AM, Ning, Hongyu wrote:
>
>
> On 2025/2/6 16:59, Eric Auger wrote:
>> Hi,
>>
>> On 2/4/25 12:46 PM, Eric Auger wrote:
>>> Hi,
>>>
>>> On 2/3/25 3:48 PM, Michael S. Tsirkin wrote:
>>>> On Fri, Jan 31, 20
Fixed misspelling.
Signed-off-by: Eric Salem
---
tools/testing/selftests/mm/uffd-common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/mm/uffd-common.c
b/tools/testing/selftests/mm/uffd-common.c
index 717539eddf98..f23c57d9d1bd 100644
--- a/tools
On 2/6/25 11:04 AM, Kirill A. Shutemov wrote:
> On Thu, Feb 06, 2025 at 09:59:58AM +0100, Eric Auger wrote:
>> Hi,
>>
>> On 2/4/25 12:46 PM, Eric Auger wrote:
>>> Hi,
>>>
>>> On 2/3/25 3:48 PM, Michael S. Tsirkin wrote:
>>>> On Fri,
Hi,
On 2/4/25 12:46 PM, Eric Auger wrote:
> Hi,
>
> On 2/3/25 3:48 PM, Michael S. Tsirkin wrote:
>> On Fri, Jan 31, 2025 at 10:53:15AM +0100, Eric Auger wrote:
>>> Hi Kirill, Michael
>>>
>>> On 8/8/24 9:51 AM, Kirill A. Shutemov wrote:
>>>>
Hi Jason,
On 1/29/25 9:13 PM, Jason Gunthorpe wrote:
> On Wed, Jan 29, 2025 at 06:46:20PM +0100, Eric Auger wrote:
>>>>> This missing peice is cleaning up the ITS mapping to allow for
>>>>> multiple ITS pages. I've imagined that kvm would someone give iomm
Hi,
On 2/3/25 3:48 PM, Michael S. Tsirkin wrote:
> On Fri, Jan 31, 2025 at 10:53:15AM +0100, Eric Auger wrote:
>> Hi Kirill, Michael
>>
>> On 8/8/24 9:51 AM, Kirill A. Shutemov wrote:
>>> Hongyu reported a hang on kexec in a VM. QEMU reported invalid memor
ls, see qemu thread ([PATCH] hw/virtio/vhost: Disable
IOTLB callbacks when IOMMU gets disabled,
https://lore.kernel.org/all/20250120173339.865681-1-eric.au...@redhat.com/)
Reviewed-by: Eric Auger
Tested-by: Eric Auger
Thanks
Eric
> ---
> drivers/virtio/virtio.c | 10 ++
>
On 1/29/25 6:39 PM, Jason Gunthorpe wrote:
> On Wed, Jan 29, 2025 at 06:23:33PM +0100, Eric Auger wrote:
>>>> IIUC the MSI window will then be different when using legacy VFIO
>>>> assignment and iommufd backend.
>>> ? They use the same, iommufd can have use
On 1/29/25 4:04 PM, Jason Gunthorpe wrote:
> On Wed, Jan 29, 2025 at 03:54:48PM +0100, Eric Auger wrote:
>>>> or you are just mentioning it here because
>>>> it is still possible to make use of that. I think from previous
>>>> discussions the
>>
On 1/29/25 3:58 PM, Jason Gunthorpe wrote:
> On Wed, Jan 29, 2025 at 02:44:12PM +0100, Eric Auger wrote:
>> Hi,
>>
>>
>> On 1/11/25 4:32 AM, Nicolin Chen wrote:
>>> For systems that require MSI pages to be mapped into the IOMMU translation
>>> t
someone give iommufd
> a FD that holds the specific ITS pages instead of the
> IOMMU_OPTION_SW_MSI_START/SIZE flow.
That's what I don't get: at the moment you only pass the gIOVA. With
technique 2, how can you build the nested mapping, ie.
S1 S2
gIOVA->gDB->hDB
without passing the full gIOVA/gDB S1 mapping to the host?
Eric
>
> Jason
>
en(struct inode *inode, struct
> file *filp)
> init_waitqueue_head(&ictx->destroy_wait);
> mutex_init(&ictx->sw_msi_lock);
> INIT_LIST_HEAD(&ictx->sw_msi_list);
> + ictx->sw_msi_start = PHYS_ADDR_MAX;
> + ictx->sw_msi_size = 0;
> filp->private_data = ictx;
> return 0;
> }
> @@ -287,6 +289,10 @@ static int iommufd_option(struct iommufd_ucmd *ucmd)
> case IOMMU_OPTION_RLIMIT_MODE:
> rc = iommufd_option_rlimit_mode(cmd, ucmd->ictx);
> break;
> + case IOMMU_OPTION_SW_MSI_START:
> + case IOMMU_OPTION_SW_MSI_SIZE:
> + rc = iommufd_option_sw_msi(cmd, ucmd->ictx);
> + break;
> case IOMMU_OPTION_HUGE_PAGES:
> rc = iommufd_ioas_option(ucmd);
> break;
Eric
gt;domain, idev->igroup->group);
> + if (hwpt->fault)
> + iommufd_fault_domain_detach_dev(hwpt, idev, handle, true);
same here, pretty difficult to understand what this
iommufd_fault_domain_detach_dev does
To me calling iommufd_auto_response_faults and iommufd_fault_iopf
mmufd_fault_iopf_handler;
> - hwpt->domain->fault_data = hwpt;
> refcount_inc(&fault->obj.users);
> iommufd_put_object(ucmd->ictx, &fault->obj);
> }
> + hwpt->domain->iommufd_hwpt = hwpt;
don't we want to reset this somewhere on release path?
Eric
>
> cmd->out_hwpt_id = hwpt->obj.id;
> rc = iommufd_ucmd_respond(ucmd, sizeof(*cmd));
Hi Jason,
On 1/23/25 7:16 PM, Jason Gunthorpe wrote:
> On Thu, Jan 23, 2025 at 06:10:47PM +0100, Eric Auger wrote:
>> Hi,
>>
>>
>> On 1/11/25 4:32 AM, Nicolin Chen wrote:
>>> From: Jason Gunthorpe
>>>
>>> SW_MSI supports IOMMU to translate
Hi,
On 1/23/25 7:48 PM, Jason Gunthorpe wrote:
> On Thu, Jan 23, 2025 at 06:10:48PM +0100, Eric Auger wrote:
>
>>> However iommufd now permits the domain to change while the driver is
>>> probed and VFIO userspace can create races with IRQ changes calling
>>>
Hi Jason,
On 1/23/25 7:50 PM, Jason Gunthorpe wrote:
> On Thu, Jan 23, 2025 at 06:10:54PM +0100, Eric Auger wrote:
>
>>> -/**
>>> - * iommu_dma_compose_msi_msg() - Apply translation to an MSI message
>>> - * @desc: MSI descriptor prepared by iommu_dma_prepar
Hi Nicolin,
On 1/11/25 4:32 AM, Nicolin Chen wrote:
> From: Jason Gunthorpe
>
> All the iommu cases simply want to override the MSI page's address with
those which translate MSIs
> the IOVA that was mapped through the iommu. This doesn't need a cookie
> pointer, we just need to store the IOVA a
On 1/11/25 4:32 AM, Nicolin Chen wrote:
> From: Jason Gunthorpe
>
> The new function is used to take in a u64 MSI address and store it in the
> msi_msg. If the iommu has provided an alternative address then that is
> replaced instead.
>
> All callers have a tidy u64 already so this also consol
> + * @msi_addr: MSI target address to be mapped
> + *
> + * The implementation of sw_msi() should take msi_addr and map it to
> + * an IOVA in the domain and call msi_desc_set_iommu_msi_iova() with the
> + * mapping information.
> + *
> + * Return: 0 on success or negative error code if the mapping failed.
> + */
> +int iommu_dma_prepare_msi(struct msi_desc *desc, phys_addr_t msi_addr)
> +{
> + struct device *dev = msi_desc_to_dev(desc);
> + struct iommu_group *group = dev->iommu_group;
> + int ret = 0;
> +
> + if (!group)
> + return 0;
> +
> + mutex_lock(&group->mutex);
> + if (group->domain && group->domain->sw_msi)
> + ret = group->domain->sw_msi(group->domain, desc, msi_addr);
> + mutex_unlock(&group->mutex);
> + return ret;
> +}
> +#endif /* CONFIG_IRQ_MSI_IOMMU */
Thanks
Eric
t the
> > sock object retains the dangling sk pointer, which may cause use-after-free
> > later.
> >
> > Clear the sock sk pointer on error.
> >
> > Signed-off-by: Ignat Korchagin
>
> Reviewed-by: Kuniyuki Iwashima
Reviewed-by: Eric Dumazet
Iwashima
> > Signed-off-by: Ignat Korchagin
>
> Reviewed-by: Kuniyuki Iwashima
Reviewed-by: Eric Dumazet
gt; > Put a warning in place to make sure we don't break this promise in the
> > future.
> >
> > Suggested-by: Kuniyuki Iwashima
> > Signed-off-by: Ignat Korchagin
>
> Reviewed-by: Kuniyuki Iwashima
Reviewed-by: Eric Dumazet
t; > sock object retains the dangling pointer, which may create use-after-free
> > later.
> >
> > Clear the sk pointer in the sock object on error.
> >
> > Signed-off-by: Ignat Korchagin
>
> Reviewed-by: Kuniyuki Iwashima
Reviewed-by: Eric Dumazet
is
> > freed, but the dangling pointer remains in the provided sock object, which
> > may allow use-after-free.
> >
> > Clear the sk pointer in the sock object on error.
> >
> > Signed-off-by: Ignat Korchagin
> > Reviewed-by: Miquel Raynal
>
> Reviewed-by: Kuniyuki Iwashima
Reviewed-by: Eric Dumazet
> > dangling pointer in the sock object, which may cause use-after-free.
> >
> > Fix this by swapping calls to bt_sock_alloc() and rfcomm_dlc_alloc().
> >
> > Signed-off-by: Ignat Korchagin
>
> Reviewed-by: Kuniyuki Iwashima
Reviewed-by: Eric Dumazet
> > dangling pointer is still attached to the sock object, which may create
> > use-after-free in other code.
> >
> > Signed-off-by: Ignat Korchagin
>
> Reviewed-by: Kuniyuki Iwashima
>
> Checked all bt_sock_alloc() paths and confirmed only rfcomm and l2cap
> need changes.
Reviewed-by: Eric Dumazet
gt; to use this pointer and cause use-after-free.
>
> Suggested-by: Eric Dumazet
> Signed-off-by: Ignat Korchagin
> ---
Reviewed-by: Eric Dumazet
Thanks.
"Eric W. Biederman" writes:
> Kees Cook writes:
>> I'm not super comfortable doing this regardless of bprm->fdpath; that
>> seems like too many cases getting changed. Can we just leave it as
>> depending on bprm->fdpath?
I was recommending that b
Aleksa Sarai
> Link: https://github.com/uapi-group/kernel-features#set-comm-field-before-exec
> ---
> v2: * drop the flag, everyone :)
> * change the rendered value to f_path.dentry->d_name.name instead of
> argv[0], Eric
> ---
> fs/exec.c | 13 -
is ipv6_mapped and
> use ip_queue_xmit, inet_sk(sk)->tos.
>
> Bpf_get/setsockopt use sk_is_inet() helper to fix this case.
>
> Signed-off-by: Feng Zhou
Reviewed-by: Eric Dumazet
On Fri, Sep 13, 2024 at 11:39 AM Tiago Lam wrote:
>
> This follows the same rationale provided for the ipv4 counterpart, where
> it now runs a reverse socket lookup when source addresses and/or ports
> are changed, on sendmsg, to check whether egress traffic should be
> allowed to go through or no
On Mon, Sep 9, 2024 at 5:02 PM Sean Anderson wrote:
>
> On 9/6/24 22:05, Willem de Bruijn wrote:
> > Sean Anderson wrote:
> >> Padding is not included in UDP and TCP checksums. Therefore, reduce the
> >> length of the checksummed data to include only the data in the IP
> >> payload. This fixes spu
firmed via email that these were
> intended to be run.
>
> Enable these two tests.
>
> Fixes: 13715acf8ab5 ("selftest: Add test for bind() conflicts.")
> Fixes: 2c042e8e54ef ("tcp: Add selftest for bind() and TIME_WAIT.")
> Signed-off-by: Jamie Bainbridge
Reviewed-by: Eric Dumazet
ins about a missing 'Closes' tag.
> Unfortunately I don't have an appropriate URL at hand. @Sebastian,
> @Boqiao: do you have any suggetions?
> ---
> drivers/s390/virtio/virtio_ccw.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Reviewed-by: Eric Farman
On Thu, Jun 6, 2024 at 4:14 PM Denis Arefev wrote:
>
> Two missing check in virtio_net_hdr_to_skb() allowed syzbot
> to crash kernels again
>
> 1. After the skb_segment function the buffer may become non-linear
> (nr_frags != 0), but since the SKBTX_SHARED_FRAG flag is not set anywhere
> the __skb
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 experi
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 experie
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 experience
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
nter 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
u_preempt
LastCB cpu -1 remaining 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 second
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
>
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 ftrac
> 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 if th
> 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 neces
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. Acco
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 command
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 <--seq=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 rtnl_l
he "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 lo
t cause 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 paren
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 by
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
ive_skb".
> 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 R
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 va
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 submi
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 924a9bc362a5 (
erence to MD5 that should be updated, in arch/x86/kernel/e820.c.
- Eric
BUG_ON(sectors <= 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
queue
> *q)
> {
> 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, &q->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
> ---
> block/blk.h
the maximum
> 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
explain why the WARN_ON
should never trigger.
Also, clearing 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
k_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, tcp_set_default_con
y the VFIO-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 c
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
1 - 100 of 9345 matches
Mail list logo
