linux-toradex.git/net/ceph, branch v3.14.57

crush: fix a bug in tree bucket decode

2015-08-03T16:29:57+00:00

commit 82cd003a77173c91b9acad8033fb7931dac8d751 upstream.

struct crush_bucket_tree::num_nodes is u8, so ceph_decode_8_safe()
should be used.  -Wconversion catches this, but I guess it went
unnoticed in all the noise it spews.  The actual problem (at least for
common crushmaps) isn't the u32 -> u8 truncation though - it's the
advancement by 4 bytes instead of 1 in the crushmap buffer.

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

Signed-off-by: Ilya Dryomov 
Reviewed-by: Josh Durgin 
Signed-off-by: Greg Kroah-Hartman

crush: ensuring at most num-rep osds are selected

2015-06-23T00:01:15+00:00

commit 45002267e8d2699bf9b022315bee3dd13b044843 upstream.

Crush temporary buffers are allocated as per replica size configured
by the user.  When there are more final osds (to be selected as per
rule) than the replicas, buffer overlaps and it causes crash.  Now, it
ensures that at most num-rep osds are selected even if more number of
osds are allowed by the rule.

Reflects ceph.git commits 6b4d1aa99718e3b367496326c1e64551330fabc0,
                          234b066ba04976783d15ff2abc3e81b6cc06fb10.

Signed-off-by: Ilya Dryomov 
Signed-off-by: Greg Kroah-Hartman

libceph: request a new osdmap if lingering request maps to no osd

2015-06-06T15:19:32+00:00

commit b0494532214bdfbf241e94fabab5dd46f7b82631 upstream.

This commit does two things.  First, if there are any homeless
lingering requests, we now request a new osdmap even if the osdmap that
is being processed brought no changes, i.e. if a given lingering
request turned homeless in one of the previous epochs and remained
homeless in the current epoch.  Not doing so leaves us with a stale
osdmap and as a result we may miss our window for reestablishing the
watch and lose notifies.

MON=1 OSD=1:

    # cat linger-needmap.sh
    #!/bin/bash
    rbd create --size 1 test
    DEV=$(rbd map test)
    ceph osd out 0
    rbd map dne/dne # obtain a new osdmap as a side effect (!)
    sleep 1
    ceph osd in 0
    rbd resize --size 2 test
    # rbd info test | grep size -> 2M
    # blockdev --getsize $DEV -> 1M

N.B.: Not obtaining a new osdmap in between "osd out" and "osd in"
above is enough to make it miss that resize notify, but that is a
bug^Wlimitation of ceph watch/notify v1.

