On Wed, Nov 01, 2017 at 05:47:54PM +0100, Borislav Petkov wrote:
> On Wed, Nov 01, 2017 at 07:56:20AM -0700, Laura Abbott wrote:
> > Did these get queued up somewhere? I know last week was OSSEU/Ksummit
> > so people may still be playing catch-up.
>
> Ah, thanks for the reminder.
>
> /me goes and
On Wed, Nov 01, 2017 at 07:56:20AM -0700, Laura Abbott wrote:
> Did these get queued up somewhere? I know last week was OSSEU/Ksummit
> so people may still be playing catch-up.
Ah, thanks for the reminder.
/me goes and dusts it off.
Ok, here it is, injecting some MCEs in a guest seems to work fi
On 10/16/2017 11:28 AM, Luck, Tony wrote:
> On Sun, Oct 15, 2017 at 11:40:46AM +0200, Borislav Petkov wrote:
>> On Wed, Oct 11, 2017 at 09:34:22PM +, Luck, Tony wrote:
here's a second attempt at a more rigorous simplification: RCU stuff is
gone and only a single loop scans through the
On Sun, Oct 15, 2017 at 11:40:46AM +0200, Borislav Petkov wrote:
> On Wed, Oct 11, 2017 at 09:34:22PM +, Luck, Tony wrote:
> > > here's a second attempt at a more rigorous simplification: RCU stuff is
> > > gone and only a single loop scans through the elements.
> >
> > The dev_mce_log() chang
On Wed, Oct 11, 2017 at 09:34:22PM +, Luck, Tony wrote:
> > here's a second attempt at a more rigorous simplification: RCU stuff is
> > gone and only a single loop scans through the elements.
>
> The dev_mce_log() changes look good now.
>
> You can apply the axe to more bits of mce_chrdev_rea
On Thu, Oct 12, 2017 at 11:02:52AM +0200, Borislav Petkov wrote:
> On Wed, Oct 11, 2017 at 04:11:37PM -0700, Andi Kleen wrote:
> > Sorry I take back what I wrote earlier. This RCU is actually still needed,
> > otherwise the reader could see partially written entries.
>
> Why? All the readers and w
On Wed, Oct 11, 2017 at 04:11:37PM -0700, Andi Kleen wrote:
> Sorry I take back what I wrote earlier. This RCU is actually still needed,
> otherwise the reader could see partially written entries.
Why? All the readers and writers take the mutex now.
--
Regards/Gruss,
Boris.
Good mailing pra
> - next = mce_log_get_idx_check(mcelog.next);
> + next = mcelog.next;
>
> /* Only supports full reads right now */
> err = -EINVAL;
> @@ -281,8 +266,6 @@ static ssize_t mce_chrdev_read(struct file *filp, char
> __user *ubuf,
> next = cmpxchg(&mcelog.next, prev,
> here's a second attempt at a more rigorous simplification: RCU stuff is
> gone and only a single loop scans through the elements.
The dev_mce_log() changes look good now.
You can apply the axe to more bits of mce_chrdev_read() though. Like that
while (!m->finished) {
we hold the mutex
Ok,
here's a second attempt at a more rigorous simplification: RCU stuff is
gone and only a single loop scans through the elements.
---
diff --git a/arch/x86/kernel/cpu/mcheck/dev-mcelog.c
b/arch/x86/kernel/cpu/mcheck/dev-mcelog.c
index 10cec43aac38..1e1c6d22c93e 100644
--- a/arch/x86/kernel/cpu
"Luck, Tony" writes:
>> for (;;) {
>> entry = mce_log_get_idx_check(mcelog.next);
>
> Can't this get even simpler? Do we need the loop? The mutex
> will now protect us while we check to see if there is a slot
> to stash this new entry. Also just say:
IMHO the warning is just bo
> for (;;) {
> entry = mce_log_get_idx_check(mcelog.next);
Can't this get even simpler? Do we need the loop? The mutex
will now protect us while we check to see if there is a slot
to stash this new entry. Also just say:
entry = mcelog.next;
> for
On Tue, Oct 10, 2017 at 03:00:09PM -0400, Jeremy Cline wrote:
> Hello,
>
> A Fedora user has reported an issue about suspicious RCU usage in
> dev-mcelog. It looks like perhaps the notifier call chain is not
> acquiring the mce_chrdev_read_mutex? The traceback is
>
> [36915.633804] ==
13 matches
Mail list logo
