Re: pstore: fix compression

the erst-dbg interface). Tested on a HPE ProLiant DL120 Gen10 server. Thanks! -- Jiri Bohac SUSE Labs, Prague, Czechia

pstore: fix compression

pstore_compress() and decompress_record() use a mistyped config option name ("PSTORE_COMPRESSION" instead of "PSTORE_COMPRESS"). As a result compression and decompressionm of pstore records is always disabled. Use the correct config option name. Signed-off-b

Re: [PATCH v2] kexec: Do not verify the signature without the lockdown or mandatory signature

> Signed-off-by: Lianbo Jiang Reviewed-by: Jiri Bohac -- Jiri Bohac SUSE Labs, Prague, Czechia

Re: [PATCH] kexec: Do not verify the signature without the lockdown or mandatory signature

; */ > if (!ima_appraise_signature(READING_KEXEC_IMAGE) && > security_locked_down(LOCKDOWN_KEXEC)) > return -EPERM; > > pr_debug("kernel signature verification failed (%d).\n", ret); > } > > return 0; > } Looks good to me, thanks! -- Jiri Bohac SUSE Labs, Prague, Czechia

Re: [PATCH] kexec: Do not verify the signature without the lockdown or mandatory signature

n case verification is not enforced and the failure is ignored, KERN_DEBUG seems reasonable. Regards, -- Jiri Bohac SUSE Labs, Prague, Czechia

Re: [PATCH v5] x86/gart/kcore: Exclude GART aperture from kcore

On Fri, Mar 08, 2019 at 11:05:08AM +0800, Kairui Song wrote: > Suggested-by: Baoquan He > Signed-off-by: Kairui Song Reviewed-by: Jiri Bohac Thanks, -- Jiri Bohac SUSE Labs, Prague, Czechia

Re: [PATCH v4] x86/gart/kcore: Exclude GART aperture from kcore

drop the unregister function. Otherwise the patch looks good to me. -- Jiri Bohac SUSE Labs, Prague, Czechia

Re: [PATCH v3] x86/gart/kcore: Exclude GART aperture from kcore

54fc8d19dae ("proc/kcore: optimize multiple page reads") broke this and once fixed, this KCORE_NORAM approach will work. Omar? Regards, -- Jiri Bohac SUSE Labs, Prague, Czechia

Re: [PATCH 1/1] x86/gart/kcore: Exclude GART aperture from kcore

erture from vmcore"),' > as the hook function, but rename to gart_mem_pfn_is_ram as now it's > for a more generic use. > > Suggested-by: Baoquan He > Signed-off-by: Kairui Song Reviewed-by: Jiri Bohac > --- > arch/x86/kernel/aperture_64.c | 6 -- >

Re: [PATCH 08/30] kexec_file: Restrict at runtime if the kernel is locked down

FY_SIG is not enabled, kernel should not load images > through s/KEXEC_VERIFY_SIG/KEXEC_SIG/ Again, my mistake :/ Other than that, looks OK. Much cleaner than my version. Thanks! Reviewed-by: Jiri Bohac -- Jiri Bohac SUSE Labs, Prague, Czechia

Re: [PATCH 08/30] kexec_file: Restrict at runtime if the kernel is locked down

s a preparatory patch for kexec_file_load() lockdown. A locked down > kernel needs to prevent unsigned kernel images to be loaded with s/to be loaded/from being loaded/ (my own mistake :-)) Otherwise looks good. Thanks for improving my idea. Reviewed-by: Jiri Bohac -- Jiri Bohac SUSE Labs, Prague, Czechia

Re: [PATCH 04/30] Enforce module signatures if the kernel is locked down

;t check for key expiry as the RTC might not be > valid or might not have been transferred to the kernel's clock yet. Looks good. Reviewed-by: Jiri Bohac -- Jiri Bohac SUSE Labs, Prague, Czechia

Re: [PATCH 08a/30] kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE

On Wed, Jan 17, 2018 at 04:34:24PM +, David Howells wrote: > Jiri Bohac wrote: > > > > If sig_err is -EKEYREJECTED, -EKEYEXPIRED or -EKEYREVOKED then it must > > > fail, > > > even if the signature check isn't forced. > > > > It wasn'

