aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/tools/perf/scripts/python/exported-sql-viewer.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2022-08-11docs: i2c: i2c-sysfs: improve wordingLuca Ceresoli1-5/+4
Improve wording in a couple sentences. Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> [wsa: improved a little more] Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-08-11docs: i2c: instantiating-devices: add syntax coloring to dts and C blocksLuca Ceresoli1-4/+12
These blocks can be nicely coloured via Sphinx. Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-08-11docs: i2c: smbus-protocol: improve DataLow/DataHigh definitionLuca Ceresoli1-2/+2
Use a more professional wording. Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-08-11docs: i2c: i2c-protocol: remove unused legend itemsLuca Ceresoli1-5/+1
"Comm", "Count", "DataLow", "DataHigh" are not used in this section. Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-08-11docs: i2c: i2c-protocol,smbus-protocol: remove nonsense wordsLuca Ceresoli2-2/+2
"as usual" does not mean much here, especially as these are introductory sections and 10-bit addressing hasn't been introduced yet. Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-08-11docs: i2c: i2c-protocol: update introductory paragraphLuca Ceresoli1-1/+2
This sentence dates back to the pre-git era and it does not look very professional... As there is no clear definition of "finished", and given this page is already a pretty good overview, not to mention it is not the kernel responsibility to document the protocol in detail, let's update the text accordingly. Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-08-11i2c: move core from strlcpy to strscpyWolfram Sang2-2/+2
Follow the advice of the below link and prefer 'strscpy'. Conversion is easy because no code used the return value. It has been done with a simple sed invocation. Link: https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmknw@mail.gmail.com/ Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-08-11i2c: move drivers from strlcpy to strscpyWolfram Sang47-49/+49
Follow the advice of the below link and prefer 'strscpy'. Conversion is easy because no driver used the return value and has been done with a simple sed invocation. Link: https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmknw@mail.gmail.com/ Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-08-11i2c: kempld: Support ACPI I2C device declarationChris Pringle1-0/+1
Adds an ACPI companion to the KEMPLD I2C driver so that it correctly detects any I2C devices nested under the KEMPLD's ACPI node (SBRG.CPLD). This allows I2C devices attached to the KEMPLD I2C adapter to be declared and instantiated via ACPI. Signed-off-by: Chris Pringle <chris.pringle@phabrix.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-08-11i2c: mediatek: add i2c compatible for MT8188Kewei Xu1-0/+43
Add i2c compatible for MT8188 and added mt_i2c_regs_v3[], since MT8188 i2c OFFSET_SLAVE_ADDR register changed from 0x04 to 0x94. Signed-off-by: Kewei Xu <kewei.xu@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Qii Wang <qii.wang@mediatek.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-08-11dt-bindings: i2c: update bindings for mt8188 socKewei Xu1-0/+1
Add a DT binding documentation for the mt8188 soc. Signed-off-by: Kewei Xu <kewei.xu@mediatek.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Qii Wang <qii.wang@mediatek.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-08-11i2c: microchip-corei2c: fix erroneous late ack sendConor Dooley1-1/+1
A late ack is currently being sent at the end of a transfer due to incorrect logic in mchp_corei2c_empty_rx(). Currently the Assert Ack bit is being written to the controller's control reg after the last byte has been received, causing it to sent another byte with the ack. Instead, the AA flag should be written to the control register when the penultimate byte is read so it is sent out for the last byte. Reported-by: Andreas Buerkler <andreas.buerkler@enclustra.com> Fixes: 64a6f1c4987e ("i2c: add support for microchip fpga i2c controllers") Tested-by: Lewis Hanly <lewis.hanly@microchip.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> [wsa: fixed typos in commit message] Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-08-11dt-bindings: i2c: qcom,i2c-cci: convert to dtschemaKrzysztof Kozlowski3-97/+243
Convert the Qualcomm Camera Control Interface (CCI) I2C controller to DT schema. The original bindings were not complete, so this includes changes: 1. Add address/size-cells. 2. Describe the clocks per variant. 3. Use more descriptive example based on sdm845. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-08-11i2c: qcom-geni: Fix GPI DMA buffer sync-backRobin Reckmann1-2/+3
Fix i2c transfers using GPI DMA mode for all message types that do not set the I2C_M_DMA_SAFE flag (e.g. SMBus "read byte"). In this case a bounce buffer is returned by i2c_get_dma_safe_msg_buf(), and it has to synced back to the message after the transfer is done. Add missing assignment of dma buffer in geni_i2c_gpi(). Set xferred in i2c_put_dma_safe_msg_buf() to true in case of no error to ensure the sync-back of this dma buffer to the message. Fixes: d8703554f4de ("i2c: qcom-geni: Add support for GPI DMA") Signed-off-by: Robin Reckmann <robin.reckmann@gmail.com> Tested-by: Luca Weiss <luca.weiss@fairphone.com> Tested-by: Caleb Connolly <caleb@connolly.tech> Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-08-10x86: link vdso and boot with -z noexecstack --no-warn-rwx-segmentsNick Desaulniers3-2/+6
Users of GNU ld (BFD) from binutils 2.39+ will observe multiple instances of a new warning when linking kernels in the form: ld: warning: arch/x86/boot/pmjump.o: missing .note.GNU-stack section implies executable stack ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker ld: warning: arch/x86/boot/compressed/vmlinux has a LOAD segment with RWX permissions Generally, we would like to avoid the stack being executable. Because there could be a need for the stack to be executable, assembler sources have to opt-in to this security feature via explicit creation of the .note.GNU-stack feature (which compilers create by default) or command line flag --noexecstack. Or we can simply tell the linker the production of such sections is irrelevant and to link the stack as --noexecstack. LLVM's LLD linker defaults to -z noexecstack, so this flag isn't strictly necessary when linking with LLD, only BFD, but it doesn't hurt to be explicit here for all linkers IMO. --no-warn-rwx-segments is currently BFD specific and only available in the current latest release, so it's wrapped in an ld-option check. While the kernel makes extensive usage of ELF sections, it doesn't use permissions from ELF segments. Link: https://lore.kernel.org/linux-block/3af4127a-f453-4cf7-f133-a181cce06f73@kernel.dk/ Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=ba951afb99912da01a6e8434126b8fac7aa75107 Link: https://github.com/llvm/llvm-project/issues/57009 Reported-and-tested-by: Jens Axboe <axboe@kernel.dk> Suggested-by: Fangrui Song <maskray@google.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-08-10Makefile: link with -z noexecstack --no-warn-rwx-segmentsNick Desaulniers1-0/+5
Users of GNU ld (BFD) from binutils 2.39+ will observe multiple instances of a new warning when linking kernels in the form: ld: warning: vmlinux: missing .note.GNU-stack section implies executable stack ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker ld: warning: vmlinux has a LOAD segment with RWX permissions Generally, we would like to avoid the stack being executable. Because there could be a need for the stack to be executable, assembler sources have to opt-in to this security feature via explicit creation of the .note.GNU-stack feature (which compilers create by default) or command line flag --noexecstack. Or we can simply tell the linker the production of such sections is irrelevant and to link the stack as --noexecstack. LLVM's LLD linker defaults to -z noexecstack, so this flag isn't strictly necessary when linking with LLD, only BFD, but it doesn't hurt to be explicit here for all linkers IMO. --no-warn-rwx-segments is currently BFD specific and only available in the current latest release, so it's wrapped in an ld-option check. While the kernel makes extensive usage of ELF sections, it doesn't use permissions from ELF segments. Link: https://lore.kernel.org/linux-block/3af4127a-f453-4cf7-f133-a181cce06f73@kernel.dk/ Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=ba951afb99912da01a6e8434126b8fac7aa75107 Link: https://github.com/llvm/llvm-project/issues/57009 Reported-and-tested-by: Jens Axboe <axboe@kernel.dk> Suggested-by: Fangrui Song <maskray@google.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-08-10crypto: blake2b: effectively disable frame size warningLinus Torvalds1-0/+1
It turns out that gcc-12.1 has some nasty problems with register allocation on a 32-bit x86 build for the 64-bit values used in the generic blake2b implementation, where the pattern of 64-bit rotates and xor operations ends up making gcc generate horrible code. As a result it ends up with a ridiculously large stack frame for all the spills it generates, resulting in the following build problem: crypto/blake2b_generic.c: In function ‘blake2b_compress_one_generic’: crypto/blake2b_generic.c:109:1: error: the frame size of 2640 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] on the same test-case, clang ends up generating a stack frame that is just 296 bytes (and older gcc versions generate a slightly bigger one at 428 bytes - still nowhere near that almost 3kB monster stack frame of gcc-12.1). The issue is fixed both in mainline and the GCC 12 release branch [1], but current release compilers end up failing the i386 allmodconfig build due to this issue. Disable the warning for now by simply raising the frame size for this one file, just to keep this issue from having people turn off WERROR. Link: https://lore.kernel.org/all/CAHk-=wjxqgeG2op+=W9sqgsWqCYnavC+SRfVyopu9-31S6xw+Q@mail.gmail.com/ Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105930 [1] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-08-10hwmon: (nct6775) Fix platform driver suspend regressionZev Weiss3-2/+5
Commit c3963bc0a0cf ("hwmon: (nct6775) Split core and platform driver") introduced a slight change in nct6775_suspend() in order to avoid an otherwise-needless symbol export for nct6775_update_device(), replacing a call to that function with a simple dev_get_drvdata() instead. As it turns out, there is no guarantee that nct6775_update_device() is ever called prior to suspend. If this happens, the resume function ends up writing bad data into the various chip registers, which results in a crash shortly after resume. To fix the problem, just add the symbol export and return to using nct6775_update_device() as was employed previously. Reported-by: Zoltán Kővágó <dirty.ice.hu@gmail.com> Tested-by: Zoltán Kővágó <dirty.ice.hu@gmail.com> Fixes: c3963bc0a0cf ("hwmon: (nct6775) Split core and platform driver") Cc: stable@kernel.org Signed-off-by: Zev Weiss <zev@bewilderbeest.net> Link: https://lore.kernel.org/r/20220810052646.13825-1-zev@bewilderbeest.net [groeck: Updated description] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2022-08-10hwmon: (lm90) Fix error return value from detect functionGuenter Roeck1-1/+1
lm90_detect_nuvoton() is supposed to return NULL if it can not detect a chip, or a pointer to the chip name if it does. Under some circumstances it returns an error pointer instead. Some versions of gcc interpret an ERR_PTR as region of size 0 and generate an error message. In function ‘__fortify_strlen’, inlined from ‘strlcpy’ at ./include/linux/fortify-string.h:159:10, inlined from ‘lm90_detect’ at drivers/hwmon/lm90.c:2550:2: ./include/linux/fortify-string.h:50:33: error: ‘__builtin_strlen’ reading 1 or more bytes from a region of size 0 50 | #define __underlying_strlen __builtin_strlen | ^ ./include/linux/fortify-string.h:141:24: note: in expansion of macro ‘__underlying_strlen’ 141 | return __underlying_strlen(p); | ^~~~~~~~~~~~~~~~~~~ Returning NULL instead of ERR_PTR() fixes the problem. Fixes: c7cebce984a2 ("hwmon: (lm90) Rework detect function") Reported-by: Ingo Molnar <mingo@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Kees Cook <keescook@chromium.org> Tested-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2022-08-09add barriers to buffer_uptodate and set_buffer_uptodateMikulas Patocka1-1/+24
Let's have a look at this piece of code in __bread_slow: get_bh(bh); bh->b_end_io = end_buffer_read_sync; submit_bh(REQ_OP_READ, 0, bh); wait_on_buffer(bh); if (buffer_uptodate(bh)) return bh; Neither wait_on_buffer nor buffer_uptodate contain any memory barrier. Consequently, if someone calls sb_bread and then reads the buffer data, the read of buffer data may be executed before wait_on_buffer(bh) on architectures with weak memory ordering and it may return invalid data. Fix this bug by adding a memory barrier to set_buffer_uptodate and an acquire barrier to buffer_uptodate (in a similar way as folio_test_uptodate and folio_mark_uptodate). Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-08-09dt-bindings: soc: qcom: smd-rpm: extend exampleKrzysztof Kozlowski1-6/+27
Replace existing limited example with proper code for Qualcomm Resource Power Manager (RPM) over SMD based on MSM8916. This also fixes the example's indentation. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220723082358.39544-2-krzysztof.kozlowski@linaro.org
2022-08-09dt-bindings: soc: qcom: smd: reference SMD edge schemaKrzysztof Kozlowski1-1/+1
The child node of smd is an SMD edge representing remote subsystem. Bring back missing reference from previously sent patch (disappeared when applying). Link: https://lore.kernel.org/r/20220517070113.18023-9-krzysztof.kozlowski@linaro.org Fixes: 385fad1303af ("dt-bindings: remoteproc: qcom,smd-edge: define re-usable schema for smd-edge") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220723082358.39544-1-krzysztof.kozlowski@linaro.org
2022-08-09NFS: Improve readpage/writepage tracingTrond Myklebust1-28/+26
Switch formatting to better match that used by other NFS tracepoints. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
2022-08-09NFS: Improve O_DIRECT tracingTrond Myklebust1-12/+9
Switch the formatting to match the other NFS tracepoints. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
2022-08-09NFS: Improve write error tracingTrond Myklebust3-20/+27
Don't leak request pointers, but use the "device:inode" labelling that is used by all the other trace points. Furthermore, replace use of page indexes with an offset, again in order to align behaviour with other NFS trace points. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
2022-08-09fscache: add tracepoint when failing cookieJeff Layton2-0/+4
Signed-off-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: David Howells <dhowells@redhat.com>
2022-08-09fscache: don't leak cookie access refs if invalidation is in progress or failedJeff Layton1-2/+5
It's possible for a request to invalidate a fscache_cookie will come in while we're already processing an invalidation. If that happens we currently take an extra access reference that will leak. Only call __fscache_begin_cookie_access if the FSCACHE_COOKIE_DO_INVALIDATE bit was previously clear. Also, ensure that we attempt to clear the bit when the cookie is "FAILED" and put the reference to avoid an access leak. Fixes: 85e4ea1049c7 ("fscache: Fix invalidation/lookup race") Suggested-by: David Howells <dhowells@redhat.com> Signed-off-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: David Howells <dhowells@redhat.com>
2022-08-08fix copy_page_from_iter() for compound destinationsAl Viro1-4/+18
had been broken for ITER_BVEC et.al. since ever (OK, v3.17 when ITER_BVEC had first appeared)... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2022-08-08hugetlbfs: copy_page_to_iter() can deal with compound pagesAl Viro1-30/+1
... since April 2021 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2022-08-08copy_page_to_iter(): don't split high-order page in case of ITER_PIPEAl Viro1-15/+6
... just shove it into one pipe_buffer. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2022-08-08expand those iov_iter_advance()...Al Viro1-2/+9
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2022-08-08pipe_get_pages(): switch to append_pipe()Al Viro1-29/+6
now that we are advancing the iterator, there's no need to treat the first page separately - just call append_pipe() in a loop. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2022-08-08get rid of non-advancing variantsAl Viro2-31/+20
mechanical change; will be further massaged in subsequent commits Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2022-08-08ceph: switch the last caller of iov_iter_get_pages_alloc()Al Viro1-1/+1
here nothing even looks at the iov_iter after the call, so we couldn't care less whether it advances or not. Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2022-08-089p: convert to advancing variant of iov_iter_get_pages_alloc()Al Viro3-19/+26
that one is somewhat clumsier than usual and needs serious testing. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2022-08-08af_alg_make_sg(): switch to advancing variant of iov_iter_get_pages()Al Viro2-4/+4
... and adjust the callers Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2022-08-08iter_to_pipe(): switch to advancing variant of iov_iter_get_pages()Al Viro1-23/+24
... and untangle the cleanup on failure to add into pipe. Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2022-08-08block: convert to advancing variants of iov_iter_get_pages{,_alloc}()Al Viro2-14/+18
... doing revert if we end up not using some pages Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2022-08-08iov_iter: advancing variants of iov_iter_get_pages{,_alloc}()Al Viro13-30/+34
Most of the users immediately follow successful iov_iter_get_pages() with advancing by the amount it had returned. Provide inline wrappers doing that, convert trivial open-coded uses of those. BTW, iov_iter_get_pages() never returns more than it had been asked to; such checks in cifs ought to be removed someday... Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2022-08-08iov_iter: saner helper for page array allocationAl Viro1-45/+32
All call sites of get_pages_array() are essenitally identical now. Replace with common helper... Returns number of slots available in resulting array or 0 on OOM; it's up to the caller to make sure it doesn't ask to zero-entry array (i.e. neither maxpages nor size are allowed to be zero). Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2022-08-08fold __pipe_get_pages() into pipe_get_pages()Al Viro1-37/+38
... and don't mangle maxsize there - turn the loop into counting one instead. Easier to see that we won't run out of array that way. Note that special treatment of the partial buffer in that thing is an artifact of the non-advancing semantics of iov_iter_get_pages() - if not for that, it would be append_pipe(), same as the body of the loop that follows it. IOW, once we make iov_iter_get_pages() advancing, the whole thing will turn into calculate how many pages do we want allocate an array (if needed) call append_pipe() that many times. Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2022-08-08ITER_XARRAY: don't open-code DIV_ROUND_UP()Al Viro1-9/+1
Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2022-08-08unify the rest of iov_iter_get_pages()/iov_iter_get_pages_alloc() gutsAl Viro1-59/+27
same as for pipes and xarrays; after that iov_iter_get_pages() becomes a wrapper for __iov_iter_get_pages_alloc(). Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2022-08-08unify xarray_get_pages() and xarray_get_pages_alloc()Al Viro1-39/+10
same as for pipes Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2022-08-08unify pipe_get_pages() and pipe_get_pages_alloc()Al Viro1-32/+17
The differences between those two are * pipe_get_pages() gets a non-NULL struct page ** value pointing to preallocated array + array size. * pipe_get_pages_alloc() gets an address of struct page ** variable that contains NULL, allocates the array and (on success) stores its address in that variable. Not hard to combine - always pass struct page ***, have the previous pipe_get_pages_alloc() caller pass ~0U as cap for array size. Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2022-08-08iov_iter_get_pages(): sanity-check argumentsAl Viro1-7/+2
zero maxpages is bogus, but best treated as "just return 0"; NULL pages, OTOH, should be treated as a hard bug. get rid of now completely useless checks in xarray_get_pages{,_alloc}(). Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2022-08-08iov_iter_get_pages_alloc(): lift freeing pages array on failure exits into wrapperAl Viro1-16/+22
Incidentally, ITER_XARRAY did *not* free the sucker in case when iter_xarray_populate_pages() returned 0... Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2022-08-08ITER_PIPE: fold data_start() and pipe_space_for_user() togetherAl Viro2-45/+19
All their callers are next to each other; all of them want the total amount of pages and, possibly, the offset in the partial final buffer. Combine into a new helper (pipe_npages()), fix the bogosity in pipe_space_for_user(), while we are at it. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2022-08-08ITER_PIPE: cache the type of last bufferAl Viro2-40/+42
We often need to find whether the last buffer is anon or not, and currently it's rather clumsy: check if ->iov_offset is non-zero (i.e. that pipe is not empty) if so, get the corresponding pipe_buffer and check its ->ops if it's &default_pipe_buf_ops, we have an anon buffer. Let's replace the use of ->iov_offset (which is nowhere near similar to its role for other flavours) with signed field (->last_offset), with the following rules: empty, no buffers occupied: 0 anon, with bytes up to N-1 filled: N zero-copy, with bytes up to N-1 filled: -N That way abs(i->last_offset) is equal to what used to be in i->iov_offset and empty vs. anon vs. zero-copy can be distinguished by the sign of i->last_offset. Checks for "should we extend the last buffer or should we start a new one?" become easier to follow that way. Note that most of the operations can only be done in a sane state - i.e. when the pipe has nothing past the current position of iterator. About the only thing that could be done outside of that state is iov_iter_advance(), which transitions to the sane state by truncating the pipe. There are only two cases where we leave the sane state: 1) iov_iter_get_pages()/iov_iter_get_pages_alloc(). Will be dealt with later, when we make get_pages advancing - the callers are actually happier that way. 2) iov_iter copied, then something is put into the copy. Since they share the underlying pipe, the original gets behind. When we decide that we are done with the copy (original is not usable until then) we advance the original. direct_io used to be done that way; nowadays it operates on the original and we do iov_iter_revert() to discard the excessive data. At the moment there's nothing in the kernel that could do that to ITER_PIPE iterators, so this reason for insane state is theoretical right now. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2022-08-08ITER_PIPE: clean iov_iter_revert()Al Viro1-46/+14
Fold pipe_truncate() into it, clean up. We can release buffers in the same loop where we walk backwards to the iterator beginning looking for the place where the new position will be. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.