Qual é a diferença entre um patch que reverte um commit e um “patch reverso”?

Question

Antes de 6 de maio de 2013 , o arquivo fs/eventpoll.c no kernel do Linux tinha a seguinte linha # 1605 :

if (!schedule_hrtimeout_range(to, slack, HRTIMER_MODE_ABS))

Em 6 de maio , um commit muda isso para (patch):

From 1c441e921201d523b5a6036aea22b0b426bf1af2 Mon Sep 17 00:00:00 2001
From: Colin Cross <[email protected]>
Date: Mon, 06 May 2013 23:50:16 +0000
Subject: epoll: use freezable blocking call

Avoid waking up every thread sleeping in an epoll_wait call during
suspend and resume by calling a freezable blocking call.  Previous
patches modified the freezer to avoid sending wakeups to threads
that are blocked in freezable blocking calls.

This call was selected to be converted to a freezable call because
it doesn't hold any locks or release any resources when interrupted
that might be needed by another freezing task or a kernel driver
during suspend, and is a common site where idle userspace tasks are
blocked.

Acked-by: Tejun Heo <[email protected]>
Signed-off-by: Colin Cross <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
---
(limited to 'fs/eventpoll.c')

diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index deecc72..0cff443 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -34,6 +34,7 @@
 #include <linux/mutex.h>
 #include <linux/anon_inodes.h>
 #include <linux/device.h>
+#include <linux/freezer.h>
 #include <asm/uaccess.h>
 #include <asm/io.h>
 #include <asm/mman.h>
@@ -1602,7 +1603,8 @@ fetch_events:
            }

            spin_unlock_irqrestore(&ep->lock, flags);
-           if (!schedule_hrtimeout_range(to, slack, HRTIMER_MODE_ABS))
+           if (!freezable_schedule_hrtimeout_range(to, slack,
+                               HRTIMER_MODE_ABS))
                timed_out = 1;

            spin_lock_irqsave(&ep->lock, flags);
--
cgit v0.9.2

Então, em 29 de outubro de 2013 , depois de alguns problemas com isso, decidimos reverter" epoll: use chamada de bloqueio freezable " - aqui está o patch:

From c511851de162e8ec03d62e7d7feecbdf590d881d Mon Sep 17 00:00:00 2001
From: Rafael J. Wysocki <[email protected]>
Date: Tue, 29 Oct 2013 12:12:56 +0000
Subject: Revert "epoll: use freezable blocking call"

This reverts commit 1c441e921201 (epoll: use freezable blocking call)
which is reported to cause user space memory corruption to happen
after suspend to RAM.

Since it appears to be extremely difficult to root cause this
problem, it is best to revert the offending commit and try to address
the original issue in a better way later.

References: https://bugzilla.kernel.org/show_bug.cgi?id=61781
Reported-by: Natrio <[email protected]>
Reported-by: Jeff Pohlmeyer <[email protected]>
Bisected-by: Leo Wolf <[email protected]>
Fixes: 1c441e921201 (epoll: use freezable blocking call)
Signed-off-by: Rafael J. Wysocki <[email protected]>
Cc: 3.11+ <[email protected]> # 3.11+
---
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 473e09d..810c28f 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -34,7 +34,6 @@
 #include <linux/mutex.h>
 #include <linux/anon_inodes.h>
 #include <linux/device.h>
-#include <linux/freezer.h>
 #include <asm/uaccess.h>
 #include <asm/io.h>
 #include <asm/mman.h>
@@ -1605,8 +1604,7 @@ fetch_events:
            }

            spin_unlock_irqrestore(&ep->lock, flags);
-           if (!freezable_schedule_hrtimeout_range(to, slack,
-                               HRTIMER_MODE_ABS))
+           if (!schedule_hrtimeout_range(to, slack, HRTIMER_MODE_ABS))
                timed_out = 1;

            spin_lock_irqsave(&ep->lock, flags);
--
cgit v0.9.2

O commit é acompanhado da seguinte descrição:

This reverts commit 1c441e921201 (epoll: use freezable blocking call) which is reported to cause user space memory corruption to happen after suspend to RAM.

Since it appears to be extremely difficult to root cause this problem, it is best to revert the offending commit and try to address the original issue in a better way later.

Perguntas:

1. Este último commit é simplesmente um patch que tem o efeito de reverter um patch anterior OU é um patch invertido?
2. Supondo que este não é um patch invertido, então o que é um patch invertido? Fornecendo exatamente o mesmo commit anterior (maio) e confiando no comportamento do utilitário de patch para sugerir reverter o patch (veja abaixo, e " note para remetentes de patch" na parte inferior do patch manpages)?
3. Estou certo em pensar que, se eu tentar aplicar esse patch mais recente aos meus fontes do kernel e obter o comportamento mostrado abaixo, isso simplesmente significa que o patch já foi aplicado, e posso confirmar isso e, de fato, NÃO tenho referência a freezable ou o congelamento incluem em minhas fontes e essa foi a intenção dos mantenedores do kernel aqui?
4. Estou usando o Gentoo fontes 3.10.25 e o changelog indica: %código%? Exceto por olhar no próprio arquivo .c, como posso saber se esse patch tem já foi aplicado às minhas fontes de distribuição? Posso confiar no versão intro data no changelog de fontes sendo 21 de dezembro e concluir que este patch foi aplicado porque foi adicionado a a árvore do kernel em outubro, que é antes?