Re: [PATCH 08a/30] kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE

EY and other errors when it's so easy for the caller to strip the invalid signature. And why kexec_file_load should do the same. What am I missing? Thanks, -- Jiri Bohac SUSE Labs, Prague, Czechia

Re: [PATCH 08/30] kexec_file: Restrict at runtime if the kernel is locked down

atures when you can load unsigned modules is futile. But with your original patchset, that's exactly what distro kernels will be doing when booted with secureboot off, MODULE_SIG_FORCE=n and KEXEC_VERIFY_SIG=y. Thanks, -- Jiri Bohac SUSE Labs, Prague, Czechia

[tip:x86/mm] x86/gart: Exclude GART aperture from vmcore

Commit-ID: 2a3e83c6f96c513f43ce5a8c9034608ea584a255 Gitweb: https://git.kernel.org/tip/2a3e83c6f96c513f43ce5a8c9034608ea584a255 Author: Jiri Bohac AuthorDate: Sat, 6 Jan 2018 02:00:13 +0100 Committer: Thomas Gleixner CommitDate: Thu, 11 Jan 2018 15:09:24 +0100 x86/gart: Exclude GART

[PATCH 08b/30] kexec_file: Restrict at runtime if the kernel is locked down

When KEXEC_VERIFY_SIG is not enabled, kernel should not load images through kexec_file systemcall if the kernel is locked down unless IMA can be used to validate the image. Signed-off-by: Jiri Bohac diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c --- a/kernel/kexec_file.c +++ b/kernel

[PATCH 08a/30] kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE

signature. Signed-off-by: Jiri Bohac diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 8eed3f94bfc7..f25facb0df96 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1951,20 +1951,28 @@ config KEXEC_FILE for kernel and initramfs as opposed to list of segments as

Re: [PATCH 08/30] kexec_file: Restrict at runtime if the kernel is locked down

[PATCH 08b/30] kexec_file: Restrict at runtime if the kernel is locked down Lockdown would not require KEXEC_SIG_FORCE but when enabled it would check the signature. Thanks, -- Jiri Bohac SUSE Labs, Prague, Czechia

Re: [PATCH v2] x86/kexec: Exclude GART aperture from vmcore

checks the return value. Now that we have more than one user, I added a WARN_ON just in case agp, XEN, or any other future user of register_oldmem_pfn_is_ram were to step on each other's toes. Signed-off-by: Jiri Bohac Fixes: 707d4eefbdb3 ("Revert [PATCH] Insert GART region into reso

Re: [PATCH v2] x86/kexec: Exclude GART aperture from vmcore

I have a machine right here in our lab that has this issue. It has no "enable GART" setting in BIOS. It has a "enable IOMMU" setting. The bug stays there regardless of the setting. It's old. Noone will fix the firmware. The patch fixes it. Thanks, -- Jiri Bohac SUSE Labs, Prague, Czechia

[PATCH v2] x86/kexec: Exclude GART aperture from vmcore

other future user of register_oldmem_pfn_is_ram were to step on each other's toes. Signed-off-by: Jiri Bohac Fixes: 707d4eefbdb3 ("Revert [PATCH] Insert GART region into resource map") diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c index f5d92bc3b884..837efa

[PATCH] x86_64: use HPET in 64-bit mode to avoid a harware 32-bit wraparound bug

formance penalty as a single read would require three 32-bit HPET accesses). Signed-off-by: Jiri Bohac diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c index 8ce4212e2b8d..1a500220d0dc 100644 --- a/arch/x86/kernel/hpet.c +++ b/arch/x86/kernel/hpet.c @@ -69,6 +69,31 @@ static inl

Re: [PATCH] x86/kexec: Exclude GART aperture from vmcore

On Wed, Nov 29, 2017 at 10:43:07AM +0800, Baoquan He wrote: > On 11/28/17 at 10:58pm, Jiri Bohac wrote: > > On Sun, Nov 12, 2017 at 04:04:26PM +0800, Baoquan He wrote: > > > Solution: > > > 1) Remove the code which support GART IOMMU when it's not enabled in >

Re: [PATCH] x86/kexec: Exclude GART aperture from vmcore

