code:
.. _magicnumbers:

Linux magic numbers
===================

This file is a registry of magic numbers which are in use.  When you
add a magic number to a structure, you should also add it to this
file, since it is best if the magic numbers used by various structures
are unique.

It is a **very** good idea to protect kernel data structures with magic
numbers.  This allows you to check at run time whether (a) a structure
has been clobbered, or (b) you've passed the wrong structure to a
routine.  This last is especially useful --- particularly when you are
passing pointers to structures via a void * pointer.  The tty code,
for example, does this frequently to pass driver-specific and line
discipline-specific structures back and forth.

The way to use magic numbers is to declare them at the beginning of
the structure, like so::

	struct tty_ldisc {
		int	magic;
		...
	};

Please follow this discipline when you are adding future enhancements
to the kernel!  It has saved me countless hours of debugging,
especially in the screwy cases where an array has been overrun and
structures following the array have been overwritten.  Using this
discipline, these cases get detected quickly and safely.

Changelog::

					Theodore Ts'o
					31 Mar 94

  The magic table is current to Linux 2.1.55.

					Michael Chastain
					<mailto:mec@shout.net>
					22 Sep 1997

  Now it should be up to date with Linux 2.1.112. Because
  we are in feature freeze time it is very unlikely that
  something will change before 2.2.x. The entries are
  sorted by number field.

					Krzysztof G. Baranowski
					<mailto: kgb@knm.org.pl>
					29 Jul 1998

  Updated the magic table to Linux 2.5.45. Right over the feature freeze,
  but it is possible that some new magic numbers will sneak into the
  kernel before 2.6.x yet.

					Petr Baudis
					<pasky@ucw.cz>
					03 Nov 2002

  Updated the magic table to Linux 2.5.74.

					Fabian Frederick
					<ffrederick@users.sourceforge.net>
					09 Jul 2003

===================== ================ ======================== ==========================================
Magic Name            Number           Structure                File
===================== ================ ======================== ==========================================
PG_MAGIC              'P'              pg_{read,write}_hdr      ``include/linux/pg.h``
APM_BIOS_MAGIC        0x4101           apm_user                 ``arch/x86/kernel/apm_32.c``
FASYNC_MAGIC          0x4601           fasync_struct            ``include/linux/fs.h``
SLIP_MAGIC            0x5302           slip                     ``drivers/net/slip.h``
MGSLPC_MAGIC          0x5402           mgslpc_info              ``drivers/char/pcmcia/synclink_cs.c``
BAYCOM_MAGIC          0x19730510       baycom_state             ``drivers/net/baycom_epp.c``
HDLCDRV_MAGIC         0x5ac6e778       hdlcdrv_state            ``include/linux/hdlcdrv.h``
KV_MAGIC              0x5f4b565f       kernel_vars_s            ``arch/mips/include/asm/sn/klkernvars.h``
CODA_MAGIC            0xC0DAC0DA       coda_file_info           ``fs/coda/coda_fs_i.h``
YAM_MAGIC             0xF10A7654       yam_port                 ``drivers/net/hamradio/yam.c``
CCB_MAGIC             0xf2691ad2       ccb                      ``drivers/scsi/ncr53c8xx.c``
QUEUE_MAGIC_FREE      0xf7e1c9a3       queue_entry              ``drivers/scsi/arm/queue.c``
QUEUE_MAGIC_USED      0xf7e1cc33       queue_entry              ``drivers/scsi/arm/queue.c``
NMI_MAGIC             0x48414d4d455201 nmi_s                    ``arch/mips/include/asm/sn/nmi.h``
===================== ================ ======================== ==========================================


code:
.. SPDX-License-Identifier: GPL-2.0

.. _maintainer_handbooks_main:

Subsystem and maintainer tree specific development process notes
================================================================

The purpose of this document is to provide subsystem specific information
which is supplementary to the general development process handbook
:ref:`Documentation/process <development_process_main>`.

Contents:

.. toctree::
   :numbered:
   :maxdepth: 2

   maintainer-tip
   maintainer-netdev

repo_name: angery/linux


code:
.. SPDX-License-Identifier: GPL-2.0

.. _netdev-FAQ:

==========
netdev FAQ
==========

tl;dr
-----

 - designate your patch to a tree - ``[PATCH net]`` or ``[PATCH net-next]``
 - for fixes the ``Fixes:`` tag is required, regardless of the tree
 - don't post large series (> 15 patches), break them up
 - don't repost your patches within one 24h period
 - reverse xmas tree

What is netdev?
---------------
It is a mailing list for all network-related Linux stuff.  This
includes anything found under net/ (i.e. core code like IPv6) and
drivers/net (i.e. hardware specific drivers) in the Linux source tree.

Note that some subsystems (e.g. wireless drivers) which have a high
volume of traffic have their own specific mailing lists.

