Re: CVE-2021-47377: kernel: xen/balloon: use a kernel thread instead a workqueue

[Greg KH]

On Mon, May 27, 2024 at 12:58:16PM +0200, Juergen Gross wrote:
> Hi,
> 
> I'd like to dispute CVE-2021-47377: the issue fixed by upstream commit
> 8480ed9c2bbd56fc86524998e5f2e3e22f5038f6 can in no way be triggered by
> an unprivileged user or by a remote attack of the system, as it requires
> initiation of memory ballooning of the running system. This can be done
> only by either a host admin or by an admin of the guest which might
> suffer the detection of the hanging workqueue.
> 
> Please revoke this CVE.

Ah, good catch, this came in as part of the GSD import, and I missed
that this required that type of permissions.  Now revoked, thanks for
the review!

greg k-h

Re: [PATCH net] xen-netfront: Add missing skb_mark_for_recycle

[Greg KH]

On Tue, May 07, 2024 at 02:57:08PM +0100, Andrew Cooper wrote:
> Hello,
> 
> Please could we request a CVE for "xen-netfront: Add missing
> skb_mark_for_recycle" which is 037965402a010898d34f4e35327d22c0a95cd51f
> in Linus' tree.
> 
> This is a kernel memory leak trigger-able from unprivileged userspace.
> 
> I can't see any evidence of this fix having been assigned a CVE thus far
> on the linux-cve-annouce mailing list.

CVE-2024-27393 is now created for this, thanks.

greg k-h

Re: CVE-2024-26908: x86/xen: Add some null pointer checking to smp.c

[Greg KH]

On Mon, Apr 29, 2024 at 01:53:44PM +0200, Juergen Gross wrote:
> Hi,
> 
> I'd like to dispute CVE-2024-26908: the issue fixed by upstream commit
> 3693bb4465e6e32a204a5b86d3ec7e6b9f7e67c2 can in no way be triggered by
> an unprivileged user or by a remote attack of the system, as it requires
> hotplug of (virtual) cpus to the running system. This can be done only by
> either a host admin or by an admin of the guest which might suffer the
> out-of-memory situation.
> 
> Please revoke this CVE.

Sorry for the delay, thanks for looking into this and letting us know.
It's now rejected.

greg k-h

Re: [PATCH net] xen-netfront: Add missing skb_mark_for_recycle

[Greg KH]

On Thu, Apr 25, 2024 at 02:39:38PM +0100, George Dunlap wrote:
> Greg,
> 
> We're issuing an XSA for this; can you issue a CVE?

To ask for a cve, please contact c...@kernel.org as per our
documentation.  Please provide the git id of the commit you wish to have
the cve assigned to.

thanks,

greg k-h

Re: [PATCH 5.10] xen/events: close evtchn after mapping cleanup

[Greg KH]

On Sat, Mar 02, 2024 at 08:03:57AM -0800, Andrew Panyakin wrote:
> 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 inversion. Both
> are called with the irq_desc->lock being taking. The lock order,
> however, is first irq_mapping_update_lock and then irq_desc->lock.
> 
> This opens multiple races:
> - shutdown_pirq can be interrupted by a function that allocates an event
>   channel:
> 
>   CPU0CPU1
>   shutdown_pirq {
> xen_evtchn_close(e)
>   __startup_pirq {
> EVTCHNOP_bind_pirq
>   -> returns just freed evtchn e
> set_evtchn_to_irq(e, irq)
>   }
> xen_irq_info_cleanup() {
>   set_evtchn_to_irq(e, -1)
> }
>   }
> 
>   Assume here event channel e refers here to the same event channel
>   number.
>   After this race the evtchn_to_irq mapping for e is invalid (-1).
> 
> - __startup_pirq races with __unbind_from_irq in a similar way. Because
>   __startup_pirq doesn't take irq_mapping_update_lock it can grab the
>   evtchn that __unbind_from_irq is currently freeing and cleaning up. In
>   this case even though the event channel is allocated, its mapping can
>   be unset in evtchn_to_irq.
> 
> The fix is to first cleanup the mappings and then close the event
> channel. In this way, when an event channel gets allocated it's
> potential previous evtchn_to_irq mappings are guaranteed to be unset already.
> This is also the reverse order of the allocation where first the event
> channel is allocated and then the mappings are setup.
> 
> On a 5.10 kernel prior to commit 3fcdaf3d7634 ("xen/events: modify internal
> [un]bind interfaces"), we hit a BUG like the following during probing of NVMe
> devices. The issue is that during nvme_setup_io_queues, pci_free_irq
> is called for every device which results in a call to shutdown_pirq.
> With many nvme devices it's therefore likely to hit this race during
> boot because there will be multiple calls to shutdown_pirq and
> startup_pirq are running potentially in parallel.
> 
>   [ cut here ]
>   blkfront: xvda: barrier or flush: disabled; persistent grants: enabled; 
> indirect descriptors: enabled; bounce buffer: enabled
>   kernel BUG at drivers/xen/events/events_base.c:499!
>   invalid opcode:  [#1] SMP PTI
>   CPU: 44 PID: 375 Comm: kworker/u257:23 Not tainted 
> 5.10.201-191.748.amzn2.x86_64 #1
>   Hardware name: Xen HVM domU, BIOS 4.11.amazon 08/24/2006
>   Workqueue: nvme-reset-wq nvme_reset_work
>   RIP: 0010:bind_evtchn_to_cpu+0xdf/0xf0
>   Code: 5d 41 5e c3 cc cc cc cc 44 89 f7 e8 2b 55 ad ff 49 89 c5 48 85 c0 0f 
> 84 64 ff ff ff 4c 8b 68 30 41 83 fe ff 0f 85 60 ff ff ff <0f> 0b 66 66 2e 0f 
> 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00
>   RSP: :c9000d533b08 EFLAGS: 00010046
>   RAX:  RBX:  RCX: 0006
>   RDX: 0028 RSI:  RDI: 
>   RBP: 888107419680 R08:  R09: 82d72b00
>   R10:  R11:  R12: 01ed
>   R13:  R14:  R15: 0002
>   FS:  () GS:88bc8b50() knlGS:
>   CS:  0010 DS:  ES:  CR0: 80050033
>   CR2:  CR3: 02610001 CR4: 001706e0
>   DR0:  DR1:  DR2: 
>   DR3:  DR6: fffe0ff0 DR7: 0400
>   Call Trace:
>? show_trace_log_lvl+0x1c1/0x2d9
>? show_trace_log_lvl+0x1c1/0x2d9
>? set_affinity_irq+0xdc/0x1c0
>? __die_body.cold+0x8/0xd
>? die+0x2b/0x50
>? do_trap+0x90/0x110
>? bind_evtchn_to_cpu+0xdf/0xf0
>? do_error_trap+0x65/0x80
>? bind_evtchn_to_cpu+0xdf/0xf0
>? exc_invalid_op+0x4e/0x70
>? bind_evtchn_to_cpu+0xdf/0xf0
>? asm_exc_invalid_op+0x12/0x20
>? bind_evtchn_to_cpu+0xdf/0xf0
>? bind_evtchn_to_cpu+0xc5/0xf0
>set_affinity_irq+0xdc/0x1c0
>irq_do_set_affinity+0x1d7/0x1f0
>irq_setup_affinity+0xd6/0x1a0
>irq_startup+0x8a/0xf0
>__setup_irq+0x639/0x6d0
>? nvme_suspend+0x150/0x150
>request_threaded_irq+0x10c/0x180
>? nvme_suspend+0x150/0x150
>pci_request_irq+0xa8/0xf0
>? __blk_mq_free_request+0x74/0xa0
>queue_request_irq+0x6f/0x80
>nvme_create_queue+0x1af/0x200
>nvme_create_io_queues+0xbd/0xf0
>nvme_setup_io_queues+0x246/0x320
>? nvme_irq_check+0x30/0x30
>nvme_reset_work+0x1c8/0x400
>process_one_work+0x1b0/0x350
>worker_thread+0x49/0x310
>? process_one_work+0x350/0x350
>kthread+0x11b/0x140
>? __kthread_bind_mask+0x60/0x60
>ret_from_fork+0x22/0x30
>   Modules linked in:
>   ---[ 

Re: [PATCH -next] block: remove field 'bd_inode' from block_device

[Greg KH]

On Sat, Nov 25, 2023 at 05:39:12PM +0800, Yu Kuai wrote:
> From: Yu Kuai 
> 
> block_devcie is allocated from bdev_alloc() by bdev_alloc_inode(), and
> currently block_device contains a pointer that point to the address of
> inode, while such inode is allocated together:
> 
> bdev_alloc
>  inode = new_inode()
>   // inode is _inode->vfs_inode
>  bdev = I_BDEV(inode)
>   // bdev is _inode->bdev
>  bdev->inode = inode
> 
> Add a new helper to get address of inode from bdev by add operation
> instead of memory access, which is more efficiency. Also prepare to
> add a new field 'bd_flags' in the first cacheline(64 bytes).
> 
> Signed-off-by: Yu Kuai 
> ---
>  block/bdev.c   | 39 +-
>  block/blk-zoned.c  |  4 +--
>  block/fops.c   |  4 +--
>  block/genhd.c  |  8 +++---
>  block/ioctl.c  |  8 +++---
>  block/partitions/core.c|  9 ---
>  drivers/block/xen-blkback/xenbus.c |  2 +-
>  drivers/md/bcache/super.c  |  2 +-
>  drivers/mtd/devices/block2mtd.c| 12 -
>  drivers/s390/block/dasd_ioctl.c|  2 +-
>  drivers/scsi/scsicam.c |  2 +-
>  fs/bcachefs/util.h |  2 +-
>  fs/btrfs/disk-io.c |  6 ++---
>  fs/btrfs/volumes.c |  4 +--
>  fs/btrfs/zoned.c   |  2 +-
>  fs/buffer.c|  8 +++---
>  fs/cramfs/inode.c  |  2 +-
>  fs/erofs/data.c|  2 +-
>  fs/ext4/dir.c  |  2 +-
>  fs/ext4/ext4_jbd2.c|  2 +-
>  fs/ext4/super.c|  8 +++---
>  fs/gfs2/glock.c|  2 +-
>  fs/gfs2/ops_fstype.c   |  2 +-
>  fs/jbd2/journal.c  |  3 ++-
>  fs/jbd2/recovery.c |  2 +-
>  fs/nilfs2/segment.c|  2 +-
>  include/linux/blk_types.h  | 10 ++--
>  include/linux/blkdev.h |  4 +--
>  include/linux/buffer_head.h|  4 +--
>  29 files changed, 86 insertions(+), 73 deletions(-)

You should do this as a patch series, add the helper function that does
nothing, convert all the different portions of the kernel as different
patches, and _then_ change the implementation of the block layer to
handle the change in the structure.

Otherwise this is going to be hard to get accepted.

Also, one note:

> @@ -85,6 +84,13 @@ struct block_device {
>  #define bdev_kobj(_bdev) \
>   (&((_bdev)->bd_device.kobj))
>  
> +static inline struct inode *bdev_inode(struct block_device *bdev)
> +{
> + void *inode = bdev + 1;

That's crazy, if something changes, this will keep working yet the
kernel will break and no one will know why.

Please use container_of(), that's what it is there for, this exact type
of thing.  Or if not, are you just assuming that the memory location
right after bdev is the inode?  That's a tough assumption, how are you
going to assure it really stays there?

thanks,

greg k-h

Re: [PATCH] xen: fix potential shift out-of-bounds in xenhcd_hub_control()

[Greg KH]

On Sun, Aug 06, 2023 at 11:15:51AM -0400, Alan Stern wrote:
> On Sun, Aug 06, 2023 at 04:27:27PM +0200, Greg KH wrote:
> > On Sun, Aug 06, 2023 at 10:11:43PM +0800, Zhang Shurong wrote:
> > > 在 2023年7月1日星期六 CST 下午11:51:43，Zhang Shurong 写道：
> > > > 在 2023年6月26日星期一 CST 下午1:52:02，您写道：
> > > > 
> > > > > On Mon, Jun 26, 2023 at 07:48:05AM +0200, Jan Beulich wrote:
> > > > > > On 25.06.2023 18:42, Zhang Shurong wrote:
> > > > > > > --- a/drivers/usb/host/xen-hcd.c
> > > > > > > +++ b/drivers/usb/host/xen-hcd.c
> > > > > > > @@ -456,6 +456,8 @@ static int xenhcd_hub_control(struct usb_hcd 
> > > > > > > *hcd,
> > > > > > > __u16 typeReq, __u16 wValue,> >
> > > > > > > 
> > > > > > >   info->ports[wIndex - 1].c_connection =
> > > > 
> > > > false;
> > > > 
> > > > > > >   fallthrough;
> > > > > > >   
> > > > > > >   default:
> > > > > > > + if (wValue >= 32)
> > > > > > > + goto error;
> > > > > > > 
> > > > > > >   info->ports[wIndex - 1].status &= ~(1
> > > > 
> > > > << wValue);
> > > > 
> > > > > > Even 31 is out of bounds (as in: UB) as long as it's 1 here rather
> > > > > > than 1u.
> > > > > 
> > > > > Why isn't the caller fixed so this type of value could never be passed
> > > > > to the hub_control callback?
> > > > > 
> > > > > thanks,
> > > > > 
> > > > > greg k-h
> > > > 
> > > > Although I'm not knowledgeable about the USB subsystem, I've observed 
> > > > that
> > > > not all driver code that implements hub_control callback performs a 
> > > > shift
> > > > operation on wValue, and not all shift operations among them cause
> > > > problems. Therefore, I've decided to fix this issue within each driver
> > > > itself.
> > > > 
> > > > For example, in r8a66597_hub_control, it will first check whether 
> > > > wValue is
> > > > valid (always < 31) before the shift operation. In case of an invalid
> > > > number, the code would execute the error branch instead of the shift
> > > > operation.
> > > > 
> > > > switch (wValue) {
> > > > case USB_PORT_FEAT_ENABLE:
> > > > rh->port &= ~USB_PORT_STAT_POWER;
> > > > break;
> > > > case USB_PORT_FEAT_SUSPEND:
> > > > break;
> > > > case USB_PORT_FEAT_POWER:
> > > > r8a66597_port_power(r8a66597, port, 0);
> > > > break;
> > > > case USB_PORT_FEAT_C_ENABLE:
> > > > case USB_PORT_FEAT_C_SUSPEND:
> > > > case USB_PORT_FEAT_C_CONNECTION:
> > > > case USB_PORT_FEAT_C_OVER_CURRENT:
> > > > case USB_PORT_FEAT_C_RESET:
> > > > break;
> > > > default:
> > > > goto error;
> > > > }
> > > > rh->port &= ~(1 << wValue);
> > > 
> > > Hi there. I apologize for reaching out once more. I'm feeling a bit 
> > > puzzled 
> > > about what my next step should be. I'm unsure whether I should rewrite 
> > > this 
> > > patch or attempt to address the issue at the caller level.
> > 
> > Try addressing it at the caller level first please.  If that somehow
> > does not work, then we will take a patch series that fixes all of the
> > host controller drivers at once.
> 
> It's not feasible to fix all the callers, because the calls can come 
> from userspace via usbfs.

It can?  Hm, that happens through the call in rh_call_control(), right?
But there, we do a bunch of validation before calling hub_control() so
why can't we do the same thing in that one place as well?  Making
invalid requests from userspace should be disallowed (or we can catch
this in the usbfs interface.)

thanks,

greg k-h

Re: [PATCH] xen: fix potential shift out-of-bounds in xenhcd_hub_control()

[Greg KH]

On Sun, Aug 06, 2023 at 10:11:43PM +0800, Zhang Shurong wrote:
> 在 2023年7月1日星期六 CST 下午11:51:43，Zhang Shurong 写道：
> > 在 2023年6月26日星期一 CST 下午1:52:02，您写道：
> > 
> > > On Mon, Jun 26, 2023 at 07:48:05AM +0200, Jan Beulich wrote:
> > > > On 25.06.2023 18:42, Zhang Shurong wrote:
> > > > > --- a/drivers/usb/host/xen-hcd.c
> > > > > +++ b/drivers/usb/host/xen-hcd.c
> > > > > @@ -456,6 +456,8 @@ static int xenhcd_hub_control(struct usb_hcd *hcd,
> > > > > __u16 typeReq, __u16 wValue,> >
> > > > > 
> > > > >   info->ports[wIndex - 1].c_connection =
> > 
> > false;
> > 
> > > > >   fallthrough;
> > > > >   
> > > > >   default:
> > > > > + if (wValue >= 32)
> > > > > + goto error;
> > > > > 
> > > > >   info->ports[wIndex - 1].status &= ~(1
> > 
> > << wValue);
> > 
> > > > Even 31 is out of bounds (as in: UB) as long as it's 1 here rather
> > > > than 1u.
> > > 
> > > Why isn't the caller fixed so this type of value could never be passed
> > > to the hub_control callback?
> > > 
> > > thanks,
> > > 
> > > greg k-h
> > 
> > Although I'm not knowledgeable about the USB subsystem, I've observed that
> > not all driver code that implements hub_control callback performs a shift
> > operation on wValue, and not all shift operations among them cause
> > problems. Therefore, I've decided to fix this issue within each driver
> > itself.
> > 
> > For example, in r8a66597_hub_control, it will first check whether wValue is
> > valid (always < 31) before the shift operation. In case of an invalid
> > number, the code would execute the error branch instead of the shift
> > operation.
> > 
> > switch (wValue) {
> > case USB_PORT_FEAT_ENABLE:
> > rh->port &= ~USB_PORT_STAT_POWER;
> > break;
> > case USB_PORT_FEAT_SUSPEND:
> > break;
> > case USB_PORT_FEAT_POWER:
> > r8a66597_port_power(r8a66597, port, 0);
> > break;
> > case USB_PORT_FEAT_C_ENABLE:
> > case USB_PORT_FEAT_C_SUSPEND:
> > case USB_PORT_FEAT_C_CONNECTION:
> > case USB_PORT_FEAT_C_OVER_CURRENT:
> > case USB_PORT_FEAT_C_RESET:
> > break;
> > default:
> > goto error;
> > }
> > rh->port &= ~(1 << wValue);
> 
> Hi there. I apologize for reaching out once more. I'm feeling a bit puzzled 
> about what my next step should be. I'm unsure whether I should rewrite this 
> patch or attempt to address the issue at the caller level.

Try addressing it at the caller level first please.  If that somehow
does not work, then we will take a patch series that fixes all of the
host controller drivers at once.

thanks,

greg k-h

Re: [PATCH] xen: fix potential shift out-of-bounds in xenhcd_hub_control()

[Greg KH]

On Mon, Jun 26, 2023 at 07:48:05AM +0200, Jan Beulich wrote:
> On 25.06.2023 18:42, Zhang Shurong wrote:
> > --- a/drivers/usb/host/xen-hcd.c
> > +++ b/drivers/usb/host/xen-hcd.c
> > @@ -456,6 +456,8 @@ static int xenhcd_hub_control(struct usb_hcd *hcd, 
> > __u16 typeReq, __u16 wValue,
> > info->ports[wIndex - 1].c_connection = false;
> > fallthrough;
> > default:
> > +   if (wValue >= 32)
> > +   goto error;
> > info->ports[wIndex - 1].status &= ~(1 << wValue);
> 
> Even 31 is out of bounds (as in: UB) as long as it's 1 here rather
> than 1u.

Why isn't the caller fixed so this type of value could never be passed
to the hub_control callback?

thanks,

greg k-h

Re: [PATCH 2/6] macio: Make remove callback of macio driver void returned

[Greg KH]

On Mon, Dec 05, 2022 at 11:36:40PM +0800, Dawei Li wrote:
> Commit fc7a6209d571 ("bus: Make remove callback return
> void") forces bus_type::remove be void-returned, it doesn't
> make much sense for any bus based driver implementing remove
> callbalk to return non-void to its caller.
> 
> This change is for macio bus based drivers.
> 
> Signed-off-by: Dawei Li 
> ---
>  arch/powerpc/include/asm/macio.h| 12 ++--
>  drivers/ata/pata_macio.c|  4 +---
>  drivers/macintosh/rack-meter.c  |  4 +---
>  drivers/net/ethernet/apple/bmac.c   |  4 +---
>  drivers/net/ethernet/apple/mace.c   |  4 +---
>  drivers/net/wireless/intersil/orinoco/airport.c |  4 +---
>  drivers/scsi/mac53c94.c |  5 +
>  drivers/scsi/mesh.c |  5 +
>  drivers/tty/serial/pmac_zilog.c |  7 ++-
>  sound/aoa/soundbus/i2sbus/core.c|  4 +---
>  10 files changed, 16 insertions(+), 37 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/macio.h 
> b/arch/powerpc/include/asm/macio.h
> index ff5fd82d9ff0..f641c730c3b7 100644
> --- a/arch/powerpc/include/asm/macio.h
> +++ b/arch/powerpc/include/asm/macio.h
> @@ -124,15 +124,15 @@ static inline struct pci_dev *macio_get_pci_dev(struct 
> macio_dev *mdev)
>   */
>  struct macio_driver
>  {
> - int (*probe)(struct macio_dev* dev, const struct of_device_id 
> *match);
> - int (*remove)(struct macio_dev* dev);
> + int (*probe)(struct macio_dev *dev, const struct of_device_id 
> *match);
> + void(*remove)(struct macio_dev *dev);

Again, you are changing lines you do not need to here.

thanks,

greg k-h

Re: [PATCH 6/6] soundbus: make remove callback of soundbus driver void returned

[Greg KH]

On Mon, Dec 05, 2022 at 11:36:44PM +0800, Dawei Li wrote:
> Since commit fc7a6209d571 ("bus: Make remove callback return
> void") forces bus_type::remove be void-returned, it doesn't
> make much sense for any bus based driver implementing remove
> callbalk to return non-void to its caller.
> 
> This change is for soundbus based drivers.
> 
> Signed-off-by: Dawei Li 
> ---
>  sound/aoa/fabrics/layout.c| 3 +--
>  sound/aoa/soundbus/soundbus.h | 6 +++---
>  2 files changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/sound/aoa/fabrics/layout.c b/sound/aoa/fabrics/layout.c
> index ec4ef18555bc..850dc8c53e9b 100644
> --- a/sound/aoa/fabrics/layout.c
> +++ b/sound/aoa/fabrics/layout.c
> @@ -1094,7 +1094,7 @@ static int aoa_fabric_layout_probe(struct soundbus_dev 
> *sdev)
>   return -ENODEV;
>  }
>  
> -static int aoa_fabric_layout_remove(struct soundbus_dev *sdev)
> +static void aoa_fabric_layout_remove(struct soundbus_dev *sdev)
>  {
>   struct layout_dev *ldev = dev_get_drvdata(>ofdev.dev);
>   int i;
> @@ -1123,7 +1123,6 @@ static int aoa_fabric_layout_remove(struct soundbus_dev 
> *sdev)
>   kfree(ldev);
>   sdev->pcmid = -1;
>   sdev->pcmname = NULL;
> - return 0;
>  }
>  
>  #ifdef CONFIG_PM_SLEEP
> diff --git a/sound/aoa/soundbus/soundbus.h b/sound/aoa/soundbus/soundbus.h
> index 3a99c1f1a3ca..230dfa1ba270 100644
> --- a/sound/aoa/soundbus/soundbus.h
> +++ b/sound/aoa/soundbus/soundbus.h
> @@ -184,10 +184,10 @@ struct soundbus_driver {
>  
>   /* we don't implement any matching at all */
>  
> - int (*probe)(struct soundbus_dev* dev);
> - int (*remove)(struct soundbus_dev* dev);
> + int (*probe)(struct soundbus_dev *dev);

Why change this line too?

thanks,

greg k-h

Re: [PATCH 5/6] ac97: make remove callback of ac97 driver void returned

[Greg KH]

On Mon, Dec 05, 2022 at 11:36:43PM +0800, Dawei Li wrote:
> Since commit fc7a6209d571 ("bus: Make remove callback return
> void") forces bus_type::remove be void-returned, it doesn't
> make much sense for any bus based driver implementing remove
> callbalk to return non-void to its caller.
> 
> This change is for ac97 bus based drivers.
> 
> Signed-off-by: Dawei Li 
> ---
>  drivers/mfd/wm97xx-core.c  | 4 +---
>  include/sound/ac97/codec.h | 6 +++---
>  sound/ac97/bus.c   | 5 ++---
>  3 files changed, 6 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/mfd/wm97xx-core.c b/drivers/mfd/wm97xx-core.c
> index 9a2331eb1bfa..663acbb1854c 100644
> --- a/drivers/mfd/wm97xx-core.c
> +++ b/drivers/mfd/wm97xx-core.c
> @@ -319,13 +319,11 @@ static int wm97xx_ac97_probe(struct ac97_codec_device 
> *adev)
>   return ret;
>  }
>  
> -static int wm97xx_ac97_remove(struct ac97_codec_device *adev)
> +static void wm97xx_ac97_remove(struct ac97_codec_device *adev)
>  {
>   struct wm97xx_priv *wm97xx = ac97_get_drvdata(adev);
>  
>   snd_ac97_compat_release(wm97xx->ac97);
> -
> - return 0;
>  }
>  
>  static const struct ac97_id wm97xx_ac97_ids[] = {
> diff --git a/include/sound/ac97/codec.h b/include/sound/ac97/codec.h
> index 9792d25fa369..a26e9e0082f6 100644
> --- a/include/sound/ac97/codec.h
> +++ b/include/sound/ac97/codec.h
> @@ -62,9 +62,9 @@ struct ac97_codec_device {
>   */
>  struct ac97_codec_driver {
>   struct device_driverdriver;
> - int (*probe)(struct ac97_codec_device *);
> - int (*remove)(struct ac97_codec_device *);
> - void(*shutdown)(struct ac97_codec_device *);
> + int (*probe)(struct ac97_codec_device *dev);

Why did you change this line?

> + void(*remove)(struct ac97_codec_device *dev);
> + void(*shutdown)(struct ac97_codec_device *dev);

And this line?

Don't change things that you don't describe in your changelog and that
are not needed for your change.

thanks,

greg k-h

Re: [PATCH 4/6] xen: make remove callback of xen driver void returned

[Greg KH]

On Mon, Dec 05, 2022 at 11:36:42PM +0800, Dawei Li wrote:
> Since commit fc7a6209d571 ("bus: Make remove callback return
> void") forces bus_type::remove be void-returned, it doesn't
> make much sense for any bus based driver implementing remove
> callbalk to return non-void to its caller.

Please wrap changelogs at 72 columns.

And this should go through the maintainers of the Xen bus code, not me,
right?

And why wasn't this attached to the 0/6 email properly?  Did you use
different tools?  If so, our tools can't find the link to keep them in
sync either :(

thanks,

greg k-h

Re: [PATCH 0/6] Make remove() of any bus based driver void returned

[Greg KH]

On Mon, Dec 05, 2022 at 11:36:38PM +0800, Dawei Li wrote:
> For bus-based driver, device removal is implemented as:
> device_remove() => bus->remove() => driver->remove()
> 
> Driver core needs no feedback from bus driver about the result of
> remove callback. In which case, commit fc7a6209d571 ("bus: Make
> remove callback return void") forces bus_type::remove be void-returned.
> 
> Now we have the situation that both 1st & 2nd part of calling chain
> are void returned, so it does not make much sense for the last one
> (driver->remove) to return non-void to its caller.
> 
> So the basic idea behind this patchset is making remove() callback of
> any bus-based driver to be void returned.
> 
> This patchset includes changes for drivers below:
> 1. hyperv
> 2. macio
> 3. apr
> 4. xen
> 5. ac87
> 6. soundbus

Then that should be 6 different patchsets going to 6 different
subsystems.  No need to make this seems like a unified set of patches at
all.

> Q: Why not platform drivers?
> A: Too many of them.(maybe 4K+)

That will have to be done eventually, right?

thanks,

greg k-h

Re: [PATCH for-stable-5.10.y] xen-blkfront: Cache feature_persistent value before advertisement

[Greg KH]

On Tue, Sep 06, 2022 at 04:24:14PM +, SeongJae Park wrote:
> commit fe8f65b018effbf473f53af3538d0c1878b8b329 upstream.
> 
> Xen blkfront advertises its support of the persistent grants feature
> when it first setting up and when resuming in 'talk_to_blkback()'.
> Then, blkback reads the advertised value when it connects with blkfront
> and decides if it will use the persistent grants feature or not, and
> advertises its decision to blkfront.  Blkfront reads the blkback's
> decision and it also makes the decision for the use of the feature.
> 
> Commit 402c43ea6b34 ("xen-blkfront: Apply 'feature_persistent' parameter
> when connect"), however, made the blkfront's read of the parameter for
> disabling the advertisement, namely 'feature_persistent', to be done
> when it negotiate, not when advertise.  Therefore blkfront advertises
> without reading the parameter.  As the field for caching the parameter
> value is zero-initialized, it always advertises as the feature is
> disabled, so that the persistent grants feature becomes always disabled.
> 
> This commit fixes the issue by making the blkfront does parmeter caching
> just before the advertisement.
> 
> Fixes: 402c43ea6b34 ("xen-blkfront: Apply 'feature_persistent' parameter when 
> connect")
> Cc:  # 5.10.x
> Reported-by: Marek Marczykowski-Górecki 
> Signed-off-by: SeongJae Park 
> Tested-by: Marek Marczykowski-Górecki 
> Reviewed-by: Juergen Gross 
> Link: https://lore.kernel.org/r/20220831165824.94815-4...@kernel.org
> Signed-off-by: Juergen Gross 
> ---
> 
> This patch is a manual backport of the upstream commit on the 5.10.y
> kernel.  Please note that this patch can be applied on the latest 5.10.y
> only after the preceding patch[1] is applied.
> 
> [1] 
> https://lore.kernel.org/stable/20220906132819.016040...@linuxfoundation.org/

Now queued up, thanks.

greg k-h

Re: [PATCH v2 01/10] x86/mtrr: fix MTRR fixup on APs

[Greg KH]

On Sat, Aug 20, 2022 at 11:25:24AM +0200, Juergen Gross wrote:
> When booting or resuming the system MTRR state is saved on the boot
> processor and then this state is loaded into MTRRs of all other cpus.
> During update of the MTRRs the MTRR mechanism needs to be disabled by
> writing the related MSR. The old contents of this MSR are saved in a
> set of static variables and later those static variables are used to
> restore the MSR.
> 
> In case the MSR contents need to be modified on a cpu due to the MSR
> not having been initialized properly by the BIOS, the related update
> function is modifying the static variables accordingly.
> 
> Unfortunately the MTRR state update is usually running on all cpus
> at the same time, so using just one set of static variables for all
> cpus is racy in case the MSR contents differ across cpus.
> 
> Fix that by using percpu variables for saving the MSR contents.
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Juergen Gross 
> ---
> I thought adding a "Fixes:" tag for the kernel's initial git commit
> would maybe be entertaining, but without being really helpful.

So that means I will just do a "best guess" as to how far to backport
things.  Hopefully I guess well...

thanks,

greg k-h

Re: [PATCH 0/3] x86: make pat and mtrr independent from each other

[Greg KH]

On Sun, Aug 14, 2022 at 08:08:30AM -0400, Chuck Zmudzinski wrote:
> On 8/14/2022 5:50 AM, Greg KH wrote:
> > On Sun, Aug 14, 2022 at 05:19:12AM -0400, Chuck Zmudzinski wrote:
> > > Well, that did not take long. Juergen responded with a message,
> > > which is encrypted and not delivered to my mailbox because I do not
> > > have the PGP keys, presumably to make it difficult for me to continue
> > > the discussion and defend myself after I was accused of violating
> > > the netiquette rules yesterday by Boris:
> >
> > The message was signed, not encrypted.  Odd that your email client could
> > not read it, perhaps you need to use a different one?
> >
> > thanks,
> >
> > greg k-h
> 
> It's not that my e-mail client could not read it, there is no evidence it
> was ever sent to me.

The To: line had your address in it, so it was sent to you, and again,
it was not encrypted as you claimed, but rather just signed to verify he
was the sender.  That's not making anything difficult for anyone, so I
think you owe him an apology here, especially as you are asking him to
do work for you.

best of luck!

greg k-h

Re: [PATCH 0/3] x86: make pat and mtrr independent from each other

[Greg KH]

On Sun, Aug 14, 2022 at 05:19:12AM -0400, Chuck Zmudzinski wrote:
> Well, that did not take long. Juergen responded with a message,
> which is encrypted and not delivered to my mailbox because I do not
> have the PGP keys, presumably to make it difficult for me to continue
> the discussion and defend myself after I was accused of violating
> the netiquette rules yesterday by Boris:

The message was signed, not encrypted.  Odd that your email client could
not read it, perhaps you need to use a different one?

thanks,

greg k-h

Re: [PATCH] x86/PAT: Report PAT on CPUs that support PAT without MTRR

[Greg KH]

On Tue, Jul 12, 2022 at 03:57:45PM -0400, Chuck Zmudzinski wrote:
> On 7/12/22 3:26 PM, Greg KH wrote:
> > On Tue, Jul 12, 2022 at 03:16:01PM -0400, Chuck Zmudzinski wrote:
> > > On 7/12/22 2:36 PM, Greg KH wrote:
> > > > On Tue, Jul 12, 2022 at 02:20:37PM -0400, Chuck Zmudzinski wrote:
> > > > > The commit 99c13b8c8896d7bcb92753bf
> > > > > ("x86/mm/pat: Don't report PAT on CPUs that don't support it")
> > > > > incorrectly failed to account for the case in init_cache_modes() when
> > > > > CPUs do support PAT and falsely reported PAT to be disabled when in
> > > > > fact PAT is enabled. In some environments, notably in Xen PV domains,
> > > > > MTRR is disabled but PAT is still enabled, and that is the case
> > > > > that the aforementioned commit failed to account for.
> > > > > 
> > > > > As an unfortunate consequnce, the pat_enabled() function currently 
> > > > > does
> > > > > not correctly report that PAT is enabled in such environments. The fix
> > > > > is implemented in init_cache_modes() by setting pat_bp_enabled to true
> > > > > in init_cache_modes() for the case that commit 
> > > > > 99c13b8c8896d7bcb92753bf
> > > > > ("x86/mm/pat: Don't report PAT on CPUs that don't support it") failed
> > > > > to account for.
> > > > > 
> > > > > This patch fixes a regression that some users are experiencing with
> > > > > Linux as a Xen Dom0 driving particular Intel graphics devices by
> > > > > correctly reporting to the Intel i915 driver that PAT is enabled where
> > > > > previously it was falsely reporting that PAT is disabled.
> > > > > 
> > > > > Fixes: 99c13b8c8896d7bcb92753bf ("x86/mm/pat: Don't report PAT on 
> > > > > CPUs that don't support it")
> > > > > Cc: sta...@vger.kernel.org
> > > > > Signed-off-by: Chuck Zmudzinski 
> > > > > ---
> > > > > Reminder: This patch is a regression fix that is needed on stable
> > > > > versions 5.17 and later.
> > > >
> > > > Then why are you saying it fixes a commit that is in 4.4.y and newer?
> > > >
> > > > confused,
> > > >
> > > > greg k-h
> > > 
> > > It is true the erroneous reporting of PAT goes back to 4.4.y. But it
> > > was not until 5.17.y when the i915 driver was patched with a commit
> > > that started using pat_enabled() instead of boot_cpu_has(X86_FEATURE_PAT)
> > > and that is when a regression that started annoying users appeared
> > > in the kernel. I presume that we only backport patches to stable that
> > > fix regressions that are really bothering users, so even though the
> > > problem dates to 4.4.y, there is no need to backport before 5.17.y
> > > which is when the problem manifested in a way that started
> > > bothering users.
> >
> > If it needs to go back to 4.9.y or so, let's take it all the way back to
> > be consistent everywhere.
> >
> > thanks,
> >
> > greg k-h
> 
> I presume you want me to prepare the backport patches, or at
> least the ones that need the patch to be significantly modified to
> apply to those branches. I expect older versions will need the
> patch to be significantly modified to apply. If not, please let me know.

I will not know until it hits Linus's tree and the patch is backported
then.  If there are problems, you will get an email at that point in
time.

> Is 4.9.y the oldest version we are still supporting?

Yes, the front page of kernel.org lists the active kernel versions.

thanks,

greg k-h

Re: Build warnings in Xen 5.15.y and 5.10.y with retbleed backports

[Greg KH]

On Tue, Jul 12, 2022 at 03:19:39PM -0400, Boris Ostrovsky wrote:
> 
> On 7/12/22 12:38 PM, Greg KH wrote:
> > Hi all,
> > 
> > I'm seeing the following build warning:
> > arch/x86/kernel/head_64.o: warning: objtool: 
> > xen_hypercall_mmu_update(): can't find starting instruction
> > in the 5.15.y and 5.10.y retbleed backports.
> > 
> > I don't know why just this one hypercall is being called out by objtool,
> > and this warning isn't in 5.18 and Linus's tree due to I think commit
> > 5b2fc51576ef ("x86/ibt,xen: Sprinkle the ENDBR") being there.
> > 
> > But, is this a ret call that we "forgot" here?  It's a "real" ret in
> > Linus's branch:
> > 
> > .pushsection .noinstr.text, "ax"
> > .balign PAGE_SIZE
> > SYM_CODE_START(hypercall_page)
> > .rept (PAGE_SIZE / 32)
> > UNWIND_HINT_FUNC
> > ANNOTATE_NOENDBR
> > ANNOTATE_UNRET_SAFE
> > ret
> > /*
> >  * Xen will write the hypercall page, and sort out ENDBR.
> >  */
> > .skip 31, 0xcc
> > .endr
> > 
> > while 5.15.y and older has:
> > .pushsection .text
> > .balign PAGE_SIZE
> > SYM_CODE_START(hypercall_page)
> > .rept (PAGE_SIZE / 32)
> > UNWIND_HINT_FUNC
> > .skip 31, 0x90
> > ANNOTATE_UNRET_SAFE
> > RET
> > .endr
> > 
> > So should the "ret" remain or be turned into "RET" in mainline right
> > now?
> 
> 
> It doesn't matter --- this is overwritten by the hypervisor during 
> initialization when Xen fills in actual hypercall code.
> 
> 
> So f4b4bc10b0b85ec66f1a9bf5dddf475e6695b6d2 added 'ret' to make objtool happy 
> and then 14b476e07fab6 replaced 'ret' with RET as part of SLS fixes. The 
> latter was not really necessary but harmless.
> 
> 
> So it can be 'ret', RET, or anything else that tools don't complain about. It 
> will not be executed.

Cool, thanks.

But what about the objtool warning that I now see?  Is that "real"?

I don't run any Xen systems, so I can't test any of this myself.

thanks,

greg k-h

Re: [PATCH] x86/PAT: Report PAT on CPUs that support PAT without MTRR

[Greg KH]

On Tue, Jul 12, 2022 at 03:16:01PM -0400, Chuck Zmudzinski wrote:
> On 7/12/22 2:36 PM, Greg KH wrote:
> > On Tue, Jul 12, 2022 at 02:20:37PM -0400, Chuck Zmudzinski wrote:
> > > The commit 99c13b8c8896d7bcb92753bf
> > > ("x86/mm/pat: Don't report PAT on CPUs that don't support it")
> > > incorrectly failed to account for the case in init_cache_modes() when
> > > CPUs do support PAT and falsely reported PAT to be disabled when in
> > > fact PAT is enabled. In some environments, notably in Xen PV domains,
> > > MTRR is disabled but PAT is still enabled, and that is the case
> > > that the aforementioned commit failed to account for.
> > > 
> > > As an unfortunate consequnce, the pat_enabled() function currently does
> > > not correctly report that PAT is enabled in such environments. The fix
> > > is implemented in init_cache_modes() by setting pat_bp_enabled to true
> > > in init_cache_modes() for the case that commit 99c13b8c8896d7bcb92753bf
> > > ("x86/mm/pat: Don't report PAT on CPUs that don't support it") failed
> > > to account for.
> > > 
> > > This patch fixes a regression that some users are experiencing with
> > > Linux as a Xen Dom0 driving particular Intel graphics devices by
> > > correctly reporting to the Intel i915 driver that PAT is enabled where
> > > previously it was falsely reporting that PAT is disabled.
> > > 
> > > Fixes: 99c13b8c8896d7bcb92753bf ("x86/mm/pat: Don't report PAT on CPUs 
> > > that don't support it")
> > > Cc: sta...@vger.kernel.org
> > > Signed-off-by: Chuck Zmudzinski 
> > > ---
> > > Reminder: This patch is a regression fix that is needed on stable
> > > versions 5.17 and later.
> >
> > Then why are you saying it fixes a commit that is in 4.4.y and newer?
> >
> > confused,
> >
> > greg k-h
> 
> It is true the erroneous reporting of PAT goes back to 4.4.y. But it
> was not until 5.17.y when the i915 driver was patched with a commit
> that started using pat_enabled() instead of boot_cpu_has(X86_FEATURE_PAT)
> and that is when a regression that started annoying users appeared
> in the kernel. I presume that we only backport patches to stable that
> fix regressions that are really bothering users, so even though the
> problem dates to 4.4.y, there is no need to backport before 5.17.y
> which is when the problem manifested in a way that started
> bothering users.

If it needs to go back to 4.9.y or so, let's take it all the way back to
be consistent everywhere.

thanks,

greg k-h

Re: [PATCH] x86/PAT: Report PAT on CPUs that support PAT without MTRR

[Greg KH]

On Tue, Jul 12, 2022 at 02:20:37PM -0400, Chuck Zmudzinski wrote:
> The commit 99c13b8c8896d7bcb92753bf
> ("x86/mm/pat: Don't report PAT on CPUs that don't support it")
> incorrectly failed to account for the case in init_cache_modes() when
> CPUs do support PAT and falsely reported PAT to be disabled when in
> fact PAT is enabled. In some environments, notably in Xen PV domains,
> MTRR is disabled but PAT is still enabled, and that is the case
> that the aforementioned commit failed to account for.
> 
> As an unfortunate consequnce, the pat_enabled() function currently does
> not correctly report that PAT is enabled in such environments. The fix
> is implemented in init_cache_modes() by setting pat_bp_enabled to true
> in init_cache_modes() for the case that commit 99c13b8c8896d7bcb92753bf
> ("x86/mm/pat: Don't report PAT on CPUs that don't support it") failed
> to account for.
> 
> This patch fixes a regression that some users are experiencing with
> Linux as a Xen Dom0 driving particular Intel graphics devices by
> correctly reporting to the Intel i915 driver that PAT is enabled where
> previously it was falsely reporting that PAT is disabled.
> 
> Fixes: 99c13b8c8896d7bcb92753bf ("x86/mm/pat: Don't report PAT on CPUs that 
> don't support it")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Chuck Zmudzinski 
> ---
> Reminder: This patch is a regression fix that is needed on stable
> versions 5.17 and later.

Then why are you saying it fixes a commit that is in 4.4.y and newer?

confused,

greg k-h

Build warnings in Xen 5.15.y and 5.10.y with retbleed backports

[Greg KH]

Hi all,

I'm seeing the following build warning:
arch/x86/kernel/head_64.o: warning: objtool: 
xen_hypercall_mmu_update(): can't find starting instruction
in the 5.15.y and 5.10.y retbleed backports.

I don't know why just this one hypercall is being called out by objtool,
and this warning isn't in 5.18 and Linus's tree due to I think commit
5b2fc51576ef ("x86/ibt,xen: Sprinkle the ENDBR") being there.

But, is this a ret call that we "forgot" here?  It's a "real" ret in
Linus's branch:

.pushsection .noinstr.text, "ax"
.balign PAGE_SIZE
SYM_CODE_START(hypercall_page)
.rept (PAGE_SIZE / 32)
UNWIND_HINT_FUNC
ANNOTATE_NOENDBR
ANNOTATE_UNRET_SAFE
ret
/*
 * Xen will write the hypercall page, and sort out ENDBR.
 */
.skip 31, 0xcc
.endr

while 5.15.y and older has:
.pushsection .text
.balign PAGE_SIZE
SYM_CODE_START(hypercall_page)
.rept (PAGE_SIZE / 32)
UNWIND_HINT_FUNC
.skip 31, 0x90
ANNOTATE_UNRET_SAFE
RET
.endr

So should the "ret" remain or be turned into "RET" in mainline right
now?

thanks,

greg k-h

Re: gntdev warning fixes

[Greg KH]

On Fri, Jul 08, 2022 at 12:37:44PM -0400, Demi Marie Obenour wrote:
> The recent gntdev fixes introduced two incorrect WARN_ON()s, which
> triggered immediately on my system.  Patches for master and all
> supported stable versions follow.
> 
> 



This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.

Re: Hopefully correct backports for gntdev deadlock

[Greg KH]

On Mon, Jul 04, 2022 at 03:46:12PM +0200, Juergen Gross wrote:
> On 01.07.22 02:09, Demi Marie Obenour wrote:
> > This backports "xen/gntdev: Avoid blocking in unmap_grant_pages()" to
> > the various stable trees, hopefully correctly.
> > 
> 
> I have reviewed all backports and they seem correct to me.
> 
> Greg, I'm fine with you adding the backports to the related stable
> branches.

Thanks, now queued up.

greg k-h

Re: [PATCH 5.10] xen/gntdev: Avoid blocking in unmap_grant_pages()

[Greg KH]

On Thu, Jun 30, 2022 at 03:16:41PM +0200, Juergen Gross wrote:
> On 30.06.22 13:34, Greg KH wrote:
> > On Mon, Jun 27, 2022 at 02:10:02PM -0400, Demi Marie Obenour wrote:
> > > commit dbe97cff7dd9f0f75c524afdd55ad46be3d15295 upstream
> > > 
> > > unmap_grant_pages() currently waits for the pages to no longer be used.
> > > In https://github.com/QubesOS/qubes-issues/issues/7481, this lead to a
> > > deadlock against i915: i915 was waiting for gntdev's MMU notifier to
> > > finish, while gntdev was waiting for i915 to free its pages.  I also
> > > believe this is responsible for various deadlocks I have experienced in
> > > the past.
> > > 
> > > Avoid these problems by making unmap_grant_pages async.  This requires
> > > making it return void, as any errors will not be available when the
> > > function returns.  Fortunately, the only use of the return value is a
> > > WARN_ON(), which can be replaced by a WARN_ON when the error is
> > > detected.  Additionally, a failed call will not prevent further calls
> > > from being made, but this is harmless.
> > > 
> > > Because unmap_grant_pages is now async, the grant handle will be sent to
> > > INVALID_GRANT_HANDLE too late to prevent multiple unmaps of the same
> > > handle.  Instead, a separate bool array is allocated for this purpose.
> > > This wastes memory, but stuffing this information in padding bytes is
> > > too fragile.  Furthermore, it is necessary to grab a reference to the
> > > map before making the asynchronous call, and release the reference when
> > > the call returns.
> > > 
> > > It is also necessary to guard against reentrancy in gntdev_map_put(),
> > > and to handle the case where userspace tries to map a mapping whose
> > > contents have not all been freed yet.
> > > 
> > > Fixes: 745282256c75 ("xen/gntdev: safely unmap grants in case they are 
> > > still in use")
> > > Cc: sta...@vger.kernel.org
> > > Signed-off-by: Demi Marie Obenour 
> > > Reviewed-by: Juergen Gross 
> > > Link: 
> > > https://lore.kernel.org/r/20220622022726.2538-1-d...@invisiblethingslab.com
> > > Signed-off-by: Juergen Gross 
> > > ---
> > >   drivers/xen/gntdev-common.h |   7 ++
> > >   drivers/xen/gntdev.c| 142 +---
> > >   2 files changed, 106 insertions(+), 43 deletions(-)
> > 
> > All now queued up, thanks.
> 
> Sorry, but I think at least the version for 5.10 is fishy, as it removes
> the tests for successful allocations of add->map_ops and add->unmap_ops.
> 
> I need to do a thorough review of the patches (the "Reviewed-by:" tag in
> the patches is the one for the upstream patch).
> 
> Greg, can you please wait for my explicit "okay" for the backports?

Ok, I'll go drop them all from the queues now.

thanks,

greg k-h

Re: [PATCH 5.10] xen/gntdev: Avoid blocking in unmap_grant_pages()

[Greg KH]

On Mon, Jun 27, 2022 at 02:10:02PM -0400, Demi Marie Obenour wrote:
> commit dbe97cff7dd9f0f75c524afdd55ad46be3d15295 upstream
> 
> unmap_grant_pages() currently waits for the pages to no longer be used.
> In https://github.com/QubesOS/qubes-issues/issues/7481, this lead to a
> deadlock against i915: i915 was waiting for gntdev's MMU notifier to
> finish, while gntdev was waiting for i915 to free its pages.  I also
> believe this is responsible for various deadlocks I have experienced in
> the past.
> 
> Avoid these problems by making unmap_grant_pages async.  This requires
> making it return void, as any errors will not be available when the
> function returns.  Fortunately, the only use of the return value is a
> WARN_ON(), which can be replaced by a WARN_ON when the error is
> detected.  Additionally, a failed call will not prevent further calls
> from being made, but this is harmless.
> 
> Because unmap_grant_pages is now async, the grant handle will be sent to
> INVALID_GRANT_HANDLE too late to prevent multiple unmaps of the same
> handle.  Instead, a separate bool array is allocated for this purpose.
> This wastes memory, but stuffing this information in padding bytes is
> too fragile.  Furthermore, it is necessary to grab a reference to the
> map before making the asynchronous call, and release the reference when
> the call returns.
> 
> It is also necessary to guard against reentrancy in gntdev_map_put(),
> and to handle the case where userspace tries to map a mapping whose
> contents have not all been freed yet.
> 
> Fixes: 745282256c75 ("xen/gntdev: safely unmap grants in case they are still 
> in use")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Demi Marie Obenour 
> Reviewed-by: Juergen Gross 
> Link: 
> https://lore.kernel.org/r/20220622022726.2538-1-d...@invisiblethingslab.com
> Signed-off-by: Juergen Gross 
> ---
>  drivers/xen/gntdev-common.h |   7 ++
>  drivers/xen/gntdev.c| 142 +---
>  2 files changed, 106 insertions(+), 43 deletions(-)

All now queued up, thanks.

greg k-h

Re: [PATCH 0/4] x86: decode Xen/KVM emulate prefixes

[Greg KH]

On Thu, May 12, 2022 at 01:56:47PM +, Maximilian Heyne wrote:
> This is a backport of a patch series for 5.4.x.
> 
> The patch series allows the x86 decoder to decode the Xen and KVM emulate
> prefixes.
> 
> In particular this solves the following issue that appeared when commit
> db6c6a0df840 ("objtool: Fix noreturn detection for ignored functions") was
> backported to 5.4.69:
> 
>   arch/x86/xen/enlighten_pv.o: warning: objtool: xen_cpuid()+0x25: can't find 
> jump dest instruction at .text+0x9c
> 
> Also now that this decoding is possible, also backport the commit which 
> prevents
> kprobes on probing such prefixed instructions. This was also part of the
> original series.
> 
> The series applied mostly cleanly on 5.4.192 except for a contextual problem 
> in
> the 3rd patch ("x86: xen: insn: Decode Xen and KVM emulate-prefix signature").
> 
> Masami Hiramatsu (4):
>   x86/asm: Allow to pass macros to __ASM_FORM()
>   x86: xen: kvm: Gather the definition of emulate prefixes
>   x86: xen: insn: Decode Xen and KVM emulate-prefix signature
>   x86: kprobes: Prohibit probing on instruction which has emulate prefix
> 
>  arch/x86/include/asm/asm.h  |  8 +++--
>  arch/x86/include/asm/emulate_prefix.h   | 14 +
>  arch/x86/include/asm/insn.h |  6 
>  arch/x86/include/asm/xen/interface.h| 11 +++
>  arch/x86/kernel/kprobes/core.c  |  4 +++
>  arch/x86/kvm/x86.c  |  4 ++-
>  arch/x86/lib/insn.c | 34 +
>  tools/arch/x86/include/asm/emulate_prefix.h | 14 +
>  tools/arch/x86/include/asm/insn.h   |  6 
>  tools/arch/x86/lib/insn.c   | 34 +
>  tools/objtool/sync-check.sh |  3 +-
>  tools/perf/check-headers.sh |  3 +-
>  12 files changed, 128 insertions(+), 13 deletions(-)
>  create mode 100644 arch/x86/include/asm/emulate_prefix.h
>  create mode 100644 tools/arch/x86/include/asm/emulate_prefix.h
> 
> 
> base-commit: 1d72b776f6dc973211f5d153453cf8955fb3d70a
> -- 
> 2.32.0
> 
> 
> 
> 
> Amazon Development Center Germany GmbH
> Krausenstr. 38
> 10117 Berlin
> Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
> Sitz: Berlin
> Ust-ID: DE 289 237 879
> 
> 
> 

All now queued up, thanks.

greg k-h

Re: [PATCH] xen/blkfront: fix bug in backported patch

[Greg KH]

On Thu, Dec 23, 2021 at 02:40:38PM +0100, Juergen Gross wrote:
> On 23.12.21 11:57, Greg KH wrote:
> > On Thu, Dec 23, 2021 at 11:53:08AM +0100, Juergen Gross wrote:
> > > The backport of commit 8f5a695d99000fc ("xen/blkfront: don't take local
> > > copy of a request from the ring page") to stable 4.4 kernel introduced
> > > a bug when adding the needed blkif_ring_get_request() function, as
> > > info->ring.req_prod_pvt was incremented twice now.
> > > 
> > > Fix that be deleting the now superfluous increments after calling that
> > > function.
> > > 
> > > Signed-off-by: Juergen Gross 
> > > ---
> > >   drivers/block/xen-blkfront.c | 4 
> > >   1 file changed, 4 deletions(-)
> > 
> > So this is only needed in 4.4.y?  No other backports were incorrect?
> 
> Yes. 4.4 only.

Great, now queued up, thanks.

greg k-h

Re: [PATCH] xen/blkfront: fix bug in backported patch

[Greg KH]

On Thu, Dec 23, 2021 at 11:53:08AM +0100, Juergen Gross wrote:
> The backport of commit 8f5a695d99000fc ("xen/blkfront: don't take local
> copy of a request from the ring page") to stable 4.4 kernel introduced
> a bug when adding the needed blkif_ring_get_request() function, as
> info->ring.req_prod_pvt was incremented twice now.
> 
> Fix that be deleting the now superfluous increments after calling that
> function.
> 
> Signed-off-by: Juergen Gross 
> ---
>  drivers/block/xen-blkfront.c | 4 
>  1 file changed, 4 deletions(-)

So this is only needed in 4.4.y?  No other backports were incorrect?

thanks,

greg k-h

Re: [PATCH v6 1/3] usb: Add Xen pvUSB protocol description

[Greg KH]

On Fri, Oct 15, 2021 at 10:07:35AM +0200, Juergen Gross wrote:
> On 13.10.21 14:01, Greg KH wrote:
> > On Wed, Oct 13, 2021 at 09:52:05AM +0200, Juergen Gross wrote:
> > > Add the definition of pvUSB protocol used between the pvUSB frontend in
> > > a Xen domU and the pvUSB backend in a Xen driver domain (usually Dom0).
> > > 
> > > This header was originally provided by Fujitsu for Xen based on Linux
> > > 2.6.18.
> > > 
> > > Changes are:
> > > - adapt to Linux kernel style guide
> > > - use Xen namespace
> > > - add lots of comments
> > > - don't use kernel internal defines
> > > 
> > > Signed-off-by: Juergen Gross 
> > > Reviewed-by: Boris Ostrovsky 
> > > ---
> > >   include/xen/interface/io/usbif.h | 421 +++
> > >   1 file changed, 421 insertions(+)
> > >   create mode 100644 include/xen/interface/io/usbif.h
> > > 
> > > diff --git a/include/xen/interface/io/usbif.h 
> > > b/include/xen/interface/io/usbif.h
> > > new file mode 100644
> > > index ..9494b1c9be99
> > > --- /dev/null
> > > +++ b/include/xen/interface/io/usbif.h
> > > @@ -0,0 +1,421 @@
> > > +/*
> > > + * usbif.h
> > > + *
> > > + * USB I/O interface for Xen guest OSes.
> > > + *
> > > + * Copyright (C) 2009, FUJITSU LABORATORIES LTD.
> > > + * Author: Noboru Iwamatsu 
> > > + *
> > > + * Permission is hereby granted, free of charge, to any person obtaining 
> > > a copy
> > > + * of this software and associated documentation files (the "Software"), 
> > > to
> > > + * deal in the Software without restriction, including without 
> > > limitation the
> > > + * rights to use, copy, modify, merge, publish, distribute, sublicense, 
> > > and/or
> > > + * sell copies of the Software, and to permit persons to whom the 
> > > Software is
> > > + * furnished to do so, subject to the following conditions:
> > > + *
> > > + * The above copyright notice and this permission notice shall be 
> > > included in
> > > + * all copies or substantial portions of the Software.
> > > + *
> > > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
> > > EXPRESS OR
> > > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
> > > MERCHANTABILITY,
> > > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT 
> > > SHALL THE
> > > + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> > > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, 
> > > ARISING
> > > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> > > + * DEALINGS IN THE SOFTWARE.
> > > + */
> > 
> > Please use a SPDX line and not license "boilerplate" text like this :(
> 
> Okay. Is this your only concern for this series? Or is it a blocking
> point for you before looking into it in more detail?

It was an easy thing to see at first glance that you hadn't taken my
previous comment about this seriously :(

> IOW: does it make sense for me to wait for further comments before
> sending a new version of the series?

Sure, you can fix this up and resend, it will take a while to review the
host controller code...

thanks,

greg k-h

Re: [PATCH v6 1/3] usb: Add Xen pvUSB protocol description

[Greg KH]

On Wed, Oct 13, 2021 at 09:52:05AM +0200, Juergen Gross wrote:
> Add the definition of pvUSB protocol used between the pvUSB frontend in
> a Xen domU and the pvUSB backend in a Xen driver domain (usually Dom0).
> 
> This header was originally provided by Fujitsu for Xen based on Linux
> 2.6.18.
> 
> Changes are:
> - adapt to Linux kernel style guide
> - use Xen namespace
> - add lots of comments
> - don't use kernel internal defines
> 
> Signed-off-by: Juergen Gross 
> Reviewed-by: Boris Ostrovsky 
> ---
>  include/xen/interface/io/usbif.h | 421 +++
>  1 file changed, 421 insertions(+)
>  create mode 100644 include/xen/interface/io/usbif.h
> 
> diff --git a/include/xen/interface/io/usbif.h 
> b/include/xen/interface/io/usbif.h
> new file mode 100644
> index ..9494b1c9be99
> --- /dev/null
> +++ b/include/xen/interface/io/usbif.h
> @@ -0,0 +1,421 @@
> +/*
> + * usbif.h
> + *
> + * USB I/O interface for Xen guest OSes.
> + *
> + * Copyright (C) 2009, FUJITSU LABORATORIES LTD.
> + * Author: Noboru Iwamatsu 
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a 
> copy
> + * of this software and associated documentation files (the "Software"), to
> + * deal in the Software without restriction, including without limitation the
> + * rights to use, copy, modify, merge, publish, distribute, sublicense, 
> and/or
> + * sell copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL 
> THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + */

Please use a SPDX line and not license "boilerplate" text like this :(

thanks,

greg k-h

Re: [PATCH V4 05/13] hyperv: Add Write/Read MSR registers via ghcb page

[Greg KH]

On Fri, Aug 27, 2021 at 01:21:03PM -0400, Tianyu Lan wrote:
> From: Tianyu Lan 
> 
> Hyperv provides GHCB protocol to write Synthetic Interrupt
> Controller MSR registers in Isolation VM with AMD SEV SNP
> and these registers are emulated by hypervisor directly.
> Hyperv requires to write SINTx MSR registers twice. First
> writes MSR via GHCB page to communicate with hypervisor
> and then writes wrmsr instruction to talk with paravisor
> which runs in VMPL0. Guest OS ID MSR also needs to be set
> via GHCB page.
> 
> Signed-off-by: Tianyu Lan 
> ---
> Change since v1:
>  * Introduce sev_es_ghcb_hv_call_simple() and share code
>between SEV and Hyper-V code.
> Change since v3:
>  * Pass old_msg_type to hv_signal_eom() as parameter.
>* Use HV_REGISTER_* marcro instead of HV_X64_MSR_*
>* Add hv_isolation_type_snp() weak function.
>* Add maros to set syinc register in ARM code.
> ---
>  arch/arm64/include/asm/mshyperv.h |  23 ++
>  arch/x86/hyperv/hv_init.c |  36 ++
>  arch/x86/hyperv/ivm.c | 112 ++
>  arch/x86/include/asm/mshyperv.h   |  80 -
>  arch/x86/include/asm/sev.h|   3 +
>  arch/x86/kernel/sev-shared.c  |  63 ++---
>  drivers/hv/hv.c   | 112 --
>  drivers/hv/hv_common.c|   6 ++
>  include/asm-generic/mshyperv.h|   4 +-
>  9 files changed, 345 insertions(+), 94 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/mshyperv.h 
> b/arch/arm64/include/asm/mshyperv.h
> index 20070a847304..ced83297e009 100644
> --- a/arch/arm64/include/asm/mshyperv.h
> +++ b/arch/arm64/include/asm/mshyperv.h
> @@ -41,6 +41,29 @@ static inline u64 hv_get_register(unsigned int reg)
>   return hv_get_vpreg(reg);
>  }
>  
> +#define hv_get_simp(val) { val = hv_get_register(HV_REGISTER_SIMP); }
> +#define hv_set_simp(val) hv_set_register(HV_REGISTER_SIMP, val)
> +
> +#define hv_get_siefp(val){ val = hv_get_register(HV_REGISTER_SIEFP); }
> +#define hv_set_siefp(val)hv_set_register(HV_REGISTER_SIEFP, val)
> +
> +#define hv_get_synint_state(int_num, val) {  \
> + val = hv_get_register(HV_REGISTER_SINT0 + int_num); \
> + }
> +
> +#define hv_set_synint_state(int_num, val)\
> + hv_set_register(HV_REGISTER_SINT0 + int_num, val)
> +
> +#define hv_get_synic_state(val) {\
> + val = hv_get_register(HV_REGISTER_SCONTROL);\
> + }
> +
> +#define hv_set_synic_state(val)  \
> + hv_set_register(HV_REGISTER_SCONTROL, val)
> +
> +#define hv_signal_eom(old_msg_type)   \
> + hv_set_register(HV_REGISTER_EOM, 0)

Please just use real inline functions and not #defines if you really
need it.

thanks,

greg k-h

Re: [PATCH V4 04/13] hyperv: Mark vmbus ring buffer visible to host in Isolation VM

[Greg KH]

On Fri, Aug 27, 2021 at 01:21:02PM -0400, Tianyu Lan wrote:
> From: Tianyu Lan 
> 
> Mark vmbus ring buffer visible with set_memory_decrypted() when
> establish gpadl handle.
> 
> Signed-off-by: Tianyu Lan 
> ---
> Change since v3:
>* Change vmbus_teardown_gpadl() parameter and put gpadl handle,
>buffer and buffer size in the struct vmbus_gpadl.
> ---
>  drivers/hv/channel.c| 36 -
>  drivers/net/hyperv/hyperv_net.h |  1 +
>  drivers/net/hyperv/netvsc.c | 16 +++
>  drivers/uio/uio_hv_generic.c| 14 +++--
>  include/linux/hyperv.h  |  8 +++-
>  5 files changed, 63 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
> index f3761c73b074..82650beb3af0 100644
> --- a/drivers/hv/channel.c
> +++ b/drivers/hv/channel.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -474,6 +475,13 @@ static int __vmbus_establish_gpadl(struct vmbus_channel 
> *channel,
>   if (ret)
>   return ret;
>  
> + ret = set_memory_decrypted((unsigned long)kbuffer,
> +HVPFN_UP(size));
> + if (ret) {
> + pr_warn("Failed to set host visibility for new GPADL %d.\n", 
> ret);

dev_warn()?  You have access to a struct device, why not use it?

same for all other instances here.

thanks,

greg k-h

Re: [PATCH] xen/events: fix setting irq affinity

[Greg KH]

On Mon, Apr 12, 2021 at 08:28:45AM +0200, Juergen Gross wrote:
> The backport of upstream patch 25da4618af240fbec61 ("xen/events: don't
> unmask an event channel when an eoi is pending") introduced a
> regression for stable kernels 5.10 and older: setting IRQ affinity for
> IRQs related to interdomain events would no longer work, as moving the
> IRQ to its new cpu was not included in the irq_ack callback for those
> events.
> 
> Fix that by adding the needed call.
> 
> Note that kernels 5.11 and later don't need the explicit moving of the
> IRQ to the target cpu in the irq_ack callback, due to a rework of the
> affinity setting in kernel 5.11.
> 
> Signed-off-by: Juergen Gross 
> ---
> This patch should be applied to all stable kernel branches up to
> (including) linux-5.10.y, where upstream patch 25da4618af240fbec61 has
> been added.

Now queued up, thanks.

greg k-h

Re: [PATCH for <= 5.4] xen/privcmd: allow fetching resource sizes

[Greg KH]

On Tue, Jan 26, 2021 at 05:22:59PM +, Andrew Cooper wrote:
> On 20/01/2021 11:03, Greg KH wrote:
> > On Mon, Jan 18, 2021 at 03:04:26PM +0100, Roger Pau Monne wrote:
> >> commit ef3a575baf53571dc405ee4028e26f50856898e7 upstream
> >>
> >> Allow issuing an IOCTL_PRIVCMD_MMAP_RESOURCE ioctl with num = 0 and
> >> addr = 0 in order to fetch the size of a specific resource.
> >>
> >> Add a shortcut to the default map resource path, since fetching the
> >> size requires no address to be passed in, and thus no VMA to setup.
> >>
> >> This is missing from the initial implementation, and causes issues
> >> when mapping resources that don't have fixed or known sizes.
> >>
> >> Signed-off-by: Roger Pau Monné 
> >> Reviewed-by: Juergen Gross 
> >> Tested-by: Andrew Cooper 
> >> Cc: sta...@vger.kernel.org # >= 4.18
> >> Link: https://lore.kernel.org/r/20210112115358.23346-1-roger@citrix.com
> >> Signed-off-by: Juergen Gross 
> >> ---
> >> Cc: Boris Ostrovsky 
> >> Cc: xen-devel@lists.xenproject.org
> >> ---
> >>  drivers/xen/privcmd.c | 25 +++--
> >>  1 file changed, 19 insertions(+), 6 deletions(-)
> > Now queued up, thanks.
> 
> Hello,
> 
> The upstream version of this patch was queued against 5.4 and 4.19, both
> of which suffered a patch conflict, and are fixed by this version.
> 
> Was it an oversight that this version didn't get queued for 4.19?

It does not apply cleanly there, if you provide a working backport, I
will be glad to apply it.

thanks,

greg k-h

Re: [PATCH for <= 5.4] xen/privcmd: allow fetching resource sizes

[Greg KH]

On Mon, Jan 18, 2021 at 03:04:26PM +0100, Roger Pau Monne wrote:
> commit ef3a575baf53571dc405ee4028e26f50856898e7 upstream
> 
> Allow issuing an IOCTL_PRIVCMD_MMAP_RESOURCE ioctl with num = 0 and
> addr = 0 in order to fetch the size of a specific resource.
> 
> Add a shortcut to the default map resource path, since fetching the
> size requires no address to be passed in, and thus no VMA to setup.
> 
> This is missing from the initial implementation, and causes issues
> when mapping resources that don't have fixed or known sizes.
> 
> Signed-off-by: Roger Pau Monné 
> Reviewed-by: Juergen Gross 
> Tested-by: Andrew Cooper 
> Cc: sta...@vger.kernel.org # >= 4.18
> Link: https://lore.kernel.org/r/20210112115358.23346-1-roger@citrix.com
> Signed-off-by: Juergen Gross 
> ---
> Cc: Boris Ostrovsky 
> Cc: xen-devel@lists.xenproject.org
> ---
>  drivers/xen/privcmd.c | 25 +++--
>  1 file changed, 19 insertions(+), 6 deletions(-)

Now queued up, thanks.

greg k-h

Re: [PATCH v2] xen-blkfront: allow discard-* nodes to be optional

[Greg KH]

On Tue, Jan 19, 2021 at 01:36:22PM +0100, Roger Pau Monné wrote:
> Forgot to Cc stable for the Fixes tag. Doing it now.



This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.

Re: [RFC PATCH v3 2/6] swiotlb: Add restricted DMA pool

[Greg KH]

On Wed, Jan 13, 2021 at 12:51:26PM +0100, Christoph Hellwig wrote:
> On Wed, Jan 06, 2021 at 08:50:03AM +0100, Greg KH wrote:
> > > --- a/include/linux/device.h
> > > +++ b/include/linux/device.h
> > > @@ -413,6 +413,7 @@ struct dev_links_info {
> > >   * @dma_pools:   Dma pools (if dma'ble device).
> > >   * @dma_mem: Internal for coherent mem override.
> > >   * @cma_area:Contiguous memory area for dma allocations
> > > + * @dma_io_tlb_mem: Internal for swiotlb io_tlb_mem override.
> > 
> > Why does this have to be added here?  Shouldn't the platform-specific
> > code handle it instead?
> 
> The whole code added here is pretty generic.  What we need to eventually
> do, though is to add a separate dma_device instead of adding more and more
> bloat to struct device.

I have no objections for that happening!

Re: [RFC PATCH v3 2/6] swiotlb: Add restricted DMA pool

[Greg KH]

On Wed, Jan 06, 2021 at 11:41:20AM +0800, Claire Chang wrote:
> Add the initialization function to create restricted DMA pools from
> matching reserved-memory nodes in the device tree.
> 
> Signed-off-by: Claire Chang 
> ---
>  include/linux/device.h  |   4 ++
>  include/linux/swiotlb.h |   7 +-
>  kernel/dma/Kconfig  |   1 +
>  kernel/dma/swiotlb.c| 144 ++--
>  4 files changed, 131 insertions(+), 25 deletions(-)
> 
> diff --git a/include/linux/device.h b/include/linux/device.h
> index 89bb8b84173e..ca6f71ec8871 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -413,6 +413,7 @@ struct dev_links_info {
>   * @dma_pools:   Dma pools (if dma'ble device).
>   * @dma_mem: Internal for coherent mem override.
>   * @cma_area:Contiguous memory area for dma allocations
> + * @dma_io_tlb_mem: Internal for swiotlb io_tlb_mem override.

Why does this have to be added here?  Shouldn't the platform-specific
code handle it instead?

thanks,

greg k-h

Re: merge struct block_device and struct hd_struct

[Greg KH]

On Wed, Nov 18, 2020 at 10:23:51AM +0100, Jan Beulich wrote:
> On 18.11.2020 10:09, Greg KH wrote:
> > On Wed, Nov 18, 2020 at 10:04:04AM +0100, Jan Beulich wrote:
> >> On 18.11.2020 09:58, Christoph Hellwig wrote:
> >>> On Wed, Nov 18, 2020 at 09:56:11AM +0100, Jan Beulich wrote:
> >>>> since this isn't the first series from you recently spamming
> >>>> xen-devel, may I ask that you don't Cc entire series to lists
> >>>> which are involved with perhaps just one out of the many patches?
> >>>> IMO Cc lists should be compiled on a per-patch basis; the cover
> >>>> letter may of course be sent to the union of all of them.
> >>>
> >>> No way.  Individual CCs are completely broken as they don't provide
> >>> the reviewer a context.
> >>
> >> That's the view of some people, but not all. Context can be easily
> >> established by those who care going to one of the many archives on
> >> which the entire series lands. Getting spammed, however, can't be
> >> avoided by the dozens or hundreds of list subscribers.
> > 
> > kernel patches are never "spam", sorry, but for developers to try to
> > determine which lists/maintainers want to see the whole series and which
> > do not is impossible.
> > 
> > Patches in a series are easily deleted from sane mail clients with a
> > single click/keystroke all at once, they aren't a problem that needs to
> > be reduced in volume.
> 
> This doesn't scale, neither in the dimension of recipients nor in
> the dimension of possible sources of such series.

Again, trying to figure out what subsystem does, and does not, want
stuff like this does not scale either.  Remember, we had 4000 developers
last year, how are you going to tell all of them what the special rules
are for your subsystem and how they differ from any other subsystem?

And why does it matter?  We are all working on the same project, why
wouldn't you want to see core block device handling patches?  What
hurts with that, someone might notice something in one of them that a
different developer did not.

> While it may seem small, it's also a waste of resources to have mails
> sent to hundreds of even thousands of people. So while from a
> technical content perspective I surely agree with you saying 'kernel
> patches are never "spam"', they still are from the perspective of
> what "spam mail" originally means: Mail the recipients did not want
> to receive.

Anyone on a kernel subsystem mailing list should expect to see kernel
patches, that's part of the process, and always has been.

Kernel subsystems are not silos, people on them should be aware of what
else is going on in order to stay informed.  And again, if it's a huge
problem, one click/keystroke and they are gone, no waste.

thanks,

greg k-h

Re: merge struct block_device and struct hd_struct

[Greg KH]

On Wed, Nov 18, 2020 at 09:47:40AM +0100, Christoph Hellwig wrote:
> Hi Jens,
> 
> this series cleans up our main per-device node data structure by merging
> the block_device and hd_struct data structures that have the same scope,
> but different life times.  The main effect (besides removing lots of
> code) is that instead of having two device sizes that need complex
> synchronization there is just one now.
> 
> Note that it depends on the previous "misc cleanups" series.
> 
> A git tree is available here:
> 
> git://git.infradead.org/users/hch/block.git bdev-lookup
> 
> Gitweb:
> 
> 
> http://git.infradead.org/users/hch/block.git/shortlog/refs/heads/bdev-lookup

Nice cleanups, thanks for doing this.

Series is:
Reviewed-by: Greg Kroah-Hartman 

Re: [PATCH 19/20] bcache: remove a superflous lookup_bdev all

[Greg KH]

On Wed, Nov 18, 2020 at 04:54:51PM +0800, Coly Li wrote:
> On 11/18/20 4:47 PM, Christoph Hellwig wrote:
> > Don't bother to call lookup_bdev for just a slightly different error
> > message without any functional change.
> > 
> > Signed-off-by: Christoph Hellwig ist
> 
> Hi Christoph,
> 
> NACK. This removing error message is frequently triggered and observed,
> and distinct a busy device and an already registered device is important
> (the first one is critical error and second one is not).
> 
> Remove such error message will be a functional regression.

What normal operation causes this error message to be emitted?  And what
can a user do with it?

thanks,

greg k-h

Re: merge struct block_device and struct hd_struct

[Greg KH]

On Wed, Nov 18, 2020 at 10:04:04AM +0100, Jan Beulich wrote:
> On 18.11.2020 09:58, Christoph Hellwig wrote:
> > On Wed, Nov 18, 2020 at 09:56:11AM +0100, Jan Beulich wrote:
> >> since this isn't the first series from you recently spamming
> >> xen-devel, may I ask that you don't Cc entire series to lists
> >> which are involved with perhaps just one out of the many patches?
> >> IMO Cc lists should be compiled on a per-patch basis; the cover
> >> letter may of course be sent to the union of all of them.
> > 
> > No way.  Individual CCs are completely broken as they don't provide
> > the reviewer a context.
> 
> That's the view of some people, but not all. Context can be easily
> established by those who care going to one of the many archives on
> which the entire series lands. Getting spammed, however, can't be
> avoided by the dozens or hundreds of list subscribers.

kernel patches are never "spam", sorry, but for developers to try to
determine which lists/maintainers want to see the whole series and which
do not is impossible.

Patches in a series are easily deleted from sane mail clients with a
single click/keystroke all at once, they aren't a problem that needs to
be reduced in volume.

thanks,

greg k-h

Re: [RFC] treewide: cleanup unreachable breaks

[Greg KH]

On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
> From: Tom Rix 
> 
> This is a upcoming change to clean up a new warning treewide.
> I am wondering if the change could be one mega patch (see below) or
> normal patch per file about 100 patches or somewhere half way by collecting
> early acks.

Please break it up into one-patch-per-subsystem, like normal, and get it
merged that way.

Sending us a patch, without even a diffstat to review, isn't going to
get you very far...

thanks,

greg k-h

Re: [PATCH] xen: don't reschedule in preemption off sections

[Greg KH]

On Thu, Aug 20, 2020 at 08:59:08AM +0200, Juergen Gross wrote:
> For support of long running hypercalls xen_maybe_preempt_hcall() is
> calling cond_resched() in case a hypercall marked as preemptible has
> been interrupted.
> 
> Normally this is no problem, as only hypercalls done via some ioctl()s
> are marked to be preemptible. In rare cases when during such a
> preemptible hypercall an interrupt occurs and any softirq action is
> started from irq_exit(), a further hypercall issued by the softirq
> handler will be regarded to be preemptible, too. This might lead to
> rescheduling in spite of the softirq handler potentially having set
> preempt_disable(), leading to splats like:
> 
> BUG: sleeping function called from invalid context at drivers/xen/preempt.c:37
> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 20775, name: xl
> INFO: lockdep is turned off.
> CPU: 1 PID: 20775 Comm: xl Tainted: G D W 5.4.46-1_prgmr_debug.el7.x86_64 #1
> Call Trace:
> 
> dump_stack+0x8f/0xd0
> ___might_sleep.cold.76+0xb2/0x103
> xen_maybe_preempt_hcall+0x48/0x70
> xen_do_hypervisor_callback+0x37/0x40
> RIP: e030:xen_hypercall_xen_version+0xa/0x20
> Code: ...
> RSP: e02b:c900400dcc30 EFLAGS: 0246
> RAX: 0004000d RBX: 0200 RCX: 8100122a
> RDX: 88812e788000 RSI:  RDI: 
> RBP: 83ee3ad0 R08: 0001 R09: 0001
> R10:  R11: 0246 R12: 8881824aa0b0
> R13: 000865496000 R14: 000865496000 R15: 88815d04
> ? xen_hypercall_xen_version+0xa/0x20
> ? xen_force_evtchn_callback+0x9/0x10
> ? check_events+0x12/0x20
> ? xen_restore_fl_direct+0x1f/0x20
> ? _raw_spin_unlock_irqrestore+0x53/0x60
> ? debug_dma_sync_single_for_cpu+0x91/0xc0
> ? _raw_spin_unlock_irqrestore+0x53/0x60
> ? xen_swiotlb_sync_single_for_cpu+0x3d/0x140
> ? mlx4_en_process_rx_cq+0x6b6/0x1110 [mlx4_en]
> ? mlx4_en_poll_rx_cq+0x64/0x100 [mlx4_en]
> ? net_rx_action+0x151/0x4a0
> ? __do_softirq+0xed/0x55b
> ? irq_exit+0xea/0x100
> ? xen_evtchn_do_upcall+0x2c/0x40
> ? xen_do_hypervisor_callback+0x29/0x40
> 
> ? xen_hypercall_domctl+0xa/0x20
> ? xen_hypercall_domctl+0x8/0x20
> ? privcmd_ioctl+0x221/0x990 [xen_privcmd]
> ? do_vfs_ioctl+0xa5/0x6f0
> ? ksys_ioctl+0x60/0x90
> ? trace_hardirqs_off_thunk+0x1a/0x20
> ? __x64_sys_ioctl+0x16/0x20
> ? do_syscall_64+0x62/0x250
> ? entry_SYSCALL_64_after_hwframe+0x49/0xbe
> 
> Fix that by testing preempt_count() before calling cond_resched().
> 
> In kernel 5.8 this can't happen any more due to the entry code rework
> (more than 100 patches, so not a candidate for backporting).
> 
> The issue was introduced in kernel 4.3, so this patch should go into
> all stable kernels in [4.3 ... 5.7].

Now queued up, thanks!

greg k-h

Re: [Xen-devel] [PATCH STABLE 4.9] x86, mm, gup: prevent get_page() race with munmap in paravirt guest

[Greg KH]

On Fri, Aug 02, 2019 at 06:06:14PM +0200, Vlastimil Babka wrote:
> The x86 version of get_user_pages_fast() relies on disabled interrupts to
> synchronize gup_pte_range() between gup_get_pte(ptep); and get_page() against
> a parallel munmap. The munmap side nulls the pte, then flushes TLBs, then
> releases the page. As TLB flush is done synchronously via IPI disabling
> interrupts blocks the page release, and get_page(), which assumes existing
> reference on page, is thus safe.
> However when TLB flush is done by a hypercall, e.g. in a Xen PV guest, there 
> is
> no blocking thanks to disabled interrupts, and get_page() can succeed on a 
> page
> that was already freed or even reused.
> 
> We have recently seen this happen with our 4.4 and 4.12 based kernels, with
> userspace (java) that exits a thread, where mm_release() performs a 
> futex_wake()
> on tsk->clear_child_tid, and another thread in parallel unmaps the page where
> tsk->clear_child_tid points to. The spurious get_page() succeeds, but futex 
> code
> immediately releases the page again, while it's already on a freelist. 
> Symptoms
> include a bad page state warning, general protection faults acessing a 
> poisoned
> list prev/next pointer in the freelist, or free page pcplists of two cpus 
> joined
> together in a single list. Oscar has also reproduced this scenario, with a
> patch inserting delays before the get_page() to make the race window larger.
> 
> Fix this by removing the dependency on TLB flush interrupts the same way as 
> the
> generic get_user_pages_fast() code by using page_cache_add_speculative() and
> revalidating the PTE contents after pinning the page. Mainline is safe since
> 4.13 where the x86 gup code was removed in favor of the common code. Accessing
> the page table itself safely also relies on disabled interrupts and TLB flush
> IPIs that don't happen with hypercalls, which was acknowledged in commit
> 9e52fc2b50de ("x86/mm: Enable RCU based page table freeing
> (CONFIG_HAVE_RCU_TABLE_FREE=y)"). That commit with follups should also be
> backported for full safety, although our reproducer didn't hit a problem
> without that backport.
> 
> Reproduced-by: Oscar Salvador 
> Signed-off-by: Vlastimil Babka 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: Peter Zijlstra 
> Cc: Juergen Gross 
> Cc: Kirill A. Shutemov 
> Cc: Vitaly Kuznetsov 
> Cc: Linus Torvalds 
> Cc: Borislav Petkov 
> Cc: Dave Hansen 
> Cc: Andy Lutomirski 
> ---
> 
> Hi, I'm sending this stable-only patch for consideration because it's probably
> unrealistic to backport the 4.13 switch to generic GUP. I can look at 4.4 and
> 3.16 if accepted. The RCU page table freeing could be also considered.
> Note the patch also includes page refcount protection. I found out that
> 8fde12ca79af ("mm: prevent get_user_pages() from overflowing page refcount")
> backport to 4.9 missed the arch-specific gup implementations:
> https://lore.kernel.org/lkml/6650323f-dbc9-f069-000b-f6b0f941a...@suse.cz/

This looks sane to me, thank you for the backport.  I've queued it up
now, and if anyone has any objections, please let me know.

thanks,

greg k-h

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [stable] xen/pciback: Don't disable PCI_COMMAND on PCI device reset.

[Greg KH]

On Mon, Jun 03, 2019 at 03:10:55PM +0200, Juergen Gross wrote:
> On 03/06/2019 14:02, Ben Hutchings wrote:
> > On Mon, 2019-06-03 at 10:00 +0200, Greg KH wrote:
> >> On Thu, May 30, 2019 at 07:02:34PM -0700, Konrad Rzeszutek Wilk wrote:
> >>> On 5/30/19 8:16 AM, Ben Hutchings wrote:
> >>>> I'm looking at CVE-2015-8553 which is fixed by:
> >>>>
> >>>> commit 7681f31ec9cdacab4fd10570be924f2cef6669ba
> >>>> Author: Konrad Rzeszutek Wilk 
> >>>> Date:   Wed Feb 13 18:21:31 2019 -0500
> >>>>
> >>>>  xen/pciback: Don't disable PCI_COMMAND on PCI device reset.
> >>>>
> >>>> I'm aware that this change is incompatible with qemu < 2.5, but that's
> >>>> now quite old.  Do you think it makes sense to apply this change to
> >>>> some stable branches?
> >>>>
> >>>> Ben.
> >>>>
> >>>
> >>> Hey Ben,
> >>>
> >>>  My opinion is to drop it, but if Juergen thinks it makes sense to
> >>> backport I am not going to argue.
> >>
> >> Ok, I've queued this up now, thanks.
> > 
> > Juergen said:
> > 
> >> I'm with Konrad here.
> > 
> > so unless I'm very confused this should *not* be applied to stable
> > branches.
> 
> "should not" is a little bit hard. I didn't opt for adding it, but I
> don't object to add it either (like Konrad :-) ).

Ok, I've added it as it does fix a CVE, and if I don't, I'll get odd
emails 6 months from now asking why I didn't include it...

thanks,

greg k-h

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [stable] xen/pciback: Don't disable PCI_COMMAND on PCI device reset.

[Greg KH]

On Thu, May 30, 2019 at 07:02:34PM -0700, Konrad Rzeszutek Wilk wrote:
> On 5/30/19 8:16 AM, Ben Hutchings wrote:
> > I'm looking at CVE-2015-8553 which is fixed by:
> > 
> > commit 7681f31ec9cdacab4fd10570be924f2cef6669ba
> > Author: Konrad Rzeszutek Wilk 
> > Date:   Wed Feb 13 18:21:31 2019 -0500
> > 
> >  xen/pciback: Don't disable PCI_COMMAND on PCI device reset.
> > 
> > I'm aware that this change is incompatible with qemu < 2.5, but that's
> > now quite old.  Do you think it makes sense to apply this change to
> > some stable branches?
> > 
> > Ben.
> > 
> 
> Hey Ben,
> 
>  My opinion is to drop it, but if Juergen thinks it makes sense to
> backport I am not going to argue.

Ok, I've queued this up now, thanks.

greg k-h

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Linux 3.18 no longer boots under Xen, Xen CI dropping it

[Greg KH]

On Wed, May 29, 2019 at 10:06:00AM -0600, Jan Beulich wrote:
> >>> On 29.05.19 at 17:57,  wrote:
> > Linux 3.18 no longer boots under Xen.
> > 
> > This has been true for over half a year.  The Xen project CI has been
> > sending automatic mails including bisection reports (see below).
> > I emailed Xen kernel folks and got no takers for fixing this.
> > 
> > Unless this is fixed soon, or at least someone shows some inclination
> > to investigate this regression, I intend to drop all testing of this
> > "stable" branch.  It has rotted and no-one is fixing it.
> 
> Afaics 3.18 has been marked EOL upstream.

Yes, there will not be any more 3.18.y releases on kernel.org anymore.

I don't think I recall any people complaining about 3.18 breaking on
Xen as the only users that I know of for that kernel are some SoC-based
devices, and they do not use Xen.

thanks,

greg k-h

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4.9 1/1] jiffies: use jiffies64_to_nsecs() to fix 100% steal usage for xen vcpu hotplug

[Greg KH]

On Wed, Mar 06, 2019 at 03:35:40PM +0800, Dongli Zhang wrote:
> Thanks to Joe Jin's reminding, this patch is applicable to mainline linux
> kernel, although there is no issue due to this kind of bug in mainline kernel.
> 
> Therefore, can I first submit this patch to mainline kernel and then backport 
> it
> to stable linux with more detailed explanation how the issue is reproduced on 
> xen?

Yes, please do that.

thanks,

greg k-h

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [Intel-gfx] [PATCH 1/3] treewide: Lift switch variables out of switches

[Greg KH]

On Thu, Jan 24, 2019 at 07:55:51AM +1300, Kees Cook wrote:
> On Thu, Jan 24, 2019 at 4:44 AM Jani Nikula  
> wrote:
> >
> > On Wed, 23 Jan 2019, Edwin Zimmerman  wrote:
> > > On Wed, 23 Jan 2019, Jani Nikula  wrote:
> > >> On Wed, 23 Jan 2019, Greg KH  wrote:
> > >> > On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
> > >> >> Variables declared in a switch statement before any case statements
> > >> >> cannot be initialized, so move all instances out of the switches.
> > >> >> After this, future always-initialized stack variables will work
> > >> >> and not throw warnings like this:
> > >> >>
> > >> >> fs/fcntl.c: In function ‘send_sigio_to_task’:
> > >> >> fs/fcntl.c:738:13: warning: statement will never be executed 
> > >> >> [-Wswitch-unreachable]
> > >> >>siginfo_t si;
> > >> >>  ^~
> > >> >
> > >> > That's a pain, so this means we can't have any new variables in { }
> > >> > scope except for at the top of a function?
> 
> Just in case this wasn't clear: no, it's just the switch statement
> before the first "case". I cannot imagine how bad it would be if we
> couldn't have block-scoped variables! Heh. :)

Sorry, it was not clear at first glance.  So no more objection from me
for this change.

greg k-h

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 1/3] treewide: Lift switch variables out of switches

[Greg KH]

On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
> Variables declared in a switch statement before any case statements
> cannot be initialized, so move all instances out of the switches.
> After this, future always-initialized stack variables will work
> and not throw warnings like this:
> 
> fs/fcntl.c: In function ‘send_sigio_to_task’:
> fs/fcntl.c:738:13: warning: statement will never be executed 
> [-Wswitch-unreachable]
>siginfo_t si;
>  ^~

That's a pain, so this means we can't have any new variables in { }
scope except for at the top of a function?

That's going to be a hard thing to keep from happening over time, as
this is valid C :(

greg k-h

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Linux 4.19.5 fails to boot as Xen dom0

[Greg KH]

On Fri, Jan 11, 2019 at 08:59:52AM +0100, Juergen Gross wrote:
> On 22/12/2018 12:14, Juergen Gross wrote:
> > On 06/12/2018 12:46, Greg KH wrote:
> >> On Thu, Dec 06, 2018 at 12:31:15PM +0100, Juergen Gross wrote:
> >>> On 06/12/2018 12:13, Greg KH wrote:
> >>>> On Thu, Nov 29, 2018 at 02:35:17PM +0100, Juergen Gross wrote:
> >>>>> On 29/11/2018 14:26, Kirill A. Shutemov wrote:
> >>>>>> On Thu, Nov 29, 2018 at 09:41:25AM +, Juergen Gross wrote:
> >>>>>>> On 29/11/2018 02:22, Hans van Kranenburg wrote:
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> As also seen at:
> >>>>>>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914951
> >>>>>>>>
> >>>>>>>> Attached there are two serial console output logs. One is starting 
> >>>>>>>> with
> >>>>>>>> Xen 4.11 (from debian unstable) as dom0, and the other one without 
> >>>>>>>> Xen.
> >>>>>>>>
> >>>>>>>> [2.085543] BUG: unable to handle kernel paging request at
> >>>>>>>> 888d9fffc000
> >>>>>>>> [2.085610] PGD 200c067 P4D 200c067 PUD 0
> >>>>>>>> [2.085674] Oops:  [#1] SMP NOPTI
> >>>>>>>> [2.085736] CPU: 1 PID: 1 Comm: swapper/0 Not tainted
> >>>>>>>> 4.19.0-trunk-amd64 #1 Debian 4.19.5-1~exp1+pvh1
> >>>>>>>> [2.085823] Hardware name: HP ProLiant DL360 G7, BIOS P68 
> >>>>>>>> 05/21/2018
> >>>>>>>> [2.085895] RIP: e030:ptdump_walk_pgd_level_core+0x1fd/0x490
> >>>>>>>> [...]
> >>>>>>>
> >>>>>>> The offending stable commit is 
> >>>>>>> 4074ca7d8a1832921c865d250bbd08f3441b3657
> >>>>>>> ("x86/mm: Move LDT remap out of KASLR region on 5-level paging"), this
> >>>>>>> is commit d52888aa2753e3063a9d3a0c9f72f94aa9809c15 upstream.
> >>>>>>>
> >>>>>>> Current upstream kernel is booting fine under Xen, so in general the
> >>>>>>> patch should be fine. Using an upstream kernel built from above commit
> >>>>>>> (with the then needed Xen fixup patch 1457d8cf7664f34c4ba534) is fine,
> >>>>>>> too.
> >>>>>>>
> >>>>>>> Kirill, are you aware of any prerequisite patch from 4.20 which could 
> >>>>>>> be
> >>>>>>> missing in 4.19.5?
> >>>>>>
> >>>>>> I'm not.
> >>>>>>
> >>>>>> Let me look into this.
> >>>>>>
> >>>>>
> >>>>> What is making me suspicious is the failure happening just after
> >>>>> releasing the init memory. Maybe there is an access to .init.data
> >>>>> segment or similar? The native kernel booting could be related to the
> >>>>> usage of 2M mappings not being available in a PV-domain.
> >>>>
> >>>> Did this ever get fixed anywhere that I can properly backport it to the
> >>>> 4.19.y tree?
> >>>
> >>> https://lore.kernel.org/lkml/20181130202328.65359-2-kirill.shute...@linux.intel.com/
> >>>
> >>> Still pending upstream. Just pinged tglx.
> >>
> >> Thanks, it should have gotten a cc: stable@ tag, but I can watch out for
> >> it...
> > 
> > It's upstream now: commit 16877a5570e0c5f4270d5b17f9bab427bcae9514
> 
> Any reason you didn't include this patch in 4.19.14?

I was catching up on pending patches and got to this yesterday. It
should now be queued up already for the next releases, right?

thanks,

greg k-h

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Linux 4.19.5 fails to boot as Xen dom0

[Greg KH]

On Thu, Dec 06, 2018 at 12:31:15PM +0100, Juergen Gross wrote:
> On 06/12/2018 12:13, Greg KH wrote:
> > On Thu, Nov 29, 2018 at 02:35:17PM +0100, Juergen Gross wrote:
> >> On 29/11/2018 14:26, Kirill A. Shutemov wrote:
> >>> On Thu, Nov 29, 2018 at 09:41:25AM +, Juergen Gross wrote:
> >>>> On 29/11/2018 02:22, Hans van Kranenburg wrote:
> >>>>> Hi,
> >>>>>
> >>>>> As also seen at:
> >>>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914951
> >>>>>
> >>>>> Attached there are two serial console output logs. One is starting with
> >>>>> Xen 4.11 (from debian unstable) as dom0, and the other one without Xen.
> >>>>>
> >>>>> [2.085543] BUG: unable to handle kernel paging request at
> >>>>> 888d9fffc000
> >>>>> [2.085610] PGD 200c067 P4D 200c067 PUD 0
> >>>>> [2.085674] Oops:  [#1] SMP NOPTI
> >>>>> [2.085736] CPU: 1 PID: 1 Comm: swapper/0 Not tainted
> >>>>> 4.19.0-trunk-amd64 #1 Debian 4.19.5-1~exp1+pvh1
> >>>>> [2.085823] Hardware name: HP ProLiant DL360 G7, BIOS P68 05/21/2018
> >>>>> [2.085895] RIP: e030:ptdump_walk_pgd_level_core+0x1fd/0x490
> >>>>> [...]
> >>>>
> >>>> The offending stable commit is 4074ca7d8a1832921c865d250bbd08f3441b3657
> >>>> ("x86/mm: Move LDT remap out of KASLR region on 5-level paging"), this
> >>>> is commit d52888aa2753e3063a9d3a0c9f72f94aa9809c15 upstream.
> >>>>
> >>>> Current upstream kernel is booting fine under Xen, so in general the
> >>>> patch should be fine. Using an upstream kernel built from above commit
> >>>> (with the then needed Xen fixup patch 1457d8cf7664f34c4ba534) is fine,
> >>>> too.
> >>>>
> >>>> Kirill, are you aware of any prerequisite patch from 4.20 which could be
> >>>> missing in 4.19.5?
> >>>
> >>> I'm not.
> >>>
> >>> Let me look into this.
> >>>
> >>
> >> What is making me suspicious is the failure happening just after
> >> releasing the init memory. Maybe there is an access to .init.data
> >> segment or similar? The native kernel booting could be related to the
> >> usage of 2M mappings not being available in a PV-domain.
> > 
> > Did this ever get fixed anywhere that I can properly backport it to the
> > 4.19.y tree?
> 
> https://lore.kernel.org/lkml/20181130202328.65359-2-kirill.shute...@linux.intel.com/
> 
> Still pending upstream. Just pinged tglx.

Thanks, it should have gotten a cc: stable@ tag, but I can watch out for
it...

greg k-h

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Linux 4.19.5 fails to boot as Xen dom0

[Greg KH]

On Thu, Nov 29, 2018 at 02:35:17PM +0100, Juergen Gross wrote:
> On 29/11/2018 14:26, Kirill A. Shutemov wrote:
> > On Thu, Nov 29, 2018 at 09:41:25AM +, Juergen Gross wrote:
> >> On 29/11/2018 02:22, Hans van Kranenburg wrote:
> >>> Hi,
> >>>
> >>> As also seen at:
> >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914951
> >>>
> >>> Attached there are two serial console output logs. One is starting with
> >>> Xen 4.11 (from debian unstable) as dom0, and the other one without Xen.
> >>>
> >>> [2.085543] BUG: unable to handle kernel paging request at
> >>> 888d9fffc000
> >>> [2.085610] PGD 200c067 P4D 200c067 PUD 0
> >>> [2.085674] Oops:  [#1] SMP NOPTI
> >>> [2.085736] CPU: 1 PID: 1 Comm: swapper/0 Not tainted
> >>> 4.19.0-trunk-amd64 #1 Debian 4.19.5-1~exp1+pvh1
> >>> [2.085823] Hardware name: HP ProLiant DL360 G7, BIOS P68 05/21/2018
> >>> [2.085895] RIP: e030:ptdump_walk_pgd_level_core+0x1fd/0x490
> >>> [...]
> >>
> >> The offending stable commit is 4074ca7d8a1832921c865d250bbd08f3441b3657
> >> ("x86/mm: Move LDT remap out of KASLR region on 5-level paging"), this
> >> is commit d52888aa2753e3063a9d3a0c9f72f94aa9809c15 upstream.
> >>
> >> Current upstream kernel is booting fine under Xen, so in general the
> >> patch should be fine. Using an upstream kernel built from above commit
> >> (with the then needed Xen fixup patch 1457d8cf7664f34c4ba534) is fine,
> >> too.
> >>
> >> Kirill, are you aware of any prerequisite patch from 4.20 which could be
> >> missing in 4.19.5?
> > 
> > I'm not.
> > 
> > Let me look into this.
> > 
> 
> What is making me suspicious is the failure happening just after
> releasing the init memory. Maybe there is an access to .init.data
> segment or similar? The native kernel booting could be related to the
> usage of 2M mappings not being available in a PV-domain.

Did this ever get fixed anywhere that I can properly backport it to the
4.19.y tree?

thanks,

greg k-h

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] xen-blkfront: fix kernel panic with blkfront_remove()

[Greg KH]

On Thu, Nov 08, 2018 at 04:58:28PM -0800, Manjunath Patil wrote:
> If a hot-attaching device fails inside domU[ex:negotiate_mq() returns
> with ENOMEM] we clear the blkfront_info struct in talk_to_blkback()
> 
> When we try to detach the device, blkfront_remove() tries to access
> blkfront_info leading to kernel panic.
> 
> Typical call stack involving panic -
>  #10 page_fault at 816f25df
>  [exception RIP: blkif_free+46]
>  #11 blkfront_remove at a004de47 [xen_blkfront]
>  #12 xenbus_dev_remove at 813faa4c
>  #13 __device_release_driver at 814769aa
>  #14 device_release_driver at 81476a63
>  #15 bus_remove_device at 814762eb
>  #16 device_del at 81472684
>  #17 device_unregister at 814727e2
>  #18 xenbus_dev_changed at 813fa89f
>  #19 frontend_changed at 813fca19
>  #20 xenwatch_thread at 813f88f9
>  #21 kthread at 810a486b
>  #22 ret_from_fork at 816ed2a8
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Manjunath Patil 
> ---
>  drivers/block/xen-blkfront.c |3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index dc8fe25..144cda8 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -2496,6 +2496,9 @@ static int blkfront_remove(struct xenbus_device *xbdev)
>  
>   dev_dbg(>dev, "%s removed", xbdev->nodename);
>  
> + if(!info)
> + return 0;
> +

Always run scripts/checkpatch.pl on your patches so you do not get a
grumpy maintainer telling you to run scripts/checkpatch.pl on your
patches.

thanks,

greg k-h

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [GIT PULL] xen: fixes for 4.19-rc5

[Greg KH]

On Sun, Sep 23, 2018 at 09:55:38AM +0200, Juergen Gross wrote:
> Linus/Greg,
> 
> Please git pull the following tag:
> 
>  git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git 
> for-linus-4.19d-rc5-tag
> 
> xen: fixes for 4.19-rc5
> 
> It contains two small fixes for xen drivers.

Noe pulled, thanks.

greg k-h

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] xen-swiotlb: use actually allocated size on check physical contiguous

[Greg KH]

On Tue, Sep 04, 2018 at 11:16:58AM -0700, Joe Jin wrote:
> xen_swiotlb_{alloc,free}_coherent() actually allocate/free size by order
> but used the required size to check if address is physical contiguous,
> if first pages are physical contiguous also passed
> range_straddles_page_boundary() check, but others were not it will
> lead kernel panic.
> 
> Signed-off-by: Joe Jin 
> Cc: Konrad Rzeszutek Wilk 
> ---
>  drivers/xen/swiotlb-xen.c | 6 ++
>  1 file changed, 6 insertions(+)
> 



This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2] x86/entry/64: Remove %ebx handling from error_entry/exit

[Greg KH]

On Tue, Aug 21, 2018 at 06:42:56PM -0700, Andy Lutomirski wrote:
> On Thu, Aug 16, 2018 at 9:19 PM, Sarah Newman  wrote:
> > commit b3681dd548d06deb2e1573890829dff4b15abf46 upstream.
> >
> > This version applies to v4.9.
> 
> ...
> 
> Looks okay to me.

Thanks for the review, and Sarah, thanks for the backport.  Now queued
up.

greg k-h

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/entry/64: Remove %ebx handling from error_entry/exit

[Greg KH]

On Fri, Aug 10, 2018 at 12:23:45AM -0700, Sarah Newman wrote:
> On 08/09/2018 05:41 AM, David Woodhouse wrote:
> > On Wed, 2018-08-08 at 10:35 -0700, Sarah Newman wrote:
> >> commit b3681dd548d06deb2e1573890829dff4b15abf46 upstream.
> >>
> >> This version applies to v4.9.
> > 
> > I think you can kill the 'xorl %ebx,%ebx' from error_entry too but yes,
> > this does want to go to 4.9 and earlier because the 'Fixes:' tag is a
> > bit of a lie — the problem existed before that, at least in theory.
> 
> The commit 2140a9942 "x86/entry/64: Relax pvops stub clobber
> specifications" was what removed the "movl %ebx, %eax" line later on
> originally, but it was the commit 3ac6d8c787b8 that removed the
> 'xorl %ebx,%ebx'. So these weren't matched.
> 
> I don't know if it's a concern, but if someone had gone to the effort of
> backporting the original commit 3ac6d8c787b83, adding the removal of
> 'xorl %ebx,%ebx' to this patch would create merge conflicts.
> For that reason and given the line is harmless, should it be left in?

I need some kind of agreement here for me to know what to do with this
patch...  {hint}

thanks,

greg k-h

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RESEND] Spectre-v2 (IBPB/IBRS) and SSBD fixes for 4.4.y

[Greg KH]

On Tue, Aug 07, 2018 at 12:08:07PM -0700, Srivatsa S. Bhat wrote:
> Also, upstream commit e01e80634ecdde1 (fork: unconditionally clear
> stack on fork) applies cleanly on 4.14 stable, so it would be great to
> cherry-pick it to 4.14 stable as well.

It is already in the 4.14.60 release, did I somehow mess up the
backport?

thanks,

greg k-h

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RESEND] Spectre-v2 (IBPB/IBRS) and SSBD fixes for 4.4.y

[Greg KH]

On Fri, Aug 03, 2018 at 04:20:31PM -0700, Srivatsa S. Bhat wrote:
> On 8/2/18 3:22 PM, Kees Cook wrote:
> > On Thu, Aug 2, 2018 at 12:22 PM, Srivatsa S. Bhat
> >  wrote:
> >> On 7/26/18 4:09 PM, Kees Cook wrote:
> >>> On Tue, Jul 24, 2018 at 3:02 PM, Jiri Kosina  wrote:
>  On Tue, 24 Jul 2018, Srivatsa S. Bhat wrote:
> 
> > However, if you are proposing that you'd like to contribute the enhanced
> > PTI/Spectre (upstream) patches from the SLES 4.4 tree to 4.4 stable, and
> > have them merged instead of this patch series, then I would certainly
> > welcome it!
> 
>  I'd in principle love us to push everything back to 4.4, but there are a
>  few reasons (*) why that's not happening shortly.
> 
>  Anyway, to point out explicitly what's really needed for those folks
>  running 4.4-stable and relying on PTI providing The Real Thing(TM), it's
>  either a 4.4-stable port of
> 
>  
>  http://kernel.suse.com/cgit/kernel-source/plain/patches.suse/x86-entry-64-use-a-per-cpu-trampoline-stack.patch?id=3428a77b02b1ba03e45d8fc352ec350429f57fc7
> 
>  or making THREADINFO_GFP imply __GFP_ZERO.
> >>>
> >>> This is true in Linus's tree now. Should be trivial to backport:
> >>> https://git.kernel.org/linus/e01e80634ecdd
> >>>
> >>
> >> Hi Jiri, Kees,
> >>
> >> Thank you for suggesting the patch! I have attached the (locally
> >> tested) 4.4 and 4.9 backports of that patch with this mail. (The
> >> mainline commit applies cleanly on 4.14).
> >>
> >> Greg, could you please consider including them in stable 4.4, 4.9
> >> and 4.14?
> > 
> > I don't think your v4.9 is sufficient: it leaves the vmapped stack
> > uncleared. v4.9 needs ca182551857 ("kmemleak: clear stale pointers
> > from task stacks") included in the backport (really, just adding the
> > memset()).
> > 
> 
> Ah, I see, thank you! I have attached the updated patchset for 4.9
> with this mail.
> 
> > Otherwise, yup, looks good.
> > 
> Thank you for reviewing the patches!
>  
> Regards,
> Srivatsa
> VMware Photon OS

These work for 4.9, do you also have a set for 4.4?

thanks,

greg k-h

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RESEND] Spectre-v2 (IBPB/IBRS) and SSBD fixes for 4.4.y

[Greg KH]

On Sat, Jul 14, 2018 at 02:25:43AM -0700, Srivatsa S. Bhat wrote:
> Hi Greg,
> 
> This patch series is a backport of the Spectre-v2 fixes (IBPB/IBRS)
> and patches for the Speculative Store Bypass vulnerability to 4.4.y
> (they apply cleanly on top of 4.4.140).
> 
> I used 4.9.y as my reference when backporting to 4.4.y (as I thought
> that would minimize the amount of fixing up necessary). Unfortunately
> I had to skip the KVM fixes for these vulnerabilities, as the KVM
> codebase is drastically different in 4.4 as compared to 4.9. (I tried
> my best to backport them initially, but wasn't confident that they
> were correct, so I decided to drop them from this series).
> 
> You'll notice that the initial few patches in this series include
> cleanups etc., that are non-critical to IBPB/IBRS/SSBD. Most of these
> patches are aimed at getting the cpufeature.h vs cpufeatures.h split
> into 4.4, since a lot of the subsequent patches update these headers.
> On my first attempt to backport these patches to 4.4.y, I had actually
> tried to do all the updates on the cpufeature.h file itself, but it
> started getting very cumbersome, so I resorted to backporting the
> cpufeature.h vs cpufeatures.h split and their dependencies as well. I
> think apart from these initial patches, the rest of the patchset
> doesn't have all that much noise. 
> 
> This patchset has been tested on both Intel and AMD machines (Intel
> Xeon CPU E5-2660 v4 and AMD EPYC 7281 16-Core Processor, respectively)
> with updated microcode. All the patch backports have been
> independently reviewed by Matt Helsley, Alexey Makhalov and Bo Gan.
> 
> I would appreciate if you could kindly consider these patches for
> review and inclusion in a future 4.4.y release.

Given no one has complained about these yet, I've queued them all up,
including the 2 extra ones you sent afterward.

Let's see what breaks :)

thanks,

greg k-h

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/entry/64: Remove %ebx handling from error_entry/exit

[Greg KH]

On Sun, Jul 22, 2018 at 11:05:09AM -0700, Andy Lutomirski wrote:
> error_entry and error_exit communicate the user vs kernel status of
> the frame using %ebx.  This is unnecessary -- the information is in
> regs->cs.  Just use regs->cs.
> 
> This makes error_entry simpler and makes error_exit more robust.
> 
> It also fixes a nasty bug.  Before all the Spectre nonsense, The
> xen_failsafe_callback entry point returned like this:
> 
> ALLOC_PT_GPREGS_ON_STACK
> SAVE_C_REGS
> SAVE_EXTRA_REGS
> ENCODE_FRAME_POINTER
> jmp error_exit
> 
> And it did not go through error_entry.  This was bogus: RBX
> contained garbage, and error_exit expected a flag in RBX.
> Fortunately, it generally contained *nonzero* garbage, so the
> correct code path was used.  As part of the Spectre fixes, code was
> added to clear RBX to mitigate certain speculation attacks.  Now,
> depending on kernel configuration, RBX got zeroed and, when running
> some Wine workloads, the kernel crashes.  This was introduced by:
> 
> commit 3ac6d8c787b8 ("x86/entry/64: Clear registers for
> exceptions/interrupts, to reduce speculation attack surface")
> 
> With this patch applied, RBX is no longer needed as a flag, and the
> problem goes away.
> 
> I suspect that malicious userspace could use this bug to crash the
> kernel even without the offending patch applied, though.
> 
> [Historical note: I wrote this patch as a cleanup before I was aware
>  of the bug it fixed.]
> 
> [Note to stable maintainers: this should probably get applied to all
>  kernels.  If you're nervous about that, a more conservative fix to
>  add xorl %ebx,%ebx; incl %ebx before the jump to error_exit should
>  also fix the problem.]
> 
> Cc: Brian Gerst 
> Cc: Borislav Petkov 
> Cc: Dominik Brodowski 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> Cc: Thomas Gleixner 
> Cc: Boris Ostrovsky 
> Cc: Juergen Gross 
> Cc: xen-devel@lists.xenproject.org
> Cc: x...@kernel.org
> Cc: sta...@vger.kernel.org
> Fixes: 3ac6d8c787b8 ("x86/entry/64: Clear registers for 
> exceptions/interrupts, to reduce speculation attack surface")
> Reported-and-tested-by: "M. Vefa Bicakci" 
> Signed-off-by: Andy Lutomirski 
> ---
> 
> I could also submit the conservative fix tagged for -stable and respin
> this on top of it.  Ingo, Greg, what do you prefer?

I don't care, this patch looks good to me to take as-is for the stable
trees.  If you trust it in Linus's tree, it should be fine for others :)

thanks,

greg k-h

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RESEND] Spectre-v2 (IBPB/IBRS) and SSBD fixes for 4.4.y

[Greg KH]

On Sat, Jul 14, 2018 at 02:25:43AM -0700, Srivatsa S. Bhat wrote:
> Hi Greg,
> 
> This patch series is a backport of the Spectre-v2 fixes (IBPB/IBRS)
> and patches for the Speculative Store Bypass vulnerability to 4.4.y
> (they apply cleanly on top of 4.4.140).
> 
> I used 4.9.y as my reference when backporting to 4.4.y (as I thought
> that would minimize the amount of fixing up necessary). Unfortunately
> I had to skip the KVM fixes for these vulnerabilities, as the KVM
> codebase is drastically different in 4.4 as compared to 4.9. (I tried
> my best to backport them initially, but wasn't confident that they
> were correct, so I decided to drop them from this series).
> 
> You'll notice that the initial few patches in this series include
> cleanups etc., that are non-critical to IBPB/IBRS/SSBD. Most of these
> patches are aimed at getting the cpufeature.h vs cpufeatures.h split
> into 4.4, since a lot of the subsequent patches update these headers.
> On my first attempt to backport these patches to 4.4.y, I had actually
> tried to do all the updates on the cpufeature.h file itself, but it
> started getting very cumbersome, so I resorted to backporting the
> cpufeature.h vs cpufeatures.h split and their dependencies as well. I
> think apart from these initial patches, the rest of the patchset
> doesn't have all that much noise. 

I've applied the "initial" patches to the 4.4-stable queue right now, as
those were all just "housekeeping" stuff.  I'll let others review the
rest of the series this week and see if anyone objects before throwing
them at the test-bots.

Many thanks for doing all of this work.

greg k-h

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 0/3] Correct 4.9 stable commit 944e0fc51a89c98

[Greg KH]

On Wed, May 30, 2018 at 01:09:55PM +0200, Juergen Gross wrote:
> Above commit is a wrong backport, as it is based on a missing
> prerequisite patch. Correct that by reverting said commit, include the
> missing patch, and do the backport correctly.
> 
> Juergen Gross (3):
>   x86/amd: revert commit 944e0fc51a89c9827b98813d65dc083274777c7f
>   xen: set cpu capabilities from xen_start_kernel()
>   x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS when running under Xen

All now queued up, thanks.

greg k-h

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] xen: fix pv domain on amd in 4.9 stable branch

[Greg KH]

On Wed, May 30, 2018 at 11:33:22AM +0200, Juergen Gross wrote:
> On 30/05/18 10:33, Greg KH wrote:
> > On Tue, May 29, 2018 at 03:11:36PM +0200, Juergen Gross wrote:
> >> Commit 944e0fc51a89c9827b98813d65dc083274777c7f ("x86/amd: don't set
> >> X86_BUG_SYSRET_SS_ATTRS when running under Xen") breaks Xen pv-domains
> >> on AMD processors, as a prerequisite patch from upstream wasn't added
> >> to 4.9.
> > 
> > What is the prerequsite patch's git id in Linus's tree?
> 
> Commit 0808e80cb760de2733c0527d2090ed2205a1eef8. It won't apply,
> backporting is rather easy, though.
> 
> I thought this was a patch in the middle of a larger series, but
> obviously I misremembered. It was the first patch of that series.
> 
> I'll send a series in case you don't object:
> 
> - revert of stable-4.9 944e0fc51a89c9827b98813d65dc083274777c7f
> - backport of 0808e80cb760de2733c0527d2090ed2205a1eef8
> - new backport of def9331a1290cc6132d79f8e6565871e8e38

That would be great, I'll gladly take that, thanks.

greg k-h

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] xen: fix pv domain on amd in 4.9 stable branch

[Greg KH]

On Tue, May 29, 2018 at 03:11:36PM +0200, Juergen Gross wrote:
> Commit 944e0fc51a89c9827b98813d65dc083274777c7f ("x86/amd: don't set
> X86_BUG_SYSRET_SS_ATTRS when running under Xen") breaks Xen pv-domains
> on AMD processors, as a prerequisite patch from upstream wasn't added
> to 4.9.

What is the prerequsite patch's git id in Linus's tree?

> Fix that by adding the prerequisite setting of X86_FEATURE_XENPV to the
> Xen pv early boot path.
> 
> Cc: David Woodhouse 
> Cc: Boris Ostrovsky 
> Signed-off-by: Juergen Gross 
> ---
>  arch/x86/xen/enlighten.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index 081437b5f381..674656cdb68c 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -1632,6 +1632,9 @@ asmlinkage __visible void __init xen_start_kernel(void)
>   xen_init_irq_ops();
>   xen_init_cpuid_mask();
>  
> + /* Needed for init_amd(). */
> + setup_force_cpu_cap(X86_FEATURE_XENPV);
> +
>  #ifdef CONFIG_X86_LOCAL_APIC
>   /*
>* set up the basic apic ops.
> -- 
> 2.13.6

I'd prefer to take whatever is in Linus's tree if at all possible.

thanks,

greg k-h

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH UPSTREAM] xen-swiotlb: fix the check condition for xen_swiotlb_free_coherent

[Greg KH]

On Thu, May 17, 2018 at 11:45:57AM -0700, Joe Jin wrote:
> When run raidconfig from Dom0 we found that the Xen DMA heap is reduced,
> but Dom Heap is increased by the same size. Tracing raidconfig we found
> that the related ioctl() in megaraid_sas will call dma_alloc_coherent()
> to apply memory. If the memory allocated by Dom0 is not in the DMA area,
> it will exchange memory with Xen to meet the requiment. Later drivers
> call dma_free_coherent() to free the memory, on xen_swiotlb_free_coherent()
> the check condition (dev_addr + size - 1 <= dma_mask) is always false,
> it prevents calling xen_destroy_contiguous_region() to return the memory
> to the Xen DMA heap.
> 
> This issue introduced by commit 6810df88dcfc2 "xen-swiotlb: When doing
> coherent alloc/dealloc check before swizzling the MFNs.".
> 
> Signed-off-by: Joe Jin 
> Tested-by: John Sobecki  
> Reviewed-by: Rzeszutek Wilk 
> Cc: sta...@vger.kernel.org
> ---
>  drivers/xen/swiotlb-xen.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

What does "PATCH UPSTREAM" mean?

confused,

greg k-h

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Patch "x86/xen: Add pvh specific rsdp address retrieval function" has been added to the 4.16-stable tree

[Greg KH]

On Wed, May 02, 2018 at 11:23:12AM +0200, Juergen Gross wrote:
> On 02/05/18 00:33, gre...@linuxfoundation.org wrote:
> > 
> > This is a note to let you know that I've just added the patch titled
> > 
> > x86/xen: Add pvh specific rsdp address retrieval function
> > 
> > to the 4.16-stable tree which can be found at:
> > 
> > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
> > 
> > The filename of the patch is:
> >  x86-xen-add-pvh-specific-rsdp-address-retrieval-function.patch
> > and it can be found in the queue-4.16 subdirectory.
> > 
> > If you, or anyone else, feels it should not be added to the stable tree,
> > please let  know about it.
> > 
> > 
> > From foo@baz Tue May  1 14:59:18 PDT 2018
> > From: Juergen Gross 
> > Date: Mon, 19 Feb 2018 11:09:06 +0100
> > Subject: x86/xen: Add pvh specific rsdp address retrieval function
> > 
> > From: Juergen Gross 
> > 
> > [ Upstream commit b17d9d1df3c33a4f1d2bf397e2257aecf9dc56d4 ]
> > 
> > Add pvh_get_root_pointer() for Xen PVH guests to communicate the
> > address of the RSDP table given to the kernel via Xen start info.
> > 
> > This makes the kernel boot again in PVH mode after on recent Xen the
> > RSDP was moved to higher addresses. So up to that change it was pure
> > luck that the legacy method to locate the RSDP was working when
> > running as PVH mode.
> > 
> > Signed-off-by: Juergen Gross 
> > Reviewed-by: Andy Shevchenko 
> > Acked-by: Thomas Gleixner 
> > Acked-by: Rafael J. Wysocki 
> > Cc: Borislav Petkov 
> > Cc: Eric Biederman 
> > Cc: H. Peter Anvin 
> > Cc: Kees Cook 
> > Cc: Kirill A. Shutemov 
> > Cc: Linus Torvalds 
> > Cc: Peter Zijlstra 
> > Cc: boris.ostrov...@oracle.com
> > Cc: l...@kernel.org
> > Cc: linux-a...@vger.kernel.org
> > Cc: xen-devel@lists.xenproject.org
> > Link: http://lkml.kernel.org/r/20180219100906.14265-4-jgr...@suse.com
> > Signed-off-by: Ingo Molnar 
> > Signed-off-by: Sasha Levin 
> > Signed-off-by: Greg Kroah-Hartman 
> 
> Thanks for adding this patch.
> 
> For making it compile I think you'll need upstream commits
> 038bac2b02989acf1fc938cedcb7944c02672b9f and
> dfc9327ab7c99bc13e12106448615efba833886b.

I'll just drop this and if Sasha thinks it is worth it, he can backport
these other two patches and resend them.  Especially as I think we
already talked about this in the past :)

thanks,

greg k-h

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Patches for stable

[Greg KH]

On Thu, Apr 05, 2018 at 09:02:27AM +0200, Juergen Gross wrote:
> On 05/04/18 08:33, Greg KH wrote:
> > On Wed, Apr 04, 2018 at 06:32:17PM +0200, Juergen Gross wrote:
> >> On 04/04/18 17:42, Greg KH wrote:
> >>> On Wed, Apr 04, 2018 at 05:12:32PM +0200, Juergen Gross wrote:
> >>>> On 04/04/18 16:46, Greg KH wrote:
> >>>>> On Wed, Apr 04, 2018 at 04:30:30PM +0200, Juergen Gross wrote:
> >>>>>> On 04/04/18 16:27, Greg KH wrote:
> >>>>>>> On Wed, Apr 04, 2018 at 12:38:43PM +0200, Juergen Gross wrote:
> >>>>>>>> Please add the patches:
> >>>>>>>>
> >>>>>>>> commit 038bac2b02989acf1fc938cedcb7944c02672b9f upstream
> >>>>>>>> commit dfc9327ab7c99bc13e12106448615efba833886b upstream
> >>>>>>>> commit b17d9d1df3c33a4f1d2bf397e2257aecf9dc56d4 upstream
> >>>>>>>>
> >>>>>>>> to the 4.15 and 4.16 stable kernels.
> >>>>>>>>
> >>>>>>>> Those patches are needed to boot Linux as PVH guest on recent Xen.
> >>>>>>>
> >>>>>>> So a new feature?  Why is that ok for stable kernels?
> >>>>>>
> >>>>>> It works for kernels since at least 4.11 on Xen 4.10.
> >>>>>
> >>>>> Great, so what commit caused this to fail?
> >>>>>
> >>>>> So far, in reading those commits, it sounds like they are "make Linux
> >>>>> work again due to changes in Xen".  That sounds like a pretty bad thing
> >>>>> that Xen did, why do we have to fix up their mess?
> >>>>
> >>>> Xen did nothing bad. It was the "old" kernel implementation which relied
> >>>> on an assumption which happened to be true by accident. Xen had to be
> >>>> changed in order to enable grub2 to support PVH mode.
> >>>>
> >>>> The PVH interface specifies that the RSDP address is available via the
> >>>> start_info structure handed over to the PVH boot entry. The Linux kernel
> >>>> didn't look at that address, but used the legacy method scanning low
> >>>> memory for the RSDP table. As soon as Xen moved the RSDP to a higher
> >>>> address (which is covered by the PVH interface specification) the kernel
> >>>> could no longer be booted.
> >>>>
> >>>> So it was clearly a fault of the kernel not complying to the PVH
> >>>> specification.
> >>>
> >>> But it worked previously, so you can't fault Linux here :)
> >>>
> >>> How many other operating systems broke with this change?
> >>
> >> None.
> >>
> >> BSD did it correctly. I guess Mini-OS doesn't count, as it is mostly
> >> Xen-internal, but it was not hit by this change.
> > 
> > Xen doesn't support anything other than BSD, Linux, and Mini-OS? :)
> 
> No other OS supports PVH mode so far.
> 
> >>> Not at all.  We have a working kernel here.  Xen changed and broke
> >>> working Linux systems.  Now I understand the goal of wanting to also
> >>> change Linux to work properly, but these changes are really a new
> >>> feature addition if you read the patches.
> >>
> >> We have a working kernel just by luck. Would your reasoning be the same
> >> if the kernel would use an EFI runtime service wrong and an EFI update
> >> would lead to a crash?
> > 
> > If a UEFI/BIOS update broken working systems, first we would go yell at
> > the BIOS engineers for doing something foolish (like I am doing here...)
> > Then we would grumble and go fix the issue in the latest kernel version
> > and tell people to update to a new release and never buy from that
> > vendor ever again as they obviously do not care about their users.
> 
> Even if the kernel wasn't using the EFI interfaces correctly and just
> worked by accident? Sorry, that's ridiculous.
> 
> > So, I'll gladly tell everyone who hits this bug, to stop using Xen as
> > they don't care about their users, and to work around it they have to
> > use the 4.17 kernel release.
> 
> The kernel is wrong here. You don't want to take the patches fixing the
> issue.

These are not just "patches to fix the issue", they are "patches to add
new features" that touch core acpi bits, right?  Support for new
hardware and platforms and such are not normally part of 

Re: [Xen-devel] Patches for stable

[Greg KH]

On Wed, Apr 04, 2018 at 06:32:17PM +0200, Juergen Gross wrote:
> On 04/04/18 17:42, Greg KH wrote:
> > On Wed, Apr 04, 2018 at 05:12:32PM +0200, Juergen Gross wrote:
> >> On 04/04/18 16:46, Greg KH wrote:
> >>> On Wed, Apr 04, 2018 at 04:30:30PM +0200, Juergen Gross wrote:
> >>>> On 04/04/18 16:27, Greg KH wrote:
> >>>>> On Wed, Apr 04, 2018 at 12:38:43PM +0200, Juergen Gross wrote:
> >>>>>> Please add the patches:
> >>>>>>
> >>>>>> commit 038bac2b02989acf1fc938cedcb7944c02672b9f upstream
> >>>>>> commit dfc9327ab7c99bc13e12106448615efba833886b upstream
> >>>>>> commit b17d9d1df3c33a4f1d2bf397e2257aecf9dc56d4 upstream
> >>>>>>
> >>>>>> to the 4.15 and 4.16 stable kernels.
> >>>>>>
> >>>>>> Those patches are needed to boot Linux as PVH guest on recent Xen.
> >>>>>
> >>>>> So a new feature?  Why is that ok for stable kernels?
> >>>>
> >>>> It works for kernels since at least 4.11 on Xen 4.10.
> >>>
> >>> Great, so what commit caused this to fail?
> >>>
> >>> So far, in reading those commits, it sounds like they are "make Linux
> >>> work again due to changes in Xen".  That sounds like a pretty bad thing
> >>> that Xen did, why do we have to fix up their mess?
> >>
> >> Xen did nothing bad. It was the "old" kernel implementation which relied
> >> on an assumption which happened to be true by accident. Xen had to be
> >> changed in order to enable grub2 to support PVH mode.
> >>
> >> The PVH interface specifies that the RSDP address is available via the
> >> start_info structure handed over to the PVH boot entry. The Linux kernel
> >> didn't look at that address, but used the legacy method scanning low
> >> memory for the RSDP table. As soon as Xen moved the RSDP to a higher
> >> address (which is covered by the PVH interface specification) the kernel
> >> could no longer be booted.
> >>
> >> So it was clearly a fault of the kernel not complying to the PVH
> >> specification.
> > 
> > But it worked previously, so you can't fault Linux here :)
> > 
> > How many other operating systems broke with this change?
> 
> None.
> 
> BSD did it correctly. I guess Mini-OS doesn't count, as it is mostly
> Xen-internal, but it was not hit by this change.

Xen doesn't support anything other than BSD, Linux, and Mini-OS? :)

> > Not at all.  We have a working kernel here.  Xen changed and broke
> > working Linux systems.  Now I understand the goal of wanting to also
> > change Linux to work properly, but these changes are really a new
> > feature addition if you read the patches.
> 
> We have a working kernel just by luck. Would your reasoning be the same
> if the kernel would use an EFI runtime service wrong and an EFI update
> would lead to a crash?

If a UEFI/BIOS update broken working systems, first we would go yell at
the BIOS engineers for doing something foolish (like I am doing here...)
Then we would grumble and go fix the issue in the latest kernel version
and tell people to update to a new release and never buy from that
vendor ever again as they obviously do not care about their users.

So, I'll gladly tell everyone who hits this bug, to stop using Xen as
they don't care about their users, and to work around it they have to
use the 4.17 kernel release.

There, that was simple :)

thanks,

greg k-h

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Patches for stable

[Greg KH]

On Wed, Apr 04, 2018 at 05:12:32PM +0200, Juergen Gross wrote:
> On 04/04/18 16:46, Greg KH wrote:
> > On Wed, Apr 04, 2018 at 04:30:30PM +0200, Juergen Gross wrote:
> >> On 04/04/18 16:27, Greg KH wrote:
> >>> On Wed, Apr 04, 2018 at 12:38:43PM +0200, Juergen Gross wrote:
> >>>> Please add the patches:
> >>>>
> >>>> commit 038bac2b02989acf1fc938cedcb7944c02672b9f upstream
> >>>> commit dfc9327ab7c99bc13e12106448615efba833886b upstream
> >>>> commit b17d9d1df3c33a4f1d2bf397e2257aecf9dc56d4 upstream
> >>>>
> >>>> to the 4.15 and 4.16 stable kernels.
> >>>>
> >>>> Those patches are needed to boot Linux as PVH guest on recent Xen.
> >>>
> >>> So a new feature?  Why is that ok for stable kernels?
> >>
> >> It works for kernels since at least 4.11 on Xen 4.10.
> > 
> > Great, so what commit caused this to fail?
> > 
> > So far, in reading those commits, it sounds like they are "make Linux
> > work again due to changes in Xen".  That sounds like a pretty bad thing
> > that Xen did, why do we have to fix up their mess?
> 
> Xen did nothing bad. It was the "old" kernel implementation which relied
> on an assumption which happened to be true by accident. Xen had to be
> changed in order to enable grub2 to support PVH mode.
> 
> The PVH interface specifies that the RSDP address is available via the
> start_info structure handed over to the PVH boot entry. The Linux kernel
> didn't look at that address, but used the legacy method scanning low
> memory for the RSDP table. As soon as Xen moved the RSDP to a higher
> address (which is covered by the PVH interface specification) the kernel
> could no longer be booted.
> 
> So it was clearly a fault of the kernel not complying to the PVH
> specification.

But it worked previously, so you can't fault Linux here :)

How many other operating systems broke with this change?

> >>>> In PVH mode there is no guarantee the kernel can find the RSDP table
> >>>> at the legacy location in low memory, which is a requirement for the
> >>>> kernel to boot successful without those patches.
> >>>
> >>> Why not just use newer kernels for new Xen features?  This really
> >>> doesn't look like a bugfix to me, does it to you?
> >>
> >> It does. A working setup will no longer work if Xen version is upgraded
> >> to 4.11.
> > 
> > Why isn't this a regression in Xen that they fix?  Why are we
> > responsible for adding new kernel features to work on newer versions of
> > Xen and backport them to older kernels?
> 
> In case a Linux user program relies on undocumented behavior of the
> kernel (e.g. a register being non-zero on return from a syscall), does
> the kernel have to support that behavior eternally? I don't think so.

Yes, the kernel does have to support it.  It's called "do not break
working systems", or as some like to call it, the "Cambridge Promise"
that we made to userspace well over a decade ago at a kernel summit in
Cambridge.

We do this all the time, sometimes going through great gyrations in
order to achieve it.  Or sometimes we just "wait it out" and delay 4+
years to make these types of changes to allow everyone to update their
userspace programs before we make a change like this.

It's part of the job of running a good software project by not breaking
user's systems.  I suggest that Xen also adopt this same behavior if
they want to keep a happy userbase.  Otherwise we can just tell everyone
to go use KVM :)

> This is a similar case.

Not at all.  We have a working kernel here.  Xen changed and broke
working Linux systems.  Now I understand the goal of wanting to also
change Linux to work properly, but these changes are really a new
feature addition if you read the patches.

So why can't Xen just tell all Linux users to update to a more modern
kernel, i.e. 4.17.y and newer, in order to run with the new Xen kernel
if they want to enforce this previously working behavior?  Why does
Linux have to be the one to change here?

thanks,

greg k-h

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Patches for stable

[Greg KH]

On Wed, Apr 04, 2018 at 04:30:30PM +0200, Juergen Gross wrote:
> On 04/04/18 16:27, Greg KH wrote:
> > On Wed, Apr 04, 2018 at 12:38:43PM +0200, Juergen Gross wrote:
> >> Please add the patches:
> >>
> >> commit 038bac2b02989acf1fc938cedcb7944c02672b9f upstream
> >> commit dfc9327ab7c99bc13e12106448615efba833886b upstream
> >> commit b17d9d1df3c33a4f1d2bf397e2257aecf9dc56d4 upstream
> >>
> >> to the 4.15 and 4.16 stable kernels.
> >>
> >> Those patches are needed to boot Linux as PVH guest on recent Xen.
> > 
> > So a new feature?  Why is that ok for stable kernels?
> 
> It works for kernels since at least 4.11 on Xen 4.10.

Great, so what commit caused this to fail?

So far, in reading those commits, it sounds like they are "make Linux
work again due to changes in Xen".  That sounds like a pretty bad thing
that Xen did, why do we have to fix up their mess?

> >> In PVH mode there is no guarantee the kernel can find the RSDP table
> >> at the legacy location in low memory, which is a requirement for the
> >> kernel to boot successful without those patches.
> > 
> > Why not just use newer kernels for new Xen features?  This really
> > doesn't look like a bugfix to me, does it to you?
> 
> It does. A working setup will no longer work if Xen version is upgraded
> to 4.11.

Why isn't this a regression in Xen that they fix?  Why are we
responsible for adding new kernel features to work on newer versions of
Xen and backport them to older kernels?

thanks,

greg k-h

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Patches for stable

[Greg KH]

On Wed, Apr 04, 2018 at 12:38:43PM +0200, Juergen Gross wrote:
> Please add the patches:
> 
> commit 038bac2b02989acf1fc938cedcb7944c02672b9f upstream
> commit dfc9327ab7c99bc13e12106448615efba833886b upstream
> commit b17d9d1df3c33a4f1d2bf397e2257aecf9dc56d4 upstream
> 
> to the 4.15 and 4.16 stable kernels.
> 
> Those patches are needed to boot Linux as PVH guest on recent Xen.

So a new feature?  Why is that ok for stable kernels?

> In PVH mode there is no guarantee the kernel can find the RSDP table
> at the legacy location in low memory, which is a requirement for the
> kernel to boot successful without those patches.

Why not just use newer kernels for new Xen features?  This really
doesn't look like a bugfix to me, does it to you?

thanks,

greg k-h

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 2/2] xen: add acpi_arch_get_root_pointer() for pvh guests

[Greg KH]

On Thu, Jan 25, 2018 at 01:06:26PM +0100, Juergen Gross wrote:
> On 25/01/18 12:00, Greg KH wrote:
> > On Thu, Jan 25, 2018 at 11:49:35AM +0100, Juergen Gross wrote:
> >> On 25/01/18 11:37, Greg KH wrote:
> >>> On Thu, Jan 25, 2018 at 11:04:54AM +0100, Juergen Gross wrote:
> >>>> Add acpi_arch_get_root_pointer() for Xen PVH guests to communicate
> >>>> the address of the RSDP table given to the kernel via Xen start info.
> >>>>
> >>>> This makes the kernel boot again in PVH mode after on recent Xen the
> >>>> RSDP was moved to higher addresses. So up to that change it was pure
> >>>> luck that the legacy method to locate the RSDP was working when
> >>>> running as PVH mode.
> >>>>
> >>>> Cc: <sta...@vger.kernel.org> # 4.11
> >>>> Signed-off-by: Juergen Gross <jgr...@suse.com>
> >>>> ---
> >>>>  arch/x86/xen/enlighten_pvh.c | 15 ---
> >>>>  1 file changed, 12 insertions(+), 3 deletions(-)
> >>>>
> >>>> diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
> >>>> index 436c4f003e17..9a5c3a7fe673 100644
> >>>> --- a/arch/x86/xen/enlighten_pvh.c
> >>>> +++ b/arch/x86/xen/enlighten_pvh.c
> >>>> @@ -16,15 +16,24 @@
> >>>>  /*
> >>>>   * PVH variables.
> >>>>   *
> >>>> - * xen_pvh and pvh_bootparams need to live in data segment since they
> >>>> - * are used after startup_{32|64}, which clear .bss, are invoked.
> >>>> + * xen_pvh, pvh_bootparams and pvh_start_info need to live in data 
> >>>> segment
> >>>> + * since they are used after startup_{32|64}, which clear .bss, are 
> >>>> invoked.
> >>>>   */
> >>>>  bool xen_pvh __attribute__((section(".data"))) = 0;
> >>>>  struct boot_params pvh_bootparams __attribute__((section(".data")));
> >>>> +struct hvm_start_info pvh_start_info __attribute__((section(".data")));
> >>>>  
> >>>> -struct hvm_start_info pvh_start_info;
> >>>>  unsigned int pvh_start_info_sz = sizeof(pvh_start_info);
> >>>>  
> >>>> +acpi_physical_address acpi_arch_get_root_pointer(void)
> >>>> +{
> >>>> +if (xen_pvh)
> >>>> +return pvh_start_info.rsdp_paddr;
> >>>> +
> >>>> +return 0;
> >>>> +}
> >>>> +EXPORT_SYMBOL_GPL(acpi_arch_get_root_pointer);
> >>>
> >>> Why does this have to be an exported symbol?  Does this code get built
> >>> as a module and will the linker somehow go and rewrite the previous call
> >>> places with this one if it gets loaded?
> >>
> >> With being called by drivers/acpi/... I just wanted to make sure it is
> >> working properly even in case the acpi code is built as a module.
> > 
> > I didn't think the core ACPI code can be built as a module, have you
> > tried that?
> 
> No, but as the build wouldn't break whenever this is changed I wanted
> to make sure the symbol is found.
> 
> If you feel strong about that I can remove the EXPORT_SYMBOL_GPL().

Please don't export symbols that do not need to be exported, that's just
a waste.

thanks,

greg k-h

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 2/2] xen: add acpi_arch_get_root_pointer() for pvh guests

[Greg KH]

On Thu, Jan 25, 2018 at 11:49:35AM +0100, Juergen Gross wrote:
> On 25/01/18 11:37, Greg KH wrote:
> > On Thu, Jan 25, 2018 at 11:04:54AM +0100, Juergen Gross wrote:
> >> Add acpi_arch_get_root_pointer() for Xen PVH guests to communicate
> >> the address of the RSDP table given to the kernel via Xen start info.
> >>
> >> This makes the kernel boot again in PVH mode after on recent Xen the
> >> RSDP was moved to higher addresses. So up to that change it was pure
> >> luck that the legacy method to locate the RSDP was working when
> >> running as PVH mode.
> >>
> >> Cc: <sta...@vger.kernel.org> # 4.11
> >> Signed-off-by: Juergen Gross <jgr...@suse.com>
> >> ---
> >>  arch/x86/xen/enlighten_pvh.c | 15 ---
> >>  1 file changed, 12 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
> >> index 436c4f003e17..9a5c3a7fe673 100644
> >> --- a/arch/x86/xen/enlighten_pvh.c
> >> +++ b/arch/x86/xen/enlighten_pvh.c
> >> @@ -16,15 +16,24 @@
> >>  /*
> >>   * PVH variables.
> >>   *
> >> - * xen_pvh and pvh_bootparams need to live in data segment since they
> >> - * are used after startup_{32|64}, which clear .bss, are invoked.
> >> + * xen_pvh, pvh_bootparams and pvh_start_info need to live in data segment
> >> + * since they are used after startup_{32|64}, which clear .bss, are 
> >> invoked.
> >>   */
> >>  bool xen_pvh __attribute__((section(".data"))) = 0;
> >>  struct boot_params pvh_bootparams __attribute__((section(".data")));
> >> +struct hvm_start_info pvh_start_info __attribute__((section(".data")));
> >>  
> >> -struct hvm_start_info pvh_start_info;
> >>  unsigned int pvh_start_info_sz = sizeof(pvh_start_info);
> >>  
> >> +acpi_physical_address acpi_arch_get_root_pointer(void)
> >> +{
> >> +  if (xen_pvh)
> >> +  return pvh_start_info.rsdp_paddr;
> >> +
> >> +  return 0;
> >> +}
> >> +EXPORT_SYMBOL_GPL(acpi_arch_get_root_pointer);
> > 
> > Why does this have to be an exported symbol?  Does this code get built
> > as a module and will the linker somehow go and rewrite the previous call
> > places with this one if it gets loaded?
> 
> With being called by drivers/acpi/... I just wanted to make sure it is
> working properly even in case the acpi code is built as a module.

I didn't think the core ACPI code can be built as a module, have you
tried that?

thanks,

greg k-h

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 2/2] xen: add acpi_arch_get_root_pointer() for pvh guests

[Greg KH]

On Thu, Jan 25, 2018 at 11:04:54AM +0100, Juergen Gross wrote:
> Add acpi_arch_get_root_pointer() for Xen PVH guests to communicate
> the address of the RSDP table given to the kernel via Xen start info.
> 
> This makes the kernel boot again in PVH mode after on recent Xen the
> RSDP was moved to higher addresses. So up to that change it was pure
> luck that the legacy method to locate the RSDP was working when
> running as PVH mode.
> 
> Cc:  # 4.11
> Signed-off-by: Juergen Gross 
> ---
>  arch/x86/xen/enlighten_pvh.c | 15 ---
>  1 file changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
> index 436c4f003e17..9a5c3a7fe673 100644
> --- a/arch/x86/xen/enlighten_pvh.c
> +++ b/arch/x86/xen/enlighten_pvh.c
> @@ -16,15 +16,24 @@
>  /*
>   * PVH variables.
>   *
> - * xen_pvh and pvh_bootparams need to live in data segment since they
> - * are used after startup_{32|64}, which clear .bss, are invoked.
> + * xen_pvh, pvh_bootparams and pvh_start_info need to live in data segment
> + * since they are used after startup_{32|64}, which clear .bss, are invoked.
>   */
>  bool xen_pvh __attribute__((section(".data"))) = 0;
>  struct boot_params pvh_bootparams __attribute__((section(".data")));
> +struct hvm_start_info pvh_start_info __attribute__((section(".data")));
>  
> -struct hvm_start_info pvh_start_info;
>  unsigned int pvh_start_info_sz = sizeof(pvh_start_info);
>  
> +acpi_physical_address acpi_arch_get_root_pointer(void)
> +{
> + if (xen_pvh)
> + return pvh_start_info.rsdp_paddr;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(acpi_arch_get_root_pointer);

Why does this have to be an exported symbol?  Does this code get built
as a module and will the linker somehow go and rewrite the previous call
places with this one if it gets loaded?

thanks,

greg k-h

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel