On Fri, Jan 20, 2017 at 04:57:37PM +0100, Ilya Dryomov wrote:
> 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.
Sure, I'll work to queue these all up for the next round of kernels,
thanks for the git commit ids.
greg k-h
--
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