e visible in /proc/iomem but would allow other resources to be requested even when overlapping the region of this special resource? This way, we could insert the "GART" resource when allocating the hole but later, when an actual AGP driver requests the range during PCI enumeration, the "GART" resource would be overwrtiten by the actual PCI resource. -- Jiri Bohac SUSE Labs, Prague, Czechia

Re: [PATCH] x86/kexec: Exclude GART aperture from vmcore

On Tue, Nov 07, 2017 at 02:42:12PM +0100, Jiri Bohac wrote: > On Tue, Nov 07, 2017 at 07:39:56PM +0800, Baoquan He wrote: > > don't worry about the user space kexec utility either. > > What's the problem with the userspace kexec? The bug is in > reading /proc/vmcore

Re: [PATCH] x86/kexec: Exclude GART aperture from vmcore

roc/vmcore by makedumpfile. kexec would only operate within the preallocated crashkernel area, right? Regards, -- Jiri Bohac SUSE Labs, Prague, Czechia

Re: [PATCH] x86/kexec: Exclude GART aperture from vmcore

4e0274000-4e03c8fff : Kernel bss 83100-8374f : Crash kernel Sorry for the confusion! -- Jiri Bohac SUSE Labs, Prague, Czechia

Re: [PATCH] x86/kexec: Exclude GART aperture from vmcore

Hi Baoquan, On Mon, Nov 06, 2017 at 10:41:43AM +0800, Baoquan He wrote: > Is this reproduced on a machine with GART existing and passing test with > this patch applied? Do you have a /proc/iomem printing about the machine > you are testing on? I've seen this on at least three different machines.

[PATCH] x86/kexec: Exclude GART aperture from vmcore

634920 to exclude the region from /proc/vmcore. Passing the information via an iomem_resource (or by reserving the range in the e820, which would propagate into an iomem_resource) would reintroduce bko#72201. Signed-off-by: Jiri Bohac Fixes: 707d4eefbdb3 ("Revert [PATCH] Insert GART region into re

[tip:x86/boot] x86/debug: Extend the lower bound of crash kernel low reservations

Commit-ID: fe2d48b805d01e14ddb8144de01de43171eb516f Gitweb: http://git.kernel.org/tip/fe2d48b805d01e14ddb8144de01de43171eb516f Author: Jiri Bohac AuthorDate: Fri, 16 Jun 2017 18:16:02 +0200 Committer: Ingo Molnar CommitDate: Thu, 22 Jun 2017 11:10:23 +0200 x86/debug: Extend the lower

[PATCH] x86: fix lower bound of crash kernel low reservation

tries to find a block of low_size bytes. But there seems to be no good reason to restrict the lower bound of the range to low_size. Make memblock_find_in_range search from the start of memory. Signed-off-by: Jiri Bohac --- diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index

Re: [PATCH 1/2] kernel, timekeeping, add trylock option to ktime_get_with_offset()

tk_deferred when holding timekeeping seqlock). So directly calling ktime_get() from printk would just turn a rare deadlock into a certain one - perhaps a good thing? -- Jiri Bohac SUSE Labs, SUSE CZ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in th

Re: [RFC][PATCH 3/4] ntp: Use printk_deferred in leapsecond path

cond_overflow() is called from accumulate_nsecs_to_secs(). accumulate_nsecs_to_secs() is called from update_wall_time() - once directly - once via logarithmic_accumulation() Both calls are before write_seqcount_begin(&tk_core.seq). So it looks safe to use printk there. Regards, -- Jiri Bohac SUS

running hrtimer_start on an already active hrtimer?

enqueue_hrtimer() raw_spin_lock(&cpu_base->lock); ... BUG_ON(timer->state != HRTIMER_STATE_CALLBACK); // state has HRTIMER_STATE_ENQUEUED set Should __hrtimer_start_range_ns() do something like hrtimer_cancel - i.e. explicitly check for ... HRTIMER_STATE_CALLBACK? Thanks, -- Jiri

Re: [PATCH] time, ntp: Do not update time_state in middle of leap second [v3]

On Fri, Feb 20, 2015 at 09:15:23AM -0500, Prarit Bhargava wrote: > On 02/19/2015 12:00 PM, Jiri Bohac wrote: > > Prarit, can you explain who sets the STA_PLL flag, so that > > process_adj_status() detects a STA_PLL->!STA_PLL transition and > > goes to the branch that s

