Hello,
This patch removes a dead code in lib/inflate.c; it follows from a discussion in Xen.
The dead code is tracked by Coverity-ID 1055253 in Xen, was triggered by a file taken unmodified from Linux.
Thank you,
Link: https://lore.kernel.org/all/7587b503-b2ca-4476-8dc9-e9683d4ca5f0@suse.com/ -- v2: * Cc stable
Ariel Otilibili (1): lib: Remove dead code
lib/inflate.c | 2 -- 1 file changed, 2 deletions(-)
This is a follow up from a discussion in Xen:
The if-statement tests `res` is non-zero; meaning the case zero is never reached.
Link: https://lore.kernel.org/all/7587b503-b2ca-4476-8dc9-e9683d4ca5f0@suse.com/ Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Suggested-by: Jan Beulich jbeulich@suse.com Signed-off-by: Ariel Otilibili ariel.otilibili-anieli@eurecom.fr -- Cc: stable@vger.kernel.org Cc: Andrew Morton akpm@linux-foundation.org Cc: linux-kernel@vger.kernel.org Cc: Andrew Cooper andrew.cooper3@citrix.com Cc: Anthony PERARD anthony.perard@vates.tech Cc: Michal Orzel michal.orzel@amd.com Cc: Julien Grall julien@xen.org Cc: =?utf-8?q?Roger_Pau_Monn=C3=A9?= roger.pau@citrix.com Cc: Stefano Stabellini sstabellini@kernel.org Cc: xen-devel@lists.xenproject.org --- lib/inflate.c | 2 -- 1 file changed, 2 deletions(-)
diff --git a/lib/inflate.c b/lib/inflate.c index fbaf03c1748d..eab886baa1b4 100644 --- a/lib/inflate.c +++ b/lib/inflate.c @@ -1257,8 +1257,6 @@ static int INIT gunzip(void) /* Decompress */ if ((res = inflate())) { switch (res) { - case 0: - break; case 1: error("invalid compressed format (err=1)"); break;
On Thu, Dec 19, 2024 at 11:45:01PM +0100, Ariel Otilibili wrote:
This is a follow up from a discussion in Xen:
The if-statement tests `res` is non-zero; meaning the case zero is never reached.
Link: https://lore.kernel.org/all/7587b503-b2ca-4476-8dc9-e9683d4ca5f0@suse.com/ Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Suggested-by: Jan Beulich jbeulich@suse.com Signed-off-by: Ariel Otilibili ariel.otilibili-anieli@eurecom.fr -- Cc: stable@vger.kernel.org
Why is "removing dead code" a stable kernel thing?
confused,
greg k-h
On Friday, December 20, 2024 08:09 CET, Greg KH gregkh@linuxfoundation.org wrote:
On Thu, Dec 19, 2024 at 11:45:01PM +0100, Ariel Otilibili wrote:
This is a follow up from a discussion in Xen:
The if-statement tests `res` is non-zero; meaning the case zero is never reached.
Link: https://lore.kernel.org/all/7587b503-b2ca-4476-8dc9-e9683d4ca5f0@suse.com/ Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Suggested-by: Jan Beulich jbeulich@suse.com Signed-off-by: Ariel Otilibili ariel.otilibili-anieli@eurecom.fr -- Cc: stable@vger.kernel.org
Why is "removing dead code" a stable kernel thing?
Hello Greg,
It is what I understood from the process:
"Attaching a Fixes: tag does not subvert the stable kernel rules process nor the requirement to Cc: stable@vger.kernel.org on all stable patch candidates." [1]
Does my understanding make sense?
Regards, Ariel
[1] https://docs.kernel.org/process/submitting-patches.html
confused,
greg k-h
On Fri, Dec 20, 2024 at 09:44:31AM +0100, Ariel Otilibili-Anieli wrote:
On Friday, December 20, 2024 08:09 CET, Greg KH gregkh@linuxfoundation.org wrote:
On Thu, Dec 19, 2024 at 11:45:01PM +0100, Ariel Otilibili wrote:
This is a follow up from a discussion in Xen:
The if-statement tests `res` is non-zero; meaning the case zero is never reached.
Link: https://lore.kernel.org/all/7587b503-b2ca-4476-8dc9-e9683d4ca5f0@suse.com/ Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Suggested-by: Jan Beulich jbeulich@suse.com Signed-off-by: Ariel Otilibili ariel.otilibili-anieli@eurecom.fr -- Cc: stable@vger.kernel.org
Why is "removing dead code" a stable kernel thing?
Hello Greg,
It is what I understood from the process:
"Attaching a Fixes: tag does not subvert the stable kernel rules process nor the requirement to Cc: stable@vger.kernel.org on all stable patch candidates." [1]
Does my understanding make sense?
I'm confused, what are you expecting to happen here? Why is this even marked as a "fix"?
Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for the stable kernel rules.
Again, you have a "cc: stable@..." in your patch, why?
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org