This silences -517 errors and helps figuring out why the device probe
is deferred.
Signed-off-by: Alexander Stein
---
sound/soc/fsl/imx-hdmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/fsl/imx-hdmi.c b/sound/soc/fsl/imx-hdmi.c
index a780cf5a65ffa..b6cc7e6c2a32
Walks the stack when copy_{to,from}_user address is in the stack to
ensure that the object being copied is entirely within a single stack
frame.
Substatially similar to the x86 implementation except using the back
chain to traverse the stack and identify stack frame boundaries.
Signed-off-by: Nic
On Thu Jan 19, 2023 at 8:22 AM AEST, Nadav Amit wrote:
>
>
> > On Jan 18, 2023, at 12:00 AM, Nicholas Piggin wrote:
> >
> > +static void do_shoot_lazy_tlb(void *arg)
> > +{
> > + struct mm_struct *mm = arg;
> > +
> > + if (current->active_mm == mm) {
> > + WARN_ON_ONCE(current->mm);
On Thu Jan 19, 2023 at 3:30 AM AEST, Linus Torvalds wrote:
> [ Adding a few more x86 and arm64 maintainers - while linux-arch is
> the right mailing list, I'm not convinced people actually follow it
> all that closely ]
>
> On Wed, Jan 18, 2023 at 12:00 AM Nicholas Piggin wrote:
> >
> > On a 16-so
Hi Rob,
I love your patch! Perhaps something to improve:
[auto build test WARNING on 1b929c02afd37871d5afb9d498426f83432e71c2]
url:
https://github.com/intel-lab-lkp/linux/commits/Rob-Herring/dt-bindings-usb-Remove-obsolete-brcm-bcm3384-usb-txt/20230119-030120
base: 1b929c02afd37871d5afb9d4
On Wed Jan 18, 2023 at 7:05 PM AEST, David Howells wrote:
> Linus Torvalds wrote:
>
> > And for the kernel, where we don't have bad locking, and where we
> > actually use fine-grained locks that are _near_ the data that we are
> > locking (the lockref of the dcache is obviously one example of that
On Wed Jan 18, 2023 at 4:10 PM AEST, Andrew Donnellan wrote:
> From: Russell Currey
>
> The code that handles the format string in secvar-sysfs.c is entirely
> OPAL specific, so create a new "format" op in secvar_operations to make
> the secvar code more generic. No functional change.
>
> Signed-
On Wed Jan 18, 2023 at 4:10 PM AEST, Andrew Donnellan wrote:
> plpks_confirm_object_flushed() uses the H_PKS_CONFIRM_OBJECT_FLUSHED hcall
> to check whether changes to an object in the Platform KeyStore have been
> flushed to non-volatile storage.
>
> The hcall returns two output values, the return
On Wed Jan 18, 2023 at 4:10 PM AEST, Andrew Donnellan wrote:
> From: Nayna Jain
>
> The Platform Keystore provides a signed update interface which can be used
> to create, replace or append to certain variables in the PKS in a secure
> fashion, with the hypervisor requiring that the update be sign
On Wed Jan 18, 2023 at 4:10 PM AEST, Andrew Donnellan wrote:
> Currently, the list of variables is populated by calling
> secvar_ops->get_next() repeatedly, which is explicitly modelled on the
> OPAL API (including the keylen parameter).
>
> For the upcoming PLPKS backend, we have a static list of
On Wed Jan 18, 2023 at 4:10 PM AEST, Andrew Donnellan wrote:
> From: Russell Currey
>
> The code that handles the format string in secvar-sysfs.c is entirely
> OPAL specific, so create a new "format" op in secvar_operations to make
> the secvar code more generic. No functional change.
>
> Signed-
On Wed Jan 18, 2023 at 4:10 PM AEST, Andrew Donnellan wrote:
> From: Russell Currey
>
> The secvar code only supports one consumer at a time.
>
> Multiple consumers aren't possible at this point in time, but we'd want
> it to be obvious if it ever could happen.
>
> Signed-off-by: Russell Currey
>
On Thu Jan 19, 2023 at 8:22 AM AEST, Nadav Amit wrote:
>
>
> > On Jan 18, 2023, at 12:00 AM, Nicholas Piggin wrote:
> >
> > +static void do_shoot_lazy_tlb(void *arg)
> > +{
> > + struct mm_struct *mm = arg;
> > +
> > + if (current->active_mm == mm) {
> > + WARN_ON_ONCE(current->mm);
> On Jan 18, 2023, at 12:00 AM, Nicholas Piggin wrote:
>
> +static void do_shoot_lazy_tlb(void *arg)
> +{
> + struct mm_struct *mm = arg;
> +
> + if (current->active_mm == mm) {
> + WARN_ON_ONCE(current->mm);
> + current->active_mm = &init_mm;
> + sw
The commit 2d681d6a23a1 ("of: Make of framebuffer devices unique")
breaks build because of wrong argument to snprintf. That certainly
avoids the runtime error but is not the intended outcome.
Fixes: 2d681d6a23a1 ("of: Make of framebuffer devices unique")
Signed-off-by: Michal Suchanek
---
driv
On Wed, Jan 18, 2023 at 1:33 PM Michal Hocko wrote:
>
> On Wed 18-01-23 10:09:29, Suren Baghdasaryan wrote:
> > On Wed, Jan 18, 2023 at 1:23 AM Michal Hocko wrote:
> > >
> > > On Tue 17-01-23 18:01:01, Suren Baghdasaryan wrote:
> > > > On Tue, Jan 17, 2023 at 7:16 AM Michal Hocko wrote:
> > > >
On Wed, Jan 18, 2023 at 09:13:05PM +0100, Erhard F. wrote:
> On Tue, 17 Jan 2023 17:58:04 +0100
> Michal Suchanek wrote:
>
> > Since Linux 5.19 this error is observed:
> >
> > sysfs: cannot create duplicate filename '/devices/platform/of-display'
> >
> > This is because multiple devices with th
On Wed, Jan 18, 2023 at 1:28 PM Michal Hocko wrote:
>
> On Wed 18-01-23 09:36:44, Suren Baghdasaryan wrote:
> > On Wed, Jan 18, 2023 at 7:11 AM 'Michal Hocko' via kernel-team
> > wrote:
> > >
> > > On Wed 18-01-23 14:23:32, Jann Horn wrote:
> > > > On Wed, Jan 18, 2023 at 1:28 PM Michal Hocko wr
On Wed 18-01-23 10:09:29, Suren Baghdasaryan wrote:
> On Wed, Jan 18, 2023 at 1:23 AM Michal Hocko wrote:
> >
> > On Tue 17-01-23 18:01:01, Suren Baghdasaryan wrote:
> > > On Tue, Jan 17, 2023 at 7:16 AM Michal Hocko wrote:
> > > >
> > > > On Mon 09-01-23 12:53:12, Suren Baghdasaryan wrote:
> > >
On Tue, Jan 17, 2023 at 6:44 PM Matthew Wilcox wrote:
>
> On Tue, Jan 17, 2023 at 05:06:57PM -0800, Suren Baghdasaryan wrote:
> > On Tue, Jan 17, 2023 at 7:47 AM Michal Hocko wrote:
> > >
> > > On Mon 09-01-23 12:53:23, Suren Baghdasaryan wrote:
> > > > Introduce lock_vma_under_rcu function to lo
On Wed 18-01-23 09:36:44, Suren Baghdasaryan wrote:
> On Wed, Jan 18, 2023 at 7:11 AM 'Michal Hocko' via kernel-team
> wrote:
> >
> > On Wed 18-01-23 14:23:32, Jann Horn wrote:
> > > On Wed, Jan 18, 2023 at 1:28 PM Michal Hocko wrote:
> > > > On Tue 17-01-23 19:02:55, Jann Horn wrote:
> > > > > +
On Wed, Jan 18, 2023 at 11:01:08AM -0800, Suren Baghdasaryan wrote:
> On Wed, Jan 18, 2023 at 10:34 AM Paul E. McKenney wrote:
> >
> > On Wed, Jan 18, 2023 at 10:04:39AM -0800, Suren Baghdasaryan wrote:
> > > On Wed, Jan 18, 2023 at 1:49 AM Michal Hocko wrote:
> > > >
> > > > On Tue 17-01-23 17:1
On Wed, Jan 18, 2023 at 10:34 AM Paul E. McKenney wrote:
>
> On Wed, Jan 18, 2023 at 10:04:39AM -0800, Suren Baghdasaryan wrote:
> > On Wed, Jan 18, 2023 at 1:49 AM Michal Hocko wrote:
> > >
> > > On Tue 17-01-23 17:19:46, Suren Baghdasaryan wrote:
> > > > On Tue, Jan 17, 2023 at 7:57 AM Michal H
"usb-ohci" is another "generic" OHCI controller compatible string used by
several platforms. Add it to the generic-ohci.yaml schema and remove all
the old binding docs.
Marvell pxa-usb.txt has "usb-ohci" in the example, but actual users don't,
so drop it.
Signed-off-by: Rob Herring
---
v2:
- Fi
The Marvell Orion EHCI binding is just some compatible strings, so add it
to the generic-ehci.yaml schema.
Signed-off-by: Rob Herring
---
.../devicetree/bindings/usb/ehci-orion.txt | 22 --
.../devicetree/bindings/usb/generic-ehci.yaml | 2 ++
2 files changed, 2
The OMAP OHCI and EHCI USB host bindings follow the generic binding, so
add the compatibles and remove the old txt binding docs.
The examples in omap-usb-host.txt don't match actual users, so update
them dropping the fallback compatible.
Signed-off-by: Rob Herring
---
v2:
- New patch
---
.../d
The "brcm,bcm3384-ohci" and "brcm,bcm3384-ehci" compatibles are already
documented in generic-ohci.yaml and generic-ehci.yaml, respectively, so
remove the old txt binding.
Signed-off-by: Rob Herring
---
Documentation/devicetree/bindings/usb/brcm,bcm3384-usb.txt | 11 ---
1 file changed,
The Nuvoton EHCI binding is just some compatible strings, so add it to the
generic-ehci.yaml schema.
Signed-off-by: Rob Herring
---
.../devicetree/bindings/usb/generic-ehci.yaml| 2 ++
.../devicetree/bindings/usb/npcm7xx-usb.txt | 20
2 files changed, 2 ins
The 'ohci-usb' compatible is another 'generic' compatible for OHCI, but
isn't documented with a schema. Let's add it to generic-ohci.yaml
schema. While looking at this, I found a few other USB host bindings
which are simple enough to use the 'generic' schemas.
Signed-off-by: Rob Herring
---
Ch
On Wed, Jan 18, 2023 at 10:04:39AM -0800, Suren Baghdasaryan wrote:
> On Wed, Jan 18, 2023 at 1:49 AM Michal Hocko wrote:
> >
> > On Tue 17-01-23 17:19:46, Suren Baghdasaryan wrote:
> > > On Tue, Jan 17, 2023 at 7:57 AM Michal Hocko wrote:
> > > >
> > > > On Mon 09-01-23 12:53:34, Suren Baghdasar
On Wed, Jan 18, 2023 at 1:23 AM Michal Hocko wrote:
>
> On Tue 17-01-23 18:01:01, Suren Baghdasaryan wrote:
> > On Tue, Jan 17, 2023 at 7:16 AM Michal Hocko wrote:
> > >
> > > On Mon 09-01-23 12:53:12, Suren Baghdasaryan wrote:
> > > > Move VMA flag modification (which now implies VMA locking) be
On Wed, Jan 18, 2023 at 1:43 AM 'Michal Hocko' via kernel-team
wrote:
>
> On Tue 17-01-23 17:53:00, Suren Baghdasaryan wrote:
> > On Tue, Jan 17, 2023 at 7:42 AM 'Michal Hocko' via kernel-team
> > wrote:
> > >
> > > On Mon 09-01-23 12:53:21, Suren Baghdasaryan wrote:
> > > > Assert there are no h
On Wed, Jan 18, 2023 at 1:49 AM Michal Hocko wrote:
>
> On Tue 17-01-23 17:19:46, Suren Baghdasaryan wrote:
> > On Tue, Jan 17, 2023 at 7:57 AM Michal Hocko wrote:
> > >
> > > On Mon 09-01-23 12:53:34, Suren Baghdasaryan wrote:
> > > > call_rcu() can take a long time when callback offloading is e
On Wed, Jan 18, 2023 at 1:40 AM Michal Hocko wrote:
>
> On Tue 17-01-23 21:28:06, Jann Horn wrote:
> > On Tue, Jan 17, 2023 at 4:25 PM Michal Hocko wrote:
> > > On Mon 09-01-23 12:53:13, Suren Baghdasaryan wrote:
> > > > Protect VMA from concurrent page fault handler while collapsing a huge
> > >
On Wed, Jan 18, 2023 at 4:51 AM Jann Horn wrote:
>
> On Mon, Jan 9, 2023 at 9:54 PM Suren Baghdasaryan wrote:
> > Page fault handlers might need to fire MMU notifications while a new
> > notifier is being registered. Modify mm_take_all_locks to write-lock all
> > VMAs and prevent this race with f
On Wed, Jan 18, 2023 at 7:11 AM 'Michal Hocko' via kernel-team
wrote:
>
> On Wed 18-01-23 14:23:32, Jann Horn wrote:
> > On Wed, Jan 18, 2023 at 1:28 PM Michal Hocko wrote:
> > > On Tue 17-01-23 19:02:55, Jann Horn wrote:
> > > > +locking maintainers
> > > >
> > > > On Mon, Jan 9, 2023 at 9:54 PM
[ Adding a few more x86 and arm64 maintainers - while linux-arch is
the right mailing list, I'm not convinced people actually follow it
all that closely ]
On Wed, Jan 18, 2023 at 12:00 AM Nicholas Piggin wrote:
>
> On a 16-socket 192-core POWER8 system, a context switching benchmark
> with as man
On 17-01-23, 11:46, Sean Anderson wrote:
>
> I noticed that this series is marked "changes requested" on patchwork.
> However, I have received only automated feedback. I have done my best
> effort to address feedback I have received on prior revisions. I would
> appreciate getting another round of
On Tue, 17 Jan 2023 17:58:04 +0100, Michal Suchanek wrote:
> Since Linux 5.19 this error is observed:
>
> sysfs: cannot create duplicate filename '/devices/platform/of-display'
>
> This is because multiple devices with the same name 'of-display' are
> created on the same bus.
>
> Update the co
Prefer core helper if available.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 2 +-
drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_ggtt.c
Recently introduced helper simplifies the code.
Signed-off-by: Andrzej Hajda
---
include/linux/qed/qed_chain.h | 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/include/linux/qed/qed_chain.h b/include/linux/qed/qed_chain.h
index a84063492c71ae..6355d558cf01
Recently introduced helper simplifies the code.
Signed-off-by: Andrzej Hajda
---
io_uring/io_uring.c | 7 ++-
io_uring/slist.h| 6 ++
2 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c
index 2ac1cd8d23ea62..2b46a692d69022 100644
-
llist_del_all uses xchg, let's use __xchg here.
Signed-off-by: Andrzej Hajda
---
include/linux/llist.h | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/include/linux/llist.h b/include/linux/llist.h
index 85bda2d02d65be..4dc1d185ea98ab 100644
--- a/include/linux/llist.h
+
In all architectures, except x86, arch_uretprobe_hijack_return_addr
is just __xchg.
Signed-off-by: Andrzej Hajda
---
arch/arm/probes/uprobes/core.c | 8 ++--
arch/arm64/kernel/probes/uprobes.c | 9 ++---
arch/csky/kernel/probes/uprobes.c | 9 ++---
arch/mips/kernel/uprobes.c
The pattern of setting variable with new value and returning old
one is very common in kernel. Usually atomicity of the operation
is not required, so xchg seems to be suboptimal and confusing in
such cases.
Signed-off-by: Andrzej Hajda
Reviewed-by: Andy Shevchenko
---
include/linux/non-atomic/x
__xchg will be used for non-atomic xchg macro.
Signed-off-by: Andrzej Hajda
Reviewed-by: Arnd Bergmann
Acked-by: Geert Uytterhoeven [m68k]
Acked-by: Palmer Dabbelt [riscv]
---
v2: squashed all arch patches into one
v3: fixed alpha/xchg_local, thx to l...@intel.com
v4: adjusted indentation (Hei
Hi all,
The helper is tiny and there are advices we can live without it, so
I want to present few arguments why it would be good to have it:
1. Code readability/simplification/number of lines:
- decreases number of lines,
- it often eliminates local variables,
- for real examples see patche
On Wed 18-01-23 14:23:32, Jann Horn wrote:
> On Wed, Jan 18, 2023 at 1:28 PM Michal Hocko wrote:
> > On Tue 17-01-23 19:02:55, Jann Horn wrote:
> > > +locking maintainers
> > >
> > > On Mon, Jan 9, 2023 at 9:54 PM Suren Baghdasaryan
> > > wrote:
> > > > Introduce a per-VMA rw_semaphore to be use
Em Mon, Jan 16, 2023 at 10:31:30AM +0530, Athira Rajeev escreveu:
> The test "build id cache operations" fails on powerpc
> As below:
>
> Adding 5a0fd882b53084224ba47b624c55a469 ./tests/shell/../pe-file.exe: Ok
> build id: 5a0fd882b53084224ba47b624c55a469
> link: /tmp/perf.debug.
On Wed, Jan 18, 2023 at 1:28 PM Michal Hocko wrote:
> On Tue 17-01-23 19:02:55, Jann Horn wrote:
> > +locking maintainers
> >
> > On Mon, Jan 9, 2023 at 9:54 PM Suren Baghdasaryan wrote:
> > > Introduce a per-VMA rw_semaphore to be used during page fault handling
> > > instead of mmap_lock. Becau
...
> > One thing that might be gnarly here is that I think you might not be
> > allowed to use up_read() to fully release ownership of an object -
> > from what I remember, I think that up_read() (unlike something like
> > spin_unlock()) can access the lock object after it's already been
> > acqui
On 1/18/23 01:10, Andrew Donnellan wrote:
+
+// PLPKS dynamic secure boot doesn't give us a format string in the same way
OPAL does.
+// Instead, report the format using the SB_VERSION variable in the keystore.
+static ssize_t plpks_secvar_format(char *buf)
Ideally there would be a size_t
On Mon, Jan 9, 2023 at 9:54 PM Suren Baghdasaryan wrote:
> Page fault handlers might need to fire MMU notifications while a new
> notifier is being registered. Modify mm_take_all_locks to write-lock all
> VMAs and prevent this race with fault handlers that would hold VMA locks.
> VMAs are locked b
On Wed, Jan 18, 2023 at 10:40 AM Michal Hocko wrote:
> On Tue 17-01-23 21:28:06, Jann Horn wrote:
> > On Tue, Jan 17, 2023 at 4:25 PM Michal Hocko wrote:
> > > On Mon 09-01-23 12:53:13, Suren Baghdasaryan wrote:
> > > > Protect VMA from concurrent page fault handler while collapsing a huge
> > >
On Tue 17-01-23 19:02:55, Jann Horn wrote:
> +locking maintainers
>
> On Mon, Jan 9, 2023 at 9:54 PM Suren Baghdasaryan wrote:
> > Introduce a per-VMA rw_semaphore to be used during page fault handling
> > instead of mmap_lock. Because there are cases when multiple VMAs need
> > to be exclusively
On Wed, 2023-01-18 at 17:10 +1100, Andrew Donnellan wrote:
>
> struct umem_info {
> u64 *buf; /* data buffer for usable-memory
> property */
> @@ -1155,7 +1156,7 @@ int setup_new_fdt_ppc64(const struct kimage
> *image, void *fdt,
> unsigned long initr
On Tue 17-01-23 17:19:46, Suren Baghdasaryan wrote:
> On Tue, Jan 17, 2023 at 7:57 AM Michal Hocko wrote:
> >
> > On Mon 09-01-23 12:53:34, Suren Baghdasaryan wrote:
> > > call_rcu() can take a long time when callback offloading is enabled.
> > > Its use in the vm_area_free can cause regressions i
On Tue 17-01-23 17:53:00, Suren Baghdasaryan wrote:
> On Tue, Jan 17, 2023 at 7:42 AM 'Michal Hocko' via kernel-team
> wrote:
> >
> > On Mon 09-01-23 12:53:21, Suren Baghdasaryan wrote:
> > > Assert there are no holders of VMA lock for reading when it is about to be
> > > destroyed.
> > >
> > > Si
On Tue 17-01-23 21:28:06, Jann Horn wrote:
> On Tue, Jan 17, 2023 at 4:25 PM Michal Hocko wrote:
> > On Mon 09-01-23 12:53:13, Suren Baghdasaryan wrote:
> > > Protect VMA from concurrent page fault handler while collapsing a huge
> > > page. Page fault handler needs a stable PMD to use PTL and rel
On Wed, Jan 18, 2023 at 02:04:44PM +1100, Stephen Rothwell wrote:
>
> arch/powerpc/crypto/aesp8-ppc.o: warning: objtool:
> aes_p8_set_encrypt_key+0x44: unannotated intra-function call
>
> from the powerpc pseries_le_defconfig build (which is otherwise ok).
Thanks Stephen. I've reverted these ch
On Tue 17-01-23 18:01:01, Suren Baghdasaryan wrote:
> On Tue, Jan 17, 2023 at 7:16 AM Michal Hocko wrote:
> >
> > On Mon 09-01-23 12:53:12, Suren Baghdasaryan wrote:
> > > Move VMA flag modification (which now implies VMA locking) before
> > > anon_vma_lock_write to match the locking order of page
On Tue 17-01-23 21:54:58, Matthew Wilcox wrote:
> On Tue, Jan 17, 2023 at 01:21:47PM -0800, Suren Baghdasaryan wrote:
> > On Tue, Jan 17, 2023 at 7:12 AM Michal Hocko wrote:
> > >
> > > On Tue 17-01-23 16:04:26, Michal Hocko wrote:
> > > > On Mon 09-01-23 12:53:07, Suren Baghdasaryan wrote:
> > >
> On 18-Jan-2023, at 11:35 AM, Namhyung Kim wrote:
>
> When it saves the branch stack to the perf sample data, it needs to
> update the sample flags and the dynamic size. To make sure this,
> add the perf_sample_save_brstack() helper and convert all call sites.
>
> Cc: linuxppc-dev@lists.ozl
Linus Torvalds wrote:
> And for the kernel, where we don't have bad locking, and where we
> actually use fine-grained locks that are _near_ the data that we are
> locking (the lockref of the dcache is obviously one example of that,
> but the skbuff queue you mention is almost certainly exactly th
Hi Stephen,
On 18/01/23 08:34, Stephen Rothwell wrote:
Hi Herbert,
On Tue, 17 Jan 2023 15:26:24 +0800 Herbert Xu
wrote:
On Tue, Jan 17, 2023 at 02:47:47PM +1100, Stephen Rothwell wrote:
Hi all,
After merging the crypto tree, today's linux-next build (powerpc
pseries_le_defconfig) failed li
** Not for merge **
CONFIG_MMU_LAZY_TLB_SHOOTDOWN that requires IPIs to clear the "lazy tlb"
references to an mm that is being freed. With the radix MMU, the final
userspace exit TLB flush can be performed with IPIs, and those IPIs can
also clear lazy tlb mm references, which mostly eliminates the
On a 16-socket 192-core POWER8 system, a context switching benchmark
with as many software threads as CPUs (so each switch will go in and
out of idle), upstream can achieve a rate of about 1 million context
switches per second, due to contention on the mm refcount.
64s meets the prerequisites for
On big systems, the mm refcount can become highly contented when doing
a lot of context switching with threaded applications (particularly
switching between the idle thread and an application thread).
Abandoning lazy tlb slows switching down quite a bit in the important
user->idle->user cases, so
Add CONFIG_MMU_TLB_REFCOUNT which enables refcounting of the lazy tlb mm
when it is context switched. This can be disabled by architectures that
don't require this refcounting if they clean up lazy tlb mms when the
last refcount is dropped. Currently this is always enabled, which is
what existing c
Add explicit _lazy_tlb annotated functions for lazy tlb mm refcounting.
This makes the lazy tlb mm references more obvious, and allows the
refcounting scheme to be modified in later changes.
The only functional change is in kthread_use_mm/kthread_unuse_mm is
because it is clever with refcounting:
It's time for that annual flamewar. Nothing really changed in core code
to clean things up or make it better for x86 last year, so I think we
can table that objection.
IIRC the situation left off with Andy proposing a different approach,
and Linus preferring to shoot the lazies at exit time (piggy
71 matches
Mail list logo