Re: [PATCH] time, ntp: Do not update time_state in middle of leap second [v3]

the state machine will transition from TIME_WAIT to TIME_OK and your test program will set STA_INS again (fighting with ntpd which will clear the flag from time to time) ... right? Thanks, -- Jiri Bohac SUSE Labs, SUSE CZ -- To unsubscribe from this list: send the line "unsubscribe linux-

Re: [PATCH] time, ntp: Do not update time_state in middle of leap second [v3]

On Wed, Feb 18, 2015 at 06:14:04PM +0100, Jiri Bohac wrote: > I think the only real problem occurs when the adjtimex is called in the > the TIME_OOP state ... or the TIME_WAIT state ... > with STA_PLL cleared _and_ STA_INS set. > In this case the state machine is reset to TIME

Re: [PATCH] time, ntp: Do not update time_state in middle of leap second [v3]

OK to TIME_INS/TIME_DEL anyway. I think the "time_status = TIME_OK" should be just dropped. It has been added by eea83d896e318bda54be2d2770d2c5d6668d11db (ntp: NTP4 user space bits update) and it's not clear why. Roman? -- Jiri Bohac SUSE Labs, SUSE CZ -- To unsubscribe

[tip:timers/urgent] timer: Prevent overflow in apply_slack

Commit-ID: 98a01e779f3c66b0b11cd7e64d531c0e41c95762 Gitweb: http://git.kernel.org/tip/98a01e779f3c66b0b11cd7e64d531c0e41c95762 Author: Jiri Bohac AuthorDate: Fri, 18 Apr 2014 17:23:11 +0200 Committer: Thomas Gleixner CommitDate: Wed, 30 Apr 2014 13:46:17 +0200 timer: Prevent overflow

Re: [PATCH v3] timer: prevent overflow in apply_slack

imer fires immediately. Signed-off-by: Jiri Bohac Suggested-by: Deborah Townsend diff --git a/kernel/timer.c b/kernel/timer.c index 87bd529..4c36c91 100644 --- a/kernel/timer.c +++ b/kernel/timer.c @@ -838,7 +838,7 @@ unsigned long apply_slack(struct timer_list *timer, unsigned long expire

Re: [PATCH v2] timer: prevent overflow in apply_slack

Thomas, does this make sense now, with the new description? On Fri, Apr 18, 2014 at 05:23:11PM +0200, Jiri Bohac wrote: > On architectures with sizeof(int) < sizeof (long), the > computation of mask inside apply_slack() can be undefined if the > computed bit is > 32. > &g

[PATCH v2] timer: prevent overflow in apply_slack

sk becomes 1 and and the slack is not applied properly. On s390, mask is -1, expires is set to 0 and the timer fires immediately. Signed-off-by: Jiri Bohac Suggested-by: Deborah Townsend diff --git a/kernel/timer.c b/kernel/timer.c index 87bd529..4c36c91 100644 --- a/kernel/timer.c +++ b/ke

[PATCH] timer: prevent overflow in apply_slack

Prevent overflow in the computation of timer expiry time inside apply_slack(). Signed-off-by: Jiri Bohac Suggested-by: Deborah Townsend diff --git a/kernel/timer.c b/kernel/timer.c index 87bd529..4c36c91 100644 --- a/kernel/timer.c +++ b/kernel/timer.c @@ -838,7 +838,7 @@ unsigned long

Re: is printk() safe within a timekeeper_seq write section?

keeping: Shorten seq_count region). write_seqcount_begin(&timekeeper_seq) is now done after the accumulate_nsecs_to_secs(tk) from where the printks are called. Regards, -- Jiri Bohac SUSE Labs, SUSE CZ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body

is printk() safe within a timekeeper_seq write section?

less loop on read_seqcount_retry(&timekeeper_seq, ...) It looks like an unlikely but possible deadlock. Or did I overlook something? Thanks! -- Jiri Bohac SUSE Labs, SUSE CZ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" i

Re: [PATCH][RFC] specific do_timer_cpu value for nohz off mode

