Debian Bug report logs - #593516
schroot: race condition in /proc/mounts can break cleanup

version graph

Package: schroot; Maintainer for schroot is Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>; Source for schroot is src:schroot.

Reported by: Greg Price <price@ksplice.com>

Date: Wed, 18 Aug 2010 21:15:01 UTC

Severity: normal

Tags: fixed-upstream

Found in version schroot/1.3.2-1

Fixed in version schroot/1.4.9-1

Done: Roger Leigh <rleigh@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#593516; Package schroot. (Wed, 18 Aug 2010 21:15:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Greg Price <price@ksplice.com>:
New Bug report received and forwarded. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>. (Wed, 18 Aug 2010 21:15:04 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Greg Price <price@ksplice.com>
To: submit@bugs.debian.org
Subject: schroot: race condition in /proc/mounts can break cleanup
Date: Wed, 18 Aug 2010 17:12:35 -0400
Package: schroot
Version: 1.3.2-1
Severity: normal

Hello,

schroot suffers from a race condition where if two schroot sessions
are ended concurrently, one of them may fail to clean up properly.  On
some intensely schroot-using build machines, I see this failure
regularly.  The symptom looks like this:

  E: 10mount: umount:
/var/lib/schroot/mount/somechroot-source-bd8cdb9f-611a-4991-869c-e479fa673ec7:
device is busy.

and then the 'schroot' command exits with failure.

The issue is that /proc/mounts is unreliable.  It turns out that when
you read it concurrently with a umount, you can end up missing records
for mounts that have nothing to do with the ones that were unmounted.
Arguably this is a kernel bug, but there is no simple fix, so
/proc/mounts will definitely remain unreliable at least for squeeze.

Consequently because schroot-listmounts relies on /proc/mounts, it too
is unreliable.  So when do_umount_all() in etc/setup.d/10mount does
what amounts to this (but with better reporting and error handling):

    "$LIBEXEC_DIR/schroot-listmounts" -m "$base" | xargs -rn1 umount

the schroot-listmounts may skip a record if another process is ending
another schroot session, or unmounting something for any other reason.
Then one of the internal mounts, like .../tmp or .../dev/pts, remains
mounted, and the attempt to unmount the base directory fails.

Currently I'm working around the issue with a flock around the body of
do_umount_all().  That's easy and is enough to address the problem
when no other umounts are happening on the system.  A real fix would
probably have to be for schroot to record for itself the list of
mounts it makes inside a session's tree, and rely on that list instead
of on /proc/mounts.

Cheers,
Greg




Information forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#593516; Package schroot. (Thu, 19 Aug 2010 19:24:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>. (Thu, 19 Aug 2010 19:24:05 GMT) Full text and rfc822 format available.

Message #10 received at 593516@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@codelibre.net>
To: Greg Price <price@ksplice.com>, 593516@bugs.debian.org
Subject: Re: [buildd-tools-devel] Bug#593516: schroot: race condition in /proc/mounts can break cleanup
Date: Thu, 19 Aug 2010 20:21:31 +0100
[Message part 1 (text/plain, inline)]
On Wed, Aug 18, 2010 at 05:12:35PM -0400, Greg Price wrote:
> schroot suffers from a race condition where if two schroot sessions
> are ended concurrently, one of them may fail to clean up properly.  On
> some intensely schroot-using build machines, I see this failure
> regularly.  The symptom looks like this:
> 
>   E: 10mount: umount:
> /var/lib/schroot/mount/somechroot-source-bd8cdb9f-611a-4991-869c-e479fa673ec7:
> device is busy.
> 
> and then the 'schroot' command exits with failure.
> 
> The issue is that /proc/mounts is unreliable.  It turns out that when
> you read it concurrently with a umount, you can end up missing records
> for mounts that have nothing to do with the ones that were unmounted.
> Arguably this is a kernel bug, but there is no simple fix, so
> /proc/mounts will definitely remain unreliable at least for squeeze.

This is rather annoying, but thanks for bringing it to my attention.

> Currently I'm working around the issue with a flock around the body of
> do_umount_all().  That's easy and is enough to address the problem
> when no other umounts are happening on the system.

If you would like this fix including, I'll be happy to accept a
patch implementing this.  Are you doing this in the shell script?
If it's possible to directly lock /proc/mounts with fcntl this could
be addressed directly in schroot-listmounts using sbuild::file_lock,
which wraps fcntl.

Has a bug report been filed against the Linux kernel or on the
kernel mailing list?  A fix in the kernel would be ideal, and they
should probably also be notified.

> A real fix would
> probably have to be for schroot to record for itself the list of
> mounts it makes inside a session's tree, and rely on that list instead
> of on /proc/mounts.

This wouldn't be robust enough, I'm afraid.  Processes inside the
chroot (or outside, for that matter) could mount (and umount)
filesystems after initial setup.  Mounts might also occur in
additional custom setup scripts.  As a result, we really do need
to get a definitive list of mounts at the session end in order to
clean up correctly.

At least on Linux, one other approach would be to make use of
per-process namespaces which would TTBOMK allow us to skip the
umounts completely since it's automatically cleaned up when the
last process in the namespace exits.  This has only recently
become viable without significant rearchitecting of schroot
though (IIRC it's now possible to connect to an existing namespace
without a parent-child relationship, though I'm not familiar with
the details).


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#593516; Package schroot. (Fri, 20 Aug 2010 00:57:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Greg Price <price@ksplice.com>:
Extra info received and forwarded to list. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>. (Fri, 20 Aug 2010 00:57:06 GMT) Full text and rfc822 format available.

Message #15 received at 593516@bugs.debian.org (full text, mbox):

From: Greg Price <price@ksplice.com>
To: Roger Leigh <rleigh@codelibre.net>
Cc: 593516@bugs.debian.org
Subject: Re: [buildd-tools-devel] Bug#593516: schroot: race condition in /proc/mounts can break cleanup
Date: Thu, 19 Aug 2010 20:54:38 -0400
On Thu, Aug 19, 2010 at 3:21 PM, Roger Leigh <rleigh@codelibre.net> wrote:
>> Currently I'm working around the issue with a flock around the body of
>> do_umount_all().  That's easy and is enough to address the problem
>> when no other umounts are happening on the system.
>
> If you would like this fix including, I'll be happy to accept a
> patch implementing this.  Are you doing this in the shell script?
> If it's possible to directly lock /proc/mounts with fcntl this could
> be addressed directly in schroot-listmounts using sbuild::file_lock,
> which wraps fcntl.

Sure, patch copied below.  It's not possible for userspace to directly
lock /proc/mounts; the best we can do is an advisory lock that we
ourselves respect.  So I placed a flock around the invocations of both
schroot-listmounts and umount, which are the only such invocations in
the schroot source tree.


> Has a bug report been filed against the Linux kernel or on the
> kernel mailing list?  A fix in the kernel would be ideal, and they
> should probably also be notified.

I haven't filed such a bug.  I'm debating whether to send a message to
the LKML.  Honestly, I suspect this will follow many other well-loved
quirks in that it is difficult to fix, and the best solution to hope
for may be for more people to be aware of it and handle it with
strategies like the separate-namespace approach you suggest.  Maybe
I'll mail the LKML with a strawman patch, and see if someone can prove
me wrong. =)


