On 2017年10月30日 08:19, Ben Hutchings wrote: > On Mon, 2017-10-30 at 07:59 +0800, Qu Wenruo wrote: >> >> On 2017年10月30日 01:15, Ben Hutchings wrote: >>> You recently made a number of fixes to validation and use of name >>> lengths in btrfs: >>> >>> 286b92f43c0d btrfs: tree-log.c: Wrong printk information about namelen >>> 19c6dcbfa746 btrfs: Introduce btrfs_is_name_len_valid to avoid reading beyond boundary >>> e79a33270d05 btrfs: Check name_len with boundary in verify dir_item >>> 26a836cec2ea btrfs: Check name_len on add_inode_ref call path >>> 8ee8c2d62d5f btrfs: Verify dir_item in replay_xattr_deletes >>> 3c1d41844896 btrfs: Check name_len in btrfs_check_ref_name_override >>> 59b0a7f2c7c1 btrfs: Check name_len before read in iterate_dir_item >>> 488d7c456653 btrfs: Check name_len before reading btrfs_get_name >>> 64c7b01446f4 btrfs: Check name_len before in btrfs_del_root_ref >>> fbc326159a01 btrfs: Verify dir_item in iterate_object_props >>> >>> The bugs these are fixing probably should also be fixed on the affected >>> stable branches. Do you agree? Can you provide any guidance about how >>> far back these fixes would be needed? >> >> These fixes will soon be replace by centralized tree-checker facilities. > > Is that likely to be a small enough change to be reasonably backport- > able? It depends. Check the thread with the subject "[PATCH v3 0/5] Enhance tree block validation checker" ---- fs/btrfs/Makefile | 2 +- fs/btrfs/ctree.h | 4 + fs/btrfs/disk-io.c | 284 +------------------------------- fs/btrfs/tree-checker.c | 429 ++++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 437 insertions(+), 282 deletions(-) create mode 100644 fs/btrfs/tree-checker.c ---- Since it's centralized, most of the modification will be in tree-checker.c, and make the impact to existing code to minimal. However that patchset is just the skeleton of the whole thing, name_len related code is not moved to tree-checker yet. On the other hand, the whole name_len patchset is just an enhanced validation checker, I'm not pretty sure if such thing should be back ported especially when it's just a whack-a-hole solution. Thanks, Qu > > Ben. >
Attachment:
signature.asc
Description: OpenPGP digital signature