Linux man-pages:   home | contributing | bugs | patches | download   ||   git | online pages

Reporting bugs in the kernel and glibc

If, rather than a documentation bug, you think you've found a bug in a system call or library function, then you should report a bug to either the kernel developers or to the glibc developers. A few hints about reporting bugs in each case are given below.

Reporting library function (and other glibc) bugs

If you are reasonably sure that your bug is not a result of distribution-specific modifications to glibc, then you can submit a bug to the glibc bugzilla. If the glibc bug is distribution-specific, then raise a report in your distributor's bug-reporting facility: if necessary, the distributor will push the bug upstream to the glibc maintainers. Take a look here for more details.

Reporting system call (and other kernel) bugs

There are two ways of reporting bugs in kernel interfaces. You can either send an email to the Linux Kernel Mailing List (LKML, or raise a bug in the kernel bugzilla. If you know that the kernel feature is currently being actively worked on, then reporting via LKML may be the better of the two options.

In either case, two things are likely to very much improve your chances of seeing the bug properly resolved:

Providing a useful bug report

Whether you are reporting a bug via LKML or via the kernel bugzilla, first take a look at for some details on how to report bugs.

Various things will help improve your bug report, and its chances of getting resolved in a timely fashion:

CCing relevant people

IMPORTANT: Most kernel developers do not read every message that gets sent to LKML or monitor every bug report submitted to the bugzilla. This means that if you don't CC relevant developers on your bug report, then you will be relying on the fact that someone else pushes the bug in the direction of the relevant developer or maintainer. This is likely to take time, and may not happen at all (especially for reports submitted via LKML). So, for best results you should identify (all of) the people that should be CCed.

Be generous in your CC list, but note that while Linus Torvalds is at some level responsible everything that goes into the kernel, and Andrew Morton is likewise connected with much that passes onto Linus, indiscriminately adding these two to your CC list is not far removed from spamming; avoid doing that.

Identifying the right developers to CC isn't always straightforward, but here are some suggestions that may help:

No-one responded to my bug report!

If you reported a bug, and no-one responds, this may be because: