• L
    Btrfs: fix up bounds checking in lseek · 4d1a40c6
    Liu Bo 提交于
    An user reported this, it is because that lseek's SEEK_SET/SEEK_CUR/SEEK_END
    allow a negative value for @offset, but btrfs's SEEK_DATA/SEEK_HOLE don't
    prepare for that and convert the negative @offset into unsigned type,
    so we get (end < start) warning.
    
    [ 1269.835374] ------------[ cut here ]------------
    [ 1269.836809] WARNING: CPU: 0 PID: 1241 at fs/btrfs/extent_io.c:430 insert_state+0x11d/0x140()
    [ 1269.838816] BTRFS: end < start 4094 18446744073709551615
    [ 1269.840334] CPU: 0 PID: 1241 Comm: a.out Tainted: G        W      3.16.0+ #306
    [ 1269.858229] Call Trace:
    [ 1269.858612]  [<ffffffff81801a69>] dump_stack+0x4e/0x68
    [ 1269.858952]  [<ffffffff8107894c>] warn_slowpath_common+0x8c/0xc0
    [ 1269.859416]  [<ffffffff81078a36>] warn_slowpath_fmt+0x46/0x50
    [ 1269.859929]  [<ffffffff813b0fbd>] insert_state+0x11d/0x140
    [ 1269.860409]  [<ffffffff813b1396>] __set_extent_bit+0x3b6/0x4e0
    [ 1269.860805]  [<ffffffff813b21c7>] lock_extent_bits+0x87/0x200
    [ 1269.861697]  [<ffffffff813a5b28>] btrfs_file_llseek+0x148/0x2a0
    [ 1269.862168]  [<ffffffff811f201e>] SyS_lseek+0xae/0xc0
    [ 1269.862620]  [<ffffffff8180b212>] system_call_fastpath+0x16/0x1b
    [ 1269.862970] ---[ end trace 4d33ea885832054b ]---
    
    This assumes that btrfs starts finding DATA/HOLE from the beginning of file
    if the assigned @offset is negative.
    
    Also we add alignment for lock_extent_bits 's range.
    Reported-by: NToralf Förster <toralf.foerster@gmx.de>
    Signed-off-by: NLiu Bo <bo.li.liu@oracle.com>
    Signed-off-by: NChris Mason <clm@fb.com>
    4d1a40c6
file.c 70.6 KB