The netdev list is managed (like many other Linux mailing lists) through
VGER (http://vger.kernel.org/) with archives available at
https://lore.kernel.org/netdev/

Aside from subsystems like those mentioned above, all network-related
Linux development (i.e. RFC, review, comments, etc.) takes place on
netdev.

How do the changes posted to netdev make their way into Linux?
--------------------------------------------------------------
There are always two trees (git repositories) in play.  Both are
driven by David Miller, the main network maintainer.  There is the
``net`` tree, and the ``net-next`` tree.  As you can probably guess from
the names, the ``net`` tree is for fixes to existing code already in the
mainline tree from Linus, and ``net-next`` is where the new code goes
for the future release.  You can find the trees here:

- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git
- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git

How do I indicate which tree (net vs. net-next) my patch should be in?
----------------------------------------------------------------------
To help maintainers and CI bots you should explicitly mark which tree
your patch is targeting. Assuming that you use git, use the prefix
flag::

  git format-patch --subject-prefix='PATCH net-next' start..finish

Use ``net`` instead of ``net-next`` (always lower case) in the above for
bug-fix ``net`` content.

How often do changes from these trees make it to the mainline Linus tree?
-------------------------------------------------------------------------
To understand this, you need to know a bit of background information on
the cadence of Linux development.  Each new release starts off with a
two week "merge window" where the main maintainers feed their new stuff
to Linus for merging into the mainline tree.  After the two weeks, the
merge window is closed, and it is called/tagged ``-rc1``.  No new
features get mainlined after this -- only fixes to the rc1 content are
expected.  After roughly a week of collecting fixes to the rc1 content,
rc2 is released.  This repeats on a roughly weekly basis until rc7
(typically; sometimes rc6 if things are quiet, or rc8 if things are in a
state of churn), and a week after the last vX.Y-rcN was done, the
official vX.Y is released.

Relating that to netdev: At the beginning of the 2-week merge window,
the ``net-next`` tree will be closed - no new changes/features.  The
accumulated new content of the past ~10 weeks will be passed onto
mainline/Linus via a pull request for vX.Y -- at the same time, the
``net`` tree will start accumulating fixes for this pulled content
relating to vX.Y

An announcement indicating when ``net-next`` has been closed is usually
sent to netdev, but knowing the above, you can predict that in advance.

.. warning::
  Do not send new ``net-next`` content to netdev during the
  period during which ``net-next`` tree is closed.

RFC patches sent for review only are obviously welcome at any time
(use ``--subject-prefix='RFC net-next'`` with ``git format-patch``).

Shortly after the two weeks have passed (and vX.Y-rc1 is released), the
tree for ``net-next`` reopens to collect content for the next (vX.Y+1)
release.

If you aren't subscribed to netdev and/or are simply unsure if
``net-next`` has re-opened yet, simply check the ``net-next`` git
repository link above for any new networking-related commits.  You may
also check the following website for the current status:

  http://vger.kernel.org/~davem/net-next.html

The ``net`` tree continues to collect fixes for the vX.Y content, and is
fed back to Linus at regular (~weekly) intervals.  Meaning that the
focus for ``net`` is on stabilization and bug fixes.

Finally, the vX.Y gets released, and the whole cycle starts over.

So where are we now in this cycle?
----------------------------------

Load the mainline (Linus) page here:

  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

and note the top of the "tags" section.  If it is rc1, it is early in
the dev cycle.  If it was tagged rc7 a week ago, then a release is
probably imminent. If the most recent tag is a final release tag
(without an ``-rcN`` suffix) - we are most likely in a merge window
and ``net-next`` is closed.

How can I tell the status of a patch I've sent?
-----------------------------------------------
Start by looking at the main patchworks queue for netdev:

  https://patchwork.kernel.org/project/netdevbpf/list/

The "State" field will tell you exactly where things are at with your
patch. Patches are indexed by the ``Message-ID`` header of the emails
which carried them so if you have trouble finding your patch append
the value of ``Message-ID`` to the URL above.

How long before my patch is accepted?
-------------------------------------
Generally speaking, the patches get triaged quickly (in less than
48h). But be patient, if your patch is active in patchwork (i.e. it's
listed on the project's patch list) the chances it was missed are close to zero.
Asking the maintainer for status updates on your
patch is a good way to ensure your patch is ignored or pushed to the
bottom of the priority list.

Should I directly update patchwork state of my own patches?
-----------------------------------------------------------
It may be tempting to help the maintainers and update the state of your
own patches when you post a new version or spot a bug. Please do not do that.
Interfering with the patch status on patchwork will only cause confusion. Leave
it to the maintainer to figure out what is the most recent and current
version that should be applied. If there is any doubt, the maintainer
will reply and ask what should be done.

How do I divide my work into patches?
-------------------------------------

Put yourself in the shoes of the reviewer. Each patch is read separately
and therefore should constitute a comprehensible step towards your stated
goal.

Avoid sending series longer than 15 patches. Larger series takes longer
to review as reviewers will defer looking at it until they find a large
chunk of time. A small series can be reviewed in a short time, so Maintainers
just do it. As a result, a sequence of smaller series gets merged quicker and
with better review coverage. Re-posting large series also increases the mailing
list traffic.

I made changes to only a few patches in a patch series should I resend only those changed?
------------------------------------------------------------------------------------------
No, please resend the entire patch series and make sure you do number your
patches such that it is clear this is the latest and greatest set of patches
that can be applied.

I have received review feedback, when should I post a revised version of the patches?
-------------------------------------------------------------------------------------
Allow at least 24 hours to pass between postings. This will ensure reviewers
from all geographical locations have a chance to chime in. Do not wait
too long (weeks) between postings either as it will make it harder for reviewers
to recall all the context.

Make sure you address all the feedback in your new posting. Do not post a new
version of the code if the discussion about the previous version is still
ongoing, unless directly instructed by a reviewer.

I submitted multiple versions of a patch series and it looks like a version other than the last one has been accepted, what should I do?
----------------------------------------------------------------------------------------------------------------------------------------
There is no revert possible, once it is pushed out, it stays like that.
Please send incremental versions on top of what has been merged in order to fix
the patches the way they would look like if your latest patch series was to be
merged.

Are there special rules regarding stable submissions on netdev?
---------------------------------------------------------------
While it used to be the case that netdev submissions were not supposed
to carry explicit ``CC: stable@vger.kernel.org`` tags that is no longer
the case today. Please follow the standard stable rules in
:ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`,
and make sure you include appropriate Fixes tags!

Is the comment style convention different for the networking content?
---------------------------------------------------------------------
Yes, in a largely trivial way.  Instead of this::

  /*
   * foobar blah blah blah
   * another line of text
   */

it is requested that you make it look like this::

  /* foobar blah blah blah
   * another line of text
   */

What is "reverse xmas tree"?
----------------------------

Netdev has a convention for ordering local variables in functions.
Order the variable declaration lines longest to shortest, e.g.::

  struct scatterlist *sg;
  struct sk_buff *skb;
  int err, i;

If there are dependencies between the variables preventing the ordering
move the initialization out of line.

I am working in existing code which uses non-standard formatting. Which formatting should I use?
------------------------------------------------------------------------------------------------
Make your code follow the most recent guidelines, so that eventually all code
in the domain of netdev is in the preferred format.

I found a bug that might have possible security implications or similar. Should I mail the main netdev maintainer off-list?
---------------------------------------------------------------------------------------------------------------------------
No. The current netdev maintainer has consistently requested that
people use the mailing lists and not reach out directly.  If you aren't
OK with that, then perhaps consider mailing security@kernel.org or
reading about http://oss-security.openwall.org/wiki/mailing-lists/distros
as possible alternative mechanisms.

What level of testing is expected before I submit my change?
------------------------------------------------------------
At the very minimum your changes must survive an ``allyesconfig`` and an
``allmodconfig`` build with ``W=1`` set without new warnings or failures.

Ideally you will have done run-time testing specific to your change,
and the patch series contains a set of kernel selftest for
``tools/testing/selftests/net`` or using the KUnit framework.

You are expected to test your changes on top of the relevant networking
tree (``net`` or ``net-next``) and not e.g. a stable tree or ``linux-next``.

How do I post corresponding changes to user space components?
-------------------------------------------------------------
User space code exercising kernel features should be posted
alongside kernel patches. This gives reviewers a chance to see
how any new interface is used and how well it works.

When user space tools reside in the kernel repo itself all changes
should generally come as one series. If series becomes too large
or the user space project is not reviewed on netdev include a link
to a public repo where user space patches can be seen.

In case user space tooling lives in a separate repository but is
reviewed on netdev  (e.g. patches to ``iproute2`` tools) kernel and
user space patches should form separate series (threads) when posted
to the mailing list, e.g.::

  [PATCH net-next 0/3] net: some feature cover letter
   └─ [PATCH net-next 1/3] net: some feature prep
   └─ [PATCH net-next 2/3] net: some feature do it
   └─ [PATCH net-next 3/3] selftest: net: some feature

  [PATCH iproute2-next] ip: add support for some feature

Posting as one thread is discouraged because it confuses patchwork
(as of patchwork 2.2.2).

Can I reproduce the checks from patchwork on my local machine?
--------------------------------------------------------------

Checks in patchwork are mostly simple wrappers around existing kernel
scripts, the sources are available at:

https://github.com/kuba-moo/nipa/tree/master/tests

Running all the builds and checks locally is a pain, can I post my patches and have the patchwork bot validate them?
--------------------------------------------------------------------------------------------------------------------

No, you must ensure that your patches are ready by testing them locally
before posting to the mailing list. The patchwork build bot instance
gets overloaded very easily and netdev@vger really doesn't need more
traffic if we can help it.

netdevsim is great, can I extend it for my out-of-tree tests?
-------------------------------------------------------------

No, ``netdevsim`` is a test vehicle solely for upstream tests.
(Please add your tests under ``tools/testing/selftests/``.)

We also give no guarantees that ``netdevsim`` won't change in the future
in a way which would break what would normally be considered uAPI.

Is netdevsim considered a "user" of an API?
-------------------------------------------

Linux kernel has a long standing rule that no API should be added unless
it has a real, in-tree user. Mock-ups and tests based on ``netdevsim`` are
strongly encouraged when adding new APIs, but ``netdevsim`` in itself
is **not** considered a use case/user.

Any other tips to help ensure my net/net-next patch gets OK'd?
--------------------------------------------------------------
Attention to detail.  Re-read your own work as if you were the
reviewer.  You can start with using ``checkpatch.pl``, perhaps even with
the ``--strict`` flag.  But do not be mindlessly robotic in doing so.
If your change is a bug fix, make sure your commit log indicates the
end-user visible symptom, the underlying reason as to why it happens,
and then if necessary, explain why the fix proposed is the best way to
get things done.  Don't mangle whitespace, and as is common, don't
mis-indent function arguments that span multiple lines.  If it is your
first patch, mail it to yourself so you can test apply it to an
unpatched tree to confirm infrastructure didn't mangle it.

Finally, go back and read
:ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
to be sure you are not repeating some common mistake documented there.

My company uses peer feedback in employee performance reviews. Can I ask netdev maintainers for feedback?
---------------------------------------------------------------------------------------------------------

Yes, especially if you spend significant amount of time reviewing code
and go out of your way to improve shared infrastructure.

The feedback must be requested by you, the contributor, and will always
be shared with you (even if you request for it to be submitted to your
manager).


code:
.. _pgpguide:

===========================
Kernel Maintainer PGP guide
===========================

:Author: Konstantin Ryabitsev <konstantin@linuxfoundation.org>

This document is aimed at Linux kernel developers, and especially at
subsystem maintainers. It contains a subset of information discussed in
the more general "`Protecting Code Integrity`_" guide published by the
Linux Foundation. Please read that document for more in-depth discussion
on some of the topics mentioned in this guide.

.. _`Protecting Code Integrity`: https://github.com/lfit/itpol/blob/master/protecting-code-integrity.md

The role of PGP in Linux Kernel development
===========================================

PGP helps ensure the integrity of the code that is produced by the Linux
kernel development community and, to a lesser degree, establish trusted
communication channels between developers via PGP-signed email exchange.

The Linux kernel source code is available in two main formats:

- Distributed source repositories (git)
- Periodic release snapshots (tarballs)

Both git repositories and tarballs carry PGP signatures of the kernel
developers who create official kernel releases. These signatures offer a
cryptographic guarantee that downloadable versions made available via
kernel.org or any other mirrors are identical to what these developers
have on their workstations. To this end:

- git repositories provide PGP signatures on all tags
- tarballs provide detached PGP signatures with all downloads

.. _devs_not_infra:

Trusting the developers, not infrastructure
-------------------------------------------

Ever since the 2011 compromise of core kernel.org systems, the main
operating principle of the Kernel Archives project has been to assume
that any part of the infrastructure can be compromised at any time. For
this reason, the administrators have taken deliberate steps to emphasize
that trust must always be placed with developers and never with the code
hosting infrastructure, regardless of how good the security practices
for the latter may be.

The above guiding principle is the reason why this guide is needed. We
want to make sure that by placing trust into developers we do not simply
shift the blame for potential future security incidents to someone else.
The goal is to provide a set of guidelines developers can use to create
a secure working environment and safeguard the PGP keys used to
establish the integrity of the Linux kernel itself.

.. _pgp_tools:

PGP tools
=========

Use GnuPG v2
------------

Your distro should already have GnuPG installed by default, you just
need to verify that you are using version 2.x and not the legacy 1.4
release -- many distributions still package both, with the default
``gpg`` command invoking GnuPG v.1. To check, run::

    $ gpg --version | head -n1

If you see ``gpg (GnuPG) 1.4.x``, then you are using GnuPG v.1. Try the
``gpg2`` command (if you don't have it, you may need to install the
gnupg2 package)::

    $ gpg2 --version | head -n1

If you see ``gpg (GnuPG) 2.x.x``, then you are good to go. This guide
will assume you have the version 2.2 of GnuPG (or later). If you are
using version 2.0 of GnuPG, then some of the commands in this guide will
not work, and you should consider installing the latest 2.2 version of
GnuPG. Versions of gnupg-2.1.11 and later should be compatible for the
purposes of this guide as well.

If you have both ``gpg`` and ``gpg2`` commands, you should make sure you
are always using GnuPG v2, not the legacy version. You can enforce this
by setting the appropriate alias::

    $ alias gpg=gpg2

You can put that in your ``.bashrc`` to make sure it's always the case.

Configure gpg-agent options
~~~~~~~~~~~~~~~~~~~~~~~~~~~

The GnuPG agent is a helper tool that will start automatically whenever
you use the ``gpg`` command and run in the background with the purpose
of caching the private key passphrase. There are two options you should
know in order to tweak when the passphrase should be expired from cache:

- ``default-cache-ttl`` (seconds): If you use the same key again before
  the time-to-live expires, the countdown will reset for another period.
  The default is 600 (10 minutes).
- ``max-cache-ttl`` (seconds): Regardless of how recently you've used
  the key since initial passphrase entry, if the maximum time-to-live
  countdown expires, you'll have to enter the passphrase again. The
  default is 30 minutes.

If you find either of these defaults too short (or too long), you can
edit your ``~/.gnupg/gpg-agent.conf`` file to set your own values::

    # set to 30 minutes for regular ttl, and 2 hours for max ttl
    default-cache-ttl 1800
    max-cache-ttl 7200

.. note::

    It is no longer necessary to start gpg-agent manually at the
    beginning of your shell session. You may want to check your rc files
    to remove anything you had in place for older versions of GnuPG, as
    it may not be doing the right thing any more.

.. _protect_your_key:

Protect your PGP key
====================

This guide assumes that you already have a PGP key that you use for Linux
kernel development purposes. If you do not yet have one, please see the
"`Protecting Code Integrity`_" document mentioned earlier for guidance
on how to create a new one.

You should also make a new key if your current one is weaker than 2048
bits (RSA).

Understanding PGP Subkeys
-------------------------

A PGP key rarely consists of a single keypair -- usually it is a
collection of independent subkeys that can be used for different
purposes based on their capabilities, assigned at their creation time.
PGP defines four capabilities that a key can have:

- **[S]** keys can be used for signing
- **[E]** keys can be used for encryption
- **[A]** keys can be used for authentication
- **[C]** keys can be used for certifying other keys

The key with the **[C]** capability is often called the "master" key,
but this terminology is misleading because it implies that the Certify
key can be used in place of any of other subkey on the same chain (like
a physical "master key" can be used to open the locks made for other
keys). Since this is not the case, this guide will refer to it as "the
Certify key" to avoid any ambiguity.

It is critical to fully understand the following:

1. All subkeys are fully independent from each other. If you lose a
   private subkey, it cannot be restored or recreated from any other
   private key on your chain.
2. With the exception of the Certify key, there can be multiple subkeys
   with identical capabilities (e.g. you can have 2 valid encryption
   subkeys, 3 valid signing subkeys, but only one valid certification
   subkey). All subkeys are fully independent -- a message encrypted to
   one **[E]** subkey cannot be decrypted with any other **[E]** subkey
   you may also have.
3. A single subkey may have multiple capabilities (e.g. your **[C]** key
   can also be your **[S]** key).

The key carrying the **[C]** (certify) capability is the only key that
can be used to indicate relationship with other keys. Only the **[C]**
key can be used to:

- add or revoke other keys (subkeys) with S/E/A capabilities
- add, change or revoke identities (uids) associated with the key
- add or change the expiration date on itself or any subkey
- sign other people's keys for web of trust purposes

By default, GnuPG creates the following when generating new keys:

- One subkey carrying both Certify and Sign capabilities (**[SC]**)
- A separate subkey with the Encryption capability (**[E]**)

If you used the default parameters when generating your key, then that
is what you will have. You can verify by running ``gpg --list-secret-keys``,
for example::

    sec   rsa2048 2018-01-23 [SC] [expires: 2020-01-23]
          000000000000000000000000AAAABBBBCCCCDDDD
    uid           [ultimate] Alice Dev <adev@kernel.org>
    ssb   rsa2048 2018-01-23 [E] [expires: 2020-01-23]

The long line under the ``sec`` entry is your key fingerprint --
whenever you see ``[fpr]`` in the examples below, that 40-character
string is what it refers to.

Ensure your passphrase is strong
--------------------------------

GnuPG uses passphrases to encrypt your private keys before storing them on
disk. This way, even if your ``.gnupg`` directory is leaked or stolen in
its entirety, the attackers cannot use your private keys without first
obtaining the passphrase to decrypt them.

It is absolutely essential that your private keys are protected by a
strong passphrase. To set it or change it, use::

    $ gpg --change-passphrase [fpr]

Create a separate Signing subkey
--------------------------------

Our goal is to protect your Certify key by moving it to offline media,
so if you only have a combined **[SC]** key, then you should create a
separate signing subkey::

    $ gpg --quick-addkey [fpr] ed25519 sign

.. note:: ECC support in GnuPG

    GnuPG 2.1 and later has full support for Elliptic Curve
    Cryptography, with ability to combine ECC subkeys with traditional
    RSA keys. The main upside of ECC cryptography is that it is much
    faster computationally and creates much smaller signatures when
    compared byte for byte with 2048+ bit RSA keys. Unless you plan on
    using a smartcard device that does not support ECC operations, we
    recommend that you create an ECC signing subkey for your kernel
    work.

    Note, that if you plan to use a hardware device that does not
    support ED25519 ECC keys, you should choose "nistp256" instead or
    "ed25519."

Back up your Certify key for disaster recovery
----------------------------------------------

The more signatures you have on your PGP key from other developers, the
more reasons you have to create a backup version that lives on something
other than digital media, for disaster recovery reasons.

The best way to create a printable hardcopy of your private key is by
using the ``paperkey`` software written for this very purpose. See ``man
paperkey`` for more details on the output format and its benefits over
other solutions. Paperkey should already be packaged for most
distributions.

Run the following command to create a hardcopy backup of your private
key::

    $ gpg --export-secret-key [fpr] | paperkey -o /tmp/key-backup.txt

Print out that file (or pipe the output straight to lpr), then take a
pen and write your passphrase on the margin of the paper. **This is
strongly recommended** because the key printout is still encrypted with
that passphrase, and if you ever change it you will not remember what it
used to be when you had created the backup -- *guaranteed*.

Put the resulting printout and the hand-written passphrase into an envelope
and store in a secure and well-protected place, preferably away from your
home, such as your bank vault.

.. note::

    Your printer is probably no longer a simple dumb device connected to
    your parallel port, but since the output is still encrypted with
    your passphrase, printing out even to "cloud-integrated" modern
    printers should remain a relatively safe operation.

Back up your whole GnuPG directory
----------------------------------

.. warning::

    **!!!Do not skip this step!!!**

It is important to have a readily available backup of your PGP keys
should you need to recover them. This is different from the
disaster-level preparedness we did with ``paperkey``. You will also rely
on these external copies whenever you need to use your Certify key --
such as when making changes to your own key or signing other people's
keys after conferences and summits.

Start by getting a small USB "thumb" drive (preferably two!) that you
will use for backup purposes. You will need to encrypt them using LUKS
-- refer to your distro's documentation on how to accomplish this.

For the encryption passphrase, you can use the same one as on your
PGP key.

Once the encryption process is over, re-insert the USB drive and make
sure it gets properly mounted. Copy your entire ``.gnupg`` directory
over to the encrypted storage::

    $ cp -a ~/.gnupg /media/disk/foo/gnupg-backup

You should now test to make sure everything still works::

    $ gpg --homedir=/media/disk/foo/gnupg-backup --list-key [fpr]

If you don't get any errors, then you should be good to go. Unmount the
USB drive, distinctly label it so you don't blow it away next time you
need to use a random USB drive, and put in a safe place -- but not too
far away, because you'll need to use it every now and again for things
like editing identities, adding or revoking subkeys, or signing other
people's keys.

Remove the Certify key from your homedir
----------------------------------------

The files in our home directory are not as well protected as we like to
think.  They can be leaked or stolen via many different means:

- by accident when making quick homedir copies to set up a new workstation
- by systems administrator negligence or malice
- via poorly secured backups
- via malware in desktop apps (browsers, pdf viewers, etc)
- via coercion when crossing international borders

Protecting your key with a good passphrase greatly helps reduce the risk
of any of the above, but passphrases can be discovered via keyloggers,
shoulder-surfing, or any number of other means. For this reason, the
recommended setup is to remove your Certify key from your home directory
and store it on offline storage.

.. warning::

    Please see the previous section and make sure you have backed up
    your GnuPG directory in its entirety. What we are about to do will
    render your key useless if you do not have a usable backup!

First, identify the keygrip of your Certify key::

    $ gpg --with-keygrip --list-key [fpr]

The output will be something like this::

    pub   rsa2048 2018-01-24 [SC] [expires: 2020-01-24]
          000000000000000000000000AAAABBBBCCCCDDDD
          Keygrip = 1111000000000000000000000000000000000000
    uid           [ultimate] Alice Dev <adev@kernel.org>
    sub   rsa2048 2018-01-24 [E] [expires: 2020-01-24]
          Keygrip = 2222000000000000000000000000000000000000
    sub   ed25519 2018-01-24 [S]
          Keygrip = 3333000000000000000000000000000000000000

Find the keygrip entry that is beneath the ``pub`` line (right under the
Certify key fingerprint). This will correspond directly to a file in your
``~/.gnupg`` directory::

    $ cd ~/.gnupg/private-keys-v1.d
    $ ls
    1111000000000000000000000000000000000000.key
    2222000000000000000000000000000000000000.key
    3333000000000000000000000000000000000000.key

All you have to do is simply remove the .key file that corresponds to
the Certify key keygrip::

    $ cd ~/.gnupg/private-keys-v1.d
    $ rm 1111000000000000000000000000000000000000.key

Now, if you issue the ``--list-secret-keys`` command, it will show that
the Certify key is missing (the ``#`` indicates it is not available)::

    $ gpg --list-secret-keys
    sec#  rsa2048 2018-01-24 [SC] [expires: 2020-01-24]
          000000000000000000000000AAAABBBBCCCCDDDD
    uid           [ultimate] Alice Dev <adev@kernel.org>
    ssb   rsa2048 2018-01-24 [E] [expires: 2020-01-24]
    ssb   ed25519 2018-01-24 [S]

You should also remove any ``secring.gpg`` files in the ``~/.gnupg``
directory, which are left over from earlier versions of GnuPG.

If you don't have the "private-keys-v1.d" directory
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If you do not have a ``~/.gnupg/private-keys-v1.d`` directory, then your
secret keys are still stored in the legacy ``secring.gpg`` file used by
GnuPG v1. Making any changes to your key, such as changing the
passphrase or adding a subkey, should automatically convert the old
``secring.gpg`` format to use ``private-keys-v1.d`` instead.

Once you get that done, make sure to delete the obsolete ``secring.gpg``
file, which still contains your private keys.

.. _smartcards:

Move the subkeys to a dedicated crypto device
=============================================

Even though the Certify key is now safe from being leaked or stolen, the
subkeys are still in your home directory. Anyone who manages to get
their hands on those will be able to decrypt your communication or fake
your signatures (if they know the passphrase). Furthermore, each time a
GnuPG operation is performed, the keys are loaded into system memory and
can be stolen from there by sufficiently advanced malware (think
Meltdown and Spectre).

The best way to completely protect your keys is to move them to a
specialized hardware device that is capable of smartcard operations.

The benefits of smartcards
--------------------------

A smartcard contains a cryptographic chip that is capable of storing
private keys and performing crypto operations directly on the card
itself. Because the key contents never leave the smartcard, the
operating system of the computer into which you plug in the hardware
device is not able to retrieve the private keys themselves. This is very
different from the encrypted USB storage device we used earlier for
backup purposes -- while that USB device is plugged in and mounted, the
operating system is able to access the private key contents.

Using external encrypted USB media is not a substitute to having a
smartcard-capable device.

Available smartcard devices
---------------------------

Unless all your laptops and workstations have smartcard readers, the
easiest is to get a specialized USB device that implements smartcard
functionality. There are several options available:

- `Nitrokey Start`_: Open hardware and Free Software, based on FSI
  Japan's `Gnuk`_. One of the few available commercial devices that
  support ED25519 ECC keys, but offer fewest security features (such as
  resistance to tampering or some side-channel attacks).
- `Nitrokey Pro 2`_: Similar to the Nitrokey Start, but more
  tamper-resistant and offers more security features. Pro 2 supports ECC
  cryptography (NISTP).
- `Yubikey 5`_: proprietary hardware and software, but cheaper than
  Nitrokey Pro and comes available in the USB-C form that is more useful
  with newer laptops. Offers additional security features such as FIDO
  U2F, among others, and now finally supports NISTP and ED25519 ECC
  keys.

`LWN has a good review`_ of some of the above models, as well as several
others. Your choice will depend on cost, shipping availability in your
geographical region, and open/proprietary hardware considerations.

.. note::

    If you are listed in MAINTAINERS or have an account at kernel.org,
    you `qualify for a free Nitrokey Start`_ courtesy of The Linux
    Foundation.

.. _`Nitrokey Start`: https://shop.nitrokey.com/shop/product/nitrokey-start-6
.. _`Nitrokey Pro 2`: https://shop.nitrokey.com/shop/product/nkpr2-nitrokey-pro-2-3
.. _`Yubikey 5`: https://www.yubico.com/products/yubikey-5-overview/
.. _Gnuk: https://www.fsij.org/doc-gnuk/
.. _`LWN has a good review`: https://lwn.net/Articles/736231/
.. _`qualify for a free Nitrokey Start`: https://www.kernel.org/nitrokey-digital-tokens-for-kernel-developers.html

Configure your smartcard device
-------------------------------

Your smartcard device should Just Work (TM) the moment you plug it into
any modern Linux workstation. You can verify it by running::

    $ gpg --card-status

If you see full smartcard details, then you are good to go.
Unfortunately, troubleshooting all possible reasons why things may not
be working for you is way beyond the scope of this guide. If you are
having trouble getting the card to work with GnuPG, please seek help via
usual support channels.

To configure your smartcard, you will need to use the GnuPG menu system, as
there are no convenient command-line switches::

    $ gpg --card-edit
    [...omitted...]
    gpg/card> admin
    Admin commands are allowed
    gpg/card> passwd

You should set the user PIN (1), Admin PIN (3), and the Reset Code (4).
Please make sure to record and store these in a safe place -- especially
the Admin PIN and the Reset Code (which allows you to completely wipe
the smartcard). You so rarely need to use the Admin PIN, that you will
inevitably forget what it is if you do not record it.

Getting back to the main card menu, you can also set other values (such
as name, sex, login data, etc), but it's not necessary and will
additionally leak information about your smartcard should you lose it.

.. note::

    Despite having the name "PIN", neither the user PIN nor the admin
    PIN on the card need to be numbers.

.. warning::

    Some devices may require that you move the subkeys onto the device
    before you can change the passphrase. Please check the documentation
    provided by the device manufacturer.

Move the subkeys to your smartcard
----------------------------------

Exit the card menu (using "q") and save all changes. Next, let's move
your subkeys onto the smartcard. You will need both your PGP key
passphrase and the admin PIN of the card for most operations::

    $ gpg --edit-key [fpr]

    Secret subkeys are available.

    pub  rsa2048/AAAABBBBCCCCDDDD
         created: 2018-01-23  expires: 2020-01-23  usage: SC
         trust: ultimate      validity: ultimate
    ssb  rsa2048/1111222233334444
         created: 2018-01-23  expires: never       usage: E
    ssb  ed25519/5555666677778888
         created: 2017-12-07  expires: never       usage: S
    [ultimate] (1). Alice Dev <adev@kernel.org>

    gpg>

Using ``--edit-key`` puts us into the menu mode again, and you will
notice that the key listing is a little different. From here on, all
commands are done from inside this menu mode, as indicated by ``gpg>``.

First, let's select the key we'll be putting onto the card -- you do
this by typing ``key 1`` (it's the first one in the listing, the **[E]**
subkey)::

    gpg> key 1

In the output, you should now see ``ssb*`` on the **[E]** key. The ``*``
indicates which key is currently "selected." It works as a *toggle*,
meaning that if you type ``key 1`` again, the ``*`` will disappear and
the key will not be selected any more.

Now, let's move that key onto the smartcard::

    gpg> keytocard
    Please select where to store the key:
       (2) Encryption key
    Your selection? 2

Since it's our **[E]** key, it makes sense to put it into the Encryption
slot.  When you submit your selection, you will be prompted first for
your PGP key passphrase, and then for the admin PIN. If the command
returns without an error, your key has been moved.

**Important**: Now type ``key 1`` again to unselect the first key, and
``key 2`` to select the **[S]** key::

    gpg> key 1
    gpg> key 2
    gpg> keytocard
    Please select where to store the key:
       (1) Signature key
       (3) Authentication key
    Your selection? 1

You can use the **[S]** key both for Signature and Authentication, but
we want to make sure it's in the Signature slot, so choose (1). Once
again, if your command returns without an error, then the operation was
successful::

    gpg> q
    Save changes? (y/N) y

Saving the changes will delete the keys you moved to the card from your
home directory (but it's okay, because we have them in our backups
should we need to do this again for a replacement smartcard).

Verifying that the keys were moved
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If you perform ``--list-secret-keys`` now, you will see a subtle
difference in the output::

    $ gpg --list-secret-keys
    sec#  rsa2048 2018-01-24 [SC] [expires: 2020-01-24]
          000000000000000000000000AAAABBBBCCCCDDDD
    uid           [ultimate] Alice Dev <adev@kernel.org>
    ssb>  rsa2048 2018-01-24 [E] [expires: 2020-01-24]
    ssb>  ed25519 2018-01-24 [S]

The ``>`` in the ``ssb>`` output indicates that the subkey is only
available on the smartcard. If you go back into your secret keys
directory and look at the contents there, you will notice that the
``.key`` files there have been replaced with stubs::

    $ cd ~/.gnupg/private-keys-v1.d
    $ strings *.key | grep 'private-key'

The output should contain ``shadowed-private-key`` to indicate that
these files are only stubs and the actual content is on the smartcard.

Verifying that the smartcard is functioning
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

To verify that the smartcard is working as intended, you can create a
signature::

    $ echo "Hello world" | gpg --clearsign > /tmp/test.asc
    $ gpg --verify /tmp/test.asc

This should ask for your smartcard PIN on your first command, and then
show "Good signature" after you run ``gpg --verify``.

Congratulations, you have successfully made it extremely difficult to
steal your digital developer identity!

Other common GnuPG operations
-----------------------------

Here is a quick reference for some common operations you'll need to do
with your PGP key.

Mounting your safe offline storage
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

You will need your Certify key for any of the operations below, so you
will first need to mount your backup offline storage and tell GnuPG to
use it::

    $ export GNUPGHOME=/media/disk/foo/gnupg-backup
    $ gpg --list-secret-keys

You want to make sure that you see ``sec`` and not ``sec#`` in the
output (the ``#`` means the key is not available and you're still using
your regular home directory location).

Extending key expiration date
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The Certify key has the default expiration date of 2 years from the date
of creation. This is done both for security reasons and to make obsolete
keys eventually disappear from keyservers.

To extend the expiration on your key by a year from current date, just
run::

    $ gpg --quick-set-expire [fpr] 1y

You can also use a specific date if that is easier to remember (e.g.
your birthday, January 1st, or Canada Day)::

    $ gpg --quick-set-expire [fpr] 2020-07-01

Remember to send the updated key back to keyservers::

    $ gpg --send-key [fpr]

Updating your work directory after any changes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

After you make any changes to your key using the offline storage, you will
want to import these changes back into your regular working directory::

    $ gpg --export | gpg --homedir ~/.gnupg --import
    $ unset GNUPGHOME

Using gpg-agent over ssh
~~~~~~~~~~~~~~~~~~~~~~~~

You can forward your gpg-agent over ssh if you need to sign tags or
commits on a remote system. Please refer to the instructions provided
on the GnuPG wiki:

- `Agent Forwarding over SSH`_

It works more smoothly if you can modify the sshd server settings on the
remote end.

.. _`Agent Forwarding over SSH`: https://wiki.gnupg.org/AgentForwarding

.. _pgp_with_git:

Using PGP with Git
==================

One of the core features of Git is its decentralized nature -- once a
repository is cloned to your system, you have full history of the
project, including all of its tags, commits and branches. However, with
hundreds of cloned repositories floating around, how does anyone verify
that their copy of linux.git has not been tampered with by a malicious
third party?

Or what happens if a backdoor is discovered in the code and the "Author"
line in the commit says it was done by you, while you're pretty sure you
had `nothing to do with it`_?

To address both of these issues, Git introduced PGP integration. Signed
tags prove the repository integrity by assuring that its contents are
exactly the same as on the workstation of the developer who created the
tag, while signed commits make it nearly impossible for someone to
impersonate you without having access to your PGP keys.

.. _`nothing to do with it`: https://github.com/jayphelps/git-blame-someone-else

Configure git to use your PGP key
---------------------------------

If you only have one secret key in your keyring, then you don't really
need to do anything extra, as it becomes your default key.  However, if
you happen to have multiple secret keys, you can tell git which key
should be used (``[fpr]`` is the fingerprint of your key)::

    $ git config --global user.signingKey [fpr]

**IMPORTANT**: If you have a distinct ``gpg2`` command, then you should
tell git to always use it instead of the legacy ``gpg`` from version 1::

    $ git config --global gpg.program gpg2
    $ git config --global gpgv.program gpgv2

How to work with signed tags
----------------------------

To create a signed tag, simply pass the ``-s`` switch to the tag
command::

    $ git tag -s [tagname]

Our recommendation is to always sign git tags, as this allows other
developers to ensure that the git repository they are pulling from has
not been maliciously altered.

How to verify signed tags
~~~~~~~~~~~~~~~~~~~~~~~~~

To verify a signed tag, simply use the ``verify-tag`` command::

    $ git verify-tag [tagname]

If you are pulling a tag from another fork of the project repository,
git should automatically verify the signature at the tip you're pulling
and show you the results during the merge operation::

    $ git pull [url] tags/sometag

The merge message will contain something like this::

    Merge tag 'sometag' of [url]

    [Tag message]

    # gpg: Signature made [...]
    # gpg: Good signature from [...]

If you are verifying someone else's git tag, then you will need to
import their PGP key. Please refer to the
":ref:`verify_identities`" section below.

.. note::

    If you get "``gpg: Can't check signature: unknown pubkey
    algorithm``" error, you need to tell git to use gpgv2 for
    verification, so it properly processes signatures made by ECC keys.
    See instructions at the start of this section.

Configure git to always sign annotated tags
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Chances are, if you're creating an annotated tag, you'll want to sign
it. To force git to always sign annotated tags, you can set a global
configuration option::

    $ git config --global tag.forceSignAnnotated true

How to work with signed commits
-------------------------------

It is easy to create signed commits, but it is much more difficult to
use them in Linux kernel development, since it relies on patches sent to
the mailing list, and this workflow does not preserve PGP commit
signatures. Furthermore, when rebasing your repository to match
upstream, even your own PGP commit signatures will end up discarded. For
this reason, most kernel developers don't bother signing their commits
and will ignore signed commits in any external repositories that they
rely upon in their work.

However, if you have your working git tree publicly available at some
git hosting service (kernel.org, infradead.org, ozlabs.org, or others),
then the recommendation is that you sign all your git commits even if
upstream developers do not directly benefit from this practice.

We recommend this for the following reasons:

1. Should there ever be a need to perform code forensics or track code
   provenance, even externally maintained trees carrying PGP commit
   signatures will be valuable for such purposes.
2. If you ever need to re-clone your local repository (for example,
   after a disk failure), this lets you easily verify the repository
   integrity before resuming your work.
3. If someone needs to cherry-pick your commits, this allows them to
   quickly verify their integrity before applying them.

Creating signed commits
~~~~~~~~~~~~~~~~~~~~~~~

To create a signed commit, you just need to pass the ``-S`` flag to the
``git commit`` command (it's capital ``-S`` due to collision with
another flag)::

    $ git commit -S

Configure git to always sign commits
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

You can tell git to always sign commits::

    git config --global commit.gpgSign true

.. note::

    Make sure you configure ``gpg-agent`` before you turn this on.

.. _verify_identities:

How to work with signed patches
-------------------------------

It is possible to use your PGP key to sign patches sent to kernel
developer mailing lists. Since existing email signature mechanisms
(PGP-Mime or PGP-inline) tend to cause problems with regular code
review tasks, you should use the tool kernel.org created for this
purpose that puts cryptographic attestation signatures into message
headers (a-la DKIM):

- `Patatt Patch Attestation`_

.. _`Patatt Patch Attestation`: https://pypi.org/project/patatt/

Installing and configuring patatt
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Patatt is packaged for many distributions already, so please check there
first. You can also install it from pypi using "``pip install patatt``".

If you already have your PGP key configured with git (via the
``user.signingKey`` configuration parameter), then patatt requires no
further configuration. You can start signing your patches by installing
the git-send-email hook in the repository you want::

    patatt install-hook

Now any patches you send with ``git send-email`` will be automatically
signed with your cryptographic signature.

Checking patatt signatures
~~~~~~~~~~~~~~~~~~~~~~~~~~

If you are using ``b4`` to retrieve and apply patches, then it will
automatically attempt to verify all DKIM and patatt signatures it
encounters, for example::

    $ b4 am 20220720205013.890942-1-broonie@kernel.org
    [...]
    Checking attestation on all messages, may take a moment...
    ---
      ✓ [PATCH v1 1/3] kselftest/arm64: Correct buffer allocation for SVE Z registers
      ✓ [PATCH v1 2/3] arm64/sve: Document our actual ABI for clearing registers on syscall
      ✓ [PATCH v1 3/3] kselftest/arm64: Enforce actual ABI for SVE syscalls
      ---
      ✓ Signed: openpgp/broonie@kernel.org
      ✓ Signed: DKIM/kernel.org

.. note::

    Patatt and b4 are still in active development and you should check
    the latest documentation for these projects for any new or updated
    features.

.. _kernel_identities:

How to verify kernel developer identities
=========================================

Signing tags and commits is easy, but how does one go about verifying
that the key used to sign something belongs to the actual kernel
developer and not to a malicious imposter?

Configure auto-key-retrieval using WKD and DANE
-----------------------------------------------

If you are not already someone with an extensive collection of other
developers' public keys, then you can jumpstart your keyring by relying
on key auto-discovery and auto-retrieval. GnuPG can piggyback on other
delegated trust technologies, namely DNSSEC and TLS, to get you going if
the prospect of starting your own Web of Trust from scratch is too
daunting.

Add the following to your ``~/.gnupg/gpg.conf``::

    auto-key-locate wkd,dane,local
    auto-key-retrieve

DNS-Based Authentication of Named Entities ("DANE") is a method for
publishing public keys in DNS and securing them using DNSSEC signed
zones. Web Key Directory ("WKD") is the alternative method that uses
https lookups for the same purpose. When using either DANE or WKD for
looking up public keys, GnuPG will validate DNSSEC or TLS certificates,
respectively, before adding auto-retrieved public keys to your local
keyring.

Kernel.org publishes the WKD for all developers who have kernel.org
accounts. Once you have the above changes in your ``gpg.conf``, you can
auto-retrieve the keys for Linus Torvalds and Greg Kroah-Hartman (if you
don't already have them)::

    $ gpg --locate-keys torvalds@kernel.org gregkh@kernel.org

If you have a kernel.org account, then you should `add the kernel.org
UID to your key`_ to make WKD more useful to other kernel developers.

.. _`add the kernel.org UID to your key`: https://korg.wiki.kernel.org/userdoc/mail#adding_a_kernelorg_uid_to_your_pgp_key

Web of Trust (WOT) vs. Trust on First Use (TOFU)
------------------------------------------------

PGP incorporates a trust delegation mechanism known as the "Web of
Trust." At its core, this is an attempt to replace the need for
centralized Certification Authorities of the HTTPS/TLS world. Instead of
various software makers dictating who should be your trusted certifying
entity, PGP leaves this responsibility to each user.

Unfortunately, very few people understand how the Web of Trust works.
While it remains an important aspect of the OpenPGP specification,
recent versions of GnuPG (2.2 and above) have implemented an alternative
mechanism called "Trust on First Use" (TOFU). You can think of TOFU as
"the SSH-like approach to trust." With SSH, the first time you connect
to a remote system, its key fingerprint is recorded and remembered. If
the key changes in the future, the SSH client will alert you and refuse
to connect, forcing you to make a decision on whether you choose to
trust the changed key or not. Similarly, the first time you import
someone's PGP key, it is assumed to be valid. If at any point in the
future GnuPG comes across another key with the same identity, both the
previously imported key and the new key will be marked as invalid and
you will need to manually figure out which one to keep.

We recommend that you use the combined TOFU+PGP trust model (which is
the new default in GnuPG v2). To set it, add (or modify) the
``trust-model`` setting in ``~/.gnupg/gpg.conf``::

    trust-model tofu+pgp

Using the kernel.org web of trust repository
--------------------------------------------

Kernel.org maintains a git repository with developers' public keys as a
replacement for replicating keyserver networks that have gone mostly
dark in the past few years. The full documentation for how to set up
that repository as your source of public keys can be found here:

- `Kernel developer PGP Keyring`_

If you are a kernel developer, please consider submitting your key for
inclusion into that keyring.

.. _`Kernel developer PGP Keyring`: https://korg.docs.kernel.org/pgpkeys.html


code:
.. SPDX-License-Identifier: GPL-2.0

The tip tree handbook
=====================

What is the tip tree?
---------------------

The tip tree is a collection of several subsystems and areas of
development. The tip tree is both a direct development tree and a
aggregation tree for several sub-maintainer trees. The tip tree gitweb URL
is: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git

The tip tree contains the following subsystems:

   - **x86 architecture**

     The x86 architecture development takes place in the tip tree except
     for the x86 KVM and XEN specific parts which are maintained in the
     corresponding subsystems and routed directly to mainline from
     there. It's still good practice to Cc the x86 maintainers on
     x86-specific KVM and XEN patches.

     Some x86 subsystems have their own maintainers in addition to the
     overall x86 maintainers.  Please Cc the overall x86 maintainers on
     patches touching files in arch/x86 even when they are not called out
     by the MAINTAINER file.

     Note, that ``x86@kernel.org`` is not a mailing list. It is merely a
     mail alias which distributes mails to the x86 top-level maintainer
     team. Please always Cc the Linux Kernel mailing list (LKML)
     ``linux-kernel@vger.kernel.org``, otherwise your mail ends up only in
     the private inboxes of the maintainers.

   - **Scheduler**

     Scheduler development takes place in the -tip tree, in the
     sched/core branch - with occasional sub-topic trees for
     work-in-progress patch-sets.

   - **Locking and atomics**

     Locking development (including atomics and other synchronization
     primitives that are connected to locking) takes place in the -tip
     tree, in the locking/core branch - with occasional sub-topic trees
     for work-in-progress patch-sets.

   - **Generic interrupt subsystem and interrupt chip drivers**:

     - interrupt core development happens in the irq/core branch

     - interrupt chip driver development also happens in the irq/core
       branch, but the patches are usually applied in a separate maintainer
       tree and then aggregated into irq/core

   - **Time, timers, timekeeping, NOHZ and related chip drivers**:

     - timekeeping, clocksource core, NTP and alarmtimer development
       happens in the timers/core branch, but patches are usually applied in
       a separate maintainer tree and then aggregated into timers/core

     - clocksource/event driver development happens in the timers/core
       branch, but patches are mostly applied in a separate maintainer tree
       and then aggregated into timers/core

   - **Performance counters core, architecture support and tooling**:

     - perf core and architecture support development happens in the
       perf/core branch

     - perf tooling development happens in the perf tools maintainer
       tree and is aggregated into the tip tree.

   - **CPU hotplug core**

   - **RAS core**

     Mostly x86-specific RAS patches are collected in the tip ras/core
     branch.

   - **EFI core**

     EFI development in the efi git tree. The collected patches are
     aggregated in the tip efi/core branch.

   - **RCU**

     RCU development happens in the linux-rcu tree. The resulting changes
     are aggregated into the tip core/rcu branch.

   - **Various core code components**:

       - debugobjects

       - objtool

       - random bits and pieces

Patch submission notes
----------------------

Selecting the tree/branch
^^^^^^^^^^^^^^^^^^^^^^^^^

In general, development against the head of the tip tree master branch is
fine, but for the subsystems which are maintained separately, have their
own git tree and are only aggregated into the tip tree, development should
take place against the relevant subsystem tree or branch.

Bug fixes which target mainline should always be applicable against the
mainline kernel tree. Potential conflicts against changes which are already
queued in the tip tree are handled by the maintainers.

Patch subject
^^^^^^^^^^^^^

The tip tree preferred format for patch subject prefixes is
'subsys/component:', e.g. 'x86/apic:', 'x86/mm/fault:', 'sched/fair:',
'genirq/core:'. Please do not use file names or complete file paths as
prefix. 'git log path/to/file' should give you a reasonable hint in most
cases.

The condensed patch description in the subject line should start with a
uppercase letter and should be written in imperative tone.

Changelog
^^^^^^^^^

The general rules about changelogs in the process documentation, see
:ref:`Documentation/process/ <submittingpatches>`, apply.

The tip tree maintainers set value on following these rules, especially on
the request to write changelogs in imperative mood and not impersonating
code or the execution of it. This is not just a whim of the
maintainers. Changelogs written in abstract words are more precise and
tend to be less confusing than those written in the form of novels.

It's also useful to structure the changelog into several paragraphs and not
lump everything together into a single one. A good structure is to explain
the context, the problem and the solution in separate paragraphs and this
order.

Examples for illustration:

  Example 1::

    x86/intel_rdt/mbm: Fix MBM overflow handler during hot cpu

    When a CPU is dying, we cancel the worker and schedule a new worker on a
    different CPU on the same domain. But if the timer is already about to
    expire (say 0.99s) then we essentially double the interval.

    We modify the hot cpu handling to cancel the delayed work on the dying
    cpu and run the worker immediately on a different cpu in same domain. We
    donot flush the worker because the MBM overflow worker reschedules the
    worker on same CPU and scans the domain->cpu_mask to get the domain
    pointer.

  Improved version::

    x86/intel_rdt/mbm: Fix MBM overflow handler during CPU hotplug

    When a CPU is dying, the overflow worker is canceled and rescheduled on a
    different CPU in the same domain. But if the timer is already about to
    expire this essentially doubles the interval which might result in a non
    detected overflow.

    Cancel the overflow worker and reschedule it immediately on a different CPU
    in the same domain. The work could be flushed as well, but that would
    reschedule it on the same CPU.

  Example 2::

    time: POSIX CPU timers: Ensure that variable is initialized

    If cpu_timer_sample_group returns -EINVAL, it will not have written into
    *sample. Checking for cpu_timer_sample_group's return value precludes the
    potential use of an uninitialized value of now in the following block.
    Given an invalid clock_idx, the previous code could otherwise overwrite
    *oldval in an undefined manner. This is now prevented. We also exploit
    short-circuiting of && to sample the timer only if the result will
    actually be used to update *oldval.

  Improved version::

    posix-cpu-timers: Make set_process_cpu_timer() more robust

    Because the return value of cpu_timer_sample_group() is not checked,
    compilers and static checkers can legitimately warn about a potential use
    of the uninitialized variable 'now'. This is not a runtime issue as all
    call sites hand in valid clock ids.

    Also cpu_timer_sample_group() is invoked unconditionally even when the
    result is not used because *oldval is NULL.

    Make the invocation conditional and check the return value.

  Example 3::

    The entity can also be used for other purposes.

    Let's rename it to be more generic.

  Improved version::

    The entity can also be used for other purposes.

    Rename it to be more generic.

For complex scenarios, especially race conditions and memory ordering
issues, it is valuable to depict the scenario with a table which shows
the parallelism and the temporal order of events. Here is an example::

    CPU0                            CPU1
    free_irq(X)                     interrupt X
                                    spin_lock(desc->lock)
                                    wake irq thread()
                                    spin_unlock(desc->lock)
    spin_lock(desc->lock)
    remove action()
    shutdown_irq()
    release_resources()             thread_handler()
    spin_unlock(desc->lock)           access released resources.
                                      ^^^^^^^^^^^^^^^^^^^^^^^^^
    synchronize_irq()

Lockdep provides similar useful output to depict a possible deadlock
scenario::

    CPU0                                    CPU1
    rtmutex_lock(&rcu->rt_mutex)
      spin_lock(&rcu->rt_mutex.wait_lock)
                                            local_irq_disable()
                                            spin_lock(&timer->it_lock)
                                            spin_lock(&rcu->mutex.wait_lock)
    --> Interrupt
        spin_lock(&timer->it_lock)

Function references in changelogs
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

When a function is mentioned in the changelog, either the text body or the
subject line, please use the format 'function_name()'. Omitting the
brackets after the function name can be ambiguous::

  Subject: subsys/component: Make reservation_count static

  reservation_count is only used in reservation_stats. Make it static.

The variant with brackets is more precise::

  Subject: subsys/component: Make reservation_count() static

  reservation_count() is only called from reservation_stats(). Make it
  static.

Backtraces in changelogs
^^^^^^^^^^^^^^^^^^^^^^^^

See :ref:`backtraces`.

Ordering of commit tags
^^^^^^^^^^^^^^^^^^^^^^^

To have a uniform view of the commit tags, the tip maintainers use the
following tag ordering scheme:

 - Fixes: 12char-SHA1 ("sub/sys: Original subject line")

   A Fixes tag should be added even for changes which do not need to be
   backported to stable kernels, i.e. when addressing a recently introduced
   issue which only affects tip or the current head of mainline. These tags
   are helpful to identify the original commit and are much more valuable
   than prominently mentioning the commit which introduced a problem in the
   text of the changelog itself because they can be automatically
   extracted.

   The following example illustrates the difference::

     Commit

       abcdef012345678 ("x86/xxx: Replace foo with bar")

     left an unused instance of variable foo around. Remove it.

     Signed-off-by: J.Dev <j.dev@mail>

   Please say instead::

     The recent replacement of foo with bar left an unused instance of
     variable foo around. Remove it.

     Fixes: abcdef012345678 ("x86/xxx: Replace foo with bar")
     Signed-off-by: J.Dev <j.dev@mail>

   The latter puts the information about the patch into the focus and
   amends it with the reference to the commit which introduced the issue
   rather than putting the focus on the original commit in the first place.

 - Reported-by: ``Reporter <reporter@mail>``

 - Originally-by: ``Original author <original-author@mail>``

 - Suggested-by: ``Suggester <suggester@mail>``

 - Co-developed-by: ``Co-author <co-author@mail>``

   Signed-off: ``Co-author <co-author@mail>``

   Note, that Co-developed-by and Signed-off-by of the co-author(s) must
   come in pairs.

 - Signed-off-by: ``Author <author@mail>``

   The first Signed-off-by (SOB) after the last Co-developed-by/SOB pair is the
   author SOB, i.e. the person flagged as author by git.

 - Signed-off-by: ``Patch handler <handler@mail>``

   SOBs after the author SOB are from people handling and transporting
   the patch, but were not involved in development. SOB chains should
   reflect the **real** route a patch took as it was propagated to us,
   with the first SOB entry signalling primary authorship of a single
   author. Acks should be given as Acked-by lines and review approvals
   as Reviewed-by lines.

   If the handler made modifications to the patch or the changelog, then
   this should be mentioned **after** the changelog text and **above**
   all commit tags in the following format::

     ... changelog text ends.

     [ handler: Replaced foo by bar and updated changelog ]

     First-tag: .....

   Note the two empty new lines which separate the changelog text and the
   commit tags from that notice.

   If a patch is sent to the mailing list by a handler then the author has
   to be noted in the first line of the changelog with::

     From: Author <author@mail>

     Changelog text starts here....

   so the authorship is preserved. The 'From:' line has to be followed
   by a empty newline. If that 'From:' line is missing, then the patch
   would be attributed to the person who sent (transported, handled) it.
   The 'From:' line is automatically removed when the patch is applied
   and does not show up in the final git changelog. It merely affects
   the authorship information of the resulting Git commit.

 - Tested-by: ``Tester <tester@mail>``

 - Reviewed-by: ``Reviewer <reviewer@mail>``

 - Acked-by: ``Acker <acker@mail>``

 - Cc: ``cc-ed-person <person@mail>``

   If the patch should be backported to stable, then please add a '``Cc:
   stable@vger.kernel.org``' tag, but do not Cc stable when sending your
   mail.

 - Link: ``https://link/to/information``

   For referring to an email on LKML or other kernel mailing lists,
   please use the lore.kernel.org redirector URL::

     https://lore.kernel.org/r/email-message@id

   The kernel.org redirector is considered a stable URL, unlike other email
   archives.

   Maintainers will add a Link tag referencing the email of the patch
   submission when they apply a patch to the tip tree. This tag is useful
   for later reference and is also used for commit notifications.

Please do not use combined tags, e.g. ``Reported-and-tested-by``, as
they just complicate automated extraction of tags.

Links to documentation
^^^^^^^^^^^^^^^^^^^^^^

Providing links to documentation in the changelog is a great help to later
debugging and analysis.  Unfortunately, URLs often break very quickly
because companies restructure their websites frequently.  Non-'volatile'
exceptions include the Intel SDM and the AMD APM.

Therefore, for 'volatile' documents, please create an entry in the kernel
bugzilla https://bugzilla.kernel.org and attach a copy of these documents
to the bugzilla entry. Finally, provide the URL of the bugzilla entry in
the changelog.

Patch resend or reminders
^^^^^^^^^^^^^^^^^^^^^^^^^

See :ref:`resend_reminders`.

Merge window
^^^^^^^^^^^^

Please do not expect large patch series to be handled during the merge
window or even during the week before.  Such patches should be submitted in
mergeable state *at* *least* a week before the merge window opens.
Exceptions are made for bug fixes and *sometimes* for small standalone
drivers for new hardware or minimally invasive patches for hardware
enablement.

During the merge window, the maintainers instead focus on following the
upstream changes, fixing merge window fallout, collecting bug fixes, and
allowing themselves a breath. Please respect that.

The release candidate -rc1 is the starting point for new patches to be
applied which are targeted for the next merge window.

Git
^^^

The tip maintainers accept git pull requests from maintainers who provide
subsystem changes for aggregation in the tip tree.

Pull requests for new patch submissions are usually not accepted and do not
replace proper patch submission to the mailing list. The main reason for
this is that the review workflow is email based.

If you submit a larger patch series it is helpful to provide a git branch
in a private repository which allows interested people to easily pull the
series for testing. The usual way to offer this is a git URL in the cover
letter of the patch series.

Testing
^^^^^^^

Code should be tested before submitting to the tip maintainers.  Anything
other than minor changes should be built, booted and tested with
comprehensive (and heavyweight) kernel debugging options enabled.

These debugging options can be found in kernel/configs/x86_debug.config
and can be added to an existing kernel config by running:

	make x86_debug.config

Some of these options are x86-specific and can be left out when testing
on other architectures.

Coding style notes
------------------

Comment style
^^^^^^^^^^^^^

Sentences in comments start with an uppercase letter.

Single line comments::

	/* This is a single line comment */

Multi-line comments::

	/*
	 * This is a properly formatted
	 * multi-line comment.
	 *
	 * Larger multi-line comments should be split into paragraphs.
	 */

No tail comments:

  Please refrain from using tail comments. Tail comments disturb the
  reading flow in almost all contexts, but especially in code::

	if (somecondition_is_true) /* Don't put a comment here */
		dostuff(); /* Neither here */

	seed = MAGIC_CONSTANT; /* Nor here */

  Use freestanding comments instead::

	/* This condition is not obvious without a comment */
	if (somecondition_is_true) {
		/* This really needs to be documented */
		dostuff();
	}

	/* This magic initialization needs a comment. Maybe not? */
	seed = MAGIC_CONSTANT;

Comment the important things:

  Comments should be added where the operation is not obvious. Documenting
  the obvious is just a distraction::

	/* Decrement refcount and check for zero */
	if (refcount_dec_and_test(&p->refcnt)) {
		do;
		lots;
		of;
		magic;
		things;
	}

  Instead, comments should explain the non-obvious details and document
  constraints::

	if (refcount_dec_and_test(&p->refcnt)) {
		/*
		 * Really good explanation why the magic things below
		 * need to be done, ordering and locking constraints,
		 * etc..
		 */
		do;
		lots;
		of;
		magic;
		/* Needs to be the last operation because ... */
		things;
	}

Function documentation comments:

  To document functions and their arguments please use kernel-doc format
  and not free form comments::

	/**
	 * magic_function - Do lots of magic stuff
	 * @magic:	Pointer to the magic data to operate on
	 * @offset:	Offset in the data array of @magic
	 *
	 * Deep explanation of mysterious things done with @magic along
         * with documentation of the return values.
	 *
	 * Note, that the argument descriptors above are arranged
	 * in a tabular fashion.
	 */

  This applies especially to globally visible functions and inline
  functions in public header files. It might be overkill to use kernel-doc
  format for every (static) function which needs a tiny explanation. The
  usage of descriptive function names often replaces these tiny comments.
  Apply common sense as always.

Documenting locking requirements
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  Documenting locking requirements is a good thing, but comments are not
  necessarily the best choice. Instead of writing::

	/* Caller must hold foo->lock */
	void func(struct foo *foo)
	{
		...
	}

  Please use::

	void func(struct foo *foo)
	{
		lockdep_assert_held(&foo->lock);
		...
	}

  In PROVE_LOCKING kernels, lockdep_assert_held() emits a warning
  if the caller doesn't hold the lock.  Comments can't do that.

Bracket rules
^^^^^^^^^^^^^

Brackets should be omitted only if the statement which follows 'if', 'for',
'while' etc. is truly a single line::

	if (foo)
		do_something();

The following is not considered to be a single line statement even
though C does not require brackets::

	for (i = 0; i < end; i++)
		if (foo[i])
			do_something(foo[i]);

Adding brackets around the outer loop enhances the reading flow::

	for (i = 0; i < end; i++) {
		if (foo[i])
			do_something(foo[i]);
	}

Variable declarations
^^^^^^^^^^^^^^^^^^^^^

The preferred ordering of variable declarations at the beginning of a
function is reverse fir tree order::

	struct long_struct_name *descriptive_name;
	unsigned long foo, bar;
	unsigned int tmp;
	int ret;

The above is faster to parse than the reverse ordering::

	int ret;
	unsigned int tmp;
	unsigned long foo, bar;
	struct long_struct_name *descriptive_name;

And even more so than random ordering::

	unsigned long foo, bar;
	int ret;
	struct long_struct_name *descriptive_name;
	unsigned int tmp;

Also please try to aggregate variables of the same type into a single
line. There is no point in wasting screen space::

	unsigned long a;
	unsigned long b;
	unsigned long c;
	unsigned long d;

It's really sufficient to do::

	unsigned long a, b, c, d;

Please also refrain from introducing line splits in variable declarations::

	struct long_struct_name *descriptive_name = container_of(bar,
						      struct long_struct_name,
	                                              member);
	struct foobar foo;

It's way better to move the initialization to a separate line after the
declarations::

	struct long_struct_name *descriptive_name;
	struct foobar foo;

	descriptive_name = container_of(bar, struct long_struct_name, member);

Variable types
^^^^^^^^^^^^^^

Please use the proper u8, u16, u32, u64 types for variables which are meant
to describe hardware or are used as arguments for functions which access
hardware. These types are clearly defining the bit width and avoid
truncation, expansion and 32/64-bit confusion.

u64 is also recommended in code which would become ambiguous for 32-bit
kernels when 'unsigned long' would be used instead. While in such
situations 'unsigned long long' could be used as well, u64 is shorter
and also clearly shows that the operation is required to be 64 bits wide
independent of the target CPU.

Please use 'unsigned int' instead of 'unsigned'.

Constants
^^^^^^^^^

Please do not use literal (hexa)decimal numbers in code or initializers.
Either use proper defines which have descriptive names or consider using
an enum.

Struct declarations and initializers
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Struct declarations should align the struct member names in a tabular
fashion::

	struct bar_order {
		unsigned int	guest_id;
		int		ordered_item;
		struct menu	*menu;
	};

Please avoid documenting struct members within the declaration, because
this often results in strangely formatted comments and the struct members
become obfuscated::

	struct bar_order {
		unsigned int	guest_id; /* Unique guest id */
		int		ordered_item;
		/* Pointer to a menu instance which contains all the drinks */
		struct menu	*menu;
	};

Instead, please consider using the kernel-doc format in a comment preceding
the struct declaration, which is easier to read and has the added advantage
of including the information in the kernel documentation, for example, as
follows::

	/**
	 * struct bar_order - Description of a bar order
	 * @guest_id:		Unique guest id
	 * @ordered_item:	The item number from the menu
	 * @menu:		Pointer to the menu from which the item
	 *  			was ordered
	 *
	 * Supplementary information for using the struct.
	 *
	 * Note, that the struct member descriptors above are arranged
	 * in a tabular fashion.
	 */
	struct bar_order {
		unsigned int	guest_id;
		int		ordered_item;
		struct menu	*menu;
	};

Static struct initializers must use C99 initializers and should also be
aligned in a tabular fashion::

	static struct foo statfoo = {
		.a		= 0,
		.plain_integer	= CONSTANT_DEFINE_OR_ENUM,
		.bar		= &statbar,
	};

Note that while C99 syntax allows the omission of the final comma,
we recommend the use of a comma on the last line because it makes
reordering and addition of new lines easier, and makes such future
patches slightly easier to read as well.

Line breaks
^^^^^^^^^^^

Restricting line length to 80 characters makes deeply indented code hard to
read.  Consider breaking out code into helper functions to avoid excessive
line breaking.

The 80 character rule is not a strict rule, so please use common sense when
breaking lines. Especially format strings should never be broken up.

When splitting function declarations or function calls, then please align
the first argument in the second line with the first argument in the first
line::

  static int long_function_name(struct foobar *barfoo, unsigned int id,
				unsigned int offset)
  {

	if (!id) {
		ret = longer_function_name(barfoo, DEFAULT_BARFOO_ID,
					   offset);
	...

Namespaces
^^^^^^^^^^

Function/variable namespaces improve readability and allow easy
grepping. These namespaces are string prefixes for globally visible
function and variable names, including inlines. These prefixes should
combine the subsystem and the component name such as 'x86_comp\_',
'sched\_', 'irq\_', and 'mutex\_'.

This also includes static file scope functions that are immediately put
into globally visible driver templates - it's useful for those symbols
to carry a good prefix as well, for backtrace readability.

Namespace prefixes may be omitted for local static functions and
variables. Truly local functions, only called by other local functions,
can have shorter descriptive names - our primary concern is greppability
and backtrace readability.

Please note that 'xxx_vendor\_' and 'vendor_xxx_` prefixes are not
helpful for static functions in vendor-specific files. After all, it
is already clear that the code is vendor-specific. In addition, vendor
names should only be for truly vendor-specific functionality.

As always apply common sense and aim for consistency and readability.

Commit notifications
--------------------

The tip tree is monitored by a bot for new commits. The bot sends an email
for each new commit to a dedicated mailing list
(``linux-tip-commits@vger.kernel.org``) and Cc's all people who are
mentioned in one of the commit tags. It uses the email message ID from the
Link tag at the end of the tag list to set the In-Reply-To email header so
the message is properly threaded with the patch submission email.

The tip maintainers and submaintainers try to reply to the submitter
when merging a patch, but they sometimes forget or it does not fit the
workflow of the moment. While the bot message is purely mechanical, it
also implies a 'Thank you! Applied.'.


code:
.. _managementstyle:

Linux kernel management style
=============================

This is a short document describing the preferred (or made up, depending
on who you ask) management style for the linux kernel.  It's meant to
mirror the :ref:`process/coding-style.rst <codingstyle>` document to some
degree, and mainly written to avoid answering [#f1]_  the same (or similar)
questions over and over again.

Management style is very personal and much harder to quantify than
simple coding style rules, so this document may or may not have anything
to do with reality.  It started as a lark, but that doesn't mean that it
might not actually be true. You'll have to decide for yourself.

Btw, when talking about "kernel manager", it's all about the technical
lead persons, not the people who do traditional management inside
companies.  If you sign purchase orders or you have any clue about the
budget of your group, you're almost certainly not a kernel manager.
These suggestions may or may not apply to you.

First off, I'd suggest buying "Seven Habits of Highly Effective
People", and NOT read it.  Burn it, it's a great symbolic gesture.

.. [#f1] This document does so not so much by answering the question, but by
  making it painfully obvious to the questioner that we don't have a clue
  to what the answer is.

Anyway, here goes:

.. _decisions:

1) Decisions
------------

Everybody thinks managers make decisions, and that decision-making is
important.  The bigger and more painful the decision, the bigger the
manager must be to make it.  That's very deep and obvious, but it's not
actually true.

The name of the game is to **avoid** having to make a decision.  In
particular, if somebody tells you "choose (a) or (b), we really need you
to decide on this", you're in trouble as a manager.  The people you
manage had better know the details better than you, so if they come to
you for a technical decision, you're screwed.  You're clearly not
competent to make that decision for them.

(Corollary:if the people you manage don't know the details better than
you, you're also screwed, although for a totally different reason.
Namely that you are in the wrong job, and that **they** should be managing
your brilliance instead).

So the name of the game is to **avoid** decisions, at least the big and
painful ones.  Making small and non-consequential decisions is fine, and
makes you look like you know what you're doing, so what a kernel manager
needs to do is to turn the big and painful ones into small things where
nobody really cares.

It helps to realize that the key difference between a big decision and a
small one is whether you can fix your decision afterwards.  Any decision
can be made small by just always making sure that if you were wrong (and
you **will** be wrong), you can always undo the damage later by
backtracking.  Suddenly, you get to be doubly managerial for making
**two** inconsequential decisions - the wrong one **and** the right one.

And people will even see that as true leadership (*cough* bullshit
*cough*).

Thus the key to avoiding big decisions becomes to just avoiding to do
things that can't be undone.  Don't get ushered into a corner from which
you cannot escape.  A cornered rat may be dangerous - a cornered manager
is just pitiful.

It turns out that since nobody would be stupid enough to ever really let
a kernel manager have huge fiscal responsibility **anyway**, it's usually
fairly easy to backtrack.  Since you're not going to be able to waste
huge amounts of money that you might not be able to repay, the only
thing you can backtrack on is a technical decision, and there
back-tracking is very easy: just tell everybody that you were an
incompetent nincompoop, say you're sorry, and undo all the worthless
work you had people work on for the last year.  Suddenly the decision
you made a year ago wasn't a big decision after all, since it could be
easily undone.

It turns out that some people have trouble with this approach, for two
reasons:

 - admitting you were an idiot is harder than it looks.  We all like to
   maintain appearances, and coming out in public to say that you were
   wrong is sometimes very hard indeed.
 - having somebody tell you that what you worked on for the last year
   wasn't worthwhile after all can be hard on the poor lowly engineers
   too, and while the actual **work** was easy enough to undo by just
   deleting it, you may have irrevocably lost the trust of that
   engineer.  And remember: "irrevocable" was what we tried to avoid in
   the first place, and your decision ended up being a big one after
   all.

Happily, both of these reasons can be mitigated effectively by just
admitting up-front that you don't have a friggin' clue, and telling
people ahead of the fact that your decision is purely preliminary, and
might be the wrong thing.  You should always reserve the right to change
your mind, and make people very **aware** of that.  And it's much easier
to admit that you are stupid when you haven't **yet** done the really
stupid thing.

Then, when it really does turn out to be stupid, people just roll their
eyes and say "Oops, not again".

This preemptive admission of incompetence might also make the people who
actually do the work also think twice about whether it's worth doing or
not.  After all, if **they** aren't certain whether it's a good idea, you
sure as hell shouldn't encourage them by promising them that what they
work on will be included.  Make them at least think twice before they
embark on a big endeavor.

Remember: they'd better know more about the details than you do, and
they usually already think they have the answer to everything.  The best
thing you can do as a manager is not to instill confidence, but rather a
healthy dose of critical thinking on what they do.

Btw, another way to avoid a decision is to plaintively just whine "can't
we just do both?" and look pitiful.  Trust me, it works.  If it's not
clear which approach is better, they'll eventually figure it out.  The
answer may end up being that both teams get so frustrated by the
situation that they just give up.

That may sound like a failure, but it's usually a sign that there was
something wrong with both projects, and the reason the people involved
couldn't decide was that they were both wrong.  You end up coming up
smelling like roses, and you avoided yet another decision that you could
have screwed up on.

2) People
---------

Most people are idiots, and being a manager means you'll have to deal
with it, and perhaps more importantly, that **they** have to deal with
**you**.

It turns out that while it's easy to undo technical mistakes, it's not
as easy to undo personality disorders.  You just have to live with
theirs - and yours.

However, in order to prepare yourself as a kernel manager, it's best to
remember not to burn any bridges, bomb any innocent villagers, or
alienate too many kernel developers. It turns out that alienating people
is fairly easy, and un-alienating them is hard. Thus "alienating"
immediately falls under the heading of "not reversible", and becomes a
no-no according to :ref:`decisions`.

There's just a few simple rules here:

 (1) don't call people d*ckheads (at least not in public)
 (2) learn how to apologize when you forgot rule (1)

The problem with #1 is that it's very easy to do, since you can say
"you're a d*ckhead" in millions of different ways [#f2]_, sometimes without
even realizing it, and almost always with a white-hot conviction that
you are right.

And the more convinced you are that you are right (and let's face it,
you can call just about **anybody** a d*ckhead, and you often **will** be
right), the harder it ends up being to apologize afterwards.

To solve this problem, you really only have two options:

 - get really good at apologies
 - spread the "love" out so evenly that nobody really ends up feeling
   like they get unfairly targeted.  Make it inventive enough, and they
   might even be amused.

The option of being unfailingly polite really doesn't exist. Nobody will
trust somebody who is so clearly hiding their true character.

.. [#f2] Paul Simon sang "Fifty Ways to Leave Your Lover", because quite
  frankly, "A Million Ways to Tell a Developer They're a D*ckhead" doesn't
  scan nearly as well.  But I'm sure he thought about it.

3) People II - the Good Kind
----------------------------

While it turns out that most people are idiots, the corollary to that is
sadly that you are one too, and that while we can all bask in the secure
knowledge that we're better than the average person (let's face it,
nobody ever believes that they're average or below-average), we should
also admit that we're not the sharpest knife around, and there will be
other people that are less of an idiot than you are.

Some people react badly to smart people.  Others take advantage of them.

Make sure that you, as a kernel maintainer, are in the second group.
Suck up to them, because they are the people who will make your job
easier. In particular, they'll be able to make your decisions for you,
which is what the game is all about.

So when you find somebody smarter than you are, just coast along.  Your
management responsibilities largely become ones of saying "Sounds like a
good idea - go wild", or "That sounds good, but what about xxx?".  The
second version in particular is a great way to either learn something
new about "xxx" or seem **extra** managerial by pointing out something the
smarter person hadn't thought about.  In either case, you win.

One thing to look out for is to realize that greatness in one area does
not necessarily translate to other areas.  So you might prod people in
specific directions, but let's face it, they might be good at what they
do, and suck at everything else.  The good news is that people tend to
naturally gravitate back to what they are good at, so it's not like you
are doing something irreversible when you **do** prod them in some
direction, just don't push too hard.

4) Placing blame
----------------

Things will go wrong, and people want somebody to blame. Tag, you're it.

It's not actually that hard to accept the blame, especially if people
kind of realize that it wasn't **all** your fault.  Which brings us to the
best way of taking the blame: do it for someone else. You'll feel good
for taking the fall, they'll feel good about not getting blamed, and the
person who lost their whole 36GB porn-collection because of your
incompetence will grudgingly admit that you at least didn't try to weasel
out of it.

Then make the developer who really screwed up (if you can find them) know
**in private** that they screwed up.  Not just so they can avoid it in the
future, but so that they know they owe you one.  And, perhaps even more
importantly, they're also likely the person who can fix it.  Because, let's
face it, it sure ain't you.

Taking the blame is also why you get to be manager in the first place.
It's part of what makes people trust you, and allow you the potential
glory, because you're the one who gets to say "I screwed up".  And if
you've followed the previous rules, you'll be pretty good at saying that
by now.

5) Things to avoid
------------------

There's one thing people hate even more than being called "d*ckhead",
and that is being called a "d*ckhead" in a sanctimonious voice.  The
first you can apologize for, the second one you won't really get the
chance.  They likely will no longer be listening even if you otherwise
do a good job.

We all think we're better than anybody else, which means that when
somebody else puts on airs, it **really** rubs us the wrong way.  You may
be morally and intellectually superior to everybody around you, but
don't try to make it too obvious unless you really **intend** to irritate
somebody [#f3]_.

Similarly, don't be too polite or subtle about things. Politeness easily
ends up going overboard and hiding the problem, and as they say, "On the
internet, nobody can hear you being subtle". Use a big blunt object to
hammer the point in, because you can't really depend on people getting
your point otherwise.

Some humor can help pad both the bluntness and the moralizing.  Going
overboard to the point of being ridiculous can drive a point home
without making it painful to the recipient, who just thinks you're being
silly.  It can thus help get through the personal mental block we all
have about criticism.

.. [#f3] Hint: internet newsgroups that are not directly related to your work
  are great ways to take out your frustrations at other people. Write
  insulting posts with a sneer just to get into a good flame every once in
  a while, and you'll feel cleansed. Just don't crap too close to home.

6) Why me?
----------

Since your main responsibility seems to be to take the blame for other
peoples mistakes, and make it painfully obvious to everybody else that
you're incompetent, the obvious question becomes one of why do it in the
first place?

First off, while you may or may not get screaming teenage girls (or
boys, let's not be judgmental or sexist here) knocking on your dressing
room door, you **will** get an immense feeling of personal accomplishment
for being "in charge".  Never mind the fact that you're really leading
by trying to keep up with everybody else and running after them as fast
as you can.  Everybody will still think you're the person in charge.

It's a great job if you can hack it.


code:
.. _programming_language:

Programming Language
====================

The kernel is written in the C programming language [c-language]_.
More precisely, the kernel is typically compiled with ``gcc`` [gcc]_
under ``-std=gnu11`` [gcc-c-dialect-options]_: the GNU dialect of ISO C11.
``clang`` [clang]_ is also supported, see docs on
:ref:`Building Linux with Clang/LLVM <kbuild_llvm>`.

This dialect contains many extensions to the language [gnu-extensions]_,
and many of them are used within the kernel as a matter of course.

There is some support for compiling the kernel with ``icc`` [icc]_ for several
of the architectures, although at the time of writing it is not completed,
requiring third-party patches.

Attributes
----------

One of the common extensions used throughout the kernel are attributes
[gcc-attribute-syntax]_. Attributes allow to introduce
implementation-defined semantics to language entities (like variables,
functions or types) without having to make significant syntactic changes
to the language (e.g. adding a new keyword) [n2049]_.

In some cases, attributes are optional (i.e. a compiler not supporting them
should still produce proper code, even if it is slower or does not perform
as many compile-time checks/diagnostics).

The kernel defines pseudo-keywords (e.g. ``__pure``) instead of using
directly the GNU attribute syntax (e.g. ``__attribute__((__pure__))``)
in order to feature detect which ones can be used and/or to shorten the code.

Please refer to ``include/linux/compiler_attributes.h`` for more information.

.. [c-language] http://www.open-std.org/jtc1/sc22/wg14/www/standards
.. [gcc] https://gcc.gnu.org
.. [clang] https://clang.llvm.org
.. [icc] https://software.intel.com/en-us/c-compilers
.. [gcc-c-dialect-options] https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html
.. [gnu-extensions] https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html
.. [gcc-attribute-syntax] https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html
.. [n2049] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2049.pdf