On Dec 3, 2019, at 8:23 PM, Theodore Ts'o <tytso@xxxxxxx> wrote: > > This allows us to test various error handling code paths > > Previous-Version-Link: https://lore.kernel.org/r/20191121183036.29385-2-tytso@xxxxxxx > Signed-off-by: Theodore Ts'o <tytso@xxxxxxx> > --- > > +/* > + * Simulate_fail flags > + */ > +#define EXT4_SIM_BBITMAP_EIO 0x00000001 > +#define EXT4_SIM_BBITMAP_CRC 0x00000002 > +#define EXT4_SIM_IBITMAP_EIO 0x00000004 > +#define EXT4_SIM_IBITMAP_CRC 0x00000008 > +#define EXT4_SIM_INODE_EIO 0x00000010 > +#define EXT4_SIM_INODE_CRC 0x00000020 > +#define EXT4_SIM_DIRBLOCK_EIO 0x00000040 > +#define EXT4_SIM_DIRBLOCK_CRC 0x00000080 Do we really need to have the ability to inject several different failures at the same time? This will only allow 32 or 64 different failure hooks. IMHO it would be much more flexible to have these as an enum of independent values. That does somewhat limit the ability to inject multiple failures, but allows for many more different/specific fault injection points to be added in the future. We have hundreds of different fault points in Lustre to simulate hard-to-hit race conditions and trigger specific error paths. If this patch has already been landed, it would still be possible to change ext4_simulate_fail() to check "if (likely(old != flag))" rather than just the bit. That allows making this into an enum that just happens to have an non-consecutive sequence of values assigned rather than a bitmask. Cheers, Andreas
Attachment:
signature.asc
Description: Message signed with OpenPGP
