Re: [patch] do_no_pfn

> One struct page for a random single page here, another for a single
> random page there. And the risk that someone will start walking the
> pages and dereference and cause data corruption. As explained before,
> it's a bad idea.

Note sure what your point is. Why should they cause memory corruption?

Allowing struct page less VM is worse. If you add that then people
will use it for other stuff, and eventually we got a two class
VM. All not very good.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

---

• Follow-Ups:
  • Re: [patch] do_no_pfn
    • From: Jes Sorensen <[email protected]>
  • Re: [patch] do_no_pfn
    • From: Robin Holt <[email protected]>

• References:
  • [patch] do_no_pfn
    • From: Jes Sorensen <[email protected]>
  • Re: [patch] do_no_pfn
    • From: Andi Kleen <[email protected]>
  • Re: [patch] do_no_pfn
    • From: Jes Sorensen <[email protected]>

• Prev by Date: Re: [patch] fix spinlock-debug looping
• Next by Date: Re: [RFC] [PATCH 1/8] inode_diet: Replace inode.u.generic_ip with inode.i_private
• Previous by thread: Re: [patch] do_no_pfn
• Next by thread: Re: [patch] do_no_pfn
• Index(es):
  • Date
  • Thread

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]