Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian dpkg (http://www.linux-archive.org/debian-dpkg/)
-   -   Dpkg update in stable to fix bug with btrfs? (http://www.linux-archive.org/debian-dpkg/442349-dpkg-update-stable-fix-bug-btrfs.html)

Raphael Hertzog 10-20-2010 09:19 PM

Dpkg update in stable to fix bug with btrfs?
 
Hello,

after someone got bitten by #575891 while running a lenny chroot
on a btrfs filesystem, Julien Cristau suggested me to try to fix this bug
in stable.

Would you accept a stable upload with the attached patch ?

It's a relatively simple cherry pick of the fix made in the current
version. It's not tested yet but I would do it if you think it needs to be
fixed in stable.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693]

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
commit fd2021ab7cf2ca85fd97c74023fbcb3484ae4601
Author: Raphaël Hertzog <hertzog@debian.org>
Date: Fri Apr 9 08:35:47 2010 +0200

dpkg: fix metadata installation by not mixing rename() in a readdir() loop

dpkg's process_archive() was doing the improper assumption that a
readdir() loop would not return the same filename twice even when the
scanned directory has files renamed into it (coming from tmp.ci).

The net result of having the same filename returned twice is that the
the second time the updated file to install is no longer there and
thus dpkg removed the current metadata file believing that it was
obsolete. btrfs triggers this bug consistently.

All other readdir() occurrences have been reviewed as well for similar
problems. But they are all safe, they mainly unlink() files rather
than adding new files into the scanned directory.

Thanks to Carey Underwood and Chris Mason for their help in diagnosing
this problem.

Acked-by: Guillem Jover <guillem@debian.org>

diff --git a/debian/changelog b/debian/changelog
index c7e6e8b..d1763b9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+dpkg (1.14.30) stable; urgency=low
+
+ * Fix dpkg to not lose package metadata on filesystems where readdir()
+ returns new files added after the opendir() call, btrfs in particular
+ triggered the problematic behaviour. Closes: #575891
+
+ -- Raphaël Hertzog <hertzog@debian.org> Wed, 20 Oct 2010 23:10:29 +0200
+
dpkg (1.14.29) stable-security; urgency=high

* Modify dpkg-source to error out when it would apply patches containing
diff --git a/src/processarc.c b/src/processarc.c
index 3085962..e5922d7 100644
--- a/src/processarc.c
+++ b/src/processarc.c
@@ -44,6 +44,12 @@
#include "main.h"
#include "archives.h"

+struct rename_list {
+ struct rename_list *next;
+ char *src;
+ char *dst;
+};
+
void process_archive(const char *filename) {
static const struct TarFunctions tf = {
tarfileread,
@@ -83,6 +89,7 @@ void process_archive(const char *filename) {
struct dirent *de;
struct stat stab, oldfs;
struct packageinlist *deconpil, *deconpiltemp;
+ struct rename_list *rename_head = NULL, *rename_node = NULL;

cleanup_pkg_failed= cleanup_conflictor_failed= 0;
admindirlen= strlen(admindir);
@@ -796,19 +803,37 @@ void process_archive(const char *filename) {
varbufaddstr(&infofnvb,de->d_name);
varbufaddc(&infofnvb,0);
strcpy(cidirrest,p);
- if (!rename(cidir,infofnvb.buf)) {
+ /* We keep files to rename in a list as doing the rename immediately
+ * might influence the current readdir(), the just renamed file might
+ * be returned a second time as it's actually a new file from the
+ * point of view of the filesystem. */
+ rename_node = m_malloc(sizeof(*rename_node));
+ rename_node->next = rename_head;
+ rename_node->src = m_strdup(cidir);
+ rename_node->dst = m_strdup(infofnvb.buf);
+ rename_head = rename_node;
+ }
+ pop_cleanup(ehflag_normaltidy); /* closedir */
+
+ while ((rename_node = rename_head)) {
+ if (!rename(rename_node->src, rename_node->dst)) {
debug(dbg_scripts, "process_archive info installed %s as %s",
- cidir, infofnvb.buf);
+ rename_node->src, rename_node->dst);
} else if (errno == ENOENT) {
/* Right, no new version. */
- if (unlink(infofnvb.buf))
- ohshite(_("unable to remove obsolete info file `%.250s'"),infofnvb.buf);
- debug(dbg_scripts, "process_archive info unlinked %s",infofnvb.buf);
+ if (unlink(rename_node->dst))
+ ohshite(_("unable to remove obsolete info file `%.250s'"),
+ rename_node->dst);
+ debug(dbg_scripts, "process_archive info unlinked %s", rename_node->dst);
} else {
- ohshite(_("unable to install (supposed) new info file `%.250s'"),cidir);
+ ohshite(_("unable to install (supposed) new info file `%.250s'"),
+ rename_node->src);
}
+ rename_head = rename_node->next;
+ free(rename_node->src);
+ free(rename_node->dst);
+ free(rename_node);
}
- pop_cleanup(ehflag_normaltidy); /* closedir */

*cidirrest= 0; /* the directory itself */
dsd= opendir(cidir);

"Adam D. Barratt" 10-21-2010 08:11 PM

Dpkg update in stable to fix bug with btrfs?
 
On Wed, 2010-10-20 at 23:19 +0200, Raphael Hertzog wrote:
> after someone got bitten by #575891 while running a lenny chroot
> on a btrfs filesystem, Julien Cristau suggested me to try to fix this bug
> in stable.
>
> Would you accept a stable upload with the attached patch ?

Yes, please go ahead.

> It's a relatively simple cherry pick of the fix made in the current
> version. It's not tested yet but I would do it if you think it needs to be
> fixed in stable.

That would be good. :-)

Regards,

Adam


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1287691878.16686.825.camel@hathi.jungle.funky-badger.org">http://lists.debian.org/1287691878.16686.825.camel@hathi.jungle.funky-badger.org

Raphael Hertzog 10-31-2010 10:12 AM

Dpkg update in stable to fix bug with btrfs?
 
Hi,

On Thu, 21 Oct 2010, Adam D. Barratt wrote:
> On Wed, 2010-10-20 at 23:19 +0200, Raphael Hertzog wrote:
> > after someone got bitten by #575891 while running a lenny chroot
> > on a btrfs filesystem, Julien Cristau suggested me to try to fix this bug
> > in stable.
> >
> > Would you accept a stable upload with the attached patch ?
>
> Yes, please go ahead.

Uploaded.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693]

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20101031111227.GA9374@rivendell.home.ouaza.com">ht tp://lists.debian.org/20101031111227.GA9374@rivendell.home.ouaza.com

"Adam D. Barratt" 10-31-2010 11:36 AM

Dpkg update in stable to fix bug with btrfs?
 
On Sun, 2010-10-31 at 12:12 +0100, Raphael Hertzog wrote:
> Hi,
>
> On Thu, 21 Oct 2010, Adam D. Barratt wrote:
> > On Wed, 2010-10-20 at 23:19 +0200, Raphael Hertzog wrote:
> > > after someone got bitten by #575891 while running a lenny chroot
> > > on a btrfs filesystem, Julien Cristau suggested me to try to fix this bug
> > > in stable.
> > >
> > > Would you accept a stable upload with the attached patch ?
> >
> > Yes, please go ahead.
>
> Uploaded.

Accepted; thanks.

Regards,

Adam


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1288528597.30602.17059.camel@hathi.jungle.funky-badger.org">http://lists.debian.org/1288528597.30602.17059.camel@hathi.jungle.funky-badger.org


All times are GMT. The time now is 11:36 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.