>> A real fix would
>> probably have to be for schroot to record for itself the list of
>> mounts it makes inside a session's tree, and rely on that list instead
>> of on /proc/mounts.
>
> This wouldn't be robust enough, I'm afraid.  Processes inside the
> chroot (or outside, for that matter) could mount (and umount)
> filesystems after initial setup.  Mounts might also occur in
> additional custom setup scripts.  As a result, we really do need
> to get a definitive list of mounts at the session end in order to
> clean up correctly.

Oof.  Yes, I see.


> At least on Linux, one other approach would be to make use of
> per-process namespaces which would TTBOMK allow us to skip the
> umounts completely since it's automatically cleaned up when the
> last process in the namespace exits.  This has only recently
> become viable without significant rearchitecting of schroot
> though (IIRC it's now possible to connect to an existing namespace
> without a parent-child relationship, though I'm not familiar with
> the details).

That sounds like a potential solution.  If you could give a separate
mount namespace to each schroot session, that would definitely fix the
problem -- the list that /proc/mounts reads is per-namespace, so there
is no race between unmounting in one namespace and reading
/proc/mounts in another.

Greg



--- schroot-1.3.2.orig/etc/setup.d/10mount
+++ schroot-1.3.2/etc/setup.d/10mount
@@ -53,6 +53,7 @@
 do_umount_all()
 {
     if [ -d "$1" ]; then
+       ( flock 9
        mounts="$("$LIBEXEC_DIR/schroot-listmounts" -m "$1")"
        if [ "x$mounts" != 'x' ]; then
             echo "$mounts" |
@@ -63,6 +64,7 @@
                umount "$mountloc" || exit 1
             done || exit 1
        fi
+       ) 9>/var/lock/umount
     fi
 }




