* RE: [PATCH 1/1] Drivers: scsi: storvsc: Don't pass ATA_16 command to the host
From: KY Srinivasan @ 2012-03-02 21:33 UTC (permalink / raw)
To: Greg KH
Cc: linux-scsi@vger.kernel.org, Haiyang Zhang, ohering@suse.com,
jbottomley@parallels.com, linux-kernel@vger.kernel.org,
hch@infradead.org, virtualization@lists.osdl.org,
devel@linuxdriverproject.org
In-Reply-To: <20120302213116.GA23443@kroah.com>
> -----Original Message-----
> From: Greg KH [mailto:gregkh@linuxfoundation.org]
> Sent: Friday, March 02, 2012 4:31 PM
> To: KY Srinivasan
> Cc: linux-scsi@vger.kernel.org; Haiyang Zhang; ohering@suse.com;
> jbottomley@parallels.com; linux-kernel@vger.kernel.org; hch@infradead.org;
> virtualization@lists.osdl.org; devel@linuxdriverproject.org
> Subject: Re: [PATCH 1/1] Drivers: scsi: storvsc: Don't pass ATA_16 command to
> the host
>
> On Fri, Mar 02, 2012 at 09:22:38PM +0000, KY Srinivasan wrote:
> >
> >
> > > -----Original Message-----
> > > From: Greg KH [mailto:gregkh@linuxfoundation.org]
> > > Sent: Friday, March 02, 2012 4:14 PM
> > > To: KY Srinivasan
> > > Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> > > virtualization@lists.osdl.org; ohering@suse.com; jbottomley@parallels.com;
> > > hch@infradead.org; linux-scsi@vger.kernel.org; Haiyang Zhang
> > > Subject: Re: [PATCH 1/1] Drivers: scsi: storvsc: Don't pass ATA_16 command to
> > > the host
> > >
> > > On Fri, Mar 02, 2012 at 12:49:07PM -0800, K. Y. Srinivasan wrote:
> > > > Windows hosts don't handle the ATA_16 command; don't pass it to the
> host.
> > > >
> > > > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > > > Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> > > > ---
> > > > drivers/scsi/storvsc_drv.c | 2 ++
> > > > 1 files changed, 2 insertions(+), 0 deletions(-)
> > >
> > > Should this go to older kernel versions as well?
> >
> > I think it should. Do you want me to resend this patch with the correct tag?
> > Also, given that storvsc has changed so much over the last several months,
> > this patch may or may not apply to earlier versions of this driver even though
> > this patch itself is quite trivial.
>
> I'll tag it for the stable tree, then when it doesn't apply, you will
> get an email saying it didn't, so you can then send me the correct one
> :)
Thanks Greg.
K. Y
^ permalink raw reply
* Re: [PATCH 1/1] Drivers: scsi: storvsc: Don't pass ATA_16 command to the host
From: Greg KH @ 2012-03-02 21:31 UTC (permalink / raw)
To: KY Srinivasan
Cc: linux-scsi@vger.kernel.org, Haiyang Zhang, ohering@suse.com,
jbottomley@parallels.com, linux-kernel@vger.kernel.org,
hch@infradead.org, virtualization@lists.osdl.org,
devel@linuxdriverproject.org
In-Reply-To: <6E21E5352C11B742B20C142EB499E0481B736783@TK5EX14MBXC126.redmond.corp.microsoft.com>
On Fri, Mar 02, 2012 at 09:22:38PM +0000, KY Srinivasan wrote:
>
>
> > -----Original Message-----
> > From: Greg KH [mailto:gregkh@linuxfoundation.org]
> > Sent: Friday, March 02, 2012 4:14 PM
> > To: KY Srinivasan
> > Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> > virtualization@lists.osdl.org; ohering@suse.com; jbottomley@parallels.com;
> > hch@infradead.org; linux-scsi@vger.kernel.org; Haiyang Zhang
> > Subject: Re: [PATCH 1/1] Drivers: scsi: storvsc: Don't pass ATA_16 command to
> > the host
> >
> > On Fri, Mar 02, 2012 at 12:49:07PM -0800, K. Y. Srinivasan wrote:
> > > Windows hosts don't handle the ATA_16 command; don't pass it to the host.
> > >
> > > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > > Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> > > ---
> > > drivers/scsi/storvsc_drv.c | 2 ++
> > > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > Should this go to older kernel versions as well?
>
> I think it should. Do you want me to resend this patch with the correct tag?
> Also, given that storvsc has changed so much over the last several months,
> this patch may or may not apply to earlier versions of this driver even though
> this patch itself is quite trivial.
I'll tag it for the stable tree, then when it doesn't apply, you will
get an email saying it didn't, so you can then send me the correct one
:)
thanks,
greg k-h
^ permalink raw reply
* RE: [PATCH 1/1] Drivers: scsi: storvsc: Don't pass ATA_16 command to the host
From: KY Srinivasan @ 2012-03-02 21:22 UTC (permalink / raw)
To: Greg KH
Cc: linux-kernel@vger.kernel.org, devel@linuxdriverproject.org,
virtualization@lists.osdl.org, ohering@suse.com,
jbottomley@parallels.com, hch@infradead.org,
linux-scsi@vger.kernel.org, Haiyang Zhang
In-Reply-To: <20120302211354.GB6008@kroah.com>
> -----Original Message-----
> From: Greg KH [mailto:gregkh@linuxfoundation.org]
> Sent: Friday, March 02, 2012 4:14 PM
> To: KY Srinivasan
> Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> virtualization@lists.osdl.org; ohering@suse.com; jbottomley@parallels.com;
> hch@infradead.org; linux-scsi@vger.kernel.org; Haiyang Zhang
> Subject: Re: [PATCH 1/1] Drivers: scsi: storvsc: Don't pass ATA_16 command to
> the host
>
> On Fri, Mar 02, 2012 at 12:49:07PM -0800, K. Y. Srinivasan wrote:
> > Windows hosts don't handle the ATA_16 command; don't pass it to the host.
> >
> > Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> > Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> > ---
> > drivers/scsi/storvsc_drv.c | 2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
>
> Should this go to older kernel versions as well?
I think it should. Do you want me to resend this patch with the correct tag?
Also, given that storvsc has changed so much over the last several months,
this patch may or may not apply to earlier versions of this driver even though
this patch itself is quite trivial.
Regards,
K. Y
^ permalink raw reply
* Re: [PATCH 1/1] Drivers: scsi: storvsc: Don't pass ATA_16 command to the host
From: Greg KH @ 2012-03-02 21:13 UTC (permalink / raw)
To: K. Y. Srinivasan
Cc: linux-kernel, devel, virtualization, ohering, jbottomley, hch,
linux-scsi, Haiyang Zhang
In-Reply-To: <1330721347-26781-1-git-send-email-kys@microsoft.com>
On Fri, Mar 02, 2012 at 12:49:07PM -0800, K. Y. Srinivasan wrote:
> Windows hosts don't handle the ATA_16 command; don't pass it to the host.
>
> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> ---
> drivers/scsi/storvsc_drv.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
Should this go to older kernel versions as well?
greg k-h
^ permalink raw reply
* [PATCH 1/1] Drivers: scsi: storvsc: Don't pass ATA_16 command to the host
From: K. Y. Srinivasan @ 2012-03-02 20:49 UTC (permalink / raw)
To: gregkh, linux-kernel, devel, virtualization, ohering, jbottomley,
hch, linux-scsi
Cc: K. Y. Srinivasan, Haiyang Zhang
Windows hosts don't handle the ATA_16 command; don't pass it to the host.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
---
drivers/scsi/storvsc_drv.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 44c7a48..1404c9b 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1221,8 +1221,10 @@ static bool storvsc_scsi_cmd_ok(struct scsi_cmnd *scmnd)
/*
* smartd sends this command and the host does not handle
* this. So, don't send it.
+ * Host also does not support ATA_16 command.
*/
case SET_WINDOW:
+ case ATA_16:
scmnd->result = ILLEGAL_REQUEST << 16;
allowed = false;
break;
--
1.7.4.1
^ permalink raw reply related
* Call for Papers: eScience 2012 and associated workshops and tutorial
From: Ioan Raicu @ 2012-03-02 2:02 UTC (permalink / raw)
To: virtualization
[-- Attachment #1.1: Type: text/plain, Size: 11812 bytes --]
*Call for Papers: eScience 2012 and associated workshops*
*
*
In addition to the eScience conference itself, described below, there
are six associated workshops and one tutorial
(http://www.ci.uchicago.edu/escience2012/workshops.php)
* Extending High-Performance Computing Beyond its Traditional User
Communities, http://www.psc.edu/events/escience-2012-workshop/
* 2nd International Workshop on Analyzing and Improving Collaborative
eScience with Social Networks (eSoN 12),
http://www.ci.uchicago.edu/eson2012/
* Advances in eHealth,
http://www.scalalife.eu/content/advances-ehealth-2012-workshop
* Maintainable Software Practices in e-Science,
http://software.ac.uk/maintainable-software-practice-workshop
* eScience Meets the Instrument,
https://confluence-vre.its.monash.edu.au/display/escience2012/eScience+Meets+the+Instrument
* Collaborative research using eScience infrastructure and high speed
networks,
http://www.surfnet.nl/en/Hybride_netwerk/SURFlichtpaden/Pages/CollaborativeresearchusingeScienceinfrastructureandhighspeednetworks.aspx
* Tutorial: Big Data Processing: Lessons from Industry and
Applications in Science,
http://www.ci.uchicago.edu/escience2012/tutorial.php
CALL FOR PAPERS
8th IEEE International Conference on eScience
http://www.ci.uchicago.edu/escience2012/
October 8-12, 2012
Chicago, IL, USA
Researchers in all disciplines are increasingly adopting digital tools,
techniques and practices, often in communities and projects that span
disciplines, laboratories, organizations, and national boundaries. The
eScience 2012 conference is designed to bring together leading
international and interdisciplinary research communities, developers,
and users of eScience applications and enabling IT technologies. The
conference serves as a forum to present the results of the latest
applications research and product/tool developments and to highlight
related activities from around the world. Also, we are now entering the
second decade of eScience and the 2012 conference gives an opportunity
to take stock of what has been achieved so far and look forward to the
challenges and opportunities the next decade will bring.
A special emphasis of the 2012 conference is on advances in the
application of technology in a particular discipline. Accordingly,
significant advances in applications science and technology will be
considered as important as the development of new technologies
themselves. Further, we welcome contributions in educational activities
under any of these disciplines.
As a result, the conference will be structured around two e-Science tracks:
. eScience Algorithms and Applications
. eScience application areas, including:
. Physical sciences
. Biomedical sciences
. Social sciences and humanities
. Data-oriented approaches and applications
. Compute-oriented approaches and applications
. Extreme scale approaches and applications
. Cyberinfrastructure to support eScience
. Novel hardware
. Novel uses of production infrastructure
. Software and services
. Tools
The conference proceedings will be published by the IEEE Computer
Society Press, USA and will be made available online through the IEEE
Digital Library. Selected papers will be invited to submit extended
versions to a special issue of the Future Generation Computer Systems
(FGCS)journal.
SUBMISSION PROCESS
Authors are invited to submit papers with unpublished, original work of
not more than 8 pages of double column text using single spaced 10 point
size on 8.5 x 11 inch pages, as per IEEE 8.5 x 11 manuscript guidelines.
(Up to 2 additional pages may be purchased for US$150/page)
Templates are available from
http://www.ieee.org/conferences_events/conferences/publishing/templates.html.
Authors should submit a PDF file that will print on a PostScript printer
to https://www.easychair.org/conferences/?conf=escience2012
<tohttps://www.easychair.org/conferences/?conf=escience2012>
(Note that paper submitters also must submit an abstract in advance of
the paper deadline. This should be done through the same site where
papers are submitted.)
It is a requirement that at least one author of each accepted paper
attend the conference.
IMPORTANT DATES
Abstract submission (required): 4 July 2012
Paper submission: 11 July 2012
Paper author notification: 22 August 2012
Camera-ready papers due: 10 September 2012
Conference: 8-12 October 2012
CONFERENCE ORGANIZATION
General Chair
. Ian Foster, University of Chicago & Argonne National Laboratory, USA
Program Co-Chairs
. Daniel S. Katz, University of Chicago & Argonne National Laboratory, USA
. Heinz Stockinger, SIB Swiss Institute of Bioinformatics, Switzerland
Program Vice Co-Chairs
. eScience Algorithms and Applications Track
. David Abramson, Monash University, Australia
. Gabrielle Allen, Louisiana State University, USA
. Cyberinfrastructure to support eScience Track
. Rosa M. Badia, Barcelona Supercomputing Center / CSIC, Spain
. Geoffrey Fox, Indiana University, USA
Early Results and Works-in-Progress Posters Chair
. Roger Barga, Microsoft, USA
Workshops Chair
. Ruth Pordes, FNAL, USA
Sponsorship Chair
. Charlie Catlett, Argonne National Laboratory, USA
Conference Manager and Finance Chair
. Julie Wulf-Knoerzer, University of Chicago & Argonne National
Laboratory, USA
Publicity Chairs
. Kento Aida, National Institute of Informatics, Japan
. Ioan Raicu, Illinois Institute of Technology, USA
. David Wallom, Oxford e-Research Centre, UK
Local Organizing Committee
. Ninfa Mayorga, University of Chicago, USA
. Evelyn Rayburn, University of Chicago, USA
. Lynn Valentini, Argonne National Laboratory, USA
Program Committee
. eScience Algorithms and Applications Track
. Srinivas Aluru, Iowa State University, USA
. Ashiq Anjum, University of Derby, UK
. David A. Bader, Georgia Institute of Technology, USA
. Jon Blower, University of Reading, UK
. Paul Bonnington, Monash University, Australia
. Simon Cox, University of Southampton, UK
. David De Roure, Oxford e-Research Centre, UK
. George Djorgovski, California Institute of Technology, USA
. Anshu Dubey, University of Chicago & Argonne National Laboratory, USA
. Yuri Estrin, Monash University, Australia
. Dan Fay, Microsoft, USA
. Jeremy Frey, University of Southampton, UK
. Wolfgang Gentzsch, HPC Consultant, Germany
. Lutz Gross, The University of Queensland, Austrialia
. Sverker Holmgren, Uppsala University, Sweden
. Bill Howe, University of Washington, USA
. Marina Jirotka, University of Oxford, UK
. Timoleon Kipouros, University of Cambridge, UK
. Kerstin Kleese van Dam, Pacific Northwest National Laboratory, USA
. Arun S. Konagurthu, Monash University, Australia
. Peter Kunszt, SystemsX.ch <http://SystemsX.ch/>, Switzerland
. Alexey Lastovetsky, University College Dublin, Ireland
. Andrew Lewis, Griffith University, Australia
. Sergio Maffioletti, University of Zurich, Switzerland
. Amitava Majumdar, San Diego Supercomputer Center, University of
California at San Diego, USA
. Rui Mao, Shenzhen University, China
. Madhav V. Marathe, Virginia Tech, USA
. Maryann Martone, University of California at San Diego, USA
. Louis Moresi, Monash University, Australia
. Riccardo Murri, University of Zurich, Switzerland
. Silvia D. Olabarriaga, Academic Medical Center of the University of
Amsterdam, Netherlands
. Enrique S. Quintana-Ortí, Universidad Jaume I, Spain
. Abani Patra, University at Buffalo, USA
. Rob Pennington, NSF, USA
. Andrew Perry, Monash University, Australia
. Beth Plale, Indiana University, USA
. Michael Resch, University of Stuttgart, Germany
. Adrian Sandu, Virginia Tech, USA
. Mark Savill, Cranfield University, UK
. Erik Schnetter, Perimeter Institute for Theoretical Physics, Canada
. Edward Seidel, Louisiana State University, USA
. Suzanne M. Shontz, The Pennsylvania State University, USA
. David Skinner, Lawrence Berkeley National Laboratory, USA
. Alan Sussman, University of Maryland, USA
. Alex Szalay, Johns Hopkins University, USA
. Domenico Talia, ICAR-CNR & University of Calabria, Italy
. Jian Tao, Louisiana State University, USA
. David Wallom, Oxford e-Research Centre, UK
. Shaowen Wang, University of Illinois at Urbana-Champaign, USA
. Michael Wilde, Argonne National Laboratory & University of Chicago, USA
. Nancy Wilkins-Diehr, San Diego Supercomputer Center, University of
California at San Diego, USA
. Wu Zhang, Shanghai University, China
. Yunquan Zhang, Chinese Academy of Sciences, China
. Cyberinfrastructure to support eScience Track
. Deb Agarwal, Lawrence Berkeley National Laboratory, USA
. Ilkay Altintas, San Diego Supercomputer Center, University of
California at San Diego, USA
. Henri Bal, Vrije Universiteit, Netherlands
. Roger Barga, Microsoft, USA
. Martin Berzins, University of Utah, USA
. John Brooke, University of Manchester, UK
. Thomas Fahringer, University of Innsbruck, Austria
. Gilles Fedak, INRIA, France
. José A. B. Fortes, University of Florida, USA
. Yolanda Gil, ISI/USC, USA
. Madhusudhan Govindaraju, SUNY Binghamton, USA
. Thomas Hacker, Purdue University, USA
. Ken Hawick, Massey University, New Zealand
. Marty Humphrey, University of Virginia, USA
. Hai Jin, Huazhong University of Science and Technology, China
. Thilo Kielmann, Vrije Universiteit, Netherlands
. Scott Klasky, Oak Ridge National Laboratory, USA
. Isao Kojima, AIST, Japan
. Tevfik Kosar, University at Buffalo, USA
. Dieter Kranzlmueller, LMU & LRZ Munich, Germany
. Erwin Laure, KTH, Sweden
. Jysoo Lee, KISTI, Korea
. Li Xiaoming, Peking University, China
. Bertram Ludäscher, University of California, Davis, USA
. Andrew Lumsdaine, Indiana University, USA
. Tanu Malik, University of Chicago, USA
. Satoshi Matsuoka, Tokyo Institute of Technology, Japan
. Reagan Moore, University of North Carolina at Chapel Hill, USA
. Shirley Moore, University of Kentucky, USA
. Steven Newhouse, EGI, Netherlands
. Dhabaleswar K. (DK) Panda, The Ohio State University, USA
. Manish Parashar, Rutgers University, USA
. Ron Perrott, University of Oxford, UK
. Depei Qian, Beihang University, China
. Judy Qui, Indiana University, USA
. Ioan Raicu, Illinois Institute of Technology, USA
. Lavanya Ramakrishnan, Lawrence Berkeley National Laboratory, USA
. Omer Rana, Cardiff University, UK
. Paul Roe, Queensland University of Technology, Australia
. Bruno Schulze, LNCC, Brazil
. Marc Snir, Argonne National Laboratory & University of Illinois at
Urbana-Champaign, USA
. Xian-He Sun, Illinois Institute of Technology, USA
. Yoshio Tanaka, AIST, Japan
. Michela Taufer, University of Delaware, USA
. Kerry Taylor, CSIRO, Australia
. Douglas Thain, University of Notre Dame, USA
. Paul Watson, Newcastle University, UK
. Jian Zhang, Northern Illinois University, USA
. Jun Zhao, University of Oxford, UK
--
=================================================================
Ioan Raicu, Ph.D.
Assistant Professor, Illinois Institute of Technology (IIT)
Guest Research Faculty, Argonne National Laboratory (ANL)
=================================================================
Data-Intensive Distributed Systems Laboratory, CS/IIT
Distributed Systems Laboratory, MCS/ANL
=================================================================
Cel: 1-847-722-0876
Office: 1-312-567-5704
Email: iraicu@cs.iit.edu
Web: http://www.cs.iit.edu/~iraicu/
Web: http://datasys.cs.iit.edu/
=================================================================
=================================================================
[-- Attachment #1.2: Type: text/html, Size: 27860 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* [PULL] virtio: balloon: leak / fill balloon across S4
From: Rusty Russell @ 2012-02-29 23:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Amit Shah, Michael S. Tsirkin, Virtualization List
In-Reply-To: <2d3cb82e72219287db72e20901237a1058246915.1330517514.git.amit.shah@redhat.com>
+ 65e65f9...847ce6c for-linus -> for-linus (forced update)
The following changes since commit 5ffca28a4ac7abb8a254fafe6bd03b2f83667df7:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/aia21/ntfs (2012-02-27 07:59:33 -0800)
are available in the git repository at:
git://github.com/rustyrussell/linux.git master
Amit Shah (1):
virtio: balloon: leak / fill balloon across S4
drivers/virtio/virtio_balloon.c | 33 ++++++++++++++++++++++-----------
1 files changed, 22 insertions(+), 11 deletions(-)
^ permalink raw reply
* [PATCH 1/1] virtio: balloon: leak / fill balloon across S4
From: Amit Shah @ 2012-02-29 12:12 UTC (permalink / raw)
To: Rusty Russell; +Cc: Amit Shah, Michael S. Tsirkin, Virtualization List
commit e562966dbaf49e7804097cd991e5d3a8934fc148 added support for S4 to
the balloon driver. The freeze function did nothing to free the pages,
since reclaiming the pages from the host to immediately give them back
(if S4 was successful) seemed wasteful. Also, if S4 wasn't successful,
the guest would have to re-fill the balloon. On restore, the pages were
supposed to be marked freed and the free page counters were incremented
to reflect the balloon was totally deflated.
However, this wasn't done right. The pages that were earlier taken away
from the guest during a balloon inflation operation were just shown as
used pages after a successful restore from S4. Just a fancy way of
leaking lots of memory.
Instead of trying that, just leak the balloon on freeze and fill it on
restore/thaw paths. This works properly now. The optimisation to not
leak can be added later on after a bit of refactoring of the code.
Signed-off-by: Amit Shah <amit.shah@redhat.com>
---
Rusty, please pick this up for 3.3. Thanks.
drivers/virtio/virtio_balloon.c | 33 ++++++++++++++++++++++-----------
1 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 95aeedf..958e512 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -367,29 +367,45 @@ static void __devexit virtballoon_remove(struct virtio_device *vdev)
#ifdef CONFIG_PM
static int virtballoon_freeze(struct virtio_device *vdev)
{
+ struct virtio_balloon *vb = vdev->priv;
+
/*
* The kthread is already frozen by the PM core before this
* function is called.
*/
+ while (vb->num_pages)
+ leak_balloon(vb, vb->num_pages);
+ update_balloon_size(vb);
+
/* Ensure we don't get any more requests from the host */
vdev->config->reset(vdev);
vdev->config->del_vqs(vdev);
return 0;
}
+static int restore_common(struct virtio_device *vdev)
+{
+ struct virtio_balloon *vb = vdev->priv;
+ int ret;
+
+ ret = init_vqs(vdev->priv);
+ if (ret)
+ return ret;
+
+ fill_balloon(vb, towards_target(vb));
+ update_balloon_size(vb);
+ return 0;
+}
+
static int virtballoon_thaw(struct virtio_device *vdev)
{
- return init_vqs(vdev->priv);
+ return restore_common(vdev);
}
static int virtballoon_restore(struct virtio_device *vdev)
{
struct virtio_balloon *vb = vdev->priv;
- struct page *page, *page2;
-
- /* We're starting from a clean slate */
- vb->num_pages = 0;
/*
* If a request wasn't complete at the time of freezing, this
@@ -397,12 +413,7 @@ static int virtballoon_restore(struct virtio_device *vdev)
*/
vb->need_stats_update = 0;
- /* We don't have these pages in the balloon anymore! */
- list_for_each_entry_safe(page, page2, &vb->pages, lru) {
- list_del(&page->lru);
- totalram_pages++;
- }
- return init_vqs(vdev->priv);
+ return restore_common(vdev);
}
#endif
--
1.7.7.6
^ permalink raw reply related
* CFP: IEEE Int. Scalable Computing Challenge (SCALE) at CCGrid 2012
From: Ioan Raicu @ 2012-02-26 14:27 UTC (permalink / raw)
To: virtualization
CALL FOR PAPERS
The Fifth IEEE International Scalable Computing Challenge (SCALE)
Co-located with the 11th CCGrid Conference in Ottawa, Canada
Sponsored by the IEEE Computer Society Technical Committee on
Scalable Computing (TCSC)
May 13-16, 2012
http://www.cloudbus.org/ccgrid2012/cfp-scale.html
---------------------------------------------------------------------
Objective and Focus: The objective of the Fifth IEEE International
Scalable Computing Challenge (SCALE 2012), sponsored by the IEEE
Computer Society Technical Committee on Scalable Computing (TCSC), is
to highlight and showcase real-world problem solving using computing
that scales.
Effective solutions to many scientific problems require applications
that can scale. There are different dimensions to application scaling:
for example, applications can scale-up to large number of cores or
compute units, scale-out to utilize multiple distinct compute units,
or scale-down to release resources that are no longer needed. In order
to scale, applications need the support of tools, middleware,
infrastructure, programming systems, etc. SCALE is concerned with
advances in application development and supporting infrastructure that
enable scaling.
Call for Proposals: The Fifth IEEE International Scalable Computing
Challenge (SCALE 2012) contest will focus on end-to-end problem
solving using concepts, technologies and architectures (including
Clusters, Grids and Clouds) that facilitate scaling. Participants in
the challenge will be expected to identify significant current
real-world problems where scalable computing techniques can be
effectively used, and design, implement, evaluate and demonstrate
solutions. SCALE2012 will be held in conjunction with the 11th CCGrid
Conference in Ottawa, Canada on 13-16 May, 2012.
We invite teams to submit white papers outlining the problem addressed
and the technologies employed to enable applications to scale. White
papers should be up to 4 pages long, 12-pt. font and single column,
and in addition to listing team members and contact information,
should clearly outline:
1. The problem being solved and the technology employed
2. The application scenario and its requirements
3. Performance data and a qualitative description of how the
application scales -- scale-up, scale-out or any other type of scaling
4. The solution -- architecture, underlying concepts and technologies
used -- highlighting the innovative aspects of the solution
5. Impact of the solution, including extensibility and uniqueness of
results, and the extent to which the presented solution pushes the
envelope in scalable computing
6. Analysis of solution and technology employed compared to related
approaches
In addition to the above, finalists will be judged on the quality of
their presentation, which shall include a 5-minute demonstration, as
well as their responses to questions by a technical committee.
Papers will be shortlisted using the above 6 points as merit criteria,
and up to 6 papers will be invited to compete in a final round at
CCGrid 2012. Selected teams will receive an award of up to $1000 to
help with travel to the conference. At least one member from each
selected team will be expected to present and demonstrate their
project at CCGrid 2012. Participation from students and young
researchers, especially in leadership roles, is strongly encouraged.
Awards:
First prize: Plaque + $1000
Second prize: Plaque + $500
Tentative timeline:
The deadline for submitting proposals is 15 March, 2012.
Decisions: 01 April 2012.
Final presentation/demo: 13-16 May, 2012.
Coordinator:
Shantenu Jha, Rutgers University, USA, shantenu dot jha at rutgers dot edu
--
=================================================================
Ioan Raicu, Ph.D.
Assistant Professor, Illinois Institute of Technology (IIT)
Guest Research Faculty, Argonne National Laboratory (ANL)
=================================================================
Data-Intensive Distributed Systems Laboratory, CS/IIT
Distributed Systems Laboratory, MCS/ANL
=================================================================
Cel: 1-847-722-0876
Office: 1-312-567-5704
Email: iraicu@cs.iit.edu
Web: http://www.cs.iit.edu/~iraicu/
Web: http://datasys.cs.iit.edu/
=================================================================
=================================================================
^ permalink raw reply
* CFP: The 9th Int. Conf. on Autonomic Computing (ICAC) 2012
From: Ioan Raicu @ 2012-02-26 13:57 UTC (permalink / raw)
To: virtualization
CALL FOR PAPERS
The 9th International Conference on Autonomic Computing (ICAC 2012)
September 16-20, 2012. San Jose, CA, USA
http://icac2012.cs.fiu.edu/
-----------------------------------------------------------------
IMPORTANT DATES
Paper and Poster Submission: March 9, 2012, 11:59pm PST
Notification: May 18, 2012
Camera-ready Due: June 8, 2012
-----------------------------------------------------------------
OVERVIEW
ICAC is the leading conference on autonomic computing techniques,
foundations, and applications. Autonomic computing refers to
methods and means for automated management of performance, fault,
security, and configuration with little involvement of users or
administrators. Systems introducing new autonomic features are
becoming increasingly prevalent, motivating research that spans
a variety of areas, from computer systems, networking, software
engineering, and data management to machine learning, control
theory, and bio-inspired computing. ICAC brings together
researchers and practitioners across these disciplines to
address multiple facets of adaptation and self-management in
computing systems and applications from different perspectives.
Autonomic computing solutions are sought for clouds, grids,
data centers, enterprise software, internet services, data
services, smart phones, embedded systems, and sensor networks.
In these environments, resources and applications must be managed
to maximize performance and minimize cost, while maintaining
predictable and reliable behavior in the face of varying
workloads, failures, and malicious threats. Papers are solicited
from all areas of autonomic computing, including (but not limited
to):
* End-to-end techniques for management of resources, workloads,
performance, faults, power/cooling, security, and others.
* Self-managing components, such as server, storage, network
protocols, or specific application elements, and embedded and
mobile end systems such as smart phones.
* Decision and analysis techniques and their use, such as machine
learning, control theory, predictive methods, probability and
stochastic processes, queuing theory methodologies, emergent
behavior, rule-based systems, and bio-inspired techniques.
* Monitoring systems for autonomic computing.
* Hypervisor, operating systems, hardware, or application support
for autonomic computing.
* Novel human interfaces for monitoring and controlling autonomic
systems.
* Management topics, such as specification and modeling of
service-level agreements, behavior enforcement and tie-in with
IT governance.
* Toolkits, frameworks, principles and architectures, from
software engineering practices and experimental methodologies
to agent-based techniques and virtualization.
* Fundamental science and theory of self-managing systems:
understanding, controlling or exploiting system behaviors to
enforce autonomic properties.
* Applications of autonomic computing and experiences with
prototyped or deployed systems solving real-world problems in
science, engineering, business and society.
Papers will be judged on originality, significance, interest,
correctness, clarity and relevance to the broader community.
Papers should report on experiences, measurements, user studies,
or other evaluations, as appropriate. Evaluations of a prototype
or large-scale deployment of systems and applications is expected.
PAPER AND POSTER SUBMISSIONS
Full papers (a maximum of 10 pages in the two-column ACM proceedings
format) and posters (2 pages) are invited on a wide variety of
topics relating to autonomic computing. Submitted papers must be
original work, and may not be under consideration for another
conference or journal. Complete formatting and submission
instructions can be found on the conference web site. Accepted
papers and posters will appear in proceedings distributed at the
conference and available electronically. Relevant top ICAC'12
papers will be invited for "fast-track" submissions to the
ACM Transactions on Autonomous and Adaptive Systems (TAAS).
WORKSHOPS, DEMONSTRATIONS AND EXHIBITION
ICAC'12 welcomes proposals for co-located workshops on topics of
interest to the autonomic computing community. Workshop proposals
should be submitted to the Workshop Chair, Fred Douglis
(f.douglis@computer.org) by February 10, 2012. Workshops are
expected to publish proceedings, and should cover areas that
complement the main program. ICAC'12 will also feature a
demonstration and exhibition session consisting of prototypes and
technology artifacts such as demonstrating autonomic software or
autonomic computing principles. Entries will be judged by a
separate committee led by the demo/exhibit chair.
INDUSTRY SESSION
One of ICAC's important roles is to bring together researchers
and practitioners from academia and industry. In its industry
session, ICAC helps fulfill this role by presenting an industry
viewpoint on technologies, products, and market needs. The
industry session also addresses current challenges, and
opportunities for academic and corporate research collaborations.
We encourage industry leaders, including entrepreneurs, product
developers, architects, managers, marketers and end users,
to submit their papers and posters reflecting such industry
perspectives as part of the regular submission process.
------------------------------------------------------------------
ORGANIZERS
GENERAL CHAIR
Dejan Milojicic, HP Labs
PROGRAM CHAIRS
Dongyan Xu, Purdue University
Vanish Talwar, HP Labs
INDUSTRY CHAIR
Xiaoyun Zhu, VMware
WORKSHOPS CHAIR
Fred Douglis, EMC
POSTERS/DEMO/EXHIBITS CHAIR
Eno Thereska, Microsoft Research
FINANCE CHAIR
Michael Kozuch, Intel
LOCAL ARRANGEMENT CHAIR
Jessica Blaine
PUBLICITY CHAIRS
Daniel Batista, University of São Paulo
Vartan Padaryan, ISP/Russian Academy of Sci.
Ioan Raicu, Illinois Inst. of Technology
Jianfeng Zhan, ICT/Chinese Academy of Sci.
Ming Zhao, Florida Intl. University
PROGRAM COMMITTEE
Tarek Abdelzaher, UIUC
Umesh Bellur, IIT, Bombay
Ken Birman, Cornell University
Rajkumar Buyya, Univ. of Melbourne
Rocky Chang, Hong Kong Polytechnic University
Yuan Chen, HP Labs
Alva Couch, Tufts University
Peter Dinda, Northwestern University
Fred Douglis, EMC
Renato Figueiredo, University of Florida
Mohamed Hefeeda, Qatar Computing Research Institute
Joe Hellerstein, Google
Geoff Jiang, NEC Labs
Jeff Kephart, IBM Research
Emre Kiciman, Microsoft Research
Fabio Kon, University of São Paulo
Michael Kozuch, Intel
Dejan Milojicic, HP Labs
Klara Nahrstedt, UIUC
Priya Narasimhan, CMU
Manish Parashar, Rutgers University
Ioan Raicu, Illinois Inst. of Technology
Omer Rana, Cardiff University
Masoud Sadjadi, Florida Intl. University
Rick Schlichting, AT&T Labs
Hartmut Schmeck, KIT
Karsten Schwan, Georgia Tech
Onn Shehory, IBM Research
Eno Thereska, Microsoft Research
Xiaoyun Zhu, VMware
--
=================================================================
Ioan Raicu, Ph.D.
Assistant Professor, Illinois Institute of Technology (IIT)
Guest Research Faculty, Argonne National Laboratory (ANL)
=================================================================
Data-Intensive Distributed Systems Laboratory, CS/IIT
Distributed Systems Laboratory, MCS/ANL
=================================================================
Cel: 1-847-722-0876
Office: 1-312-567-5704
Email: iraicu@cs.iit.edu
Web: http://www.cs.iit.edu/~iraicu/
Web: http://datasys.cs.iit.edu/
=================================================================
=================================================================
^ permalink raw reply
* Re: [PATCH] blkfront: don't put bdev right after getting it
From: Konrad Rzeszutek Wilk @ 2012-02-21 14:58 UTC (permalink / raw)
To: Andrew Jones; +Cc: jeremy, xen-devel, virtualization
In-Reply-To: <1329394585-10129-1-git-send-email-drjones@redhat.com>
On Thu, Feb 16, 2012 at 01:16:25PM +0100, Andrew Jones wrote:
> We should hang onto bdev until we're done with it.
applied in #testing
>
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
> drivers/block/xen-blkfront.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 2f22874..5d45688 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -1410,7 +1410,6 @@ static int blkif_release(struct gendisk *disk, fmode_t mode)
> mutex_lock(&blkfront_mutex);
>
> bdev = bdget_disk(disk, 0);
> - bdput(bdev);
>
> if (bdev->bd_openers)
> goto out;
> @@ -1441,6 +1440,7 @@ static int blkif_release(struct gendisk *disk, fmode_t mode)
> }
>
> out:
> + bdput(bdev);
> mutex_unlock(&blkfront_mutex);
> return 0;
> }
> --
> 1.7.7.5
^ permalink raw reply
* Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're busy
From: Konrad Rzeszutek Wilk @ 2012-02-21 14:36 UTC (permalink / raw)
To: Jan Beulich, joe.jin; +Cc: Andrew Jones, xen-devel, jeremy, virtualization
In-Reply-To: <4F43743102000078000740C2@nat28.tlf.novell.com>
On Tue, Feb 21, 2012 at 09:38:41AM +0000, Jan Beulich wrote:
> >>> On 21.02.12 at 10:23, Andrew Jones <drjones@redhat.com> wrote:
> >> >>> On 20.02.12 at 11:35, Andrew Jones <drjones@redhat.com> wrote:
> >> >> On Fri, Feb 17, 2012 at 05:52:54PM +0100, Andrew Jones wrote:
> >> >> There was another fix that sounds similar to this in the backend.
> >> >> 6f5986bce558e64fe867bff600a2127a3cb0c006
> >> >>
> >> >
> >> > Thanks for the pointer. It doesn't look like the upstream 2.6.18
> >> > tree has that, but it probably would be a good idea there too.
> >>
> >> While I had seen the change and considered pulling it in, I wasn't
> >> really convinced this is the right behavior here: After all, if the
> >> host
> >> admin requested a resource to be removed from a guest, it shouldn't
> >> depend on the guest whether and when to honor that request, yet
> >> by deferring the disconnect you basically allow the guest to continue
> >> using the disk indefinitely.
> >>
> >
> > I agree. Yesterday I wrote[1] asking if "deferred detach" is really
> > something we want. At the moment, Igor and I are poking through
> > xen-blkfront.c, and currently we'd rather see the feature dropped
> > in favor of a simplified driver. One that has less release paths,
> > and/or release paths with more consistent locking behavior.
>
> I must have missed this, or it's one more instance of delayed mail
> delivery via xen-devel.
>
> Konrad - care to revert that original change as having barked up
> the wrong tree?
Meaning the 6f5986bce558e64fe867bff600a2127a3cb0c006?
Lets CC Joe Jin here to get his input. I recall that the --force argument
still works with that patch so the admin can still choose to terminate the
state. Which I thought was the point of the --force - as in if the
guest is still using it, we won't be yanking it out until we are
completly sure.
>
> Jan
>
> > [1] http://lists.xen.org/archives/html/xen-devel/2012-02/msg01672.html
>
^ permalink raw reply
* Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're busy
From: Jan Beulich @ 2012-02-21 9:38 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, Andrew Jones; +Cc: jeremy, xen-devel, virtualization
In-Reply-To: <0321d9ab-a725-47af-b6f6-8342aa1d7c5f@zmail17.collab.prod.int.phx2.redhat.com>
>>> On 21.02.12 at 10:23, Andrew Jones <drjones@redhat.com> wrote:
>> >>> On 20.02.12 at 11:35, Andrew Jones <drjones@redhat.com> wrote:
>> >> On Fri, Feb 17, 2012 at 05:52:54PM +0100, Andrew Jones wrote:
>> >> There was another fix that sounds similar to this in the backend.
>> >> 6f5986bce558e64fe867bff600a2127a3cb0c006
>> >>
>> >
>> > Thanks for the pointer. It doesn't look like the upstream 2.6.18
>> > tree has that, but it probably would be a good idea there too.
>>
>> While I had seen the change and considered pulling it in, I wasn't
>> really convinced this is the right behavior here: After all, if the
>> host
>> admin requested a resource to be removed from a guest, it shouldn't
>> depend on the guest whether and when to honor that request, yet
>> by deferring the disconnect you basically allow the guest to continue
>> using the disk indefinitely.
>>
>
> I agree. Yesterday I wrote[1] asking if "deferred detach" is really
> something we want. At the moment, Igor and I are poking through
> xen-blkfront.c, and currently we'd rather see the feature dropped
> in favor of a simplified driver. One that has less release paths,
> and/or release paths with more consistent locking behavior.
I must have missed this, or it's one more instance of delayed mail
delivery via xen-devel.
Konrad - care to revert that original change as having barked up
the wrong tree?
Jan
> [1] http://lists.xen.org/archives/html/xen-devel/2012-02/msg01672.html
^ permalink raw reply
* Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're busy
From: Andrew Jones @ 2012-02-21 9:23 UTC (permalink / raw)
To: Jan Beulich; +Cc: jeremy, xen-devel, Konrad Rzeszutek Wilk, virtualization
In-Reply-To: <4F436E75020000780007409F@nat28.tlf.novell.com>
----- Original Message -----
> >>> On 20.02.12 at 11:35, Andrew Jones <drjones@redhat.com> wrote:
>
> >
> > ----- Original Message -----
> >> On Fri, Feb 17, 2012 at 05:52:54PM +0100, Andrew Jones wrote:
> >> > On Thu, Feb 16, 2012 at 12:33:32PM -0500, Andrew Jones wrote:
> >> > > Hmm, I should maybe self-nack this. The bug that led me to
> >> > > writing
> >> > > it is likely only with older tooling, such as RHEL5's. The
> >> > > problem
> >> > > was if you attempted to detach a mounted disk twice, then the
> >> > > second
> >> > > time it would succeed. The guest had flipped to Closing on the
> >> > > first
> >> > > try, and thus didn't issue an error to xenbus on the second. I
> >> > > see
> >> >
> >> > Actually, it's even worse than I thought. Just a single attempt
> >> > to
> >> > detach the device will cause the guest grief (with RHEL5's tools
> >> > anyway). Once xenbus shows the device is in the Closing state,
> >> > then
> >> > tasks accessing the device may hang.
> >> >
> >> > > The reason I only say maybe self-nack though, is because this
> >> > > state
> >> > > change seemed to be thrown in with another fix[1]. I'm not
> >> > > sure
> >> > > if
> >> > > the new behavior on legacy hosts was considered or not. If
> >> > > not,
> >> > > then
> >> > > we can consider it now. Do we want to have deferred asynch
> >> > > detaches
> >> > > over protecting the guest from multiple detach calls on legacy
> >> > > hosts?
> >> > >
> >> >
> >> > I guess we can keep the feature and protect the guest with a
> >> > patch
> >> > like
> >> > I'll send in a moment. It doesn't really work for me with a
> >> > RHEL5
> >> > host
> >> > though. The deferred close works from the pov of the guest, but
> >> > the
> >> > state of the block device gets left in Closed after the guest
> >> > unmounts
> >> > it, and then RHEL5's tools can't detach/reattach it. If the
> >> > deferred
> >> > close ever worked on other Xen hosts though, then I don't
> >> > believe
> >> > this
> >> > patch would break it, and it will also keep the guest safe when
> >> > run
> >> > on
> >> > hosts that don't treat state=Closing the way it currently
> >> > expects.
> >>
> >> There was another fix that sounds similar to this in the backend.
> >> 6f5986bce558e64fe867bff600a2127a3cb0c006
> >>
> >
> > Thanks for the pointer. It doesn't look like the upstream 2.6.18
> > tree has that, but it probably would be a good idea there too.
>
> While I had seen the change and considered pulling it in, I wasn't
> really convinced this is the right behavior here: After all, if the
> host
> admin requested a resource to be removed from a guest, it shouldn't
> depend on the guest whether and when to honor that request, yet
> by deferring the disconnect you basically allow the guest to continue
> using the disk indefinitely.
>
I agree. Yesterday I wrote[1] asking if "deferred detach" is really
something we want. At the moment, Igor and I are poking through
xen-blkfront.c, and currently we'd rather see the feature dropped
in favor of a simplified driver. One that has less release paths,
and/or release paths with more consistent locking behavior.
Drew
[1] http://lists.xen.org/archives/html/xen-devel/2012-02/msg01672.html
> Jan
>
> > However, even with that ability to patch backends, we probably
> > want the frontends to be more robust on legacy backends for a while
> > longer. So, it probably would be best to avoid changing the state
> > to
> > Closing while we're still busy, unless it's absolutely necessary.
> >
> > Drew
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xensource.com/xen-devel
>
^ permalink raw reply
* Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're busy
From: Jan Beulich @ 2012-02-21 9:14 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, Andrew Jones; +Cc: jeremy, xen-devel, virtualization
In-Reply-To: <2f885124-dcd7-42c0-ade3-e164457513fe@zmail17.collab.prod.int.phx2.redhat.com>
>>> On 20.02.12 at 11:35, Andrew Jones <drjones@redhat.com> wrote:
>
> ----- Original Message -----
>> On Fri, Feb 17, 2012 at 05:52:54PM +0100, Andrew Jones wrote:
>> > On Thu, Feb 16, 2012 at 12:33:32PM -0500, Andrew Jones wrote:
>> > > Hmm, I should maybe self-nack this. The bug that led me to
>> > > writing
>> > > it is likely only with older tooling, such as RHEL5's. The
>> > > problem
>> > > was if you attempted to detach a mounted disk twice, then the
>> > > second
>> > > time it would succeed. The guest had flipped to Closing on the
>> > > first
>> > > try, and thus didn't issue an error to xenbus on the second. I
>> > > see
>> >
>> > Actually, it's even worse than I thought. Just a single attempt to
>> > detach the device will cause the guest grief (with RHEL5's tools
>> > anyway). Once xenbus shows the device is in the Closing state, then
>> > tasks accessing the device may hang.
>> >
>> > > The reason I only say maybe self-nack though, is because this
>> > > state
>> > > change seemed to be thrown in with another fix[1]. I'm not sure
>> > > if
>> > > the new behavior on legacy hosts was considered or not. If not,
>> > > then
>> > > we can consider it now. Do we want to have deferred asynch
>> > > detaches
>> > > over protecting the guest from multiple detach calls on legacy
>> > > hosts?
>> > >
>> >
>> > I guess we can keep the feature and protect the guest with a patch
>> > like
>> > I'll send in a moment. It doesn't really work for me with a RHEL5
>> > host
>> > though. The deferred close works from the pov of the guest, but the
>> > state of the block device gets left in Closed after the guest
>> > unmounts
>> > it, and then RHEL5's tools can't detach/reattach it. If the
>> > deferred
>> > close ever worked on other Xen hosts though, then I don't believe
>> > this
>> > patch would break it, and it will also keep the guest safe when run
>> > on
>> > hosts that don't treat state=Closing the way it currently expects.
>>
>> There was another fix that sounds similar to this in the backend.
>> 6f5986bce558e64fe867bff600a2127a3cb0c006
>>
>
> Thanks for the pointer. It doesn't look like the upstream 2.6.18
> tree has that, but it probably would be a good idea there too.
While I had seen the change and considered pulling it in, I wasn't
really convinced this is the right behavior here: After all, if the host
admin requested a resource to be removed from a guest, it shouldn't
depend on the guest whether and when to honor that request, yet
by deferring the disconnect you basically allow the guest to continue
using the disk indefinitely.
Jan
> However, even with that ability to patch backends, we probably
> want the frontends to be more robust on legacy backends for a while
> longer. So, it probably would be best to avoid changing the state to
> Closing while we're still busy, unless it's absolutely necessary.
>
> Drew
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: [Xen-devel] [PATCH v2] blkfront: don't change to closing if we're busy
From: Andrew Jones @ 2012-02-20 18:26 UTC (permalink / raw)
To: xen-devel; +Cc: jeremy, konrad wilk, virtualization
In-Reply-To: <1329497959-19427-1-git-send-email-drjones@redhat.com>
----- Original Message -----
> We just reported to xenbus that we can't close yet, because we're
> still
> in use. So we shouldn't then immediately tell xenbus that we are
> closing. If we do, then we risk bypassing the chance to complain
> again,
> if we're told to close again, and we're still in use. The reason this
> code was here was to implement a deferred close. We can still support
> this feature by adding a member to our private data, and setting that
> instead. Besides being able to complain each time, this patch fixes
> a problem when running on hosts with legacy tools that may interpret
> the lack of a complaint or state=Closing incorrectly, and then yank
> the device out from under the guest.
>
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
> drivers/block/xen-blkfront.c | 7 +++++--
> 1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/block/xen-blkfront.c
> b/drivers/block/xen-blkfront.c
> index 2f22874..d7f2e03 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -103,6 +103,7 @@ struct blkfront_info
> unsigned int discard_granularity;
> unsigned int discard_alignment;
> int is_ready;
> + int closing;
> };
>
> static DEFINE_SPINLOCK(blkif_io_lock);
> @@ -1134,7 +1135,7 @@ blkfront_closing(struct blkfront_info *info)
> if (bdev->bd_openers) {
> xenbus_dev_error(xbdev, -EBUSY,
> "Device in use; refusing to close");
> - xenbus_switch_state(xbdev, XenbusStateClosing);
> + info->closing = 1;
> } else {
> xlvbd_release_gendisk(info);
> xenbus_frontend_closed(xbdev);
> @@ -1423,8 +1424,10 @@ static int blkif_release(struct gendisk *disk,
> fmode_t mode)
> mutex_lock(&info->mutex);
> xbdev = info->xbdev;
>
> - if (xbdev && xbdev->state == XenbusStateClosing) {
> + if (xbdev && (xbdev->state == XenbusStateClosing || info->closing))
Ugh. This isn't right either. After discussing with Igor Mammedov, I
see that I missed that xbdev->state will now never be XenbusStateClosing.
We need the xenbus_read_driver_state() to come back for getting the
state (that was also changed with 7fd152f4b6ae).
However, I'm starting to wonder if supporting "deferred detach" is
worth the complexity. If we took a pass through xen-blkfront.c and
removed all code related to it, and perhaps also all code related to a
"forced detach", then I suspect the driver could be nicely simplified.
Do we need deferred and forced detach support? Forced seems like a bad
idea. For what would a guest use a disk that could disappear with little
notice? Deferred also seems strange. It seems like the host and guest
admins should generally better coordinate and synchronize these types
of activities. It's possible there are good usecases that I'm missing.
I'd be happy to hear examples.
Thanks,
Drew
> {
> /* pending switch to state closed */
> + if (xbdev->state != XenbusStateClosing)
> + xenbus_switch_state(xbdev, XenbusStateClosing);
> dev_info(disk_to_dev(bdev->bd_disk), "releasing disk\n");
> xlvbd_release_gendisk(info);
> xenbus_frontend_closed(info->xbdev);
> --
> 1.7.7.5
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
^ permalink raw reply
* Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're busy
From: Andrew Jones @ 2012-02-20 10:35 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk; +Cc: jeremy, xen-devel, virtualization
In-Reply-To: <20120217185836.GA23942@phenom.dumpdata.com>
----- Original Message -----
> On Fri, Feb 17, 2012 at 05:52:54PM +0100, Andrew Jones wrote:
> > On Thu, Feb 16, 2012 at 12:33:32PM -0500, Andrew Jones wrote:
> > > Hmm, I should maybe self-nack this. The bug that led me to
> > > writing
> > > it is likely only with older tooling, such as RHEL5's. The
> > > problem
> > > was if you attempted to detach a mounted disk twice, then the
> > > second
> > > time it would succeed. The guest had flipped to Closing on the
> > > first
> > > try, and thus didn't issue an error to xenbus on the second. I
> > > see
> >
> > Actually, it's even worse than I thought. Just a single attempt to
> > detach the device will cause the guest grief (with RHEL5's tools
> > anyway). Once xenbus shows the device is in the Closing state, then
> > tasks accessing the device may hang.
> >
> > > The reason I only say maybe self-nack though, is because this
> > > state
> > > change seemed to be thrown in with another fix[1]. I'm not sure
> > > if
> > > the new behavior on legacy hosts was considered or not. If not,
> > > then
> > > we can consider it now. Do we want to have deferred asynch
> > > detaches
> > > over protecting the guest from multiple detach calls on legacy
> > > hosts?
> > >
> >
> > I guess we can keep the feature and protect the guest with a patch
> > like
> > I'll send in a moment. It doesn't really work for me with a RHEL5
> > host
> > though. The deferred close works from the pov of the guest, but the
> > state of the block device gets left in Closed after the guest
> > unmounts
> > it, and then RHEL5's tools can't detach/reattach it. If the
> > deferred
> > close ever worked on other Xen hosts though, then I don't believe
> > this
> > patch would break it, and it will also keep the guest safe when run
> > on
> > hosts that don't treat state=Closing the way it currently expects.
>
> There was another fix that sounds similar to this in the backend.
> 6f5986bce558e64fe867bff600a2127a3cb0c006
>
Thanks for the pointer. It doesn't look like the upstream 2.6.18
tree has that, but it probably would be a good idea there too.
However, even with that ability to patch backends, we probably
want the frontends to be more robust on legacy backends for a while
longer. So, it probably would be best to avoid changing the state to
Closing while we're still busy, unless it's absolutely necessary.
Drew
^ permalink raw reply
* Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're busy
From: Konrad Rzeszutek Wilk @ 2012-02-17 18:58 UTC (permalink / raw)
To: Andrew Jones; +Cc: jeremy, xen-devel, virtualization
In-Reply-To: <20120217165253.GA17397@turtle.usersys.redhat.com>
On Fri, Feb 17, 2012 at 05:52:54PM +0100, Andrew Jones wrote:
> On Thu, Feb 16, 2012 at 12:33:32PM -0500, Andrew Jones wrote:
> > Hmm, I should maybe self-nack this. The bug that led me to writing
> > it is likely only with older tooling, such as RHEL5's. The problem
> > was if you attempted to detach a mounted disk twice, then the second
> > time it would succeed. The guest had flipped to Closing on the first
> > try, and thus didn't issue an error to xenbus on the second. I see
>
> Actually, it's even worse than I thought. Just a single attempt to
> detach the device will cause the guest grief (with RHEL5's tools
> anyway). Once xenbus shows the device is in the Closing state, then
> tasks accessing the device may hang.
>
> > The reason I only say maybe self-nack though, is because this state
> > change seemed to be thrown in with another fix[1]. I'm not sure if
> > the new behavior on legacy hosts was considered or not. If not, then
> > we can consider it now. Do we want to have deferred asynch detaches
> > over protecting the guest from multiple detach calls on legacy hosts?
> >
>
> I guess we can keep the feature and protect the guest with a patch like
> I'll send in a moment. It doesn't really work for me with a RHEL5 host
> though. The deferred close works from the pov of the guest, but the
> state of the block device gets left in Closed after the guest unmounts
> it, and then RHEL5's tools can't detach/reattach it. If the deferred
> close ever worked on other Xen hosts though, then I don't believe this
> patch would break it, and it will also keep the guest safe when run on
> hosts that don't treat state=Closing the way it currently expects.
There was another fix that sounds similar to this in the backend.
6f5986bce558e64fe867bff600a2127a3cb0c006
^ permalink raw reply
* [PATCH v2] blkfront: don't change to closing if we're busy
From: Andrew Jones @ 2012-02-17 16:59 UTC (permalink / raw)
To: xen-devel; +Cc: jeremy, virtualization, konrad.wilk
In-Reply-To: <20120217165253.GA17397@turtle.usersys.redhat.com>
We just reported to xenbus that we can't close yet, because we're still
in use. So we shouldn't then immediately tell xenbus that we are
closing. If we do, then we risk bypassing the chance to complain again,
if we're told to close again, and we're still in use. The reason this
code was here was to implement a deferred close. We can still support
this feature by adding a member to our private data, and setting that
instead. Besides being able to complain each time, this patch fixes
a problem when running on hosts with legacy tools that may interpret
the lack of a complaint or state=Closing incorrectly, and then yank
the device out from under the guest.
Signed-off-by: Andrew Jones <drjones@redhat.com>
---
drivers/block/xen-blkfront.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 2f22874..d7f2e03 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -103,6 +103,7 @@ struct blkfront_info
unsigned int discard_granularity;
unsigned int discard_alignment;
int is_ready;
+ int closing;
};
static DEFINE_SPINLOCK(blkif_io_lock);
@@ -1134,7 +1135,7 @@ blkfront_closing(struct blkfront_info *info)
if (bdev->bd_openers) {
xenbus_dev_error(xbdev, -EBUSY,
"Device in use; refusing to close");
- xenbus_switch_state(xbdev, XenbusStateClosing);
+ info->closing = 1;
} else {
xlvbd_release_gendisk(info);
xenbus_frontend_closed(xbdev);
@@ -1423,8 +1424,10 @@ static int blkif_release(struct gendisk *disk, fmode_t mode)
mutex_lock(&info->mutex);
xbdev = info->xbdev;
- if (xbdev && xbdev->state == XenbusStateClosing) {
+ if (xbdev && (xbdev->state == XenbusStateClosing || info->closing)) {
/* pending switch to state closed */
+ if (xbdev->state != XenbusStateClosing)
+ xenbus_switch_state(xbdev, XenbusStateClosing);
dev_info(disk_to_dev(bdev->bd_disk), "releasing disk\n");
xlvbd_release_gendisk(info);
xenbus_frontend_closed(info->xbdev);
--
1.7.7.5
^ permalink raw reply related
* Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're busy
From: Andrew Jones @ 2012-02-17 16:52 UTC (permalink / raw)
To: xen-devel; +Cc: jeremy, virtualization, konrad wilk
In-Reply-To: <7bc7b30a-158e-411a-8eac-9650790c0bec@zmail17.collab.prod.int.phx2.redhat.com>
On Thu, Feb 16, 2012 at 12:33:32PM -0500, Andrew Jones wrote:
> Hmm, I should maybe self-nack this. The bug that led me to writing
> it is likely only with older tooling, such as RHEL5's. The problem
> was if you attempted to detach a mounted disk twice, then the second
> time it would succeed. The guest had flipped to Closing on the first
> try, and thus didn't issue an error to xenbus on the second. I see
Actually, it's even worse than I thought. Just a single attempt to
detach the device will cause the guest grief (with RHEL5's tools
anyway). Once xenbus shows the device is in the Closing state, then
tasks accessing the device may hang.
> The reason I only say maybe self-nack though, is because this state
> change seemed to be thrown in with another fix[1]. I'm not sure if
> the new behavior on legacy hosts was considered or not. If not, then
> we can consider it now. Do we want to have deferred asynch detaches
> over protecting the guest from multiple detach calls on legacy hosts?
>
I guess we can keep the feature and protect the guest with a patch like
I'll send in a moment. It doesn't really work for me with a RHEL5 host
though. The deferred close works from the pov of the guest, but the
state of the block device gets left in Closed after the guest unmounts
it, and then RHEL5's tools can't detach/reattach it. If the deferred
close ever worked on other Xen hosts though, then I don't believe this
patch would break it, and it will also keep the guest safe when run on
hosts that don't treat state=Closing the way it currently expects.
Drew
^ permalink raw reply
* Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're busy
From: Andrew Jones @ 2012-02-17 16:31 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Konrad Rzeszutek Wilk, jeremy, xen-devel, virtualization
In-Reply-To: <20120217152004.GB30298@phenom.dumpdata.com>
----- Original Message -----
> On Fri, Feb 17, 2012 at 07:50:11AM -0500, Andrew Jones wrote:
> >
> >
> > ----- Original Message -----
> > > On Thu, Feb 16, 2012 at 01:17:09PM +0100, Andrew Jones wrote:
> > > > We just reported to xenbus that we can't close yet, because
> > > > blkfront is still in use. So we shouldn't then immediately
> > > > state that we are closing.
> > >
> > > What happens if the user uses --force to unplug the device?
> > > Will that still work?
> >
> > With RHEL5 tooling I get the same results. That is, the device
> > is forcibly detached, and then any task in the guest that still
> > attempts to use (or even just unmount) the device hangs.
> >
> > I don't know anything about xl, but afaict block-detach
> > doesn't take a 'force' option?
>
> konrad@phenom:~/ssd/linux$ xm block-detach
> xend [ERROR] Config file does not exist: /etc/xen/xend-config.sxp
> Error: 'xm block-detach' requires between 2 and 3 arguments.
>
> Usage: xm block-detach <Domain> <DevId> [-f|--force]
>
> Destroy a domain's virtual block device.
That's 'xm', not 'xl'. I tested RHEL5's 'xm' with the force option
and, as I said above, I got the same results before and after this
patch. I believe the problem (the non-force case) may exist with
latest 'xm' too (not just RHEL5's), but I didn't really check, since
I know 'xl' is the tool that truly matters for upstream now. As I
said before, the problem shouldn't exist with 'xl' though, since it
bails on state != 4, and afaict it doesn't have a force option.
Anyway, I don't think this patch would break that path even if it
did.
I'm actually going to send a v2 of this patch in a few minutes. I'm
just finishing it up now.
Drew
>
>
> >
> > Drew
> >
> > > >
> > > > Signed-off-by: Andrew Jones <drjones@redhat.com>
> > > > ---
> > > > drivers/block/xen-blkfront.c | 1 -
> > > > 1 files changed, 0 insertions(+), 1 deletions(-)
> > > >
> > > > diff --git a/drivers/block/xen-blkfront.c
> > > > b/drivers/block/xen-blkfront.c
> > > > index 5d45688..b53cae4 100644
> > > > --- a/drivers/block/xen-blkfront.c
> > > > +++ b/drivers/block/xen-blkfront.c
> > > > @@ -1134,7 +1134,6 @@ blkfront_closing(struct blkfront_info
> > > > *info)
> > > > if (bdev->bd_openers) {
> > > > xenbus_dev_error(xbdev, -EBUSY,
> > > > "Device in use; refusing to close");
> > > > - xenbus_switch_state(xbdev, XenbusStateClosing);
> > > > } else {
> > > > xlvbd_release_gendisk(info);
> > > > xenbus_frontend_closed(xbdev);
> > > > --
> > > > 1.7.7.5
> > > >
> > > >
> > > > _______________________________________________
> > > > Xen-devel mailing list
> > > > Xen-devel@lists.xensource.com
> > > > http://lists.xensource.com/xen-devel
> > >
>
^ permalink raw reply
* Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're busy
From: Konrad Rzeszutek Wilk @ 2012-02-17 15:20 UTC (permalink / raw)
To: Andrew Jones; +Cc: Konrad Rzeszutek Wilk, jeremy, xen-devel, virtualization
In-Reply-To: <df073550-b049-4522-ac03-8f4ffcea426c@zmail17.collab.prod.int.phx2.redhat.com>
On Fri, Feb 17, 2012 at 07:50:11AM -0500, Andrew Jones wrote:
>
>
> ----- Original Message -----
> > On Thu, Feb 16, 2012 at 01:17:09PM +0100, Andrew Jones wrote:
> > > We just reported to xenbus that we can't close yet, because
> > > blkfront is still in use. So we shouldn't then immediately
> > > state that we are closing.
> >
> > What happens if the user uses --force to unplug the device?
> > Will that still work?
>
> With RHEL5 tooling I get the same results. That is, the device
> is forcibly detached, and then any task in the guest that still
> attempts to use (or even just unmount) the device hangs.
>
> I don't know anything about xl, but afaict block-detach
> doesn't take a 'force' option?
konrad@phenom:~/ssd/linux$ xm block-detach
xend [ERROR] Config file does not exist: /etc/xen/xend-config.sxp
Error: 'xm block-detach' requires between 2 and 3 arguments.
Usage: xm block-detach <Domain> <DevId> [-f|--force]
Destroy a domain's virtual block device.
>
> Drew
>
> > >
> > > Signed-off-by: Andrew Jones <drjones@redhat.com>
> > > ---
> > > drivers/block/xen-blkfront.c | 1 -
> > > 1 files changed, 0 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/drivers/block/xen-blkfront.c
> > > b/drivers/block/xen-blkfront.c
> > > index 5d45688..b53cae4 100644
> > > --- a/drivers/block/xen-blkfront.c
> > > +++ b/drivers/block/xen-blkfront.c
> > > @@ -1134,7 +1134,6 @@ blkfront_closing(struct blkfront_info *info)
> > > if (bdev->bd_openers) {
> > > xenbus_dev_error(xbdev, -EBUSY,
> > > "Device in use; refusing to close");
> > > - xenbus_switch_state(xbdev, XenbusStateClosing);
> > > } else {
> > > xlvbd_release_gendisk(info);
> > > xenbus_frontend_closed(xbdev);
> > > --
> > > 1.7.7.5
> > >
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xensource.com
> > > http://lists.xensource.com/xen-devel
> >
^ permalink raw reply
* Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're busy
From: Andrew Jones @ 2012-02-17 12:50 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk; +Cc: jeremy, xen-devel, konrad wilk, virtualization
In-Reply-To: <20120216194801.GB8023@andromeda.dapyr.net>
----- Original Message -----
> On Thu, Feb 16, 2012 at 01:17:09PM +0100, Andrew Jones wrote:
> > We just reported to xenbus that we can't close yet, because
> > blkfront is still in use. So we shouldn't then immediately
> > state that we are closing.
>
> What happens if the user uses --force to unplug the device?
> Will that still work?
With RHEL5 tooling I get the same results. That is, the device
is forcibly detached, and then any task in the guest that still
attempts to use (or even just unmount) the device hangs.
I don't know anything about xl, but afaict block-detach
doesn't take a 'force' option?
Drew
> >
> > Signed-off-by: Andrew Jones <drjones@redhat.com>
> > ---
> > drivers/block/xen-blkfront.c | 1 -
> > 1 files changed, 0 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/block/xen-blkfront.c
> > b/drivers/block/xen-blkfront.c
> > index 5d45688..b53cae4 100644
> > --- a/drivers/block/xen-blkfront.c
> > +++ b/drivers/block/xen-blkfront.c
> > @@ -1134,7 +1134,6 @@ blkfront_closing(struct blkfront_info *info)
> > if (bdev->bd_openers) {
> > xenbus_dev_error(xbdev, -EBUSY,
> > "Device in use; refusing to close");
> > - xenbus_switch_state(xbdev, XenbusStateClosing);
> > } else {
> > xlvbd_release_gendisk(info);
> > xenbus_frontend_closed(xbdev);
> > --
> > 1.7.7.5
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
>
^ permalink raw reply
* Re: [Xen-devel] [PATCH] blkfront: don't put bdev right after getting it
From: Andrew Jones @ 2012-02-17 12:03 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk; +Cc: jeremy, xen-devel, konrad wilk, virtualization
In-Reply-To: <20120216194422.GA8023@andromeda.dapyr.net>
----- Original Message -----
> On Thu, Feb 16, 2012 at 01:16:25PM +0100, Andrew Jones wrote:
> > We should hang onto bdev until we're done with it.
>
> Looks ok. Is there a BZ that sparked this? Thanks.
Nope. Just came across it while I was looking at the code.
Drew
> >
> > Signed-off-by: Andrew Jones <drjones@redhat.com>
> > ---
> > drivers/block/xen-blkfront.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/block/xen-blkfront.c
> > b/drivers/block/xen-blkfront.c
> > index 2f22874..5d45688 100644
> > --- a/drivers/block/xen-blkfront.c
> > +++ b/drivers/block/xen-blkfront.c
> > @@ -1410,7 +1410,6 @@ static int blkif_release(struct gendisk
> > *disk, fmode_t mode)
> > mutex_lock(&blkfront_mutex);
> >
> > bdev = bdget_disk(disk, 0);
> > - bdput(bdev);
> >
> > if (bdev->bd_openers)
> > goto out;
> > @@ -1441,6 +1440,7 @@ static int blkif_release(struct gendisk
> > *disk, fmode_t mode)
> > }
> >
> > out:
> > + bdput(bdev);
> > mutex_unlock(&blkfront_mutex);
> > return 0;
> > }
> > --
> > 1.7.7.5
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
>
^ permalink raw reply
* Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're busy
From: Konrad Rzeszutek Wilk @ 2012-02-16 19:48 UTC (permalink / raw)
To: Andrew Jones; +Cc: jeremy, xen-devel, konrad.wilk, virtualization
In-Reply-To: <1329394629-10299-1-git-send-email-drjones@redhat.com>
On Thu, Feb 16, 2012 at 01:17:09PM +0100, Andrew Jones wrote:
> We just reported to xenbus that we can't close yet, because
> blkfront is still in use. So we shouldn't then immediately
> state that we are closing.
What happens if the user uses --force to unplug the device?
Will that still work?
>
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
> drivers/block/xen-blkfront.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 5d45688..b53cae4 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -1134,7 +1134,6 @@ blkfront_closing(struct blkfront_info *info)
> if (bdev->bd_openers) {
> xenbus_dev_error(xbdev, -EBUSY,
> "Device in use; refusing to close");
> - xenbus_switch_state(xbdev, XenbusStateClosing);
> } else {
> xlvbd_release_gendisk(info);
> xenbus_frontend_closed(xbdev);
> --
> 1.7.7.5
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox