On Friday 27 November 2015 18:55:43 Aya Mahfouz wrote:
My first idea would be to split the key_preparsed_payload changes from the struct key changes. Have you tried that? What problems did you run into?
Yes, the problem is that the assignments to key->expiry come from key_preparsed_payload-> expiry. I tried the following division:
patch 1 include/linux/key.h security/keys/keyring.c security/keys/permission.c security/keys/process_keys.c security/keys/gc.c security/keys/internal.h
patch 2 include/linux/key-type.h security/keys/key.c
But key.c manipulates structures of type key and key_preparsed_payload.
Ok, so splitting the patch by files won't work, but that's rarely possible. It takes a little practice to split up multi-file patches, but it's not hard once you've done it a few times. Here are two methods that I tend to use:
a) 'git reset HEAD^' to undo a commit but leave the changes in place, then do 'git add -p' to selectively add changes I want in one patch, using the 'edit' subcommand when I need to split up changes within a single line.
b) 'git revert HEAD', followed by 'git show HEAD^ | patch -p1' to keep the original patch in place, then undo changes individually until you have a simpler patch to apply. Then do 'git diff HEAD^^ | patch -Rp1' to get back the changes from the original patch in a second commit. Repeat as necessary, then use 'git rebase -i' to reorder the patches as needed and clean out the extra commits.
If there are not too many instances where the two patches clash, I would probably add explicit conversions between time_t and time64_t using a cast to annotate where the first patch is incomplete.
Arnd