From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8BF49C433B4 for ; Tue, 27 Apr 2021 16:44:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5789561027 for ; Tue, 27 Apr 2021 16:44:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236623AbhD0Qox (ORCPT ); Tue, 27 Apr 2021 12:44:53 -0400 Received: from mail.kernel.org ([198.145.29.99]:35264 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236169AbhD0Qov (ORCPT ); Tue, 27 Apr 2021 12:44:51 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 5F614613D9; Tue, 27 Apr 2021 16:44:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1619541847; bh=EmmnL/cy7W84WTRcqLXm2uxSDfTW0ua9r1rfSq1Aq6Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kAAew465q1zNbOIv5oXwKeRmW9zGqf1JlX5pZhfOCMUooW7okigb3cRTrycTzOyPf Nocm9zmvgRskRed73ZoDvtERnnBow6ReHbL6yel2EtH0GCo6r6TAtO1Jk0e1loX2c1 pfEmW/UtbLIIW6ifGyqh4Ml0S3UT3a4qForr8gis= Date: Tue, 27 Apr 2021 18:44:05 +0200 From: Greg Kroah-Hartman To: Daniel Vetter Cc: Ben Skeggs , Alex Deucher , dri-devel , intel-gfx , "Anholt, Eric" , "airlied@gmail.com" , Linux Kernel Mailing List , Aditya Pakki , Kangjie Lu , David Airlie , Linus Walleij , Jean Delvare , Laurent Pinchart Subject: Re: [PATCH 000/190] Revertion of all of the umn.edu commits Message-ID: References: <20210421130105.1226686-1-gregkh@linuxfoundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 21, 2021 at 07:35:44PM +0200, Daniel Vetter wrote: > On Wed, Apr 21, 2021 at 3:01 PM Greg Kroah-Hartman > wrote: > > > > I have been meaning to do this for a while, but recent events have > > finally forced me to do so. > > > > 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 patchset has the "easy" reverts, there are 68 remaining ones that > > need to be manually reviewed. Some of them are not able to be reverted > > as they already have been reverted, or fixed up with follow-on patches > > as they were determined to be invalid. Proof that these submissions > > were almost universally wrong. > > Will you take care of these remaining ones in subsequent patches too? Yes I will. > > I will be working with some other kernel developers to determine if any > > of these reverts were actually valid changes, were actually valid, and > > if so, will resubmit them properly later. For now, it's better to be > > safe. > > > > I'll take this through my tree, so no need for any maintainer to worry > > about this, but they should be aware that future submissions from anyone > > with a umn.edu address should be by default-rejected unless otherwise > > determined to actually be a valid fix (i.e. they provide proof and you > > can verify it, but really, why waste your time doing that extra work?) > > > > thanks, > > > > greg k-h > > > > Greg Kroah-Hartman (190): > > Revert "net/rds: Avoid potential use after free in > > rds_send_remove_from_sock" > > Revert "media: st-delta: Fix reference count leak in delta_run_work" > > Revert "media: sti: Fix reference count leaks" > > Revert "media: exynos4-is: Fix several reference count leaks due to > > pm_runtime_get_sync" > > Revert "media: exynos4-is: Fix a reference count leak due to > > pm_runtime_get_sync" > > Revert "media: exynos4-is: Fix a reference count leak" > > Revert "media: ti-vpe: Fix a missing check and reference count leak" > > Revert "media: stm32-dcmi: Fix a reference count leak" > > Revert "media: s5p-mfc: Fix a reference count leak" > > Revert "media: camss: Fix a reference count leak." > > Revert "media: platform: fcp: Fix a reference count leak." > > Revert "media: rockchip/rga: Fix a reference count leak." > > Revert "media: rcar-vin: Fix a reference count leak." > > Revert "media: rcar-vin: Fix a reference count leak." > > Revert "firmware: Fix a reference count leak." > > Revert "drm/nouveau: fix reference count leak in > > nouveau_debugfs_strap_peek" > > Revert "drm/nouveau: fix reference count leak in > > nv50_disp_atomic_commit" > > Revert "drm/nouveau: fix multiple instances of reference count leaks" > > Revert "drm/nouveau/drm/noveau: fix reference count leak in > > nouveau_fbcon_open" > > Revert "PCI: Fix pci_create_slot() reference count leak" > > Revert "omapfb: fix multiple reference count leaks due to > > pm_runtime_get_sync" > > Revert "drm/radeon: Fix reference count leaks caused by > > pm_runtime_get_sync" > > Revert "drm/radeon: fix multiple reference count leak" > > Revert "drm/amdkfd: Fix reference count leaks." > > I didn't review these carefully, but from a quick look they all seem > rather inconsequental. Either error paths that are very unlikely, or > drivers which are very dead (looking at the entire list, not just what > you reverted here). > > Acked-by: Daniel Vetter Thanks for the quick review, I'm now going over them all again to see if they are valid or not, some of the pm reference count stuff all looks correct. Others not at all. > Also adding drm maintainers/lists, those aren't all on your cc it > seems. I will also forward this to fd.o sitewranglers as abuse of our > infrastructure, it's for community collaboration, not for inflicting > experiments on unconsenting subjects. Much appreciated. greg k-h From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B079BC43461 for ; Tue, 27 Apr 2021 16:44:11 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 57E7B613DD for ; Tue, 27 Apr 2021 16:44:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 57E7B613DD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id CBD996E3EF; Tue, 27 Apr 2021 16:44:09 +0000 (UTC) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by gabe.freedesktop.org (Postfix) with ESMTPS id 52C296E0F1; Tue, 27 Apr 2021 16:44:08 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 5F614613D9; Tue, 27 Apr 2021 16:44:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1619541847; bh=EmmnL/cy7W84WTRcqLXm2uxSDfTW0ua9r1rfSq1Aq6Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kAAew465q1zNbOIv5oXwKeRmW9zGqf1JlX5pZhfOCMUooW7okigb3cRTrycTzOyPf Nocm9zmvgRskRed73ZoDvtERnnBow6ReHbL6yel2EtH0GCo6r6TAtO1Jk0e1loX2c1 pfEmW/UtbLIIW6ifGyqh4Ml0S3UT3a4qForr8gis= Date: Tue, 27 Apr 2021 18:44:05 +0200 From: Greg Kroah-Hartman To: Daniel Vetter Subject: Re: [PATCH 000/190] Revertion of all of the umn.edu commits Message-ID: References: <20210421130105.1226686-1-gregkh@linuxfoundation.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jean Delvare , David Airlie , intel-gfx , Kangjie Lu , Linux Kernel Mailing List , dri-devel , Ben Skeggs , Aditya Pakki , Alex Deucher , Laurent Pinchart Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Wed, Apr 21, 2021 at 07:35:44PM +0200, Daniel Vetter wrote: > On Wed, Apr 21, 2021 at 3:01 PM Greg Kroah-Hartman > wrote: > > > > I have been meaning to do this for a while, but recent events have > > finally forced me to do so. > > > > 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 patchset has the "easy" reverts, there are 68 remaining ones that > > need to be manually reviewed. Some of them are not able to be reverted > > as they already have been reverted, or fixed up with follow-on patches > > as they were determined to be invalid. Proof that these submissions > > were almost universally wrong. > > Will you take care of these remaining ones in subsequent patches too? Yes I will. > > I will be working with some other kernel developers to determine if any > > of these reverts were actually valid changes, were actually valid, and > > if so, will resubmit them properly later. For now, it's better to be > > safe. > > > > I'll take this through my tree, so no need for any maintainer to worry > > about this, but they should be aware that future submissions from anyone > > with a umn.edu address should be by default-rejected unless otherwise > > determined to actually be a valid fix (i.e. they provide proof and you > > can verify it, but really, why waste your time doing that extra work?) > > > > thanks, > > > > greg k-h > > > > Greg Kroah-Hartman (190): > > Revert "net/rds: Avoid potential use after free in > > rds_send_remove_from_sock" > > Revert "media: st-delta: Fix reference count leak in delta_run_work" > > Revert "media: sti: Fix reference count leaks" > > Revert "media: exynos4-is: Fix several reference count leaks due to > > pm_runtime_get_sync" > > Revert "media: exynos4-is: Fix a reference count leak due to > > pm_runtime_get_sync" > > Revert "media: exynos4-is: Fix a reference count leak" > > Revert "media: ti-vpe: Fix a missing check and reference count leak" > > Revert "media: stm32-dcmi: Fix a reference count leak" > > Revert "media: s5p-mfc: Fix a reference count leak" > > Revert "media: camss: Fix a reference count leak." > > Revert "media: platform: fcp: Fix a reference count leak." > > Revert "media: rockchip/rga: Fix a reference count leak." > > Revert "media: rcar-vin: Fix a reference count leak." > > Revert "media: rcar-vin: Fix a reference count leak." > > Revert "firmware: Fix a reference count leak." > > Revert "drm/nouveau: fix reference count leak in > > nouveau_debugfs_strap_peek" > > Revert "drm/nouveau: fix reference count leak in > > nv50_disp_atomic_commit" > > Revert "drm/nouveau: fix multiple instances of reference count leaks" > > Revert "drm/nouveau/drm/noveau: fix reference count leak in > > nouveau_fbcon_open" > > Revert "PCI: Fix pci_create_slot() reference count leak" > > Revert "omapfb: fix multiple reference count leaks due to > > pm_runtime_get_sync" > > Revert "drm/radeon: Fix reference count leaks caused by > > pm_runtime_get_sync" > > Revert "drm/radeon: fix multiple reference count leak" > > Revert "drm/amdkfd: Fix reference count leaks." > > I didn't review these carefully, but from a quick look they all seem > rather inconsequental. Either error paths that are very unlikely, or > drivers which are very dead (looking at the entire list, not just what > you reverted here). > > Acked-by: Daniel Vetter Thanks for the quick review, I'm now going over them all again to see if they are valid or not, some of the pm reference count stuff all looks correct. Others not at all. > Also adding drm maintainers/lists, those aren't all on your cc it > seems. I will also forward this to fd.o sitewranglers as abuse of our > infrastructure, it's for community collaboration, not for inflicting > experiments on unconsenting subjects. Much appreciated. greg k-h _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 48FC2C433ED for ; Tue, 27 Apr 2021 16:44:10 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D563B613E7 for ; Tue, 27 Apr 2021 16:44:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D563B613E7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 404366E3D2; Tue, 27 Apr 2021 16:44:09 +0000 (UTC) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by gabe.freedesktop.org (Postfix) with ESMTPS id 52C296E0F1; Tue, 27 Apr 2021 16:44:08 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 5F614613D9; Tue, 27 Apr 2021 16:44:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1619541847; bh=EmmnL/cy7W84WTRcqLXm2uxSDfTW0ua9r1rfSq1Aq6Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kAAew465q1zNbOIv5oXwKeRmW9zGqf1JlX5pZhfOCMUooW7okigb3cRTrycTzOyPf Nocm9zmvgRskRed73ZoDvtERnnBow6ReHbL6yel2EtH0GCo6r6TAtO1Jk0e1loX2c1 pfEmW/UtbLIIW6ifGyqh4Ml0S3UT3a4qForr8gis= Date: Tue, 27 Apr 2021 18:44:05 +0200 From: Greg Kroah-Hartman To: Daniel Vetter Message-ID: References: <20210421130105.1226686-1-gregkh@linuxfoundation.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Subject: Re: [Intel-gfx] [PATCH 000/190] Revertion of all of the umn.edu commits X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jean Delvare , David Airlie , intel-gfx , Kangjie Lu , Linux Kernel Mailing List , dri-devel , "Anholt, Eric" , Ben Skeggs , Aditya Pakki , Alex Deucher , Linus Walleij , Laurent Pinchart Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Wed, Apr 21, 2021 at 07:35:44PM +0200, Daniel Vetter wrote: > On Wed, Apr 21, 2021 at 3:01 PM Greg Kroah-Hartman > wrote: > > > > I have been meaning to do this for a while, but recent events have > > finally forced me to do so. > > > > 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 patchset has the "easy" reverts, there are 68 remaining ones that > > need to be manually reviewed. Some of them are not able to be reverted > > as they already have been reverted, or fixed up with follow-on patches > > as they were determined to be invalid. Proof that these submissions > > were almost universally wrong. > > Will you take care of these remaining ones in subsequent patches too? Yes I will. > > I will be working with some other kernel developers to determine if any > > of these reverts were actually valid changes, were actually valid, and > > if so, will resubmit them properly later. For now, it's better to be > > safe. > > > > I'll take this through my tree, so no need for any maintainer to worry > > about this, but they should be aware that future submissions from anyone > > with a umn.edu address should be by default-rejected unless otherwise > > determined to actually be a valid fix (i.e. they provide proof and you > > can verify it, but really, why waste your time doing that extra work?) > > > > thanks, > > > > greg k-h > > > > Greg Kroah-Hartman (190): > > Revert "net/rds: Avoid potential use after free in > > rds_send_remove_from_sock" > > Revert "media: st-delta: Fix reference count leak in delta_run_work" > > Revert "media: sti: Fix reference count leaks" > > Revert "media: exynos4-is: Fix several reference count leaks due to > > pm_runtime_get_sync" > > Revert "media: exynos4-is: Fix a reference count leak due to > > pm_runtime_get_sync" > > Revert "media: exynos4-is: Fix a reference count leak" > > Revert "media: ti-vpe: Fix a missing check and reference count leak" > > Revert "media: stm32-dcmi: Fix a reference count leak" > > Revert "media: s5p-mfc: Fix a reference count leak" > > Revert "media: camss: Fix a reference count leak." > > Revert "media: platform: fcp: Fix a reference count leak." > > Revert "media: rockchip/rga: Fix a reference count leak." > > Revert "media: rcar-vin: Fix a reference count leak." > > Revert "media: rcar-vin: Fix a reference count leak." > > Revert "firmware: Fix a reference count leak." > > Revert "drm/nouveau: fix reference count leak in > > nouveau_debugfs_strap_peek" > > Revert "drm/nouveau: fix reference count leak in > > nv50_disp_atomic_commit" > > Revert "drm/nouveau: fix multiple instances of reference count leaks" > > Revert "drm/nouveau/drm/noveau: fix reference count leak in > > nouveau_fbcon_open" > > Revert "PCI: Fix pci_create_slot() reference count leak" > > Revert "omapfb: fix multiple reference count leaks due to > > pm_runtime_get_sync" > > Revert "drm/radeon: Fix reference count leaks caused by > > pm_runtime_get_sync" > > Revert "drm/radeon: fix multiple reference count leak" > > Revert "drm/amdkfd: Fix reference count leaks." > > I didn't review these carefully, but from a quick look they all seem > rather inconsequental. Either error paths that are very unlikely, or > drivers which are very dead (looking at the entire list, not just what > you reverted here). > > Acked-by: Daniel Vetter Thanks for the quick review, I'm now going over them all again to see if they are valid or not, some of the pm reference count stuff all looks correct. Others not at all. > Also adding drm maintainers/lists, those aren't all on your cc it > seems. I will also forward this to fd.o sitewranglers as abuse of our > infrastructure, it's for community collaboration, not for inflicting > experiments on unconsenting subjects. Much appreciated. greg k-h _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx