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: <47BEF575.40908@redhat.com>
Date:	Fri, 22 Feb 2008 10:16:53 -0600
From:	Eric Sandeen <sandeen@...hat.com>
To:	Theodore Tso <tytso@....EDU>
CC:	ext4 development <linux-ext4@...r.kernel.org>,
	pspencer@...lds.utoronto.ca
Subject: Re: [PATCH] e2fsprogs: error checking in blkid/devname.c

Theodore Tso wrote:
> On Fri, Feb 22, 2008 at 09:02:56AM -0600, Eric Sandeen wrote:
>> Theodore Tso wrote:
>>> This looks good, but I assume that the bug was caused by some race
>>> condition where if you try to call dm_task_get_info() while some other
>>> process is creating or removing a snapshot, dm_task_get_info() is
>>> returning some kind of EAGAIN, or some other "Try again; we're busy"
>>> error, right?
>>>
>>> If that is the case, can you try to find out what error is being
>>> returned?  It may be the right thing to do is to check to see if we
>>> are getting a "resource is locked; try again in a sec" error message,
>>> and retry the dm_task_get_info(), instead of just returning a failure.
>> well, dm_task_get_info just returns either 0 or 1; unless there is some
>> other contextual piece of information to use, I don't know if we can
>> differentiate between error types.  I'll ask agk...
> 
> Maybe the right thing is to try 3 times before giving up, maybe with a
> nanosleep in between, or some such?  Hopefully agk can give us some
> hints about what's the right way to handle errors from all of the
> dm_task* calls.

>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?)

-Eric
-
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