On Wed, 12 Jun 2019 01:08:36 +0530 Shyam Saini
wrote:
> Currently, there are 3 different macros, namely sizeof_field, SIZEOF_FIELD
> and FIELD_SIZEOF which are used to calculate the size of a member of
> structure, so to bring uniformity in entire kernel source tree lets use
> FIELD_SIZEOF and r
On Tue, 11 Jun 2019 15:00:10 -0600 Andreas Dilger wrote:
> >> to FIELD_SIZEOF
> >
> > As Alexey has pointed out, C structs and unions don't have fields -
> > they have members. So this is an opportunity to switch everything to
> > a new member_sizeof().
> >
> > What do people think of that and
On Fri, 5 Jul 2019 13:14:35 +1000 Stephen Rothwell
wrote:
> > I checked next-20190704 tag.
> >
> > I see the empty file
> > drivers/gpu/drm/i915/oa/Makefile
> >
> > Did someone delete it?
>
> Commit
>
> 5ed7a0cf3394 ("drm/i915: Move OA files to separate folder")
>
> from the drm-intel tre
On Thu, 04 Jul 2019 22:22:41 -0700 Joe Perches wrote:
> > So when comparing a zero-length file with a non-existent file, diff
> > produces no output.
>
> Why use the -N option ?
>
> $ diff --help
> [...]
> -N, --new-file treat absent files as empty
>
> otherwise
>
> $ cd $(
On Wed, 10 Aug 2022 17:09:37 +0100 Matthew Wilcox wrote:
> On Wed, Aug 10, 2022 at 08:55:32AM -0700, Hugh Dickins wrote:
> > This is not a bug in zram or i915, but what Matthew fixes in
> > https://lore.kernel.org/lkml/20220730042518.1264767-1-wi...@infradead.org/
>
> Thanks for tracking that do
On Sun, 6 Mar 2022 05:26:55 +0200 Jarkko Sakkinen wrote:
> Sometimes you might want to use MAP_POPULATE to ask a device driver to
> initialize the device memory in some specific manner. SGX driver can use
> this to request more memory by issuing ENCLS[EAUG] x86 opcode for each
> page in the addr
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Tue, 01 Oct 2019 17:06:35 + bugzilla-dae...@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=205065
>
> Bug ID: 205065
>Summary: workqueue: P
On Wed, 23 Oct 2019 16:13:08 +0300 Jani Nikula wrote:
> The kernel has plenty of ternary operators to choose between constant
> strings, such as condition ? "yes" : "no", as well as value == 1 ? "" :
> "s":
>
> $ git grep '? "yes" : "no"' | wc -l
> 258
> $ git grep '? "on" : "off"' | wc -l
> 204
On Tue, 10 Mar 2020 08:47:49 -0700 "Paul E. McKenney"
wrote:
> On Tue, Mar 10, 2020 at 03:05:57PM +, David Laight wrote:
> > From: Marco Elver
> > > Sent: 10 March 2020 14:10
> > ...
> > > FWIW, for writes we're already being quite generous, in that plain
> > > aligned writes up to word-size
On Wed, 14 Aug 2019 22:20:24 +0200 Daniel Vetter wrote:
> In some special cases we must not block, but there's not a
> spinlock, preempt-off, irqs-off or similar critical section already
> that arms the might_sleep() debug checks. Add a non_block_start/end()
> pair to annotate these.
>
> This wi
On Wed, 14 Aug 2019 22:20:23 +0200 Daniel Vetter wrote:
> Just a bit of paranoia, since if we start pushing this deep into
> callchains it's hard to spot all places where an mmu notifier
> implementation might fail when it's not allowed to.
>
> Inspired by some confusion we had discussing i915 m
On Thu, 15 Aug 2019 10:44:29 +0200 Michal Hocko wrote:
> > I continue to struggle with this. It introduces a new kernel state
> > "running preemptibly but must not call schedule()". How does this make
> > any sense?
> >
> > Perhaps a much, much more detailed description of the oom_reaper
> > s
On Tue, 20 Aug 2019 22:24:40 +0200 Daniel Vetter wrote:
> Hi Peter,
>
> Iirc you've been involved at least somewhat in discussing this. -mm folks
> are a bit undecided whether these new non_block semantics are a good idea.
> Michal Hocko still is in support, but And
On Fri, 1 May 2020 15:20:44 -0300 Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> There is no reason for a user to select this or not directly - it should
> be selected by drivers that are going to use the feature, similar to how
> CONFIG_HMM_MIRROR works.
>
> Currently all drivers provide
On Fri, 21 Aug 2020 14:37:46 +0200 Joerg Roedel wrote:
> The __apply_to_page_range() function is also used to change and/or
> allocate page-table pages in the vmalloc area of the address space.
> Make sure these changes get synchronized to other page-tables in the
> system by calling arch_sync_ke
On Fri, 21 Aug 2020 14:37:46 +0200 Joerg Roedel wrote:
> The __apply_to_page_range() function is also used to change and/or
> allocate page-table pages in the vmalloc area of the address space.
> Make sure these changes get synchronized to other page-tables in the
> system by calling arch_sync_ke
On Thu, 24 Sep 2020 15:58:42 +0200 Christoph Hellwig wrote:
> this series removes alloc_vm_area, which was left over from the big
> vmalloc interface rework. It is a rather arkane interface, basicaly
> the equivalent of get_vm_area + actually faulting in all PTEs in
> the allocated area. It was
On Wed, 19 Feb 2020 11:20:31 +0100 Daniel Vetter wrote:
> tracker in drm for stuff that's tied to the lifetime of a drm_device,
> not the underlying struct device. Kinda like devres, but for drm.
>
> ...
>
> Ack for merging through drm trees very much appreciated.
c(struct pagevec *pvec)
> +{
> + if (pagevec_count(pvec)) {
> + check_move_unevictable_pages(pvec);
> + __pagevec_release(pvec);
> + cond_resched();
> + }
> +}
This looks too large to be inlined and the co
On Mon, 9 Jul 2018 18:25:09 +0200 Daniel Vetter wrote:
> To avoid compilers complainig about ambigious else blocks when putting
> an if condition into a for_each macro one needs to invert the
> condition and add a dummy else. We have a nice little convenience
> macro for that in drm headers, let
On Wed, 11 Jul 2018 13:51:08 +0200 Daniel Vetter wrote:
> But I still have the situation that a bunch of maintainers acked this
> and Andrew Morton defacto nacked it, which I guess means I'll keep the
> macro in drm? The common way to go about this seems to be to just push
>
On Mon, 16 Jul 2018 13:50:58 +0200 Michal Hocko wrote:
> From: Michal Hocko
>
> There are several blockable mmu notifiers which might sleep in
> mmu_notifier_invalidate_range_start and that is a problem for the
> oom_reaper because it needs to guarantee a forward progress so it cannot
> depend
On Tue, 17 Jul 2018 10:12:01 +0200 Michal Hocko wrote:
> > Any suggestions regarding how the driver developers can test this code
> > path? I don't think we presently have a way to fake an oom-killing
> > event? Perhaps we should add such a thing, given the problems we're
> > having with that f
On Mon, 16 Jul 2018 13:50:58 +0200 Michal Hocko wrote:
> From: Michal Hocko
>
> There are several blockable mmu notifiers which might sleep in
> mmu_notifier_invalidate_range_start and that is a problem for the
> oom_reaper because it needs to guarantee a forward progress so it cannot
> depend
On Tue, 24 Jul 2018 16:17:47 +0200 Michal Hocko wrote:
> On Fri 20-07-18 17:09:02, Andrew Morton wrote:
> [...]
> > - Undocumented return value.
> >
> > - comment "failed to reap part..." is misleading - sounds like it's
> > referring to som
On Tue, 22 Nov 2016 14:30:39 + Chris Wilson
wrote:
> Drivers, or other modules, that use a mixture of objects (especially
> objects embedded within other objects) would like to take advantage of
> the debugobjects facilities to help catch misuse. Currently, the
> debugobjects interface is on
On Fri, 15 Apr 2016 12:14:31 +0100 Chris Wilson
wrote:
> > > purge_fragmented_blocks() manages per-cpu lists, so that looks safe
> > > under its own rcu_read_lock.
> > >
> > > Yes, it looks feasible to remove the purge_lock if we can relax sync.
> >
> > what is still left is waiting on vmap_are
nterface is styled after the oom-notifier where the callees are
> > passed a pointer to an unsigned long counter for them to indicate if they
> > have freed any space.
> >
> > v2: Guard the blocking notifier call with gfpflags_allow_blocking()
> >
> > Signed-off
On Wed, 23 Dec 2015 17:04:27 -0500 Johannes Weiner wrote:
> On Thu, Dec 10, 2015 at 10:32:42AM +0100, Daniel Vetter wrote:
> > On Fri, Dec 04, 2015 at 11:09:52AM -0500, Johannes Weiner wrote:
> > > On Fri, Dec 04, 2015 at 03:58:53PM +, Chris Wilson wrote:
> > > > Some modules, like i915.ko, u
On Thu, 08 Mar 2018 12:06:46 +0200 Jani Nikula
wrote:
> On Wed, 07 Mar 2018, a...@linux-foundation.org wrote:
> > From: Andrew Morton
> > Subject: drivers/gpu/drm/i915/intel_guc_log.c: work around gcc-4.4.4 union
> > initializer issue
> >
> > gcc-4.4.4 has
On Wed, 2 Aug 2017 14:06:39 +0100 Tvrtko Ursulin
wrote:
>
> Hi Andrew,
>
> We have a couple of small lib/scatterlist.c tidies here, plus exporting
> the new API which allows drivers to control the maximum coalesced entry
> as created by __sg_alloc_table_from_pages.
>
> I am looking for an a
On Sat, 12 Aug 2017 12:34:37 +0100 Chris Wilson
wrote:
> Some shrinkers may only be able to free a bunch of objects at a time, and
> so free more than the requested nr_to_scan in one pass. Account for the
> extra freed objects against the total number of objects we intend to
> free, otherwise we
Cc: Shaohua Li
Cc: Christoph Lameter
Cc: David Rientjes
Cc: Joonsoo Kim
Cc: Pekka Enberg
Signed-off-by: Andrew Morton
---
drivers/gpu/drm/i915/i915_debugfs.c |4 +--
drivers/gpu/drm/i915/i915_drv.h |1
drivers/gpu/drm/i915/i915_gem.c |4 +--
drivers/gp
On Wed, 23 Aug 2017 12:31:28 +0300 Joonas Lahtinen
wrote:
> This patch has been floating around for a while now Acked and without
> further comments. It is blocking us from merging huge page support to
> drm/i915.
>
> Would you mind merging it, or prodding the right people to get it in?
>
> Re
On Thu, 24 Aug 2017 13:04:09 +0100 Matthew Auld
wrote:
> On 23 August 2017 at 23:34, Andrew Morton wrote:
> > On Wed, 23 Aug 2017 12:31:28 +0300 Joonas Lahtinen
> > wrote:
> >
> >> This patch has been floating around for a while now Acked and without
> >&
On Thu, 24 Aug 2017 10:00:49 +0200 Vlastimil Babka wrote:
> > Even if a
> > shrinker has a mistake, VM will have big trouble like infinite loop.
>
> We could fake 0 as 1 or something, at least.
If the shrinker returns sc->nr_scanned==0 then that's a buggy shrinker
- it should return SHRINK_STOP
On Thu, 3 Aug 2023 16:19:18 +0300 Andy Shevchenko
wrote:
> abs_diff() belongs to math.h. Move it there.
> This will allow others to use it.
>
> ...
>
> --- a/include/linux/math.h
> +++ b/include/linux/math.h
> @@ -155,6 +155,13 @@ __STRUCT_FRACT(u32)
> __builtin_types_compatible_p(typeof
On Sun, 26 Feb 2023 01:10:55 +0800 kernel test robot wrote:
> tree/branch:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> branch HEAD: 8232539f864ca60474e38eb42d451f5c26415856 Add linux-next
> specific files for 20230225
>
> Error/Warning reports:
>
> mm/page_
On Wed, 10 Jan 2024 10:21:07 +0100 Christoph Hellwig wrote:
> Hi all,
>
> Darrick reported that the fairly new XFS xfile code blows up when force
> enabling large folio for shmem. This series fixes this quickly by disabling
> large folios for this particular shmem file for now until it can be f
On Wed, 10 Jan 2024 12:04:51 -0800 "Darrick J. Wong" wrote:
> > > Fixing this will require a bit of an API change, and prefeably sorting out
> > > the hwpoison story for pages vs folio and where it is placed in the shmem
> > > API. For now use this one liner to disable large folios.
> > >
> > >
On Thu, 22 Dec 2022 12:46:16 +0100 Andrzej Hajda
wrote:
> Hi all,
>
> I hope there will be place for such tiny helper in kernel.
> Quick cocci analyze shows there is probably few thousands places
> where it could be useful.
So to clarify, the intent here is a simple readability cleanup for
exi
On Tue, 25 Oct 2022 11:03:38 +0100 Mel Gorman
wrote:
> > If so I
> > can temporarily put it in until it arrives via the next rc - assuming that
> > would be the flow from upstream pov?
> >
>
> I expect it to. It's currently in the akpm/mm.git branch
> mm/mm-hotfixes-unstable where I expect it
On Mon, 10 May 2010 14:26:52 -0700 Jesse Barnes
wrote:
> Intel Core i3/5 platforms with integrated graphics support both CPU and
> GPU turbo mode. CPU turbo mode is opportunistic: the CPU will use any
> available power to increase core frequencies if thermal headroom is
> available. The GPU si
On Tue, 11 May 2010 19:22:14 +0100 Chris Wilson
wrote:
> + reloc_offset = src_priv->gtt_offset;
> for (page = 0; page < page_count; page++) {
> - void *s, *d = kmalloc(PAGE_SIZE, GFP_ATOMIC);
> + void __iomem *s;
> + void *d;
> +
> + d =
On Tue, 11 May 2010 11:18:54 -0700 Jesse Barnes
wrote:
> > > > +#define thm_writeb(off, val) writeb((val), ips->regmap + (off))
> > > > +#define thm_writew(off, val) writew((val), ips->regmap + (off))
> > > > +#define thm_writel(off, val) writel((val), ips->regmap + (off))
> > >
> > > ick.
> >
On Thu, 30 Mar 2023 13:42:39 +0300 Jani Nikula wrote:
> is_power_of_2() only works for types <= sizeof(unsigned long) and it's
> also not a constant expression. There are a number of places in kernel
> where is_power_of_2() is called on u64, which fails on 32-bit
> builds. Try to remedy that. Whi
On Thu, 30 Mar 2023 21:53:03 + David Laight wrote:
> > But wouldn't all these issues be addressed by simply doing
> >
> > #define is_power_of_2(n) (n != 0 && ((n & (n - 1)) == 0))
> >
> > ?
> >
> > (With suitable tweaks to avoid evaluating `n' more than once)
>
> I think you need to use t
On Wed, 17 Jul 2024 13:00:58 +0200 David Hildenbrand wrote:
> > Could you please check why the patch causes this regression and provide a
> > fix if necessary?
>
> This is know.
>
> There is a discussion along the original patch [1] on how to do it
> differently. But likely we'll tackle it di
On Thu, 11 Jan 2024 18:22:50 -0800 "Darrick J. Wong" wrote:
> On Thu, Jan 11, 2024 at 10:45:53PM +, Matthew Wilcox wrote:
> > On Thu, Jan 11, 2024 at 02:00:53PM -0800, Andrew Morton wrote:
> > > On Wed, 10 Jan 2024 12:04:51 -0800 "Darrick J. Wong"
On Thu, 10 Apr 2014 08:05:06 +0100 Chris Wilson
wrote:
> During testing of i915.ko with working texture sets larger than RAM, we
> encounter OOM with plenty of memory still trapped within writeback, e.g:
>
> [ 42.386039] active_anon:10134 inactive_anon:1900781 isolated_anon:32
> active_file:
On Wed, 5 Mar 2014 10:33:14 +0100 Daniel Vetter wrote:
> Users just love to set random piles of options since surely enabling
> all the experimental stuff helps. Later on we get bug reports because
> it all fell apart.
>
> Even more fun when it's labelled a regression when some change only
> ju
On Sun, 26 Jan 2014 12:24:33 + Chris Wilson
wrote:
> Note for maintainers, this is being proposed for use by i915.ko, so it
> may make the most sense to merge it via the drm/i915 tree in the next
> cycle.
Yes, please proceed that way.
___
Intel-gf
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Wed, 06 Nov 2013 19:12:29 + bugzilla-dae...@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=64521
>
> Bug ID: 64521
>Summary: BUG kmalloc-4
On Tue, 26 Mar 2013 15:50:20 +0100 Daniel Vetter wrote:
> On Tue, Mar 26, 2013 at 03:14:17PM +0200, Imre Deak wrote:
> > When adding sg_page_iter I haven't thought properly through the use case
> > for sg lists w/o backing pages - which is specific to the i915 driver -
> > so this patchset adds s
On Wed, 10 Aug 2011 07:53:18 -0700 Keith Packard wrote:
> On Wed, 10 Aug 2011 15:14:09 +0200, Michel Alexandre Salim
> wrote:
>
> > FYI, I'm using that on top of Linux 3.0 and 3.1-rc1 and it still works
> > fine.
>
> Matthew -- shall I just merge the old patch? Or did you want to make
> some
On Thu, 16 Feb 2012 13:01:36 +0100
Daniel Vetter wrote:
> drm/i915 wants to read/write more than one page in its fastpath
> and hence needs to prefault more than PAGE_SIZE bytes.
>
> I've checked the callsites and they all already clamp size when
> calling fault_in_pages_* to the same as for the
On Fri, 24 Feb 2012 14:34:31 +0100
Daniel Vetter wrote:
> > > --- a/include/linux/pagemap.h
> > > +++ b/include/linux/pagemap.h
> > > @@ -408,6 +408,7 @@ extern void add_page_wait_queue(struct page *page,
> > > wait_queue_t *waiter);
> > > static inline int fault_in_pages_writeable(char __user
* to the same as for the subsequent
> __copy_to|from_user and hence don't rely on the implicit clamping
> to PAGE_SIZE.
>
> Also kill a copy&pasted spurious space in both functions while at it.
>
> v2: As suggested by Andrew Morton, add a multipage parameter to both
>
On Thu, 1 Mar 2012 00:14:53 +0100
Daniel Vetter wrote:
> I'll redo this patch by adding _multipage versions of these 2 functions
> for i915.
OK, but I hope "for i915" doesn't mean "private to"! Put 'em in
pagemap.h, for maintenance reasons and because they are generic.
Making them inline is a
On Thu, 1 Mar 2012 20:22:59 +0100
Daniel Vetter wrote:
> drm/i915 wants to read/write more than one page in its fastpath
> and hence needs to prefault more than PAGE_SIZE bytes.
>
> Add new functions in filemap.h to make that possible.
>
> Also kill a copy&pasted spurious space in both functio
On Fri, 19 Nov 2010 10:53:52 -0500
Matthew Garrett wrote:
> There may be multiple ways of controlling the backlight on a given machine.
> Allow drivers to expose the type of interface they are providing, making
> it possible for userspace to make appropriate policy decisions.
>
> ...
>
> 60 fil
On Fri, 19 Nov 2010 20:25:59 +
Matthew Garrett wrote:
> On Fri, Nov 19, 2010 at 12:05:23PM -0800, Andrew Morton wrote:
> > On Fri, 19 Nov 2010 10:53:52 -0500
> > Matthew Garrett wrote:
> >
> > > There may be multiple ways of controlling the backlight on a giv
On Wed, 1 Dec 2010 17:54:18 +0100
Julien Cristau wrote:
> On Wed, Dec 1, 2010 at 17:10:42 +0200, Alexander Shishkin wrote:
>
> > For headers that get exported to userland and make use of u32 style
> > type names, it is advised to include linux/types.h.
> >
> > This fixes 5 headers_check warnin
On Fri, 14 Jan 2011 14:24:23 -0500
Matthew Garrett wrote:
> From: Michel D__nzer
>
> Allows e.g. power management daemons to control the backlight level. Inspired
> by the corresponding code in radeonfb.
>
> (Updated to add backlight type and make the connector the parent device - mjg)
>
x86
On Fri, 21 Jan 2011 00:43:46 +0330
Ali Gholami Rudi wrote:
> Ali Gholami Rudi wrote:
> > I tried to apply this patch but I get:
> >
> > drivers/gpu/drm/i915/intel_panel.c: In function
> > 'intel_panel_setup_backlight':
> > drivers/gpu/drm/i915/intel_panel.c:319: error: 'struct
> > bac
On Fri, 21 Jan 2011 00:43:59 +
Matthew Garrett wrote:
> On Thu, Jan 20, 2011 at 03:13:49PM -0800, Andrew Morton wrote:
> > On Fri, 21 Jan 2011 00:43:46 +0330
> > Ali Gholami Rudi wrote:
> >
> > > Ali Gholami Rudi wrote:
> > >
On Fri, 21 Jan 2011 06:36:54 +0100 Sedat Dilek
wrote:
> ( Original posting from [1] )
>
> I have the backlight-type patchset for months in my patch-series (and
> maintained them if necessary against daily linux-next).
> Also the last series from 14-Jan-2011 (see 1-5 patch from [2] and the
> fol
On Tue, 7 Apr 2015 17:31:36 +0100 Chris Wilson
wrote:
> In preparation for exporting very similar functionality through another
> interface, gut the current remap_pfn_range(). The motivating factor here
> is to reuse the PGB/PUD/PMD/PTE walker, but allow back progation of
> errors rather than B
I'm not sure what's happened to the drm code in linux-next - it's
exploding all over the place. Did someone turn on -Werror without
doing anywhere near enough testing?
Anyway, I don't know how to fix this i386 build error:
drivers/gpu/drm/i915/i915_gem_gtt.c: In function 'gen8_ppgtt_init':
driv
On Sat, 23 May 2015 14:30:09 +0100 Damien Lespiau
wrote:
> On Fri, May 22, 2015 at 02:17:32PM -0700, Andrew Morton wrote:
> > I'm not sure what's happened to the drm code in linux-next - it's
> > exploding all over the place. Did someone turn on -Werror without
On Mon, 3 Feb 2025 10:39:58 +0200 "Kirill A. Shutemov"
wrote:
> > diff --git a/mm/filemap.c b/mm/filemap.c
> > index 4fe551037bf7..98493443d120 100644
> > --- a/mm/filemap.c
> > +++ b/mm/filemap.c
> > @@ -1605,8 +1605,9 @@ static void folio_end_reclaim_write(struct folio
> > *folio)
> >
On Thu, 30 Jan 2025 16:18:04 -0800 "Vishal Moola (Oracle)"
wrote:
> Currently, users have to call vmap() or vmap_pfn() to map pages to
> kernel virtual space. vmap() requires the page references, and
> vmap_pfn() requires page pfns. If we have a file but no page references,
> we have to do extra
72 matches
Mail list logo
