| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Sun, 19 Jun 2011 17:10:28 -0500 From: Shane <software.research.development@...il.com> To: Eric Dumazet <eric.dumazet@...il.com> Cc: linux-kernel@...r.kernel.org Subject: Re: tracing kernel panics > It seems you have bugs in your module, maybe something like freeing > memory twice, or memory you dont own, or manipulating some data without > taking the associated lock protecting it. > > tcp sockets are protected by RCU and various locks, getting them used > right is not an easy task. > All very helpful comments. I'm interested in how you guys came to the conclusion that I was doing these things wrong. Not that I don't deny it, but I'm trying to learn the *how* of getting to the source of a problem without asking what am I doing wrong. For example, is there anyplace that tells how to use TCP sockets correctly in relation to the various locks? Best I can tell, I'm doing exactly as is in the kernel sources under /net. I'm still trying to understand when to use a lock when manipulating data, or what type of data needs a lock. What scares me (because I'm spending so much time on it) is that some of these panics seem to be coming from the VM and I may be chasing something that is the effect rather than the cause, and therefore not seeing/catching the real panic. Or maybe I have all the info I need, but just confused on how to read it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists