¿Cuál es la diferencia entre un parche que revierte un compromiso y un "parche invertido"?

Antes del 6 de mayo de 2013 , el file fs/eventpoll.c en el kernel de Linux tenía la siguiente línea # 1605 :

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

El 6 de mayo , una confirmación cambia esto a (parche):

 From 1c441e921201d523b5a6036aea22b0b426bf1af2 Mon Sep 17 00:00:00 2001 From: Colin Cross <ccross@android.com> 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 <tj@kernel.org> Signed-off-by: Colin Cross <ccross@android.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> --- (limited to 'fs/eventpoll.c') diff --git a/fs/eventpoll.cb/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_irqrestre(&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 

Luego, el 29 de octubre de 2013 , después de algunos problemas con eso, se decidió revertir "epoll: use la llamada de locking freezable" – aquí está el parche:

 From c511851de162e8ec03d62e7d7feecbdf590d881d Mon Sep 17 00:00:00 2001 From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 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 <natrio@list.ru> Reported-by: Jeff Pohlmeyer <yetanothergeek@gmail.com> Bisected-by: Leo Wolf <jclw@ymail.com> Fixes: 1c441e921201 (epoll: use freezable blocking call) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: 3.11+ <stable@vger.kernel.org> # 3.11+ --- diff --git a/fs/eventpoll.cb/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_irqrestre(&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 

El compromiso viene acompañado de la siguiente descripción:

Esto revierte commit 1c441e921201 (epoll: usa la llamada de locking freezable) que se informa que causa daños en la memory del espacio del usuario después de suspender a la RAM.

Dado que parece ser extremadamente difícil de enraizar causar este problema, es mejor revertir el compromiso ofensivo y tratar de abordar el problema original de una mejor manera más adelante.

Preguntas:

  1. ¿Es este último compromiso simplemente un parche que tiene el efecto de revertir un parche anterior O es un parche invertido?
  2. Suponiendo que esto no fuera un parche invertido, entonces, ¿qué es un parche invertido? Suministrar el mismo compromiso previo exacto (mayo) y confiar en el comportamiento de utilidad del parche para sugerir la reversión del parche (consulte a continuación y " nota para remitentes de parche" en la parte inferior de las páginas de manual del patch ).
  3. Estoy en lo cierto al pensar que si trato de aplicar este último parche a mis fonts de kernel, y obtengo el comportamiento que se muestra a continuación, eso simplemente significa que el parche ya está aplicado, y puedo confirmarlo y, de hecho, NO tengo ninguna reference a freezable o congelar include en mis fonts y esa era la intención de los mantenedores de kernel aquí?
  4. Estoy usando las fonts de Gentoo 3.10.25 y el logging de cambios indica: el Linux patch 3.10.25 and the date is 21 Dec 2013 . Excepto mirando el file .c modificado, ¿cómo puedo saber si este parche ya se ha aplicado a mis fonts de distribución? ¿Puedo confiar en la date de introducción de la versión en el logging de cambios de las fonts el 21 de diciembre y concluir que este parche se ha aplicado porque se agregó al tree kernel en octubre, que está antes?

Q3:

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

Complemento

Un queueborador explicó:

Un "parche invertido" es cuando alguien accidentalmente hace un parche con diff -u foo.c foo.c.orig (donde foo.c es el file más nuevo) en lugar del diff correcto -u foo.c.orig foo.c

Estaba preguntando esto por lo que encontré en la Nota para aplicar parches a los remitentes en las páginas de manual de patch :

Tenga cuidado de no enviar parches revertidos, ya que hace que las personas se pregunten si ya aplicaron el parche.

Esto significa que un parche invertido puede ser el resultado de un error como el explicado o una "técnica" para revertir un cambio, pero que no es aconsejable porque crea confusión.

De hecho, puedes probar diff -u new.c old.c (el error) aquí:

 --- 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_irqrestre(&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); 

… y este es el compromiso original del 6 de mayo . Por lo tanto, un parche invertido está en efecto como enviar el parche original que desencadenaría el comportamiento de reversión en la utilidad de patch siempre que el parche ya esté aplicado, volviendo efectivamente a un estado cuando no se aplicó el parche inicial.

En última instancia, no puede haber ninguna duda de que el parche se ha aplicado a mis fonts. Este es el último file eventpoll.c en el tree del kernel git. No contiene ninguna reference a 'freezable'. Mis fonts tampoco. Y al tratar de aplicar el parche, se activa el post de parche aplicado anteriormente. En caso de duda, observe el código más reciente en el tree (y git logs si tiene un clon del repository) y compárelo con lo que tiene en sus fonts de distribución.

Es un parche que deshace el parche anterior. Se puede hacer con patch -R -pX bad.patch (donde X es el número de niveles de directory para eliminar del parche y bad.patch es el parche que queremos deshacer) seguido de un git commit

Un "parche invertido" es cuando alguien accidentalmente hace un parche con diff -u foo.c foo.c.orig (donde foo.c es el file más nuevo) en lugar del diff -u foo.c.orig foo.c correcto diff -u foo.c.orig foo.c

El error "parche aplicado invertido o anterior" indica que el parche ya se ha aplicado. No puedo ser más específico sin conocer el contenido de tu file kernelsuspend.patch .

Si tiene el directory .git para el origen del kernel, puede consultar el logging de un solo file con el command git log seguido del nombre del file. por ejemplo, git log fs/eventpoll.c o incluso git log -p fs/eventpoll.c .

Parches revertidos

De la página man de git-revert :

Dado uno o más commits existentes, revertir los cambios que los parches relacionados introducen, y registrar algunos commits nuevos que los graban. Esto requiere que su tree de trabajo esté limpio (sin modificaciones desde el compromiso HEAD).

Nota: git revert se usa para registrar algunos commits nuevos para revertir el efecto de algunos commits anteriores (a menudo solo uno defectuoso). Si desea descartar todos los cambios no confirmados en su directory de trabajo, debería ver git-reset (1), particularmente la opción hard. Si desea extraer files específicos tal como estaban en otra confirmación, debería ver git-checkout (1), específicamente la extracción de git – syntax. Tenga cuidado con estas alternativas, ya que ambas descartarán los cambios no confirmados en su directory de trabajo.

Parches revertidos

De esta página de Drupal titulada: Parches de inversión :

Puede revertir un parche si ha terminado de probarlo, o si desea ver si un problema ha sido introducido por un parche en particular. También debe invertir un parche antes de agregar una versión más nueva y actualizada del mismo parche. Para invertir el parche, use el command de parche con la opción -R:

  patch -p1 -R < path/file.patch 

(Si su parche se aplicó con la opción -p0, utilícelo en su lugar).

O:

  git apply -R path/file.patch