Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1530913 > unrolled thread
| Started by | Theodore Ts'o <tytso@mit.edu> |
|---|---|
| First post | 2016-11-27 19:00 +0100 |
| Last post | 2016-11-29 03:30 +0100 |
| Articles | 5 — 3 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH 00/29] UBIFS File Encryption v1 Theodore Ts'o <tytso@mit.edu> - 2016-11-27 19:00 +0100
Re: [PATCH 00/29] UBIFS File Encryption v1 Richard Weinberger <richard@nod.at> - 2016-11-27 23:30 +0100
Re: [PATCH 00/29] UBIFS File Encryption v1 Theodore Ts'o <tytso@mit.edu> - 2016-11-28 01:50 +0100
Re: [PATCH 00/29] UBIFS File Encryption v1 Eric Biggers <ebiggers@google.com> - 2016-11-28 02:30 +0100
Re: [PATCH 00/29] UBIFS File Encryption v1 Theodore Ts'o <tytso@mit.edu> - 2016-11-29 03:30 +0100
| From | Theodore Ts'o <tytso@mit.edu> |
|---|---|
| Date | 2016-11-27 19:00 +0100 |
| Subject | Re: [PATCH 00/29] UBIFS File Encryption v1 |
| Message-ID | <sIbU5-7vA-11@gated-at.bofh.it> |
On Fri, Nov 25, 2016 at 09:18:12AM +0100, Richard Weinberger wrote: > > Do you want us to address Eric's review comments on top of the fscrypt > branch or shall we rebase? > I'd suggest the former. Yes, let's address them on top of the existing fscrypt branch. I don't consider any of his comments super-serious --- they were mostly documentation or comments level changes unless I missed something. - Ted
[toc] | [next] | [standalone]
| From | Richard Weinberger <richard@nod.at> |
|---|---|
| Date | 2016-11-27 23:30 +0100 |
| Message-ID | <sIg7o-1WZ-17@gated-at.bofh.it> |
| In reply to | #1530913 |
Ted, On 27.11.2016 18:52, Theodore Ts'o wrote: > On Fri, Nov 25, 2016 at 09:18:12AM +0100, Richard Weinberger wrote: >> >> Do you want us to address Eric's review comments on top of the fscrypt >> branch or shall we rebase? >> I'd suggest the former. > > Yes, let's address them on top of the existing fscrypt branch. I > don't consider any of his comments super-serious --- they were mostly > documentation or comments level changes unless I missed something. Okay. Then I'll queue UBIFS encryption for the v4.10 merge window. Just to be sure, I base my UBIFS next tree on your fscrypt tree such that it will build fine and Linus won't see same commits with a different sha1? Usually I'm a lucky maintainer and not have to deal with dependencies between pull requests. :-) Thanks, //richard
[toc] | [prev] | [next] | [standalone]
| From | Theodore Ts'o <tytso@mit.edu> |
|---|---|
| Date | 2016-11-28 01:50 +0100 |
| Message-ID | <sIiiR-3fL-5@gated-at.bofh.it> |
| In reply to | #1530947 |
On Sun, Nov 27, 2016 at 11:21:56PM +0100, Richard Weinberger wrote:
>
> Okay. Then I'll queue UBIFS encryption for the v4.10 merge window.
> Just to be sure, I base my UBIFS next tree on your fscrypt tree such that
> it will build fine and Linus won't see same commits with a different sha1?
Yep, if you pull down the dev branch from ext4.git, and run the
command:
git log --merges ext4/origin^..ext4/dev
you should see:
commit 6da22013bb7907b33c87968c25034b409a6161a2
Merge: a2f6d9c4c081 a6e089128617
Author: Theodore Ts'o <tytso@mit.edu>
Date: Sun Nov 13 22:02:22 2016 -0500
Merge branch 'fscrypt' into origin
commit a2f6d9c4c081ec2a02529b8af2c04f3e557a3a3e
Merge: bc33b0ca11e3 9484ab1bf446
Author: Theodore Ts'o <tytso@mit.edu>
Date: Sun Nov 13 22:02:15 2016 -0500
Merge branch 'dax-4.10-iomap-pmd' into origin
Cheers,
- Ted
[toc] | [prev] | [next] | [standalone]
| From | Eric Biggers <ebiggers@google.com> |
|---|---|
| Date | 2016-11-28 02:30 +0100 |
| Message-ID | <sIiVz-3IN-7@gated-at.bofh.it> |
| In reply to | #1530947 |
On Sun, Nov 27, 2016 at 11:21:56PM +0100, Richard Weinberger wrote: > Ted, > > On 27.11.2016 18:52, Theodore Ts'o wrote: > > On Fri, Nov 25, 2016 at 09:18:12AM +0100, Richard Weinberger wrote: > >> > >> Do you want us to address Eric's review comments on top of the fscrypt > >> branch or shall we rebase? > >> I'd suggest the former. > > > > Yes, let's address them on top of the existing fscrypt branch. I > > don't consider any of his comments super-serious --- they were mostly > > documentation or comments level changes unless I missed something. > > Okay. Then I'll queue UBIFS encryption for the v4.10 merge window. > Just to be sure, I base my UBIFS next tree on your fscrypt tree such that > it will build fine and Linus won't see same commits with a different sha1? > Usually I'm a lucky maintainer and not have to deal with dependencies > between pull requests. :-) > > Thanks, > //richard Shouldn't the branch be rebased to remove the CONFIG_VMAP_STACK fixes which are already in Linus' tree? fscrypto: don't use on-stack buffer for key derivation fscrypto: don't use on-stack buffer for filename encryption Otherwise we'll end up with duplicate commits. Eric
[toc] | [prev] | [next] | [standalone]
| From | Theodore Ts'o <tytso@mit.edu> |
|---|---|
| Date | 2016-11-29 03:30 +0100 |
| Message-ID | <sIGlb-293-1@gated-at.bofh.it> |
| In reply to | #1530981 |
On Sun, Nov 27, 2016 at 05:27:58PM -0800, Eric Biggers wrote: > > Shouldn't the branch be rebased to remove the CONFIG_VMAP_STACK fixes which are > already in Linus' tree? > > fscrypto: don't use on-stack buffer for key derivation > fscrypto: don't use on-stack buffer for filename encryption > > Otherwise we'll end up with duplicate commits. Given that the ubifs folks are depending on the existing branch, having duplicate commits is considered an acceptable tradeoff to not rebasing a published commit that other trees are depending on. I tell people that the ext4.git dev branch is a rewinding branch, so people shouldn't be building other trees on top of it unless they are willing to deal with the fact that it can be rebased. However, i didn't give that warning for the fscrypt branch, so I'd much rather not rewind/rebase it. - Ted
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web