02 Mar, 2013

2 commits

  • Use 'bio' in the name of variables and functions that deal with
    bios rather than 'request' to avoid confusion with the normal
    block layer use of 'request'.

    No functional changes.

    Signed-off-by: Alasdair G Kergon

    Alasdair G Kergon
     
  • Avoid returning a truncated table or status string instead of setting
    the DM_BUFFER_FULL_FLAG when the last target of a table fills the
    buffer.

    When processing a table or status request, the function retrieve_status
    calls ti->type->status. If ti->type->status returns non-zero,
    retrieve_status assumes that the buffer overflowed and sets
    DM_BUFFER_FULL_FLAG.

    However, targets don't return non-zero values from their status method
    on overflow. Most targets returns always zero.

    If a buffer overflow happens in a target that is not the last in the
    table, it gets noticed during the next iteration of the loop in
    retrieve_status; but if a buffer overflow happens in the last target, it
    goes unnoticed and erroneously truncated data is returned.

    In the current code, the targets behave in the following way:
    * dm-crypt returns -ENOMEM if there is not enough space to store the
    key, but it returns 0 on all other overflows.
    * dm-thin returns errors from the status method if a disk error happened.
    This is incorrect because retrieve_status doesn't check the error
    code, it assumes that all non-zero values mean buffer overflow.
    * all the other targets always return 0.

    This patch changes the ti->type->status function to return void (because
    most targets don't use the return code). Overflow is detected in
    retrieve_status: if the status method fills up the remaining space
    completely, it is assumed that buffer overflow happened.

    Cc: stable@vger.kernel.org
    Signed-off-by: Mikulas Patocka
    Signed-off-by: Alasdair G Kergon

    Mikulas Patocka
     

22 Dec, 2012

2 commits


27 Jul, 2012

1 commit

  • Commit outstanding metadata before returning the status for a dm thin
    pool so that the numbers reported are as up-to-date as possible.

    The commit is not performed if the device is suspended or if
    the DM_NOFLUSH_FLAG is supplied by userspace and passed to the target
    through a new 'status_flags' parameter in the target's dm_status_fn.

    The userspace dmsetup tool will support the --noflush flag with the
    'dmsetup status' and 'dmsetup wait' commands from version 1.02.76
    onwards.

    Tested-by: Mike Snitzer
    Signed-off-by: Alasdair G Kergon

    Alasdair G Kergon
     

29 Mar, 2012

1 commit

  • Device mapper uses sscanf to convert arguments to numbers. The problem is that
    the way we use it ignores additional unmatched characters in the scanned string.

    For example, this `if (sscanf(string, "%d", &number) == 1)' will match a number,
    but also it will match number with some garbage appended, like "123abc".

    As a result, device mapper accepts garbage after some numbers. For example
    the command `dmsetup create vg1-new --table "0 16384 linear 254:1bla 34816bla"'
    will pass without an error.

    This patch fixes all sscanf uses in device mapper. It appends "%c" with
    a pointer to a dummy character variable to every sscanf statement.

    The construct `if (sscanf(string, "%d%c", &number, &dummy) == 1)' succeeds
    only if string is a null-terminated number (optionally preceded by some
    whitespace characters). If there is some character appended after the number,
    sscanf matches "%c", writes the character to the dummy variable and returns 2.
    We check the return value for 1 and consequently reject numbers with some
    garbage appended.

    Signed-off-by: Mikulas Patocka
    Acked-by: Mike Snitzer
    Signed-off-by: Alasdair G Kergon

    Mikulas Patocka
     

08 Mar, 2012

1 commit

  • The following BUG is hit on the first read that is submitted to a dm
    flakey test device while the device is "down" if the corrupt_bio_byte
    feature wasn't requested when the device's table was loaded.

    Example DM table that will hit this BUG:
    0 2097152 flakey 8:0 2048 0 30

    This bug was introduced by commit a3998799fb4df0b0af8271a7d50c4269032397aa
    (dm flakey: add corrupt_bio_byte feature) in v3.1-rc1.

    BUG: unable to handle kernel paging request at ffff8801cfce3fff
    IP: [] corrupt_bio_data+0x6e/0xae [dm_flakey]
    PGD 1606063 PUD 0
    Oops: 0002 [#1] SMP
    ...
    Call Trace:

    [] flakey_end_io+0x42/0x48 [dm_flakey]
    [] clone_endio+0x54/0xb6 [dm_mod]
    [] bio_endio+0x2d/0x2f
    [] req_bio_endio+0x96/0x9f
    [] blk_update_request+0x1dc/0x3a9
    [] ? rcu_read_unlock+0x21/0x23
    [] blk_update_bidi_request+0x20/0x6e
    [] blk_end_bidi_request+0x1f/0x5d
    [] blk_end_request+0x10/0x12
    [] scsi_io_completion+0x1e5/0x4b1
    [] scsi_finish_command+0xec/0xf5
    [] scsi_softirq_done+0xff/0x108
    [] blk_done_softirq+0x84/0x98
    [] __do_softirq+0xe3/0x1d5
    [] ? _raw_spin_lock+0x62/0x69
    [] ? handle_irq_event+0x4c/0x61
    [] call_softirq+0x1c/0x30
    [] do_softirq+0x4b/0xa3
    [] irq_exit+0x53/0xca
    [] do_IRQ+0x9d/0xb4
    [] common_interrupt+0x73/0x73
    ...

    Signed-off-by: Mike Snitzer
    Cc: stable@vger.kernel.org # 3.1+
    Signed-off-by: Alasdair G Kergon

    Mike Snitzer
     

15 Jan, 2012

1 commit


26 Sep, 2011

1 commit


02 Aug, 2011

4 commits


24 Mar, 2011

1 commit

  • This target is the same as the linear target except that it returns I/O
    errors periodically. It's been found useful in simulating failing
    devices for testing purposes.

    I needed a dm target to do some failure testing on btrfs's raid code, and
    Mike pointed me at this.

    Signed-off-by: Josef Bacik
    Signed-off-by: Alasdair G Kergon

    Josef Bacik