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,
linux-kernel@vger.kernel.org)
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:
Provide as much useful information as possible when reporting the bug.
Various things will help improve your bug report,
and its chances of getting resolved in a timely fashion:
Provide a precise description of how to reproduce the problem
(possibly including shell session logs, contents of relevant
log files, etc.)
This description may include a test program,
which should be as simple as possible in order to demonstrate the problem.
(If a kernel developer has doubts about
whether the problem is in the kernel or in your test program,
then they are likely to assume the latter, both because it is often true,
and because there are plenty of other calls on most developers' time,
and checking a test program for bugs probably has low priority.)
If possible, provide information about which kernel versions are or
are not affected by the bug.
Provide a description of why the bug is important
(not just to you, but to others).
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:
Look in the MAINTAINERS file at the root of the kernel source tree.
to see if you can identify the maintainer(s) who are relevant
for the kernel
(An online version of the MAINTAINERS file is
here.)
Try to determine the kernel source file(s) that may
be relevant to your bug (e.g., perhaps doing a
grep -r
of the kernel source tree to find the file that implements the
system call that you think is buggy).
Having found that source file, try to work out who
has actively worked on it, especially recently.
Check the source file to see if there are developer email
addresses at the top of it.
Look at
Linus's Git tree
to see which developers have made changes to the file.
Search LKML archives
(e.g., lore
and
MARC)
to look for email messages that look relevant to your bug.
Authors of some of those messages may be useful to CC.
If the bug relates to the kernel-userspace interface provided
by a system call, then CC
mtk.manpages@gmail.com
and
linux-man@vger.kernel.org.
This will allow the bug to be documented in man-pages,
if that seems necessary.
No-one responded to my bug report!
If you reported a bug, and no-one responds, this may be because:
The relevant developers don't know about the bug.
You need to CC the relevant developers by adding them to the
bugzilla report, or resubmitting the bug-report email to LKML with
the relevant developers CCed.
The bug report did not contain enough useful information
to enable the problem to be understood and replicated.
Add that to the bug report, or a resubmitted email to LKML.
No-one has had the time work on the bug, perhaps because it
it is not thought to be important enough.
If you believe the bug is important (not just to you,
but to others), then you need to explain why.