[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] PG_blkback handling issue?

  • To: Jan Beulich <JBeulich@xxxxxxxxxx>
  • From: jake wires <jake.wires@xxxxxxxxx>
  • Date: Mon, 19 Oct 2009 11:31:50 -0700
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 19 Oct 2009 11:32:17 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bZuQUhoEHFbWb/sdwRDgvcsrTBa0F4NPBxlgqLZzvy5MwNhxSnFiF5usnr0tAP/nEw DlcDuLgdGdTAxgy7ShEOKMzRqlf/7x2lV3vaK6J5ZH/xHeARAJJNwyv1W/OKTczKqfqK s67ZwQSVaha4Nt1pzn8rc4Mtd2v56mfB1xoic=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

This flag is only ever set for special pages acquired in blkback (and blktap2) via alloc_empty_pages_and_pagevec(), so in a sense the PG_blkback flag always does apply, but I suppose it would be safe to clear it in blkback_pagemap_clear().


On Fri, Oct 16, 2009 at 12:50 AM, Jan Beulich <JBeulich@xxxxxxxxxx> wrote:
This flag, introduced with blktap2, seems to be sticky when blktap2 isn't
actively involved in any operations, since blkback-pagemap.c is only ever
setting or testing this bit. Shouldn't blkback_pagemap_clear() clear it?

And it would seem to me that, for safety purposes, both PG_blkback and
PG_netback should be included in the checks in mm/page_alloc.c which
already look at PG_foreign and (for ix86) PG_pinned.

Thanks, Jan

Xen-devel mailing list

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.