From: Li Li <[email protected]>
Resend [Patch v3] with cover letter in case my previous email failed
to reach the maillist (no comments for 2 weeks).
The previous comments of the old patch can be found at the following link:
https://lore.kernel.org/lkml/CANBPYPjkNWsO94nuG1TkR1DgK2W2kBxiJTriyVB7S3czHTZ1Yg@mail.gmail.com/
I copy and paste the key information here for your convenience.
* Question #1
Note, your subject does not say what TF_UPDATE_TXN is, so it's a bit
hard to determine what is happening here. Can you clean that up a bit
and sumarize what this new addition does?
How was this tested?
* Answer #1 ===
A more descriptive summary has been added to the new version of patch.
* Question #2
How was this tested?
* Answer #2
Old kernel: without this TF_UPDATE_TXN patch
New kernel: with this TF_UPDATE_TXN patch
Old apps: without setting TF_UPDATE_TXN
New apps: if (flags & TF_ONE_WAY) flags |= TF_UPDATE_TXN;
1. Compatibility: New kernel + Old apps, to verify the original
behavior doesn't change;
2. Compatibility: Old kernel + New apps, to verify the original
behavior doesn't change;
3. Unit test: New kernel + New apps, to verify the outdated oneway
binder transaction is actually superseded by the latest one (by
enabling BINDER_DEBUG logs);
4. Stress test: New kernel + New apps sending oneway binder
transactions repeatedly, to verify the size of the available async
binder buffer over time, and if the transactions fail as before
(due to async buffer running out).
* Question #3
Did checkpatch pass this? Please always use --strict and fix up all the
issues that it reports as this is not a normal kernel coding style.
* Answer #3
Yes, the latest version has passed "./scripts/checkpatch.pl --strict"
* Changelog
v3:
- Add this changelog required by "The canonical patch format"
v2:
- Fix alignment warnings reported by checkpatch --strict
- Add descriptive summary in patch subject
Li Li (1):
Binder: add TF_UPDATE_TXN to replace outdated txn
drivers/android/binder.c | 85 ++++++++++++++++++++++++++++-
drivers/android/binder_trace.h | 4 ++
include/uapi/linux/android/binder.h | 1 +
3 files changed, 87 insertions(+), 3 deletions(-)
--
2.36.1.124.g0e6072fb45-goog
On Thu, May 26, 2022 at 10:50 PM Greg KH <[email protected]> wrote:
>
> On Thu, May 26, 2022 at 03:00:17PM -0700, Li Li wrote:
> > From: Li Li <[email protected]>
> >
> > Resend [Patch v3] with cover letter in case my previous email failed
> > to reach the maillist (no comments for 2 weeks).
> >
> > The previous comments of the old patch can be found at the following link:
> > https://lore.kernel.org/lkml/CANBPYPjkNWsO94nuG1TkR1DgK2W2kBxiJTriyVB7S3czHTZ1Yg@mail.gmail.com/
> >
> > I copy and paste the key information here for your convenience.
> >
> > * Question #1
> >
> > Note, your subject does not say what TF_UPDATE_TXN is, so it's a bit
> > hard to determine what is happening here. Can you clean that up a bit
> > and sumarize what this new addition does?
> > How was this tested?
> >
> > * Answer #1 ===
> >
> > A more descriptive summary has been added to the new version of patch.
> >
> > * Question #2
> >
> > How was this tested?
> >
> > * Answer #2
> >
> > Old kernel: without this TF_UPDATE_TXN patch
> > New kernel: with this TF_UPDATE_TXN patch
> > Old apps: without setting TF_UPDATE_TXN
> > New apps: if (flags & TF_ONE_WAY) flags |= TF_UPDATE_TXN;
> >
> > 1. Compatibility: New kernel + Old apps, to verify the original
> > behavior doesn't change;
> >
> > 2. Compatibility: Old kernel + New apps, to verify the original
> > behavior doesn't change;
> >
> > 3. Unit test: New kernel + New apps, to verify the outdated oneway
> > binder transaction is actually superseded by the latest one (by
> > enabling BINDER_DEBUG logs);
> >
> > 4. Stress test: New kernel + New apps sending oneway binder
> > transactions repeatedly, to verify the size of the available async
> > binder buffer over time, and if the transactions fail as before
> > (due to async buffer running out).
> >
> > * Question #3
> >
> > Did checkpatch pass this? Please always use --strict and fix up all the
> > issues that it reports as this is not a normal kernel coding style.
> >
> > * Answer #3
> >
> > Yes, the latest version has passed "./scripts/checkpatch.pl --strict"
> >
> > * Changelog
> >
> > v3:
> > - Add this changelog required by "The canonical patch format"
> > v2:
> > - Fix alignment warnings reported by checkpatch --strict
> > - Add descriptive summary in patch subject
> >
> > Li Li (1):
> > Binder: add TF_UPDATE_TXN to replace outdated txn
> >
> > drivers/android/binder.c | 85 ++++++++++++++++++++++++++++-
> > drivers/android/binder_trace.h | 4 ++
> > include/uapi/linux/android/binder.h | 1 +
> > 3 files changed, 87 insertions(+), 3 deletions(-)
> >
> > --
> > 2.36.1.124.g0e6072fb45-goog
> >
> > _______________________________________________
> > devel mailing list
> > [email protected]
> > http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
>
>
> Hi,
>
> This is the friendly semi-automated patch-bot of Greg Kroah-Hartman.
> You have sent him a patch that has triggered this response.
>
> Right now, the development tree you have sent a patch for is "closed"
> due to the timing of the merge window. Don't worry, the patch(es) you
> have sent are not lost, and will be looked at after the merge window is
> over (after the -rc1 kernel is released by Linus).
>
> So thank you for your patience and your patches will be reviewed at this
> later time, you do not have to do anything further, this is just a short
> note to let you know the patch status and so you don't worry they didn't
> make it through.
Hi Greg and all reviewers,
The rc-1 has been released for some days. Do I need to resend the patch
v3 [1] again to the maillist? Please let me know what I should do next to
have it reviewed. Thanks!
[1]:
[RESEND PATCH v3 0/1] Binder: add TF_UPDATE_TXN to replace outdated txn
https://lore.kernel.org/lkml/[email protected]/
>
> thanks,
>
> greg k-h's patch email bot
On Wed, Jun 15, 2022 at 11:05:23AM -0700, Li Li wrote:
> On Thu, May 26, 2022 at 10:50 PM Greg KH <[email protected]> wrote:
> >
> > On Thu, May 26, 2022 at 03:00:17PM -0700, Li Li wrote:
> > > From: Li Li <[email protected]>
> > >
> > > Resend [Patch v3] with cover letter in case my previous email failed
> > > to reach the maillist (no comments for 2 weeks).
> > >
> > > The previous comments of the old patch can be found at the following link:
> > > https://lore.kernel.org/lkml/CANBPYPjkNWsO94nuG1TkR1DgK2W2kBxiJTriyVB7S3czHTZ1Yg@mail.gmail.com/
> > >
> > > I copy and paste the key information here for your convenience.
> > >
> > > * Question #1
> > >
> > > Note, your subject does not say what TF_UPDATE_TXN is, so it's a bit
> > > hard to determine what is happening here. Can you clean that up a bit
> > > and sumarize what this new addition does?
> > > How was this tested?
> > >
> > > * Answer #1 ===
> > >
> > > A more descriptive summary has been added to the new version of patch.
> > >
> > > * Question #2
> > >
> > > How was this tested?
> > >
> > > * Answer #2
> > >
> > > Old kernel: without this TF_UPDATE_TXN patch
> > > New kernel: with this TF_UPDATE_TXN patch
> > > Old apps: without setting TF_UPDATE_TXN
> > > New apps: if (flags & TF_ONE_WAY) flags |= TF_UPDATE_TXN;
> > >
> > > 1. Compatibility: New kernel + Old apps, to verify the original
> > > behavior doesn't change;
> > >
> > > 2. Compatibility: Old kernel + New apps, to verify the original
> > > behavior doesn't change;
> > >
> > > 3. Unit test: New kernel + New apps, to verify the outdated oneway
> > > binder transaction is actually superseded by the latest one (by
> > > enabling BINDER_DEBUG logs);
> > >
> > > 4. Stress test: New kernel + New apps sending oneway binder
> > > transactions repeatedly, to verify the size of the available async
> > > binder buffer over time, and if the transactions fail as before
> > > (due to async buffer running out).
> > >
> > > * Question #3
> > >
> > > Did checkpatch pass this? Please always use --strict and fix up all the
> > > issues that it reports as this is not a normal kernel coding style.
> > >
> > > * Answer #3
> > >
> > > Yes, the latest version has passed "./scripts/checkpatch.pl --strict"
> > >
> > > * Changelog
> > >
> > > v3:
> > > - Add this changelog required by "The canonical patch format"
> > > v2:
> > > - Fix alignment warnings reported by checkpatch --strict
> > > - Add descriptive summary in patch subject
> > >
> > > Li Li (1):
> > > Binder: add TF_UPDATE_TXN to replace outdated txn
> > >
> > > drivers/android/binder.c | 85 ++++++++++++++++++++++++++++-
> > > drivers/android/binder_trace.h | 4 ++
> > > include/uapi/linux/android/binder.h | 1 +
> > > 3 files changed, 87 insertions(+), 3 deletions(-)
> > >
> > > --
> > > 2.36.1.124.g0e6072fb45-goog
> > >
> > > _______________________________________________
> > > devel mailing list
> > > [email protected]
> > > http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
> >
> >
> > Hi,
> >
> > This is the friendly semi-automated patch-bot of Greg Kroah-Hartman.
> > You have sent him a patch that has triggered this response.
> >
> > Right now, the development tree you have sent a patch for is "closed"
> > due to the timing of the merge window. Don't worry, the patch(es) you
> > have sent are not lost, and will be looked at after the merge window is
> > over (after the -rc1 kernel is released by Linus).
> >
> > So thank you for your patience and your patches will be reviewed at this
> > later time, you do not have to do anything further, this is just a short
> > note to let you know the patch status and so you don't worry they didn't
> > make it through.
>
> Hi Greg and all reviewers,
>
> The rc-1 has been released for some days. Do I need to resend the patch
> v3 [1] again to the maillist? Please let me know what I should do next to
> have it reviewed. Thanks!
If it still applies, no need to resend.
I'm waiting for the other binder maintainers to review it before doing
anything with it.
thanks
greg k-h