When xenbus_printf fails, the lack of error-handling code may
cause unexpected results.
This patch adds error-handling code after calling xenbus_printf.
Signed-off-by: Zhouyang Jia
---
v1->v2:
- Use xenbus_dev_error to report errors.
v2->v3:
- Fix compilation errors.
---
flight 124174 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124174/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-rtds broken
test-armhf-armhf-libvirt-xsm
flight 124191 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124191/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 7 xen-boot fail REGR. vs. 124090
On 06/15/2018 02:50 AM, Oleksandr Andrushchenko wrote:
> On 06/15/2018 09:46 AM, Juergen Gross wrote:
>> On 15/06/18 08:32, Oleksandr Andrushchenko wrote:
>>> Please note, that this will need a change (attached) while
>>> applying to the mainline kernel because of API changes [1].
>>>
>>>
On 06/15/2018 02:27 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> 1. Import a dma-buf with the file descriptor provided and export
>granted references to the pages of that dma-buf into the array
>of grant references.
>
> 2. Add API to close all references to an
On 06/15/2018 02:27 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> 1. Create a dma-buf from grant references provided by the foreign
>domain. By default dma-buf is backed by system memory pages, but
>by providing GNTDEV_DMA_FLAG_XXX flags it can also be created
>
On 06/15/2018 02:27 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Add UAPI and IOCTLs for dma-buf grant device driver extension:
> the extension allows userspace processes and kernel modules to
> use Xen backed dma-buf implementation. With this extension grant
>
On Fri, 15 Jun 2018, Ian Jackson wrote:
In XSA-254, we advertised siome special new branches, comet and vixen,
which were intended to be used as the shim in the PV-in-HVM shim
approaches to XSA-254 mitigation.
With my Debian maintainer hat on, I chose to do that. (I don't know,
of course,
flight 124190 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124190/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 xen-bootfail REGR. vs. 122969
When xenbus_printf fails, the lack of error-handling code may
cause unexpected results.
This patch adds error-handling code after calling xenbus_printf.
Signed-off-by: Zhouyang Jia
---
v1->v2:
- Use xenbus_dev_error to report errors.
---
drivers/xen/xen-scsiback.c | 18 --
1
As we move stuff around, some doc references are broken. Fix some of
them via this script:
./scripts/documentation-file-ref-check --fix
Manually checked if the produced result is valid, removing a few
false-positives.
Acked-by: Takashi Iwai
Acked-by: Masami Hiramatsu
Acked-by: Stephen
It is hard to reconcile the comment at the top of the loop in
vtd_set_hwdom_mapping() with the if statement following it. This patch
re-phrases the logic, preserving the semantics, but making it easier
to read.
The patch also modifies the Xen command line documentation to make it
clear that
When dom0-strict mode is enabled the iommu_inclusive_mapping workaround
for firmware with undeclared RMRRs is rendered useless. This series fixes
the problem.
Paul Durrant (2):
VT-d: re-phrase logic in vtd_set_hwdom_mapping() for clarity
VT-d: reconcile iommu_inclusive_mapping and
Juergen Gross writes ("Re: [Xen-devel] [PATCH 3/3] tools/libxc: retry hypercall
in case of EFAULT"):
> On 15/06/18 16:54, Andrew Cooper wrote:
> > Probably a very minor issue, but is it worth caching never_fault once
> > when opening the xc_interface? Calling into a separate shared object on
> >
Juergen Gross writes ("Re: [PATCH 1/3] tools/libxencall: use hypercall buffer
device if available"):
> On 15/06/18 16:48, Ian Jackson wrote:
> > I find this early exit approach a bit clumsy, but maybe putting all
> > the rest in an else branch would be worse.
>
> What about two sub-functions and
In XSA-254, we advertised siome special new branches, comet and vixen,
which were intended to be used as the shim in the PV-in-HVM shim
approaches to XSA-254 mitigation.
With my Debian maintainer hat on, I chose to do that. (I don't know,
of course, what proportion of Debian users are using shim
On 15/06/18 16:54, Andrew Cooper wrote:
> On 15/06/18 14:26, Juergen Gross wrote:
>> diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
>> index 03bc9a7776..18add80232 100644
>> --- a/tools/libxc/xc_private.h
>> +++ b/tools/libxc/xc_private.h
>> @@ -254,9 +254,12 @@ out1:
>>
On 15/06/18 16:48, Ian Jackson wrote:
> Juergen Gross writes ("[PATCH 1/3] tools/libxencall: use hypercall buffer
> device if available"):
>> Instead of using anonymous memory for hypercall buffers which is then
>> locked into memory, use the hypercall buffer device of the Linux
>> privcmd driver
This run is configured for baseline tests only.
flight 74871 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74871/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 15
On Fri, 15 Jun 2018, Anthony PERARD wrote:
> On Fri, Jun 15, 2018 at 11:06:47AM +0100, Peter Maydell wrote:
> > On 5 June 2018 at 17:55, Anthony PERARD wrote:
> > > On Fri, Jun 01, 2018 at 06:59:10PM +0100, Peter Maydell wrote:
> > >> The xen pci_assign_dev_load_option_rom() currently creates a
On 15/06/18 16:43, Boris Ostrovsky wrote:
> On 06/15/2018 09:17 AM, Juergen Gross wrote:
>> +static int privcmd_buf_mmap(struct file *file, struct vm_area_struct *vma)
>> +{
>> +struct privcmd_buf_private *file_priv = file->private_data;
>> +struct privcmd_buf_vma_private *vma_priv;
>> +
On 15/06/18 16:35, Jan Beulich wrote:
On 15.06.18 at 15:17, wrote:
>> --- /dev/null
>> +++ b/drivers/xen/privcmd-buf.c
>> @@ -0,0 +1,216 @@
>> +// SPDX-License-Identifier: GPL-2.0 OR MIT
>> +
>> +/**
>> + *
>>> On 08.06.18 at 17:07, wrote:
> No functional change.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
>>> On 08.06.18 at 17:07, wrote:
> The value written by the guest must be valid according to the mask
> provided in the interrupt routing capabilities register. If the
> interrupt is not valid set it to the first valid IRQ in the
> capabilities field if the timer is enabled, else just clear the
On Thu, Jun 14, 2018 at 08:33:17AM -0600, Jan Beulich wrote:
> > So far I've not been able to make Xen panic with the new xen kernel.
> > Attached is a log of the serial console, in case you notice something.
>
> None of the printk()s replacing ASSERT()s have triggered, so nothing
> interesting
flight 124186 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124186/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. vs.
123091
On 15/06/18 14:26, Juergen Gross wrote:
> diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
> index 03bc9a7776..18add80232 100644
> --- a/tools/libxc/xc_private.h
> +++ b/tools/libxc/xc_private.h
> @@ -254,9 +254,12 @@ out1:
> return ret;
> }
>
> -static inline int
Juergen Gross writes ("[PATCH 3/3] tools/libxc: retry hypercall in case of
EFAULT"):
> A hypercall issued via the privcmd driver can very rarely return
> -EFAULT even if the hypercall buffers are locked in memory. This
> happens for hypercall buffers in user memory when the Linux kernel
> is
Juergen Gross writes ("[PATCH 2/3] tools/libxencalls: add new function to query
hypercall buffer safety"):
> Add a new function to query whether hypercall buffers are always safe
> to access by the hypervisor or might result in EFAULT.
Acked-by: Ian Jackson
Juergen Gross writes ("[PATCH 1/3] tools/libxencall: use hypercall buffer
device if available"):
> Instead of using anonymous memory for hypercall buffers which is then
> locked into memory, use the hypercall buffer device of the Linux
> privcmd driver if available.
>
> This has the advantage of
On 06/15/2018 09:17 AM, Juergen Gross wrote:
> +static int privcmd_buf_mmap(struct file *file, struct vm_area_struct *vma)
> +{
> + struct privcmd_buf_private *file_priv = file->private_data;
> + struct privcmd_buf_vma_private *vma_priv;
> + unsigned int count = vma_pages(vma);
> +
On Fri, Jun 15, 2018 at 11:06:47AM +0100, Peter Maydell wrote:
> On 5 June 2018 at 17:55, Anthony PERARD wrote:
> > On Fri, Jun 01, 2018 at 06:59:10PM +0100, Peter Maydell wrote:
> >> The xen pci_assign_dev_load_option_rom() currently creates a RAM
> >> memory region with
On 15/06/18 16:15, Andrew Cooper wrote:
> On 15/06/18 14:17, Juergen Gross wrote:
>> +MODULE_LICENSE("GPL");
>> +
>> +static int limit = 64;
>> +module_param(limit, int, 0644);
>> +MODULE_PARM_DESC(limit, "Maximum number of pages that may be allocated by "
>> +"the privcmd-buf
>>> On 15.06.18 at 15:17, wrote:
> --- /dev/null
> +++ b/drivers/xen/privcmd-buf.c
> @@ -0,0 +1,216 @@
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> +
> +/**
> + * privcmd-buf.c
> + *
> + * Mmap of hypercall buffers.
>
On 15/06/18 16:06, Jan Beulich wrote:
On 15.06.18 at 15:26, wrote:
>> Add a new function to query whether hypercall buffers are always safe
>> to access by the hypervisor or might result in EFAULT.
>>
>> Signed-off-by: Juergen Gross
>> ---
>> tools/libs/call/Makefile | 2 +-
>>
On 15/06/18 14:17, Juergen Gross wrote:
> +MODULE_LICENSE("GPL");
> +
> +static int limit = 64;
> +module_param(limit, int, 0644);
> +MODULE_PARM_DESC(limit, "Maximum number of pages that may be allocated by "
> + "the privcmd-buf device per open file");
I have a feeling that,
>>> On 15.06.18 at 15:26, wrote:
> Add a new function to query whether hypercall buffers are always safe
> to access by the hypervisor or might result in EFAULT.
>
> Signed-off-by: Juergen Gross
> ---
> tools/libs/call/Makefile | 2 +-
> tools/libs/call/freebsd.c | 5 +
>
Hello. Some update on my 4.11rc6 tests. In brief, Linux guest
migration works fine. Some issues with NetBSD guests' migrations but
this is not necessarily related to 4.11rc6. I am rather addressing this
to the port-xen netbsd mailing-list.
In detail, I am maintaining a farm of 4 XEN hosts
On Linux systems hypercall buffers in user memory are allocated with
MAP_LOCKED attribute. Unfortunately that doesn't mean that the buffer
will always be accessible by the hypervisor, as the kernel might set
the PTE for the buffer to invalid or read only for short periods of
time, e.g. due to page
Add a new function to query whether hypercall buffers are always safe
to access by the hypervisor or might result in EFAULT.
Signed-off-by: Juergen Gross
---
tools/libs/call/Makefile | 2 +-
tools/libs/call/freebsd.c | 5 +
tools/libs/call/include/xencall.h | 7 +++
A hypercall issued via the privcmd driver can very rarely return
-EFAULT even if the hypercall buffers are locked in memory. This
happens for hypercall buffers in user memory when the Linux kernel
is doing memory scans e.g. for page migration or compaction.
Retry the getpageframeinfo3 hypercall
Instead of using anonymous memory for hypercall buffers which is then
locked into memory, use the hypercall buffer device of the Linux
privcmd driver if available.
This has the advantage of needing just a single mmap() for allocating
the buffer and page migration or compaction can't make the
For passing arbitrary data from user land to the Xen hypervisor the
Xen tools today are using mlock()ed buffers. Unfortunately the kernel
might change access rights of such buffers for brief periods of time
e.g. for page migration or compaction, leading to access faults in the
hypervisor, as the
On 06/14/2018 07:34 PM, Zhouyang Jia wrote:
> When xenbus_printf fails, the lack of error-handling code may
> cause unexpected results.
>
> This patch adds error-handling code after calling xenbus_printf.
>
> Signed-off-by: Zhouyang Jia
Reviewed-by: Boris Ostrovsky
(I wasn't asking you to use
flight 124213 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124213/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
flight 74872 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74872/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-armhf-jessie-netboot-pygrub 10 debian-di-install fail like
74806
baseline version:
Hi,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on xen-tip/linux-next]
[also build test ERROR on v4.17 next-20180615]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
Ian Jackson writes ("Re: [osstest] add FreeBSD flight"):
> Thanks. It LGTM. I have rebased it again and put it in
> ~osstest/branches/for-freebsd-master.git#master and am now running an
> instance of the cron job run (with --real, ie as if actually run from
> cron).
This did not work,
Ian Jackson writes ("Re: [osstest] add FreeBSD flight"):
> We are discussing this on IRC. Meanwhile I have unblessed 124214.
11:52 Diziet: I've managed to build new images in
http://logs.test-lab.xenproject.org/osstest/logs/124163/ maybe
those will have the right
"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate. The baseline, if
any, is the most recent actually tested revision.
flight 124214 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124214/
Failures and
Roger Pau Monné writes ("[osstest] add FreeBSD flight"):
> I've run a test flight of my FreeBSD osstest series today, the flight
> shows all green:
>
> http://logs.test-lab.xenproject.org/osstest/logs/124163/
>
> The series can be found at:
>
> git://xenbits.xen.org/people/royger/osstest.git
From: Oleksandr Grytsov
Add PV sound device described in sndif.h
Signed-off-by: Oleksandr Grytsov
Acked-by: Wei Liu
---
tools/libxl/Makefile | 2 +-
tools/libxl/libxl.h | 14 ++
tools/libxl/libxl_create.c | 1 +
tools/libxl/libxl_internal.h
From: Oleksandr Grytsov
Update documentation with virtual sound device
Signed-off-by: Oleksandr Grytsov
Acked-by: Wei Liu
---
docs/man/xl.cfg.pod.5.in | 149 +++
docs/man/xl.pod.1.in | 30
2 files changed, 179 insertions(+)
diff --git
From: Oleksandr Grytsov
Add CLI commands to attach, detach and list virtual sound devices
Signed-off-by: Oleksandr Grytsov
Acked-by: Wei Liu
---
tools/xl/Makefile | 2 +-
tools/xl/xl.h | 3 +
tools/xl/xl_cmdtable.c | 15 +++
tools/xl/xl_vsnd.c | 206
On Fri, Jun 15, 2018 at 10:06:15AM +0200, Roger Pau Monné wrote:
> Adding Daniel Kiper.
>
> On Wed, Jun 13, 2018 at 02:09:45AM +0300, Kristaps Čivkulis wrote:
> > Hello,
> >
> > I am implementing Multiboot2 support for FreeBSD loader to load Xen
> > kernel. Currently I pass EFI 64-bit system table
From: Oleksandr Grytsov
Add config parser for virtual sound devices
Signed-off-by: Oleksandr Grytsov
Acked-by: Wei Liu
---
tools/xl/xl_parse.c | 246
tools/xl/xl_parse.h | 1 +
2 files changed, 247 insertions(+)
diff --git a/tools/xl/xl_parse.c
From: Oleksandr Grytsov
This patch set adds PV sound device support to xl.cfg and xl.
See sndif.h for protocol implementation details.
Changes since v2:
* address comments
* rename libxl_vsnd_stream.id -> libxl_vsnd_stream.unique_id
* use XENSND_FIELD_... defines in xl_parse.c and xl_vsnd.c
On 5 June 2018 at 17:55, Anthony PERARD wrote:
> On Fri, Jun 01, 2018 at 06:59:10PM +0100, Peter Maydell wrote:
>> The xen pci_assign_dev_load_option_rom() currently creates a RAM
>> memory region with memory_region_init_ram_nomigrate(), and then
>> manually registers it with
>>> On 15.06.18 at 11:27, wrote:
> On 15/06/18 09:47, Jan Beulich wrote:
>> As both XenRT and osstest have found, the XSA-267 patches overlooked a
>> special case in HVM insn emulation. While looking into this I've also
> noticed
>> an omission in the sibling function to the one needing to be
From: Oleksandr Andrushchenko
Dan Carpenter has reported that there is the following static checker
warning:
drivers/gpu/drm/drm_prime.c:317 drm_gem_map_dma_buf()
warn: 'sgt' can also be NULL
314 sgt = obj->dev->driver->gem_prime_get_sg_table(obj);
315
316 if
flight 124181 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124181/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw 5 host-ping-check-native fail REGR. vs. 123389
On 15/06/18 10:47, Jan Beulich wrote:
> As both XenRT and osstest have found, the XSA-267 patches overlooked a
> special case in HVM insn emulation. While looking into this I've also noticed
> an omission in the sibling function to the one needing to be changed. At
> least patch 1 should be
On 15/06/18 09:47, Jan Beulich wrote:
> As both XenRT and osstest have found, the XSA-267 patches overlooked a
> special case in HVM insn emulation. While looking into this I've also noticed
> an omission in the sibling function to the one needing to be changed. At
> least patch 1 should be
In fully eager mode we must not clear fpu_dirtied, set CR0.TS, or invoke
the fpu_leave() hook. Instead do what the mode's name says: Restore
state right away.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -2139,13 +2139,20 @@ static void
As both XenRT and osstest have found, the XSA-267 patches overlooked a
special case in HVM insn emulation. While looking into this I've also noticed
an omission in the sibling function to the one needing to be changed. At
least patch 1 should be strongly considered for 4.11; patch 2 will need
flight 124188 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124188/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 123814
build-i386-libvirt
flight 124184 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124184/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 124058
version targeted for
Adding Daniel Kiper.
On Wed, Jun 13, 2018 at 02:09:45AM +0300, Kristaps Čivkulis wrote:
> Hello,
>
> I am implementing Multiboot2 support for FreeBSD loader to load Xen
> kernel. Currently I pass EFI 64-bit system table pointer tag, EFI boot
> services not terminated tag, EFI 64-bit image handle
On Thu, Jun 14, 2018 at 9:33 PM, Philippe Mathieu-Daudé wrote:
> On 06/14/2018 04:17 PM, John Snow wrote:
>> On 06/14/2018 12:44 PM, Stefan Hajnoczi wrote:
>>> Determining the size of a field is useful when you don't have a struct
>>> variable handy. Open-coding this is ugly.
>>>
>>> This patch
On 06/15/2018 09:46 AM, Juergen Gross wrote:
On 15/06/18 08:32, Oleksandr Andrushchenko wrote:
Please note, that this will need a change (attached) while
applying to the mainline kernel because of API changes [1].
Unfortunately, current Xen tip kernel tree is v4.17-rc5 based,
so I cannot make
Please note, that this will need a change (attached) while
applying to the mainline kernel because of API changes [1].
Unfortunately, current Xen tip kernel tree is v4.17-rc5 based,
so I cannot make the change in this patch now.
[1]
From: Oleksandr Andrushchenko
Allow mappings for DMA backed buffers if grant table module
supports such: this extends grant device to not only map buffers
made of balloon pages, but also from buffers allocated with
dma_alloc_xxx.
Signed-off-by: Oleksandr Andrushchenko
Reviewed-by: Boris
From: Oleksandr Andrushchenko
Extend grant table module API to allow allocating buffers that can
be used for DMA operations and mapping foreign grant references
on top of those.
The resulting buffer is similar to the one allocated by the balloon
driver in that proper memory reservation is made
From: Oleksandr Andrushchenko
This is in preparation for adding support of DMA buffer
functionality: make map/unmap related code and structures, used
privately by gntdev, ready for dma-buf extension, which will re-use
these. Rename corresponding structures as those become non-private
to gntdev
From: Oleksandr Andrushchenko
1. Create a dma-buf from grant references provided by the foreign
domain. By default dma-buf is backed by system memory pages, but
by providing GNTDEV_DMA_FLAG_XXX flags it can also be created
as a DMA write-combine/coherent buffer, e.g. allocated with
From: Oleksandr Andrushchenko
Memory {increase|decrease}_reservation and VA mappings update/reset
code used in balloon driver can be made common, so other drivers can
also re-use the same functionality without open-coding.
Create a dedicated file for the shared code and export corresponding
From: Oleksandr Andrushchenko
1. Import a dma-buf with the file descriptor provided and export
granted references to the pages of that dma-buf into the array
of grant references.
2. Add API to close all references to an imported buffer, so it can be
released by the owner. This is only
From: Oleksandr Andrushchenko
Only gnttab_{alloc|free}_pages are exported as EXPORT_SYMBOL
while all the rest are exported as EXPORT_SYMBOL_GPL, thus
effectively making it not possible for non-GPL driver modules
to use grant table module. Export gnttab_{alloc|free}_pages as
EXPORT_SYMBOL_GPL so
From: Oleksandr Andrushchenko
This work is in response to my previous attempt to introduce Xen/DRM
zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based
frontends/backends. There is also an existing hyper_dmabuf approach
available [3] which, if reworked to utilize the proposed
From: Oleksandr Andrushchenko
Add UAPI and IOCTLs for dma-buf grant device driver extension:
the extension allows userspace processes and kernel modules to
use Xen backed dma-buf implementation. With this extension grant
references to the pages of an imported dma-buf can be exported
for other
From: Oleksandr Andrushchenko
Make set/clear page private code shared and accessible to
other kernel modules which can re-use these instead of open-coding.
Signed-off-by: Oleksandr Andrushchenko
Reviewed-by: Boris Ostrovsky
---
drivers/xen/grant-table.c | 54
/linux/commits/linux-kernel-owner-vger-kernel-org/scsi-xen-scsifront-add-error-handling-for-xenbus_printf/20180615-094919
base: https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git linux-next
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF
82 matches
Mail list logo
