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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 26 Oct 2021 14:06:37 +0200 From: Jan Kara <jack@...e.cz> To: Amir Goldstein <amir73il@...il.com> Cc: Gabriel Krisman Bertazi <krisman@...labora.com>, 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, Jan Kara <jack@...e.cz> Subject: Re: [PATCH v9 24/31] fanotify: Report fid entry even for zero-length file_handle On Tue 26-10-21 12:09:19, Amir Goldstein wrote: > On Mon, Oct 25, 2021 at 10:30 PM Gabriel Krisman Bertazi > <krisman@...labora.com> wrote: > > > > Non-inode errors will reported with an empty file_handle. In > > preparation for that, allow some events to print the FID record even if > > there isn't any file_handle encoded > > > > Even though FILEID_ROOT is used internally, make zero-length file > > handles be reported as FILEID_INVALID. > > > > Reviewed-by: Amir Goldstein <amir73il@...il.com> > > Reviewed-by: Jan Kara <jack@...e.cz> > > Signed-off-by: Gabriel Krisman Bertazi <krisman@...labora.com> > > > > --- > > Changes since v8: > > - Move fanotify_event_has_object_fh check here (jan) > > Logically, this move is wrong, because after this patch, > copy_fid_info_to_user() can theoretically be called with NULL fh in the > existing construct of: > if (fanotify_event_has_object_fh(event)) { > ... > ret = copy_fid_info_to_user(fanotify_event_fsid(event), > > fanotify_event_object_fh(event), > > The thing that prevents this case in effect is that FAN_FS_ERROR > is not yet wired, but I am not sure if leaving this theoretic bisect > issue is a good idea. > > Anyway, that's a very minor theoretic issue and I am sure Jan can > decide whether to deal with it and how (no need to post v10 IMO). Hum, correct. I guess I'll just fold this patch into patch 26. Logically they are very close anyway. Honza -- Jan Kara <jack@...e.com> SUSE Labs, CR
Powered by blists - more mailing lists