tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: ac139fc7db67968e5061715508b5fc4aa7c40c56 Add linux-next specific
files for 20240206
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202402061900.rtuydlo6-...@intel.com
https
On Tue, 2024-02-06 at 20:47 -0800, Sean Christopherson wrote:
>
> I'm saying this:
>
> When processing mmu_notifier invalidations for gpc caches, pre-check for
> overlap with the invalidation event while holding gpc->lock for read, and
> only take gpc->lock for write if the cache needs to b
On Tue, Feb 06, 2024, David Woodhouse wrote:
> On Tue, 2024-02-06 at 20:22 -0800, Sean Christopherson wrote:
> > On Mon, Jan 15, 2024, Paul Durrant wrote:
> > > From: Paul Durrant
> > >
> > > Taking a write lock on a pfncache will be disruptive if the cache is
> >
> > *Unnecessarily* taking a wr
On Tue, 2024-02-06 at 20:22 -0800, Sean Christopherson wrote:
> On Mon, Jan 15, 2024, Paul Durrant wrote:
> > From: Paul Durrant
> >
> > Taking a write lock on a pfncache will be disruptive if the cache is
>
> *Unnecessarily* taking a write lock.
No. Taking a write lock will be disrupting.
Unn
On Mon, Jan 15, 2024, Paul Durrant wrote:
> From: Paul Durrant
>
> Taking a write lock on a pfncache will be disruptive if the cache is
*Unnecessarily* taking a write lock. Please save readers a bit of brain power
and explain that this is beneificial when there are _unrelated_ invalidation.
>
On Tue, 2024-02-06 at 20:17 -0800, Sean Christopherson wrote:
> On Mon, Jan 15, 2024, Paul Durrant wrote:
> > From: Paul Durrant
> >
> > As described in [1] compiling with CONFIG_PROVE_RAW_LOCK_NESTING shows that
> > kvm_xen_set_evtchn_fast() is blocking on pfncache locks in IRQ context.
> > Ther
On Mon, Jan 15, 2024, Paul Durrant wrote:
> From: Paul Durrant
>
> As described in [1] compiling with CONFIG_PROVE_RAW_LOCK_NESTING shows that
> kvm_xen_set_evtchn_fast() is blocking on pfncache locks in IRQ context.
> There is only actually blocking with PREEMPT_RT because the locks will
> turne
Please stop making up random scopes. Yes, I know "KVM: selftests:" is too
coarse,
bt everyone doing their own thing is worse.
On Tue, 2024-02-06 at 20:03 -0800, Sean Christopherson wrote:
> +s390 folks (question on kvm_is_error_gpa() for ya)
>
> On Mon, Jan 15, 2024, Paul Durrant wrote:
> > @@ -1398,7 +1414,9 @@ void kvm_gpc_deactivate(struct gfn_to_pfn_cache *gpc);
> > static inline void kvm_gpc_mark_dirty(struct gfn_
On Mon, Jan 15, 2024, Paul Durrant wrote:
> @@ -638,20 +637,32 @@ int kvm_xen_hvm_set_attr(struct kvm *kvm, struct
> kvm_xen_hvm_attr *data)
> }
> break;
>
> - case KVM_XEN_ATTR_TYPE_SHARED_INFO: {
> + case KVM_XEN_ATTR_TYPE_SHARED_INFO:
> + case KVM_XEN_A
+s390 folks (question on kvm_is_error_gpa() for ya)
On Mon, Jan 15, 2024, Paul Durrant wrote:
> @@ -1398,7 +1414,9 @@ void kvm_gpc_deactivate(struct gfn_to_pfn_cache *gpc);
> static inline void kvm_gpc_mark_dirty(struct gfn_to_pfn_cache *gpc)
> {
> lockdep_assert_held(&gpc->lock);
> -
On Tue, 2024-02-06 at 19:17 -0800, Sean Christopherson wrote:
> KVM: x86/xen: for the scope please. A few commits have "KVM: xen:", but
> "x86/xen"
> is the overwhelming favorite.
Paul's been using "KVM: xen:" in this patch series since first posting
it in September of last year. If there aren't
On Mon, Jan 15, 2024, Paul Durrant wrote:
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index 7e7fd25b09b3..f3bb9e0a81fe 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -1399,6 +1399,17 @@ int kvm_gpc_refresh(struct gfn_to_pfn_cache *gpc,
> unsi
KVM: x86/xen: for the scope please. A few commits have "KVM: xen:", but
"x86/xen"
is the overwhelming favorite.
Pstore now supports multiple backends, adjust related document.
Signed-off-by: Yuanhe Shu
---
Documentation/ABI/testing/pstore| 8
Documentation/admin-guide/kernel-parameters.txt | 4 +++-
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/Documentation/ABI/t
Pstore now supports multiple backends, the module parameter
pstore.backend varies from 'registered backend' to 'backends that are
allowed to register'. Adjust selftests to match the change.
Signed-off-by: Yuanhe Shu
---
tools/testing/selftests/pstore/common_tests | 8 +--
.../selftests/pstore
Currently, pstore supports only one backend open at a time.
Specifically, due to the global variable "psinfo", pstore only accepts
the first registered backend. If a new backend wants to register later,
pstore will simply reject it and return an error. This design forced us
to close existing backen
I have been steadily working but struggled to find a seamlessly
integrated way to implement tty frontend until Guilherme inspired me
that multi-backend and tty frontend are actually two separate entities.
This submission presents the 3rd iteration of my efforts, listing
notable changes form the v1:
On 2/6/24 9:04 AM, Marco Elver wrote:
On Mon, Feb 05, 2024 at 03:24PM -0800, Martin KaFai Lau wrote:
[...]
Or can you suggest different functions to hook to for the recursion test?
I don't prefer to add another tracepoint for the selftest.
Ok - I also checked, even though it should be a no-o
This exact case was fail for async crypto and we weren't
catching it.
Signed-off-by: Jakub Kicinski
---
CC: sh...@kernel.org
CC: linux-kselftest@vger.kernel.org
---
tools/testing/selftests/net/tls.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftes
On Tue, Feb 06, 2024 at 01:56:23PM +0100, Frederic Weisbecker wrote:
> Le Wed, Jan 17, 2024 at 12:15:07PM -0500, Waiman Long a écrit :
> >
> > On 1/17/24 12:07, Tejun Heo wrote:
> > > Hello,
> > >
> > > On Wed, Jan 17, 2024 at 11:35:03AM -0500, Waiman Long wrote:
> > > > The first 2 patches are a
> -Original Message-
> From: Rae Moar
> On Sun, Feb 4, 2024 at 8:03 AM Kees Cook wrote:
> >
> > On January 26, 2024 11:14:26 PM GMT+01:00, Rae Moar
> > wrote:
> > > KTAP version 2
> > > # ktap_test: main
> > > # ktap_arch: uml
> > > 1..1
> > > KTAP version 2
> > > # ktap_test: s
On Sun, Feb 04, 2024 at 08:56:18AM -0800, Jakub Kicinski wrote:
> cmsg_ipv6 test requests tcpdump to capture 4 packets,
> and sends until tcpdump quits. Only the first packet
> is "real", however, and the rest are basic UDP packets.
> So if tcpdump doesn't start in time it will miss
> the real pack
On Mon, Feb 05, 2024 at 03:24PM -0800, Martin KaFai Lau wrote:
[...]
> > Or can you suggest different functions to hook to for the recursion test?
>
> I don't prefer to add another tracepoint for the selftest.
Ok - I also checked, even though it should be a no-op, it wasn't
(compiler generated wo
On Wed, Jan 24, 2024 at 10:21:43PM -0800, de...@rivosinc.com wrote:
> To allow userspace to enable this feature for itself, following prtcls are
> defined:
> - PR_GET_INDIR_BR_LP_STATUS: Gets current configured status for indirect
> branch
>tracking.
> - PR_SET_INDIR_BR_LP_STATUS: Sets a co
On Wed, Jan 24, 2024 at 10:21:40PM -0800, de...@rivosinc.com wrote:
> As discussed extensively in the changelog for the addition of this
> syscall on x86 ("x86/shstk: Introduce map_shadow_stack syscall") the
> existing mmap() and madvise() syscalls do not map entirely well onto the
> security requ
Paolo Abeni wrote:
> The gro self-tests sends the packets to be aggregated with
> multiple write operations.
>
> When running is slow environment, it's hard to guarantee that
> the GRO engine will wait for the last packet in an intended
> train.
>
> The above causes almost deterministic failures
The gro self-tests sends the packets to be aggregated with
multiple write operations.
When running is slow environment, it's hard to guarantee that
the GRO engine will wait for the last packet in an intended
train.
The above causes almost deterministic failures in our CI for
the 'large' test-case
On Tue, Feb 06, 2024 at 06:12:38AM -0800, Kees Cook wrote:
> The seccomp benchmark test (for validating the benefit of bitmaps) can
> be sensitive to scheduling speed, so pin the process to a single CPU,
> which appears to significantly improve reliability, and loosen the
> "close enough" checking
The seccomp benchmark test (for validating the benefit of bitmaps) can
be sensitive to scheduling speed, so pin the process to a single CPU,
which appears to significantly improve reliability, and loosen the
"close enough" checking to allow up to 10% variance instead of 1%.
Reported-by: kernel tes
On Thu, 1 Feb 2024 09:25:57 +0100
Ali Zahraee wrote:
> This is just another trivial typo fix. The typo shows up in the final
> report after tests are done.
>
Thanks, and that is already reported very recently.
https://lore.kernel.org/all/20240129162841.57979-1-five231...@gmail.com/
> Signed-
Le Wed, Jan 17, 2024 at 12:15:07PM -0500, Waiman Long a écrit :
>
> On 1/17/24 12:07, Tejun Heo wrote:
> > Hello,
> >
> > On Wed, Jan 17, 2024 at 11:35:03AM -0500, Waiman Long wrote:
> > > The first 2 patches are adopted from Federic with minor twists to fix
> > > merge conflicts and compilation
Hi Yuanhe,
kernel test robot noticed the following build errors:
[auto build test ERROR on kees/for-next/pstore]
[also build test ERROR on kees/for-next/kspp shuah-kselftest/next
shuah-kselftest/fixes linus/master v6.8-rc3 next-20240206]
[cannot apply to aegl/next]
[If your patch is applied to
On Tue, Feb 06, 2024 at 03:04:32AM -0800, Kees Cook wrote:
> On Tue, Feb 06, 2024 at 10:16:19AM +, Mark Brown wrote:
> > On Tue, Feb 06, 2024 at 01:56:47AM -0800, Kees Cook wrote:
> > > + /* Set from highest CPU down. */
> > > + for (cpu = ncores - 1; cpu >= 0; cpu--) {
> > > + CPU_ZER
On Tue, Feb 06, 2024 at 10:16:19AM +, Mark Brown wrote:
> On Tue, Feb 06, 2024 at 01:56:47AM -0800, Kees Cook wrote:
>
> > + /* Set from highest CPU down. */
> > + for (cpu = ncores - 1; cpu >= 0; cpu--) {
> > + CPU_ZERO_S(setsz, setp);
> > + CPU_SET_S(cpu, setsz, setp)
Hi Paolo, Willem, Jakub,
On 06/02/2024 10:18, Paolo Abeni wrote:
> On Fri, 2024-02-02 at 19:31 -0500, Willem de Bruijn wrote:
>> Jakub Kicinski wrote:
>>> On Thu, 1 Feb 2024 11:21:19 -0500 Willem de Bruijn wrote:
This test is time sensitive. It may fail on virtual machines and for
debug
On Tue, Feb 06, 2024 at 01:56:47AM -0800, Kees Cook wrote:
> + /* Set from highest CPU down. */
> + for (cpu = ncores - 1; cpu >= 0; cpu--) {
> + CPU_ZERO_S(setsz, setp);
> + CPU_SET_S(cpu, setsz, setp);
Is there some particular reason to go from the highest CPU nu
The seccomp benchmark test (for validating the benefit of bitmaps) can
be sensitive to scheduling speed, so pin the process to a single CPU,
which appears to significantly improve reliability.
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-lkp/202402061002.3a8722fd-oliver.s...
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni :
On Fri, 2 Feb 2024 02:24:59 + you wrote:
> Selftests here check not only that connect()/accept() for
> TCP-AO/TCP-MD5/non-signed-TCP combinations do/don't establish
> connections, but also counters: those are per-AO-key,
Hello:
This patch was applied to netdev/net-next.git (main)
by Paolo Abeni :
On Thu, 1 Feb 2024 11:21:19 -0500 you wrote:
> From: Willem de Bruijn
>
> This test is time sensitive. It may fail on virtual machines and for
> debug builds.
>
> Continue to run in these environments to get code cov
On Fri, 2024-02-02 at 19:31 -0500, Willem de Bruijn wrote:
> Jakub Kicinski wrote:
> > On Thu, 1 Feb 2024 11:21:19 -0500 Willem de Bruijn wrote:
> > > This test is time sensitive. It may fail on virtual machines and for
> > > debug builds.
> > >
> > > Continue to run in these environments to get
Currently, pstore supports only one backend open at a time.
Specifically, due to the global variable "psinfo", pstore only accepts
the first registered backend. If a new backend wants to register later,
pstore will simply reject it and return an error. This design forced us
to close existing backen
205-203438
base: https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git
for-next/pstore
patch link:
https://lore.kernel.org/r/20240205122852.7069-2-xiangzao%40linux.alibaba.com
patch subject: [PATCH 1/3] pstore: add multi-backend support
config: csky-randconfig-r071-20240206
(https://d
43 matches
Mail list logo
