On Thu, Apr 18, 2024 at 10:19:33PM +0200, Jesper Dangaard Brouer wrote:
> I'm not sure it is "fine" to, explicitly choosing not to use page pool,
> and then (ab)use `struct page` member (pp) that intended for page_pool
> for other stuff. (In this case create a linked list of pages).
>
> +#define
On Tue, Apr 20, 2021 at 03:13:54PM +0300, Mike Rapoport wrote:
> Add a paragraph that explains that it may happen that the counters in
> /proc/meminfo do not add up to the overall memory usage.
... that is, the sum may be lower because memory is allocated for other
purposes that is not reported he
On Tue, Apr 20, 2021 at 09:39:54AM +0200, Geert Uytterhoeven wrote:
> > +++ b/include/linux/mm_types.h
> > @@ -97,10 +97,10 @@ struct page {
> > };
> > struct {/* page_pool used by netstack */
> > /**
> > -* @dm
On Tue, Apr 20, 2021 at 02:48:17AM +, Vineet Gupta wrote:
> > 32-bit architectures which expect 8-byte alignment for 8-byte integers
> > and need 64-bit DMA addresses (arc, arm, mips, ppc) had their struct
> > page inadvertently expanded in 2019.
>
> FWIW, ARC doesn't require 8 byte alignment
On Mon, Apr 19, 2021 at 01:22:04PM +0200, Jesper Dangaard Brouer wrote:
> On Wed, 14 Apr 2021 13:09:47 -0700
> Shakeel Butt wrote:
>
> > On Wed, Apr 14, 2021 at 12:42 PM Jesper Dangaard Brouer
> > wrote:
> > >
> > [...]
> > > > >
> > > > > Can this page_pool be used for TCP RX zerocopy? If yes
On Sat, Apr 17, 2021 at 09:18:57PM +, David Laight wrote:
> Ugly as well.
Thank you for expressing your opinion. Again.
On Sat, Apr 17, 2021 at 09:13:45PM +, David Laight wrote:
> > struct {/* page_pool used by netstack */
> > - /**
> > -* @dma_addr: might require a 64-bit value on
> > -* 32-bit architectures.
> > -
On Sat, Apr 17, 2021 at 09:32:06PM +0300, Ilias Apalodimas wrote:
> > +static inline void page_pool_set_dma_addr(struct page *page, dma_addr_t
> > addr)
> > +{
> > + page->dma_addr[0] = addr;
> > + if (sizeof(dma_addr_t) > sizeof(unsigned long))
> > + page->dma_addr[1] = addr >> 16 >
On Sat, Apr 17, 2021 at 12:31:37PM +0200, Arnd Bergmann wrote:
> On Fri, Apr 16, 2021 at 5:27 PM Matthew Wilcox wrote:
> > diff --git a/include/net/page_pool.h b/include/net/page_pool.h
> > index b5b195305346..db7c7020746a 100644
> > --- a/include/net/page_pool.h
> > ++
On Fri, Apr 16, 2021 at 07:08:23PM +0200, Jesper Dangaard Brouer wrote:
> On Fri, 16 Apr 2021 16:27:55 +0100
> Matthew Wilcox wrote:
>
> > On Thu, Apr 15, 2021 at 08:08:32PM +0200, Jesper Dangaard Brouer wrote:
> > > See below patch. Where I swap32 the dma addre
Replacement patch to fix compiler warning.
From: "Matthew Wilcox (Oracle)"
Date: Fri, 16 Apr 2021 16:34:55 -0400
Subject: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
To: bro...@redhat.com
Cc: linux-ker...@vger.kernel.org,
linux...@kvack.org,
netdev@vger.
loc().
Since page_pool doesn't want to set its magic value on pages which are
pfmemalloc, we can use bit 1 of compound_head to indicate that the page
came from the memory reserves.
Signed-off-by: Matthew Wilcox (Oracle)
---
include/linux/mm.h | 12 +++-
include/linux/mm_type
d a racing get_user_pages_fast()
could dereference a bogus compound_head().
Fixes: c25fff7171be ("mm: add dma_addr_t to struct page")
Signed-off-by: Matthew Wilcox (Oracle)
---
include/linux/mm_types.h | 4 ++--
include/net/page_pool.h | 12 +++-
net/core/page_pool.c | 12 +
s new functionality. It is much less urgent.
I'd really like to see Mel & Michal's thoughts on it.
I have only compile-tested these patches.
Matthew Wilcox (Oracle) (2):
mm: Fix struct page layout on 32-bit systems
mm: Indicate pfmemalloc pages in compound_head
include/li
On Thu, Apr 15, 2021 at 08:08:32PM +0200, Jesper Dangaard Brouer wrote:
> See below patch. Where I swap32 the dma address to satisfy
> page->compound having bit zero cleared. (It is the simplest fix I could
> come up with).
I think this is slightly simpler, and as a bonus code that assumes the
ol
On Fri, Apr 16, 2021 at 07:32:35AM +, David Laight wrote:
> From: Matthew Wilcox
> > Sent: 15 April 2021 23:22
> >
> > On Thu, Apr 15, 2021 at 09:11:56PM +, David Laight wrote:
> > > Isn't it possible to move the field down one long?
> > > Th
On Thu, Apr 15, 2021 at 09:11:56PM +, David Laight wrote:
> Isn't it possible to move the field down one long?
> This might require an explicit zero - but this is not a common
> code path - the extra write will be noise.
Then it overlaps page->mapping. See emails passim.
On Thu, Apr 15, 2021 at 08:08:32PM +0200, Jesper Dangaard Brouer wrote:
> +static inline
> +dma_addr_t page_pool_dma_addr_read(dma_addr_t dma_addr)
> +{
> + /* Workaround for storing 64-bit DMA-addr on 32-bit machines in struct
> + * page. The page->dma_addr share area with page->compound
On Wed, Apr 14, 2021 at 09:13:22PM +0200, Jesper Dangaard Brouer wrote:
> (If others want to reproduce). First I could not reproduce on ARM32.
> Then I found out that enabling CONFIG_XEN on ARCH=arm was needed to
> cause the issue by enabling CONFIG_ARCH_DMA_ADDR_T_64BIT.
hmmm ... you should be a
On Wed, Apr 14, 2021 at 10:10:44AM +0200, Jesper Dangaard Brouer wrote:
> Yes, indeed! - And very frustrating. It's keeping me up at night.
> I'm dreaming about 32 vs 64 bit data structures. My fitbit stats tell
> me that I don't sleep well with these kind of dreams ;-)
Then you're going to love
t; have to be kept intact. In above, I'm unsure @index is untouched.
Well, I tried three different approaches. Here's the one I hated the least.
From: "Matthew Wilcox (Oracle)"
Date: Sat, 10 Apr 2021 16:12:06 -0400
Subject: [PATCH] mm: Fix struct page layout on 32-bit system
On Sun, Apr 11, 2021 at 11:33:18AM +0100, Matthew Wilcox wrote:
> Basically, we have three aligned dwords here. We can either alias with
> @flags and the first word of @lru, or the second word of @lru and @mapping,
> or @index and @private. @flags is a non-starter. If we use @mappin
On Sun, Apr 11, 2021 at 11:43:07AM +0200, Jesper Dangaard Brouer wrote:
> On Sat, 10 Apr 2021 21:52:45 +0100
> "Matthew Wilcox (Oracle)" wrote:
>
> > 32-bit architectures which expect 8-byte alignment for 8-byte integers
> > and need 64-bit DMA addresses (arc, a
be cleared on free. To avoid
this, insert three words of padding and use the same bits as ->index
and ->private, neither of which have to be cleared on free.
Fixes: c25fff7171be ("mm: add dma_addr_t to struct page")
Signed-off-by: Matthew Wilco
I'd really appreciate people testing this, particularly on
arm32/mips32/ppc32 systems with a 64-bit dma_addr_t.
Matthew Wilcox (Oracle) (1):
mm: Fix struct page layout on 32-bit systems
include/linux/mm_types.h | 38 ++
1 file changed, 26 insertions(+
On Sat, Apr 10, 2021 at 09:27:31PM +0300, Ilias Apalodimas wrote:
> > Can this page_pool be used for TCP RX zerocopy? If yes then PageType
> > can not be used.
>
> Yes it can, since it's going to be used as your default allocator for
> payloads, which might end up on an SKB.
> So we have to keep t
On Sat, Apr 10, 2021 at 12:37:58AM +0200, Matteo Croce wrote:
> This is needed by the page_pool to avoid recycling a page not allocated
> via page_pool.
Is the PageType mechanism more appropriate to your needs? It wouldn't
be if you use page->_mapcount (ie mapping it to userspace).
> Signed-off-
How about moving the flags into the union? A bit messy, but we don't
have to play games with __packed__.
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 1210a8e41fad..f374d2f06255 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -68,16 +68,22 @@ struc
On Sun, Apr 04, 2021 at 09:48:08AM -0700, Paul E. McKenney wrote:
> On Sun, Apr 04, 2021 at 11:24:57AM +0100, Matthew Wilcox wrote:
> > On Sat, Apr 03, 2021 at 09:15:17PM -0700, syzbot wrote:
> > > HEAD commit:2bb25b3a Merge tag 'mips-fixes_5.12_3' of
> > &
On Sat, Apr 03, 2021 at 09:15:17PM -0700, syzbot wrote:
> HEAD commit:2bb25b3a Merge tag 'mips-fixes_5.12_3' of git://git.kernel..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1284cc31d0
> kernel config: https://syzkaller.appspot.com/x/.config?x=78
The XArray interface is easier for this driver to use. Also fixes a
bug reported by the improper use of GFP_ATOMIC.
Signed-off-by: Matthew Wilcox (Oracle)
---
net/qrtr/qrtr.c | 42 ++
1 file changed, 14 insertions(+), 28 deletions(-)
diff --git a/net
opers willing to maintain the
> > > > > net/qrtr/ code, so move it to drivers/staging/ so that it can be
> > > > > removed
> > > > > from the kernel tree entirely in a few kernel releases if no one steps
> > > > > up to maintain it.
> > &g
On Sun, Mar 28, 2021 at 08:56:17AM +0200, Greg Kroah-Hartman wrote:
> On Sat, Mar 27, 2021 at 03:51:10PM +0000, Matthew Wilcox wrote:
> > On Sat, Mar 27, 2021 at 03:31:18PM +0100, Greg Kroah-Hartman wrote:
> > > On Sat, Mar 27, 2021 at 10:25:20PM +0800, Du Cheng wrote:
> >
On Sat, Mar 27, 2021 at 03:31:18PM +0100, Greg Kroah-Hartman wrote:
> On Sat, Mar 27, 2021 at 10:25:20PM +0800, Du Cheng wrote:
> > On Sat, Mar 27, 2021 at 03:12:14PM +0100, Greg Kroah-Hartman wrote:
> > > Adding the xarray maintainer...
> > >
> > > On Sat, Mar 27, 2021 at 10:07:02PM +0800, Du Che
On Thu, Mar 25, 2021 at 03:06:57PM +0100, Uladzislau Rezki wrote:
> For the vmalloc we should be able to allocating on a specific NUMA node,
> at least the current interface takes it into account. As far as i see
> the current interface allocate on a current node:
>
> static inline unsigned long
>
On Thu, Mar 25, 2021 at 11:42:19AM +, Mel Gorman wrote:
> This series introduces a bulk order-0 page allocator with sunrpc and
> the network page pool being the first users. The implementation is not
> efficient as semantics needed to be ironed out first. If no other semantic
> changes are need
On Thu, Mar 25, 2021 at 11:42:23AM +, Mel Gorman wrote:
>
> - if (WARN_ON_ONCE(nr_pages <= 0))
> + if (unlikely(nr_pages <= 0))
> return 0;
If we made nr_pages unsigned, we wouldn't need this check at all (ok,
we'd still need to figure out what to do with 0). But then,
On Thu, Mar 25, 2021 at 11:42:21AM +, Mel Gorman wrote:
> +int __alloc_pages_bulk(gfp_t gfp, int preferred_nid,
> + nodemask_t *nodemask, int nr_pages,
> + struct list_head *list);
> +
> +/* Bulk allocate order-0 pages */
> +static inline
troduced.
>
> Signed-off-by: Mel Gorman
Reviewed-by: Matthew Wilcox (Oracle)
On Mon, Mar 22, 2021 at 08:32:54PM +, Chuck Lever III wrote:
> > It's not expected that the array implementation would be worse *unless*
> > you are passing in arrays with holes in the middle. Otherwise, the success
> > rate should be similar.
>
> Essentially, sunrpc will always pass an array
On Mon, Mar 22, 2021 at 06:41:30PM +0100, Antoine Tenart wrote:
> Quoting Matthew Wilcox (2021-03-22 17:54:39)
> > - rcu_read_lock();
> > - dev_maps = rcu_dereference(dev->xps_maps[type]);
> > + dev_maps = READ_ONCE(dev->xps_maps[type]);
>
> C
On Mon, Mar 22, 2021 at 04:43:29PM +0100, Antoine Tenart wrote:
> xps_queue_show is mostly made of an RCU read-side critical section and
> calls bitmap_zalloc with GFP_KERNEL in the middle of it. That is not
> allowed as this call may sleep and such behaviours aren't allowed in RCU
> read-side crit
lear copy-n-paste error. I think Coverity have
started looking for issues like this?
Reviewed-by: Matthew Wilcox (Oracle)
Also, maybe,
Fixes: c6a58ffed536 ("RDS: TCP: Add sysctl tunables for sndbuf/rcvbuf on
rds-tcp socket")
On Sat, Mar 13, 2021 at 04:56:31PM +, Chuck Lever III wrote:
> IME lists are indeed less CPU-efficient, but I wonder if that
> expense is insignificant compared to serialization primitives like
> disabling and re-enabling IRQs, which we are avoiding by using
> bulk page allocation.
Cache misse
On Sat, Mar 13, 2021 at 01:16:48PM +, Mel Gorman wrote:
> > I'm not claiming the pagevec is definitely a win, but it's very
> > unclear which tradeoff is actually going to lead to better performance.
> > Hopefully Jesper or Chuck can do some tests and figure out what actually
> > works better w
On Fri, Mar 12, 2021 at 04:03:50PM +, Mel Gorman wrote:
> On Fri, Mar 12, 2021 at 02:58:14PM +0000, Matthew Wilcox wrote:
> > On Fri, Mar 12, 2021 at 12:46:09PM +0100, Jesper Dangaard Brouer wrote:
> > > In my page_pool patch I'm bulk allocating 64 pages. I wanted to a
On Thu, Mar 11, 2021 at 08:48:27AM +, Mel Gorman wrote:
> I don't have that information unfortunately. It's a chicken and egg
> problem because without the API, there is no point creating new users.
> For example, fault around or readahead could potentially batch pages
> but whether it is actua
On Fri, Mar 12, 2021 at 12:46:09PM +0100, Jesper Dangaard Brouer wrote:
> In my page_pool patch I'm bulk allocating 64 pages. I wanted to ask if
> this is too much? (PP_ALLOC_CACHE_REFILL=64).
>
> The mlx5 driver have a while loop for allocation 64 pages, which it
> used in this case, that is why
On Wed, Mar 10, 2021 at 10:46:15AM +, Mel Gorman wrote:
> +int __alloc_pages_bulk_nodemask(gfp_t gfp_mask, int preferred_nid,
> + nodemask_t *nodemask, int nr_pages,
> + struct list_head *list);
For the next revision, can you ditch the '_
On Sun, Jan 31, 2021 at 12:12:11PM +, Alexander Lobakin wrote:
> pool_page_reusable() is a leftover from pre-NUMA-aware times. For now,
> this function is just a redundant wrapper over page_is_pfmemalloc(),
> so inline it into its sole call site.
Why doesn't this want to use {dev_}page_is_reus
On Sun, Jan 31, 2021 at 12:11:52PM +, Alexander Lobakin wrote:
> A bunch of drivers test the page before reusing/recycling for two
> common conditions:
> - if a page was allocated under memory pressure (pfmemalloc page);
> - if a page was allocated at a distant memory node (to exclude
>sl
On Sun, Jan 31, 2021 at 12:11:30PM +, Alexander Lobakin wrote:
> The function only tests for page->index, so its argument should be
> const.
>
> Signed-off-by: Alexander Lobakin
> Reviewed-by: Jesse Brandeburg
> Acked-by: David Rientjes
Reviewed-by: Matthew Wilcox (Oracle)
On Fri, Jan 29, 2021 at 01:18:20PM -0800, Jakub Kicinski wrote:
> On Fri, 29 Jan 2021 12:44:44 -0800 Shoaib Rao wrote:
> > On 1/29/21 12:18 PM, Jakub Kicinski wrote:
> > > On Fri, 29 Jan 2021 12:10:21 -0800 Shoaib Rao wrote:
> > >> The code does not care about the size of data -- All it does is t
On Fri, Jan 29, 2021 at 09:56:48AM -0800, Shoaib Rao wrote:
> On 1/25/21 3:36 PM, Jakub Kicinski wrote:
> > On Fri, 22 Jan 2021 15:06:37 +0000 Matthew Wilcox (Oracle) wrote:
> > > From: Rao Shoaib
> > >
> > > TCP sockets allow SIGURG to be sent to the proces
On Tue, Jan 26, 2021 at 06:36:02PM +, Mark Rutland wrote:
> On Tue, Jan 26, 2021 at 11:00:05AM -0600, Bjorn Andersson wrote:
> > On Tue 26 Jan 10:21 CST 2021, Mark Rutland wrote:
> >
> > > On Tue, Jan 26, 2021 at 02:58:33PM +, Matthew Wilcox wrote:
> > >
On Tue, Jan 26, 2021 at 10:47:34AM +, Mark Rutland wrote:
> Hi,
>
> When fuzzing arm64 with Syzkaller, I'm seeing some splats where
> this_cpu_ptr() is used in the bowels of idr_alloc(), by way of
> radix_tree_node_alloc(), in a preemptible context:
I sent a patch to fix this last June. The
-by: Rao Shoaib
Signed-off-by: Matthew Wilcox (Oracle)
---
net/unix/af_unix.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 41c3303c3357..849dff688c2c 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -1837,8
On Sun, Nov 22, 2020 at 06:46:46AM -0800, Tom Rix wrote:
>
> On 11/21/20 7:23 PM, Matthew Wilcox wrote:
> > On Sat, Nov 21, 2020 at 08:50:58AM -0800, t...@redhat.com wrote:
> >> The fixer review is
> >> https://reviews.llvm.org/D91789
> >>
> >> A
On Sat, Nov 21, 2020 at 08:50:58AM -0800, t...@redhat.com wrote:
> The fixer review is
> https://reviews.llvm.org/D91789
>
> A run over allyesconfig for x86_64 finds 62 issues, 5 are false positives.
> The false positives are caused by macros passed to other macros and by
> some macro expansions t
On Sat, Nov 14, 2020 at 10:51:06PM -0800, Dongli Zhang wrote:
> + if (nc->pfmemalloc) {
You missed the unlikely() change that Eric recommended.
On Thu, Nov 05, 2020 at 02:02:24PM +, Matthew Wilcox wrote:
> On Thu, Nov 05, 2020 at 02:21:25PM +0100, Eric Dumazet wrote:
> > On 11/5/20 5:21 AM, Matthew Wilcox (Oracle) wrote:
> > > When the machine is under extreme memory pressure, the page_frag allocator
> &g
On Thu, Nov 05, 2020 at 02:21:25PM +0100, Eric Dumazet wrote:
> On 11/5/20 5:21 AM, Matthew Wilcox (Oracle) wrote:
> > When the machine is under extreme memory pressure, the page_frag allocator
> > signals this to the networking stack by marking allocations with the
> > &#x
On Thu, Nov 05, 2020 at 12:56:43PM +0100, Vlastimil Babka wrote:
> > +++ b/mm/page_alloc.c
> > @@ -5139,6 +5139,10 @@ void *page_frag_alloc(struct page_frag_cache *nc,
> > if (!page_ref_sub_and_test(page, nc->pagecnt_bias))
> > goto refill;
> > + if (nc->pf
enkatsubra
Cc: Manjunath Patil
Cc: Joe Jin
Cc: SRINIVAS
Cc: sta...@vger.kernel.org
Fixes: 79930f5892e ("net: do not deplete pfmemalloc reserve")
Signed-off-by: Matthew Wilcox (Oracle)
---
mm/page_alloc.c | 4
1 file changed, 4 insertions(+)
diff --git a/mm/page_alloc.c b/m
On Wed, Nov 04, 2020 at 09:50:30AM +0100, Eric Dumazet wrote:
> On 11/4/20 2:16 AM, Rama Nichanamatlu wrote:
> >> Thanks for providing the numbers. Do you think that dropping (up to)
> >> 7 packets is acceptable?
> >
> > net.ipv4.tcp_syn_retries = 6
> >
> > tcp clients wouldn't even get that far
On Tue, Nov 03, 2020 at 12:57:33PM -0800, Dongli Zhang wrote:
> On 11/3/20 12:35 PM, Matthew Wilcox wrote:
> > On Tue, Nov 03, 2020 at 11:32:39AM -0800, Dongli Zhang wrote:
> >> However, once kernel is not under memory pressure any longer (suppose large
> >> amou
On Tue, Nov 03, 2020 at 11:32:39AM -0800, Dongli Zhang wrote:
> The ethernet driver may allocates skb (and skb->data) via napi_alloc_skb().
> This ends up to page_frag_alloc() to allocate skb->data from
> page_frag_cache->va.
>
> During the memory pressure, page_frag_cache->va may be allocated as
On Mon, Nov 02, 2020 at 04:20:30PM +0100, Bartosz Golaszewski wrote:
> +Chunks allocated with `kmalloc` can be resized with `krealloc`. Similarly
> +to `kmalloc_array`: a helper for resising arrays is provided in the form of
> +`krealloc_array`.
Is there any reason you chose to `do_this` instead o
On Thu, Oct 22, 2020 at 04:35:17PM +, David Laight wrote:
> Wait...
> readv(2) defines:
> ssize_t readv(int fd, const struct iovec *iov, int iovcnt);
It doesn't really matter what the manpage says. What does the AOSP
libc header say?
> But the syscall is defined as:
>
> SYSCALL_DEFINE
On Sun, Oct 18, 2020 at 12:13:35PM -0700, James Bottomley wrote:
> On Sun, 2020-10-18 at 19:59 +0100, Matthew Wilcox wrote:
> > On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
> > > clang has a number of useful, new warnings see
> > > https:
On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
> clang has a number of useful, new warnings see
> https://urldefense.com/v3/__https://clang.llvm.org/docs/DiagnosticsReference.html__;!!GqivPVa7Brio!Krxz78O3RKcB9JBMVo_F98FupVhj_jxX60ddN6tKGEbv_cnooXc1nnBmchm-e_O9ieGnyQ$
>
Please
On Tue, Oct 13, 2020 at 11:44:29AM -0700, Dan Williams wrote:
> On Fri, Oct 9, 2020 at 12:52 PM wrote:
> >
> > From: Ira Weiny
> >
> > The kmap() calls in this FS are localized to a single thread. To avoid
> > the over head of global PKRS updates use the new kmap_thread() call.
> >
> > Cc: Nicol
On Mon, Oct 12, 2020 at 12:53:54PM -0700, Ira Weiny wrote:
> On Mon, Oct 12, 2020 at 05:44:38PM +0100, Matthew Wilcox wrote:
> > On Mon, Oct 12, 2020 at 09:28:29AM -0700, Dave Hansen wrote:
> > > kmap_atomic() is always preferred over kmap()/kmap_thread().
> > > k
On Mon, Oct 12, 2020 at 09:28:29AM -0700, Dave Hansen wrote:
> kmap_atomic() is always preferred over kmap()/kmap_thread().
> kmap_atomic() is _much_ more lightweight since its TLB invalidation is
> always CPU-local and never broadcast.
>
> So, basically, unless you *must* sleep while the mapping
On Fri, Oct 09, 2020 at 02:34:34PM -0700, Eric Biggers wrote:
> On Fri, Oct 09, 2020 at 12:49:57PM -0700, ira.we...@intel.com wrote:
> > The kmap() calls in this FS are localized to a single thread. To avoid
> > the over head of global PKRS updates use the new kmap_thread() call.
> >
> > @@ -2410,
On Mon, Sep 21, 2020 at 04:34:25PM +0200, Christoph Hellwig wrote:
> {
> - WARN_ON(direction & ~(READ | WRITE));
> + WARN_ON(direction & ~(READ | WRITE | CHECK_IOVEC_ONLY));
This is now a no-op because:
include/linux/fs.h:#define CHECK_IOVEC_ONLY -1
I'd suggest we renumber it to 2?
(RE
On Sun, Sep 20, 2020 at 08:10:31PM +0100, Al Viro wrote:
> IMO it's much saner to mark those and refuse to touch them from io_uring...
Simpler solution is to remove io_uring from the 32-bit syscall list.
If you're a 32-bit process, you don't get to use io_uring. Would
any real users actually care
On Sun, Sep 20, 2020 at 07:07:42PM +0100, Al Viro wrote:
> 2) a few drivers are really fucked in head. They use different
> *DATA* layouts for reads/writes, depending upon the calling process.
> IOW, if you fork/exec a 32bit binary and your stdin is one of those,
> reads from stdin in parent
On Fri, Sep 18, 2020 at 02:45:25PM +0200, Christoph Hellwig wrote:
> Add a flag to force processing a syscall as a compat syscall. This is
> required so that in_compat_syscall() works for I/O submitted by io_uring
> helper threads on behalf of compat syscalls.
Al doesn't like this much, but my su
On Fri, Sep 18, 2020 at 02:45:27PM +0200, Christoph Hellwig wrote:
> }
> - if (type >= 0
> - && unlikely(!access_ok(buf, len))) {
> + if (type != CHECK_IOVEC_ONLY && unlikely(!access_ok(buf, len)))
> {
drop the unlikely() at the same time? if
On Tue, Sep 15, 2020 at 12:17:55AM +0530, Anmol Karn wrote:
> On Mon, Sep 14, 2020 at 12:08:03PM +0100, Matthew Wilcox wrote:
> > On Mon, Sep 14, 2020 at 12:47:24PM +0530, Anmol Karn wrote:
> > > idr_get_next() gives WARN_ON_ONCE() when it gets (id > INT_MAX) true
> &
On Mon, Sep 14, 2020 at 04:44:16PM +0200, Christoph Hellwig wrote:
> I'm still a little unsure about the API naming, as alloc_pages sort of
> implies a struct page return value, but we return a kernel virtual
> address.
Erm ... dma_alloc_pages() returns a struct page, so is this sentence
stale?
>
On Mon, Sep 14, 2020 at 04:44:27PM +0200, Christoph Hellwig wrote:
> drivers/net/ethernet/i825xx/lasi_82596.c | 25 ++---
> drivers/net/ethernet/i825xx/lib82596.c | 114 ++-
> drivers/net/ethernet/i825xx/sni_82596.c | 4 -
> drivers/net/ethernet/seeq/sgiseeq.c | 28
On Tue, Sep 01, 2020 at 06:41:12PM +0200, Helge Deller wrote:
> > I still have a zoo of machines running for such testing, including a
> > 715/64 and two 730.
> > I'm going to test this git tree on the 715/64:
The 715/64 is a 7100LC machine though. I think you need to boot on
the 730 to test the
On Tue, Sep 01, 2020 at 07:52:40AM -0700, James Bottomley wrote:
> I think this looks mostly OK, except for one misnamed parameter below.
> Unfortunately, the last non-coherent parisc was the 700 series and I no
> longer own a box, so I can't test that part of it (I can fire up the
> C360 to test
On Thu, Aug 13, 2020 at 12:48:10PM +0200, Dmitry Vyukov wrote:
> On Fri, Jun 5, 2020 at 6:44 PM Eric Dumazet wrote:
> >
> > On 6/5/20 5:00 AM, Matthew Wilcox wrote:
> > > From: "Matthew Wilcox (Oracle)"
> > >
> > > The XArray interface is ea
On Wed, Jul 29, 2020 at 03:52:51PM +0200, Peter Zijlstra wrote:
> Manual repetition is boring and error prone.
Yes, but generated functions are hard to grep for, and I'm pretty sure
that kernel-doc doesn't know how to expand macros into comments that it
can then extract documentation from.
I've b
On Wed, Jul 15, 2020 at 12:17:17PM -0700, Jakub Kicinski wrote:
> On Thu, 9 Jul 2020 23:22:10 +0300 Vladimir Oltean wrote:
> > Reading the document in vim is currently not a pleasant experience. Its
> > rst syntax highlighting is confused by the "*/" sequences which it's not
> > interpreting as pa
On Wed, Jun 17, 2020 at 01:31:57PM +0200, Michal Hocko wrote:
> On Wed 17-06-20 04:08:20, Matthew Wilcox wrote:
> > If you call vfree() under
> > a spinlock, you're in trouble. in_atomic() only knows if we hold a
> > spinlock for CONFIG_PREEMPT, so it's not safe
On Wed, Jun 17, 2020 at 09:12:12AM +0200, Michal Hocko wrote:
> On Tue 16-06-20 17:37:11, Matthew Wilcox wrote:
> > Not just performance critical, but correctness critical. Since kvfree()
> > may allocate from the vmalloc allocator, I really think that kvfree()
> > sh
On Wed, Jun 17, 2020 at 01:01:30AM +0200, David Sterba wrote:
> On Tue, Jun 16, 2020 at 11:53:50AM -0700, Joe Perches wrote:
> > On Mon, 2020-06-15 at 21:57 -0400, Waiman Long wrote:
> > > v4:
> > > - Break out the memzero_explicit() change as suggested by Dan Carpenter
> > > so that it can
On Tue, Jun 16, 2020 at 11:53:50AM -0700, Joe Perches wrote:
> To this larger audience and last week without reply:
> https://lore.kernel.org/lkml/573b3fbd5927c643920e1364230c296b23e7584d.ca...@perches.com/
>
> Are there _any_ fastpath uses of kfree or vfree?
I worked on adding a 'free' a couple
On Fri, May 29, 2020 at 04:43:08PM -0700, John Hubbard wrote:
> +CASE 5: Pinning in order to write to the data within the page
> +-
> +Even though neither DMA nor Direct IO is involved, just a simple case of
> "pin,
> +access page's data,
On Tue, Jun 09, 2020 at 01:45:57PM +0300, Stanimir Varbanov wrote:
> Here is the third version of dynamic debug improvements in Venus
> driver. As has been suggested on previous version by Joe [1] I've
> made the relevant changes in dynamic debug core to handle leveling
> as more generic way and n
On Tue, Jun 09, 2020 at 01:45:58PM +0300, Stanimir Varbanov wrote:
> +level
> +The given level will be a bitmask ANDed with the level of the each
> ``pr_debug()``
> +callsite. This will allow to group debug messages and show only those of
> the
> +same level. The -p flag takes preced
[I meant to cc netdev on this originally. Added now, preserving entire
message below for context]
On Fri, Jun 05, 2020 at 05:12:05AM -0700, Matthew Wilcox wrote:
> While doing the XArray conversion, I came across your commit
> f16a4b26f31f95dddb12cf3c2390906a735203ae
>
> synchron
From: "Matthew Wilcox (Oracle)"
The XArray interface is easier for this driver to use. Also fixes a
bug reported by the improper use of GFP_ATOMIC.
Signed-off-by: Matthew Wilcox (Oracle)
---
net/qrtr/qrtr.c | 39 +--
1 file changed, 13 inserti
On Thu, Jun 04, 2020 at 08:55:55PM -0700, Eric Biggers wrote:
> Possibly a bug in lib/radix-tree.c? this_cpu_ptr() in radix_tree_node_alloc()
> can be reached without a prior preempt_disable(). Or is the caller of
> idr_alloc() doing something wrong?
Yes, the idr_alloc() call is plainly wrong:
On Thu, Jun 04, 2020 at 05:40:31PM -0700, Eric Biggers wrote:
> +Cc linux-crypto. crypto_free_shash() is being called in atomic context;
> perhaps that should be allowed? kfree() can be called in atomic context.
Although vfree() cannot (which i personally hate ...)
> On Thu, Jun 04, 2020 at 05:
On Fri, May 22, 2020 at 03:52:39PM +0800, Muchun Song wrote:
> On Fri, May 22, 2020 at 12:47 AM Matthew Wilcox wrote:
> > > @@ -160,14 +168,23 @@ static int proc_fd_link(struct dentry *dentry,
> > > struct path *path)
> > > unsigned i
1 - 100 of 330 matches
Mail list logo
