On Mon, Nov 20 2023 at 19:34, Vlastimil Babka wrote:
> The CPUHP_SLAB_PREPARE hooks are only used by SLAB which is removed.
> SLUB defines them as NULL, so we can remove those altogether.
>
> Signed-off-by: Vlastimil Babka
Acked-by: Thomas Gleixner
the way to enabling the wrap-around sanitizers in the future.
>
> Link: https://git.kernel.org/linus/68df3755e383e6fecf2354a67b08f92f18536594
> [1]
> Link: https://github.com/KSPP/linux/issues/26 [2]
> Link: https://github.com/KSPP/linux/issues/27 [3]
> Link: https://github.com/KS
On Wed, Mar 13 2024 at 05:30, Enlin Mu wrote:
> From: Enlin Mu
>
> On the Arm platform,arch_timer may occur irq strom,
> By using the next_timer of hrtimer_cpu_base, it is
> possible to quickly locate abnormal timers.
> As it is an out of tree modules,the function needs
> to be exproted.
No. We a
On Thu, Mar 14 2024 at 18:45, Enlin Mu wrote:
> Thomas Gleixner 于2024年3月14日周四 18:22写道：
>>
>> On Wed, Mar 13 2024 at 05:30, Enlin Mu wrote:
>> > From: Enlin Mu
>> >
>> > On the Arm platform,arch_timer may occur irq strom,
>> > By using the nex
On Fri, Mar 15 2024 at 11:12, Enlin Mu wrote:
> Thomas Gleixner 于2024年3月14日周四 19:59写道：
>>
>> On Thu, Mar 14 2024 at 18:45, Enlin Mu wrote:
>> > Thomas Gleixner 于2024年3月14日周四 18:22写道：
>> >>
>> >> On Wed, Mar 13 2024 at 05:30, Enlin Mu wrote:
&g
On Tue, May 07 2024 at 04:34, Justin Stitt wrote:
> Using syzkaller alongside the newly reintroduced signed integer overflow
> sanitizer spits out this report:
>
> [ 138.454979] [ cut here ]
> [ 138.458089] UBSAN: signed-integer-overflow in ../kernel/time/ntp.c:461:16
> [
On Thu, May 16 2024 at 16:40, Justin Stitt wrote:
> On Tue, May 14, 2024 at 3:38 AM Thomas Gleixner wrote:
>> So how can 0xf42400 + 50/1000 overflow in the first place?
>>
>> It can't unless time_maxerror is somehow initialized to a bogus
Justin!
On Fri, May 17 2024 at 00:47, Justin Stitt wrote:
> if (txc->modes & ADJ_TIMECONST) {
> - time_constant = txc->constant;
> - if (!(time_status & STA_NANO))
> + if (!(time_status & STA_NANO) && time_constant < MAXTC)
> time_con
On Fri, May 17 2024 at 22:18, Justin Stitt wrote:
> On Fri, May 17, 2024, 19:33 Thomas Gleixner wrote:
> I accidentally sent a Frankstein-esque creation of two patches I was
> working on. Not my brightest moment. It got past my testing because (as you
> pointed out) I only ran th
On Fri, May 17 2024 at 20:22, Justin Stitt wrote:
> time_maxerror is unconditionally incremented and the result is checked
> against NTP_PHASE_LIMIT, but the increment itself can overflow,
> resulting in wrap-around to negative space.
>
> The user can supply some crazy values which is causing the o
On Fri, May 24 2024 at 14:09, Thomas Gleixner wrote:
> On Fri, May 17 2024 at 20:22, Justin Stitt wrote:
> I dug into history to find a Fixes tag. That unearthed something
> interesting. Exactly this check used to be there until commit
> eea83d896e31 ("ntp: NTP4 user space bi
Justin!
On Fri, May 24 2024 at 15:43, Justin Stitt wrote:
> I appreciate you reviewing my patches.
You're welcome!
> On Fri, May 24, 2024 at 5:09 AM Thomas Gleixner wrote:
>> So instead of turning the clock back, we might be better off to actually
>> put the normal
On Tue, May 28 2024 at 07:18, Dave Hansen wrote:
> On 5/27/24 23:38, Tony W Wang-oc wrote:
> ...> diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
>> index c96ae8fee95e..ecadd0698d6a 100644
>> --- a/arch/x86/kernel/hpet.c
>> +++ b/arch/x86/kernel/hpet.c
>> @@ -804,6 +804,12 @@ static u6
Linus!
On Tue, May 28 2024 at 16:22, Linus Torvalds wrote:
> On Tue, 28 May 2024 at 15:12, Thomas Gleixner wrote:
> I see the smiley, but yeah, I don't think we really care about it.
Indeed. But the same problem exists on other architectures as
well. drivers/clocksource alone has
On Wed, May 29 2024 at 12:39, Tony W Wang-oc wrote:
> printk deadlock will happened at #A because in_nmi() evaluates to false
> on CPU B and CPU B do not enter the panic() AT #A.
>
> Update user space MCE handler to NMI class context is preferred?
No.
On Wed, May 29 2024 at 14:44, Tony W Wang-oc wrote:
> Actually, this scenario is what this patch is trying to solve.
>
> We encountered hpet_lock deadlock from the call path of the MCE handler,
> and this hpet_lock deadlock scenario may happen when others exceptions'
> handler like #PF/#GP... to ca
On Mon, May 27 2024 at 10:26, Miroslav Lichvar wrote:
> On Fri, May 24, 2024 at 02:44:19PM +0200, Thomas Gleixner wrote:
>> On Fri, May 24 2024 at 14:09, Thomas Gleixner wrote:
>> > So instead of turning the clock back, we might be better off to actually
>> > put the no
On Sat, Jun 01 2024 at 03:10, Gatlin Newhouse wrote:
> Bring x86 to parity with arm64, similar to commit 25b84002afb9
> ("arm64: Support Clang UBSAN trap codes for better reporting").
> Enable the output of UBSAN type information on x86 architectures
> compiled with clang when CONFIG_UBSAN_TRAP=y.
On Wed, Jun 12 2024 at 11:42, Kees Cook wrote:
> On Tue, Jun 11, 2024 at 01:26:09PM -0700, Gatlin Newhouse wrote:
>> It seems that is_valid_bugaddr() needs to be implemented on all architectures
>> and the function get_ud_type() replaces it here. So how should the patch
>> handle
>> is_valid_bugad
On Mon, Jun 17 2024 at 16:06, Kees Cook wrote:
> On Tue, Jun 18, 2024 at 12:13:27AM +0200, Thomas Gleixner wrote:
>> In fact is_valid_bugaddr() should be globally fixed up to return bool to
>> match what the function name suggests.
>>
>> The UD type information i
teven Rostedt (Google) # for kernel/trace/
> Reviewed-by: Martin K. Petersen # SCSI
> Reviewed-by: Darrick J. Wong # xfs
> Acked-by: Jani Nikula
> Acked-by: Corey Minyard
> Signed-off-by: Joel Granados
Acked-by: Thomas Gleixner
21 matches
Mail list logo
