On Thu, Oct 03, 2019 at 01:18:47PM -0700, Davidlohr Bueso wrote:
> It has been discussed[1,2] that almost all users of interval trees would
> better
> be served if the intervals were actually not [a,b], but instead [a, b). This
So how does a user represent a range from ULONG_MAX to ULONG_MAX now?
On Thu, Oct 03, 2019 at 01:18:55PM -0700, Davidlohr Bueso wrote:
> +++ b/mm/nommu.c
> @@ -1793,7 +1793,7 @@ int nommu_shrink_inode_mappings(struct inode *inode,
> size_t size,
> size_t r_size, r_top;
>
> low = newsize >> PAGE_SHIFT;
> - high = (size + PAGE_SIZE - 1) >> PAGE_SHIFT
On Fri, Oct 04, 2019 at 06:15:11AM -0700, Michel Lespinasse wrote:
> My take is that this (Davidlohr's) patch series does not necessarily
> need to be applied all at once - we could get the first change in
> (adding the interval_tree_gen.h header), and convert the first few
> users, without getting
On Mon, Oct 14, 2019 at 08:48:48PM +, tim.b...@sony.com wrote:
>
>
> > -Original Message-
> > From: Jani Nikula on October 13, 2019 11:00 PM
> > On Sun, 13 Oct 2019, Changbin Du wrote:
> > > The 'functions' directive is not only for functions, but also works for
> > > structs/unions.
On Tue, Oct 15, 2019 at 11:25:53AM +0200, Thomas Zimmermann wrote:
> > My preference would be to use 'symbols'. I tried to come up with something
> > but 'symbols' is better than anything I came up with.
>
> Maybe 'interfaces' or 'artifacts'. The term 'symbols' is just as
> imprecise as 'function
On Wed, Oct 16, 2019 at 08:03:24AM +0800, Changbin Du wrote:
> On Tue, Oct 15, 2019 at 04:54:39AM -0700, Matthew Wilcox wrote:
> > On Tue, Oct 15, 2019 at 11:25:53AM +0200, Thomas Zimmermann wrote:
> > > > My preference would be to use 'symbols'. I tried to
On Fri, Mar 13, 2020 at 04:55:50PM -0300, Jason Gunthorpe wrote:
> On Thu, Mar 12, 2020 at 05:02:18PM +, Steven Price wrote:
> > On 12/03/2020 16:37, Jason Gunthorpe wrote:
> > > On Thu, Mar 12, 2020 at 04:16:33PM +, Steven Price wrote:
> > > > > Actually, while you are looking at this, do
On Fri, Sep 13, 2019 at 11:32:09AM +0200, Thomas Hellström (VMware) wrote:
> +vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf,
> + pgprot_t prot,
> + pgoff_t num_prefault)
> +{
> + struct vm_area_struct *vma = vmf->vma;
>
On Fri, Aug 23, 2019 at 08:47:47AM +, Peter Rosin wrote:
> +++ b/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -56,6 +56,9 @@ EXPORT_SYMBOL(num_registered_fb);
> bool fb_center_logo __read_mostly;
> EXPORT_SYMBOL(fb_center_logo);
>
> +unsigned int fb_logo_co
On Fri, Aug 02, 2019 at 01:23:06PM -0700, Andrew Morton wrote:
> > [259701.387365] BUG: Bad page state in process Xorg pfn:2a300
> > [259701.393593] page:eaa8c000 refcount:0 mapcount:-128
> > mapping: index:0x0
mapcount -128 is PAGE_MAPCOUNT_RESERVE, aka PageBuddy. I thin
On Fri, Aug 02, 2019 at 05:17:30PM -0400, Qian Cai wrote:
> On Fri, 2019-08-02 at 13:33 -0700, Matthew Wilcox wrote:
> > It occurs to me that when a page is freed, we could record some useful bits
> > of information in the page from the stack trace to help debug double-free
> &
On Fri, Aug 02, 2019 at 02:41:46PM +0200, Jan Kara wrote:
> On Fri 02-08-19 11:12:44, Michal Hocko wrote:
> > On Thu 01-08-19 19:19:31, john.hubb...@gmail.com wrote:
> > [...]
> > > 2) Convert all of the call sites for get_user_pages*(), to
> > > invoke put_user_page*(), instead of put_page(). This
On Tue, Aug 06, 2019 at 11:50:42AM -0700, Linus Torvalds wrote:
> In fact, I do note that a lot of the users don't actually use the
> "void *private" argument at all - they just want the walker - and just
> pass in a NULL private pointer. So we have things like this:
>
> > + if (walk_page_ra
On Tue, Aug 06, 2019 at 11:40:00PM -0700, Christoph Hellwig wrote:
> On Tue, Aug 06, 2019 at 12:09:38PM -0700, Matthew Wilcox wrote:
> > Has anyone looked at turning the interface inside-out? ie something like:
> >
> > struct mm_walk_state state = { .mm = mm, .star
On Wed, Aug 07, 2019 at 04:32:51PM +0100, Steven Price wrote:
> On 07/08/2019 15:56, Matthew Wilcox wrote:
> > On Wed, Aug 07, 2019 at 03:30:38PM +0100, Steven Price wrote:
> >> On 07/08/2019 15:15, Matthew Wilcox wrote:
> >>> On Tue, Aug 06, 2019 at 11:40:00PM
On Wed, Aug 07, 2019 at 03:30:38PM +0100, Steven Price wrote:
> On 07/08/2019 15:15, Matthew Wilcox wrote:
> > On Tue, Aug 06, 2019 at 11:40:00PM -0700, Christoph Hellwig wrote:
> >> On Tue, Aug 06, 2019 at 12:09:38PM -0700, Matthew Wilcox wrote:
> >>> Has anyone l
On Sun, May 30, 2021 at 12:13:05PM -0700, Nathan Chancellor wrote:
> Hi Matthew,
>
> On Wed, Mar 10, 2021 at 06:55:30PM +, Matthew Wilcox (Oracle) wrote:
> > There's no need to give the page an address_space. Leaving the
> > page->mapping as NULL will cause th
On Tue, Jun 01, 2021 at 04:10:32PM +0200, Daniel Vetter wrote:
> On Sun, May 30, 2021 at 10:14:22PM +0100, Matthew Wilcox wrote:
> > On Sun, May 30, 2021 at 12:13:05PM -0700, Nathan Chancellor wrote:
> > > Hi Matthew,
> > >
> > > On Wed, Mar 10, 2021 at 06:5
On Fri, Jun 04, 2021 at 02:25:01PM +0200, Vitaly Kuznetsov wrote:
> Commit ccf953d8f3d6 ("fb_defio: Remove custom address_space_operations")
> seems to be breaking Hyper-V framebuffer
https://lore.kernel.org/linux-mm/YLZUrEjVJWBGGMxf@phenom.ffwll.local/
On Fri, Jun 04, 2021 at 06:37:49PM +, Dexuan Cui wrote:
> > From: Dexuan Cui
> > Sent: Friday, June 4, 2021 11:17 AM
> > > >> ...
> > > > I've heard a similar report from Vineeth but we didn't get to the bottom
> > > > of this.
> > > I have just tried reverting the commit mentioned above and it
On Mon, Jun 07, 2021 at 03:42:18PM -0500, Alex Sierra wrote:
> v1:
> https://lore.kernel.org/linux-mm/20210529064022.gb15...@lst.de/T/
Please copy and paste the rationale into followup patch series instead
of sending a link:
AMD is building a system architecture for the Frontier supercomputer wit
On Tue, Jun 08, 2021 at 12:29:04AM +, Liam Howlett wrote:
> * Alex Sierra [210607 16:43]:
> > From: Ralph Campbell
> >
> > There are several places where ZONE_DEVICE struct pages assume a reference
> > count == 1 means the page is idle and free. Instead of open coding this,
> > add a helper
On Mon, Jun 07, 2021 at 03:42:19PM -0500, Alex Sierra wrote:
> +++ b/include/linux/dax.h
> @@ -243,6 +243,16 @@ static inline bool dax_mapping(struct address_space
> *mapping)
> return mapping->host && IS_DAX(mapping->host);
> }
>
> +static inline bool dax_layout_is_idle_page(struct page
On Wed, Jan 25, 2023 at 08:49:50AM -0800, Suren Baghdasaryan wrote:
> On Wed, Jan 25, 2023 at 1:10 AM Peter Zijlstra wrote:
> > > + /*
> > > + * Flags, see mm.h.
> > > + * WARNING! Do not modify directly.
> > > + * Use {init|reset|set|clear|mod}_vm_flags() functions instead.
> >
On Wed, Jan 25, 2023 at 12:38:46AM -0800, Suren Baghdasaryan wrote:
> +/* Use when VMA is not part of the VMA tree and needs no locking */
> +static inline void init_vm_flags(struct vm_area_struct *vma,
> + unsigned long flags)
> +{
> + vma->vm_flags = flags;
vm_fl
On Thu, Jan 26, 2023 at 04:50:59PM +0200, Mike Rapoport wrote:
> On Thu, Jan 26, 2023 at 11:17:09AM +0200, Mike Rapoport wrote:
> > On Wed, Jan 25, 2023 at 12:38:46AM -0800, Suren Baghdasaryan wrote:
> > > +/* Use when VMA is not part of the VMA tree and needs no locking */
> > > +static inline voi
On Fri, Feb 17, 2023 at 02:44:10PM +0100, Danilo Krummrich wrote:
> Generic components making use of the maple tree (such as the
> DRM GPUVA Manager) delegate the responsibility of ensuring mutual
> exclusion to their users.
>
> While such components could inherit the concept of an external lock,
On Fri, Feb 17, 2023 at 02:44:09PM +0100, Danilo Krummrich wrote:
> \#define SAMPLE_ITER(name, __mgr) \
> struct sample_iter name = { \
> .mas = __MA_STATE(&(__mgr)->mt, 0, 0),
This is usually called MA_STATE_INIT()
> #define sample_iter_for_each_range(it__, start__, end__) \
On Mon, Feb 20, 2023 at 03:00:59PM +0100, Danilo Krummrich wrote:
> On 2/17/23 20:38, Matthew Wilcox wrote:
> > On Fri, Feb 17, 2023 at 02:44:10PM +0100, Danilo Krummrich wrote:
> > > Generic components making use of the maple tree (such as the
> > > DRM GPUVA Manager)
On Mon, Feb 20, 2023 at 06:06:03PM +0100, Danilo Krummrich wrote:
> On 2/20/23 16:10, Matthew Wilcox wrote:
> > This is why we like people to use the spinlock embedded in the tree.
> > There's nothing for the user to care about. If the access really is
> > serialise
On Tue, Feb 21, 2023 at 03:37:49PM +0100, Danilo Krummrich wrote:
> On Mon, Feb 20, 2023 at 08:33:35PM +0000, Matthew Wilcox wrote:
> > On Mon, Feb 20, 2023 at 06:06:03PM +0100, Danilo Krummrich wrote:
> > > On 2/20/23 16:10, Matthew Wilcox wrote:
> > > > This is
On Wed, Feb 22, 2023 at 05:11:34PM +0100, Danilo Krummrich wrote:
> On 2/21/23 19:31, Matthew Wilcox wrote:
> > on tue, feb 21, 2023 at 03:37:49pm +0100, danilo krummrich wrote:
> > > It feels a bit weird that I, as a user of the API, would need to lock
> > > c
On Mon, Feb 27, 2023 at 06:39:33PM +0100, Danilo Krummrich wrote:
> On 2/21/23 19:31, Matthew Wilcox wrote:
> > Lockdep will shout at you if you get it wrong ;-) But you can safely
> > take the spinlock before calling mas_store_gfp(GFP_KERNEL) because
> > mas_nomem() knows to
On Thu, Jan 19, 2023 at 03:23:08PM +0900, Byungchul Park wrote:
> Boqun wrote:
> > * Looks like the DEPT dependency graph doesn't handle the
> > fair/unfair readers as lockdep current does. Which bring the
> > next question.
>
> No. DEPT works better for unfair read. It works based on wa
On Sat, Jan 21, 2023 at 11:03:05AM -0400, Jason Gunthorpe wrote:
> I would like to have a session at LSF to talk about Matthew's
> physr discussion starter:
>
> https://lore.kernel.org/linux-mm/ydykweu0htv8m...@casper.infradead.org/
I'm definitely interested in discussing phyrs (even if you'd ra
On Mon, Jan 23, 2023 at 11:36:51AM -0800, Dan Williams wrote:
> Jason Gunthorpe via Lsf-pc wrote:
> > I would like to have a session at LSF to talk about Matthew's
> > physr discussion starter:
> >
> > https://lore.kernel.org/linux-mm/ydykweu0htv8m...@casper.infradead.org/
> >
> > I have become
On Mon, Jan 23, 2023 at 12:50:52PM -0800, Dan Williams wrote:
> Matthew Wilcox wrote:
> > On Mon, Jan 23, 2023 at 11:36:51AM -0800, Dan Williams wrote:
> > > Jason Gunthorpe via Lsf-pc wrote:
> > > > I would like to have a session at LSF to talk about Matthew'
On Thu, Oct 20, 2022 at 03:35:16PM +0200, Kwapulinski, Maciej wrote:
> +++ b/drivers/gpu/drm/gna/Kconfig
> @@ -0,0 +1,12 @@
> +#
> +# Intel(R) Gaussian & Neural Accelerator (Intel(R) GNA)
> +#
> +
> +config DRM_GNA
> + tristate "Intel(R) Gaussian & Neural Accelerator (Intel(R) GNA)"
> + dep
On Sun, Nov 06, 2022 at 04:51:39PM +0200, Oded Gabbay wrote:
> I tried executing the following code in a dummy driver I wrote:
You don't need to write a dummy driver; you can write test-cases
entirely in userspace. Just add them to lib/test_xarray.c and then
make -C tools/testing/radix-tree/
> s
changing how DRM + ACCEL do minor id handling.
>
> This sounds sane to me. However, this appears to be something that Matthew
> Wilcox should be aware of (added for visibility). Perhaps he has a very
> quick solution. If not, at-least he might have ideas on how to best address
> in t
On Thu, Jun 15, 2023 at 03:33:12PM -0400, Peter Xu wrote:
> My question is whether page_zonenum() is ready for taking all kinds of tail
> pages?
>
> Zone device tail pages all look fine, per memmap_init_zone_device(). The
> question was other kinds of usual compound pages, like either thp or
> hu
On Sun, Jul 30, 2023 at 07:01:26PM +0800, Zhu Yanjun wrote:
> Does the following function have folio version?
>
> "
> int sg_alloc_append_table_from_pages(struct sg_append_table *sgt_append,
> struct page **pages, unsigned int n_pages, unsigned int offset,
> unsigned lo
On Sun, Jul 30, 2023 at 09:57:06PM +0800, Zhu Yanjun wrote:
>
> 在 2023/7/30 19:18, Matthew Wilcox 写道:
> > On Sun, Jul 30, 2023 at 07:01:26PM +0800, Zhu Yanjun wrote:
> > > Does the following function have folio version?
> > >
> > > "
>
On Mon, Aug 21, 2023 at 12:46:20PM +0900, Byungchul Park wrote:
> @@ -1219,6 +1220,9 @@ static inline bool folio_trylock_flag(struct folio
> *folio, int bit_nr,
> /* How many times do we accept lock stealing from under a waiter? */
> int sysctl_page_lock_unfairness = 5;
>
> +static struct dept
On Mon, Aug 21, 2023 at 12:46:37PM +0900, Byungchul Park wrote:
> @@ -377,44 +421,88 @@ static __always_inline int Page##uname(struct page
> *page) \
> #define SETPAGEFLAG(uname, lname, policy)\
> static __always_inline
On Mon, Aug 21, 2023 at 01:16:43PM +0200, Jan Kara wrote:
> On Sat 19-08-23 20:42:25, Xueshi Hu wrote:
> > In folio_mark_dirty(), it will automatically fallback to
> > noop_dirty_folio() if a_ops->dirty_folio is not registered.
> >
> > As anon_aops, dev_dax_aops and fb_deferred_io_aops becames emp
enguin-ker...@i-love.sakura.ne.jp
> ]
>
> On 03/24/2017 07:17 PM, Matthew Wilcox wrote:
> > On Fri, Mar 24, 2017 at 06:05:45PM +0300, Andrey Ryabinin wrote:
> >> Just fix the drm code. There is zero point in releasing memory under
> >> spinlock.
> >
> > I di
On Thu, Oct 08, 2020 at 01:23:39PM +0200, Christian König wrote:
> drivers/dma-buf/dma-buf.c | 16 +---
> drivers/gpu/drm/etnaviv/etnaviv_gem.c | 4 +---
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 3 +--
> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 4 ++--
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, 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 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 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
dereferenced for reading, constify it.
>
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: "Matthew Wilcox (Oracle)"
> Cc: "Kirill A. Shutemov"
> Cc: Ralph Campbell
> Cc: "Jérôme Glisse"
> Cc: "Christian König"
> Cc: Dan William
On Wed, Apr 08, 2020 at 05:12:03PM +0200, Peter Zijlstra wrote:
> On Wed, Apr 08, 2020 at 08:01:00AM -0700, Randy Dunlap wrote:
> > Hi,
> >
> > On 4/8/20 4:59 AM, Christoph Hellwig wrote:
> > > diff --git a/mm/Kconfig b/mm/Kconfig
> > > index 36949a9425b8..614cc786b519 100644
> > > --- a/mm/Kconfi
On Mon, Sep 14, 2020 at 11:55:24PM +0200, Thomas Gleixner wrote:
> But just look at any check which uses preemptible(), especially those
> which check !preemptible():
hmm.
+++ b/include/linux/preempt.h
@@ -180,7 +180,9 @@ do { \
#define preempt_enable_no_resched() sched_preempt_enable_no_resch
On Sat, Sep 19, 2020 at 10:18:54AM -0700, Linus Torvalds wrote:
> On Sat, Sep 19, 2020 at 2:50 AM Thomas Gleixner wrote:
> >
> > this provides a preemptible variant of kmap_atomic & related
> > interfaces. This is achieved by:
>
> Ack. This looks really nice, even apart from the new capability.
>
On Fri, Sep 18, 2020 at 06:37:21PM +0200, Christoph Hellwig wrote:
> void shmem_unpin_map(struct file *file, void *ptr)
> {
> + long i = shmem_npages(file);
> +
> mapping_clear_unevictable(file->f_mapping);
> - __shmem_unpin_map(file, ptr, shmem_npte(file));
> + vunmap(ptr);
> +
On Tue, Sep 22, 2020 at 04:39:06PM +0200, Christoph Hellwig wrote:
> On Tue, Sep 22, 2020 at 12:21:44PM +0100, Matthew Wilcox wrote:
> > Actually, vfree() will work today; I cc'd you on a documentation update
> > to make it clear that this is permitted.
>
> vfree calls
On Tue, Sep 22, 2020 at 08:22:49AM +0200, Christoph Hellwig wrote:
> On Mon, Sep 21, 2020 at 08:11:57PM +0100, Matthew Wilcox wrote:
> > This is awkward. I'd like it if we had a vfree() variant which called
> > put_page() instead of __free_pages(). I'd like it
On Mon, Aug 03, 2020 at 09:00:00AM -0700, Suren Baghdasaryan wrote:
> On Mon, Aug 3, 2020 at 8:41 AM Matthew Wilcox wrote:
> >
> > On Mon, Aug 03, 2020 at 02:47:19PM +, Kalesh Singh wrote:
> > > +static void dma_buf_fd_install(i
On Mon, Aug 03, 2020 at 02:47:19PM +, Kalesh Singh wrote:
> +static void dma_buf_fd_install(int fd, struct file *filp)
> +{
> + trace_dma_buf_fd_ref_inc(current, filp);
> +}
You're adding a new file_operation in order to just add a new tracepoint?
NACK.
From: Tejun Heo [mailto:hte...@gmail.com] On Behalf Of Tejun Heo
> Ah, yeah, great to see the silly implementation being replaced the
> radix tree. ida_pre_get() looks suspicious tho. idr_preload()
> immedicately being followed by idr_preload_end() probably is broken.
> Maybe what we need is movi
From: Rasmus Villemoes [mailto:li...@rasmusvillemoes.dk]
> On Fri, Dec 16 2016, Matthew Wilcox wrote:
> > Thanks for your work on this; you've really put some effort into
> > proving your work has value. My motivation was purely aesthetic, but
> > you've got some g
From: Andrew Morton [mailto:a...@linux-foundation.org]
> On Thu, 8 Dec 2016 02:22:55 +0100 Rasmus Villemoes
> wrote:
> > TL;DR: these patches save 250 KB of memory, with more low-hanging
> > fruit ready to pick.
> >
> > While browsing through the lib/idr.c code, I noticed that the code at
> > the
From: Matthew Wilcox
> From: Rasmus Villemoes [mailto:linux at rasmusvillemoes.dk]
> > This sounds good. I think there may still be a lot of users that never
> > allocate more than a handful of IDAs, making a 128 byte allocation still
> > somewhat excessive. One thing I consi
From: Matthew Wilcox
> From: Matthew Wilcox
> > Heh, I was thinking about that too. The radix tree supports "exceptional
> > entries" which have the bottom bit set. On a 64-bit machine, we could use
> 62
> > of the bits in the radix tree root to store the ID
From: Rasmus Villemoes [mailto:li...@rasmusvillemoes.dk]
> Nice work! A few random comments/questions:
>
> - It does add some complexity, but I think a few comments would make it
> more digestable.
I'm open to adding some comments ... I need some time between writing the code
and writing the c
On Tue, Oct 02, 2018 at 01:43:28PM +0200, Gerd Hoffmann wrote:
> On Wed, Sep 26, 2018 at 09:04:55AM -0700, Matthew Wilcox wrote:
> > On Wed, Sep 26, 2018 at 09:00:31AM -0700, Matthew Wilcox wrote:
> > > @@ -59,6 +59,7 @@ static int virtio_gpu_context_create(struct
> > &g
On Thu, Oct 04, 2018 at 12:28:54AM +0530, Souptick Joarder wrote:
> These are the approaches which could have been taken to handle
> this scenario -
>
> * Replace vm_insert_page with vmf_insert_page and then write few
>extra lines of code to convert VM_FAULT_CODE to errno which
>makes dri
On Wed, Oct 03, 2018 at 11:14:45PM +0100, Russell King - ARM Linux wrote:
> On Wed, Oct 03, 2018 at 01:00:03PM -0700, Matthew Wilcox wrote:
> > On Thu, Oct 04, 2018 at 12:28:54AM +0530, Souptick Joarder wrote:
> > > These are the approaches which could have been taken to handle
&
On Thu, Oct 04, 2018 at 11:42:18PM +0530, Souptick Joarder wrote:
> On Thu, Oct 4, 2018 at 6:04 PM Russell King - ARM Linux
> wrote:
> > I'm confused, what are you trying to do?
> >
> > It seems that we already have:
> >
> > vm_insert_page() - returns an errno
> > vmf_insert_page() - returns a VM_
> > > Because we already have a plan for entire vm_fault_t migration and
> > > the * instruction * was to send one patch per driver.
> >
> > The instruction?
>
> Sorry for the delayed response.
> Instruction from Matthew Wilcox who is supervising the entire
On Tue, Oct 23, 2018 at 06:03:42PM +0530, Souptick Joarder wrote:
> On Tue, Oct 23, 2018 at 5:54 PM Matthew Wilcox wrote:
> > On Tue, Oct 23, 2018 at 05:44:32PM +0530, Souptick Joarder wrote:
> > > Instruction from Matthew Wilcox who is supervising the entire vm_fault_t
&g
0-based IDAs are more efficient than any other base. Convert the
1-based IDAs to be 0-based.
Signed-off-by: Matthew Wilcox
---
drivers/gpu/drm/virtio/virtgpu_kms.c| 5 +++--
drivers/gpu/drm/virtio/virtgpu_object.c | 6 +++---
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a
On Mon, Oct 29, 2018 at 10:53:39PM +0100, Gerd Hoffmann wrote:
> On Wed, Sep 26, 2018 at 09:00:27AM -0700, Matthew Wilcox wrote:
> > I noticed you were using IDRs where you could be using the more efficient
> > IDAs, then while fixing that I noticed the lack of error handling,
>
ida_alloc() can return -ENOMEM in the highly unlikely case we run out
of memory. The current code creates an object with an invalid ID.
Signed-off-by: Matthew Wilcox
---
drivers/gpu/drm/virtio/virtgpu_object.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a
On Thu, Jun 14, 2018 at 01:54:15PM +0200, Thomas Hellstrom wrote:
> On 06/14/2018 01:36 PM, Peter Zijlstra wrote:
> > Currently you don't allow mixing WD and WW contexts (which is not
> > immediately obvious from the above code), and the above hard relies on
> > that. Are there sensible use cases f
On Wed, May 16, 2018 at 07:43:34AM +0200, Christoph Hellwig wrote:
> this series tries to actually turn vm_fault_t into a type that can be
> typechecked and checks the fallout instead of sprinkling random
> annotations without context.
Yes, why should we have small tasks that newcomers can do when
On Wed, May 16, 2018 at 03:01:59PM +0200, Christoph Hellwig wrote:
> On Wed, May 16, 2018 at 11:53:03AM +0200, Daniel Vetter wrote:
> > Reviewed-by: Daniel Vetter
> >
> > Want me to merge this through drm-misc or plan to pick it up yourself?
>
> For now I just want a honest discussion if people
On Wed, May 16, 2018 at 03:03:09PM +0200, Christoph Hellwig wrote:
> On Wed, May 16, 2018 at 04:23:47AM -0700, Matthew Wilcox wrote:
> > On Wed, May 16, 2018 at 07:43:34AM +0200, Christoph Hellwig wrote:
> > > this series tries to actually turn vm_fault_t into a type that can be
On Wed, May 16, 2018 at 07:43:48AM +0200, Christoph Hellwig wrote:
> Switch vm_fault_t to point to an unsigned int with __bіtwise annotations.
> This both catches any old ->fault or ->page_mkwrite instance with plain
> compiler type checking, as well as finding more intricate problems with
> sparse
On Wed, May 16, 2018 at 07:43:35AM +0200, Christoph Hellwig wrote:
> + rc = orangefs_inode_getattr(file->f_mapping->host, 0, 1, STATX_SIZE);
> if (rc) {
> gossip_err("%s: orangefs_inode_getattr failed, "
> "rc:%d:.\n", __func__, rc);
> - return
On Fri, Nov 16, 2018 at 11:00:30AM +0530, Souptick Joarder wrote:
> On Thu, Nov 15, 2018 at 11:44 PM Randy Dunlap wrote:
> > On 11/15/18 7:45 AM, Souptick Joarder wrote:
> > What is the opposite of vm_insert_range() or even of vm_insert_page()?
> > or is there no need for that?
>
> There is no op
On Sat, Nov 17, 2018 at 12:26:38PM +0530, Souptick Joarder wrote:
> On Fri, Nov 16, 2018 at 11:59 PM Mike Rapoport wrote:
> > > + * vm_insert_range - insert range of kernel pages into user vma
> > > + * @vma: user vma to map to
> > > + * @addr: target user address of this page
> > > + * @pages: po
On Mon, Nov 19, 2018 at 09:08:20AM +0800, kernel test robot wrote:
> Greetings,
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
Umm. I don't see a 'suspicious RCU usage' message in here. I see a
lot of vmalloc warnings ... ?
> [7.699777] swapper: vmalloc: allo
On Sun, Nov 18, 2018 at 05:19:04PM -0800, Matthew Wilcox wrote:
> On Mon, Nov 19, 2018 at 09:08:20AM +0800, kernel test robot wrote:
> > Greetings,
> >
> > 0day kernel testing robot got the below dmesg and the first bad commit is
>
> Umm. I don't see a 'susp
On Mon, Nov 19, 2018 at 01:02:46PM +0200, Oleksandr Andrushchenko wrote:
> On 11/19/18 12:42 PM, Souptick Joarder wrote:
> > On Mon, Nov 19, 2018 at 3:22 PM Oleksandr Andrushchenko
> > wrote:
> > > > - unsigned long addr = vma->vm_start;
> > > > - int i;
> > > > + int err;
> > > I woul
On Wed, Nov 21, 2018 at 04:19:11AM -0700, William Kucharski wrote:
> Could you add a line to the description explicitly stating that a failure
> to insert any page in the range will fail the entire routine, something
> like:
>
> > * This allows drivers to insert range of kernel pages they've alloc
On Tue, Aug 21, 2018 at 05:16:11PM +0100, Brian Starkey wrote:
> There's a number of things which haven't previously been documented
> around the usage of format modifiers. Capture the current
> understanding in an overview comment and add it to the rst
> documentation.
>
> Ideally, the generated
; > On Tue, Aug 21, 2018 at 09:26:39AM -0700, Matthew Wilcox wrote:
> > > > > Can you turn them into enums? This seems to work ok:
>
> I'm not sure that swapping out explicit 32-bit unsigned integers for
> enums (unspecified width, signed integers) is necessarily a go
On Tue, Aug 28, 2018 at 10:44:43PM +0530, Souptick Joarder wrote:
> We have introduce a new return type vm_fault_t for
> fault handler. Update the document for the same.
Have you built the documentation and checked the html looks better with
the changed spacing? rst can be a bit weird about some
Reorder allocation to avoid an awkward lock/unlock/lock sequence.
Simpler code due to being able to use ida_alloc_max(), even if we can't
eliminate the driver's spinlock.
Signed-off-by: Matthew Wilcox
---
drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 41 ++-
1 file c
On Tue, Jul 03, 2018 at 09:40:43PM +0530, Souptick Joarder wrote:
> Use new return type vm_fault_t for fault handler. For
> now, this is just documenting that the function returns
> a VM_FAULT value rather than an errno. Once all instances
> are converted, vm_fault_t will become a distinct type.
>
On Wed, Jul 04, 2018 at 08:25:57PM +0530, Souptick Joarder wrote:
> Convert v3d_gem_fault to return vm_fault_t
>
> Instead of converting an errno into a vm_fault_t ourselves, use
> vmf_insert_mixed() which returns a vm_fault_t directly.
>
> Signed-off-by: Souptick Joarder
Re
On Thu, Dec 06, 2018 at 12:32:47PM +, Kieran Bingham wrote:
> On 04/12/2018 20:47, Luis Chamberlain wrote:
> > On Mon, Dec 03, 2018 at 03:48:15PM -0800, Brendan Higgins wrote:
> >> On Thu, Nov 29, 2018 at 5:54 AM Kieran Bingham
> >> wrote:
> >>>
> >>> Hi Brendan,
> >>>
> >>> Thanks again for t
On Fri, Dec 07, 2018 at 03:34:56PM +, Robin Murphy wrote:
> > +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> > + struct page **pages, unsigned long page_count)
> > +{
> > + unsigned long uaddr = addr;
> > + int ret = 0, i;
>
> Some of the sites bei
On Thu, Sep 13, 2018 at 06:52:43PM +0200, Thomas Hellstrom wrote:
> On 09/13/2018 05:28 PM, Matthew Wilcox wrote:
> > On Thu, Sep 13, 2018 at 04:56:53PM +0200, Thomas Hellstrom wrote:
> > > On 09/13/2018 04:10 PM, Matthew Wilcox wrote:
> > > > I think this could be
On Thu, Sep 13, 2018 at 01:58:37PM +0200, Thomas Hellstrom wrote:
> Commit 4eb085e42fde ("drm/vmwgfx: Convert to new IDA API") indroduced
> an incorrect return value from the function vmw_gmrid_man_get_node(),
> when we run out if integer ids. Instead of returning 0 (meaning
> non-fatal error) we f
On Thu, Sep 13, 2018 at 04:56:53PM +0200, Thomas Hellstrom wrote:
> Hi,
>
> On 09/13/2018 04:10 PM, Matthew Wilcox wrote:
> > On Thu, Sep 13, 2018 at 01:58:37PM +0200, Thomas Hellstrom wrote:
> > > Commit 4eb085e42fde ("drm/vmwgfx: Convert to new IDA API") in
ted using glretrace.
>
> Cc:
> Signed-off-by: Thomas Hellstrom
> Reviewed-by: Sinclair Yeh
Reviewed-by: Matthew Wilcox
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
101 - 200 of 278 matches
Mail list logo