Bug 593516 cloned as bug 593883. Request was from Roger Leigh <rleigh@codelibre.net> to control@bugs.debian.org. (Sat, 21 Aug 2010 20:51:06 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>:
Bug#593516; Package schroot. (Sat, 21 Aug 2010 21:51:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>. (Sat, 21 Aug 2010 21:51:05 GMT) Full text and rfc822 format available.

Message #22 received at 593516@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@codelibre.net>
To: Greg Price <price@ksplice.com>, 593516@bugs.debian.org
Subject: Re: [buildd-tools-devel] Bug#593516: Bug#593516: schroot: race condition in /proc/mounts can break cleanup
Date: Sat, 21 Aug 2010 22:50:00 +0100
[Message part 1 (text/plain, inline)]
tags 593516 + fixed-upstream pending
thanks

On Thu, Aug 19, 2010 at 08:54:38PM -0400, Greg Price wrote:
> On Thu, Aug 19, 2010 at 3:21 PM, Roger Leigh <rleigh@codelibre.net> wrote:
> >> Currently I'm working around the issue with a flock around the body of
> >> do_umount_all().  That's easy and is enough to address the problem
> >> when no other umounts are happening on the system.
> >
> > If you would like this fix including, I'll be happy to accept a
> > patch implementing this.  Are you doing this in the shell script?
> > If it's possible to directly lock /proc/mounts with fcntl this could
> > be addressed directly in schroot-listmounts using sbuild::file_lock,
> > which wraps fcntl.
> 
> Sure, patch copied below.  It's not possible for userspace to directly
> lock /proc/mounts; the best we can do is an advisory lock that we
> ourselves respect.  So I placed a flock around the invocations of both
> schroot-listmounts and umount, which are the only such invocations in
> the schroot source tree.

This is ideal, and I've included your patch on the schroot-1.4 branch

http://git.debian.org/?p=buildd-tools/schroot.git;a=commitdiff;h=806466870c810332fc6a5e932598e339029992bf
http://git.debian.org/?p=buildd-tools/schroot.git;a=commitdiff;h=8a65a3426da512bba036f4ac02ee588765e1bcc4

I've just altered the patch to add a comment about the purpose of the
lock.  I've also altered the lock name to /var/log/schroot-umount
to prevent conflicts with others since it's in our namespace.

> > Has a bug report been filed against the Linux kernel or on the
> > kernel mailing list?  A fix in the kernel would be ideal, and they
> > should probably also be notified.
> 
> I haven't filed such a bug.  I'm debating whether to send a message to
> the LKML.  Honestly, I suspect this will follow many other well-loved
> quirks in that it is difficult to fix, and the best solution to hope
> for may be for more people to be aware of it and handle it with
> strategies like the separate-namespace approach you suggest.  Maybe
> I'll mail the LKML with a strawman patch, and see if someone can prove
> me wrong. =)

In the meantime I duplicated this bug as #593883 and assigned it
to linux-2.6.  At least the Debian kernel team will be aware of it.


Thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
[signature.asc (application/pgp-signature, inline)]

Added tag(s) pending and fixed-upstream. Request was from Roger Leigh <rleigh@codelibre.net> to control@bugs.debian.org. (Sat, 21 Aug 2010 21:51:12 GMT) Full text and rfc822 format available.

Reply sent to Roger Leigh <rleigh@debian.org>:
You have taken responsibility. (Sat, 21 Aug 2010 23:36:06 GMT) Full text and rfc822 format available.

Notification sent to Greg Price <price@ksplice.com>:
Bug acknowledged by developer. (Sat, 21 Aug 2010 23:36:06 GMT) Full text and rfc822 format available.

Message #29 received at 593516-close@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@debian.org>
To: 593516-close@bugs.debian.org
Subject: Bug#593516: fixed in schroot 1.4.9-1
Date: Sat, 21 Aug 2010 23:33:04 +0000
Source: schroot
Source-Version: 1.4.9-1

We believe that the bug you reported is fixed in the latest version of
schroot, which is due to be installed in the Debian FTP archive:

dchroot-dsa_1.4.9-1_amd64.deb
  to main/s/schroot/dchroot-dsa_1.4.9-1_amd64.deb
dchroot_1.4.9-1_amd64.deb
  to main/s/schroot/dchroot_1.4.9-1_amd64.deb
libsbuild-dev_1.4.9-1_amd64.deb
  to main/s/schroot/libsbuild-dev_1.4.9-1_amd64.deb
libsbuild-doc_1.4.9-1_all.deb
  to main/s/schroot/libsbuild-doc_1.4.9-1_all.deb
schroot-common_1.4.9-1_all.deb
  to main/s/schroot/schroot-common_1.4.9-1_all.deb
