| 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
| ||
|
Message-ID: <bug-206443-13602-WKCFLZTcQL@https.bugzilla.kernel.org/> Date: Thu, 20 Feb 2020 04:26:23 +0000 From: bugzilla-daemon@...zilla.kernel.org To: linux-ext4@...r.kernel.org Subject: [Bug 206443] general protection fault in ext4 during simultaneous online resize and write operations https://bugzilla.kernel.org/show_bug.cgi?id=206443 --- Comment #14 from Theodore Tso (tytso@....edu) --- Patches to BZ don't have to be perfect, or mailing list ready. But it would be nice if they actually applied (e.g., not be white-space damaged) and if they actually compiled (not be missing macro definitions). :-) In my experience, bugzilla is good for collecting data when we are trying to root-cause a problem. But it's a lot more work to look at a bug in BZ, since we have to download it first. Where as if it is sent to the mailing list, it's a lot easier to review it and to send back comments. For that matter, it's fine to send patches to the mailing list that aren't ready to be applied. Using a [PATCH RFC] subject prefix is a good way to make that clear; Linus Torvalds has been known to post patches with "Warning! I haven't even tried to compile it yet"; this is just to show the approach I'm thinking of. What's important is to make sure expectations are set for why the patch is being sent to the list or being uploaded to BZ. Thanks for your work on this bug! -- You are receiving this mail because: You are watching the assignee of the bug.
Powered by blists - more mailing lists