search for: livepatches

...tate_safe(current, vhost_worker); Even better might be to get the caller address using some compiler macro. I guess that it should be possible. And even better would be to detect this at the compile time. But I do not know how to do so. > > A good enough solution might be to document this. Livepatches could > > not be created blindly. There are more situations where the > > livepatch is tricky or not possible at all. > > I can add this if you like. Is Documentation/livepatch/livepatch.rst the > right place for this? Yes, the best place probably would be "7. Limitation...

On Thu, Jan 26, 2023 at 08:43:55PM -0800, Josh Poimboeuf wrote: > On Thu, Jan 26, 2023 at 03:12:35PM -0600, Seth Forshee (DigitalOcean) wrote: > > On Thu, Jan 26, 2023 at 06:03:16PM +0100, Petr Mladek wrote: > > > On Fri 2023-01-20 16:12:20, Seth Forshee (DigitalOcean) wrote: > > > > We've fairly regularaly seen liveptches which cannot transition within

...derestand this is more a 'looks ok superficially and I don't have better ideas' than 'I have reviewed this thoroughly'. > > --- > Seth Forshee (DigitalOcean) (2): > livepatch: add an interface for safely switching kthreads > vhost: check for pending livepatches from vhost worker kthreads > > drivers/vhost/vhost.c | 4 ++++ > include/linux/livepatch.h | 2 ++ > kernel/livepatch/transition.c | 11 +++++++++++ > 3 files changed, 17 insertions(+) > --- > base-commit: 5dc4c995db9eb45f6373a956eb1f69460e69e6d4 > change-id:...

...atches I sent are > just about improving the only case I've identified which has lead to > kpatch failing to load a patch for a day or longer. If it is acceptable to wait hours or even days then the 1 minute timeout is quite contra-productive. We actually do not use any timeout at all in livepatches provided by SUSE. Best Regards, Petr

On Fri 2023-01-20 16:12:20, Seth Forshee (DigitalOcean) wrote: > We've fairly regularaly seen liveptches which cannot transition within kpatch's > timeout period due to busy vhost worker kthreads. I have missed this detail. Miroslav told me that we have solved something similar some time ago, see https://lore.kernel.org/all/20220507174628.2086373-1-song at kernel.org/ Honestly,

Hi, I am running CentOS Linux release 7.7.1908 (Core). Does CentOS Linux kernel 3.10.0-1062.1.1.el7.x86_64 support kernel updates without rebooting (Live Patching)? I look forward to hearing from you and thanks in advance. Best Regards, Kaushal

On Wed, Oct 9, 2019 at 11:27 AM Kaushal Shriyan <kaushalshriyan at gmail.com> wrote: > Hi, > > I am running CentOS Linux release 7.7.1908 (Core). Does CentOS Linux kernel > 3.10.0-1062.1.1.el7.x86_64 support kernel updates without rebooting (Live > Patching)? > > I look forward to hearing from you and thanks in advance. > > > this was just discussed in length

Instead of storing the map per CPU provide and use per task storage. That prepares for local kmaps which are preemptible. The context switch code is preparatory and not yet in use because kmap_atomic() runs with preemption disabled. Will be made usable in the next step. The context switch logic is safe even when an interrupt happens after clearing or before restoring the kmaps. The kmap index in

Hello, While testing Virt-SIG Xen 4.12 rpms on CentOS7 I noticed the following problem with libvirt/virt-manager when manually installing a new HVM guest from virt-manager GUI.. basicly the VM installation won't start, because libvirt/virt-manager is not able to start the VM, due to "missing" qemu-system-i386 binary: Unable to complete install: 'unsupported configuration:

Accepted: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Format: 1.8 Date: Fri, 05 Oct 2018 19:38:52 +0100 Source: xen Binary: xenstore-utils xen-utils-common xen-hypervisor-common xen-doc xen-utils-4.11 xen-hypervisor-4.11-amd64 xen-system-amd64 xen-hypervisor-4.11-arm64 xen-system-arm64 xen-hypervisor-4.11-armhf xen-system-armhf libxen-dev libxenmisc4.11 libxencall1 libxendevicemodel1

Following up to the discussion in: https://lore.kernel.org/r/20200914204209.256266093 at linutronix.de and the second version of this: https://lore.kernel.org/r/20201029221806.189523375 at linutronix.de this series provides a preemptible variant of kmap_atomic & related interfaces. This is achieved by: - Removing the RT dependency from migrate_disable/enable() - Consolidating all

Following up to the discussion in: https://lore.kernel.org/r/20200914204209.256266093 at linutronix.de and the second version of this: https://lore.kernel.org/r/20201029221806.189523375 at linutronix.de this series provides a preemptible variant of kmap_atomic & related interfaces. This is achieved by: - Removing the RT dependency from migrate_disable/enable() - Consolidating all

Following up to the discussion in: https://lore.kernel.org/r/20200914204209.256266093 at linutronix.de and the second version of this: https://lore.kernel.org/r/20201029221806.189523375 at linutronix.de this series provides a preemptible variant of kmap_atomic & related interfaces. This is achieved by: - Removing the RT dependency from migrate_disable/enable() - Consolidating all

This series adds new functions to the mmu interval notifier API to allow device drivers with MMUs to dynamically mirror a process' page tables based on device faults and invalidation callbacks. The Nouveau driver is updated to use the extended API and a set of stand alone self tests is added to help validate and maintain correctness. The patches are based on linux-5.5.0-rc6 and are for