X-Recipient:	archive-cygwin AT delorie DOT com
X-Spam-Check-By:	sourceware.org
Date:	Sat, 19 Jan 2013 12:24:52 +0100
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: rtorrent and recent snapshots - apparent problem with msync()
Message-ID:	<20130119112452.GA17553@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<20130117062415 DOT GB24529 AT ednor DOT casa DOT cgf DOT cx> <CAGHJv4cTsRD5km3oSmBy2BbWGTvL2mfbU9xRMPbnj2XCLN7HgQ AT mail DOT gmail DOT com> <CAGHJv4cAm+v_VuKXxjdriTN-d-AoQfengNEFY+MqZOAnOsH0-Q AT mail DOT gmail DOT com> <20130118003522 DOT GA1913 AT ednor DOT casa DOT cgf DOT cx> <20130118093205 DOT GB11791 AT calimero DOT vinschen DOT de> <20130118154352 DOT GA23471 AT ednor DOT casa DOT cgf DOT cx> <20130118160742 DOT GH11791 AT calimero DOT vinschen DOT de> <1213214325 DOT 20130119001839 AT mtu-net DOT ru> <20130118211025 DOT GB519 AT ednor DOT casa DOT cgf DOT cx> <20130118212413 DOT GA9011 AT ednor DOT casa DOT cgf DOT cx>
MIME-Version:	1.0
In-Reply-To:	<20130118212413.GA9011@ednor.casa.cgf.cx>
User-Agent:	Mutt/1.5.21 (2010-09-15)
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Unsubscribe:	<mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

On Jan 18 16:24, Christopher Faylor wrote:
> On Fri, Jan 18, 2013 at 04:10:25PM -0500, Christopher Faylor wrote:
> >On Sat, Jan 19, 2013 at 12:18:39AM +0400, Andrey Repin wrote:
> >>Greetings, Corinna Vinschen!
> >>
> >>>> I saw that you made another change to this function.  Is it possible that
> >>>> this might actually fix the "rtorrent problem"?
> >>
> >>> No.  It only adds the MS_SYNC handling.  rtorrent uses MS_ASYNC.
> >>
> >>That made me think... If rtorrent uses MS_ASYNC, shouldn't *rtorrent* be
> >>prepared for consequences? Instead of you trying to satisfy its
> >>expectations?

Me adding MS_SYNC handling has nothing to do with the original problem.
It was just something I realized being missing in our msync
implementation while looking into the rtorrent behaviour.

Actually, what I was really looking into at this time was...

> >It does seem that way.
> 
> Actually, it isn't that clear.  It seems like msync is failing in the
> MS_ASYNC case when it shouldn't be, i.e., rtorrent is within its rights
> to expect the operation to succeed.

...this:  Under Linux, msync might return with errno set to EBUSY if
"MS_INVALIDATE was specified in flags, and a memory  lock exists for the
specified address range."(*)

This sounds a lot like what rtorrent occurs.  So, what I was looking for
is if rtorrent calls msync with the MS_INVALIDATE flag, but it doesn't.

Right now the msync loop does not handle MS_INVALIDATE specificially,
only after the loop is exited is EBUSY returned now.  OTOH, usually the
kernel is not expected to lock a memory page temporarily for its own
dubious purposes *and* let a user mode function call fail due to that.


Corinna

(*) http://www.kernel.org/doc/man-pages/online/pages/man2/msync.2.html

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -