>>> On 07.05.15 at 08:02, wrote:
> AFAICT gas will produce relocations for jumps to global labels in the
> same file. This doesn't seem directly harmful to me, except that, on
> x86, it forces five-byte jumps instead of two-byte jumps.
>
> This seems especially unfortunate, since even hidden and
>>> On 23.04.15 at 17:33, wrote:
> On Tue, Apr 21, 2015 at 11:33 PM, Jan Beulich wrote:
>>
>> while the description of commit cae2a173fe certainly makes sense, the
>> change itself ignores the __probe_kernel_write() code path, for which
>> the destination
>>> On 23.04.15 at 17:33, wrote:
> On Tue, Apr 21, 2015 at 11:33 PM, Jan Beulich wrote:
>>
>> while the description of commit cae2a173fe certainly makes sense, the
>> change itself ignores the __probe_kernel_write() code path, for which
>> the destination
Linus,
while the description of commit cae2a173fe certainly makes sense, the
change itself ignores the __probe_kernel_write() code path, for which
the destination address is expected to be in kernel space but accesses
may still fault. I.e. the use of plain memset() causes
__probe_kernel_write() to
>>> On 20.04.15 at 19:09, wrote:
> A different approach, given the dual nature of the AC flag now is to gate
> setup_smap() on a kernel rpl of 0. SMAP necessarily can't be used in a
> paravirtual situation where the kernel runs in cpl > 0.
"Can't" isn't true here - for 64-bit PV Xen guests, whic
>>> On 10.04.15 at 16:37, wrote:
> On 03/04/15 15:28, Konrad Rzeszutek Wilk wrote:
>> Hey David and Boris,
>>
>> Please see the two patches - the first one fixes an situation that
>> the original XSA-120 patch hadn't considered.
>>
>> The second patch is more of just a cleanup. Can be 4.1 materi
>>> On 11.04.15 at 01:05, wrote:
>> One might argue that this code serves no purpose, but it's there, so
>> we had better keep our per-invocation usage of DEBUG_STACK within 4k.
>
> Only if you run NKLD. I doubt KDB or GDB support nesting.
> We can ask Jan if he still uses it.
I didn't have the
>>> On 23.03.15 at 23:58, wrote:
> On Monday 23 March 2015 22:24:28 Paul Bolle wrote:
>> > A real world case is PCI_QUIRKS in the mainline kernel:
>> >
>> > init/Kconfig:1554: default y
>> > arch/s390/Kconfig:59: def_bool n
>> >
>> > When setting PCI!=n && EXPERT=n then on each architecture
>>> On 23.03.15 at 22:08, wrote:
> On Thursday 12 March 2015 13:11:47 Paul Bolle wrote:
>> On Wed, 2015-03-11 at 13:59 +, Jan Beulich wrote:
>> > Default "no" is pretty pointless for options without (visible) prompts:
>>
>> Related: is
>>> On 12.03.15 at 13:11, wrote:
> On Wed, 2015-03-11 at 13:59 +, Jan Beulich wrote:
>> Default "no" is pretty pointless for options without (visible) prompts:
>
> Related: is there ever a situation where using "default n" or "def_bool
> n
>>> On 12.03.15 at 00:10, wrote:
> config X86_LOCAL_APIC
> def_bool y
> - depends on X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_APIC ||
> PCI_MSI
> + depends on X86_64 || SMP || X86_32_NON_STANDARD || PCI_MSI
I.e. building a 32-bit kernel with APIC support but with !SMP, !PCI_
>>> On 11.03.15 at 15:44, wrote:
> On 11/03/15 14:42, Konrad Rzeszutek Wilk wrote:
>> On Wed, Mar 11, 2015 at 01:52:00PM +, Jan Beulich wrote:
>>> It's not clear to me why only the enabling operation got handled so
>>> far.
>>
>> Reviewed
Default "no" is pretty pointless for options without (visible) prompts:
They only clutter .config-s with "# CONFIG_... is not set" and thus
prevent users of "make oldconfig", when the option obtains a prompt or
its prompt becomes visible, noticing that these may now b
It's not clear to me why only the enabling operation got handled so
far.
Signed-off-by: Jan Beulich
---
drivers/xen/xen-pciback/conf_space_header.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
--- 4.0-rc3-xen-pciback.orig/drivers/xen/xen-pciback/conf_space_hea
alter any of the bits collected together as
PCI_COMMAND_GUEST permissive mode is now required to be enabled
globally or on the specific device.
This is CVE-2015-2150 / XSA-120.
Signed-off-by: Jan Beulich
Reviewed-by: Konrad Rzeszutek Wilk
---
drivers/xen/xen-pciback/conf_space.c|2
>>> On 05.03.15 at 09:52, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Thursday, March 5, 2015 4:40 PM
>> >>> On 05.03.15 at 04:53, wrote:
>> >> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
>> >> S
>>> On 05.03.15 at 04:53, wrote:
>> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
>> Sent: Thursday, March 5, 2015 3:43 AM
>> On Tue, Mar 03, 2015 at 04:11:09PM +0800, Wang Xiaoming wrote:
>> > @@ -101,13 +119,32 @@ setup_io_tlb_npages(char *str) {
>> >if (isdigit(*str)) {
>> >
c: Dexuan Cui
> Cc: Greg Kroah-Hartman
> Cc: H. Peter Anvin
> Cc: jbeul...@suse.com
> Cc: Jan Beulich
> Cc: Joonsoo Kim
> Cc: Juergen Gross
> Cc: Linus Torvalds
> Cc: Pavel Machek
> Cc: Thomas Gleixner
> Cc: Tony Lindgren
> Cc: Toshi Kani
> Cc: Vlastim
>>> On 04.03.15 at 05:53, wrote:
> On 03/03/2015 08:20 PM, Luis R. Rodriguez wrote:
>> On Tue, Mar 3, 2015 at 2:06 AM, David Vrabel wrote:
>>> On 03/03/15 09:40, Luis R. Rodriguez wrote:
if X86_64 && SPARSEMEM_VMEMMAP
Now Xen should not have SPARSEMEM_VMEMMAP but PVOPs' goal is to
>>> On 03.03.15 at 10:40, wrote:
> Let's go down the rabbit hole for a bit. HAVE_ARCH_KASAN will be
> selected on x86 when:
>
> if X86_64 && SPARSEMEM_VMEMMAP
>
> Now Xen should not have SPARSEMEM_VMEMMAP
Why would that be?
Jan
--
To unsubscribe from this list: send the line "unsubscribe linu
Commit-ID: 0cdb81bef20b1d9e12111fa6cd81f748ebd87778
Gitweb: http://git.kernel.org/tip/0cdb81bef20b1d9e12111fa6cd81f748ebd87778
Author: Jan Beulich
AuthorDate: Fri, 23 Jan 2015 08:35:13 +
Committer: Ingo Molnar
CommitDate: Thu, 19 Feb 2015 02:18:26 +0100
x86-64: Also clear
Commit-ID: db2dcb4f91d5fec5c346a82c309187ee821e2495
Gitweb: http://git.kernel.org/tip/db2dcb4f91d5fec5c346a82c309187ee821e2495
Author: Jan Beulich
AuthorDate: Tue, 20 Jan 2015 13:00:46 +
Committer: Ingo Molnar
CommitDate: Thu, 19 Feb 2015 01:08:42 +0100
irqflags: Fix (at least
Commit-ID: 3ebfaff2bbd1d2ef882e475245d9f0276f21fe83
Gitweb: http://git.kernel.org/tip/3ebfaff2bbd1d2ef882e475245d9f0276f21fe83
Author: Jan Beulich
AuthorDate: Fri, 23 Jan 2015 08:35:13 +
Committer: Ingo Molnar
CommitDate: Thu, 19 Feb 2015 00:44:46 +0100
x86-64: Also clear
Commit-ID: 50849eefea3ba8aa6e540e0cbdc9533098f25656
Gitweb: http://git.kernel.org/tip/50849eefea3ba8aa6e540e0cbdc9533098f25656
Author: Jan Beulich
AuthorDate: Thu, 5 Feb 2015 15:31:56 +
Committer: Ingo Molnar
CommitDate: Wed, 18 Feb 2015 22:10:54 +0100
x86/Kconfig: Simplify
Commit-ID: e0fd24a3b4ad7b4084b41944835952eedec53f98
Gitweb: http://git.kernel.org/tip/e0fd24a3b4ad7b4084b41944835952eedec53f98
Author: Jan Beulich
AuthorDate: Thu, 5 Feb 2015 15:39:34 +
Committer: Ingo Molnar
CommitDate: Wed, 18 Feb 2015 22:08:46 +0100
x86/Kconfig: Avoid issuing
Commit-ID: b1da1e715d4faf01468b7f45f7098922bc85ea8e
Gitweb: http://git.kernel.org/tip/b1da1e715d4faf01468b7f45f7098922bc85ea8e
Author: Jan Beulich
AuthorDate: Thu, 5 Feb 2015 15:35:21 +
Committer: Ingo Molnar
CommitDate: Wed, 18 Feb 2015 22:09:33 +0100
x86/Kconfig: Simplify
Commit-ID: 890a5409f9d0c84d75a1e16eebdfe91d8a57ef1e
Gitweb: http://git.kernel.org/tip/890a5409f9d0c84d75a1e16eebdfe91d8a57ef1e
Author: Jan Beulich
AuthorDate: Mon, 9 Feb 2015 12:30:00 +0100
Committer: Ingo Molnar
CommitDate: Wed, 18 Feb 2015 16:18:02 +0100
sched/numa: Avoid some
>>> On 18.02.15 at 10:37, wrote:
> On 02/18/2015 10:21 AM, Paul Bolle wrote:
>> On Wed, 2015-02-18 at 07:52 +0100, Juergen Gross wrote:
>>> --- a/arch/x86/xen/Kconfig
>>> +++ b/arch/x86/xen/Kconfig
>>> @@ -23,14 +23,29 @@ config XEN_PVHVM
>>> def_bool y
>>> depends on XEN && PCI && X86_LOC
>>> On 18.02.15 at 10:09, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Tuesday, February 17, 2015 6:09 PM
>> >>> On 17.02.15 at 07:51, wrote:
>> > --- a/Documentation/kernel-parameters.txt
>> > +++ b/Documentation/ke
>>> On 17.02.15 at 07:51, wrote:
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -3438,10 +3438,12 @@ bytes respectively. Such letter suffixes can also be
> entirely omitted.
> it if 0 is given (See Documentation/cgroups/memory.tx
It's perfectly fine to add it.
Jan
> ---
> Subject: sched/numa: Avoid some pointless iterations
> From: Jan Beulich
> Date: Mon Feb 9 12:30:00 CET 2015
>
> Commit 81907478c431 ("sched/fair: Avoid using uninitialized variable
> in preferred_group_nid()") unc
ng an incremental update of the configuration (make oldconfig).
Signed-off-by: Jan Beulich
---
arch/x86/Kconfig | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
--- 3.19-rc7/arch/x86/Kconfig
+++ 3.19-rc7-x86-Kconfig-cleanup/arch/x86/Kconfig
@@ -232,12 +232,10 @@ c
Since dependencies are transitive, we don't really need to repeat those
of X86_UP_IOAPIC.
Furthermore avoid the symbol getting entered into .config when it is
off by having the default simply Y and the dependencies solely handled
via the intended for that purpose "depends on".
Sig
We don't really need a helper symbol for that. For one, it's
pointlessly getting set to Y for all configurations (even 64-bit ones).
And then the purpose can be fulfilled by suitably adjusting
X86_UP_APIC: Hide its prompt when PCI_MSI, and default it to PCI_MSI.
Signed-off-by: Jan B
>>> On 03.02.15 at 22:03, wrote:
> On Wed, 2015-02-04 at 07:50 +1100, NeilBrown wrote:
>> Actually the prefix of this macro is "CONFIG_AS_", not "CONFIG_" :-)
>> CONFIG_AS_ is reserved for assembly magic, and is never used by the the
>> kconfig system.
>>
>> (Well. I might have made bits of t
>>> On 30.01.15 at 12:21, wrote:
> @@ -734,11 +734,11 @@ static int scsiback_do_cmd_fn(struct vscsibk_info *info)
> if (!pending_req)
> return 1;
>
> - ring_req = RING_GET_REQUEST(ring, rc);
> + memcpy(&ring_req, RING_GET_REQUEST(ring,
Commit-ID: 81907478c4311a679849216abf723999184ab984
Gitweb: http://git.kernel.org/tip/81907478c4311a679849216abf723999184ab984
Author: Jan Beulich
AuthorDate: Fri, 23 Jan 2015 08:25:38 +
Committer: Ingo Molnar
CommitDate: Wed, 28 Jan 2015 13:14:12 +0100
sched/fair: Avoid using
>>> On 28.01.15 at 15:29, wrote:
> Commit-ID: 81907478c4311a679849216abf723999184ab984
> Gitweb:
> http://git.kernel.org/tip/81907478c4311a679849216abf723999184ab984
> Author: Jan Beulich
> AuthorDate: Fri, 23 Jan 2015 08:25:38 +
> Committer: Ingo Mo
>>> On 27.01.15 at 02:51, wrote:
Even if David told you this would be acceptable, I have to question
an abstract model of fixing issues on only 64-bit kernels - this may
be acceptable for distro purposes, but seems hardly the right
approach for upstream. If 32-bit ones are to become deliberately
>>> On 23.01.15 at 19:58, wrote:
> On Fri, Jan 23, 2015 at 11:45:06AM +, David Vrabel wrote:
>> On 23/01/15 00:29, Luis R. Rodriguez wrote:
>> > @@ -1243,6 +1247,25 @@ void xen_evtchn_do_upcall(struct pt_regs *regs)
>> >set_irq_regs(old_regs);
>> > }
>> >
>> > +/*
>> > + * CONFIG_PREEMP
>>> On 23.01.15 at 10:58, wrote:
> On Fri, Jan 23, 2015 at 08:32:01AM +, Jan Beulich wrote:
>> The compiler validly warns about it being ignored.
>>
>> Signed-off-by: Jan Beulich
>
> Applied, thanks.
>
> Out of curiosity: When do you see thi
>>> On 23.01.15 at 10:54, wrote:
> On Fri, Jan 23, 2015 at 08:25:38AM +, Jan Beulich wrote:
>> At least some gcc versions - validly afaict - warn about potentially
>> using max_group uninitialized: There's no way the compiler can prove
>> that the b
As a module_init() function, this should have been this way from the
beginning.
Signed-off-by: Jan Beulich
---
drivers/xen/tmem.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 3.19-rc5/drivers/xen/tmem.c
+++ 3.19-rc5-xen-tmem-init/drivers/xen/tmem.c
@@ -374,7 +374,7 @@ static
Not just setting it when the feature is available is for consistency,
and may allow Xen to drop its custom clearing of the flag (unless it
needs it cleared earlier than this code executes). Note that the change
is benign to ix86, as the flag starts out clear there.
Signed-off-by: Jan Beulich
The compiler validly warns about it being ignored.
Signed-off-by: Jan Beulich
---
arch/x86/kernel/cpu/mcheck/mce_amd.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 3.19-rc5/arch/x86/kernel/cpu/mcheck/mce_amd.c
+++ 3.19-rc5-x86-MCE-AMD-bank4_names/arch/x86/kernel/cpu/mcheck
Just like for AVX2 (which simply needs an #if -> #ifdef conversion),
SSSE3 assembler support should be checked for before using it.
Signed-off-by: Jan Beulich
Cc: Jim Kukunas
Cc: Neil Brown
---
arch/x86/Makefile |1 +
lib/raid6/algos.c |2 +-
lib/raid6/recov_avx2.c |
by exiting the
outer loop when max_faults is still zero after the inner loop. For the
compiler's sake, mark max_group uninitialized, as we're now able to
prove it's not actually being used uninitalized anymore.
Signed-off-by: Jan Beulich
Cc: Rik van Riel
---
kernel/sched/fair.c |
There not being a similar difference in page fault handling, I can't
see why 32- and 64-bit should differ in behavior here.
Signed-off-by: Jan Beulich
---
arch/x86/kernel/traps.c |2 --
1 file changed, 2 deletions(-)
--- 3.19-rc5/arch/x86/kernel/traps.c
+++ 3.19-rc5-ix86-show-unha
preceding it (which was slightly wrong from at least
from 2.6.37 onwards).
The code bloat was observed in reality with an experimental x86 patch.
Signed-off-by: Jan Beulich
---
v2: Deal with architectures not defining raw_irqs_disabled() by
retaining the CONFIG_TRACE_IRQFLAGS_SUPPORT-dependent
Commit-ID: 4a0d3107d6b19125f21172c2b7d95f9c30ecaf6f
Gitweb: http://git.kernel.org/tip/4a0d3107d6b19125f21172c2b7d95f9c30ecaf6f
Author: Jan Beulich
AuthorDate: Fri, 16 Jan 2015 15:47:07 +
Committer: Thomas Gleixner
CommitDate: Tue, 20 Jan 2015 12:37:23 +0100
x86, irq: Properly tag
The mis-naming likely was a copy-and-paste effect.
Signed-off-by: Jan Beulich
---
arch/x86/kernel/irq.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 3.19-rc4/arch/x86/kernel/irq.c
+++ 3.19-rc4-xen-x86-HYP-interrupt/arch/x86/kernel/irq.c
@@ -127,7 +127,7 @@ int
>>> On 13.01.15 at 14:29, wrote:
> Em Tue, Jan 13, 2015 at 08:48:35AM +, Jan Beulich escreveu:
>> Arnaldo,
>>
>> considering that tools/include/ gets used by other than just perf, in
>> particular arch/x86/vdso/vdso2c.c, would you mind clarifying how
>
Arnaldo,
considering that tools/include/ gets used by other than just perf, in
particular arch/x86/vdso/vdso2c.c, would you mind clarifying how
"tools: Move bitops.h from tools/perf/util to tools/" adding an
inclusion of asm/hweight.h to linux/bitops.h is supposed to work,
when the only potentiall
t hold zero all the time. Note
further that hardware NMI handling for PVH doesn't currently work
anyway due to missing code in the hypervisor (but it is expected to
work the native rather than the PV way).
Signed-off-by: Jan Beulich
Reviewed-by: Boris Ostrovsky
---
v2: Use DEFINE_GUEST_HANDLE
>>> On 09.01.15 at 13:51, wrote:
> On 09/01/15 09:57, Jan Beulich wrote:
>>>>> On 08.01.15 at 18:01, wrote:
>>> @@ -284,7 +286,7 @@ static void __init xen_update_mem_tables(unsigned long
>>> pfn, unsigned long mfn)
>>> }
>&
>>> On 08.01.15 at 18:01, wrote:
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -140,7 +140,7 @@ static void __init xen_del_extra_mem(u64 start, u64 size)
> unsigned long __ref xen_chk_extra_mem(unsigned long pfn)
> {
> int i;
> - unsigned long addr = PFN_PHYS(pfn);
> +
>>> On 07.01.15 at 17:30, wrote:
> On Wed, 2015-01-07 at 17:16 +0100, Imre Palik wrote:
>> From: "Palik, Imre"
>>
>> In Dom0's the use of the TSC clocksource (whenever it is stable enough to
>> be used) instead of the Xen clocksource should not cause any issues, as
>> Dom0 VMs never live-migrate
>>> David Vrabel 01/05/15 11:35 AM >>>
>On 19/12/14 16:16, Jan Beulich wrote:
>> Using the native code here can't work properly, as the hypervisor would
>> normally have cleared the two reason bits by the time Dom0 gets to see
>> the NMI (if passed to
>>> Andy Lutomirski 01/02/15 7:03 PM >>>
>On Jan 2, 2015 8:11 AM, "Jan Beulich" wrote:
>> Trying to guess what you mean by "this": A stack switch gets expressed by
>> CFI annotations just like any other frame pointer adjustments. See f
de -> IST exception -> NMI, then
>task_pt_regs is entirely uninitialized. Assuming all the CFI
>annotations are correct, the unwinder could still do it from the
>kernel.
>
>Note that, as far as I know, Jan Beulich is the only person who uses
>the unwinder on kernel code. Jan
>>> David Vrabel 12/23/14 12:01 PM >>>
>On 19/12/14 16:16, Jan Beulich wrote:
>> Using the native code here can't work properly, as the hypervisor would
>> normally have cleared the two reason bits by the time Dom0 gets to see
>> the NMI (if passed to
Commit-ID: 132978b94e66f8ad7d20790f8332f0e9c1426029
Gitweb: http://git.kernel.org/tip/132978b94e66f8ad7d20790f8332f0e9c1426029
Author: Jan Beulich
AuthorDate: Fri, 19 Dec 2014 16:10:54 +
Committer: Ingo Molnar
CommitDate: Tue, 23 Dec 2014 11:39:34 +0100
x86: Fix step size
e
that the hook can (and should) be used irrespective of whether being in
Dom0, as accessing port 0x61 in a DomU would be even worse, while the
shared info field would just hold zero all the time.
Signed-off-by: Jan Beulich
---
arch/x86/xen/enlighten.c| 22 +-
include/xen/
range boundary of zero can't really work well.
Signed-off-by: Jan Beulich
Cc: Yinghai Lu
---
arch/x86/mm/init.c | 34 +++---
1 file changed, 15 insertions(+), 19 deletions(-)
--- 3.18/arch/x86/mm/init.c
+++ 3.18-x86-init-mem-steps/arch/x86/mm/init.c
@@ -409,2
Commit-ID: 2414e021ac8d588f1b09f64891f69a3e26feadf1
Gitweb: http://git.kernel.org/tip/2414e021ac8d588f1b09f64891f69a3e26feadf1
Author: Jan Beulich
AuthorDate: Mon, 3 Nov 2014 08:39:43 +
Committer: Thomas Gleixner
CommitDate: Tue, 16 Dec 2014 14:08:14 +0100
x86: Avoid building
Commit-ID: e10679825924580845c4825deaaddf5331ff627c
Gitweb: http://git.kernel.org/tip/e10679825924580845c4825deaaddf5331ff627c
Author: Jan Beulich
AuthorDate: Mon, 3 Nov 2014 08:15:42 +
Committer: Thomas Gleixner
CommitDate: Tue, 16 Dec 2014 14:08:14 +0100
x86: irq: Fix placement
>>> On 15.12.14 at 12:38, wrote:
> On 11/12/14 18:04, Juergen Gross wrote:
>> --- a/arch/x86/syscalls/Makefile
>> +++ b/arch/x86/syscalls/Makefile
>
> Why are these changes here and not in arch/x86/xen/Makefile?
Because this needs to be done in a step that (afaict) has no hook
in the Xen-specifi
>>> On 12.12.14 at 23:48, wrote:
> On 12/11/2014 01:04 PM, Juergen Gross wrote:
>> diff --git a/scripts/xen-hypercalls.sh b/scripts/xen-hypercalls.sh
>> new file mode 100644
>> index 000..e6447b7
>> --- /dev/null
>> +++ b/scripts/xen-hypercalls.sh
>> @@ -0,0 +1,11 @@
>> +#!/bin/sh
>> +out="$1"
>>> On 11.12.14 at 00:34, wrote:
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -4239,6 +4239,16 @@ int __sched _cond_resched(void)
> }
> EXPORT_SYMBOL(_cond_resched);
>
> +int __sched cond_resched_irq(void)
> +{
> + if (should_resched()) {
> + preempt_schedule_ir
>>> On 04.12.14 at 12:07, wrote:
> On 03/12/14 21:40, Konrad Rzeszutek Wilk wrote:
>> From: Jan Beulich
>>
>> When a PF driver unloads, it may find it necessary to leave the VFs
>> around simply because of pciback having marked them as assigned to a
>>
>>> Konrad Rzeszutek Wilk 12/02/14 4:05 PM >>>
>On Tue, Dec 02, 2014 at 10:10:11AM +, Jan Beulich wrote:
>> >>> On 21.11.14 at 23:17, wrote:
>> > Konrad Rzeszutek Wilk (7):
>> > xen/pciback: Don't deadlock when unbinding.
>
>>> On 21.11.14 at 23:17, wrote:
> Konrad Rzeszutek Wilk (7):
> xen/pciback: Don't deadlock when unbinding.
> driver core: Provide an wrapper around the mutex to do lockdep warnings
> xen/pciback: Include the domain id if removing the device whilst still
> in use
> xen/pci
>>> On 10.11.14 at 13:13, wrote:
> * Jan Beulich wrote:
>> @@ -131,7 +131,7 @@
>> } while (0)
>>
>>
>> -#else /* !CONFIG_TRACE_IRQFLAGS_SUPPORT */
>> +#else /* !CONFIG_TRACE_IRQFLAGS */
>>
>> #define local_irq_en
>>> On 21.11.14 at 23:03, wrote:
> I rewrote it a bit to be more in the style of pciback:
>[...]
> [v2: Removed the switch statement, moved it about]
What you don't mention here is that you also removed the outer
loop, yet that breaks functionality afaict: There can (and I suppose
normally will)
t; Provide a get_required_mask op that uses the maximum MFN to calculate
> the DMA mask.
>
> Signed-off-by: David Vrabel
Reviewed-by: Jan Beulich
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
>>> On 13.11.14 at 11:38, wrote:
> On 12/11/14 15:55, Jan Beulich wrote:
>>>>> On 12.11.14 at 16:25, wrote:
>>> +u64
>>> +xen_swiotlb_get_required_mask(struct device *dev)
>>> +{
>>> + u64 max_mfn;
>>>
>>> On 13.11.14 at 11:25, wrote:
On 12.11.14 at 16:25, wrote:
>> --- a/arch/x86/include/asm/device.h
>> +++ b/arch/x86/include/asm/device.h
>> @@ -13,4 +13,6 @@ struct dev_archdata {
>> struct pdev_archdata {
>> };
>>
>> +#define ARCH_HAS_DMA_GET_REQUIRED_MASK
>
> Is there a particular
>>> On 12.11.14 at 16:25, wrote:
> --- a/arch/x86/include/asm/device.h
> +++ b/arch/x86/include/asm/device.h
> @@ -13,4 +13,6 @@ struct dev_archdata {
> struct pdev_archdata {
> };
>
> +#define ARCH_HAS_DMA_GET_REQUIRED_MASK
Is there a particular reason you put this here rather than in
dma-ma
>>> On 12.11.14 at 16:55, wrote:
On 12.11.14 at 16:25, wrote:
>> +u64
>> +xen_swiotlb_get_required_mask(struct device *dev)
>> +{
>> +u64 max_mfn;
>> +
>> +max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
>> +
>> +return DMA_BIT_MASK(fls64(max_mfn << PAGE_SHIFT) + 1
>>> On 12.11.14 at 21:36, wrote:
> On Mon, Nov 10, 2014 at 11:42 PM, Jan Beulich wrote:
>>
>> Nothing crashes with the unwind information being wrong. It is
>> solely you who was claiming (without proof) years ago that the
>> unwinder repeatedly caused issues
>>> On 12.11.14 at 17:59, wrote:
> On 12/11/14 15:55, Jan Beulich wrote:
>>>>> On 12.11.14 at 16:25, wrote:
>>> +u64
>>> +xen_swiotlb_get_required_mask(struct device *dev)
>>> +{
>>> + u64 max_mfn;
>>>
>>> On 12.11.14 at 16:25, wrote:
> +u64
> +xen_swiotlb_get_required_mask(struct device *dev)
> +{
> + u64 max_mfn;
> +
> + max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
> +
> + return DMA_BIT_MASK(fls64(max_mfn << PAGE_SHIFT) + 1);
> +}
The value the hypercall returns
>>> On 10.11.14 at 19:10, wrote:
> Btw, the sane thing to do is to make your infrastructure just say "If
> my frame walker hits a push/pop without CFI information, I'll just add
> it myself".
>
> Yes, that involved having to actuall ylook at the instruction. Tough
> shit. Just do it right. There
>>> On 10.11.14 at 18:56, wrote:
> So no. A very strong NACK. The code was too ugly to live, there is no good
> stated reason for it, and the only reason I can even remotely imagine is
> wrong and complete crap anyway (ie making the CFI annotations a correctness
> issue by introducing other infras
allows the driver to be loaded again with
it being able to create the VFs anew, but which also allows to then
pass through the PF instead of the VFs).
Don't do this however for any VFs currently in active use by a guest.
Signed-off-by: Jan Beulich
---
drivers/xen/xen-pciback/pci_stub.c |
>>> On 05.11.14 at 18:23, wrote:
> On Wed, Nov 5, 2014 at 9:13 AM, Jan Beulich wrote:
>>>>> Andy Lutomirski 11/04/14 8:40 PM >>>
>>>On 11/04/2014 01:24 AM, Jan Beulich wrote:
>>>> The main obstacle to having done this long ago was the nee
>>> Andy Lutomirski 11/04/14 8:40 PM >>>
>On 11/04/2014 01:24 AM, Jan Beulich wrote:
>> The main obstacle to having done this long ago was the need to
>> determine whether annotations are needed in the first place: They need
>> to be avoided when a frame
>>> Andy Lutomirski 11/04/14 8:33 PM >>>
>On 11/04/2014 12:49 AM, Jan Beulich wrote:
>> Observing that per-CPU data (in the SMP case) is reachable by
>> exploiting 64-bit address wraparound, these two patches
>> arrange for using the one byte shorter R
>>> "H. Peter Anvin" 11/04/14 9:11 PM >>>
>On 11/04/2014 11:45 AM, tip-bot for Jan Beulich wrote:
>> x86-64: Use RIP-relative addressing for most per-CPU accesses
>>
>> Observing that per-CPU data (in the SMP case) is reachable by
>> exploi
Commit-ID: 97b67ae559947f1e208439a1bf6a734da3087006
Gitweb: http://git.kernel.org/tip/97b67ae559947f1e208439a1bf6a734da3087006
Author: Jan Beulich
AuthorDate: Tue, 4 Nov 2014 08:50:48 +
Committer: Thomas Gleixner
CommitDate: Tue, 4 Nov 2014 20:43:14 +0100
x86-64: Use RIP-relative
Commit-ID: 6d24c5f72dfb26e5fa7f02fa9266dfdbae41adba
Gitweb: http://git.kernel.org/tip/6d24c5f72dfb26e5fa7f02fa9266dfdbae41adba
Author: Jan Beulich
AuthorDate: Tue, 4 Nov 2014 08:50:18 +
Committer: Thomas Gleixner
CommitDate: Tue, 4 Nov 2014 20:43:14 +0100
x86-64: Handle PC
Commit-ID: 2c773dd31fbacbbb6425f8a9d3f97e0010272368
Gitweb: http://git.kernel.org/tip/2c773dd31fbacbbb6425f8a9d3f97e0010272368
Author: Jan Beulich
AuthorDate: Tue, 4 Nov 2014 08:26:42 +
Committer: Thomas Gleixner
CommitDate: Tue, 4 Nov 2014 20:13:28 +0100
x86: Convert a few more
Commit-ID: 8c66877ee65ec4e6974e9aa69bc53abe4a603f10
Gitweb: http://git.kernel.org/tip/8c66877ee65ec4e6974e9aa69bc53abe4a603f10
Author: Jan Beulich
AuthorDate: Mon, 3 Nov 2014 08:39:43 +
Committer: Thomas Gleixner
CommitDate: Tue, 4 Nov 2014 20:11:59 +0100
x86: Avoid building
Commit-ID: 3b67bdc6599e25b082f12dbde6b0ce91dd235549
Gitweb: http://git.kernel.org/tip/3b67bdc6599e25b082f12dbde6b0ce91dd235549
Author: Jan Beulich
AuthorDate: Mon, 3 Nov 2014 08:15:42 +
Committer: Thomas Gleixner
CommitDate: Tue, 4 Nov 2014 19:12:41 +0100
x86: irq: Fix placement
s)
arch/x86/kernel/kprobes/
arch/x86/kernel/kvm/
drivers/char/i8k.c:i8k_smm()
drivers/char/toshiba.c:tosh_smm()
drivers/lguest/x86/
Signed-off-by: Jan Beulich
Cc: Tony Jones
---
arch/x86/Makefile| 22
arch/x86/include/as
he dependency on the minimum kernel load address, arbitrarily
low values for CONFIG_PHYSICAL_START are now no longer possible. A
link time assertion is being added, directing to the need to increase
that value when it triggers.
Signed-off-by: Jan Beulich
---
a
addressing for most per-CPU accesses
Signed-off-by: Jan Beulich
--
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 FA
This is in preparation of using RIP-relative addressing in many of the
per-CPU accesses.
Signed-off-by: Jan Beulich
---
arch/x86/boot/compressed/misc.c | 14 +-
arch/x86/tools/relocs.c | 38 --
2 files changed, 41 insertions(+), 11
t got converted to per-CPU data years ago).
Signed-off-by: Jan Beulich
---
arch/x86/include/asm/percpu.h|2 +-
arch/x86/include/asm/processor.h |4 ++--
arch/x86/kernel/setup_percpu.c |2 +-
arch/x86/kernel/smpboot.c|2 +-
4 files changed, 5 insertions(+), 5 dele
preceding it (which was slightly wrong from at least
from 2.6.37 onwards).
The code bloat was observed in reality with an experimental x86 patch
I'm about to post as RFC.
Signed-off-by: Jan Beulich
---
include/linux/irqflags.h |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- 3.1
401 - 500 of 1372 matches
Mail list logo
