Bug#412132: marked as done (cacct interface misscalced about 100 TB)

2007-08-15 Thread Debian Bug Tracking System
Your message dated Wed, 15 Aug 2007 22:37:44 +
with message-id [EMAIL PROTECTED]
and subject line Bug#412132: fixed in linux-2.6 2.6.18.dfsg.1-13
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

---BeginMessage---

Package: linux-image-2.6.18-4-vserver-amd64
Version: 2.6.18.dfsg.1-9
Severity: serious

Hello,

I think I've found a serious bug in the vserver image for amd64.
We're running a daemon, which is logging the traffic of all 
hostmachines. Now I've found a very big mistake in the 
/proc/virtual/id/cacct interface.


The daemon gets the informations of this cacct interface and will calc 
the caused traffic, here's the debug of my daemon:


|Fri Feb 23 15:42:01 2007 - cacct: 1472700147 o.cacct 1472517504 logged: 1495189052 now: 1495371695 method: 1 


Fri Feb 23 16:00:01 2007 - cacct: 18446744072641133818 o.cacct 3222831651 
logged: 3178567909 now: 18446744072596870076 method: 1

|The cacct variable is the value of all incoming / outcoming IPv4 and 
IPv6 traffic in bytes.
This debug would mean, that one customer has caused traffic more as 100 
TB in 20 minutes ( and that only with one ventrilo server! ).
First I thought, it's a bug in my daemon software, but that wasn't the 
problem, how this information will show:


|hostname:~/control# cat /proc/virtual/2/cacct
UNSPEC:0/0 0/0 0/0 

UNIX: 305586/28642976 267311/28642976  1/30 

INET:9058790/1149688302  9889025/18446744071736090069  47323/18446744072430740975 

INET6: 0/0 0/0 0/0 

OTHER: 0/0 0/0 0/0 


forks:  0|
|
|It seems as the kernel misscalced or overflowed after a cacct value 
over |1472700147.


It's the first and only example of this bug, because this is the first 
customer, with such a lot traffic.


Regards,
Patrick Matthäi
|

---End Message---
---BeginMessage---
Source: linux-2.6
Source-Version: 2.6.18.dfsg.1-13

We believe that the bug you reported is fixed in the latest version of
linux-2.6, which is due to be installed in the Debian FTP archive:

linux-2.6_2.6.18.dfsg.1-13.diff.gz
  to pool/main/l/linux-2.6/linux-2.6_2.6.18.dfsg.1-13.diff.gz
linux-2.6_2.6.18.dfsg.1-13.dsc
  to pool/main/l/linux-2.6/linux-2.6_2.6.18.dfsg.1-13.dsc
linux-doc-2.6.18_2.6.18.dfsg.1-13_all.deb
  to pool/main/l/linux-2.6/linux-doc-2.6.18_2.6.18.dfsg.1-13_all.deb
linux-headers-2.6.18-5-all-sparc_2.6.18.dfsg.1-13_sparc.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-5-all-sparc_2.6.18.dfsg.1-13_sparc.deb
linux-headers-2.6.18-5-all_2.6.18.dfsg.1-13_sparc.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.18-5-all_2.6.18.dfsg.1-13_sparc.deb
linux-headers-2.6.18-5-sparc32_2.6.18.dfsg.1-13_sparc.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-5-sparc32_2.6.18.dfsg.1-13_sparc.deb
linux-headers-2.6.18-5-sparc64-smp_2.6.18.dfsg.1-13_sparc.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-5-sparc64-smp_2.6.18.dfsg.1-13_sparc.deb
linux-headers-2.6.18-5-sparc64_2.6.18.dfsg.1-13_sparc.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-5-sparc64_2.6.18.dfsg.1-13_sparc.deb
linux-headers-2.6.18-5-vserver-sparc64_2.6.18.dfsg.1-13_sparc.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-5-vserver-sparc64_2.6.18.dfsg.1-13_sparc.deb
linux-headers-2.6.18-5-vserver_2.6.18.dfsg.1-13_sparc.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-5-vserver_2.6.18.dfsg.1-13_sparc.deb
linux-headers-2.6.18-5_2.6.18.dfsg.1-13_sparc.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.18-5_2.6.18.dfsg.1-13_sparc.deb
linux-image-2.6.18-5-sparc32_2.6.18.dfsg.1-13_sparc.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6.18-5-sparc32_2.6.18.dfsg.1-13_sparc.deb
linux-image-2.6.18-5-sparc64-smp_2.6.18.dfsg.1-13_sparc.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6.18-5-sparc64-smp_2.6.18.dfsg.1-13_sparc.deb
linux-image-2.6.18-5-sparc64_2.6.18.dfsg.1-13_sparc.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6.18-5-sparc64_2.6.18.dfsg.1-13_sparc.deb
linux-image-2.6.18-5-vserver-sparc64_2.6.18.dfsg.1-13_sparc.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6.18-5-vserver-sparc64_2.6.18.dfsg.1-13_sparc.deb
linux-manual-2.6.18_2.6.18.dfsg.1-13_all.deb
  to pool/main/l/linux-2.6/linux-manual-2.6.18_2.6.18.dfsg.1-13_all.deb
linux-patch-debian-2.6.18_2.6.18.dfsg.1-13_all.deb
  to pool/main/l/linux-2.6/linux-patch-debian-2.6.18_2.6.18.dfsg.1-13_all.deb
linux-source

Bug#412132: marked as done (cacct interface misscalced about 100 TB)

2007-05-24 Thread Debian Bug Tracking System
Your message dated Thu, 24 May 2007 21:16:51 +
with message-id [EMAIL PROTECTED]
and subject line Bug#412132: fixed in linux-2.6 2.6.18.dfsg.1-13
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

---BeginMessage---

Package: linux-image-2.6.18-4-vserver-amd64
Version: 2.6.18.dfsg.1-9
Severity: serious

Hello,

I think I've found a serious bug in the vserver image for amd64.
We're running a daemon, which is logging the traffic of all 
hostmachines. Now I've found a very big mistake in the 
/proc/virtual/id/cacct interface.


The daemon gets the informations of this cacct interface and will calc 
the caused traffic, here's the debug of my daemon:


|Fri Feb 23 15:42:01 2007 - cacct: 1472700147 o.cacct 1472517504 logged: 1495189052 now: 1495371695 method: 1 


Fri Feb 23 16:00:01 2007 - cacct: 18446744072641133818 o.cacct 3222831651 
logged: 3178567909 now: 18446744072596870076 method: 1

|The cacct variable is the value of all incoming / outcoming IPv4 and 
IPv6 traffic in bytes.
This debug would mean, that one customer has caused traffic more as 100 
TB in 20 minutes ( and that only with one ventrilo server! ).
First I thought, it's a bug in my daemon software, but that wasn't the 
problem, how this information will show:


|hostname:~/control# cat /proc/virtual/2/cacct
UNSPEC:0/0 0/0 0/0 

UNIX: 305586/28642976 267311/28642976  1/30 

INET:9058790/1149688302  9889025/18446744071736090069  47323/18446744072430740975 

INET6: 0/0 0/0 0/0 

OTHER: 0/0 0/0 0/0 


forks:  0|
|
|It seems as the kernel misscalced or overflowed after a cacct value 
over |1472700147.


It's the first and only example of this bug, because this is the first 
customer, with such a lot traffic.


Regards,
Patrick Matthäi
|

---End Message---
---BeginMessage---
Source: linux-2.6
Source-Version: 2.6.18.dfsg.1-13

We believe that the bug you reported is fixed in the latest version of
linux-2.6, which is due to be installed in the Debian FTP archive:

linux-2.6_2.6.18.dfsg.1-13.diff.gz
  to pool/main/l/linux-2.6/linux-2.6_2.6.18.dfsg.1-13.diff.gz
linux-2.6_2.6.18.dfsg.1-13.dsc
  to pool/main/l/linux-2.6/linux-2.6_2.6.18.dfsg.1-13.dsc
linux-doc-2.6.18_2.6.18.dfsg.1-13_all.deb
  to pool/main/l/linux-2.6/linux-doc-2.6.18_2.6.18.dfsg.1-13_all.deb
linux-headers-2.6.18-5-all-sparc_2.6.18.dfsg.1-13_sparc.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-5-all-sparc_2.6.18.dfsg.1-13_sparc.deb
linux-headers-2.6.18-5-all_2.6.18.dfsg.1-13_sparc.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.18-5-all_2.6.18.dfsg.1-13_sparc.deb
linux-headers-2.6.18-5-sparc32_2.6.18.dfsg.1-13_sparc.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-5-sparc32_2.6.18.dfsg.1-13_sparc.deb
linux-headers-2.6.18-5-sparc64-smp_2.6.18.dfsg.1-13_sparc.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-5-sparc64-smp_2.6.18.dfsg.1-13_sparc.deb
linux-headers-2.6.18-5-sparc64_2.6.18.dfsg.1-13_sparc.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-5-sparc64_2.6.18.dfsg.1-13_sparc.deb
linux-headers-2.6.18-5-vserver-sparc64_2.6.18.dfsg.1-13_sparc.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-5-vserver-sparc64_2.6.18.dfsg.1-13_sparc.deb
linux-headers-2.6.18-5-vserver_2.6.18.dfsg.1-13_sparc.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-5-vserver_2.6.18.dfsg.1-13_sparc.deb
linux-headers-2.6.18-5_2.6.18.dfsg.1-13_sparc.deb
  to pool/main/l/linux-2.6/linux-headers-2.6.18-5_2.6.18.dfsg.1-13_sparc.deb
linux-image-2.6.18-5-sparc32_2.6.18.dfsg.1-13_sparc.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6.18-5-sparc32_2.6.18.dfsg.1-13_sparc.deb
linux-image-2.6.18-5-sparc64-smp_2.6.18.dfsg.1-13_sparc.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6.18-5-sparc64-smp_2.6.18.dfsg.1-13_sparc.deb
linux-image-2.6.18-5-sparc64_2.6.18.dfsg.1-13_sparc.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6.18-5-sparc64_2.6.18.dfsg.1-13_sparc.deb
linux-image-2.6.18-5-vserver-sparc64_2.6.18.dfsg.1-13_sparc.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6.18-5-vserver-sparc64_2.6.18.dfsg.1-13_sparc.deb
linux-manual-2.6.18_2.6.18.dfsg.1-13_all.deb
  to pool/main/l/linux-2.6/linux-manual-2.6.18_2.6.18.dfsg.1-13_all.deb
linux-patch-debian-2.6.18_2.6.18.dfsg.1-13_all.deb
  to pool/main/l/linux-2.6/linux-patch-debian-2.6.18_2.6.18.dfsg.1-13_all.deb
linux-source

Bug#412132: marked as done (cacct interface misscalced about 100 TB)

2007-05-24 Thread Debian Bug Tracking System
Your message dated Thu, 24 May 2007 21:27:01 +
with message-id [EMAIL PROTECTED]
and subject line Bug#412132: fixed in linux-2.6 2.6.18.dfsg.1-13lenny1
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

---BeginMessage---

Package: linux-image-2.6.18-4-vserver-amd64
Version: 2.6.18.dfsg.1-9
Severity: serious

Hello,

I think I've found a serious bug in the vserver image for amd64.
We're running a daemon, which is logging the traffic of all 
hostmachines. Now I've found a very big mistake in the 
/proc/virtual/id/cacct interface.


The daemon gets the informations of this cacct interface and will calc 
the caused traffic, here's the debug of my daemon:


|Fri Feb 23 15:42:01 2007 - cacct: 1472700147 o.cacct 1472517504 logged: 1495189052 now: 1495371695 method: 1 


