On 09/02/21 09:14, Christoph Hellwig wrote:
On Mon, Feb 08, 2021 at 07:18:56PM +0100, Paolo Bonzini wrote:
Fair enough. I would expect that pretty much everyone using follow_pfn will
at least want to switch to this one (as it's less bad and not impossible to
use correctly), but I'll squash
On Mon, Feb 08, 2021 at 07:18:56PM +0100, Paolo Bonzini wrote:
> Fair enough. I would expect that pretty much everyone using follow_pfn will
> at least want to switch to this one (as it's less bad and not impossible to
> use correctly), but I'll squash this in:
Daniel looked into them, so he
On 08/02/21 18:39, Christoph Hellwig wrote:
+int follow_pte(struct mm_struct *mm, unsigned long address,
+ pte_t **ptepp, spinlock_t **ptlp)
+{
+ return follow_invalidate_pte(mm, address, NULL, ptepp, NULL, ptlp);
+}
+EXPORT_SYMBOL_GPL(follow_pte);
I still don't think this
> +int follow_invalidate_pte(struct mm_struct *mm, unsigned long address,
> + struct mmu_notifier_range *range, pte_t **ptepp,
> pmd_t **pmdpp,
> + spinlock_t **ptlp);
This adds a very pointless overy long line.
> +/**
> + * follow_pte - look up PTE
On Fri, Feb 05, 2021 at 05:32:58AM -0500, Paolo Bonzini wrote:
> Currently, the follow_pfn function is exported for modules but
> follow_pte is not. However, follow_pfn is very easy to misuse,
> because it does not provide protections (so most of its callers
> assume the page is writable!) and
Currently, the follow_pfn function is exported for modules but
follow_pte is not. However, follow_pfn is very easy to misuse,
because it does not provide protections (so most of its callers
assume the page is writable!) and because it returns after having
already unlocked the page table lock.
From: Eric Dumazet
[ Upstream commit 72d05c00d7ecda85df29abd046da7e41cc071c17 ]
Before commit a337531b942b ("tcp: up initial rmem to 128KB and SYN rwin to
around 64KB")
small tcp_rmem[1] values were overridden by tcp_fixup_rcvbuf() to accommodate
various MSS.
This is no longer the case, and
From: Eric Dumazet
[ Upstream commit 72d05c00d7ecda85df29abd046da7e41cc071c17 ]
Before commit a337531b942b ("tcp: up initial rmem to 128KB and SYN rwin to
around 64KB")
small tcp_rmem[1] values were overridden by tcp_fixup_rcvbuf() to accommodate
various MSS.
This is no longer the case, and
From: Eric Dumazet
[ Upstream commit 72d05c00d7ecda85df29abd046da7e41cc071c17 ]
Before commit a337531b942b ("tcp: up initial rmem to 128KB and SYN rwin to
around 64KB")
small tcp_rmem[1] values were overridden by tcp_fixup_rcvbuf() to accommodate
various MSS.
This is no longer the case, and
From: Al Viro
no need to force its calling conventions to match the callback for
late unlamented ep_call_nested()...
Signed-off-by: Al Viro
---
fs/eventpoll.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index
Committer: Thomas Gleixner
CommitterDate: Tue, 19 May 2020 16:03:56 +02:00
x86/entry/64: Provide sane error entry/exit
For gradual conversion provide a macro parameter and the required code
which allows to handle instrumentation and interrupt flags tracking in C.
Signed-off-by: Thomas Gleixner
Steven Rostedt writes:
> On Tue, 05 May 2020 15:44:02 +0200
> Thomas Gleixner wrote:
>
>> +.if \sane == 0
>> TRACE_IRQS_OFF
>
> Are you implying that TRACE_IRQS_OFF is insane?
Very much so.
On Tue, 05 May 2020 15:44:02 +0200
Thomas Gleixner wrote:
> + .if \sane == 0
> TRACE_IRQS_OFF
Are you implying that TRACE_IRQS_OFF is insane?
-- Steve
On Tue, May 5, 2020 at 7:15 AM Thomas Gleixner wrote:
>
> For gradual conversion provide a macro parameter and the required code
> which allows to handle instrumentation and interrupt flags tracking in C.
Acked-by: Andy Lutomirski
(-)
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -500,8 +500,9 @@ SYM_CODE_END(spurious_entries_start)
* @vector:Vector number
* @cfunc: C function to be called
* @has_error_code:Hardware pushed error code on stack
+ * @sane: Sane variant
Now that magic-link modes are obeyed for file re-opening purposes, some
of the pre-existing magic-link modes need to be adjusted to be more
semantically correct.
The most blatant example of this is /proc/self/exe, which had a mode of
a+rwx even though tautologically the file could never be opened
atch. To stop trying to fix something that was broken to
begin with – at least that was what I got from the discussion here.
Do a sane API with new function names, new flag names and over time
deprecate the old one completely so that one day it hopefully could be
gradually disabled until it can be
From: "Peter Zijlstra (Intel)"
On x86_64 we can do a u64 * u64 -> u128 widening multiply followed by
a u128 / u64 -> u64 division to implement a sane version of
mul_u64_u32_div().
Signed-off-by: Peter Zijlstra (Intel)
---
New patch for V4
arch/x86/include/asm/div64.h | 13
to restore some sane defaults and
re-enable the low-level common parts of the GPU (such as the GMCH).
v2: Restore GTT entries.
Signed-off-by: Chris Wilson
Link:
https://patchwork.freedesktop.org/patch/msgid/20180726085033.4044-2-ch...@chris-wilson.co.uk
Reviewed-by: Michał Winiarski
Signed-off
state, we need to restore some sane defaults and
re-enable the low-level common parts of the GPU (such as the GMCH).
v2: Restore GTT entries.
Signed-off-by: Chris Wilson
Link:
https://patchwork.freedesktop.org/patch/msgid/20180726085033.4044-2-ch...@chris-wilson.co.uk
Reviewed-by: Michał
: Ingo Molnar
CommitterDate: Tue, 03 Sep 2019 08:56:14 +02:00
x86/math64: Provide a sane mul_u64_u32_div() implementation for x86_64
On x86_64 we can do a u64 * u64 -> u128 widening multiply followed by
a u128 / u64 -> u64 division to implement a sane version of
mul_u64_u32_div().
Sign
> > But also; x86_64 seems to lack a sane implementation of that function,
> > and it currently compiles into utter crap (it can be 2 instructions).
This one actually builds defconfig :-)
---
Subject: x86/math64: Provide a sane mul_u64_u32_div() implementation for x86_64
From: Peter Z
On Wed, Aug 28, 2019 at 05:19:21PM +0200, Peter Zijlstra wrote:
> On Mon, Aug 26, 2019 at 07:47:35AM -0700, kan.li...@linux.intel.com wrote:
> > + return mul_u64_u32_div(slots, val, 0xff);
>
> But also; x86_64 seems to lack a sane implementation of that function,
> and it
On Mon, 2019-07-01 at 19:51 -0700, Florian Fainelli wrote:
> Hi Ben,
>
> On 6/18/2019 7:28 AM, Ben Hutchings wrote:
> > 3.16.69-rc1 review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Eric Dumazet
> >
> > commit
Hi Ben,
On 6/18/2019 7:28 AM, Ben Hutchings wrote:
> 3.16.69-rc1 review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Eric Dumazet
>
> commit f070ef2ac66716357066b683fb0baf55f8191a2e upstream.
>
> Jonathan Looney reported that a malicious peer can
3.16.69-rc1 review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
commit f070ef2ac66716357066b683fb0baf55f8191a2e upstream.
Jonathan Looney reported that a malicious peer can force a sender
to fragment its retransmit queue into tiny skbs,
Now that magic-link modes are obeyed for file re-opening purposes, some
of the pre-existing magic-link modes need to be adjusted to be more
semantically correct.
The most blatant example of this is /proc/self/exe, which had a mode of
a+rwx even though tautologically the file could never be opened
3.16.66-rc1 review patch. If anyone has any objections, please let me know.
--
From: Icenowy Zheng
commit c5603d2fdb424849360fe7e3f8c1befc97571b8c upstream.
Currently the code will set US_FL_SANE_SENSE flag unconditionally if
device claims SPC3+, however we should allow
On Tue, Apr 16, 2019 at 01:56:44PM +0200, Pavel Machek wrote:
On Mon 2019-04-15 13:18:56, Andy Lutomirski wrote:
On Mon, Apr 15, 2019 at 1:04 PM Pavel Machek wrote:
>
> On Mon 2019-04-15 20:58:23, Greg Kroah-Hartman wrote:
> > [ Upstream commit 7ee18d677989e99635027cee04c878950e0752b9 ]
> >
>
On Mon 2019-04-15 13:18:56, Andy Lutomirski wrote:
> On Mon, Apr 15, 2019 at 1:04 PM Pavel Machek wrote:
> >
> > On Mon 2019-04-15 20:58:23, Greg Kroah-Hartman wrote:
> > > [ Upstream commit 7ee18d677989e99635027cee04c878950e0752b9 ]
> > >
> > > My previous attempt to fix a couple of bugs in
> >
On Mon, Apr 15, 2019 at 1:04 PM Pavel Machek wrote:
>
> On Mon 2019-04-15 20:58:23, Greg Kroah-Hartman wrote:
> > [ Upstream commit 7ee18d677989e99635027cee04c878950e0752b9 ]
> >
> > My previous attempt to fix a couple of bugs in
> > __restore_processor_context():
> >
> > 5b06bbcfc2c6
On Mon 2019-04-15 20:58:23, Greg Kroah-Hartman wrote:
> [ Upstream commit 7ee18d677989e99635027cee04c878950e0752b9 ]
>
> My previous attempt to fix a couple of bugs in __restore_processor_context():
>
> 5b06bbcfc2c6 ("x86/power: Fix some ordering bugs in
> __restore_processor_context()")
>
>
[ Upstream commit 7ee18d677989e99635027cee04c878950e0752b9 ]
My previous attempt to fix a couple of bugs in __restore_processor_context():
5b06bbcfc2c6 ("x86/power: Fix some ordering bugs in
__restore_processor_context()")
... introduced yet another bug, breaking suspend-resume.
Rather than
[ Upstream commit 7ee18d677989e99635027cee04c878950e0752b9 ]
My previous attempt to fix a couple of bugs in __restore_processor_context():
5b06bbcfc2c6 ("x86/power: Fix some ordering bugs in
__restore_processor_context()")
... introduced yet another bug, breaking suspend-resume.
Rather than
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Icenowy Zheng
commit c5603d2fdb424849360fe7e3f8c1befc97571b8c upstream.
Currently the code will set US_FL_SANE_SENSE flag unconditionally if
device claims SPC3+, however we should allow
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Icenowy Zheng
commit c5603d2fdb424849360fe7e3f8c1befc97571b8c upstream.
Currently the code will set US_FL_SANE_SENSE flag unconditionally if
device claims SPC3+, however we should allow
4.20-stable review patch. If anyone has any objections, please let me know.
--
From: Icenowy Zheng
commit c5603d2fdb424849360fe7e3f8c1befc97571b8c upstream.
Currently the code will set US_FL_SANE_SENSE flag unconditionally if
device claims SPC3+, however we should allow
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Icenowy Zheng
commit c5603d2fdb424849360fe7e3f8c1befc97571b8c upstream.
Currently the code will set US_FL_SANE_SENSE flag unconditionally if
device claims SPC3+, however we should allow
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Icenowy Zheng
commit c5603d2fdb424849360fe7e3f8c1befc97571b8c upstream.
Currently the code will set US_FL_SANE_SENSE flag unconditionally if
device claims SPC3+, however we should allow
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Icenowy Zheng
commit c5603d2fdb424849360fe7e3f8c1befc97571b8c upstream.
Currently the code will set US_FL_SANE_SENSE flag unconditionally if
device claims SPC3+, however we should allow
Currently the code will set US_FL_SANE_SENSE flag unconditionally if
device claims SPC3+, however we should allow US_FL_BAD_SENSE flag to
prevent this behavior, because SMI SM3350 UFS-USB bridge controller,
which claims SPC4, will show strange behavior with 96-byte sense
(put the chip into a wrong
On Thu, 27 Dec 2018, Icenowy Zheng wrote:
> Currently the code will set US_FL_SANE_SENSE flag unconditionally if
> device claims SPC3+, however we should allow US_FL_BAD_SENSE flag to
> prevent this behavior, because SMI SM3350 UFS-USB bridge controller,
> which claims SPC4, will show strange
在 2018-12-27四的 22:34 +0800，Icenowy Zheng写道：
> Currently the code will set US_FL_SANE_SENSE flag unconditionally if
> device claims SPC3+, however we should allow US_FL_BAD_SENSE flag to
> prevent this behavior, because SMI SM3350 UFS-USB bridge controller,
> which claims SPC4, will show strange
Currently the code will set US_FL_SANE_SENSE flag unconditionally if
device claims SPC3+, however we should allow US_FL_BAD_SENSE flag to
prevent this behavior, because SMI SM3350 UFS-USB bridge controller,
which claims SPC4, will show strange behavior with 96-byte sense
(put the chip into a wrong
On 2018-11-09, Masami Hiramatsu wrote:
> > diff --git a/arch/x86/include/asm/ptrace.h b/arch/x86/include/asm/ptrace.h
> > index ee696efec99f..c4dfafd43e11 100644
> > --- a/arch/x86/include/asm/ptrace.h
> > +++ b/arch/x86/include/asm/ptrace.h
> > @@ -172,6 +172,7 @@ static inline unsigned long
On 2018-11-09, Masami Hiramatsu wrote:
> > diff --git a/arch/x86/include/asm/ptrace.h b/arch/x86/include/asm/ptrace.h
> > index ee696efec99f..c4dfafd43e11 100644
> > --- a/arch/x86/include/asm/ptrace.h
> > +++ b/arch/x86/include/asm/ptrace.h
> > @@ -172,6 +172,7 @@ static inline unsigned long
On 2018-11-06, Steven Rostedt wrote:
> On Sun, 4 Nov 2018 22:59:13 +1100
> Aleksa Sarai wrote:
>
> > The same issue is present in __save_stack_trace
> > (arch/x86/kernel/stacktrace.c). This is likely the only reason that --
> > as Steven said -- stacktraces wouldn't work with ftrace-graph (and
On 2018-11-06, Steven Rostedt wrote:
> On Sun, 4 Nov 2018 22:59:13 +1100
> Aleksa Sarai wrote:
>
> > The same issue is present in __save_stack_trace
> > (arch/x86/kernel/stacktrace.c). This is likely the only reason that --
> > as Steven said -- stacktraces wouldn't work with ftrace-graph (and
On Sat, 3 Nov 2018 13:30:21 -0400
Steven Rostedt wrote:
> On Sun, 4 Nov 2018 01:34:30 +0900
> Masami Hiramatsu wrote:
> >
> > > I was thinking of a bitmask that represents the handlers, and use that
> > > to map which handler gets called for which shadow entry for a
> > > particular task.
>
On Sat, 3 Nov 2018 13:30:21 -0400
Steven Rostedt wrote:
> On Sun, 4 Nov 2018 01:34:30 +0900
> Masami Hiramatsu wrote:
> >
> > > I was thinking of a bitmask that represents the handlers, and use that
> > > to map which handler gets called for which shadow entry for a
> > > particular task.
>
On 2018-11-02, Masami Hiramatsu wrote:
> On Thu, 1 Nov 2018 21:49:48 +1100
> Aleksa Sarai wrote:
>
> > On 2018-11-01, Masami Hiramatsu wrote:
> > > > > > Anyway, until that merge happens, this patch looks good to avoid
> > > > > > this issue for generic solution (e.g. for the arch which
On 2018-11-02, Masami Hiramatsu wrote:
> On Thu, 1 Nov 2018 21:49:48 +1100
> Aleksa Sarai wrote:
>
> > On 2018-11-01, Masami Hiramatsu wrote:
> > > > > > Anyway, until that merge happens, this patch looks good to avoid
> > > > > > this issue for generic solution (e.g. for the arch which
On Thu, 1 Nov 2018 21:49:48 +1100
Aleksa Sarai wrote:
> On 2018-11-01, Masami Hiramatsu wrote:
> > > > > Anyway, until that merge happens, this patch looks good to avoid
> > > > > this issue for generic solution (e.g. for the arch which doesn't
> > > > > supports retstack).
> > > >
> > > > I
On Thu, 1 Nov 2018 21:49:48 +1100
Aleksa Sarai wrote:
> On 2018-11-01, Masami Hiramatsu wrote:
> > > > > Anyway, until that merge happens, this patch looks good to avoid
> > > > > this issue for generic solution (e.g. for the arch which doesn't
> > > > > supports retstack).
> > > >
> > > > I
On Thu, 1 Nov 2018 21:49:48 +1100
Aleksa Sarai wrote:
> > > Should I continue working on this patchset?
> >
> > Yes, until we finally introduce Steven's algorithm on all arch (yeah, we
> > still
> > have some archs which don't support graph-tracer but supports kprobes),
> > I think your
On Thu, 1 Nov 2018 21:49:48 +1100
Aleksa Sarai wrote:
> > > Should I continue working on this patchset?
> >
> > Yes, until we finally introduce Steven's algorithm on all arch (yeah, we
> > still
> > have some archs which don't support graph-tracer but supports kprobes),
> > I think your
On 2018-11-01, Masami Hiramatsu wrote:
> > > > Anyway, until that merge happens, this patch looks good to avoid
> > > > this issue for generic solution (e.g. for the arch which doesn't
> > > > supports retstack).
> > >
> > > I think its time to come up with an algorithm that makes function graph
On 2018-11-01, Masami Hiramatsu wrote:
> > > > Anyway, until that merge happens, this patch looks good to avoid
> > > > this issue for generic solution (e.g. for the arch which doesn't
> > > > supports retstack).
> > >
> > > I think its time to come up with an algorithm that makes function graph
On Thu, 1 Nov 2018 00:39:12 +1100
Aleksa Sarai wrote:
> On 2018-10-31, Steven Rostedt wrote:
> > > Anyway, until that merge happens, this patch looks good to avoid
> > > this issue for generic solution (e.g. for the arch which doesn't
> > > supports retstack).
> >
> > I think its time to come
On Thu, 1 Nov 2018 00:39:12 +1100
Aleksa Sarai wrote:
> On 2018-10-31, Steven Rostedt wrote:
> > > Anyway, until that merge happens, this patch looks good to avoid
> > > this issue for generic solution (e.g. for the arch which doesn't
> > > supports retstack).
> >
> > I think its time to come
essary now that stack traces are sane. *However* this patch
might be a bit contentious since the original usecase (that ftrace
returns shouldn't show kretprobe_trampoline) is arguably still an
issue. Feel free to drop it if you think it is wrong.
Patch changelog:
v3:
* kprobe: fix build on !CONFIG_K
essary now that stack traces are sane. *However* this patch
might be a bit contentious since the original usecase (that ftrace
returns shouldn't show kretprobe_trampoline) is arguably still an
issue. Feel free to drop it if you think it is wrong.
Patch changelog:
v3:
* kprobe: fix build on !CONFIG_K
the stack trace and return the
> > > entry stack trace when it is requested.
> > >
> > > In theory, patches like commit 76094a2cf46e ("ftrace: distinguish
> > > kretprobe'd functions in trace logs") are no longer necessary *for
> > > tracing* because now all
the stack trace and return the
> > > entry stack trace when it is requested.
> > >
> > > In theory, patches like commit 76094a2cf46e ("ftrace: distinguish
> > > kretprobe'd functions in trace logs") are no longer necessary *for
> > > tracing* because now all
On 2018-10-31, Steven Rostedt wrote:
> > Anyway, until that merge happens, this patch looks good to avoid
> > this issue for generic solution (e.g. for the arch which doesn't
> > supports retstack).
>
> I think its time to come up with an algorithm that makes function graph
> work with multiple
On 2018-10-31, Steven Rostedt wrote:
> > Anyway, until that merge happens, this patch looks good to avoid
> > this issue for generic solution (e.g. for the arch which doesn't
> > supports retstack).
>
> I think its time to come up with an algorithm that makes function graph
> work with multiple
On Tue, 30 Oct 2018 10:12:06 +0900
Masami Hiramatsu wrote:
> Anyway, until that merge happens, this patch looks good to avoid
> this issue for generic solution (e.g. for the arch which doesn't
> supports retstack).
I think its time to come up with an algorithm that makes function graph
work
On Tue, 30 Oct 2018 10:12:06 +0900
Masami Hiramatsu wrote:
> Anyway, until that merge happens, this patch looks good to avoid
> this issue for generic solution (e.g. for the arch which doesn't
> supports retstack).
I think its time to come up with an algorithm that makes function graph
work
is requested.
> >
> > In theory, patches like commit 76094a2cf46e ("ftrace: distinguish
> > kretprobe'd functions in trace logs") are no longer necessary *for
> > tracing* because now all kretprobe traces should produce sane stack
> > traces. However it's not c
is requested.
> >
> > In theory, patches like commit 76094a2cf46e ("ftrace: distinguish
> > kretprobe'd functions in trace logs") are no longer necessary *for
> > tracing* because now all kretprobe traces should produce sane stack
> > traces. However it's not c
necessary *for
> tracing* because now all kretprobe traces should produce sane stack
> traces. However it's not clear whether removing them completely is
> reasonable.
Then, let's try to revert it :)
BTW, could you also add a test case for ftrace too?
also, I have some comments below.
&g
necessary *for
> tracing* because now all kretprobe traces should produce sane stack
> traces. However it's not clear whether removing them completely is
> reasonable.
Then, let's try to revert it :)
BTW, could you also add a test case for ftrace too?
also, I have some comments below.
&g
stack trace when it is requested.
In theory, patches like commit 76094a2cf46e ("ftrace: distinguish
kretprobe'd functions in trace logs") are no longer necessary *for
tracing* because now all kretprobe traces should produce sane stack
traces. However it's not clear whether removing them
stack trace when it is requested.
In theory, patches like commit 76094a2cf46e ("ftrace: distinguish
kretprobe'd functions in trace logs") are no longer necessary *for
tracing* because now all kretprobe traces should produce sane stack
traces. However it's not clear whether removing them
3.16.60-rc1 review patch. If anyone has any objections, please let me know.
--
From: Linus Torvalds
commit be83bbf806822b1b89e0a0f23cd87cddc409e429 upstream.
The internal VM "mmap()" interfaces are based on the mmap target doing
everything using page indexes rather than byte
3.16.60-rc1 review patch. If anyone has any objections, please let me know.
--
From: Linus Torvalds
commit be83bbf806822b1b89e0a0f23cd87cddc409e429 upstream.
The internal VM "mmap()" interfaces are based on the mmap target doing
everything using page indexes rather than byte
Get rid of the global variable sched_domains_curr_level, which is used
to pass state into a sd_numa_mask(), which is used as a callback for
sched_domain_topology_level->mask().
Extend the ->mask() callback instead, so that it takes the topology level
as an extra argument. Provide a backward
Get rid of the global variable sched_domains_curr_level, which is used
to pass state into a sd_numa_mask(), which is used as a callback for
sched_domain_topology_level->mask().
Extend the ->mask() callback instead, so that it takes the topology level
as an extra argument. Provide a backward
: Initialize new resource group with sane defaults
Currently when a new resource group is created its allocations would be
those that belonged to the resource group to which its closid belonged
previously.
That is, we can encounter a case like:
mkdir newgroup
cat newgroup/schemata
L2:0=ff;1=ff
echo 'L2
: Initialize new resource group with sane defaults
Currently when a new resource group is created its allocations would be
those that belonged to the resource group to which its closid belonged
previously.
That is, we can encounter a case like:
mkdir newgroup
cat newgroup/schemata
L2:0=ff;1=ff
echo 'L2
Currently when a new resource group is created its allocations would be
those that belonged to the resource group to which its closid belonged
previously.
That is, we can encounter a case like:
mkdir newgroup
cat newgroup/schemata
L2:0=ff;1=ff
echo 'L2:0=0xf0;1=0xf0' > newgroup/schemata
cat
Currently when a new resource group is created its allocations would be
those that belonged to the resource group to which its closid belonged
previously.
That is, we can encounter a case like:
mkdir newgroup
cat newgroup/schemata
L2:0=ff;1=ff
echo 'L2:0=0xf0;1=0xf0' > newgroup/schemata
cat
: Initialize new resource group with sane defaults
Currently when a new resource group is created its allocations would be
those that belonged to the resource group to which its closid belonged
previously.
That is, we can encounter a case like:
mkdir newgroup
cat newgroup/schemata
L2:0=ff;1=ff
echo 'L2
: Initialize new resource group with sane defaults
Currently when a new resource group is created its allocations would be
those that belonged to the resource group to which its closid belonged
previously.
That is, we can encounter a case like:
mkdir newgroup
cat newgroup/schemata
L2:0=ff;1=ff
echo 'L2
Hi Thomas,
On 6/19/2018 9:53 AM, Thomas Gleixner wrote:
> On Tue, 19 Jun 2018, Reinette Chatre wrote:
>> On 6/19/2018 5:31 AM, Thomas Gleixner wrote:
>>> On Thu, 7 Jun 2018, Reinette Chatre wrote:
+static void cbm_ensure_valid(u32 *_val, struct rdt_resource *r)
+{
+ unsigned long
Hi Thomas,
On 6/19/2018 9:53 AM, Thomas Gleixner wrote:
> On Tue, 19 Jun 2018, Reinette Chatre wrote:
>> On 6/19/2018 5:31 AM, Thomas Gleixner wrote:
>>> On Thu, 7 Jun 2018, Reinette Chatre wrote:
+static void cbm_ensure_valid(u32 *_val, struct rdt_resource *r)
+{
+ unsigned long
On Tue, 19 Jun 2018, Reinette Chatre wrote:
> On 6/19/2018 5:31 AM, Thomas Gleixner wrote:
> > On Thu, 7 Jun 2018, Reinette Chatre wrote:
> >> +static void cbm_ensure_valid(u32 *_val, struct rdt_resource *r)
> >> +{
> >> + unsigned long *val = (unsigned long *)_val;
> >
> > I'm a bit worried
On Tue, 19 Jun 2018, Reinette Chatre wrote:
> On 6/19/2018 5:31 AM, Thomas Gleixner wrote:
> > On Thu, 7 Jun 2018, Reinette Chatre wrote:
> >> +static void cbm_ensure_valid(u32 *_val, struct rdt_resource *r)
> >> +{
> >> + unsigned long *val = (unsigned long *)_val;
> >
> > I'm a bit worried
Hi Thomas,
On 6/19/2018 5:31 AM, Thomas Gleixner wrote:
> On Thu, 7 Jun 2018, Reinette Chatre wrote:
>> +/**
>> + * cbm_ensure_valid - Enforce validity on provided CBM
>> + * @_val: Candidate CBM
>> + * @r: RDT resource to which the CBM belongs
>> + *
>> + * The provided CBM
Hi Thomas,
On 6/19/2018 5:31 AM, Thomas Gleixner wrote:
> On Thu, 7 Jun 2018, Reinette Chatre wrote:
>> +/**
>> + * cbm_ensure_valid - Enforce validity on provided CBM
>> + * @_val: Candidate CBM
>> + * @r: RDT resource to which the CBM belongs
>> + *
>> + * The provided CBM
On Thu, 7 Jun 2018, Reinette Chatre wrote:
> +/**
> + * cbm_ensure_valid - Enforce validity on provided CBM
> + * @_val:Candidate CBM
> + * @r: RDT resource to which the CBM belongs
> + *
> + * The provided CBM represents all cache portions available for use. This
> + * may be
On Thu, 7 Jun 2018, Reinette Chatre wrote:
> +/**
> + * cbm_ensure_valid - Enforce validity on provided CBM
> + * @_val:Candidate CBM
> + * @r: RDT resource to which the CBM belongs
> + *
> + * The provided CBM represents all cache portions available for use. This
> + * may be
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Linus Torvalds
commit be83bbf806822b1b89e0a0f23cd87cddc409e429 upstream.
The internal VM "mmap()" interfaces are based on the mmap target doing
everything using page indexes rather than byte
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Linus Torvalds
commit be83bbf806822b1b89e0a0f23cd87cddc409e429 upstream.
The internal VM "mmap()" interfaces are based on the mmap target doing
everything using page indexes rather than byte
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Linus Torvalds
commit be83bbf806822b1b89e0a0f23cd87cddc409e429 upstream.
The internal VM "mmap()" interfaces are based on the mmap target doing
everything using page indexes rather than byte
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Linus Torvalds
commit be83bbf806822b1b89e0a0f23cd87cddc409e429 upstream.
The internal VM "mmap()" interfaces are based on the mmap target doing
everything using page indexes rather than byte
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Linus Torvalds
commit be83bbf806822b1b89e0a0f23cd87cddc409e429 upstream.
The internal VM "mmap()" interfaces are based on the mmap target doing
everything using page indexes rather than byte
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Linus Torvalds
commit be83bbf806822b1b89e0a0f23cd87cddc409e429 upstream.
The internal VM "mmap()" interfaces are based on the mmap target doing
everything using page indexes rather than byte
On Mon, Jun 11, 2018 at 08:12:45AM +1000, David Airlie wrote:
> Can you make sure you pull in
>
> 76ef6b28ea4f81c3d511866a9b31392caa833126 (tag:
> drm-fixes-for-v4.17-rc6-urgent)
> Author: Dave Airlie
> Date: Tue May 15 13:38:15 2018 +1000
>
> drm: set FMODE_UNSIGNED_OFFSET for drm files
On Mon, Jun 11, 2018 at 08:12:45AM +1000, David Airlie wrote:
> Can you make sure you pull in
>
> 76ef6b28ea4f81c3d511866a9b31392caa833126 (tag:
> drm-fixes-for-v4.17-rc6-urgent)
> Author: Dave Airlie
> Date: Tue May 15 13:38:15 2018 +1000
>
> drm: set FMODE_UNSIGNED_OFFSET for drm files
1 - 100 of 642 matches
Mail list logo
