[PATCH v3 14/33] docs: kbuild: convert docs to ReST and rename to *.rst

The kbuild documentation clearly shows that the documents there are written at different times: some use markdown, some use their own peculiar logic to split sections. Convert everything to ReST without affecting too much the author's style and avoiding adding uneeded markups. The conversion is a

[PATCH v3 15/33] docs: kdump: convert docs to ReST and rename to *.rst

Convert kdump documentation to ReST and add it to the user faced manual, as the documents are mainly focused on sysadmins that would be enabling kdump. Note: the vmcoreinfo.rst has one very long title on one of its sub-sections: PG_lru|PG_private|PG_swapcache|PG_swapbacked|PG_slab|PG_hwp

[PATCH v3 21/33] docs: powerpc: convert docs to ReST and rename to *.rst

Convert docs to ReST and add them to the arch-specific book. The conversion here was trivial, as almost every file there was already using an elegant format close to ReST standard. The changes were mostly to mark literal blocks and add a few missing section title identifiers. One note with regar

Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook

On 6/7/19 12:29 PM, Christoph Hellwig wrote: I don't think we should work around this in the driver, we need to fix it in the core. I'm curious why my previous patch didn't work. Can you throw in a few printks what failed? I.e. did dma_direct_supported return false? Did the actual allocation

Re: powerpc hugepage leak caused by 576ed913 "block: use bio_add_page in bio_iov_iter_get_pages"

On Fri, Apr 26, 2019 at 12:41 PM David Gibson wrote: > > On Fri, Apr 26, 2019 at 11:05:17AM +1000, David Gibson wrote: > > On Thu, Apr 25, 2019 at 08:19:58AM +0200, Christoph Hellwig wrote: > > > Just curious: What exact trees do you see this with? This area > > > changed a lot with the multipag

[Bug 203839] Kernel 5.2-rc3 fails to boot on a PowerMac G4 3,6: systemd[1]: Failed to bump fs.file-max, ignoring: invalid argument

https://bugzilla.kernel.org/show_bug.cgi?id=203839 --- Comment #4 from Erhard F. (erhar...@mailbox.org) --- Created attachment 283163 --> https://bugzilla.kernel.org/attachment.cgi?id=283163&action=edit failed boot, screenshot 5.2-rc3+ After reverting the 3 commits on top of v5.2-rc3 the kernel

[PATCH AUTOSEL 4.4 10/13] KVM: PPC: Book3S: Use new mutex to synchronize access to rtas token list

From: Paul Mackerras [ Upstream commit 1659e27d2bc1ef47b6d031abe01b467f18cb72d9 ] Currently the Book 3S KVM code uses kvm->lock to synchronize access to the kvm->arch.rtas_tokens list. Because this list is scanned inside kvmppc_rtas_hcall(), which is called with the vcpu mutex held, taking kvm-

[PATCH AUTOSEL 4.9 15/20] KVM: PPC: Book3S HV: Don't take kvm->lock around kvm_for_each_vcpu

From: Paul Mackerras [ Upstream commit 5a3f49364c3ffa1107bd88f8292406e98c5d206c ] Currently the HV KVM code takes the kvm->lock around calls to kvm_for_each_vcpu() and kvm_get_vcpu_by_id() (which can call kvm_for_each_vcpu() internally). However, that leads to a lock order inversion problem, be

[PATCH AUTOSEL 4.9 14/20] KVM: PPC: Book3S: Use new mutex to synchronize access to rtas token list

From: Paul Mackerras [ Upstream commit 1659e27d2bc1ef47b6d031abe01b467f18cb72d9 ] Currently the Book 3S KVM code uses kvm->lock to synchronize access to the kvm->arch.rtas_tokens list. Because this list is scanned inside kvmppc_rtas_hcall(), which is called with the vcpu mutex held, taking kvm-

[PATCH AUTOSEL 4.14 24/31] KVM: PPC: Book3S HV: Don't take kvm->lock around kvm_for_each_vcpu

From: Paul Mackerras [ Upstream commit 5a3f49364c3ffa1107bd88f8292406e98c5d206c ] Currently the HV KVM code takes the kvm->lock around calls to kvm_for_each_vcpu() and kvm_get_vcpu_by_id() (which can call kvm_for_each_vcpu() internally). However, that leads to a lock order inversion problem, be

[PATCH AUTOSEL 4.14 23/31] KVM: PPC: Book3S: Use new mutex to synchronize access to rtas token list