Q3:

# patch -p1 < october29.patch
patching file fs/eventpoll.c
Reversed (or previously applied) patch detected!  Assume -R? [n]

Complemento

Um colaborador explicou:

A "reversed patch" is when someone accidentally makes a patch with diff -u foo.c foo.c.orig (where foo.c is the newer file) instead of the correct diff -u foo.c.orig foo.c

Eu estava perguntando isso por causa do que eu encontrei na Nota para patch remetentes no Linux patch 3.10.25 and the date is 21 Dec 2013 manpages:

Take care not to send out reversed patches, since it makes people wonder whether they already applied the patch.

Isto significa que um patch invertido pode ser o resultado de um erro como explicado ou uma "técnica" para reverter uma alteração, mas que não é aconselhável porque cria confusão.

Então, de fato, você pode tentar patch (o erro) aqui:

--- new.c   2014-02-01 21:37:55.616888434 -0500
+++ old.c   2014-02-01 21:37:41.430887944 -0500
@@ -34,6 +34,7 @@
 #include <linux/mutex.h>
 #include <linux/anon_inodes.h>
 #include <linux/device.h>
+#include <linux/freezer.h>
 #include <asm/uaccess.h>
 #include <asm/io.h>
 #include <asm/mman.h>
@@ -1604,7 +1605,8 @@
            }

            spin_unlock_irqrestore(&ep->lock, flags);
-           if (!schedule_hrtimeout_range(to, slack, HRTIMER_MODE_ABS))
+           if (!freezable_schedule_hrtimeout_range(to, slack,
+                               HRTIMER_MODE_ABS))
                timed_out = 1;

            spin_lock_irqsave(&ep->lock, flags);

... e este é o commit original de 6 de maio . Então, um patch reverso está em efeito como enviar o patch original que acionaria o comportamento de reversão no utilitário diff -u new.c old.c desde que o patch já estivesse aplicado, rolando de volta para um estado quando o patch inicial não era aplicado.

Por fim, não há dúvidas de que o patch foi aplicado às minhas fontes. Este é o arquivo patch mais recente na árvore do kernel do git. Não contém referências a 'freezable'. Minhas fontes também não. E tentar aplicar o patch aciona a mensagem de patch aplicada anteriormente. Em dúvida, olhe o código mais recente na árvore (e git logs se você tiver um clone do repositório) e compare com o que você tem em suas fontes de distribuição.

    

Answer 1

É um patch que desfaz o patch anterior. Pode ser feito com patch -R -pX bad.patch (onde X é o número de níveis de diretório para remover do patch e bad.patch é o patch que queremos desfazer) seguido por um git commit

Um "patch invertido" é quando alguém acidentalmente faz um patch com diff -u foo.c foo.c.orig (onde foo.c é o arquivo mais recente) em vez do diff -u foo.c.orig foo.c correto

O erro "correção aplicada reversa ou anterior" indica que o patch já foi aplicado. Eu não posso ser mais específico sem conhecer o conteúdo do seu arquivo kernelsuspend.patch .

Se você tiver o diretório .git para a origem do kernel, você pode verificar o log de um único arquivo com o comando git log seguido do nome do arquivo. por exemplo. git log fs/eventpoll.c ou até git log -p fs/eventpoll.c .

    

Answer 2

Patches revertidos

Na página do manual git-revert :

Given one or more existing commits, revert the changes that the related patches introduce, and record some new commits that record them. This requires your working tree to be clean (no modifications from the HEAD commit).

Note: git revert is used to record some new commits to reverse the effect of some earlier commits (often only a faulty one). If you want to throw away all uncommitted changes in your working directory, you should see git-reset(1), particularly the --hard option. If you want to extract specific files as they were in another commit, you should see git-checkout(1), specifically the git checkout -- syntax. Take care with these alternatives as both will discard uncommitted changes in your working directory.

Patches Invertidos

A partir desta página do Drupal intitulada: Invertendo os patches :

You can reverse a patch if you have finished testing it, or if you want to see whether a problem has been introduced by a particular patch. You should also reverse a patch prior to adding a newer, updated version of the same patch. To reverse the patch, use the patch command with the -R option:

   patch -p1 -R < path/file.patch

(If your patch was applied with the -p0 option, use that instead.)

Or:

   git apply -R path/file.patch