Update namespace.rst #773
Closed
Update namespace.rst #773
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
aligning the ACPI block diagram
|
Hi @girish17! Thanks for your contribution to the Linux kernel! Linux kernel development happens on mailing lists, rather than on GitHub - this GitHub repository is a read-only mirror that isn't used for accepting contributions. So that your change can become part of Linux, please email it to us as a patch. Sending patches isn't quite as simple as sending a pull request, but fortunately it is a well documented process. Here's what to do:
How do I format my contribution?The Linux kernel community is notoriously picky about how contributions are formatted and sent. Fortunately, they have documented their expectations. Firstly, all contributions need to be formatted as patches. A patch is a plain text document showing the change you want to make to the code, and documenting why it is a good idea. You can create patches with Secondly, patches need 'commit messages', which is the human-friendly documentation explaining what the change is and why it's necessary. Thirdly, changes have some technical requirements. There is a Linux kernel coding style, and there are licensing requirements you need to comply with. Both of these are documented in the Submitting Patches documentation that is part of the kernel. Note that you will almost certainly have to modify your existing git commits to satisfy these requirements. Don't worry: there are many guides on the internet for doing this. Where do I send my contribution?The Linux kernel is composed of a number of subsystems. These subsystems are maintained by different people, and have different mailing lists where they discuss proposed changes. If you don't already know what subsystem your change belongs to, the
Make sure that your list of recipients includes a mailing list. If you can't find a more specific mailing list, then LKML - the Linux Kernel Mailing List - is the place to send your patches. It's not usually necessary to subscribe to the mailing list before you send the patches, but if you're interested in kernel development, subscribing to a subsystem mailing list is a good idea. (At this point, you probably don't need to subscribe to LKML - it is a very high traffic list with about a thousand messages per day, which is often not useful for beginners.) How do I send my contribution?Use For more information about using How do I get help if I'm stuck?Firstly, don't get discouraged! There are an enormous number of resources on the internet, and many kernel developers who would like to see you succeed. Many issues - especially about how to use certain tools - can be resolved by using your favourite internet search engine. If you can't find an answer, there are a few places you can turn:
If you get really, really stuck, you could try the owners of this bot, @daxtens and @ajdlinux. Please be aware that we do have full-time jobs, so we are almost certainly the slowest way to get answers! I sent my patch - now what?You wait. You can check that your email has been received by checking the mailing list archives for the mailing list you sent your patch to. Messages may not be received instantly, so be patient. Kernel developers are generally very busy people, so it may take a few weeks before your patch is looked at. Then, you keep waiting. Three things may happen:
Further information
Happy hacking! This message was posted by a bot - if you have any questions or suggestions, please talk to my owners, @ajdlinux and @daxtens, or raise an issue at https://github.com/ajdlinux/KernelPRBot. |
|
they don't look at github pull requests 99% of the time. :/ |
metux
added a commit
to metux/linux
that referenced
this pull request
Feb 8, 2021
Fix checkpatch errors:
ERROR: else should follow close brace '}'
torvalds#121: FILE: drivers/tty/serial/cpm_uart/cpm_uart_cpm2.c:121:
+ }
+ else
WARNING: line over 80 characters
torvalds#150: FILE: drivers/tty/serial/cpm_uart/cpm_uart_cpm2.c:150:
+ pinfo->tx_fifosize), (void __force *)pinfo->mem_addr,
WARNING: Block comments should align the * on each line
torvalds#66: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:66:
+ * Check, if transmit buffers are processed
+*/
WARNING: braces {} are not necessary for any arm of this statement
torvalds#170: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:170:
+ if (IS_SMC(pinfo)) {
[...]
+ } else {
[...]
WARNING: labels should not be indented
torvalds#292: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:292:
+ error_return:
ERROR: code indent should use tabs where possible
torvalds#299: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:299:
+^I^I BD_SC_OV | BD_SC_ID);$
WARNING: labels should not be indented
torvalds#319: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:319:
+ handle_error:
WARNING: line over 80 characters
torvalds#423: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:423:
+ setbits32(&pinfo->sccp->scc_gsmrl, (SCC_GSMRL_ENR | SCC_GSMRL_ENT));
ERROR: space required before the open parenthesis '('
torvalds#451: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:451:
+ while(!cpm_uart_tx_empty(port)) {
WARNING: Missing a blank line after declarations
torvalds#462: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:462:
+ smc_t __iomem *smcp = pinfo->smcp;
+ clrbits16(&smcp->smc_smcmr, SMCMR_REN | SMCMR_TEN);
WARNING: line over 80 characters
torvalds#466: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:466:
+ clrbits32(&sccp->scc_gsmrl, SCC_GSMRL_ENR | SCC_GSMRL_ENT);
WARNING: Missing a blank line after declarations
torvalds#466: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:466:
+ scc_t __iomem *sccp = pinfo->sccp;
+ clrbits32(&sccp->scc_gsmrl, SCC_GSMRL_ENR | SCC_GSMRL_ENT);
ERROR: code indent should use tabs where possible
torvalds#484: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:484:
+ struct ktermios *termios,$
WARNING: please, no spaces at the start of a line
torvalds#484: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:484:
+ struct ktermios *termios,$
ERROR: code indent should use tabs where possible
torvalds#485: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:485:
+ struct ktermios *old)$
WARNING: please, no spaces at the start of a line
torvalds#485: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:485:
+ struct ktermios *old)$
WARNING: line over 80 characters
torvalds#624: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:624:
+ /* Output in *one* operation, so we don't interrupt RX/TX if they
WARNING: Block comments use a trailing */ on a separate line
torvalds#625: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:625:
+ * were already enabled. */
WARNING: line over 80 characters
torvalds#629: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:629:
+ out_be16(&pinfo->sccup->scc_genscc.scc_mrblr, pinfo->rx_fifosize);
WARNING: line over 80 characters
torvalds#773: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:773:
+ mem_addr = pinfo->mem_addr + L1_CACHE_ALIGN(pinfo->rx_nrfifos * pinfo->rx_fifosize);
ERROR: code indent should use tabs where possible
torvalds#797: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:797:
+^I (u8 __iomem *)pinfo->rx_bd_base - DPRAM_BASE);$
ERROR: code indent should use tabs where possible
torvalds#799: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:799:
+^I (u8 __iomem *)pinfo->tx_bd_base - DPRAM_BASE);$
ERROR: code indent should use tabs where possible
torvalds#836: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:836:
+^I SCC_GSMRL_MODE_UART | SCC_GSMRL_TDCR_16 | SCC_GSMRL_RDCR_16);$
ERROR: code indent should use tabs where possible
torvalds#859: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:859:
+^I (u8 __iomem *)pinfo->rx_bd_base - DPRAM_BASE);$
ERROR: code indent should use tabs where possible
torvalds#861: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:861:
+^I (u8 __iomem *)pinfo->tx_bd_base - DPRAM_BASE);$
WARNING: space prohibited between function name and open parenthesis '('
torvalds#866: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:866:
+#if defined (CONFIG_I2C_SPI_SMC1_UCODE_PATCH)
WARNING: line over 80 characters
torvalds#921: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:921:
+ clrbits32(&pinfo->sccp->scc_gsmrl, SCC_GSMRL_ENR | SCC_GSMRL_ENT);
WARNING: Missing a blank line after declarations
torvalds#462: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:462:
+ smc_t __iomem *smcp = pinfo->smcp;
+ clrbits16(&smcp->smc_smcmr,
WARNING: Missing a blank line after declarations
torvalds#467: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:467:
+ scc_t __iomem *sccp = pinfo->sccp;
+ clrbits32(&sccp->scc_gsmrl,
ERROR: code indent should use tabs where possible
torvalds#1151: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:1151:
+ struct uart_cpm_port *pinfo)$
WARNING: please, no spaces at the start of a line
torvalds#1151: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:1151:
+ struct uart_cpm_port *pinfo)$
ERROR: "(foo*)" should be "(foo *)"
torvalds#1161: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:1161:
+ struct clk *clk = clk_get(NULL, (const char*)data);
WARNING: Missing a blank line after declarations
torvalds#1162: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:1162:
+ struct clk *clk = clk_get(NULL, (const char*)data);
+ if (!IS_ERR(clk))
ERROR: code indent should use tabs where possible
torvalds#1169: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:1169:
+^I^I^I "fsl,cpm-brg property.\n", np);$
ERROR: code indent should use tabs where possible
torvalds#1178: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:1178:
+^I^I "fsl,cpm-command property.\n", np);$
ERROR: code indent should use tabs where possible
torvalds#1192: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:1192:
WARNING: braces {} are not necessary for any arm of this statement
torvalds#1279: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:1279:
+ if (unlikely(nolock)) {
[...]
+ } else {
[...]
WARNING: braces {} are not necessary for any arm of this statement
torvalds#1287: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:1287:
+ if (unlikely(nolock)) {
[...]
+ } else {
[...]
WARNING: line over 80 characters
torvalds#1354: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:1354:
+ clrbits32(&pinfo->sccp->scc_gsmrl, SCC_GSMRL_ENR | SCC_GSMRL_ENT);
ERROR: Macros with complex values should be enclosed in parentheses
#1394: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:1394:
+#define CPM_UART_CONSOLE &cpm_scc_uart_console
WARNING: Missing a blank line after declarations
#1437: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:1437:
+ struct uart_cpm_port *pinfo = platform_get_drvdata(ofdev);
+ return uart_remove_one_port(&cpm_reg, &pinfo->port);
WARNING: please, no spaces at the start of a line
#1464: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:1464:
+ };$
WARNING: Missing a blank line after declarations
#1469: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:1469:
+ int ret = uart_register_driver(&cpm_reg);
+ if (ret)
WARNING: Missing a blank line after declarations
#1062: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:1062:
+ int i;
+ volatile cbd_t *bdp;
ERROR: "foo * bar" should be "foo *bar"
torvalds#19: FILE: drivers/tty/serial/cpm_uart/cpm_uart_cpm1.h:19:
+static inline void cpm_set_scc_fcr(scc_uart_t __iomem * sup)
ERROR: "foo * bar" should be "foo *bar"
torvalds#25: FILE: drivers/tty/serial/cpm_uart/cpm_uart_cpm1.h:25:
+static inline void cpm_set_smc_fcr(smc_uart_t __iomem * up)
WARNING: Improper SPDX comment style for 'drivers/tty/serial/cpm_uart/cpm_uart.h', please use '/*' instead
#1: FILE: drivers/tty/serial/cpm_uart/cpm_uart.h:1:
+// SPDX-License-Identifier: GPL-2.0
WARNING: Missing or malformed SPDX-License-Identifier tag in line 1
#1: FILE: drivers/tty/serial/cpm_uart/cpm_uart.h:1:
+// SPDX-License-Identifier: GPL-2.0
WARNING: Block comments use * on subsequent lines
torvalds#106: FILE: drivers/tty/serial/cpm_uart/cpm_uart.h:106:
+/*
+ virtual to phys transtalion
ERROR: code indent should use tabs where possible
torvalds#109: FILE: drivers/tty/serial/cpm_uart/cpm_uart.h:109:
+ struct uart_cpm_port *pinfo)$
WARNING: please, no spaces at the start of a line
torvalds#109: FILE: drivers/tty/serial/cpm_uart/cpm_uart.h:109:
+ struct uart_cpm_port *pinfo)$
ERROR: code indent should use tabs where possible
torvalds#125: FILE: drivers/tty/serial/cpm_uart/cpm_uart.h:125:
+ struct uart_cpm_port *pinfo)$
WARNING: please, no spaces at the start of a line
torvalds#125: FILE: drivers/tty/serial/cpm_uart/cpm_uart.h:125:
+ struct uart_cpm_port *pinfo)$
Signed-off-by: Enrico Weigelt <[email protected]>
nbdd0121
pushed a commit
to nbdd0121/linux
that referenced
this pull request
May 23, 2022
Sync with v5.18
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Sep 17, 2025
The iput() function is a dangerous one - if the reference counter goes
to zero, the function may block for a long time due to:
- inode_wait_for_writeback() waits until writeback on this inode
completes
- the filesystem-specific "evict_inode" callback can do similar
things; e.g. all netfs-based filesystems will call
netfs_wait_for_outstanding_io() which is similar to
inode_wait_for_writeback()
Therefore, callers must carefully evaluate the context they're in and
check whether invoking iput() is a good idea at all.
Most of the time, this is not a problem because the dcache holds
references to all inodes, and the dcache is usually the one to release
the last reference. But this assumption is fragile. For example,
under (memcg) memory pressure, the dcache shrinker is more likely to
release inode references, moving the inode eviction to contexts where
that was extremely unlikely to occur.
Our production servers "found" at least two deadlock bugs in the Ceph
filesystem that were caused by this iput() behavior:
1. Writeback may lead to iput() calls in Ceph (e.g. from
ceph_put_wrbuffer_cap_refs()) which deadlocks in
inode_wait_for_writeback(). Waiting for writeback completion from
within writeback will obviously never be able to make any progress.
This leads to blocked kworkers like this:
INFO: task kworker/u777:6:1270802 blocked for more than 122 seconds.
Not tainted 6.16.7-i1-es torvalds#773
task:kworker/u777:6 state:D stack:0 pid:1270802 tgid:1270802 ppid:2
task_flags:0x4208060 flags:0x00004000
Workqueue: writeback wb_workfn (flush-ceph-3)
Call Trace:
<TASK>
__schedule+0x4ea/0x17d0
schedule+0x1c/0xc0
inode_wait_for_writeback+0x71/0xb0
evict+0xcf/0x200
ceph_put_wrbuffer_cap_refs+0xdd/0x220
ceph_invalidate_folio+0x97/0xc0
ceph_writepages_start+0x127b/0x14d0
do_writepages+0xba/0x150
__writeback_single_inode+0x34/0x290
writeback_sb_inodes+0x203/0x470
__writeback_inodes_wb+0x4c/0xe0
wb_writeback+0x189/0x2b0
wb_workfn+0x30b/0x3d0
process_one_work+0x143/0x2b0
worker_thread+0x30a/0x450
2. In the Ceph messenger thread (net/ceph/messenger*.c), any iput()
call may invoke ceph_evict_inode() which will deadlock in
netfs_wait_for_outstanding_io(); since this blocks the messenger
thread, completions from the Ceph servers will not ever be received
and handled.
It looks like these deadlock bugs have been in the Ceph filesystem
code since forever (therefore no "Fixes" tag in this patch). There
may be various ways to solve this:
- make iput() asynchronous and defer the actual eviction like fput()
(may add overhead)
- make iput() only asynchronous if I_SYNC is set (doesn't solve random
things happening inside the "evict_inode" callback)
- add iput_deferred() to make this asynchronous behavior/overhead
optional and explicit
- refactor Ceph to avoid iput() calls from within writeback and
messenger (if that is even possible)
- add a Ceph-specific workaround
After advice from Mateusz Guzik, I decided to do the latter. The
implementation is simple because it piggybacks on the existing
work_struct for ceph_queue_inode_work() - ceph_inode_work() calls
iput() at the end which means we can donate the last reference to it.
Since Ceph has a few iput() callers in a loop, it seemed simple enough
to pass this counter and use atomic_sub() instead of atomic_dec().
This patch adds ceph_iput_n_async() and converts lots of iput() calls
to it - at least those that may come through writeback and the
messenger.
Signed-off-by: Max Kellermann <[email protected]>
Cc: Mateusz Guzik <[email protected]>
Cc: [email protected]
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Sep 17, 2025
The iput() function is a dangerous one - if the reference counter goes
to zero, the function may block for a long time due to:
- inode_wait_for_writeback() waits until writeback on this inode
completes
- the filesystem-specific "evict_inode" callback can do similar
things; e.g. all netfs-based filesystems will call
netfs_wait_for_outstanding_io() which is similar to
inode_wait_for_writeback()
Therefore, callers must carefully evaluate the context they're in and
check whether invoking iput() is a good idea at all.
Most of the time, this is not a problem because the dcache holds
references to all inodes, and the dcache is usually the one to release
the last reference. But this assumption is fragile. For example,
under (memcg) memory pressure, the dcache shrinker is more likely to
release inode references, moving the inode eviction to contexts where
that was extremely unlikely to occur.
Our production servers "found" at least two deadlock bugs in the Ceph
filesystem that were caused by this iput() behavior:
1. Writeback may lead to iput() calls in Ceph (e.g. from
ceph_put_wrbuffer_cap_refs()) which deadlocks in
inode_wait_for_writeback(). Waiting for writeback completion from
within writeback will obviously never be able to make any progress.
This leads to blocked kworkers like this:
INFO: task kworker/u777:6:1270802 blocked for more than 122 seconds.
Not tainted 6.16.7-i1-es torvalds#773
task:kworker/u777:6 state:D stack:0 pid:1270802 tgid:1270802 ppid:2
task_flags:0x4208060 flags:0x00004000
Workqueue: writeback wb_workfn (flush-ceph-3)
Call Trace:
<TASK>
__schedule+0x4ea/0x17d0
schedule+0x1c/0xc0
inode_wait_for_writeback+0x71/0xb0
evict+0xcf/0x200
ceph_put_wrbuffer_cap_refs+0xdd/0x220
ceph_invalidate_folio+0x97/0xc0
ceph_writepages_start+0x127b/0x14d0
do_writepages+0xba/0x150
__writeback_single_inode+0x34/0x290
writeback_sb_inodes+0x203/0x470
__writeback_inodes_wb+0x4c/0xe0
wb_writeback+0x189/0x2b0
wb_workfn+0x30b/0x3d0
process_one_work+0x143/0x2b0
worker_thread+0x30a/0x450
2. In the Ceph messenger thread (net/ceph/messenger*.c), any iput()
call may invoke ceph_evict_inode() which will deadlock in
netfs_wait_for_outstanding_io(); since this blocks the messenger
thread, completions from the Ceph servers will not ever be received
and handled.
It looks like these deadlock bugs have been in the Ceph filesystem
code since forever (therefore no "Fixes" tag in this patch). There
may be various ways to solve this:
- make iput() asynchronous and defer the actual eviction like fput()
(may add overhead)
- make iput() only asynchronous if I_SYNC is set (doesn't solve random
things happening inside the "evict_inode" callback)
- add iput_deferred() to make this asynchronous behavior/overhead
optional and explicit
- refactor Ceph to avoid iput() calls from within writeback and
messenger (if that is even possible)
- add a Ceph-specific workaround
After advice from Mateusz Guzik, I decided to do the latter. The
implementation is simple because it piggybacks on the existing
work_struct for ceph_queue_inode_work() - ceph_inode_work() calls
iput() at the end which means we can donate the last reference to it.
This patch adds ceph_iput_async() and converts lots of iput() calls to
it - at least those that may come through writeback and the messenger.
Signed-off-by: Max Kellermann <[email protected]>
Cc: Mateusz Guzik <[email protected]>
Cc: [email protected]
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
aligning the ACPI block diagram