title: How does one submit a potential patch to the Linux kernel?
body: <p>We have some software which relied on certain behavior from another (<strong>very</strong> commonly used) application that has now changed, rendering our current implementation workable, but less than optimal.</p>
  
  <p>We believe that this change may have affected a number of other applications, particularly in the performance monitoring arena, and we have found a solution that we believe will improve a slew of other potential problems.</p>
  
  <p>Unfortunately, said solution is a kernel change (relatively simple but high-impact if we stuff it up) and we have no experience in submitting kernel patches for review.</p>
  
  <p>Has anyone on SO actually submitted a patch (while I'd appreciate all answers, I suspect the best ones will come from those that have been through the process, even unsuccessfully)? Have you had it accepted (what are the chances that Alan Cox et al hangs about on SO)?</p>
  
  <p>What is the correct process to follow? I have no intention of sending off an email to Linus since I know he has a cadre of protectors that you're supposed to go through before it gets to him. How do I find out who is responsible for a particular section of the kernel.</p>
  
  <p>It may be that I'm being overly optimistic in thinking someone the kernel world's never heard of can contribute, but I'd be interested to find out.</p>
  
  <hr>
  
  <p>EDIT with more details:</p>
  
  <p>The change is not actually for a performance bug, but an improvement (in my view) to the process accounting entries (currently) written when a process terminates.</p>
  
  <p>Websphere App Server (ah, IBM, bless their little hearts) has changed what it does; JVMs used to exit regularly so that their entries were written and we could use that for chargeback.  Now it leaves JVMs lying around for months, meaning the data is not available in a timely fashion unless we force WAS down regularly. Somehow I don't think IBM's Software Group are going to fix their software for us :-). In any case, I believe it may be a useful feature to have for other long-lived processes.</p>
  
  <p>Currently type-3 process accounting records are written when a process exits, what we're looking at is a mechanism to write type-N records periodically while a process is still active giving the figures since last write (or process start if this is the first time).  Chargeback or performance-monitoring applications could choose to use either the type-3 records (totally unchanged) or the interim type-N records. The current workaround we have is to monitor /proc/PID/stat for specific processes but that's a horrible kludge since it doesn't integrate well with the real process accounting.</p>
  
  <p>It needn't be often (we'd be happy with 24 hours) but there may be a performance impact since the work that's currently done only on process exit() will have to be done occasionally on process context switch. Linus et al might not like that idea since it may be a high-impact area of the code (even checking if there's been 24 hours since the last write may be too slow for them).</p>
  
  <p>Still, thanks for all the answers so far, I'll see how I go. Give me a couple of days and I'll accept the best answer.</p>