From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oi1-f169.google.com (mail-oi1-f169.google.com [209.85.167.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 61C1E70 for ; Thu, 22 Apr 2021 15:38:05 +0000 (UTC) Received: by mail-oi1-f169.google.com with SMTP id e25so16252840oii.2 for ; Thu, 22 Apr 2021 08:38:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=JK2soomspYTuQSSOhJK9tHriSLOGjCKEaIjmgqpnvhI=; b=eV1rCvX6fRGDy8fQbRspVchO9ps0vAhpxqlqVBs82mO78cofZHkCUr9mpd5Lzvus/h q347pntznhGIYtGQg6g+8rVr3Iv15DKEpW8NZa0Faqf0FzxIDCl780qiqcerxCcKSYYW W49ICKl/4ymrtHPcD8daTWyoi+FIv1i4WIMgw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=JK2soomspYTuQSSOhJK9tHriSLOGjCKEaIjmgqpnvhI=; b=IOPPosTWHDHnIoCZzJN7q3+Pdj+XkHJCOGeCaUe/JaUp6pmnxWDGzWzNOl20UfGwbj 2Vr18v4Ktl70vnivrRH4Mxm0Pi9iLkWukRsif6MEgkZiVZ+vCqEuEvAkAJFN3aREGesE h6ZZq0CeHjDCxwMGU1WA29E4D5QUKJI4kqIQLLZ7uefg43ePVmLZNHx7Z/+YHLM63IpZ jpmQVuuW3DTQyoEEapKKnvKfXsO2UhTYX18LV4OoVQuZR1BqQ9OnHOgYzaDCFerYgLo9 MYp9OlFz2fRBzvGHNJpxISsyRu/k6LJVMgVKiFzXv179jVbUA8Xe4jhAMEbU8uG5E7Wo MSqA== X-Gm-Message-State: AOAM532jYklutsCDwvZwaAd4Z5R8VamuQ6lspTttOQLnNIqj5JpqY+Ig +rBUFJAmlYMQFbK2OGACo/VJOA== X-Google-Smtp-Source: ABdhPJypg6hzaY6ktH8ZyP7FDRB/fEeuNhtBVPxSPOOZ+g8nCbx/b296Ly+Cko1qHcpo24V2gVnl2g== X-Received: by 2002:aca:484f:: with SMTP id v76mr2607948oia.57.1619105884566; Thu, 22 Apr 2021 08:38:04 -0700 (PDT) Received: from [192.168.1.112] (c-24-9-64-241.hsd1.co.comcast.net. [24.9.64.241]) by smtp.gmail.com with ESMTPSA id r14sm728105oth.3.2021.04.22.08.38.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Apr 2021 08:38:04 -0700 (PDT) Subject: Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches To: Leon Romanovsky , Mauro Carvalho Chehab Cc: Geert Uytterhoeven , James Morris , Julia Lawall , Stephen Hemminger , Roland Dreier , Steven Rostedt , James Bottomley , ksummit@lists.linux.dev, Shuah Khan References: <20210421152209.68075314@gandalf.local.home> <20210421132824.13a70f6c@hermes.local> <20210422115511.60d1f735@coco.lan> From: Shuah Khan Message-ID: <24762711-0252-f7d2-4e41-3eb1e27955ea@linuxfoundation.org> Date: Thu, 22 Apr 2021 09:38:03 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 X-Mailing-List: ksummit@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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 escreveu: >> >>> On Wed, Apr 21, 2021 at 11:50 PM James Morris 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. thanks, -- Shuah