On Sat, Mar 02, 2024 at 08:45:39PM -0800, Andrew Paniakin wrote:
> From: Andrew Panyakin
>
> From: Maximilian Heyne
>
> Commit fa765c4b4aed2d64266b694520ecb025c862c5a9 upstream
>
> shutdown_pirq and startup_pirq are not taking the
> irq_mapping_update_lock because they can't due to lock
d7ddcdd8aa
>
> Cc: Greg Kroah-Hartman
> Signed-off-by: Ricardo B. Marliere
Reviewed-by: Greg Kroah-Hartman
On Fri, Oct 20, 2023 at 05:15:27PM +0100, David Woodhouse wrote:
> From: David Woodhouse
>
> The xencons_connect_backend() function allocates a local interdomain
> event channel with xenbus_alloc_evtchn(), then calls
> bind_interdomain_evtchn_to_irq_lateeoi() to bind to that port# on the
>
On Mon, Oct 02, 2023 at 08:47:53AM +, Christophe Leroy wrote:
>
>
> Le 02/10/2023 à 10:17, Jiri Slaby a écrit :
> > On 28. 09. 23, 15:21, Joel Granados via B4 Relay wrote:
> >> From: Joel Granados
> >>
> >> This commit comes at the tail end of a greater effort to remove the
> >> empty
On Thu, Sep 28, 2023 at 03:21:26PM +0200, Joel Granados via B4 Relay wrote:
> From: Joel Granados
>
> This commit comes at the tail end of a greater effort to remove the
> empty elements at the end of the ctl_table arrays (sentinels) which
> will reduce the overall build time size of the kernel
om CMA (not implemented in this series yet).
>
> I have no good explanation for the increase in performance of the
> 24-thread I/O test with the default (non-growing) memory pool. Although the
> difference is within variance, it seems to be real. The average bandwidth
> is consistently above that of the unpatched kernel.
>
> To sum it up:
>
> - All workloads benefit from reduced memory footprint.
> - No performance regressions have been observed with the default size of
> the software IO TLB.
> - Most workloads retain their former performance even if the software IO
> TLB grows at run time.
>
For the driver-core touched portions:
Reviewed-by: Greg Kroah-Hartman
On Thu, Jul 06, 2023 at 02:22:50PM +, Michael Kelley (LINUX) wrote:
> From: Greg Kroah-Hartman Sent: Thursday, July 6,
> 2023 1:07 AM
> >
> > On Thu, Jul 06, 2023 at 03:50:55AM +, Michael Kelley (LINUX) wrote:
> > > From: Petr Tesarik Sent: Tuesday, June
On Thu, Jul 06, 2023 at 03:50:55AM +, Michael Kelley (LINUX) wrote:
> From: Petr Tesarik Sent: Tuesday, June 27, 2023
> 2:54 AM
> >
> > Try to allocate a transient memory pool if no suitable slots can be found,
> > except when allocating from a restricted pool. The transient pool is just
>
On Tue, Jun 27, 2023 at 11:54:23AM +0200, Petr Tesarik wrote:
> +/**
> + * is_swiotlb_active() - check if the software IO TLB is initialized
> + * @dev: Device to check, or %NULL for the default IO TLB.
> + */
> bool is_swiotlb_active(struct device *dev)
> {
> - struct io_tlb_mem *mem =
On Wed, Jun 21, 2023 at 11:09:57AM +0200, Joel Granados wrote:
> static int __init random_sysctls_init(void)
> {
> - register_sysctl_init("kernel/random", random_table);
> + register_sysctl_init("kernel/random", random_table,
> + ARRAY_SIZE(random_table));
As
Stabellini
Cc: Oleksandr Tyshchenko
Cc: xen-devel@lists.xenproject.org
Signed-off-by: Greg Kroah-Hartman
---
include/xen/xenbus.h | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/include/xen/xenbus.h b/include/xen/xenbus.h
index eaa932b99d8a..b31f77f9c50c 100644
--- a/include/xen
On Mon, Dec 19, 2022 at 04:37:10PM +0100, Pratyush Yadav wrote:
> The removal of "hotplug-status" has moved around a bit. First it was
> moved from netback_remove() to hotplug_status_changed() in upstream
> commit 1f2565780e9b ("xen-netback: remove 'hotplug-status' once it has
> served its
On Sun, Oct 30, 2022 at 03:12:40AM -0400, Demi Marie Obenour wrote:
> I backported the recent gntdev patches to stable branches before 5.15.
> The first patch is a prerequisite for the other backports. The second
> patch should apply cleanly to all stable branches, but the third only
> applies to
On Sun, Oct 30, 2022 at 03:12:43AM -0400, Demi Marie Obenour wrote:
> From: "M. Vefa Bicakci"
>
> Prior to this commit, the gntdev driver code did not handle the
> following scenario correctly with paravirtualized (PV) Xen domains:
This is already in 5.10.152, do we need to add it again?
On Mon, Oct 24, 2022 at 07:41:27PM +0200, Pavel Machek wrote:
> Hi!
>
> > From: Kees Cook
> >
> > [ Upstream commit 3e1730842f142add55dc658929221521a9ea62b6 ]
> >
> > Clang produces a false positive when building with CONFIG_FORTIFY_SOURCE=y
> > and CONFIG_UBSAN_BOUNDS=y when operating on an
From: Kees Cook
[ Upstream commit 3e1730842f142add55dc658929221521a9ea62b6 ]
Clang produces a false positive when building with CONFIG_FORTIFY_SOURCE=y
and CONFIG_UBSAN_BOUNDS=y when operating on an array with a dynamic
offset. Work around this by using a direct assignment of an empty
instance.
From: Kees Cook
[ Upstream commit 3e1730842f142add55dc658929221521a9ea62b6 ]
Clang produces a false positive when building with CONFIG_FORTIFY_SOURCE=y
and CONFIG_UBSAN_BOUNDS=y when operating on an array with a dynamic
offset. Work around this by using a direct assignment of an empty
instance.
From: Kees Cook
[ Upstream commit 3e1730842f142add55dc658929221521a9ea62b6 ]
Clang produces a false positive when building with CONFIG_FORTIFY_SOURCE=y
and CONFIG_UBSAN_BOUNDS=y when operating on an array with a dynamic
offset. Work around this by using a direct assignment of an empty
instance.
From: Kees Cook
[ Upstream commit 3e1730842f142add55dc658929221521a9ea62b6 ]
Clang produces a false positive when building with CONFIG_FORTIFY_SOURCE=y
and CONFIG_UBSAN_BOUNDS=y when operating on an array with a dynamic
offset. Work around this by using a direct assignment of an empty
instance.
From: Kees Cook
[ Upstream commit 3e1730842f142add55dc658929221521a9ea62b6 ]
Clang produces a false positive when building with CONFIG_FORTIFY_SOURCE=y
and CONFIG_UBSAN_BOUNDS=y when operating on an array with a dynamic
offset. Work around this by using a direct assignment of an empty
instance.
From: Kees Cook
[ Upstream commit 3e1730842f142add55dc658929221521a9ea62b6 ]
Clang produces a false positive when building with CONFIG_FORTIFY_SOURCE=y
and CONFIG_UBSAN_BOUNDS=y when operating on an array with a dynamic
offset. Work around this by using a direct assignment of an empty
instance.
From: Kees Cook
[ Upstream commit 3e1730842f142add55dc658929221521a9ea62b6 ]
Clang produces a false positive when building with CONFIG_FORTIFY_SOURCE=y
and CONFIG_UBSAN_BOUNDS=y when operating on an array with a dynamic
offset. Work around this by using a direct assignment of an empty
instance.
On Wed, Aug 24, 2022 at 03:52:27PM +0200, Juergen Gross wrote:
> On 24.08.22 14:10, Greg Kroah-Hartman wrote:
> > On Wed, Aug 24, 2022 at 01:20:22PM +0200, Juergen Gross wrote:
> > > Hi Greg,
> > >
> > > stable kernels 5.18 and 5.15 seem to be missing upstream
On Wed, Aug 24, 2022 at 01:20:22PM +0200, Juergen Gross wrote:
> Hi Greg,
>
> stable kernels 5.18 and 5.15 seem to be missing upstream patch
> c64cc2802a78 ("x86/entry: Move CLD to the start of the idtentry macro").
> This is a prerequisite patch for 64cbd0acb582 ("x86/entry: Don't call
>
On Fri, Jul 22, 2022 at 11:44:10PM -0400, Demi Marie Obenour wrote:
> This series backports upstream commit 166d3863231667c4f64dee72b77d1102cdfad11f
> to all supported stable kernel trees.
All now queued up, thanks.
greg k-h
://lkml.kernel.org/r/156777566048.25081.6296162369492175325.stgit@devnote2
Signed-off-by: Maximilian Heyne
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/kernel/kprobes/core.c |4
1 file changed, 4 insertions(+)
--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -358,6
Dunlap
Link:
https://lkml.kernel.org/r/156777564986.25081.4964537658500952557.stgit@devnote2
[mheyne: resolved contextual conflict in tools/objtools/sync-check.sh]
Signed-off-by: Maximilian Heyne
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/include/asm/insn.h |6
@devnote2
Signed-off-by: Maximilian Heyne
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/include/asm/emulate_prefix.h | 14 ++
arch/x86/include/asm/xen/interface.h | 11 ---
arch/x86/kvm/x86.c|4 +++-
3 files changed, 21 insertions(+), 8 deletions
-by: Greg Kroah-Hartman
---
arch/x86/include/asm/asm.h |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
--- a/arch/x86/include/asm/asm.h
+++ b/arch/x86/include/asm/asm.h
@@ -7,9 +7,11 @@
# define __ASM_FORM_RAW(x) x
# define __ASM_FORM_COMMA(x) x,
#else
-# define __ASM_FORM(x
> 1 file changed, 13 insertions(+), 42 deletions(-)
Acked-by: Greg Kroah-Hartman
tions(+), 8 deletions(-)
Acked-by: Greg Kroah-Hartman
On Wed, Mar 16, 2022 at 06:29:00AM +0100, Juergen Gross wrote:
> On 15.03.22 18:41, Greg Kroah-Hartman wrote:
> > On Fri, Mar 11, 2022 at 11:35:09AM +0100, Juergen Gross wrote:
> > > Make sure a malicious backend can't cause any harm other than wrong
> > > I/O
On Fri, Mar 11, 2022 at 11:35:09AM +0100, Juergen Gross wrote:
> Make sure a malicious backend can't cause any harm other than wrong
> I/O data.
>
> Missing are verification of the request id in a response, sanitizing
> the reported actual I/O length, and protection against interrupt storms
>
On Sat, Mar 05, 2022 at 11:33:58PM +0800, zhanglianjie wrote:
> Hi,
>
> 在 2022/3/5 21:55, Greg Kroah-Hartman 写道:
> > On Sat, Mar 05, 2022 at 09:38:23PM +0800, zhanglianjie wrote:
> > > Use helper macro __ATTR_RW to define HYPERVISOR_ATTR_RW to make code more
> > &g
On Sat, Mar 05, 2022 at 09:38:23PM +0800, zhanglianjie wrote:
> Use helper macro __ATTR_RW to define HYPERVISOR_ATTR_RW to make code more
> clear.
> Minor readability improvement.
>
> Signed-off-by: zhanglianjie
Is this the name you sign legal documents with? (I have to ask...)
>
> diff
/msi.c | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
Reviewed-by: Greg Kroah-Hartman
ice now.
Fix that be deleting the now superfluous increments after calling that
function.
Signed-off-by: Juergen Gross
Signed-off-by: Greg Kroah-Hartman
---
drivers/block/xen-blkfront.c |4
1 file changed, 4 deletions(-)
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@
>
> Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
errupts.
>
> Remove the MSI[-X] teardown from pcim_release() and add an explicit action
> to be installed on the attempt of enabling PCI/MSI[-X].
>
> This allows the MSI core data allocation to be ordered correctly in a
> subsequent step.
>
> Reported-by: Nishanth Menon
> Signed-off-by: Thomas Gleixner
> ---
> V4: New patch
Reviewed-by: Greg Kroah-Hartman
On Fri, Dec 03, 2021 at 01:50:44PM +0100, Juergen Gross wrote:
> On 03.12.21 13:49, Greg Kroah-Hartman wrote:
> > On Tue, Nov 23, 2021 at 02:20:47PM +0100, Juergen Gross wrote:
> > > Introduces the Xen pvUSB frontend. With pvUSB it is possible for a Xen
> > > domU to co
On Fri, Dec 10, 2021 at 11:18:47PM +0100, Thomas Gleixner wrote:
> From: Thomas Gleixner
>
> instead of fiddling with MSI descriptors.
>
> Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
buse. The only function which is relevant for drivers is msi_get_virq().
> + */
> +
> #include
> #include
> #include
>
Ah, to be young and idealistic and hope that kernel developers read
comments in header files :)
You might want to add this to the driver-api kernel doc build?
Anyway, looks good to me:
Reviewed-by: Greg Kroah-Hartman
oss
> Reviewed-by: Jason Gunthorpe
Reviewed-by: Greg Kroah-Hartman
On Mon, Dec 06, 2021 at 11:28:00PM +0100, Thomas Gleixner wrote:
> The irqdomain code already returns the information. Move the loop to the
> legacy code.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Reviewed-by: Greg Kroah-Hartman
On Mon, Dec 06, 2021 at 11:39:41PM +0100, Thomas Gleixner wrote:
> Use msi_get_vector() and handle the return value to be compatible.
>
> No functional change intended.
>
> Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
On Mon, Dec 06, 2021 at 11:39:25PM +0100, Thomas Gleixner wrote:
> Add a properties field which allows core code to store information for easy
> retrieval in order to replace MSI descriptor fiddling.
>
> Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
On Mon, Dec 06, 2021 at 11:39:26PM +0100, Thomas Gleixner wrote:
> Store the properties which are interesting for various places so the MSI
> descriptor fiddling can be removed.
>
> Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
On Mon, Dec 06, 2021 at 11:39:33PM +0100, Thomas Gleixner wrote:
> instead of fiddling with MSI descriptors.
>
> Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
On Mon, Dec 06, 2021 at 11:39:37PM +0100, Thomas Gleixner wrote:
> Set the domain info flag and remove the check.
>
> Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
given MSI index.
>
> Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
On Mon, Dec 06, 2021 at 11:27:57PM +0100, Thomas Gleixner wrote:
> No users outside of that file.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Reviewed-by: Greg Kroah-Hartman
On Mon, Dec 06, 2021 at 11:27:56PM +0100, Thomas Gleixner wrote:
> It's only required for PCI/MSI. So no point in having it in every struct
> device.
>
> Signed-off-by: Thomas Gleixner
Yes!!!
Reviewed-by: Greg Kroah-Hartman
On Mon, Dec 06, 2021 at 11:27:49PM +0100, Thomas Gleixner wrote:
> These functions are required even when CONFIG_PCI_MSI is not set. Move them
> to their own file.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Reviewed-by: Greg Kroah-Hartman
On Mon, Dec 06, 2021 at 11:27:52PM +0100, Thomas Gleixner wrote:
> Move the irqdomain specific code into it's own file.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Reviewed-by: Greg Kroah-Hartman
On Mon, Dec 06, 2021 at 11:27:51PM +0100, Thomas Gleixner wrote:
> Split out the non irqdomain code into its own file.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Reviewed-by: Greg Kroah-Hartman
nthorpe
Reviewed-by: Greg Kroah-Hartman
t; Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
> Acked-by: Kalle Valo
> Cc: Greg Kroah-Hartman
> Cc: sparcli...@vger.kernel.org
> Cc: x...@kernel.org
> Cc: xen-devel@lists.xenproject.org
> Cc: ath...@lists.infradead.org
Reviewed-by: Greg Kroah-Hartman
On Mon, Dec 06, 2021 at 11:27:36PM +0100, Thomas Gleixner wrote:
> instead of fiddling with msi descriptors.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Greg Kroah-Hartman
On Mon, Dec 06, 2021 at 11:27:28PM +0100, Thomas Gleixner wrote:
> No point in building unused code when CONFIG_SYSFS=n.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Reviewed-by: Greg Kroah-Hartman
On Tue, Nov 23, 2021 at 02:20:47PM +0100, Juergen Gross wrote:
> Introduces the Xen pvUSB frontend. With pvUSB it is possible for a Xen
> domU to communicate with a USB device assigned to that domU. The
> communication is all done via the pvUSB backend in a driver domain
> (usually Dom0) which is
On Mon, Nov 29, 2021 at 04:15:31PM +0100, Juergen Gross wrote:
> Hi Greg,
>
> attached are git bundles for some patches you merged into the 5.10
> stable kernel already this morning.
>
> Naming should be obvious, the patches are on the branch "back" in
> each bundle.
All now queued up, thanks!
On Mon, Nov 29, 2021 at 08:19:18AM +0100, Juergen Gross wrote:
> Hi Greg,
>
> could you please add the following upstream patches to the stable 5.10
> kernel (I'll send separate mails for the older stable kernels as some
> of the patches don't apply for those)? They are hardening Xen PV
>
On Fri, Oct 01, 2021 at 05:00:36PM +0200, Juergen Gross wrote:
> This series adds XEN guest pvUSB support. With pvUSB it is possible to
> use physical USB devices from a XEN domain.
>
> Since V4 a lot of time (several years) has passed. This is a revived
> attempt to get the frontend into the
On Fri, Oct 01, 2021 at 05:00:38PM +0200, Juergen Gross wrote:
> --- /dev/null
> +++ b/drivers/usb/host/xen-hcd.c
> @@ -0,0 +1,1641 @@
> +/*
> + * xen-hcd.c
Need a SPDX line here, instead of the license boiler-plate text you
have.
Did you run checkpatch on this thing? I thought that would have
On Fri, Sep 03, 2021 at 11:01:58AM +0200, Juergen Gross wrote:
> On 03.09.21 10:56, Greg Kroah-Hartman wrote:
> > On Fri, Sep 03, 2021 at 10:49:36AM +0200, Juergen Gross wrote:
> > > In there is no legacy RTC device, don't try to use it for storing trace
> > >
On Fri, Sep 03, 2021 at 10:49:36AM +0200, Juergen Gross wrote:
> In there is no legacy RTC device, don't try to use it for storing trace
> data across suspend/resume.
>
> Cc:
> Signed-off-by: Juergen Gross
> ---
> drivers/base/power/trace.c | 10 ++
> 1 file changed, 10 insertions(+)
>
On Mon, Aug 16, 2021 at 01:09:52PM +0200, Juergen Gross wrote:
> Greg,
>
> could you please add upstream commit 05d69d950d9d8 ("xen-blkfront:
> sanitize the removal state machine") to the stable 5.13 kernel?
>
> The patch seems not to have a "Cc: stable" tag while it fixes an
> issue introduced
ing of a pci_dev's bound driver
Other than my objection to patch 5/5 lack of changelog, looks sane to
me:
Acked-by: Greg Kroah-Hartman
On Wed, Jul 21, 2021 at 12:09:41PM +0200, Greg Kroah-Hartman wrote:
> On Tue, Jul 13, 2021 at 09:35:17PM +0200, Uwe Kleine-König wrote:
> > Hello,
> >
> > this is v4 of the final patch set for my effort to make struct
> > bus_type::remove return void.
> >
&
On Tue, Jul 13, 2021 at 09:35:17PM +0200, Uwe Kleine-König wrote:
> Hello,
>
> this is v4 of the final patch set for my effort to make struct
> bus_type::remove return void.
>
> The first four patches contain cleanups that make some of these
> callbacks (more obviously) always return 0. They are
On Mon, Jul 05, 2021 at 01:58:09PM +0200, Juergen Gross wrote:
> Hi Greg,
>
> the attached patch is a backport of upstream commit 3de218ff39b9e3f0d4
> for Linux 5.10 and older (I've checked it to apply down to 4.4).
Now applied, thanks.
greg k-h
On Thu, May 13, 2021 at 06:56:47PM -0600, Connor Davis wrote:
> Hi all,
>
> This goal of this series is to allow the USB3 debug capability (DbC) to be
> safely used by xen while linux runs as dom0.
Patch 2/4 does not seem to be showing up anywhere, did it get lost?
thanks,
greg k-h
On Thu, May 13, 2021 at 12:03:02PM +0200, Juergen Gross wrote:
> Xen frontends shouldn't BUG() in case of illegal data received from
> their backends. So replace the BUG_ON()s when reading illegal data from
> the ring page with negative return values.
>
> Signed-off-by: Juergen Gross
> ---
>
On Tue, May 11, 2021 at 06:18:21PM -0600, Connor Davis wrote:
> When running as a dom0 guest on Xen, check if the USB3 debug
> capability is enabled before xHCI reset, suspend, and resume. If it
> is, call xen_dbgp_reset_prep() to notify Xen that it is unsafe to touch
> MMIO registers until the
On Fri, Jan 29, 2021 at 01:22:15PM +0100, Roger Pau Monne wrote:
> commit ef3a575baf53571dc405ee4028e26f50856898e7 upstream.
>
Now queued up, thanks.
greg k-h
From: Jiri Slaby
commit 78762b0e79bc1dd01347be061abdf505202152c9 upstream.
All these are functions which are invoked from elsewhere but they are
not typical C functions. So annotate them using the new SYM_CODE_START.
All these were not balanced with any END, so mark their ends by
SYM_CODE_END,
Cc: Pavel Machek
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Will Deacon
Cc: x86-ml
Cc: xen-devel@lists.xenproject.org
Link: https://lkml.kernel.org/r/2019105108.12392-2-jsl...@suse.cz
Cc: Jian Cai
Signed-off-by: Greg Kroah-Hartman
---
Documentation/asm-an
On Mon, Nov 02, 2020 at 12:04:36PM +0100, Fabrice Gasnier wrote:
> On 10/30/20 11:09 AM, Mauro Carvalho Chehab wrote:
> > Em Fri, 30 Oct 2020 10:19:12 +0100
> > Fabrice Gasnier escreveu:
> >
> >> Hi Mauro,
> >>
> >> [...]
> >>
> >>>
> >>> +What:
> >>>
On Tue, Sep 08, 2020 at 10:10:08PM +0200, David Hildenbrand wrote:
> We soon want to pass flags, e.g., to mark added System RAM resources.
> mergeable. Prepare for that.
What are these random "flags", and how do we know what should be passed
to them?
Why not make this an enumerated type so that
; Cc: Jason Gunthorpe
> Cc: Kees Cook
> Cc: Ard Biesheuvel
> Cc: Pankaj Gupta
> Cc: Baoquan He
> Cc: Wei Yang
> Cc: Eric Biederman
> Cc: Thomas Gleixner
> Cc: Greg Kroah-Hartman
> Cc: ke...@lists.infradead.org
> Signed-off-by: David Hildenbrand
> ---
> in
From: Randy Dunlap
[ Upstream commit ee87e1557c42dc9c2da11c38e11b87c311569853 ]
../arch/x86/pci/xen.c: In function ‘pci_xen_init’:
../arch/x86/pci/xen.c:410:2: error: implicit declaration of function
‘acpi_noirq_set’; did you mean ‘acpi_irq_get’?
[-Werror=implicit-function-declaration]
From: Randy Dunlap
[ Upstream commit ee87e1557c42dc9c2da11c38e11b87c311569853 ]
../arch/x86/pci/xen.c: In function ‘pci_xen_init’:
../arch/x86/pci/xen.c:410:2: error: implicit declaration of function
‘acpi_noirq_set’; did you mean ‘acpi_irq_get’?
[-Werror=implicit-function-declaration]
From: Randy Dunlap
[ Upstream commit ee87e1557c42dc9c2da11c38e11b87c311569853 ]
../arch/x86/pci/xen.c: In function ‘pci_xen_init’:
../arch/x86/pci/xen.c:410:2: error: implicit declaration of function
‘acpi_noirq_set’; did you mean ‘acpi_irq_get’?
[-Werror=implicit-function-declaration]
From: Randy Dunlap
[ Upstream commit ee87e1557c42dc9c2da11c38e11b87c311569853 ]
../arch/x86/pci/xen.c: In function ‘pci_xen_init’:
../arch/x86/pci/xen.c:410:2: error: implicit declaration of function
‘acpi_noirq_set’; did you mean ‘acpi_irq_get’?
[-Werror=implicit-function-declaration]
On Thu, Aug 20, 2020 at 07:58:55AM +0200, Jürgen Groß wrote:
> On 20.08.20 07:44, Greg Kroah-Hartman wrote:
> > On Thu, Aug 20, 2020 at 07:13:00AM +0200, Jürgen Groß wrote:
> > > On 19.08.20 18:57, Sarah Newman wrote:
> > > > On 7/10/20 5:01 AM, Jürgen Groß wrote:
&g
On Thu, Aug 20, 2020 at 07:13:00AM +0200, Jürgen Groß wrote:
> On 19.08.20 18:57, Sarah Newman wrote:
> > On 7/10/20 5:01 AM, Jürgen Groß wrote:
> > > On 10.07.20 13:55, Jan Beulich wrote:
> > > > On 10.07.2020 12:50, Jürgen Groß wrote:
> > > > > On 10.07.20 11:49, Jan Beulich wrote:
> > > > > >
rix.com
Cc: konrad.w...@oracle.com
Cc: virtualizat...@lists.linux-foundation.org
Cc: xen-devel@lists.xenproject.org
Link:
http://lkml.kernel.org/r/1447970147-1733-3-git-send-email-boris.ostrov...@oracle.com
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman
---
arch/x86/entry/
From: Jason Gunthorpe
[ Upstream commit fa6614d8ef13c63aac52ad7c07c5e69ce4aba3dd ]
DMA_SHARED_BUFFER can not be enabled by the user (it represents a library
set in the kernel). The kconfig convention is to use select for such
symbols so they are turned on implicitly when the user enables a
From: Jason Gunthorpe
[ Upstream commit fa6614d8ef13c63aac52ad7c07c5e69ce4aba3dd ]
DMA_SHARED_BUFFER can not be enabled by the user (it represents a library
set in the kernel). The kconfig convention is to use select for such
symbols so they are turned on implicitly when the user enables a
Kroah-Hartman
---
drivers/net/xen-netback/netback.c | 3 --
drivers/net/xen-netback/xenbus.c | 46 ---
2 files changed, 11 insertions(+), 38 deletions(-)
diff --git a/drivers/net/xen-netback/netback.c
b/drivers/net/xen-netback/netback.c
index 1d9940d4e8c7
s is part a tree-wide conversion, as described in commit fc1d8e7cca2d
> ("mm: introduce put_user_page*(), placeholder versions").
>
> Cc: Eric Anholt
> Cc: Stefan Wahren
> Cc: Greg Kroah-Hartman
> Cc: Mihaela Muraru
> Cc: Suniel Mahesh
> Cc: Al Viro
&
; was wrong anyway, because the get_user_pages() pattern of usage here
> never allowed for NULL entries within a range of pinned pages.
>
> Cc: Frank Haverkamp
> Cc: "Guilherme G. Piccoli"
> Cc: Arnd Bergmann
> Cc: Greg Kroah-Hartman
> Signed-off-by: John Hubbard
>
[ Upstream commit 0383ad4374f7ad7edd925a2ee4753035c3f5508a ]
xen_biovec_phys_mergeable() only needs .bv_page of the 2nd bio bvec
for checking if the two bvecs can be merged, so pass page to
xen_biovec_phys_mergeable() directly.
No function change.
Cc: ris Ostrovsky
Cc: Juergen Gross
Cc:
[ Upstream commit 0383ad4374f7ad7edd925a2ee4753035c3f5508a ]
xen_biovec_phys_mergeable() only needs .bv_page of the 2nd bio bvec
for checking if the two bvecs can be merged, so pass page to
xen_biovec_phys_mergeable() directly.
No function change.
Cc: ris Ostrovsky
Cc: Juergen Gross
Cc:
[ Upstream commit db5ebd6edd2627d7e81a031643cf43587f63e66c ]
XEN has special page merge requirement, see xen_biovec_phys_mergeable().
We can't merge pages into one bvec simply for XEN.
So move XEN's specific check on page merge into __bio_try_merge_page(),
then abvoid to break XEN by multi-page
4.20-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit b4711098066f1cf808d4dc11a1a842860a3292fe ]
static checker warning:
drivers/xen/pvcalls-front.c:373 alloc_active_ring()
error: we previously assumed 'map->active.ring' could
4.20-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 9f51c05dc41a6d69423e3d03d18eb7ab22f9ec19 ]
The problem is that we call this with a spin lock held.
The call tree is:
pvcalls_front_accept() holds bedata->socket_lock.
->
4.19-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit b4711098066f1cf808d4dc11a1a842860a3292fe ]
static checker warning:
drivers/xen/pvcalls-front.c:373 alloc_active_ring()
error: we previously assumed 'map->active.ring' could
4.19-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 9f51c05dc41a6d69423e3d03d18eb7ab22f9ec19 ]
The problem is that we call this with a spin lock held.
The call tree is:
pvcalls_front_accept() holds bedata->socket_lock.
->
1 - 100 of 139 matches
Mail list logo
