aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2023-07-04Documentation: ACPI: fix typo in ssdt-overlays.rstDavid Heidelberg1-1/+1
Signed-off-by: David Heidelberg <david@ixit.cz> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20230625103305.115484-1-david@ixit.cz>
2023-07-04Fix documentation of panic_on_warnOlaf Hering2-2/+2
The kernel cmdline option panic_on_warn expects an integer, it is not a plain option as documented. A number of uses in the tree figured this already, and use panic_on_warn=1 for their purpose. Adjust a comment which otherwise may mislead people in the future. Fixes: 9e3961a09798 ("kernel: add panic_on_warn") Signed-off-by: Olaf Hering <olaf@aepfle.de> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2023-07-03docs: remove the tips on how to submit patches from MAINTAINERSJakub Kicinski2-78/+9
Having "how to submit patches" in MAINTAINTERS seems out of place. We have a whole section of documentation about it, duplication is harmful and a lot of the text looks really out of date. Sections 1, 2 and 4 look really, really old and not applicable to the modern process. Section 3 is obvious but also we have build bots now. Section 5 is a bit outdated (diff -u?!). But I like the part about factoring out shared code, so add that to process docs. Section 6 is unnecessary? Section 7 is covered by more appropriate docs. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20230630171550.128296-1-kuba@kernel.org>
2023-07-03docs: fix typo in zh_TW and zh_CN translationXueshi Hu8-8/+8
In zh_TW and zh_CN translation, "http://lwn.net/Articles" is incorrectly written as "http://lwn.net/Articles". This patch is generated by the following script: rg -l "lwn.net/Articles" | xargs sed -i 's/lwn.net\/articles/lwn.net\/Articles/g' Signed-off-by: Xueshi Hu <xueshi.hu@smartx.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <mr4mjneo2eghtpm2z6envih3kzjdjpptqcot2fm2wp5crljxag@oianggqjllbl>
2023-06-21docs: consolidate storage interfacesCosta Shulyupin1-5/+12
to make the page more organized as requested Signed-off-by: Costa Shulyupin <costa.shul@redhat.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20230618062937.481280-1-costa.shul@redhat.com
2023-06-21Documentation: update git configuration for Link: tagJohannes Berg1-1/+1
The latest version of git (2.41.0) changed the spelling of Message-Id to Message-ID. Adjust the perl script here to accept both spellings. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Tested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20230619115533.981f6abaca01.I1960c39b1d61e8514afcef4806a450a209133187@changeid
2023-06-16Documentation: KVM: make corrections to vcpu-requests.rstRandy Dunlap1-3/+3
Make corrections to punctuation and grammar. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Sean Christopherson <seanjc@google.com> Cc: Andrew Jones <drjones@redhat.com> Cc: Christoffer Dall <cdall@linaro.org> Cc: kvm@vger.kernel.org Cc: Jonathan Corbet <corbet@lwn.net> Cc: linux-doc@vger.kernel.org Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20230612030810.23376-5-rdunlap@infradead.org
2023-06-16Documentation: KVM: make corrections to ppc-pv.rstRandy Dunlap1-4/+4
Correct the path of a header file. Change "guest to ... guest" to "guest to ... host" in one place. Hyphenate "32-bit" systems. Add a comma at one parenthetical phrase. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Sean Christopherson <seanjc@google.com> Cc: kvm@vger.kernel.org Cc: Alexander Graf <agraf@suse.de> Cc: Jonathan Corbet <corbet@lwn.net> Cc: linux-doc@vger.kernel.org Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20230612030810.23376-4-rdunlap@infradead.org
2023-06-16Documentation: KVM: make corrections to locking.rstRandy Dunlap1-9/+9
Correct grammar and punctuation. Use "read-only" for consistency. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Sean Christopherson <seanjc@google.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: kvm@vger.kernel.org Cc: Jonathan Corbet <corbet@lwn.net> Cc: linux-doc@vger.kernel.org Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20230612030810.23376-3-rdunlap@infradead.org
2023-06-16Documentation: KVM: make corrections to halt-polling.rstRandy Dunlap1-5/+5
Module parameters are in sysfs, not debugfs, so change that. Remove superfluous "that" following "Note:". Hyphenate "system-wide" values. Hyphenate "trade-off". Don't treat "denial of service" as a verb. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Sean Christopherson <seanjc@google.com> Cc: kvm@vger.kernel.org Cc: Jonathan Corbet <corbet@lwn.net> Cc: linux-doc@vger.kernel.org Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20230612030810.23376-2-rdunlap@infradead.org
2023-06-16Documentation: virt: correct location of haltpoll module paramsRandy Dunlap1-1/+1
Module parameters are located in sysfs, not debugfs, so correct the statement. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Marcelo Tosatti <mtosatti@redhat.com> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20230610054302.6223-1-rdunlap@infradead.org Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2023-06-16Documentation/mm: Initial page table documentationLinus Walleij1-0/+149
This is based on an earlier blog post at people.kernel.org, it describes the concepts about page tables that were hardest for me to grasp when dealing with them for the first time, such as the prevalent three-letter acronyms pfn, pgd, p4d, pud, pmd and pte. I don't know if this is what people want, but it's what I would have wanted. The wording, introduction, choice of initial subjects and choice of style is mine. I discussed at one point with Mike Rapoport to bring this into the kernel documentation, so here is a small proposal. The current form is augmented in response to feedback from Mike Rapoport, Matthew Wilcox, Jonathan Cameron, Kuan-Ying Lee, Randy Dunlap and Bagas Sanjaya. Cc: Matthew Wilcox <willy@infradead.org> Reviewed-by: Mike Rapoport <rppt@kernel.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://people.kernel.org/linusw/arm32-page-tables Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20230614072548.996940-1-linus.walleij@linaro.org
2023-06-09docs: crypto: async-tx-api: fix typo in struct nameBaruch Siach1-1/+1
Add missing underscore. Signed-off-by: Baruch Siach <baruch@tkos.co.il> Link: https://lore.kernel.org/r/2ef9dfaa33c1eff019e6fe43fe738700c2230b3d.1685342291.git.baruch@tkos.co.il Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2023-06-09docs/doc-guide: Clarify how to write tablesJoe Stringer1-1/+10
Prior to this commit, the kernel docs writing guide spent over a page describing exactly how *not* to write tables into the kernel docs, without providing a example about the desired format. This patch provides a positive example first in the guide so that it's harder to miss, then leaves the existing less desirable approach below for contributors to follow if they have some stronger justification for why to use that approach. Signed-off-by: Joe Stringer <joe@isovalent.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20230424171850.3612317-1-joe@isovalent.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2023-06-09docs: handling-regressions: rework section about fixing proceduresThorsten Leemhuis1-82/+126
This basically rewrites the 'Prioritize work on fixing regressions' section of Documentation/process/handling-regressions.rst for various reasons. Among them: some things were too demanding, some didn't align well with the usual workflows, and some apparently were not clear enough -- and of course a few things were missing that would be good to have in there. Linus for example recently stated that regressions introduced during the past year should be handled similarly to regressions from the current cycle, if it's a clear fix with no semantic subtlety. His exact wording[1] didn't fit well into the text structure, but the author tried to stick close to the apparent intention. It was a noble goal from the original author to state "[prevent situations that might force users to] continue running an outdated and thus potentially insecure kernel version for more than two weeks after a regression's culprit was identified"; this directly led to the goal "fix regression in mainline within one week, if the issue made it into a stable/longterm kernel", because the stable team needs time to pick up and prepare a new release. But apparently all that was a bit too demanding. That "one week" target for example doesn't align well with the usual habits of the subsystem maintainers, which normally send their fixes to Linus once a week; and it doesn't align too well with stable/longterm releases either, which often enter a -rc phase on Mondays or Tuesdays and then are released two to three days later. And asking developers to create, review, and mainline fixes within one week might be too much to ask for in general. Hence tone the general goal down to three weeks and use an approach that better aligns with the usual merging and release habits. While at it, also make the rules of thumb a bit easier to follow by grouping them by topic (e.g. generic things, timing, procedures, ...). Also add text for a few cases where recent discussions showed they need covering. Among them are multiple points that better explain the relations to stable and longterm kernels and the team that manages them; they and the group seperators are the primary reason why this whole section sadly grew somewhat in the rewrite. The group about those relations led to one addition the author came up with without any precedent from Linus: the text now tells developers to add a stable tag for any regression that made it into a proper mainline release during the past 12 months. This is meant to ensure the stable team will definitely notice any fixes for recent regressions. That includes those introduced shortly before a new mainline release and found right after it; without such a rule the stable team might miss the fix, which then would only reach users after weeks or months with later releases. Note, the aspect "Do not consider regressions from the current cycle as something that can wait till the cycle's end [...]" might look like an addition, but was kinda was in the old text as well -- but only indirectly. That apparently was too subtle, as many developers seem to assume waiting till the end of the cycle is fine (even for build fixes). In practice this was especially problematic when a cause of a regression made it into a proper release (either directly or through a backport). A revert performed by Linus shortly before the 6.3 release illustrated that[2], as the developer of the culprit had been willing to revert the culprit about three weeks earlier already -- but didn't do so when a fix came into sight and a maintainer suggested it can wait. Due to that the issue in the end plagued users of 6.2.y at least two weeks longer than necessary, as the fix in the end didn't become ready in time. This issue in fact could have been resolved one or two additional weeks earlier, if the developer had reverted the culprit shortly after it had been identified (which even the old version of the text suggest to do in such cases). [1] https://lore.kernel.org/all/CAHk-=wis_qQy4oDNynNKi5b7Qhosmxtoj1jxo5wmB6SRUwQUBQ@mail.gmail.com/ [2] https://lore.kernel.org/all/CAHk-=wgD98pmSK3ZyHk_d9kZ2bhgN6DuNZMAJaV0WTtbkf=RDw@mail.gmail.com/ CC: Linus Torvalds <torvalds@linux-foundation.org> CC: Greg KH <gregkh@linuxfoundation.org> CC: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/6971680941a5b7b9cb0c2839c75b5cc4ddb2d162.1684139586.git.linux@leemhuis.info Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2023-05-20docs: process: fix a typoed cross-referenceJonathan Corbet1-1/+1
Commit 329ac9af902e added a cross-reference missing a hyphen; add one from my emergency hyphen stash. Reported-by: kernel test robot <lkp@intel.com> Fixes: 329ac9af902e ("docs: submitting-patches: Discuss interleaved replies") Closes: https://lore.kernel.org/oe-kbuild-all/202305201652.POM84URe-lkp@intel.com/ Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2023-05-19docs: submitting-patches: Discuss interleaved repliesKees Cook2-3/+29
Top-posting has been strongly discouraged in Linux development, but this was actually not written anywhere in the common documentation about sending patches and replying to reviews. Add a section about trimming and interleaved replies. Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20230511184131.gonna.399-kees@kernel.org
2023-05-19MAINTAINERS: direct process doc changes to a dedicated MLJakub Kicinski1-0/+6
It's hard to keep track of changes to the process docs. Subsystem maintainers should probably know what's going on, to ensure reasonably uniform developer experience across trees. We also need a place where process discussions can be held (i.e. designated mailing list which can be CCed on naturally arising discussions). I'm using workflows@ in this RFC, but a new list may be better. No change to the patch flow intended. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20230511020204.910178-1-kuba@kernel.org
2023-05-19Documentation: core-api: Add error pointer functions to kernel-apiJames Seo1-0/+6
Bring the error pointer functions (e.g. ERR_PTR(), PTR_ERR()) into the docs build so that they can be cross-referenced elsewhere. List them as kernel library functions in the kernel-api document. Nowhere else seems to fit, and they need to go *somewhere*. Signed-off-by: James Seo <james@equiv.tech> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20230509175543.2065835-4-james@equiv.tech
2023-05-19err.h: Add missing kerneldocs for error pointer functionsJames Seo1-0/+48
Add kerneldocs for ERR_PTR(), PTR_ERR(), PTR_ERR_OR_ZERO(), IS_ERR(), and IS_ERR_OR_NULL(). Doing so will help convert hundreds of mentions of them in existing documentation into automatic cross-references. Also add kerneldocs for IS_ERR_VALUE(). Doing so adds no automatic cross-references, but this macro has a slightly different use case than the functionally similar IS_ERR(), and documenting it may be helpful to readers who encounter it in existing code. ERR_CAST() already has kerneldocs and has not been touched. Signed-off-by: James Seo <james@equiv.tech> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20230509175543.2065835-3-james@equiv.tech
2023-05-19Documentation: conf.py: Add __force to c_id_attributesJames Seo1-0/+1
Fixes the following error in the docs build that occurs with recent versions of Sphinx when parsing kerneldocs for a function with the '__force' macro in its signature: ./include/linux/err.h:51: WARNING: Error in declarator or parameters Error in declarator or parameters Invalid C declaration: Expected identifier, got keyword: void [error at 35] void * ERR_CAST (__force const void *ptr) -----------------------------------^ Currently, almost all of the few in-signature occurrences of '__force' are in the error pointer functions. Of those, ERR_CAST() is the only one with kerneldocs, but the kerneldocs aren't even being used to generate documentation. This change will allow all the error pointer functions to be properly documented. In addition to '__force', <linux/compiler_types.h> also defines '__nocast', '__safe', and '__private'. These are not currently used in any function signatures and do not need to be added to the docs config. Signed-off-by: James Seo <james@equiv.tech> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20230509175543.2065835-2-james@equiv.tech
2023-05-19docs: clarify KVM related kernel parameters' descriptionsYan-Jie Wang1-24/+29
The descriptions of certain KVM related kernel parameters can be confusing. They state "Disable ...," which may make people think that setting them to 1 will disable the associated feature when in fact the opposite is true. This commit addresses this issue by revising the descriptions of these parameters by using "Control..." rather than "Enable/Disable...". 1==enabled or 0==disabled can be communicated by the description of default value such as "1 (enabled)" or "0 (disabled)". Also update the description of KVM's default value for kvm-intel.nested as it is enabled by default. Signed-off-by: Yan-Jie Wang <yanjiewtw@gmail.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20230503081530.19956-1-yanjiewtw@gmail.com
2023-05-19docs: consolidate human interface subsystemsCosta Shulyupin1-5/+12
to make the page more organized as requested Signed-off-by: Costa Shulyupin <costa.shul@redhat.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20230502015040.329394-1-costa.shul@redhat.com
2023-05-19docs: admin-guide: Add information about intel_pstate active modeNatesh Sharma1-0/+10
Information about intel_pstate active mode is added in the doc. This operation mode could be used to set on the hardware when it's not activated. Status of the mode could be checked from sysfs file i.e., /sys/devices/system/cpu/intel_pstate/status. The information is already available in cpu-freq/intel-pstate.txt documentation. Signed-off-by: Natesh Sharma <nsharma@redhat.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net> [jc: reformatted for width ] Link: https://lore.kernel.org/r/20230427083706.49882-1-nsharma@redhat.com
2023-05-16Documentation/filesystems: ramfs-rootfs-initramfs: use :Author:Randy Dunlap1-2/+1
Use the :Author: markup instead of making it a chapter heading. This cleans up the table of contents for this file. Fixes: 7f46a240b0a1 ("[PATCH] ramfs, rootfs, and initramfs docs") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Rob Landley <rob@landley.net> Reviewed-by: Christian Brauner <brauner@kernel.org> Link: https://lore.kernel.org/r/20230508055928.3548-1-rdunlap@infradead.org Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2023-05-16Documentation/filesystems: sharedsubtree: add section headingsRandy Dunlap1-0/+4
Several of the sections are missing underlines. This makes the generated contents have missing entries, so add the underlines. Fixes: 16c01b20ae05 ("doc/filesystems: more mount cleanups") Fixes: 9cfcceea8f7e ("[PATCH] Complete description of shared subtrees.") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Christian Brauner <brauner@kernel.org> Link: https://lore.kernel.org/r/20230508055938.6550-1-rdunlap@infradead.org Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2023-05-16docs: quickly-build-trimmed-linux: various small fixes and improvementsThorsten Leemhuis1-22/+27
* improve the short description of localmodconfig in the step-by-step guide while fixing its broken first sentence * briefly mention immutable Linux distributions * use '--shallow-exclude=v6.0' throughout the document * instead of "git reset --hard; git checkout ..." use "git checkout --force ..." in the step-by-step guide: this matches the TLDR and is one command less to execute. This led to a few small adjustments to the text and the flow in the surrounding area. * fix two thinkos in the section explaining full git clones Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info> Link: https://lore.kernel.org/r/6f4684b9a5d11d3adb04e0af3cfc60db8b28eeb2.1684140700.git.linux@leemhuis.info Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2023-05-16Documentation: use capitalization for chapters and acronymsRandy Dunlap6-8/+8
Use capital letters in acronyms for CD-ROM, FPGA, and PCMCIA. Use capital letter in the first word of chapter headings for Locking, Timers, and "Brief tutorial on CRC computation". Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Moritz Fischer <mdf@kernel.org> Cc: Wu Hao <hao.wu@intel.com> Cc: Tom Rix <trix@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Will Deacon <will@kernel.org> Cc: Waiman Long <longman@redhat.com> Cc: Boqun Feng <boqun.feng@gmail.com> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: Thomas Gleixner <tglx@linutronix.de> Acked-by: Xu Yilun <yilun.xu@intel.com> Reviewed-by: Phillip Potter <phil@philpotter.co.uk> Link: https://lore.kernel.org/r/20230516001518.14514-1-rdunlap@infradead.org Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2023-05-14Linux 6.4-rc2Linus Torvalds1-1/+1
2023-05-14parisc: Fix encoding of swp_entry due to added SWP_EXCLUSIVE flagHelge Deller1-4/+4
Fix the __swp_offset() and __swp_entry() macros due to commit 6d239fc78c0b ("parisc/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE") which introduced the SWP_EXCLUSIVE flag by reusing the _PAGE_ACCESSED flag. Reported-by: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de> Tested-by: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Helge Deller <deller@gmx.de> Fixes: 6d239fc78c0b ("parisc/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE") Cc: <stable@vger.kernel.org> # v6.3+
2023-05-13ext4: bail out of ext4_xattr_ibody_get() fails for any reasonTheodore Ts'o1-1/+1
In ext4_update_inline_data(), if ext4_xattr_ibody_get() fails for any reason, it's best if we just fail as opposed to stumbling on, especially if the failure is EFSCORRUPTED. Cc: stable@kernel.org Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-05-13ext4: add bounds checking in get_max_inline_xattr_value_size()Theodore Ts'o1-1/+11
Normally the extended attributes in the inode body would have been checked when the inode is first opened, but if someone is writing to the block device while the file system is mounted, it's possible for the inode table to get corrupted. Add bounds checking to avoid reading beyond the end of allocated memory if this happens. Reported-by: syzbot+1966db24521e5f6e23f7@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=1966db24521e5f6e23f7 Cc: stable@kernel.org Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-05-13ext4: add indication of ro vs r/w mounts in the mount messageTheodore Ts'o1-4/+6
Whether the file system is mounted read-only or read/write is more important than the quota mode, which we are already printing. Add the ro vs r/w indication since this can be helpful in debugging problems from the console log. Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-05-13ext4: fix deadlock when converting an inline directory in nojournal modeTheodore Ts'o1-1/+2
In no journal mode, ext4_finish_convert_inline_dir() can self-deadlock by calling ext4_handle_dirty_dirblock() when it already has taken the directory lock. There is a similar self-deadlock in ext4_incvert_inline_data_nolock() for data files which we'll fix at the same time. A simple reproducer demonstrating the problem: mke2fs -Fq -t ext2 -O inline_data -b 4k /dev/vdc 64 mount -t ext4 -o dirsync /dev/vdc /vdc cd /vdc mkdir file0 cd file0 touch file0 touch file1 attr -s BurnSpaceInEA -V abcde . touch supercalifragilisticexpialidocious Cc: stable@kernel.org Link: https://lore.kernel.org/r/20230507021608.1290720-1-tytso@mit.edu Reported-by: syzbot+91dccab7c64e2850a4e5@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?id=ba84cc80a9491d65416bc7877e1650c87530fe8a Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-05-13ext4: improve error recovery code paths in __ext4_remount()Theodore Ts'o1-3/+10
If there are failures while changing the mount options in __ext4_remount(), we need to restore the old mount options. This commit fixes two problem. The first is there is a chance that we will free the old quota file names before a potential failure leading to a use-after-free. The second problem addressed in this commit is if there is a failed read/write to read-only transition, if the quota has already been suspended, we need to renable quota handling. Cc: stable@kernel.org Link: https://lore.kernel.org/r/20230506142419.984260-2-tytso@mit.edu Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-05-13ext4: improve error handling from ext4_dirhash()Theodore Ts'o2-17/+42
The ext4_dirhash() will *almost* never fail, especially when the hash tree feature was first introduced. However, with the addition of support of encrypted, casefolded file names, that function can most certainly fail today. So make sure the callers of ext4_dirhash() properly check for failures, and reflect the errors back up to their callers. Cc: stable@kernel.org Link: https://lore.kernel.org/r/20230506142419.984260-1-tytso@mit.edu Reported-by: syzbot+394aa8a792cb99dbc837@syzkaller.appspotmail.com Reported-by: syzbot+344aaa8697ebd232bfc8@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?id=db56459ea4ac4a676ae4b4678f633e55da005a9b Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-05-13ext4: don't clear SB_RDONLY when remounting r/w until quota is re-enabledTheodore Ts'o1-1/+5
When a file system currently mounted read/only is remounted read/write, if we clear the SB_RDONLY flag too early, before the quota is initialized, and there is another process/thread constantly attempting to create a directory, it's possible to trigger the WARN_ON_ONCE(dquot_initialize_needed(inode)); in ext4_xattr_block_set(), with the following stack trace: WARNING: CPU: 0 PID: 5338 at fs/ext4/xattr.c:2141 ext4_xattr_block_set+0x2ef2/0x3680 RIP: 0010:ext4_xattr_block_set+0x2ef2/0x3680 fs/ext4/xattr.c:2141 Call Trace: ext4_xattr_set_handle+0xcd4/0x15c0 fs/ext4/xattr.c:2458 ext4_initxattrs+0xa3/0x110 fs/ext4/xattr_security.c:44 security_inode_init_security+0x2df/0x3f0 security/security.c:1147 __ext4_new_inode+0x347e/0x43d0 fs/ext4/ialloc.c:1324 ext4_mkdir+0x425/0xce0 fs/ext4/namei.c:2992 vfs_mkdir+0x29d/0x450 fs/namei.c:4038 do_mkdirat+0x264/0x520 fs/namei.c:4061 __do_sys_mkdirat fs/namei.c:4076 [inline] __se_sys_mkdirat fs/namei.c:4074 [inline] __x64_sys_mkdirat+0x89/0xa0 fs/namei.c:4074 Cc: stable@kernel.org Link: https://lore.kernel.org/r/20230506142419.984260-1-tytso@mit.edu Reported-by: syzbot+6385d7d3065524c5ca6d@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?id=6513f6cb5cd6b5fc9f37e3bb70d273b94be9c34c Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-05-13ext4: check iomap type only if ext4_iomap_begin() does not failBaokun Li1-1/+1
When ext4_iomap_overwrite_begin() calls ext4_iomap_begin() map blocks may fail for some reason (e.g. memory allocation failure, bare disk write), and later because "iomap->type ! = IOMAP_MAPPED" triggers WARN_ON(). When ext4 iomap_begin() returns an error, it is normal that the type of iomap->type may not match the expectation. Therefore, we only determine if iomap->type is as expected when ext4_iomap_begin() is executed successfully. Cc: stable@kernel.org Reported-by: syzbot+08106c4b7d60702dbc14@syzkaller.appspotmail.com Link: https://lore.kernel.org/all/00000000000015760b05f9b4eee9@google.com Signed-off-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20230505132429.714648-1-libaokun1@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-05-13ext4: avoid a potential slab-out-of-bounds in ext4_group_desc_csumTudor Ambarus1-4/+2
When modifying the block device while it is mounted by the filesystem, syzbot reported the following: BUG: KASAN: slab-out-of-bounds in crc16+0x206/0x280 lib/crc16.c:58 Read of size 1 at addr ffff888075f5c0a8 by task syz-executor.2/15586 CPU: 1 PID: 15586 Comm: syz-executor.2 Not tainted 6.2.0-rc5-syzkaller-00205-gc96618275234 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x290 lib/dump_stack.c:106 print_address_description+0x74/0x340 mm/kasan/report.c:306 print_report+0x107/0x1f0 mm/kasan/report.c:417 kasan_report+0xcd/0x100 mm/kasan/report.c:517 crc16+0x206/0x280 lib/crc16.c:58 ext4_group_desc_csum+0x81b/0xb20 fs/ext4/super.c:3187 ext4_group_desc_csum_set+0x195/0x230 fs/ext4/super.c:3210 ext4_mb_clear_bb fs/ext4/mballoc.c:6027 [inline] ext4_free_blocks+0x191a/0x2810 fs/ext4/mballoc.c:6173 ext4_remove_blocks fs/ext4/extents.c:2527 [inline] ext4_ext_rm_leaf fs/ext4/extents.c:2710 [inline] ext4_ext_remove_space+0x24ef/0x46a0 fs/ext4/extents.c:2958 ext4_ext_truncate+0x177/0x220 fs/ext4/extents.c:4416 ext4_truncate+0xa6a/0xea0 fs/ext4/inode.c:4342 ext4_setattr+0x10c8/0x1930 fs/ext4/inode.c:5622 notify_change+0xe50/0x1100 fs/attr.c:482 do_truncate+0x200/0x2f0 fs/open.c:65 handle_truncate fs/namei.c:3216 [inline] do_open fs/namei.c:3561 [inline] path_openat+0x272b/0x2dd0 fs/namei.c:3714 do_filp_open+0x264/0x4f0 fs/namei.c:3741 do_sys_openat2+0x124/0x4e0 fs/open.c:1310 do_sys_open fs/open.c:1326 [inline] __do_sys_creat fs/open.c:1402 [inline] __se_sys_creat fs/open.c:1396 [inline] __x64_sys_creat+0x11f/0x160 fs/open.c:1396 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f72f8a8c0c9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f72f97e3168 EFLAGS: 00000246 ORIG_RAX: 0000000000000055 RAX: ffffffffffffffda RBX: 00007f72f8bac050 RCX: 00007f72f8a8c0c9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000020000280 RBP: 00007f72f8ae7ae9 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffd165348bf R14: 00007f72f97e3300 R15: 0000000000022000 Replace le16_to_cpu(sbi->s_es->s_desc_size) with sbi->s_desc_size It reduces ext4's compiled text size, and makes the code more efficient (we remove an extra indirect reference and a potential byte swap on big endian systems), and there is no downside. It also avoids the potential KASAN / syzkaller failure, as a bonus. Reported-by: syzbot+fc51227e7100c9294894@syzkaller.appspotmail.com Reported-by: syzbot+8785e41224a3afd04321@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?id=70d28d11ab14bd7938f3e088365252aa923cff42 Link: https://syzkaller.appspot.com/bug?id=b85721b38583ecc6b5e72ff524c67302abbc30f3 Link: https://lore.kernel.org/all/000000000000ece18705f3b20934@google.com/ Fixes: 717d50e4971b ("Ext4: Uninitialized Block Groups") Cc: stable@vger.kernel.org Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://lore.kernel.org/r/20230504121525.3275886-1-tudor.ambarus@linaro.org Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-05-13ext4: fix data races when using cached status extentsJan Kara1-17/+13
When using cached extent stored in extent status tree in tree->cache_es another process holding ei->i_es_lock for reading can be racing with us setting new value of tree->cache_es. If the compiler would decide to refetch tree->cache_es at an unfortunate moment, it could result in a bogus in_range() check. Fix the possible race by using READ_ONCE() when using tree->cache_es only under ei->i_es_lock for reading. Cc: stable@kernel.org Reported-by: syzbot+4a03518df1e31b537066@syzkaller.appspotmail.com Link: https://lore.kernel.org/all/000000000000d3b33905fa0fd4a6@google.com Suggested-by: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20230504125524.10802-1-jack@suse.cz Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-05-13ext4: avoid deadlock in fs reclaim with page writebackJan Kara3-13/+40
Ext4 has a filesystem wide lock protecting ext4_writepages() calls to avoid races with switching of journalled data flag or inode format. This lock can however cause a deadlock like: CPU0 CPU1 ext4_writepages() percpu_down_read(sbi->s_writepages_rwsem); ext4_change_inode_journal_flag() percpu_down_write(sbi->s_writepages_rwsem); - blocks, all readers block from now on ext4_do_writepages() ext4_init_io_end() kmem_cache_zalloc(io_end_cachep, GFP_KERNEL) fs_reclaim frees dentry... dentry_unlink_inode() iput() - last ref => iput_final() - inode dirty => write_inode_now()... ext4_writepages() tries to acquire sbi->s_writepages_rwsem and blocks forever Make sure we cannot recurse into filesystem reclaim from writeback code to avoid the deadlock. Reported-by: syzbot+6898da502aef574c5f8a@syzkaller.appspotmail.com Link: https://lore.kernel.org/all/0000000000004c66b405fa108e27@google.com Fixes: c8585c6fcaf2 ("ext4: fix races between changing inode journal mode and ext4_writepages") CC: stable@vger.kernel.org Signed-off-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20230504124723.20205-1-jack@suse.cz Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-05-13ext4: fix invalid free tracking in ext4_xattr_move_to_block()Theodore Ts'o1-2/+3
In ext4_xattr_move_to_block(), the value of the extended attribute which we need to move to an external block may be allocated by kvmalloc() if the value is stored in an external inode. So at the end of the function the code tried to check if this was the case by testing entry->e_value_inum. However, at this point, the pointer to the xattr entry is no longer valid, because it was removed from the original location where it had been stored. So we could end up calling kvfree() on a pointer which was not allocated by kvmalloc(); or we could also potentially leak memory by not freeing the buffer when it should be freed. Fix this by storing whether it should be freed in a separate variable. Cc: stable@kernel.org Link: https://lore.kernel.org/r/20230430160426.581366-1-tytso@mit.edu Link: https://syzkaller.appspot.com/bug?id=5c2aee8256e30b55ccf57312c16d88417adbd5e1 Link: https://syzkaller.appspot.com/bug?id=41a6b5d4917c0412eb3b3c3c604965bed7d7420b Reported-by: syzbot+64b645917ce07d89bde5@syzkaller.appspotmail.com Reported-by: syzbot+0d042627c4f2ad332195@syzkaller.appspotmail.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-05-13ext4: remove a BUG_ON in ext4_mb_release_group_pa()Theodore Ts'o1-1/+5
If a malicious fuzzer overwrites the ext4 superblock while it is mounted such that the s_first_data_block is set to a very large number, the calculation of the block group can underflow, and trigger a BUG_ON check. Change this to be an ext4_warning so that we don't crash the kernel. Cc: stable@kernel.org Link: https://lore.kernel.org/r/20230430154311.579720-3-tytso@mit.edu Reported-by: syzbot+e2efa3efc15a1c9e95c3@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?id=69b28112e098b070f639efb356393af3ffec4220 Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-05-13ext4: allow ext4_get_group_info() to failTheodore Ts'o5-29/+82
Previously, ext4_get_group_info() would treat an invalid group number as BUG(), since in theory it should never happen. However, if a malicious attaker (or fuzzer) modifies the superblock via the block device while it is the file system is mounted, it is possible for s_first_data_block to get set to a very large number. In that case, when calculating the block group of some block number (such as the starting block of a preallocation region), could result in an underflow and very large block group number. Then the BUG_ON check in ext4_get_group_info() would fire, resutling in a denial of service attack that can be triggered by root or someone with write access to the block device. For a quality of implementation perspective, it's best that even if the system administrator does something that they shouldn't, that it will not trigger a BUG. So instead of BUG'ing, ext4_get_group_info() will call ext4_error and return NULL. We also add fallback code in all of the callers of ext4_get_group_info() that it might NULL. Also, since ext4_get_group_info() was already borderline to be an inline function, un-inline it. The results in a next reduction of the compiled text size of ext4 by roughly 2k. Cc: stable@kernel.org Link: https://lore.kernel.org/r/20230430154311.579720-2-tytso@mit.edu Reported-by: syzbot+e2efa3efc15a1c9e95c3@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?id=69b28112e098b070f639efb356393af3ffec4220 Signed-off-by: Theodore Ts'o <tytso@mit.edu> Reviewed-by: Jan Kara <jack@suse.cz>
2023-05-13cxl: Add missing return to cdat read error pathDave Jiang1-0/+1
Add a return to the error path when cxl_cdat_read_table() fails. Current code continues with the table pointer points to freed memory. Fixes: 7a877c923995 ("cxl/pci: Simplify CDAT retrieval error path") Signed-off-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Davidlohr Bueso <dave@stgolabs.net> Link: https://lore.kernel.org/r/168382793506.3510737.4792518576623749076.stgit@djiang5-mobl3 Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-05-13tools/testing/cxl: Use DEFINE_STATIC_SRCU()Dan Williams1-1/+1
Starting with commit: 95433f726301 ("srcu: Begin offloading srcu_struct fields to srcu_update") ...it is no longer possible to do: static DEFINE_SRCU(x) Switch to DEFINE_STATIC_SRCU(x) to fix: tools/testing/cxl/test/mock.c:22:1: error: duplicate ‘static’ 22 | static DEFINE_SRCU(cxl_mock_srcu); | ^~~~~~ Reviewed-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/168392709546.1135523.10424917245934547117.stgit@dwillia2-xfh.jf.intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-05-12x86/retbleed: Fix return thunk alignmentBorislav Petkov (AMD)1-2/+2
SYM_FUNC_START_LOCAL_NOALIGN() adds an endbr leading to this layout (leaving only the last 2 bytes of the address): 3bff <zen_untrain_ret>: 3bff: f3 0f 1e fa endbr64 3c03: f6 test $0xcc,%bl 3c04 <__x86_return_thunk>: 3c04: c3 ret 3c05: cc int3 3c06: 0f ae e8 lfence However, "the RET at __x86_return_thunk must be on a 64 byte boundary, for alignment within the BTB." Use SYM_START instead. Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Cc: <stable@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2023-05-12Documentation/block: drop the request.rst fileRandy Dunlap2-100/+0
Documentation/block/request.rst is outdated and should be removed. Also delete its entry in the block/index.rst file. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Jens Axboe <axboe@kernel.dk> Cc: linux-block@vger.kernel.org Cc: Jonathan Corbet <corbet@lwn.net> Cc: linux-doc@vger.kernel.org Link: https://lore.kernel.org/r/20230507182606.12647-1-rdunlap@infradead.org Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-05-12pipe: check for IOCB_NOWAIT alongside O_NONBLOCKJens Axboe1-2/+4
Pipe reads or writes need to enable nonblocking attempts, if either O_NONBLOCK is set on the file, or IOCB_NOWAIT is set in the iocb being passed in. The latter isn't currently true, ensure we check for both before waiting on data or space. Fixes: afed6271f5b0 ("pipe: set FMODE_NOWAIT on pipes") Signed-off-by: Jens Axboe <axboe@kernel.dk> Message-Id: <e5946d67-4e5e-b056-ba80-656bab12d9f6@kernel.dk> Signed-off-by: Christian Brauner <brauner@kernel.org>
2023-05-12ublk: fix command op code checkMing Lei1-1/+1
In case of CONFIG_BLKDEV_UBLK_LEGACY_OPCODES, type of cmd opcode could be 0 or 'u'; and type can only be 'u' if CONFIG_BLKDEV_UBLK_LEGACY_OPCODES isn't set. So fix the wrong check. Fixes: 2d786e66c966 ("block: ublk: switch to ioctl command encoding") Signed-off-by: Ming Lei <ming.lei@redhat.com> Link: https://lore.kernel.org/r/20230505153142.1258336-1-ming.lei@redhat.com Signed-off-by: Jens Axboe <axboe@kernel.dk>