r3036 - trunk/kernel/source/kernel-source-2.6.11-2.6.11/debian/patches

Simon Horman horms@costa.debian.org
Wed, 11 May 2005 07:36:44 +0000


Author: horms
Date: 2005-05-11 07:36:44 +0000 (Wed, 11 May 2005)
New Revision: 3036

Added:
   trunk/kernel/source/kernel-source-2.6.11-2.6.11/debian/patches/sparc64-sigpoll-2.6.11.patch
Removed:
   trunk/kernel/source/kernel-source-2.6.11-2.6.11/debian/patches/sparc64-sigpoll-2.6.11.patch
Log:
sync

Deleted: trunk/kernel/source/kernel-source-2.6.11-2.6.11/debian/patches/sparc64-sigpoll-2.6.11.patch
===================================================================
--- trunk/kernel/source/kernel-source-2.6.11-2.6.11/debian/patches/sparc64-sigpoll-2.6.11.patch	2005-05-11 07:31:27 UTC (rev 3035)
+++ trunk/kernel/source/kernel-source-2.6.11-2.6.11/debian/patches/sparc64-sigpoll-2.6.11.patch	2005-05-11 07:36:44 UTC (rev 3036)
@@ -1,35 +0,0 @@
-#> In Debian's bug 272683 [0] submitter describes incorrect behavior of the 
-#> F_NOTIFY function of fcntl(), which reports the wrong number of the 
-#> file descriptor, on which the event has occured. I believe that the 
-#> culprit in this case is the copy_siginfo_to_user32() function in 
-#> arch/sparc64/kernel/signal32.c. Comparison with other arches (like
-#> ppc64), shows that the __SI_POLL branch in the case statement should 
-#> fill out the si_band and si_fd fields of the siginfo_t structure (si_fd is 
-#> used by fcntl() to pass the fd number back to user). Currently it does not 
-#> do that. Attached patch (against 2.6.11.7) separates __SI_FAULT and 
-#> __SI_POLL branches and does (presumably) the right thing in the latter by 
-#> copying the si_band and si_fd into the siginfo_t passed to user. With this 
-#> change the test program attached to the bug [0] works as expected (tested 
-#> on 2.6.8, against which the original bug was filed).
-#
-# Refs: http://marc.theaimsgroup.com/?l=linux-sparc&m=111363552425781&w=2
-#       http://marc.theaimsgroup.com/?l=linux-sparc&m=111377422704236&w=2
-#
-# -- Jurij Smakov <jurij@wooyd.org>  Sun, 17 Apr 2005 19:12:11 -0400
---- a/arch/sparc64/kernel/signal32.c	2005-04-07 14:58:42.000000000 -0400
-+++ b/arch/sparc64/kernel/signal32.c	2005-04-16 03:01:00.162300632 -0400
-@@ -192,10 +192,13 @@
- 			err |= __put_user(from->si_uid, &to->si_uid);
- 			break;
- 		case __SI_FAULT >> 16:
--		case __SI_POLL >> 16:
- 			err |= __put_user(from->si_trapno, &to->si_trapno);
- 			err |= __put_user((unsigned long)from->si_addr, &to->si_addr);
- 			break;
-+		case __SI_POLL >> 16:
-+			err |= __put_user(from->si_band, &to->si_band);
-+			err |= __put_user(from->si_fd, &to->si_fd);
-+			break;
- 		case __SI_RT >> 16: /* This is not generated by the kernel as of now.  */
- 		case __SI_MESGQ >> 16:
- 			err |= __put_user(from->si_pid, &to->si_pid);

Added: trunk/kernel/source/kernel-source-2.6.11-2.6.11/debian/patches/sparc64-sigpoll-2.6.11.patch
===================================================================
--- trunk/kernel/source/kernel-source-2.6.11-2.6.11/debian/patches/sparc64-sigpoll-2.6.11.patch	2005-05-11 07:31:27 UTC (rev 3035)
+++ trunk/kernel/source/kernel-source-2.6.11-2.6.11/debian/patches/sparc64-sigpoll-2.6.11.patch	2005-05-11 07:36:44 UTC (rev 3036)
@@ -0,0 +1,35 @@
+#> In Debian's bug 272683 [0] submitter describes incorrect behavior of the 
+#> F_NOTIFY function of fcntl(), which reports the wrong number of the 
+#> file descriptor, on which the event has occured. I believe that the 
+#> culprit in this case is the copy_siginfo_to_user32() function in 
+#> arch/sparc64/kernel/signal32.c. Comparison with other arches (like
+#> ppc64), shows that the __SI_POLL branch in the case statement should 
+#> fill out the si_band and si_fd fields of the siginfo_t structure (si_fd is 
+#> used by fcntl() to pass the fd number back to user). Currently it does not 
+#> do that. Attached patch (against 2.6.11.7) separates __SI_FAULT and 
+#> __SI_POLL branches and does (presumably) the right thing in the latter by 
+#> copying the si_band and si_fd into the siginfo_t passed to user. With this 
+#> change the test program attached to the bug [0] works as expected (tested 
+#> on 2.6.8, against which the original bug was filed).
+#
+# Refs: http://marc.theaimsgroup.com/?l=linux-sparc&m=111363552425781&w=2
+#       http://marc.theaimsgroup.com/?l=linux-sparc&m=111377422704236&w=2
+#
+# -- Jurij Smakov <jurij@wooyd.org>  Sun, 17 Apr 2005 19:12:11 -0400
+--- a/arch/sparc64/kernel/signal32.c	2005-04-07 14:58:42.000000000 -0400
++++ b/arch/sparc64/kernel/signal32.c	2005-04-16 03:01:00.162300632 -0400
+@@ -192,10 +192,13 @@
+ 			err |= __put_user(from->si_uid, &to->si_uid);
+ 			break;
+ 		case __SI_FAULT >> 16:
+-		case __SI_POLL >> 16:
+ 			err |= __put_user(from->si_trapno, &to->si_trapno);
+ 			err |= __put_user((unsigned long)from->si_addr, &to->si_addr);
+ 			break;
++		case __SI_POLL >> 16:
++			err |= __put_user(from->si_band, &to->si_band);
++			err |= __put_user(from->si_fd, &to->si_fd);
++			break;
+ 		case __SI_RT >> 16: /* This is not generated by the kernel as of now.  */
+ 		case __SI_MESGQ >> 16:
+ 			err |= __put_user(from->si_pid, &to->si_pid);