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 this
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 may
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 is
> +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 at
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 bec
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.
Pro
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 H
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 H
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 H
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 8c3b02755a50..3e
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
/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
may be best
to start from scratch. 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
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
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-by
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
t; > 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 f070ef2ac66716357066b683fb0b
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, inflat
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 US_FL_
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 ("x86/pow
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 US_FL_
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 US_FL_B
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 US_FL_
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 US_FL_
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 US_FL_
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 US_FL_B
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 beha
在 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 beh
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 kern
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 t
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 doesn't
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 th
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 patc
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 u
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
xit -- we must stash away 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
>
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 u
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 with
ntry 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
> &
quot;) are no longer 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
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 kretprobe traces should produce sane stack
traces. However it's not clear whether re
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 o
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 compat
: 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 &#x
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 newgro
: 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 &#x
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 abou
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 represe
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 rep
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 of
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 o
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 of
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
>
4.16-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 o
4.14-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 o
t allocations.
Signed-off-by: Reinette Chatre
---
V6: The cache region that is available for use by a new resource group may
not be contiguous. Enforce the available region to be valid by
selecting only the first contiguous portion. The goal is to ensure a
sane and valid default on resource g
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 newgro
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 newgro
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 newgro
3.16.52-rc1 review patch. If anyone has any objections, please let me know.
--
From: Dmitry Torokhov
commit ea04efee7635c9120d015dcdeeeb6988130cb67a upstream.
Before trying to use CDC union descriptor, try to validate whether that it
is sane by checking that intf->altsett
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Gleixner
commit 7bbcbd3d1cdcbacd0f9f8dc4c98d550972f1ca30 upstream.
The recent cpu_entry_area changes fail to compile on 32-bit when BIGSMP=y
and NR_CPUS=512, because the fixmap area bec
The recent cpu_entry_area changes fail to compile on 32bit when BIGSMP=y
and NR_CPUS=512 because the fixmap area becomes too big.
Limit the number of CPUs with BIGSMP to 64, which is already way to big for
32bit, but it's at least a working limitation.
Signed-off-by: Thomas Gleixner
---
arch/x8
restore_processor_context() sane
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 trying to come up with
Hi!
> My previous attempt to fix a couple of bugs in
> __restore_processor_context() introduced yet another bug. Rather
> than trying to come up with a minimal fix, let's try to clean it up
> for real. This patch fixes quite a few things:
>
> - The old code saved a nonsensical subset of segmen
My previous attempt to fix a couple of bugs in
__restore_processor_context() introduced yet another bug. Rather
than trying to come up with a minimal fix, let's try to clean it up
for real. This patch fixes quite a few things:
- The old code saved a nonsensical subset of segment registers.
T
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Stanislaw Gruszka
[ Upstream commit a51b89698ccc93c7e274eb71377fae49c4593ab2 ]
Signed-off-by: Stanislaw Gruszka
Signed-off-by: Kalle Valo
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroa
4.13-stable review patch. If anyone has any objections, please let me know.
--
From: Dmitry Torokhov
commit ea04efee7635c9120d015dcdeeeb6988130cb67a upstream.
Before trying to use CDC union descriptor, try to validate whether that it
is sane by checking that intf->altsett
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Dmitry Torokhov
commit ea04efee7635c9120d015dcdeeeb6988130cb67a upstream.
Before trying to use CDC union descriptor, try to validate whether that it
is sane by checking that intf->altsett
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Dmitry Torokhov
commit ea04efee7635c9120d015dcdeeeb6988130cb67a upstream.
Before trying to use CDC union descriptor, try to validate whether that it
is sane by checking that intf->altsett
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Dmitry Torokhov
commit ea04efee7635c9120d015dcdeeeb6988130cb67a upstream.
Before trying to use CDC union descriptor, try to validate whether that it
is sane by checking that intf->altsett
From: Stanislaw Gruszka
[ Upstream commit a51b89698ccc93c7e274eb71377fae49c4593ab2 ]
Signed-off-by: Stanislaw Gruszka
Signed-off-by: Kalle Valo
Signed-off-by: Sasha Levin
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
ommitter: Ingo Molnar
> CommitDate: Sun, 17 Sep 2017 18:59:09 +0200
>
> x86/mm/32: Load a sane CR3 before cpu_init() on secondary CPUs
>
> For unknown historical reasons (i.e. Borislav doesn't recall),
> 32-bit kernels invoke cpu_init() on secondary CPUs with
> initial_p
CommitDate: Sun, 17 Sep 2017 18:59:09 +0200
x86/mm/32: Load a sane CR3 before cpu_init() on secondary CPUs
For unknown historical reasons (i.e. Borislav doesn't recall),
32-bit kernels invoke cpu_init() on secondary CPUs with
initial_page_table loaded into CR3. Then they set
current->a
Commit-ID: 4ba55e65f471d011d3ba2ac2022180ea0877d68e
Gitweb: http://git.kernel.org/tip/4ba55e65f471d011d3ba2ac2022180ea0877d68e
Author: Andy Lutomirski
AuthorDate: Sun, 17 Sep 2017 09:03:51 -0700
Committer: Ingo Molnar
CommitDate: Sun, 17 Sep 2017 18:59:09 +0200
x86/mm/32: Load a sane
For unknown historical reasons (i.e. Borislav doesn't recall),
32-bit kernels invoke cpu_init() on secondary CPUs with
intiial_page_table loaded into CR3. Then they set
current->active_mm to &init_mm and call enter_lazy_tlb() before
fixing CR3. This means that the x86 TLB code gets invoked while
t/meson-gx-mmc.c
@@ -339,6 +339,15 @@ static int meson_mmc_clk_init(struct meson_host *host)
const char *clk_div_parents[1];
u32 clk_reg, cfg;
+ /* init SD_EMMC_CLOCK to sane defaults w/min clock rate */
+ clk_reg = 0;
+ clk_reg |= CLK_ALWAYS_ON;
+
On Tue, Aug 1, 2017 at 1:19 PM, Linus Torvalds
wrote:
> On Tue, Aug 1, 2017 at 8:04 AM, Kees Cook wrote:
>>
>> Do you want me to carry this for -next and send it as a distinct pull
>> request for v4.14?
>
> Yes, I think that would be preferred. I consider this a "execve()"
> cleanup/change with i
On Tue, Aug 1, 2017 at 8:04 AM, Kees Cook wrote:
>
> Do you want me to carry this for -next and send it as a distinct pull
> request for v4.14?
Yes, I think that would be preferred. I consider this a "execve()"
cleanup/change with implications for the security models rather than
the other way aro
Use secureexec for setting dumpability
exec: Use secureexec for clearing pdeath_signal
smack: Remove redundant pdeath_signal clearing
exec: Consolidate dumpability logic
exec: Use sane stack rlimit under secureexec
exec: Consolidate pdeath_signal clearing
fs/binfm
For a secureexec, before memory layout selection has happened, reset the
stack rlimit to something sane to avoid the caller having control over
the resulting layouts.
$ ulimit -s
8192
$ ulimit -s unlimited
$ /bin/sh -c 'ulimit -s'
unlimited
$ sudo /bin/sh -c 'ulimit -s'
8192
On Mon, Jul 31, 2017 at 10:11 PM, Linus Torvalds
wrote:
> On Mon, Jul 31, 2017 at 8:03 PM, Kees Cook wrote:
>>
>> Yeah, I'm open to whatever. It's not clear where it should go, but if
>> you want to take it and Linus doesn't want it "early", that works for
>> me. Linus, Andrew, thoughts?
>
> I'd
1 - 100 of 343 matches
Mail list logo