Fri Feb 23 16:00:01 2007 - cacct: 18446744072641133818 o.cacct 3222831651 
logged: 3178567909 now: 18446744072596870076 method: 1

|The cacct variable is the value of all incoming / outcoming IPv4 and 
IPv6 traffic in bytes.
This debug would mean, that one customer has caused traffic more as 100 
TB in 20 minutes ( and that only with one ventrilo server! ).
First I thought, it's a bug in my daemon software, but that wasn't the 
problem, how this information will show:


|hostname:~/control# cat /proc/virtual/2/cacct
UNSPEC:0/0 0/0 0/0 

UNIX: 305586/28642976 267311/28642976  1/30 

INET:9058790/1149688302  9889025/18446744071736090069  47323/18446744072430740975 

INET6: 0/0 0/0 0/0 

OTHER: 0/0 0/0 0/0 


forks:  0|
|
|It seems as the kernel misscalced or overflowed after a cacct value 
over |1472700147.


It's the first and only example of this bug, because this is the first 
customer, with such a lot traffic.


Regards,
Patrick Matthäi
|

---End Message---
---BeginMessage---
Source: linux-2.6
Source-Version: 2.6.18.dfsg.1-13lenny1

We believe that the bug you reported is fixed in the latest version of
linux-2.6, which is due to be installed in the Debian FTP archive:

linux-2.6_2.6.18.dfsg.1-13lenny1.diff.gz
  to pool/main/l/linux-2.6/linux-2.6_2.6.18.dfsg.1-13lenny1.diff.gz
linux-2.6_2.6.18.dfsg.1-13lenny1.dsc
  to pool/main/l/linux-2.6/linux-2.6_2.6.18.dfsg.1-13lenny1.dsc
linux-doc-2.6.18_2.6.18.dfsg.1-13lenny1_all.deb
  to pool/main/l/linux-2.6/linux-doc-2.6.18_2.6.18.dfsg.1-13lenny1_all.deb
linux-headers-2.6.18-5-all-sparc_2.6.18.dfsg.1-13lenny1_sparc.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-5-all-sparc_2.6.18.dfsg.1-13lenny1_sparc.deb
linux-headers-2.6.18-5-all_2.6.18.dfsg.1-13lenny1_sparc.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-5-all_2.6.18.dfsg.1-13lenny1_sparc.deb
linux-headers-2.6.18-5-sparc32_2.6.18.dfsg.1-13lenny1_sparc.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-5-sparc32_2.6.18.dfsg.1-13lenny1_sparc.deb
linux-headers-2.6.18-5-sparc64-smp_2.6.18.dfsg.1-13lenny1_sparc.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-5-sparc64-smp_2.6.18.dfsg.1-13lenny1_sparc.deb
linux-headers-2.6.18-5-sparc64_2.6.18.dfsg.1-13lenny1_sparc.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-5-sparc64_2.6.18.dfsg.1-13lenny1_sparc.deb
linux-headers-2.6.18-5-vserver-sparc64_2.6.18.dfsg.1-13lenny1_sparc.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-5-vserver-sparc64_2.6.18.dfsg.1-13lenny1_sparc.deb
linux-headers-2.6.18-5-vserver_2.6.18.dfsg.1-13lenny1_sparc.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-5-vserver_2.6.18.dfsg.1-13lenny1_sparc.deb
linux-headers-2.6.18-5_2.6.18.dfsg.1-13lenny1_sparc.deb
  to 
pool/main/l/linux-2.6/linux-headers-2.6.18-5_2.6.18.dfsg.1-13lenny1_sparc.deb
linux-image-2.6.18-5-sparc32_2.6.18.dfsg.1-13lenny1_sparc.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6.18-5-sparc32_2.6.18.dfsg.1-13lenny1_sparc.deb
linux-image-2.6.18-5-sparc64-smp_2.6.18.dfsg.1-13lenny1_sparc.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6.18-5-sparc64-smp_2.6.18.dfsg.1-13lenny1_sparc.deb
linux-image-2.6.18-5-sparc64_2.6.18.dfsg.1-13lenny1_sparc.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6.18-5-sparc64_2.6.18.dfsg.1-13lenny1_sparc.deb
linux-image-2.6.18-5-vserver-sparc64_2.6.18.dfsg.1-13lenny1_sparc.deb
  to 
