On Tue, May 4, 2021 at 2:19 PM Michal Suchanek wrote:
>
> This way the compiler warns when a new value is added to the enum but
> not to the string translation like:
>
> drivers/net/ethernet/ibm/ibmvnic.c: In function 'adapter_state_to_string':
> drivers/net/ethernet/ibm/ibmvnic.c:832:2: warning:
On 2021-05-04 12:31, Lijun Pan wrote:
On Tue, May 4, 2021 at 2:27 PM Lijun Pan wrote:
On Tue, May 4, 2021 at 2:14 PM Dany Madden wrote:
>
> When ibmvnic gets a FATAL error message from the vnicserver, it marks
> the Command Respond Queue (CRQ) inactive and resets the adapter. If this
> FATAL
Prepare hardlockup_panic_setup() to handle a comma-separated list of
options. Thus, it can continue parsing its own command-line options while
ignoring paremeters that are relevant only to specific implementations of
the hardlockup detector. Such implementations may use an early_param to
parse
The current default implementation of the hardlockup detector assumes that
it is implemented using perf events. However, the hardlockup detector can
be driven by other sources of non-maskable interrupts (e.g., a properly
configured timer).
Group and wrap in #ifdef CONFIG_HARDLOCKUP_DETECTOR_PERF
The procedure to detect hardlockups is independent of the underlying
mechanism that generates the non-maskable interrupt used to drive the
detector. Thus, it can be put in a separate, generic function. In this
manner, it can be invoked by various implementations of the NMI watchdog.
For this
When there are more than one implementation of the NMI watchdog, there may
be situations in which switching from one to another is needed. For
if the time-stamp counter becomes unstable, the HPET-based NMI watchdog
an no longer be used.
Switching to another hardlockup detector can be done cleanly
On Tue, May 4, 2021 at 2:27 PM Lijun Pan wrote:
>
> On Tue, May 4, 2021 at 2:14 PM Dany Madden wrote:
> >
> > When ibmvnic gets a FATAL error message from the vnicserver, it marks
> > the Command Respond Queue (CRQ) inactive and resets the adapter. If this
> > FATAL reset fails and a
Hi Laurent,
Bear with me while I work through the commit message:
Laurent Dufour writes:
> After a LPM, the device tree node ibm,dynamic-reconfiguration-memory may be
> updated by the hypervisor in the case the NUMA topology of the LPAR's
> memory is updated.
Yes, the RTAS functions
On Tue, May 4, 2021 at 2:14 PM Dany Madden wrote:
>
> When ibmvnic gets a FATAL error message from the vnicserver, it marks
> the Command Respond Queue (CRQ) inactive and resets the adapter. If this
> FATAL reset fails and a transmission timeout reset follows, the CRQ is
> still inactive,
On 2021-04-22 19:26, Rick Lindsley wrote:
On 4/22/21 10:21 AM, Michal Suchánek wrote:
Merging do_reset and do_hard_reset might be a good code cleanup which
is
out of the scope of this fix.
I agree, on both points. Accepting the patch, and improving the reset
path are not in conflict with
When ibmvnic gets a FATAL error message from the vnicserver, it marks
the Command Respond Queue (CRQ) inactive and resets the adapter. If this
FATAL reset fails and a transmission timeout reset follows, the CRQ is
still inactive, ibmvnic's attempt to set link down will also fail. If
ibmvnic
This way the compiler warns when a new value is added to the enum but
not to the string translation like:
drivers/net/ethernet/ibm/ibmvnic.c: In function 'adapter_state_to_string':
drivers/net/ethernet/ibm/ibmvnic.c:832:2: warning: enumeration value
'VNIC_FOOBAR' not handled in switch [-Wswitch]
Michael Ellerman writes:
> -void do_stf_barrier_fixups(enum stf_barrier_type types)
> +static int __do_stf_barrier_fixups(void *data)
> {
> + enum stf_barrier_type types = (enum stf_barrier_type)data;
> +
> do_stf_entry_barrier_fixups(types);
> do_stf_exit_barrier_fixups(types);
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/powerpc/Kconfig
between commit:
c6b05f4e233c ("powerpc/kconfig: Restore alphabetic order of the selects under
CONFIG_PPC")
from the powerpc tree and commits:
fd7d5c273c43 ("mm: generalize
Hi Michael,
On Wed, 05 May 2021 14:57:18 +1000 Michael Ellerman wrote:
>
> Urgh, I did check linux-next to see if that patch would conflict but
> didn't think it would conflict *that* badly.
Its not as bad as it looks, the akpm-current patches just added three
selects and just need to be put in
On Fri, Apr 30, 2021 at 2:33 PM Nick Desaulniers
wrote:
>
> On Tue, Apr 27, 2021 at 1:42 PM Nick Desaulniers
> wrote:
> >
> > On Mon, Apr 26, 2021 at 11:39 PM Christophe Leroy
> > wrote:
> > >
> > > As you can see, CLANG doesn't save/restore 'lr' allthought 'lr' is
> > > explicitely listed in
Michael Ellerman writes:
> Nathan Lynch writes:
>> post_mobility_fixup() does cpus_read_unlock() before calling
>> pseries_setup_security_mitigations(), I think that will need to be
>> changed?
>
> I don't think so.
>
> I'm using stop_machine_cpuslocked() but that's because I'm a goose and
>
Le 04/05/2021 à 12:40, Christophe Leroy a écrit :
Le 04/05/2021 à 12:14, Nicholas Piggin a écrit :
Excerpts from Christophe Leroy's message of May 4, 2021 2:46 am:
PACA_SIZE, PACACONTEXTID, PACALOWSLICESPSIZE, PACAHIGHSLICEPSIZE,
PACA_SLB_ADDR_LIMIT, MMUPSIZEDEFSIZE, PACASLBCACHE,
Looks good,
Reviewed-by: Christoph Hellwig
Nathan Lynch writes:
> Michael Ellerman writes:
>> -void do_stf_barrier_fixups(enum stf_barrier_type types)
>> +static int __do_stf_barrier_fixups(void *data)
>> {
>> +enum stf_barrier_type types = (enum stf_barrier_type)data;
>> +
>> do_stf_entry_barrier_fixups(types);
>>
On Tue, 4 May 2021 at 09:16, Nicholas Piggin wrote:
>
> Excerpts from Joel Stanley's message of May 4, 2021 10:51 am:
> > On Mon, 3 May 2021 at 13:04, Nicholas Piggin wrote:
> >>
> >> These aren't necessarily POWER9 only, and it's not to say some new
> >> vulnerability may not get discovered on
randconfig-a003-20210504
i386 randconfig-a006-20210504
i386 randconfig-a001-20210504
i386 randconfig-a005-20210504
i386 randconfig-a004-20210504
i386 randconfig-a002-20210504
i386 randconfig-a003-20210503
i386
randconfig-a003-20210504
i386 randconfig-a006-20210504
i386 randconfig-a001-20210504
i386 randconfig-a005-20210504
i386 randconfig-a004-20210504
i386 randconfig-a002-20210504
i386 randconfig-a003-20210503
i386
defconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a003-20210504
i386 randconfig-a006-20210504
i386
Stephen Rothwell writes:
> Hi all,
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
> arch/powerpc/Kconfig
>
> between commit:
>
> c6b05f4e233c ("powerpc/kconfig: Restore alphabetic order of the selects
> under CONFIG_PPC")
>
> from the powerpc tree and commits:
>
>
On Thu, Apr 29, 2021 at 2:53 PM Christophe Leroy
wrote:
>
>
>
> Le 29/04/2021 à 05:15, Jordan Niethe a écrit :
> > setup_text_poke_area() is a late init call so it runs before
> > mark_rodata_ro() and after the init calls. This lets all the init code
> > patching simply write to their locations.
Le 04/05/2021 à 07:30, Alexander Dahl a écrit :
Hello Arnd,
Am Mon, May 03, 2021 at 11:25:21AM +0200 schrieb Arnd Bergmann:
On Mon, May 3, 2021 at 9:35 AM Alexander Dahl wrote:
Desktops and servers are all nice, however I just want to make you
aware, there are embedded users forced to
This changes generic-compat-pmu.c so that it only uses architected
events defined in Power ISA v3.0B, rather than event encodings which,
while common to all the IBM Power Systems implementations, are
nevertheless implementation-specific rather than architected. The
intention is that any CPU
On 04 May 2021 at 09:47am, Christophe Leroy wrote:
Hi
Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :
Hi Christophe,
Thanks for your answer but I think I don't know how it works with the
cherry-pick.
$ git bisect start
As you suspect the problem to be specific to powerpc, I can do
Am 04.05.21 um 10:58 schrieb Christophe Leroy:
Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :
On 04 May 2021 at 09:47am, Christophe Leroy wrote:
Hi
Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :
Hi Christophe,
Thanks for your answer but I think I don't know how it works with
After a LPM, the device tree node ibm,dynamic-reconfiguration-memory may be
updated by the hypervisor in the case the NUMA topology of the LPAR's
memory is updated.
This is caught by the kernel, but the memory's node is updated because
there is no way to move a memory block between nodes.
If
On Tue, May 04, 2021 at 03:26:24PM +1000, Nicholas Piggin wrote:
> Excerpts from Paul Mackerras's message of May 4, 2021 2:28 pm:
> > On Sat, May 01, 2021 at 11:58:36AM +1000, Nicholas Piggin wrote:
> >> Excerpts from Fabiano Rosas's message of April 16, 2021 9:09 am:
> >> > As one of the
Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :
Am 04.05.21 um 10:58 schrieb Christophe Leroy:
Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :
On 04 May 2021 at 09:47am, Christophe Leroy wrote:
Hi
Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :
Hi Christophe,
Thanks for
Hi Christophe,
Thanks for your answer but I think I don't know how it works with the
cherry-pick.
$ git bisect start
$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
Bisecting: 2462 revisions left to test after this (roughly
Hi
Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :
Hi Christophe,
Thanks for your answer but I think I don't know how it works with the
cherry-pick.
$ git bisect start
As you suspect the problem to be specific to powerpc, I can do
git bisect start -- arch/powerpc
$ git bisect good
Excerpts from Paul Mackerras's message of May 4, 2021 5:36 pm:
> On Tue, May 04, 2021 at 03:26:24PM +1000, Nicholas Piggin wrote:
>> Excerpts from Paul Mackerras's message of May 4, 2021 2:28 pm:
>> > On Sat, May 01, 2021 at 11:58:36AM +1000, Nicholas Piggin wrote:
>> >> Excerpts from Fabiano
On 02/05/2021 03:41, Joe Perches wrote:
On Sat, 2021-05-01 at 17:52 +0200, Miguel Ojeda wrote:
On Sat, May 1, 2021 at 5:17 PM Masahiro Yamada wrote:
More cleanups will be possible as follow-up patches, but this one must
be agreed and applied to the mainline first.
+1 This will allow me to
Am 04.05.21 um 11:11 schrieb Christophe Leroy:
Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :
Am 04.05.21 um 10:58 schrieb Christophe Leroy:
Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :
On 04 May 2021 at 09:47am, Christophe Leroy wrote:
Hi
Le 04/05/2021 à 09:21, Christian
Am 04.05.21 um 11:49 schrieb Christophe Leroy:
Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :
Am 04.05.21 um 11:11 schrieb Christophe Leroy:
Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :
Am 04.05.21 um 10:58 schrieb Christophe Leroy:
Le 04/05/2021 à 10:29, Christian Zigotzky
Le 03/05/2021 à 22:44, Tyrel Datwyler a écrit :
On 5/3/21 10:28 AM, Laurent Dufour wrote:
Le 01/05/2021 à 01:58, Tyrel Datwyler a écrit :
On 4/30/21 9:13 AM, Laurent Dufour wrote:
Le 29/04/2021 à 21:12, Tyrel Datwyler a écrit :
On 4/29/21 3:27 AM, Aneesh Kumar K.V wrote:
Laurent Dufour
On Tue, May 4, 2021 at 9:57 AM Ben Dooks wrote:
>
> Some of us are a bit stuck as either customer refuses to upgrade
> their build infrastructure or has paid for some old but safety
> blessed version of gcc. These often lag years behind the recent
> gcc releases :(
In those scenarios, why do you
Excerpts from Joel Stanley's message of May 4, 2021 10:51 am:
> On Mon, 3 May 2021 at 13:04, Nicholas Piggin wrote:
>>
>> These aren't necessarily POWER9 only, and it's not to say some new
>> vulnerability may not get discovered on other processors for which
>> we would like the flexibility of
Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :
On 04 May 2021 at 09:47am, Christophe Leroy wrote:
Hi
Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :
Hi Christophe,
Thanks for your answer but I think I don't know how it works with the
cherry-pick.
$ git bisect start
As you
Excerpts from Michal Suchánek's message of May 4, 2021 6:17 am:
> On Mon, May 03, 2021 at 11:34:25AM +0200, Michal Suchánek wrote:
>> On Mon, May 03, 2021 at 09:11:16AM +0200, Michal Suchánek wrote:
>> > On Mon, May 03, 2021 at 10:58:33AM +1000, Nicholas Piggin wrote:
>> > > Excerpts from Michal
On Tue, May 04, 2021 at 10:38:32AM +0200, Miguel Ojeda wrote:
> On Tue, May 4, 2021 at 9:57 AM Ben Dooks wrote:
> >
> > Some of us are a bit stuck as either customer refuses to upgrade
> > their build infrastructure or has paid for some old but safety
> > blessed version of gcc. These often lag
Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :
Am 04.05.21 um 11:11 schrieb Christophe Leroy:
Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :
Am 04.05.21 um 10:58 schrieb Christophe Leroy:
Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :
On 04 May 2021 at 09:47am,
Excerpts from Christophe Leroy's message of May 4, 2021 2:46 am:
> mm_ctx_id and mm_ctx_slb_addr_limit are not used anymore.
>
> Remove them.
>
> Signed-off-by: Christophe Leroy
Reviewed-by: Nicholas Piggin
> ---
> arch/powerpc/include/asm/paca.h | 2 --
> arch/powerpc/kernel/paca.c |
On Tue, May 04, 2021 at 02:09:24PM +0200, Miguel Ojeda wrote:
> On Tue, May 4, 2021 at 11:22 AM Michal Suchánek wrote:
> >
> > Except it makes answering the question "Is this bug we see on this
> > ancient system still present in upstream?" needlessly more difficult to
> > answer.
>
> Can you
Le 04/05/2021 à 14:17, Michal Suchánek a écrit :
On Tue, May 04, 2021 at 02:09:24PM +0200, Miguel Ojeda wrote:
On Tue, May 4, 2021 at 11:22 AM Michal Suchánek wrote:
Except it makes answering the question "Is this bug we see on this
ancient system still present in upstream?" needlessly
On Fri, 26 Mar 2021 07:13:09 +0100
Christoph Hellwig wrote:
> Hi all,
>
> the nvlink2 vfio subdriver is a weird beast. It supports a hardware
> feature without any open source component - what would normally be
> the normal open source userspace that we require for kernel drivers,
> although
Nicholas Piggin wrote:
Excerpts from Naveen N. Rao's message of April 27, 2021 11:59 pm:
Nicholas Piggin wrote:
+ *
+ * H_CONFER from spin locks must be treated separately though and use _notrace
+ * plpar_hcall variants, see yield_to_preempted().
*/
static DEFINE_PER_CPU(unsigned int,
Le 04/05/2021 à 04:53, Nathan Lynch a écrit :
Instead of making bare calls to get-sensor-state, use
rtas_get_sensor(), which correctly handles busy and extended delay
statuses.
Reviewed-by: Laurent Dufour
Fixes: ab519a011caa ("powerpc/pseries: Kernel DLPAR Infrastructure")
Signed-off-by:
Excerpts from Christophe Leroy's message of May 4, 2021 2:46 am:
> PACA_SIZE, PACACONTEXTID, PACALOWSLICESPSIZE, PACAHIGHSLICEPSIZE,
> PACA_SLB_ADDR_LIMIT, MMUPSIZEDEFSIZE, PACASLBCACHE, PACASLBCACHEPTR,
> PACASTABRR, PACAVMALLOCSLLP, MMUPSIZESLLP, PACACONTEXTSLLP,
> PACALPPACAPTR, LPPACA_DTLIDX
Le 04/05/2021 à 12:14, Nicholas Piggin a écrit :
Excerpts from Christophe Leroy's message of May 4, 2021 2:46 am:
PACA_SIZE, PACACONTEXTID, PACALOWSLICESPSIZE, PACAHIGHSLICEPSIZE,
PACA_SLB_ADDR_LIMIT, MMUPSIZEDEFSIZE, PACASLBCACHE, PACASLBCACHEPTR,
PACASTABRR, PACAVMALLOCSLLP, MMUPSIZESLLP,
Excerpts from Naveen N. Rao's message of May 4, 2021 8:25 pm:
> Nicholas Piggin wrote:
>> Excerpts from Naveen N. Rao's message of April 27, 2021 11:59 pm:
>>> Nicholas Piggin wrote:
+ *
+ * H_CONFER from spin locks must be treated separately though and use
_notrace
+ *
On Tue, May 4, 2021 at 7:31 AM Alexander Dahl wrote:
> Am Mon, May 03, 2021 at 11:25:21AM +0200 schrieb Arnd Bergmann:
> > On Mon, May 3, 2021 at 9:35 AM Alexander Dahl wrote:
> > >
> > > Desktops and servers are all nice, however I just want to make you
> > > aware, there are embedded users
On Tue, May 4, 2021 at 11:22 AM Michal Suchánek wrote:
>
> Except it makes answering the question "Is this bug we see on this
> ancient system still present in upstream?" needlessly more difficult to
> answer.
Can you please provide some details? If you are talking about testing
a new kernel
Segher Boessenkool writes:
> On Mon, May 03, 2021 at 10:51:41AM +1000, Nicholas Piggin wrote:
>> Excerpts from Segher Boessenkool's message of May 3, 2021 3:55 am:
>> > On Wed, Apr 29, 2020 at 10:57:16AM +1000, Nicholas Piggin wrote:
>> >> Excerpts from Segher Boessenkool's message of April 29,
On Tue, May 04, 2021 at 02:22:36PM +0200, Greg Kurz wrote:
> On Fri, 26 Mar 2021 07:13:09 +0100
> Christoph Hellwig wrote:
>
> > Hi all,
> >
> > the nvlink2 vfio subdriver is a weird beast. It supports a hardware
> > feature without any open source component - what would normally be
> > the
On Tue, May 04, 2021 at 02:59:07PM +0200, Greg Kroah-Hartman wrote:
> > Hi Christoph,
> >
> > FYI, these uapi changes break build of QEMU.
>
> What uapi changes?
>
> What exactly breaks?
>
> Why does QEMU require kernel driver stuff?
Looks like it pull in the uapi struct definitions
Excerpts from Michal Suchánek's message of May 4, 2021 12:38 am:
> On Mon, May 03, 2021 at 01:37:57PM +0200, Andreas Schwab wrote:
>> Should this add a tag to the module vermagic?
Good question.
>
> Would the modues link even if the vermagic was not changed?
>
> I suppose something like this
Am 04.05.21 um 12:07 schrieb Christian Zigotzky:
Am 04.05.21 um 11:49 schrieb Christophe Leroy:
Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :
Am 04.05.21 um 11:11 schrieb Christophe Leroy:
Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :
Am 04.05.21 um 10:58 schrieb Christophe
On Tue, May 04, 2021 at 12:53:27PM -0300, Jason Gunthorpe wrote:
> On Tue, May 04, 2021 at 04:23:40PM +0200, Daniel Vetter wrote:
>
> > Just my 2cents from drm (where we deprecate old gunk uapi quite often):
> > Imo it's best to keep the uapi headers as-is, but exchange the
> > documentation with
On Mon, May 3, 2021 at 9:17 AM Christophe Leroy
wrote:
> Le 01/05/2021 à 17:15, Masahiro Yamada a écrit :
> > The current minimum GCC version is 4.9 except ARCH=arm64 requiring
> > GCC 5.1.
> >
> > When we discussed last time, we agreed to raise the minimum GCC version
> > to 5.1 globally. [1]
>
On Mon, May 3, 2021 at 12:29 PM Arnd Bergmann wrote:
>
> On Mon, May 3, 2021 at 9:35 AM Alexander Dahl wrote:
> >
> > Desktops and servers are all nice, however I just want to make you
> > aware, there are embedded users forced to stick to older cross
> > toolchains for different reasons as
The STF (store-to-load forwarding) barrier mitigation can be
enabled/disabled at runtime via a debugfs file (stf_barrier), which
causes the kernel to patch itself to enable/disable the relevant
mitigations.
However depending on which mitigation we're using, it may not be safe to
do that patching
On Tue, 4 May 2021 15:00:39 +0200
Christoph Hellwig wrote:
> On Tue, May 04, 2021 at 02:59:07PM +0200, Greg Kroah-Hartman wrote:
> > > Hi Christoph,
> > >
> > > FYI, these uapi changes break build of QEMU.
> >
> > What uapi changes?
> >
> > What exactly breaks?
> >
> > Why does QEMU
On Tue, 4 May 2021 14:59:07 +0200
Greg Kroah-Hartman wrote:
> On Tue, May 04, 2021 at 02:22:36PM +0200, Greg Kurz wrote:
> > On Fri, 26 Mar 2021 07:13:09 +0100
> > Christoph Hellwig wrote:
> >
> > > Hi all,
> > >
> > > the nvlink2 vfio subdriver is a weird beast. It supports a hardware
> > >
On Tue, May 04, 2021 at 03:20:34PM +0200, Greg Kurz wrote:
> On Tue, 4 May 2021 14:59:07 +0200
> Greg Kroah-Hartman wrote:
>
> > On Tue, May 04, 2021 at 02:22:36PM +0200, Greg Kurz wrote:
> > > On Fri, 26 Mar 2021 07:13:09 +0100
> > > Christoph Hellwig wrote:
> > >
> > > > Hi all,
> > > >
> >
On Tue, May 04, 2021 at 03:20:34PM +0200, Greg Kurz wrote:
> On Tue, 4 May 2021 14:59:07 +0200
> Greg Kroah-Hartman wrote:
>
> > On Tue, May 04, 2021 at 02:22:36PM +0200, Greg Kurz wrote:
> > > On Fri, 26 Mar 2021 07:13:09 +0100
> > > Christoph Hellwig wrote:
> > >
> > > > Hi all,
> > > >
> >
The entry flush mitigation can be enabled/disabled at runtime via a
debugfs file (entry_flush), which causes the kernel to patch itself to
enable/disable the relevant mitigations.
However depending on which mitigation we're using, it may not be safe to
do that patching while other CPUs are
Am 04.05.21 um 13:02 schrieb Christian Zigotzky:
Am 04.05.21 um 12:07 schrieb Christian Zigotzky:
Am 04.05.21 um 11:49 schrieb Christophe Leroy:
Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :
Am 04.05.21 um 11:11 schrieb Christophe Leroy:
Le 04/05/2021 à 11:09, Christian Zigotzky a
On Tue, 4 May 2021 15:30:15 +0200
Greg Kroah-Hartman wrote:
> On Tue, May 04, 2021 at 03:20:34PM +0200, Greg Kurz wrote:
> > On Tue, 4 May 2021 14:59:07 +0200
> > Greg Kroah-Hartman wrote:
> >
> > > On Tue, May 04, 2021 at 02:22:36PM +0200, Greg Kurz wrote:
> > > > On Fri, 26 Mar 2021 07:13:09
Le 04/05/2021 à 13:02, Christian Zigotzky a écrit :
Am 04.05.21 um 12:07 schrieb Christian Zigotzky:
Am 04.05.21 um 11:49 schrieb Christophe Leroy:
Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :
Am 04.05.21 um 11:11 schrieb Christophe Leroy:
Le 04/05/2021 à 11:09, Christian
Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :
Am 04.05.21 um 11:11 schrieb Christophe Leroy:
Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :
Am 04.05.21 um 10:58 schrieb Christophe Leroy:
Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :
On 04 May 2021 at 09:47am,
Le 04/05/2021 à 15:48, Christian Zigotzky a écrit :
Am 04.05.21 um 13:02 schrieb Christian Zigotzky:
Am 04.05.21 um 12:07 schrieb Christian Zigotzky:
Am 04.05.21 um 11:49 schrieb Christophe Leroy:
Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :
Am 04.05.21 um 11:11 schrieb
Am 04.05.21 um 16:48 schrieb Christophe Leroy:
Le 04/05/2021 à 15:48, Christian Zigotzky a écrit :
Am 04.05.21 um 13:02 schrieb Christian Zigotzky:
Am 04.05.21 um 12:07 schrieb Christian Zigotzky:
Am 04.05.21 um 11:49 schrieb Christophe Leroy:
Le 04/05/2021 à 11:46, Christian Zigotzky a
Am 04.05.21 um 16:41 schrieb Christophe Leroy:
Le 04/05/2021 à 13:02, Christian Zigotzky a écrit :
Am 04.05.21 um 12:07 schrieb Christian Zigotzky:
Am 04.05.21 um 11:49 schrieb Christophe Leroy:
Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :
Am 04.05.21 um 11:11 schrieb Christophe
Le 04/05/2021 à 16:59, Christian Zigotzky a écrit :
Am 04.05.21 um 16:41 schrieb Christophe Leroy:
Le 04/05/2021 à 13:02, Christian Zigotzky a écrit :
Am 04.05.21 um 12:07 schrieb Christian Zigotzky:
Am 04.05.21 um 11:49 schrieb Christophe Leroy:
Le 04/05/2021 à 11:46, Christian
On Tue, 4 May 2021 16:11:31 +0200
Greg Kurz wrote:
> On Tue, 4 May 2021 15:30:15 +0200
> Greg Kroah-Hartman wrote:
>
> > On Tue, May 04, 2021 at 03:20:34PM +0200, Greg Kurz wrote:
> > > On Tue, 4 May 2021 14:59:07 +0200
> > > Greg Kroah-Hartman wrote:
> > >
> > > > On Tue, May 04, 2021
On Tue, May 04, 2021 at 04:23:40PM +0200, Daniel Vetter wrote:
> Just my 2cents from drm (where we deprecate old gunk uapi quite often):
> Imo it's best to keep the uapi headers as-is, but exchange the
> documentation with a big "this is removed, never use again" warning:
We in RDMA have been
On Tue, 04 May 2021 09:52:02 -0600
Alex Williamson wrote:
> Revert the uAPI changes from the below commit with notice that these
> regions and capabilities are no longer provided.
>
> Fixes: b392a1989170 ("vfio/pci: remove vfio_pci_nvlink2")
> Reported-by: Greg Kurz
> Signed-off-by: Alex
Nicholas Piggin wrote:
Excerpts from Naveen N. Rao's message of May 4, 2021 8:25 pm:
Nicholas Piggin wrote:
Excerpts from Naveen N. Rao's message of April 27, 2021 11:59 pm:
Nicholas Piggin wrote:
+ *
+ * H_CONFER from spin locks must be treated separately though and use _notrace
+ *
Revert the uAPI changes from the below commit with notice that these
regions and capabilities are no longer provided.
Fixes: b392a1989170 ("vfio/pci: remove vfio_pci_nvlink2")
Reported-by: Greg Kurz
Signed-off-by: Alex Williamson
---
Greg (Kurz), please double check this resolves the issue.
On Tue, 04 May 2021 09:52:02 -0600
Alex Williamson wrote:
> Revert the uAPI changes from the below commit with notice that these
> regions and capabilities are no longer provided.
>
> Fixes: b392a1989170 ("vfio/pci: remove vfio_pci_nvlink2")
> Reported-by: Greg Kurz
> Signed-off-by: Alex
tree: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
next-test
head: a5014a5c936a2a9a223e699e1f3abd54d5f68d2c
commit: 682ebb015052696ac93cf8df28142d83be8dbcc3 [7/8] powerpc/64s: Fix crashes
when toggling stf barrier
config: powerpc-randconfig-r022-20210503 (attached as
Nicholas Piggin wrote:
Excerpts from Michal Suchánek's message of May 4, 2021 6:17 am:
On Mon, May 03, 2021 at 11:34:25AM +0200, Michal Suchánek wrote:
On Mon, May 03, 2021 at 09:11:16AM +0200, Michal Suchánek wrote:
> On Mon, May 03, 2021 at 10:58:33AM +1000, Nicholas Piggin wrote:
> >
On Tue, May 04, 2021 at 11:11:25PM +0530, Naveen N. Rao wrote:
> Nicholas Piggin wrote:
> > Excerpts from Michal Suchánek's message of May 4, 2021 6:17 am:
> > > On Mon, May 03, 2021 at 11:34:25AM +0200, Michal Suchánek wrote:
> > > > On Mon, May 03, 2021 at 09:11:16AM +0200, Michal Suchánek
tree: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
next-test
head: a5014a5c936a2a9a223e699e1f3abd54d5f68d2c
commit: a5014a5c936a2a9a223e699e1f3abd54d5f68d2c [8/8] powerpc/64s: Fix crashes
when toggling entry flush barrier
config: powerpc-randconfig-r022-20210503
Nicholas Piggin writes:
> An error message when you try to start the nested guest telling you
> pass -machine cap-htm=off would be better... I guess that should
> really all work with caps etc today though so TM's a bad example.
> But assume we don't have a cap for the bit we disable? Maybe we
>
Le 04/05/2021 à 20:31, kernel test robot a écrit :
tree: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
next-test
head: a5014a5c936a2a9a223e699e1f3abd54d5f68d2c
commit: a5014a5c936a2a9a223e699e1f3abd54d5f68d2c [8/8] powerpc/64s: Fix crashes
when toggling entry flush
91 matches
Mail list logo
