"Serge E. Hallyn" writes:
> On Tue, Jan 19, 2021 at 07:34:49PM -0600, Eric W. Biederman wrote:
>> Miklos Szeredi writes:
>>
>> > If a capability is stored on disk in v2 format cap_inode_getsecurity() will
>> > currently return in v2 format uncon
info_iov, ARRAY_SIZE(info_iov),
> + okm, okmlen);
> }
>
Shoudn't this just be folded into the previous patch, which converted
fscrypt_hkdf_expand() to use crypto_hkdf_expand() in the first place?
- Eric
t; goto err_free_tfm;
>
> @@ -93,7 +74,6 @@ int fscrypt_init_hkdf(struct fscrypt_hkdf *hkdf, const u8
> *master_key,
> err_free_tfm:
> crypto_free_shash(hmac_tfm);
> out:
> - memzero_explicit(prk, sizeof(prk));
> return err;
> }
The 'out' label isn't needed anymore. 'goto out' should be replaced with
'return 0'.
- Eric
*
I don't think this comment should be joined with the one above it. The earlier
comment describes the general approach taken with fscrypt and HKDF (including
all steps), while the one beginning with "Compute HKDF-Extract" describes
fscrypt_init_hkdf() specifically.
- Eric
ey was set with crypto_hkdf_extract
> + * @info optional context and application specific information - this may be
> + *NULL
> + * @info_vec number of optional context/application specific information
> entries
> + * @dst destination buffer that the caller already allocated
> + * @dlen length of the destination buffer - the KDF derives that amount of
> + *bytes.
> + *
> + * @return 0 on success, < 0 on error
> + */
> +int crypto_hkdf_expand(struct crypto_shash *kmd,
> +const struct kvec *info, unsigned int info_nvec,
> +u8 *dst, unsigned int dlen);
> +
> +/**
> + * RFC 5869 HKDF extract operation
> + *
> + * @kmd Keyed message digest allocated by the caller. The key should not have
> + * been set.
> + * @salt The salt used for the KDF. It is permissible to provide NULL as salt
> + *which implies that the default salt is used.
> + * @saltlen Length of the salt buffer.
> + * @ikm The input key material (IKM). It is permissible to provide NULL as
> IKM.
> + * @ikmlen Length of the IKM buffer
> + * @seed_nvec number of seed entries (must be at least 1)
seed_nvec no longer exists.
- Eric
e working.
Is kmsg_dump expected to work after all of the device drivers
are shut down? Otherwise this placement of kmsg_dump is too late.
Eric
> root@dplat-cp22:~# cat /sys/fs/pstore/dmesg-ramoops-0 | tail
> ...
> <6>[ 70.914592] psci: CPU3 killed (polled 0 ms)
> <5>
On 1/28/21 8:23 AM, Dmitry Vyukov wrote:
> On Thu, Jan 28, 2021 at 3:43 AM Hillf Danton wrote:
>>
>> Init the u64 stats in order to avoid the lockdep prints on the 32bit
>> hardware like
>
> FTR this is not just to avoid lockdep prints, but also to prevent very
> real stalls in production.
> On Jan 28, 2021, at 8:16 AM, David Howells wrote:
>
> Which tree do you envision this going through? EFI or keyrings - or are you
> going to ask Linus to pull it directly? I can pull it if it should go through
> the keyrings tree.
I was thinking it would go thru your tree, since a
> On Jan 27, 2021, at 8:54 PM, Nayna wrote:
>
>
> On 1/22/21 1:10 PM, Eric Snowberg wrote:
>> This fixes CVE-2020-26541.
>>
>> The Secure Boot Forbidden Signature Database, dbx, contains a list of now
>> revoked signatures and keys previously approved to b
Now that the bug is fixed in the minimal way for stable, go make the
code table-driven.
Signed-off-by: Eric Anholt
---
Previous version hadn't been rebased off of a bit of debug code I had,
so it wouldn't cleanly apply.
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 124
that we start many tests in parallel, and waiting for NFS
to page in code probably means that lots of tests hit the same point
of screen init at the same time).
Signed-off-by: Eric Anholt
Cc: sta...@vger.kernel.org # v5.9
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 4
1 file changed, 4 insertions
Now that the bug is fixed in the minimal way for stable, go make the
code table-driven.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 124 +-
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 55
2 files changed, 77 insertions(+), 102
We were using the same force-poweron bit in the two codepaths, so they
could race to have one of them lose GPU power early.
Signed-off-by: Eric Anholt
Cc: sta...@vger.kernel.org # v5.9
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 25 ++---
drivers/gpu/drm/msm/adreno
On Wed, Jan 27, 2021 at 6:56 PM Kuniyuki Iwashima wrote:
>
> From: Eric Dumazet
> Date: Wed, 27 Jan 2021 18:34:35 +0100
> > On Wed, Jan 27, 2021 at 6:32 PM Kuniyuki Iwashima
> > wrote:
> > >
> > > From: Eric Dumazet
> > > Date: Wed, 2
On Wed, Jan 27, 2021 at 6:32 PM Kuniyuki Iwashima wrote:
>
> From: Eric Dumazet
> Date: Wed, 27 Jan 2021 18:05:24 +0100
> > On Wed, Jan 27, 2021 at 5:52 PM Kuniyuki Iwashima
> > wrote:
> > >
> > > From: Eric Dumazet
> > > Date: Wed, 2
On Wed, Jan 27, 2021 at 5:52 PM Kuniyuki Iwashima wrote:
>
> From: Eric Dumazet
> Date: Wed, 27 Jan 2021 15:54:32 +0100
> > On Wed, Jan 27, 2021 at 1:50 PM Kuniyuki Iwashima
> > wrote:
> > >
> > > The commit 41b14fb8724d ("net: Do not cl
> On Jan 27, 2021, at 7:03 AM, Mimi Zohar wrote:
>
> [Cc'ing linux-integrity]
>
> On Wed, 2021-01-27 at 11:46 +, David Howells wrote:
>> Jarkko Sakkinen wrote:
>>
I suppose a user space tool could be created. But wouldn’t what is
currently done in the kernel in this area need
On Wed, Jan 27, 2021 at 1:50 PM Kuniyuki Iwashima wrote:
>
> The commit 41b14fb8724d ("net: Do not clear the sock TX queue in
> sk_set_socket()") removes sk_tx_queue_clear() from sk_set_socket() and adds
> it instead in sk_alloc() and sk_clone_lock() to fix an issue introduced in
> the commit
Hi Vivek,
On 1/21/21 6:34 PM, Vivek Kumar Gautam wrote:
> Hi Eric,
>
>
> On 1/19/21 2:33 PM, Auger Eric wrote:
>> Hi Vivek,
>>
>> On 1/15/21 1:13 PM, Vivek Gautam wrote:
>>> This patch-series aims at enabling Nested stage translation in guests
>>>
ducer: https://syzkaller.appspot.com/x/repro.c?x=13856bc750
> >
> > The issue was bisected to:
> >
> > commit 3226b158e67cfaa677fd180152bfb28989cb2fac
> > Author: Eric Dumazet
> > Date: Wed Jan 13 16:18:19 2021 +
> >
> > net: avoid 32 x trues
rto_to_user_timeout()
> helper to improve accuracy").
>
> Signed-off-by: Enke Chen
> Reviewed-by: Neal Cardwell
> ---
SGTM, thanks !
Signed-off-by: Eric Dumazet
mokx into the blacklist keyring during boot.
Signed-off-by: Eric Snowberg
Suggested-by: James Bottomley
---
security/integrity/platform_certs/load_uefi.c | 20 +--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/security/integrity/platform_certs/load_uefi.c
b
in the .blacklist keyring
are referenced, if a matching key is found, the key will be rejected.
Signed-off-by: Eric Snowberg
Reviewed-by: Jarkko Sakkinen
Signed-off-by: David Howells
---
v5: Function name changes done by David Howells
---
certs/blacklist.c | 32
]
https://patchwork.kernel.org/project/linux-security-module/patch/20200916004927.64276-1-eric.snowb...@oracle.com/
[2] https://lore.kernel.org/patchwork/cover/1315485/
Eric Snowberg (4):
certs: Add EFI_CERT_X509_GUID support for dbx entries
certs: Move load_system_certificate_list to a common
Add a new Kconfig option called SYSTEM_REVOCATION_KEYS. If set,
this option should be the filename of a PEM-formated file containing
X.509 certificates to be included in the default blacklist keyring.
Signed-off-by: Eric Snowberg
Acked-by: Jarkko Sakkinen
---
certs/Kconfig
Move functionality within load_system_certificate_list to a common
function, so it can be reused in the future.
Signed-off-by: Eric Snowberg
Acked-by: Jarkko Sakkinen
---
certs/Makefile | 2 +-
certs/common.c | 56 ++
certs/common.h
Alexey Gladkov writes:
> On Tue, Jan 19, 2021 at 07:57:36PM -0600, Eric W. Biederman wrote:
>> Alexey Gladkov writes:
>>
>> > On Mon, Jan 18, 2021 at 12:34:29PM -0800, Linus Torvalds wrote:
>> >> On Mon, Jan 18, 2021 at 11:46 AM Alexey Gladkov
>> >
by having no_new_privs enforce
progressinvely tighter permissions.
Fixes: 9fcf78cca198 ("apparmor: update domain transitions that are subsets of
confinement at nnp")
Signed-off-by: Eric W. Biederman
---
I came accross this while examining the places cred_guard_mutex is
used and trying to
TL;DR selinux and apparmor ignore no_new_privs
What?
John Johansen writes:
> On 1/20/21 1:26 PM, Eric W. Biederman wrote:
>>
>> The current understanding of apparmor with respect to no_new_privs is at
>> odds with how no_new_privs is implemented and u
> On Jan 20, 2021, at 4:26 AM, Jarkko Sakkinen wrote:
>
> On Fri, Jan 15, 2021 at 09:49:02AM -0700, Eric Snowberg wrote:
>>
>>> On Jan 15, 2021, at 2:15 AM, Jarkko Sakkinen wrote:
>>>
>>> On Wed, Jan 13, 2021 at 05:11:10PM -0700, Eric Snowberg wrot
This should now Cc the correct email address for James Morris.
ebied...@xmission.com (Eric W. Biederman) writes:
> The current understanding of apparmor with respect to no_new_privs is at
> odds with how no_new_privs is implemented and understood by the rest of
> t
On Wed, 20 Jan 2021 at 13:02, Eric Curtin wrote:
>
> The current default value for max_user_watches is the 1/16 (6.25%) of
> the available low memory, divided for the "watch" cost in bytes.
>
> Tools like inotify-tools and visual studio code, seem to hit these
old value for this.
Signed-off-by: Eric Curtin
---
Documentation/admin-guide/sysctl/fs.rst | 4 ++--
fs/eventpoll.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/admin-guide/sysctl/fs.rst
b/Documentation/admin-guide/sysctl/fs
max_user_watches for epoll should say 1/25, rather than 1/32
Signed-off-by: Eric Curtin
---
Documentation/admin-guide/sysctl/fs.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/sysctl/fs.rst
b/Documentation/admin-guide/sysctl/fs.rst
index
his kind of issue does not happen for IPv6. This is
> > because tcp_v6_syn_recv_sock() clones both ipv6_opt and pktopts which
> > correspond to ireq_opt in IPv4.
> >
> > Fixes: 01770a166165 ("tcp: fix race condition when creating child sockets
> > from syncookies")
> > CC: Ricardo Dias
> > Signed-off-by: Kuniyuki Iwashima
> > Reviewed-by: Benjamin Herrenschmidt
>
> Ricardo, Eric, any reason this was written this way?
Well, I guess that was a plain bug.
IPv4 options are not used often I think.
Reviewed-by: Eric Dumazet
Hi Alex,
On 1/19/21 11:45 PM, Alex Williamson wrote:
> On Fri, 15 Jan 2021 10:24:33 +0100
> Auger Eric wrote:
>
>> Hi Vikas,
>> On 1/15/21 7:35 AM, Vikas Gupta wrote:
>>> Hi Eric,
>>>
>>> On Tue, Jan 12, 2021 at 2:52 PM Auger Eric wrote:
&
it was renamed from
CRYPTO_BLKCIPHER in 5.5. If this patch is really important enough to backport,
CRYPTO_SKCIPHER will need to be changed to CRYPTO_BLKCIPHER.
- Eric
ebied...@xmission.com (Eric W. Biederman) writes:
> Alexey Gladkov writes:
>
>> On Mon, Jan 18, 2021 at 12:34:29PM -0800, Linus Torvalds wrote:
>>> On Mon, Jan 18, 2021 at 11:46 AM Alexey Gladkov
>>> wrote:
>>> >
>>> > Sorry about that.
ith stupid/correct code that always
takes the ucounts_lock for every increment of ucounts->count, that is
later replaced with something more optimal.
Not impacting performance in the non-namespace cases and having good
performance in the other cases is a fundamental requirement of merging
code like this.
Eric
well this works with stacking. In particular
ovl_xattr_set appears to call vfs_getxattr without overriding the creds.
What the purpose of that is I haven't quite figured out. It looks like
it is just a probe to see if an xattr is present so maybe it is ok.
Acked-by: "Eric W. Biederman&q
erns
thatn curent_user_ns for the overlay filesystem and that would break
this.
So while I agree with the making a minimal fix for now. We need a good
fix because this code is much too subtle, and it can break very easily
with no one noticing.
Eric
> Thanks,
> Miklos
>
> Mikl
legated_inode and breaking
leases. Code that is enabled with CONFIG_FILE_LOCKING. So unless
I am missing something this introduces a different regression into
ecryptfs.
>
> Reported-by: Eric W. Biederman
> Cc: Tyler Hicks
> Fixes: 7c03e2cda4a5 ("vfs: move cap_convert_nscap() c
Comment did not match function signature.
Signed-off-by: Eric Curtin
---
drivers/scsi/lpfc/lpfc_mbox.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/lpfc/lpfc_mbox.c b/drivers/scsi/lpfc/lpfc_mbox.c
index 3414ffcb26fe..c03a7f12dd65 100644
--- a/drivers/scsi
t virtio backend
> and support in VMM.
>
> For testing we have added necessary support in kvmtool. The changes in
> kvmtool are based on virtio-iommu development branch by Jean-Philippe
> Brucker [3].
>
> The tested kernel branch contains following in the order bottom to top
>
QDQ and not AES-NI. In general, we've tried to
> implement x86 CPU features independently, even if they never show up in
> a real CPU independently.
We only add optimized implementations of crypto algorithms if they are actually
useful, though. If they would never be used in practice, that's not useful.
- Eric
t; case for authentication only.
>
> Although I am not sure if GHASH is specifically used for this or SHA?
>
> Also, I do not know of any cores that implement PCLMULQDQ and not AES-NI.
>
dm-verity only uses unkeyed hash algorithms. So no, it doesn't use GHASH.
- Eric
> On Jan 15, 2021, at 10:21 AM, James Bottomley
> wrote:
>
> On Tue, 2020-09-15 at 20:49 -0400, Eric Snowberg wrote:
>> The Secure Boot Forbidden Signature Database, dbx, contains a list of
>> now revoked signatures and keys previously approved to boot with UEF
> On Jan 15, 2021, at 2:15 AM, Jarkko Sakkinen wrote:
>
> On Wed, Jan 13, 2021 at 05:11:10PM -0700, Eric Snowberg wrote:
>>
>>> On Jan 13, 2021, at 1:41 PM, Jarkko Sakkinen
>>> wrote:
>>>
>>> On Tue, Jan 12, 2021 at 02:57:39PM +0
On Fri, Jan 15, 2021 at 12:55 AM Alexander Lobakin wrote:
>
> Commit 3226b158e67c ("net: avoid 32 x truesize under-estimation for
> tiny skbs") ensured that skbs with data size lower than 1025 bytes
> will be kmalloc'ed to avoid excessive page cache fragmentation and
> memory consumption.
>
is too late to filter.
>
> Eric, thoughts?
Exactly, this is what happens.
I do not know how tcpdump and other programs deal with this.
Maybe by setting a small buffer size, or draining the queue.
>
> On Wed, Jan 6, 2021 at 6:55 AM Tom Cook wrote:
> >
> > Another fa
Hi Vikas,
On 1/15/21 7:26 AM, Vikas Gupta wrote:
> Hi Eric,
>
> On Tue, Jan 12, 2021 at 2:30 PM Auger Eric wrote:
>>
>> Hi Vikas,
>>
>> On 1/5/21 6:53 AM, Vikas Gupta wrote:
>>> On Tue, Dec 22, 2020 at 10:57 PM Auger Eric wrote:
>>>>
>
Hi Vikas,
On 1/15/21 7:35 AM, Vikas Gupta wrote:
> Hi Eric,
>
> On Tue, Jan 12, 2021 at 2:52 PM Auger Eric wrote:
>>
>> Hi Vikas,
>>
>> On 12/14/20 6:45 PM, Vikas Gupta wrote:
>>> Add msi support for Broadcom platform devices
>>>
>>> Si
Hi Jean,
On 1/14/21 6:33 PM, Jean-Philippe Brucker wrote:
> Hi Eric,
>
> On Thu, Jan 14, 2021 at 05:58:27PM +0100, Auger Eric wrote:
>>>> The uacce-devel branches from
>>>>> https://github.com/Linaro/linux-kernel-uadk do provide this at the moment
>&g
Hi Shameer, Jean-Philippe,
On 12/4/20 11:23 AM, Auger Eric wrote:
> Hi Shameer, Jean-Philippe,
>
> On 12/4/20 11:20 AM, Shameerali Kolothum Thodi wrote:
>> Hi Jean,
>>
>>> -Original Message-
>>> From: Jean-Philippe Brucker [mailto:jean-phili...@li
executing the test. This patch moves the assignment after the
kvm_vgic_map_resources().
Signed-off-by: Eric Auger
---
v1 -> v2:
- slight reword of the commit msg (for instance)
---
arch/arm64/kvm/arm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kvm/arm.c b/a
R.Last bit
still makes sense for architecture compliance.
This patch restores its support (if the redistributor region
was set) while keeping the code safe.
Signed-off-by: Eric Auger
---
arch/arm64/kvm/vgic/vgic-mmio-v3.c | 7 ++-
include/kvm/arm_vgic.h | 1 +
2 files changed, 7
group
and especially the GICR_TYPER read. The goal was to test the case
recently fixed by commit 23bde34771f1
("KVM: arm64: vgic-v3: Drop the reporting of GICR_TYPER.Last for userspace").
The API under test can be found at
Documentation/virt/kvm/devices/arm-vgic-v3.rst
Signed-off-by:
,write}.
Signed-off-by: Eric Auger
---
v1 -> v2:
- reworded the commit message as suggested by Alexandru
---
arch/arm64/kvm/vgic/vgic-mmio.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/kvm/vgic/vgic-mmio.c b/arch/arm64/kvm/vgic/vgic-mmio.c
in
kvm_arch_vcpu_precreate() returns -EBUSY if the vgic is
already initialized. So let's document that KVM_DEV_ARM_VGIC_CTRL_INIT
must be called after all vcpu creations.
Signed-off-by: Eric Auger
---
v1 -> v2:
- Must be called after all vcpu creations ->
Must be called after all VCPU
in vgic_register_redist_iodev().
In such a case, remove the newly added redistributor region and free
it.
Signed-off-by: Eric Auger
---
v1 -> v2:
- fix the commit message and split declaration/assignment of rdreg
---
arch/arm64/kvm/vgic/vgic-mmio-v3.c | 8 +++-
1 file changed, 7 insertions(+), 1 delet
by looking at the count field.
Signed-off-by: Eric Auger
---
v1 -> v2:
- simplify the check sequence
---
arch/arm64/kvm/vgic/vgic-mmio-v3.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v3.c
b/arch/arm64/kvm/vgic/vgic-mmio
rm64: Implement
KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION")
Cc: sta...@vger.kernel.org#v4.17+
Signed-off-by: Eric Auger
Reviewed-by: Alexandru Elisei
---
v1 -> v2:
- in the commit message, remove the statement that the index always is 0
- add Alexandru's R-b
---
arch/arm64/kvm/vgic/vgic-kvm-device.c
On vgic_dist_destroy(), the addresses are not reset. However for
kvm selftest purpose this would allow to continue the test execution
even after a failure when running KVM_RUN. So let's reset the
base addresses.
Signed-off-by: Eric Auger
---
v1 -> v2:
- use dist-> in the else and add
they can be augmented with a lot more
register access tests, but let's try to move forward incrementally ...
Best Regards
Eric
This series can be found at:
https://github.com/eauger/linux/tree/vgic_kvmselftests_v2
History:
- Took into account all comments from Marc and Alexandru's except
Hi Alexandru,
On 1/12/21 6:02 PM, Alexandru Elisei wrote:
> Hi Eric,
>
> On 12/12/20 6:50 PM, Eric Auger wrote:
>> Commit 23bde34771f1 ("KVM: arm64: vgic-v3: Drop the
>> reporting of GICR_TYPER.Last for userspace") temporarily fixed
>> a bug identified whe
Hi Alexandru,
On 1/12/21 3:55 PM, Alexandru Elisei wrote:
> Hi Eric,
>
> On 12/12/20 6:50 PM, Eric Auger wrote:
>> has_run_once is set to true at the beginning of
>> kvm_vcpu_first_run_init(). This generally is not an issue
>> except when exercising the code
Hi Alexandru,
On 1/6/21 5:32 PM, Alexandru Elisei wrote:
> Hi Eric,
>
> On 12/12/20 6:50 PM, Eric Auger wrote:
>> KVM_DEV_ARM_VGIC_GRP_ADDR group doc says we should return
>> -EEXIST in case the base address of the redist is already set.
>> We currently return -EI
> On Jan 13, 2021, at 1:41 PM, Jarkko Sakkinen
> wrote:
>
> On Tue, Jan 12, 2021 at 02:57:39PM +, David Howells wrote:
>> Eric Snowberg wrote:
>>
>>>> On Dec 10, 2020, at 2:49 AM, David Howells wrote:
>>>>
>>>> Eric Snowber
On Wed, Jan 13, 2021 at 9:12 PM Enke Chen wrote:
>
> From: Enke Chen
>
> The TCP session does not terminate with TCP_USER_TIMEOUT when data
> remain untransmitted due to zero window.
>
> The number of unanswered zero-window probes (tcp_probes_out) is
> reset to zero with incoming acks
Hi Marc,
On 12/28/20 4:35 PM, Marc Zyngier wrote:
> Hi Eric,
>
> On Sat, 12 Dec 2020 18:50:04 +0000,
> Eric Auger wrote:
>>
>> vgic_register_all_redist_iodevs may succeed while
>> vgic_register_all_redist_iodevs fails. For example this can happen
>
>
Hi Alexandru,
On 1/12/21 4:39 PM, Alexandru Elisei wrote:
> Hi Eric,
>
> On 12/12/20 6:50 PM, Eric Auger wrote:
>> kvm_arch_vcpu_precreate() returns -EBUSY if the vgic is
>> already initialized. So let's document that KVM_DEV_ARM_VGIC_CTRL_INIT
>> must be call
Hi Marc,
On 12/28/20 4:41 PM, Marc Zyngier wrote:
> On Sat, 12 Dec 2020 18:50:05 +,
> Eric Auger wrote:
>>
>> On vgic_dist_destroy(), the addresses are not reset. However for
>> kvm selftest purpose this would allow to continue the test execution
>> even after
Hi Alexandru,
On 1/6/21 6:12 PM, Alexandru Elisei wrote:
> Hi Eric,
>
> The patch looks correct to me. kvm_vgic_addr() masks out all the bits except
> index
> from addr, so we don't need to do it in vgic_get_common_attr():
>
> Reviewed-by: Alexandru Elisei
>
> On
Hi Alexandru,
On 1/12/21 5:16 PM, Alexandru Elisei wrote:
> Hi Eric,
>
> On 1/12/21 4:04 PM, Alexandru Elisei wrote:
>> Hi Eric,
>>
>> On 12/12/20 6:50 PM, Eric Auger wrote:
>>> Instead of converting the vgic_io_device handle to a kvm_io_device
>>
On Wed, Jan 13, 2021 at 6:03 PM Jakub Kicinski wrote:
>
> On Wed, 13 Jan 2021 05:46:05 +0100 Eric Dumazet wrote:
> > On Wed, Jan 13, 2021 at 2:02 AM Jakub Kicinski wrote:
> > >
> > > On Tue, 12 Jan 2021 13:23:16 +0100 Eric Dumazet wrote:
> > > > On Tue,
Alexey Gladkov writes:
We might want to use refcount_t instead of atomic_t. Not a big deal
either way.
> Signed-off-by: Alexey Gladkov
> ---
> include/linux/user_namespace.h | 2 +-
> kernel/ucount.c| 10 +-
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff
The subject is wrong. This should be:
[RFC PATCH v2 2/8] Add a reference to ucounts for each cred.
Further the explanation could use a little work. Something along the
lines of:
For RLIMIT_NPROC and some other rlimits the user_struct that holds the
global limit is kept alive for the lifetime
Hi Shameer,
On 1/8/21 6:05 PM, Shameerali Kolothum Thodi wrote:
> Hi Eric,
>
>> -Original Message-----
>> From: Eric Auger [mailto:eric.au...@redhat.com]
>> Sent: 18 November 2020 11:22
>> To: eric.auger@gmail.com; eric.au...@redhat.com;
>> io...@list
On Wed, Jan 13, 2021 at 2:37 PM Alexander Lobakin wrote:
>
> Instead of calling kmem_cache_alloc() every time when building a NAPI
> skb, (re)use skbuff_heads from napi_alloc_cache.skb_cache. Previously
> this cache was only used for bulk-freeing skbuff_heads consumed via
> napi_consume_skb() or
On Wed, Jan 13, 2021 at 2:02 AM Jakub Kicinski wrote:
>
> On Tue, 12 Jan 2021 13:23:16 +0100 Eric Dumazet wrote:
> > On Tue, Jan 12, 2021 at 12:08 PM Alexander Lobakin wrote:
> > >
> > > From: Edward Cree
> > > Date: Tue, 12 Jan 2021 09:54:04 +
On Tue, Jan 12, 2021 at 11:48 PM Yuchung Cheng wrote:
>
> On Tue, Jan 12, 2021 at 2:31 PM Enke Chen wrote:
> >
> > From: Enke Chen
> >
> > In this patch two issues with TCP keepalives are fixed:
> >
> > 1) TCP keepalive does not timeout when there are data waiting to be
> >delivered and
From: Eric Biggers
The RNDRESEEDCRNG ioctl reseeds the primary_crng from itself, which
doesn't make sense. Reseed it from the input_pool instead.
Fixes: d848e5f8e1eb ("random: add new ioctl RNDRESEEDCRNG")
Cc: sta...@vger.kernel.org
Cc: linux-cry...@vger.kernel.org
Cc: Andy Luto
From: Eric Biggers
Remove some dead code that was left over following commit 90ea1c6436d2
("random: remove the blocking pool").
Cc: linux-cry...@vger.kernel.org
Cc: Andy Lutomirski
Cc: Jann Horn
Cc: Theodore Ts'o
Reviewed-by: Andy Lutomirski
Signed-off-by: Eric Biggers
---
Andr
From: Eric Biggers
On big endian CPUs, the ChaCha20-based CRNG is using the wrong
endianness for the ChaCha20 constants.
This doesn't matter cryptographically, but technically it means it's not
ChaCha20 anymore. Fix it to always use the standard constants.
Cc: linux-cry...@vger.kernel.org
Cc
On Tue, Jan 12, 2021 at 7:26 PM Alexander Lobakin wrote:
>
> From: Eric Dumazet
> Date: Tue, 12 Jan 2021 13:32:56 +0100
>
> > On Tue, Jan 12, 2021 at 11:56 AM Alexander Lobakin wrote:
> >>
> >
> >>
> >> Ah, I should've mentioned that I use U
te any feedback on that series as well.
Thanks
> David
> ---
> commit 8913866babb96fcfe452aac6042ca8862d4c0b53
> Author: Eric Snowberg
> Date: Tue Sep 15 20:49:27 2020 -0400
>
>certs: Add EFI_CERT_X509_GUID support for dbx entries
>
>The Secure Boot Forbidde
ebied...@xmission.com (Eric W. Biederman) writes:
> So there is the basic question do we want to read the raw bytes on disk
> or do we want to return something meaningful to the reader. As the
> existing tools use the xattr interface to set/clear fscaps returning
> data to user space
Miklos Szeredi writes:
> On Tue, Jan 12, 2021 at 1:15 AM Eric W. Biederman
> wrote:
>>
>> Miklos Szeredi writes:
>>
>> > On Fri, Jan 01, 2021 at 11:35:16AM -0600, Eric W. Biederman wrote:
>
>> > For one: a v2 fscap is supposed to be equivalent t
On Tue, Jan 12, 2021 at 11:56 AM Alexander Lobakin wrote:
>
>
> Ah, I should've mentioned that I use UDP GRO Fraglists, so these
> numbers are for GRO.
>
Right, this suggests UDP GRO fraglist is a pathological case of GRO,
not saving memory.
Real GRO (TCP in most cases) will consume one skb,
On Tue, Jan 12, 2021 at 12:08 PM Alexander Lobakin wrote:
>
> From: Edward Cree
> Date: Tue, 12 Jan 2021 09:54:04 +
>
> > Without wishing to weigh in on whether this caching is a good idea...
>
> Well, we already have a cache to bulk flush "consumed" skbs, although
> kmem_cache_free() is
if reset_required is forced to
0), I am wondering if we shouldn't try to turn the reset module into a
"specialization" module and put the msi hooks there. I am afraid we may
end up having modules for each and every vfio platform feature
specialization. At the moment that's fully bearable but I can't predict
what's next.
As the mandated feature is the reset capability maybe we could just keep
the config/module name terminology, tune the kconfig help message to
mention the msi support in case of flex-rm?
What do you think?
Thanks
Eric
> +
> +MODULE_LICENSE("GPL v2");
> +MODULE_AUTHOR("Broadcom");
>
Hi Vikas,
On 1/5/21 6:53 AM, Vikas Gupta wrote:
> On Tue, Dec 22, 2020 at 10:57 PM Auger Eric wrote:
>>
>> Hi Vikas,
>>
>> On 12/14/20 6:45 PM, Vikas Gupta wrote:
>>> MSI support for platform devices.The MSI block
>>> is added as an extended IRQ
On Mon, Jan 11, 2021 at 7:27 PM Alexander Lobakin wrote:
>
> Inspired by cpu_map_kthread_run() and _kfree_skb_defer() logics.
>
> Currently, all sorts of skb allocation always do allocate
> skbuff_heads one by one via kmem_cache_alloc().
> On the other hand, we have percpu napi_alloc_cache to
pto_cap_array);
> out:
> /* Indicate that init failed by clearing UFSHCD_CAP_CRYPTO */
> hba->caps &= ~UFSHCD_CAP_CRYPTO;
Looks fine, feel free to add:
Reviewed-by: Eric Biggers
I think this was here to free the memory in the case where the crypto support
gets disabled but t
Miklos Szeredi writes:
> On Fri, Jan 01, 2021 at 11:35:16AM -0600, Eric W. Biederman wrote:
>> Miklos Szeredi writes:
>>
>> > cap_convert_nscap() does permission checking as well as conversion of the
>> > xattr value conditionally based on fs's user-ns.
>
ork_user and sets RLIMIT_NPROC to 1 in it's systemd service file.
Further suppose there is a user bob who has two containers he wants to
run: container1 and container2. Both containers start the never_fork
service.
Bob first starts container1 and inside it the never_fork service starts.
Bob starts container2 and the never_fork service fails to start.
Does that make it clear that it is the count of the processes that would
exceed 1 if both instances of the never_fork service starts that would
be the problem?
Eric
n
> public places and the community developers having to clean up the mess.
syzkaller is an open source project that implements a coverage-guided fuzzer for
multiple operating system kernels; it's not "Google AI".
Anyone can run syzkaller (either by itself, or as part of a syzbot instance) and
find the same bugs.
- Eric
; > + }
> > >
> > > desc->tfm = *tfm;
> > >
> > > rc = crypto_shash_init(desc);
> > > if (rc) {
> > > + if (tmp_tfm)
> > > + crypto_free_shash(tmp_tfm);
> > > kfree(desc);
> > > return ERR_PTR(rc);
> > > }
> >
> > There's no need to check for NULL before calling crypto_free_shash().
> >
>
> I find there is a crypto_shash_tfm() in the definition of
> crypto_free_shash(). Will this lead to null pointer dereference
> when we use it to free a NULL pointer?
>
No. It does >base, not tfm->base.
- Eric
support (on 32bit where dosemu can use vm86)?
It may still be a valid removal target I just wanted to point out what
the original user was.
Eric
> Cc: Andrea Arcangeli
> Cc: Linux-MM
> Cc: Jason Gunthorpe
> Cc: x...@kernel.org
> Cc: Linus Torvalds
> Cc: Matthew Wilcox
>
+Jason, since this looks WireGuard-related.
On Sat, Jan 09, 2021 at 05:05:24AM -0800, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:73d62e81 kmsan: random: prevent boot-time reports in _mix_..
> git tree: https://github.com/google/kmsan.git master
>
501 - 600 of 29762 matches
Mail list logo
