Bug#412132: marked as done (cacct interface misscalced about 100 TB)
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)
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)
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:
Hi, could anyone tell me the status of this bug? Regards, Patrick Matthäi
Bug#412132: abi bump
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:
Hi, I'm sorry but when will the update with the fix available (ca ~). Regards, Patrick Matthäi
Bug#412132:
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
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:
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
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
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
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
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
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.
