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
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
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
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
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
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
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
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(_spinlock)
> kcsan: improperly instrumented type=(0): spin_unlock(_spinlock)
> kcsan: improperly instrumented
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.
> >
binutils v2.37 drops unused section symbols, which prevents recordmcount
from capturing mcount locations in sections that have no non-weak
symbols. This results in a build failure with a message such as:
Cannot find symbol for section 12: .text.perf_callchain_kernel.
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
Michael Ellerman wrote:
Naveen N Rao writes:
binutils v2.37 drops unused section symbols, which prevents recordmcount
from capturing mcount locations in sections that have no non-weak
symbols. This results in a build failure with a message such as:
Cannot find symbol for section 12:
Maninder Singh writes:
> 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 powerpc it was defined as "128" directly.
> and commit '61968dbc2d5d' changed define value to 512,
> So both were
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
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
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
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
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: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
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
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
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
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
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.
>
>
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
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.
>
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
>
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
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
> > +++
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
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
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,
>
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
> -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 ;
34 matches
Mail list logo
