[157/190] Revert "Input: ad7879 - add check for read errors in interrupt"
diff mbox series

Message ID 20210421130105.1226686-158-gregkh@linuxfoundation.org
State New, archived
Headers show
Series
  • Revertion of all of the umn.edu commits
Related show

Commit Message

Greg Kroah-Hartman April 21, 2021, 1 p.m. UTC
This reverts commit e85bb0beb6498c0dffe18a2f1f16d575bc175c32.

Commits from @umn.edu addresses have been found to be submitted in "bad
faith" to try to test the kernel community's ability to review "known
malicious" changes.  The result of these submissions can be found in a
paper published at the 42nd IEEE Symposium on Security and Privacy
entitled, "Open Source Insecurity: Stealthily Introducing
Vulnerabilities via Hypocrite Commits" written by Qiushi Wu (University
of Minnesota) and Kangjie Lu (University of Minnesota).

Because of this, all submissions from this group must be reverted from
the kernel tree and will need to be re-reviewed again to determine if
they actually are a valid fix.  Until that work is complete, remove this
change to ensure that no problems are being introduced into the
codebase.

Cc: Aditya Pakki <pakki001@umn.edu>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/input/touchscreen/ad7879.c | 11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

Comments

Dmitry Torokhov April 21, 2021, 5:03 p.m. UTC | #1
Hi Greg,

On Wed, Apr 21, 2021 at 03:00:32PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit e85bb0beb6498c0dffe18a2f1f16d575bc175c32.
> 
> Commits from @umn.edu addresses have been found to be submitted in "bad
> faith" to try to test the kernel community's ability to review "known
> malicious" changes.  The result of these submissions can be found in a
> paper published at the 42nd IEEE Symposium on Security and Privacy
> entitled, "Open Source Insecurity: Stealthily Introducing
> Vulnerabilities via Hypocrite Commits" written by Qiushi Wu (University
> of Minnesota) and Kangjie Lu (University of Minnesota).
> 
> Because of this, all submissions from this group must be reverted from
> the kernel tree and will need to be re-reviewed again to determine if
> they actually are a valid fix.  Until that work is complete, remove this
> change to ensure that no problems are being introduced into the
> codebase.

This one looks really OK to me and does not have to be reverted (unless
Aditya will come clean and show the error introduced?).

> 
> Cc: Aditya Pakki <pakki001@umn.edu>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
>  drivers/input/touchscreen/ad7879.c | 11 ++++-------
>  1 file changed, 4 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/input/touchscreen/ad7879.c b/drivers/input/touchscreen/ad7879.c
> index e850853328f1..8c4f3c193550 100644
> --- a/drivers/input/touchscreen/ad7879.c
> +++ b/drivers/input/touchscreen/ad7879.c
> @@ -245,14 +245,11 @@ static void ad7879_timer(struct timer_list *t)
>  static irqreturn_t ad7879_irq(int irq, void *handle)
>  {
>  	struct ad7879 *ts = handle;
> -	int error;
>  
> -	error = regmap_bulk_read(ts->regmap, AD7879_REG_XPLUS,
> -				 ts->conversion_data, AD7879_NR_SENSE);
> -	if (error)
> -		dev_err_ratelimited(ts->dev, "failed to read %#02x: %d\n",
> -				    AD7879_REG_XPLUS, error);
> -	else if (!ad7879_report(ts))
> +	regmap_bulk_read(ts->regmap, AD7879_REG_XPLUS,
> +			 ts->conversion_data, AD7879_NR_SENSE);
> +
> +	if (!ad7879_report(ts))
>  		mod_timer(&ts->timer, jiffies + TS_PEN_UP_TIMEOUT);
>  
>  	return IRQ_HANDLED;
> -- 
> 2.31.1
> 

Thanks.
Greg Kroah-Hartman April 27, 2021, 4:55 p.m. UTC | #2
On Wed, Apr 21, 2021 at 10:03:33AM -0700, Dmitry Torokhov wrote:
> Hi Greg,
> 
> On Wed, Apr 21, 2021 at 03:00:32PM +0200, Greg Kroah-Hartman wrote:
> > This reverts commit e85bb0beb6498c0dffe18a2f1f16d575bc175c32.
> > 
> > Commits from @umn.edu addresses have been found to be submitted in "bad
> > faith" to try to test the kernel community's ability to review "known
> > malicious" changes.  The result of these submissions can be found in a
> > paper published at the 42nd IEEE Symposium on Security and Privacy
> > entitled, "Open Source Insecurity: Stealthily Introducing
> > Vulnerabilities via Hypocrite Commits" written by Qiushi Wu (University
> > of Minnesota) and Kangjie Lu (University of Minnesota).
> > 
> > Because of this, all submissions from this group must be reverted from
> > the kernel tree and will need to be re-reviewed again to determine if
> > they actually are a valid fix.  Until that work is complete, remove this
> > change to ensure that no problems are being introduced into the
> > codebase.
> 
> This one looks really OK to me and does not have to be reverted (unless
> Aditya will come clean and show the error introduced?).

I'll drop this revert, but it isn't usually good to be calling printk()
from an irq.

thanks,

