linux-ext4 - Re: [PATCH v9 00/31] file system-wide error monitoring

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:   Thu, 28 Oct 2021 08:55:02 +0300
From:   Amir Goldstein <amir73il@...il.com>
To:     Gabriel Krisman Bertazi <krisman@...labora.com>
Cc:     Jan Kara <jack@...e.cz>, Jan Kara <jack@...e.com>,
        "Darrick J. Wong" <djwong@...nel.org>,
        Theodore Tso <tytso@....edu>,
        Dave Chinner <david@...morbit.com>,
        David Howells <dhowells@...hat.com>,
        Khazhismel Kumykov <khazhy@...gle.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Linux API <linux-api@...r.kernel.org>,
        Ext4 <linux-ext4@...r.kernel.org>, kernel@...labora.com,
        Jeff Layton <jlayton@...nel.org>, andres@...razel.de
Subject: Re: [PATCH v9 00/31] file system-wide error monitoring

> Also, thank you both for the extensive review and ideas during the
> development of this series.  It was really appreciated!
>

Thank you for your appreciated effort!
It was a wild journey through some interesting experiments, but
you survived it well ;-)

Would you be interested in pursuing FAN_WB_ERROR after a due rest
and after all the dust on FAN_FS_ERROR has settled?

FAN_WB_ERROR can use the same info record and same internal
error event struct as FAN_FS_ERROR.

A call to fsnotify_wb_error(sb, inode, err) can be placed inside
mapping_set_error() and maybe for other sporadic callers of errseq_set().

For wb error, we can consider storing a snapshot of errseq of the sb/inode
in the sb/inode mark and compute error_count from the errseq diff
instead of counting it when merging events. This will keep a more accurate
report even when error reports are dropped due to allocation failure or event
queue overflow.

I have a feeling that the Postgres project would find this
functionality useful (?).

Thanks,
Amir.