Second, homeless lingering requests are now kicked just like those
lingering requests whose mapping has changed.  This is mainly to
recognize that a homeless lingering request makes no sense and to
preserve the invariant that a registered lingering request is not
sitting on any of r_req_lru_item lists.  This spares us a WARN_ON,
which commit ba9d114ec557 ("libceph: clear r_req_lru_item in
__unregister_linger_request()") tried to fix the _wrong_ way.

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

libceph: fix double __remove_osd() problem

2015-03-06T22:43:25+00:00

commit 7eb71e0351fbb1b242ae70abb7bb17107fe2f792 upstream.

It turns out it's possible to get __remove_osd() called twice on the
same OSD.  That doesn't sit well with rb_erase() - depending on the
shape of the tree we can get a NULL dereference, a soft lockup or
a random crash at some point in the future as we end up touching freed
memory.  One scenario that I was able to reproduce is as follows:

            

con_fault_finish()
  osd_reset()
                              
                              ceph_osdc_handle_map()
                                
                                kick_requests()
                                  
                                  reset_changed_osds()
                                    __reset_osd()
                                      __remove_osd()
                                  
                                
    
    
    __kick_osd_requests()
      __reset_osd()
        __remove_osd() <-- !!!

A case can be made that osd refcounting is imperfect and reworking it
would be a proper resolution, but for now Sage and I decided to fix
this by adding a safe guard around __remove_osd().

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

Cc: Sage Weil 
Signed-off-by: Ilya Dryomov 
Reviewed-by: Sage Weil 
Reviewed-by: Alex Elder 
Signed-off-by: Greg Kroah-Hartman

libceph: change from BUG to WARN for __remove_osd() asserts

2015-03-06T22:43:25+00:00

commit cc9f1f518cec079289d11d732efa490306b1ddad upstream.

No reason to use BUG_ON for osd request list assertions.

Signed-off-by: Ilya Dryomov 
Reviewed-by: Alex Elder 
Signed-off-by: Greg Kroah-Hartman

libceph: assert both regular and lingering lists in __remove_osd()

2015-03-06T22:43:25+00:00

commit 7c6e6fc53e7335570ed82f77656cedce1502744e upstream.

It is important that both regular and lingering requests lists are
empty when the OSD is removed.

Signed-off-by: Ilya Dryomov 
Reviewed-by: Alex Elder 
Signed-off-by: Greg Kroah-Hartman

libceph: do not crash on large auth tickets

2014-11-21T17:23:01+00:00

commit aaef31703a0cf6a733e651885bfb49edc3ac6774 upstream.

Large (greater than 32k, the value of PAGE_ALLOC_COSTLY_ORDER) auth
tickets will have their buffers vmalloc'ed, which leads to the
following crash in crypto:

[   28.685082] BUG: unable to handle kernel paging request at ffffeb04000032c0
[   28.686032] IP: [] scatterwalk_pagedone+0x22/0x80
[   28.686032] PGD 0
[   28.688088] Oops: 0000 [#1] PREEMPT SMP
[   28.688088] Modules linked in:
[   28.688088] CPU: 0 PID: 878 Comm: kworker/0:2 Not tainted 3.17.0-vm+ #305
[   28.688088] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
[   28.688088] Workqueue: ceph-msgr con_work
[   28.688088] task: ffff88011a7f9030 ti: ffff8800d903c000 task.ti: ffff8800d903c000
[   28.688088] RIP: 0010:[]  [] scatterwalk_pagedone+0x22/0x80
[   28.688088] RSP: 0018:ffff8800d903f688  EFLAGS: 00010286
[   28.688088] RAX: ffffeb04000032c0 RBX: ffff8800d903f718 RCX: ffffeb04000032c0
[   28.688088] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8800d903f750
[   28.688088] RBP: ffff8800d903f688 R08: 00000000000007de R09: ffff8800d903f880
[   28.688088] R10: 18df467c72d6257b R11: 0000000000000000 R12: 0000000000000010
[   28.688088] R13: ffff8800d903f750 R14: ffff8800d903f8a0 R15: 0000000000000000
[   28.688088] FS:  00007f50a41c7700(0000) GS:ffff88011fc00000(0000) knlGS:0000000000000000
[   28.688088] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[   28.688088] CR2: ffffeb04000032c0 CR3: 00000000da3f3000 CR4: 00000000000006b0
[   28.688088] Stack:
[   28.688088]  ffff8800d903f698 ffffffff81392ca8 ffff8800d903f6e8 ffffffff81395d32
[   28.688088]  ffff8800dac96000 ffff880000000000 ffff8800d903f980 ffff880119b7e020
[   28.688088]  ffff880119b7e010 0000000000000000 0000000000000010 0000000000000010
[   28.688088] Call Trace:
[   28.688088]  [] scatterwalk_done+0x38/0x40
[   28.688088]  [] scatterwalk_done+0x38/0x40
[   28.688088]  [] blkcipher_walk_done+0x182/0x220
[   28.688088]  [] crypto_cbc_encrypt+0x15f/0x180
[   28.688088]  [] ? crypto_aes_set_key+0x30/0x30
[   28.688088]  [] ceph_aes_encrypt2+0x29c/0x2e0
[   28.688088]  [] ceph_encrypt2+0x93/0xb0
[   28.688088]  [] ceph_x_encrypt+0x4a/0x60
[   28.688088]  [] ? ceph_buffer_new+0x5d/0xf0
[   28.688088]  [] ceph_x_build_authorizer.isra.6+0x297/0x360
[   28.688088]  [] ? kmem_cache_alloc_trace+0x11b/0x1c0
[   28.688088]  [] ? ceph_auth_create_authorizer+0x36/0x80
[   28.688088]  [] ceph_x_create_authorizer+0x63/0xd0
[   28.688088]  [] ceph_auth_create_authorizer+0x54/0x80
[   28.688088]  [] get_authorizer+0x80/0xd0
[   28.688088]  [] prepare_write_connect+0x18b/0x2b0
[   28.688088]  [] try_read+0x1e59/0x1f10

This is because we set up crypto scatterlists as if all buffers were
kmalloc'ed.  Fix it.

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

libceph: ceph-msgr workqueue needs a resque worker

2014-11-14T16:59:49+00:00

commit f9865f06f7f18c6661c88d0511f05c48612319cc upstream.

Commit f363e45fd118 ("net/ceph: make ceph_msgr_wq non-reentrant")
effectively removed WQ_MEM_RECLAIM flag from ceph_msgr_wq.  This is
wrong - libceph is very much a memory reclaim path, so restore it.

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

libceph: gracefully handle large reply messages from the mon

2014-09-17T16:19:29+00:00

commit 73c3d4812b4c755efeca0140f606f83772a39ce4 upstream.

We preallocate a few of the message types we get back from the mon.  If we
get a larger message than we are expecting, fall back to trying to allocate
a new one instead of blindly using the one we have.

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

libceph: do not hard code max auth ticket len

2014-09-17T16:19:26+00:00

commit c27a3e4d667fdcad3db7b104f75659478e0c68d8 upstream.

We hard code cephx auth ticket buffer size to 256 bytes.  This isn't
enough for any moderate setups and, in case tickets themselves are not
encrypted, leads to buffer overflows (ceph_x_decrypt() errors out, but
ceph_decode_copy() doesn't - it's just a memcpy() wrapper).  Since the
buffer is allocated dynamically anyway, allocated it a bit later, at
the point where we know how much is going to be needed.

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

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