see a good reason assign tick_do_timer_cpu to the CPU doing the one-shot timer broadcasts. The timer interrupt will be generated on any other CPU as well, be it through the broadcast IPI or a per-CPU clockevent device. Any online CPU can do that job, so how about just dropping the assignment? The

Re: [PATCH 0/6] Fix for leapsecond caused hrtimer/futex issue (updated)

Or do you plan backporting the most recent version to 2.6.32? Thanks, -- Jiri Bohac SUSE Labs, SUSE CZ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

[RFC][PATCH] fix abs() macro to work with types wider than int

abs(x) ({ \ - int __x = (x); \ + typeof(x) __x = (x);\ (__x < 0) ? -__x : __x; \ }) -- Jiri Bohac <[EMAIL PROTECTED]> SUSE Labs, SUSE CZ - To unsubscribe from this list: send the line "unsubscribe

Re: [patch 1/9] Fix HPET init race

ger) - /* do nothing */ ; - while (hpet_readl(HPET_COUNTER) < trigger) + u32 trigger; + do + trigger = hpet_readl(HPET_T0_CMP); + while (hpet_readl(HPET_COUNTER) >= trigger); + + while (hpet_

Re: [patch 0/9] x86_64: reliable TSC-based gettimeofday

d to be monotonic, but it should be pretty close. Currently, we > >get errors of tens/hundreds of microseconds. > > I think a better way to do this would be to define a new > CLOCK_THREAD_MONOTONOUS > (or better name) timer for clock_gettime(). I absolutely agree. Will do that. This

Re: [patch 9/9] Make use of the Master Timer

do_vgettimeofday(tv, tsc, cpu); > > + > > + } while (read_seqretry(&__xtime_lock, seq)); > > + break; > > + default: > > + do_syscall = 1; &g

Re: [patch 2/9] Remove the support for the VXTIME_PMTMR timer mode

On Thu, Feb 01, 2007 at 02:13:00PM +0100, Andi Kleen wrote: > On Thursday 01 February 2007 14:13, Jiri Bohac wrote: > > On Thu, Feb 01, 2007 at 12:13:31PM +0100, Andi Kleen wrote: > > > On Thursday 01 February 2007 10:59, [EMAIL PROTECTED] wrote: > > > > VXTIME_PM

Re: [patch 8/9] Add time_update_mt_guess()

and a downshift at once. The problem is, that if we first do the multipclication, the result won't fit in 64 bits. If we first do the downshift, we lose precision. This does both operations at once, avoiding both the overflow and underflow. -- Jiri Bohac <[EMAIL PROTECTED]> SUSE Labs,

Re: [patch 7/9] Adapt the time initialization code

make too many unrelated changes in one patchset. It doesn't matter that much in this case that it probably is wrong (as the comment explains)... -- Jiri Bohac <[EMAIL PROTECTED]> SUSE Labs, SUSE CZ - To unsubscribe from this list: send the line "unsubscribe linux-kernel&q

Re: [patch 6/9] Add the "Master Timer"

r that the variables should not be used directly. They should only be accessed through the get_master_timer(), set_master_timer64(), etc. funcitions. Something wrong with that? I have no problem deleting the underscores :-) -- Jiri Bohac <[EMAIL PROTECTED]> SUSE Labs, SUSE CZ - To unsubsc

Re: [patch 4/9] Remove the TSC synchronization on SMP machines

TSCs are synchronized. That's why I think the synchronization code is not needed. -- Jiri Bohac <[EMAIL PROTECTED]> SUSE Labs, SUSE CZ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo inf

Re: [patch 2/9] Remove the support for the VXTIME_PMTMR timer mode

> > A little risky. No, either HPET or PM Timer will become the Master Timer (elected on boot). Master timer is just an abstraction of these, so the rest of the timekeeping code needn't care which hardware timer is being used. That's why the VXTIME_PMTMR mode is not needed. --

[PATCH for 2.6.19] Fix xtime losing ticks

xtime is not properly incremented when main timer ticks are lost. Whatever the number of ticks elapsed is, only one tick worth of time is added to xtime. This patch fixes that. Signed-off-by: Jiri Bohac <[EMAIL PROTECTED]> Index: linux-2.6.19-rc5/kernel/t