linux-ext4 - Re: [PATCH] e2fsprogs: error checking in blkid/devname.c

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0802221305410.11313@lpc1.fields.utoronto.ca>
Date:	Fri, 22 Feb 2008 13:10:40 -0500 (EST)
From:	Philip Spencer <pspencer@...lds.utoronto.ca>
To:	Theodore Tso <tytso@....EDU>
cc:	Eric Sandeen <sandeen@...hat.com>,
	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH] e2fsprogs: error checking in blkid/devname.c

You know what -- I went back and double-checked all the logs, and somehow
or other I must have recorded a timestamp wrong as 3:19:21 instead of 
3:19:51.

The segfault did in fact happen at 3:19:51 a.m. which is exactly the same 
time as my backup script moved on to the next filesystem.

So, it occurred during the unmount and lvremove of the snapshot volume.
It is, then, entirely expected that the device-mapper routines would 
return an error if the device no longer existed when the task was run.

My apologies for mixing up the timestamps! And no bug in device-mapper, 
just the one in e2fsprogs whch segfaulted in this circumstance instead of 
dropping the device from its list. Having it fail outright, and not list 
the device at all, is the correct behaviour for this situation -- just as 
if the device had already been removed before the blkid routines were run.

- Philip

On Fri, 22 Feb 2008, Theodore Tso wrote:

> On Fri, Feb 22, 2008 at 10:16:53AM -0600, Eric Sandeen wrote:
>> From a quick chat with agk, it sounds like outright failure is
>> appropriate.  Sounds like most of the calls fail for reasons like ENOMEM
>> (but it might be nice if it returned that, eh?)
>
> So the question then is why is it that Phillip was able to seeing
> failures when he was creating and deleting snapshots?
>
> I don't mind having blkid return a failure, but it may not fix
> Phillip's scenario which he listed in BZ #433857; yeah, he won't have
> a core dump, which is good, but it might mean that some or all of the
> dm volumes disappear from the blkid results.
>
> 							- Ted
>

--------------------------------------------+-------------------------------
Philip Spencer  pspencer@...lds.utoronto.ca | Director of Computing Services
Room 336        (416)-348-9710  ext3036     | The Fields Institute for
222 College St, Toronto ON M5T 3J1 Canada   | Research in Mathematical Sciences
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html