* Re: [PATCH v2 0/2] Don't generate thousands of new warnings when building docs
From: Jonathan Corbet @ 2020-03-20 23:10 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Ricardo Ribalda Delgado, Linux Doc Mailing List, target-devel,
Paul Mackerras, H. Peter Anvin, Alex Shi, linux-scsi, x86,
Tyler Hicks, Ingo Molnar, Jakub Kicinski, Jacopo Mondi,
Luca Ceresoli, Johannes Berg, ecryptfs, Matthias Maennich,
dmaengine, Borislav Petkov, Thomas Gleixner, Martin K. Petersen,
netdev, linux-kernel, Vinod Koul, Harry Wei, Greg Kroah-Hartman,
Hans Verkuil, linuxppc-dev, David S. Miller, Madhuparna Bhowmik
In-Reply-To: <cover.1584716446.git.mchehab+huawei@kernel.org>
On Fri, 20 Mar 2020 16:11:01 +0100
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> This small series address a regression caused by a new patch at
> docs-next (and at linux-next).
I don't know how I missed that mess, sorry. I plead distracting times or
something like that. Heck, I think I'll blame everything on the plague
for at least the next few weeks.
Anyway, I've applied this, thanks for cleaning it up.
jon
^ permalink raw reply
* Re: [patch V2 08/15] Documentation: Add lock ordering and nesting documentation
From: Thomas Gleixner @ 2020-03-20 22:36 UTC (permalink / raw)
To: paulmck
Cc: Randy Dunlap, Peter Zijlstra, linux-pci,
Sebastian Andrzej Siewior, Oleg Nesterov, Joel Fernandes,
Will Deacon, Ingo Molnar, Davidlohr Bueso, Logan Gunthorpe,
Arnd Bergmann, linuxppc-dev, Steven Rostedt, Bjorn Helgaas,
Kurt Schwemmer, Kalle Valo, Felipe Balbi, Greg Kroah-Hartman,
linux-usb, linux-wireless, LKML, netdev, Linus Torvalds,
David S. Miller
In-Reply-To: <20200320210243.GT3199@paulmck-ThinkPad-P72>
"Paul E. McKenney" <paulmck@kernel.org> writes:
> On Fri, Mar 20, 2020 at 08:51:44PM +0100, Thomas Gleixner wrote:
>> "Paul E. McKenney" <paulmck@kernel.org> writes:
>> >
>> > - The soft interrupt related suffix (_bh()) still disables softirq
>> > handlers. However, unlike non-PREEMPT_RT kernels (which disable
>> > preemption to get this effect), PREEMPT_RT kernels use a per-CPU
>> > lock to exclude softirq handlers.
>>
>> I've made that:
>>
>> - The soft interrupt related suffix (_bh()) still disables softirq
>> handlers.
>>
>> Non-PREEMPT_RT kernels disable preemption to get this effect.
>>
>> PREEMPT_RT kernels use a per-CPU lock for serialization. The lock
>> disables softirq handlers and prevents reentrancy by a preempting
>> task.
>
> That works! At the end, I would instead say "prevents reentrancy
> due to task preemption", but what you have works.
Yours is better.
>> - Task state is preserved across spinlock acquisition, ensuring that the
>> task-state rules apply to all kernel configurations. Non-PREEMPT_RT
>> kernels leave task state untouched. However, PREEMPT_RT must change
>> task state if the task blocks during acquisition. Therefore, it
>> saves the current task state before blocking and the corresponding
>> lock wakeup restores it. A regular not lock related wakeup sets the
>> task state to RUNNING. If this happens while the task is blocked on
>> a spinlock then the saved task state is changed so that correct
>> state is restored on lock wakeup.
>>
>> Hmm?
>
> I of course cannot resist editing the last two sentences:
>
> ... Other types of wakeups unconditionally set task state to RUNNING.
> If this happens while a task is blocked while acquiring a spinlock,
> then the task state is restored to its pre-acquisition value at
> lock-wakeup time.
Errm no. That would mean
state = UNINTERRUPTIBLE
lock()
block()
real_state = state
state = SLEEPONLOCK
non lock wakeup
state = RUNNING <--- FAIL #1
lock wakeup
state = real_state <--- FAIL #2
How it works is:
state = UNINTERRUPTIBLE
lock()
block()
real_state = state
state = SLEEPONLOCK
non lock wakeup
real_state = RUNNING
lock wakeup
state = real_state == RUNNING
If there is no 'non lock wakeup' before the lock wakeup:
state = UNINTERRUPTIBLE
lock()
block()
real_state = state
state = SLEEPONLOCK
lock wakeup
state = real_state == UNINTERRUPTIBLE
I agree that what I tried to express is hard to parse, but it's at least
halfways correct :)
Thanks,
tglx
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS a87b93bdf800a4d7a42d95683624a4516e516b4f
From: kbuild test robot @ 2020-03-20 22:00 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: a87b93bdf800a4d7a42d95683624a4516e516b4f Automatic merge of branches 'master', 'next' and 'fixes' into merge
elapsed time: 569m
configs tested: 157
configs skipped: 0
The following configs have been built successfully.
More configs may be tested in the coming days.
arm allmodconfig
arm allnoconfig
arm allyesconfig
arm64 allmodconfig
arm64 allnoconfig
arm64 allyesconfig
arm at91_dt_defconfig
arm efm32_defconfig
arm exynos_defconfig
arm multi_v5_defconfig
arm multi_v7_defconfig
arm shmobile_defconfig
arm sunxi_defconfig
arm64 defconfig
sparc allyesconfig
parisc generic-32bit_defconfig
openrisc simple_smp_defconfig
sparc64 allmodconfig
powerpc ppc64_defconfig
i386 allnoconfig
i386 alldefconfig
i386 allyesconfig
i386 defconfig
ia64 alldefconfig
ia64 allmodconfig
ia64 allnoconfig
ia64 allyesconfig
ia64 defconfig
c6x allyesconfig
c6x evmc6678_defconfig
nios2 10m50_defconfig
nios2 3c120_defconfig
openrisc or1ksim_defconfig
xtensa common_defconfig
xtensa iss_defconfig
alpha defconfig
csky defconfig
nds32 allnoconfig
nds32 defconfig
h8300 edosk2674_defconfig
h8300 h8300h-sim_defconfig
h8300 h8s-sim_defconfig
m68k m5475evb_defconfig
m68k sun3_defconfig
m68k allmodconfig
m68k multi_defconfig
arc defconfig
arc allyesconfig
powerpc defconfig
powerpc rhel-kconfig
microblaze mmu_defconfig
microblaze nommu_defconfig
powerpc allnoconfig
mips fuloong2e_defconfig
mips malta_kvm_defconfig
mips allyesconfig
mips 64r6el_defconfig
mips allnoconfig
mips 32r2_defconfig
mips allmodconfig
parisc allnoconfig
parisc allyesconfig
parisc generic-64bit_defconfig
x86_64 randconfig-a001-20200320
x86_64 randconfig-a002-20200320
x86_64 randconfig-a003-20200320
i386 randconfig-a001-20200320
i386 randconfig-a002-20200320
i386 randconfig-a003-20200320
alpha randconfig-a001-20200320
mips randconfig-a001-20200320
nds32 randconfig-a001-20200320
parisc randconfig-a001-20200320
m68k randconfig-a001-20200320
c6x randconfig-a001-20200320
h8300 randconfig-a001-20200320
microblaze randconfig-a001-20200320
nios2 randconfig-a001-20200320
sparc64 randconfig-a001-20200320
csky randconfig-a001-20200320
openrisc randconfig-a001-20200320
s390 randconfig-a001-20200320
sh randconfig-a001-20200320
xtensa randconfig-a001-20200320
i386 randconfig-b003-20200320
i386 randconfig-b001-20200320
x86_64 randconfig-b003-20200320
i386 randconfig-b002-20200320
x86_64 randconfig-b002-20200320
x86_64 randconfig-b001-20200320
x86_64 randconfig-c003-20200320
i386 randconfig-c002-20200320
x86_64 randconfig-c001-20200320
i386 randconfig-c003-20200320
i386 randconfig-c001-20200320
x86_64 randconfig-c002-20200320
i386 randconfig-d003-20200320
i386 randconfig-d001-20200320
x86_64 randconfig-d002-20200320
i386 randconfig-d002-20200320
x86_64 randconfig-d001-20200320
x86_64 randconfig-d003-20200320
x86_64 randconfig-f001-20200320
x86_64 randconfig-f002-20200320
x86_64 randconfig-f003-20200320
i386 randconfig-f001-20200320
i386 randconfig-f002-20200320
i386 randconfig-f003-20200320
x86_64 randconfig-g001-20200320
x86_64 randconfig-g002-20200320
x86_64 randconfig-g003-20200320
i386 randconfig-g001-20200320
i386 randconfig-g002-20200320
i386 randconfig-g003-20200320
x86_64 randconfig-h001-20200320
x86_64 randconfig-h002-20200320
x86_64 randconfig-h003-20200320
i386 randconfig-h001-20200320
i386 randconfig-h002-20200320
i386 randconfig-h003-20200320
arc randconfig-a001-20200320
arm randconfig-a001-20200320
arm64 randconfig-a001-20200320
ia64 randconfig-a001-20200320
powerpc randconfig-a001-20200320
sparc randconfig-a001-20200320
riscv allnoconfig
riscv allyesconfig
riscv defconfig
riscv nommu_virt_defconfig
riscv rv32_defconfig
riscv allmodconfig
s390 alldefconfig
s390 allmodconfig
s390 allnoconfig
s390 allyesconfig
s390 debug_defconfig
s390 defconfig
s390 zfcpdump_defconfig
sh allmodconfig
sh allnoconfig
sh rsk7269_defconfig
sh sh7785lcr_32bit_defconfig
sh titan_defconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allyesconfig
um x86_64_defconfig
um i386_defconfig
um defconfig
x86_64 rhel
x86_64 rhel-7.6
x86_64 rhel-7.2-clear
x86_64 lkp
x86_64 fedora-25
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:next-test] BUILD SUCCESS b3258f133d72af0bb463e198610d47ae57498b00
From: kbuild test robot @ 2020-03-20 22:00 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
branch HEAD: b3258f133d72af0bb463e198610d47ae57498b00 powerpc/64: Prevent stack protection in early boot
elapsed time: 1090m
configs tested: 167
configs skipped: 17
The following configs have been built successfully.
More configs may be tested in the coming days.
arm allmodconfig
arm allnoconfig
arm allyesconfig
arm64 allmodconfig
arm64 allnoconfig
arm64 allyesconfig
arm at91_dt_defconfig
arm efm32_defconfig
arm exynos_defconfig
arm multi_v5_defconfig
arm multi_v7_defconfig
arm shmobile_defconfig
arm sunxi_defconfig
arm64 defconfig
sparc allyesconfig
riscv defconfig
i386 defconfig
s390 allyesconfig
sh rsk7269_defconfig
parisc generic-32bit_defconfig
openrisc simple_smp_defconfig
sparc64 allmodconfig
ia64 alldefconfig
powerpc ppc64_defconfig
mips malta_kvm_defconfig
i386 allnoconfig
i386 allyesconfig
i386 alldefconfig
ia64 allmodconfig
ia64 defconfig
ia64 allnoconfig
ia64 allyesconfig
c6x allyesconfig
c6x evmc6678_defconfig
nios2 10m50_defconfig
nios2 3c120_defconfig
openrisc or1ksim_defconfig
xtensa common_defconfig
xtensa iss_defconfig
alpha defconfig
csky defconfig
nds32 allnoconfig
nds32 defconfig
h8300 h8s-sim_defconfig
h8300 edosk2674_defconfig
m68k m5475evb_defconfig
m68k allmodconfig
h8300 h8300h-sim_defconfig
m68k sun3_defconfig
m68k multi_defconfig
arc allyesconfig
arc defconfig
microblaze mmu_defconfig
microblaze nommu_defconfig
powerpc allnoconfig
powerpc defconfig
powerpc rhel-kconfig
mips fuloong2e_defconfig
mips allyesconfig
mips 64r6el_defconfig
mips allnoconfig
mips 32r2_defconfig
mips allmodconfig
parisc allnoconfig
parisc allyesconfig
parisc generic-64bit_defconfig
x86_64 randconfig-a001-20200320
x86_64 randconfig-a002-20200320
x86_64 randconfig-a003-20200320
i386 randconfig-a001-20200320
i386 randconfig-a002-20200320
i386 randconfig-a003-20200320
alpha randconfig-a001-20200320
m68k randconfig-a001-20200320
mips randconfig-a001-20200320
nds32 randconfig-a001-20200320
parisc randconfig-a001-20200320
c6x randconfig-a001-20200320
h8300 randconfig-a001-20200320
microblaze randconfig-a001-20200320
nios2 randconfig-a001-20200320
sparc64 randconfig-a001-20200320
csky randconfig-a001-20200320
openrisc randconfig-a001-20200320
s390 randconfig-a001-20200320
sh randconfig-a001-20200320
xtensa randconfig-a001-20200320
x86_64 randconfig-b001-20200320
x86_64 randconfig-b002-20200320
x86_64 randconfig-b003-20200320
i386 randconfig-b001-20200320
i386 randconfig-b002-20200320
i386 randconfig-b003-20200320
x86_64 randconfig-c001-20200320
x86_64 randconfig-c002-20200320
x86_64 randconfig-c003-20200320
i386 randconfig-c001-20200320
i386 randconfig-c002-20200320
i386 randconfig-c003-20200320
i386 randconfig-d003-20200320
i386 randconfig-d001-20200320
x86_64 randconfig-d002-20200320
i386 randconfig-d002-20200320
x86_64 randconfig-d001-20200320
x86_64 randconfig-d003-20200320
x86_64 randconfig-e001-20200320
x86_64 randconfig-e002-20200320
x86_64 randconfig-e003-20200320
i386 randconfig-e001-20200320
i386 randconfig-e002-20200320
i386 randconfig-e003-20200320
x86_64 randconfig-f001-20200320
x86_64 randconfig-f002-20200320
x86_64 randconfig-f003-20200320
i386 randconfig-f001-20200320
i386 randconfig-f002-20200320
i386 randconfig-f003-20200320
x86_64 randconfig-g001-20200320
x86_64 randconfig-g002-20200320
x86_64 randconfig-g003-20200320
i386 randconfig-g001-20200320
i386 randconfig-g002-20200320
i386 randconfig-g003-20200320
x86_64 randconfig-h001-20200320
x86_64 randconfig-h002-20200320
x86_64 randconfig-h003-20200320
i386 randconfig-h001-20200320
i386 randconfig-h002-20200320
i386 randconfig-h003-20200320
arc randconfig-a001-20200320
arm randconfig-a001-20200320
arm64 randconfig-a001-20200320
ia64 randconfig-a001-20200320
powerpc randconfig-a001-20200320
sparc randconfig-a001-20200320
arm randconfig-a001-20200321
arm64 randconfig-a001-20200321
ia64 randconfig-a001-20200321
powerpc randconfig-a001-20200321
riscv allnoconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv rv32_defconfig
riscv allmodconfig
s390 zfcpdump_defconfig
s390 debug_defconfig
s390 allnoconfig
s390 allmodconfig
s390 alldefconfig
s390 defconfig
sh allmodconfig
sh allnoconfig
sh sh7785lcr_32bit_defconfig
sh titan_defconfig
sparc defconfig
sparc64 allnoconfig
sparc64 allyesconfig
sparc64 defconfig
um x86_64_defconfig
um i386_defconfig
um defconfig
x86_64 fedora-25
x86_64 kexec
x86_64 lkp
x86_64 rhel
x86_64 rhel-7.2-clear
x86_64 rhel-7.6
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH v12 8/8] MAINTAINERS: perf: Add pattern that matches ppc perf to the perf entry.
From: Joe Perches @ 2020-03-20 21:36 UTC (permalink / raw)
To: Andy Shevchenko, Linus Torvalds
Cc: linux-fsdevel, Michal Suchánek, linuxppc-dev, linux-kernel
In-Reply-To: <20200320163157.GF1922688@smile.fi.intel.com>
(removed a bunch of cc's)
On Fri, 2020-03-20 at 18:31 +0200, Andy Shevchenko wrote:
> On Fri, Mar 20, 2020 at 07:42:03AM -0700, Joe Perches wrote:
> > On Fri, 2020-03-20 at 14:42 +0200, Andy Shevchenko wrote:
> > > On Fri, Mar 20, 2020 at 12:23:38PM +0100, Michal Suchánek wrote:
> > > > On Fri, Mar 20, 2020 at 12:33:50PM +0200, Andy Shevchenko wrote:
> > > > > On Fri, Mar 20, 2020 at 11:20:19AM +0100, Michal Suchanek wrote:
> > > > > > While at it also simplify the existing perf patterns.
> > > > > And still missed fixes from parse-maintainers.pl.
> > > >
> > > > Oh, that script UX is truly ingenious.
> > >
> > > You have at least two options, their combinations, etc:
> > > - complain to the author :-)
> > > - send a patch :-)
> >
> > Recently:
> >
> > https://lore.kernel.org/lkml/4d5291fa3fb4962b1fa55e8fd9ef421ef0c1b1e5.camel@perches.com/
>
> But why?
>
> Shouldn't we rather run MAINTAINERS clean up once and require people to use
> parse-maintainers.pl for good?
That can basically only be done by Linus just before he releases
an RC1.
I am for it. One day...
^ permalink raw reply
* Re: [patch V2 08/15] Documentation: Add lock ordering and nesting documentation
From: Paul E. McKenney @ 2020-03-20 21:02 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Randy Dunlap, Peter Zijlstra, linux-pci,
Sebastian Andrzej Siewior, Oleg Nesterov, Joel Fernandes,
Will Deacon, Ingo Molnar, Davidlohr Bueso, Logan Gunthorpe,
Arnd Bergmann, linuxppc-dev, Steven Rostedt, Bjorn Helgaas,
Kurt Schwemmer, Kalle Valo, Felipe Balbi, Greg Kroah-Hartman,
linux-usb, linux-wireless, LKML, netdev, Linus Torvalds,
David S. Miller
In-Reply-To: <87mu8apzxr.fsf@nanos.tec.linutronix.de>
On Fri, Mar 20, 2020 at 08:51:44PM +0100, Thomas Gleixner wrote:
> "Paul E. McKenney" <paulmck@kernel.org> writes:
> >
> > - The soft interrupt related suffix (_bh()) still disables softirq
> > handlers. However, unlike non-PREEMPT_RT kernels (which disable
> > preemption to get this effect), PREEMPT_RT kernels use a per-CPU
> > lock to exclude softirq handlers.
>
> I've made that:
>
> - The soft interrupt related suffix (_bh()) still disables softirq
> handlers.
>
> Non-PREEMPT_RT kernels disable preemption to get this effect.
>
> PREEMPT_RT kernels use a per-CPU lock for serialization. The lock
> disables softirq handlers and prevents reentrancy by a preempting
> task.
That works! At the end, I would instead say "prevents reentrancy
due to task preemption", but what you have works.
> On non-RT this is implicit through preemption disable, but it's non
> obvious for RT as preemption stays enabled.
>
> > PREEMPT_RT kernels preserve all other spinlock_t semantics:
> >
> > - Tasks holding a spinlock_t do not migrate. Non-PREEMPT_RT kernels
> > avoid migration by disabling preemption. PREEMPT_RT kernels instead
> > disable migration, which ensures that pointers to per-CPU variables
> > remain valid even if the task is preempted.
> >
> > - Task state is preserved across spinlock acquisition, ensuring that the
> > task-state rules apply to all kernel configurations. In non-PREEMPT_RT
> > kernels leave task state untouched. However, PREEMPT_RT must change
> > task state if the task blocks during acquisition. Therefore, the
> > corresponding lock wakeup restores the task state. Note that regular
> > (not lock related) wakeups do not restore task state.
>
> - Task state is preserved across spinlock acquisition, ensuring that the
> task-state rules apply to all kernel configurations. Non-PREEMPT_RT
> kernels leave task state untouched. However, PREEMPT_RT must change
> task state if the task blocks during acquisition. Therefore, it
> saves the current task state before blocking and the corresponding
> lock wakeup restores it. A regular not lock related wakeup sets the
> task state to RUNNING. If this happens while the task is blocked on
> a spinlock then the saved task state is changed so that correct
> state is restored on lock wakeup.
>
> Hmm?
I of course cannot resist editing the last two sentences:
... Other types of wakeups unconditionally set task state to RUNNING.
If this happens while a task is blocked while acquiring a spinlock,
then the task state is restored to its pre-acquisition value at
lock-wakeup time.
> > But this code failes on PREEMPT_RT kernels because the memory allocator
> > is fully preemptible and therefore cannot be invoked from truly atomic
> > contexts. However, it is perfectly fine to invoke the memory allocator
> > while holding a normal non-raw spinlocks because they do not disable
> > preemption::
> >
> >> + spin_lock(&lock);
> >> + p = kmalloc(sizeof(*p), GFP_ATOMIC);
> >> +
> >> +Most places which use GFP_ATOMIC allocations are safe on PREEMPT_RT as the
> >> +execution is forced into thread context and the lock substitution is
> >> +ensuring preemptibility.
> >
> > Interestingly enough, most uses of GFP_ATOMIC allocations are
> > actually safe on PREEMPT_RT because the the lock substitution ensures
> > preemptibility. Only those GFP_ATOMIC allocations that are invoke
> > while holding a raw spinlock or with preemption otherwise disabled need
> > adjustment to work correctly on PREEMPT_RT.
> >
> > [ I am not as confident of the above as I would like to be... ]
>
> I'd leave that whole paragraph out. This documents the rules and from
> the above code examples it's pretty clear what works and what not :)
Works for me! ;-)
> > And meeting time, will continue later!
>
> Enjoy!
Not bad, actually, as meetings go.
Thanx, Paul
^ permalink raw reply
* Re: [patch V2 08/15] Documentation: Add lock ordering and nesting documentation
From: Thomas Gleixner @ 2020-03-20 19:51 UTC (permalink / raw)
To: paulmck
Cc: Randy Dunlap, Peter Zijlstra, linux-pci,
Sebastian Andrzej Siewior, Oleg Nesterov, Joel Fernandes,
Will Deacon, Ingo Molnar, Davidlohr Bueso, Logan Gunthorpe,
Arnd Bergmann, linuxppc-dev, Steven Rostedt, Bjorn Helgaas,
Kurt Schwemmer, Kalle Valo, Felipe Balbi, Greg Kroah-Hartman,
linux-usb, linux-wireless, LKML, netdev, Linus Torvalds,
David S. Miller
In-Reply-To: <20200320160145.GN3199@paulmck-ThinkPad-P72>
"Paul E. McKenney" <paulmck@kernel.org> writes:
>
> - The soft interrupt related suffix (_bh()) still disables softirq
> handlers. However, unlike non-PREEMPT_RT kernels (which disable
> preemption to get this effect), PREEMPT_RT kernels use a per-CPU
> lock to exclude softirq handlers.
I've made that:
- The soft interrupt related suffix (_bh()) still disables softirq
handlers.
Non-PREEMPT_RT kernels disable preemption to get this effect.
PREEMPT_RT kernels use a per-CPU lock for serialization. The lock
disables softirq handlers and prevents reentrancy by a preempting
task.
On non-RT this is implicit through preemption disable, but it's non
obvious for RT as preemption stays enabled.
> PREEMPT_RT kernels preserve all other spinlock_t semantics:
>
> - Tasks holding a spinlock_t do not migrate. Non-PREEMPT_RT kernels
> avoid migration by disabling preemption. PREEMPT_RT kernels instead
> disable migration, which ensures that pointers to per-CPU variables
> remain valid even if the task is preempted.
>
> - Task state is preserved across spinlock acquisition, ensuring that the
> task-state rules apply to all kernel configurations. In non-PREEMPT_RT
> kernels leave task state untouched. However, PREEMPT_RT must change
> task state if the task blocks during acquisition. Therefore, the
> corresponding lock wakeup restores the task state. Note that regular
> (not lock related) wakeups do not restore task state.
- Task state is preserved across spinlock acquisition, ensuring that the
task-state rules apply to all kernel configurations. Non-PREEMPT_RT
kernels leave task state untouched. However, PREEMPT_RT must change
task state if the task blocks during acquisition. Therefore, it
saves the current task state before blocking and the corresponding
lock wakeup restores it. A regular not lock related wakeup sets the
task state to RUNNING. If this happens while the task is blocked on
a spinlock then the saved task state is changed so that correct
state is restored on lock wakeup.
Hmm?
> But this code failes on PREEMPT_RT kernels because the memory allocator
> is fully preemptible and therefore cannot be invoked from truly atomic
> contexts. However, it is perfectly fine to invoke the memory allocator
> while holding a normal non-raw spinlocks because they do not disable
> preemption::
>
>> + spin_lock(&lock);
>> + p = kmalloc(sizeof(*p), GFP_ATOMIC);
>> +
>> +Most places which use GFP_ATOMIC allocations are safe on PREEMPT_RT as the
>> +execution is forced into thread context and the lock substitution is
>> +ensuring preemptibility.
>
> Interestingly enough, most uses of GFP_ATOMIC allocations are
> actually safe on PREEMPT_RT because the the lock substitution ensures
> preemptibility. Only those GFP_ATOMIC allocations that are invoke
> while holding a raw spinlock or with preemption otherwise disabled need
> adjustment to work correctly on PREEMPT_RT.
>
> [ I am not as confident of the above as I would like to be... ]
I'd leave that whole paragraph out. This documents the rules and from
the above code examples it's pretty clear what works and what not :)
> And meeting time, will continue later!
Enjoy!
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH] powerpc/64: ftrace don't trace real mode
From: Naveen N. Rao @ 2020-03-20 18:39 UTC (permalink / raw)
To: linuxppc-dev, Nicholas Piggin
In-Reply-To: <20200320152551.1468983-1-npiggin@gmail.com>
Hi Nick,
Nicholas Piggin wrote:
> This warns and prevents tracing attempted in a real-mode context.
Is this something you're seeing often? Last time we looked at this, KVM
was the biggest offender and we introduced paca->ftrace_enabled as a way
to disable ftrace while in KVM code.
While this is cheap when handling ftrace_regs_caller() as done in this
patch, for simple function tracing (see below), we will have to grab the
MSR which will slow things down slightly.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> arch/powerpc/kernel/trace/ftrace.c | 3 +++
> .../powerpc/kernel/trace/ftrace_64_mprofile.S | 19 +++++++++++++++----
> 2 files changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/kernel/trace/ftrace.c b/arch/powerpc/kernel/trace/ftrace.c
> index 7ea0ca044b65..ef965815fcb9 100644
> --- a/arch/powerpc/kernel/trace/ftrace.c
> +++ b/arch/powerpc/kernel/trace/ftrace.c
> @@ -949,6 +949,9 @@ unsigned long prepare_ftrace_return(unsigned long parent, unsigned long ip,
> {
> unsigned long return_hooker;
>
> + if (WARN_ON_ONCE((mfmsr() & (MSR_IR|MSR_DR)) != (MSR_IR|MSR_DR)))
> + goto out;
> +
This is called on function entry to redirect function return to a
trampoline if needed. I am not sure if we have (or will have) too many C
functions that disable MSR_IR|MSR_DR. Unless the number of such
functions is large, it might be preferable to mark specific functions as
notrace.
> if (unlikely(ftrace_graph_is_dead()))
> goto out;
>
> diff --git a/arch/powerpc/kernel/trace/ftrace_64_mprofile.S b/arch/powerpc/kernel/trace/ftrace_64_mprofile.S
> index f9fd5f743eba..6205f15cb603 100644
> --- a/arch/powerpc/kernel/trace/ftrace_64_mprofile.S
> +++ b/arch/powerpc/kernel/trace/ftrace_64_mprofile.S
> @@ -51,16 +51,21 @@ _GLOBAL(ftrace_regs_caller)
> SAVE_10GPRS(12, r1)
> SAVE_10GPRS(22, r1)
>
> - /* Save previous stack pointer (r1) */
> - addi r8, r1, SWITCH_FRAME_SIZE
> - std r8, GPR1(r1)
> -
> /* Load special regs for save below */
> mfmsr r8
> mfctr r9
> mfxer r10
> mfcr r11
>
> + /* Shouldn't be called in real mode */
> + andi. r3,r8,(MSR_IR|MSR_DR)
> + cmpdi r3,(MSR_IR|MSR_DR)
> + bne ftrace_bad_realmode
> +
> + /* Save previous stack pointer (r1) */
> + addi r8, r1, SWITCH_FRAME_SIZE
> + std r8, GPR1(r1)
> +
This stomps on the MSR value in r8, which is saved into pt_regs further
below.
You'll also have to handle ftrace_caller() which is used for simple
function tracing. We don't read the MSR there today, but that will be
needed if we want to suppress tracing.
- Naveen
^ permalink raw reply
* Re: [PATCH v5 6/7] ASoC: dt-bindings: fsl_easrc: Add document for EASRC
From: Rob Herring @ 2020-03-20 17:48 UTC (permalink / raw)
To: Shengjiu Wang
Cc: mark.rutland, devicetree, alsa-devel, timur, Xiubo.Lee,
linuxppc-dev, tiwai, lgirdwood, perex, nicoleotsuka, broonie,
festevam, linux-kernel
In-Reply-To: <71b6ad3d0ea79076fded2373490ec1eb8c418d21.1583725533.git.shengjiu.wang@nxp.com>
On Mon, Mar 09, 2020 at 11:58:33AM +0800, Shengjiu Wang wrote:
> EASRC (Enhanced Asynchronous Sample Rate Converter) is a new
> IP module found on i.MX8MN.
>
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> ---
> .../devicetree/bindings/sound/fsl,easrc.yaml | 101 ++++++++++++++++++
> 1 file changed, 101 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/fsl,easrc.yaml
>
> diff --git a/Documentation/devicetree/bindings/sound/fsl,easrc.yaml b/Documentation/devicetree/bindings/sound/fsl,easrc.yaml
> new file mode 100644
> index 000000000000..ff22f8056a63
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/fsl,easrc.yaml
> @@ -0,0 +1,101 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sound/fsl,easrc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NXP Asynchronous Sample Rate Converter (ASRC) Controller
> +
> +maintainers:
> + - Shengjiu Wang <shengjiu.wang@nxp.com>
> +
> +properties:
> + $nodename:
> + pattern: "^easrc@.*"
> +
> + compatible:
> + const: fsl,imx8mn-easrc
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + clocks:
> + items:
> + - description: Peripheral clock
> +
> + clock-names:
> + items:
> + - const: mem
> +
> + dmas:
> + maxItems: 8
> +
> + dma-names:
> + items:
> + - const: ctx0_rx
> + - const: ctx0_tx
> + - const: ctx1_rx
> + - const: ctx1_tx
> + - const: ctx2_rx
> + - const: ctx2_tx
> + - const: ctx3_rx
> + - const: ctx3_tx
> +
> + fsl,easrc-ram-script-name:
'firmware-name' is the established property name for this.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/string
> + - const: imx/easrc/easrc-imx8mn.bin
Though if there's only 1 possible value, why does this need to be in DT?
> + description: The coefficient table for the filters
If the firmware is only 1 thing, then perhaps this should just be a DT
property rather than a separate file. It depends on who owns/creates
this file. If fixed for the platform, then DT is a good fit. If updated
separately from DT and boot firmware, then keeping it separate makes
sense.
> +
> + fsl,asrc-rate:
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - minimum: 8000
> + - maximum: 192000
> + description: Defines a mutual sample rate used by DPCM Back Ends
> +
> + fsl,asrc-format:
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - enum: [2, 6, 10, 32, 36]
> + default: 2
> + description:
> + Defines a mutual sample format used by DPCM Back Ends
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - clock-names
> + - dmas
> + - dma-names
> + - fsl,easrc-ram-script-name
> + - fsl,asrc-rate
> + - fsl,asrc-format
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/imx8mn-clock.h>
> +
> + easrc: easrc@300C0000 {
> + compatible = "fsl,imx8mn-easrc";
> + reg = <0x0 0x300C0000 0x0 0x10000>;
> + interrupts = <0x0 122 0x4>;
> + clocks = <&clk IMX8MN_CLK_ASRC_ROOT>;
> + clock-names = "mem";
> + dmas = <&sdma2 16 23 0> , <&sdma2 17 23 0>,
> + <&sdma2 18 23 0> , <&sdma2 19 23 0>,
> + <&sdma2 20 23 0> , <&sdma2 21 23 0>,
> + <&sdma2 22 23 0> , <&sdma2 23 23 0>;
> + dma-names = "ctx0_rx", "ctx0_tx",
> + "ctx1_rx", "ctx1_tx",
> + "ctx2_rx", "ctx2_tx",
> + "ctx3_rx", "ctx3_tx";
> + fsl,easrc-ram-script-name = "imx/easrc/easrc-imx8mn.bin";
> + fsl,asrc-rate = <8000>;
> + fsl,asrc-format = <2>;
> + };
> --
> 2.21.0
>
^ permalink raw reply
* Re: [PATCH v5 1/7] ASoC: dt-bindings: fsl_asrc: Add new property fsl,asrc-format
From: Rob Herring @ 2020-03-20 17:32 UTC (permalink / raw)
To: Nicolin Chen
Cc: mark.rutland, devicetree, alsa-devel, timur, Xiubo.Lee,
linuxppc-dev, Shengjiu Wang, tiwai, lgirdwood, perex, broonie,
festevam, linux-kernel
In-Reply-To: <20200309211943.GB11333@Asurada-Nvidia.nvidia.com>
On Mon, Mar 09, 2020 at 02:19:44PM -0700, Nicolin Chen wrote:
> On Mon, Mar 09, 2020 at 11:58:28AM +0800, Shengjiu Wang wrote:
> > In order to support new EASRC and simplify the code structure,
> > We decide to share the common structure between them. This bring
> > a problem that EASRC accept format directly from devicetree, but
> > ASRC accept width from devicetree.
> >
> > In order to align with new ESARC, we add new property fsl,asrc-format.
> > The fsl,asrc-format can replace the fsl,asrc-width, then driver
> > can accept format from devicetree, don't need to convert it to
> > format through width.
> >
> > Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> > ---
> > Documentation/devicetree/bindings/sound/fsl,asrc.txt | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/sound/fsl,asrc.txt b/Documentation/devicetree/bindings/sound/fsl,asrc.txt
> > index cb9a25165503..780455cf7f71 100644
> > --- a/Documentation/devicetree/bindings/sound/fsl,asrc.txt
> > +++ b/Documentation/devicetree/bindings/sound/fsl,asrc.txt
> > @@ -51,6 +51,11 @@ Optional properties:
> > will be in use as default. Otherwise, the big endian
> > mode will be in use for all the device registers.
> >
> > + - fsl,asrc-format : Defines a mutual sample format used by DPCM Back
> > + Ends, which can replace the fsl,asrc-width.
> > + The value is SNDRV_PCM_FORMAT_S16_LE, or
> > + SNDRV_PCM_FORMAT_S24_LE
>
> I am still holding the concern at the DT binding of this format,
> as it uses values from ASoC header file instead of a dt-binding
> header file -- not sure if we can do this. Let's wait for Rob's
> comments.
I assume those are an ABI as well, so it's okay to copy them unless we
already have some format definitions for DT. But it does need to be copy
in a header under include/dt-bindings/.
Rob
^ permalink raw reply
* Re: [PATCH v12 8/8] MAINTAINERS: perf: Add pattern that matches ppc perf to the perf entry.
From: Andy Shevchenko @ 2020-03-20 16:47 UTC (permalink / raw)
To: Michal Suchánek
Cc: Mark Rutland, Gustavo Luiz Duarte, Peter Zijlstra,
Sebastian Andrzej Siewior, linux-kernel, Paul Mackerras,
Jiri Olsa, Rob Herring, Michael Neuling, Mauro Carvalho Chehab,
Masahiro Yamada, Nayna Jain, Alexander Shishkin, Ingo Molnar,
Allison Randal, Jordan Niethe, Valentin Schneider, Arnd Bergmann,
Arnaldo Carvalho de Melo, linux-fsdevel, Alexander Viro,
Jonathan Cameron, Namhyung Kim, Thomas Gleixner, Hari Bathini,
Greg Kroah-Hartman, Nicholas Piggin, Claudio Carvalho,
Eric Richter, Eric W. Biederman, Joe Perches, linuxppc-dev,
David S. Miller, Thiago Jung Bauermann
In-Reply-To: <20200320164204.GV25468@kitsune.suse.cz>
On Fri, Mar 20, 2020 at 05:42:04PM +0100, Michal Suchánek wrote:
> On Fri, Mar 20, 2020 at 06:31:57PM +0200, Andy Shevchenko wrote:
> > On Fri, Mar 20, 2020 at 07:42:03AM -0700, Joe Perches wrote:
> > > On Fri, 2020-03-20 at 14:42 +0200, Andy Shevchenko wrote:
> > > > On Fri, Mar 20, 2020 at 12:23:38PM +0100, Michal Suchánek wrote:
> > > > > On Fri, Mar 20, 2020 at 12:33:50PM +0200, Andy Shevchenko wrote:
> > > > > > On Fri, Mar 20, 2020 at 11:20:19AM +0100, Michal Suchanek wrote:
> > > > > > > While at it also simplify the existing perf patterns.
> > > > > > And still missed fixes from parse-maintainers.pl.
> > > > >
> > > > > Oh, that script UX is truly ingenious.
> > > >
> > > > You have at least two options, their combinations, etc:
> > > > - complain to the author :-)
> > > > - send a patch :-)
> > >
> > > Recently:
> > >
> > > https://lore.kernel.org/lkml/4d5291fa3fb4962b1fa55e8fd9ef421ef0c1b1e5.camel@perches.com/
> >
> > But why?
> >
> > Shouldn't we rather run MAINTAINERS clean up once and require people to use
> > parse-maintainers.pl for good?
>
> That cleanup did not happen yet, and I am not volunteering for one.
> The difference between MAINTAINERS and MAINTAINERS.new is:
>
> MAINTAINERS | 5510 +++++++++++++++++++++++++++++------------------------------
> 1 file changed, 2755 insertions(+), 2755 deletions(-)
Yes, it was basically reply to Joe.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v12 8/8] MAINTAINERS: perf: Add pattern that matches ppc perf to the perf entry.
From: Michal Suchánek @ 2020-03-20 16:42 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Mark Rutland, Gustavo Luiz Duarte, Peter Zijlstra,
Sebastian Andrzej Siewior, linux-kernel, Paul Mackerras,
Jiri Olsa, Rob Herring, Michael Neuling, Mauro Carvalho Chehab,
Masahiro Yamada, Nayna Jain, Alexander Shishkin, Ingo Molnar,
Allison Randal, Jordan Niethe, Valentin Schneider, Arnd Bergmann,
Arnaldo Carvalho de Melo, linux-fsdevel, Alexander Viro,
Jonathan Cameron, Namhyung Kim, Thomas Gleixner, Hari Bathini,
Greg Kroah-Hartman, Nicholas Piggin, Claudio Carvalho,
Eric Richter, Eric W. Biederman, Joe Perches, linuxppc-dev,
David S. Miller, Thiago Jung Bauermann
In-Reply-To: <20200320163157.GF1922688@smile.fi.intel.com>
On Fri, Mar 20, 2020 at 06:31:57PM +0200, Andy Shevchenko wrote:
> On Fri, Mar 20, 2020 at 07:42:03AM -0700, Joe Perches wrote:
> > On Fri, 2020-03-20 at 14:42 +0200, Andy Shevchenko wrote:
> > > On Fri, Mar 20, 2020 at 12:23:38PM +0100, Michal Suchánek wrote:
> > > > On Fri, Mar 20, 2020 at 12:33:50PM +0200, Andy Shevchenko wrote:
> > > > > On Fri, Mar 20, 2020 at 11:20:19AM +0100, Michal Suchanek wrote:
> > > > > > While at it also simplify the existing perf patterns.
> > > > > And still missed fixes from parse-maintainers.pl.
> > > >
> > > > Oh, that script UX is truly ingenious.
> > >
> > > You have at least two options, their combinations, etc:
> > > - complain to the author :-)
> > > - send a patch :-)
> >
> > Recently:
> >
> > https://lore.kernel.org/lkml/4d5291fa3fb4962b1fa55e8fd9ef421ef0c1b1e5.camel@perches.com/
>
> But why?
>
> Shouldn't we rather run MAINTAINERS clean up once and require people to use
> parse-maintainers.pl for good?
That cleanup did not happen yet, and I am not volunteering for one.
The difference between MAINTAINERS and MAINTAINERS.new is:
MAINTAINERS | 5510 +++++++++++++++++++++++++++++------------------------------
1 file changed, 2755 insertions(+), 2755 deletions(-)
Thanks
Michal
^ permalink raw reply
* Re: [PATCH v12 8/8] MAINTAINERS: perf: Add pattern that matches ppc perf to the perf entry.
From: Andy Shevchenko @ 2020-03-20 16:31 UTC (permalink / raw)
To: Joe Perches
Cc: Mark Rutland, Gustavo Luiz Duarte, Peter Zijlstra,
Sebastian Andrzej Siewior, linux-kernel, Paul Mackerras,
Jiri Olsa, Rob Herring, Michael Neuling, Mauro Carvalho Chehab,
Masahiro Yamada, Nayna Jain, Alexander Shishkin, Ingo Molnar,
Allison Randal, Jordan Niethe, Michal Suchánek,
Valentin Schneider, Arnd Bergmann, Arnaldo Carvalho de Melo,
Alexander Viro, Jonathan Cameron, Namhyung Kim, Thomas Gleixner,
Hari Bathini, Greg Kroah-Hartman, Nicholas Piggin,
Claudio Carvalho, Eric Richter, Eric W. Biederman, linux-fsdevel,
linuxppc-dev, David S. Miller, Thiago Jung Bauermann
In-Reply-To: <b96c9dd4dba4afca5288a551158659bf545d29fb.camel@perches.com>
On Fri, Mar 20, 2020 at 07:42:03AM -0700, Joe Perches wrote:
> On Fri, 2020-03-20 at 14:42 +0200, Andy Shevchenko wrote:
> > On Fri, Mar 20, 2020 at 12:23:38PM +0100, Michal Suchánek wrote:
> > > On Fri, Mar 20, 2020 at 12:33:50PM +0200, Andy Shevchenko wrote:
> > > > On Fri, Mar 20, 2020 at 11:20:19AM +0100, Michal Suchanek wrote:
> > > > > While at it also simplify the existing perf patterns.
> > > > And still missed fixes from parse-maintainers.pl.
> > >
> > > Oh, that script UX is truly ingenious.
> >
> > You have at least two options, their combinations, etc:
> > - complain to the author :-)
> > - send a patch :-)
>
> Recently:
>
> https://lore.kernel.org/lkml/4d5291fa3fb4962b1fa55e8fd9ef421ef0c1b1e5.camel@perches.com/
But why?
Shouldn't we rather run MAINTAINERS clean up once and require people to use
parse-maintainers.pl for good?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v12 8/8] MAINTAINERS: perf: Add pattern that matches ppc perf to the perf entry.
From: Michal Suchánek @ 2020-03-20 16:28 UTC (permalink / raw)
To: Joe Perches
Cc: Mark Rutland, Gustavo Luiz Duarte, Peter Zijlstra, Jordan Niethe,
Sebastian Andrzej Siewior, Claudio Carvalho, Paul Mackerras,
Jiri Olsa, Rob Herring, Michael Neuling, Mauro Carvalho Chehab,
Masahiro Yamada, Nayna Jain, Alexander Shishkin, Ingo Molnar,
Hari Bathini, Valentin Schneider, Arnd Bergmann,
Arnaldo Carvalho de Melo, Alexander Viro, Jonathan Cameron,
Namhyung Kim, Thomas Gleixner, Andy Shevchenko, Allison Randal,
Greg Kroah-Hartman, Nicholas Piggin, linux-kernel, Eric Richter,
Eric W. Biederman, linux-fsdevel, linuxppc-dev, David S. Miller,
Thiago Jung Bauermann
In-Reply-To: <b96c9dd4dba4afca5288a551158659bf545d29fb.camel@perches.com>
On Fri, Mar 20, 2020 at 07:42:03AM -0700, Joe Perches wrote:
> On Fri, 2020-03-20 at 14:42 +0200, Andy Shevchenko wrote:
> > On Fri, Mar 20, 2020 at 12:23:38PM +0100, Michal Suchánek wrote:
> > > On Fri, Mar 20, 2020 at 12:33:50PM +0200, Andy Shevchenko wrote:
> > > > On Fri, Mar 20, 2020 at 11:20:19AM +0100, Michal Suchanek wrote:
> > > > > While at it also simplify the existing perf patterns.
> > > > And still missed fixes from parse-maintainers.pl.
> > >
> > > Oh, that script UX is truly ingenious.
> >
> > You have at least two options, their combinations, etc:
> > - complain to the author :-)
> > - send a patch :-)
>
> Recently:
>
> https://lore.kernel.org/lkml/4d5291fa3fb4962b1fa55e8fd9ef421ef0c1b1e5.camel@perches.com/
Can we expect that reaordering is taken care of in that discussion then?
Thanks
Michal
^ permalink raw reply
* Re: [patch V2 08/15] Documentation: Add lock ordering and nesting documentation
From: Paul E. McKenney @ 2020-03-20 16:01 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Randy Dunlap, Peter Zijlstra, linux-pci,
Sebastian Andrzej Siewior, Oleg Nesterov, Joel Fernandes,
Will Deacon, Ingo Molnar, Davidlohr Bueso, Logan Gunthorpe,
Arnd Bergmann, linuxppc-dev, Steven Rostedt, Bjorn Helgaas,
Kurt Schwemmer, Kalle Valo, Felipe Balbi, Greg Kroah-Hartman,
linux-usb, linux-wireless, LKML, netdev, Linus Torvalds,
David S. Miller
In-Reply-To: <874kuk5il2.fsf@nanos.tec.linutronix.de>
On Thu, Mar 19, 2020 at 07:02:17PM +0100, Thomas Gleixner wrote:
> Paul,
>
> "Paul E. McKenney" <paulmck@kernel.org> writes:
>
> > On Wed, Mar 18, 2020 at 09:43:10PM +0100, Thomas Gleixner wrote:
> >
> > Mostly native-English-speaker services below, so please feel free to
> > ignore. The one place I made a substantive change, I marked it "@@@".
> > I only did about half of this document, but should this prove useful,
> > I will do the other half later.
>
> Native speaker services are always useful and appreciated.
Glad it is helpful. ;-)
[ . . . ]
> >> +
> >> +raw_spinlock_t and spinlock_t
> >> +=============================
> >> +
> >> +raw_spinlock_t
> >> +--------------
> >> +
> >> +raw_spinlock_t is a strict spinning lock implementation regardless of the
> >> +kernel configuration including PREEMPT_RT enabled kernels.
> >> +
> >> +raw_spinlock_t is to be used only in real critical core code, low level
> >> +interrupt handling and places where protecting (hardware) state is required
> >> +to be safe against preemption and eventually interrupts.
> >> +
> >> +Another reason to use raw_spinlock_t is when the critical section is tiny
> >> +to avoid the overhead of spinlock_t on a PREEMPT_RT enabled kernel in the
> >> +contended case.
> >
> > raw_spinlock_t is a strict spinning lock implementation in all kernels,
> > including PREEMPT_RT kernels. Use raw_spinlock_t only in real critical
> > core code, low level interrupt handling and places where disabling
> > preemption or interrupts is required, for example, to safely access
> > hardware state. raw_spinlock_t can sometimes also be used when the
> > critical section is tiny and the lock is lightly contended, thus avoiding
> > RT-mutex overhead.
> >
> > @@@ I added the point about the lock being lightly contended.
>
> Hmm, not sure. The point is that if the critical section is small the
> overhead of cross CPU boosting along with the resulting IPIs is going to
> be at least an order of magnitude larger. And on contention this is just
> pushing the raw_spinlock contention off to the raw_spinlock in the rt
> mutex plus the owning tasks pi_lock which makes things even worse.
Fair enough. So, leaving that out:
raw_spinlock_t is a strict spinning lock implementation in all kernels,
including PREEMPT_RT kernels. Use raw_spinlock_t only in real critical
core code, low level interrupt handling and places where disabling
preemption or interrupts is required, for example, to safely access
hardware state. In addition, raw_spinlock_t can sometimes be used when
the critical section is tiny, thus avoiding RT-mutex overhead.
> >> + - The hard interrupt related suffixes for spin_lock / spin_unlock
> >> + operations (_irq, _irqsave / _irqrestore) do not affect the CPUs
>
> Si senor!
;-)
> >> + interrupt disabled state
> >> +
> >> + - The soft interrupt related suffix (_bh()) is still disabling the
> >> + execution of soft interrupts, but contrary to a non PREEMPT_RT enabled
> >> + kernel, which utilizes the preemption count, this is achieved by a per
> >> + CPU bottom half locking mechanism.
> >
> > - The soft interrupt related suffix (_bh()) still disables softirq
> > handlers. However, unlike non-PREEMPT_RT kernels (which disable
> > preemption to get this effect), PREEMPT_RT kernels use a per-CPU
> > per-bottom-half locking mechanism.
>
> it's not per-bottom-half anymore. That turned out to be dangerous due to
> dependencies between BH types, e.g. network and timers.
Ah! OK, how about this?
- The soft interrupt related suffix (_bh()) still disables softirq
handlers. However, unlike non-PREEMPT_RT kernels (which disable
preemption to get this effect), PREEMPT_RT kernels use a per-CPU
lock to exclude softirq handlers.
> I hope I was able to encourage you to comment on the other half as well :)
OK, here goes...
> +All other semantics of spinlock_t are preserved:
> +
> + - Migration of tasks which hold a spinlock_t is prevented. On a non
> + PREEMPT_RT enabled kernel this is implicit due to preemption disable.
> + PREEMPT_RT has a separate mechanism to achieve this. This ensures that
> + pointers to per CPU variables stay valid even if the task is preempted.
> +
> + - Task state preservation. The task state is not affected when a lock is
> + contended and the task has to schedule out and wait for the lock to
> + become available. The lock wake up restores the task state unless there
> + was a regular (not lock related) wake up on the task. This ensures that
> + the task state rules are always correct independent of the kernel
> + configuration.
How about this?
PREEMPT_RT kernels preserve all other spinlock_t semantics:
- Tasks holding a spinlock_t do not migrate. Non-PREEMPT_RT kernels
avoid migration by disabling preemption. PREEMPT_RT kernels instead
disable migration, which ensures that pointers to per-CPU variables
remain valid even if the task is preempted.
- Task state is preserved across spinlock acquisition, ensuring that the
task-state rules apply to all kernel configurations. In non-PREEMPT_RT
kernels leave task state untouched. However, PREEMPT_RT must change
task state if the task blocks during acquisition. Therefore, the
corresponding lock wakeup restores the task state. Note that regular
(not lock related) wakeups do not restore task state.
> +rwlock_t
> +========
> +
> +rwlock_t is a multiple readers and single writer lock mechanism.
> +
> +On a non PREEMPT_RT enabled kernel rwlock_t is implemented as a spinning
> +lock and the suffix rules of spinlock_t apply accordingly. The
> +implementation is fair and prevents writer starvation.
Non-PREEMPT_RT kernels implement rwlock_t as a spinning lock and the
suffix rules of spinlock_t apply accordingly. The implementation is fair,
thus preventing writer starvation.
> +rwlock_t and PREEMPT_RT
> +-----------------------
> +
> +On a PREEMPT_RT enabled kernel rwlock_t is mapped to a separate
> +implementation based on rt_mutex which changes the semantics:
> +
> + - Same changes as for spinlock_t
> +
> + - The implementation is not fair and can cause writer starvation under
> + certain circumstances. The reason for this is that a writer cannot grant
> + its priority to multiple readers. Readers which are blocked on a writer
> + fully support the priority inheritance protocol.
PREEMPT_RT kernels map rwlock_t to a separate rt_mutex-based
implementation, thus changing semantics:
- All the spinlock_t changes also apply to rwlock_t.
- Because an rwlock_t writer cannot grant its priority to multiple
readers, a preempted low-priority reader will continue holding its
lock, thus starving even high-priority writers. In contrast, because
readers can grant their priority to a writer, a preempted low-priority
writer will have its priority boosted until it releases the lock,
thus preventing that writer from starving readers.
> +PREEMPT_RT caveats
> +==================
> +
> +spinlock_t and rwlock_t
> +-----------------------
> +
> +The substitution of spinlock_t and rwlock_t on PREEMPT_RT enabled kernels
> +with RT-mutex based implementations has a few implications.
> +
> +On a non PREEMPT_RT enabled kernel the following code construct is
> +perfectly fine::
These changes in spinlock_t and rwlock_t semantics on PREEMPT_RT kernels
have a few implications. For example, on a non-PREEMPT_RT kernel the
following code sequence works as expected::
> + local_irq_disable();
> + spin_lock(&lock);
> +
> +and fully equivalent to::
and is fully equivalent to::
> + spin_lock_irq(&lock);
> +
> +Same applies to rwlock_t and the _irqsave() suffix variant.
The same applies to rwlock_t and its _irqsave() variant.
> +On a PREEMPT_RT enabled kernel this breaks because the RT-mutex
> +substitution expects a fully preemptible context.
> +
> +The preferred solution is to use :c:func:`spin_lock_irq()` or
> +:c:func:`spin_lock_irqsave()` and their unlock counterparts.
> +
> +PREEMPT_RT also offers a local_lock mechanism to substitute the
> +local_irq_disable/save() constructs in cases where a separation of the
> +interrupt disabling and the locking is really unavoidable. This should be
> +restricted to very rare cases.
On PREEMPT_RT kernel this code sequence breaks because RT-mutex
requires a fully preemptible context. Instead, use spin_lock_irq() or
spin_lock_irqsave() and their unlock counterparts. In cases where the
interrupt disabling and locking must remain separate, PREEMPT_RT offers
a local_lock mechanism. Acquiring the local_lock pins the task to a
CPU, allowing things like per-CPU irq-disabled locks to be acquired.
However, this approach should be used only where absolutely necessary.
> +raw_spinlock_t
> +--------------
> +
> +Locking of a raw_spinlock_t disables preemption and eventually interrupts.
> +Therefore code inside the critical region has to be careful to avoid calls
> +into code which takes a regular spinlock_t or rwlock_t. A prime example is
> +memory allocation.
> +
> +On a non PREEMPT_RT enabled kernel the following code construct is
> +perfectly fine code::
Acquiring a raw_spinlock_t disables preemption and possibly also
interrupts, so the critical section must avoid acquiring a regular
spinlock_t or rwlock_t, for example, the critical section must avoid
allocating memory. Thus, on a non-PREEMPT_RT kernel the following code
works perfectly::
> + raw_spin_lock(&lock);
> + p = kmalloc(sizeof(*p), GFP_ATOMIC);
> +
> +On a PREEMPT_RT enabled kernel this breaks because the memory allocator is
> +fully preemptible and therefore does not support allocations from truly
> +atomic contexts.
> +
> +Contrary to that the following code construct is perfectly fine on
> +PREEMPT_RT as spin_lock() does not disable preemption::
But this code failes on PREEMPT_RT kernels because the memory allocator
is fully preemptible and therefore cannot be invoked from truly atomic
contexts. However, it is perfectly fine to invoke the memory allocator
while holding a normal non-raw spinlocks because they do not disable
preemption::
> + spin_lock(&lock);
> + p = kmalloc(sizeof(*p), GFP_ATOMIC);
> +
> +Most places which use GFP_ATOMIC allocations are safe on PREEMPT_RT as the
> +execution is forced into thread context and the lock substitution is
> +ensuring preemptibility.
Interestingly enough, most uses of GFP_ATOMIC allocations are
actually safe on PREEMPT_RT because the the lock substitution ensures
preemptibility. Only those GFP_ATOMIC allocations that are invoke
while holding a raw spinlock or with preemption otherwise disabled need
adjustment to work correctly on PREEMPT_RT.
[ I am not as confident of the above as I would like to be... ]
And meeting time, will continue later!
Thanx, Paul
> +bit spinlocks
> +-------------
> +
> +Bit spinlocks are problematic for PREEMPT_RT as they cannot be easily
> +substituted by an RT-mutex based implementation for obvious reasons.
> +
> +The semantics of bit spinlocks are preserved on a PREEMPT_RT enabled kernel
> +and the caveats vs. raw_spinlock_t apply.
> +
> +Some bit spinlocks are substituted by regular spinlock_t for PREEMPT_RT but
> +this requires conditional (#ifdef'ed) code changes at the usage side while
> +the spinlock_t substitution is simply done by the compiler and the
> +conditionals are restricted to header files and core implementation of the
> +locking primitives and the usage sites do not require any changes.
> +
> +
> +Lock type nesting rules
> +=======================
> +
> +The most basic rules are:
> +
> + - Lock types of the same lock category (sleeping, spinning) can nest
> + arbitrarily as long as they respect the general lock ordering rules to
> + prevent deadlocks.
> +
> + - Sleeping lock types cannot nest inside spinning lock types.
> +
> + - Spinning lock types can nest inside sleeping lock types.
> +
> +These rules apply in general independent of CONFIG_PREEMPT_RT.
> +
> +As PREEMPT_RT changes the lock category of spinlock_t and rwlock_t from
> +spinning to sleeping this has obviously restrictions how they can nest with
> +raw_spinlock_t.
> +
> +This results in the following nest ordering:
> +
> + 1) Sleeping locks
> + 2) spinlock_t and rwlock_t
> + 3) raw_spinlock_t and bit spinlocks
> +
> +Lockdep is aware of these constraints to ensure that they are respected.
> +
> +
> +Owner semantics
> +===============
> +
> +Most lock types in the Linux kernel have strict owner semantics, i.e. the
> +context (task) which acquires a lock has to release it.
> +
> +There are two exceptions:
> +
> + - semaphores
> + - rwsems
> +
> +semaphores have no strict owner semantics for historical reasons. They are
> +often used for both serialization and waiting purposes. That's generally
> +discouraged and should be replaced by separate serialization and wait
> +mechanisms.
> +
> +rwsems have grown interfaces which allow non owner release for special
> +purposes. This usage is problematic on PREEMPT_RT because PREEMPT_RT
> +substitutes all locking primitives except semaphores with RT-mutex based
> +implementations to provide priority inheritance for all lock types except
> +the truly spinning ones. Priority inheritance on ownerless locks is
> +obviously impossible.
> +
> +For now the rwsem non-owner release excludes code which utilizes it from
> +being used on PREEMPT_RT enabled kernels. In same cases this can be
> +mitigated by disabling portions of the code, in other cases the complete
> +functionality has to be disabled until a workable solution has been found.
>
^ permalink raw reply
* Re: [PATCH] powerpc/pseries: avoid harmless preempt warning
From: Christophe Leroy @ 2020-03-20 15:33 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev
In-Reply-To: <20200320152436.1468651-1-npiggin@gmail.com>
Le 20/03/2020 à 16:24, Nicholas Piggin a écrit :
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> arch/powerpc/platforms/pseries/lpar.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c
> index 3c3da25b445c..e4ed5317f117 100644
> --- a/arch/powerpc/platforms/pseries/lpar.c
> +++ b/arch/powerpc/platforms/pseries/lpar.c
> @@ -636,8 +636,16 @@ static const struct proc_ops vcpudispatch_stats_freq_proc_ops = {
>
> static int __init vcpudispatch_stats_procfs_init(void)
> {
> - if (!lppaca_shared_proc(get_lppaca()))
> + /*
> + * Avoid smp_processor_id while preemptible. All CPUs should have
> + * the same value for lppaca_shared_proc.
> + */
> + preempt_disable();
> + if (!lppaca_shared_proc(get_lppaca())) {
> + preempt_enable();
> return 0;
> + }
> + preempt_enable();
Can we avoid the double preempt_enable() with something like:
preempt_disable();
is_shared = lppaca_shared_proc(get_lppaca());
preempt_enable();
if (!is_shared)
return 0;
>
> if (!proc_create("powerpc/vcpudispatch_stats", 0600, NULL,
> &vcpudispatch_stats_proc_ops))
>
Christophe
^ permalink raw reply
* [PATCH] powerpc/64: allow rtas to be called in real-mode, use this in machine check
From: Nicholas Piggin @ 2020-03-20 15:28 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Mahesh Salgaonkar, Ganesh Goudar, Nicholas Piggin
rtas_call allocates and uses memory in failure paths, which is
not safe for RMA. It also calls local_irq_save() which may not be safe
in all real mode contexts.
Particularly machine check may run with interrupts not "reconciled",
and it may have hit while it was in tracing code that should not be
rentered.
Create minimal rtas call that should be usable by guest machine check
code, use it there to call "ibm,nmi-interlock".
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/include/asm/rtas.h | 1 +
arch/powerpc/kernel/entry_64.S | 12 ++++++--
arch/powerpc/kernel/rtas.c | 43 ++++++++++++++++++++++++++++
arch/powerpc/platforms/pseries/ras.c | 2 +-
4 files changed, 54 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/rtas.h b/arch/powerpc/include/asm/rtas.h
index 3c1887351c71..4ffc499ce1ac 100644
--- a/arch/powerpc/include/asm/rtas.h
+++ b/arch/powerpc/include/asm/rtas.h
@@ -352,6 +352,7 @@ extern struct rtas_t rtas;
extern int rtas_token(const char *service);
extern int rtas_service_present(const char *service);
extern int rtas_call(int token, int, int, int *, ...);
+extern int raw_rtas_call(int token, int, int, int *, ...);
void rtas_call_unlocked(struct rtas_args *args, int token, int nargs,
int nret, ...);
extern void __noreturn rtas_restart(char *cmd);
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 51c5b681f70c..309abb677788 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -759,6 +759,13 @@ _GLOBAL(enter_rtas)
li r0,0
mtcr r0
+ /* enter_rtas called from real-mode may not have irqs reconciled
+ * but will always have interrupts disabled.
+ */
+ mfmsr r6
+ andi. r7,r6,(MSR_IR|MSR_DR)
+ beq 2f
+
#ifdef CONFIG_BUG
/* There is no way it is acceptable to get here with interrupts enabled,
* check it with the asm equivalent of WARN_ON
@@ -769,10 +776,10 @@ _GLOBAL(enter_rtas)
#endif
/* Hard-disable interrupts */
- mfmsr r6
rldicl r7,r6,48,1
rotldi r7,r7,16
mtmsrd r7,1
+2:
/* Unfortunately, the stack pointer and the MSR are also clobbered,
* so they are saved in the PACA which allows us to restore
@@ -795,7 +802,6 @@ _GLOBAL(enter_rtas)
ori r9,r9,MSR_IR|MSR_DR|MSR_FE0|MSR_FE1|MSR_FP|MSR_RI|MSR_LE
andc r6,r0,r9
-__enter_rtas:
sync /* disable interrupts so SRR0/1 */
mtmsrd r0 /* don't get trashed */
@@ -837,7 +843,7 @@ rtas_return_loc:
mtspr SPRN_SRR1,r4
RFI_TO_KERNEL
b . /* prevent speculative execution */
-_ASM_NOKPROBE_SYMBOL(__enter_rtas)
+_ASM_NOKPROBE_SYMBOL(enter_rtas)
_ASM_NOKPROBE_SYMBOL(rtas_return_loc)
.align 3
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index c5fa251b8950..a058dcfb6726 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -450,6 +450,8 @@ int rtas_call(int token, int nargs, int nret, int *outputs, ...)
char *buff_copy = NULL;
int ret;
+ WARN_ON_ONCE((mfmsr() & (MSR_IR|MSR_DR)) != (MSR_IR|MSR_DR));
+
if (!rtas.entry || token == RTAS_UNKNOWN_SERVICE)
return -1;
@@ -483,6 +485,47 @@ int rtas_call(int token, int nargs, int nret, int *outputs, ...)
}
EXPORT_SYMBOL(rtas_call);
+/*
+ * Like rtas_call but no kmalloc or printk etc in error handling, so
+ * error won't go through log_error. No tracing, may be called in real mode.
+ */
+int notrace raw_rtas_call(int token, int nargs, int nret, int *outputs, ...)
+{
+ va_list list;
+ int i;
+ struct rtas_args *rtas_args;
+ int ret;
+
+ WARN_ON_ONCE((mfmsr() & MSR_EE));
+
+ if (!rtas.entry || token == RTAS_UNKNOWN_SERVICE)
+ return -1;
+
+ /*
+ * Real mode must have MSR[EE]=0 and we prefer not to touch any
+ * irq or preempt state (this may be called in machine check).
+ */
+ preempt_disable_notrace();
+ arch_spin_lock(&rtas.lock);
+
+ /* We use the global rtas args buffer */
+ rtas_args = &rtas.args;
+
+ va_start(list, outputs);
+ va_rtas_call_unlocked(rtas_args, token, nargs, nret, list);
+ va_end(list);
+
+ if (nret > 1 && outputs != NULL)
+ for (i = 0; i < nret-1; ++i)
+ outputs[i] = be32_to_cpu(rtas_args->rets[i+1]);
+ ret = (nret > 0)? be32_to_cpu(rtas_args->rets[0]): 0;
+
+ arch_spin_unlock(&rtas.lock);
+ preempt_enable_notrace();
+
+ return ret;
+}
+
/* For RTAS_BUSY (-2), delay for 1 millisecond. For an extended busy status
* code of 990n, perform the hinted delay of 10^n (last digit) milliseconds.
*/
diff --git a/arch/powerpc/platforms/pseries/ras.c b/arch/powerpc/platforms/pseries/ras.c
index c74d5e740922..e87f86f02569 100644
--- a/arch/powerpc/platforms/pseries/ras.c
+++ b/arch/powerpc/platforms/pseries/ras.c
@@ -458,7 +458,7 @@ static struct rtas_error_log *fwnmi_get_errinfo(struct pt_regs *regs)
*/
static void fwnmi_release_errinfo(void)
{
- int ret = rtas_call(ibm_nmi_interlock_token, 0, 1, NULL);
+ int ret = raw_rtas_call(ibm_nmi_interlock_token, 0, 1, NULL);
if (ret != 0)
printk(KERN_ERR "FWNMI: nmi-interlock failed: %d\n", ret);
}
--
2.23.0
^ permalink raw reply related
* [PATCH] powerpc/64: ftrace don't trace real mode
From: Nicholas Piggin @ 2020-03-20 15:25 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Naveen N . Rao, Nicholas Piggin
This warns and prevents tracing attempted in a real-mode context.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/kernel/trace/ftrace.c | 3 +++
.../powerpc/kernel/trace/ftrace_64_mprofile.S | 19 +++++++++++++++----
2 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/trace/ftrace.c b/arch/powerpc/kernel/trace/ftrace.c
index 7ea0ca044b65..ef965815fcb9 100644
--- a/arch/powerpc/kernel/trace/ftrace.c
+++ b/arch/powerpc/kernel/trace/ftrace.c
@@ -949,6 +949,9 @@ unsigned long prepare_ftrace_return(unsigned long parent, unsigned long ip,
{
unsigned long return_hooker;
+ if (WARN_ON_ONCE((mfmsr() & (MSR_IR|MSR_DR)) != (MSR_IR|MSR_DR)))
+ goto out;
+
if (unlikely(ftrace_graph_is_dead()))
goto out;
diff --git a/arch/powerpc/kernel/trace/ftrace_64_mprofile.S b/arch/powerpc/kernel/trace/ftrace_64_mprofile.S
index f9fd5f743eba..6205f15cb603 100644
--- a/arch/powerpc/kernel/trace/ftrace_64_mprofile.S
+++ b/arch/powerpc/kernel/trace/ftrace_64_mprofile.S
@@ -51,16 +51,21 @@ _GLOBAL(ftrace_regs_caller)
SAVE_10GPRS(12, r1)
SAVE_10GPRS(22, r1)
- /* Save previous stack pointer (r1) */
- addi r8, r1, SWITCH_FRAME_SIZE
- std r8, GPR1(r1)
-
/* Load special regs for save below */
mfmsr r8
mfctr r9
mfxer r10
mfcr r11
+ /* Shouldn't be called in real mode */
+ andi. r3,r8,(MSR_IR|MSR_DR)
+ cmpdi r3,(MSR_IR|MSR_DR)
+ bne ftrace_bad_realmode
+
+ /* Save previous stack pointer (r1) */
+ addi r8, r1, SWITCH_FRAME_SIZE
+ std r8, GPR1(r1)
+
/* Get the _mcount() call site out of LR */
mflr r7
/* Save it as pt_regs->nip */
@@ -141,6 +146,12 @@ _GLOBAL(ftrace_graph_stub)
_GLOBAL(ftrace_stub)
blr
+ftrace_bad_realmode:
+ REST_4GPRS(8, r1)
+#ifdef CONFIG_BUG
+1: trap
+ EMIT_BUG_ENTRY 1b,__FILE__,__LINE__,(BUGFLAG_WARNING | BUGFLAG_ONCE)
+#endif
ftrace_no_trace:
mflr r3
mtctr r3
--
2.23.0
^ permalink raw reply related
* Re: [PATCH] arch/powerpc/64: Avoid isync in flush_dcache_range
From: Segher Boessenkool @ 2020-03-20 15:27 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev
In-Reply-To: <c98c0044-39ec-452d-34db-f7284e4497df@linux.ibm.com>
On Fri, Mar 20, 2020 at 08:38:42PM +0530, Aneesh Kumar K.V wrote:
> On 3/20/20 8:35 PM, Segher Boessenkool wrote:
> >On Fri, Mar 20, 2020 at 04:02:42PM +0530, Aneesh Kumar K.V wrote:
> >>As per ISA and isync is only needed on instruction cache
> >>block invalidate. Remove the same from dcache invalidate.
> >
> >Is that true on older CPUs?
> >
>
> That is what I found by checking with hardware team.
Oh, the comment right before this function says "does not invalidat
the corresponding insncache blocks", so this looks fine, sorry for not
looking closely enough before.
> One thing i was not
> able to get full confirmation about was the usage of 'sync' before 'dcbf'.
Yeah, this looks like something that would matter on some implementations.
Would it make anything measurably faster if you would remove that sync?
Segher
^ permalink raw reply
* [PATCH] powerpc/pseries: avoid harmless preempt warning
From: Nicholas Piggin @ 2020-03-20 15:24 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/platforms/pseries/lpar.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c
index 3c3da25b445c..e4ed5317f117 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -636,8 +636,16 @@ static const struct proc_ops vcpudispatch_stats_freq_proc_ops = {
static int __init vcpudispatch_stats_procfs_init(void)
{
- if (!lppaca_shared_proc(get_lppaca()))
+ /*
+ * Avoid smp_processor_id while preemptible. All CPUs should have
+ * the same value for lppaca_shared_proc.
+ */
+ preempt_disable();
+ if (!lppaca_shared_proc(get_lppaca())) {
+ preempt_enable();
return 0;
+ }
+ preempt_enable();
if (!proc_create("powerpc/vcpudispatch_stats", 0600, NULL,
&vcpudispatch_stats_proc_ops))
--
2.23.0
^ permalink raw reply related
* [PATCH v2 1/2] docs: prevent warnings due to autosectionlabel
From: Mauro Carvalho Chehab @ 2020-03-20 15:11 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Ricardo Ribalda Delgado, Harry Wei, Paul Mackerras,
H. Peter Anvin, Alex Shi, dmaengine, linux-scsi, Jonathan Corbet,
Mauro Carvalho Chehab, x86, Tyler Hicks, Ingo Molnar,
Jakub Kicinski, Jacopo Mondi, Johannes Berg, ecryptfs,
Matthias Maennich, Luca Ceresoli, Borislav Petkov,
Thomas Gleixner, Martin K. Petersen, Greg Kroah-Hartman,
linux-kernel, Vinod Koul, target-devel, netdev, Hans Verkuil,
linuxppc-dev, David S. Miller, Madhuparna Bhowmik
In-Reply-To: <cover.1584716446.git.mchehab+huawei@kernel.org>
Changeset 58ad30cf91f0 ("docs: fix reference to core-api/namespaces.rst")
enabled a new feature at Sphinx: it will now generate index for each
document title, plus to each chapter inside it.
There's a drawback, though: one document cannot have two sections
with the same name anymore.
A followup patch will change the logic of autosectionlabel to
avoid most creating references for every single section title,
but still we need to be able to reference the chapters inside
a document.
There are a few places where there are two chapters with the
same name. This patch renames one of the chapters, in order to
avoid symbol conflict within the same document.
PS.: as I don't speach Chinese, I had some help from a friend
(Wen Liu) at the Chinese translation for "publishing patches"
for this document:
Documentation/translations/zh_CN/process/5.Posting.rst
Fixes: 58ad30cf91f0 ("docs: fix reference to core-api/namespaces.rst")
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
Documentation/driver-api/80211/mac80211-advanced.rst | 8 ++++----
Documentation/driver-api/dmaengine/index.rst | 4 ++--
Documentation/filesystems/ecryptfs.rst | 11 +++++------
Documentation/kernel-hacking/hacking.rst | 4 ++--
Documentation/media/kapi/v4l2-controls.rst | 8 ++++----
Documentation/networking/snmp_counter.rst | 4 ++--
Documentation/powerpc/ultravisor.rst | 4 ++--
Documentation/security/siphash.rst | 8 ++++----
Documentation/target/tcmu-design.rst | 6 +++---
.../translations/zh_CN/process/5.Posting.rst | 2 +-
Documentation/x86/intel-iommu.rst | 3 ++-
11 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/Documentation/driver-api/80211/mac80211-advanced.rst b/Documentation/driver-api/80211/mac80211-advanced.rst
index 9f1c5bb7ac35..24cb64b3b715 100644
--- a/Documentation/driver-api/80211/mac80211-advanced.rst
+++ b/Documentation/driver-api/80211/mac80211-advanced.rst
@@ -272,8 +272,8 @@ STA information lifetime rules
.. kernel-doc:: net/mac80211/sta_info.c
:doc: STA information lifetime rules
-Aggregation
-===========
+Aggregation Functions
+=====================
.. kernel-doc:: net/mac80211/sta_info.h
:functions: sta_ampdu_mlme
@@ -284,8 +284,8 @@ Aggregation
.. kernel-doc:: net/mac80211/sta_info.h
:functions: tid_ampdu_rx
-Synchronisation
-===============
+Synchronisation Functions
+=========================
TBD
diff --git a/Documentation/driver-api/dmaengine/index.rst b/Documentation/driver-api/dmaengine/index.rst
index b9df904d0a79..bdc45d8b4cfb 100644
--- a/Documentation/driver-api/dmaengine/index.rst
+++ b/Documentation/driver-api/dmaengine/index.rst
@@ -5,8 +5,8 @@ DMAEngine documentation
DMAEngine documentation provides documents for various aspects of DMAEngine
framework.
-DMAEngine documentation
------------------------
+DMAEngine development documentation
+-----------------------------------
This book helps with DMAengine internal APIs and guide for DMAEngine device
driver writers.
diff --git a/Documentation/filesystems/ecryptfs.rst b/Documentation/filesystems/ecryptfs.rst
index 7236172300ef..1f2edef4c57a 100644
--- a/Documentation/filesystems/ecryptfs.rst
+++ b/Documentation/filesystems/ecryptfs.rst
@@ -30,13 +30,12 @@ Userspace requirements include:
- Libgcrypt
-Notes
-=====
+.. note::
-In the beta/experimental releases of eCryptfs, when you upgrade
-eCryptfs, you should copy the files to an unencrypted location and
-then copy the files back into the new eCryptfs mount to migrate the
-files.
+ In the beta/experimental releases of eCryptfs, when you upgrade
+ eCryptfs, you should copy the files to an unencrypted location and
+ then copy the files back into the new eCryptfs mount to migrate the
+ files.
Mount-wide Passphrase
diff --git a/Documentation/kernel-hacking/hacking.rst b/Documentation/kernel-hacking/hacking.rst
index d707a0a61cc9..eed2136d847f 100644
--- a/Documentation/kernel-hacking/hacking.rst
+++ b/Documentation/kernel-hacking/hacking.rst
@@ -601,7 +601,7 @@ Defined in ``include/linux/export.h``
This is the variant of `EXPORT_SYMBOL()` that allows specifying a symbol
namespace. Symbol Namespaces are documented in
-:ref:`Documentation/core-api/symbol-namespaces.rst <Symbol Namespaces>`
+:doc:`../core-api/symbol-namespaces`
:c:func:`EXPORT_SYMBOL_NS_GPL()`
--------------------------------
@@ -610,7 +610,7 @@ Defined in ``include/linux/export.h``
This is the variant of `EXPORT_SYMBOL_GPL()` that allows specifying a symbol
namespace. Symbol Namespaces are documented in
-:ref:`Documentation/core-api/symbol-namespaces.rst <Symbol Namespaces>`
+:doc:`../core-api/symbol-namespaces`
Routines and Conventions
========================
diff --git a/Documentation/media/kapi/v4l2-controls.rst b/Documentation/media/kapi/v4l2-controls.rst
index b20800cae3f2..5129019afb49 100644
--- a/Documentation/media/kapi/v4l2-controls.rst
+++ b/Documentation/media/kapi/v4l2-controls.rst
@@ -291,8 +291,8 @@ and QUERYMENU. And G/S_CTRL as well as G/TRY/S_EXT_CTRLS are automatically suppo
In practice the basic usage as described above is sufficient for most drivers.
-Inheriting Controls
--------------------
+Inheriting Sub-device Controls
+------------------------------
When a sub-device is registered with a V4L2 driver by calling
v4l2_device_register_subdev() and the ctrl_handler fields of both v4l2_subdev
@@ -757,8 +757,8 @@ attempting to find another control from the same handler will deadlock.
It is recommended not to use this function from inside the control ops.
-Inheriting Controls
--------------------
+Preventing Controls inheritance
+-------------------------------
When one control handler is added to another using v4l2_ctrl_add_handler, then
by default all controls from one are merged to the other. But a subdev might
diff --git a/Documentation/networking/snmp_counter.rst b/Documentation/networking/snmp_counter.rst
index 38a4edc4522b..10e11099e74a 100644
--- a/Documentation/networking/snmp_counter.rst
+++ b/Documentation/networking/snmp_counter.rst
@@ -908,8 +908,8 @@ A TLP probe packet is sent.
A packet loss is detected and recovered by TLP.
-TCP Fast Open
-=============
+TCP Fast Open description
+=========================
TCP Fast Open is a technology which allows data transfer before the
3-way handshake complete. Please refer the `TCP Fast Open wiki`_ for a
general description.
diff --git a/Documentation/powerpc/ultravisor.rst b/Documentation/powerpc/ultravisor.rst
index 363736d7fd36..df136c8f91fa 100644
--- a/Documentation/powerpc/ultravisor.rst
+++ b/Documentation/powerpc/ultravisor.rst
@@ -8,8 +8,8 @@ Protected Execution Facility
.. contents::
:depth: 3
-Protected Execution Facility
-############################
+Introduction
+############
Protected Execution Facility (PEF) is an architectural change for
POWER 9 that enables Secure Virtual Machines (SVMs). DD2.3 chips
diff --git a/Documentation/security/siphash.rst b/Documentation/security/siphash.rst
index 9965821ab333..4eba68cdf0a1 100644
--- a/Documentation/security/siphash.rst
+++ b/Documentation/security/siphash.rst
@@ -128,8 +128,8 @@ then when you can be absolutely certain that the outputs will never be
transmitted out of the kernel. This is only remotely useful over `jhash` as a
means of mitigating hashtable flooding denial of service attacks.
-Generating a key
-================
+Generating a HalfSipHash key
+============================
Keys should always be generated from a cryptographically secure source of
random numbers, either using get_random_bytes or get_random_once:
@@ -139,8 +139,8 @@ get_random_bytes(&key, sizeof(key));
If you're not deriving your key from here, you're doing it wrong.
-Using the functions
-===================
+Using the HalfSipHash functions
+===============================
There are two variants of the function, one that takes a list of integers, and
one that takes a buffer::
diff --git a/Documentation/target/tcmu-design.rst b/Documentation/target/tcmu-design.rst
index a7b426707bf6..e47047e32e27 100644
--- a/Documentation/target/tcmu-design.rst
+++ b/Documentation/target/tcmu-design.rst
@@ -5,7 +5,7 @@ TCM Userspace Design
.. Contents:
- 1) TCM Userspace Design
+ 1) Design
a) Background
b) Benefits
c) Design constraints
@@ -23,8 +23,8 @@ TCM Userspace Design
3) A final note
-TCM Userspace Design
-====================
+Design
+======
TCM is another name for LIO, an in-kernel iSCSI target (server).
Existing TCM targets run in the kernel. TCMU (TCM in Userspace)
diff --git a/Documentation/translations/zh_CN/process/5.Posting.rst b/Documentation/translations/zh_CN/process/5.Posting.rst
index 41aba21ff050..9ff9945f918c 100644
--- a/Documentation/translations/zh_CN/process/5.Posting.rst
+++ b/Documentation/translations/zh_CN/process/5.Posting.rst
@@ -5,7 +5,7 @@
.. _cn_development_posting:
-发送补丁
+发布补丁
========
迟早，当您的工作准备好提交给社区进行审查，并最终包含到主线内核中时。不出所料，
diff --git a/Documentation/x86/intel-iommu.rst b/Documentation/x86/intel-iommu.rst
index 9dae6b47e398..099f13d51d5f 100644
--- a/Documentation/x86/intel-iommu.rst
+++ b/Documentation/x86/intel-iommu.rst
@@ -95,9 +95,10 @@ and any RMRR's processed::
When DMAR is enabled for use, you will notice..
PCI-DMA: Using DMAR IOMMU
+-------------------------
Fault reporting
----------------
+^^^^^^^^^^^^^^^
::
--
2.24.1
^ permalink raw reply related
* [PATCH v2 0/2] Don't generate thousands of new warnings when building docs
From: Mauro Carvalho Chehab @ 2020-03-20 15:11 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Ricardo Ribalda Delgado, target-devel, Paul Mackerras,
H. Peter Anvin, Alex Shi, linux-scsi, Jonathan Corbet,
Mauro Carvalho Chehab, x86, Tyler Hicks, Ingo Molnar,
Jakub Kicinski, Jacopo Mondi, Luca Ceresoli, Johannes Berg,
ecryptfs, Matthias Maennich, dmaengine, Borislav Petkov,
Thomas Gleixner, Martin K. Petersen, netdev, linux-kernel,
Vinod Koul, Harry Wei, Greg Kroah-Hartman, Hans Verkuil,
linuxppc-dev, David S. Miller, Madhuparna Bhowmik
This small series address a regression caused by a new patch at
docs-next (and at linux-next).
Before this patch, when a cross-reference to a chapter within the
documentation is needed, we had to add a markup like:
.. _foo:
foo
===
This behavor is now different after this patch:
58ad30cf91f0 ("docs: fix reference to core-api/namespaces.rst")
As a Sphinx extension now creates automatically a reference
like the above, without requiring any extra markup.
That, however, comes with a price: it is not possible anymore to have
two sections with the same name within the entire Kernel docs!
This causes thousands of warnings, as we have sections named
"introduction" on lots of places.
This series solve this regression by doing two changes:
1) The references are now prefixed by the document name. So,
a file named "bar" would have the "foo" reference as "bar:foo".
2) It will only use the first two levels. The first one is (usually) the
name of the document, and the second one the chapter name.
This solves almost all problems we have. Still, there are a few places
where we have two chapters at the same document with the
same name. The first patch addresses this problem.
The second patch limits the escope of the autosectionlabel.
Mauro Carvalho Chehab (2):
docs: prevent warnings due to autosectionlabel
docs: conf.py: avoid thousands of duplicate label warning on Sphinx
Documentation/conf.py | 4 ++++
Documentation/driver-api/80211/mac80211-advanced.rst | 8 ++++----
Documentation/driver-api/dmaengine/index.rst | 4 ++--
Documentation/filesystems/ecryptfs.rst | 11 +++++------
Documentation/kernel-hacking/hacking.rst | 4 ++--
Documentation/media/kapi/v4l2-controls.rst | 8 ++++----
Documentation/networking/snmp_counter.rst | 4 ++--
Documentation/powerpc/ultravisor.rst | 4 ++--
Documentation/security/siphash.rst | 8 ++++----
Documentation/target/tcmu-design.rst | 6 +++---
.../translations/zh_CN/process/5.Posting.rst | 2 +-
Documentation/x86/intel-iommu.rst | 3 ++-
12 files changed, 35 insertions(+), 31 deletions(-)
--
2.24.1
^ permalink raw reply
* Re: [PATCH] arch/powerpc/64: Avoid isync in flush_dcache_range
From: Aneesh Kumar K.V @ 2020-03-20 15:08 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <20200320150539.GF22482@gate.crashing.org>
On 3/20/20 8:35 PM, Segher Boessenkool wrote:
> On Fri, Mar 20, 2020 at 04:02:42PM +0530, Aneesh Kumar K.V wrote:
>> As per ISA and isync is only needed on instruction cache
>> block invalidate. Remove the same from dcache invalidate.
>
> Is that true on older CPUs?
>
That is what I found by checking with hardware team. One thing i was not
able to get full confirmation about was the usage of 'sync' before 'dcbf'.
-aneesh
^ permalink raw reply
* Re: [PATCH] arch/powerpc/64: Avoid isync in flush_dcache_range
From: Segher Boessenkool @ 2020-03-20 15:05 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev
In-Reply-To: <20200320103242.229223-1-aneesh.kumar@linux.ibm.com>
On Fri, Mar 20, 2020 at 04:02:42PM +0530, Aneesh Kumar K.V wrote:
> As per ISA and isync is only needed on instruction cache
> block invalidate. Remove the same from dcache invalidate.
Is that true on older CPUs?
Segher
^ permalink raw reply
* Re: [PATCH 1/2] dma-mapping: add a dma_ops_bypass flag to struct device
From: Greg Kroah-Hartman @ 2020-03-20 15:02 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Alexey Kardashevskiy, linuxppc-dev, Joerg Roedel, linux-kernel,
iommu, Robin Murphy, Lu Baolu
In-Reply-To: <20200320141640.366360-2-hch@lst.de>
On Fri, Mar 20, 2020 at 03:16:39PM +0100, Christoph Hellwig wrote:
> Several IOMMU drivers have a bypass mode where they can use a direct
> mapping if the devices DMA mask is large enough. Add generic support
> to the core dma-mapping code to do that to switch those drivers to
> a common solution.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> include/linux/device.h | 6 ++++++
> include/linux/dma-mapping.h | 30 ++++++++++++++++++------------
> kernel/dma/mapping.c | 36 +++++++++++++++++++++++++++---------
> 3 files changed, 51 insertions(+), 21 deletions(-)
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox