Lines Matching +full:model +full:- +full:dependent
11 ---------------------
16 Documentation/admin-guide/reporting-issues.rst if you are unclear about what
21 will not be processed. Note that a time-dependent version such as "latest
39 instructions, file-system image etc). Binary-only executables are not
63 immediately merged (see Documentation/process/submitting-patches.rst).
64 This will save some back-and-forth exchanges if it is accepted, and you
66 only a ``Signed-off-by:`` tag is needed, without ``Reported-by:`` when the
74 --------------------------------
84 a lack of awareness of the Linux kernel's threat model, as described in
85 Documentation/process/threat-model.rst, and ought to have been sent through
86 the normal channels described in Documentation/admin-guide/reporting-issues.rst
110 --------------------
117 anyone, or use of AI-based tools).
126 One difficulty for most first-time reporters is to figure the right list of
137 $ ./scripts/get_maintainer.pl --no-l --no-r --pattern-depth 1 \
146 $ ./scripts/get_maintainer.pl --no-l --no-r drivers/example.c
153 long, it is possible to produce a comma-delimited e-mail address list on a
156 $ ./scripts/get_maintainer.pl --no-tree --no-l --no-r --no-n --m \
157 --no-git-fallback --no-substatus --no-rolestats --no-multiline \
158 --pattern-depth 1 drivers/example.c
163 $ ./scripts/get_maintainer.pl --no-tree --no-l --no-r --no-n --m \
164 --no-git-fallback --no-substatus --no-rolestats --no-multiline \
172 equally be forwarded as-is to the relevant maintainers.
175 ----------------------------------
185 * **Length**: AI-generated reports tend to be excessively long, containing
190 text. Configure your tools to produce concise, human-style reports.
192 * **Formatting**: Most AI-generated reports are littered with Markdown tags.
198 * **Impact Evaluation**: Many AI-generated reports lack an understanding
199 of the kernel's threat model (see Documentation/process/threat-model.rst)
206 * **Reproducer**: AI-based tools are often capable of generating reproducers.
218 Documentation/process/submitting-patches.rst and include a 'Fixes:' tag
226 likely that usage has declined and exposed users are virtually non-existent
233 assistant read this file and threat-model.rst before proceeding, and have it
234 follow the procedure described in coding-assistants.rst: work on an up-to-date
236 build it warning-free and checkpatch-clean, commit it with a Fixes tag, and
241 1. Prepare a plain-text report explaining the problem. It must contain the
249 their email client is properly setup (see email-clients.rst), and leave it
255 ------------------
257 Reports are to be sent over e-mail exclusively. Please use a working e-mail
258 address, preferably the same that you want to appear in ``Reported-by`` tags
287 It is much harder to have a context-quoted discussion about a complex
289 :doc:`regular patch submission <../process/submitting-patches>`
296 text by default, please consult Documentation/process/email-clients.rst for
300 ------------------------------------
330 ------------------------------
335 handled by the "linux-distros" mailing list and disclosure by the
336 public "oss-security" mailing list, both of which are closely related
337 and presented in the linux-distros wiki:
338 <https://oss-security.openwall.org/wiki/mailing-lists/distros>
344 days) start from the availability of a fix, while for "linux-distros"
349 of a potential security issue you DO NOT contact the "linux-distros"
352 the requirements that contacting "linux-distros" will impose on you and
356 fix is accepted do not Cc: "linux-distros", and after it's merged do not
360 --------------
368 Non-disclosure agreements
369 -------------------------
372 to enter any non-disclosure agreements.