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>] [day] [month] [year] [list]
Message-ID: <20070920125035.GG2689@duck.suse.cz>
Date:	Thu, 20 Sep 2007 14:50:35 +0200
From:	Jan Kara <jack@...e.cz>
To:	linux-ext4@...r.kernel.org
Cc:	linux-kernel@...r.kernel.org
Subject: Ext3 not marking filesystems as with errors

  Hi,

  one friend has just pointed me to a following misbehaviour of ext3. If we
stumble on some error in JBD (e.g. in commit code), we call
__journal_abort_hard(). It just marks the journal as aborted but does
nothing else. Later ext3 comes, finds journal aborted, calls ext3_abort()
which remounts fs read-only and stops (it does not mark filesystem as
having errors). It calls journal_abort(.., -EIO) but that does nothing
because the journal is already aborted. If you then unmount the filesystem
and mount it again, everything goes on happily as if there was no error -
no suggestion for running fsck, nothing.
  I guess this is a bug but please correct me if you don't think so. There
are two possibilities how to fix it - either we mark the filesystem as with
errors in ext3_abort() or we could call some less lowlevel function from
JBD to abort journal (as soon as j_errno is set, we are safe). Any feeling
what is less hacky?

									Honza

-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
-
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