From: Paul Mackerras [ Upstream commit 1659e27d2bc1ef47b6d031abe01b467f18cb72d9 ] Currently the Book 3S KVM code uses kvm->lock to synchronize access to the kvm->arch.rtas_tokens list. Because this list is scanned inside kvmppc_rtas_hcall(), which is called with the vcpu mutex held, taking kvm-

[PATCH AUTOSEL 4.14 07/31] powerpc/powernv: Return for invalid IMC domain

From: Anju T Sudhakar [ Upstream commit b59bd3527fe3c1939340df558d7f9d568fc9f882 ] Currently init_imc_pmu() can fail either because we try to register an IMC unit with an invalid domain (i.e an IMC node not supported by the kernel) or something went wrong while registering a valid IMC unit. In b

[PATCH AUTOSEL 4.19 37/49] KVM: PPC: Book3S HV: Don't take kvm->lock around kvm_for_each_vcpu

From: Paul Mackerras [ Upstream commit 5a3f49364c3ffa1107bd88f8292406e98c5d206c ] Currently the HV KVM code takes the kvm->lock around calls to kvm_for_each_vcpu() and kvm_get_vcpu_by_id() (which can call kvm_for_each_vcpu() internally). However, that leads to a lock order inversion problem, be

[PATCH AUTOSEL 4.19 36/49] KVM: PPC: Book3S: Use new mutex to synchronize access to rtas token list

From: Paul Mackerras [ Upstream commit 1659e27d2bc1ef47b6d031abe01b467f18cb72d9 ] Currently the Book 3S KVM code uses kvm->lock to synchronize access to the kvm->arch.rtas_tokens list. Because this list is scanned inside kvmppc_rtas_hcall(), which is called with the vcpu mutex held, taking kvm-

[PATCH AUTOSEL 4.19 09/49] powerpc/powernv: Return for invalid IMC domain

From: Anju T Sudhakar [ Upstream commit b59bd3527fe3c1939340df558d7f9d568fc9f882 ] Currently init_imc_pmu() can fail either because we try to register an IMC unit with an invalid domain (i.e an IMC node not supported by the kernel) or something went wrong while registering a valid IMC unit. In b

[PATCH AUTOSEL 5.1 54/70] KVM: PPC: Book3S HV: Don't take kvm->lock around kvm_for_each_vcpu

From: Paul Mackerras [ Upstream commit 5a3f49364c3ffa1107bd88f8292406e98c5d206c ] Currently the HV KVM code takes the kvm->lock around calls to kvm_for_each_vcpu() and kvm_get_vcpu_by_id() (which can call kvm_for_each_vcpu() internally). However, that leads to a lock order inversion problem, be

[PATCH AUTOSEL 5.1 53/70] KVM: PPC: Book3S: Use new mutex to synchronize access to rtas token list

From: Paul Mackerras [ Upstream commit 1659e27d2bc1ef47b6d031abe01b467f18cb72d9 ] Currently the Book 3S KVM code uses kvm->lock to synchronize access to the kvm->arch.rtas_tokens list. Because this list is scanned inside kvmppc_rtas_hcall(), which is called with the vcpu mutex held, taking kvm-

[PATCH AUTOSEL 5.1 52/70] KVM: PPC: Book3S HV: Use new mutex to synchronize MMU setup

From: Paul Mackerras [ Upstream commit 0d4ee88d92884c661fcafd5576da243aa943dc24 ] Currently the HV KVM code uses kvm->lock in conjunction with a flag, kvm->arch.mmu_ready, to synchronize MMU setup and hold off vcpu execution until the MMU-related data structures are ready. However, this means t

[PATCH AUTOSEL 5.1 17/70] powerpc/powernv: Return for invalid IMC domain

From: Anju T Sudhakar [ Upstream commit b59bd3527fe3c1939340df558d7f9d568fc9f882 ] Currently init_imc_pmu() can fail either because we try to register an IMC unit with an invalid domain (i.e an IMC node not supported by the kernel) or something went wrong while registering a valid IMC unit. In b

Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook

On Sat, Jun 08, 2019 at 02:21:23PM +1000, Benjamin Herrenschmidt wrote: > > > Please try the attached patch. I'm not really pleased with it and I will > > continue to determine why the fallback to a 30-bit mask fails, but at least > > this > > one works for me. > > Your patch only makes sense