pool/main/l/linux-2.6/linux-image-2.6.18-5-vserver-sparc64_2.6.18.dfsg.1-13lenny1_sparc.deb
linux-manual-2.6.18_2.6.18.dfsg.1-13lenny1_all.deb
  to pool/main/l/linux

Bug#412132:

2007-05-13 Thread Patrick Matthäi

Hi,

could anyone tell me the status of this bug?

Regards,
   Patrick Matthäi



Bug#412132: abi bump

2007-03-24 Thread dann frazier
Saw this on IRC  wanted to record it...

waldi dannf: can you please take a look at #412143?
waldi hrm, I can't fix #412132 without abi bump
waldi someone defined atomic_t as signed
vorlon r1, then?
waldi yes

-- 
dann frazier



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



Bug#412132:

2007-03-19 Thread Patrick Matthäi

Hi,

I'm sorry but when will the update with the fix available (ca ~).

Regards,
Patrick Matthäi



Bug#412132:

2007-03-19 Thread dann frazier
On Mon, Mar 19, 2007 at 07:03:35PM +0100, Patrick Matth??i wrote:
 Hi,
 
 I'm sorry but when will the update with the fix available (ca ~).

Its too early to say.

-- 
dann frazier



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



Bug#412132: cacct interface misscalced about 100 TB

2007-02-23 Thread Patrick Matthäi

Package: linux-image-2.6.18-4-vserver-amd64
Version: 2.6.18.dfsg.1-9
Severity: serious

Hello,

I think I've found a serious bug in the vserver image for amd64.
We're running a daemon, which is logging the traffic of all 
hostmachines. Now I've found a very big mistake in the 
/proc/virtual/id/cacct interface.


The daemon gets the informations of this cacct interface and will calc 
the caused traffic, here's the debug of my daemon:


|Fri Feb 23 15:42:01 2007 - cacct: 1472700147 o.cacct 1472517504 logged: 1495189052 now: 1495371695 method: 1 


Fri Feb 23 16:00:01 2007 - cacct: 18446744072641133818 o.cacct 3222831651 
logged: 3178567909 now: 18446744072596870076 method: 1

|The cacct variable is the value of all incoming / outcoming IPv4 and 
IPv6 traffic in bytes.
This debug would mean, that one customer has caused traffic more as 100 
TB in 20 minutes ( and that only with one ventrilo server! ).
First I thought, it's a bug in my daemon software, but that wasn't the 
problem, how this information will show:


|hostname:~/control# cat /proc/virtual/2/cacct
UNSPEC:0/0 0/0 0/0 

UNIX: 305586/28642976 267311/28642976  1/30 

INET:9058790/1149688302  9889025/18446744071736090069  47323/18446744072430740975 

INET6: 0/0 0/0 0/0 

OTHER: 0/0 0/0 0/0 


forks:  0|
|
|It seems as the kernel misscalced or overflowed after a cacct value 
over |1472700147.


It's the first and only example of this bug, because this is the first 
customer, with such a lot traffic.


Regards,
Patrick Matthäi
|



Bug#412132:

2007-02-23 Thread Patrick Matthäi

Hi again,

I'm very sorry, I pasted the wrong debug lines:

Fri Feb 23 15:42:01 2007 - cacct: 39375996 o.cacct 39375996 logged: 
39375996 now: 39375996 method: 1
Fri Feb 23 16:00:01 2007 - cacct: 18446744072641133818 o.cacct 
3222831651 logged: 3178567909 now: 18446744072596870076 method: 1


This would be the right one, which would mean, that this error will 
cause maybe about 39375996 bytes ( ~ 4gb ).


Regards,
Patrick Matthäi




Bug#412132: Patch

