1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"https://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=utf-8" />
<link rel=stylesheet type="text/css" href="style.css" title="style">
<title>
Reporting bugs in the kernel and glibc
</title>
</head>
<body>
<!--BEGIN-LINKS-->
<form method="get" action="https://www.google.com/search">
<table border=0 cellpadding=0 cellspacing=0 width="100%">
<tr>
<td align="left">
<font size="-1">
Linux <em>man-pages</em>:
<a href="./index.html">home</a> |
<a href="https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/CONTRIBUTING">contributing</a> |
<a href="./reporting_bugs.html">bugs</a> |
<a href="./download.html">download</a>
||
<a href="https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git">git</a> |
<a href="https://man7.org/linux/man-pages/index.html">online pages</a></font>
</td>
<td align="right">
<input type="text" name="q" size=10 maxlength=255 value="">
<input type="hidden" name="sitesearch" value="man7.org/linux/man-pages">
<input type="submit" name="sa" value="Search online pages">
</td>
</tr>
</table>
</form>
<!--END-LINKS-->
<h1>Reporting bugs in the kernel and glibc</h1>
<p>
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.
</p>
<h2>Reporting library function (and other glibc) bugs</h2>
<p>
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
<a href="https://sourceware.org/bugzilla/">glibc bugzilla</a>.
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
<a href="https://www.gnu.org/software/libc/bugs.html">here</a>
for more details.
</p>
<h2>Reporting system call (and other kernel) bugs</h2>
<p>
There are two ways of reporting bugs in kernel interfaces.
You can either send an email to the Linux Kernel Mailing List (LKML,
<a href="mailto:linux-kernel@vger.kernel.org">linux-kernel@vger.kernel.org</a>)
or raise a bug in the
<a href="https://bugzilla.kernel.org/">kernel bugzilla</a>.
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.
</p>
<p>
In either case,
two things are likely to very much improve your chances of
seeing the bug properly resolved:
</p>
<ul>
<li>
Provide as much useful information as possible when reporting the bug.
<br>
<br>
</li>
<li>CC relevant people on the bug report.
</li>
</ul>
<h3>Providing a useful bug report</h3>
<p>
Whether you are reporting a bug via
LKML or via the kernel bugzilla, first take a look at
<a href="https://www.kernel.org/pub/linux/docs/lkml/reporting-bugs.html">https://www.kernel.org/pub/linux/docs/lkml/reporting-bugs.html</a> for some details
on how to report bugs.
</p>
<p>
Various things will help improve your bug report,
and its chances of getting resolved in a timely fashion:
</p>
<ul>
<li>
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.)
<br>
<br>
</li>
<li>
If possible, provide information about which kernel versions are or
are not affected by the bug.
<br>
<br>
</li>
<li>
Provide a description of why the bug is important
(not just to you, but to others).
</li>
</ul>
<h3>CCing relevant people</h3>
<p>
<strong>IMPORTANT</strong>:
Most kernel developers do <strong>not</strong> 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.
</p>
<blockquote>
<blockquote>
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, <em>indiscriminately</em> adding these two to your CC list
is not far removed from spamming; avoid doing that.
</blockquote>
</blockquote>
<p>
Identifying the right developers to CC isn't always straightforward,
but here are some suggestions that may help:
</p>
<ul>
<li>
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
<a href="http://lxr.linux.no/linux//MAINTAINERS">here</a>.)
<br>
<br>
</li>
<li>
Try to determine the kernel source file(s) that may
be relevant to your bug (e.g., perhaps doing a
<span class="cmd">grep -r</span>
of the kernel source tree to find the file that implements the
system call that you think is buggy).
<br>
<br>
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
<a href="https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=tree">Linus's Git tree</a>
to see which developers have made changes to the file.
<br>
<br>
</li>
<li>
Grep
<a href="https://www.kernel.org/pub/linux/kernel/v3.0/">recent kernel ChangeLogs</a>
to see who made changes that may be relevant to your bug.
<br>
<br>
</li>
<li>
Search LKML archives
(e.g., <a href="https://lore.kernel.org/lkml/">lore</a>
and
<a href="https://marc.info/?l=linux-man">MARC</a>)
to look for email messages that look relevant to your bug.
Authors of some of those messages may be useful to CC.
<br>
<br>
</li>
<li>
If the bug relates to the kernel-userspace interface provided
by a system call, then CC
<span class="email">mtk.manpages@gmail.com</span>
and
<span class="email">linux-man@vger.kernel.org</span>.
This will allow the bug to be documented in <em>man-pages</em>,
if that seems necessary.
</li>
</ul>
<h3>No-one responded to my bug report!</h3>
<p>
If you reported a bug, and no-one responds, this may be because:
</p>
<ul>
<li>
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.
<br>
<br>
</li>
<li>
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.
<br>
<br>
</li>
<li>
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 <em>is</em> important (not just to you,
but to others), then you need to explain why.
</li>
</ul>
<!--BEGIN-STATCOUNTER-->
<!-- SITETRACKING.linux_man-pages -->
<!-- Start of StatCounter Code -->
<script type="text/javascript">
var sc_project=5618989;
var sc_invisible=1;
var sc_partition=60;
var sc_click_stat=1;
var sc_security="4f8507d7";
</script>
<script type="text/javascript"
src="https://www.statcounter.com/counter/counter.js"></script><noscript><div
class="statcounter"><a title="customisable counter"
href="https://www.statcounter.com/free_hit_counter.html"
target="_blank"><img class="statcounter"
src="https://c.statcounter.com/5618989/0/4f8507d7/1/" alt="customisable
counter" ></a></div></noscript>
<!-- End of StatCounter Code -->
<!--END-STATCOUNTER-->
</body>
</html>
|
