linux-kernel - Re: WARNING in xfs_lwr.c, xfs

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]

Date:	Sun, 13 Jun 2010 19:10:30 -0400
From:	Ilia Mirkin <imirkin@...m.mit.edu>
To:	Dave Chinner <david@...morbit.com>
Cc:	Roman Kononov <roman@...arylife.net>, xfs@....sgi.com,
	linux-kernel@...r.kernel.org
Subject: Re: WARNING in xfs_lwr.c, xfs_write()

On Sun, Jun 13, 2010 at 6:47 PM, Dave Chinner <david@...morbit.com> wrote:
> On Sat, Jun 12, 2010 at 01:00:52AM -0400, Ilia Mirkin wrote:
>> Sorry to pick up an old-ish thread, but I have a similar situation:
>>
>> On Sun, May 23, 2010 at 9:19 PM, Dave Chinner <david@...morbit.com> wrote:
>> > On Sun, May 23, 2010 at 09:23:44AM -0500, Roman Kononov wrote:
>> >> On 2010-05-23, 20:18:56 +1000, Dave Chinner <david@...morbit.com> wrote:
>> >> > Can you find out what the application is triggering this?
>>
>> I noticed this happening with mysql and xtrabackup -- the latter opens
>> up mysql's files while mysql is still running (and modifying its own
>> files) and backs them up in a (hopefully) safe way.
>
> That's not safe at all - there's no guarantee you'll end up with a
> consistent database image doing backups like this. Have you ever
> tried to restore and use one of these backups?

Yep, works great. [Used it to initialize a slave, did the full
checksums, so it's unlikely to have randomly corrupt data.] It's the
only credible way to backup a sizeable mysql db, since it works online
with InnoDB; the other options involve either only using MyISAM
(non-transactional) or locking the db for the duration (we couldn't
wait that long, but attempting to do it on a backup machine looked
like it was going to take somewhere between 3 and 7 days, although we
gave up after 24 hours... not something we can afford to do with any
kind of regularity).

>>
>> Would it be safe to remove the warning at
>> fs/xfs/linux-2.6/xfs_lrw.c:651 (which looks like it has moved to
>> xfs_file.c in 2.6.34)? It seems undesirable to get a long stream of
>> these (51 in this particular instance) every time we run a backup...
>
> You can if you want, but then you won't know when your backup or
> database might have been corrupted, right?

No, but I wouldn't know that without the warnings either -- for all I
know xtrabackup could be buggy in all kinds of ways. The only real way
to check is to use the backup data in some way.

>
>> IOW, is the warning purely something along the lines of "Userspace is
>> doing something wonky, but the underlying FS will still be fine no
>> matter what" kind of deal, or could there be an actual problem with
>> the XFS metadata itself?
>
> Nothing wrong with the filesystem metadata will occur - as I said
> eariler in the thread that this is a warning to tell us that data
> corruption is possible due to userspace doing something stupid, not
> a filesystem bug.

OK, thanks for the clarification. Ideally these wouldn't taint the
kernel either -- perhaps these can be downgraded to a message that
explicitly suggests that nothing is wrong with kernel-space things,
only user-space? The backtrace doesn't really get you much, so really
all you want to show is the offending process...

Thanks,

Ilia Mirkin
imirkin@...m.mit.edu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/