Bug#631799: [squeeze] Kernel logs name_count maxed, losing inode data messages
On Fri, 2012-12-07 at 09:48 +0100, Rik Theys wrote: Hi, On 12/06/2012 02:51 PM, Ben Hutchings wrote: On Thu, 2012-12-06 at 13:58 +0100, Rik Theys wrote: On 12/06/2012 01:29 PM, Ben Hutchings wrote: It is not too difficult to fix up the conflicts. But this is a fairly big change, so I think this bug should now be 'wontfix' for wheezy. Sorry we didn't get it fixed earlier. Sorry to hear that. Would a patch that simply increases the static number of entries in the names array be an acceptable workaround? It would decrease the change of hitting this bug. Perhaps; do you have any idea what the limit should be? Not really. I'm currently building a test kernel with the limit set to 25 (instead of 20). I'll see if I can boot that kernel one of these days to see if 25 is enough. The 25 might be enough for my situation, but other users could of course need an even bigger number... We do need to consider that this costs 76 bytes per name per task for which auditing is enabled, and there are normally hundreds or thousands of tasks running, so extra names aren't cheap. What would you consider the upper limit to which we could increase the number? Just so I know at which limit I can stop building test kernels. Since you're asking me to make a somewhat arbitrary decision, I'll arbitrarily decide on double the current limit, i.e. 40. I've booted a kernel which has the AUDIT_NAMES set to 30. It's been running for about 12 hours now without any messages (with the Debian 3.2.32 kernel it already logged the first message after 57s uptime). For now, it seems 30 is enough for my use case. If you're willing to bump it up to 40, I would go for that. Thank you for considering. As I said, every increase costs memory for all audit users. I've set it to 30 until the next person finds a reason to increase it further! Ben. -- Ben Hutchings Always try to do things in chronological order; it's less confusing that way. signature.asc Description: This is a digitally signed message part
Bug#631799: [squeeze] Kernel logs name_count maxed, losing inode data messages
Hi, On 12/07/2012 09:48 AM, Rik Theys wrote: Hi, On 12/06/2012 02:51 PM, Ben Hutchings wrote: On Thu, 2012-12-06 at 13:58 +0100, Rik Theys wrote: On 12/06/2012 01:29 PM, Ben Hutchings wrote: It is not too difficult to fix up the conflicts. But this is a fairly big change, so I think this bug should now be 'wontfix' for wheezy. Sorry we didn't get it fixed earlier. Sorry to hear that. Would a patch that simply increases the static number of entries in the names array be an acceptable workaround? It would decrease the change of hitting this bug. Perhaps; do you have any idea what the limit should be? What would you consider the upper limit to which we could increase the number? Just so I know at which limit I can stop building test kernels. Since you're asking me to make a somewhat arbitrary decision, I'll arbitrarily decide on double the current limit, i.e. 40. I've booted a kernel which has the AUDIT_NAMES set to 30. It's been running for about 12 hours now without any messages (with the Debian 3.2.32 kernel it already logged the first message after 57s uptime). The system is running the patches kernel for 5 days now without a single error message. Is it possible to include this change in an upcoming 3.2 kernel upload? Regards, Rik For now, it seems 30 is enough for my use case. If you're willing to bump it up to 40, I would go for that. -- Rik Theys System Engineer KU Leuven - Dept. Elektrotechniek (ESAT) Kasteelpark Arenberg 10 bus 2440 - B-3001 Leuven-Heverlee +32(0)16/32.11.07 Any errors in spelling, tact or fact are transmission errors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631799: [squeeze] Kernel logs name_count maxed, losing inode data messages
Hi, On 12/06/2012 02:51 PM, Ben Hutchings wrote: On Thu, 2012-12-06 at 13:58 +0100, Rik Theys wrote: On 12/06/2012 01:29 PM, Ben Hutchings wrote: It is not too difficult to fix up the conflicts. But this is a fairly big change, so I think this bug should now be 'wontfix' for wheezy. Sorry we didn't get it fixed earlier. Sorry to hear that. Would a patch that simply increases the static number of entries in the names array be an acceptable workaround? It would decrease the change of hitting this bug. Perhaps; do you have any idea what the limit should be? Not really. I'm currently building a test kernel with the limit set to 25 (instead of 20). I'll see if I can boot that kernel one of these days to see if 25 is enough. The 25 might be enough for my situation, but other users could of course need an even bigger number... We do need to consider that this costs 76 bytes per name per task for which auditing is enabled, and there are normally hundreds or thousands of tasks running, so extra names aren't cheap. What would you consider the upper limit to which we could increase the number? Just so I know at which limit I can stop building test kernels. Since you're asking me to make a somewhat arbitrary decision, I'll arbitrarily decide on double the current limit, i.e. 40. I've booted a kernel which has the AUDIT_NAMES set to 30. It's been running for about 12 hours now without any messages (with the Debian 3.2.32 kernel it already logged the first message after 57s uptime). For now, it seems 30 is enough for my use case. If you're willing to bump it up to 40, I would go for that. Thank you for considering. Regards, Rik -- Rik Theys System Engineer KU Leuven - Dept. Elektrotechniek (ESAT) Kasteelpark Arenberg 10 bus 2440 - B-3001 Leuven-Heverlee +32(0)16/32.11.07 Any errors in spelling, tact or fact are transmission errors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631799: [squeeze] Kernel logs name_count maxed, losing inode data messages
Hi, On 12/01/2012 11:10 PM, Ben Hutchings wrote: On Fri, 2012-11-30 at 11:10 +0100, Rik Theys wrote: [...] I cherry picked commits 5ef30ee53b187786e64bdc1f8109e39d17f2ce58 and 5195d8e217a78697152d64fc09a16e063a022465 and tried to compile the result, but it failed with the following error: kernel/auditsc.c:2189: error: conflicting types for ‘__audit_mq_open’ include/linux/audit.h:477: note: previous declaration of ‘__audit_mq_open’ was here kernel/auditsc.c:2289: error: conflicting types for ‘__audit_ipc_set_perm’ include/linux/audit.h:471: note: previous declaration of ‘__audit_ipc_set_perm’ was here Any idea on how to determine which intermediate patches are also needed? Or should I just try to modify commit 5195d8e217a78697152d64fc09a16e063a022465 to make it apply? It is not too difficult to fix up the conflicts. But this is a fairly big change, so I think this bug should now be 'wontfix' for wheezy. Sorry we didn't get it fixed earlier. Sorry to hear that. Would a patch that simply increases the static number of entries in the names array be an acceptable workaround? It would decrease the change of hitting this bug. Regards, Rik -- Rik Theys System Engineer KU Leuven - Dept. Elektrotechniek (ESAT) Kasteelpark Arenberg 10 bus 2440 - B-3001 Leuven-Heverlee +32(0)16/32.11.07 Any errors in spelling, tact or fact are transmission errors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631799: [squeeze] Kernel logs name_count maxed, losing inode data messages
On Thu, 2012-12-06 at 10:58 +0100, Rik Theys wrote: Hi, On 12/01/2012 11:10 PM, Ben Hutchings wrote: On Fri, 2012-11-30 at 11:10 +0100, Rik Theys wrote: [...] I cherry picked commits 5ef30ee53b187786e64bdc1f8109e39d17f2ce58 and 5195d8e217a78697152d64fc09a16e063a022465 and tried to compile the result, but it failed with the following error: kernel/auditsc.c:2189: error: conflicting types for ‘__audit_mq_open’ include/linux/audit.h:477: note: previous declaration of ‘__audit_mq_open’ was here kernel/auditsc.c:2289: error: conflicting types for ‘__audit_ipc_set_perm’ include/linux/audit.h:471: note: previous declaration of ‘__audit_ipc_set_perm’ was here Any idea on how to determine which intermediate patches are also needed? Or should I just try to modify commit 5195d8e217a78697152d64fc09a16e063a022465 to make it apply? It is not too difficult to fix up the conflicts. But this is a fairly big change, so I think this bug should now be 'wontfix' for wheezy. Sorry we didn't get it fixed earlier. Sorry to hear that. Would a patch that simply increases the static number of entries in the names array be an acceptable workaround? It would decrease the change of hitting this bug. Perhaps; do you have any idea what the limit should be? We do need to consider that this costs 76 bytes per name per task for which auditing is enabled, and there are normally hundreds or thousands of tasks running, so extra names aren't cheap. Ben. -- Ben Hutchings Computers are not intelligent. They only think they are. signature.asc Description: This is a digitally signed message part
Bug#631799: [squeeze] Kernel logs name_count maxed, losing inode data messages
On 12/06/2012 01:29 PM, Ben Hutchings wrote: It is not too difficult to fix up the conflicts. But this is a fairly big change, so I think this bug should now be 'wontfix' for wheezy. Sorry we didn't get it fixed earlier. Sorry to hear that. Would a patch that simply increases the static number of entries in the names array be an acceptable workaround? It would decrease the change of hitting this bug. Perhaps; do you have any idea what the limit should be? Not really. I'm currently building a test kernel with the limit set to 25 (instead of 20). I'll see if I can boot that kernel one of these days to see if 25 is enough. The 25 might be enough for my situation, but other users could of course need an even bigger number... We do need to consider that this costs 76 bytes per name per task for which auditing is enabled, and there are normally hundreds or thousands of tasks running, so extra names aren't cheap. What would you consider the upper limit to which we could increase the number? Just so I know at which limit I can stop building test kernels. Regards, Rik -- Rik Theys System Engineer KU Leuven - Dept. Elektrotechniek (ESAT) Kasteelpark Arenberg 10 bus 2440 - B-3001 Leuven-Heverlee +32(0)16/32.11.07 Any errors in spelling, tact or fact are transmission errors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631799: [squeeze] Kernel logs name_count maxed, losing inode data messages
On Thu, 2012-12-06 at 13:58 +0100, Rik Theys wrote: On 12/06/2012 01:29 PM, Ben Hutchings wrote: It is not too difficult to fix up the conflicts. But this is a fairly big change, so I think this bug should now be 'wontfix' for wheezy. Sorry we didn't get it fixed earlier. Sorry to hear that. Would a patch that simply increases the static number of entries in the names array be an acceptable workaround? It would decrease the change of hitting this bug. Perhaps; do you have any idea what the limit should be? Not really. I'm currently building a test kernel with the limit set to 25 (instead of 20). I'll see if I can boot that kernel one of these days to see if 25 is enough. The 25 might be enough for my situation, but other users could of course need an even bigger number... We do need to consider that this costs 76 bytes per name per task for which auditing is enabled, and there are normally hundreds or thousands of tasks running, so extra names aren't cheap. What would you consider the upper limit to which we could increase the number? Just so I know at which limit I can stop building test kernels. Since you're asking me to make a somewhat arbitrary decision, I'll arbitrarily decide on double the current limit, i.e. 40. Ben. -- Ben Hutchings Computers are not intelligent. They only think they are. signature.asc Description: This is a digitally signed message part
Bug#631799: [squeeze] Kernel logs name_count maxed, losing inode data messages
On Fri, 2012-11-30 at 11:10 +0100, Rik Theys wrote: [...] I cherry picked commits 5ef30ee53b187786e64bdc1f8109e39d17f2ce58 and 5195d8e217a78697152d64fc09a16e063a022465 and tried to compile the result, but it failed with the following error: kernel/auditsc.c:2189: error: conflicting types for ‘__audit_mq_open’ include/linux/audit.h:477: note: previous declaration of ‘__audit_mq_open’ was here kernel/auditsc.c:2289: error: conflicting types for ‘__audit_ipc_set_perm’ include/linux/audit.h:471: note: previous declaration of ‘__audit_ipc_set_perm’ was here Any idea on how to determine which intermediate patches are also needed? Or should I just try to modify commit 5195d8e217a78697152d64fc09a16e063a022465 to make it apply? It is not too difficult to fix up the conflicts. But this is a fairly big change, so I think this bug should now be 'wontfix' for wheezy. Sorry we didn't get it fixed earlier. Ben. -- Ben Hutchings Never attribute to conspiracy what can adequately be explained by stupidity. signature.asc Description: This is a digitally signed message part
Bug#631799: [squeeze] Kernel logs name_count maxed, losing inode data messages
Hi, On 11/30/2012 08:18 AM, Rik Theys wrote: On 11/29/2012 01:10 PM, Rik Theys wrote: On 11/25/2012 01:12 AM, Jonathan Nieder wrote: On some of our servers, we periodically see name_count maxed, losing inode data messages in the kernel log. As you mentioned, this is said to be fixed by commit 5195d8e217a7 Author: Eric Paris epa...@redhat.com Date: Tue Jan 3 14:23:05 2012 -0500 audit: dynamically allocate audit_names when not enough space is in the names array which is part of 3.3. Am I correct in understanding that the wheezy kernel is affected, too? I have not yet tried to apply the fix, so I can't comment on that. I can install the 3.2 backports kernel on this system to see if Wheezy is also affected, but I assume it is if the fix is in 3.3. I've booted the 3.2.32 bpo kernel and it is indeed affected. I'll see if I can find time to build a test kernel with the patch applied. I tried to apply this commit to 3.2.34 (and 3.2.32) but it failed to apply. Looking at the git log between 3.2.34 and 3.3 I assumed it also needed commit 5ef30ee53b187786e64bdc1f8109e39d17f2ce58. I cherry picked commits 5ef30ee53b187786e64bdc1f8109e39d17f2ce58 and 5195d8e217a78697152d64fc09a16e063a022465 and tried to compile the result, but it failed with the following error: kernel/auditsc.c:2189: error: conflicting types for ‘__audit_mq_open’ include/linux/audit.h:477: note: previous declaration of ‘__audit_mq_open’ was here kernel/auditsc.c:2289: error: conflicting types for ‘__audit_ipc_set_perm’ include/linux/audit.h:471: note: previous declaration of ‘__audit_ipc_set_perm’ was here Any idea on how to determine which intermediate patches are also needed? Or should I just try to modify commit 5195d8e217a78697152d64fc09a16e063a022465 to make it apply? Regards, Rik -- Rik Theys System Engineer KU Leuven - Dept. Elektrotechniek (ESAT) Kasteelpark Arenberg 10 bus 2440 - B-3001 Leuven-Heverlee +32(0)16/32.11.07 Any errors in spelling, tact or fact are transmission errors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631799: [squeeze] Kernel logs name_count maxed, losing inode data messages
On 11/25/2012 01:12 AM, Jonathan Nieder wrote: On some of our servers, we periodically see name_count maxed, losing inode data messages in the kernel log. As you mentioned, this is said to be fixed by commit 5195d8e217a7 Author: Eric Paris epa...@redhat.com Date: Tue Jan 3 14:23:05 2012 -0500 audit: dynamically allocate audit_names when not enough space is in the names array which is part of 3.3. Am I correct in understanding that the wheezy kernel is affected, too? What is the impact of this bug --- does it flood logs in some situations, for example, or does it lose important information? Is the fix harmless or does it have potential downsides? On this particular server, I get 3 messages every approx. 6 minutes. [5262360.801855] name_count maxed, losing inode data: dev=00:07, inode=8 [5262360.801861] name_count maxed, losing inode data: dev=00:07, inode=334434366 [5262360.803580] name_count maxed, losing inode data: dev=00:3c, inode=21757958 The inode=8 and inode=21757958 are always the same. The second message is always different. I don't think it loses important information in my case as I don't audit a lot of items. My audit log is 99% LOGIN audits. I have not yet tried to apply the fix, so I can't comment on that. I can install the 3.2 backports kernel on this system to see if Wheezy is also affected, but I assume it is if the fix is in 3.3. It could be a while before I can confirm this as this is a production system and I did not plan on rebooting the system before the end of January. I'll see if I can squeeze in a reboot somewhere. Regards, Rik -- Rik Theys System Engineer KU Leuven - Dept. Elektrotechniek (ESAT) Kasteelpark Arenberg 10 bus 2440 - B-3001 Leuven-Heverlee +32(0)16/32.11.07 Any errors in spelling, tact or fact are transmission errors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631799: [squeeze] Kernel logs name_count maxed, losing inode data messages
On 11/29/2012 01:10 PM, Rik Theys wrote: On 11/25/2012 01:12 AM, Jonathan Nieder wrote: On some of our servers, we periodically see name_count maxed, losing inode data messages in the kernel log. As you mentioned, this is said to be fixed by commit 5195d8e217a7 Author: Eric Paris epa...@redhat.com Date: Tue Jan 3 14:23:05 2012 -0500 audit: dynamically allocate audit_names when not enough space is in the names array which is part of 3.3. Am I correct in understanding that the wheezy kernel is affected, too? I have not yet tried to apply the fix, so I can't comment on that. I can install the 3.2 backports kernel on this system to see if Wheezy is also affected, but I assume it is if the fix is in 3.3. I've booted the 3.2.32 bpo kernel and it is indeed affected. I'll see if I can find time to build a test kernel with the patch applied. Rik -- Rik Theys System Engineer KU Leuven - Dept. Elektrotechniek (ESAT) Kasteelpark Arenberg 10 bus 2440 - B-3001 Leuven-Heverlee +32(0)16/32.11.07 Any errors in spelling, tact or fact are transmission errors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631799: [squeeze] Kernel logs name_count maxed, losing inode data messages
reassign 631799 src:linux linux-2.6/2.6.32-35 tags 631799 + upstream patch moreinfo quit Hi Rik, Rik Theys wrote: On some of our servers, we periodically see name_count maxed, losing inode data messages in the kernel log. As you mentioned, this is said to be fixed by commit 5195d8e217a7 Author: Eric Paris epa...@redhat.com Date: Tue Jan 3 14:23:05 2012 -0500 audit: dynamically allocate audit_names when not enough space is in the names array which is part of 3.3. Am I correct in understanding that the wheezy kernel is affected, too? What is the impact of this bug --- does it flood logs in some situations, for example, or does it lose important information? Is the fix harmless or does it have potential downsides? With thanks, lazily, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
