Hi.

FWIW, the message sent only to the maintainer and [EMAIL PROTECTED] contains 
some elements relating to the patch which may be masked while looking at the 
BTS on the Web.

Here's original message from Jan Niehusmann :

----- Forwarded message from Jan Niehusmann <[EMAIL PROTECTED]> -----

X-Spam-Checker-Version: SpamAssassin 3.1.4-bugs.debian.org_2005_01_02 
        (2006-07-26) on rietz.debian.org
X-Spam-Level: 
X-Spam-Status: No, score=-6.0 required=4.0 tests=BAYES_00,FROMDEVELOPER,
        IMPRONONCABLE_2,MURPHY_DRUGS_REL8,VALID_BTS_CONTROL autolearn=no 
        version=3.1.4-bugs.debian.org_2005_01_02
From: Jan Niehusmann <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: reopen Bug#449053

reopen 449053
thanks

Hi Bastian,

On Sat, Nov 03, 2007 at 10:43:41AM +0100, Jan Niehusmann wrote:
> On Fri, Nov 02, 2007 at 10:45:03PM +0000, Debian Bug Tracking System wrote:
> > This bug is fixed in the version mentioned above.
> > 
> > > EIP:    0060:[<c0138a6d>]    Not tainted VLI
> > > EFLAGS: 00210046   (2.6.22-2-vserver-686 #1)
> > 
> > This is the wrong version.
> 
> Oops, sorry, indeed I did update between reproducing the bug and
> sending the report. But I didn't find the mentioned patch in the source
> of -3, and no related changelog entry, so I assumed it was not fixed.

I checked the source package again, and in fact it does not contain the
mentioned fix. It does contain a patch called vs2.2.0.4.patch. But if I
download 
http://ftp.linux-vserver.org/pub/kernel/vs2.2/patch-2.6.21.7-vs2.2.0.4.diff
and compare both patches, I find the following difference (besides
version numbers, file dates and other unrelated stuff):

This is from the debian package:

diff -NurpP --minimal linux-2.6.22.9/kernel/posix-timers.c 
linux-2.6.22.9-vs2.2.0.4/kernel/posix-timers.c
--- linux-2.6.22.9/kernel/posix-timers.c        2007-07-09 13:20:03 +0200
+++ linux-2.6.22.9-vs2.2.0.4/kernel/posix-timers.c      2007-07-07 03:52:54 
+0200
@@ -297,6 +298,10 @@ void do_schedule_next_timer(struct sigin
 
 int posix_timer_event(struct k_itimer *timr,int si_private)
 {
+       struct vx_info_save vxis;
+       int ret;
+
+       enter_vx_info(task_get_vx_info(timr->it_process), &vxis);
        memset(&timr->sigq->info, 0, sizeof(siginfo_t));
        timr->sigq->info.si_sys_private = si_private;
        /* Send signal to the process that owns this timer.*/
@@ -321,8 +326,12 @@ int posix_timer_event(struct k_itimer *t
                timr->it_process = leader;
        }
 
-       return send_group_sigqueue(timr->it_sigev_signo, timr->sigq,
+       ret = send_group_sigqueue(timr->it_sigev_signo, timr->sigq,
                                   timr->it_process);
+out:
+       leave_vx_info(&vxis);
+       put_vx_info(vxis.vxi);
+       return ret;
 }
 EXPORT_SYMBOL_GPL(posix_timer_event);
 

And this is from the upstream patch:

diff -NurpP --minimal linux-2.6.21.7/kernel/posix-timers.c 
linux-2.6.21.7-vs2.2.0.4/kernel/posix-timers.c
--- linux-2.6.21.7/kernel/posix-timers.c        2007-10-01 17:03:05 +0200
+++ linux-2.6.21.7-vs2.2.0.4/kernel/posix-timers.c      2007-10-01 15:52:41 
+0200
@@ -298,6 +299,12 @@ void do_schedule_next_timer(struct sigin
 
 int posix_timer_event(struct k_itimer *timr,int si_private)
 {
+       struct vx_info_save vxis;
+       struct vx_info *vxi;
+       int ret;
+
+       vxi = task_get_vx_info(timr->it_process);
+       enter_vx_info(vxi, &vxis);
        memset(&timr->sigq->info, 0, sizeof(siginfo_t));
        timr->sigq->info.si_sys_private = si_private;
        /* Send signal to the process that owns this timer.*/
@@ -322,8 +329,12 @@ int posix_timer_event(struct k_itimer *t
                timr->it_process = leader;
        }
 
-       return send_group_sigqueue(timr->it_sigev_signo, timr->sigq,
+       ret = send_group_sigqueue(timr->it_sigev_signo, timr->sigq,
                                   timr->it_process);
+out:
+       leave_vx_info(&vxis);
+       put_vx_info(vxi);
+       return ret;
 }
 EXPORT_SYMBOL_GPL(posix_timer_event);


I think this difference is the cause for the panic I observed.  Please
note that vs2.2.0.3 and the debian version of vs2.2.0.4 are identical in
this regard, the difference is between the debian version of vs2.2.0.4
and the upstream version of vs2.2.0.4.

The confusion is probably caused by the fact that upstream did modify
the patch after release, without changing the version number. At least
this is what I get from the upstream changelog:

| ADDENDUM: The patch was re-released on 11 Oct 2007, which also included:
|
|    * fix reference counting of vxi's in POSIX timer code 

Which, once again, proves that changing a release without changing the
version number is bad practice :-(

Regards,
Jan





----- End forwarded message -----



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to