From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Miller <davem@davemloft.net>,
Ian Campbell <Ian.Campbell@eu.citrix.com>
Cc: mgorman@suse.de, xen-devel@lists.xensource.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, konrad@darnok.org, akpm@linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] netvm: check for page == NULL when propogating the skb->pfmemalloc flag
Date: Mon, 13 Aug 2012 11:41:44 -0400 [thread overview]
Message-ID: <20120813154144.GA24868@phenom.dumpdata.com> (raw)
In-Reply-To: <20120808.155046.820543563969484712.davem@davemloft.net>
On Wed, Aug 08, 2012 at 03:50:46PM -0700, David Miller wrote:
> From: Mel Gorman <mgorman@suse.de>
> Date: Tue, 7 Aug 2012 09:55:55 +0100
>
> > Commit [c48a11c7: netvm: propagate page->pfmemalloc to skb] is responsible
> > for the following bug triggered by a xen network driver
> ...
> > The problem is that the xenfront driver is passing a NULL page to
> > __skb_fill_page_desc() which was unexpected. This patch checks that
> > there is a page before dereferencing.
> >
> > Reported-and-Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Signed-off-by: Mel Gorman <mgorman@suse.de>
>
> That call to __skb_fill_page_desc() in xen-netfront.c looks completely bogus.
> It's the only driver passing NULL here.
It looks to be passing a valid page pointer (at least by looking
at the code) so I am not sure how it got turned in a NULL.
But let me double-check by instrumenting the driver..
>
> That whole song and dance figuring out what to do with the head
> fragment page, depending upon whether the length is greater than the
> RX_COPY_THRESHOLD, is completely unnecessary.
>
> Just use something like a call to __pskb_pull_tail(skb, len) and all
> that other crap around that area can simply be deleted.
It looks like an overkill - it does a lot more than just allocate an SKB
and a page.
Deleting of extra code would be nice - however I am not going to be able
to do that for the next two weeks sadly - as my plate if full of debugging
some other stuff.
Lets see if Ian has some time.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Miller <davem@davemloft.net>,
Ian Campbell <Ian.Campbell@eu.citrix.com>
Cc: mgorman@suse.de, xen-devel@lists.xensource.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Ian.Campbell@eu.citrix.com, linux-mm@kvack.org,
konrad@darnok.org, akpm@linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] netvm: check for page == NULL when propogating the skb->pfmemalloc flag
Date: Mon, 13 Aug 2012 11:41:44 -0400 [thread overview]
Message-ID: <20120813154144.GA24868@phenom.dumpdata.com> (raw)
In-Reply-To: <20120808.155046.820543563969484712.davem@davemloft.net>
On Wed, Aug 08, 2012 at 03:50:46PM -0700, David Miller wrote:
> From: Mel Gorman <mgorman@suse.de>
> Date: Tue, 7 Aug 2012 09:55:55 +0100
>
> > Commit [c48a11c7: netvm: propagate page->pfmemalloc to skb] is responsible
> > for the following bug triggered by a xen network driver
> ...
> > The problem is that the xenfront driver is passing a NULL page to
> > __skb_fill_page_desc() which was unexpected. This patch checks that
> > there is a page before dereferencing.
> >
> > Reported-and-Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Signed-off-by: Mel Gorman <mgorman@suse.de>
>
> That call to __skb_fill_page_desc() in xen-netfront.c looks completely bogus.
> It's the only driver passing NULL here.
It looks to be passing a valid page pointer (at least by looking
at the code) so I am not sure how it got turned in a NULL.
But let me double-check by instrumenting the driver..
>
> That whole song and dance figuring out what to do with the head
> fragment page, depending upon whether the length is greater than the
> RX_COPY_THRESHOLD, is completely unnecessary.
>
> Just use something like a call to __pskb_pull_tail(skb, len) and all
> that other crap around that area can simply be deleted.
It looks like an overkill - it does a lot more than just allocate an SKB
and a page.
Deleting of extra code would be nice - however I am not going to be able
to do that for the next two weeks sadly - as my plate if full of debugging
some other stuff.
Lets see if Ian has some time.
WARNING: multiple messages have this Message-ID (diff)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Miller <davem@davemloft.net>,
Ian Campbell <Ian.Campbell@eu.citrix.com>
Cc: mgorman@suse.de, xen-devel@lists.xensource.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Ian.Campbell@eu.citrix.com, linux-mm@kvack.org,
konrad@darnok.org, akpm@linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] netvm: check for page == NULL when propogating the skb->pfmemalloc flag
Date: Mon, 13 Aug 2012 11:41:44 -0400 [thread overview]
Message-ID: <20120813154144.GA24868@phenom.dumpdata.com> (raw)
In-Reply-To: <20120808.155046.820543563969484712.davem@davemloft.net>
On Wed, Aug 08, 2012 at 03:50:46PM -0700, David Miller wrote:
> From: Mel Gorman <mgorman@suse.de>
> Date: Tue, 7 Aug 2012 09:55:55 +0100
>
> > Commit [c48a11c7: netvm: propagate page->pfmemalloc to skb] is responsible
> > for the following bug triggered by a xen network driver
> ...
> > The problem is that the xenfront driver is passing a NULL page to
> > __skb_fill_page_desc() which was unexpected. This patch checks that
> > there is a page before dereferencing.
> >
> > Reported-and-Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Signed-off-by: Mel Gorman <mgorman@suse.de>
>
> That call to __skb_fill_page_desc() in xen-netfront.c looks completely bogus.
> It's the only driver passing NULL here.
It looks to be passing a valid page pointer (at least by looking
at the code) so I am not sure how it got turned in a NULL.
But let me double-check by instrumenting the driver..
>
> That whole song and dance figuring out what to do with the head
> fragment page, depending upon whether the length is greater than the
> RX_COPY_THRESHOLD, is completely unnecessary.
>
> Just use something like a call to __pskb_pull_tail(skb, len) and all
> that other crap around that area can simply be deleted.
It looks like an overkill - it does a lot more than just allocate an SKB
and a page.
Deleting of extra code would be nice - however I am not going to be able
to do that for the next two weeks sadly - as my plate if full of debugging
some other stuff.
Lets see if Ian has some time.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Miller <davem@davemloft.net>
Cc: mgorman@suse.de, xen-devel@lists.xensource.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Ian.Campbell@eu.citrix.com, linux-mm@kvack.org,
konrad@darnok.org, akpm@linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] netvm: check for page == NULL when propogating the skb->pfmemalloc flag
Date: Mon, 13 Aug 2012 11:41:44 -0400 [thread overview]
Message-ID: <20120813154144.GA24868@phenom.dumpdata.com> (raw)
In-Reply-To: <20120808.155046.820543563969484712.davem@davemloft.net>
On Wed, Aug 08, 2012 at 03:50:46PM -0700, David Miller wrote:
> From: Mel Gorman <mgorman@suse.de>
> Date: Tue, 7 Aug 2012 09:55:55 +0100
>
> > Commit [c48a11c7: netvm: propagate page->pfmemalloc to skb] is responsible
> > for the following bug triggered by a xen network driver
> ...
> > The problem is that the xenfront driver is passing a NULL page to
> > __skb_fill_page_desc() which was unexpected. This patch checks that
> > there is a page before dereferencing.
> >
> > Reported-and-Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Signed-off-by: Mel Gorman <mgorman@suse.de>
>
> That call to __skb_fill_page_desc() in xen-netfront.c looks completely bogus.
> It's the only driver passing NULL here.
It looks to be passing a valid page pointer (at least by looking
at the code) so I am not sure how it got turned in a NULL.
But let me double-check by instrumenting the driver..
>
> That whole song and dance figuring out what to do with the head
> fragment page, depending upon whether the length is greater than the
> RX_COPY_THRESHOLD, is completely unnecessary.
>
> Just use something like a call to __pskb_pull_tail(skb, len) and all
> that other crap around that area can simply be deleted.
It looks like an overkill - it does a lot more than just allocate an SKB
and a page.
Deleting of extra code would be nice - however I am not going to be able
to do that for the next two weeks sadly - as my plate if full of debugging
some other stuff.
Lets see if Ian has some time.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2012-08-13 15:51 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-07 8:55 [PATCH] netvm: check for page == NULL when propogating the skb->pfmemalloc flag Mel Gorman
2012-08-07 8:55 ` Mel Gorman
2012-08-08 19:14 ` Rik van Riel
2012-08-08 19:14 ` Rik van Riel
2012-08-08 22:50 ` David Miller
2012-08-08 22:50 ` David Miller
2012-08-13 10:26 ` Mel Gorman
2012-08-13 10:26 ` Mel Gorman
2012-08-13 10:47 ` Mel Gorman
2012-08-13 10:47 ` Mel Gorman
2012-08-13 18:56 ` Jeremy Fitzhardinge
2012-08-13 18:56 ` Jeremy Fitzhardinge
2012-08-14 10:18 ` Mel Gorman
2012-08-14 10:18 ` Mel Gorman
2012-08-13 15:41 ` Konrad Rzeszutek Wilk [this message]
2012-08-13 15:41 ` [Xen-devel] " Konrad Rzeszutek Wilk
2012-08-13 15:41 ` Konrad Rzeszutek Wilk
2012-08-13 15:41 ` Konrad Rzeszutek Wilk
2012-08-14 10:05 ` Mel Gorman
2012-08-14 10:05 ` Mel Gorman
2012-08-14 13:28 ` Konrad Rzeszutek Wilk
2012-08-14 13:28 ` Konrad Rzeszutek Wilk
2012-08-22 10:26 ` Ian Campbell
2012-08-22 10:26 ` Ian Campbell
2012-08-23 14:17 ` Konrad Rzeszutek Wilk
2012-08-23 14:17 ` Konrad Rzeszutek Wilk
2012-08-30 16:24 ` David Miller
2012-08-30 16:24 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120813154144.GA24868@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=Ian.Campbell@eu.citrix.com \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=konrad@darnok.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=netdev@vger.kernel.org \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.