2007-02-23 Thread Patrick Matthäi

And hello again ;)

I talked about that problem with the people of linux-vserver.org. It's a 
known upstream bug, which is already fixed.


Here's the patch:
http://people.linux-vserver.org/~dhozac/p/k/delta-longatomic-fix01.diff

The counter overflows like I said at 4 GB ( like on a 32 bit system ).

I hope you can apply this patch fast, it's very important for us.

Thanks and regards,
Patrick Matthäi



Bug#412132: cacct interface misscalced about 100 TB

2007-02-23 Thread Bastian Blank
severity 412132 important
user debian-kernel@lists.debian.org
usertag dkt-waiting-etch-update
tags 412132 +patch
thanks

On Fri, Feb 23, 2007 at 11:19:57PM +0100, Patrick Matthäi wrote:
 I think I've found a serious bug in the vserver image for amd64.
 We're running a daemon, which is logging the traffic of all 
 hostmachines. Now I've found a very big mistake in the 
 /proc/virtual/id/cacct interface.

Known. Can be fixed with the first stable update, not security relevant.

Available patch, needs to be fixed to avoid abi change (use atomic_t and crop
at the printf):

diff -Nurp linux-2.6.19.2-vs2.2.0-rc9/include/linux/vserver/cacct_def.h 
linux-2.6.19.2-vs2.2.0-rc9.longatomic/include/linux/vserver/cacct_def.h
--- linux-2.6.19.2-vs2.2.0-rc9/include/linux/vserver/cacct_def.h
2007-01-11 18:10:53.0 +0100
+++ linux-2.6.19.2-vs2.2.0-rc9.longatomic/include/linux/vserver/cacct_def.h 
2007-02-02 18:17:38.0 +0100
@@ -6,8 +6,8 @@
 
 
 struct _vx_sock_acc {
-   atomic_t count;
-   atomic_t total;
+   atomic_long_t count;
+   atomic_long_t total;
 };
 
 /* context sub struct */
@@ -30,9 +30,9 @@ static inline void __dump_vx_cacct(struc
 
printk(\t [%d] =, i);
for (j=0; j3; j++) {
-   printk( [%d] = %8d, %8d, j,
-   atomic_read(ptr[j].count),
-   atomic_read(ptr[j].total));
+   printk( [%d] = %8ld, %8ld, j,
+   atomic_long_read(ptr[j].count),
+   atomic_long_read(ptr[j].total));
}
printk(\n);
}
diff -Nurp linux-2.6.19.2-vs2.2.0-rc9/include/linux/vs_socket.h 
linux-2.6.19.2-vs2.2.0-rc9.longatomic/include/linux/vs_socket.h
--- linux-2.6.19.2-vs2.2.0-rc9/include/linux/vs_socket.h2007-01-11 
18:10:52.0 +0100
+++ linux-2.6.19.2-vs2.2.0-rc9.longatomic/include/linux/vs_socket.h 
2007-02-02 18:18:14.0 +0100
@@ -38,8 +38,8 @@ static inline void __vx_acc_sock(struct 
if (vxi) {
int type = vx_sock_type(family);
 
-   atomic_inc(vxi-cacct.sock[type][pos].count);
-   atomic_add(size, vxi-cacct.sock[type][pos].total);
+   atomic_long_inc(vxi-cacct.sock[type][pos].count);
+   atomic_long_add(size, vxi-cacct.sock[type][pos].total);
}
 }
 
Bastian

-- 
Without freedom of choice there is no creativity.
-- Kirk, The return of the Archons, stardate 3157.4



Processed (with 1 errors): Re: Bug#412132: cacct interface misscalced about 100 TB

2007-02-23 Thread Debian Bug Tracking System
Processing commands for [EMAIL PROTECTED]:

 severity 412132 important
Bug#412132: cacct interface misscalced about 100 TB
Severity set to `important' from `serious'

 user debian-kernel@lists.debian.org
Setting user to debian-kernel@lists.debian.org (was [EMAIL PROTECTED]).
 usertag dkt-waiting-etch-update
