|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel][PV-ops][PATCH] Netback: Fix PV network issue for netback
To: |
Jeremy Fitzhardinge <jeremy@xxxxxxxx> |
Subject: |
Re: [Xen-devel][PV-ops][PATCH] Netback: Fix PV network issue for netback multiple threads patchset |
From: |
Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx> |
Date: |
Thu, 1 Jul 2010 17:11:57 +0100 |
Cc: |
xen-devel@xxxxxxxxxxxxxxxxxxx, Fantu <fantonifabio@xxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>, "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx>, Paul Durrant <Paul.Durrant@xxxxxxxxxx>, djmagee@xxxxxxxxxxxx |
Delivery-date: |
Thu, 01 Jul 2010 09:12:37 -0700 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
In-reply-to: |
<4C2CBD30.4060704@xxxxxxxx> |
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
List-post: |
<mailto:xen-devel@lists.xensource.com> |
List-subscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
List-unsubscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
Organization: |
Citrix Systems, Inc. |
References: |
<D5AB6E638E5A3E4B8F4406B113A5A19A1F205536@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <1276248930.19091.2870.camel@xxxxxxxxxxxxxxxxxxxxxx> <D5AB6E638E5A3E4B8F4406B113A5A19A1F372F07@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4C1F49B1.3060403@xxxxxxxx> <1277995730.28432.24.camel@xxxxxxxxxxxxxxxxxxxxxx> <4C2CB443.1060907@xxxxxxxx> <1277999255.28432.50.camel@xxxxxxxxxxxxxxxxxxxxxx> <4C2CBD30.4060704@xxxxxxxx> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
On Thu, 2010-07-01 at 17:07 +0100, Jeremy Fitzhardinge wrote:
> On 07/01/2010 05:47 PM, Ian Campbell wrote:
> >> Hm, I hadn't meant to commit that properly. I had it locally and
> >> accidentally pushed it out.
> >>
> >> I only did that patch as an RFC in response to an issue alluded to by
> >> Dongxiao (or was it you?) about things not being fully initialized by
> >> the time the async code starts. Is this a real issue, and if so, what's
> >> the correct fix?
> >>
> > I don't think there is an actual current issue, just a potential one
> > since we are relying on data structures being zeroed rather than
> > properly initialised to keep the async code from running off into the
> > weeds, it just seemed a little fragile this way.
> >
> > Originally I said:
> >
> >>> The crash is in one of the calls to list_move_tail and I think it is
> >>> because netbk->pending_inuse_head not being initialised until after
> >>> the
> >>> threads and/or tasklets are created (I was running in threaded mode).
> >>> Perhaps even though we are now zeroing the netbk struct those fields
> >>> should still be initialised before kicking off any potentially
> >>> asynchronous tasks?
> >>>
> > this specific issue was fixed by zeroing the netbk array as it is
> > allocated, I just thought we could make things more robust by not
> > triggering the async code until everything was fully setup.
> >
>
> It would only affect system startup time, not domain creation?
I think so, it's a race during netback_init.
netbk_action_thread can reference &netbk->net_schedule_list (via
tx_work_todo) before it is initialised. It is now zeroed which is
probably safe but not exactly robust.
> I was looking at it because Stefano was having fairly consistent crashes
> on domain creation, and it looked like sort-of-racy sy
I think this particular race would be long gone by the time you started
a domain. Although I suppose having the thread spinning doing
potentially arbitrary things for a small window during netback_init
could leave things in a fragile enough state that it might fall apart
when you started a domain. I'm not convinced though.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|