greg k-h
Dmitry Torokhov April 27, 2021, 7:22 p.m. UTC | #3
On Tue, Apr 27, 2021 at 06:55:10PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Apr 21, 2021 at 10:03:33AM -0700, Dmitry Torokhov wrote:
> > Hi Greg,
> > 
> > On Wed, Apr 21, 2021 at 03:00:32PM +0200, Greg Kroah-Hartman wrote:
> > > This reverts commit e85bb0beb6498c0dffe18a2f1f16d575bc175c32.
> > > 
> > > Commits from @umn.edu addresses have been found to be submitted in "bad
> > > faith" to try to test the kernel community's ability to review "known
> > > malicious" changes.  The result of these submissions can be found in a
> > > paper published at the 42nd IEEE Symposium on Security and Privacy
> > > entitled, "Open Source Insecurity: Stealthily Introducing
> > > Vulnerabilities via Hypocrite Commits" written by Qiushi Wu (University
> > > of Minnesota) and Kangjie Lu (University of Minnesota).
> > > 
> > > Because of this, all submissions from this group must be reverted from
> > > the kernel tree and will need to be re-reviewed again to determine if
> > > they actually are a valid fix.  Until that work is complete, remove this
> > > change to ensure that no problems are being introduced into the
> > > codebase.
> > 
> > This one looks really OK to me and does not have to be reverted (unless
> > Aditya will come clean and show the error introduced?).
> 
> I'll drop this revert, but it isn't usually good to be calling printk()
> from an irq.

How else do you suggest we tell that something is wrong when
communicating with the device? For these types of devices the
communication is essentially unsolicited so we can't pass failure to a
caller to deal with it (i.e. unlike USB there is no URB posted that we
could fail and use as a mechanism to signal error to some other layer)
and while we could invent "something went wrong" input event so far
there was no interest in having anything like that.

I'd suggest sending KOBJ_ERROR uevent when a device driver detects
anomaly in the device it controls, but I wonder how systemd would react
given past experiences with KOBJ_BIND/KOBJ_UNBIND.

The message is ratelimited so it will not overfill the logs...

Thanks.
Greg Kroah-Hartman April 28, 2021, 2:14 p.m. UTC | #4
On Tue, Apr 27, 2021 at 12:22:12PM -0700, Dmitry Torokhov wrote:
> On Tue, Apr 27, 2021 at 06:55:10PM +0200, Greg Kroah-Hartman wrote:
> > On Wed, Apr 21, 2021 at 10:03:33AM -0700, Dmitry Torokhov wrote:
> > > Hi Greg,
> > > 
> > > On Wed, Apr 21, 2021 at 03:00:32PM +0200, Greg Kroah-Hartman wrote:
> > > > This reverts commit e85bb0beb6498c0dffe18a2f1f16d575bc175c32.
> > > > 
> > > > Commits from @umn.edu addresses have been found to be submitted in "bad
> > > > faith" to try to test the kernel community's ability to review "known
> > > > malicious" changes.  The result of these submissions can be found in a
> > > > paper published at the 42nd IEEE Symposium on Security and Privacy
> > > > entitled, "Open Source Insecurity: Stealthily Introducing
> > > > Vulnerabilities via Hypocrite Commits" written by Qiushi Wu (University
> > > > of Minnesota) and Kangjie Lu (University of Minnesota).
> > > > 
> > > > Because of this, all submissions from this group must be reverted from
> > > > the kernel tree and will need to be re-reviewed again to determine if
> > > > they actually are a valid fix.  Until that work is complete, remove this
> > > > change to ensure that no problems are being introduced into the
> > > > codebase.
> > > 
> > > This one looks really OK to me and does not have to be reverted (unless
> > > Aditya will come clean and show the error introduced?).
> > 
> > I'll drop this revert, but it isn't usually good to be calling printk()
> > from an irq.
> 
> How else do you suggest we tell that something is wrong when
> communicating with the device? For these types of devices the
> communication is essentially unsolicited so we can't pass failure to a
> caller to deal with it (i.e. unlike USB there is no URB posted that we
> could fail and use as a mechanism to signal error to some other layer)
> and while we could invent "something went wrong" input event so far
> there was no interest in having anything like that.
> 
> I'd suggest sending KOBJ_ERROR uevent when a device driver detects
> anomaly in the device it controls, but I wonder how systemd would react
> given past experiences with KOBJ_BIND/KOBJ_UNBIND.
> 
> The message is ratelimited so it will not overfill the logs...

Sending uevents from an irq is not a good idea, as you say :)

I don't know what the best way to "fail" this is, a ratelimited printk()
seems to be about all you can do.  Luckily hardware doesn't fail that
often in this manner.

thanks,

greg k-h

Patch
diff mbox series

diff --git a/drivers/input/touchscreen/ad7879.c b/drivers/input/touchscreen/ad7879.c
index e850853328f1..8c4f3c193550 100644
--- a/drivers/input/touchscreen/ad7879.c
+++ b/drivers/input/touchscreen/ad7879.c
@@ -245,14 +245,11 @@  static void ad7879_timer(struct timer_list *t)
 static irqreturn_t ad7879_irq(int irq, void *handle)
 {
 	struct ad7879 *ts = handle;
-	int error;
 
-	error = regmap_bulk_read(ts->regmap, AD7879_REG_XPLUS,
-				 ts->conversion_data, AD7879_NR_SENSE);
-	if (error)
-		dev_err_ratelimited(ts->dev, "failed to read %#02x: %d\n",
-				    AD7879_REG_XPLUS, error);
-	else if (!ad7879_report(ts))
+	regmap_bulk_read(ts->regmap, AD7879_REG_XPLUS,
+			 ts->conversion_data, AD7879_NR_SENSE);
+
+	if (!ad7879_report(ts))
 		mod_timer(&ts->timer, jiffies + TS_PEN_UP_TIMEOUT);
 
 	return IRQ_HANDLED;