On Mon, Jan 23, 2017 at 4:41 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> On Fri, Jan 20, 2017 at 06:38:18PM +0100, Greg KH wrote:
>> 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.
>
> Ok, I've queued these all up, along with a few other minor ones I found
> when digging through the logs. If any of them look incorrect, please
> let me know.
All 9 commits from my original list are there and look good. Not sure
which are those other minor ones you are talking about, though...
Could you also add 6db2304aabb0 and 7af3ea189a9a, as discussed
above?
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