Re: [PATCH v2 0/8] mm/kdump: allow to exclude pages that are logically offline
On 2/28/19 2:45 PM, Andrew Morton wrote: > On Wed, 27 Feb 2019 13:32:14 +0800 Dave Young wrote: > >> This series have been in -next for some days, could we get this in >> mainline? > It's been in -next for two months? > >> Andrew, do you have plan about them, maybe next release? > They're all reviewed except for "xen/balloon: mark inflated pages > PG_offline". > (https://ozlabs.org/~akpm/mmotm/broken-out/xen-balloon-mark-inflated-pages-pg_offline.patch). > Yes, I plan on sending these to Linus during the merge window for 5.1 > This was reviewed: https://lore.kernel.org/lkml/3d5250b7-870e-e702-a6e4-937d2362f...@suse.com/ -boris ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1 09/10] mm/memory_hotplug: Don't mark pages PG_reserved when initializing the memmap
On 10/24/19 8:09 AM, David Hildenbrand wrote:
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index 4f2e78a5e4db..af69f057913a 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -374,6 +374,13 @@ static void xen_online_page(struct page *page, unsigned
> int order)
> mutex_lock(&balloon_mutex);
> for (i = 0; i < size; i++) {
> p = pfn_to_page(start_pfn + i);
> + /*
> + * TODO: The core used to mark the pages reserved. Most probably
> + * we can stop doing that now. However, especially
> + * alloc_xenballooned_pages() left PG_reserved set
> + * on pages that can get mapped to user space.
> + */
> + __SetPageReserved(p);
I suspect this is not needed. Pages can get into balloon either from
here or from non-hotplug path (e.g. decrease_reservation()) and so when
we get a page from the balloon we would get a random page that may or
may not have Reserved bit set.
-boris
> balloon_append(p);
> }
> mutex_unlock(&balloon_mutex);
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1 09/10] mm/memory_hotplug: Don't mark pages PG_reserved when initializing the memmap
On 11/5/19 5:18 AM, David Hildenbrand wrote:
> On 04.11.19 23:44, Boris Ostrovsky wrote:
>> On 10/24/19 8:09 AM, David Hildenbrand wrote:
>>> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
>>> index 4f2e78a5e4db..af69f057913a 100644
>>> --- a/drivers/xen/balloon.c
>>> +++ b/drivers/xen/balloon.c
>>> @@ -374,6 +374,13 @@ static void xen_online_page(struct page *page,
>>> unsigned int order)
>>> mutex_lock(&balloon_mutex);
>>> for (i = 0; i < size; i++) {
>>> p = pfn_to_page(start_pfn + i);
>>> + /*
>>> + * TODO: The core used to mark the pages reserved. Most
>>> probably
>>> + * we can stop doing that now. However, especially
>>> + * alloc_xenballooned_pages() left PG_reserved set
>>> + * on pages that can get mapped to user space.
>>> + */
>>> + __SetPageReserved(p);
>>
>> I suspect this is not needed. Pages can get into balloon either from
>> here or from non-hotplug path (e.g. decrease_reservation()) and so when
>> we get a page from the balloon we would get a random page that may or
>> may not have Reserved bit set.
>
> Yeah, I also think it is fine. If you agree, I'll drop this hunk and
> add details to the patch description.
>
>
Yes, let's do that. Thanks.
-boris
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] dma-buf: add struct dma_buf_attach_info v2
On 4/30/19 7:10 AM, Christian König wrote:
> diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
> index 2c4f324f8626..cacca830b482 100644
> --- a/drivers/xen/gntdev-dmabuf.c
> +++ b/drivers/xen/gntdev-dmabuf.c
> @@ -608,6 +608,7 @@ dmabuf_imp_to_refs(struct gntdev_dmabuf_priv *priv,
> struct device *dev,
> int fd, int count, int domid)
> {
> struct gntdev_dmabuf *gntdev_dmabuf, *ret;
> + struct dma_buf_attach_info attach_info;
> struct dma_buf *dma_buf;
> struct dma_buf_attachment *attach;
> struct sg_table *sgt;
> @@ -627,6 +628,9 @@ dmabuf_imp_to_refs(struct gntdev_dmabuf_priv *priv,
> struct device *dev,
> gntdev_dmabuf->priv = priv;
> gntdev_dmabuf->fd = fd;
>
> + memset(&attach_info, 0, sizeof(attach_info));
> + attach_info.dev = dev;
> + attach_info.dmabuf = dma_buf;
> attach = dma_buf_attach(dma_buf, dev);
> if (IS_ERR(attach)) {
> ret = ERR_CAST(attach);
This won't build.
Did you mean
attach = dma_buf_attach(&attach_info);
?
-boris
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [Xen-devel] [PATCH 29/29] drivers, xen: convert grant_map.users from atomic_t to refcount_t
On 03/06/2017 09:21 AM, Elena Reshetova wrote: > refcount_t type and corresponding API should be > used instead of atomic_t when the variable is used as > a reference counter. This allows to avoid accidental > refcounter overflows that might lead to use-after-free > situations. > > Signed-off-by: Elena Reshetova > Signed-off-by: Hans Liljestrand > Signed-off-by: Kees Cook > Signed-off-by: David Windsor > --- > drivers/xen/gntdev.c | 11 ++- > 1 file changed, 6 insertions(+), 5 deletions(-) Reviewed-by: Boris Ostrovsky ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [Xen-devel] [PATCH 29/29] drivers, xen: convert grant_map.users from atomic_t to refcount_t
On 03/08/2017 08:49 AM, Reshetova, Elena wrote: >> On 03/06/2017 09:21 AM, Elena Reshetova wrote: >>> refcount_t type and corresponding API should be >>> used instead of atomic_t when the variable is used as >>> a reference counter. This allows to avoid accidental >>> refcounter overflows that might lead to use-after-free >>> situations. >>> >>> Signed-off-by: Elena Reshetova >>> Signed-off-by: Hans Liljestrand >>> Signed-off-by: Kees Cook >>> Signed-off-by: David Windsor >>> --- >>> drivers/xen/gntdev.c | 11 ++- >>> 1 file changed, 6 insertions(+), 5 deletions(-) >> Reviewed-by: Boris Ostrovsky > Is there a tree that can take this change? Turns out it is better to > propagate changes via separate trees and only leftovers can be taken via > Greg's tree. > Sure, we can take it via Xen tree for rc3. -boris ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
