Re: [PATCH] binder: add BINDER_GET_EXTENDED_ERROR ioctl

From: Carlos Llamas
Date: Fri Apr 22 2022 - 12:02:04 EST


On Fri, Apr 22, 2022 at 05:25:07PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Apr 21, 2022 at 04:20:36AM +0000, Carlos Llamas wrote:
> > Provide a userspace mechanism to pull precise error information upon
> > failed operations. Extending the current error codes returned by the
> > interfaces allows userspace to better determine the course of action.
> > This could be for instance, retrying a failed transaction at a later
> > point and thus offloading the error handling from the driver.
> >
> > Some of the elements for logging failed transactions and similar are
> > folded into this new logic to avoid duplication. Such is the case for
> > error line numbers, which become irrelevant after assigning individual
> > error messages instead.
> >
> > This patch also adds BINDER_GET_EXTENDED_ERROR to the binderfs feature
> > list, to help userspace determine if the new ioctl is supported by the
> > driver.
>
> Hint, when you say "also" in a changelog text, that's a hint that this
> should be more than one patch. The last thing should be a separate
> change, right?

Yes it should. I now notice I forgot to add the binderfs feature to the
kselftests too, so I'll include that in v2.

> > @@ -2845,22 +2885,20 @@ static void binder_transaction(struct binder_proc *proc,
> > /*
> > * return_error is set above
> > */
> > - return_error_param = -EINVAL;
> > - return_error_line = __LINE__;
> > + binder_txn_error(e, &ee, return_error, -EINVAL,
> > + "cannot find target node");
>
> You do this a lot, how about making this one commit (first one), and
> then adding the new "back end" to the error stuff in a second commit.
> That would make it much easier to review, first commit does nothing new,
> second one adds the new functionality, and third adds the feature flag.

Yeah, that sounds like the appropiate split. Thanks!

>
> thanks,
>
> greg k-h

--
Carlos Llamas