> #ifdef CONFIG_FLATMEM
> -#define pfn_valid(pfn) (((pfn) - ARCH_PFN_OFFSET) < max_mapnr)
> +#define pfn_valid(pfn) ((pfn) >= ARCH_PFN_OFFSET && ((pfn) -
> ARCH_PFN_OFFSET) < max_mapnr)
> #endif
>
> /*
> --
> 2.7.4
>
--
Michal
ccupied for example and allocate just before
> closest vma. So this solution doesn’t give that much security like
> randomization address inside kernel.
The userspace can use the new MAP_FIXED_NOREPLACE to probe for the
address range atomically and chose a different range on failure.
On Mon 26-03-18 22:45:31, Ilya Smith wrote:
>
> > On 26 Mar 2018, at 11:46, Michal Hocko wrote:
> >
> > On Fri 23-03-18 20:55:49, Ilya Smith wrote:
> >>
> >>> On 23 Mar 2018, at 15:48, Matthew Wilcox wrote:
> >>>
> >&
On Tue 27-03-18 16:51:08, Ilya Smith wrote:
>
> > On 27 Mar 2018, at 10:24, Michal Hocko wrote:
> >
> > On Mon 26-03-18 22:45:31, Ilya Smith wrote:
> >>
> >>> On 26 Mar 2018, at 11:46, Michal Hocko wrote:
> >>>
> >>> On Fri 2
| 4 ++--
> mm/memory.c | 2 +-
> 23 files changed, 18 insertions(+), 24 deletions(-)
>
> --
> 2.7.4
--
Michal Hocko
SUSE Labs
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
page tables.
>* eg. VDSO mappings can cause them to exist.
>*/
> -out:
> +out: __maybe_unused
> return pfn_to_page(pfn);
Why do we need this ugliness all of the sudden?
--
Michal Hocko
SUSE Labs
___
linux-s
ed-by: Jerome Glisse
> Reviewed-by: Jerome Glisse
> Acked-by: David Rientjes
> Signed-off-by: Laurent Dufour
Looks good to me. I have checked x86 and the generic code and it looks
good to me. Anyway arch maintainers really have to double check this.
--
Michal Hocko
SUSE L
On Wed 11-04-18 10:41:23, Laurent Dufour wrote:
> On 11/04/2018 10:33, Michal Hocko wrote:
> > On Wed 11-04-18 10:03:36, Laurent Dufour wrote:
> >> @@ -881,7 +876,8 @@ struct page *_vm_normal_page(struct vm_area_struct
> >> *vma, unsigned long addr,
> &g
On Wed 11-04-18 12:32:07, Laurent Dufour wrote:
[...]
> Andrew, should I send a v4 or could you wipe the 2 __maybe_unsued when
> applying
> the patch ?
A follow $patch-fix should be better rather than post this again and
spam people with more emails.
--
Michal Hocko
g that I've seen a patch to address
that. It would be great to have it folded to this one.
> Signed-off-by: Mike Rapoport
Acked-by: Michal Hocko
--
Michal Hocko
SUSE Labs
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
ht
Acked-by: Michal Hocko
--
Michal Hocko
SUSE Labs
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
On Fri 14-09-18 15:10:20, Mike Rapoport wrote:
> Several bootmem functions and macros are not used. Remove them.
>
> Signed-off-by: Mike Rapoport
Acked-by: Michal Hocko
--
Michal Hocko
SUSE Labs
___
linux-snps-arc mailing list
linux
if (slab_is_available())
> section = kzalloc_node(array_size, GFP_KERNEL, nid);
> else
> - section = memblock_alloc_node(array_size, nid);
> + section = memblock_alloc_node(array_size, 0, nid);
>
> return section;
> }
> --
&
by this change. It is
unnecessary churn. So if nothing else just add a note _why_ you think
this is better.
--
Michal Hocko
SUSE Labs
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
On Wed 26-09-18 11:31:27, Michal Hocko wrote:
> On Fri 14-09-18 15:10:29, Mike Rapoport wrote:
> > With the align parameter memblock_alloc_node() can be used as drop in
> > replacement for alloc_bootmem_pages_node() and __alloc_bootmem_node(),
> > which is done in the follow
On Fri 14-09-18 15:10:31, Mike Rapoport wrote:
> Use memblock_alloc_try_nid whenever goal (i.e. minimal address is
> specified) and memblock_alloc_node otherwise.
>
> Signed-off-by: Mike Rapoport
Acked-by: Michal Hocko
--
Michal Hoc
f (new == NULL) {
> pr_err("Alloc_bootmem failed\n");
> return 1;
> diff --git a/drivers/macintosh/smu.c b/drivers/macintosh/smu.c
> index e8ae2e5..332fcca 100644
> --- a/drivers/macintosh/smu.c
> +++ b/drivers/macintosh/smu.c
> @@ -493,7 +493,7 @@ int __init smu_init (vo
l of duplicated '#include
>
> @@
> @@
> - #include
> + #include
>
> Signed-off-by: Mike Rapoport
Acked-by: Michal Hocko
--
Michal Hocko
SUSE Labs
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://l
cks from the previous
iteration and there are only minor comments. This looks good overall.
Nice work Mike!
--
Michal Hocko
SUSE Labs
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
On Wed 26-09-18 16:43:35, Mike Rapoport wrote:
> On Wed, Sep 26, 2018 at 11:36:48AM +0200, Michal Hocko wrote:
> > On Wed 26-09-18 11:31:27, Michal Hocko wrote:
> > > On Fri 14-09-18 15:10:29, Mike Rapoport wrote:
> > > > With the align parameter memblock_alloc
ce to sift thru when debugging pesky issues.
But show_regs is called from contexts which might be called from deep
call chains (e.g WARN). Is it safe to allocate such a large stack there?
--
Michal Hocko
SUSE Labs
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
e actual problem
rather than build on top of it instead?
Or maybe I am just missing something here.
--
Michal Hocko
SUSE Labs
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
On Thu 20-12-18 18:45:48, Vineet Gupta wrote:
> On 12/20/18 5:04 AM, Michal Hocko wrote:
> > On Tue 18-12-18 10:53:59, Vineet Gupta wrote:
> >> signal handling core calls ARCH show_regs() with preemption disabled
> >> which causes __might_sleep functions such as mmput le
On Fri 21-12-18 14:04:04, Michal Hocko wrote:
[...]
> Yes, but you are building on a broken concept I believe. What
> implications does re-enabling really have? Now you could reschedule and
> you can move to another CPU. Is this really safe? I believe that yes
> because the preemption
On Fri 21-12-18 09:55:34, Vineet Gupta wrote:
> On 12/21/18 5:04 AM, Michal Hocko wrote:
[...]
> > Yes, the fix might be more involved but I would much rather prefer a
> > correct code which builds on solid assumptions.
>
> Right so the first step is reverting the disabled
t be order bases
http://lkml.kernel.org/r/20180423000943.go17...@dhcp22.suse.cz
Order based API makes sense for the buddy allocator but why should we
restrict sizes like that for an allocator that is capable to allocate
arbitrary page sized requests?
--
Michal Hocko
SUSE Labs
___
nd what they are testing for would be
really appreciated. Who wants to run these tests and why/when? What kind
of bugs would get detected? In short why do we really need/want this
code in the tree?
--
Michal Hocko
SUSE Labs
___
linux-snps-
o_online_page() here
> instead of a pfn_valid() ?
http://lkml.kernel.org/r/20180423000943.go17...@dhcp22.suse.cz
--
Michal Hocko
SUSE Labs
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
On Tue 15-10-19 13:50:02, David Hildenbrand wrote:
> On 15.10.19 13:47, Michal Hocko wrote:
> > On Tue 15-10-19 13:42:03, David Hildenbrand wrote:
> > [...]
> > > > -static bool pfn_range_valid_gigantic(struct zone *z,
> > > > - unsigned
On Tue 15-10-19 14:09:56, Michal Hocko wrote:
> On Tue 15-10-19 13:50:02, David Hildenbrand wrote:
> > On 15.10.19 13:47, Michal Hocko wrote:
> > > On Tue 15-10-19 13:42:03, David Hildenbrand wrote:
> > > [...]
> > > > > -static bo
Poisoned(p))
> [ 13.898549][T1] [ cut here ]
> [ 13.898549][T1] kernel BUG at ./include/linux/mm.h:1107!
> [ 13.898549][ T1] invalid opcode: [#1] SMP DEBUG_PAGEALLOC KASAN PTI
> [ 13.898549][T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
from greater address
space would do that explicitly than other way around.
--
Michal Hocko
SUSE Labs
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
On Thu 29-08-24 10:33:22, Charlie Jenkins wrote:
> On Thu, Aug 29, 2024 at 10:30:56AM +0200, Michal Hocko wrote:
> > On Thu 29-08-24 00:15:57, Charlie Jenkins wrote:
> > > Some applications rely on placing data in free bits addresses allocated
> > > by mmap. Various ar
33 matches
Mail list logo