schroot-dbg_1.4.9-1_amd64.deb
  to main/s/schroot/schroot-dbg_1.4.9-1_amd64.deb
schroot_1.4.9-1.debian.tar.gz
  to main/s/schroot/schroot_1.4.9-1.debian.tar.gz
schroot_1.4.9-1.dsc
  to main/s/schroot/schroot_1.4.9-1.dsc
schroot_1.4.9-1_amd64.deb
  to main/s/schroot/schroot_1.4.9-1_amd64.deb
schroot_1.4.9.orig.tar.gz
  to main/s/schroot/schroot_1.4.9.orig.tar.gz



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 593516@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Roger Leigh <rleigh@debian.org> (supplier of updated schroot package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Format: 1.8
Date: Sat, 21 Aug 2010 22:41:22 +0100
Source: schroot
Binary: schroot-common libsbuild-dev schroot-dbg libsbuild-doc schroot dchroot dchroot-dsa
Architecture: source all amd64
Version: 1.4.9-1
Distribution: unstable
Urgency: low
Maintainer: Debian buildd-tools Developers <buildd-tools-devel@lists.alioth.debian.org>
Changed-By: Roger Leigh <rleigh@debian.org>
Description: 
 dchroot    - Execute commands in a chroot environment
 dchroot-dsa - Execute commands in a chroot environment
 libsbuild-dev - development files for the Debian source builder
 libsbuild-doc - development documentation for the Debian source builder
 schroot    - Execute commands in a chroot environment
 schroot-common - common files for schroot
 schroot-dbg - schroot, dchroot and dchroot-dsa debuggging symbols
Closes: 593256 593516 593622
Changes: 
 schroot (1.4.9-1) unstable; urgency=low
 .
   * New upstream stable release.
   * Hide deprecation warning for deprecated priority= key name when
     reloading sessions (Closes: #593256).
   * Build doxygen documentation in arch-indep build rule.  Split
     build rule into build-arch and build-indep and also have
     separate install-arch and install-indep rules to separate
     binary and documentation installation.  This is to remove the
     need to run doxygen on all platforms, since its use of threads
     is breaking builds on some platforms.
   * Update it translation.  Thanks to Vincenzo Campanella.
   * Update zh_CN translation.  Thanks to Ji ZhengYu.
   * Update da translation (Closes: #593622).  Thanks to Joe Hanson.
   * 10mount: Add lock around schroot-listmounts call to prevent
     race condition reading /proc/mounts (Closes: #593516).  Thanks to
     Greg Price for this patch.
Checksums-Sha1: 
 445a10ad5bc1412e57903389436d897d9cb946d3 1571 schroot_1.4.9-1.dsc
 a605bfd86e70934384052157a03c8c17f8a71a34 1088368 schroot_1.4.9.orig.tar.gz
 801140fbb970bfe3b51c961d5007d1e34414a83e 21096 schroot_1.4.9-1.debian.tar.gz
 0c9893fe3d88fbf5e5a440bb384cb2ed9b7e8200 240802 schroot-common_1.4.9-1_all.deb
 1f927ecddf4de583676e909984cd1199b151f8f4 7243626 libsbuild-doc_1.4.9-1_all.deb
 a8368798faf8b2164929786f3924e27df13b6388 1845918 libsbuild-dev_1.4.9-1_amd64.deb
 b81c18c63fc0201f0e243dc476ba171ce611a8a4 16451822 schroot-dbg_1.4.9-1_amd64.deb
 5900938c867ca5020cb5fc2be2b71b88baa8b615 903472 schroot_1.4.9-1_amd64.deb
 1b5c8dff4000fc95334b4ddd31efaddb457c7c7b 401674 dchroot_1.4.9-1_amd64.deb
 55253e51230fe3afb0c5aa7088c5bfcda60fa12e 401418 dchroot-dsa_1.4.9-1_amd64.deb
Checksums-Sha256: 
 c39c1ce666e737c9b2089df67fb8ada60ad8d61a2724d3cff659ba4aee20aafe 1571 schroot_1.4.9-1.dsc
 3b7000ffd83ea4582be7ea1ef983e9a6611f9de81430b2b5a1778dbe1749def7 1088368 schroot_1.4.9.orig.tar.gz
 d8f73a98fccdbbfffc04eb3723ec3c21751cee24986a9265f2cab5ea34257f1e 21096 schroot_1.4.9-1.debian.tar.gz
 cf591df4452031d0b688cdf0668b5c02158c4a28221dbba25c32ee2fda938b7a 240802 schroot-common_1.4.9-1_all.deb
 5f03dedbd1cee51ae346b84a639e9bf83a99612dcd64911863728619d2aaa516 7243626 libsbuild-doc_1.4.9-1_all.deb
 731f0639a967ac42348b5f710614562efdc916e4e1dcee42feeb82f054a658b2 1845918 libsbuild-dev_1.4.9-1_amd64.deb
 100ab274886df3717146c3763ae538bc385c2c18070ad0fe63da52404ae04839 16451822 schroot-dbg_1.4.9-1_amd64.deb
 054e3a388b3236d4625c84be530933644c7da85866708719514f75cd8abe7562 903472 schroot_1.4.9-1_amd64.deb
 b9041a44da2512c7748ac57c7f5db6baad8af80f9d0a3fbf233616ccffaede4b 401674 dchroot_1.4.9-1_amd64.deb
 117253c813c5752811e7995e16c9a732a3fd2ca777a5de86eb175b611fdc49fd 401418 dchroot-dsa_1.4.9-1_amd64.deb
Files: 
 db7f62560206dfd4324e8d2ef8e805c8 1571 admin optional schroot_1.4.9-1.dsc
 653361f670635861213a2d2b263aa369 1088368 admin optional schroot_1.4.9.orig.tar.gz
 b77a86f96e9ae3ad6d710ffc403ace6d 21096 admin optional schroot_1.4.9-1.debian.tar.gz
 7db91cf9ed8f4db941a7710229d4f84d 240802 admin optional schroot-common_1.4.9-1_all.deb
 78640bd0762e3220ec64255057676f6f 7243626 doc optional libsbuild-doc_1.4.9-1_all.deb
 68c0b1492837f090f7d0e2737247e1cf 1845918 libdevel optional libsbuild-dev_1.4.9-1_amd64.deb
 19a719118ba5277d925c735398bad339 16451822 debug extra schroot-dbg_1.4.9-1_amd64.deb
 f15d596eeab03752dce48d0a8b074791 903472 admin optional schroot_1.4.9-1_amd64.deb
 488481bcb68407ef41dc064e47f98bd9 401674 admin optional dchroot_1.4.9-1_amd64.deb
 e0fe81153f5aa4dd865cb96cf354b94d 401418 admin optional dchroot-dsa_1.4.9-1_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEAREDAAYFAkxwXjEACgkQVcFcaSW/uEgGHwCeOanB0GBuyRvr8s6UlgWMKbFD
AGAAoI/fz09wdYG3pFu4G7ZVZyRJzpdR
=m5yz
-----END PGP SIGNATURE-----





Message #30 received at 593516-done@bugs.debian.org (full text, mbox):

From: Ben Hutchings <ben@decadent.org.uk>
To: 593516-done@bugs.debian.org
Subject: Re: race reading /proc/mounts causes umount failure and potential for serious dataloss
Date: Sun, 22 Aug 2010 02:28:43 +0100
[Message part 1 (text/plain, inline)]
On Sat, 2010-08-21 at 21:46 +0100, Roger Leigh wrote:
[...]
> I'm not aware of the specifics of how /proc/mounts is implemented, but
> I think this could be made reliable if the contents were not changed
> once opened (i.e. each reader gets a unique immutable copy rather than
> a mutable global copy that's subject to spurious changes).
[...]

And it would be a lot more convenient if directories worked like that
too.  Neither of them do, because it would require arbitrarily large
memory allocations in the kernel.

If you can't read the whole file in one go, allocate a larger buffer and
retry.  Repeat until successful.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
[signature.asc (application/pgp-signature, inline)]

Message #31 received at 593516-done@bugs.debian.org (full text, mbox):

From: Ben Hutchings <ben@decadent.org.uk>
To: 593516-done@bugs.debian.org
Subject: Re: race reading /proc/mounts causes umount failure and potential for serious dataloss
Date: Sun, 12 Sep 2010 17:41:15 +0100
[Message part 1 (text/plain, inline)]
On Sat, 2010-08-21 at 21:46 +0100, Roger Leigh wrote:
[...]
> I'm not aware of the specifics of how /proc/mounts is implemented, but
> I think this could be made reliable if the contents were not changed
> once opened (i.e. each reader gets a unique immutable copy rather than
> a mutable global copy that's subject to spurious changes).
[...]

And it would be a lot more convenient if directories worked like that
too.  Neither of them do, because it would require arbitrarily large
memory allocations in the kernel.

If you can't read the whole file in one go, allocate a larger buffer and
retry.  Repeat until successful.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

[signature.asc (application/pgp-signature, inline)]

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Thu, 14 Oct 2010 07:31:20 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Sun Apr 20 23:27:30 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.