ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Shuah Khan <skhan@linuxfoundation.org>
To: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Leon Romanovsky <leon@kernel.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	James Morris <jmorris@namei.org>,
	Julia Lawall <julia.lawall@inria.fr>,
	Stephen Hemminger <stephen@networkplumber.org>,
	Roland Dreier <roland@kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	ksummit@lists.linux.dev, Shuah Khan <skhan@linuxfoundation.org>
Subject: Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
Date: Fri, 23 Apr 2021 16:41:38 -0600	[thread overview]
Message-ID: <a0572704-05c9-d9a4-c930-ba3de573f8d9@linuxfoundation.org> (raw)
In-Reply-To: <20210423110643.4b28c29b@coco.lan>

On 4/23/21 3:06 AM, Mauro Carvalho Chehab wrote:
> Em Thu, 22 Apr 2021 09:38:03 -0600
> Shuah Khan <skhan@linuxfoundation.org> escreveu:
> 
>> On 4/22/21 6:18 AM, Leon Romanovsky wrote:
>>> On Thu, Apr 22, 2021 at 11:55:11AM +0200, Mauro Carvalho Chehab wrote:
>>>> Em Thu, 22 Apr 2021 09:34:38 +0200
>>>> Geert Uytterhoeven <geert@linux-m68k.org> escreveu:
>>>>   
>>>>> On Wed, Apr 21, 2021 at 11:50 PM James Morris <jmorris@namei.org> wrote:
>>>>>> On Wed, 21 Apr 2021, Julia Lawall wrote:
>>>>>>> The apology states that they didn't detect any vulnerabilities.  They
>>>>>>> found three non exploitable bugs and submitted incorrect patches for them.
>>>>>>> When the patches received some positive feedback, they explained that the
>>>>>>> patches were incorrect and provided a proper fix.
>>>>>>>
>>>>>>> So they damaged trust, but not actually the Linux kernel...
>>>>>>
>>>>>> The issue is that there was no consent and no coordination, so we don't
>>>>>> know the scope of the experiment and whether it was still continuing.
>>>>>>
>>>>>> We are this not able to trust anything the group said about what they'd
>>>>>> done or not done, until now [1].
>>>>>>
>>>>>> In all probability there is nothing further amiss but we would not have
>>>>>> expected them to use fake gmail accounts to submit bugs to the kernel
>>>>>> either.
>>>>>>
>>>>>> It's now on us to audit all of their known contributions, because we don't
>>>>>> know the scope of the experiment, which was based on the use of deception,
>>>>>> and we can't make any assumptions based on what they have said.
>>>>>>
>>>>>> We also need the identity of the 'random' gmail accounts they used,
>>>>>> although this should be handled by a small trusted group in private, as it
>>>>>> will lead to privacy issues for kernel maintainers who responded to them
>>>>>> in public.
>>>>>
>>>>> What do we gain by blindly reverting all[1] umn.edu patches, and
>>>>> ignoring future patches from umn.edu?
>>>>> I think all of this is moot: other people may be doing the same thing,
>>>>> or even "in worse faith".  The only thing that helps is making sure
>>>>> patches get reviewed[2] before being applied.
>>>>>
>>>>> [1] Judging from the new review comments, many of the 190 patches
>>>>>       to be reverted were real fixes.
>>>>
>>>> The reverted ones for media (29 patches) didn't contain any malicious code.
>>>> One was useless (because the media core already fixes the pointed issue),
>>>> but the other ones were valid patches.
>>>
>>> I'm sorry that I didn't check all media commits, but this random commit
>>> 467a37fba93f ("media: dvb: Add check on sp8870_readreg") has a bug and
>>> broke sp8870 (I don't know what is it).
>>>
>>> diff --git a/drivers/media/dvb-frontends/sp8870.c b/drivers/media/dvb-frontends/sp8870.c
>>> index 8d31cf3f4f07..270a3c559e08 100644
>>> --- a/drivers/media/dvb-frontends/sp8870.c
>>> +++ b/drivers/media/dvb-frontends/sp8870.c
>>> @@ -293,7 +293,9 @@ static int sp8870_set_frontend_parameters(struct dvb_frontend *fe)
>>>           sp8870_writereg(state, 0xc05, reg0xc05);
>>>
>>>           // read status reg in order to clear pending irqs
>>> -       sp8870_readreg(state, 0x200);
>>> +       err = sp8870_readreg(state, 0x200);
>>> +       if (err)
>>> +               return err;
>>>
>>>           // system controller start
>>>           sp8870_microcontroller_start(state);
>>>
>>>
>>>      67 static int sp8870_readreg (struct sp8870_state* state, u16 reg)
>>>      68 {
>>>      69         int ret;
>>>    <...>
>>>      77         if (ret != 2) {
>>>      78                 dprintk("%s: readreg error (ret == %i)\n", __func__, ret);
>>>      79                 return -1;
>>>      80         }
>>>      81
>>>      82         return (b1[0] << 8 | b1[1]);
>>>      83 }
>>>
>>> The valid check should be if (err < 0);
>>>    
>>
>> Correct. Like all the other callers of sp8870_readreg() do with
>> its return. Non-zero return is valid for this routine.
> 
> This particular patch is completely broken and should be reverted.
> Also, probably a comment should be added to ensure that people won't
> try to send us similar "trivial" fixes.
> 
> Basically, the logic at sp8870_set_frontend_parameters() is called
> when tuning into a new DVB-T channel. the call there for
> 
> 		sp8870_readreg(state, 0x200);
> 
> Seems to be there just to reset IRQ registers. It should _not_ check
> the return results on this particular case.
> 
> Yet, this driver was written back in 1999 for a DVB-T device that
> used to be available on that time. Just one driver (av7110) can
> use such tuner. Those PCI chipsets had stopped produced a very long
> time ago. Even the company that used to produce av7110 has long
> gone, more than 17 years ago.
> 
> I guess it is time to get rid of av7110 and the ancillary drivers
> used only on it.
> 

Mauro,

Quick search shows me the following. Are you saying all of these
can be removed??

drivers/media/dvb-frontends/Kconfig
config DVB_SP8870

grep AV7 drivers/media/pci/ttpci/Kconfig

config DVB_AV7110_IR
	depends on RC_CORE=y || RC_CORE = DVB_AV7110
	default DVB_AV7110
config DVB_AV7110
	tristate "AV7110 cards"
	  Support for SAA7146 and AV7110 based DVB cards as produced
config DVB_AV7110_OSD
	bool "AV7110 OSD support"
	depends on DVB_AV7110
	default y if DVB_AV7110=y || DVB_AV7110=m
	  The AV7110 firmware provides some code to generate an OnScreenDisplay
	tristate "AV7110 cards with Budget Patch"
	depends on DVB_AV7110
	  SAA7146+AV7110 based cards (DVB-S cards). This
	  standard AV7110 driver prior to loading this

thanks,
-- Shuah

  parent reply	other threads:[~2021-04-23 22:41 UTC|newest]

Thread overview: 153+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-21 18:35 [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches James Bottomley
2021-04-21 18:46 ` Christian Borntraeger
2021-04-21 18:51 ` Alexey Dobriyan
2021-04-21 18:53   ` Christian Borntraeger
2021-04-21 19:06 ` Al Viro
2021-04-21 19:14 ` James Bottomley
2021-04-21 19:22 ` Steven Rostedt
2021-04-21 19:26   ` Kees Cook
2021-04-21 19:32   ` Roland Dreier
2021-04-21 19:55     ` Julia Lawall
2021-04-21 20:28       ` Stephen Hemminger
2021-04-21 20:37         ` Julia Lawall
2021-04-21 20:45           ` Steven Rostedt
2021-04-21 20:50             ` Julia Lawall
2021-04-21 21:03               ` Jiri Kosina
2021-04-21 21:37           ` James Morris
2021-04-22  7:34             ` Geert Uytterhoeven
2021-04-22  7:51               ` Mike Rapoport
2021-04-22  8:45                 ` Christian Brauner
2021-04-22 15:27                   ` Steven Rostedt
2021-04-22  9:39                 ` Mauro Carvalho Chehab
2021-04-22  9:55               ` Mauro Carvalho Chehab
2021-04-22 12:01                 ` Leon Romanovsky
2021-04-22 12:26                   ` Mark Brown
2021-04-22 12:35                     ` Leon Romanovsky
2021-04-22 12:52                       ` Hans Verkuil
2021-04-22 13:33                       ` Mauro Carvalho Chehab
2021-04-22 13:42                         ` Leon Romanovsky
2021-04-22 12:18                 ` Leon Romanovsky
2021-04-22 15:38                   ` Shuah Khan
2021-04-23  9:06                     ` Mauro Carvalho Chehab
2021-04-23 17:17                       ` Leon Romanovsky
2021-04-23 22:41                       ` Shuah Khan [this message]
2021-04-22  5:59     ` Christoph Hellwig
2021-04-22  6:28       ` Tomasz Figa
2021-04-22  7:05         ` Al Viro
2021-04-22  7:46           ` Al Viro
2021-04-22  7:06         ` H. Peter Anvin
2021-04-22  7:05       ` Jiri Kosina
2021-04-22 16:05       ` Roland Dreier
2021-04-22 16:24         ` Krzysztof Kozlowski
2021-04-22 18:03       ` Al Viro
2021-04-22 22:35         ` Thomas Gleixner
2021-04-22 22:53           ` Laurent Pinchart
2021-07-20 16:26             ` Kernel sustainability (was Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches) Daniel Vetter
2021-04-21 19:30 ` [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches Jiri Kosina
2021-04-21 20:28   ` Jiri Kosina
2021-04-21 22:18     ` Shuah Khan
2021-04-21 23:17       ` Guenter Roeck
2021-04-21 23:21         ` Shuah Khan
2021-04-21 19:47 ` Dan Carpenter
2021-04-22  9:34   ` Mauro Carvalho Chehab
2021-04-22  9:59     ` Johannes Berg
2021-04-22 10:52       ` Mauro Carvalho Chehab
2021-04-22 12:16         ` Mike Rapoport
2021-04-22 13:41           ` Mauro Carvalho Chehab
2021-04-22 20:15       ` Alexandre Belloni
2021-04-23  0:09         ` Randy Dunlap
2021-04-21 19:49 ` Alexandre Belloni
2021-04-22  2:05 ` Martin K. Petersen
2021-04-22  3:04   ` Joe Perches
2021-04-22 10:13     ` Mauro Carvalho Chehab
2021-04-22 12:07     ` Mark Brown
2021-04-22 16:42     ` Bart Van Assche
2021-04-22 17:58       ` Jiri Kosina
2021-04-22  4:21 ` Leon Romanovsky
2021-04-22  4:56   ` Al Viro
2021-04-22  5:52     ` Leon Romanovsky
2021-04-22  6:05     ` Christoph Hellwig
2021-04-22  6:03   ` Christoph Hellwig
2021-04-22  6:18     ` Leon Romanovsky
2021-04-22  9:20   ` Mauro Carvalho Chehab
2021-04-22 11:34     ` Leon Romanovsky
2021-04-22 13:22       ` Mark Brown
2021-04-22 13:47         ` Leon Romanovsky
2021-04-22 13:51           ` Mark Brown
2021-04-22 14:12         ` Mauro Carvalho Chehab
2021-04-22 14:51           ` Leon Romanovsky
2021-04-22 13:29       ` Steven Rostedt
2021-04-22 13:58         ` Leon Romanovsky
2021-04-22 14:20         ` Rob Herring
2021-04-23  6:04           ` Mauro Carvalho Chehab
2021-04-23  6:46             ` Joe Perches
2021-04-23  7:13               ` Mauro Carvalho Chehab
2021-04-23  7:20                 ` [PATCH RFC] scripts: add a script for sending patches Mauro Carvalho Chehab
2021-04-23 14:52                 ` Better tools for sending patches (was: Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches) Doug Anderson
2021-04-23 16:03                   ` Mark Brown
2021-04-23 17:12                     ` Leon Romanovsky
2021-04-26 23:50                       ` Simon Glass
2021-04-22 12:53     ` [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches Konstantin Ryabitsev
2021-04-22 13:08       ` Leon Romanovsky
2021-04-22 13:27         ` Konstantin Ryabitsev
2021-04-22 13:41           ` Leon Romanovsky
2021-04-22 16:28           ` Serge E. Hallyn
2021-04-22 17:56       ` Leon Romanovsky
2021-04-22 18:05         ` backfilling threads with b4 (was: Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches) Konstantin Ryabitsev
2021-04-23  7:19       ` [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches Greg KH
2021-04-23  7:31       ` Christian Brauner
2021-04-23 18:50         ` Konstantin Ryabitsev
2021-04-22 12:40   ` Mark Brown
2021-04-22 12:54     ` Mike Rapoport
2021-04-22 13:23       ` Mark Brown
2021-04-22 15:19         ` Steven Rostedt
2021-04-22 21:19           ` Thomas Gleixner
2021-04-22 21:36             ` Steven Rostedt
2021-04-22 22:39               ` Thomas Gleixner
2021-04-23  0:26                 ` Joe Perches
2021-04-23  6:15           ` Greg KH
2021-04-23  6:50             ` Dan Williams
2021-04-23  7:13             ` Geert Uytterhoeven
2021-04-23 14:41               ` Shuah Khan
2021-04-23  9:12             ` Michal Hocko
2021-04-22 14:51       ` Laurent Pinchart
2021-04-22 15:14         ` Mike Rapoport
2021-04-22 15:17           ` Laurent Pinchart
2021-04-22 15:35             ` Al Viro
2021-04-22 15:32           ` Shuah Khan
2021-04-22 10:35 ` Mauro Carvalho Chehab
2021-04-22 11:03   ` Sudip Mukherjee
2021-04-22 14:00     ` Steven Rostedt
2021-04-22 14:07       ` Jiri Kosina
2021-04-22 15:31         ` Sudip Mukherjee
2021-04-22 21:33           ` Thomas Gleixner
2021-04-22 20:28     ` Andrew Morton
2021-04-22 20:46       ` Steven Rostedt
2021-04-22 12:32   ` Martin K. Petersen
2021-04-22 15:11     ` Laurent Pinchart
2021-04-22 15:28     ` James Bottomley
2021-04-22 15:35       ` Johannes Berg
2021-04-22 15:36       ` Mark Brown
2021-04-22 15:40         ` James Bottomley
2021-04-23  9:27         ` Dan Carpenter
2021-04-22 13:24   ` Konstantin Ryabitsev
2021-04-22 14:31     ` Mauro Carvalho Chehab
2021-04-22 15:34   ` Shuah Khan
2021-04-22 15:42     ` James Bottomley
2021-04-22 15:48       ` James Bottomley
2021-04-22 15:52         ` Steven Rostedt
2021-04-22 16:08           ` Shuah Khan
2021-04-22 16:13           ` Jan Kara
2021-04-22 17:04             ` Steven Rostedt
2021-04-22 17:08             ` Martin K. Petersen
2021-04-23 11:16               ` Jan Kara
2021-04-23 12:57                 ` Mauro Carvalho Chehab
2021-04-23  7:58           ` Mauro Carvalho Chehab
2021-04-23 10:54             ` Greg KH
2021-04-23 17:09             ` Leon Romanovsky
2021-04-22 16:23         ` Konstantin Ryabitsev
2021-04-22 16:38       ` Bart Van Assche
2021-04-22 16:57         ` Leon Romanovsky
2021-04-22 18:03         ` Jiri Kosina
2021-04-22 21:26           ` Thomas Gleixner
2021-04-22 21:36             ` Jiri Kosina

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a0572704-05c9-d9a4-c930-ba3de573f8d9@linuxfoundation.org \
    --to=skhan@linuxfoundation.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=geert@linux-m68k.org \
    --cc=jmorris@namei.org \
    --cc=julia.lawall@inria.fr \
    --cc=ksummit@lists.linux.dev \
    --cc=leon@kernel.org \
    --cc=mchehab@kernel.org \
    --cc=roland@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=stephen@networkplumber.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).