On Tue, Sep 28, 2021 at 03:53:47PM +0530, Abdul Haleem wrote:
>
> On 9/1/21 7:06 PM, Christoph Hellwig wrote:
>> On Wed, Sep 01, 2021 at 04:47:26PM +0530, Abdul Haleem wrote:
>>> Greeting's
>>>
>>> multiple task hung while adding the vfc disk back to the multipath on my
>>> powerpc box running
On 28/09/2021 12:15, Alexey Kardashevskiy wrote:
The upcoming PAPR spec adds a 2M page size, bit 23 right after the 16G page
size in the "ibm,query-pe-dma-window" call.
This adds support for the new page size. Since the new page size is out
of sorted order, this changes the loop to not
* Nathan Lynch [2021-09-28 16:41:46]:
> Add comments more clearly documenting that this function determines whether
> hypervisor-level preemption of the VM has occurred.
>
> Signed-off-by: Nathan Lynch
Looks good to me.
Reviewed-by: Srikar Dronamraju
> ---
>
* Nathan Lynch [2021-09-28 07:45:50]:
> When check_kvm_guest() succeeds in looking up a /hypervisor OF node, it
> returns without performing a matching put for the lookup, leaving the
> node's reference count elevated.
>
> Add the necessary call to of_node_put(), rearranging the code slightly
On Tue, Sep 28, 2021 at 12:31:29PM +0200, Uwe Kleine-König wrote:
> On Tue, Sep 28, 2021 at 12:01:28PM +0200, Simon Horman wrote:
> > On Mon, Sep 27, 2021 at 10:43:22PM +0200, Uwe Kleine-König wrote:
> > > From: Uwe Kleine-König
> > >
> > > struct pci_dev::driver holds (apart from a constant
Hello Simon,
On Wed, Sep 29, 2021 at 10:05:42AM +0200, Simon Horman wrote:
> On Tue, Sep 28, 2021 at 12:31:29PM +0200, Uwe Kleine-König wrote:
> > On Tue, Sep 28, 2021 at 12:01:28PM +0200, Simon Horman wrote:
> > > On Mon, Sep 27, 2021 at 10:43:22PM +0200, Uwe Kleine-König wrote:
> > > > From:
On Wed, Sep 29, 2021 at 10:53:02AM +0200, Uwe Kleine-König wrote:
> struct pci_dev::driver holds (apart from a constant offset) the same
> data as struct pci_dev::dev->driver. With the goal to remove struct
> pci_dev::driver to get rid of data duplication replace getting the
> driver name by
allmodconfig
i386 randconfig-c001-20210929
powerpcamigaone_defconfig
powerpc ksi8560_defconfig
sh se7722_defconfig
armpleb_defconfig
arm ep93xx_defconfig
arm
* Nathan Lynch [2021-09-28 16:41:47]:
> vcpu_is_preempted() can be used outside of preempt-disabled critical
> sections, yielding warnings such as:
>
> BUG: using smp_processor_id() in preemptible [] code:
> systemd-udevd/185
> caller is rwsem_spin_on_owner+0x1cc/0x2d0
> CPU: 1 PID:
On 09/09/2020 17:58, Christoph Hellwig wrote:
> On Tue, Sep 08, 2020 at 11:10:03PM +1000, Alexey Kardashevskiy wrote:
a-ha, this makes more sense, thanks. Then I guess we need to revert that
one bit from yours f1565c24b596, do not we?
>>>
>>> Why? The was the original intent of the
struct pci_dev::driver contains (apart from a constant offset) the same
data as struct pci_dev::dev->driver. Replace all remaining users of the
former pointer by the latter to allow removing the former.
Reviewed-by: Boris Ostrovsky
Signed-off-by: Uwe Kleine-König
---
The driver member of struct pci_dev is to be removed as it tracks
information already present by tracking of the driver core. So replace
pdev->driver->name by dev_driver_string() for the corresponding struct
device.
Also move the function nearer to its only user and instead of the ?:
operator use
struct pci_dev::driver holds (apart from a constant offset) the same
data as struct pci_dev::dev->driver. With the goal to remove struct
pci_dev::driver to get rid of data duplication replace getting the
driver name by dev_driver_string() which implicitly makes use of struct
pci_dev::dev->driver.
From: Ravi Bangoria
BPF load instruction with BPF_PROBE_MEM mode can cause a fault
inside kernel. Append exception table for such instructions
within BPF program.
Unlike other archs which uses extable 'fixup' field to pass dest_reg
and nip, BPF exception table on PowerPC follows the generic
Define and use PPC_RAW_BRANCH() macro instead of open coding it. This
macro is used while adding BPF_PROBE_MEM support.
Signed-off-by: Hari Bathini
Reviewed-by: Christophe Leroy
---
* No changes in v4.
arch/powerpc/include/asm/ppc-opcode.h | 2 ++
arch/powerpc/net/bpf_jit.h| 4
Le 29/09/2021 à 13:18, Hari Bathini a écrit :
Refactor powerpc LDX JITing code to simplify adding BPF_PROBE_MEM
support.
Signed-off-by: Hari Bathini
Reviewed-by: Christophe Leroy
---
Changes in v4:
* Dropped the default case in the switch statement for bpf size.
* Dropped explicit
Le 29/09/2021 à 13:18, Hari Bathini a écrit :
From: Ravi Bangoria
BPF load instruction with BPF_PROBE_MEM mode can cause a fault
inside kernel. Append exception table for such instructions
within BPF program.
Unlike other archs which uses extable 'fixup' field to pass dest_reg
and nip, BPF
From: Ravi Bangoria
SEEN_STACK is unused on PowerPC. Remove it. Also, have
SEEN_TAILCALL use 0x4000.
Signed-off-by: Ravi Bangoria
Reviewed-by: Christophe Leroy
---
* No changes in v4.
arch/powerpc/net/bpf_jit.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
BPF load instruction with BPF_PROBE_MEM mode can cause a fault
inside kernel. Append exception table for such instructions
within BPF program.
Unlike other archs which uses extable 'fixup' field to pass dest_reg
and nip, BPF exception table on PowerPC follows the generic PowerPC
exception table
From: Ravi Bangoria
On PPC64 with KUAP enabled, any kernel code which wants to
access userspace needs to be surrounded by disable-enable KUAP.
But that is not happening for BPF_PROBE_MEM load instruction.
So, when BPF program tries to access invalid userspace address,
page-fault handler
Le 29/09/2021 à 13:18, Hari Bathini a écrit :
From: Ravi Bangoria
BPF load instruction with BPF_PROBE_MEM mode can cause a fault
inside kernel. Append exception table for such instructions
within BPF program.
Unlike other archs which uses extable 'fixup' field to pass dest_reg
and nip, BPF
Michael Ellerman writes:
> Daniel Henrique Barboza writes:
>> This is enough to say that we can't easily see the history behind this
>> comment.
>> I also believe that we're better of without it since it doesn't make sense
>> with the current codebase.
>
> It was added by the original CPU
From: Ravi Bangoria
In case of extra_pass, usual JIT passes are always skipped. So,
extra_pass is always false while calling bpf_jit_build_body() and
can be removed.
Signed-off-by: Ravi Bangoria
---
* No changes in v4.
arch/powerpc/net/bpf_jit.h| 2 +-
Patch #1 & #2 are simple cleanup patches. Patch #3 refactors JIT
compiler code with the aim to simplify adding BPF_PROBE_MEM support.
Patch #4 introduces PPC_RAW_BRANCH() macro instead of open coding
branch instruction. Patch #5 & #7 add BPF_PROBE_MEM support for PPC64
& PPC32 JIT compilers
Refactor powerpc LDX JITing code to simplify adding BPF_PROBE_MEM
support.
Signed-off-by: Hari Bathini
---
Changes in v4:
* Dropped the default case in the switch statement for bpf size.
* Dropped explicit fallthrough statement for empty switch cases.
arch/powerpc/net/bpf_jit_comp32.c | 33
With KUAP enabled, any kernel code which wants to access userspace
needs to be surrounded by disable-enable KUAP. But that is not
happening for BPF_PROBE_MEM load instruction. Though PPC32 does not
support read protection, considering the fact that PTR_TO_BTF_ID
(which uses BPF_PROBE_MEM mode)
Le 29/09/2021 à 13:18, Hari Bathini a écrit :
BPF load instruction with BPF_PROBE_MEM mode can cause a fault
inside kernel. Append exception table for such instructions
within BPF program.
Unlike other archs which uses extable 'fixup' field to pass dest_reg
and nip, BPF exception table on
Le 29/09/2021 à 13:18, Hari Bathini a écrit :
> From: Ravi Bangoria
>
> On PPC64 with KUAP enabled, any kernel code which wants to
> access userspace needs to be surrounded by disable-enable KUAP.
> But that is not happening for BPF_PROBE_MEM load instruction.
> So, when BPF program tries to
Le 29/09/2021 à 13:18, Hari Bathini a écrit :
With KUAP enabled, any kernel code which wants to access userspace
needs to be surrounded by disable-enable KUAP. But that is not
happening for BPF_PROBE_MEM load instruction. Though PPC32 does not
support read protection, considering the fact
Hello,
this is v5 of the quest to drop the "driver" member from struct pci_dev
which tracks the same data (apart from a constant offset) as dev.driver.
Changes since v4:
- split some changes out of "PCI: replace pci_dev::driver usage that
gets the driver name" and reworked them a bit as
Some cleanups around CONFIG_MEMORY_HOTPLUG, including removing 32 bit
leftovers of memory hotplug support.
Compile-tested on various architectures, quickly tested memory hotplug
on x86-64.
Cc: Andrew Morton
Cc: Jonathan Corbet
Cc: Alex Shi
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc:
SPARSEMEM is the only possible memory model for x86-64, FLATMEM is not
possible:
config ARCH_FLATMEM_ENABLE
def_bool y
depends on X86_32 && !NUMA
And X86_64_ACPI_NUMA (obviously) only supports x86-64:
config X86_64_ACPI_NUMA
def_bool
CONFIG_MEMORY_HOTPLUG depends on CONFIG_SPARSEMEM, so there is no need for
CONFIG_MEMORY_HOTPLUG_SPARSE anymore; adjust all instances to use
CONFIG_MEMORY_HOTPLUG and remove CONFIG_MEMORY_HOTPLUG_SPARSE.
Signed-off-by: David Hildenbrand
---
arch/powerpc/include/asm/machdep.h| 2 +-
These functions no longer exist.
Signed-off-by: David Hildenbrand
---
include/linux/memory_hotplug.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index e5a867c950b2..be48e003a518 100644
--- a/include/linux/memory_hotplug.h
32 bit support is broken in various ways: for example, we can online
memory that should actually go to ZONE_HIGHMEM to ZONE_MOVABLE or in
some cases even to one of the other kernel zones.
We marked it BROKEN in commit b59d02ed0869 ("mm/memory_hotplug: disable the
functionality for 32b") almost
We don't support CONFIG_MEMORY_HOTPLUG on 32 bit and consequently not
HIGHMEM. Let's remove any leftover code -- including the unused
"status_change_nid_high" field part of the memory notifier.
Signed-off-by: David Hildenbrand
---
Documentation/core-api/memory-hotplug.rst | 3 --
CONFIG_MEMORY_HOTPLUG was marked BROKEN over one year and we just
restricted it to 64 bit. Let's remove the unused x86 32bit implementation
and simplify the Kconfig.
Signed-off-by: David Hildenbrand
---
arch/x86/Kconfig | 6 +++---
arch/x86/mm/init_32.c | 31
Ard Biesheuvel writes:
> On Tue, 28 Sept 2021 at 02:16, Michael Ellerman wrote:
>>
>> Michael Ellerman writes:
>> > Ard Biesheuvel writes:
>> >> On Tue, 14 Sept 2021 at 14:11, Ard Biesheuvel wrote:
>> >>>
>> >>> The CPU field will be moved back into thread_info even when
>> >>>
On Thu, Sep 30, 2021 at 08:46:04AM +1000, Michael Ellerman wrote:
> Ard Biesheuvel writes:
> > On Tue, 28 Sept 2021 at 02:16, Michael Ellerman wrote:
> >>
> >> Michael Ellerman writes:
> >> > Ard Biesheuvel writes:
> >> >> On Tue, 14 Sept 2021 at 14:11, Ard Biesheuvel wrote:
> >> >>>
> >> >>>
On Wed, Sep 29, 2021 at 9:50 PM Christophe Leroy
wrote:
>
>
>
> Le 29/09/2021 à 13:18, Hari Bathini a écrit :
> > From: Ravi Bangoria
> >
> > BPF load instruction with BPF_PROBE_MEM mode can cause a fault
> > inside kernel. Append exception table for such instructions
> > within BPF program.
> >
On Wed, Sep 29, 2021 at 10:53:02AM +0200, Uwe Kleine-König wrote:
> struct pci_dev::driver holds (apart from a constant offset) the same
> data as struct pci_dev::dev->driver. With the goal to remove struct
> pci_dev::driver to get rid of data duplication replace getting the
> driver name by
According to dma-api.rst, the dma_get_required_mask() helper should return
"the mask that the platform requires to operate efficiently". Which in
the case of PPC64 means the bypass mask and not a mask from an IOMMU table
which is shorter and slower to use due to map/unmap operations (especially
> This looks all very good to me, I had one very minor comment.
>
> Whole series
>
> Reviewed-by: Arnd Bergmann
Thanks for the series and the review!
Same here, looks good to me and I only had one minor comment.
signature.asc
Description: PGP signature
On Wed, Sep 29, 2021 at 05:44:51PM +0300, Ido Schimmel wrote:
> On Wed, Sep 29, 2021 at 10:53:02AM +0200, Uwe Kleine-König wrote:
> > struct pci_dev::driver holds (apart from a constant offset) the same
> > data as struct pci_dev::dev->driver. With the goal to remove struct
> > pci_dev::driver to
> drivers/i2c/busses/i2c-pasemi-apple.c | 122 ++
Can't we name it 'i2c-pasemi-platform.c' instead? Makes more sense to me
because the other instance is named -pci.
signature.asc
Description: PGP signature
On Thu, Sep 30, 2021 at 01:44:54PM +1000, Alexey Kardashevskiy wrote:
> and returns the IOMMU table mask on the pseries platform which makes some
> drivers (mpt3sas is one example) choose 32bit DMA even though bypass is
> supported. The powernv platform sort of handles it by having a bigger
>
On 29/9/21 11:43 pm, Uwe Kleine-König wrote:> I'm not a huge fan either,
I used it to keep the control flow as is and
without introducing several calls to to_pci_driver.
The whole code looks as follows:
list_for_each_entry(afu_dev, >phb->bus->devices, bus_list) {
struct
On 29/9/21 6:53 pm, Uwe Kleine-König wrote:>
list_for_each_entry(afu_dev, >phb->bus->devices, bus_list) {
- if (afu_dev->driver && afu_dev->driver->err_handler &&
- afu_dev->driver->err_handler->resume)
-
On Wed, Sep 29, 2021 at 11:15:37PM +1000, Andrew Donnellan wrote:
> On 29/9/21 6:53 pm, Uwe Kleine-König wrote:>
> list_for_each_entry(afu_dev, >phb->bus->devices, bus_list) {
> > - if (afu_dev->driver && afu_dev->driver->err_handler &&
> > -
Hi Pratik,
Some comments inline below ...
"Pratik R. Sampat" writes:
> Adds a generic interface to represent the energy and frequency related
> PAPR attributes on the system using the new H_CALL
> "H_GET_ENERGY_SCALE_INFO".
In Linux "generic" would usually mean something that is not
50 matches
Mail list logo
