us/j/87093034809?pwd=alBWcW9DcWwwVC8wWnlLUGx2TXBhZz09
Meeting ID: 870 9303 4809
Passcode: 227284
Robin Rapoport
Reference Librarian (in the library Monday, Tuesday, and Wednesday)
Lincoln Public Library
3 Bedford Road
Lincoln, MA 01773
781-259-8465
My pronouns are she/her/hers
--
Th
On Tue, Jan 11, 2022 at 08:44:41PM +, Frank van der Linden wrote:
> On Tue, Jan 11, 2022 at 12:31:58PM +0200, Mike Rapoport wrote:
> > > --- a/include/linux/memblock.h
> > > +++ b/include/linux/memblock.h
> > > @@ -481,6 +481,8 @@ phys_addr_t memblock_reserved_
On Wed, Jan 12, 2022 at 11:54:49AM +0100, David Hildenbrand wrote:
> On 05.01.22 22:47, Zi Yan wrote:
> > From: Zi Yan
> >
> > This is done in addition to MIGRATE_ISOLATE pageblock merge avoidance.
> > It prepares for the upcoming removal of the MAX_ORDER-1 alignment
> > requirement for CMA and
On Wed, Jan 12, 2022 at 11:54:49AM +0100, David Hildenbrand wrote:
> On 05.01.22 22:47, Zi Yan wrote:
> > From: Zi Yan
> >
> > This is done in addition to MIGRATE_ISOLATE pageblock merge avoidance.
> > It prepares for the upcoming removal of the MAX_ORDER-1 alignment
> > requirement for CMA and
brary
<https://www.lincolnpl.org/about/friends>
*To receive the zoom information please register for the program.*
*Registration
for this event opens Tuesday, January 4 9:00 AM.*
Robin Rapoport
Reference Librarian (in the library Monday, Tuesday, and Wednesday)
Lincoln Public Library
3 Bedfor
On Tue, Jan 11, 2022 at 08:44:41PM +, Frank van der Linden wrote:
> On Tue, Jan 11, 2022 at 12:31:58PM +0200, Mike Rapoport wrote:
> > > --- a/include/linux/memblock.h
> > > +++ b/include/linux/memblock.h
> > > @@ -481,6 +481,8 @@ phys_addr_t memblock_reserved_
On Mon, Jan 10, 2022 at 09:08:07PM +, Frank van der Linden wrote:
> Some architectures might limit the usable memory range based
> on a firmware property, like "linux,usable-memory-range"
> for ARM crash kernels. This limit needs to be enforced after
> firmware memory map processing has been
sponsored by the Friends of the Lincoln Public Library
<https://www.lincolnpl.org/about/friends>
*To receive the zoom information please register for the program.*
*Registration
for this event opens Tuesday, January 4 9:00 AM.*
Robin Rapoport
Reference Librarian (in the library Monday, Tuesd
ends of the Lincoln Public Library
<https://www.lincolnpl.org/about/friends>
*To receive the zoom information please register for the program.*
*Registration
for this event opens Tuesday, January 4 9:00 AM.*
Robin Rapoport
Reference Librarian (in the library Monday, Tuesday, and Wednesday)
L
laptop, CD-ROM or USB flash drive and share them with the group or just
come and watch the show!
For Zoom information, please email Lisa at lrothenb...@minlib.net
Robin Rapoport
Reference Librarian (in the library Monday, Tuesday, and Wednesday)
Lincoln Public Library
3 Bedford Road
Lincoln, MA
nection activities for children in grade 5 and
6. For more information and to register, email sfeat...@minlib.net
Robin Rapoport
Reference Librarian (in the library Monday, Tuesday, and Wednesday)
Lincoln Public Library
3 Bedford Road
Lincoln, MA 01773
781-259-8465
My pronouns are she/her/hers
--
The L
y in collaboration with
Wellesley Books and many other Massachusetts Public Libraries.
*Free and open to all but registration is required.*
*To Register click here*
<https://us02web.zoom.us/webinar/register/4716371807639/WN_ulu4vdhzQ1-cziAX5VBxSw>
Robin Rapoport
Reference Librarian (in the
On Mon, Nov 29, 2021 at 06:08:10PM -0600, Rob Herring wrote:
> On Sun, Nov 21, 2021 at 08:43:47AM +0200, Mike Rapoport wrote:
> > On Fri, Nov 19, 2021 at 03:58:17PM +0800, Calvin Zhang wrote:
> > > The count of reserved regions in /reserved-memory was limited because
> > &
On Mon, Nov 29, 2021 at 06:08:10PM -0600, Rob Herring wrote:
> On Sun, Nov 21, 2021 at 08:43:47AM +0200, Mike Rapoport wrote:
> > On Fri, Nov 19, 2021 at 03:58:17PM +0800, Calvin Zhang wrote:
> > > The count of reserved regions in /reserved-memory was limited because
> > &
it him at DavidBaldacci.com and his
foundation at WishYouWellFoundation.org.
This event is hosted by the Tewksbury Public Library in collaboration with
Wellesley Books and many other Massachusetts Public Libraries.
*Free and open to all but registration is required. *
*To Register click here
&l
On Fri, Nov 19, 2021 at 03:58:17PM +0800, Calvin Zhang wrote:
> The count of reserved regions in /reserved-memory was limited because
> the struct reserved_mem array was defined statically. This series sorts
> out reserved memory code and allocates that array from early allocator.
>
> Note:
On Fri, Nov 19, 2021 at 03:58:17PM +0800, Calvin Zhang wrote:
> The count of reserved regions in /reserved-memory was limited because
> the struct reserved_mem array was defined statically. This series sorts
> out reserved memory code and allocates that array from early allocator.
>
> Note:
public speaker, teacher and writer of fiction and
non-fiction.
About the Interviewer: Lisa Genova is the New York Times bestselling author
of the novels *Still* *Alice, Left Neglected, Love Anthony*, *Inside the O’
Briens*, and *Every Note Played.*
*To Register click here*
<https://us02web.z
hony*, *Inside the O’
Briens*, and *Every Note Played.*
*To Register click here*
<https://us02web.zoom.us/webinar/register/5316349328121/WN_gO-4CmB5TaeTYQSDTWOadA>
Robin Rapoport
Reference Librarian (in the library Monday, Tuesday, and Wednesday)
Lincoln Public Library
3 Bedford Road
Lincoln, MA
elor, public speaker, teacher and writer of fiction and
non-fiction.
About the Interviewer: Lisa Genova is the New York Times bestselling author
of the novels *Still* *Alice, Left Neglected, Love Anthony*, *Inside the O’
Briens*, and *Every Note Played.*
*To Register click here
<https://us02w
ily counselor, public speaker, teacher and writer of fiction and
non-fiction.
About the Interviewer: Lisa Genova is the New York Times bestselling author
of the novels Still Alice, Left Neglected, Love Anthony, Inside the O’
Briens, and Every Note Played.
*To Register click here
<https:/
COVID-19 the Photoshare group has moved to Zoom for all meetings.
For information or to receive a Zoom invitation please email Lisa at
lrothenb...@minlib.net
Robin Rapoport
Reference Librarian (in the library Monday, Tuesday, and Wednesday)
Lincoln Public Library
3 Bedford Road
Lincoln, MA 017
On Fri, Oct 15, 2021 at 10:27:17AM +0200, Vlastimil Babka wrote:
> On 10/14/21 12:16, Mike Rapoport wrote:
> > On Thu, Oct 14, 2021 at 11:33:03AM +0200, Vlastimil Babka wrote:
> >> On 10/14/21 10:54, kernel test robot wrote:
> >>
> >> In my local t
On Fri, Oct 15, 2021 at 10:27:17AM +0200, Vlastimil Babka wrote:
> On 10/14/21 12:16, Mike Rapoport wrote:
> > On Thu, Oct 14, 2021 at 11:33:03AM +0200, Vlastimil Babka wrote:
> >> On 10/14/21 10:54, kernel test robot wrote:
> >>
> >> In my local t
19.151964][ T259] Oops: [#1] SMP
> > [ 319.152617][ T259] CPU: 0 PID: 259 Comm: systemd-rc-loca Not tainted
> > 5.15.0-rc1-00270-g1cd8ce52c520 #1
> > [ 319.154514][ T259] Hardware name: QEMU Standard PC (i440FX + PIIX,
> > 1996), BIOS 1.12.0-1 04/01/2014
> > [ 319
19.151964][ T259] Oops: [#1] SMP
> > [ 319.152617][ T259] CPU: 0 PID: 259 Comm: systemd-rc-loca Not tainted
> > 5.15.0-rc1-00270-g1cd8ce52c520 #1
> > [ 319.154514][ T259] Hardware name: QEMU Standard PC (i440FX + PIIX,
> > 1996), BIOS 1.12.0-1 04/01/2014
> > [ 319
k club for 5/6 graders.
*The Write Stuff
<https://lincolnpl.assabetinteractive.com/calendar/write-stuff-60/>*
*Wednesday, October 27, 7:00 pm – 8:30 pm*
*Zoom*
Lincoln's own writer's group. For information on joining the group please
email Lisa at lrothenb...@minlib.net
Robin Rapoport
R
at monuments mean and reimagine how they can
celebrate values of community, equity, and justice. Intended for school
aged children.
Program will be virtual. Email dleop...@minlib.net to register and receive
Zoom invite.
Robin Rapoport
Reference Librarian (in the library Monday, Tuesday, and
t Uytterhoeven
> Acked-by: Heiko Carstens
> Signed-off-by: David Hildenbrand
Reviewed-by: Mike Rapoport
> ---
> arch/arc/mm/init.c | 4 ++--
> arch/ia64/mm/contig.c| 2 +-
> arch/ia64/mm/init.c | 2 +-
> arch/m68k/mm/mcfm
pluggable. kexec *must not* indicate this memory to
> the second kernel and *must not* place kexec-images on this memory.
>
> Signed-off-by: David Hildenbrand
Reviewed-by: Mike Rapoport
> ---
> include/linux/memblock.h | 16 ++--
> kernel/kexec_file.c
; Without "movable_node" set, we don't care and can place kexec-images on
> this memory. In both cases, after successful memory hotunplug, kexec has to
> be re-armed to update the memory map for the second kernel and to place the
> kexec-images somewhere else.
>
> Signed
t Uytterhoeven
> Acked-by: Heiko Carstens
> Signed-off-by: David Hildenbrand
Reviewed-by: Mike Rapoport
> ---
> arch/arc/mm/init.c | 4 ++--
> arch/ia64/mm/contig.c| 2 +-
> arch/ia64/mm/init.c | 2 +-
> arch/m68k/mm/mcfm
; Without "movable_node" set, we don't care and can place kexec-images on
> this memory. In both cases, after successful memory hotunplug, kexec has to
> be re-armed to update the memory map for the second kernel and to place the
> kexec-images somewhere else.
>
> Signed
pluggable. kexec *must not* indicate this memory to
> the second kernel and *must not* place kexec-images on this memory.
>
> Signed-off-by: David Hildenbrand
Reviewed-by: Mike Rapoport
> ---
> include/linux/memblock.h | 16 ++--
> kernel/kexec_file.c
On Fri, Oct 01, 2021 at 10:04:24AM +0200, David Hildenbrand wrote:
> On 30.09.21 23:21, Mike Rapoport wrote:
> > On Wed, Sep 29, 2021 at 06:54:01PM +0200, David Hildenbrand wrote:
> > > On 29.09.21 18:39, Mike Rapoport wrote:
> > > > Hi,
> > > >
> &
On Fri, Oct 01, 2021 at 10:04:24AM +0200, David Hildenbrand wrote:
> On 30.09.21 23:21, Mike Rapoport wrote:
> > On Wed, Sep 29, 2021 at 06:54:01PM +0200, David Hildenbrand wrote:
> > > On 29.09.21 18:39, Mike Rapoport wrote:
> > > > Hi,
> > > >
> &
On Thu, Sep 30, 2021 at 02:20:33PM -0700, Linus Torvalds wrote:
> On Thu, Sep 30, 2021 at 11:50 AM Mike Rapoport wrote:
> >
> > The first patch is a cleanup of numa_distance allocation in arch_numa I've
> > spotted during the conversion.
> > The second patch is a
On Thu, Sep 30, 2021 at 02:20:33PM -0700, Linus Torvalds wrote:
> On Thu, Sep 30, 2021 at 11:50 AM Mike Rapoport wrote:
> >
> > The first patch is a cleanup of numa_distance allocation in arch_numa I've
> > spotted during the conversion.
> > The second patch is a
On Thu, Sep 30, 2021 at 02:20:33PM -0700, Linus Torvalds wrote:
> On Thu, Sep 30, 2021 at 11:50 AM Mike Rapoport wrote:
> >
> > The first patch is a cleanup of numa_distance allocation in arch_numa I've
> > spotted during the conversion.
> > The second patch is a
On Thu, Sep 30, 2021 at 02:20:33PM -0700, Linus Torvalds wrote:
> On Thu, Sep 30, 2021 at 11:50 AM Mike Rapoport wrote:
> >
> > The first patch is a cleanup of numa_distance allocation in arch_numa I've
> > spotted during the conversion.
> > The second patch is a
On Wed, Sep 29, 2021 at 06:54:01PM +0200, David Hildenbrand wrote:
> On 29.09.21 18:39, Mike Rapoport wrote:
> > Hi,
> >
> > On Mon, Sep 27, 2021 at 05:05:17PM +0200, David Hildenbrand wrote:
> > > Let's add a flag that corresponds to IORESOURCE_SYSRAM
On Wed, Sep 29, 2021 at 06:54:01PM +0200, David Hildenbrand wrote:
> On 29.09.21 18:39, Mike Rapoport wrote:
> > Hi,
> >
> > On Mon, Sep 27, 2021 at 05:05:17PM +0200, David Hildenbrand wrote:
> > > Let's add a flag that corresponds to IORESOURCE_SYSRAM
From: Mike Rapoport
Rename memblock_free_ptr() to memblock_free() and use memblock_free()
when freeing a virtual pointer so that memblock_free() will be a
counterpart of memblock_alloc()
The callers are updated with the below semantic patch and manual addition
of (void *) casting to pointers
From: Mike Rapoport
memblock_free_late() is a NOP wrapper for __memblock_free_late(), there is
no point to keep this indirection.
Drop the wrapper and rename __memblock_free_late() to memblock_free_late().
Signed-off-by: Mike Rapoport
---
include/linux/memblock.h | 7 +--
mm/memblock.c
From: Mike Rapoport
Since memblock_free() operates on a physical range, make its name reflect
it and rename it to memblock_phys_free(), so it will be a logical
counterpart to memblock_phys_alloc().
The callers are updated with the below semantic patch:
@@
expression addr;
expression size
From: Mike Rapoport
free_p2m_page() wrongly passes a virtual pointer to memblock_free() that
treats it as a physical address.
Call memblock_free_ptr() instead that gets a virtual address to free the
memory.
Signed-off-by: Mike Rapoport
Reviewed-by: Juergen Gross
---
arch/x86/xen/p2m.c | 2
From: Mike Rapoport
Memory allocation of numa_distance uses memblock_phys_alloc_range() without
actual range limits, converts the returned physical address to virtual and
then only uses the virtual address for further initialization.
Simplify this by replacing memblock_phys_alloc_range
From: Mike Rapoport
Rename memblock_free_ptr() to memblock_free() and use memblock_free()
when freeing a virtual pointer so that memblock_free() will be a
counterpart of memblock_alloc()
The callers are updated with the below semantic patch and manual addition
of (void *) casting to pointers
From: Mike Rapoport
Hi,
Following the discussion on [1] this is the fix for memblock freeing APIs
mismatch.
The first patch is a cleanup of numa_distance allocation in arch_numa I've
spotted during the conversion.
The second patch is a fix for Xen memory freeing on some of the error
paths.
I
From: Mike Rapoport
Since memblock_free() operates on a physical range, make its name reflect
it and rename it to memblock_phys_free(), so it will be a logical
counterpart to memblock_phys_alloc().
The callers are updated with the below semantic patch:
@@
expression addr;
expression size
From: Mike Rapoport
memblock_free_late() is a NOP wrapper for __memblock_free_late(), there is
no point to keep this indirection.
Drop the wrapper and rename __memblock_free_late() to memblock_free_late().
Signed-off-by: Mike Rapoport
---
include/linux/memblock.h | 7 +--
mm/memblock.c
From: Mike Rapoport
memblock_free_early_nid() is unused and memblock_free_early() is an alias
for memblock_free().
Replace calls to memblock_free_early() with calls to memblock_free() and
remove memblock_free_early() and memblock_free_early_nid().
Signed-off-by: Mike Rapoport
---
arch/mips
From: Mike Rapoport
free_p2m_page() wrongly passes a virtual pointer to memblock_free() that
treats it as a physical address.
Call memblock_free_ptr() instead that gets a virtual address to free the
memory.
Signed-off-by: Mike Rapoport
Reviewed-by: Juergen Gross
---
arch/x86/xen/p2m.c | 2
From: Mike Rapoport
Rename memblock_free_ptr() to memblock_free() and use memblock_free()
when freeing a virtual pointer so that memblock_free() will be a
counterpart of memblock_alloc()
The callers are updated with the below semantic patch and manual addition
of (void *) casting to pointers
From: Mike Rapoport
memblock_free_late() is a NOP wrapper for __memblock_free_late(), there is
no point to keep this indirection.
Drop the wrapper and rename __memblock_free_late() to memblock_free_late().
Signed-off-by: Mike Rapoport
---
include/linux/memblock.h | 7 +--
mm/memblock.c
From: Mike Rapoport
Rename memblock_free_ptr() to memblock_free() and use memblock_free()
when freeing a virtual pointer so that memblock_free() will be a
counterpart of memblock_alloc()
The callers are updated with the below semantic patch and manual addition
of (void *) casting to pointers
From: Mike Rapoport
Memory allocation of numa_distance uses memblock_phys_alloc_range() without
actual range limits, converts the returned physical address to virtual and
then only uses the virtual address for further initialization.
Simplify this by replacing memblock_phys_alloc_range
From: Mike Rapoport
Since memblock_free() operates on a physical range, make its name reflect
it and rename it to memblock_phys_free(), so it will be a logical
counterpart to memblock_phys_alloc().
The callers are updated with the below semantic patch:
@@
expression addr;
expression size
From: Mike Rapoport
memblock_free_early_nid() is unused and memblock_free_early() is an alias
for memblock_free().
Replace calls to memblock_free_early() with calls to memblock_free() and
remove memblock_free_early() and memblock_free_early_nid().
Signed-off-by: Mike Rapoport
---
arch/mips
From: Mike Rapoport
memblock_free_late() is a NOP wrapper for __memblock_free_late(), there is
no point to keep this indirection.
Drop the wrapper and rename __memblock_free_late() to memblock_free_late().
Signed-off-by: Mike Rapoport
---
include/linux/memblock.h | 7 +--
mm/memblock.c
From: Mike Rapoport
memblock_free_early_nid() is unused and memblock_free_early() is an alias
for memblock_free().
Replace calls to memblock_free_early() with calls to memblock_free() and
remove memblock_free_early() and memblock_free_early_nid().
Signed-off-by: Mike Rapoport
---
arch/mips
From: Mike Rapoport
free_p2m_page() wrongly passes a virtual pointer to memblock_free() that
treats it as a physical address.
Call memblock_free_ptr() instead that gets a virtual address to free the
memory.
Signed-off-by: Mike Rapoport
Reviewed-by: Juergen Gross
---
arch/x86/xen/p2m.c | 2
From: Mike Rapoport
free_p2m_page() wrongly passes a virtual pointer to memblock_free() that
treats it as a physical address.
Call memblock_free_ptr() instead that gets a virtual address to free the
memory.
Signed-off-by: Mike Rapoport
Reviewed-by: Juergen Gross
---
arch/x86/xen/p2m.c | 2
From: Mike Rapoport
Memory allocation of numa_distance uses memblock_phys_alloc_range() without
actual range limits, converts the returned physical address to virtual and
then only uses the virtual address for further initialization.
Simplify this by replacing memblock_phys_alloc_range
From: Mike Rapoport
Hi,
Following the discussion on [1] this is the fix for memblock freeing APIs
mismatch.
The first patch is a cleanup of numa_distance allocation in arch_numa I've
spotted during the conversion.
The second patch is a fix for Xen memory freeing on some of the error
paths.
I
From: Mike Rapoport
Hi,
Following the discussion on [1] this is the fix for memblock freeing APIs
mismatch.
The first patch is a cleanup of numa_distance allocation in arch_numa I've
spotted during the conversion.
The second patch is a fix for Xen memory freeing on some of the error
paths.
I
From: Mike Rapoport
Memory allocation of numa_distance uses memblock_phys_alloc_range() without
actual range limits, converts the returned physical address to virtual and
then only uses the virtual address for further initialization.
Simplify this by replacing memblock_phys_alloc_range
From: Mike Rapoport
Hi,
Following the discussion on [1] this is the fix for memblock freeing APIs
mismatch.
The first patch is a cleanup of numa_distance allocation in arch_numa I've
spotted during the conversion.
The second patch is a fix for Xen memory freeing on some of the error
paths.
I
be dropped. This also moves
the pfn upper bits sanity check into generic pfn_valid().
[rppt: rebased on v5.15-rc3]
Link:
https://lkml.kernel.org/r/1621947349-25421-1-git-send-email-anshuman.khand...@arm.com
Signed-off-by: Anshuman Khandual
Acked-by: David Hildenbrand
Acked-by: Mike Rapoport
Cc
From: Mike Rapoport
dma_map_resource() uses pfn_valid() to ensure the range is not RAM.
However, pfn_valid() only checks for availability of the memory map for a
PFN but it does not ensure that the PFN is actually backed by RAM.
As dma_map_resource() is the only method in DMA mapping APIs
From: Mike Rapoport
Hi,
This is a new attempt to drop HAVE_ARCH_PFN_VALID on arm64 and start using
the generic implementation of pfn_valid().
The first patch removes the check for pfn_valid() in dma_map_resource()
which is required to avoid false positives when there is memory map for
MMIO
re magazine and his work has
appeared in a variety of other publications including The Globe and Mail,
Northern Woodlands magazine, Maisonneuve magazine, and The Aurorean. Morley
lives in northern New Hampshire.
Please email Lisa at lrothenb...@minlib.net to receive a Zoom invitation
Robin Ra
Hi,
On Mon, Sep 27, 2021 at 05:05:17PM +0200, David Hildenbrand wrote:
> Let's add a flag that corresponds to IORESOURCE_SYSRAM_DRIVER_MANAGED.
> Similar to MEMBLOCK_HOTPLUG, most infrastructure has to treat such memory
> like ordinary MEMBLOCK_NONE memory -- for example, when selecting memory
>
Hi,
On Mon, Sep 27, 2021 at 05:05:17PM +0200, David Hildenbrand wrote:
> Let's add a flag that corresponds to IORESOURCE_SYSRAM_DRIVER_MANAGED.
> Similar to MEMBLOCK_HOTPLUG, most infrastructure has to treat such memory
> like ordinary MEMBLOCK_NONE memory -- for example, when selecting memory
>
On Mon, Sep 27, 2021 at 05:05:16PM +0200, David Hildenbrand wrote:
> We want to specify flags when hotplugging memory. Let's prepare to pass
> flags to memblock_add_node() by adjusting all existing users.
>
> Note that when hotplugging memory the system is already up and running
> and we don't
On Mon, Sep 27, 2021 at 05:05:16PM +0200, David Hildenbrand wrote:
> We want to specify flags when hotplugging memory. Let's prepare to pass
> flags to memblock_add_node() by adjusting all existing users.
>
> Note that when hotplugging memory the system is already up and running
> and we don't
On Thu, Sep 23, 2021 at 03:54:46PM +0200, Christophe Leroy wrote:
>
> Le 23/09/2021 à 14:01, Mike Rapoport a écrit :
> > On Thu, Sep 23, 2021 at 11:47:48AM +0200, Christophe Leroy wrote:
> > >
> > >
> > > Le 23/09/2021 à 09:43, Mike Rapopor
On Thu, Sep 23, 2021 at 03:54:46PM +0200, Christophe Leroy wrote:
>
> Le 23/09/2021 à 14:01, Mike Rapoport a écrit :
> > On Thu, Sep 23, 2021 at 11:47:48AM +0200, Christophe Leroy wrote:
> > >
> > >
> > > Le 23/09/2021 à 09:43, Mike Rapopor
On Thu, Sep 23, 2021 at 03:54:46PM +0200, Christophe Leroy wrote:
>
> Le 23/09/2021 à 14:01, Mike Rapoport a écrit :
> > On Thu, Sep 23, 2021 at 11:47:48AM +0200, Christophe Leroy wrote:
> > >
> > >
> > > Le 23/09/2021 à 09:43, Mike Rapopor
On Thu, Sep 23, 2021 at 03:54:46PM +0200, Christophe Leroy wrote:
>
> Le 23/09/2021 à 14:01, Mike Rapoport a écrit :
> > On Thu, Sep 23, 2021 at 11:47:48AM +0200, Christophe Leroy wrote:
> > >
> > >
> > > Le 23/09/2021 à 09:43, Mike Rapopor
Hi Linus,
On Thu, Sep 23, 2021 at 09:01:46AM -0700, Linus Torvalds wrote:
> On Thu, Sep 23, 2021 at 12:43 AM Mike Rapoport wrote:
> >
> You need to be a LOT more careful.
>
> From a trivial check - exactly because I looked at doing it with a
> script, and decided it's
Hi Linus,
On Thu, Sep 23, 2021 at 09:01:46AM -0700, Linus Torvalds wrote:
> On Thu, Sep 23, 2021 at 12:43 AM Mike Rapoport wrote:
> >
> You need to be a LOT more careful.
>
> From a trivial check - exactly because I looked at doing it with a
> script, and decided it's
Hi Linus,
On Thu, Sep 23, 2021 at 09:01:46AM -0700, Linus Torvalds wrote:
> On Thu, Sep 23, 2021 at 12:43 AM Mike Rapoport wrote:
> >
> You need to be a LOT more careful.
>
> From a trivial check - exactly because I looked at doing it with a
> script, and decided it's
Hi Linus,
On Thu, Sep 23, 2021 at 09:01:46AM -0700, Linus Torvalds wrote:
> On Thu, Sep 23, 2021 at 12:43 AM Mike Rapoport wrote:
> >
> You need to be a LOT more careful.
>
> From a trivial check - exactly because I looked at doing it with a
> script, and decided it's
On Thu, Sep 23, 2021 at 11:47:48AM +0200, Christophe Leroy wrote:
>
>
> Le 23/09/2021 à 09:43, Mike Rapoport a écrit :
> > From: Mike Rapoport
> >
> > For ages memblock_free() interface dealt with physical addresses even
> > despite the existence of memblock
On Thu, Sep 23, 2021 at 11:47:48AM +0200, Christophe Leroy wrote:
>
>
> Le 23/09/2021 à 09:43, Mike Rapoport a écrit :
> > From: Mike Rapoport
> >
> > For ages memblock_free() interface dealt with physical addresses even
> > despite the existence of memblock
On Thu, Sep 23, 2021 at 11:47:48AM +0200, Christophe Leroy wrote:
>
>
> Le 23/09/2021 à 09:43, Mike Rapoport a écrit :
> > From: Mike Rapoport
> >
> > For ages memblock_free() interface dealt with physical addresses even
> > despite the existence of memblock
On Thu, Sep 23, 2021 at 11:47:48AM +0200, Christophe Leroy wrote:
>
>
> Le 23/09/2021 à 09:43, Mike Rapoport a écrit :
> > From: Mike Rapoport
> >
> > For ages memblock_free() interface dealt with physical addresses even
> > despite the existence of memblock
From: Mike Rapoport
For ages memblock_free() interface dealt with physical addresses even
despite the existence of memblock_alloc_xx() functions that return a
virtual pointer.
Introduce memblock_phys_free() for freeing physical ranges and repurpose
memblock_free() to free virtual pointers
From: Mike Rapoport
free_p2m_page() wrongly passes a virtual pointer to memblock_free() that
treats it as a physical address.
Call memblock_free_ptr() instead that gets a virtual address to free the
memory.
Signed-off-by: Mike Rapoport
---
arch/x86/xen/p2m.c | 2 +-
1 file changed, 1
From: Mike Rapoport
For ages memblock_free() interface dealt with physical addresses even
despite the existence of memblock_alloc_xx() functions that return a
virtual pointer.
Introduce memblock_phys_free() for freeing physical ranges and repurpose
memblock_free() to free virtual pointers
From: Mike Rapoport
free_p2m_page() wrongly passes a virtual pointer to memblock_free() that
treats it as a physical address.
Call memblock_free_ptr() instead that gets a virtual address to free the
memory.
Signed-off-by: Mike Rapoport
---
arch/x86/xen/p2m.c | 2 +-
1 file changed, 1
From: Mike Rapoport
Memory allocation of numa_distance uses memblock_phys_alloc_range() without
actual range limits, converts the returned physical address to virtual and
then only uses the virtual address for further initialization.
Simplify this by replacing memblock_phys_alloc_range
From: Mike Rapoport
Memory allocation of numa_distance uses memblock_phys_alloc_range() without
actual range limits, converts the returned physical address to virtual and
then only uses the virtual address for further initialization.
Simplify this by replacing memblock_phys_alloc_range
From: Mike Rapoport
Hi,
Following the discussion on [1] this is the fix for memblock freeing APIs
mismatch.
The first patch is a cleanup of numa_distance allocation in arch_numa I've
spotted during the conversion.
The second patch is a fix for Xen memory freeing on some of the error
paths
From: Mike Rapoport
For ages memblock_free() interface dealt with physical addresses even
despite the existence of memblock_alloc_xx() functions that return a
virtual pointer.
Introduce memblock_phys_free() for freeing physical ranges and repurpose
memblock_free() to free virtual pointers
From: Mike Rapoport
For ages memblock_free() interface dealt with physical addresses even
despite the existence of memblock_alloc_xx() functions that return a
virtual pointer.
Introduce memblock_phys_free() for freeing physical ranges and repurpose
memblock_free() to free virtual pointers
From: Mike Rapoport
Hi,
Following the discussion on [1] this is the fix for memblock freeing APIs
mismatch.
The first patch is a cleanup of numa_distance allocation in arch_numa I've
spotted during the conversion.
The second patch is a fix for Xen memory freeing on some of the error
paths
From: Mike Rapoport
free_p2m_page() wrongly passes a virtual pointer to memblock_free() that
treats it as a physical address.
Call memblock_free_ptr() instead that gets a virtual address to free the
memory.
Signed-off-by: Mike Rapoport
---
arch/x86/xen/p2m.c | 2 +-
1 file changed, 1
From: Mike Rapoport
free_p2m_page() wrongly passes a virtual pointer to memblock_free() that
treats it as a physical address.
Call memblock_free_ptr() instead that gets a virtual address to free the
memory.
Signed-off-by: Mike Rapoport
---
arch/x86/xen/p2m.c | 2 +-
1 file changed, 1
901 - 1000 of 6450 matches
Mail list logo