Unknown command or malformed arguments to command.

 tags 412132 +patch
Bug#412132: cacct interface misscalced about 100 TB
There were no tags set.
Tags added: patch

 thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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



Bug#412132: cacct interface misscalced about 100 TB

2007-02-23 Thread Patrick Matthäi

Hi,

I'm sorry, normaly it shouldn't be a very important bug, but please 
think about these ones, who have to log the caused traffic, that's very 
terrible. So could you please add it to the next upload?


Regards, Patrick Matthäi


Bastian Blank schrieb:

severity 412132 important
user debian-kernel@lists.debian.org
usertag dkt-waiting-etch-update
tags 412132 +patch
thanks

On Fri, Feb 23, 2007 at 11:19:57PM +0100, Patrick Matthäi wrote:
  

I think I've found a serious bug in the vserver image for amd64.
We're running a daemon, which is logging the traffic of all 
hostmachines. Now I've found a very big mistake in the 
/proc/virtual/id/cacct interface.



Known. Can be fixed with the first stable update, not security relevant.

Available patch, needs to be fixed to avoid abi change (use atomic_t and crop
at the printf):

diff -Nurp linux-2.6.19.2-vs2.2.0-rc9/include/linux/vserver/cacct_def.h 
linux-2.6.19.2-vs2.2.0-rc9.longatomic/include/linux/vserver/cacct_def.h
--- linux-2.6.19.2-vs2.2.0-rc9/include/linux/vserver/cacct_def.h
2007-01-11 18:10:53.0 +0100
+++ linux-2.6.19.2-vs2.2.0-rc9.longatomic/include/linux/vserver/cacct_def.h 
2007-02-02 18:17:38.0 +0100
@@ -6,8 +6,8 @@
 
 
 struct _vx_sock_acc {

-   atomic_t count;
-   atomic_t total;
+   atomic_long_t count;
+   atomic_long_t total;
 };
 
 /* context sub struct */

@@ -30,9 +30,9 @@ static inline void __dump_vx_cacct(struc
 
 		printk(\t [%d] =, i);

for (j=0; j3; j++) {
-   printk( [%d] = %8d, %8d, j,
-   atomic_read(ptr[j].count),
-   atomic_read(ptr[j].total));
+   printk( [%d] = %8ld, %8ld, j,
+   atomic_long_read(ptr[j].count),
+   atomic_long_read(ptr[j].total));
}
printk(\n);
}
diff -Nurp linux-2.6.19.2-vs2.2.0-rc9/include/linux/vs_socket.h 
linux-2.6.19.2-vs2.2.0-rc9.longatomic/include/linux/vs_socket.h
--- linux-2.6.19.2-vs2.2.0-rc9/include/linux/vs_socket.h2007-01-11 
18:10:52.0 +0100
+++ linux-2.6.19.2-vs2.2.0-rc9.longatomic/include/linux/vs_socket.h 
2007-02-02 18:18:14.0 +0100
@@ -38,8 +38,8 @@ static inline void __vx_acc_sock(struct 
 	if (vxi) {

int type = vx_sock_type(family);
 
-		atomic_inc(vxi-cacct.sock[type][pos].count);

-   atomic_add(size, vxi-cacct.sock[type][pos].total);
+   atomic_long_inc(vxi-cacct.sock[type][pos].count);
+   atomic_long_add(size, vxi-cacct.sock[type][pos].total);
}
 }
 
Bastian


  





Bug#412132: cacct interface misscalced about 100 TB

2007-02-23 Thread Bastian Blank
On Sat, Feb 24, 2007 at 12:48:20AM +0100, Patrick Matthäi wrote:
 I'm sorry, normaly it shouldn't be a very important bug, but please 
 think about these ones, who have to log the caused traffic, that's very 
 terrible. So could you please add it to the next upload?

I do, but I have to prioritize them.

Bastian

-- 
Kirk to Enterprise -- beam down yeoman Rand and a six-pack.