is used, so when the hook is disabled (by default), this adds
only a NOP to the core functions, with zero performance penalty.
This is the first step towards the goal of emulating h/w events.
Signed-off-by: Rui Wang rui.y.w...@intel.com
---
arch/x86/Kconfig |7 +
arch/x86/boot
zero.
I tested the performance by repeatedly running lspci, which calls into the
pci access functions. There's no added overhead observed.
Regards,
Rui Wang
Intel Open Source Technology Center
Rui Wang (3):
IO Hook: core functions and Register Override
IO Hook: kernel interface to manage
Documentation/PCI/iohook.txt for usage details.
Signed-off-by: Rui Wang rui.y.w...@intel.com
---
Documentation/PCI/iohook.txt | 290
drivers/misc/Kconfig |1 +
drivers/misc/Makefile|1 +
drivers/misc/iohook/Kconfig |5 +
drivers/misc/iohook/Makefile
-off-by: Rui Wang rui.y.w...@intel.com
---
drivers/pci/access.c | 150 ++
include/linux/reg_ovrd.h |9 +++
2 files changed, 159 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/access.c b/drivers/pci/access.c
index fe7b282..81428655 100644
.
Yes building it statically in the kernel would be cleaner and easier
to use. I'll roll out a new version for you to review.
Thanks
Rui
I tested the performance by repeatedly running lspci, which calls into
the
pci access functions. There's no added overhead observed.
Regards,
Rui Wang
On 8/22/13, rui wang ruiv.w...@gmail.com wrote:
On 8/11/13, Yinghai Lu ying...@kernel.org wrote:
Some ioapic controllers do not show up on pci config space,
or pci device is there but no bar is used and is set by firmware in
other non standard registers.
We can get ioapic address from
On 8/11/13, Yinghai Lu ying...@kernel.org wrote:
During ioapic hotplug, acpi_register_ioapic will be called.
Now for x86, that function is blank.
Fill that will update __mp_register_ioapic to use those ioapic.
Signed-off-by: Yinghai Lu ying...@kernel.org
---
arch/x86/kernel/acpi/boot.c |
On 8/27/13, Yinghai Lu ying...@kernel.org wrote:
On Fri, Aug 23, 2013 at 5:51 PM, rui wang ruiv.w...@gmail.com wrote:
On 8/11/13, Yinghai Lu ying...@kernel.org wrote:
During ioapic hotplug, acpi_register_ioapic will be called.
Now for x86, that function is blank.
Fill that will update
On 8/27/13, Yinghai Lu ying...@kernel.org wrote:
On Mon, Aug 26, 2013 at 11:44 PM, rui wang ruiv.w...@gmail.com wrote:
On 8/27/13, Yinghai Lu ying...@kernel.org wrote:
On Fri, Aug 23, 2013 at 5:51 PM, rui wang ruiv.w...@gmail.com wrote:
On 8/11/13, Yinghai Lu ying...@kernel.org wrote:
During
From: Rui Wang rui.y.w...@intel.com
Date: Tue, 27 Aug 2013 11:23:43 -0400
Subject: [PATCH] Hotadd of IOAPICs described in static MADT
For IOAPICs described in static MADT, we already called __mp_register_ioapic()
in arch_early_irq_init(). During boot PCI root hotadd will call it again and
will find
FWIW, I'm using my I/O Hook (http://lwn.net/Articles/561359/) as a
tool to test yinghai's IOAPIC patchset. It can be used to test any
kind of hotplug.
For people who don't yet have full hardware support and want to test
the hotplug of IOAPIC, CPU, Memory, IOH, PCIe root, etc., it is an
ideal
On 8/28/13, Yinghai Lu ying...@kernel.org wrote:
On Tue, Aug 27, 2013 at 3:25 AM, rui wang ruiv.w...@gmail.com wrote:
On 8/11/13, Yinghai Lu ying...@kernel.org wrote:
We need to have ioapic setup before normal pci drivers.
otherwise other pci driver can not setup irq.
So we should not treat
On 8/11/13, Yinghai Lu ying...@kernel.org wrote:
Some ioapic controllers do not show up on pci config space,
or pci device is there but no bar is used and is set by firmware in
other non standard registers.
We can get ioapic address from ACPI0009's _CRS.
Signed-off-by: Yinghai Lu
On 8/15/13, Bjorn Helgaas bhelg...@google.com wrote:
On Thu, Aug 8, 2013 at 2:09 PM, Alex Williamson
snip
I don't think this is hotplug-safe. It looks like pci_bus_sem might
be the right semaphore to hold while verifying that we won't reset any
unintended devices.
Something like pci_bus_sem
used to generate ACPI events, PCI interrupts, PCIe
AER injection etc., and can thus be used to help test RAS features like
the hotplug of CPU/MEM/IOH on machines that are not capable of generating
the events.
See Documentation/PCI/iohook.txt for usage details.
Signed-off-by: Rui Wang rui.y.w
Add the following kernel functions used to add/delete/query Register
Overrides, and to start/stop the I/O Hook:
hook_add_ovrd
hook_query_ovrd
hook_cleanup_ovrd
hook_start_ovrd
hook_stop_ovrd
hook_get_status
Signed-off-by: Rui Wang rui.y.w
this new version on Westmere-EX. It worked as expected.
Regards,
Rui Wang
Intel Open Source Technology Center
Rui Wang (3):
I/O Hook: core functions and Register Override
I/O Hook: kernel interface to manage the hook
I/O Hook: sysfs interface to emulate h/w events
Documentation/PCI/iohook.txt
is used, so when the hook is disabled (by default), this adds
only a NOP to the core functions, with zero performance penalty.
This is the first step towards the goal of emulating h/w events.
Signed-off-by: Rui Wang rui.y.w...@intel.com
---
arch/Kconfig | 10 +
arch/x86/boot
one is the standard? Is there a plan to unify all these names?
Thanks
Rui Wang
+
+#endif /* _TRACE_AER_H */
+
+/* This part must be outside protection */
+#include trace/define_trace.h
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
cpu
requires a new vector slot.
Rui Wang
/* A cpu has been removed from cpu_online_mask. Reset irq affinities. */
void fixup_irqs(void)
{
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 6cacab6..6d991d1 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86
1
#define AER_CORRECTABLE 2
So which one is the standard? Is there a plan to unify all these names?
Thanks
Rui Wang
+
+#endif /* _TRACE_AER_H */
+
+/* This part must be outside protection */
+#include trace/define_trace.h
--
To unsubscribe from this list: send the line
On 12/5/13, Borislav Petkov b...@alien8.de wrote:
Yes, the AER tracepoint above should use the AER_* defines and not the
HW_EVENT_ERR_* ones which are for memory errors.
Wanna send a fix?
Yes. Does it translate into something like this?
From: Rui Wang rui.y.w...@intel.com
Date: Fri, 6 Dec
On 12/19/13, Prarit Bhargava pra...@redhat.com wrote:
On 12/03/2013 09:48 PM, rui wang wrote:
On 11/20/13, Prarit Bhargava pra...@redhat.com wrote:
Have you considered the case when an IRQ is destined to more than one CPU?
e.g.:
bash# cat /proc/irq/89/smp_affinity_list
30,62
bash
On 12/29/13, Prarit Bhargava pra...@redhat.com wrote:
On 12/20/2013 04:41 AM, rui wang wrote:
snip
The vector number for an irq is programmed in the LSB of the IOAPIC
IRTE (or MSI data register in the case of MSI/MSIx). So there can be
only one vector number (although multiple CPUs can
On 12/30/13, Prarit Bhargava pra...@redhat.com wrote:
On 12/30/2013 07:56 AM, rui wang wrote:
An irq can be mapped to only one vector number, but can have multiple
destination CPUs. i.e. the same irq/vector can appear on multiple
CPUs' vector_irq[]. So checking data-affinity is necessary I
On 12/29/13, Prarit Bhargava pra...@redhat.com wrote:
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64831
When downing a cpu it is possible that there are unhandled irqs left in
the APIC IRR register. The following code path shows how the problem
can occur:
1. CPU 5 is to go down.
;
for_each_online_cpu(cpu) {
- if (per_cpu(vector_irq, cpu)[vector] != -1)
+ if (per_cpu(vector_irq, cpu)[vector] VECTOR_UNDEFINED)
return 1;
}
--
1.7.9.3
If it precisely catches the remaining IRR, then it is something good to have.
Reviewed-by: Rui
because info-severity is assigned in
aer_isr_one_error() using the definitions in include/linux/ras.h:
Signed-off-by: Rui Wang rui.y.w...@intel.com
---
include/trace/events/ras.h | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/trace/events/ras.h b/include/trace
and a negative number denotes a vector, thus
bash# echo -18 irq
specifies that a machine check exception (int 18) will be triggered.
Signed-off-by: Rui Wang rui.y.w...@intel.com
---
Documentation/PCI/iohook.txt | 31 ++--
arch/x86/include/asm/msr.h | 100
...12.478001: iohook_event: write(0x38302034,
0x4) == 0x0
...
Signed-off-by: Rui Wang rui.y.w...@intel.com
---
Documentation/PCI/iohook.txt | 54 +++-
drivers/misc/iohook/iohook.c | 319 +++--
include/trace/events/iohook.h | 58
3 files changed
to trace h/w access. A new
attribute 'tc' can be defined for any Register Override for tracing
purpose.
Rui Wang (5):
I/O Hook: core functions and Register Override
I/O Hook: Help functions to manage the hook
I/O Hook: sysfs interface to emulate h/w events
I/O Hook: Override
Add the following kernel helper functions used to add/delete/query Register
Overrides, and to start/stop the I/O Hook:
iohook_add_ovrd
iohook_query_ovrd
iohook_cleanup_ovrd
iohook_start_ovrd
iohook_stop_ovrd
iohook_get_status
Signed-off-by: Rui Wang
used to generate ACPI events, PCI interrupts, PCIe
AER injection etc., and can thus be used to help test RAS features like
the hotplug of CPU/MEM/IOH on machines that are not capable of generating
the events.
See Documentation/PCI/iohook.txt for usage details.
Signed-off-by: Rui Wang rui.y.w
, etc., similar to how a hardware register behaves when accessed.
Jump Label is used, so when the hook is disabled (by default), this adds
only a NOP to the core functions, with zero performance penalty.
This patch is the first step towards the goal of emulating h/w events.
Signed-off-by: Rui Wang
On 12/20/13, Prarit Bhargava pra...@redhat.com wrote:
On 12/19/2013 01:05 PM, Tony Luck wrote:
On Wed, Dec 18, 2013 at 11:50 AM, Tony Luck tony.l...@intel.com wrote:
Looks good to me.
Though now I've been confused by an offline question about affinity.
Heh :) I'm pursuing it now. Rui
On 12/2/13, Prarit Bhargava pra...@redhat.com wrote:
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64831
When downing a cpu it is possible that there are unhandled irqs left in
the APIC IRR register. fixup_irqs() goes through the IRR and retriggers
the IRQs left in the APIC IRR.
On 12/23/13, Prarit Bhargava pra...@redhat.com wrote:
On 12/23/2013 04:41 AM, rui wang wrote:
On 12/2/13, Prarit Bhargava pra...@redhat.com wrote:
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64831
When downing a cpu it is possible that there are unhandled irqs left in
the APIC
On 12/24/13, Prarit Bhargava pra...@redhat.com wrote:
On 12/23/2013 11:41 PM, rui wang wrote:
On 12/23/13, Prarit Bhargava pra...@redhat.com wrote:
I think I have root caused this to the IRR being set in the down'd cpu.
It
is
admittedly a rare occurrence in the kernel. I usually have
On 11/20/14, Borislav Petkov b...@alien8.de wrote:
On Wed, Nov 19, 2014 at 11:34:10PM +, Luck, Tony wrote:
The SDM has this to say about EN=0 (in section 15.10.4.1 of volume 3B):
When the EN flag is zero but the VAL and UC flags are one in
the IA32_MCi_STATUS register, the reported
On 11/22/14, Borislav Petkov b...@alien8.de wrote:
... there are two possibilities:
* error got logged into mcelog and is long out to dmesg.
So we go look at dmesg. Not very easy to do when we panic, I know, so we
better make sure we have serial connected.
[ Btw., we can know when
On 11/22/14, Borislav Petkov b...@alien8.de wrote:
On Sat, Nov 22, 2014 at 10:16:49AM +0800, rui wang wrote:
I think both possibilities are valid. But experiments show that the
error logs are not in the dmesg preserved by kdump in /var/crash/
after panic and reboot, and not in the mcelog.entry
--
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/
Hi all,
When a machine check panics while the kdump service isn't loaded (e.g.
due to insufficient disk space), we see an infinite stream of error
messages on the console, repeatedly, like this (The machine can never
reboot):
[ 82.733050] bad: scheduling from the idle thread!
[ 82.738304]
On 12/4/14, Borislav Petkov b...@alien8.de wrote:
On Wed, Dec 03, 2014 at 05:11:49PM +0800, rui wang wrote:
The problem is because kdump fails to load a new kernel, and we're
executing past crash_kexec() in panic(). And it calls
bust_spinlocks(0) which calls into the GPU driver trying
ruiv.w...@gmail.com wrote:
From: Rui Wang rui.y.w...@intel.com
There are still some places in the fb helper that need to avoid
sleeping in panic context. Here's an example:
[ 65.615496] bad: scheduling from the idle thread!
[ 65.620747] CPU: 92 PID: 0 Comm: swapper/92 Tainted: G M
...@ffwll.ch, tony.l...@intel.com,
b...@alien8.de, a...@redhat.com, rui.y.w...@intel.com
Cc: linux-kernel@vger.kernel.org
From: Rui Wang rui.y.w...@intel.com
There are still some places in the fb helper that need to avoid
sleeping in panic context. Here's an example:
[ 65.615496] bad: scheduling from
Hi Rob,
Yes it's exactly what I'm doing. Please scroll down and review my patch.
Thanks
Rui
On 12/10/14, Rob Clark robdcl...@gmail.com wrote:
perhaps fb helpers could use __drm_modeset_lock_all() w/ trylock=true
in panic context?
BR,
-R
On Tue, Dec 9, 2014 at 7:09 PM, rui wang ruiv.w
Hi all,
I'm here to report two panics which hang forever (the machine cannot reboot).
It is because mgag200 doesn't work in panic context. It sleeps and allocates
memory non-atomically.
These were triggered while injecting machine checks using einj.
1)
[321381.466885] [ cut here
On Wed, Jun 17, 2015 at 11:41:56AM +0200, Borislav Petkov wrote:
And I was waiting in line to get a chance to do some injection on our
EINJ box here too. But it seems you have the required setup already so
if you want to give those changes a run, I've uploaded them here:
Hi Boris Tony,
While injecting MCEs using einj, I encountered a panic:
[0.305697] mce: CPU supports 22 MCE banks
[0.310288] BUG: unable to handle kernel NULL pointer dereference at
0100
[0.319057] IP:
On Tuesday, June 30, 2015 2:37 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
On Tue, Jun 30, 2015 at 4:53 AM, Rui Wang rui.y.w...@intel.com wrote:
I think testing can be done by injecting a fatal machine check
exception via einj's debugfs interface. I can reproduce the hard hang every
On Tuesday, June 30, 2015 11:24 PM, Daniel Vetter daniel.vet...@ffwll.ch
wrote:
On Tue, Jun 30, 2015 at 9:23 AM, Rui Wang rui.y.w...@intel.com wrote:
But einj does something more than what an IPI can do, it injects hardware
errors which trigger exceptions in NMI context... and the exception
On Monday, June 29, 2015 5:25 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
As long as the display is up and running we should have a fair stab at
showing the oops - it's just that no one has seriously bothered with
the necessary infastructure, automated testing (it won't work
otherwise) and
ve the check early in the function
can fix the problem.
Signed-off-by: Rui Wang <rui.y.w...@intel.com>
---
drivers/gpu/drm/mgag200/mgag200_cursor.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_cursor.c
b/drivers/gpu/drm/mgag200/mgag20
Hi All,
Just found the following bug causing machine hang:
[ 487.777538] BUG: unable to handle kernel NULL pointer dereference at
0060
[ 487.777554] IP: [] _raw_spin_lock+0xe/0x30
[ 487.777557] PGD 42e9f7067 PUD 42f2fa067 PMD 0
[ 487.777560] Oops: 0002 [#1] SMP
...
[ 487.777618]
ort(), and must have a non-
zero statesize.
This patch has been tested with the algif_hash interface. The calculated
digest values, after several rounds of import()s and export()s, match those
calculated by tcrypt.
Signed-off-by: Rui Wang <rui.y.w...@intel.com>
---
arch/x86/crypto/ghash
cryptd_create_hash() fails by returning -EINVAL. It is because after
8996eafdc ("crypto: ahash - ensure statesize is non-zero") all ahash
drivers must have a non-zero statesize.
This patch fixes the problem by properly assigning the statesize.
Signed-off-by: Rui Wang <rui.y.w
ghash_clmulni_intel fails to load on Linux 4.3+ with the following message:
"modprobe: ERROR: could not insert 'ghash_clmulni_intel': Invalid argument"
These two patches need to go together, for the driver to load correctly.
Rui Wang (2):
crypto: ghash-clmulni - Fix load failur
74 1b
[ 453.829861] RIP [] release_resource+0x22/0x80
[ 453.837188] RSP
[ 453.841673] CR2: 0030
Fix it by assigning the correct pointers to ioapics[i].iomem_res in
ioapic_setup_resources(). Also simplify the function by removing
the redundant 'num' variable.
Signed-off-by: Ru
-removing ioapics.
On a 4-socket brickland, hot-removal of the 3 sockets can be done
only after applying these two patches.
Regards,
Rui
Rui Wang (2):
Support hot-removal of IOAPICs present during boot
x86/ioapic: Fix wrong pointers in ioapic_setup_resources()
arch/x86/kernel/apic/io_apic.c | 18
IOAPICs present during system boot aren't added to ioapic_list,
thus are unable to be hot-removed. Fix it by calling
acpi_ioapic_add() during root bus enumeration.
Signed-off-by: Rui Wang <rui.y.w...@intel.com>
---
drivers/acpi/internal.h | 2 --
drivers/acpi/ioapic.c | 7 ---
driver
On Tuesday, June 7, 2016 5:17 PM, Thomas Gleixner wrote:
> On Tue, 7 Jun 2016, Rui Wang wrote:
> > Also simplify the function by removing the redundant 'num' variable.
> Please don't do that. This makes the patch hard to read. Split this into a
> minimal bugfix, which ca
v3: Previous versions break mips. This version fixes it.
IOAPICs present during system boot aren't added to ioapic_list,
thus are unable to be hot-removed. Fix it by calling
acpi_ioapic_add() during root bus enumeration.
Signed-off-by: Rui Wang <rui.y.w...@intel.com>
---
drivers/acpi/inte
Optimize the function by removing the variable 'num'.
Signed-off-by: Rui Wang <rui.y.w...@intel.com>
---
arch/x86/kernel/apic/io_apic.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
to Thomas.
Rui Wang (3):
x86/ioapic: Support hot-removal of IOAPICs present during boot
x86/ioapic: Fix wrong pointers in ioapic_setup_resources()
x86/ioapic: Simplify ioapic_setup_resources()
arch/x86/kernel/apic/io_apic.c | 18 +++---
drivers/acpi/internal.h| 2
);
r++;
}
Here r is treated as an arry of struct resource, and the r++ ensures that
each element of the array is inserted separately. Thus we should call
release_resouce() on each element at [num].
Signed-off-by: Rui Wang <rui.y.w...@intel.com>
---
arch/x86/kernel/apic/io_apic
IOAPICs present during system boot aren't added to ioapic_list,
thus are unable to be hot-removed. Fix it by calling
acpi_ioapic_add() during root bus enumeration.
Signed-off-by: Rui Wang <rui.y.w...@intel.com>
---
drivers/acpi/internal.h | 2 --
drivers/acpi/ioapic.c | 7 ---
driver
On Saturday, June 11, 2016 12:43 AM, Bjorn Helgaas wrote:
> On Wed, Jun 08, 2016 at 05:32:44PM +0800, Rui Wang wrote:
> > @@ -1779,8 +1780,12 @@ void __init
> > pci_assign_unassigned_resources(void)
> > {
> > struct pci_bus *root_bus;
> >
> > - li
On Friday, June 17, 2016 1:10 AM, Bjorn Helgaas wrote:
> ioapic_insert_resources() is x86-specific, but I'm not sure why; it seems
> like it does things that should be applicable to ia64 as well.
>
> acpi_ioapic_add() is not x86-specific, and it is called from
> acpi_pci_root_add() for the
-by: Rui Wang <rui.y.w...@intel.com>
---
drivers/acpi/internal.h | 2 --
drivers/acpi/ioapic.c | 7 ---
drivers/acpi/pci_root.c | 13 -
drivers/pci/setup-bus.c | 7 ++-
include/linux/acpi.h| 3 +++
5 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/driver
On Wed, June 22, 2016 10:54 PM Bjorn Helgaas wrote:
> On Wed, Jun 22, 2016 at 03:13:32PM +0800, Rui Wang wrote:
> > On Friday, June 17, 2016 1:10 AM, Bjorn Helgaas wrote:
> > > ioapic_insert_resources() is x86-specific, but I'm not sure why; it
> > > seems like
On Fri, Jun 24, 2016 1:35 AM Bjorn Helgaas wrote:
> On Thu, Jun 23, 2016 at 01:11:41PM +0800, Rui Wang wrote:
> > On Wed, June 22, 2016 11:15 PM Bjorn Helgaas wrote:
> > > [...]
> > > > @@ -1779,8 +1780,12 @@ void __init
> > >
it by calling
acpi_ioapic_add() during root bus enumeration.
Signed-off-by: Rui Wang <rui.y.w...@intel.com>
---
drivers/acpi/internal.h | 2 --
drivers/acpi/ioapic.c | 7 ---
drivers/acpi/pci_root.c | 13 -
drivers/pci/setup-bus.c | 5 -
include/linux/acpi.h
Modify __test_hash() so that hash import/export can be tested
from within the kernel. The test is unconditionally done when
a struct hash_testvec has its .np > 1.
v3: make the test unconditional
v2: Leverage template[i].np as suggested by Tim Chen
Signed-off-by: Rui Wang <rui.y.w...@int
On Monday, February 1, 2016 4:18 PM, Herbert Xu wrote:
>
> On Wed, Jan 27, 2016 at 05:08:35PM +0800, Rui Wang wrote:
>>
>> +static int sha1_mb_async_import(struct ahash_request *req, const void
>> +*in) {
>> +struct ahash_request *mcryptd_req = ahash_re
On Mon, Feb 1, 2016 4:22 PM Herbert Xu wrote:
>
> On Wed, Jan 27, 2016 at 05:08:38PM +0800, Rui Wang wrote:
> >
> > diff --git a/crypto/testmgr.h b/crypto/testmgr.h index
> > da0a8fd..451e7eb 100644
> > --- a/crypto/testmgr.h
> > +++ b/crypto/testmgr.h
>
On Tue, Feb 2, 2016 10:45 PM Herbert Xu wrote:
>
> On Tue, Feb 02, 2016 at 10:16:34PM +0800, Rui Wang wrote:
> >
> > I initially made it unconditional, but then I found that it can easily
> > hang the machine during boot due to any import/export bug in any of
> &g
On Sat, Jan 30, 2016 5:44 PM Konstantin Khlebnikov <koc...@gmail.com> wrote:
> On Fri, Jan 8, 2016 at 6:09 PM, Rui Wang <rui.y.w...@intel.com> wrote:
> ovl_remove_upper() should do d_drop() only after it successfully
> removes the dir, otherwise a subsequent getcwd() sys
sha1_mb.
patch04 adds a test case for import() and export(). A hash algo's
import()/export() can be tested by simply adding .partial = 1 to
its corresponding struct hash_testvec where .np > 1.
v2: Leverage template[i].np in the test case as suggested by Tim Chen.
Rui Wang (4):
crypto x86/sha1
modprobe sha1_mb fails with the following message:
modprobe: ERROR: could not insert 'sha1_mb': No such device
It is because it needs to set its statesize and implement its
import() and export() interface.
Signed-off-by: Rui Wang <rui.y.w...@intel.com>
---
arch/x86/crypto/sha-mb/sha1_mb.
Modify __test_hash() so that hash import/export can be tested
from within the kernel by simply adding .partial = 1 to a hash
algo's struct hash_testvec where .np > 1.
v2: Leverage template[i].np as suggested by Tim Chen
Signed-off-by: Rui Wang <rui.y.w...@intel.com>
---
crypto/testmg
mcryptd_create_hash() fails by returning -EINVAL, causing any
driver using mcryptd to fail to load. It is because it needs
to set its statesize properly.
Signed-off-by: Rui Wang <rui.y.w...@intel.com>
---
crypto/mcryptd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/crypto/mcryp
hash_sendmsg/sendpage() need to wait for the completion
of crypto_ahash_init() otherwise it can cause panic.
Signed-off-by: Rui Wang <rui.y.w...@intel.com>
---
crypto/algif_hash.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/crypto/algif_hash.c b/crypto/algif_
On Wed, July 27, 2016 4:20 AM Bjorn Helgaas wrote:
> On Wed, Jul 27, 2016 at 12:13:14AM +0800, Rui Wang wrote:
> > IOAPICs present during system boot aren't added to ioapic_list, thus
> > are unable to be hot-removed. Fix it by calling
> > acpi_ioapic_add() during
On Wed, July 27, 2016 4:24 AM, Bjorn Helgaas wrote:
> On Wed, Jul 27, 2016 at 12:13:16AM +0800, Rui Wang wrote:
> > ioapic resource at 0xfecx gets lost from /proc/iomem after
> > hot-removing and then hot-adding the ioapic devices.
> >
> > After system boot, i
meat of the change, i.e., the addition of calls
to acpi_ioapic_add()."
* Removed acpi_ioapic_add() as an exported symbol.
* Fixed some typos, and s/acpi/ACPI/, s/ioapic/IOAPIC/ throughout.
* Fixed a warning from 0-day testing.
Rui Wang (5):
x86/ioapic: Change prototype of acpi_ioapic_add()
IOAPICs present during system boot aren't added to ioapic_list,
thus are unable to be hot-removed. Fix it by calling
acpi_ioapic_add() during root bus enumeration.
Signed-off-by: Rui Wang <rui.y.w...@intel.com>
---
drivers/acpi/pci_root.c | 10 ++
drivers/pci/setup-bus.c | 5 ++
Change the argument of acpi_ioapic_add() to a generic ACPI handle, and
move its prototype from drivers/acpi/internal.h to include/linux/acpi.h
so that it can be called from outside the pci_root driver.
Signed-off-by: Rui Wang <rui.y.w...@intel.com>
---
drivers/acpi/internal.h | 2 --
d
nge
appears in "_CRS" of each IOAPIC device. Both ranges should be claimed
from /proc/iomem for exclusive use.
Signed-off-by: Rui Wang <rui.y.w...@intel.com>
---
drivers/acpi/ioapic.c | 36
1 file changed, 20 insertions(+), 16 deletions(-)
diff --g
setup_res() doesn't actually get any resource because it mistakenly
checks the return value of acpi_dev_filter_resource_type(), which
returns 0 on success, and 1 on failure. Fix it by taking the return
value of non-zero as failing to match the specified resource type.
Signed-off-by: Rui Wang
ff). Fix it by using
insert_resource() which can request resources by taking the conflicting
resource as the parent.
Signed-off-by: Rui Wang <rui.y.w...@intel.com>
---
drivers/acpi/ioapic.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/ioapic.c b/d
IOAPICs present during system boot aren't added to ioapic_list,
thus are unable to be hot-removed. Fix it by calling
acpi_ioapic_add() during root bus enumeration.
Signed-off-by: Rui Wang <rui.y.w...@intel.com>
---
drivers/acpi/internal.h | 2 --
drivers/acpi/ioapic.c | 7 ---
d
Hi all,
The 1st patch has been discussed before Bjorn went on vacation. I've fixed
all the issues. Bjorn, please advise how we'll move forward.
The remaining patches fix newly found bugs while testing ioapic hotplug.
Regards,
Rui
Rui Wang (4):
x86/ioapic: Support hot-removal of IOAPICs
ff). Fix it by using
insert_resoure() which can request resources by taking the conflicting
resource as the parent.
Signed-off-by: Rui Wang <rui.y.w...@intel.com>
---
drivers/acpi/ioapic.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/ioapic.c b/d
setup_res() doesn't actually get any resoure because it mistakenly
checks the return value of acpi_dev_filter_resource_type(), which
returns 0 on success, and 1 on failure. Fix it by taking the return
value of non-zero as failing to match the specified resource type.
Signed-off-by: Rui Wang
for exclusive use.
Signed-off-by: Rui Wang <rui.y.w...@intel.com>
---
drivers/acpi/ioapic.c | 36
1 file changed, 20 insertions(+), 16 deletions(-)
diff --git a/drivers/acpi/ioapic.c b/drivers/acpi/ioapic.c
index daf4a40..80b0b1a 100644
--- a/drivers/acpi/io
/ioapic/IOAPIC/ throughout.
* Fixed a warning from 0-day testing.
Rui Wang (5):
x86/ioapic: Change prototype of acpi_ioapic_add()
x86/ioapic: Support hot-removal of IOAPICs present during boot
x86/ioapic: Fix setup_res() failing to get resource
x86/ioapic: Fix lost IOAPIC resource aft
nge
appears in "_CRS" of each IOAPIC device. Both ranges should be claimed
from /proc/iomem for exclusive use.
Signed-off-by: Rui Wang <rui.y.w...@intel.com>
---
drivers/acpi/ioapic.c | 36
1 file changed, 20 insertions(+), 16 deletions(-)
diff --g
IOAPICs present during system boot aren't added to ioapic_list,
thus are unable to be hot-removed. Fix it by calling
acpi_ioapic_add() during root bus enumeration.
Signed-off-by: Rui Wang <rui.y.w...@intel.com>
---
drivers/acpi/pci_root.c | 10 ++
drivers/pci/setup-bus.c | 5 ++
Change the argument of acpi_ioapic_add() to a generic ACPI handle, and
move its prototype from drivers/acpi/internal.h to include/linux/acpi.h
so that it can be called from outside the pci_root driver.
Signed-off-by: Rui Wang <rui.y.w...@intel.com>
---
drivers/acpi/internal.h | 2 --
d
1 - 100 of 272 matches
Mail list logo
