On Tue, Jan 30 2024 at 11:58, Byungchul Park wrote:
> On Fri, Jan 26, 2024 at 06:30:02PM +0100, Thomas Gleixner wrote:
>> On Wed, Jan 24 2024 at 20:59, Byungchul Park wrote:
>>
>> Why is lockdep in the subsystem prefix here? You are changing the CPU
>> hotplu
On Wed, Jan 24 2024 at 20:59, Byungchul Park wrote:
Why is lockdep in the subsystem prefix here? You are changing the CPU
hotplug (not hotplus) code, right?
> cb92173d1f0 ("locking/lockdep, cpu/hotplug: Annotate AP thread") was
> introduced to make lockdep_assert_cpus_held() work in AP thread.
>
On Tue, Dec 05 2023 at 18:45, Yoshinori Sato wrote:
> +static void endisable_irq(struct irq_data *data, int enable)
bool enable?
> +{
> + struct sh7751_intc_priv *priv;
> + unsigned int irq;
> +
> + priv = irq_data_to_priv(data);
> +
> + irq = irqd_to_hwirq(data);
> + if
On Wed, Sep 13 2023 at 09:47, Linus Torvalds wrote:
> On Wed, 13 Sept 2023 at 07:21, Tetsuo Handa
> wrote:
>>
>> Hello. A deadlock was reported in drivers/gpu/drm/vkms/ .
>> It looks like this locking pattern remains as of 6.6-rc1. Please fix.
>>
>> void drm_crtc_vblank_off(struct drm_crtc *crtc)
On Mon, Jan 09 2023 at 12:33, Byungchul Park wrote:
> Makes Dept able to track dependencies by
> wait_for_completion()/complete().
>
> In order to obtain the meaningful caller points, replace all the
> wait_for_completion*() declarations with macros in the header.
That's just wrong.
> -extern
On Mon, Jan 09 2023 at 12:33, Byungchul Park wrote:
> It'd be useful to show Dept internal stats and dependency graph on
> runtime via proc for better information. Introduced the knobs.
proc?
That's what debugfs is for.
On Tue, Jan 17 2023 at 10:18, Boqun Feng wrote:
> On Mon, Jan 16, 2023 at 10:00:52AM -0800, Linus Torvalds wrote:
>> I also recall this giving a fair amount of false positives, are they all
>> fixed?
>
> From the following part in the cover letter, I guess the answer is no?
> ...
>
On Mon, Jan 09 2023 at 12:33, Byungchul Park wrote:
> +/*
> + * sdt_might_sleep() and its family will be committed in __schedule()
> + * when it actually gets to __schedule(). Both dept_request_event() and
> + * dept_wait() will be performed on the commit.
> + */
> +
> +/*
> + * Use the code
Linus,
On Sun, Nov 06 2022 at 22:32, Steven Rostedt wrote:
> As discussed here:
>
> https://lore.kernel.org/all/20221106212427.739928...@goodmis.org/
Please hold off. It's only nits, but tip has documented rules and random
pull requests are not making them go away.
Thanks,
tglx
A recent syzbot report unearthed abuse of hrtimer_forward() which can cause
runaway timers hogging the CPU in timer expiry context by rearming the
timer in the past over and over.
This happens when the caller uses timer->expiry for the 'now' argument of
hrtimer_forward(). That works as long as
hrtimer_forward() is about to be removed from the public
interfaces. Replace it with hrtimer_forward_now() which provides the same
functionality.
Signed-off-by: Thomas Gleixner
Cc: David Airlie
Cc: intel-...@lists.freedesktop.org
Cc: Joonas Lahtinen
Cc: Jani Nikula
Cc: dri-devel
From: Thomas Gleixner
None of these mapping requires the side effect of disabling pagefaults and
preemption.
Use io_mapping_map_local_wc() instead, and clean up gtt_user_read() and
gtt_user_write() to use a plain copy_from_user() as the local maps are not
disabling pagefaults.
Signed-off
From: Thomas Gleixner
None of these mapping requires the side effect of disabling pagefaults and
preemption.
Use io_mapping_map_local_wc() instead, rename the related functions
accordingly and clean up qxl_process_single_command() to use a plain
copy_from_user() as the local maps
From: Thomas Gleixner
There is no reason to disable pagefaults and preemption as a side effect of
kmap_atomic_prot().
Use kmap_local_page_prot() instead and document the reasoning for the
mapping usage with the given pgprot.
Remove the NULL pointer check for the map. These functions return
From: Thomas Gleixner
No more users. Get rid of it and remove the traces in documentation.
Signed-off-by: Thomas Gleixner
Cc: Andrew Morton
Cc: linux...@kvack.org
---
Documentation/driver-api/io-mapping.rst | 22 +---
include/linux/io-mapping.h | 42
From: Thomas Gleixner
No more users.
Signed-off-by: Thomas Gleixner
Cc: Andrew Morton
Cc: linux...@kvack.org
---
include/linux/highmem-internal.h | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
--- a/include/linux/highmem-internal.h
+++ b/include/linux/highmem
From: Thomas Gleixner
Neither fbmem_peek() nor fbmem_poke() require to disable pagefaults and
preemption as a side effect of io_mapping_map_atomic_wc().
Use io_mapping_map_local_wc() instead.
Signed-off-by: Thomas Gleixner
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel
None of the DRM usage sites of temporary mappings requires the side
effects of io/kmap_atomic(), i.e. preemption and pagefault disable.
Replace them with the io/kmap_local() variants, simplify the
copy_to/from_user() error handling and remove the atomic variants.
Thanks,
tglx
---
From: Thomas Gleixner
There is no reason to disable pagefaults and preemption as a side effect of
kmap_atomic_prot().
Use kmap_local_page_prot() instead and document the reasoning for the
mapping usage with the given pgprot.
Remove the NULL pointer check for the map. These functions return
On Sun, Dec 27 2020 at 11:20, Guenter Roeck wrote:
> On Thu, Dec 10, 2020 at 08:25:38PM +0100, Thomas Gleixner wrote:
> Yes, but that means that irq_check_status_bit() may be called from modules,
> but it is not exported, resulting in build errors such as the following.
>
> arm
On Fri, Dec 11 2020 at 22:08, Thomas Gleixner wrote:
> On Fri, Dec 11 2020 at 19:53, Andy Shevchenko wrote:
>
>> On Thu, Dec 10, 2020 at 10:14 PM Thomas Gleixner wrote:
>>>
>>> irq_set_lockdep_class() is used from modules and requires irq_to_desc() to
>>>
On Fri, Dec 11 2020 at 19:53, Andy Shevchenko wrote:
> On Thu, Dec 10, 2020 at 10:14 PM Thomas Gleixner wrote:
>>
>> irq_set_lockdep_class() is used from modules and requires irq_to_desc() to
>> be exported. Move it into the core code which lifts another requirem
Andrew,
On Fri, Dec 11 2020 at 22:21, Andrew Cooper wrote:
> On 11/12/2020 21:27, Thomas Gleixner wrote:
>> It's not any different from the hardware example at least not as far as
>> I understood the code.
>
> Xen's event channels do have a couple of quirks.
Why am I not
On Fri, Dec 11 2020 at 13:10, Jürgen Groß wrote:
> On 11.12.20 00:20, boris.ostrov...@oracle.com wrote:
>>
>> On 12/10/20 2:26 PM, Thomas Gleixner wrote:
>>> All event channel setups bind the interrupt on CPU0 or the target CPU for
>>> percpu interrupt
On Fri, Dec 11 2020 at 09:29, boris ostrovsky wrote:
> On 12/11/20 7:37 AM, Thomas Gleixner wrote:
>> On Fri, Dec 11 2020 at 13:10, Jürgen Groß wrote:
>>> On 11.12.20 00:20, boris.ostrov...@oracle.com wrote:
>>>> On 12/10/20 2:26 PM, Thomas Gleixner wrote:
>
On Fri, Dec 11 2020 at 10:13, Tvrtko Ursulin wrote:
> On 10/12/2020 19:25, Thomas Gleixner wrote:
>>
>> Aside of that the count is per interrupt line and therefore takes
>> interrupts from other devices into account which share the interrupt line
>> and are not han
On Fri, Dec 11 2020 at 14:19, David Laight wrote:
> From: Thomas Gleixner
>> You can't catch that. If this really becomes an issue you need a
>> sequence counter around it.
>
> Or just two copies of the high word.
> Provided the accesses are sequenced:
> writer:
>
of subsystem
boundaries and racy against concurrent modifications of the interrupt
descriptor.
Print the irq line instead so the information can be looked up in a sane
way in /proc/interrupts.
Signed-off-by: Thomas Gleixner
Cc: Linus Walleij
Cc: Lee Jones
Cc: linux-arm-ker...@lists.infradead.org
Both the per cpu stats and the accumulated count are accessed lockless and
can be concurrently modified. That's intentional and the stats are a rough
estimate anyway. Annotate them with data_race().
Signed-off-by: Thomas Gleixner
---
kernel/irq/irqdesc.c |4 ++--
kernel/irq/proc.c|5
These checks are used by modules and prevent the removal of the export of
irq_to_desc(). Move the accessor into the core.
Signed-off-by: Thomas Gleixner
---
include/linux/irqdesc.h | 17 +
kernel/irq/manage.c | 17 +
2 files changed, 22 insertions(+), 12
.
Retrieve a pointer to the affinity mask itself and use that. It's still
using an interface which is usually not for random drivers, but definitely
less hideous than the previous hack.
Signed-off-by: Thomas Gleixner
Cc: Tariq Toukan
Cc: "David S. Miller"
Cc: Jakub Kicinsk
Keep track of the assignments of event channels to CPUs and select the
online CPU with the least assigned channels in the affinity mask which is
handed to irq_chip::irq_set_affinity() from the core code.
Signed-off-by: Thomas Gleixner
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano
No more (ab)use in modules finally. Remove the export so there won't come
new ones.
Signed-off-by: Thomas Gleixner
---
kernel/irq/irqdesc.c |1 -
1 file changed, 1 deletion(-)
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -352,7 +352,6 @@ struct irq_desc *irq_to_desc(unsigned
to contain cpumask_of(0).
As the CPU0 enforcement was in place _before_ this was implemented it's
entirely unclear how that can ever have worked at all.
Remove it as preparation for doing it proper.
Signed-off-by: Thomas Gleixner
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: xen-de
irq().
This also prepares for proper interrupt spreading.
Signed-off-by: Thomas Gleixner
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: xen-de...@lists.xenproject.org
---
drivers/xen/events/events_base.c | 42 ++-
1 file changed, 28 inserti
Signed-off-by: Thomas Gleixner
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: xen-de...@lists.xenproject.org
---
drivers/xen/events/events_base.c |6 --
1 file changed, 6 deletions(-)
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
The irq descriptor is already there, no need to look it up again.
Signed-off-by: Thomas Gleixner
Cc: Marc Zyngier
Cc: Russell King
Cc: linux-arm-ker...@lists.infradead.org
---
arch/arm/kernel/smp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/kernel/smp.c
+++ b
To prepare for interrupt spreading reduce the storage size of
irq_info::spurious_cnt to u8 so the required flag for the spreading logic
will not increase the storage size.
Protect the usage site against overruns.
Signed-off-by: Thomas Gleixner
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano
The irq descriptor is already there, no need to look it up again.
Signed-off-by: Thomas Gleixner
Cc: Mark Rutland
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Marc Zyngier
Cc: linux-arm-ker...@lists.infradead.org
---
arch/arm64/kernel/smp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion
Nothing uses the result and nothing should ever use it in driver code.
Signed-off-by: Thomas Gleixner
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: David Airlie
Cc: Daniel Vetter
Cc: Pankaj Bharadiya
Cc: Chris Wilson
Cc: Wambui Karuga
Cc: intel-...@lists.freedesktop.org
Cc
The SMP variant works perfectly fine on UP as well.
Signed-off-by: Thomas Gleixner
Cc: "James E.J. Bottomley"
Cc: Helge Deller
Cc: afzal mohammed
Cc: linux-par...@vger.kernel.org
---
arch/parisc/kernel/irq.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
--- a/a
The irq descriptor is already there, no need to look it up again.
Signed-off-by: Thomas Gleixner
Cc: "James E.J. Bottomley"
Cc: Helge Deller
Cc: afzal mohammed
Cc: linux-par...@vger.kernel.org
---
arch/parisc/kernel/irq.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
means that checking the affinity mask itself does not really tell
about the actual target CPUs.
Signed-off-by: Thomas Gleixner
Cc: Tariq Toukan
Cc: "David S. Miller"
Cc: Jakub Kicinski
Cc: net...@vger.kernel.org
Cc: linux-r...@vger.kernel.org
---
drivers/net/ethernet/mellanox/ml
chip data of the top level chip of a hierarchy. It does not
matter in this case because the chip is the top level chip, but that
doesn't make it more correct.
Signed-off-by: Thomas Gleixner
Cc: Lorenzo Pieralisi
Cc: Rob Herring
Cc: Bjorn Helgaas
Cc: Michal Simek
Cc: linux-...@vger.kernel.org
.
Retrieve a pointer to the affinity mask itself and use that. It's still
using an interface which is usually not for random drivers, but definitely
less hideous than the previous hack.
Signed-off-by: Thomas Gleixner
---
drivers/net/ethernet/mellanox/mlx5/core/en.h |2 +-
drivers/net/ethernet
On Thu, Dec 10 2020 at 18:19, boris ostrovsky wrote:
> On 12/10/20 2:26 PM, Thomas Gleixner wrote:
>> -EXPORT_SYMBOL_GPL(bind_evtchn_to_irq_lateeoi);
>
> include/xen/events.h also needs to be updated (and in the next patch for
> xen_set_affinity_evtchn() as we
On Thu, Dec 10 2020 at 10:45, Tvrtko Ursulin wrote:
> On 10/12/2020 07:53, Joonas Lahtinen wrote:
>> I think later in the thread there was a suggestion to replace this with
>> simple counter increment in IRQ handler.
>
> It was indeed unsafe until recent b00bccb3f0bb ("drm/i915/pmu: Handle
> PCI
A recent request to export kstat_irqs() pointed to a copy of the same in
the i915 code, which made me look for further usage of irq descriptors in
drivers.
The usage in drivers ranges from creative to broken in all colours.
irqdesc.h clearly says that this is core functionality and the fact C
No more users outside the core code.
Signed-off-by: Thomas Gleixner
---
include/linux/kernel_stat.h |1 -
kernel/irq/irqdesc.c| 19 ++-
2 files changed, 6 insertions(+), 14 deletions(-)
--- a/include/linux/kernel_stat.h
+++ b/include/linux/kernel_stat.h
@@ -67,7
.
Signed-off-by: Thomas Gleixner
---
arch/alpha/kernel/sys_jensen.c |2 +-
arch/x86/kernel/topology.c |1 +
include/linux/interrupt.h |1 +
include/linux/irqdesc.h|7 +--
kernel/irq/manage.c| 17 +
5 files changed, 21 insertions
means that checking the affinity mask itself does not really tell
about the actual target CPUs.
Signed-off-by: Thomas Gleixner
Cc: Saeed Mahameed
Cc: Leon Romanovsky
Cc: "David S. Miller"
Cc: Jakub Kicinski
Cc: net...@vger.kernel.org
Cc: linux-r...@vger.kernel.org
---
drivers/ne
Most users of kstat_irqs_cpu() have the irq descriptor already. No point in
calling into the core code and looking it up once more.
Use it in per_cpu_count_show() to start with.
Signed-off-by: Thomas Gleixner
---
include/linux/irqdesc.h |6 ++
kernel/irq/irqdesc.c|4 ++--
2
irq_set_lockdep_class() is used from modules and requires irq_to_desc() to
be exported. Move it into the core code which lifts another requirement for
the export.
Signed-off-by: Thomas Gleixner
---
include/linux/irqdesc.h | 10 --
kernel/irq/irqdesc.c| 14 ++
2 files
Let the core code do the fiddling with irq_desc.
Signed-off-by: Thomas Gleixner
Cc: Linus Walleij
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-g...@vger.kernel.org
---
drivers/pinctrl/nomadik/pinctrl-nomadik.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers
On Thu, Dec 10 2020 at 18:20, boris ostrovsky wrote:
> On 12/10/20 2:26 PM, Thomas Gleixner wrote:
>> All event channel setups bind the interrupt on CPU0 or the target CPU for
>> percpu interrupts and overwrite the affinity mask with the corresponding
>> cpumask. Tha
Use the proper core function.
Signed-off-by: Thomas Gleixner
Cc: Jon Mason
Cc: Dave Jiang
Cc: Allen Hubbe
Cc: linux-...@googlegroups.com
---
drivers/ntb/msi.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/drivers/ntb/msi.c
+++ b/drivers/ntb/msi.c
@@ -282,15 +282,13
chip data of the top level chip of a hierarchy. It does not
matter in this case because the chip is the top level chip, but that
doesn't make it more correct.
Signed-off-by: Thomas Gleixner
Cc: Karthikeyan Mitran
Cc: Hou Zhiqiang
Cc: Lorenzo Pieralisi
Cc: Rob Herring
Cc: Bjorn Helgaas
Cc
On Thu, Dec 10 2020 at 17:09, Tvrtko Ursulin wrote:
> On 10/12/2020 16:35, Thomas Gleixner wrote:
>> I'll send out a series addressing irq_to_desc() (ab)use all over the
>> place shortly. i915 is in there...
>
> Yep we don't need atomic, my bad. And we would care about the sha
Provide an accessor to the effective interrupt affinity mask. Going to be
used to replace open coded fiddling with the irq descriptor.
Signed-off-by: Thomas Gleixner
---
include/linux/irq.h |7 +++
1 file changed, 7 insertions(+)
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
The irq descriptor is already there, no need to look it up again.
Signed-off-by: Thomas Gleixner
Cc: Christian Borntraeger
Cc: Heiko Carstens
Cc: linux-s...@vger.kernel.org
---
arch/s390/kernel/irq.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/s390/kernel/irq.c
+++ b
().
This makes XEN on x86 use the same mechanics as on e.g. ARM64 where
deferred affinity setting is not required and not implemented and the code
path in the ack functions is compiled out.
Signed-off-by: Thomas Gleixner
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: xen-de
only counts interrupts which
originate from the graphics card.
To avoid atomics or heuristics of some sort make the counter field
'unsigned long'. That limits the count to 4e9 on 32bit which is a lot and
postprocessing can easily deal with the occasional wraparound.
Signed-off-by: Thomas Gleixner
Jerry,
On Fri, Dec 04 2020 at 18:43, Jerry Snitselaar wrote:
> @@ -715,9 +717,23 @@ static irqreturn_t tis_int_handler(int dummy, void
> *dev_id)
> {
> struct tpm_chip *chip = dev_id;
> struct tpm_tis_data *priv = dev_get_drvdata(>dev);
> + static bool check_storm = true;
> +
On Fri, Dec 04 2020 at 18:43, Jerry Snitselaar wrote:
> Now that kstat_irqs is exported, get rid of count_interrupts in
> i915_pmu.c
> --- a/drivers/gpu/drm/i915/i915_pmu.c
> +++ b/drivers/gpu/drm/i915/i915_pmu.c
> @@ -423,22 +423,6 @@ static enum hrtimer_restart i915_sample(struct hrtimer
>
On Sun, Dec 06 2020 at 09:40, James Bottomley wrote:
> On Sun, 2020-12-06 at 17:40 +0100, Thomas Gleixner wrote:
>> On Sat, Dec 05 2020 at 12:39, Jarkko Sakkinen wrote:
>> > On Fri, Dec 04, 2020 at 06:43:37PM -0700, Jerry Snitselaar wrote:
>> > > To try and det
On Sun, Dec 06 2020 at 17:38, Thomas Gleixner wrote:
> On Fri, Dec 04 2020 at 18:43, Jerry Snitselaar wrote:
>> Now that kstat_irqs is exported, get rid of count_interrupts in
>> i915_pmu.c
>
> May I ask why this has been merged in the first place?
>
> Nothing in
On Sat, Dec 05 2020 at 12:39, Jarkko Sakkinen wrote:
> On Fri, Dec 04, 2020 at 06:43:37PM -0700, Jerry Snitselaar wrote:
>> To try and detect potential interrupt storms that
>> have been occurring with tpm_tis devices it was suggested
>> to use kstat_irqs() to get the number of interrupts.
>>
On Sun, Dec 06 2020 at 14:47, Jerry Snitselaar wrote:
> Thomas Gleixner @ 2020-12-06 09:38 MST:
>
> I don't know the history behind this bit. I stumbled across it in cscope
> when looking for places using kstat_irqs.
I'm not ranting at you. The i915 peop
Jerry,
On Fri, Dec 04 2020 at 18:43, Jerry Snitselaar wrote:
The proper prefix is 'genirq:' git log kernel/irq/irqdesc.c would have
told you.
> To try and detect potential interrupt storms that
> have been occurring with tpm_tis devices it was suggested
> to use kstat_irqs() to get the number
Marek,
On Thu, Nov 12 2020 at 09:10, Marek Szyprowski wrote:
> On 03.11.2020 10:27, Thomas Gleixner wrote:
>
> I can do more tests to help fixing this issue. Just let me know what to do.
Just sent out the fix before I saw your report.
https://lore.kernel.org/r/8
On Mon, Nov 09 2020 at 20:59, Ira Weiny wrote:
> On Tue, Nov 10, 2020 at 02:13:56AM +0100, Thomas Gleixner wrote:
> Also, we can convert the new memcpy_*_page() calls to kmap_local() as well.
> [For now my patch just uses kmap_atomic().]
>
> I've not looked at all of the patches
Ira,
On Fri, Oct 09 2020 at 12:49, ira weiny wrote:
> From: Ira Weiny
>
> To correctly support the semantics of kmap() with Kernel protection keys
> (PKS), kmap() may be required to set the protections on multiple
> processors (globally). Enabling PKS globally can be very expensive
> depending
All users gone.
Signed-off-by: Thomas Gleixner
---
include/linux/highmem.h | 63 +++-
mm/highmem.c|7 -
2 files changed, 5 insertions(+), 65 deletions(-)
--- a/include/linux/highmem.h
+++ b/include/linux/highmem.h
@@ -86,31
Nothing uses totalhigh_pages_dec() and totalhigh_pages_set().
Signed-off-by: Thomas Gleixner
---
V3: New patch
---
include/linux/highmem.h | 10 --
1 file changed, 10 deletions(-)
--- a/include/linux/highmem.h
+++ b/include/linux/highmem.h
@@ -104,21 +104,11 @@ static inline void
Historical leftovers from the time where kmap() had fixed slots.
Signed-off-by: Thomas Gleixner
Cc: Alexander Viro
Cc: Benjamin LaHaise
Cc: linux-fsde...@vger.kernel.org
Cc: linux-...@kvack.org
Cc: Chris Mason
Cc: Josef Bacik
Cc: David Sterba
Cc: linux-bt...@vger.kernel.org
---
fs/aio.c
Similar to kmap local provide a iomap local variant which only disables
migration, but neither disables pagefaults nor preemption.
Signed-off-by: Thomas Gleixner
---
V3: Restrict migrate disable to the 32bit mapping case and update documentation.
V2: Split out from the large combo patch and add
On Tue, Nov 03 2020 at 09:48, Linus Torvalds wrote:
> I have no complaints about the patch, but it strikes me that if people
> want to actually have much better debug coverage, this is where it
> should be (I like the "every other address" thing too, don't get me
> wrong).
>
> In particular,
-off-by: Thomas Gleixner
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: David Airlie
Cc: Daniel Vetter
Cc: virtualizat...@lists.linux-foundation.org
Cc: spice-de...@lists.freedesktop.org
---
V3: New patch
---
drivers/gpu/drm/qxl/qxl_image.c | 18 +-
drivers/gpu/drm/qxl/qxl_ioctl.c
No reason having the same code in every architecture.
Signed-off-by: Thomas Gleixner
Cc: Russell King
Cc: Arnd Bergmann
Cc: linux-arm-ker...@lists.infradead.org
---
V3: Remove the kmap types cruft
---
arch/arm/Kconfig |1
arch/arm/include/asm/fixmap.h |4 -
arch
No reason having the same code in every architecture
Signed-off-by: Thomas Gleixner
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: linuxppc-...@lists.ozlabs.org
---
V3: Remove the kmap types cruft
---
arch/powerpc/Kconfig |1
arch/powerpc/include
No reason having the same code in every architecture.
Signed-off-by: Thomas Gleixner
Cc: Michal Simek
---
V3: Remove the kmap types cruft
---
arch/microblaze/Kconfig |1
arch/microblaze/include/asm/fixmap.h |4 -
arch/microblaze/include/asm/highmem.h |6 ++
arch
. Going back to user
space with an active kmap local is a nono.
Signed-off-by: Thomas Gleixner
---
V4: Use the version which actually compiles and works
V3: Handle the debug case correctly
---
include/linux/highmem-internal.h | 10 +++
include/linux/sched.h|9 +++
kernel/entry
Switch the atomic iomap implementation over to kmap_local and stick the
preempt/pagefault mechanics into the generic code similar to the
kmap_atomic variants.
Rename the x86 map function in preparation for a non-atomic variant.
Signed-off-by: Thomas Gleixner
---
V2: New patch to make review
. Going back to user
space with an active kmap local is a nono.
Signed-off-by: Thomas Gleixner
---
V3: Handle the debug case correctly
---
include/linux/highmem-internal.h | 10 +++
include/linux/sched.h|9 +++
kernel/entry/common.c|2
kernel/fork.c
Neither fbmem_peek() nor fbmem_poke() require to disable pagefaults and
preemption as a side effect of io_mapping_map_atomic_wc().
Use io_mapping_map_local_wc() instead.
Signed-off-by: Thomas Gleixner
Cc: Ben Skeggs
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc
On Tue, Nov 03 2020 at 10:27, Thomas Gleixner wrote:
> +struct kmap_ctrl {
> +#ifdef CONFIG_KMAP_LOCAL
> + int idx;
> + pte_t pteval[KM_TYPE_NR];
I'm a moron. Fixed it on the
The kmap_atomic* interfaces in all architectures are pretty much the same
except for post map operations (flush) and pre- and post unmap operations.
Provide a generic variant for that.
Signed-off-by: Thomas Gleixner
Cc: Andrew Morton
Cc: linux...@kvack.org
---
V3: Do not reuse
to the generic kmap_local* implementation.
Signed-off-by: Thomas Gleixner
---
V3: New patch
---
mm/highmem.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
--- a/mm/highmem.c
+++ b/mm/highmem.c
@@ -374,9 +374,19 @@ EXPORT_SYMBOL(kunmap_high);
static DEFINE_PER_CPU(int
The header is not longer used and on alpha, ia64, openrisc, parisc and um
it was completely unused anyway as these architectures have no highmem
support.
Signed-off-by: Thomas Gleixner
---
V3: New patch
---
arch/alpha/include/asm/kmap_types.h | 15 ---
arch/ia64/include/asm
The mapping code is odd and looks broken. See FIXME in the comment.
Also fix the harmless off by one in the FIX_KMAP_END define.
Signed-off-by: Thomas Gleixner
Cc: Nick Hu
Cc: Greentime Hu
Cc: Vincent Chen
---
V3: Remove the kmap types cruft
---
arch/nds32/Kconfig.cpu |1
There is no requirement to disable pagefaults and preemption for these
cache management mappings.
Replace kmap_atomic_pfn() with kmap_local_pfn(). This allows to remove
kmap_atomic_pfn() in the next step.
Signed-off-by: Thomas Gleixner
Cc: Russell King
Cc: linux-arm-ker...@lists.infradead.org
Move the gory details of kmap & al into a private header and only document
the interfaces which are usable by drivers.
Signed-off-by: Thomas Gleixner
---
V3: New patch
---
include/linux/highmem-internal.h | 174 +
include/linux/highmem.h |
Convert X86 to the generic kmap atomic implementation and make the
iomap_atomic() naming convention consistent while at it.
Signed-off-by: Thomas Gleixner
Cc: x...@kernel.org
---
V3: Remove the kmap_types cruft
---
arch/x86/Kconfig |3 +
arch/x86/include/asm/fixmap.h
Replace kmap_atomic_pfn() with kmap_local_pfn() which is preemptible and
can take page faults.
Remove the indirection of the dump page and the related cruft which is not
longer required.
Signed-off-by: Thomas Gleixner
Cc: Thomas Bogendoerfer
Cc: linux-m...@vger.kernel.org
---
V3: New patch
Replace kmap_atomic_pfn() with kmap_local_pfn() which is preemptible and
can take page faults.
Remove the indirection of the dump page and the related cruft which is not
longer required.
Signed-off-by: Thomas Gleixner
---
V3: New patch
---
arch/x86/kernel/crash_dump_32.c | 48
nesting for the upcoming reemptible version would be:
2 maps in task context and a fault inside
2 maps in the fault handler
3 maps in softirq
2 maps in interrupt
So a total of 16 is sufficient and probably overestimated.
Signed-off-by: Thomas Gleixner
---
V3: New patch
on the preemption
disable for serialization or on the implicit pagefault disable. Needs to be
done on a case by case basis.
Signed-off-by: Thomas Gleixner
---
V3: Move migrate disable into the actual highmem mapping code so it only
affects real highmem mappings.
V2: Make it more consistent
pages and the return was bogus anyway as it would have
left preemption and pagefaults disabled.
Signed-off-by: Thomas Gleixner
Cc: Christian Koenig
Cc: Huang Rui
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
---
V3: New patch
---
drivers/gpu/drm/ttm/ttm_bo_util.c
Nothing in modules can use that.
Signed-off-by: Thomas Gleixner
Reviewed-by: Christoph Hellwig
Cc: Andrew Morton
Cc: linux...@kvack.org
---
mm/highmem.c |2 --
1 file changed, 2 deletions(-)
--- a/mm/highmem.c
+++ b/mm/highmem.c
@@ -108,8 +108,6 @@ static inline wait_queue_head_t
For whatever reasons SH has highmem bits all over the place but does
not enable it via Kconfig. Remove the bitrot.
Signed-off-by: Thomas Gleixner
---
arch/sh/include/asm/fixmap.h |8
arch/sh/include/asm/kmap_types.h | 15 ---
arch/sh/mm/init.c
1 - 100 of 223 matches
Mail list logo
