linux-kernel - Re: [RFC v3][PATCH 4/9] Memory management (dump)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1220552725.23386.46.camel@nimitz>
Date:	Thu, 04 Sep 2008 11:25:25 -0700
From:	Dave Hansen <dave@...ux.vnet.ibm.com>
To:	Oren Laadan <orenl@...columbia.edu>
Cc:	containers@...ts.linux-foundation.org, jeremy@...p.org,
	linux-kernel@...r.kernel.org, arnd@...db.de
Subject: Re: [RFC v3][PATCH 4/9] Memory management (dump)

On Thu, 2008-09-04 at 04:03 -0400, Oren Laadan wrote:
> +/* free a chain of page-arrays */
> +void cr_pgarr_free(struct cr_ctx *ctx)
> +{
> +       struct cr_pgarr *pgarr, *pgnxt;
> +
> +       for (pgarr = ctx->pgarr; pgarr; pgarr = pgnxt) {
> +               _cr_pgarr_release(ctx, pgarr);
> +               free_pages((unsigned long) ctx->pgarr->addrs, CR_PGARR_ORDER);
> +               free_pages((unsigned long) ctx->pgarr->pages, CR_PGARR_ORDER);
> +               pgnxt = pgarr->next;
> +               kfree(pgarr);
> +       }
> +}

What we effectively have here is:

void *addrs[CR_PGARR_TOTAL];
void *pages[CR_PGARR_TOTAL];

right?

Would any of this get simpler if we just had:

struct cr_page {
	struct page *page;
	unsigned long vaddr;
};

struct cr_pgarr {
       struct cr_page *cr_pages;
       struct cr_pgarr *next;
       unsigned short nleft;
       unsigned short nused;
};

Also, we do have lots of linked list implementations in the kernel.
They do lots of fun stuff like poisoning and checking for
initialization.  We should use them instead of rolling our own.  It lets
us do other fun stuff like list_for_each().

Also, just looking at this structure 'nleft' and 'nused' sound a bit
redundant.  I know from looking at the code that this is how many have
been filled and read back at restore time, but that is not very obvious
looking at the structure.  I think we can do a bit better in the
structure itself.

The length of the arrays is fixed at compile-time, right?  Should we
just make that explicit as well?  

-- Dave

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