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, 08 Dec 2020 12:51:08 +0000 From: David Howells <dhowells@...hat.com> To: Gabriel Krisman Bertazi <krisman@...labora.com> Cc: dhowells@...hat.com, viro@...iv.linux.org.uk, tytso@....edu, khazhy@...gle.com, adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org, kernel@...labora.com Subject: Re: [PATCH 5/8] vfs: Include origin of the SB error notification Gabriel Krisman Bertazi <krisman@...labora.com> wrote: > @@ -130,6 +131,8 @@ struct superblock_error_notification { > __u32 error_cookie; > __u64 inode; > __u64 block; > + char function[SB_NOTIFICATION_FNAME_LEN]; > + __u16 line; > char desc[0]; > }; As Darrick said, this is a UAPI breaker, so you shouldn't do this (you can, however, merge this ahead a patch). Also, I would put the __u16 before the char[]. That said, I'm not sure whether it's useful to include the function name and line. Both fields are liable to change over kernel commits, so it's not something userspace can actually interpret. I think you're better off dumping those into dmesg. Further, this reduces the capacity of desc[] significantly - I don't know if that's a problem. And yet further, there's no room for addition of new fields with the desc[] buffer on the end. Now maybe you're planning on making use of desc[] for text-encoding? David
Powered by blists - more mailing lists