All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH] arm64: fix build error when use rodata_enabled
From: Mark Rutland @ 2022-01-05 10:47 UTC (permalink / raw)
  To: AliOS system security
  Cc: Anshuman Khandual, catalin.marinas, will, linux-arm-kernel,
	linux-kernel
In-Reply-To: <0432f592-789b-7c92-8d7a-99191d7bc669@arm.com>

On Wed, Jan 05, 2022 at 02:51:05PM +0530, Anshuman Khandual wrote:
> Hello,
> 
> On 1/5/22 8:37 AM, AliOS system security wrote:
> > rodata_enabled should be used when CONFIG_STRICT_KERNEL_RWX
> > or CONFIG_STRICT_MODULE_RWX is selected

Further to Anshuman's comments here, for a build issue, please include the
specific build error in the commit log, and describe the configuration where
this manifests.

For the reasons Anshuman gives below I do not see how this can be a problem in
mainline.

Thanks,
Mark.

> Both these configs get selected invariably with CONFIG_ARM64 in the
> platform config file (arch/arm64/Kconfig). I guess there can not be
> any such situation, where both configs will be missing/not selected
> given ARCH_OPTIONAL_KERNEL_RWX[or _DEFAULT] is not enabled on arm64.
> 
> config ARM64
>         def_bool y
>         select ACPI_CCA_REQUIRED if ACPI
> 	.....
>         select ARCH_HAS_STRICT_KERNEL_RWX
>         select ARCH_HAS_STRICT_MODULE_RWX
> 	.....
> 
> Hence for all practical purpose, rodata_enabled could be considered
> always available. I am sure there other similar situations as well,
> where code elements are not wrapped around if the config option is
> always present.
> 
> > 
> > Signed-off-by: AliOS system security <alios_sys_security@linux.alibaba.com>
> 
> Also please refer Documentation/process/submitting-patches.rst for
> the rules regarding names, that can be used for a commit sign off.
> 
> ------------------------------------------------------------------------
> then you just add a line saying::
> 
>         Signed-off-by: Random J Developer <random@developer.example.org>
> 
> using your real name (sorry, no pseudonyms or anonymous contributions.)
> ------------------------------------------------------------------------
> 
> - Anshuman
> 
> > ---
> >  arch/arm64/mm/mmu.c | 14 ++++++++++++--
> >  1 file changed, 12 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> > index acfae9b..47f8754 100644
> > --- a/arch/arm64/mm/mmu.c
> > +++ b/arch/arm64/mm/mmu.c
> > @@ -596,6 +596,7 @@ static void __init map_kernel_segment(pgd_t *pgdp, void *va_start, void *va_end,
> >  	vm_area_add_early(vma);
> >  }
> >  
> > +#if defined(CONFIG_STRICT_KERNEL_RWX) || defined(CONFIG_STRICT_MODULE_RWX)
> >  static int __init parse_rodata(char *arg)
> >  {
> >  	int ret = strtobool(arg, &rodata_enabled);
> > @@ -613,11 +614,16 @@ static int __init parse_rodata(char *arg)
> >  	return 0;
> >  }
> >  early_param("rodata", parse_rodata);
> > +#endif
> >  
> >  #ifdef CONFIG_UNMAP_KERNEL_AT_EL0
> >  static int __init map_entry_trampoline(void)
> >  {
> > -	pgprot_t prot = rodata_enabled ? PAGE_KERNEL_ROX : PAGE_KERNEL_EXEC;
> > +	pgprot_t prot = PAGE_KERNEL_EXEC;
> > +#if defined(CONFIG_STRICT_KERNEL_RWX) || defined(CONFIG_STRICT_MODULE_RWX)
> > +	if (rodata_enabled)
> > +		prot = PAGE_KERNEL_ROX;
> > +#endif
> >  	phys_addr_t pa_start = __pa_symbol(__entry_tramp_text_start);
> >  
> >  	/* The trampoline is always mapped and can therefore be global */
> > @@ -672,7 +678,11 @@ static void __init map_kernel(pgd_t *pgdp)
> >  	 * mapping to install SW breakpoints. Allow this (only) when
> >  	 * explicitly requested with rodata=off.
> >  	 */
> > -	pgprot_t text_prot = rodata_enabled ? PAGE_KERNEL_ROX : PAGE_KERNEL_EXEC;
> > +	pgprot_t text_prot = PAGE_KERNEL_EXEC;
> > +#if defined(CONFIG_STRICT_KERNEL_RWX) || defined(CONFIG_STRICT_MODULE_RWX)
> > +	if (rodata_enabled)
> > +		text_prot = PAGE_KERNEL_ROX;
> > +#endif
> >  
> >  	/*
> >  	 * If we have a CPU that supports BTI and a kernel built for
> > 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 2/2] sched/fair: Adjust the allowed NUMA imbalance when SD_NUMA spans multiple LLCs
From: Mel Gorman @ 2022-01-05 10:49 UTC (permalink / raw)
  To: Vincent Guittot
  Cc: Gautham R. Shenoy, Peter Zijlstra, Ingo Molnar,
	Valentin Schneider, Aubrey Li, Barry Song, Mike Galbraith,
	Srikar Dronamraju, LKML
In-Reply-To: <20220105104207.GV3366@techsingularity.net>

On Wed, Jan 05, 2022 at 10:42:07AM +0000, Mel Gorman wrote:
> On Tue, Dec 21, 2021 at 06:13:15PM +0100, Vincent Guittot wrote:
> > > <SNIP>
> > >
> > > @@ -9050,9 +9054,9 @@ static bool update_pick_idlest(struct sched_group *idlest,
> > >   * This is an approximation as the number of running tasks may not be
> > >   * related to the number of busy CPUs due to sched_setaffinity.
> > >   */
> > > -static inline bool allow_numa_imbalance(int dst_running, int dst_weight)
> > > +static inline bool allow_numa_imbalance(int dst_running, int imb_numa_nr)
> > >  {
> > > -       return (dst_running < (dst_weight >> 2));
> > > +       return dst_running < imb_numa_nr;
> > >  }
> > >
> > >  /*
> > >
> > > <SNIP>
> > >
> > > @@ -9280,19 +9285,13 @@ static inline void update_sd_lb_stats(struct lb_env *env, struct sd_lb_stats *sd
> > >         }
> > >  }
> > >
> > > -#define NUMA_IMBALANCE_MIN 2
> > > -
> > >  static inline long adjust_numa_imbalance(int imbalance,
> > > -                               int dst_running, int dst_weight)
> > > +                               int dst_running, int imb_numa_nr)
> > >  {
> > > -       if (!allow_numa_imbalance(dst_running, dst_weight))
> > > +       if (!allow_numa_imbalance(dst_running, imb_numa_nr))
> > >                 return imbalance;
> > >
> > > -       /*
> > > -        * Allow a small imbalance based on a simple pair of communicating
> > > -        * tasks that remain local when the destination is lightly loaded.
> > > -        */
> > > -       if (imbalance <= NUMA_IMBALANCE_MIN)
> > > +       if (imbalance <= imb_numa_nr)
> > 
> > Isn't this always true ?
> > 
> > imbalance is "always" < dst_running as imbalance is usually the number
> > of these tasks that we would like to migrate
> > 
> 
> It's not necessarily true. allow_numa_imbalanced is checking if
> dst_running < imb_numa_nr and adjust_numa_imbalance is checking the
> imbalance.
> 
> imb_numa_nr = 4
> dst_running = 2
> imbalance   = 1
> 
> In that case, imbalance of 1 is ok, but 2 is not.
> 

My bad, this is based on v5 which I just queued for testing.

-- 
Mel Gorman
SUSE Labs

^ permalink raw reply

* Re: [PATCH 1/4] i2c: at91: add compatible with microchip,sama7g5-i2c
From: Michael Walle @ 2022-01-05 10:49 UTC (permalink / raw)
  To: Eugen.Hristev; +Cc: hs, u-boot
In-Reply-To: <08d16a59-e1f5-6e1e-1392-31f5e0cafb80@microchip.com>

Am 2022-01-05 11:37, schrieb Eugen.Hristev@microchip.com:
> On 1/5/22 12:04 PM, Michael Walle wrote:
>> Hi,
>> 
>>> Add compatible and data platform struct for sama7g5 SoC.
>>> 
>>> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
>>> ---
>>>   drivers/i2c/at91_i2c.c | 6 ++++++
>>>   1 file changed, 6 insertions(+)
>>> 
>>> diff --git a/drivers/i2c/at91_i2c.c b/drivers/i2c/at91_i2c.c
>>> index 6b4c0e4804..400a3786ca 100644
>>> --- a/drivers/i2c/at91_i2c.c
>>> +++ b/drivers/i2c/at91_i2c.c
>>> @@ -305,6 +305,11 @@ static const struct at91_i2c_pdata 
>>> sama5d2_config = {
>>>        .clk_offset = 3,
>>>   };
>>> 
>>> +static const struct at91_i2c_pdata sama7g5_config = {
>>> +     .clk_max_div = 7,
>>> +     .clk_offset = 3,
>>> +};
>>> +
>>>   static const struct udevice_id at91_i2c_ids[] = {
>>>   { .compatible = "atmel,at91rm9200-i2c", .data = 
>>> (long)&at91rm9200_config },
>>>   { .compatible = "atmel,at91sam9260-i2c", .data = 
>>> (long)&at91sam9260_config },
>>> @@ -314,6 +319,7 @@ static const struct udevice_id at91_i2c_ids[] = {
>>>   { .compatible = "atmel,at91sam9x5-i2c", .data = 
>>> (long)&at91sam9x5_config },
>>>   { .compatible = "atmel,sama5d4-i2c", .data = (long)&sama5d4_config 
>>> },
>>>   { .compatible = "atmel,sama5d2-i2c", .data = (long)&sama5d2_config 
>>> },
>>> +{ .compatible = "microchip,sama7g5-i2c", .data = 
>>> (long)&sama7g5_config },
>> 
>> I see that this compatible string is is also used in the linux
>> device tree, but there is no dt binding for it in linux. Could you
>> add it, so the binding is approved by Rob?
> 
> I can, for sure, but the current binding format is txt. I am not sure 
> if
> we have to convert to yaml first, in which case it would be a little
> more difficult than just adding a new compatible string.
> The current DT node in Linux is also compatible with sam9x60, and this
> string is already in the Linux binding file.
> I could add the sam9x60 compatible instead, and it will still work, as
> 9x60 type of i2c is the same as in sama7g5.
> You think this option would be better for now ?

It's at least better than adding an undocumented string. But TBH,
this looks like "what can I do to avoid converting the dt binding
to yaml". Which eventually has to be done anyway, so now might be
a good opportunity for that :)

But looking at sama7g5_config above again, will that also be the
correct values for the generic sam9x60?

-michael

^ permalink raw reply

* Re: [PATCH 5/8] PM: runtime: Add EXPORT[_GPL]_RUNTIME_DEV_PM_OPS macros
From: Jonathan Cameron @ 2022-01-05 10:49 UTC (permalink / raw)
  To: Paul Cercueil
  Cc: Rafael J . Wysocki, Ulf Hansson, Jonathan Cameron,
	Lars-Peter Clausen, Linus Walleij, Arnd Bergmann, Len Brown,
	Pavel Machek, list, linux-iio, linux-kernel, linux-mips,
	linux-mmc, linux-pm
In-Reply-To: <20220105100723.00001958@Huawei.com>

On Wed, 5 Jan 2022 10:07:23 +0000
Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote:

> On Tue, 4 Jan 2022 21:42:11 +0000
> Paul Cercueil <paul@crapouillou.net> wrote:
> 
> > Similar to EXPORT[_GPL]_SIMPLE_DEV_PM_OPS, but for users with runtime-PM
> > suspend/resume callbacks.
> > 
> > Signed-off-by: Paul Cercueil <paul@crapouillou.net>  
> Follow up earlier comment.  I think you want pm_ptr() around all the
> entries for RUNTIME_PM_OPS
> 

That issue didn't exist... 
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

> Jonathan
> 
> > ---
> >  include/linux/pm_runtime.h | 7 +++++++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/include/linux/pm_runtime.h b/include/linux/pm_runtime.h
> > index 4af454d29281..a7f862a26c03 100644
> > --- a/include/linux/pm_runtime.h
> > +++ b/include/linux/pm_runtime.h
> > @@ -36,6 +36,13 @@
> >  			   pm_runtime_force_resume, suspend_fn, \
> >  			   resume_fn, idle_fn)
> >  
> > +#define EXPORT_RUNTIME_DEV_PM_OPS(name, suspend_fn, resume_fn, idle_fn) \
> > +	_EXPORT_DEV_PM_OPS(name, pm_runtime_force_suspend, pm_runtime_force_resume, \
> > +			   suspend_fn, resume_fn, idle_fn, "")
> > +#define EXPORT_GPL_RUNTIME_DEV_PM_OPS(name, suspend_fn, resume_fn, idle_fn) \
> > +	_EXPORT_DEV_PM_OPS(name, pm_runtime_force_suspend, pm_runtime_force_resume, \
> > +			   suspend_fn, resume_fn, idle_fn, "_gpl")
> > +
> >  #ifdef CONFIG_PM
> >  extern struct workqueue_struct *pm_wq;
> >    
> 


^ permalink raw reply

* [PATCH] MAINTAINERS: Improve the PowerPC machines section
From: Thomas Huth @ 2022-01-05 10:48 UTC (permalink / raw)
  To: Daniel Henrique Barboza, Cédric Le Goater, qemu-devel
  Cc: Mark Cave-Ayland, Hervé Poussineau, qemu-ppc, Greg Kurz,
	David Gibson

Add some documentation files to the corresponding machine sections
and mention the machine names in the section titles where it is
not so obvious (e.g. that "taihu" is a 405 machine).

Signed-off-by: Thomas Huth <thuth@redhat.com>
---
 MAINTAINERS | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index f871d759fd..53cf0fdc00 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1245,7 +1245,7 @@ F: hw/openrisc/openrisc_sim.c
 
 PowerPC Machines
 ----------------
-405
+405 (ref405ep and taihu)
 L: qemu-ppc@nongnu.org
 S: Orphan
 F: hw/ppc/ppc405_boards.c
@@ -1281,6 +1281,7 @@ New World (mac99)
 M: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
 L: qemu-ppc@nongnu.org
 S: Odd Fixes
+F: docs/system/ppc/powermac.rst
 F: hw/ppc/mac_newworld.c
 F: hw/pci-host/uninorth.c
 F: hw/pci-bridge/dec.[hc]
@@ -1299,6 +1300,7 @@ Old World (g3beige)
 M: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
 L: qemu-ppc@nongnu.org
 S: Odd Fixes
+F: docs/system/ppc/powermac.rst
 F: hw/ppc/mac_oldworld.c
 F: hw/pci-host/grackle.c
 F: hw/misc/macio/
@@ -1312,6 +1314,7 @@ PReP
 M: Hervé Poussineau <hpoussin@reactos.org>
 L: qemu-ppc@nongnu.org
 S: Maintained
+F: docs/system/ppc/prep.rst
 F: hw/ppc/prep.c
 F: hw/ppc/prep_systemio.c
 F: hw/ppc/rs6000_mc.c
@@ -1324,7 +1327,7 @@ F: include/hw/isa/pc87312.h
 F: include/hw/rtc/m48t59.h
 F: tests/avocado/ppc_prep_40p.py
 
-sPAPR
+sPAPR (pseries)
 M: Cédric Le Goater <clg@kaod.org>
 M: Daniel Henrique Barboza <danielhb413@gmail.com>
 R: David Gibson <david@gibson.dropbear.id.au>
@@ -1336,8 +1339,8 @@ F: include/hw/*/spapr*
 F: hw/*/xics*
 F: include/hw/*/xics*
 F: pc-bios/slof.bin
-F: docs/specs/ppc-spapr-hcalls.txt
-F: docs/specs/ppc-spapr-hotplug.txt
+F: docs/system/ppc/pseries.rst
+F: docs/specs/ppc-spapr-*
 F: tests/qtest/spapr*
 F: tests/qtest/libqos/*spapr*
 F: tests/qtest/rtas*
@@ -1348,6 +1351,7 @@ PowerNV (Non-Virtualized)
 M: Cédric Le Goater <clg@kaod.org>
 L: qemu-ppc@nongnu.org
 S: Maintained
+F: docs/system/ppc/powernv.rst
 F: hw/ppc/pnv*
 F: hw/intc/pnv*
 F: hw/intc/xics_pnv.c
-- 
2.27.0



^ permalink raw reply related

* Re: linux-next: Fixes tags need some work in the watchdog tree
From: Wim Van Sebroeck @ 2022-01-05 10:43 UTC (permalink / raw)
  To: Andrej Picej
  Cc: Stephen Rothwell, Sam Protsenko, Linux Kernel Mailing List,
	Linux Next Mailing List
In-Reply-To: <432b6c61-f8c6-368d-2386-590bed2aee7a@norik.com>

Hi All,

> Hi Stephan,
> 
> On 3. 01. 22 22:36, Stephen Rothwell wrote:
> >Hi all,
> >
> >In commit
> >
> >   02d04e694fa3 ("watchdog: s3c2410: Fix getting the optional clock")
> >
> >Fixes tag
> >
> >   Fixes: a4f3dc8d5fbc ("watchdog: s3c2410: Support separate source clock")
> >
> >has these problem(s):
> >
> >   - Target SHA1 does not exist
> >
> >Maybe you meant
> >
> >Fixes: e249d01b5e8b ("watchdog: s3c2410: Support separate source clock")
> >
> >In commit
> >
> >   ce3401c72f01 ("watchdog: da9063: Add hard dependency on I2C")
> >
> >Fixes tag
> >
> >   Fixes: 5ea29919c294 ("watchdog: da9063: use atomic safe i2c transfer in reset handler")
> >
> >has these problem(s):
> >
> >   - Target SHA1 does not exist
> >
> >Maybe you meant
> >
> >Fixes: 968011a291f3 ("watchdog: da9063: use atomic safe i2c transfer in reset handler")
> >
> 
> Yes, that's probably right for my patch, sorry for that.
> 
> I was puzzled on where to get the SHA1 of not-yet applied commit,
> because this patches ("watchdog: da9063: use atomic safe i2c
> transfer in reset handler" and the fix "watchdog: da9063: Add hard
> dependency on I2C") followed quite closely together. Is there any
> way that I can get the SHA1 of the commit that was applied? It
> should be a part of some branch right? I'm asking because I couldn't
> find a repo or a branch that this two commits are a part of.
> 
> Anyway should I send a v2, or what is the procedure here?

I'll fix that.

Kind reards,
Wim.


^ permalink raw reply

* Re: [PATCH 2/4] coresight: trbe: Work around the ignored system register writes
From: Anshuman Khandual @ 2022-01-05 10:51 UTC (permalink / raw)
  To: Suzuki K Poulose, linux-arm-kernel
  Cc: Catalin Marinas, Will Deacon, Mathieu Poirier, coresight,
	linux-doc, linux-kernel
In-Reply-To: <0020da84-ce90-f269-27e1-6a6c90f6317b@arm.com>


On 1/5/22 3:31 PM, Suzuki K Poulose wrote:
> Hi Anshuman
> 
> On 05/01/2022 05:05, Anshuman Khandual wrote:
>> TRBE implementations affected by Arm erratum #2064142 might fail to write
>> into certain system registers after the TRBE has been disabled. Under some
>> conditions after TRBE has been disabled, writes into certain TRBE registers
>> TRBLIMITR_EL1, TRBPTR_EL1, TRBBASER_EL1, TRBSR_EL1 and TRBTRG_EL1 will be
>> ignored and not be effected.
>>
>> Work around this problem in the TRBE driver by executing TSB CSYNC and DSB
>> just after the trace collection has stopped and before performing a system
>> register write to one of the affected registers. This adds a new cpu errata
>> in arm64 errata framework and also updates TRBE driver as required.
>>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will@kernel.org>
>> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
>> Cc: Suzuki Poulose <suzuki.poulose@arm.com>
>> Cc: coresight@lists.linaro.org
>> Cc: linux-doc@vger.kernel.org
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>>   Documentation/arm64/silicon-errata.rst       |  2 +
>>   arch/arm64/Kconfig                           | 18 +++++++
>>   arch/arm64/kernel/cpu_errata.c               |  9 ++++
>>   arch/arm64/tools/cpucaps                     |  1 +
>>   drivers/hwtracing/coresight/coresight-trbe.c | 54 ++++++++++++++------
>>   drivers/hwtracing/coresight/coresight-trbe.h |  8 ---
>>   6 files changed, 68 insertions(+), 24 deletions(-)
> 
> I think it may be a good idea to split the patch into
> two parts :
> 
> - arm64 kernel part. (cpucap defintions and detection)
> - trbe driver part
> 
> So that it is easier to merge these series upstream to
> avoid conflicts.

Sure, will do.

> 
>>
>> diff --git a/Documentation/arm64/silicon-errata.rst b/Documentation/arm64/silicon-errata.rst
>> index 5342e895fb60..c9b30e6c2b6c 100644
>> --- a/Documentation/arm64/silicon-errata.rst
>> +++ b/Documentation/arm64/silicon-errata.rst
>> @@ -52,6 +52,8 @@ stable kernels.
>>   | Allwinner      | A64/R18         | UNKNOWN1        | SUN50I_ERRATUM_UNKNOWN1     |
>>   +----------------+-----------------+-----------------+-----------------------------+
>>   +----------------+-----------------+-----------------+-----------------------------+
>> +| ARM            | Cortex-A510     | #2064142        | ARM64_ERRATUM_2064142       |
>> ++----------------+-----------------+-----------------+-----------------------------+
>>   | ARM            | Cortex-A53      | #826319         | ARM64_ERRATUM_826319        |
>>   +----------------+-----------------+-----------------+-----------------------------+
>>   | ARM            | Cortex-A53      | #827319         | ARM64_ERRATUM_827319        |
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index c4207cf9bb17..2105b68d88db 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -778,6 +778,24 @@ config ARM64_ERRATUM_2224489
>>           If unsure, say Y.
>>   +config ARM64_ERRATUM_2064142
>> +    bool "Cortex-A510: 2064142: workaround TRBE register writes while disabled"
>> +    depends on CORESIGHT_TRBE
>> +    default y
>> +    help
>> +      This option adds the workaround for ARM Cortex-A510 erratum 2064142.
>> +
>> +      Affected Cortex-A510 core might fail to write into system registers after the
>> +      TRBE has been disabled. Under some conditions after the TRBE has been disabled
>> +      writes into TRBE registers TRBLIMITR_EL1, TRBPTR_EL1, TRBBASER_EL1, TRBSR_EL1,
>> +      and TRBTRG_EL1 will be ignored and will not be effected.
>> +
>> +      Work around this in the driver by executing TSB CSYNC and DSB after collection
>> +      is stopped and before performing a system register write to one of the affected
>> +      registers.
>> +
>> +      If unsure, say Y.
>> +
>>   config CAVIUM_ERRATUM_22375
>>       bool "Cavium erratum 22375, 24313"
>>       default y
>> diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
>> index 9e1c1aef9ebd..cbb7d5a9aee7 100644
>> --- a/arch/arm64/kernel/cpu_errata.c
>> +++ b/arch/arm64/kernel/cpu_errata.c
>> @@ -597,6 +597,15 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
>>           .type = ARM64_CPUCAP_WEAK_LOCAL_CPU_FEATURE,
>>           CAP_MIDR_RANGE_LIST(trbe_write_out_of_range_cpus),
>>       },
>> +#endif
>> +#ifdef CONFIG_ARM64_ERRATUM_2064142
>> +    {
>> +        .desc = "ARM erratum 2064142",
>> +        .capability = ARM64_WORKAROUND_2064142,
>> +
>> +        /* Cortex-A510 r0p0 - r0p2 */
>> +        ERRATA_MIDR_REV_RANGE(MIDR_CORTEX_A510, 0, 0, 2)
>> +    },
>>   #endif
>>       {
>>       }
>> diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
>> index 870c39537dd0..fca3cb329e1d 100644
>> --- a/arch/arm64/tools/cpucaps
>> +++ b/arch/arm64/tools/cpucaps
>> @@ -55,6 +55,7 @@ WORKAROUND_1418040
>>   WORKAROUND_1463225
>>   WORKAROUND_1508412
>>   WORKAROUND_1542419
>> +WORKAROUND_2064142
>>   WORKAROUND_TRBE_OVERWRITE_FILL_MODE
>>   WORKAROUND_TSB_FLUSH_FAILURE
>>   WORKAROUND_TRBE_WRITE_OUT_OF_RANGE
>> diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c
>> index 276862c07e32..ec24b62b2cec 100644
>> --- a/drivers/hwtracing/coresight/coresight-trbe.c
>> +++ b/drivers/hwtracing/coresight/coresight-trbe.c
>> @@ -91,10 +91,12 @@ struct trbe_buf {
>>    */
>>   #define TRBE_WORKAROUND_OVERWRITE_FILL_MODE    0
>>   #define TRBE_WORKAROUND_WRITE_OUT_OF_RANGE    1
>> +#define TRBE_WORKAROUND_SYSREG_WRITE_FAILURE    2
>>     static int trbe_errata_cpucaps[] = {
>>       [TRBE_WORKAROUND_OVERWRITE_FILL_MODE] = ARM64_WORKAROUND_TRBE_OVERWRITE_FILL_MODE,
>>       [TRBE_WORKAROUND_WRITE_OUT_OF_RANGE] = ARM64_WORKAROUND_TRBE_WRITE_OUT_OF_RANGE,
>> +    [TRBE_WORKAROUND_SYSREG_WRITE_FAILURE] = ARM64_WORKAROUND_2064142,
> 
> super minor nit: TRBE_NEEDS_DRAIN_AFTER_DISABLE
>>>       -1,        /* Sentinel, must be the last entry */
>>   };
>>   @@ -167,6 +169,11 @@ static inline bool trbe_may_write_out_of_range(struct trbe_cpudata *cpudata)
>>       return trbe_has_erratum(cpudata, TRBE_WORKAROUND_WRITE_OUT_OF_RANGE);
>>   }
>>   +static inline bool trbe_may_fail_sysreg_write(struct trbe_cpudata *cpudata)
>> +{
> 
> minor nit: trbe_needs_drain_after_disable() ?

Changing this helper name and its index above would reflect actual
workaround implemented, instead of the errata which it is trying
to solve. Although the series has already broken that convention
in the last patch with trbe_is_broken() and TRBE_IS_BROKEN. If we
are going with TRBE_<work around required> format, I will have to
change the next workaround patch as well.

> 
> Either ways, the patch looks good to me.> 
> Suzuki

^ permalink raw reply

* Re: [PATCH v2 48/51] iio:dac:m62332: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr() etc
From: Jonathan Cameron @ 2022-01-05 10:52 UTC (permalink / raw)
  To: Jonathan Cameron
  Cc: linux-iio, Paul Cercueil, Arnd Bergmann, Rafael J . Wysocki,
	Gwendal Grignou
In-Reply-To: <20220102125617.1259804-49-jic23@kernel.org>

On Sun,  2 Jan 2022 12:56:14 +0000
Jonathan Cameron <jic23@kernel.org> wrote:

> From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> 
> Letting the compiler remove these functions when the kernel is built
> without CONFIG_PM_SLEEP support is simpler and less error prone than the
> use of #ifdef based config guards.
> 
> Removing instances of this approach from IIO also stops them being
> copied into new drivers.
> 
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

I missed that there were some CONFIG_PM guards around iio_priv()->save
that also need dropping.  Will do that in v3.

Jonathan

> ---
>  drivers/iio/dac/m62332.c | 9 ++-------
>  1 file changed, 2 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/iio/dac/m62332.c b/drivers/iio/dac/m62332.c
> index 225b1a374dc1..4a413936fabb 100644
> --- a/drivers/iio/dac/m62332.c
> +++ b/drivers/iio/dac/m62332.c
> @@ -124,7 +124,6 @@ static int m62332_write_raw(struct iio_dev *indio_dev,
>  	return -EINVAL;
>  }
>  
> -#ifdef CONFIG_PM_SLEEP
>  static int m62332_suspend(struct device *dev)
>  {
>  	struct i2c_client *client = to_i2c_client(dev);
> @@ -156,11 +155,7 @@ static int m62332_resume(struct device *dev)
>  	return m62332_set_value(indio_dev, data->save[1], 1);
>  }
>  
> -static SIMPLE_DEV_PM_OPS(m62332_pm_ops, m62332_suspend, m62332_resume);
> -#define M62332_PM_OPS (&m62332_pm_ops)
> -#else
> -#define M62332_PM_OPS NULL
> -#endif
> +DEFINE_SIMPLE_DEV_PM_OPS(m62332_pm_ops, m62332_suspend, m62332_resume);
>  
>  static const struct iio_info m62332_info = {
>  	.read_raw = m62332_read_raw,
> @@ -246,7 +241,7 @@ MODULE_DEVICE_TABLE(i2c, m62332_id);
>  static struct i2c_driver m62332_driver = {
>  	.driver = {
>  		.name	= "m62332",
> -		.pm	= M62332_PM_OPS,
> +		.pm	= pm_sleep_ptr(&m62332_pm_ops),
>  	},
>  	.probe		= m62332_probe,
>  	.remove		= m62332_remove,


^ permalink raw reply

* Re: [PATCHv2] Documentation: kgdb: Replace deprecated remotebaud
From: Daniel Thompson @ 2022-01-05 10:52 UTC (permalink / raw)
  To: Christian Löhle
  Cc: jason.wessel@windriver.com, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, dianders@chromium.org,
	corbet@lwn.net
In-Reply-To: <4050689967ed46baaa3bfadda53a0e73@hyperstone.com>

On Wed, Jan 05, 2022 at 09:58:38AM +0000, Christian Löhle wrote:
> Using set remotebaud to set the baud rate was deprecated in
> gdb-7.7 and completely removed from the command parser in gdb-7.8
> (released in 2014). Adopt set serial baud instead.
> 
> Signed-off-by: Christian Loehle <cloehle@hyperstone.com>

Thanks for the update.

Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>


Daniel.

PS No need to worry about it this time around but, for future
   reference, if someone provides you one of the tags
   (Reviewed-By, Acked-By, etc) during a review cycle then you are
   normally expected to collect this and add them to tags section when
   you share the next version of the patch or, if there are big
   technical changes that make you choose to view the tag as
   out-of-date then drop the tag but mention why in the patch
   changelog.


> ---
>  Documentation/dev-tools/kgdb.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/dev-tools/kgdb.rst b/Documentation/dev-tools/kgdb.rst
> index 43456244651a..7c90e111b364 100644
> --- a/Documentation/dev-tools/kgdb.rst
> +++ b/Documentation/dev-tools/kgdb.rst
> @@ -557,7 +557,7 @@ Connecting with gdb to a serial port
>     Example (using a directly connected port)::
> 
>             % gdb ./vmlinux
> -           (gdb) set remotebaud 115200
> +           (gdb) set serial baud 115200
>             (gdb) target remote /dev/ttyS0
> 
> 
> --
> 2.34.1
> Hyperstone GmbH | Reichenaustr. 39a  | 78467 Konstanz
> Managing Director: Dr. Jan Peter Berns.
> Commercial register of local courts: Freiburg HRB381782
> 

^ permalink raw reply

* Re: [PATCH 2/4] coresight: trbe: Work around the ignored system register writes
From: Anshuman Khandual @ 2022-01-05 10:51 UTC (permalink / raw)
  To: Suzuki K Poulose, linux-arm-kernel
  Cc: Catalin Marinas, Will Deacon, Mathieu Poirier, coresight,
	linux-doc, linux-kernel
In-Reply-To: <0020da84-ce90-f269-27e1-6a6c90f6317b@arm.com>


On 1/5/22 3:31 PM, Suzuki K Poulose wrote:
> Hi Anshuman
> 
> On 05/01/2022 05:05, Anshuman Khandual wrote:
>> TRBE implementations affected by Arm erratum #2064142 might fail to write
>> into certain system registers after the TRBE has been disabled. Under some
>> conditions after TRBE has been disabled, writes into certain TRBE registers
>> TRBLIMITR_EL1, TRBPTR_EL1, TRBBASER_EL1, TRBSR_EL1 and TRBTRG_EL1 will be
>> ignored and not be effected.
>>
>> Work around this problem in the TRBE driver by executing TSB CSYNC and DSB
>> just after the trace collection has stopped and before performing a system
>> register write to one of the affected registers. This adds a new cpu errata
>> in arm64 errata framework and also updates TRBE driver as required.
>>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will@kernel.org>
>> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
>> Cc: Suzuki Poulose <suzuki.poulose@arm.com>
>> Cc: coresight@lists.linaro.org
>> Cc: linux-doc@vger.kernel.org
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>>   Documentation/arm64/silicon-errata.rst       |  2 +
>>   arch/arm64/Kconfig                           | 18 +++++++
>>   arch/arm64/kernel/cpu_errata.c               |  9 ++++
>>   arch/arm64/tools/cpucaps                     |  1 +
>>   drivers/hwtracing/coresight/coresight-trbe.c | 54 ++++++++++++++------
>>   drivers/hwtracing/coresight/coresight-trbe.h |  8 ---
>>   6 files changed, 68 insertions(+), 24 deletions(-)
> 
> I think it may be a good idea to split the patch into
> two parts :
> 
> - arm64 kernel part. (cpucap defintions and detection)
> - trbe driver part
> 
> So that it is easier to merge these series upstream to
> avoid conflicts.

Sure, will do.

> 
>>
>> diff --git a/Documentation/arm64/silicon-errata.rst b/Documentation/arm64/silicon-errata.rst
>> index 5342e895fb60..c9b30e6c2b6c 100644
>> --- a/Documentation/arm64/silicon-errata.rst
>> +++ b/Documentation/arm64/silicon-errata.rst
>> @@ -52,6 +52,8 @@ stable kernels.
>>   | Allwinner      | A64/R18         | UNKNOWN1        | SUN50I_ERRATUM_UNKNOWN1     |
>>   +----------------+-----------------+-----------------+-----------------------------+
>>   +----------------+-----------------+-----------------+-----------------------------+
>> +| ARM            | Cortex-A510     | #2064142        | ARM64_ERRATUM_2064142       |
>> ++----------------+-----------------+-----------------+-----------------------------+
>>   | ARM            | Cortex-A53      | #826319         | ARM64_ERRATUM_826319        |
>>   +----------------+-----------------+-----------------+-----------------------------+
>>   | ARM            | Cortex-A53      | #827319         | ARM64_ERRATUM_827319        |
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index c4207cf9bb17..2105b68d88db 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -778,6 +778,24 @@ config ARM64_ERRATUM_2224489
>>           If unsure, say Y.
>>   +config ARM64_ERRATUM_2064142
>> +    bool "Cortex-A510: 2064142: workaround TRBE register writes while disabled"
>> +    depends on CORESIGHT_TRBE
>> +    default y
>> +    help
>> +      This option adds the workaround for ARM Cortex-A510 erratum 2064142.
>> +
>> +      Affected Cortex-A510 core might fail to write into system registers after the
>> +      TRBE has been disabled. Under some conditions after the TRBE has been disabled
>> +      writes into TRBE registers TRBLIMITR_EL1, TRBPTR_EL1, TRBBASER_EL1, TRBSR_EL1,
>> +      and TRBTRG_EL1 will be ignored and will not be effected.
>> +
>> +      Work around this in the driver by executing TSB CSYNC and DSB after collection
>> +      is stopped and before performing a system register write to one of the affected
>> +      registers.
>> +
>> +      If unsure, say Y.
>> +
>>   config CAVIUM_ERRATUM_22375
>>       bool "Cavium erratum 22375, 24313"
>>       default y
>> diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
>> index 9e1c1aef9ebd..cbb7d5a9aee7 100644
>> --- a/arch/arm64/kernel/cpu_errata.c
>> +++ b/arch/arm64/kernel/cpu_errata.c
>> @@ -597,6 +597,15 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
>>           .type = ARM64_CPUCAP_WEAK_LOCAL_CPU_FEATURE,
>>           CAP_MIDR_RANGE_LIST(trbe_write_out_of_range_cpus),
>>       },
>> +#endif
>> +#ifdef CONFIG_ARM64_ERRATUM_2064142
>> +    {
>> +        .desc = "ARM erratum 2064142",
>> +        .capability = ARM64_WORKAROUND_2064142,
>> +
>> +        /* Cortex-A510 r0p0 - r0p2 */
>> +        ERRATA_MIDR_REV_RANGE(MIDR_CORTEX_A510, 0, 0, 2)
>> +    },
>>   #endif
>>       {
>>       }
>> diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
>> index 870c39537dd0..fca3cb329e1d 100644
>> --- a/arch/arm64/tools/cpucaps
>> +++ b/arch/arm64/tools/cpucaps
>> @@ -55,6 +55,7 @@ WORKAROUND_1418040
>>   WORKAROUND_1463225
>>   WORKAROUND_1508412
>>   WORKAROUND_1542419
>> +WORKAROUND_2064142
>>   WORKAROUND_TRBE_OVERWRITE_FILL_MODE
>>   WORKAROUND_TSB_FLUSH_FAILURE
>>   WORKAROUND_TRBE_WRITE_OUT_OF_RANGE
>> diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c
>> index 276862c07e32..ec24b62b2cec 100644
>> --- a/drivers/hwtracing/coresight/coresight-trbe.c
>> +++ b/drivers/hwtracing/coresight/coresight-trbe.c
>> @@ -91,10 +91,12 @@ struct trbe_buf {
>>    */
>>   #define TRBE_WORKAROUND_OVERWRITE_FILL_MODE    0
>>   #define TRBE_WORKAROUND_WRITE_OUT_OF_RANGE    1
>> +#define TRBE_WORKAROUND_SYSREG_WRITE_FAILURE    2
>>     static int trbe_errata_cpucaps[] = {
>>       [TRBE_WORKAROUND_OVERWRITE_FILL_MODE] = ARM64_WORKAROUND_TRBE_OVERWRITE_FILL_MODE,
>>       [TRBE_WORKAROUND_WRITE_OUT_OF_RANGE] = ARM64_WORKAROUND_TRBE_WRITE_OUT_OF_RANGE,
>> +    [TRBE_WORKAROUND_SYSREG_WRITE_FAILURE] = ARM64_WORKAROUND_2064142,
> 
> super minor nit: TRBE_NEEDS_DRAIN_AFTER_DISABLE
>>>       -1,        /* Sentinel, must be the last entry */
>>   };
>>   @@ -167,6 +169,11 @@ static inline bool trbe_may_write_out_of_range(struct trbe_cpudata *cpudata)
>>       return trbe_has_erratum(cpudata, TRBE_WORKAROUND_WRITE_OUT_OF_RANGE);
>>   }
>>   +static inline bool trbe_may_fail_sysreg_write(struct trbe_cpudata *cpudata)
>> +{
> 
> minor nit: trbe_needs_drain_after_disable() ?

Changing this helper name and its index above would reflect actual
workaround implemented, instead of the errata which it is trying
to solve. Although the series has already broken that convention
in the last patch with trbe_is_broken() and TRBE_IS_BROKEN. If we
are going with TRBE_<work around required> format, I will have to
change the next workaround patch as well.

> 
> Either ways, the patch looks good to me.> 
> Suzuki

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v6 0/9] Multigenerational LRU Framework
From: Yu Zhao @ 2022-01-05 10:53 UTC (permalink / raw)
  To: SeongJae Park
  Cc: Andrew Morton, Linus Torvalds, Andi Kleen, Catalin Marinas,
	Dave Hansen, Hillf Danton, Jens Axboe, Jesse Barnes,
	Johannes Weiner, Jonathan Corbet, Matthew Wilcox, Mel Gorman,
	Michael Larabel, Michal Hocko, Rik van Riel, Vlastimil Babka,
	Will Deacon, Ying Huang, linux-arm-kernel, linux-doc,
	linux-kernel, linux-mm, page-reclaim, x86
In-Reply-To: <20220105085534.22981-1-sj@kernel.org>

On Wed, Jan 05, 2022 at 08:55:34AM +0000, SeongJae Park wrote:
> Hi Yu,
> 
> On Tue, 4 Jan 2022 13:22:19 -0700 Yu Zhao <yuzhao@google.com> wrote:
> 
> > TLDR
> > ====
> > The current page reclaim is too expensive in terms of CPU usage and it
> > often makes poor choices about what to evict. This patchset offers an
> > alternative solution that is performant, versatile and
> > straightforward.
> >  
> [...]
> > Summery
> > =======
> > The facts are:
> > 1. The independent lab results and the real-world applications
> >    indicate substantial improvements; there are no known regressions.
> 
> So impressive results!
> 
> > 2. Thrashing prevention, working set estimation and proactive reclaim
> >    work out of the box; there are no equivalent solutions.
> 
> I think similar works are already available out of the box with the latest
> mainline tree, though it might be suboptimal in some cases.

Ok, I will sound harsh because I hate it when people challenge facts
while having no idea what they are talking about.

Our jobs are help the leadership make best decisions by providing them
with facts, not feeding them crap.

Don't get me wrong -- you are welcome to start another thread and have
a casual discussion with me. But this thread is not for that; it's for
the leadership and stakeholder to make a decision. Check who are in
"To" and "Cc" and what my request is.

> I didn't read this patchset thoroughly yet, so I might missing many things.  If
> so, please feel free to let me know.

Yes, apparently you didn't read this patchset thoroughly, and you have
missed all things that matter to this thread.

> First, you can do thrashing prevention using DAMON-based Operation Scheme
> (DAMOS)[1] with MADV_COLD action.

Here is thrashing prevention really means, from patch 8:
  +Personal computers
  +------------------
  +:Thrashing prevention: Write ``N`` to
  + ``/sys/kernel/mm/lru_gen/min_ttl_ms`` to prevent the working set of
  + ``N`` milliseconds from getting evicted. The OOM killer is invoked if
  + this working set can't be kept in memory. Based on the average human
  + detectable lag (~100ms), ``N=1000`` usually eliminates intolerable
  + lags due to thrashing. Larger values like ``N=3000`` make lags less
  + noticeable at the cost of more OOM kills.

It's about when to trigger OOM kills. Got it? Or probably you don't
understand what MADV_COLD is either?

> Second, for working set estimation, you can either use the DAMOS
> again with statistics action, or the damon_aggregated tracepoint[2].

This is you are suggesting:
  TRACE_EVENT(damon_aggregated,
    TP_printk("target_id=%lu nr_regions=%u %lu-%lu: %u",
              __entry->target_id, __entry->nr_regions,
              __entry->start, __entry->end, __entry->nr_accesses)

Now read my doc again:
  +Data centers
  +------------
  +:Debugfs interface: ``/sys/kernel/debug/lru_gen`` has the following
  + format:
  +   memcg  memcg_id  memcg_path
  +     node  node_id

Have you heard of something called memcg? And NUMA node? How exactly
can this tracepoint provide information about different memcgs and
NUMA node?

> The DAMON user space tool[3] helps the tracepoint analysis and
> visualization.

What does "work out of box" mean? Should every Linux desktop, laptop
and phone user install this tool?

> Finally, for the proactive reclaim, you can again use the DAMOS
> with MADV_PAGEOUT action

How exactly does MADV_PAGEOUT find pages that are NOT mapped in page
tables? Let me tell you another fact: they are usually the cheapest to
reclaim.

> or simply the DAMON-based proactive reclaim module (DAMON_RECLAIM)[4].
> [4] https://docs.kernel.org/admin-guide/mm/damon/reclaim.html

How many knob does DAMON_RECLAIM have? 14? I lost count.

> Of course, the integration might not be so simple as seems to me now.

Look, I'm open to your suggestion. I probably should have been nicer.
So I'm sorry. I just don't appreciate alternative facts.

^ permalink raw reply

* Re: [PATCH v6 0/9] Multigenerational LRU Framework
From: Yu Zhao @ 2022-01-05 10:53 UTC (permalink / raw)
  To: SeongJae Park
  Cc: Andrew Morton, Linus Torvalds, Andi Kleen, Catalin Marinas,
	Dave Hansen, Hillf Danton, Jens Axboe, Jesse Barnes,
	Johannes Weiner, Jonathan Corbet, Matthew Wilcox, Mel Gorman,
	Michael Larabel, Michal Hocko, Rik van Riel, Vlastimil Babka,
	Will Deacon, Ying Huang, linux-arm-kernel, linux-doc,
	linux-kernel, linux-mm, page-reclaim, x86
In-Reply-To: <20220105085534.22981-1-sj@kernel.org>

On Wed, Jan 05, 2022 at 08:55:34AM +0000, SeongJae Park wrote:
> Hi Yu,
> 
> On Tue, 4 Jan 2022 13:22:19 -0700 Yu Zhao <yuzhao@google.com> wrote:
> 
> > TLDR
> > ====
> > The current page reclaim is too expensive in terms of CPU usage and it
> > often makes poor choices about what to evict. This patchset offers an
> > alternative solution that is performant, versatile and
> > straightforward.
> >  
> [...]
> > Summery
> > =======
> > The facts are:
> > 1. The independent lab results and the real-world applications
> >    indicate substantial improvements; there are no known regressions.
> 
> So impressive results!
> 
> > 2. Thrashing prevention, working set estimation and proactive reclaim
> >    work out of the box; there are no equivalent solutions.
> 
> I think similar works are already available out of the box with the latest
> mainline tree, though it might be suboptimal in some cases.

Ok, I will sound harsh because I hate it when people challenge facts
while having no idea what they are talking about.

Our jobs are help the leadership make best decisions by providing them
with facts, not feeding them crap.

Don't get me wrong -- you are welcome to start another thread and have
a casual discussion with me. But this thread is not for that; it's for
the leadership and stakeholder to make a decision. Check who are in
"To" and "Cc" and what my request is.

> I didn't read this patchset thoroughly yet, so I might missing many things.  If
> so, please feel free to let me know.

Yes, apparently you didn't read this patchset thoroughly, and you have
missed all things that matter to this thread.

> First, you can do thrashing prevention using DAMON-based Operation Scheme
> (DAMOS)[1] with MADV_COLD action.

Here is thrashing prevention really means, from patch 8:
  +Personal computers
  +------------------
  +:Thrashing prevention: Write ``N`` to
  + ``/sys/kernel/mm/lru_gen/min_ttl_ms`` to prevent the working set of
  + ``N`` milliseconds from getting evicted. The OOM killer is invoked if
  + this working set can't be kept in memory. Based on the average human
  + detectable lag (~100ms), ``N=1000`` usually eliminates intolerable
  + lags due to thrashing. Larger values like ``N=3000`` make lags less
  + noticeable at the cost of more OOM kills.

It's about when to trigger OOM kills. Got it? Or probably you don't
understand what MADV_COLD is either?

> Second, for working set estimation, you can either use the DAMOS
> again with statistics action, or the damon_aggregated tracepoint[2].

This is you are suggesting:
  TRACE_EVENT(damon_aggregated,
    TP_printk("target_id=%lu nr_regions=%u %lu-%lu: %u",
              __entry->target_id, __entry->nr_regions,
              __entry->start, __entry->end, __entry->nr_accesses)

Now read my doc again:
  +Data centers
  +------------
  +:Debugfs interface: ``/sys/kernel/debug/lru_gen`` has the following
  + format:
  +   memcg  memcg_id  memcg_path
  +     node  node_id

Have you heard of something called memcg? And NUMA node? How exactly
can this tracepoint provide information about different memcgs and
NUMA node?

> The DAMON user space tool[3] helps the tracepoint analysis and
> visualization.

What does "work out of box" mean? Should every Linux desktop, laptop
and phone user install this tool?

> Finally, for the proactive reclaim, you can again use the DAMOS
> with MADV_PAGEOUT action

How exactly does MADV_PAGEOUT find pages that are NOT mapped in page
tables? Let me tell you another fact: they are usually the cheapest to
reclaim.

> or simply the DAMON-based proactive reclaim module (DAMON_RECLAIM)[4].
> [4] https://docs.kernel.org/admin-guide/mm/damon/reclaim.html

How many knob does DAMON_RECLAIM have? 14? I lost count.

> Of course, the integration might not be so simple as seems to me now.

Look, I'm open to your suggestion. I probably should have been nicer.
So I'm sorry. I just don't appreciate alternative facts.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v2 2/5] KVM: SVM: allow to force AVIC to be enabled
From: Maxim Levitsky @ 2022-01-05 10:54 UTC (permalink / raw)
  To: Sean Christopherson
  Cc: kvm, Jim Mattson, Thomas Gleixner, Joerg Roedel,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT), Vitaly Kuznetsov,
	Borislav Petkov, linux-kernel, Paolo Bonzini, Dave Hansen,
	H. Peter Anvin, Wanpeng Li, Ingo Molnar
In-Reply-To: <YdTJPTSsM1feVwt/@google.com>

On Tue, 2022-01-04 at 22:25 +0000, Sean Christopherson wrote:
> On Mon, Dec 13, 2021, Maxim Levitsky wrote:
> > Apparently on some systems AVIC is disabled in CPUID but still usable.
> > 
> > Allow the user to override the CPUID if the user is willing to
> > take the risk.
> > 
> > Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
> > ---
> >  arch/x86/kvm/svm/svm.c | 11 +++++++++--
> >  1 file changed, 9 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> > index c9668a3b51011..468cc385c35f0 100644
> > --- a/arch/x86/kvm/svm/svm.c
> > +++ b/arch/x86/kvm/svm/svm.c
> > @@ -206,6 +206,9 @@ module_param(tsc_scaling, int, 0444);
> >  static bool avic;
> >  module_param(avic, bool, 0444);
> >  
> > +static bool force_avic;
> > +module_param_unsafe(force_avic, bool, 0444);
> > +
> >  bool __read_mostly dump_invalid_vmcb;
> >  module_param(dump_invalid_vmcb, bool, 0644);
> >  
> > @@ -4656,10 +4659,14 @@ static __init int svm_hardware_setup(void)
> >  			nrips = false;
> >  	}
> >  
> > -	enable_apicv = avic = avic && npt_enabled && boot_cpu_has(X86_FEATURE_AVIC);
> > +	enable_apicv = avic = avic && npt_enabled && (boot_cpu_has(X86_FEATURE_AVIC) || force_avic);
> >  
> >  	if (enable_apicv) {
> > -		pr_info("AVIC enabled\n");
> > +		if (!boot_cpu_has(X86_FEATURE_AVIC)) {
> > +			pr_warn("AVIC is not supported in CPUID but force enabled");
> > +			pr_warn("Your system might crash and burn");
> > +		} else
> 
> Needs curly braces, though arguably the "AVIC enabled" part should be printed
> regardless of boot_cpu_has(X86_FEATURE_AVIC).
> 
> > +			pr_info("AVIC enabled\n");
> 
> This is all more than a bit terrifying, though I can see the usefuless for a
> developer.  At the very least, this should taint the kernel.  This should also
> probably be buried behind a Kconfig that is itself buried behind EXPERT.
> 
I used 'module_param_unsafe' which does taint the kernel.

Best regards,
	Maxim Levitsky


^ permalink raw reply

* [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: move i915_reg_read_ioctl declaration to intel_uncore.h
From: Patchwork @ 2022-01-05 10:55 UTC (permalink / raw)
  To: Jani Nikula; +Cc: intel-gfx
In-Reply-To: <20220105100520.976092-1-jani.nikula@intel.com>

[-- Attachment #1: Type: text/plain, Size: 6818 bytes --]

== Series Details ==

Series: series starting with [1/2] drm/i915: move i915_reg_read_ioctl declaration to intel_uncore.h
URL   : https://patchwork.freedesktop.org/series/98499/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11047 -> Patchwork_21925
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/index.html

Participating hosts (48 -> 37)
------------------------------

  Additional (2): fi-kbl-soraka fi-icl-u2 
  Missing    (13): fi-ilk-m540 bat-dg1-6 bat-dg1-5 fi-hsw-4200u fi-bsw-cyan bat-adlp-6 bat-adlp-4 fi-ctg-p8600 fi-pnv-d510 bat-rpls-1 fi-bdw-samus bat-jsl-2 bat-jsl-1 

Known issues
------------

  Here are the changes found in Patchwork_21925 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@amdgpu/amd_cs_nop@fork-gfx0:
    - fi-icl-u2:          NOTRUN -> [SKIP][1] ([fdo#109315]) +17 similar issues
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/fi-icl-u2/igt@amdgpu/amd_cs_nop@fork-gfx0.html

  * igt@gem_exec_fence@basic-busy@bcs0:
    - fi-kbl-soraka:      NOTRUN -> [SKIP][2] ([fdo#109271]) +16 similar issues
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/fi-kbl-soraka/igt@gem_exec_fence@basic-busy@bcs0.html

  * igt@gem_huc_copy@huc-copy:
    - fi-kbl-soraka:      NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/fi-kbl-soraka/igt@gem_huc_copy@huc-copy.html
    - fi-icl-u2:          NOTRUN -> [SKIP][4] ([i915#2190])
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/fi-icl-u2/igt@gem_huc_copy@huc-copy.html

  * igt@gem_lmem_swapping@basic:
    - fi-kbl-soraka:      NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613]) +3 similar issues
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/fi-kbl-soraka/igt@gem_lmem_swapping@basic.html

  * igt@gem_lmem_swapping@parallel-random-engines:
    - fi-icl-u2:          NOTRUN -> [SKIP][6] ([i915#4613]) +3 similar issues
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/fi-icl-u2/igt@gem_lmem_swapping@parallel-random-engines.html

  * igt@i915_selftest@live@gt_pm:
    - fi-kbl-soraka:      NOTRUN -> [DMESG-FAIL][7] ([i915#1886] / [i915#2291])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

  * igt@kms_chamelium@common-hpd-after-suspend:
    - fi-kbl-soraka:      NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +8 similar issues
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/fi-kbl-soraka/igt@kms_chamelium@common-hpd-after-suspend.html

  * igt@kms_chamelium@hdmi-hpd-fast:
    - fi-icl-u2:          NOTRUN -> [SKIP][9] ([fdo#111827]) +8 similar issues
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/fi-icl-u2/igt@kms_chamelium@hdmi-hpd-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
    - fi-icl-u2:          NOTRUN -> [SKIP][10] ([fdo#109278]) +2 similar issues
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/fi-icl-u2/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_force_connector_basic@force-load-detect:
    - fi-icl-u2:          NOTRUN -> [SKIP][11] ([fdo#109285])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/fi-icl-u2/igt@kms_force_connector_basic@force-load-detect.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
    - fi-kbl-soraka:      NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#533])
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/fi-kbl-soraka/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d.html

  * igt@kms_psr@primary_page_flip:
    - fi-skl-6600u:       [PASS][13] -> [FAIL][14] ([i915#4547])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/fi-skl-6600u/igt@kms_psr@primary_page_flip.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/fi-skl-6600u/igt@kms_psr@primary_page_flip.html

  * igt@prime_vgem@basic-userptr:
    - fi-icl-u2:          NOTRUN -> [SKIP][15] ([i915#3301])
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/fi-icl-u2/igt@prime_vgem@basic-userptr.html

  
#### Possible fixes ####

  * igt@kms_frontbuffer_tracking@basic:
    - fi-cml-u2:          [DMESG-WARN][16] ([i915#4269]) -> [PASS][17]
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/fi-cml-u2/igt@kms_frontbuffer_tracking@basic.html
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/fi-cml-u2/igt@kms_frontbuffer_tracking@basic.html

  
#### Warnings ####

  * igt@runner@aborted:
    - fi-skl-6600u:       [FAIL][18] ([i915#1436] / [i915#2722] / [i915#4312]) -> [FAIL][19] ([i915#4312])
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11047/fi-skl-6600u/igt@runner@aborted.html
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/fi-skl-6600u/igt@runner@aborted.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291
  [i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#4269]: https://gitlab.freedesktop.org/drm/intel/issues/4269
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533


Build changes
-------------

  * Linux: CI_DRM_11047 -> Patchwork_21925

  CI-20190529: 20190529
  CI_DRM_11047: f50e5d7abd1873b3488081da88dc8412584280b9 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6323: 9dbaa0d5be7a859cda9b7d54c20ba96a596f43bd @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21925: f152d466ca818a4104916fec78e7c293d64cb27f @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

f152d466ca81 drm/i915/uncore: rename i915_reg_read_ioctl intel_uncore_reg_read_ioctl
341fc6f92a0f drm/i915: move i915_reg_read_ioctl declaration to intel_uncore.h

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21925/index.html

[-- Attachment #2: Type: text/html, Size: 8333 bytes --]

^ permalink raw reply

* Re: [PATCH v2 02/11] usb: gadget: u_audio: Support multiple sampling rates
From: Pavel Hofman @ 2022-01-05 10:55 UTC (permalink / raw)
  To: John Keeping
  Cc: linux-usb, Ruslan Bilovol, Jerome Brunet, Julian Scheel,
	Greg Kroah-Hartman
In-Reply-To: <YdRopd4BfUM9ZtbX@donbot>



Dne 04. 01. 22 v 16:32 John Keeping napsal(a):
> On Wed, Dec 22, 2021 at 08:13:01AM +0100, Pavel Hofman wrote:
>> Dne 21. 12. 21 v 12:35 John Keeping napsal(a):
>>> On Mon, Dec 20, 2021 at 10:11:21PM +0100, Pavel Hofman wrote:
>>>> From: Julian Scheel <julian@jusst.de>
>>>>
>>>> Implement support for multiple sampling rates in u_audio part of the
>>>> audio gadget. The currently configured rates are exposed through
>>>> read-only amixer controls 'Capture Rate' and 'Playback Rate'.
>>>>
>>>> Signed-off-by: Julian Scheel <julian@jusst.de>
>>>> Signed-off-by: Pavel Hofman <pavel.hofman@ivitera.com>
>>>> ---
>>>
>>>> diff --git a/drivers/usb/gadget/function/uac_common.h b/drivers/usb/gadget/function/uac_common.h
>>>> new file mode 100644
>>>> index 000000000000..3ecf89d6e814
>>>> --- /dev/null
>>>> +++ b/drivers/usb/gadget/function/uac_common.h
>>>> @@ -0,0 +1,9 @@
>>>> +/* SPDX-License-Identifier: GPL-2.0+ */
>>>> +/*
>>>> + */
>>>> +
>>>> +#ifndef UAC_COMMON_H
>>>> +#define UAC_COMMON_H
>>>> +
>>>> +#define UAC_MAX_RATES 10 /* maximum number of rates configurable by f_uac1/2 */
>>>
>>> Why a new header for this - doesn't it belong in u_audio.h?
>>
>> The constant is used in subsequent patches in f_uac1.c, f_uac2.c, their
>> headers u_uac1.h, u_uac2.h, and legacy/audio.c (which already includes
>> u_uac1.h/u_uac2.h as needed). Since all occurences must use the same value,
>> I did not know how to solve this without introducing a common header file,
>> included in the existing headers u_audio.h, u_uac1.h, u_uac2.h. If there is
>> a better way, I will be happy to use it, I do not like the extra common
>> header file either. Thanks a lot for your help.
> 
> Ah, right - I hadn't accounted for UAC1.
> 
> Do you think anyone is using UAC1 these days?  I wonder if it makes
> sense to just drop those changes and focus on UAC2.
> 

I have no problem with dropping the UAC1 support from my current 
patches. That fact is UAC2 will likely receive further features and 
porting to UAC1 and testing takes effort. I have no need for UAC1, but 
its future course is not for me to decide :-)

Any opinion from UAC1 users?

Thanks,

Pavel.

^ permalink raw reply

* Re: [PATCH] ALSA: hda/realtek: Add quirk for Legion Y9000X 2020
From: Greg Kroah-Hartman @ 2022-01-05 10:55 UTC (permalink / raw)
  To: Takashi Iwai
  Cc: Baole Fang, Jaroslav Kysela, Takashi Iwai, Jeremy Szu,
	Werner Sembach, Hui Wang, Cameron Berkenpas, Kailang Yang,
	Sami Loone, Elia Devito, alsa-devel, linux-kernel
In-Reply-To: <s5ha6gak2qf.wl-tiwai@suse.de>

On Wed, Jan 05, 2022 at 09:26:16AM +0100, Takashi Iwai wrote:
> On Wed, 05 Jan 2022 04:41:01 +0100,
> Baole Fang wrote:
> > 
> > commit 25960cafa06e6fcd830e6c792e6a7de68c1e25ed upstream.
> 
> I couldn't find this commit.  Is this a bogus information?
> 
> > Legion Y9000X 2020 has a speaker, but the speaker doesn't work.
> > This can be fixed by applying alc285_fixup_ideapad_s740_coef
> >  to fix the speaker's coefficients.
> > Besides, to support the transition between the speaker and the headphone,
> > alc287_fixup_legion_15imhg05_speakers needs to be run.
> > 
> > Signed-off-by: Baole Fang <fbl718@163.com>
> 
> The code change itself looks fine, so I'd apply it if the line above
> can be omitted.

That commit id comes from 5.15.12, and it is the commit id of the
release commit:
	25960cafa06e ("Linux 5.15.12")
which makes no sense at all.

Baole, why did you add this line?

confused,

greg k-h

^ permalink raw reply

* Re: [PATCH mptcp-next v7 1/4] Squash to "mptcp: implement fastclose xmit path"
From: Geliang Tang @ 2022-01-05 10:55 UTC (permalink / raw)
  To: Matthieu Baerts; +Cc: mptcp
In-Reply-To: <9dcec4f1-26ea-ade8-7547-93fef53922b0@tessares.net>

On Wed, Jan 05, 2022 at 11:01:59AM +0100, Matthieu Baerts wrote:
> Hi Geliang,
> 
> On 05/01/2022 09:50, Geliang Tang wrote:
> > On Thu, Dec 30, 2021 at 08:16:48PM +0100, Matthieu Baerts wrote:
> >> From: Geliang Tang <geliang.tang@suse.com>
> >>
> >> MP_FAIL could be sent with RST or DSS, and FASTCLOSE can be sent with
> >> RST too. So we should use a similar xmit logic for FASTCLOSE and
> >> MP_FAIL in both mptcp_write_options() and mptcp_established_options*().
> >>
> >> Cc: Paolo Abeni <pabeni@redhat.com>
> >> Co-developed-by: Matthieu Baerts <matthieu.baerts@tessares.net>
> >> Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
> >> Signed-off-by: Geliang Tang <geliang.tang@suse.com>
> >> ---
> >>  net/mptcp/options.c | 66 ++++++++++++++++++++++++++++-----------------
> >>  1 file changed, 41 insertions(+), 25 deletions(-)
> >>
> >> diff --git a/net/mptcp/options.c b/net/mptcp/options.c
> >> index c6726e8389ec..9d2c1c9edbe6 100644
> >> --- a/net/mptcp/options.c
> >> +++ b/net/mptcp/options.c
> >> @@ -829,8 +829,12 @@ bool mptcp_established_options(struct sock *sk, struct sk_buff *skb,
> >>  
> >>  	if (unlikely(skb && TCP_SKB_CB(skb)->tcp_flags & TCPHDR_RST)) {
> >>  		if (mptcp_established_options_fastclose(sk, &opt_size, remaining, opts) ||
> >> -		    mptcp_established_options_mp_fail(sk, &opt_size, remaining, opts) ||
> >> -		    mptcp_established_options_rst(sk, skb, &opt_size, remaining, opts)) {
> >> +		    mptcp_established_options_mp_fail(sk, &opt_size, remaining, opts)) {
> >> +			*size += opt_size;
> >> +			remaining -= opt_size;
> >> +		}
> >> +		/* MP_RST can be used with MP_FASTCLOSE and MP_FAIL if there is room */
> >> +		if (mptcp_established_options_rst(sk, skb, &opt_size, remaining, opts)) {
> >>  			*size += opt_size;
> >>  			remaining -= opt_size;
> >>  		}
> >> @@ -1257,21 +1261,7 @@ static u16 mptcp_make_csum(const struct mptcp_ext *mpext)
> >>  void mptcp_write_options(__be32 *ptr, const struct tcp_sock *tp,
> >>  			 struct mptcp_out_options *opts)
> >>  {
> >> -	if (unlikely(OPTION_MPTCP_FAIL & opts->suboptions)) {
> >> -		const struct sock *ssk = (const struct sock *)tp;
> >> -		struct mptcp_subflow_context *subflow;
> >> -
> >> -		subflow = mptcp_subflow_ctx(ssk);
> >> -		subflow->send_mp_fail = 0;
> >> -
> >> -		*ptr++ = mptcp_option(MPTCPOPT_MP_FAIL,
> >> -				      TCPOLEN_MPTCP_FAIL,
> >> -				      0, 0);
> >> -		put_unaligned_be64(opts->fail_seq, ptr);
> >> -		ptr += 2;
> >> -	}
> > 
> > Hi Matt,
> > 
> > Sorry, this patch doesn't work on my test. We write both DSS + MP_FAIL,
> > but MP_FAIL is lost on the received side. Only DSS is received.
> > 
> > If we write MP_FAIL + DSS like the orignal code, MP_FAIL and DSS will be
> > received correctly.
> > 
> > I haven't figured out why yet.
> > 
> > Could we just keep this MP_FAIL writting code still at the beginning of
> > the function just like the orignal code did?
> 
> Thank you for having tested and reviewed the series!
> 
> Is this issue here fixed by your patch you sent a couple of minutes ago
> (mptcp: fix a DSS option writting error)
> 
> That would make sense as the only thing I did was to send the MP_FAIL
> after the DSS option.
> 
> Do you mind if I send a v8 series with your new fix the missing 'ptr +=
> 2;' below and have the code moving the writing of the MP_FAIL option
> later in a dedicated commit?

Hi Matt,

I think about it again. How about just using the v2 of this patch
(https://patchwork.kernel.org/project/mptcp/patch/5a8c6024481d6106c662c3e892ae5e499b4a7f76.1638156809.git.geliang.tang@suse.com/)
as a squash-to patch (We have reached an agreement on this part), and move
all the other code in this v7 as a new patch (It still needs to be
improved)?

Thanks,
-Geliang

> 
> > 
> >> -
> >> -	/* DSS, MPC, MPJ, ADD_ADDR, FASTCLOSE and RST are mutually exclusive,
> >> +	/* DSS, MPC, MPJ, ADD_ADDR, FASTCLOSE and FAIL are mutually exclusive,
> >>  	 * see mptcp_established_options*()
> >>  	 */
> >>  	if (likely(OPTION_MPTCP_DSS & opts->suboptions)) {
> >> @@ -1328,6 +1318,10 @@ void mptcp_write_options(__be32 *ptr, const struct tcp_sock *tp,
> >>  						   TCPOPT_NOP << 8 | TCPOPT_NOP, ptr);
> >>  			}
> >>  		}
> >> +
> >> +		/* We might need to add MP_FAIL options in rare cases */
> >> +		if (unlikely(OPTION_MPTCP_FAIL & opts->suboptions))
> >> +			goto mp_fail;
> >>  	} else if (OPTIONS_MPTCP_MPC & opts->suboptions) {
> >>  		u8 len, flag = MPTCP_CAP_HMAC_SHA256;
> >>  
> >> @@ -1460,19 +1454,41 @@ void mptcp_write_options(__be32 *ptr, const struct tcp_sock *tp,
> >>  				ptr += 1;
> >>  			}
> >>  		}
> >> -	} else if (unlikely(OPTION_MPTCP_RST & opts->suboptions)) {
> >> -		/* RST is mutually exclusive with everything else */
> >> -		*ptr++ = mptcp_option(MPTCPOPT_RST,
> >> -				      TCPOLEN_MPTCP_RST,
> >> -				      opts->reset_transient,
> >> -				      opts->reset_reason);
> >> -		return;
> >>  	} else if (unlikely(OPTION_MPTCP_FASTCLOSE & opts->suboptions)) {
> >> -		/* FASTCLOSE is mutually exclusive with everything else */
> >> +		/* FASTCLOSE is mutually exclusive with others except RST */
> >>  		*ptr++ = mptcp_option(MPTCPOPT_MP_FASTCLOSE,
> >>  				      TCPOLEN_MPTCP_FASTCLOSE,
> >>  				      0, 0);
> >>  		put_unaligned_be64(opts->rcvr_key, ptr);
> > 
> > Here, 'ptr += 2;' is needed.
> 
> Good catch!
> 
> Note related to my modification but to "mptcp: implement fastclose xmit
> path" so it should be in this squash-to patch!
> 
> Cheers,
> Matt
> -- 
> Tessares | Belgium | Hybrid Access Solutions
> www.tessares.net
> 


^ permalink raw reply

* Re: [PATCH] serial: imx: reduce RX interrupt frequency
From: Tomasz Moń @ 2022-01-05 10:56 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Uwe Kleine-König, linux-serial, Jiri Slaby, Fabio Estevam,
	Sascha Hauer, NXP Linux Team, Pengutronix Kernel Team, Shawn Guo,
	k.drobinski
In-Reply-To: <YdV00WYGGd49WYt9@kroah.com>

On 05.01.2022 11:37, Greg Kroah-Hartman wrote:
> On Wed, Jan 05, 2022 at 08:59:09AM +0100, Tomasz Moń wrote:
>> While the increased latency due to this change is undeniable, it is
>> important to note that latency is not everything. There are applications
>> where the latency is crucial, however using Linux for such applications
>> is questionable. Linux is not a Real Time Operating System after all.
> 
> Yes, Linux can be used in real time situtations just fine, look at the
> RT patchset for proof of that.
> 
> So let's not make things any worse for no good reason if at all
> possible.

Avoiding interrupt storm is a good reason for me.

>> Latency is simple to measure and argue based on the reception of single
>> character. That is only a corner case, not fully describing real world.
>> In the real world, it is important to consider the overall performance
>> improvement. It is hard to determine how much does the performance of
>> the system improve thanks to less time spent in interrupt handling.
> 
> If this can't be measured at all, why make this change in the first
> place?

It can be measured, just in general case, it is hard to tell exactly how
much does it help due to the complexity. All the time saved by not
wasting it in interrupt handler can have impact on many parts of the system.

However, there is a use case where it is easy to tell how much does this
change improve performance. In the situation where the interrupt storm
occurs with current mainline kernel (RXTL is set to 1) essentially
freezing everything until the sender stops transmitting, the patched
kernel (with RXTL is set to 8) handles the situation just fine. Change
from completely unresponsive to just fine is easy to notice.

Best Regards,
Tomasz Mon


^ permalink raw reply

* Re: [PATCH -next V2] blk-mq: fix tag_get wait task can't be awakened
From: John Garry @ 2022-01-05 10:56 UTC (permalink / raw)
  To: Laibin Qiu, axboe, ming.lei; +Cc: linux-block, linux-kernel
In-Reply-To: <20220105035644.3311480-1-qiulaibin@huawei.com>

On 05/01/2022 03:56, Laibin Qiu wrote:
> +
>   /*
>    * If a previously inactive queue goes active, bump the active user count.
>    * We need to do this before try to allocate driver tag, then even if fail
> @@ -23,10 +38,16 @@
>    */
>   bool __blk_mq_tag_busy(struct blk_mq_hw_ctx *hctx)
>   {
> +	unsigned int users;
> +
>   	if (!test_bit(BLK_MQ_S_TAG_ACTIVE, &hctx->state) &&
> -	    !test_and_set_bit(BLK_MQ_S_TAG_ACTIVE, &hctx->state))
> +	    !test_and_set_bit(BLK_MQ_S_TAG_ACTIVE, &hctx->state)) {
>   		atomic_inc(&hctx->tags->active_queues);
>   
> +		users = atomic_read(&hctx->tags->active_queues);
> +		blk_mq_update_wake_batch(hctx->tags, users);
> +	}
> +
>   	return true;
>   }
>   

This code looks old to me. Which baseline is used here?

Thanks,
John

^ permalink raw reply

* Re: [PATCH] ALSA: hda/realtek: Add quirk for Legion Y9000X 2020
From: Greg Kroah-Hartman @ 2022-01-05 10:55 UTC (permalink / raw)
  To: Takashi Iwai
  Cc: alsa-devel, Kailang Yang, Jeremy Szu, linux-kernel, Baole Fang,
	Takashi Iwai, Werner Sembach, Hui Wang, Sami Loone,
	Cameron Berkenpas, Elia Devito
In-Reply-To: <s5ha6gak2qf.wl-tiwai@suse.de>

On Wed, Jan 05, 2022 at 09:26:16AM +0100, Takashi Iwai wrote:
> On Wed, 05 Jan 2022 04:41:01 +0100,
> Baole Fang wrote:
> > 
> > commit 25960cafa06e6fcd830e6c792e6a7de68c1e25ed upstream.
> 
> I couldn't find this commit.  Is this a bogus information?
> 
> > Legion Y9000X 2020 has a speaker, but the speaker doesn't work.
> > This can be fixed by applying alc285_fixup_ideapad_s740_coef
> >  to fix the speaker's coefficients.
> > Besides, to support the transition between the speaker and the headphone,
> > alc287_fixup_legion_15imhg05_speakers needs to be run.
> > 
> > Signed-off-by: Baole Fang <fbl718@163.com>
> 
> The code change itself looks fine, so I'd apply it if the line above
> can be omitted.

That commit id comes from 5.15.12, and it is the commit id of the
release commit:
	25960cafa06e ("Linux 5.15.12")
which makes no sense at all.

Baole, why did you add this line?

confused,

greg k-h

^ permalink raw reply

* Re: [PATCH v2 4/5] KVM: x86: don't touch irr_pending in kvm_apic_update_apicv when inhibiting it
From: Maxim Levitsky @ 2022-01-05 10:56 UTC (permalink / raw)
  To: Sean Christopherson
  Cc: kvm, Jim Mattson, Thomas Gleixner, Joerg Roedel,
	maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT), Vitaly Kuznetsov,
	Borislav Petkov, linux-kernel, Paolo Bonzini, Dave Hansen,
	H. Peter Anvin, Wanpeng Li, Ingo Molnar
In-Reply-To: <YdTQ3ewNzNOKoXCN@google.com>

On Tue, 2022-01-04 at 22:57 +0000, Sean Christopherson wrote:
> On Mon, Dec 13, 2021, Maxim Levitsky wrote:
> > kvm_apic_update_apicv is called when AVIC is still active, thus IRR bits
> > can be set by the CPU after it was called, and won't cause the irr_pending
> > to be set to true.
> > 
> > Also the logic in avic_kick_target_vcpu doesn't expect a race with this
> > function.
> > 
> > To make it simple, just keep irr_pending set to true and
> > let the next interrupt injection to the guest clear it.
> > 
> > Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
> > ---
> >  arch/x86/kvm/lapic.c | 5 ++++-
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> > index baca9fa37a91c..6e1fbbf4c508b 100644
> > --- a/arch/x86/kvm/lapic.c
> > +++ b/arch/x86/kvm/lapic.c
> > @@ -2312,7 +2312,10 @@ void kvm_apic_update_apicv(struct kvm_vcpu *vcpu)
> >  		apic->irr_pending = true;
> >  		apic->isr_count = 1;
> >  	} else {
> > -		apic->irr_pending = (apic_search_irr(apic) != -1);
> > +		/*
> > +		 * Don't touch irr_pending, let it be cleared when
> > +		 * we process the interrupt
> 
> Please don't use pronouns in comments, e.g. who is "we" in this context?  Please
> also say _why_.  IIUC, this could more precisely be:

Yes, good point. I will fix this.

Best regards,
	Maxim Levitsky

> 
> 		/*
> 		 * Don't clear irr_pending, searching the IRR can race with
> 		 * updates from the CPU as APICv is still active from hardware's
> 		 * perspective.  The flag will be cleared as appropriate when
> 		 * KVM injects the interrupt.
> 		 */
> 
> > +		 */
> >  		apic->isr_count = count_vectors(apic->regs + APIC_ISR);
> >  	}
> >  }
> > -- 
> > 2.26.3
> > 



^ permalink raw reply

* Re: [PATCH] serial: imx: reduce RX interrupt frequency
From: Marc Kleine-Budde @ 2022-01-05 10:57 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Tomasz Moń, Pengutronix Kernel Team, Jiri Slaby,
	Sascha Hauer, NXP Linux Team, linux-serial, Uwe Kleine-König,
	Shawn Guo, Fabio Estevam, k.drobinski
In-Reply-To: <YdV00WYGGd49WYt9@kroah.com>

[-- Attachment #1: Type: text/plain, Size: 1841 bytes --]

On 05.01.2022 11:37:05, Greg Kroah-Hartman wrote:
> On Wed, Jan 05, 2022 at 08:59:09AM +0100, Tomasz Moń wrote:
> > On 04.01.2022 23:49, Uwe Kleine-König wrote:
> > > On Tue, Jan 04, 2022 at 12:38:01PM +0100, Greg Kroah-Hartman wrote:
> > >> On Tue, Jan 04, 2022 at 12:13:06PM +0100, Tomasz Moń wrote:
> > >>> On 04.01.2022 11:54, Greg Kroah-Hartman wrote:
> > >>>> Why can't you do this dynamically based on the baud rate so as to always
> > >>>> work properly for all speeds without increased delays for slower ones?
> > >>>
> > >>> Could you please advise on which baud rates to consider as slow? Does it
> > >>> sound good to have the old trigger level for rates up to and including
> > >>> 115200 and the new one for faster ones?
> > >>
> > >> You tell me, you are the one seeing this issue and are seeing delays on
> > >> slower values with your change.  Do some testing to see where the curve
> > >> is.
> > 
> > While the increased latency due to this change is undeniable, it is
> > important to note that latency is not everything. There are applications
> > where the latency is crucial, however using Linux for such applications
> > is questionable. Linux is not a Real Time Operating System after all.
> 
> Yes, Linux can be used in real time situtations just fine, look at the
> RT patchset for proof of that.
> 
> So let's not make things any worse for no good reason if at all
> possible.

+1

We have a $CUSTOMER, where serial latency is crucial. And we have a task
to cut down latencies and jitter even more.

Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde           |
Embedded Linux                   | https://www.pengutronix.de  |
Vertretung West/Dortmund         | Phone: +49-231-2826-924     |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-5555 |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply

* Re: [PATCH 1/4] i2c: at91: add compatible with microchip,sama7g5-i2c
From: Eugen.Hristev @ 2022-01-05 11:00 UTC (permalink / raw)
  To: michael; +Cc: hs, u-boot
In-Reply-To: <908a94ecb12c0177b2b2f903daf298b4@walle.cc>

On 1/5/22 12:49 PM, Michael Walle wrote:
> Am 2022-01-05 11:37, schrieb Eugen.Hristev@microchip.com:
>> On 1/5/22 12:04 PM, Michael Walle wrote:
>>> Hi,
>>>
>>>> Add compatible and data platform struct for sama7g5 SoC.
>>>>
>>>> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
>>>> ---
>>>>   drivers/i2c/at91_i2c.c | 6 ++++++
>>>>   1 file changed, 6 insertions(+)
>>>>
>>>> diff --git a/drivers/i2c/at91_i2c.c b/drivers/i2c/at91_i2c.c
>>>> index 6b4c0e4804..400a3786ca 100644
>>>> --- a/drivers/i2c/at91_i2c.c
>>>> +++ b/drivers/i2c/at91_i2c.c
>>>> @@ -305,6 +305,11 @@ static const struct at91_i2c_pdata
>>>> sama5d2_config = {
>>>>        .clk_offset = 3,
>>>>   };
>>>>
>>>> +static const struct at91_i2c_pdata sama7g5_config = {
>>>> +     .clk_max_div = 7,
>>>> +     .clk_offset = 3,
>>>> +};
>>>> +
>>>>   static const struct udevice_id at91_i2c_ids[] = {
>>>>   { .compatible = "atmel,at91rm9200-i2c", .data =
>>>> (long)&at91rm9200_config },
>>>>   { .compatible = "atmel,at91sam9260-i2c", .data =
>>>> (long)&at91sam9260_config },
>>>> @@ -314,6 +319,7 @@ static const struct udevice_id at91_i2c_ids[] = {
>>>>   { .compatible = "atmel,at91sam9x5-i2c", .data =
>>>> (long)&at91sam9x5_config },
>>>>   { .compatible = "atmel,sama5d4-i2c", .data = (long)&sama5d4_config
>>>> },
>>>>   { .compatible = "atmel,sama5d2-i2c", .data = (long)&sama5d2_config
>>>> },
>>>> +{ .compatible = "microchip,sama7g5-i2c", .data =
>>>> (long)&sama7g5_config },
>>>
>>> I see that this compatible string is is also used in the linux
>>> device tree, but there is no dt binding for it in linux. Could you
>>> add it, so the binding is approved by Rob?
>>
>> I can, for sure, but the current binding format is txt. I am not sure
>> if
>> we have to convert to yaml first, in which case it would be a little
>> more difficult than just adding a new compatible string.
>> The current DT node in Linux is also compatible with sam9x60, and this
>> string is already in the Linux binding file.
>> I could add the sam9x60 compatible instead, and it will still work, as
>> 9x60 type of i2c is the same as in sama7g5.
>> You think this option would be better for now ?
> 
> It's at least better than adding an undocumented string. But TBH,
> this looks like "what can I do to avoid converting the dt binding
> to yaml". Which eventually has to be done anyway, so now might be
> a good opportunity for that :)

You are right. It has to be done anyway, but I would not like to stop 
the addition to u-boot because of that.
Converting the i2c to yaml might open several other issues, and this 
might delay a simple compatible string in uboot a lot.
sam9x60 compatible has to be added anyway, since it's supported and it's 
already in the binding tree.
So I see this like an intermediary step.

> 
> But looking at sama7g5_config above again, will that also be the
> correct values for the generic sam9x60?

That's right.
I will follow up with a patch to add sam9x60, and think of converting 
the i2c binding later on.

> 
> -michael


^ permalink raw reply

* Re: [PATCH bpf-next v5 2/7] page_pool: Add callback to init pages when they are allocated
From: Jesper Dangaard Brouer @ 2022-01-05 11:01 UTC (permalink / raw)
  To: Toke Høiland-Jørgensen, Jesper Dangaard Brouer,
	Ilias Apalodimas, David S. Miller, Jakub Kicinski,
	Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Martin KaFai Lau, Song Liu, Yonghong Song, John Fastabend,
	KP Singh
  Cc: brouer, netdev, bpf
In-Reply-To: <20220103150812.87914-3-toke@redhat.com>



On 03/01/2022 16.08, Toke Høiland-Jørgensen wrote:
> Add a new callback function to page_pool that, if set, will be called every
> time a new page is allocated. This will be used from bpf_test_run() to
> initialise the page data with the data provided by userspace when running
> XDP programs with redirect turned on.
> 
> Acked-by: John Fastabend<john.fastabend@gmail.com>
> Signed-off-by: Toke Høiland-Jørgensen<toke@redhat.com>

Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>


^ permalink raw reply

* Re: [PATCH bpf-next v5 3/7] page_pool: Store the XDP mem id
From: Jesper Dangaard Brouer @ 2022-01-05 11:02 UTC (permalink / raw)
  To: Toke Høiland-Jørgensen, Jesper Dangaard Brouer,
	Ilias Apalodimas, David S. Miller, Jakub Kicinski,
	Alexei Starovoitov, Daniel Borkmann, John Fastabend,
	Andrii Nakryiko, Martin KaFai Lau, Song Liu, Yonghong Song,
	KP Singh
  Cc: brouer, netdev, bpf
In-Reply-To: <20220103150812.87914-4-toke@redhat.com>


On 03/01/2022 16.08, Toke Høiland-Jørgensen wrote:
> Store the XDP mem ID inside the page_pool struct so it can be retrieved
> later for use in bpf_prog_run().
> 
> Signed-off-by: Toke Høiland-Jørgensen<toke@redhat.com>
> ---
>   include/net/page_pool.h | 9 +++++++--
>   net/core/page_pool.c    | 4 +++-
>   net/core/xdp.c          | 2 +-
>   3 files changed, 11 insertions(+), 4 deletions(-)

Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>


^ permalink raw reply


This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.