linux-stable.git/drivers/block/rbd.c, branch linux-3.17.y

rbd: Fix error recovery in rbd_obj_read_sync()

2014-11-14T18:10:39+00:00

commit a8d4205623ae965e36c68629db306ca0695a2771 upstream.

When we fail to allocate page vector in rbd_obj_read_sync() we just
basically ignore the problem and continue which will result in an oops
later. Fix the problem by returning proper error.

CC: Yehuda Sadeh 
CC: Sage Weil 
CC: ceph-devel@vger.kernel.org
Coverity-id: 1226882
Signed-off-by: Jan Kara 
Signed-off-by: Ilya Dryomov 
Signed-off-by: Greg Kroah-Hartman

rbd: rbd workqueues need a resque worker

2014-11-14T18:10:24+00:00

commit 792c3a914910bd34302c5345578f85cfcb5e2c01 upstream.

Need to use WQ_MEM_RECLAIM for our workqueues to prevent I/O lockups
under memory pressure - we sit on the memory reclaim path.

Signed-off-by: Ilya Dryomov 
Tested-by: Micha Krause 
Reviewed-by: Sage Weil 
Signed-off-by: Greg Kroah-Hartman

rbd: fix error return code in rbd_dev_device_setup()

2014-09-10T07:59:06+00:00

Fix to return -ENOMEM from the workqueue alloc error handling
case instead of 0, as done elsewhere in this function.

Reviewed-by: Alex Elder 
Signed-off-by: Wei Yongjun

rbd: avoid format-security warning inside alloc_workqueue()

2014-09-10T07:59:06+00:00

drivers/block/rbd.c: In function ‘rbd_dev_device_setup’:
drivers/block/rbd.c:5090:19: warning: format not a string literal and no format arguments [-Wformat-security]

Reported-by: kbuild test robot 
Signed-off-by: Ilya Dryomov

rbd: remove extra newlines from rbd_warn() messages

2014-08-07T12:01:09+00:00

rbd_warn() string should be a single line - rbd_warn() appends \n.

Signed-off-by: Ilya Dryomov

rbd: allocate img_request with GFP_NOIO instead GFP_ATOMIC

2014-08-07T12:00:52+00:00

Now that rbd_img_request_create() is called from work functions, no
need to use GFP_ATOMIC.

Signed-off-by: Ilya Dryomov 
Reviewed-by: Alex Elder

rbd: rework rbd_request_fn()

2014-08-07T10:56:20+00:00

While it was never a good idea to sleep in request_fn(), commit
34c6bc2c919a ("locking/mutexes: Add extra reschedule point") made it
a *bad* idea.  mutex_lock() since 3.15 may reschedule *before* putting
task on the mutex wait queue, which for tasks in !TASK_RUNNING state
means block forever.  request_fn() may be called with !TASK_RUNNING on
the way to schedule() in io_schedule().

Offload request handling to a workqueue, one per rbd device, to avoid
calling blocking primitives from rbd_request_fn().

Fixes: http://tracker.ceph.com/issues/8818

Cc: stable@vger.kernel.org # 3.16, needs backporting for 3.15
Signed-off-by: Ilya Dryomov 
Tested-by: Eric Eastman 
Tested-by: Greg Wilson 
Reviewed-by: Alex Elder

rbd: take snap_id into account when reading in parent info

2014-07-25T09:16:50+00:00

If we are mapping a snapshot, we must read in the parent_overlap value
of that snapshot instead of that of the base image.  Not doing so may
in particular result in us returning zeros instead of user data:

    # cat overlap-snap.sh
    #!/bin/bash
    rbd create --size 10 --image-format 2 foo
    FOO_DEV=$(rbd map foo)
    dd if=/dev/urandom of=$FOO_DEV bs=1M &>/dev/null
    echo "Base image"
    dd if=$FOO_DEV bs=1 count=16 skip=$(((4 << 20) - 8)) 2>/dev/null | xxd
    rbd snap create foo@snap
    rbd snap protect foo@snap
    rbd clone foo@snap bar
    rbd snap create bar@snap
    BAR_DEV=$(rbd map bar@snap)
    echo "Snapshot"
    dd if=$BAR_DEV bs=1 count=16 skip=$(((4 << 20) - 8)) 2>/dev/null | xxd
    rbd resize --allow-shrink --size 4 bar
    echo "Snapshot after base image resize"
    dd if=$BAR_DEV bs=1 count=16 skip=$(((4 << 20) - 8)) 2>/dev/null | xxd

    # ./overlap-snap.sh
    Base image
    0000000: e781 e33b d34b 2225 6034 2845 a2e3 36ed  ...;.K"%`4(E..6.
    Snapshot
    0000000: e781 e33b d34b 2225 6034 2845 a2e3 36ed  ...;.K"%`4(E..6.
    Resizing image: 100% complete...done.
    Snapshot after base image resize
    0000000: e781 e33b d34b 2225 0000 0000 0000 0000  ...;.K"%........

Even though bar@snap is taken with the old bar parent_overlap (8M),
reads from bar@snap beyond the new bar parent_overlap (4M) return
zeroes.  Fix it.

Signed-off-by: Ilya Dryomov 
Reviewed-by: Alex Elder

rbd: do not read in parent info before snap context

2014-07-25T09:16:14+00:00

Currently rbd_dev_v2_header_info() reads in parent info before the snap
context is read in.  This is wrong, because we may need to look at the
the parent_overlap value of the snapshot instead of that of the base
image, for example when mapping a snapshot - see next commit.  (When
mapping a snapshot, all we got is its name and we need the snap context
to translate that name into an id to know which parent info to look
for.)

The approach taken here is to make sure rbd_dev_v2_parent_info() is
called after the snap context has been read in.  The other approach
would be to add a parent_overlap field to struct rbd_mapping and
maintain it the same way rbd_mapping::size is maintained.  The reason
I chose the first approach is that the value of keeping around both
base image values and the actual mapping values is unclear to me.

Signed-off-by: Ilya Dryomov 
Reviewed-by: Alex Elder

rbd: update mapping size only on refresh

2014-07-25T09:15:58+00:00

There is no sense in trying to update the mapping size before it's even
been set.

Signed-off-by: Ilya Dryomov 
Reviewed-by: Alex Elder