>>> 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 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 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 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 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
>>> 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 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)
>>> 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
>>> 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 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
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
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/
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
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
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
>>> 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
>>> 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 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 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 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
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 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)) {
>> >
>>> 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
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
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
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
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
>>> 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 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
>>> 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 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,
>>> 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
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
>>> 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
>>> 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 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 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"
0x110
[] prepare_exit_to_usermode+0xe9/0xf0
[] retint_user+0x8/0x13
This is CVE-2016-3961 / XSA-174.
Reported-by: Vitaly Kuznetsov
Signed-off-by: Jan Beulich
Cc: sta...@vger.kernel.org
---
arch/x86/include/asm/hugetlb.h |1 +
1 file changed, 1 insertion(+)
--- 4.6-rc4/arch/x86/include/asm/hugetlb.h
++
nge for i386 users who turing it on manually and expect seeing the
> unhandled signal
> output in log, but nothing.
>
> This patch turns it on for i386 in do_trap().
>
> Signed-off-by: Jianyu Zhan
I've been carrying this patch for years, without ever being able to
decide
>>> On 22.04.16 at 20:03, wrote:
> On 04/22/2016 02:47 AM, tip-bot for Jan Beulich wrote:
>> Commit-ID: 103f6112f253017d7062cd74d17f4a514ed4485c
>> Gitweb:
> http://git.kernel.org/tip/103f6112f253017d7062cd74d17f4a514ed4485c
>> Author: Jan Beulich
>
>>> On 23.11.15 at 14:03, wrote:
> I was wondering if u could answer a question in that respect:
> arch/arc/kernel/unwind.c
>
> If the binary search for a PC fails, it resorts to linear search, which for
> our
> case was taking 3 million cycles (vs. normal ~2000).
> Do you remember why this lin
>>> On 23.11.15 at 14:27, wrote:
> On Monday 23 November 2015 06:45 PM, Jan Beulich wrote:
>>>>> On 23.11.15 at 14:03, wrote:
>>> I was wondering if u could answer a question in that respect:
>>> arch/arc/kernel/unwind.c
>>>
>>> I
>>> On 24.11.15 at 07:55, wrote:
> What about:
>
> 4) Instead of relying on the kernel maintained p2m list for m2p
>conversion use the hypervisor maintained m2p list which should be
>available in the dump as well. This is the way the alive kernel is
>working, so mimic it during crash
>>> On 08.02.19 at 20:58, wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch
> cases where we are expecting to fall through.
>
> Warning level 3 was used: -Wimplicit-fallthrough=3
>
> This patch is part of the ongoing efforts to enabling
> -Wimplicit-fallthrough.
>
> Signed
On 06.09.2019 17:55, Andrew Cooper wrote:
> On 06/09/2019 16:39, Arnd Bergmann wrote:
>> HYPERVISOR_platform_op() is an inline function and should not
>> be exported. Since commit 15bfc2348d54 ("modpost: check for
>> static EXPORT_SYMBOL* functions"), this causes a warning:
>>
>> WARNING: "HYPERVIS
On 10.09.2019 11:46, Igor Druzhinin wrote:
> On 10/09/2019 02:47, Boris Ostrovsky wrote:
>> On 9/9/19 5:48 PM, Igor Druzhinin wrote:
>>> Actually, pci_mmcfg_late_init() that's called out of acpi_init() -
>>> that's where MCFG areas are properly sized.
>>
>> pci_mmcfg_late_init() reads the (static)
On 01.09.2019 08:58, Adam Zerella wrote:
> This resolves a type conversion from 'char *' to 'unsigned short'.
Could you explain this? There's no ...
> --- a/arch/x86/xen/efi.c
> +++ b/arch/x86/xen/efi.c
> @@ -118,8 +118,8 @@ static enum efi_secureboot_mode
> xen_efi_get_secureboot(void)
>
On 04.09.2019 02:20, Igor Druzhinin wrote:
> If MCFG area is not reserved in E820, Xen by default will defer its usage
> until Dom0 registers it explicitly after ACPI parser recognizes it as
> a reserved resource in DSDT. Having it reserved in E820 is not
> mandatory according to "PCI Firmware Spec
On 04.09.2019 13:36, Igor Druzhinin wrote:
> On 04/09/2019 10:08, Jan Beulich wrote:
>> On 04.09.2019 02:20, Igor Druzhinin wrote:
>>> If MCFG area is not reserved in E820, Xen by default will defer its usage
>>> until Dom0 registers it explicitly after ACPI parser reco
On 11.09.2019 03:15, Igor Druzhinin wrote:
> Another thing that I implied by "not supporting" but want to explicitly
> call out is that currently Xen will refuse reserving any MCFG area
> unless it actually existed in MCFG table at boot. I don't clearly
> understand reasoning behind it but it might
On 02.10.2019 15:24, Boris Ostrovsky wrote:
> On 10/2/19 3:40 AM, Jan Beulich wrote:
>> On 01.10.2019 17:16, Boris Ostrovsky wrote:
>>> Currently execution of panic() continues until Xen's panic notifier
>>> (xen_panic_event()) is called at which point we make a
On 02.10.2019 16:14, Boris Ostrovsky wrote:
> On 10/2/19 9:42 AM, Jan Beulich wrote:
>>
>> I can only guess that the thinking probably was that e.g. external
>> dumping (by the tool stack) would be more reliable (including but
>> not limited to this meaning less ch
;
I don't think exporting an __init function is a good idea, and I also
don't see why the function would need exporting had it had the __init
dropped. With the line dropped
Reviewed-by: Jan Beulich
Jan
On 01.10.2019 17:16, Boris Ostrovsky wrote:
> Currently execution of panic() continues until Xen's panic notifier
> (xen_panic_event()) is called at which point we make a hypercall that
> never returns.
>
> This means that any notifier that is supposed to be called later as
> well as significant p
nt pt_regs")
Signed-off-by: Jan Beulich
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -48,6 +48,17 @@
#include "calling.h"
+#ifndef CONFIG_XEN_PV
+# define USER_SEGMENT_RPL_MASK SEGMENT_RPL_MASK
+#else
+/*
+ * When running paravirtualized on Xen the kernel
On 15.07.2019 19:28, Andy Lutomirski wrote:
> On Mon, Jul 15, 2019 at 9:34 AM Andi Kleen wrote:
>>
>> Juergen Gross writes:
>>
>>> The long term plan has been to replace Xen PV guests by PVH. The first
>>> victim of that plan are now 32-bit PV guests, as those are used only
>>> rather seldom thes
>>> On 22.01.19 at 09:06, wrote:
> Don't allow memory to be added above the allowed maximum allocation
> limit set by Xen.
This reads as if the hypervisor was imposing a limit here, but looking at
xen_get_max_pages(), xen_foreach_remap_area(), and
xen_count_remap_pages() I take it that it's a res
ts.
Fixes: 7f2590a110b837af5679d08fc25c6227c5a8c497
Signed-off-by: Jan Beulich
Cc: sta...@kernel.org
---
v3: Drop NMI path change. Use ALTERNATIVE.
v2: Correct placement of .Lint80_keep_stack label.
---
arch/x86/entry/entry_64_compat.S |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
--- 5.0-rc
>>> On 23.05.19 at 19:27, wrote:
> This fixes 53809751ac23 ("sscanf: don't ignore field widths for numeric
> conversions"). sscanf overflows integers with simple strings such as dates.
> As an example, consider
>
> r = sscanf("20190523123456", "%4d%2d%2d%2d%2d%2d",
> &year, &m
On 15.07.2019 07:05, Zhenzhong Duan wrote:
>
> On 2019/7/12 22:06, Andrew Cooper wrote:
>> On 11/07/2019 03:15, Zhenzhong Duan wrote:
>>> Commit 7457c0da024b ("x86/alternatives: Add int3_emulate_call()
>>> selftest") is used to ensure there is a gap setup in exception stack
>>> which could be used
On 22.07.2019 12:10, Thomas Gleixner wrote:
> On Thu, 11 Jul 2019, Arnd Bergmann wrote:
>
> Trimmed CC list and added Jan
>
>> See below for the patch I am using locally to work around this.
>> That patch is probably wrong, so I have not submitted it yet, but it
>> gives you a clean build ;-)
>>
>>> On 20.02.19 at 23:03, wrote:
> On 2/20/19 9:46 PM, Boris Ostrovsky wrote:
>> On 2/20/19 3:46 PM, Julien Grall wrote:
>>> On 2/20/19 8:04 PM, Boris Ostrovsky wrote:
On 2/20/19 1:05 PM, Julien Grall wrote:
Some sort of a FIFO that stores {irq, data} tuple. It could obviously be
im
#x27;t write ptes directly in 32-bit PV
> guests")
> Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
>>> On 14.03.18 at 23:47, wrote:
> On 03/13/2018 05:06 PM, Arnd Bergmann wrote:
>> The legacy hypercall handlers were originally added with
>> a comment explaining that "copying the argument structures in
>> HYPERVISOR_event_channel_op() and HYPERVISOR_physdev_op() into the local
>> variable is su
that code
path is unreachable when running an PV Xen guest afaict.
Signed-off-by: Jan Beulich
Cc: sta...@kernel.org
---
There would certainly have been the option of using alternatives
patching, but afaict the patching code isn't NMI / #MC safe, so I'd
rather stay away from patching
>>> On 05.12.16 at 22:32, wrote:
> static inline void sync_core(void)
> {
> - int tmp;
> -
> -#ifdef CONFIG_X86_32
> /*
> - * Do a CPUID if available, otherwise do a jump. The jump
> - * can conveniently enough be the jump around CPUID.
> + * There are quite a few ways
n-address bits, not just the ROM
Enable one.
Signed-off-by: Jan Beulich
Reviewed-by: Boris Ostrovsky
---
v3: Use ~0U in rom_write(), to account for PCI_ROM_ADDRESS_MASK being
of unsigned long type (relevant on 64-bit). (Note: Patch 2 is
unchanged, and hence not being re-sent. I hope that
single caller
4: simplify determination of 64-bit memory resource
5: use const and unsigned in bar_init()
6: short-circuit read path used for merging write values
7: drop superfluous variables
Signed-off-by: Jan Beulich
Signed-off-by: Jan Beulich
---
drivers/xen/xen-pciback/conf_space_header.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
--- 4.7-rc6-xen-pciback.orig/drivers/xen/xen-pciback/conf_space_header.c
+++ 4.7-rc6-xen-pciback/drivers/xen/xen-pciback/conf_space_header.c
@@ -210,8
It is now identical to bar_init().
Signed-off-by: Jan Beulich
---
drivers/xen/xen-pciback/conf_space_header.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
--- 4.7-rc6-xen-pciback.orig/drivers/xen/xen-pciback/conf_space_header.c
+++ 4.7-rc6-xen-pciback/drivers/xen/xen
Signed-off-by: Jan Beulich
---
drivers/xen/xen-pciback/conf_space_header.c | 33 +++-
1 file changed, 13 insertions(+), 20 deletions(-)
--- 4.7-rc6-xen-pciback.orig/drivers/xen/xen-pciback/conf_space_header.c
+++ 4.7-rc6-xen-pciback/drivers/xen/xen-pciback
Other than for raw BAR values, flags are properly separated in the
internal representation.
Signed-off-by: Jan Beulich
---
drivers/xen/xen-pciback/conf_space_header.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
--- 4.7-rc6-xen-pciback.orig/drivers/xen/xen-pciback
Signed-off-by: Jan Beulich
---
drivers/xen/xen-pciback/conf_space_header.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- 4.7-rc6-xen-pciback.orig/drivers/xen/xen-pciback/conf_space_header.c
+++ 4.7-rc6-xen-pciback/drivers/xen/xen-pciback/conf_space_header.c
@@ -211,8 +211,8
There's no point calling xen_pcibk_config_read() here - all it'll do is
return whatever conf_space_read() returns for the field which was found
here (and which would be found there again). Also there's no point
clearing tmp_val before the call.
Signed-off-by: Jan Beulich
---
req_start is simply an alias of the "offset" function parameter, and
req_end is being used just once in each function. (And both variables
were loop invariant anyway, so should at least have got initialized
outside the loop.)
Signed-off-by: Jan Beulich
---
drivers/xen/xen-pciback/co
Inability to locate a user mode specified transaction ID should not
lead to a kernel crash. For other than XS_TRANSACTION_START also
don't issue anything to xenbus if the specified ID doesn't match that
of any active transaction.
Signed-off-by: Jan Beulich
---
drivers/
1: don't bail early from xenbus_dev_request_and_reply()
2: simplify xenbus_dev_request_and_reply()
Signed-off-by: Jan Beulich
ce I can't identify whether a more complex
change might be needed here).
Signed-off-by: Jan Beulich
Cc: Konrad Rzeszutek Wilk
---
drivers/xen/xenbus/xenbus_xs.c |3 ---
1 file changed, 3 deletions(-)
--- 4.7-rc6-xen.orig/drivers/xen/xenbus/xenbus_xs.c
+++ 4.7-rc6-xen/drivers/xen/xen
No need to retain a local copy of the full request message, only the
type is really needed.
Signed-off-by: Jan Beulich
---
drivers/xen/xenbus/xenbus_xs.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
--- 4.7-rc6-xen.orig/drivers/xen/xenbus/xenbus_xs.c
+++ 4.7-rc6-xen/drivers
There's no reason why this would need to be limited to x86-64.
Signed-off-by: Jan Beulich
---
drivers/xen/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 4.7-rc6-xen.orig/drivers/xen/Kconfig
+++ 4.7-rc6-xen/drivers/xen/Kconfig
@@ -264,7 +264,7 @@ config XEN_ACPI_PROC
This already gets done in HYPERVISOR_mca().
Signed-off-by: Jan Beulich
---
drivers/xen/mcelog.c |2 --
1 file changed, 2 deletions(-)
--- 4.7-rc6-xen.orig/drivers/xen/mcelog.c
+++ 4.7-rc6-xen/drivers/xen/mcelog.c
@@ -288,7 +288,6 @@ static int mc_queue_handle(uint32_t flag
int ret
... over list_for_each_safe() when list modification if accompanied by
breaking out of the loop.
Signed-off-by: Jan Beulich
---
drivers/xen/xenbus/xenbus_dev_frontend.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- 4.7-rc6-xen.orig/drivers/xen/xenbus/xenbus_dev_frontend.c
Many of these operations can take arbitrarily long, which can become a
problem irrespective of them being exposed to privileged users only.
Signed-off-by: Jan Beulich
---
drivers/xen/privcmd.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
--- 4.7-rc6-xen.orig
Commit 9d092603cc ("xen-blkback: do not leak mode property") left one
path unfixed; correct this.
Signed-off-by: Jan Beulich
---
drivers/block/xen-blkback/xenbus.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
--- 4.7-rc6-xen.orig/drivers/block/xen-blkback/xenbus.c
+
The functions such get passed to have been taking pointers to const
since at least 2.6.16.
Signed-off-by: Jan Beulich
---
drivers/block/xen-blkback/xenbus.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 4.7-rc6-xen.orig/drivers/block/xen-blkback/xenbus.c
+++ 4.7-rc6-xen/drivers
The ioctl can be called prior to full device setup having completed.
Signed-off-by: Jan Beulich
---
drivers/block/xen-blkfront.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
--- 4.7-rc6-xen.orig/drivers/block/xen-blkfront.c
+++ 4.7-rc6-xen/drivers/block/xen-blkfront.c
Only a positive return value indicates success.
Signed-off-by: Jan Beulich
---
drivers/xen/manage.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 4.7-rc6-xenbus_scanf.orig/drivers/xen/manage.c
+++ 4.7-rc6-xenbus_scanf/drivers/xen/manage.c
@@ -275,7 +275,7 @@ static void
Set backend state to unknown when unsuccessful.
Signed-off-by: Jan Beulich
---
drivers/xen/xenbus/xenbus_probe_frontend.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- 4.7-rc6-xenbus_scanf.orig/drivers/xen/xenbus/xenbus_probe_frontend.c
+++ 4.7-rc6-xenbus_scanf/drivers/xen
... as being the simpler variant.
Signed-off-by: Jan Beulich
---
drivers/video/fbdev/xen-fbfront.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- 4.7-rc6-prefer-xenbus_write.orig/drivers/video/fbdev/xen-fbfront.c
+++ 4.7-rc6-prefer-xenbus_write/drivers/video/fbdev/xen
... for single items being collected: It is more typesafe (as the
compiler can check format string and to-be-written-to variable match)
and requires one less parameter to be passed.
Signed-off-by: Jan Beulich
---
drivers/block/xen-blkback/xenbus.c | 13 ++---
1 file changed, 6
... for single items being collected: It is more typesafe (as the
compiler can check format string and to-be-written-to variable match)
and requires one less parameter to be passed.
Signed-off-by: Jan Beulich
---
drivers/block/xen-blkfront.c | 43 +++
1
... as being the simpler variant.
Signed-off-by: Jan Beulich
---
drivers/block/xen-blkback/xenbus.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
--- 4.7-rc6-prefer-xenbus_write.orig/drivers/block/xen-blkback/xenbus.c
+++ 4.7-rc6-prefer-xenbus_write/drivers/block/xen-blkback
... as being the simpler variant.
Signed-off-by: Jan Beulich
---
drivers/block/xen-blkfront.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
--- 4.7-rc6-prefer-xenbus_write.orig/drivers/block/xen-blkfront.c
+++ 4.7-rc6-prefer-xenbus_write/drivers/block/xen-blkfront.c
... for single items being collected: It is more typesafe (as the
compiler can check format string and to-be-written-to variable match)
and requires one less parameter to be passed.
Signed-off-by: Jan Beulich
---
drivers/xen/xenbus/xenbus_client.c |6 +++---
1 file changed, 3 insertions
... as being the simpler variant.
Signed-off-by: Jan Beulich
---
drivers/xen/xen-pciback/pci_stub.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 4.7-rc6-prefer-xenbus_write.orig/drivers/xen/xen-pciback/pci_stub.c
+++ 4.7-rc6-prefer-xenbus_write/drivers/xen/xen-pciback
>>> On 07.07.16 at 11:32, wrote:
> On Thu, Jul 07, 2016 at 01:40:54AM -0600, Jan Beulich wrote:
>> The ioctl can be called prior to full device setup having completed.
>>
>> Signed-off-by: Jan Beulich
>> ---
>> drivers/block/xen-blkfront.c |6 ++-
>>> On 07.07.16 at 11:40, wrote:
> On 07/07/16 08:35, Jan Beulich wrote:
>> There's no reason why this would need to be limited to x86-64.
>
> Did you test it?
Well, its original version in the 2.6.18 tree did get enabled for 32-bit
use in the course of forward port
>>> On 07.07.16 at 11:44, wrote:
> On Thu, Jul 07, 2016 at 02:06:33AM -0600, Jan Beulich wrote:
>> ... as being the simpler variant.
>>
>> Signed-off-by: Jan Beulich
>> ---
>> drivers/block/xen-blkfront.c |7 +++
>> 1 file changed, 3
>>> On 07.07.16 at 13:36, wrote:
> On 07/07/16 08:32, Jan Beulich wrote:
>> We must not skip the transaction_end() call for a failed
>> XS_TRANSACTION_START. The removed code fragment got introduced by
>> commit 027bd7e899 ("xen/xenbus: Avoid synchronous
>>> On 07.07.16 at 14:17, wrote:
> On 07/07/16 13:09, Jan Beulich wrote:
>>>>> On 07.07.16 at 13:36, wrote:
>>> On 07/07/16 08:32, Jan Beulich wrote:
>>>> We must not skip the transaction_end() call for a failed
>>>> XS_TRANSACTION_ST
1001 - 1100 of 1374 matches
Mail list logo
