On Fri, Jan 20, 2017 at 4:34 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> On Fri, Jan 20, 2017 at 04:26:16PM +0100, Ilya Dryomov wrote:
>> On Fri, Jan 20, 2017 at 4:08 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>> > Ok, what were the surrounding commits? Don't we need this to handle the
>> > vmalloced stack issue in 4.9? If not, that's fine, I'll drop this,
>> > otherwise it would be good to fix that up, right?
>>
>> Yes, but it's pretty large in terms of diffstat. Honestly, I'm not
>> worried -- our on-stack buffers are really small and the chances that
>> any of them will straddle a page should be tiny.
>>
>> Here is the list (bottom to top):
>>
>> 2b1e1a7cd0a6 libceph: remove now unused ceph_*{en,de}crypt*() functions
>> e15fd0a11db0 libceph: switch ceph_x_decrypt() to ceph_crypt()
>> d03857c63bb0 libceph: switch ceph_x_encrypt() to ceph_crypt()
>> 4eb4517ce7c9 libceph: tweak calcu_signature() a little
>> 7882a26d2e2e libceph: rename and align ceph_x_authorizer::reply_buf
>> a45f795c65b4 libceph: introduce ceph_crypt() for in-place en/decryption
>> 55d9cc834f93 libceph: introduce ceph_x_encrypt_offset()
>> 462e650451c5 libceph: old_key in process_one_ticket() is redundant
>> 36721ece1e84 libceph: ceph_x_encrypt_buflen() takes in_len
>>
>> Can probably drop one or two, but you want to take these, I'd rather
>> you take them all.
>
> Given the length that 4.9 is going to be around, I'd prefer to have this
> work correctly. I'll drop this single patch now, but will queue this
> larger list up later when I get a chance to do more testing and review.
Any chance you can also take
7af3ea189a9a libceph: stop allocating a new cipher on every crypto request
6db2304aabb0 libceph: uninline ceph_crypto_key_destroy()
to make 4.9.z even more awesome? ;)
These depend on the ceph_crypt() bunch and fix a writeback deadlock
that has been there forever but started showing up only recently. The
only reason I didn't mark it for stable was this dependency.
All of the above patches were developed and tested on 4.9, so there
shouldn't be any issues.
Thanks,
Ilya
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html