- 12 Aug, 2022 3 commits
-
-
Krzysztof Kozlowski authored
Emails to Beniamin Bia and Stefan Popa bounce ("550 5.1.10 RESOLVER.ADR.RecipientNotFound; Recipient not found by SMTP address lookup"). Signed-off-by:Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220809162752.10186-4-krzysztof.kozlowski@linaro.org
-
Krzysztof Kozlowski authored
Emails to Bogdan Pricop bounce ("550 5.4.1 Recipient address rejected: Access denied. AS(201806281)"). Signed-off-by: -
Krzysztof Kozlowski authored
Emails to Joachim Eastwood bounce ("552 5.2.2 The email account that you tried to reach is over quota and inactive."). Signed-off-by:
-
- 10 Aug, 2022 4 commits
-
-
Rob Herring authored
The secure interrupt is only useful to secure world, therefore for NS users it shouldn't be required. Make it optional. This fixes a warning on Arm Juno board: mhu@2b1f0000: interrupts: [[0, 36, 4], [0, 35, 4]] is too short Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com> Link: https://lore.kernel.org/r/20220728190810.1290857-1-robh@kernel.org
-
Rob Herring authored
'gpio-ranges' entries have a fixed size of 1 phandle plus arg 3 cells. The qcom,ipq6018-pinctrl example is a cell short: Documentation/devicetree/bindings/pinctrl/qcom,ipq6018-pinctrl.example.dtb: pinctrl@1000000: gpio-ranges:0: [1, 0, 80] is too short From schema: /usr/local/lib/python3.10/dist-packages/dtschema/schemas/gpio/gpio.yaml Signed-off-by:
-
Rob Herring authored
Since commit ef8795f3 ("dt-bindings: kbuild: Use DTB files for validation"), dt-mk-schema always needs a complete list of schemas, so the conditional using DT_MK_SCHEMA_FLAGS should be removed. Signed-off-by:
-
David Heidelberg authored
Convert Qualcomm SPMI PMIC binding to yaml format. Additional changes: - filled many missing compatibles Co-developed-by:
Caleb Connolly <caleb@connolly.tech> Signed-off-by:
David Heidelberg <david@ixit.cz> Reviewed-by:
-
- 09 Aug, 2022 33 commits
-
-
Bhupesh Sharma authored
As Rob reported in [1], there is one more issue present in the 'sdhci-msm' dt-binding which shows up when a fix for 'unevaluatedProperties' handling is applied: Documentation/devicetree/bindings/mmc/sdhci-msm.example.dtb: mmc@8804000: Unevaluated properties are not allowed ('operating-points-v2' was unexpected) Fix the same. [1]. https://lore.kernel.org/lkml/20220514220116.1008254-1-bhupesh.sharma@linaro.org/ Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Rob Herring <robh@kernel.org> Cc: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:Bhupesh Sharma <bhupesh.sharma@linaro.org> Acked-by:
-
Krzysztof Kozlowski authored
Bartlomiej's Samsung email address is not working since around last year and there was no follow up patch take over of the drivers, so drop the email from maintainers. Cc: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by:
-
git://git.samba.org/ksmbdLinus Torvalds authored
Pull ksmbd updates from Steve French: - fixes for memory access bugs (out of bounds access, oops, leak) - multichannel fixes - session disconnect performance improvement, and session register improvement - cleanup * tag '5.20-rc-ksmbd-server-fixes' of git://git.samba.org/ksmbd: ksmbd: fix heap-based overflow in set_ntacl_dacl() ksmbd: prevent out of bound read for SMB2_TREE_CONNNECT ksmbd: prevent out of bound read for SMB2_WRITE ksmbd: fix use-after-free bug in smb2_tree_disconect ksmbd: fix memory leak in smb2_handle_negotiate ksmbd: fix racy issue while destroying session on multichannel ksmbd: use wait_event instead of schedule_timeout() ksmbd: fix kernel oops from idr_remove() ksmbd: add channel rwlock ksmbd: replace sessions list in connection with xarray MAINTAINERS: ksmbd: add entry for documentation ksmbd: remove unused ksmbd_share_configs_cleanup function
-
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds authored
Pull more iov_iter updates from Al Viro: - more new_sync_{read,write}() speedups - ITER_UBUF introduction - ITER_PIPE cleanups - unification of iov_iter_get_pages/iov_iter_get_pages_alloc and switching them to advancing semantics - making ITER_PIPE take high-order pages without splitting them - handling copy_page_from_iter() for high-order pages properly * tag 'pull-work.iov_iter-rebased' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (32 commits) fix copy_page_from_iter() for compound destinations hugetlbfs: copy_page_to_iter() can deal with compound pages copy_page_to_iter(): don't split high-order page in case of ITER_PIPE expand those iov_iter_advance()... pipe_get_pages(): switch to append_pipe() get rid of non-advancing variants ceph: switch the last caller of iov_iter_get_pages_alloc() 9p: convert to advancing variant of iov_iter_get_pages_alloc() af_alg_make_sg(): switch to advancing variant of iov_iter_get_pages() iter_to_pipe(): switch to advancing variant of iov_iter_get_pages() block: convert to advancing variants of iov_iter_get_pages{,_alloc}() iov_iter: advancing variants of iov_iter_get_pages{,_alloc}() iov_iter: saner helper for page array allocation fold __pipe_get_pages() into pipe_get_pages() ITER_XARRAY: don't open-code DIV_ROUND_UP() unify the rest of iov_iter_get_pages()/iov_iter_get_pages_alloc() guts unify xarray_get_pages() and xarray_get_pages_alloc() unify pipe_get_pages() and pipe_get_pages_alloc() iov_iter_get_pages(): sanity-check arguments iov_iter_get_pages_alloc(): lift freeing pages array on failure exits into wrapper ... -
Al Viro authored
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>
-
Al Viro authored
... since April 2021 Signed-off-by: -
Al Viro authored
... just shove it into one pipe_buffer. Signed-off-by: -
Al Viro authored
Signed-off-by: -
Al Viro authored
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 authored
mechanical change; will be further massaged in subsequent commits Reviewed-by:
Jeff Layton <jlayton@kernel.org> Signed-off-by:
-
Al Viro authored
here nothing even looks at the iov_iter after the call, so we couldn't care less whether it advances or not. Reviewed-by:
-
Al Viro authored
that one is somewhat clumsier than usual and needs serious testing. Signed-off-by: -
Al Viro authored
... and adjust the callers Reviewed-by:
-
Al Viro authored
... and untangle the cleanup on failure to add into pipe. Reviewed-by:
-
Al Viro authored
... doing revert if we end up not using some pages Signed-off-by: -
Al Viro authored
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:
-
Al Viro authored
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:
-
Al Viro authored
... 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:
-
Al Viro authored
Reviewed-by:
-
Al Viro authored
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 authored
same as for pipes Reviewed-by:
-
Al Viro authored
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:
-
Al Viro authored
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: -
Al Viro authored
Incidentally, ITER_XARRAY did *not* free the sucker in case when iter_xarray_populate_pages() returned 0... Reviewed-by:
-
Al Viro authored
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 authored
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 authored
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 authored
instead of setting ->iov_offset for new position and calling pipe_truncate() to adjust ->len of the last buffer and discard everything after it, adjust ->len at the same time we set ->iov_offset and use pipe_discard_from() to deal with buffers past that. Signed-off-by: -
Al Viro authored
it's only used to get to the partial buffer we can add to, and that's always the last one, i.e. pipe->head - 1. Signed-off-by: -
Al Viro authored
Expand the only remaining call of push_pipe() (in __pipe_get_pages()), combine it with the page-collecting loop there. Note that the only reason it's not a loop doing append_pipe() is that append_pipe() is advancing, while iov_iter_get_pages() is not. As soon as it switches to saner semantics, this thing will switch to using append_pipe(). Signed-off-by: -
Al Viro authored
New helper: append_pipe(). Extends the last buffer if possible, allocates a new one otherwise. Returns page and offset in it on success, NULL on failure. iov_iter is advanced past the data we've got. Use that instead of push_pipe() in copy-to-pipe primitives; they get simpler that way. Handling of short copy (in "mc" one) is done simply by iov_iter_revert() - iov_iter is in consistent state after that one, so we can use that. [Fix for braino caught by Liu Xinpeng <liuxp11@chinatelecom.cn> folded in] [another braino fix, this time in copy_pipe_to_iter() and pipe_zero(); caught by testcase from Hugh Dickins] Signed-off-by: -
Al Viro authored
There are only two kinds of pipe_buffer in the area used by ITER_PIPE. 1) anonymous - copy_to_iter() et.al. end up creating those and copying data there. They have zero ->offset, and their ->ops points to default_pipe_page_ops. 2) zero-copy ones - those come from copy_page_to_iter(), and page comes from caller. ->offset is also caller-supplied - it might be non-zero. ->ops points to page_cache_pipe_buf_ops. Move creation and insertion of those into helpers - push_anon(pipe, size) and push_page(pipe, page, offset, size) resp., separating them from the "could we avoid creating a new buffer by merging with the current head?" logics. Acked-by:
-
Al Viro authored
pipe_buffer instances of a pipe are organized as a ring buffer, with power-of-2 size. Indices are kept *not* reduced modulo ring size, so the buffer refered to by index N is pipe->bufs[N & (pipe->ring_size - 1)]. Ring size can change over the lifetime of a pipe, but not while the pipe is locked. So for any iov_iter primitives it's a constant. Original conversion of pipes to this layout went overboard trying to microoptimize that - calculating pipe->ring_size - 1, storing it in a local variable and using through the function. In some cases it might be warranted, but most of the times it only obfuscates what's going on in there. Introduce a helper (pipe_buf(pipe, N)) that would encapsulate that and use it in the obvious cases. More will follow... Reviewed-by:
Christian Brauner (Microsoft) <brauner@kernel.org> Signed-off-by:
-
