On Wed, 2025-05-14 at 11:09 -0400, Mimi Zohar wrote:
> On Tue, 2025-04-29 at 15:04 +0200, Thomas Weißschuh wrote:
> > When configuration settings are disabled the guarded functions are
> > defined as empty stubs, so the check is unnecessary.
> > The specific configuration option for set_module_sig_
On Tue, 2025-04-29 at 15:04 +0200, Thomas Weißschuh wrote:
> When CONFIG_MODULE_SIG is disabled set_module_sig_enforced() is defined
> as an empty stub, so the check is unnecessary.
> The specific configuration option for set_module_sig_enforced() is
> about to change and removing the check avoids
On Wed, 14 May 2025 at 13:30, Luis Gerhorst wrote:
>
> Kumar Kartikeya Dwivedi writes:
>
> (including relevant part from other message)
>
> > On Thu, 1 May 2025 at 04:00, Luis Gerhorst wrote:
> >
> >> +static bool error_recoverable_with_nospec(int err)
> >> +{
> >> + /* Should only return
On May 13, 2025 2:53:23 AM PDT, Arnd Bergmann wrote:
>On Tue, May 13, 2025, at 11:17, Andrey Albershteyn wrote:
>
>>
>> long syscall(SYS_file_getattr, int dirfd, const char *pathname,
>> struct fsxattr *fsx, size_t size, unsigned int at_flags);
>> long syscall(SYS_file_setat
From: Kan Liang
The throttle support has been added in the generic code. Remove
the driver-specific throttle support.
Besides the throttle, perf_event_overflow may return true because of
event_limit. It already does an inatomic event disable. The pmu->stop
is not required either.
Signed-off-by:
On Tue, 2025-04-29 at 15:04 +0200, Thomas Weißschuh wrote:
> When configuration settings are disabled the guarded functions are
> defined as empty stubs, so the check is unnecessary.
> The specific configuration option for set_module_sig_enforced() is
> about to change and removing the checks avoid
On 5/14/2025 4:02 AM, Andrey Albershteyn wrote:
> On 2025-05-12 08:43:32, Casey Schaufler wrote:
>> On 5/12/2025 6:25 AM, Andrey Albershteyn wrote:
>>> Introduce new hooks for setting and getting filesystem extended
>>> attributes on inode (FS_IOC_FSGETXATTR).
>>>
>>> Cc: seli...@vger.kernel.org
>>
May 14, 2025 19:39:37 Mimi Zohar :
> On Wed, 2025-05-14 at 11:09 -0400, Mimi Zohar wrote:
>> On Tue, 2025-04-29 at 15:04 +0200, Thomas Weißschuh wrote:
>>> When configuration settings are disabled the guarded functions are
>>> defined as empty stubs, so the check is unnecessary.
>>> The specific c
On Wed, 2025-05-14 at 20:25 +0200, Thomas Weißschuh wrote:
> May 14, 2025 19:39:37 Mimi Zohar :
>
> > On Wed, 2025-05-14 at 11:09 -0400, Mimi Zohar wrote:
> > > On Tue, 2025-04-29 at 15:04 +0200, Thomas Weißschuh wrote:
> > > > When configuration settings are disabled the guarded functions are
> >
Eric Biggers wrote:
> From: Eric Biggers
>
> As discussed in the thread containing
> https://lore.kernel.org/linux-crypto/20250510053308.GB505731@sol/, the
> Power10-optimized Poly1305 code is currently not safe to call in softirq
> context. Disable it for now. It can be re-enabled once it is
On Wed, May 14, 2025 at 03:46:30PM +0200, Stefano Garzarella wrote:
> From: Stefano Garzarella
>
> This driver does not support interrupts, and receiving the response is
> synchronous with sending the command.
>
> Enable synchronous send() with TPM_CHIP_FLAG_SYNC, which implies that
> ->send() a
On Mon, 05 May 2025 13:53:07 -0400, Ben Collins wrote:
> The driver currently hardcodes DMA_BIT_MASK to 36-bits, which is only
> correct on eloplus:
>
> elo3 supports 40-bits
> eloplus supports 36-bits
> elo supports 32-bits
>
> [...]
Applied, thanks!
[1/1] fs
On Wed, May 14, 2025 at 05:41:39PM +0800, Herbert Xu wrote:
> Eric Biggers wrote:
> > From: Eric Biggers
> >
> > As discussed in the thread containing
> > https://lore.kernel.org/linux-crypto/20250510053308.GB505731@sol/, the
> > Power10-optimized Poly1305 code is currently not safe to call in s
On Wed, May 14, 2025 at 12:00:11PM +0530, Krishna Chaitanya Chundru wrote:
>
>
> On 5/8/2025 12:40 PM, Manivannan Sadhasivam wrote:
> > The PCI link, when down, needs to be recovered to bring it back. But that
> > cannot be done in a generic way as link recovery procedure is specific to
> > host
On Thu, 08 May 2025 12:40:29 +0530, Manivannan Sadhasivam wrote:
> Currently, in the event of AER/DPC, PCI core will try to reset the slot and
> its
> subordinate devices by invoking bridge control reset and FLR. But in some
> cases like AER Fatal error, it might be necessary to reset the slots
On Wed, May 14, 2025 at 11:52:13AM +0530, Krishna Chaitanya Chundru wrote:
>
>
> On 5/8/2025 12:40 PM, Manivannan Sadhasivam wrote:
> > The PCIe link can go down under circumstances such as the device firmware
> > crash, link instability, etc... When that happens, the PCIe slot needs to
> > be re
On 5/8/25 12:10 AM, Manivannan Sadhasivam wrote:
A PCI device is just another peripheral in a system. So failure to
recover it, must not result in a kernel panic. So remove the TODO which
is quite misleading.
Signed-off-by: Manivannan Sadhasivam
---
Reviewed-by: Kuppuswamy Sathyanarayanan
On 5/8/25 12:10 AM, Manivannan Sadhasivam wrote:
Some host bridge devices require resetting the slots in a platform specific
way to recover them from error conditions such as Fatal AER errors, Link
Down etc... So introduce pci_host_bridge::reset_slot callback and call it
from pcibios_reset_seco
Kumar Kartikeya Dwivedi writes:
(including relevant part from other message)
> On Thu, 1 May 2025 at 04:00, Luis Gerhorst wrote:
>
>> +static bool error_recoverable_with_nospec(int err)
>> +{
>> + /* Should only return true for non-fatal errors that are allowed to
>> +* occur dur
On 5/7/25 11:12 PM, Alexandru Elisei wrote:
Arm and arm64 support running the tests under kvmtool. kvmtool has a
different command line syntax for configuring and running a virtual
machine, and the automated scripts know only how to use qemu.
One issue with that is even though the tests have
On 5/7/25 11:12 PM, Alexandru Elisei wrote:
Move away from hardcoded qemu arguments and use instead an associative
array to get the needed arguments. This paves the way for adding kvmtool
support to the scripts, which has a different syntax for the same VM
configuration parameters.
Suggested-
On 5/8/25 11:59 AM, Narayana Murty N wrote:
VFIO EEH recovery for PCI passthrough devices fails on PowerNV and pseries
platforms due to missing host-side PE bridge reconfiguration. In the
current implementation, eeh_pe_configure() only performs RTAS or OPAL-based
bridge reconfiguration for native
From: Stefano Garzarella
This driver does not support interrupts, and receiving the response is
synchronous with sending the command.
Enable synchronous send() with TPM_CHIP_FLAG_SYNC, which implies that
->send() already fills the provided buffer with a response, and ->recv()
is not implemented.
From: Stefano Garzarella
Add a new `bufsiz` parameter to the `.send` callback in `tpm_class_ops`.
This parameter will allow drivers to differentiate between the actual
command length to send and the total buffer size. Currently `bufsiz` is
not used, but it will be used to implement devices with s
SNP" [2], which is currently merged in the tip tree and available
in linux-next.
Thanks,
Stefano
Changelog
- v4 -> v5
- changed order and parameter names to match tpm_try_transmit() [Jarkko]
- rebased on next-20250514
- v3 -> v4:
https://lore.kernel.org/linux-integrity/2025050908571
From: Stefano Garzarella
This driver does not support interrupts, and receiving the response is
synchronous with sending the command.
Enable synchronous send() with TPM_CHIP_FLAG_SYNC, which implies that
->send() already fills the provided buffer with a response, and ->recv()
is not implemented.
From: Stefano Garzarella
Some devices do not support interrupts and provide a single synchronous
operation to send the command and receive the response on the same buffer.
Currently, these types of drivers must use an internal buffer where they
temporarily store the response between .send() and
On Thu, 1 May 2025 at 04:03, Luis Gerhorst wrote:
>
> This is based on the gadget from the description of commit 9183671af6db
> ("bpf: Fix leakage under speculation on mispredicted branches").
>
> Signed-off-by: Luis Gerhorst
> ---
Acked-by: Kumar Kartikeya Dwivedi
On 2025-05-12 08:43:32, Casey Schaufler wrote:
> On 5/12/2025 6:25 AM, Andrey Albershteyn wrote:
> > Introduce new hooks for setting and getting filesystem extended
> > attributes on inode (FS_IOC_FSGETXATTR).
> >
> > Cc: seli...@vger.kernel.org
> > Cc: Paul Moore
> >
> > Signed-off-by: Andrey Alb
On Wed, May 14, 2025 at 09:29:33AM -0700, Eric Biggers wrote:
>
> I didn't notice that. Probably, though I don't have time to review this
> subtle
> Poly1305 code. Especially with all the weird unions in the code. Would be
> great if the PowerPC folks would take a look.
Of course more reviews
30 matches
Mail list logo
