pages);
> vm_area_unmap_pages(area, kaddr, kend);
>
> // after bpf program is detached and unloaded
> free_vm_area(area);
>
> Signed-off-by: Alexei Starovoitov
Reviewed-by: Pasha Tatashin
On Wed, Mar 6, 2024 at 5:13 PM Alexei Starovoitov
wrote:
>
> On Wed, Mar 6, 2024 at 1:46 PM Pasha Tatashin
> wrote:
> >
> > > > This interface and in general VM_SPARSE would be useful for
> > > > dynamically grown kernel stacks [1]. However, the might_slee
> > This interface and in general VM_SPARSE would be useful for
> > dynamically grown kernel stacks [1]. However, the might_sleep() here
> > would be a problem. We would need to be able to handle
> > vm_area_map_pages() from interrupt disabled context therefore no
> > sleeping. The caller would nee
On Mon, Mar 4, 2024 at 10:05 PM Alexei Starovoitov
wrote:
>
> From: Alexei Starovoitov
>
> vmap/vmalloc APIs are used to map a set of pages into contiguous kernel
> virtual space.
>
> get_vm_area() with appropriate flag is used to request an area of kernel
> address range. It's used for vmalloc,
Reviewed-by: Pavel Tatashin
On 8/21/18 6:44 AM, David Hildenbrand wrote:
> Let's document the magic a bit, especially why device_hotplug_lock is
> required when adding/removing memory and how it all play together with
> requests to online/offline memory from user space.
>
__
Reviewed-by: Pavel Tatashin
On 8/21/18 6:44 AM, David Hildenbrand wrote:
> Let's perform all checking + offlining + removing under
> device_hotplug_lock, so nobody can mess with these devices via
> sysfs concurrently.
>
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Michael Ellerman
Reviewed-by: Pavel Tatashin
On 8/21/18 6:44 AM, David Hildenbrand wrote:
> device_online() should be called with device_hotplug_lock() held.
>
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Michael Ellerman
> Cc: Rashmica Gupta
> Cc: Balbir Singh
> Cc: Michael Neuling
> Signed-off
On 8/21/18 6:44 AM, David Hildenbrand wrote:
> There seem to be some problems as result of 30467e0b3be ("mm, hotplug:
> fix concurrent memory hot-add deadlock"), which tried to fix a possible
> lock inversion reported and discussed in [1] due to the two locks
> a) device_lock()
> b) mem
> +
> +void __ref remove_memory(int nid, u64 start, u64 size)
Remove __ref, otherwise looks good:
Reviewed-by: Pavel Tatashin
> +{
> + lock_device_hotplug();
> + __remove_memory(nid, start, size);
> + unlock_device_hotplug();
> +}
> EXPORT_SYMBOL_GPL(remove_memory);
> #endif /* CO
On 8/21/18 6:44 AM, David Hildenbrand wrote:
> add_memory() currently does not take the device_hotplug_lock, however
> is aleady called under the lock from
> arch/powerpc/platforms/pseries/hotplug-memory.c
> drivers/acpi/acpi_memhotplug.c
> to synchronize against CPU hot-remove and simi
On 8/30/18 8:31 AM, David Hildenbrand wrote:
> On 21.08.2018 12:44, David Hildenbrand wrote:
>> This is the same approach as in the first RFC, but this time without
>> exporting device_hotplug_lock (requested by Greg) and with some more
>> details and documentation regarding locking. Tested only
On Fri, Aug 17, 2018 at 9:41 AM Juergen Gross wrote:
>
> Commit 7b25b9cb0dad83 ("x86/xen/time: Initialize pv xen time in
> init_hypervisor_platform()") moved the mapping of the shared info area
> before pagetable_init(). This breaks booting as 32-bit PV guest as the
> use of set_fixmap isn't possi
12 matches
Mail list logo
