X-Recipient: archive-cygwin@delorie.com X-Spam-Check-By: sourceware.org Date: Sat, 19 Jan 2013 12:24:52 +0100 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: rtorrent and recent snapshots - apparent problem with msync() Message-ID: <20130119112452.GA17553@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <20130117062415.GB24529@ednor.casa.cgf.cx> <20130118003522.GA1913@ednor.casa.cgf.cx> <20130118093205.GB11791@calimero.vinschen.de> <20130118154352.GA23471@ednor.casa.cgf.cx> <20130118160742.GH11791@calimero.vinschen.de> <1213214325.20130119001839@mtu-net.ru> <20130118211025.GB519@ednor.casa.cgf.cx> <20130118212413.GA9011@ednor.casa.cgf.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20130118212413.GA9011@ednor.casa.cgf.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.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