Thanks for looking, Peter: I was well aware of you dropping several hints
that you wanted to see what's intended before passing judgment on earlier
series, and I preferred to get on with showing this series, than go into
detail in responses to you there - thanks for your patience :)
On Mon, 29 May
> -Original Message-
> From: Uwe Kleine-König
> Sent: Tuesday, May 30, 2023 8:51 AM
> To: Leo Li
> Cc: Stuart Yoder ; Gaurav Jain
> ; Roy Pledge ; Diana
> Madalina Craciun (OSS) ; Eric Dumazet
> ; Ioana Ciornei ;
> k...@vger.kernel.org; Horia Geanta ; Jakub
> Kicinski ; Paolo Abeni ; La
Hello maintainers,
I am still seeing these build errors on linux-next-20230530.
Is there a problem with the patch?
Thanks.
On 5/21/23 15:57, Randy Dunlap wrote:
> Both SND_MPC52xx_SOC_PCM030 and SND_MPC52xx_SOC_EFIKA select
> SND_SOC_MPC5200_AC97. The latter symbol depends on PPC_BESTCOMM
On Mon, May 29, 2023 at 04:50:45PM +0200, Miguel Ojeda wrote:
> Kees: what is the current stance on `[static N]` parameters? Something like:
>
> const char *kallsyms_lookup(unsigned long addr,
> unsigned long *symbolsize,
> unsign
On Fri, May 12, 2023 at 02:48:51PM -0500, Bjorn Helgaas wrote:
> On Fri, May 12, 2023 at 01:56:29PM +0300, Andy Shevchenko wrote:
> > On Tue, May 09, 2023 at 01:21:22PM -0500, Bjorn Helgaas wrote:
> > > On Tue, Apr 04, 2023 at 11:11:01AM -0500, Bjorn Helgaas wrote:
> > > > On Thu, Mar 30, 2023 at 0
On Tue, May 30, 2023 at 1:37 PM Oliver Upton wrote:
>
> Hi Yu,
>
> On Sat, May 27, 2023 at 02:13:07PM -0600, Yu Zhao wrote:
> > On Sat, May 27, 2023 at 12:08 PM Oliver Upton
> > wrote:
> > > diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
> > > index 3d61bd3e591d..bfbebd
Hi Yu,
On Sat, May 27, 2023 at 02:13:07PM -0600, Yu Zhao wrote:
> On Sat, May 27, 2023 at 12:08 PM Oliver Upton wrote:
> > diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
> > index 3d61bd3e591d..bfbebdcb4ef0 100644
> > --- a/arch/arm64/kvm/hyp/pgtable.c
> > +++ b/arch/arm
Duplicate of
https://lore.kernel.org/all/20230523021425.2406309-1-azeemshaik...@gmail.com/.
Sorry about that.
On Tue, May 30, 2023 at 12:00 PM Azeem Shaikh wrote:
>
> strlcpy() reads the entire source buffer first.
> This read may exceed the destination size limit.
> This is both inefficient and
strlcpy() reads the entire source buffer first.
This read may exceed the destination size limit.
This is both inefficient and can lead to linear read
overflows if a source string is not NUL-terminated [1].
In an effort to remove strlcpy() completely [2], replace
strlcpy() here with strscpy().
No re
On Fri 2023-05-26 18:41:39, Douglas Anderson wrote:
> It's been suggested that since the SMP barriers are only potentially
> useful for the buddy hardlockup detector, not the perf hardlockup
> detector, that the barriers belong in the buddy code. Let's move them
> and add clearer comments about why
On Fri 2023-05-26 18:41:38, Douglas Anderson wrote:
> The dependency for HARDLOCKUP_DETECTOR_PREFER_BUDDY was more
> complicated than it needed to be. If the "perf" detector is available
> and we have SMP then we have a choice, so enable the config based on
> just those two config items.
>
> Sugge
On Fri 2023-05-26 18:41:37, Douglas Anderson wrote:
> There's no reason to make a copy of the "watchdog_cpus" locally in
> watchdog_next_cpu(). Making a copy wouldn't make things any more race
> free and we're just reading the value so there's no need for a copy.
>
> Suggested-by: Petr Mladek
> S
On Fri 2023-05-26 18:41:36, Douglas Anderson wrote:
> In the patch ("watchdog/hardlockup: detect hard lockups using
> secondary (buddy) CPUs"), we added a call from the common watchdog.c
> file into the buddy. That call could be done more cleanly.
> Specifically:
> 1. If we move the call into watch
On Fri 2023-05-26 18:41:35, Douglas Anderson wrote:
> In the patch ("watchdog/hardlockup: add comments to
> touch_nmi_watchdog()") we adjusted some comments for
> touch_nmi_watchdog(). The comment about the softlockup had a typo and
> were also felt to be too obvious. Remove it.
>
> Suggested-by:
On Fri 2023-05-26 18:41:34, Douglas Anderson wrote:
> In the patch ("watchdog/hardlockup: add a "cpu" param to
> watchdog_hardlockup_check()") we started using a cpumask to keep track
> of which CPUs to backtrace. When setting up this cpumask, it's better
> to use cpumask_copy() than to just copy t
On Fri 2023-05-26 18:41:33, Douglas Anderson wrote:
> In the patch ("watchdog/hardlockup: add a "cpu" param to
> watchdog_hardlockup_check()") there was no reason to use
> raw_cpu_ptr(). Using this_cpu_ptr() works fine.
>
> Suggested-by: Petr Mladek
> Signed-off-by: Douglas Anderson
Reviewed-by
On Fri 2023-05-26 18:41:32, Douglas Anderson wrote:
> Right now there is one arch (sparc64) that selects HAVE_NMI_WATCHDOG
> without selecting HAVE_HARDLOCKUP_DETECTOR_ARCH. Because of that one
> architecture, we have some special case code in the watchdog core to
> handle the fact that watchdog_ha
On Fri 2023-05-26 18:41:31, Douglas Anderson wrote:
> The permissions for the kernel.nmi_watchdog sysctl have always been
> set at compile time despite the fact that a watchdog can fail to
> probe. Let's fix this and set the permissions based on whether the
> hardlockup detector actually probed.
>
Hello,
On Mon, May 08, 2023 at 04:57:00PM -0500, Li Yang wrote:
> On Mon, May 8, 2023 at 8:44 AM Uwe Kleine-König
> wrote:
> > On Thu, Apr 13, 2023 at 08:00:04AM +0200, Uwe Kleine-König wrote:
> > > On Wed, Apr 12, 2023 at 09:30:05PM +, Leo Li wrote:
> > > > > On Fri, Mar 10, 2023 at 11:41:22
On Tue, May 30, 2023 at 10:03:53PM +1000, Michael Ellerman wrote:
> Jason Gunthorpe writes:
> > On Tue, May 23, 2023 at 08:26:32AM +0200, Joerg Roedel wrote:
> >> On Tue, May 16, 2023 at 09:35:25PM -0300, Jason Gunthorpe wrote:
> >> > With POWER SPAPR now having a real iommu driver and using the n
From: Maninder Singh
> Sent: 29 May 2023 12:14
>
> kallsyms_lookup which in turn calls for kallsyms_lookup_buildid()
> writes on index "KSYM_NAME_LEN - 1".
>
> Thus array size should be KSYM_NAME_LEN.
>
> for hexagon it was defined as "128" directly.
> and commit '61968dbc2d5d' changed define va
On Mon, May 29, 2023 at 1:14 PM Maninder Singh wrote:
>
> kallsyms_lookup which in turn calls for kallsyms_lookup_buildid()
> writes on index "KSYM_NAME_LEN - 1".
>
> Thus array size should be KSYM_NAME_LEN.
>
> for hexagon it was defined as "128" directly.
> and commit '61968dbc2d5d' changed defi
On Mon, May 29, 2023 at 1:14 PM Maninder Singh wrote:
>
> +static char tmpstr[KSYM_NAME_LEN];
Reviewed-by: Miguel Ojeda
Side-note: in `get_function_bounds()`, I see `kallsyms_lookup()` being
used, but the name seems discarded? Can
`kallsyms_lookup_size_offset()` be used instead, thus avoiding t
Jason Gunthorpe writes:
> On Tue, May 23, 2023 at 08:26:32AM +0200, Joerg Roedel wrote:
>> On Tue, May 16, 2023 at 09:35:25PM -0300, Jason Gunthorpe wrote:
>> > With POWER SPAPR now having a real iommu driver and using the normal group
>> > lifecycle stuff fixing FSL will leave only VFIO's no-iomm
Greg KH writes:
> On Sun, May 28, 2023 at 01:16:44PM +0530, mirim...@outlook.com wrote:
>> From: Immad Mir
>>
>> The debugfs_create_dir returns ERR_PTR incase of an error and the
>> correct way of checking it by using the IS_ERR inline function, and
>> not the simple null comparision. This patch
There's an issue on SAI synchronous mode that TX/RX side can't get BCLK
from RX/TX it sync with if BYP bit is asserted. It's a workaround to
fix it that enable SION of IOMUX pad control and assert BCI.
For example if TX sync with RX which means both TX and RX are using clk
form RX and BYP=1. TX ca
Toolchains don't always default to the ELFv2 ABI. This is true with at
least the kernel.org toolchains. As such, pass -mabi=elfv2 explicitly to
ensure that we are testing against the correct compiler output.
Signed-off-by: Naveen N Rao
---
The script works fine without this change, so this is not
On Mon 2023-05-29 16:43:36, Maninder Singh wrote:
> kallsyms_lookup which in turn calls for kallsyms_lookup_buildid()
> writes on index "KSYM_NAME_LEN - 1".
>
> Thus array size should be KSYM_NAME_LEN.
>
> for hexagon it was defined as "128" directly.
> and commit '61968dbc2d5d' changed define va
Hi Peter,
>
> The best solution would be to pass the buffer size as an extra
> parameter. Especially when some code passes buffers that are
> allocated/reserved dynamically.
>
> Sigh, I am not sure how many changes it would require in kallsyms
> API and all the callers. But it would be really app
On Mon 2023-05-29 16:50:45, Miguel Ojeda wrote:
> On Mon, May 29, 2023 at 1:08 PM Maninder Singh
> wrote:
> >
> > I Will add co-developed-by` tag.
> > because this change was identified while we were working on kallsyms some
> > time back.
> > https://lore.kernel.org/lkml/yontol4zc4cyt...@infrad
On Mon, 29 May 2023 at 17:50, Christophe Leroy
wrote:
>
> The following boottime error is encountered with SMP kernel:
>
> kcsan: improperly instrumented type=(0): arch_spin_unlock(&arch_spinlock)
> kcsan: improperly instrumented type=(0): spin_unlock(&test_spinlock)
> kcsan: improperly inst
31 matches
Mail list logo
