[PATCH v3 25/25] KVM: x86: Add capability to grant VM access to privileged SGX attribute
From: Sean Christopherson
Add a capability, KVM_CAP_SGX_ATTRIBUTE, that can be used by userspace
to grant a VM access to a priveleged attribute, with args[0] holding a
file handle to a valid SGX attribute file.
The SGX subsystem restricts access to a subset of enclave attributes to
provide additional security for an uncompromised kernel, e.g. to prevent
malware from using the PROVISIONKEY to ensure its nodes are running
inside a geniune SGX enclave and/or to obtain a stable fingerprint.
To prevent userspace from circumventing such restrictions by running an
enclave in a VM, KVM restricts guest access to privileged attributes by
default.
Cc: Andy Lutomirski
Signed-off-by: Sean Christopherson
Signed-off-by: Kai Huang
---
Documentation/virt/kvm/api.rst | 23 +++
arch/x86/kvm/cpuid.c | 2 +-
arch/x86/kvm/x86.c | 21 +
include/uapi/linux/kvm.h | 1 +
4 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index 38e327d4b479..ebb47e48d4f3 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -6230,6 +6230,29 @@ KVM_RUN_BUS_LOCK flag is used to distinguish between
them.
This capability can be used to check / enable 2nd DAWR feature provided
by POWER10 processor.
+7.24 KVM_CAP_SGX_ATTRIBUTE
+--
+
+:Architectures: x86
+:Target: VM
+:Parameters: args[0] is a file handle of a SGX attribute file in securityfs
+:Returns: 0 on success, -EINVAL if the file handle is invalid or if a requested
+ attribute is not supported by KVM.
+
+KVM_CAP_SGX_ATTRIBUTE enables a userspace VMM to grant a VM access to one or
+more priveleged enclave attributes. args[0] must hold a file handle to a valid
+SGX attribute file corresponding to an attribute that is supported/restricted
+by KVM (currently only PROVISIONKEY).
+
+The SGX subsystem restricts access to a subset of enclave attributes to provide
+additional security for an uncompromised kernel, e.g. use of the PROVISIONKEY
+is restricted to deter malware from using the PROVISIONKEY to obtain a stable
+system fingerprint. To prevent userspace from circumventing such restrictions
+by running an enclave in a VM, KVM prevents access to privileged attributes by
+default.
+
+See Documentation/x86/sgx/2.Kernel-internals.rst for more details.
+
8. Other capabilities.
==
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index a0d45607b702..6dc12d949f86 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -849,7 +849,7 @@ static inline int __do_cpuid_func(struct kvm_cpuid_array
*array, u32 function)
* expected to derive it from supported XCR0.
*/
entry->eax &= SGX_ATTR_DEBUG | SGX_ATTR_MODE64BIT |
- /* PROVISIONKEY | */ SGX_ATTR_EINITTOKENKEY |
+ SGX_ATTR_PROVISIONKEY | SGX_ATTR_EINITTOKENKEY |
SGX_ATTR_KSS;
entry->ebx &= 0;
break;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index d2da5abcf395..81139e076380 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -75,6 +75,7 @@
#include
#include
#include
+#include
#include
#define CREATE_TRACE_POINTS
@@ -3759,6 +3760,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long
ext)
case KVM_CAP_X86_USER_SPACE_MSR:
case KVM_CAP_X86_MSR_FILTER:
case KVM_CAP_ENFORCE_PV_FEATURE_CPUID:
+#ifdef CONFIG_X86_SGX_KVM
+ case KVM_CAP_SGX_ATTRIBUTE:
+#endif
r = 1;
break;
#ifdef CONFIG_KVM_XEN
@@ -5345,6 +5349,23 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
kvm->arch.bus_lock_detection_enabled = true;
r = 0;
break;
+#ifdef CONFIG_X86_SGX_KVM
+ case KVM_CAP_SGX_ATTRIBUTE: {
+ unsigned long allowed_attributes = 0;
+
+ r = sgx_set_attribute(_attributes, cap->args[0]);
+ if (r)
+ break;
+
+ /* KVM only supports the PROVISIONKEY privileged attribute. */
+ if ((allowed_attributes & SGX_ATTR_PROVISIONKEY) &&
+ !(allowed_attributes & ~SGX_ATTR_PROVISIONKEY))
+ kvm->arch.sgx_provisioning_allowed = true;
+ else
+ r = -EINVAL;
+ break;
+ }
+#endif
default:
r = -EINVAL;
break;
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index f6afee209620..7d8927e474f8 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1078,6 +1078,7 @@ struct kvm_ppc_resize_hpt {
#define KVM_CAP_DIRTY_LOG_RING 192
#define KVM_CAP_X86_BUS_LOCK_EXIT 193
#define KVM_CAP_PPC_DAWR1 194
+#define KVM_CAP_SGX_ATTRIBUTE 195
#ifdef KVM_CAP_IRQ_ROUTING
--
2.30.2
[PATCH v2 25/25] KVM: x86: Add capability to grant VM access to privileged SGX attribute
From: Sean Christopherson
Add a capability, KVM_CAP_SGX_ATTRIBUTE, that can be used by userspace
to grant a VM access to a priveleged attribute, with args[0] holding a
file handle to a valid SGX attribute file.
The SGX subsystem restricts access to a subset of enclave attributes to
provide additional security for an uncompromised kernel, e.g. to prevent
malware from using the PROVISIONKEY to ensure its nodes are running
inside a geniune SGX enclave and/or to obtain a stable fingerprint.
To prevent userspace from circumventing such restrictions by running an
enclave in a VM, KVM restricts guest access to privileged attributes by
default.
Cc: Andy Lutomirski
Signed-off-by: Sean Christopherson
Signed-off-by: Kai Huang
---
Documentation/virt/kvm/api.rst | 23 +++
arch/x86/kvm/cpuid.c | 2 +-
arch/x86/kvm/x86.c | 21 +
include/uapi/linux/kvm.h | 1 +
4 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index 1a2b5210cdbf..614f150e6c15 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -6227,6 +6227,29 @@ KVM_RUN_BUS_LOCK flag is used to distinguish between
them.
This capability can be used to check / enable 2nd DAWR feature provided
by POWER10 processor.
+7.24 KVM_CAP_SGX_ATTRIBUTE
+--
+
+:Architectures: x86
+:Target: VM
+:Parameters: args[0] is a file handle of a SGX attribute file in securityfs
+:Returns: 0 on success, -EINVAL if the file handle is invalid or if a requested
+ attribute is not supported by KVM.
+
+KVM_CAP_SGX_ATTRIBUTE enables a userspace VMM to grant a VM access to one or
+more priveleged enclave attributes. args[0] must hold a file handle to a valid
+SGX attribute file corresponding to an attribute that is supported/restricted
+by KVM (currently only PROVISIONKEY).
+
+The SGX subsystem restricts access to a subset of enclave attributes to provide
+additional security for an uncompromised kernel, e.g. use of the PROVISIONKEY
+is restricted to deter malware from using the PROVISIONKEY to obtain a stable
+system fingerprint. To prevent userspace from circumventing such restrictions
+by running an enclave in a VM, KVM prevents access to privileged attributes by
+default.
+
+See Documentation/x86/sgx/2.Kernel-internals.rst for more details.
+
8. Other capabilities.
==
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index a0d45607b702..6dc12d949f86 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -849,7 +849,7 @@ static inline int __do_cpuid_func(struct kvm_cpuid_array
*array, u32 function)
* expected to derive it from supported XCR0.
*/
entry->eax &= SGX_ATTR_DEBUG | SGX_ATTR_MODE64BIT |
- /* PROVISIONKEY | */ SGX_ATTR_EINITTOKENKEY |
+ SGX_ATTR_PROVISIONKEY | SGX_ATTR_EINITTOKENKEY |
SGX_ATTR_KSS;
entry->ebx &= 0;
break;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 5233e3ad69ee..ec243ce7c27a 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -75,6 +75,7 @@
#include
#include
#include
+#include
#include
#define CREATE_TRACE_POINTS
@@ -3759,6 +3760,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long
ext)
case KVM_CAP_X86_USER_SPACE_MSR:
case KVM_CAP_X86_MSR_FILTER:
case KVM_CAP_ENFORCE_PV_FEATURE_CPUID:
+#ifdef CONFIG_X86_SGX_KVM
+ case KVM_CAP_SGX_ATTRIBUTE:
+#endif
r = 1;
break;
#ifdef CONFIG_KVM_XEN
@@ -5345,6 +5349,23 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
kvm->arch.bus_lock_detection_enabled = true;
r = 0;
break;
+#ifdef CONFIG_X86_SGX_KVM
+ case KVM_CAP_SGX_ATTRIBUTE: {
+ unsigned long allowed_attributes = 0;
+
+ r = sgx_set_attribute(_attributes, cap->args[0]);
+ if (r)
+ break;
+
+ /* KVM only supports the PROVISIONKEY privileged attribute. */
+ if ((allowed_attributes & SGX_ATTR_PROVISIONKEY) &&
+ !(allowed_attributes & ~SGX_ATTR_PROVISIONKEY))
+ kvm->arch.sgx_provisioning_allowed = true;
+ else
+ r = -EINVAL;
+ break;
+ }
+#endif
default:
r = -EINVAL;
break;
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index f6afee209620..7d8927e474f8 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1078,6 +1078,7 @@ struct kvm_ppc_resize_hpt {
#define KVM_CAP_DIRTY_LOG_RING 192
#define KVM_CAP_X86_BUS_LOCK_EXIT 193
#define KVM_CAP_PPC_DAWR1 194
+#define KVM_CAP_SGX_ATTRIBUTE 195
#ifdef KVM_CAP_IRQ_ROUTING
--
2.29.2
[PATCH 25/25] KVM: x86: Add capability to grant VM access to privileged SGX attribute
From: Sean Christopherson
Add a capability, KVM_CAP_SGX_ATTRIBUTE, that can be used by userspace
to grant a VM access to a priveleged attribute, with args[0] holding a
file handle to a valid SGX attribute file.
The SGX subsystem restricts access to a subset of enclave attributes to
provide additional security for an uncompromised kernel, e.g. to prevent
malware from using the PROVISIONKEY to ensure its nodes are running
inside a geniune SGX enclave and/or to obtain a stable fingerprint.
To prevent userspace from circumventing such restrictions by running an
enclave in a VM, KVM restricts guest access to privileged attributes by
default.
Cc: Andy Lutomirski
Signed-off-by: Sean Christopherson
Signed-off-by: Kai Huang
---
Documentation/virt/kvm/api.rst | 23 +++
arch/x86/kvm/cpuid.c | 2 +-
arch/x86/kvm/x86.c | 21 +
include/uapi/linux/kvm.h | 1 +
4 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index aed52b0fc16e..d65016a05a8b 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -6227,6 +6227,29 @@ KVM_RUN_BUS_LOCK flag is used to distinguish between
them.
This capability can be used to check / enable 2nd DAWR feature provided
by POWER10 processor.
+7.24 KVM_CAP_SGX_ATTRIBUTE
+--
+
+:Architectures: x86
+:Target: VM
+:Parameters: args[0] is a file handle of a SGX attribute file in securityfs
+:Returns: 0 on success, -EINVAL if the file handle is invalid or if a requested
+ attribute is not supported by KVM.
+
+KVM_CAP_SGX_ATTRIBUTE enables a userspace VMM to grant a VM access to one or
+more priveleged enclave attributes. args[0] must hold a file handle to a valid
+SGX attribute file corresponding to an attribute that is supported/restricted
+by KVM (currently only PROVISIONKEY).
+
+The SGX subsystem restricts access to a subset of enclave attributes to provide
+additional security for an uncompromised kernel, e.g. use of the PROVISIONKEY
+is restricted to deter malware from using the PROVISIONKEY to obtain a stable
+system fingerprint. To prevent userspace from circumventing such restrictions
+by running an enclave in a VM, KVM prevents access to privileged attributes by
+default.
+
+See Documentation/x86/sgx/2.Kernel-internals.rst for more details.
+
8. Other capabilities.
==
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index a0d45607b702..6dc12d949f86 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -849,7 +849,7 @@ static inline int __do_cpuid_func(struct kvm_cpuid_array
*array, u32 function)
* expected to derive it from supported XCR0.
*/
entry->eax &= SGX_ATTR_DEBUG | SGX_ATTR_MODE64BIT |
- /* PROVISIONKEY | */ SGX_ATTR_EINITTOKENKEY |
+ SGX_ATTR_PROVISIONKEY | SGX_ATTR_EINITTOKENKEY |
SGX_ATTR_KSS;
entry->ebx &= 0;
break;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index a4a514523c45..0f9d9ace2b66 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -75,6 +75,7 @@
#include
#include
#include
+#include
#include
#define CREATE_TRACE_POINTS
@@ -3754,6 +3755,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long
ext)
case KVM_CAP_X86_USER_SPACE_MSR:
case KVM_CAP_X86_MSR_FILTER:
case KVM_CAP_ENFORCE_PV_FEATURE_CPUID:
+#ifdef CONFIG_X86_SGX_KVM
+ case KVM_CAP_SGX_ATTRIBUTE:
+#endif
r = 1;
break;
case KVM_CAP_XEN_HVM:
@@ -5330,6 +5334,23 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
kvm->arch.bus_lock_detection_enabled = true;
r = 0;
break;
+#ifdef CONFIG_X86_SGX_KVM
+ case KVM_CAP_SGX_ATTRIBUTE: {
+ unsigned long allowed_attributes = 0;
+
+ r = sgx_set_attribute(_attributes, cap->args[0]);
+ if (r)
+ break;
+
+ /* KVM only supports the PROVISIONKEY privileged attribute. */
+ if ((allowed_attributes & SGX_ATTR_PROVISIONKEY) &&
+ !(allowed_attributes & ~SGX_ATTR_PROVISIONKEY))
+ kvm->arch.sgx_provisioning_allowed = true;
+ else
+ r = -EINVAL;
+ break;
+ }
+#endif
default:
r = -EINVAL;
break;
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 8b281f722e5b..df37fcf41a74 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1078,6 +1078,7 @@ struct kvm_ppc_resize_hpt {
#define KVM_CAP_DIRTY_LOG_RING 192
#define KVM_CAP_X86_BUS_LOCK_EXIT 193
#define KVM_CAP_PPC_DAWR1 194
+#define KVM_CAP_SGX_ATTRIBUTE 195
#ifdef KVM_CAP_IRQ_ROUTING
--
2.29.2
[PATCH 5.9 081/105] xen: add helpers for caching grant mapping pages
From: Juergen Gross
commit ca33479cc7be2c9b5f8be078c8bf3ac26b7d6186 upstream.
Instead of having similar helpers in multiple backend drivers use
common helpers for caching pages allocated via gnttab_alloc_pages().
Make use of those helpers in blkback and scsiback.
Cc: # 5.9
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
Signed-off-by: Juergen Gross
Signed-off-by: Greg Kroah-Hartman
---
drivers/block/xen-blkback/blkback.c | 89 ++--
drivers/block/xen-blkback/common.h |4 -
drivers/block/xen-blkback/xenbus.c |6 --
drivers/xen/grant-table.c | 72 +
drivers/xen/xen-scsiback.c | 60
include/xen/grant_table.h | 13 +
6 files changed, 116 insertions(+), 128 deletions(-)
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -132,73 +132,12 @@ module_param(log_stats, int, 0644);
#define BLKBACK_INVALID_HANDLE (~0)
-/* Number of free pages to remove on each call to gnttab_free_pages */
-#define NUM_BATCH_FREE_PAGES 10
-
static inline bool persistent_gnt_timeout(struct persistent_gnt
*persistent_gnt)
{
return pgrant_timeout && (jiffies - persistent_gnt->last_used >=
HZ * pgrant_timeout);
}
-static inline int get_free_page(struct xen_blkif_ring *ring, struct page
**page)
-{
- unsigned long flags;
-
- spin_lock_irqsave(>free_pages_lock, flags);
- if (list_empty(>free_pages)) {
- BUG_ON(ring->free_pages_num != 0);
- spin_unlock_irqrestore(>free_pages_lock, flags);
- return gnttab_alloc_pages(1, page);
- }
- BUG_ON(ring->free_pages_num == 0);
- page[0] = list_first_entry(>free_pages, struct page, lru);
- list_del([0]->lru);
- ring->free_pages_num--;
- spin_unlock_irqrestore(>free_pages_lock, flags);
-
- return 0;
-}
-
-static inline void put_free_pages(struct xen_blkif_ring *ring, struct page
**page,
- int num)
-{
- unsigned long flags;
- int i;
-
- spin_lock_irqsave(>free_pages_lock, flags);
- for (i = 0; i < num; i++)
- list_add([i]->lru, >free_pages);
- ring->free_pages_num += num;
- spin_unlock_irqrestore(>free_pages_lock, flags);
-}
-
-static inline void shrink_free_pagepool(struct xen_blkif_ring *ring, int num)
-{
- /* Remove requested pages in batches of NUM_BATCH_FREE_PAGES */
- struct page *page[NUM_BATCH_FREE_PAGES];
- unsigned int num_pages = 0;
- unsigned long flags;
-
- spin_lock_irqsave(>free_pages_lock, flags);
- while (ring->free_pages_num > num) {
- BUG_ON(list_empty(>free_pages));
- page[num_pages] = list_first_entry(>free_pages,
- struct page, lru);
- list_del([num_pages]->lru);
- ring->free_pages_num--;
- if (++num_pages == NUM_BATCH_FREE_PAGES) {
- spin_unlock_irqrestore(>free_pages_lock, flags);
- gnttab_free_pages(num_pages, page);
- spin_lock_irqsave(>free_pages_lock, flags);
- num_pages = 0;
- }
- }
- spin_unlock_irqrestore(>free_pages_lock, flags);
- if (num_pages != 0)
- gnttab_free_pages(num_pages, page);
-}
-
#define vaddr(page) ((unsigned long)pfn_to_kaddr(page_to_pfn(page)))
static int do_block_io_op(struct xen_blkif_ring *ring, unsigned int
*eoi_flags);
@@ -331,7 +270,8 @@ static void free_persistent_gnts(struct
unmap_data.count = segs_to_unmap;
BUG_ON(gnttab_unmap_refs_sync(_data));
- put_free_pages(ring, pages, segs_to_unmap);
+ gnttab_page_cache_put(>free_pages, pages,
+ segs_to_unmap);
segs_to_unmap = 0;
}
@@ -371,7 +311,8 @@ void xen_blkbk_unmap_purged_grants(struc
if (++segs_to_unmap == BLKIF_MAX_SEGMENTS_PER_REQUEST) {
unmap_data.count = segs_to_unmap;
BUG_ON(gnttab_unmap_refs_sync(_data));
- put_free_pages(ring, pages, segs_to_unmap);
+ gnttab_page_cache_put(>free_pages, pages,
+ segs_to_unmap);
segs_to_unmap = 0;
}
kfree(persistent_gnt);
@@ -379,7 +320,7 @@ void xen_blkbk_unmap_purged_grants(struc
if (segs_to_unmap > 0) {
unmap_data.count = segs_to_unmap;
BUG_ON(gnttab_unmap_refs_sync(_data));
- put_free_pages(ring, pages, segs_to_unmap);
+
Re: [PATCH 1/2] xen: add helpers for caching grant mapping pages
On 12/7/20 8:30 AM, Juergen Gross wrote:
> Instead of having similar helpers in multiple backend drivers use
> common helpers for caching pages allocated via gnttab_alloc_pages().
>
> Make use of those helpers in blkback and scsiback.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
> +
> +void gnttab_page_cache_shrink(struct gnttab_page_cache *cache, unsigned int
> num)
> +{
> + struct page *page[10];
> + unsigned int i = 0;
> + unsigned long flags;
> +
> + spin_lock_irqsave(>lock, flags);
> +
> + while (cache->num_pages > num) {
> + page[i] = list_first_entry(>pages, struct page, lru);
> + list_del([i]->lru);
> + cache->num_pages--;
> + if (++i == ARRAY_SIZE(page)) {
> + spin_unlock_irqrestore(>lock, flags);
> + gnttab_free_pages(i, page);
> + i = 0;
> + spin_lock_irqsave(>lock, flags);
> + }
> + }
> +
> + spin_unlock_irqrestore(>lock, flags);
> +
> + if (i != 0)
> + gnttab_free_pages(i, page);
> +}
How about splitting cache->pages list into two lists (one @num long and the
other holding the rest) and then batching gntab_free_pages() from that first
list? Then you won't have to deal with locking.
In fact, I am not even sure batching gains us much, I'd consider going
one-by-one.
-boris
[PATCH 1/2] xen: add helpers for caching grant mapping pages
Instead of having similar helpers in multiple backend drivers use
common helpers for caching pages allocated via gnttab_alloc_pages().
Make use of those helpers in blkback and scsiback.
Signed-off-by: Juergen Gross
---
drivers/block/xen-blkback/blkback.c | 89 ++---
drivers/block/xen-blkback/common.h | 4 +-
drivers/block/xen-blkback/xenbus.c | 6 +-
drivers/xen/grant-table.c | 72 +++
drivers/xen/xen-scsiback.c | 60 ---
include/xen/grant_table.h | 13 +
6 files changed, 116 insertions(+), 128 deletions(-)
diff --git a/drivers/block/xen-blkback/blkback.c
b/drivers/block/xen-blkback/blkback.c
index 501e9dacfff9..9ebf53903d7b 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -132,73 +132,12 @@ module_param(log_stats, int, 0644);
#define BLKBACK_INVALID_HANDLE (~0)
-/* Number of free pages to remove on each call to gnttab_free_pages */
-#define NUM_BATCH_FREE_PAGES 10
-
static inline bool persistent_gnt_timeout(struct persistent_gnt
*persistent_gnt)
{
return pgrant_timeout && (jiffies - persistent_gnt->last_used >=
HZ * pgrant_timeout);
}
-static inline int get_free_page(struct xen_blkif_ring *ring, struct page
**page)
-{
- unsigned long flags;
-
- spin_lock_irqsave(>free_pages_lock, flags);
- if (list_empty(>free_pages)) {
- BUG_ON(ring->free_pages_num != 0);
- spin_unlock_irqrestore(>free_pages_lock, flags);
- return gnttab_alloc_pages(1, page);
- }
- BUG_ON(ring->free_pages_num == 0);
- page[0] = list_first_entry(>free_pages, struct page, lru);
- list_del([0]->lru);
- ring->free_pages_num--;
- spin_unlock_irqrestore(>free_pages_lock, flags);
-
- return 0;
-}
-
-static inline void put_free_pages(struct xen_blkif_ring *ring, struct page
**page,
- int num)
-{
- unsigned long flags;
- int i;
-
- spin_lock_irqsave(>free_pages_lock, flags);
- for (i = 0; i < num; i++)
- list_add([i]->lru, >free_pages);
- ring->free_pages_num += num;
- spin_unlock_irqrestore(>free_pages_lock, flags);
-}
-
-static inline void shrink_free_pagepool(struct xen_blkif_ring *ring, int num)
-{
- /* Remove requested pages in batches of NUM_BATCH_FREE_PAGES */
- struct page *page[NUM_BATCH_FREE_PAGES];
- unsigned int num_pages = 0;
- unsigned long flags;
-
- spin_lock_irqsave(>free_pages_lock, flags);
- while (ring->free_pages_num > num) {
- BUG_ON(list_empty(>free_pages));
- page[num_pages] = list_first_entry(>free_pages,
- struct page, lru);
- list_del([num_pages]->lru);
- ring->free_pages_num--;
- if (++num_pages == NUM_BATCH_FREE_PAGES) {
- spin_unlock_irqrestore(>free_pages_lock, flags);
- gnttab_free_pages(num_pages, page);
- spin_lock_irqsave(>free_pages_lock, flags);
- num_pages = 0;
- }
- }
- spin_unlock_irqrestore(>free_pages_lock, flags);
- if (num_pages != 0)
- gnttab_free_pages(num_pages, page);
-}
-
#define vaddr(page) ((unsigned long)pfn_to_kaddr(page_to_pfn(page)))
static int do_block_io_op(struct xen_blkif_ring *ring, unsigned int
*eoi_flags);
@@ -331,7 +270,8 @@ static void free_persistent_gnts(struct xen_blkif_ring
*ring, struct rb_root *ro
unmap_data.count = segs_to_unmap;
BUG_ON(gnttab_unmap_refs_sync(_data));
- put_free_pages(ring, pages, segs_to_unmap);
+ gnttab_page_cache_put(>free_pages, pages,
+ segs_to_unmap);
segs_to_unmap = 0;
}
@@ -371,7 +311,8 @@ void xen_blkbk_unmap_purged_grants(struct work_struct *work)
if (++segs_to_unmap == BLKIF_MAX_SEGMENTS_PER_REQUEST) {
unmap_data.count = segs_to_unmap;
BUG_ON(gnttab_unmap_refs_sync(_data));
- put_free_pages(ring, pages, segs_to_unmap);
+ gnttab_page_cache_put(>free_pages, pages,
+ segs_to_unmap);
segs_to_unmap = 0;
}
kfree(persistent_gnt);
@@ -379,7 +320,7 @@ void xen_blkbk_unmap_purged_grants(struct work_struct *work)
if (segs_to_unmap > 0) {
unmap_data.count = segs_to_unmap;
BUG_ON(gnttab_unmap_refs_sync(_data));
- put_free_pages(ring, pages, segs_to_unmap);
+
Re: [PATCH v2] block: grant IOPRIO_CLASS_RT to CAP_SYS_NICE
On 9/1/20 4:49 PM, Khazhismel Kumykov wrote: > On Sat, Aug 29, 2020 at 6:00 PM Bart Van Assche wrote: >> >> From https://www.kernel.org/doc/man-pages/linux-api-ml.html: >> "all Linux kernel patches that change userspace interfaces should be CCed >> to linux-...@vger.kernel.org" >> >> So I have added the linux-api mailing list to the Cc-list. Anyway: > Thanks, sorry for missing that! >> >> Reviewed-by: Bart Van Assche > > Jens, does this change look good? Yes, I'll queue it up for 5.10. -- Jens Axboe
Re: [PATCH v2] block: grant IOPRIO_CLASS_RT to CAP_SYS_NICE
On Sat, Aug 29, 2020 at 6:00 PM Bart Van Assche wrote: > > From https://www.kernel.org/doc/man-pages/linux-api-ml.html: > "all Linux kernel patches that change userspace interfaces should be CCed > to linux-...@vger.kernel.org" > > So I have added the linux-api mailing list to the Cc-list. Anyway: Thanks, sorry for missing that! > > Reviewed-by: Bart Van Assche Jens, does this change look good? khazhy smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH v2] block: grant IOPRIO_CLASS_RT to CAP_SYS_NICE
On 2020-08-24 15:10, Khazhismel Kumykov wrote:
> CAP_SYS_ADMIN is too broad, and ionice fits into CAP_SYS_NICE's grouping.
>
> Retain CAP_SYS_ADMIN permission for backwards compatibility.
>
> Signed-off-by: Khazhismel Kumykov
> ---
> block/ioprio.c | 2 +-
> include/uapi/linux/capability.h | 2 ++
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> v2: fix embarrassing logic mistake
> diff --git a/block/ioprio.c b/block/ioprio.c
> index 77bcab11dce5..276496246fe9 100644
> --- a/block/ioprio.c
> +++ b/block/ioprio.c
> @@ -69,7 +69,7 @@ int ioprio_check_cap(int ioprio)
>
> switch (class) {
> case IOPRIO_CLASS_RT:
> - if (!capable(CAP_SYS_ADMIN))
> + if (!capable(CAP_SYS_NICE) && !capable(CAP_SYS_ADMIN))
> return -EPERM;
> /* fall through */
> /* rt has prio field too */
> diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
> index 395dd0df8d08..c6ca33034147 100644
> --- a/include/uapi/linux/capability.h
> +++ b/include/uapi/linux/capability.h
> @@ -288,6 +288,8 @@ struct vfs_ns_cap_data {
> processes and setting the scheduling algorithm used by another
> process. */
> /* Allow setting cpu affinity on other processes */
> +/* Allow setting realtime ioprio class */
> +/* Allow setting ioprio class on other processes */
>
> #define CAP_SYS_NICE 23
>From https://www.kernel.org/doc/man-pages/linux-api-ml.html:
"all Linux kernel patches that change userspace interfaces should be CCed
to linux-...@vger.kernel.org"
So I have added the linux-api mailing list to the Cc-list. Anyway:
Reviewed-by: Bart Van Assche
Re: [PATCH v2] block: grant IOPRIO_CLASS_RT to CAP_SYS_NICE
On Mon, Aug 24, 2020 at 03:10:34PM -0700, Khazhismel Kumykov wrote:
> CAP_SYS_ADMIN is too broad, and ionice fits into CAP_SYS_NICE's grouping.
>
> Retain CAP_SYS_ADMIN permission for backwards compatibility.
>
> Signed-off-by: Khazhismel Kumykov
Acked-by: Serge Hallyn
> ---
> block/ioprio.c | 2 +-
> include/uapi/linux/capability.h | 2 ++
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> v2: fix embarrassing logic mistake
> diff --git a/block/ioprio.c b/block/ioprio.c
> index 77bcab11dce5..276496246fe9 100644
> --- a/block/ioprio.c
> +++ b/block/ioprio.c
> @@ -69,7 +69,7 @@ int ioprio_check_cap(int ioprio)
>
> switch (class) {
> case IOPRIO_CLASS_RT:
> - if (!capable(CAP_SYS_ADMIN))
> + if (!capable(CAP_SYS_NICE) && !capable(CAP_SYS_ADMIN))
> return -EPERM;
> /* fall through */
> /* rt has prio field too */
> diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
> index 395dd0df8d08..c6ca33034147 100644
> --- a/include/uapi/linux/capability.h
> +++ b/include/uapi/linux/capability.h
> @@ -288,6 +288,8 @@ struct vfs_ns_cap_data {
> processes and setting the scheduling algorithm used by another
> process. */
> /* Allow setting cpu affinity on other processes */
> +/* Allow setting realtime ioprio class */
> +/* Allow setting ioprio class on other processes */
>
> #define CAP_SYS_NICE 23
>
> --
> 2.28.0.297.g1956fa8f8d-goog
[PATCH v2] block: grant IOPRIO_CLASS_RT to CAP_SYS_NICE
CAP_SYS_ADMIN is too broad, and ionice fits into CAP_SYS_NICE's grouping.
Retain CAP_SYS_ADMIN permission for backwards compatibility.
Signed-off-by: Khazhismel Kumykov
---
block/ioprio.c | 2 +-
include/uapi/linux/capability.h | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
v2: fix embarrassing logic mistake
diff --git a/block/ioprio.c b/block/ioprio.c
index 77bcab11dce5..276496246fe9 100644
--- a/block/ioprio.c
+++ b/block/ioprio.c
@@ -69,7 +69,7 @@ int ioprio_check_cap(int ioprio)
switch (class) {
case IOPRIO_CLASS_RT:
- if (!capable(CAP_SYS_ADMIN))
+ if (!capable(CAP_SYS_NICE) && !capable(CAP_SYS_ADMIN))
return -EPERM;
/* fall through */
/* rt has prio field too */
diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
index 395dd0df8d08..c6ca33034147 100644
--- a/include/uapi/linux/capability.h
+++ b/include/uapi/linux/capability.h
@@ -288,6 +288,8 @@ struct vfs_ns_cap_data {
processes and setting the scheduling algorithm used by another
process. */
/* Allow setting cpu affinity on other processes */
+/* Allow setting realtime ioprio class */
+/* Allow setting ioprio class on other processes */
#define CAP_SYS_NICE 23
--
2.28.0.297.g1956fa8f8d-goog
Re: [PATCH] block: grant IOPRIO_CLASS_RT to CAP_SYS_NICE
On Mon, Aug 24, 2020 at 1:45 PM Khazhismel Kumykov wrote:
>
> CAP_SYS_ADMIN is too broad, and ionice fits into CAP_SYS_NICE's grouping.
>
> Retain CAP_SYS_ADMIN permission for backwards compatibility.
>
> Signed-off-by: Khazhismel Kumykov
> ---
> block/ioprio.c | 2 +-
> include/uapi/linux/capability.h | 2 ++
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/block/ioprio.c b/block/ioprio.c
> index 77bcab11dce5..4572456430f9 100644
> --- a/block/ioprio.c
> +++ b/block/ioprio.c
> @@ -69,7 +69,7 @@ int ioprio_check_cap(int ioprio)
>
> switch (class) {
> case IOPRIO_CLASS_RT:
> - if (!capable(CAP_SYS_ADMIN))
> + if (!capable(CAP_SYS_ADMIN) || !capable(CAP_SYS_NICE))
yikes, sorry for the spam
> return -EPERM;
> /* fall through */
> /* rt has prio field too */
> diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
> index 395dd0df8d08..c6ca33034147 100644
> --- a/include/uapi/linux/capability.h
> +++ b/include/uapi/linux/capability.h
> @@ -288,6 +288,8 @@ struct vfs_ns_cap_data {
> processes and setting the scheduling algorithm used by another
> process. */
> /* Allow setting cpu affinity on other processes */
> +/* Allow setting realtime ioprio class */
> +/* Allow setting ioprio class on other processes */
>
> #define CAP_SYS_NICE 23
>
> --
> 2.28.0.297.g1956fa8f8d-goog
>
smime.p7s
Description: S/MIME Cryptographic Signature
[PATCH] block: grant IOPRIO_CLASS_RT to CAP_SYS_NICE
CAP_SYS_ADMIN is too broad, and ionice fits into CAP_SYS_NICE's grouping.
Retain CAP_SYS_ADMIN permission for backwards compatibility.
Signed-off-by: Khazhismel Kumykov
---
block/ioprio.c | 2 +-
include/uapi/linux/capability.h | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/block/ioprio.c b/block/ioprio.c
index 77bcab11dce5..4572456430f9 100644
--- a/block/ioprio.c
+++ b/block/ioprio.c
@@ -69,7 +69,7 @@ int ioprio_check_cap(int ioprio)
switch (class) {
case IOPRIO_CLASS_RT:
- if (!capable(CAP_SYS_ADMIN))
+ if (!capable(CAP_SYS_ADMIN) || !capable(CAP_SYS_NICE))
return -EPERM;
/* fall through */
/* rt has prio field too */
diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
index 395dd0df8d08..c6ca33034147 100644
--- a/include/uapi/linux/capability.h
+++ b/include/uapi/linux/capability.h
@@ -288,6 +288,8 @@ struct vfs_ns_cap_data {
processes and setting the scheduling algorithm used by another
process. */
/* Allow setting cpu affinity on other processes */
+/* Allow setting realtime ioprio class */
+/* Allow setting ioprio class on other processes */
#define CAP_SYS_NICE 23
--
2.28.0.297.g1956fa8f8d-goog
drivers/xen/grant-table.c:747:17: sparse: sparse: incorrect type in argument 1 (different address spaces)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 8882572675c1bb1cc544f4e229a11661f1fc52e4
commit: 670d0a4b10704667765f7d18f7592993d02783aa sparse: use identifiers to
define address spaces
date: 4 weeks ago
config: arm-randconfig-s031-20200717 (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-49-g707c5017-dirty
git checkout 670d0a4b10704667765f7d18f7592993d02783aa
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=arm
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
drivers/xen/grant-table.c:739:15: sparse: sparse: incorrect type in
assignment (different address spaces) @@ expected void *vaddr @@ got
void [noderef] __iomem * @@
drivers/xen/grant-table.c:739:15: sparse: expected void *vaddr
drivers/xen/grant-table.c:739:15: sparse: got void [noderef] __iomem *
>> drivers/xen/grant-table.c:747:17: sparse: sparse: incorrect type in argument
>> 1 (different address spaces) @@ expected void volatile [noderef] __iomem
>> *iomem_cookie @@ got void *vaddr @@
>> drivers/xen/grant-table.c:747:17: sparse: expected void volatile
>> [noderef] __iomem *iomem_cookie
drivers/xen/grant-table.c:747:17: sparse: got void *vaddr
>> drivers/xen/grant-table.c:766:9: sparse: sparse: incorrect type in argument
>> 1 (different address spaces) @@ expected void volatile [noderef] __iomem
>> *iomem_cookie @@ got void *[addressable] [assigned] [toplevel] vaddr @@
drivers/xen/grant-table.c:766:9: sparse: expected void volatile
[noderef] __iomem *iomem_cookie
drivers/xen/grant-table.c:766:9: sparse: got void *[addressable]
[assigned] [toplevel] vaddr
vim +747 drivers/xen/grant-table.c
ad9a86121f5a374 Jeremy Fitzhardinge 2007-07-17 728
47c542050d306e5 Julien Grall 2014-01-30 729 int
gnttab_setup_auto_xlat_frames(phys_addr_t addr)
efaf30a3357872c Konrad Rzeszutek Wilk 2014-01-06 730 {
efaf30a3357872c Konrad Rzeszutek Wilk 2014-01-06 731 xen_pfn_t *pfn;
efaf30a3357872c Konrad Rzeszutek Wilk 2014-01-06 732 unsigned int
max_nr_gframes = __max_nr_grant_frames();
efaf30a3357872c Konrad Rzeszutek Wilk 2014-01-06 733 unsigned int i;
efaf30a3357872c Konrad Rzeszutek Wilk 2014-01-06 734 void *vaddr;
efaf30a3357872c Konrad Rzeszutek Wilk 2014-01-06 735
efaf30a3357872c Konrad Rzeszutek Wilk 2014-01-06 736 if
(xen_auto_xlat_grant_frames.count)
efaf30a3357872c Konrad Rzeszutek Wilk 2014-01-06 737 return -EINVAL;
efaf30a3357872c Konrad Rzeszutek Wilk 2014-01-06 738
5ed5451d997f7a8 Julien Grall 2015-05-05 739 vaddr = xen_remap(addr,
XEN_PAGE_SIZE * max_nr_gframes);
efaf30a3357872c Konrad Rzeszutek Wilk 2014-01-06 740 if (vaddr == NULL) {
47c542050d306e5 Julien Grall 2014-01-30 741 pr_warn("Failed
to ioremap gnttab share frames (addr=%pa)!\n",
47c542050d306e5 Julien Grall 2014-01-30 742 );
efaf30a3357872c Konrad Rzeszutek Wilk 2014-01-06 743 return -ENOMEM;
efaf30a3357872c Konrad Rzeszutek Wilk 2014-01-06 744 }
efaf30a3357872c Konrad Rzeszutek Wilk 2014-01-06 745 pfn =
kcalloc(max_nr_gframes, sizeof(pfn[0]), GFP_KERNEL);
efaf30a3357872c Konrad Rzeszutek Wilk 2014-01-06 746 if (!pfn) {
efaf30a3357872c Konrad Rzeszutek Wilk 2014-01-06 @747
xen_unmap(vaddr);
efaf30a3357872c Konrad Rzeszutek Wilk 2014-01-06 748 return -ENOMEM;
efaf30a3357872c Konrad Rzeszutek Wilk 2014-01-06 749 }
efaf30a3357872c Konrad Rzeszutek Wilk 2014-01-06 750 for (i = 0; i <
max_nr_gframes; i++)
5ed5451d997f7a8 Julien Grall 2015-05-05 751 pfn[i] =
XEN_PFN_DOWN(addr) + i;
efaf30a3357872c Konrad Rzeszutek Wilk 2014-01-06 752
efaf30a3357872c Konrad Rzeszutek Wilk 2014-01-06 753
xen_auto_xlat_grant_frames.vaddr = vaddr;
efaf30a3357872c Konrad Rzeszutek Wilk 2014-01-06 754
xen_auto_xlat_grant_frames.pfn = pfn;
efaf30a3357872c Konrad Rzeszutek Wilk 2014-01-06 755
xen_auto_xlat_grant_frames.count = max_nr_gframes;
efaf30a3357872c Konrad Rzeszutek Wilk 2014-01-06 756
efaf30a3357872c Konrad Rzeszutek Wilk 2014-01-06 757 return 0;
efaf30a3357872c Konrad Rzeszutek Wilk 2014-01-06 758 }
efaf30a3357872c Konrad Rzeszutek Wilk 2014-01-06 759
EXPORT_SYMBOL_GPL(gnttab_setup_auto_xlat_frames);
efaf30a3357872c Konrad Rzeszutek Wilk 2014-01-06 760
efaf30a3357872c Konrad Rzeszutek Wilk 2014-01-06 761 void
gnttab_free_auto_xlat_frames(void)
efaf3
[PATCH] MIPS: Grant pte read permission, even if vma only have VM_WRITE permission.
Background:
a cpu have RIXI feature.
Now, if a vma only have VM_WRITE permission, the vma->vm_page_prot will
set _PAGE_NO_READ. In general case, someone read the vma will trigger
RI exception, then do_page_fault will handle it.
But in the following scene, program will hang.
example scene(a trinity test case):
futex_wake_op() will read uaddr, which is passed from user space.
If a program mmap a vma, which only have VM_WRITE permission,
then call futex, and use an address belonging to the vma as uaddr
argument. futex_wake_op() will read the address after disable
pagefault and set correct __ex_table(return -14 directly),
do_page_fault will find the correct __ex_table, and then return -14.
Then futex_wake_op() will try to fixup this error by call
fault_in_user_writeable(), because the pte have write permission,
so handle_mm_fault will do nothing, and return success.
But the RI bit in pte and tlb entry still exsits.
The program will deadloop:
do_page_fault -> find __ex_table success -> return -14;
futex_wake_op -> call fault_in_user_writeable() to fix the error -> retry;
do_page_fault -> find __ex_table success -> return -14;
futex_wake_op -> call fault_in_user_writeable() to fix the error -> retry;
.
The first perspective of root cause:
Futex think a pte have write permission will have read permission.
When page fault, it only try to fixup with FAULT_FLAG_WRITE.
The second perspective of root cause:
MIPS platform doesn't grant pte read permission, if vma only have
VM_WRITE permission.But X86 and arm64 will.
Most of the architecture will grant pte read permission, even if
the vma only have VM_WRITE permission.
And if the cpu doesn't have RIXI feature, MIPS platform will
grant pte read permission by set _PAGE_READ.
So I think we should fixup thix problem by grant pte read permission,
even if vma only have VM_WRITE permission.
Signed-off-by: Lichao Liu
---
arch/mips/mm/cache.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/mips/mm/cache.c b/arch/mips/mm/cache.c
index ad6df1cea866..72b60c44a962 100644
--- a/arch/mips/mm/cache.c
+++ b/arch/mips/mm/cache.c
@@ -160,7 +160,7 @@ static inline void setup_protection_map(void)
if (cpu_has_rixi) {
protection_map[0] = __pgprot(_page_cachable_default |
_PAGE_PRESENT | _PAGE_NO_EXEC | _PAGE_NO_READ);
protection_map[1] = __pgprot(_page_cachable_default |
_PAGE_PRESENT | _PAGE_NO_EXEC);
- protection_map[2] = __pgprot(_page_cachable_default |
_PAGE_PRESENT | _PAGE_NO_EXEC | _PAGE_NO_READ);
+ protection_map[2] = __pgprot(_page_cachable_default |
_PAGE_PRESENT | _PAGE_NO_EXEC);
protection_map[3] = __pgprot(_page_cachable_default |
_PAGE_PRESENT | _PAGE_NO_EXEC);
protection_map[4] = __pgprot(_page_cachable_default |
_PAGE_PRESENT);
protection_map[5] = __pgprot(_page_cachable_default |
_PAGE_PRESENT);
@@ -169,7 +169,7 @@ static inline void setup_protection_map(void)
protection_map[8] = __pgprot(_page_cachable_default |
_PAGE_PRESENT | _PAGE_NO_EXEC | _PAGE_NO_READ);
protection_map[9] = __pgprot(_page_cachable_default |
_PAGE_PRESENT | _PAGE_NO_EXEC);
- protection_map[10] = __pgprot(_page_cachable_default |
_PAGE_PRESENT | _PAGE_NO_EXEC | _PAGE_WRITE | _PAGE_NO_READ);
+ protection_map[10] = __pgprot(_page_cachable_default |
_PAGE_PRESENT | _PAGE_NO_EXEC | _PAGE_WRITE);
protection_map[11] = __pgprot(_page_cachable_default |
_PAGE_PRESENT | _PAGE_NO_EXEC | _PAGE_WRITE);
protection_map[12] = __pgprot(_page_cachable_default |
_PAGE_PRESENT);
protection_map[13] = __pgprot(_page_cachable_default |
_PAGE_PRESENT);
--
2.25.1
Grant(info)
Lieber Bewohner, lieber Die DBZ Project Foundation hat 25 Millionen US-Dollar für Notfallzuschüsse für kleine Unternehmen und einzelne Projekte bereitgestellt. Der Betrag variiert zwischen 300.000,00 USD und 800.000,00 USD pro Antragsteller. Die Bewerbung beginnt am 27. April unter folgender E-Mail-Adresse: inf...@dbzmail.com Sie finden Details in mehreren Sprachen, die erforderlichen Bewerbungsunterlagen und ein Bewerbungsformular. HINWEIS: Diese Spende gilt für die ersten 30 Bewerber. Vielen Dank, DBZ-Projektteam (Weltstiftungsgruppe). E-Mail: inf...@dbzmail.com. E-Mail: donationbudgetzonefoundat...@gmail.com. Policy Disclaimer for Donation Budget Zone Foundation. Corporacion: This message contains information that may be privileged or confidential and is the property of Donation Budget Zone Foundation. It is only intended for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
[PATCH 4.4 63/70] xen/xenbus: ensure xenbus_map_ring_valloc() returns proper grant status
From: Juergen Gross
[ Upstream commit 6b51fd3f65a22e3d1471b18a1d56247e246edd46 ]
xenbus_map_ring_valloc() maps a ring page and returns the status of the
used grant (0 meaning success).
There are Xen hypervisors which might return the value 1 for the status
of a failed grant mapping due to a bug. Some callers of
xenbus_map_ring_valloc() test for errors by testing the returned status
to be less than zero, resulting in no error detected and crashing later
due to a not available ring page.
Set the return value of xenbus_map_ring_valloc() to GNTST_general_error
in case the grant status reported by Xen is greater than zero.
This is part of XSA-316.
Signed-off-by: Juergen Gross
Reviewed-by: Wei Liu
Link: https://lore.kernel.org/r/20200326080358.1018-1-jgr...@suse.com
Signed-off-by: Juergen Gross
Signed-off-by: Sasha Levin
---
drivers/xen/xenbus/xenbus_client.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/xen/xenbus/xenbus_client.c
b/drivers/xen/xenbus/xenbus_client.c
index 056da6ee1a357..df27cefb2fa35 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -469,7 +469,14 @@ EXPORT_SYMBOL_GPL(xenbus_free_evtchn);
int xenbus_map_ring_valloc(struct xenbus_device *dev, grant_ref_t *gnt_refs,
unsigned int nr_grefs, void **vaddr)
{
- return ring_ops->map(dev, gnt_refs, nr_grefs, vaddr);
+ int err;
+
+ err = ring_ops->map(dev, gnt_refs, nr_grefs, vaddr);
+ /* Some hypervisors are buggy and can return 1. */
+ if (err > 0)
+ err = GNTST_general_error;
+
+ return err;
}
EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc);
--
2.20.1
[PATCH 4.9 71/80] xen/xenbus: ensure xenbus_map_ring_valloc() returns proper grant status
From: Juergen Gross
[ Upstream commit 6b51fd3f65a22e3d1471b18a1d56247e246edd46 ]
xenbus_map_ring_valloc() maps a ring page and returns the status of the
used grant (0 meaning success).
There are Xen hypervisors which might return the value 1 for the status
of a failed grant mapping due to a bug. Some callers of
xenbus_map_ring_valloc() test for errors by testing the returned status
to be less than zero, resulting in no error detected and crashing later
due to a not available ring page.
Set the return value of xenbus_map_ring_valloc() to GNTST_general_error
in case the grant status reported by Xen is greater than zero.
This is part of XSA-316.
Signed-off-by: Juergen Gross
Reviewed-by: Wei Liu
Link: https://lore.kernel.org/r/20200326080358.1018-1-jgr...@suse.com
Signed-off-by: Juergen Gross
Signed-off-by: Sasha Levin
---
drivers/xen/xenbus/xenbus_client.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/xen/xenbus/xenbus_client.c
b/drivers/xen/xenbus/xenbus_client.c
index 056da6ee1a357..df27cefb2fa35 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -469,7 +469,14 @@ EXPORT_SYMBOL_GPL(xenbus_free_evtchn);
int xenbus_map_ring_valloc(struct xenbus_device *dev, grant_ref_t *gnt_refs,
unsigned int nr_grefs, void **vaddr)
{
- return ring_ops->map(dev, gnt_refs, nr_grefs, vaddr);
+ int err;
+
+ err = ring_ops->map(dev, gnt_refs, nr_grefs, vaddr);
+ /* Some hypervisors are buggy and can return 1. */
+ if (err > 0)
+ err = GNTST_general_error;
+
+ return err;
}
EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc);
--
2.20.1
[PATCH 4.19 37/46] xen/xenbus: ensure xenbus_map_ring_valloc() returns proper grant status
From: Juergen Gross
[ Upstream commit 6b51fd3f65a22e3d1471b18a1d56247e246edd46 ]
xenbus_map_ring_valloc() maps a ring page and returns the status of the
used grant (0 meaning success).
There are Xen hypervisors which might return the value 1 for the status
of a failed grant mapping due to a bug. Some callers of
xenbus_map_ring_valloc() test for errors by testing the returned status
to be less than zero, resulting in no error detected and crashing later
due to a not available ring page.
Set the return value of xenbus_map_ring_valloc() to GNTST_general_error
in case the grant status reported by Xen is greater than zero.
This is part of XSA-316.
Signed-off-by: Juergen Gross
Reviewed-by: Wei Liu
Link: https://lore.kernel.org/r/20200326080358.1018-1-jgr...@suse.com
Signed-off-by: Juergen Gross
Signed-off-by: Sasha Levin
---
drivers/xen/xenbus/xenbus_client.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/xen/xenbus/xenbus_client.c
b/drivers/xen/xenbus/xenbus_client.c
index a1c17000129ba..e94a61eaeceb0 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -450,7 +450,14 @@ EXPORT_SYMBOL_GPL(xenbus_free_evtchn);
int xenbus_map_ring_valloc(struct xenbus_device *dev, grant_ref_t *gnt_refs,
unsigned int nr_grefs, void **vaddr)
{
- return ring_ops->map(dev, gnt_refs, nr_grefs, vaddr);
+ int err;
+
+ err = ring_ops->map(dev, gnt_refs, nr_grefs, vaddr);
+ /* Some hypervisors are buggy and can return 1. */
+ if (err > 0)
+ err = GNTST_general_error;
+
+ return err;
}
EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc);
--
2.20.1
[PATCH 5.4 66/83] xen/xenbus: ensure xenbus_map_ring_valloc() returns proper grant status
From: Juergen Gross
[ Upstream commit 6b51fd3f65a22e3d1471b18a1d56247e246edd46 ]
xenbus_map_ring_valloc() maps a ring page and returns the status of the
used grant (0 meaning success).
There are Xen hypervisors which might return the value 1 for the status
of a failed grant mapping due to a bug. Some callers of
xenbus_map_ring_valloc() test for errors by testing the returned status
to be less than zero, resulting in no error detected and crashing later
due to a not available ring page.
Set the return value of xenbus_map_ring_valloc() to GNTST_general_error
in case the grant status reported by Xen is greater than zero.
This is part of XSA-316.
Signed-off-by: Juergen Gross
Reviewed-by: Wei Liu
Link: https://lore.kernel.org/r/20200326080358.1018-1-jgr...@suse.com
Signed-off-by: Juergen Gross
Signed-off-by: Sasha Levin
---
drivers/xen/xenbus/xenbus_client.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/xen/xenbus/xenbus_client.c
b/drivers/xen/xenbus/xenbus_client.c
index e17ca81561713..a38292ef79f6d 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -448,7 +448,14 @@ EXPORT_SYMBOL_GPL(xenbus_free_evtchn);
int xenbus_map_ring_valloc(struct xenbus_device *dev, grant_ref_t *gnt_refs,
unsigned int nr_grefs, void **vaddr)
{
- return ring_ops->map(dev, gnt_refs, nr_grefs, vaddr);
+ int err;
+
+ err = ring_ops->map(dev, gnt_refs, nr_grefs, vaddr);
+ /* Some hypervisors are buggy and can return 1. */
+ if (err > 0)
+ err = GNTST_general_error;
+
+ return err;
}
EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc);
--
2.20.1
[PATCH 5.6 082/106] xen/xenbus: ensure xenbus_map_ring_valloc() returns proper grant status
From: Juergen Gross
[ Upstream commit 6b51fd3f65a22e3d1471b18a1d56247e246edd46 ]
xenbus_map_ring_valloc() maps a ring page and returns the status of the
used grant (0 meaning success).
There are Xen hypervisors which might return the value 1 for the status
of a failed grant mapping due to a bug. Some callers of
xenbus_map_ring_valloc() test for errors by testing the returned status
to be less than zero, resulting in no error detected and crashing later
due to a not available ring page.
Set the return value of xenbus_map_ring_valloc() to GNTST_general_error
in case the grant status reported by Xen is greater than zero.
This is part of XSA-316.
Signed-off-by: Juergen Gross
Reviewed-by: Wei Liu
Link: https://lore.kernel.org/r/20200326080358.1018-1-jgr...@suse.com
Signed-off-by: Juergen Gross
Signed-off-by: Sasha Levin
---
drivers/xen/xenbus/xenbus_client.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/xen/xenbus/xenbus_client.c
b/drivers/xen/xenbus/xenbus_client.c
index e17ca81561713..a38292ef79f6d 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -448,7 +448,14 @@ EXPORT_SYMBOL_GPL(xenbus_free_evtchn);
int xenbus_map_ring_valloc(struct xenbus_device *dev, grant_ref_t *gnt_refs,
unsigned int nr_grefs, void **vaddr)
{
- return ring_ops->map(dev, gnt_refs, nr_grefs, vaddr);
+ int err;
+
+ err = ring_ops->map(dev, gnt_refs, nr_grefs, vaddr);
+ /* Some hypervisors are buggy and can return 1. */
+ if (err > 0)
+ err = GNTST_general_error;
+
+ return err;
}
EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc);
--
2.20.1
[PATCH 4.14 104/117] xen/xenbus: ensure xenbus_map_ring_valloc() returns proper grant status
From: Juergen Gross
[ Upstream commit 6b51fd3f65a22e3d1471b18a1d56247e246edd46 ]
xenbus_map_ring_valloc() maps a ring page and returns the status of the
used grant (0 meaning success).
There are Xen hypervisors which might return the value 1 for the status
of a failed grant mapping due to a bug. Some callers of
xenbus_map_ring_valloc() test for errors by testing the returned status
to be less than zero, resulting in no error detected and crashing later
due to a not available ring page.
Set the return value of xenbus_map_ring_valloc() to GNTST_general_error
in case the grant status reported by Xen is greater than zero.
This is part of XSA-316.
Signed-off-by: Juergen Gross
Reviewed-by: Wei Liu
Link: https://lore.kernel.org/r/20200326080358.1018-1-jgr...@suse.com
Signed-off-by: Juergen Gross
Signed-off-by: Sasha Levin
---
drivers/xen/xenbus/xenbus_client.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/xen/xenbus/xenbus_client.c
b/drivers/xen/xenbus/xenbus_client.c
index a1c17000129ba..e94a61eaeceb0 100644
--- a/drivers/xen/xenbus/xenbus_client.c
+++ b/drivers/xen/xenbus/xenbus_client.c
@@ -450,7 +450,14 @@ EXPORT_SYMBOL_GPL(xenbus_free_evtchn);
int xenbus_map_ring_valloc(struct xenbus_device *dev, grant_ref_t *gnt_refs,
unsigned int nr_grefs, void **vaddr)
{
- return ring_ops->map(dev, gnt_refs, nr_grefs, vaddr);
+ int err;
+
+ err = ring_ops->map(dev, gnt_refs, nr_grefs, vaddr);
+ /* Some hypervisors are buggy and can return 1. */
+ if (err > 0)
+ err = GNTST_general_error;
+
+ return err;
}
EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc);
--
2.20.1
Re: [PATCH] xen/grant-table: remove unnecessary printing
On 10.10.19 10:32, Fuqian Huang wrote: xen_auto_xlat_grant_frames.vaddr is definitely NULL in this case. So the address printing is unnecessary. Signed-off-by: Fuqian Huang Reviewed-by: Juergen Gross Juergen
[PATCH] xen/grant-table: remove unnecessary printing
xen_auto_xlat_grant_frames.vaddr is definitely NULL in this case.
So the address printing is unnecessary.
Signed-off-by: Fuqian Huang
---
drivers/xen/grant-table.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 7ea6fb6a2e5d..49b381e104ef 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -1363,8 +1363,7 @@ static int gnttab_setup(void)
if (xen_feature(XENFEAT_auto_translated_physmap) && gnttab_shared.addr
== NULL) {
gnttab_shared.addr = xen_auto_xlat_grant_frames.vaddr;
if (gnttab_shared.addr == NULL) {
- pr_warn("gnttab share frames (addr=0x%08lx) is not
mapped!\n",
- (unsigned
long)xen_auto_xlat_grant_frames.vaddr);
+ pr_warn("gnttab share frames is not mapped!\n");
return -ENOMEM;
}
}
--
2.11.0
Re: [RFC PATCH 21/21] KVM: x86: Add capability to grant VM access to privileged SGX attribute
On Fri, Jul 26, 2019 at 10:52 PM Sean Christopherson wrote: > > The SGX subsystem restricts access to a subset of enclave attributes to > provide additional security for an uncompromised kernel, e.g. to prevent > malware from using the PROVISIONKEY to ensure its nodes are running > inside a geniune SGX enclave and/or to obtain a stable fingerprint. > > To prevent userspace from circumventing such restrictions by running an > enclave in a VM, KVM restricts guest access to privileged attributes by > default. Add a capability, KVM_CAP_SGX_ATTRIBUTE, that can be used by > userspace to grant a VM access to a priveleged attribute, with args[0] > holding a file handle to a valid SGX attribute file corresponding to > an attribute that is restricted by KVM (currently only PROVISIONKEY). Looks good to me. Thanks! > +can use KVM_CAP_SGX_ATTRIBUTE to grant a VM access to a priveleged attribute. Spelling.
[RFC PATCH 21/21] KVM: x86: Add capability to grant VM access to privileged SGX attribute
The SGX subsystem restricts access to a subset of enclave attributes to
provide additional security for an uncompromised kernel, e.g. to prevent
malware from using the PROVISIONKEY to ensure its nodes are running
inside a geniune SGX enclave and/or to obtain a stable fingerprint.
To prevent userspace from circumventing such restrictions by running an
enclave in a VM, KVM restricts guest access to privileged attributes by
default. Add a capability, KVM_CAP_SGX_ATTRIBUTE, that can be used by
userspace to grant a VM access to a priveleged attribute, with args[0]
holding a file handle to a valid SGX attribute file corresponding to
an attribute that is restricted by KVM (currently only PROVISIONKEY).
Cc: Andy Lutomirski
Signed-off-by: Sean Christopherson
---
Documentation/virtual/kvm/api.txt | 20
arch/x86/kvm/cpuid.c | 2 +-
arch/x86/kvm/x86.c| 22 ++
include/uapi/linux/kvm.h | 1 +
4 files changed, 44 insertions(+), 1 deletion(-)
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index 383b292966fa..b1c0ff4e9224 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -5013,6 +5013,26 @@ it hard or impossible to use it correctly. The
availability of
KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2 signals that those bugs are fixed.
Userspace should not try to use KVM_CAP_MANUAL_DIRTY_LOG_PROTECT.
+7.19 KVM_CAP_SGX_ATTRIBUTE
+
+Architectures: x86
+Parameters: args[0] is a file handle of a SGX attribute file in securityfs
+Returns: 0 on success, -EINVAL if the file handle is invalid or if a requested
+attribute is not supported by KVM.
+
+The SGX subsystem restricts access to a subset of enclave attributes, e.g. the
+PROVISIONKEY, to provide additional security for an uncompromised kernel, e.g.
+to prevent malware from using the PROVISIONKEY to ensure its nodes are running
+inside a geniune SGX enclave and/or to obtain a stable system fingerprint.
+
+To prevent userspace from circumventing such restrictions by running an enclave
+in a VM, KVM prevents access to privileged attributes by default. Userspace
+can use KVM_CAP_SGX_ATTRIBUTE to grant a VM access to a priveleged attribute.
+args[0] must hold a file handle to a valid SGX attribute file corresponding to
+an attribute that is supported/restricted by KVM (currently only PROVISIONKEY).
+
+See Documentation/x86/sgx/2.Kernel-internals.rst for more details.
+
8. Other capabilities.
--
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 73a0326a1968..73af09edb2fa 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -439,7 +439,7 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2
*entry, u32 function,
/* cpuid 12.1.eax*/
const u32 kvm_cpuid_12_1_eax_sgx_features =
- SGX_ATTR_DEBUG | SGX_ATTR_MODE64BIT | 0 /* PROVISIONKEY */ |
+ SGX_ATTR_DEBUG | SGX_ATTR_MODE64BIT | SGX_ATTR_PROVISIONKEY |
SGX_ATTR_EINITTOKENKEY | SGX_ATTR_KSS;
/* cpuid 12.1.ebx*/
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index ec92c5534336..9144909d4a8e 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -67,6 +67,8 @@
#include
#include
#include
+#include
+#include
#include
#define CREATE_TRACE_POINTS
@@ -3090,6 +3092,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long
ext)
case KVM_CAP_GET_MSR_FEATURES:
case KVM_CAP_MSR_PLATFORM_INFO:
case KVM_CAP_EXCEPTION_PAYLOAD:
+#ifdef CONFIG_INTEL_SGX_VIRTUALIZATION
+ case KVM_CAP_SGX_ATTRIBUTE:
+#endif
r = 1;
break;
case KVM_CAP_SYNC_REGS:
@@ -4626,6 +4631,23 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
kvm->arch.exception_payload_enabled = cap->args[0];
r = 0;
break;
+#ifdef CONFIG_INTEL_SGX_VIRTUALIZATION
+ case KVM_CAP_SGX_ATTRIBUTE: {
+ u64 allowed_attributes = 0;
+
+ r = sgx_set_attribute(_attributes, cap->args[0]);
+ if (r)
+ break;
+
+ /* KVM only supports the PROVISIONKEY privileged attribute. */
+ if ((allowed_attributes & SGX_ATTR_PROVISIONKEY) &&
+ !(allowed_attributes & ~SGX_ATTR_PROVISIONKEY))
+ kvm->arch.sgx_provisioning_allowed = true;
+ else
+ r = -EINVAL;
+ break;
+ }
+#endif
default:
r = -EINVAL;
break;
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 2fe12b40d503..b16708c2b6c9 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -993,6 +993,7 @@ struct kvm_ppc_resize_hpt {
#define KVM_CAP_ARM_SVE 170
#define KVM_CAP_ARM_PTRAUTH_ADDRESS 171
#define KVM_CAP_ARM_PTRAUTH_GENERIC 172
+#define KVM_CAP
[PATCH 08/10] keys: Grant Link permission to possessers of request_key auth keys [ver #3]
Grant Link permission to the possessers of request_key authentication keys,
thereby allowing a daemon that is servicing upcalls to arrange things such
that only the necessary auth key is passed to the actual service program
and not all the daemon's pending auth keys.
Signed-off-by: David Howells
Reviewed-by: James Morris
---
security/keys/request_key_auth.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/security/keys/request_key_auth.c b/security/keys/request_key_auth.c
index 572c7a60473a..ec5226557023 100644
--- a/security/keys/request_key_auth.c
+++ b/security/keys/request_key_auth.c
@@ -204,7 +204,7 @@ struct key *request_key_auth_new(struct key *target, const
char *op,
authkey = key_alloc(_type_request_key_auth, desc,
cred->fsuid, cred->fsgid, cred,
- KEY_POS_VIEW | KEY_POS_READ | KEY_POS_SEARCH |
+ KEY_POS_VIEW | KEY_POS_READ | KEY_POS_SEARCH |
KEY_POS_LINK |
KEY_USR_VIEW, KEY_ALLOC_NOT_IN_QUOTA, NULL);
if (IS_ERR(authkey)) {
ret = PTR_ERR(authkey);
Re: [RFC PATCH 16/16] xen/grant-table: host_addr fixup in mapping on xenhost_r0
On 6/17/19 3:55 AM, Juergen Gross wrote: On 09.05.19 19:25, Ankur Arora wrote: Xenhost type xenhost_r0 does not support standard GNTTABOP_map_grant_ref semantics (map a gref onto a specified host_addr). That's because since the hypervisor is local (same address space as the caller of GNTTABOP_map_grant_ref), there is no external entity that could map an arbitrary page underneath an arbitrary address. To handle this, the GNTTABOP_map_grant_ref hypercall on xenhost_r0 treats the host_addr as an OUT parameter instead of IN and expects the gnttab_map_refs() and similar to fixup any state that caches the value of host_addr from before the hypercall. Accordingly gnttab_map_refs() now adds two parameters, a fixup function and a pointer to cached maps to fixup: int gnttab_map_refs(xenhost_t *xh, struct gnttab_map_grant_ref *map_ops, struct gnttab_map_grant_ref *kmap_ops, - struct page **pages, unsigned int count) + struct page **pages, gnttab_map_fixup_t map_fixup_fn, + void **map_fixup[], unsigned int count) The reason we use a fixup function and not an additional mapping op in the xenhost_t is because, depending on the caller, what we are fixing might be different: blkback, netback for instance cache host_addr in via a struct page *, while __xenbus_map_ring() caches a phys_addr. This patch fixes up xen-blkback and xen-gntdev drivers. TODO: - also rewrite gnttab_batch_map() and __xenbus_map_ring(). - modify xen-netback, scsiback, pciback etc Co-developed-by: Joao Martins Signed-off-by: Ankur Arora Without seeing the __xenbus_map_ring() modification it is impossible to do a proper review of this patch. Will do in v2. Ankur Juergen
Re: [RFC PATCH 11/16] xen/grant-table: make grant-table xenhost aware
On 6/17/19 2:36 AM, Juergen Gross wrote:
On 09.05.19 19:25, Ankur Arora wrote:
Largely mechanical changes: the exported grant table symbols now take
xenhost_t * as a parameter. Also, move the grant table global state
inside xenhost_t.
If there's more than one xenhost, then initialize both.
Signed-off-by: Ankur Arora
---
arch/x86/xen/grant-table.c | 71 +++--
drivers/xen/grant-table.c | 611 +
include/xen/grant_table.h | 72 ++---
include/xen/xenhost.h | 11 +
4 files changed, 443 insertions(+), 322 deletions(-)
diff --git a/include/xen/xenhost.h b/include/xen/xenhost.h
index 9e08627a9e3e..acee0c7872b6 100644
--- a/include/xen/xenhost.h
+++ b/include/xen/xenhost.h
@@ -129,6 +129,17 @@ typedef struct {
const struct evtchn_ops *evtchn_ops;
int **evtchn_to_irq;
};
+
+ /* grant table private state */
+ struct {
+ /* private to drivers/xen/grant-table.c */
+ void *gnttab_private;
+
+ /* x86/xen/grant-table.c */
+ void *gnttab_shared_vm_area;
+ void *gnttab_status_vm_area;
+ void *auto_xlat_grant_frames;
Please use proper types here instead of void *. This avoids lots of
casts. It is okay to just add anonymous struct definitions and keep the
real struct layout local to grant table code.
Will fix.
Ankur
Juergen
Re: [RFC PATCH 16/16] xen/grant-table: host_addr fixup in mapping on xenhost_r0
On 09.05.19 19:25, Ankur Arora wrote: Xenhost type xenhost_r0 does not support standard GNTTABOP_map_grant_ref semantics (map a gref onto a specified host_addr). That's because since the hypervisor is local (same address space as the caller of GNTTABOP_map_grant_ref), there is no external entity that could map an arbitrary page underneath an arbitrary address. To handle this, the GNTTABOP_map_grant_ref hypercall on xenhost_r0 treats the host_addr as an OUT parameter instead of IN and expects the gnttab_map_refs() and similar to fixup any state that caches the value of host_addr from before the hypercall. Accordingly gnttab_map_refs() now adds two parameters, a fixup function and a pointer to cached maps to fixup: int gnttab_map_refs(xenhost_t *xh, struct gnttab_map_grant_ref *map_ops, struct gnttab_map_grant_ref *kmap_ops, - struct page **pages, unsigned int count) + struct page **pages, gnttab_map_fixup_t map_fixup_fn, + void **map_fixup[], unsigned int count) The reason we use a fixup function and not an additional mapping op in the xenhost_t is because, depending on the caller, what we are fixing might be different: blkback, netback for instance cache host_addr in via a struct page *, while __xenbus_map_ring() caches a phys_addr. This patch fixes up xen-blkback and xen-gntdev drivers. TODO: - also rewrite gnttab_batch_map() and __xenbus_map_ring(). - modify xen-netback, scsiback, pciback etc Co-developed-by: Joao Martins Signed-off-by: Ankur Arora Without seeing the __xenbus_map_ring() modification it is impossible to do a proper review of this patch. Juergen
Re: [RFC PATCH 11/16] xen/grant-table: make grant-table xenhost aware
On 09.05.19 19:25, Ankur Arora wrote:
Largely mechanical changes: the exported grant table symbols now take
xenhost_t * as a parameter. Also, move the grant table global state
inside xenhost_t.
If there's more than one xenhost, then initialize both.
Signed-off-by: Ankur Arora
---
arch/x86/xen/grant-table.c | 71 +++--
drivers/xen/grant-table.c | 611 +
include/xen/grant_table.h | 72 ++---
include/xen/xenhost.h | 11 +
4 files changed, 443 insertions(+), 322 deletions(-)
diff --git a/include/xen/xenhost.h b/include/xen/xenhost.h
index 9e08627a9e3e..acee0c7872b6 100644
--- a/include/xen/xenhost.h
+++ b/include/xen/xenhost.h
@@ -129,6 +129,17 @@ typedef struct {
const struct evtchn_ops *evtchn_ops;
int **evtchn_to_irq;
};
+
+ /* grant table private state */
+ struct {
+ /* private to drivers/xen/grant-table.c */
+ void *gnttab_private;
+
+ /* x86/xen/grant-table.c */
+ void *gnttab_shared_vm_area;
+ void *gnttab_status_vm_area;
+ void *auto_xlat_grant_frames;
Please use proper types here instead of void *. This avoids lots of
casts. It is okay to just add anonymous struct definitions and keep the
real struct layout local to grant table code.
Juergen
Re: Loan grant @affordable rate
Hello Dear, We are a large Company based in Istanbul Turkey and we offers flexible loans and funding for all projects for as low as 2% interest rate per annum for a period of 5-15 yrs . We invite you to partner with us and benefit in our new Loan and Project funding program. We can approve a loan/funding for up to USD$1 Billion or more depending on the nature of business so If you need loan/ funding and for more details Send us email to customers email address only at: l...@mfigc.info Note: We also pay 1% agents fee for each client referred to us by agent therefore if you know any one who need genuine loan you can refer to us and get 1%. This is a Guaranteed loan/Funding and please reply only to this email address at: l...@mfigc.info Regards Haider Dawber Istanbul-Turkey Email: l...@mfigc.info
[PATCH 08/10] keys: Grant Link permission to possessers of request_key auth keys [ver #2]
Grant Link permission to the possessers of request_key authentication keys,
thereby allowing a daemon that is servicing upcalls to arrange things such
that only the necessary auth key is passed to the actual service program
and not all the daemon's pending auth keys.
Signed-off-by: David Howells
Reviewed-by: James Morris
---
security/keys/request_key_auth.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/security/keys/request_key_auth.c b/security/keys/request_key_auth.c
index 572c7a60473a..ec5226557023 100644
--- a/security/keys/request_key_auth.c
+++ b/security/keys/request_key_auth.c
@@ -204,7 +204,7 @@ struct key *request_key_auth_new(struct key *target, const
char *op,
authkey = key_alloc(_type_request_key_auth, desc,
cred->fsuid, cred->fsgid, cred,
- KEY_POS_VIEW | KEY_POS_READ | KEY_POS_SEARCH |
+ KEY_POS_VIEW | KEY_POS_READ | KEY_POS_SEARCH |
KEY_POS_LINK |
KEY_USR_VIEW, KEY_ALLOC_NOT_IN_QUOTA, NULL);
if (IS_ERR(authkey)) {
ret = PTR_ERR(authkey);
Re: [PATCH 7/7] keys: Grant Link permission to possessers of request_key auth keys
On Wed, 22 May 2019, David Howells wrote: > Grant Link permission to the possessers of request_key authentication keys, > thereby allowing a daemon that is servicing upcalls to arrange things such > that only the necessary auth key is passed to the actual service program > and not all the daemon's pending auth keys. > > Signed-off-by: David Howells Reviewed-by: James Morris -- James Morris
[PATCH 7/7] keys: Grant Link permission to possessers of request_key auth keys
Grant Link permission to the possessers of request_key authentication keys,
thereby allowing a daemon that is servicing upcalls to arrange things such
that only the necessary auth key is passed to the actual service program
and not all the daemon's pending auth keys.
Signed-off-by: David Howells
---
security/keys/request_key_auth.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/security/keys/request_key_auth.c b/security/keys/request_key_auth.c
index 572c7a60473a..ec5226557023 100644
--- a/security/keys/request_key_auth.c
+++ b/security/keys/request_key_auth.c
@@ -204,7 +204,7 @@ struct key *request_key_auth_new(struct key *target, const
char *op,
authkey = key_alloc(_type_request_key_auth, desc,
cred->fsuid, cred->fsgid, cred,
- KEY_POS_VIEW | KEY_POS_READ | KEY_POS_SEARCH |
+ KEY_POS_VIEW | KEY_POS_READ | KEY_POS_SEARCH |
KEY_POS_LINK |
KEY_USR_VIEW, KEY_ALLOC_NOT_IN_QUOTA, NULL);
if (IS_ERR(authkey)) {
ret = PTR_ERR(authkey);
[RFC PATCH 11/16] xen/grant-table: make grant-table xenhost aware
Largely mechanical changes: the exported grant table symbols now take
xenhost_t * as a parameter. Also, move the grant table global state
inside xenhost_t.
If there's more than one xenhost, then initialize both.
Signed-off-by: Ankur Arora
---
arch/x86/xen/grant-table.c | 71 +++--
drivers/xen/grant-table.c | 611 +
include/xen/grant_table.h | 72 ++---
include/xen/xenhost.h | 11 +
4 files changed, 443 insertions(+), 322 deletions(-)
diff --git a/arch/x86/xen/grant-table.c b/arch/x86/xen/grant-table.c
index ecb0d5450334..8f4b071427f9 100644
--- a/arch/x86/xen/grant-table.c
+++ b/arch/x86/xen/grant-table.c
@@ -23,48 +23,54 @@
#include
-static struct gnttab_vm_area {
+struct gnttab_vm_area {
struct vm_struct *area;
pte_t **ptes;
-} gnttab_shared_vm_area, gnttab_status_vm_area;
+};
-int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
- unsigned long max_nr_gframes,
- void **__shared)
+int arch_gnttab_map_shared(xenhost_t *xh, unsigned long *frames,
+ unsigned long nr_gframes,
+ unsigned long max_nr_gframes,
+ void **__shared)
{
void *shared = *__shared;
unsigned long addr;
unsigned long i;
if (shared == NULL)
- *__shared = shared = gnttab_shared_vm_area.area->addr;
+ *__shared = shared = ((struct gnttab_vm_area *)
+ xh->gnttab_shared_vm_area)->area->addr;
addr = (unsigned long)shared;
for (i = 0; i < nr_gframes; i++) {
- set_pte_at(_mm, addr, gnttab_shared_vm_area.ptes[i],
- mfn_pte(frames[i], PAGE_KERNEL));
+ set_pte_at(_mm, addr,
+ ((struct gnttab_vm_area *)
xh->gnttab_shared_vm_area)->ptes[i],
+ mfn_pte(frames[i], PAGE_KERNEL));
addr += PAGE_SIZE;
}
return 0;
}
-int arch_gnttab_map_status(uint64_t *frames, unsigned long nr_gframes,
- unsigned long max_nr_gframes,
- grant_status_t **__shared)
+int arch_gnttab_map_status(xenhost_t *xh, uint64_t *frames,
+ unsigned long nr_gframes,
+ unsigned long max_nr_gframes,
+ grant_status_t **__shared)
{
grant_status_t *shared = *__shared;
unsigned long addr;
unsigned long i;
if (shared == NULL)
- *__shared = shared = gnttab_status_vm_area.area->addr;
+ *__shared = shared = ((struct gnttab_vm_area *)
+ xh->gnttab_status_vm_area)->area->addr;
addr = (unsigned long)shared;
for (i = 0; i < nr_gframes; i++) {
- set_pte_at(_mm, addr, gnttab_status_vm_area.ptes[i],
+ set_pte_at(_mm, addr, ((struct gnttab_vm_area *)
+ xh->gnttab_status_vm_area)->ptes[i],
mfn_pte(frames[i], PAGE_KERNEL));
addr += PAGE_SIZE;
}
@@ -72,16 +78,17 @@ int arch_gnttab_map_status(uint64_t *frames, unsigned long
nr_gframes,
return 0;
}
-void arch_gnttab_unmap(void *shared, unsigned long nr_gframes)
+void arch_gnttab_unmap(xenhost_t *xh, void *shared, unsigned long nr_gframes)
{
pte_t **ptes;
unsigned long addr;
unsigned long i;
- if (shared == gnttab_status_vm_area.area->addr)
- ptes = gnttab_status_vm_area.ptes;
+ if (shared == ((struct gnttab_vm_area *)
+ xh->gnttab_status_vm_area)->area->addr)
+ ptes = ((struct gnttab_vm_area *)
xh->gnttab_status_vm_area)->ptes;
else
- ptes = gnttab_shared_vm_area.ptes;
+ ptes = ((struct gnttab_vm_area *)
xh->gnttab_shared_vm_area)->ptes;
addr = (unsigned long)shared;
@@ -112,14 +119,15 @@ static void arch_gnttab_vfree(struct gnttab_vm_area *area)
kfree(area->ptes);
}
-int arch_gnttab_init(unsigned long nr_shared, unsigned long nr_status)
+int arch_gnttab_init(xenhost_t *xh, unsigned long nr_shared, unsigned long
nr_status)
{
int ret;
if (!xen_pv_domain())
return 0;
- ret = arch_gnttab_valloc(_shared_vm_area, nr_shared);
+ ret = arch_gnttab_valloc((struct gnttab_vm_area *)
+ xh->gnttab_shared_vm_area, nr_shared);
if (ret < 0)
return ret;
@@ -127,13 +135,15 @@ int arch_gnttab_init(unsigned long nr_shared, unsigned
long nr_status)
* Always allocate the space for the status frames in case
* we're migrated to a host with V2 support.
*/
- ret = arch_
[RFC PATCH 16/16] xen/grant-table: host_addr fixup in mapping on xenhost_r0
Xenhost type xenhost_r0 does not support standard GNTTABOP_map_grant_ref
semantics (map a gref onto a specified host_addr). That's because
since the hypervisor is local (same address space as the caller of
GNTTABOP_map_grant_ref), there is no external entity that could
map an arbitrary page underneath an arbitrary address.
To handle this, the GNTTABOP_map_grant_ref hypercall on xenhost_r0
treats the host_addr as an OUT parameter instead of IN and expects the
gnttab_map_refs() and similar to fixup any state that caches the
value of host_addr from before the hypercall.
Accordingly gnttab_map_refs() now adds two parameters, a fixup function
and a pointer to cached maps to fixup:
int gnttab_map_refs(xenhost_t *xh, struct gnttab_map_grant_ref *map_ops,
struct gnttab_map_grant_ref *kmap_ops,
- struct page **pages, unsigned int count)
+ struct page **pages, gnttab_map_fixup_t map_fixup_fn,
+ void **map_fixup[], unsigned int count)
The reason we use a fixup function and not an additional mapping op
in the xenhost_t is because, depending on the caller, what we are fixing
might be different: blkback, netback for instance cache host_addr in
via a struct page *, while __xenbus_map_ring() caches a phys_addr.
This patch fixes up xen-blkback and xen-gntdev drivers.
TODO:
- also rewrite gnttab_batch_map() and __xenbus_map_ring().
- modify xen-netback, scsiback, pciback etc
Co-developed-by: Joao Martins
Signed-off-by: Ankur Arora
---
drivers/block/xen-blkback/blkback.c | 14 +-
drivers/xen/gntdev.c| 2 +-
drivers/xen/grant-table.c | 20 ++--
include/xen/grant_table.h | 11 ++-
4 files changed, 38 insertions(+), 9 deletions(-)
diff --git a/drivers/block/xen-blkback/blkback.c
b/drivers/block/xen-blkback/blkback.c
index d366a17a4bd8..50ce40ba35e5 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -806,11 +806,18 @@ static void xen_blkbk_unmap(struct xen_blkif_ring *ring,
}
}
+static void blkbk_map_fixup(uint64_t host_addr, void **fixup)
+{
+ struct page **pg = (struct page **)fixup;
+ *pg = virt_to_page(host_addr);
+}
+
static int xen_blkbk_map(struct xen_blkif_ring *ring,
struct grant_page *pages[],
int num, bool ro)
{
struct gnttab_map_grant_ref map[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+ struct page **map_fixup[BLKIF_MAX_SEGMENTS_PER_REQUEST];
struct page *pages_to_gnt[BLKIF_MAX_SEGMENTS_PER_REQUEST];
struct persistent_gnt *persistent_gnt = NULL;
phys_addr_t addr = 0;
@@ -858,6 +865,9 @@ static int xen_blkbk_map(struct xen_blkif_ring *ring,
gnttab_set_map_op([segs_to_map++], addr,
flags, pages[i]->gref,
blkif->domid);
+
+ if (gnttab_map_fixup(dev->xh))
+ map_fixup[i] = [i]->page;
}
map_until = i + 1;
if (segs_to_map == BLKIF_MAX_SEGMENTS_PER_REQUEST)
@@ -865,7 +875,9 @@ static int xen_blkbk_map(struct xen_blkif_ring *ring,
}
if (segs_to_map) {
- ret = gnttab_map_refs(dev->xh, map, NULL, pages_to_gnt,
segs_to_map);
+ ret = gnttab_map_refs(dev->xh, map, NULL, pages_to_gnt,
+ gnttab_map_fixup(dev->xh) ? blkbk_map_fixup : NULL,
+ (void ***) map_fixup, segs_to_map);
BUG_ON(ret);
}
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 40a42abe2dd0..32c6471834ba 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -342,7 +342,7 @@ int gntdev_map_grant_pages(struct gntdev_grant_map *map)
pr_debug("map %d+%d\n", map->index, map->count);
err = gnttab_map_refs(xh, map->map_ops, use_ptemod ? map->kmap_ops :
NULL,
- map->pages, map->count);
+ map->pages, NULL, NULL, map->count);
if (err)
return err;
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 959b81ade113..2f3a0a4a2660 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -1084,7 +1084,8 @@ void gnttab_foreach_grant(struct page **pages,
int gnttab_map_refs(xenhost_t *xh, struct gnttab_map_grant_ref *map_ops,
struct gnttab_map_grant_ref *kmap_ops,
- struct page **pages, unsigned int count)
+ struct page **pages, gnttab_map_fixup_t map_fixup_fn,
+ void **map_fixup[], unsigned int count)
{
int i, ret;
@@ -1096,12 +1097,19 @@ int gnttab_map_refs(xenhost_t *xh, struct
gnttab_map_grant_ref *map_ops,
switc
[PATCH v2] mm: do not grant +x by default in memfd_create()
This syscall allows easy fileless execution, without calling chmod() first.
Thus, some security-related restrictions (like seccomp filters that deny
chmod +x) can by bypassed using memfd_create() if the policy author is
unaware of this.
Signed-off-by: Dima Krasner
Cc: linux...@kvack.org
Cc: Hugh Dickins
---
fs/hugetlbfs/inode.c| 5 +++--
include/linux/hugetlb.h | 4 ++--
include/linux/stat.h| 1 +
ipc/shm.c | 3 ++-
mm/memfd.c | 3 ++-
mm/mmap.c | 3 ++-
mm/shmem.c | 11 ++-
7 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 9285dd4f4b1c..512ac8a226ef 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -1363,7 +1363,8 @@ static int get_hstate_idx(int page_size_log)
*/
struct file *hugetlb_file_setup(const char *name, size_t size,
vm_flags_t acctflag, struct user_struct **user,
- int creat_flags, int page_size_log)
+ int creat_flags, int page_size_log,
+ umode_t mode)
{
struct inode *inode;
struct vfsmount *mnt;
@@ -1393,7 +1394,7 @@ struct file *hugetlb_file_setup(const char *name, size_t
size,
}
file = ERR_PTR(-ENOSPC);
- inode = hugetlbfs_get_inode(mnt->mnt_sb, NULL, S_IFREG | S_IRWXUGO, 0);
+ inode = hugetlbfs_get_inode(mnt->mnt_sb, NULL, S_IFREG | mode, 0);
if (!inode)
goto out;
if (creat_flags == HUGETLB_SHMFS_INODE)
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 11943b60f208..59486f5ea89f 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -308,7 +308,7 @@ extern const struct file_operations
hugetlbfs_file_operations;
extern const struct vm_operations_struct hugetlb_vm_ops;
struct file *hugetlb_file_setup(const char *name, size_t size, vm_flags_t acct,
struct user_struct **user, int creat_flags,
- int page_size_log);
+ int page_size_log, umode_t mode);
static inline bool is_file_hugepages(struct file *file)
{
@@ -325,7 +325,7 @@ static inline bool is_file_hugepages(struct file *file)
static inline struct file *
hugetlb_file_setup(const char *name, size_t size, vm_flags_t acctflag,
struct user_struct **user, int creat_flags,
- int page_size_log)
+ int page_size_log, umode_t mode)
{
return ERR_PTR(-ENOSYS);
}
diff --git a/include/linux/stat.h b/include/linux/stat.h
index 765573dc17d6..efda7df06d6e 100644
--- a/include/linux/stat.h
+++ b/include/linux/stat.h
@@ -11,6 +11,7 @@
#define S_IRUGO(S_IRUSR|S_IRGRP|S_IROTH)
#define S_IWUGO(S_IWUSR|S_IWGRP|S_IWOTH)
#define S_IXUGO(S_IXUSR|S_IXGRP|S_IXOTH)
+#define S_IRWUGO (S_IRUGO|S_IWUGO)
#define UTIME_NOW ((1l << 30) - 1l)
#define UTIME_OMIT ((1l << 30) - 2l)
diff --git a/ipc/shm.c b/ipc/shm.c
index ce1ca9f7c6e9..a64a52e4ccf1 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -651,7 +651,8 @@ static int newseg(struct ipc_namespace *ns, struct
ipc_params *params)
acctflag = VM_NORESERVE;
file = hugetlb_file_setup(name, hugesize, acctflag,
>mlock_user, HUGETLB_SHMFS_INODE,
- (shmflg >> SHM_HUGE_SHIFT) & SHM_HUGE_MASK);
+ (shmflg >> SHM_HUGE_SHIFT) & SHM_HUGE_MASK,
+ S_IRWXUGO);
} else {
/*
* Do not allow no accounting for OVERCOMMIT_NEVER, even
diff --git a/mm/memfd.c b/mm/memfd.c
index 650e65a46b9c..b680fae87240 100644
--- a/mm/memfd.c
+++ b/mm/memfd.c
@@ -300,7 +300,8 @@ SYSCALL_DEFINE2(memfd_create,
file = hugetlb_file_setup(name, 0, VM_NORESERVE, ,
HUGETLB_ANONHUGE_INODE,
(flags >> MFD_HUGE_SHIFT) &
- MFD_HUGE_MASK);
+ MFD_HUGE_MASK,
+ S_IRWUGO);
} else
file = shmem_file_setup(name, 0, VM_NORESERVE);
if (IS_ERR(file)) {
diff --git a/mm/mmap.c b/mm/mmap.c
index bd7b9f293b39..4494ce44ca5d 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1600,7 +1600,8 @@ unsigned long ksys_mmap_pgoff(unsigned long addr,
unsigned long len,
file = hugetlb_file_setup(HUGETLB_ANON_FILE, len,
VM_NORESERVE,
, HUGETLB_ANONHUGE_INODE,
- (flags >> MAP_HUGE_SHIFT) & MAP_HUGE_MASK);
+ (flags >> MAP_HUGE_SHIFT) & MAP_HUGE_MASK,
+ S_IRWXUGO);
if (IS_ERR(file))
Re: Grant-
I Mikhail Fridman picked you for $5,000,000 donatiion,Reply for more details IZJAVA O ODRICANJU ODGOVORNOSTI: Ova elektronicka posta moze sadrzavati povjerljive informacije i namijenjena je samo osobama na koje je naslovljena. Ukoliko Vi niste navedeni primatelj nije Vam dopusteno koristiti njen sadrzaj, kopirati ili dalje prosljedivati. Molimo Vas da ako ste greskom primili ovu elektronicku postu o tome odmah obavijestite posiljatelja i izbrisete ovu poruku. KBC Zagreb ne prihvaca nikakvu odgovornost za eventualnu stetu nastalu primitkom ove poruke i priloga sadrzanih u poruci. DISCLAIMER: This message may contain confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail-message by mistake and delete this e-mail-message from your system. KBC Zagreb ltd. accepts no liability for any potential damage caused by this message and files attached to it.
[PATCH 4.4 068/230] xen-netback: fix occasional leak of grant ref mappings under memory pressure
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Igor Druzhinin
[ Upstream commit 99e87f56b48f490fb16b6e0f74691c1e664dea95 ]
Zero-copy callback flag is not yet set on frag list skb at the moment
xenvif_handle_frag_list() returns -ENOMEM. This eventually results in
leaking grant ref mappings since xenvif_zerocopy_callback() is never
called for these fragments. Those eventually build up and cause Xen
to kill Dom0 as the slots get reused for new mappings:
"d0v0 Attempt to implicitly unmap a granted PTE c01329fce005"
That behavior is observed under certain workloads where sudden spikes
of page cache writes coexist with active atomic skb allocations from
network traffic. Additionally, rework the logic to deal with frag_list
deallocation in a single place.
Signed-off-by: Paul Durrant
Signed-off-by: Igor Druzhinin
Acked-by: Wei Liu
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/xen-netback/netback.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1538,11 +1538,6 @@ static int xenvif_handle_frag_list(struc
skb_frag_size_set([i], len);
}
- /* Copied all the bits from the frag list -- free it. */
- skb_frag_list_init(skb);
- xenvif_skb_zerocopy_prepare(queue, nskb);
- kfree_skb(nskb);
-
/* Release all the original (foreign) frags. */
for (f = 0; f < skb_shinfo(skb)->nr_frags; f++)
skb_frag_unref(skb, f);
@@ -1611,6 +1606,8 @@ static int xenvif_tx_submit(struct xenvi
xenvif_fill_frags(queue, skb);
if (unlikely(skb_has_frag_list(skb))) {
+ struct sk_buff *nskb = skb_shinfo(skb)->frag_list;
+ xenvif_skb_zerocopy_prepare(queue, nskb);
if (xenvif_handle_frag_list(queue, skb)) {
if (net_ratelimit())
netdev_err(queue->vif->dev,
@@ -1619,6 +1616,9 @@ static int xenvif_tx_submit(struct xenvi
kfree_skb(skb);
continue;
}
+ /* Copied all the bits from the frag list -- free it. */
+ skb_frag_list_init(skb);
+ kfree_skb(nskb);
}
skb->dev = queue->vif->dev;
[PATCH 4.9 22/96] xen-netback: fix occasional leak of grant ref mappings under memory pressure
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Igor Druzhinin
[ Upstream commit 99e87f56b48f490fb16b6e0f74691c1e664dea95 ]
Zero-copy callback flag is not yet set on frag list skb at the moment
xenvif_handle_frag_list() returns -ENOMEM. This eventually results in
leaking grant ref mappings since xenvif_zerocopy_callback() is never
called for these fragments. Those eventually build up and cause Xen
to kill Dom0 as the slots get reused for new mappings:
"d0v0 Attempt to implicitly unmap a granted PTE c01329fce005"
That behavior is observed under certain workloads where sudden spikes
of page cache writes coexist with active atomic skb allocations from
network traffic. Additionally, rework the logic to deal with frag_list
deallocation in a single place.
Signed-off-by: Paul Durrant
Signed-off-by: Igor Druzhinin
Acked-by: Wei Liu
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/xen-netback/netback.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1074,11 +1074,6 @@ static int xenvif_handle_frag_list(struc
skb_frag_size_set([i], len);
}
- /* Copied all the bits from the frag list -- free it. */
- skb_frag_list_init(skb);
- xenvif_skb_zerocopy_prepare(queue, nskb);
- kfree_skb(nskb);
-
/* Release all the original (foreign) frags. */
for (f = 0; f < skb_shinfo(skb)->nr_frags; f++)
skb_frag_unref(skb, f);
@@ -1147,6 +1142,8 @@ static int xenvif_tx_submit(struct xenvi
xenvif_fill_frags(queue, skb);
if (unlikely(skb_has_frag_list(skb))) {
+ struct sk_buff *nskb = skb_shinfo(skb)->frag_list;
+ xenvif_skb_zerocopy_prepare(queue, nskb);
if (xenvif_handle_frag_list(queue, skb)) {
if (net_ratelimit())
netdev_err(queue->vif->dev,
@@ -1155,6 +1152,9 @@ static int xenvif_tx_submit(struct xenvi
kfree_skb(skb);
continue;
}
+ /* Copied all the bits from the frag list -- free it. */
+ skb_frag_list_init(skb);
+ kfree_skb(nskb);
}
skb->dev = queue->vif->dev;
[PATCH 4.14 025/135] xen-netback: fix occasional leak of grant ref mappings under memory pressure
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Igor Druzhinin
[ Upstream commit 99e87f56b48f490fb16b6e0f74691c1e664dea95 ]
Zero-copy callback flag is not yet set on frag list skb at the moment
xenvif_handle_frag_list() returns -ENOMEM. This eventually results in
leaking grant ref mappings since xenvif_zerocopy_callback() is never
called for these fragments. Those eventually build up and cause Xen
to kill Dom0 as the slots get reused for new mappings:
"d0v0 Attempt to implicitly unmap a granted PTE c01329fce005"
That behavior is observed under certain workloads where sudden spikes
of page cache writes coexist with active atomic skb allocations from
network traffic. Additionally, rework the logic to deal with frag_list
deallocation in a single place.
Signed-off-by: Paul Durrant
Signed-off-by: Igor Druzhinin
Acked-by: Wei Liu
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/xen-netback/netback.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1074,11 +1074,6 @@ static int xenvif_handle_frag_list(struc
skb_frag_size_set([i], len);
}
- /* Copied all the bits from the frag list -- free it. */
- skb_frag_list_init(skb);
- xenvif_skb_zerocopy_prepare(queue, nskb);
- kfree_skb(nskb);
-
/* Release all the original (foreign) frags. */
for (f = 0; f < skb_shinfo(skb)->nr_frags; f++)
skb_frag_unref(skb, f);
@@ -1147,6 +1142,8 @@ static int xenvif_tx_submit(struct xenvi
xenvif_fill_frags(queue, skb);
if (unlikely(skb_has_frag_list(skb))) {
+ struct sk_buff *nskb = skb_shinfo(skb)->frag_list;
+ xenvif_skb_zerocopy_prepare(queue, nskb);
if (xenvif_handle_frag_list(queue, skb)) {
if (net_ratelimit())
netdev_err(queue->vif->dev,
@@ -1155,6 +1152,9 @@ static int xenvif_tx_submit(struct xenvi
kfree_skb(skb);
continue;
}
+ /* Copied all the bits from the frag list -- free it. */
+ skb_frag_list_init(skb);
+ kfree_skb(nskb);
}
skb->dev = queue->vif->dev;
Accept My Legit Grant.
Dear Friend, Greetings. I am Mrs Mavis Wanczyk the Powerball Lottery Winner of $ 758.7 Million. Click the below link to see about my winnings so that you know this is LEGITIMATE. https://edition.cnn.com/videos/us/2017/08/24/powerball-winner-massachusetts-quit-job-sot.wcvb/video/playlists/lottery-mania/ I intend to grant you a portion of my wealth as a free-will financial grant to you. Respond to sjjo...@mail.com to partake. IMPORTANT NOTE: Only mails sent to sjjo...@mail.com will be attend to. Best Regards, Mrs Mavis Wanczyk. SUPERPOP - Com muito bom humor, Luciana Gimenez discute temas polêmicos e curiosos. Clique aqui e veja o último programa. http://www.redetv.uol.com.br/superpop --- Usar papel é coisa do passado. Só imprima este e-mail caso seja imprescindível. Sendo moderno, você também ajuda a salvar o Planeta. ---
Grant Donation of €1,700,000
You were chosen to receive a Cash Grant Donation of €1,700,000 from Maria-Elisabeth Schaeffler, Respond back for more details email me at: patriciachandl...@gmail.com
[PATCH 4.20 47/76] xen-netback: fix occasional leak of grant ref mappings under memory pressure
4.20-stable review patch. If anyone has any objections, please let me know.
--
From: Igor Druzhinin
[ Upstream commit 99e87f56b48f490fb16b6e0f74691c1e664dea95 ]
Zero-copy callback flag is not yet set on frag list skb at the moment
xenvif_handle_frag_list() returns -ENOMEM. This eventually results in
leaking grant ref mappings since xenvif_zerocopy_callback() is never
called for these fragments. Those eventually build up and cause Xen
to kill Dom0 as the slots get reused for new mappings:
"d0v0 Attempt to implicitly unmap a granted PTE c01329fce005"
That behavior is observed under certain workloads where sudden spikes
of page cache writes coexist with active atomic skb allocations from
network traffic. Additionally, rework the logic to deal with frag_list
deallocation in a single place.
Signed-off-by: Paul Durrant
Signed-off-by: Igor Druzhinin
Acked-by: Wei Liu
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/xen-netback/netback.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1072,11 +1072,6 @@ static int xenvif_handle_frag_list(struc
skb_frag_size_set([i], len);
}
- /* Copied all the bits from the frag list -- free it. */
- skb_frag_list_init(skb);
- xenvif_skb_zerocopy_prepare(queue, nskb);
- kfree_skb(nskb);
-
/* Release all the original (foreign) frags. */
for (f = 0; f < skb_shinfo(skb)->nr_frags; f++)
skb_frag_unref(skb, f);
@@ -1145,6 +1140,8 @@ static int xenvif_tx_submit(struct xenvi
xenvif_fill_frags(queue, skb);
if (unlikely(skb_has_frag_list(skb))) {
+ struct sk_buff *nskb = skb_shinfo(skb)->frag_list;
+ xenvif_skb_zerocopy_prepare(queue, nskb);
if (xenvif_handle_frag_list(queue, skb)) {
if (net_ratelimit())
netdev_err(queue->vif->dev,
@@ -1153,6 +1150,9 @@ static int xenvif_tx_submit(struct xenvi
kfree_skb(skb);
continue;
}
+ /* Copied all the bits from the frag list -- free it. */
+ skb_frag_list_init(skb);
+ kfree_skb(nskb);
}
skb->dev = queue->vif->dev;
[PATCH 4.19 40/68] xen-netback: fix occasional leak of grant ref mappings under memory pressure
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Igor Druzhinin
[ Upstream commit 99e87f56b48f490fb16b6e0f74691c1e664dea95 ]
Zero-copy callback flag is not yet set on frag list skb at the moment
xenvif_handle_frag_list() returns -ENOMEM. This eventually results in
leaking grant ref mappings since xenvif_zerocopy_callback() is never
called for these fragments. Those eventually build up and cause Xen
to kill Dom0 as the slots get reused for new mappings:
"d0v0 Attempt to implicitly unmap a granted PTE c01329fce005"
That behavior is observed under certain workloads where sudden spikes
of page cache writes coexist with active atomic skb allocations from
network traffic. Additionally, rework the logic to deal with frag_list
deallocation in a single place.
Signed-off-by: Paul Durrant
Signed-off-by: Igor Druzhinin
Acked-by: Wei Liu
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/xen-netback/netback.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1072,11 +1072,6 @@ static int xenvif_handle_frag_list(struc
skb_frag_size_set([i], len);
}
- /* Copied all the bits from the frag list -- free it. */
- skb_frag_list_init(skb);
- xenvif_skb_zerocopy_prepare(queue, nskb);
- kfree_skb(nskb);
-
/* Release all the original (foreign) frags. */
for (f = 0; f < skb_shinfo(skb)->nr_frags; f++)
skb_frag_unref(skb, f);
@@ -1145,6 +1140,8 @@ static int xenvif_tx_submit(struct xenvi
xenvif_fill_frags(queue, skb);
if (unlikely(skb_has_frag_list(skb))) {
+ struct sk_buff *nskb = skb_shinfo(skb)->frag_list;
+ xenvif_skb_zerocopy_prepare(queue, nskb);
if (xenvif_handle_frag_list(queue, skb)) {
if (net_ratelimit())
netdev_err(queue->vif->dev,
@@ -1153,6 +1150,9 @@ static int xenvif_tx_submit(struct xenvi
kfree_skb(skb);
continue;
}
+ /* Copied all the bits from the frag list -- free it. */
+ skb_frag_list_init(skb);
+ kfree_skb(nskb);
}
skb->dev = queue->vif->dev;
Re: [PATCH v2] xen-netback: fix occasional leak of grant ref mappings under memory pressure
From: Igor Druzhinin Date: Thu, 28 Feb 2019 12:48:03 + > Zero-copy callback flag is not yet set on frag list skb at the moment > xenvif_handle_frag_list() returns -ENOMEM. This eventually results in > leaking grant ref mappings since xenvif_zerocopy_callback() is never > called for these fragments. Those eventually build up and cause Xen > to kill Dom0 as the slots get reused for new mappings: > > "d0v0 Attempt to implicitly unmap a granted PTE c01329fce005" > > That behavior is observed under certain workloads where sudden spikes > of page cache writes coexist with active atomic skb allocations from > network traffic. Additionally, rework the logic to deal with frag_list > deallocation in a single place. > > Signed-off-by: Paul Durrant > Signed-off-by: Igor Druzhinin Applied and queued up for -stable, thanks.
Re: [PATCH v2] xen-netback: fix occasional leak of grant ref mappings under memory pressure
On Thu, Feb 28, 2019 at 12:48:03PM +, Igor Druzhinin wrote:
> Zero-copy callback flag is not yet set on frag list skb at the moment
> xenvif_handle_frag_list() returns -ENOMEM. This eventually results in
> leaking grant ref mappings since xenvif_zerocopy_callback() is never
> called for these fragments. Those eventually build up and cause Xen
> to kill Dom0 as the slots get reused for new mappings:
>
> "d0v0 Attempt to implicitly unmap a granted PTE c01329fce005"
>
> That behavior is observed under certain workloads where sudden spikes
> of page cache writes coexist with active atomic skb allocations from
> network traffic. Additionally, rework the logic to deal with frag_list
> deallocation in a single place.
>
> Signed-off-by: Paul Durrant
> Signed-off-by: Igor Druzhinin
Acked-by: Wei Liu
> ---
> drivers/net/xen-netback/netback.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/xen-netback/netback.c
> b/drivers/net/xen-netback/netback.c
> index 80aae3a..f09948b 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -1072,11 +1072,6 @@ static int xenvif_handle_frag_list(struct xenvif_queue
> *queue, struct sk_buff *s
> skb_frag_size_set([i], len);
> }
>
> - /* Copied all the bits from the frag list -- free it. */
> - skb_frag_list_init(skb);
> - xenvif_skb_zerocopy_prepare(queue, nskb);
> - kfree_skb(nskb);
> -
> /* Release all the original (foreign) frags. */
> for (f = 0; f < skb_shinfo(skb)->nr_frags; f++)
> skb_frag_unref(skb, f);
> @@ -1145,6 +1140,8 @@ static int xenvif_tx_submit(struct xenvif_queue *queue)
> xenvif_fill_frags(queue, skb);
>
> if (unlikely(skb_has_frag_list(skb))) {
> + struct sk_buff *nskb = skb_shinfo(skb)->frag_list;
> + xenvif_skb_zerocopy_prepare(queue, nskb);
> if (xenvif_handle_frag_list(queue, skb)) {
> if (net_ratelimit())
> netdev_err(queue->vif->dev,
> @@ -1153,6 +1150,9 @@ static int xenvif_tx_submit(struct xenvif_queue *queue)
> kfree_skb(skb);
> continue;
> }
> + /* Copied all the bits from the frag list -- free it. */
> + skb_frag_list_init(skb);
> + kfree_skb(nskb);
> }
>
> skb->dev = queue->vif->dev;
> --
> 2.7.4
>
[PATCH v2] xen-netback: fix occasional leak of grant ref mappings under memory pressure
Zero-copy callback flag is not yet set on frag list skb at the moment
xenvif_handle_frag_list() returns -ENOMEM. This eventually results in
leaking grant ref mappings since xenvif_zerocopy_callback() is never
called for these fragments. Those eventually build up and cause Xen
to kill Dom0 as the slots get reused for new mappings:
"d0v0 Attempt to implicitly unmap a granted PTE c01329fce005"
That behavior is observed under certain workloads where sudden spikes
of page cache writes coexist with active atomic skb allocations from
network traffic. Additionally, rework the logic to deal with frag_list
deallocation in a single place.
Signed-off-by: Paul Durrant
Signed-off-by: Igor Druzhinin
---
drivers/net/xen-netback/netback.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/xen-netback/netback.c
b/drivers/net/xen-netback/netback.c
index 80aae3a..f09948b 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1072,11 +1072,6 @@ static int xenvif_handle_frag_list(struct xenvif_queue
*queue, struct sk_buff *s
skb_frag_size_set([i], len);
}
- /* Copied all the bits from the frag list -- free it. */
- skb_frag_list_init(skb);
- xenvif_skb_zerocopy_prepare(queue, nskb);
- kfree_skb(nskb);
-
/* Release all the original (foreign) frags. */
for (f = 0; f < skb_shinfo(skb)->nr_frags; f++)
skb_frag_unref(skb, f);
@@ -1145,6 +1140,8 @@ static int xenvif_tx_submit(struct xenvif_queue *queue)
xenvif_fill_frags(queue, skb);
if (unlikely(skb_has_frag_list(skb))) {
+ struct sk_buff *nskb = skb_shinfo(skb)->frag_list;
+ xenvif_skb_zerocopy_prepare(queue, nskb);
if (xenvif_handle_frag_list(queue, skb)) {
if (net_ratelimit())
netdev_err(queue->vif->dev,
@@ -1153,6 +1150,9 @@ static int xenvif_tx_submit(struct xenvif_queue *queue)
kfree_skb(skb);
continue;
}
+ /* Copied all the bits from the frag list -- free it. */
+ skb_frag_list_init(skb);
+ kfree_skb(nskb);
}
skb->dev = queue->vif->dev;
--
2.7.4
Re: [PATCH] xen-netback: fix occasional leak of grant ref mappings under memory pressure
On Thu, Feb 28, 2019 at 12:07:07PM +, Paul Durrant wrote: > Yes, I meant kfree_skb(nskb). > In that case I think your patch looks fine. Wei.
RE: [PATCH] xen-netback: fix occasional leak of grant ref mappings under memory pressure
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
> Paul Durrant
> Sent: 28 February 2019 11:22
> To: Wei Liu
> Cc: Igor Druzhinin ; Wei Liu
> ; net...@vger.kernel.org;
> linux-kernel@vger.kernel.org; xen-de...@lists.xenproject.org;
> da...@davemloft.net
> Subject: Re: [Xen-devel] [PATCH] xen-netback: fix occasional leak of grant
> ref mappings under memory
> pressure
>
> > -Original Message-
> > From: Wei Liu [mailto:wei.l...@citrix.com]
> > Sent: 28 February 2019 11:02
> > To: Paul Durrant
> > Cc: Igor Druzhinin ;
> > xen-de...@lists.xenproject.org;
> > net...@vger.kernel.org; linux-kernel@vger.kernel.org; Wei Liu
> > ;
> > da...@davemloft.net
> > Subject: Re: [PATCH] xen-netback: fix occasional leak of grant ref mappings
> > under memory pressure
> >
> > On Thu, Feb 28, 2019 at 09:46:57AM +, Paul Durrant wrote:
> > > > -Original Message-
> > > > From: Igor Druzhinin [mailto:igor.druzhi...@citrix.com]
> > > > Sent: 28 February 2019 02:03
> > > > To: xen-de...@lists.xenproject.org; net...@vger.kernel.org;
> > > > linux-kernel@vger.kernel.org
> > > > Cc: Wei Liu ; Paul Durrant
> > > > ; da...@davemloft.net;
> > Igor
> > > > Druzhinin
> > > > Subject: [PATCH] xen-netback: fix occasional leak of grant ref mappings
> > > > under memory pressure
> > > >
> > > > Zero-copy callback flag is not yet set on frag list skb at the moment
> > > > xenvif_handle_frag_list() returns -ENOMEM. This eventually results in
> > > > leaking grant ref mappings since xenvif_zerocopy_callback() is never
> > > > called for these fragments. Those eventually build up and cause Xen
> > > > to kill Dom0 as the slots get reused for new mappings.
> > > >
> > > > That behavior is observed under certain workloads where sudden spikes
> > > > of page cache usage for writes coexist with active atomic skb
> > > > allocations.
> > > >
> > > > Signed-off-by: Igor Druzhinin
> > > > ---
> > > > drivers/net/xen-netback/netback.c | 3 +++
> > > > 1 file changed, 3 insertions(+)
> > > >
> > > > diff --git a/drivers/net/xen-netback/netback.c
> > > > b/drivers/net/xen-netback/netback.c
> > > > index 80aae3a..2023317 100644
> > > > --- a/drivers/net/xen-netback/netback.c
> > > > +++ b/drivers/net/xen-netback/netback.c
> > > > @@ -1146,9 +1146,12 @@ static int xenvif_tx_submit(struct xenvif_queue
> > > > *queue)
> > > >
> > > > if (unlikely(skb_has_frag_list(skb))) {
> > > > if (xenvif_handle_frag_list(queue, skb)) {
> > > > + struct sk_buff *nskb =
> > > > +
> > > > skb_shinfo(skb)->frag_list;
> > > > if (net_ratelimit())
> > > > netdev_err(queue->vif->dev,
> > > >"Not enough memory
> > > > to consolidate frag_list!\n");
> > > > + xenvif_skb_zerocopy_prepare(queue,
> > > > nskb);
> > > > xenvif_skb_zerocopy_prepare(queue, skb);
> > > > kfree_skb(skb);
> > > > continue;
> > >
> > > Whilst this fix will do the job, I think it would be better to get rid of
> > > the kfree_skb() from
> > inside xenvif_handle_frag_list() and always deal with it here rather than
> > having it happen in two
> > different places. Something like the following...
> >
> > +1 for having only one place.
> >
> > >
> > > ---8<---
> > > diff --git a/drivers/net/xen-netback/netback.c
> > > b/drivers/net/xen-netback/netback.c
> > > index 80aae3a32c2a..093c7b860772 100644
> > > --- a/drivers/net/xen-netback/netback.c
> > > +++ b/drivers/net/xen-netback/netback.c
> > > @@ -1027,13 +1027,13 @@ static void xenvif_tx_build_gops(struct
> > > xenvif_queue *queue,
> > > /* Consolidate skb with a frag_list into a brand new one with local
> > > pages on
> > > * frags. Returns 0 or -ENOMEM if can't allocate new pages.
> > >
RE: [PATCH] xen-netback: fix occasional leak of grant ref mappings under memory pressure
> -Original Message- > From: Igor Druzhinin [mailto:igor.druzhi...@citrix.com] > Sent: 28 February 2019 11:44 > To: Paul Durrant ; Wei Liu > Cc: xen-de...@lists.xenproject.org; net...@vger.kernel.org; > linux-kernel@vger.kernel.org; > da...@davemloft.net > Subject: Re: [PATCH] xen-netback: fix occasional leak of grant ref mappings > under memory pressure > > On 28/02/2019 11:21, Paul Durrant wrote: > >>> @@ -1153,6 +1152,10 @@ static int xenvif_tx_submit(struct xenvif_queue > >>> *queue) > >>> kfree_skb(skb); > >>> continue; > >>> } > >>> + > >>> + /* Copied all the bits from the frag list. */ > >>> + skb_frag_list_init(skb); > >>> + kfree(nskb); > >> > >> I think you want kfree_skb here? > > > > No. nskb is the frag list... it is unlinked from skb by the call to > > skb_frag_list_init() and then it > can be freed on its own. The skb is what we need to retain, because that now > contains all the data. > > > > Are you saying previous code in xenvif_handle_frag_list() incorrectly > called kfree_skb()? No, it correctly called kfree_skb() on nskb in the success case. What Wei and myself would prefer is that we have a single place that the frag list is freed in both the success and error cases. Paul > > Igor
Re: [PATCH] xen-netback: fix occasional leak of grant ref mappings under memory pressure
On 28/02/2019 11:21, Paul Durrant wrote: >>> @@ -1153,6 +1152,10 @@ static int xenvif_tx_submit(struct xenvif_queue >>> *queue) >>> kfree_skb(skb); >>> continue; >>> } >>> + >>> + /* Copied all the bits from the frag list. */ >>> + skb_frag_list_init(skb); >>> + kfree(nskb); >> >> I think you want kfree_skb here? > > No. nskb is the frag list... it is unlinked from skb by the call to > skb_frag_list_init() and then it can be freed on its own. The skb is what we > need to retain, because that now contains all the data. > Are you saying previous code in xenvif_handle_frag_list() incorrectly called kfree_skb()? Igor
RE: [PATCH] xen-netback: fix occasional leak of grant ref mappings under memory pressure
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 28 February 2019 11:02
> To: Paul Durrant
> Cc: Igor Druzhinin ;
> xen-de...@lists.xenproject.org;
> net...@vger.kernel.org; linux-kernel@vger.kernel.org; Wei Liu
> ;
> da...@davemloft.net
> Subject: Re: [PATCH] xen-netback: fix occasional leak of grant ref mappings
> under memory pressure
>
> On Thu, Feb 28, 2019 at 09:46:57AM +, Paul Durrant wrote:
> > > -Original Message-
> > > From: Igor Druzhinin [mailto:igor.druzhi...@citrix.com]
> > > Sent: 28 February 2019 02:03
> > > To: xen-de...@lists.xenproject.org; net...@vger.kernel.org;
> > > linux-kernel@vger.kernel.org
> > > Cc: Wei Liu ; Paul Durrant
> > > ; da...@davemloft.net;
> Igor
> > > Druzhinin
> > > Subject: [PATCH] xen-netback: fix occasional leak of grant ref mappings
> > > under memory pressure
> > >
> > > Zero-copy callback flag is not yet set on frag list skb at the moment
> > > xenvif_handle_frag_list() returns -ENOMEM. This eventually results in
> > > leaking grant ref mappings since xenvif_zerocopy_callback() is never
> > > called for these fragments. Those eventually build up and cause Xen
> > > to kill Dom0 as the slots get reused for new mappings.
> > >
> > > That behavior is observed under certain workloads where sudden spikes
> > > of page cache usage for writes coexist with active atomic skb allocations.
> > >
> > > Signed-off-by: Igor Druzhinin
> > > ---
> > > drivers/net/xen-netback/netback.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/drivers/net/xen-netback/netback.c
> > > b/drivers/net/xen-netback/netback.c
> > > index 80aae3a..2023317 100644
> > > --- a/drivers/net/xen-netback/netback.c
> > > +++ b/drivers/net/xen-netback/netback.c
> > > @@ -1146,9 +1146,12 @@ static int xenvif_tx_submit(struct xenvif_queue
> > > *queue)
> > >
> > > if (unlikely(skb_has_frag_list(skb))) {
> > > if (xenvif_handle_frag_list(queue, skb)) {
> > > + struct sk_buff *nskb =
> > > + skb_shinfo(skb)->frag_list;
> > > if (net_ratelimit())
> > > netdev_err(queue->vif->dev,
> > > "Not enough memory to
> > > consolidate frag_list!\n");
> > > + xenvif_skb_zerocopy_prepare(queue, nskb);
> > > xenvif_skb_zerocopy_prepare(queue, skb);
> > > kfree_skb(skb);
> > > continue;
> >
> > Whilst this fix will do the job, I think it would be better to get rid of
> > the kfree_skb() from
> inside xenvif_handle_frag_list() and always deal with it here rather than
> having it happen in two
> different places. Something like the following...
>
> +1 for having only one place.
>
> >
> > ---8<---
> > diff --git a/drivers/net/xen-netback/netback.c
> > b/drivers/net/xen-netback/netback.c
> > index 80aae3a32c2a..093c7b860772 100644
> > --- a/drivers/net/xen-netback/netback.c
> > +++ b/drivers/net/xen-netback/netback.c
> > @@ -1027,13 +1027,13 @@ static void xenvif_tx_build_gops(struct
> > xenvif_queue *queue,
> > /* Consolidate skb with a frag_list into a brand new one with local pages
> > on
> > * frags. Returns 0 or -ENOMEM if can't allocate new pages.
> > */
> > -static int xenvif_handle_frag_list(struct xenvif_queue *queue, struct
> > sk_buff *skb)
> > +static int xenvif_handle_frag_list(struct xenvif_queue *queue, struct
> > sk_buff *diff --git
> a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> > index 80aae3a32c2a..093c7b860772 100644
> > --- a/drivers/net/xen-netback/netback.c
> > +++ b/drivers/net/xen-netback/netback.c
> > @@ -1027,13 +1027,13 @@ static void xenvif_tx_build_gops(struct
> > xenvif_queue *qu
> > eue,
> > /* Consolidate skb with a frag_list into a brand new one with local pages
> > on
> > * frags. Returns 0 or -ENOMEM if can't allocate new pages.
> > */
> > -static int xenvif_handle_frag_list(struct xenvif_queue *queue, struct
> > sk_buff *
> > skb)
> > +static int xenvif_handle_frag_list(struct xenvif_queue *queue, struct
> > sk_buff *
> > skb,
> > +
Re: [PATCH] xen-netback: fix occasional leak of grant ref mappings under memory pressure
On Thu, Feb 28, 2019 at 09:46:57AM +, Paul Durrant wrote:
> > -Original Message-
> > From: Igor Druzhinin [mailto:igor.druzhi...@citrix.com]
> > Sent: 28 February 2019 02:03
> > To: xen-de...@lists.xenproject.org; net...@vger.kernel.org;
> > linux-kernel@vger.kernel.org
> > Cc: Wei Liu ; Paul Durrant ;
> > da...@davemloft.net; Igor
> > Druzhinin
> > Subject: [PATCH] xen-netback: fix occasional leak of grant ref mappings
> > under memory pressure
> >
> > Zero-copy callback flag is not yet set on frag list skb at the moment
> > xenvif_handle_frag_list() returns -ENOMEM. This eventually results in
> > leaking grant ref mappings since xenvif_zerocopy_callback() is never
> > called for these fragments. Those eventually build up and cause Xen
> > to kill Dom0 as the slots get reused for new mappings.
> >
> > That behavior is observed under certain workloads where sudden spikes
> > of page cache usage for writes coexist with active atomic skb allocations.
> >
> > Signed-off-by: Igor Druzhinin
> > ---
> > drivers/net/xen-netback/netback.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/net/xen-netback/netback.c
> > b/drivers/net/xen-netback/netback.c
> > index 80aae3a..2023317 100644
> > --- a/drivers/net/xen-netback/netback.c
> > +++ b/drivers/net/xen-netback/netback.c
> > @@ -1146,9 +1146,12 @@ static int xenvif_tx_submit(struct xenvif_queue
> > *queue)
> >
> > if (unlikely(skb_has_frag_list(skb))) {
> > if (xenvif_handle_frag_list(queue, skb)) {
> > + struct sk_buff *nskb =
> > + skb_shinfo(skb)->frag_list;
> > if (net_ratelimit())
> > netdev_err(queue->vif->dev,
> >"Not enough memory to
> > consolidate frag_list!\n");
> > + xenvif_skb_zerocopy_prepare(queue, nskb);
> > xenvif_skb_zerocopy_prepare(queue, skb);
> > kfree_skb(skb);
> > continue;
>
> Whilst this fix will do the job, I think it would be better to get rid of the
> kfree_skb() from inside xenvif_handle_frag_list() and always deal with it
> here rather than having it happen in two different places. Something like the
> following...
+1 for having only one place.
>
> ---8<---
> diff --git a/drivers/net/xen-netback/netback.c
> b/drivers/net/xen-netback/netback.c
> index 80aae3a32c2a..093c7b860772 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -1027,13 +1027,13 @@ static void xenvif_tx_build_gops(struct xenvif_queue
> *queue,
> /* Consolidate skb with a frag_list into a brand new one with local pages on
> * frags. Returns 0 or -ENOMEM if can't allocate new pages.
> */
> -static int xenvif_handle_frag_list(struct xenvif_queue *queue, struct
> sk_buff *skb)
> +static int xenvif_handle_frag_list(struct xenvif_queue *queue, struct
> sk_buff *diff --git a/drivers/net/xen-netback/netback.c
> b/drivers/net/xen-netback/netback.c
> index 80aae3a32c2a..093c7b860772 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -1027,13 +1027,13 @@ static void xenvif_tx_build_gops(struct xenvif_queue
> *qu
> eue,
> /* Consolidate skb with a frag_list into a brand new one with local pages on
> * frags. Returns 0 or -ENOMEM if can't allocate new pages.
> */
> -static int xenvif_handle_frag_list(struct xenvif_queue *queue, struct
> sk_buff *
> skb)
> +static int xenvif_handle_frag_list(struct xenvif_queue *queue, struct
> sk_buff *
> skb,
> + struct sk_buff *nskb)
> {
> unsigned int offset = skb_headlen(skb);
> skb_frag_t frags[MAX_SKB_FRAGS];
> int i, f;
> struct ubuf_info *uarg;
> - struct sk_buff *nskb = skb_shinfo(skb)->frag_list;
>
> queue->stats.tx_zerocopy_sent += 2;
> queue->stats.tx_frag_overflow++;
> @@ -1072,11 +1072,6 @@ static int xenvif_handle_frag_list(struct xenvif_queue
> *q
> ueue, struct sk_buff *s
> skb_frag_size_set([i], len);
> }
>
> - /* Copied all the bits from the frag list -- free it. */
> - skb_frag_list_init(skb);
> - xenvif_skb_zerocopy_prepare(queue, nskb);
> - kfree_skb(nskb);
> -
> /* Release all the original (foreign) frags. */
> for (f =
Re: [Xen-devel] [PATCH] xen-netback: fix occasional leak of grant ref mappings under memory pressure
On 28/02/2019 02:03, Igor Druzhinin wrote: > Zero-copy callback flag is not yet set on frag list skb at the moment > xenvif_handle_frag_list() returns -ENOMEM. This eventually results in > leaking grant ref mappings since xenvif_zerocopy_callback() is never > called for these fragments. Those eventually build up and cause Xen > to kill Dom0 as the slots get reused for new mappings. Its worth pointing out what (debug) Xen notices is dom0 performing implicit grant unmap. ~Andrew
RE: [PATCH] xen-netback: fix occasional leak of grant ref mappings under memory pressure
> -Original Message-
> From: Igor Druzhinin [mailto:igor.druzhi...@citrix.com]
> Sent: 28 February 2019 02:03
> To: xen-de...@lists.xenproject.org; net...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Cc: Wei Liu ; Paul Durrant ;
> da...@davemloft.net; Igor
> Druzhinin
> Subject: [PATCH] xen-netback: fix occasional leak of grant ref mappings under
> memory pressure
>
> Zero-copy callback flag is not yet set on frag list skb at the moment
> xenvif_handle_frag_list() returns -ENOMEM. This eventually results in
> leaking grant ref mappings since xenvif_zerocopy_callback() is never
> called for these fragments. Those eventually build up and cause Xen
> to kill Dom0 as the slots get reused for new mappings.
>
> That behavior is observed under certain workloads where sudden spikes
> of page cache usage for writes coexist with active atomic skb allocations.
>
> Signed-off-by: Igor Druzhinin
> ---
> drivers/net/xen-netback/netback.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/xen-netback/netback.c
> b/drivers/net/xen-netback/netback.c
> index 80aae3a..2023317 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -1146,9 +1146,12 @@ static int xenvif_tx_submit(struct xenvif_queue *queue)
>
> if (unlikely(skb_has_frag_list(skb))) {
> if (xenvif_handle_frag_list(queue, skb)) {
> + struct sk_buff *nskb =
> + skb_shinfo(skb)->frag_list;
> if (net_ratelimit())
> netdev_err(queue->vif->dev,
> "Not enough memory to
> consolidate frag_list!\n");
> + xenvif_skb_zerocopy_prepare(queue, nskb);
> xenvif_skb_zerocopy_prepare(queue, skb);
> kfree_skb(skb);
> continue;
Whilst this fix will do the job, I think it would be better to get rid of the
kfree_skb() from inside xenvif_handle_frag_list() and always deal with it here
rather than having it happen in two different places. Something like the
following...
---8<---
diff --git a/drivers/net/xen-netback/netback.c
b/drivers/net/xen-netback/netback.c
index 80aae3a32c2a..093c7b860772 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1027,13 +1027,13 @@ static void xenvif_tx_build_gops(struct xenvif_queue
*queue,
/* Consolidate skb with a frag_list into a brand new one with local pages on
* frags. Returns 0 or -ENOMEM if can't allocate new pages.
*/
-static int xenvif_handle_frag_list(struct xenvif_queue *queue, struct sk_buff
*skb)
+static int xenvif_handle_frag_list(struct xenvif_queue *queue, struct sk_buff
*diff --git a/drivers/net/xen-netback/netback.c
b/drivers/net/xen-netback/netback.c
index 80aae3a32c2a..093c7b860772 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1027,13 +1027,13 @@ static void xenvif_tx_build_gops(struct xenvif_queue *qu
eue,
/* Consolidate skb with a frag_list into a brand new one with local pages on
* frags. Returns 0 or -ENOMEM if can't allocate new pages.
*/
-static int xenvif_handle_frag_list(struct xenvif_queue *queue, struct sk_buff *
skb)
+static int xenvif_handle_frag_list(struct xenvif_queue *queue, struct sk_buff *
skb,
+ struct sk_buff *nskb)
{
unsigned int offset = skb_headlen(skb);
skb_frag_t frags[MAX_SKB_FRAGS];
int i, f;
struct ubuf_info *uarg;
- struct sk_buff *nskb = skb_shinfo(skb)->frag_list;
queue->stats.tx_zerocopy_sent += 2;
queue->stats.tx_frag_overflow++;
@@ -1072,11 +1072,6 @@ static int xenvif_handle_frag_list(struct xenvif_queue *q
ueue, struct sk_buff *s
skb_frag_size_set([i], len);
}
- /* Copied all the bits from the frag list -- free it. */
- skb_frag_list_init(skb);
- xenvif_skb_zerocopy_prepare(queue, nskb);
- kfree_skb(nskb);
-
/* Release all the original (foreign) frags. */
for (f = 0; f < skb_shinfo(skb)->nr_frags; f++)
skb_frag_unref(skb, f);
@@ -1145,7 +1140,11 @@ static int xenvif_tx_submit(struct xenvif_queue *queue)
xenvif_fill_frags(queue, skb);
if (unlikely(skb_has_frag_list(skb))) {
- if (xenvif_handle_frag_list(queue, skb)) {
+ struct sk_buff *nskb = skb_shinfo(skb)->frag_list;
+
+ xenvif_skb_zerocopy_prepare(queue, nskb);
+
+ if (xenvif_handle_frag_list(queue, skb, nskb)) {
if (net_ratelim
[PATCH] xen-netback: fix occasional leak of grant ref mappings under memory pressure
Zero-copy callback flag is not yet set on frag list skb at the moment
xenvif_handle_frag_list() returns -ENOMEM. This eventually results in
leaking grant ref mappings since xenvif_zerocopy_callback() is never
called for these fragments. Those eventually build up and cause Xen
to kill Dom0 as the slots get reused for new mappings.
That behavior is observed under certain workloads where sudden spikes
of page cache usage for writes coexist with active atomic skb allocations.
Signed-off-by: Igor Druzhinin
---
drivers/net/xen-netback/netback.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/xen-netback/netback.c
b/drivers/net/xen-netback/netback.c
index 80aae3a..2023317 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1146,9 +1146,12 @@ static int xenvif_tx_submit(struct xenvif_queue *queue)
if (unlikely(skb_has_frag_list(skb))) {
if (xenvif_handle_frag_list(queue, skb)) {
+ struct sk_buff *nskb =
+ skb_shinfo(skb)->frag_list;
if (net_ratelimit())
netdev_err(queue->vif->dev,
"Not enough memory to
consolidate frag_list!\n");
+ xenvif_skb_zerocopy_prepare(queue, nskb);
xenvif_skb_zerocopy_prepare(queue, skb);
kfree_skb(skb);
continue;
--
2.7.4
[PATCH RFC 25/39] KVM: x86/xen: grant map support
From: Ankur Arora
Introduce support for mapping grant references. The sequence of events
to map a grant is:
rframe = read_shared_entry(guest_grant_table, grant-ref);
rpfn = get_user_pages_remote(remote_mm, rframe);
mark_shared_entry(guest_grant_table, grant-ref,
GTF_reading | GTF_writing);
To correctly handle grant unmaps for mapped grants, we save the mapping
parameters in maptrack. Also, grant map (and unmap) can be called from
non-sleeping contexts, so we call get_user_pages_remote() in
non-blocking mode and ask the user to retry.
Also note that this code is not compliant with Xen's grant map/unmap
ABI. In particular, we do not support multiple simultaneous mappings of
a grant-reference. Later versions will support that.
Co-developed-by: Joao Martins
Signed-off-by: Ankur Arora
Signed-off-by: Joao Martins
---
arch/x86/kvm/xen.c | 396 +
1 file changed, 396 insertions(+)
diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c
index 645cd22ab4e7..3603645086a7 100644
--- a/arch/x86/kvm/xen.c
+++ b/arch/x86/kvm/xen.c
@@ -9,6 +9,7 @@
#include "xen.h"
#include "ioapic.h"
+#include
#include
#include
#include
@@ -29,9 +30,11 @@
/* Grant v1 references per 4K page */
#define GPP_V1 (PAGE_SIZE / sizeof(struct grant_entry_v1))
+#define shared_entry(gt, ref) (&((gt)[(ref) / GPP_V1][(ref) % GPP_V1]))
/* Grant mappings per 4K page */
#define MPP(PAGE_SIZE / sizeof(struct kvm_grant_map))
+#define maptrack_entry(mt, hdl)(&((mt)[(hdl) / MPP][(hdl) % MPP]))
struct evtchnfd {
struct eventfd_ctx *ctx;
@@ -81,6 +84,18 @@ static int kvm_xen_domid_init(struct kvm *kvm, bool any,
domid_t domid)
return 0;
}
+static struct kvm *kvm_xen_find_vm(domid_t domid)
+{
+ unsigned long flags;
+ struct kvm *vm;
+
+ read_lock_irqsave(_lock, flags);
+ vm = idr_find(_to_kvm, domid);
+ read_unlock_irqrestore(_lock, flags);
+
+ return vm;
+}
+
int kvm_xen_free_domid(struct kvm *kvm)
{
struct kvm_xen *xen = >arch.xen;
@@ -1153,7 +1168,20 @@ int kvm_xen_gnttab_init(struct kvm *kvm, struct kvm_xen
*xen,
gnttab->frames = addr;
gnttab->frames[0] = xen->gnttab.initial;
gnttab->max_nr_frames = max_frames;
+
+ addr = kcalloc(max_mt_frames, sizeof(addr), GFP_KERNEL);
+ if (!addr)
+ goto out;
+
+ /* Needs to be aligned at 16b boundary. */
+ gnttab->handle = addr;
gnttab->max_mt_frames = max_mt_frames;
+
+ addr = (void *) get_zeroed_page(GFP_KERNEL);
+ if (!addr)
+ goto out;
+ gnttab->handle[0] = addr;
+
gnttab->nr_mt_frames = 1;
gnttab->nr_frames = 0;
@@ -1162,6 +1190,7 @@ int kvm_xen_gnttab_init(struct kvm *kvm, struct kvm_xen
*xen,
return 0;
out:
+ kfree(xen->gnttab.handle);
kfree(xen->gnttab.frames);
kfree(xen->gnttab.frames_addr);
if (page)
@@ -1170,11 +1199,38 @@ int kvm_xen_gnttab_init(struct kvm *kvm, struct kvm_xen
*xen,
return -ENOMEM;
}
+static void kvm_xen_maptrack_free(struct kvm_xen *xen)
+{
+ u32 max_entries = xen->gnttab.nr_mt_frames * MPP;
+ struct kvm_grant_map *map;
+ int ref, inuse = 0;
+
+ for (ref = 0; ref < max_entries; ref++) {
+ map = maptrack_entry(xen->gnttab.handle, ref);
+
+ if (test_and_clear_bit(_KVM_GNTMAP_ACTIVE,
+ (unsigned long *)>flags)) {
+ put_page(virt_to_page(map->gpa));
+ inuse++;
+ }
+ }
+
+ if (inuse)
+ pr_debug("kvm: dom%u teardown %u mappings\n",
+xen->domid, inuse);
+}
+
void kvm_xen_gnttab_free(struct kvm_xen *xen)
{
struct kvm_grant_table *gnttab = >gnttab;
int i;
+ if (xen->domid)
+ kvm_xen_maptrack_free(xen);
+
+ for (i = 0; i < gnttab->nr_mt_frames; i++)
+ free_page((unsigned long)gnttab->handle[i]);
+
for (i = 0; i < gnttab->nr_frames; i++)
put_page(virt_to_page(gnttab->frames[i]));
@@ -1313,6 +1369,343 @@ void kvm_xen_unregister_lcall(void)
}
EXPORT_SYMBOL_GPL(kvm_xen_unregister_lcall);
+static inline int gnttab_entries(struct kvm *kvm)
+{
+ struct kvm_grant_table *gnttab = >arch.xen.gnttab;
+ int n = max_t(unsigned int, gnttab->nr_frames, 1);
+
+ return n * ((n << PAGE_SHIFT) / sizeof(struct grant_entry_v1));
+}
+
+/*
+ * The first two members of a grant entry are updated as a combined pair.
+ * The following union allows that to happen in an endian-neutral fashion.
+ * Taken from Xen.
+ */
+union grant_combo {
+ uint32_t word;
+ struct {
+ uint16_t flags;
+ domid_t domid;
+
[PATCH RFC 26/39] KVM: x86/xen: grant unmap support
From: Ankur Arora
Grant unmap removes the grant from maptrack and marks it as not in use.
We maintain a one-to-one correspondence between grant table and maptrack
entries so there's no contention in allocation/free.
Co-developed-by: Joao Martins
Signed-off-by: Ankur Arora
Signed-off-by: Joao Martins
---
arch/x86/kvm/xen.c | 73 ++
1 file changed, 73 insertions(+)
diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c
index 3603645086a7..8f06924e0dfa 100644
--- a/arch/x86/kvm/xen.c
+++ b/arch/x86/kvm/xen.c
@@ -1684,6 +1684,69 @@ static int shim_hcall_gntmap(struct kvm_xen *ld,
return 0;
}
+static int shim_hcall_gntunmap(struct kvm_xen *xen,
+ struct gnttab_unmap_grant_ref *op)
+{
+ struct kvm_grant_map *map, unmap;
+ struct grant_entry_v1 **rgt;
+ struct grant_entry_v1 *shah;
+ struct kvm *rd = NULL;
+ domid_t domid;
+ u32 ref;
+
+ domid = handle_get_domid(op->handle);
+ ref = handle_get_grant(op->handle);
+
+
+ rd = kvm_xen_find_vm(domid);
+ if (unlikely(!rd)) {
+ /* We already teardown all ongoing grant maps */
+ op->status = GNTST_okay;
+ return 0;
+ }
+
+ if (unlikely(ref >= gnttab_entries(rd))) {
+ pr_err("gnttab: bad ref %u\n", ref);
+ op->status = GNTST_bad_handle;
+ return 0;
+ }
+
+ rgt = rd->arch.xen.gnttab.frames_v1;
+ map = maptrack_entry(rd->arch.xen.gnttab.handle, ref);
+
+ /*
+* The test_and_clear_bit (below) serializes ownership of this
+* grant-entry. After we clear it, there can be a grant-map on this
+* entry. So we cache the unmap entry before relinquishing ownership.
+*/
+ unmap = *map;
+
+ if (!test_and_clear_bit(_KVM_GNTMAP_ACTIVE,
+ (unsigned long *) >flags)) {
+ pr_err("gnttab: bad flags for %u (dom %u ref %u) flags %x\n",
+ op->handle, domid, ref, unmap.flags);
+ op->status = GNTST_bad_handle;
+ return 0;
+ }
+
+ /* Give up the reference taken in get_user_pages_remote(). */
+ put_page(virt_to_page(unmap.gpa));
+
+ shah = shared_entry(rgt, unmap.ref);
+
+ /*
+* We have cleared _KVM_GNTMAP_ACTIVE, so a simultaneous grant-map
+* could update the shah and we would stomp all over it but the
+* guest deserves it.
+*/
+ if (!(unmap.flags & GNTMAP_readonly))
+ clear_bit(_GTF_writing, (unsigned long *) >flags);
+ clear_bit(_GTF_reading, (unsigned long *) >flags);
+
+ op->status = GNTST_okay;
+ return 0;
+}
+
static int shim_hcall_gnttab(int op, void *p, int count)
{
int ret = -ENOSYS;
@@ -1698,6 +1761,16 @@ static int shim_hcall_gnttab(int op, void *p, int count)
ret = 0;
break;
}
+ case GNTTABOP_unmap_grant_ref: {
+ struct gnttab_unmap_grant_ref *ref = p;
+
+ for (i = 0; i < count; i++) {
+ shim_hcall_gntunmap(xen_shim, ref + i);
+ ref[i].host_addr = 0;
+ }
+ ret = 0;
+ break;
+ }
default:
pr_info("lcall-gnttab:op default=%d\n", op);
break;
--
2.11.0
[PATCH RFC 33/39] xen/grant-table: xen_shim_domain() support
With xen-shim, allocate_xenballooned_pages() only allocates a
place-holder page (pfn 0) expecting a subsequent map_grant_ref to fix
it up.
However, this means that, until the grant operation
(GNTTABOP_map_grant_ref) provides a valid page, we cannot set
PagePrivate or save any state.
This patch elides the setting of that state if xen_shim_domain(). In
addition, gnttab_map_refs() now fills in the appropriate page returned
from the grant operation.
Signed-off-by: Joao Martins
---
drivers/xen/grant-table.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 7ea6fb6a2e5d..ab05b70d98bb 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -804,7 +804,7 @@ int gnttab_alloc_pages(int nr_pages, struct page **pages)
int ret;
ret = alloc_xenballooned_pages(nr_pages, pages);
- if (ret < 0)
+ if (ret < 0 || xen_shim_domain())
return ret;
ret = gnttab_pages_set_private(nr_pages, pages);
@@ -1045,6 +1045,11 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
{
struct xen_page_foreign *foreign;
+ if (xen_shim_domain()) {
+ pages[i] = virt_to_page(map_ops[i].host_addr);
+ continue;
+ }
+
SetPageForeign(pages[i]);
foreign = xen_page_foreign(pages[i]);
foreign->domid = map_ops[i].dom;
@@ -1085,8 +1090,10 @@ int gnttab_unmap_refs(struct gnttab_unmap_grant_ref
*unmap_ops,
if (ret)
return ret;
- for (i = 0; i < count; i++)
- ClearPageForeign(pages[i]);
+ for (i = 0; i < count; i++) {
+ if (!xen_shim_domain())
+ ClearPageForeign(pages[i]);
+ }
return clear_foreign_p2m_mapping(unmap_ops, kunmap_ops, pages, count);
}
@@ -1113,7 +1120,7 @@ static void __gnttab_unmap_refs_async(struct
gntab_unmap_queue_data* item)
int pc;
for (pc = 0; pc < item->count; pc++) {
- if (page_count(item->pages[pc]) > 1) {
+ if (page_count(item->pages[pc]) > 1 && !xen_shim_domain()) {
unsigned long delay = GNTTAB_UNMAP_REFS_DELAY *
(item->age + 1);
schedule_delayed_work(>gnttab_work,
msecs_to_jiffies(delay));
--
2.11.0
[PATCH RFC 23/39] KVM: x86/xen: grant table grow support
Guests grant tables with core Xen PV devices (xenbus, console) need to
be seeded with a bunch of reserved entries at boot. However, at init,
the grant table is, from a guest perspective, empty and has no frames
backing it. That only happens once the guest does:
XENMEM_add_to_physmap(idx=N,gfn=M,space=XENMAPSPACE_grant_table)
Which will share the added page with the hypervisor.
The way we handle this then is to seed (from userspace) the initial
frame where we store special entries which reference guest PV ring
pages. These pages are in-turn mapped/unmapped in backend domains
hosting xenstored and xenconsoled.
When the guest initializes its grant tables (with the hypercall listed
above) we copy the entries from the private frame into a "mapped" gfn.
To do this, the userspace VMM handles XENMEM_add_to_physmap hypercall and
the hypervisor grows its grant table. Note that a grant table can only
grow - no shrinking is possible.
Signed-off-by: Joao Martins
---
arch/x86/include/asm/kvm_host.h | 16
arch/x86/kvm/xen.c | 90 +
include/uapi/linux/kvm.h| 5 +++
3 files changed, 111 insertions(+)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index e0cbc0899580..70bb7339ddd4 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -860,6 +860,21 @@ struct kvm_hv {
atomic_t num_mismatched_vp_indexes;
};
+struct kvm_grant_map {
+ u64 gpa;
+ union {
+ struct {
+
+#define _KVM_GNTMAP_ACTIVE (15)
+#define KVM_GNTMAP_ACTIVE (1 << _KVM_GNTMAP_ACTIVE)
+ u16 flags;
+ u16 ref;
+ u32 domid;
+ };
+ u64 fields;
+ };
+};
+
/* Xen grant table */
struct kvm_grant_table {
u32 nr_frames;
@@ -871,6 +886,7 @@ struct kvm_grant_table {
gfn_t *frames_addr;
gpa_t initial_addr;
struct grant_entry_v1 *initial;
+ struct kvm_grant_map **handle;
/* maptrack limits */
u32 max_mt_frames;
diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c
index b9e6e8f72d87..7266d27db210 100644
--- a/arch/x86/kvm/xen.c
+++ b/arch/x86/kvm/xen.c
@@ -22,6 +22,12 @@
#include "trace.h"
+/* Grant v1 references per 4K page */
+#define GPP_V1 (PAGE_SIZE / sizeof(struct grant_entry_v1))
+
+/* Grant mappings per 4K page */
+#define MPP(PAGE_SIZE / sizeof(struct kvm_grant_map))
+
struct evtchnfd {
struct eventfd_ctx *ctx;
u32 vcpu;
@@ -1158,11 +1164,92 @@ int kvm_xen_gnttab_init(struct kvm *kvm, struct kvm_xen
*xen,
void kvm_xen_gnttab_free(struct kvm_xen *xen)
{
struct kvm_grant_table *gnttab = >gnttab;
+ int i;
+
+ for (i = 0; i < gnttab->nr_frames; i++)
+ put_page(virt_to_page(gnttab->frames[i]));
kfree(gnttab->frames);
kfree(gnttab->frames_addr);
}
+int kvm_xen_gnttab_copy_initial_frame(struct kvm *kvm)
+{
+ struct kvm_grant_table *gnttab = >arch.xen.gnttab;
+ int idx = 0;
+
+ /* Only meant to copy the first gpa being populated */
+ if (!gnttab->initial_addr || !gnttab->frames[idx])
+ return -EINVAL;
+
+ memcpy(gnttab->frames[idx], gnttab->initial, PAGE_SIZE);
+ return 0;
+}
+
+int kvm_xen_maptrack_grow(struct kvm_xen *xen, u32 target)
+{
+ u32 max_entries = target * GPP_V1;
+ u32 nr_entries = xen->gnttab.nr_mt_frames * MPP;
+ int i, j, err = 0;
+ void *addr;
+
+ for (i = nr_entries, j = xen->gnttab.nr_mt_frames;
+i < max_entries; i += MPP, j++) {
+ addr = (void *) get_zeroed_page(GFP_KERNEL);
+ if (!addr) {
+ err = -ENOMEM;
+ break;
+ }
+
+ xen->gnttab.handle[j] = addr;
+ }
+
+ xen->gnttab.nr_mt_frames = j;
+ xen->gnttab.nr_frames = target;
+ return err;
+}
+
+int kvm_xen_gnttab_grow(struct kvm *kvm, struct kvm_xen_gnttab *op)
+{
+ struct kvm_xen *xen = >arch.xen;
+ struct kvm_grant_table *gnttab = >gnttab;
+ gfn_t *map = gnttab->frames_addr;
+ u64 gfn = op->grow.gfn;
+ u32 idx = op->grow.idx;
+ struct page *page;
+
+ if (idx < gnttab->nr_frames || idx >= gnttab->max_nr_frames)
+ return -EINVAL;
+
+ if (!idx && !gnttab->nr_frames &&
+ !gnttab->initial) {
+ return -EINVAL;
+ }
+
+ page = gfn_to_page(kvm, gfn);
+ if (is_error_page(page))
+ return -EINVAL;
+
+ map[idx] = gfn;
+
+ gnttab->frames[idx] = page_to_virt(page);
+ if (!idx && !gnttab->nr_frames &&
+ kvm_xen_gnttab_copy_initial_frame(kvm)) {
+ pr_err("kvm_xen: dom%u: failed
[PATCH RFC 22/39] KVM: x86/xen: grant table init
Add support for guest grant table initialization. This is mostly
scaffolding at this point: we allocate grant table state and map
it globally.
Later patches add support for seeding the grant table with reserved
entries, and setup maptrack which would be used for grant map and unmap
operations.
Signed-off-by: Joao Martins
---
arch/x86/include/asm/kvm_host.h | 19 +
arch/x86/kvm/xen.c | 88 +
arch/x86/kvm/xen.h | 1 +
include/uapi/linux/kvm.h| 13 ++
4 files changed, 121 insertions(+)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 384247fc433d..e0cbc0899580 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -860,6 +860,23 @@ struct kvm_hv {
atomic_t num_mismatched_vp_indexes;
};
+/* Xen grant table */
+struct kvm_grant_table {
+ u32 nr_frames;
+ u32 max_nr_frames;
+ union {
+ void **frames;
+ struct grant_entry_v1 **frames_v1;
+ };
+ gfn_t *frames_addr;
+ gpa_t initial_addr;
+ struct grant_entry_v1 *initial;
+
+ /* maptrack limits */
+ u32 max_mt_frames;
+ u32 nr_mt_frames;
+};
+
/* Xen emulation context */
struct kvm_xen {
u64 xen_hypercall;
@@ -871,6 +888,8 @@ struct kvm_xen {
struct idr port_to_evt;
unsigned long poll_mask[BITS_TO_LONGS(KVM_MAX_VCPUS)];
struct mutex xen_lock;
+
+ struct kvm_grant_table gnttab;
};
enum kvm_xen_callback_via {
diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c
index e570c9b26563..b9e6e8f72d87 100644
--- a/arch/x86/kvm/xen.c
+++ b/arch/x86/kvm/xen.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include "trace.h"
@@ -35,6 +36,7 @@ struct evtchnfd {
static int kvm_xen_evtchn_send(struct kvm_vcpu *vcpu, int port);
static void *xen_vcpu_info(struct kvm_vcpu *v);
+static void kvm_xen_gnttab_free(struct kvm_xen *xen);
#define XEN_DOMID_MIN 1
#define XEN_DOMID_MAX (DOMID_FIRST_RESERVED - 1)
@@ -513,6 +515,12 @@ int kvm_xen_hvm_set_attr(struct kvm *kvm, struct
kvm_xen_hvm_attr *data)
r = kvm_xen_domid_init(kvm, any, domid);
break;
}
+ case KVM_XEN_ATTR_TYPE_GNTTAB: {
+ struct kvm_xen_gnttab xevfd = data->u.gnttab;
+
+ r = kvm_vm_ioctl_xen_gnttab(kvm, );
+ break;
+ }
default:
break;
}
@@ -969,6 +977,7 @@ void kvm_xen_destroy_vm(struct kvm *kvm)
put_page(virt_to_page(xen->shinfo));
kvm_xen_free_domid(kvm);
+ kvm_xen_gnttab_free(>arch.xen);
}
void kvm_xen_init(void)
@@ -1093,3 +1102,82 @@ int kvm_vm_ioctl_xen_eventfd(struct kvm *kvm, struct
kvm_xen_eventfd *args)
return kvm_xen_eventfd_assign(kvm, >port_to_evt,
>xen_lock, args);
}
+
+int kvm_xen_gnttab_init(struct kvm *kvm, struct kvm_xen *xen,
+ struct kvm_xen_gnttab *op, int dom0)
+{
+ u32 max_mt_frames = op->init.max_maptrack_frames;
+ unsigned long initial = op->init.initial_frame;
+ struct kvm_grant_table *gnttab = >gnttab;
+ u32 max_frames = op->init.max_frames;
+ struct page *page = NULL;
+ void *addr;
+
+ if (!dom0) {
+ if (!op->init.initial_frame ||
+ offset_in_page(op->init.initial_frame))
+ return -EINVAL;
+
+ if (get_user_pages_fast(initial, 1, 1, ) != 1)
+ return -EFAULT;
+
+ gnttab->initial_addr = initial;
+ gnttab->initial = page_to_virt(page);
+ put_page(page);
+ }
+
+ addr = kcalloc(max_frames, sizeof(gfn_t), GFP_KERNEL);
+ if (!addr)
+ goto out;
+ xen->gnttab.frames_addr = addr;
+
+ addr = kcalloc(max_frames, sizeof(addr), GFP_KERNEL);
+ if (!addr)
+ goto out;
+
+ gnttab->frames = addr;
+ gnttab->frames[0] = xen->gnttab.initial;
+ gnttab->max_nr_frames = max_frames;
+ gnttab->max_mt_frames = max_mt_frames;
+ gnttab->nr_mt_frames = 1;
+ gnttab->nr_frames = 0;
+
+ pr_debug("kvm_xen: dom%u: grant table limits (gnttab:%d maptrack:%d)\n",
+xen->domid, gnttab->max_nr_frames, gnttab->max_mt_frames);
+ return 0;
+
+out:
+ kfree(xen->gnttab.frames);
+ kfree(xen->gnttab.frames_addr);
+ if (page)
+ put_page(page);
+ memset(>gnttab, 0, sizeof(xen->gnttab));
+ return -ENOMEM;
+}
+
+void kvm_xen_gnttab_free(struct kvm_xen *xen)
+{
+ struct kvm_grant_table *gnttab = >gnttab;
+
+ kfree(gnttab->frames);
+ kfree(gnttab->frames_addr);
+}
+
+int kvm_vm_ioctl_xen_gnttab(struct kvm *kvm, struct
[PATCH RFC 27/39] KVM: x86/xen: grant copy support
Copies from source grant reference to dest grant reference (or the
other way around.)
Signed-off-by: Joao Martins
---
arch/x86/kvm/xen.c | 151 +
1 file changed, 151 insertions(+)
diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c
index 8f06924e0dfa..fecc548b2f12 100644
--- a/arch/x86/kvm/xen.c
+++ b/arch/x86/kvm/xen.c
@@ -10,6 +10,7 @@
#include "ioapic.h"
#include
+#include
#include
#include
#include
@@ -1747,6 +1748,148 @@ static int shim_hcall_gntunmap(struct kvm_xen *xen,
return 0;
}
+static unsigned long __kvm_gfn_to_hva(struct kvm_vcpu *vcpu, gfn_t gfn)
+{
+ struct kvm_xen *xen = vcpu ? >kvm->arch.xen : xen_shim;
+ unsigned long hva;
+
+ if (xen->domid == 0)
+ return (unsigned long) page_to_virt(pfn_to_page(gfn));
+
+ hva = gfn_to_hva(vcpu->kvm, gfn);
+ if (unlikely(kvm_is_error_hva(hva)))
+ return 0;
+
+ return hva;
+}
+
+static int __kvm_gref_to_page(struct kvm_vcpu *vcpu, grant_ref_t ref,
+ domid_t domid, struct page **page,
+ int16_t *status)
+{
+ struct kvm_xen *source = vcpu ? >kvm->arch.xen : xen_shim;
+ struct grant_entry_v1 *shah;
+ struct grant_entry_v1 **gt;
+ struct kvm *dest;
+
+ dest = kvm_xen_find_vm(domid);
+ if (unlikely(!dest)) {
+ pr_err("gnttab: could not find domain %u\n", domid);
+ *status = GNTST_bad_domain;
+ return 0;
+ }
+
+ if (unlikely(ref >= gnttab_entries(dest))) {
+ pr_err("gnttab: bad ref %u\n", ref);
+ *status = GNTST_bad_gntref;
+ return 0;
+ }
+
+ gt = dest->arch.xen.gnttab.frames_v1;
+ shah = shared_entry(gt, ref);
+ if (unlikely(shah->domid != source->domid)) {
+ pr_err("gnttab: bad domain (%u != %u)\n",
+ shah->domid, source->domid);
+ *status = GNTST_bad_gntref;
+ return 0;
+ }
+
+ (void) map_grant_nosleep(dest, shah->frame, 0, page, status);
+
+ return 0;
+}
+
+static int shim_hcall_gntcopy(struct kvm_vcpu *vcpu,
+ struct gnttab_copy *op)
+{
+ void *saddr = NULL, *daddr = NULL;
+ struct page *spage = NULL, *dpage = NULL;
+ unsigned long hva;
+ int err = -ENOSYS;
+ gfn_t gfn;
+
+ if (!(op->flags & GNTCOPY_source_gref) &&
+ (op->source.domid == DOMID_SELF)) {
+ gfn = op->source.u.gmfn;
+ hva = __kvm_gfn_to_hva(vcpu, gfn);
+ if (unlikely(!hva)) {
+ pr_err("gnttab: bad source gfn:%llx\n", gfn);
+ op->status = GNTST_general_error;
+ err = 0;
+ return 0;
+ }
+
+ saddr = (void *) (((unsigned long) hva) + op->source.offset);
+ } else if (op->flags & GNTCOPY_source_gref) {
+ op->status = GNTST_okay;
+ if (__kvm_gref_to_page(vcpu, op->source.u.ref,
+ op->source.domid, , >status))
+ return -EFAULT;
+
+ if (!spage || op->status != GNTST_okay) {
+ pr_err("gnttab: failed to get page for source
gref:%x\n",
+ op->source.u.ref);
+ err = 0;
+ goto out;
+ }
+
+ saddr = kmap(spage);
+ saddr = (void *) (((unsigned long) saddr) + op->source.offset);
+ }
+
+ if (!(op->flags & GNTCOPY_dest_gref) &&
+ (op->dest.domid == DOMID_SELF)) {
+ gfn = op->dest.u.gmfn;
+ hva = __kvm_gfn_to_hva(vcpu, gfn);
+ if (unlikely(!hva)) {
+ pr_err("gnttab: bad dest gfn:%llx\n", gfn);
+ op->status = GNTST_general_error;
+ err = 0;
+ return 0;
+ }
+
+ daddr = (void *) (((unsigned long) hva) + op->dest.offset);
+ } else if (op->flags & GNTCOPY_dest_gref) {
+ op->status = GNTST_okay;
+ if (__kvm_gref_to_page(vcpu, op->dest.u.ref,
+ op->dest.domid, , >status))
+ return -EFAULT;
+
+ if (!dpage || op->status != GNTST_okay) {
+ pr_err("gnttab: failed to get page for dest gref:%x\n",
+ op->dest.u.ref);
+ err = 0;
+ goto out;
+ }
+
+ daddr = kmap(dpage);
+ daddr = (void *)
[RFC PATCH 27/27] containers: Sample to grant access to a key in a container
Provide a sample program that will grant access to the specified key for a
container named "foo-test" (as created by the test-container sample) and
then link the key into the container keyring (either given on the command
line or searches for a keyring called "_container" in the session keyring
as placed there by the test-container sample).
So, for example, this could be used to place an rxrpc key in the container
keyring for kAFS inside the container to use:
(1) Poke kerberos to get a ticket for accessing AFS.
# kinit
# aklog-kafs redhat.com
(2) Find the rxrpc key ID:
# keyctl show
Session Keyring
1071328996 --alswrv 0 0 keyring: _ses
574060623 ---lswrv 0 65534 \_ keyring: _uid.0
1004048468 --alswrv 0 0 \_ rxrpc: a...@redhat.com
918328787 --alswrv 0 0 \_ keyring: upcall
996275498 --alswrv 0 0 \_ keyring: _container
785497401 --alswrv 0 0 \_ user: foobar
which would be 1004048468 in this example.
(3) Invoke the sample:
# test-cont-grant 1004048468
The rxrpc key can now be seen in the container keyring:
# keyctl show
Session Keyring
1071328996 --alswrv 0 0 keyring: _ses
574060623 ---lswrv 0 65534 \_ keyring: _uid.0
1004048468 --alswrv 0 0 \_ rxrpc: a...@redhat.com
918328787 --alswrv 0 0 \_ keyring: upcall
996275498 --alswrv 0 0 \_ keyring: _container
785497401 --alswrv 0 0 \_ user: foobar
1004048468 --alswrv 0 0 \_ rxrpc: a...@redhat.com
(4) Mount the kAFS filesystem inside the container:
> mount -t afs "%redhat.com:root.cell" /mnt
The contents of /mnt can then be used from inside the container using the
key placed into the container keyring.
Signed-off-by: David Howells
---
samples/vfs/Makefile |3 +
samples/vfs/test-cont-grant.c | 84 +
2 files changed, 87 insertions(+)
create mode 100644 samples/vfs/test-cont-grant.c
diff --git a/samples/vfs/Makefile b/samples/vfs/Makefile
index a8e9e1142ae3..c8eea193a856 100644
--- a/samples/vfs/Makefile
+++ b/samples/vfs/Makefile
@@ -6,6 +6,7 @@ hostprogs-$(CONFIG_SAMPLE_VFS) := \
test-mntinfo \
test-statx \
test-container \
+ test-cont-grant \
test-upcall
# Tell kbuild to always build the programs
@@ -22,5 +23,7 @@ HOSTCFLAGS_test-statx.o += -I$(objtree)/usr/include
HOSTCFLAGS_test-container.o += -I$(objtree)/usr/include
HOSTLDLIBS_test-container += -lkeyutils
+HOSTCFLAGS_test-cont-grant.o += -I$(objtree)/usr/include
+HOSTLDLIBS_test-cont-grant += -lkeyutils
HOSTCFLAGS_test-upcall.o += -I$(objtree)/usr/include
HOSTLDLIBS_test-upcall += -lkeyutils
diff --git a/samples/vfs/test-cont-grant.c b/samples/vfs/test-cont-grant.c
new file mode 100644
index ..da4a60bc71fa
--- /dev/null
+++ b/samples/vfs/test-cont-grant.c
@@ -0,0 +1,84 @@
+/* Link a key into a container keyring and grant perms to the container.
+ *
+ * Copyright (C) 2019 Red Hat, Inc. All Rights Reserved.
+ * Written by David Howells (dhowe...@redhat.com)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public Licence
+ * as published by the Free Software Foundation; either version
+ * 2 of the Licence, or (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define KEYCTL_GRANT_PERMISSION36 /* Grant a permit to a
key */
+
+enum key_ace_subject_type {
+ KEY_ACE_SUBJ_STANDARD = 0,/* subject is one of
key_ace_standard_subject */
+ KEY_ACE_SUBJ_CONTAINER = 1,/* subject is a container fd */
+ KEY_ACE_SUBJ_CONTAINER_NAME = 2, /* subject is a container name pointer
*/
+};
+
+enum key_ace_standard_subject {
+ KEY_ACE_EVERYONE= 0,/* Everyone, including owner and group
*/
+ KEY_ACE_GROUP = 1,/* The key's group */
+ KEY_ACE_OWNER = 2,/* The owner of the key */
+ KEY_ACE_POSSESSOR = 3,/* Any process that possesses of the
key */
+};
+
+#define KEY_ACE_VIEW 0x0001 /* Can describe the key */
+#define KEY_ACE_READ 0x0002 /* Can read the key content */
+#define KEY_ACE_WRITE 0x0004 /* Can update/modify the key content
*/
+#define KEY_ACE_SEARCH 0x0008 /* Can find the key by search */
+#define KEY_ACE_LINK 0x0010 /* Can make a link to the key */
+#define KEY_ACE_SET_SECURITY 0x0020 /* Can set owner, group, ACL */
+#define KEY_ACE_INVAL 0x0040 /* Can invalidate the key */
+#define KEY_ACE_REVOKE 0x0080 /* Can revoke the key */
+#define KEY_ACE
[RFC PATCH 16/27] keys: Grant Link permission to possessers of request_key auth keys
Grant Link permission to the possessers of request_key authentication keys,
thereby allowing a daemon that is servicing upcalls to arrange things such
that only the necessary auth key is passed to the actual service program
and not all the daemon's pending auth keys.
Signed-off-by: David Howells
---
security/keys/request_key_auth.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/security/keys/request_key_auth.c b/security/keys/request_key_auth.c
index cd75173cadad..726555a0639c 100644
--- a/security/keys/request_key_auth.c
+++ b/security/keys/request_key_auth.c
@@ -208,7 +208,7 @@ struct key *request_key_auth_new(struct key *target, const
char *op,
authkey = key_alloc(_type_request_key_auth, desc,
cred->fsuid, cred->fsgid, cred,
- KEY_POS_VIEW | KEY_POS_READ | KEY_POS_SEARCH |
+ KEY_POS_VIEW | KEY_POS_READ | KEY_POS_SEARCH |
KEY_POS_LINK |
KEY_USR_VIEW, KEY_ALLOC_NOT_IN_QUOTA, NULL);
if (IS_ERR(authkey)) {
ret = PTR_ERR(authkey);
[PATCH 4.19 10/50] CIFS: Do not set credits to 1 if the server didnt grant anything
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Pavel Shilovsky
commit 33fa5c8b8a7dbe6353a56eaa654b790348890d42 upstream.
Currently we reset the number of total credits granted by the server
to 1 if the server didn't grant us anything int the response. This
violates the SMB3 protocol - we need to trust the server and use
the credit values from the response. Fix this by removing the
corresponding code.
Signed-off-by: Pavel Shilovsky
Signed-off-by: Steve French
CC: Stable
Signed-off-by: Greg Kroah-Hartman
---
fs/cifs/transport.c |2 --
1 file changed, 2 deletions(-)
--- a/fs/cifs/transport.c
+++ b/fs/cifs/transport.c
@@ -885,8 +885,6 @@ compound_send_recv(const unsigned int xi
for (i = 0; i < num_rqst; i++)
if (midQ[i]->resp_buf)
credits += ses->server->ops->get_credits(midQ[i]);
- if (!credits)
- credits = 1;
for (i = 0; i < num_rqst; i++) {
if (rc < 0)
[PATCH 4.20 13/57] CIFS: Do not set credits to 1 if the server didnt grant anything
4.20-stable review patch. If anyone has any objections, please let me know.
--
From: Pavel Shilovsky
commit 33fa5c8b8a7dbe6353a56eaa654b790348890d42 upstream.
Currently we reset the number of total credits granted by the server
to 1 if the server didn't grant us anything int the response. This
violates the SMB3 protocol - we need to trust the server and use
the credit values from the response. Fix this by removing the
corresponding code.
Signed-off-by: Pavel Shilovsky
Signed-off-by: Steve French
CC: Stable
Signed-off-by: Greg Kroah-Hartman
---
fs/cifs/transport.c |2 --
1 file changed, 2 deletions(-)
--- a/fs/cifs/transport.c
+++ b/fs/cifs/transport.c
@@ -892,8 +892,6 @@ compound_send_recv(const unsigned int xi
for (i = 0; i < num_rqst; i++)
if (midQ[i]->resp_buf)
credits += ses->server->ops->get_credits(midQ[i]);
- if (!credits)
- credits = 1;
for (i = 0; i < num_rqst; i++) {
if (rc < 0)
Re: Yes: The linux devs can rescind their license grant. GPLv2 is a bare license and is revocable by
That may be OpenBSD policy, but it is not the law. Your OpenBSD policy cannot bind the copyright holder of the works you distribute. It's also an incorrect statement of the law. If the copyright holder did not receive consideration/payment/etc from you: you have no interest to bind him with. He can rescind. If you read the BSD license(s) there is never a "no-revocation-by-grantor" clause, so you cannot even make an argument that you relied on a promise of his (he made no such promise). Furthermore you never paid for that non-existent promise to begin with: he just gratuitously gave you permission to use and modify his property. He end that permission. Why would you think that you can make promises for some other entity even? How does that even make sense to you? Additionally, the *BSD projects (as entities) cannot make promises about code they do not own the copyright to. So if you did not require copyright assignment from developer X, Y, Z, said developer still owns the copyright: not the project. So, maybe the project or entity E is making some promise: but that promise was not made with respect to code snippet FOO since the project or entity E does not actually OWN code snippet FOO but instead there has been granted a license to use and modify it. Permission that can be rescinded from the licensee E unless the licensee E secured an interest regarding that (paid the programmer, for instance, and he agreed to terms etc). The rule is that a license is revocable absent an attached interest. Gratuitous licenses are not worth the paper they are printed on. (usually they are never printed out tho :P, or even read). They do not bind the grantor. They bind YOU. Not the property owner. (If you want the property owner bound to the terms you purchase that right from him in some way.) Ingo Schwarze wrote: -- Hi, i'm not replying to the trolls (or their off-topic rants) in this thread, and i'm not spamming other project's lists. Instead, i'd merely like to clarify a point that is actually on topic on this list, to avoid that users get confused by FUD. One of the trolls wrote: A gratuitous license, absent an attached interest, is revocable at will. This goes for GPLv2 as used by linux, just as it goes for the BSD license(s). That is not what /usr/share/misc/license.template means, and i'm sure all OpenBSD developers are aware of that. The OpenBSD website makes the meaning very explicit: https://www.openbsd.org/policy.html [...] Finally, releases are generally binding on the material that they are distributed with. This means that if the originator of a work distributes that work with a release granting certain permissions, those permissions apply as stated, without discrimination, to all persons legitimately possessing a copy of the work. That means that having granted a permission, the copyright holder can not retroactively say that an individual or class of individuals are no longer granted those permissions. Likewise should the copyright holder decide to "go commercial" he can not revoke permissions already granted for the use of the work as distributed, though he may impose more restrictive permissions in his future distributions of that work. Yours, Ingo
FWD: 2: Re: [gentoo-user] Re: Yes: The linux devs can rescind their license grant. GPLv2 is a bare license and is revocable by the grantor.
Subject: Re: [gentoo-user] Re: Yes: The linux devs can rescind their license grant. GPLv2 is a bare license and is revocable by the grantor. FromR0b0t1 To gentoo-u...@lists.gentoo.org Cc ubuntu-us...@lists.ubuntu.com , debian-u...@lists.debian.org, d...@lists.dyne.org Reply-Togentoo-u...@lists.gentoo.org DateThu 20:42 Message Body Apologize for the follow up: Not being able to rescind the license is like saying someone who was lent a lawnmower gets to keep it indefinitely with no contest because the person who lent it can't rescind the grant to the lawnmower. On Thu, Dec 27, 2018 at 9:39 PM R0b0t1 wrote:
FWD: [gentoo-user] Re: Yes: The linux devs can rescind their license grant. GPLv2 is a bare license and is revocable by the grantor.
Re: [gentoo-user] Re: Yes: The linux devs can rescind their license grant. GPLv2 is a bare license and is revocable by the grantor. FromR0b0t1 To gentoo-u...@lists.gentoo.org Cc ubuntu-us...@lists.ubuntu.com , debian-u...@lists.debian.org, d...@lists.dyne.org Reply-Togentoo-u...@lists.gentoo.org DateThu 20:39 This was cross posted so many places I have to preface: I got here from the Gentoo list. If this only makes it to the crossposter forward or follow up on the information as you see fit. The post is crass but still has technical merit. More importantly he seems to be right, the idea that the grantees can't rescind their grant is pretty strange. I'm allowed to change my mind, and you have no claim to my labor if you didn't pay for it, nor can you make me work for free. On Thu, Dec 27, 2018 at 9:16 PM wrote: > (2) ... (I am not going to go over the legal mistakes you've made, > because of (1))... I have not made legal mistakes, pompous programmer asshole*. A gratuitous license, absent an attached interest, is revocable at will. This goes for GPLv2 as used by linux, just as it goes for the BSD license(s). The only entities who have, with regards to BSD, an attached interests are perhaps those companies who pay for its development. Non-gratis (paying) customers may have some refuge under consumer protection statutes, for current versions they have in their posession, paid for by good consideration. There is one thing you get for free (that you probably had anyway): I was seeing whether or not the disclaimer of liability in most FOSS licenses was valid. They may not be, *especially* in those United States which require a guarantee of merchantability or suitability for a particular purpose. Read: You made it, you claim it does something, and if someone uses it and it *doesn't* do that thing explosively it's still your fault even if it was free. The amount of damages are definitely tempered by the fact it was free. Depending on the license, state, and judge, you could have given consideration even though you did not pay money. Everyone else has NOTHING. Do you understand that? I think it is important to clarify that it can be requested you stop distributing the work or stop using it for some commercial purpose, but there is no way you could e.g. be forced to delete copies of it you already have. Also: Consideration can be nonmonetary, can you speak to this? Cheers, R0b0t1 [... snip anger ...] On 2018-12-24 16:01, Raul Miller wrote: > (1) Wrong mailing lists - these are not linux mailing lists. > > (2) ... (I am not going to go over the legal mistakes you've made, > because of (1))... > > (3) Anyways, ... people do make mistakes... But, please stop making > these mistakes. > > Thanks, > > -- > Raul > > On Mon, Dec 24, 2018 at 10:55 AM wrote: >> >> Bradley M. Kuhn: The SFConservancy's new explanation was refuted 5 >> hours >> after it was published: >> >> >> >> >> Yes they can, greg. >> >> The GPL v2, is a bare license. It is not a contract. It lacks >> consideration between the licensee and the grantor. >> >> (IE: They didn't pay you, Greg, a thing. YOU, Greg, simply have chosen >> to bestow a benefit upon them where they suffer no detriment and you, >> in >> fact, gain no bargained-for benefit) >> >> As a bare license, (read: property license), the standard rules >> regarding the alienation of property apply. >> >> Therein: a gratuitous license is revocable at the will of the grantor. >> >> The licensee then may ATTEMPT, as an affirmative defense against your >> as-of-right action to claim promissory estoppel in state court, and >> "keep you to your word". However you made no such promise disclaiming >> your right to rescind the license. >> >> Remeber: There is no utterance disclaiming this right within the GPL >> version 2. Linus, furthermore, has chosen both to exclude the "or any >> later version" codicil, to reject the GPL version 3, AND to publicly >> savage GPL version 3 (he surely has his reasons, perhaps this is one >> of >> them, left unstated). (GPLv3 which has such promises listed (not to >> say >> that they would be effective against the grantor, but it is an attempt >> at the least)). >> >> >> >> >> The Software Freedom Conservancy has attempted to mis-construe clause >> 4 >> of the GPL version 2 as a "no-revocation by grantor" clause. >> >> However, reading said clause, using plain construction, leads a >> reasonable person to understand that said clause is speaking >> specifically about the situation where an upstream licensee loses >> their >> p
A license is a temporary grant, not a transfer.
1013746 If you think that rescinding the GPLv2 is possible why don't you do it :^) You do realize that a license pertains to the licensed article, do you not? Do you imagine that the goal is to "blanket rescind all licenses using the GPLv2 verbiage"? Is that it? Are you that stupid a lay person? The guy who owns the property grants the license. Understand? He can rescind that license whenever he wishes, unless you pay him not to, or he promises not to and you reasonably rely on that promise. (did you pay for that promise? is it reasonable for you to rely on?). Did each of the linux programmers make such a promise to you? No they did not. Did you pay each of the linux programmers anything. No you did not. They can rescind the license from you. Understand? A license is a temporary grant, it is not a transfer.
Re: Yes: The linux devs can rescind their license grant. GPLv2 is a bare license and is revocable by the grantor.
On Thu, Dec 27, 2018 at 3:12 PM wrote: > ... pompous programmer asshole*. I think you are projecting your own personality in your perception of others (which is a natural thing to do - everyone does that to some degree). That said, I am going to filter your messages to my spam bucket from now on. Have fun, -- Raul
Re: Yes: The linux devs can rescind their license grant. GPLv2 is a bare license and is revocable by the grantor.
(2) ... (I am not going to go over the legal mistakes you've made, because of (1))... I have not made legal mistakes, pompous programmer a__hole*. A gratuitous license, absent an attached interest, is revocable at will. This goes for GPLv2 as used by linux, just as it goes for the BSD license(s). The only entities who have, with regards to BSD, an attached interests are perhaps those companies who pay for its development. Non-gratis (paying) customers may have some refuge under consumer protection statutes, for current versions they have in their posession, paid for by good consideration. Everyone else has NOTHING. Do you understand that? In the case of the 1000's of linux copyright holders to whom no consideration was given by an entity, and the various BSD copyright holders (read: the programmers), who have not ASSIGNED their copyright over to some other entity, there is NOTHING to hold them to a promise THEY NEVER MADE. DO YOU UNDERSTAND THAT YOU F___ING PIECE OF S__T? DO YOU UNDERSTAND THAT NEITHER THEY NOR YOU HAVE PROMISED NOT TO ELLECT TO USE YOUR AS-OF-RIGHT OPTION TO RESCIND YOUR GRATUITOUS LICENSE REGARDING YOUR WORK. One cannot rely on a promise that was never made, additionally many of them were never paid consideration for this non existant promise either. *(Note: I am both a programmer and an attorney, so I know the type) On 2018-12-24 16:01, Raul Miller wrote: (1) Wrong mailing lists - these are not linux mailing lists. (2) ... (I am not going to go over the legal mistakes you've made, because of (1))... (3) Anyways, ... people do make mistakes... But, please stop making these mistakes. Thanks, -- Raul
Re: Yes: The linux devs can rescind their license grant. GPLv2 is a bare license and is revocable by the grantor.
(2) ... (I am not going to go over the legal mistakes you've made, because of (1))... I have not made legal mistakes, pompous programmer asshole*. A gratuitous license, absent an attached interest, is revocable at will. This goes for GPLv2 as used by linux, just as it goes for the BSD license(s). The only entities who have, with regards to BSD, an attached interests are perhaps those companies who pay for its development. Non-gratis (paying) customers may have some refuge under consumer protection statutes, for current versions they have in their posession, paid for by good consideration. Everyone else has NOTHING. Do you understand that? In the case of the 1000's of linux copyright holders to whom no consideration was given by an entity, and the various BSD copyright holders (read: the programmers), who have not ASSIGNED their copyright over to some other entity, there is NOTHING to hold them to a promise THEY NEVER MADE. DO YOU UNDERSTAND THAT YOU FUCKING PIECE OF SHIT? DO YOU UNDERSTAND THAT NEITHER THEY NOR YOU HAVE PROMISED NOT TO ELLECT TO USE YOUR AS-OF-RIGHT OPTION TO RESCIND YOUR GRATUITOUS LICENSE REGARDING YOUR WORK. One cannot rely on a promise that was never made, additionally many of them were never paid consideration for this non existant promise either. *(Note: I am both a programmer and an attorney, so I know the type) On 2018-12-24 16:01, Raul Miller wrote: (1) Wrong mailing lists - these are not linux mailing lists. (2) ... (I am not going to go over the legal mistakes you've made, because of (1))... (3) Anyways, ... people do make mistakes... But, please stop making these mistakes. Thanks, -- Raul On Mon, Dec 24, 2018 at 10:55 AM wrote: Bradley M. Kuhn: The SFConservancy's new explanation was refuted 5 hours after it was published: Yes they can, greg. The GPL v2, is a bare license. It is not a contract. It lacks consideration between the licensee and the grantor. (IE: They didn't pay you, Greg, a thing. YOU, Greg, simply have chosen to bestow a benefit upon them where they suffer no detriment and you, in fact, gain no bargained-for benefit) As a bare license, (read: property license), the standard rules regarding the alienation of property apply. Therein: a gratuitous license is revocable at the will of the grantor. The licensee then may ATTEMPT, as an affirmative defense against your as-of-right action to claim promissory estoppel in state court, and "keep you to your word". However you made no such promise disclaiming your right to rescind the license. Remeber: There is no utterance disclaiming this right within the GPL version 2. Linus, furthermore, has chosen both to exclude the "or any later version" codicil, to reject the GPL version 3, AND to publicly savage GPL version 3 (he surely has his reasons, perhaps this is one of them, left unstated). (GPLv3 which has such promises listed (not to say that they would be effective against the grantor, but it is an attempt at the least)). The Software Freedom Conservancy has attempted to mis-construe clause 4 of the GPL version 2 as a "no-revocation by grantor" clause. However, reading said clause, using plain construction, leads a reasonable person to understand that said clause is speaking specifically about the situation where an upstream licensee loses their permission under the terms due to a violation of the terms; in that case the down-stream licensee does not in-turn also lose their permission under the terms. Additionally, clause 0 makes it crystal clear that "You" is defined as the licensee, not the grantor. Another issue the SFConservancy's public service announcement chooses to ignore. Thirdly, the SFConservancy banks on the ignorance of both the public and the developers regarding property alienation. A license does not impinge the rights of the party granting the license in a quid-pro-quo manner vis a vis the licensee's taking. A license merely grants permission, extended from the grantor, to the licensee, regarding the article of property that is being impinged. A license is NOT a full nor is it a permanent alienation of the article(property) in question. The impinged property, being under a non bargained-for temporary grant, can be taken back into the sole dominion of the owner - at his election to do so. Now as to the 9th circuit appellate court's decision in Jacobsen v. Katzer . While the court waxes eloquently about opensource licenses, even mentioning the word "consideration" in it's long dicta, when it comes time to make the binding decision the court found that the lower (district) court was in _ERROR_ regarding the application of contract-law principals to the Artistic License, regarding the case, and instructed the lower court to instead construe said license as a Copyright License. The SFConservancy, and Bruce Perens have chosen to: 1) Rely on the dicta. (non-binding - "some thin
Fwd: Re: [DNG] 2 months and no response from Eben Moglen - Yes you can rescind your grant. -- The CoC regime is a License violation - Additional restrictive terms
Original Message Subject: Re: [DNG] 2 months and no response from Eben Moglen - Yes you can rescind your grant. -- The CoC regime is a License violation - Additional restrictive terms Date: 2018-12-24 16:24 From: vnsnda...@memeware.net To: d...@lists.dyne.org Version 2 of the GPL forbids the incorporation of additional restrictive terms, relating to the distribution, modification, etc of the article licensed under the terms. Those that violate this section are declared, by operation of the terms, to have their grant automatically revoked. An additional term need-not be present in the same writing. Such terms simply need to be present to or made known to the taker(sub-licensee) by the distributor. They may be proffered in writing, orally, or implied in the course of doing business dealings. They simply must relate back or involve the article in question (the licensed code or product.) The proffering of additional restrictive terms is a violation of the text of the license grant in and of itself. Here we have a situation where an additional writing has been proffered. The additional writing promises both in it's own text and by implication consequences against those who violate the terms of this additional writing. The additional writing restricts those subject to it from expressing certain views publicly - promising retribution against those who do. No consideration is paid to those subject to the additional writing for their assent; it is simply imposed unilaterally against the subjects. The violators of the additional writing are promised: Additional, unwanted, public scrutiny (to which they were not subject to prior) Public ridicule. Loss of public standing. as-well as an implied loss of future income. These are the enforcement mechanisms of the additional writing to enforce its restrictions against those who publish derivative works of the kernel. The additional writing is activated when (with the prerequisite of being a derivative work of the linux kernel) the work of a rights-holder is incorporated into the kernel, when such a work is made known to the kernel-team to exist where any one person on this earth has seen fit to present it for inclusion, or by simple prior-inclusion into the kernel. Thus all current and past rights-holders who have code in, or have published for distribution, derivative works of the kernel are subject to the retributive promises made to them in the additional writing, drafted to restrict their actions and utterances. This is tantamount to an additional restrictive term regarding the modification and distribution of works under the linux kernel license grant. It is a violation of the license terms of the rights-holders past incorporated works in much the same way that GRSecurity's Contributor Access Agreement was and is. ___ Dng mailing list d...@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] 2 months and no response from Eben Moglen - Yes you can rescind your grant. -- The CoC regime is a License violation - Additional restrictive terms
Hendrik Boom, are you a lawyer? No? How about you shut your fucking mouth about things you have no clue of? Sound like a plan, ignorant lay person? Below is an explanation of just how it is a violation of the rights-holder's grant. The courts are not fooled by "clever" verbiage written up by laypersons such as yourself and such as the drafter of the CoC. They see things for what they are. Hendrik Boom wrote: Actually, no. It has no effect on what you can do with your copy of the Linux kernel. It just restricts your ability to participate fully in its development. But you can continue to use, modify, and distribute your copies as much as before, as provided by the license. -- hendrik Version 2 of the GPL forbids the incorporation of additional restrictive terms, relating to the distribution, modification, etc of the article licensed under the terms. Those that violate this section are declared, by operation of the terms, to have their grant automatically revoked. An additional term need-not be present in the same writing. Such terms simply need to be present to or made known to the taker(sub-licensee) by the distributor. They may be proffered in writing, orally, or implied in the course of doing business dealings. They simply must relate back or involve the article in question (the licensed code or product.) The proffering of additional restrictive terms is a violation of the text of the license grant in and of itself. Here we have a situation where an additional writing has been proffered. The additional writing promises both in it's own text and by implication consequences against those who violate the terms of this additional writing. The additional writing restricts those subject to it from expressing certain views publicly - promising retribution against those who do. No consideration is paid to those subject to the additional writing for their assent; it is simply imposed unilaterally against the subjects. The violators of the additional writing are promised: Additional, unwanted, public scrutiny (to which they were not subject to prior) Public ridicule. Loss of public standing. as-well as an implied loss of future income. These are the enforcement mechanisms of the additional writing to enforce its restrictions against those who publish derivative works of the kernel. The additional writing is activated when (with the prerequisite of being a derivative work of the linux kernel) the work of a rights-holder is incorporated into the kernel, when such a work is made known to the kernel-team to exist where any one person on this earth has seen fit to present it for inclusion, or by simple prior-inclusion into the kernel. Thus all current and past rights-holders who have code in, or have published for distribution, derivative works of the kernel are subject to the retributive promises made to them in the additional writing, drafted to restrict their actions and utterances. This is tantamount to an additional restrictive term regarding the modification and distribution of works under the linux kernel license grant. It is a violation of the license terms of the rights-holders past incorporated works in much the same way that GRSecurity's Contributor Access Agreement was and is.
Yes: The linux devs can rescind their license grant. GPLv2 is a bare license and is revocable by the grantor.
Bradley M. Kuhn: The SFConservancy's new explanation was refuted 5 hours after it was published: Yes they can, greg. The GPL v2, is a bare license. It is not a contract. It lacks consideration between the licensee and the grantor. (IE: They didn't pay you, Greg, a thing. YOU, Greg, simply have chosen to bestow a benefit upon them where they suffer no detriment and you, in fact, gain no bargained-for benefit) As a bare license, (read: property license), the standard rules regarding the alienation of property apply. Therein: a gratuitous license is revocable at the will of the grantor. The licensee then may ATTEMPT, as an affirmative defense against your as-of-right action to claim promissory estoppel in state court, and "keep you to your word". However you made no such promise disclaiming your right to rescind the license. Remeber: There is no utterance disclaiming this right within the GPL version 2. Linus, furthermore, has chosen both to exclude the "or any later version" codicil, to reject the GPL version 3, AND to publicly savage GPL version 3 (he surely has his reasons, perhaps this is one of them, left unstated). (GPLv3 which has such promises listed (not to say that they would be effective against the grantor, but it is an attempt at the least)). The Software Freedom Conservancy has attempted to mis-construe clause 4 of the GPL version 2 as a "no-revocation by grantor" clause. However, reading said clause, using plain construction, leads a reasonable person to understand that said clause is speaking specifically about the situation where an upstream licensee loses their permission under the terms due to a violation of the terms; in that case the down-stream licensee does not in-turn also lose their permission under the terms. Additionally, clause 0 makes it crystal clear that "You" is defined as the licensee, not the grantor. Another issue the SFConservancy's public service announcement chooses to ignore. Thirdly, the SFConservancy banks on the ignorance of both the public and the developers regarding property alienation. A license does not impinge the rights of the party granting the license in a quid-pro-quo manner vis a vis the licensee's taking. A license merely grants permission, extended from the grantor, to the licensee, regarding the article of property that is being impinged. A license is NOT a full nor is it a permanent alienation of the article(property) in question. The impinged property, being under a non bargained-for temporary grant, can be taken back into the sole dominion of the owner - at his election to do so. Now as to the 9th circuit appellate court's decision in Jacobsen v. Katzer . While the court waxes eloquently about opensource licenses, even mentioning the word "consideration" in it's long dicta, when it comes time to make the binding decision the court found that the lower (district) court was in _ERROR_ regarding the application of contract-law principals to the Artistic License, regarding the case, and instructed the lower court to instead construe said license as a Copyright License. The SFConservancy, and Bruce Perens have chosen to: 1) Rely on the dicta. (non-binding - "some things could be contracts - opensource is great") 2) Ignore the actual ruling. (Binding - Copyright License - Not Contract) 3) Ignore that this case was about the AL, not the GPLv2 4) Ignore the existence of different jurisdictions. (Why file in the roll-the-dice 9th district if you can file in a district that has personal-juristicion over the defendant and is much more consistent in it's rulings?) 5) Ignore all established law regard property licensing, contract formation, meeting of the minds, what consideration is etc. Which is not surprising considering the desire of people like Bruce Perens is to rob MEN of EVERY benefit of their Labour and every speck of happiness in life and to transfer those benefits to WOMEN and those who support women. (This is why people who are like Bruce Perens, the SFConservancy menbers, and the CoC supporters, banned men from taking female children as brides: in contrivance to the law of YHWH (Devarim chapter 22 - - verse 28 (na'ar (LXX: padia)), and continue to uphold that ban world-wide, and seek to destroy ALL cultures that do no bend to their will who are not idolators of Women) Look, you may love your users, you may love the people who edit your code in their home or office; but the fact of the matter is... They have done nothing for you, they have promised nothing to you. They CANNOT hold YOU. You have the right to rescind at any time, and remove your work from any future versions of Linux. And you might consider doing so if YOU are done harm. Don't let the insatiable, never-satisfied, public fool you into thinking otherwise. And, yes, I am a lawyer. And, no, unlike the SFConservancy, I di
2 months and no response from Eben Moglen - Yes you can rescind your grant.
It has been 2 months. Eben Moglen has published no research. Because there is nothing more to say: The GPLv2, as used by linux, is a bare license. It can be rescinded at the will of the grantor. The regime that the FSF used, vis-a-vis the GPLv2, is essential: copyright transfers to a central repository entity that is sure not to rescind. Linus chose not to adopt this regime. He benefited by greatly increased developer contribution. The price for that windfall was and is the retention of their traditional property rights by the property holders. They can rescind at will. They made no promise nor utterance to the contrary that can be relied upon. They were paid no consideration. There was no meeting of the minds. Additionally the CoC regime itself is a license terms violation, being an additional restrictive term, as explained in the other analysis. (Similar to the GRSecurity license violation) On 2018-10-26 18:31, Eben Moglen wrote: On Friday, 26 October 2018, visionsofal...@redchan.it wrote: You are conflating case law dealing with commercial software and non-gratuitous licenses with the present situation, which would likely be a case of first-impression in nearly any jurisdiction. I think the best procedure would be for me to publish my analysis and for you then to tell me what is wrong with it. What you say here sounds like what a lawyer might say, but isn't. I have been teaching this stuff for about thirty years, so if I am conflating or confusing anything I will be grateful for help in seeing my mistake. The rule for gratuitous licenses is that they are revocable at the will of the grantor. That's not actually "the rule." It sounds like it might be the rule, but it so happens that it's not. When I have given the explanation as I have learned, taught and depended on it, you will be able to show me what I am wrong about. Raymond Nimmer (God rest his soul) was in agreement on this point, vis-a-vis the GPL and similar licenses. You have your Nimmers confused. The primary author of the treatise Nimmer on Copyright (a book about the law, not in itself an authority) was Melville Nimmer. The treatise is continued by his son, David, a fine lawyer with whom I do from time to time politely disagree about something. Ray Nimmer is quite another person. Eben
Yes: The linux devs can rescind their license grant.
Your new explanation was refuted 5 hours after it was published. --- Yes they can, greg. The GPL v2, is a bare license. It is not a contract. It lacks consideration between the licensee and the grantor. (IE: They didn't pay you, Greg, a thing. YOU, Greg, simply have chosen to bestow a benefit upon them where they suffer no detriment and you, in fact, gain no bargained-for benefit) As a bare license, (read: property license), the standard rules regarding the alienation of property apply. Therein: a gratuitous license is revocable at the will of the grantor. The licensee then may ATTEMPT, as an affirmative defense against your as-of-right action to claim promissory estoppel in state court, and "keep you to your word". However you made no such promise disclaiming your right to rescind the license. Remeber: There is no utterance disclaiming this right within the GPL version 2. Linus, furthermore, has chosen both to exclude the "or any later version" codicil, to reject the GPL version 3, AND to publicly savage GPL version 3 (he surely has his reasons, perhaps this is one of them, left unstated). (GPLv3 which has such promises listed (not to say that they would be effective against the grantor, but it is an attempt at the least)). The Software Freedom Conservancy has attempted to mis-construe clause 4 of the GPL version 2 as a "no-revocation by grantor" clause. However, reading said clause, using plain construction, leads a reasonable person to understand that said clause is speaking specifically about the situation where an upstream licensee loses their permission under the terms due to a violation of the terms; in that case the down-stream licensee does not in-turn also lose their permission under the terms. Additionally, clause 0 makes it crystal clear that "You" is defined as the licensee, not the grantor. Another issue the SFConservancy's public service announcement chooses to ignore. Thirdly, the SFConservancy banks on the ignorance of both the public and the developers regarding property alienation. A license does not impinge the rights of the party granting the license in a quid-pro-quo manner vis a vis the licensee's taking. A license merely grants permission, extended from the grantor, to the licensee, regarding the article of property that is being impinged. A license is NOT a full nor is it a permanent alienation of the article(property) in question. The impinged property, being under a non bargained-for temporary grant, can be taken back into the sole dominion of the owner - at his election to do so. Now as to the 9th circuit appellate court's decision in Jacobsen v. Katzer . While the court waxes eloquently about opensource licenses, even mentioning the word "consideration" in it's long dicta, when it comes time to make the binding decision the court found that the lower (district) court was in _ERROR_ regarding the application of contract-law principals to the Artistic License, regarding the case, and instructed the lower court to instead construe said license as a Copyright License. The SFConservancy, and Bruce Perens have chosen to: 1) Rely on the dicta. (non-binding - "some things could be contracts - opensource is great") 2) Ignore the actual ruling. (Binding - Copyright License - Not Contract) 3) Ignore that this case was about the AL, not the GPLv2 4) Ignore the existence of different jurisdictions. (Why file in the roll-the-dice 9th district if you can file in a district that has personal-juristicion over the defendant and is much more consistent in it's rulings?) 5) Ignore all established law regard property licensing, contract formation, meeting of the minds, what consideration is etc. Which is not surprising considering the desire of people like Bruce Perens is to rob MEN of EVERY benefit of their Labour and every speck of happiness in life and to transfer those benefits to WOMEN and those who support women. (This is why people who are like Bruce Perens, the SFConservancy menbers, and the CoC supporters, banned men from taking female children as brides: in contrivance to the law of YHWH (Devarim chapter 22 - - verse 28 (na'ar (LXX: padia)), and continue to uphold that ban world-wide, and seek to destroy ALL cultures that do no bend to their will who are not idolators of Women) Look, you may love your users, you may love the people who edit your code in their home or office; but the fact of the matter is... They have done nothing for you, they have promised nothing to you. They CANNOT hold YOU. You have the right to rescind at any time, and remove your work from any future versions of Linux. And you might consider doing so if YOU are done harm. Don't let the insatiable, never-satisfied, public fool you into thinking otherwise. And, yes, I am a lawyer. And, no, unlike the SFConservancy, I did not have to call upon outs
2 months and no response from Eben Moglen - Yes you can rescind your grant.
It has been 2 months. Eben Moglen has published no research. Because there is nothing more to say: The GPLv2, as used by linux, is a bare license. It can be rescinded at the will of the grantor. The regime that the FSF used, vis-a-vis the GPLv2, is essential: copyright transfers to a central repository entity that is sure not to rescind. Linus chose not to adopt this regime. He benefited by greatly increased developer contribution. The price for that windfall was and is the retention of their traditional property rights by the property holders. They can rescind at will. They made no promise nor utterance to the contrary that can be relied upon. They were paid no consideration. There was no meeting of the minds. Additionally the CoC regime itself is a license terms violation, being an additional restrictive term, as explained in the other analysis. (Similar to the GRSecurity license violation) On 2018-10-26 18:31, Eben Moglen wrote: On Friday, 26 October 2018, visionsofal...@redchan.it wrote: You are conflating case law dealing with commercial software and non-gratuitous licenses with the present situation, which would likely be a case of first-impression in nearly any jurisdiction. I think the best procedure would be for me to publish my analysis and for you then to tell me what is wrong with it. What you say here sounds like what a lawyer might say, but isn't. I have been teaching this stuff for about thirty years, so if I am conflating or confusing anything I will be grateful for help in seeing my mistake. The rule for gratuitous licenses is that they are revocable at the will of the grantor. That's not actually "the rule." It sounds like it might be the rule, but it so happens that it's not. When I have given the explanation as I have learned, taught and depended on it, you will be able to show me what I am wrong about. Raymond Nimmer (God rest his soul) was in agreement on this point, vis-a-vis the GPL and similar licenses. You have your Nimmers confused. The primary author of the treatise Nimmer on Copyright (a book about the law, not in itself an authority) was Melville Nimmer. The treatise is continued by his son, David, a fine lawyer with whom I do from time to time politely disagree about something. Ray Nimmer is quite another person. Eben
2 months and no response from Eben Moglen - Yes you can rescind your grant.
It has been 2 months. Eben Moglen has published no research. Because there is nothing more to say: The GPLv2, as used by linux, is a bare license. It can be rescinded at the will of the grantor. The regime that the FSF used, vis-a-vis the GPLv2, is essential: copyright transfers to a central repository entity that is sure not to rescind. Linus chose not to adopt this regime. He benefited by greatly increased developer contribution. The price for that windfall was and is the retention of their traditional property rights by the property holders. They can rescind at will. They made no promise nor utterance to the contrary that can be relied upon. They were paid no consideration. There was no meeting of the minds. Additionally the CoC regime itself is a license terms violation, being an additional restrictive term, as explained in the other analysis. (Similar to the GRSecurity license violation) On 2018-10-26 18:31, Eben Moglen wrote: On Friday, 26 October 2018, visionsofal...@redchan.it wrote: You are conflating case law dealing with commercial software and non-gratuitous licenses with the present situation, which would likely be a case of first-impression in nearly any jurisdiction. I think the best procedure would be for me to publish my analysis and for you then to tell me what is wrong with it. What you say here sounds like what a lawyer might say, but isn't. I have been teaching this stuff for about thirty years, so if I am conflating or confusing anything I will be grateful for help in seeing my mistake. The rule for gratuitous licenses is that they are revocable at the will of the grantor. That's not actually "the rule." It sounds like it might be the rule, but it so happens that it's not. When I have given the explanation as I have learned, taught and depended on it, you will be able to show me what I am wrong about. Raymond Nimmer (God rest his soul) was in agreement on this point, vis-a-vis the GPL and similar licenses. You have your Nimmers confused. The primary author of the treatise Nimmer on Copyright (a book about the law, not in itself an authority) was Melville Nimmer. The treatise is continued by his son, David, a fine lawyer with whom I do from time to time politely disagree about something. Ray Nimmer is quite another person. Eben
Yes: The linux devs can rescind their license grant.
Your new explanation was refuted 5 hours after it was published. --- Yes they can, greg. The GPL v2, is a bare license. It is not a contract. It lacks consideration between the licensee and the grantor. (IE: They didn't pay you, Greg, a thing. YOU, Greg, simply have chosen to bestow a benefit upon them where they suffer no detriment and you, in fact, gain no bargained-for benefit) As a bare license, (read: property license), the standard rules regarding the alienation of property apply. Therein: a gratuitous license is revocable at the will of the grantor. The licensee then may ATTEMPT, as an affirmative defense against your as-of-right action to claim promissory estoppel in state court, and "keep you to your word". However you made no such promise disclaiming your right to rescind the license. Remeber: There is no utterance disclaiming this right within the GPL version 2. Linus, furthermore, has chosen both to exclude the "or any later version" codicil, to reject the GPL version 3, AND to publicly savage GPL version 3 (he surely has his reasons, perhaps this is one of them, left unstated). (GPLv3 which has such promises listed (not to say that they would be effective against the grantor, but it is an attempt at the least)). The Software Freedom Conservancy has attempted to mis-construe clause 4 of the GPL version 2 as a "no-revocation by grantor" clause. However, reading said clause, using plain construction, leads a reasonable person to understand that said clause is speaking specifically about the situation where an upstream licensee loses their permission under the terms due to a violation of the terms; in that case the down-stream licensee does not in-turn also lose their permission under the terms. Additionally, clause 0 makes it crystal clear that "You" is defined as the licensee, not the grantor. Another issue the SFConservancy's public service announcement chooses to ignore. Thirdly, the SFConservancy banks on the ignorance of both the public and the developers regarding property alienation. A license does not impinge the rights of the party granting the license in a quid-pro-quo manner vis a vis the licensee's taking. A license merely grants permission, extended from the grantor, to the licensee, regarding the article of property that is being impinged. A license is NOT a full nor is it a permanent alienation of the article(property) in question. The impinged property, being under a non bargained-for temporary grant, can be taken back into the sole dominion of the owner - at his election to do so. Now as to the 9th circuit appellate court's decision in Jacobsen v. Katzer . While the court waxes eloquently about opensource licenses, even mentioning the word "consideration" in it's long dicta, when it comes time to make the binding decision the court found that the lower (district) court was in _ERROR_ regarding the application of contract-law principals to the Artistic License, regarding the case, and instructed the lower court to instead construe said license as a Copyright License. The SFConservancy, and Bruce Perens have chosen to: 1) Rely on the dicta. (non-binding - "some things could be contracts - opensource is great") 2) Ignore the actual ruling. (Binding - Copyright License - Not Contract) 3) Ignore that this case was about the AL, not the GPLv2 4) Ignore the existence of different jurisdictions. (Why file in the roll-the-dice 9th district if you can file in a district that has personal-juristicion over the defendant and is much more consistent in it's rulings?) 5) Ignore all established law regard property licensing, contract formation, meeting of the minds, what consideration is etc. Which is not surprising considering the desire of people like Bruce Perens is to rob MEN of EVERY benefit of their Labour and every speck of happiness in life and to transfer those benefits to WOMEN and those who support women. (This is why people who are like Bruce Perens, the SFConservancy menbers, and the CoC supporters, banned men from taking female children as brides: in contrivance to the law of YHWH (Devarim chapter 22 - - verse 28 (na'ar (LXX: padia)), and continue to uphold that ban world-wide, and seek to destroy ALL cultures that do no bend to their will who are not idolators of Women) Look, you may love your users, you may love the people who edit your code in their home or office; but the fact of the matter is... They have done nothing for you, they have promised nothing to you. They CANNOT hold YOU. You have the right to rescind at any time, and remove your work from any future versions of Linux. And you might consider doing so if YOU are done harm. Don't let the insatiable, never-satisfied, public fool you into thinking otherwise. And, yes, I am a lawyer. And, no, unlike the SFConservancy, I did not have to call upon outs
Re: The linux devs can rescind their license grant.
Your new explanation was refuted 5 hours after it was published. --- Yes they can, greg. The GPL v2, is a bare license. It is not a contract. It lacks consideration between the licensee and the grantor. (IE: They didn't pay you, Greg, a thing. YOU, Greg, simply have chosen to bestow a benefit upon them where they suffer no detriment and you, in fact, gain no bargained-for benefit) As a bare license, (read: property license), the standard rules regarding the alienation of property apply. Therein: a gratuitous license is revocable at the will of the grantor. The licensee then may ATTEMPT, as an affirmative defense against your as-of-right action to claim promissory estoppel in state court, and "keep you to your word". However you made no such promise disclaiming your right to rescind the license. Remeber: There is no utterance disclaiming this right within the GPL version 2. Linus, furthermore, has chosen both to exclude the "or any later version" codicil, to reject the GPL version 3, AND to publicly savage GPL version 3 (he surely has his reasons, perhaps this is one of them, left unstated). (GPLv3 which has such promises listed (not to say that they would be effective against the grantor, but it is an attempt at the least)). The Software Freedom Conservancy has attempted to mis-construe clause 4 of the GPL version 2 as a "no-revocation by grantor" clause. However, reading said clause, using plain construction, leads a reasonable person to understand that said clause is speaking specifically about the situation where an upstream licensee loses their permission under the terms due to a violation of the terms; in that case the down-stream licensee does not in-turn also lose their permission under the terms. Additionally, clause 0 makes it crystal clear that "You" is defined as the licensee, not the grantor. Another issue the SFConservancy's public service announcement chooses to ignore. Thirdly, the SFConservancy banks on the ignorance of both the public and the developers regarding property alienation. A license does not impinge the rights of the party granting the license in a quid-pro-quo manner vis a vis the licensee's taking. A license merely grants permission, extended from the grantor, to the licensee, regarding the article of property that is being impinged. A license is NOT a full nor is it a permanent alienation of the article(property) in question. The impinged property, being under a non bargained-for temporary grant, can be taken back into the sole dominion of the owner - at his election to do so. Now as to the 9th circuit appellate court's decision in Jacobsen v. Katzer . While the court waxes eloquently about opensource licenses, even mentioning the word "consideration" in it's long dicta, when it comes time to make the binding decision the court found that the lower (district) court was in _ERROR_ regarding the application of contract-law principals to the Artistic License, regarding the case, and instructed the lower court to instead construe said license as a Copyright License. The SFConservancy, and Bruce Perens have chosen to: 1) Rely on the dicta. (non-binding - "some things could be contracts - opensource is great") 2) Ignore the actual ruling. (Binding - Copyright License - Not Contract) 3) Ignore that this case was about the AL, not the GPLv2 4) Ignore the existence of different jurisdictions. (Why file in the roll-the-dice 9th district if you can file in a district that has personal-juristicion over the defendant and is much more consistent in it's rulings?) 5) Ignore all established law regard property licensing, contract formation, meeting of the minds, what consideration is etc. Which is not surprising considering the desire of people like Bruce Perens is to rob MEN of EVERY benefit of their Labour and every speck of happiness in life and to transfer those benefits to WOMEN and those who support women. (This is why people who are like Bruce Perens, the SFConservancy menbers, and the CoC supporters, banned men from taking female children as brides: in contrivance to the law of YHWH (Devarim chapter 22 - - verse 28 (na'ar (LXX: padia)), and continue to uphold that ban world-wide, and seek to destroy ALL cultures that do no bend to their will who are not idolators of Women) Look, you may love your users, you may love the people who edit your code in their home or office; but the fact of the matter is... They have done nothing for you, they have promised nothing to you. They CANNOT hold YOU. You have the right to rescind at any time, and remove your work from any future versions of Linux. And you might consider doing so if YOU are done harm. Don't let the insatiable, never-satisfied, public fool you into thinking otherwise. And, yes, I am a lawyer. And, no, unlike the SFConservancy, I did not have to call upon outs
Re: The linux devs can rescind their license grant. - Analysis published?
Has the analysis been published yet? I have been away on an artistic sabbatical, but I don't see it in the inbox using searches, this was the last mail I received on the subject. On 2018-10-26 18:31, Eben Moglen wrote: On Friday, 26 October 2018, visionsofal...@redchan.it wrote: You are conflating case law dealing with commercial software and non-gratuitous licenses with the present situation, which would likely be a case of first-impression in nearly any jurisdiction. I think the best procedure would be for me to publish my analysis and for you then to tell me what is wrong with it. What you say here sounds like what a lawyer might say, but isn't. I have been teaching this stuff for about thirty years, so if I am conflating or confusing anything I will be grateful for help in seeing my mistake. The rule for gratuitous licenses is that they are revocable at the will of the grantor. That's not actually "the rule." It sounds like it might be the rule, but it so happens that it's not. When I have given the explanation as I have learned, taught and depended on it, you will be able to show me what I am wrong about. Raymond Nimmer (God rest his soul) was in agreement on this point, vis-a-vis the GPL and similar licenses. You have your Nimmers confused. The primary author of the treatise Nimmer on Copyright (a book about the law, not in itself an authority) was Melville Nimmer. The treatise is continued by his son, David, a fine lawyer with whom I do from time to time politely disagree about something. Ray Nimmer is quite another person. Eben
[PATCH 4.19 060/118] xen/grant-table: Fix incorrect gnttab_dma_free_pages() pr_debug message
4.19-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit d9cccfa7c4d1d9ef967ec9308df7304a18609b30 ]
If a call to xenmem_reservation_increase() in gnttab_dma_free_pages()
fails it triggers a message "Failed to decrease reservation..." which
should be "Failed to increase reservation..."
Fixes: 9bdc7304f536 ('xen/grant-table: Allow allocating buffers suitable for
DMA')
Reported-by: Ross Philipson
Signed-off-by: Liam Merwick
Reviewed-by: Mark Kanda
Reviewed-by: Juergen Gross
Signed-off-by: Juergen Gross
Signed-off-by: Sasha Levin
---
drivers/xen/grant-table.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 84575baceebc..97341fa75458 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -914,7 +914,7 @@ int gnttab_dma_free_pages(struct gnttab_dma_alloc_args
*args)
ret = xenmem_reservation_increase(args->nr_pages, args->frames);
if (ret != args->nr_pages) {
- pr_debug("Failed to decrease reservation for DMA buffer\n");
+ pr_debug("Failed to increase reservation for DMA buffer\n");
ret = -EFAULT;
} else {
ret = 0;
--
2.17.1
[PATCH 4.19 060/118] xen/grant-table: Fix incorrect gnttab_dma_free_pages() pr_debug message
4.19-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit d9cccfa7c4d1d9ef967ec9308df7304a18609b30 ]
If a call to xenmem_reservation_increase() in gnttab_dma_free_pages()
fails it triggers a message "Failed to decrease reservation..." which
should be "Failed to increase reservation..."
Fixes: 9bdc7304f536 ('xen/grant-table: Allow allocating buffers suitable for
DMA')
Reported-by: Ross Philipson
Signed-off-by: Liam Merwick
Reviewed-by: Mark Kanda
Reviewed-by: Juergen Gross
Signed-off-by: Juergen Gross
Signed-off-by: Sasha Levin
---
drivers/xen/grant-table.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 84575baceebc..97341fa75458 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -914,7 +914,7 @@ int gnttab_dma_free_pages(struct gnttab_dma_alloc_args
*args)
ret = xenmem_reservation_increase(args->nr_pages, args->frames);
if (ret != args->nr_pages) {
- pr_debug("Failed to decrease reservation for DMA buffer\n");
+ pr_debug("Failed to increase reservation for DMA buffer\n");
ret = -EFAULT;
} else {
ret = 0;
--
2.17.1
[PATCH AUTOSEL 4.19 36/73] xen/grant-table: Fix incorrect gnttab_dma_free_pages() pr_debug message
From: Liam Merwick
[ Upstream commit d9cccfa7c4d1d9ef967ec9308df7304a18609b30 ]
If a call to xenmem_reservation_increase() in gnttab_dma_free_pages()
fails it triggers a message "Failed to decrease reservation..." which
should be "Failed to increase reservation..."
Fixes: 9bdc7304f536 ('xen/grant-table: Allow allocating buffers suitable for
DMA')
Reported-by: Ross Philipson
Signed-off-by: Liam Merwick
Reviewed-by: Mark Kanda
Reviewed-by: Juergen Gross
Signed-off-by: Juergen Gross
Signed-off-by: Sasha Levin
---
drivers/xen/grant-table.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 84575baceebc..97341fa75458 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -914,7 +914,7 @@ int gnttab_dma_free_pages(struct gnttab_dma_alloc_args
*args)
ret = xenmem_reservation_increase(args->nr_pages, args->frames);
if (ret != args->nr_pages) {
- pr_debug("Failed to decrease reservation for DMA buffer\n");
+ pr_debug("Failed to increase reservation for DMA buffer\n");
ret = -EFAULT;
} else {
ret = 0;
--
2.17.1
[PATCH AUTOSEL 4.19 36/73] xen/grant-table: Fix incorrect gnttab_dma_free_pages() pr_debug message
From: Liam Merwick
[ Upstream commit d9cccfa7c4d1d9ef967ec9308df7304a18609b30 ]
If a call to xenmem_reservation_increase() in gnttab_dma_free_pages()
fails it triggers a message "Failed to decrease reservation..." which
should be "Failed to increase reservation..."
Fixes: 9bdc7304f536 ('xen/grant-table: Allow allocating buffers suitable for
DMA')
Reported-by: Ross Philipson
Signed-off-by: Liam Merwick
Reviewed-by: Mark Kanda
Reviewed-by: Juergen Gross
Signed-off-by: Juergen Gross
Signed-off-by: Sasha Levin
---
drivers/xen/grant-table.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 84575baceebc..97341fa75458 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -914,7 +914,7 @@ int gnttab_dma_free_pages(struct gnttab_dma_alloc_args
*args)
ret = xenmem_reservation_increase(args->nr_pages, args->frames);
if (ret != args->nr_pages) {
- pr_debug("Failed to decrease reservation for DMA buffer\n");
+ pr_debug("Failed to increase reservation for DMA buffer\n");
ret = -EFAULT;
} else {
ret = 0;
--
2.17.1
[PATCH 4.19 156/361] xprtrdma: Reset credit grant properly after a disconnect
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Chuck Lever
[ Upstream commit ef739b2175dde9c05594f768cb78149f1ce2ac36 ]
On a fresh connection, an RPC/RDMA client is supposed to send only
one RPC Call until it gets a credit grant in the first RPC Reply
from the server [RFC 8166, Section 3.3.3].
There is a bug in the Linux client's credit accounting mechanism
introduced by commit e7ce710a8802 ("xprtrdma: Avoid deadlock when
credit window is reset"). On connect, it simply dumps all pending
RPC Calls onto the new connection.
Servers have been tolerant of this bad behavior. Currently no server
implementation ever changes its credit grant over reconnects, and
servers always repost enough Receives before connections are fully
established.
To correct this issue, ensure that the client resets both the credit
grant _and_ the congestion window when handling a reconnect.
Fixes: e7ce710a8802 ("xprtrdma: Avoid deadlock when credit ... ")
Signed-off-by: Chuck Lever
Cc: sta...@kernel.org
Signed-off-by: Anna Schumaker
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
net/sunrpc/xprtrdma/svc_rdma_backchannel.c |1 +
net/sunrpc/xprtrdma/transport.c|6 ++
2 files changed, 7 insertions(+)
--- a/net/sunrpc/xprtrdma/svc_rdma_backchannel.c
+++ b/net/sunrpc/xprtrdma/svc_rdma_backchannel.c
@@ -248,6 +248,7 @@ static void
xprt_rdma_bc_close(struct rpc_xprt *xprt)
{
dprintk("svcrdma: %s: xprt %p\n", __func__, xprt);
+ xprt->cwnd = RPC_CWNDSHIFT;
}
static void
--- a/net/sunrpc/xprtrdma/transport.c
+++ b/net/sunrpc/xprtrdma/transport.c
@@ -468,6 +468,12 @@ xprt_rdma_close(struct rpc_xprt *xprt)
xprt->reestablish_timeout = 0;
xprt_disconnect_done(xprt);
rpcrdma_ep_disconnect(ep, ia);
+
+ /* Prepare @xprt for the next connection by reinitializing
+* its credit grant to one (see RFC 8166, Section 3.3.3).
+*/
+ r_xprt->rx_buf.rb_credits = 1;
+ xprt->cwnd = RPC_CWNDSHIFT;
}
/**
[PATCH 4.19 156/361] xprtrdma: Reset credit grant properly after a disconnect
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Chuck Lever
[ Upstream commit ef739b2175dde9c05594f768cb78149f1ce2ac36 ]
On a fresh connection, an RPC/RDMA client is supposed to send only
one RPC Call until it gets a credit grant in the first RPC Reply
from the server [RFC 8166, Section 3.3.3].
There is a bug in the Linux client's credit accounting mechanism
introduced by commit e7ce710a8802 ("xprtrdma: Avoid deadlock when
credit window is reset"). On connect, it simply dumps all pending
RPC Calls onto the new connection.
Servers have been tolerant of this bad behavior. Currently no server
implementation ever changes its credit grant over reconnects, and
servers always repost enough Receives before connections are fully
established.
To correct this issue, ensure that the client resets both the credit
grant _and_ the congestion window when handling a reconnect.
Fixes: e7ce710a8802 ("xprtrdma: Avoid deadlock when credit ... ")
Signed-off-by: Chuck Lever
Cc: sta...@kernel.org
Signed-off-by: Anna Schumaker
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
net/sunrpc/xprtrdma/svc_rdma_backchannel.c |1 +
net/sunrpc/xprtrdma/transport.c|6 ++
2 files changed, 7 insertions(+)
--- a/net/sunrpc/xprtrdma/svc_rdma_backchannel.c
+++ b/net/sunrpc/xprtrdma/svc_rdma_backchannel.c
@@ -248,6 +248,7 @@ static void
xprt_rdma_bc_close(struct rpc_xprt *xprt)
{
dprintk("svcrdma: %s: xprt %p\n", __func__, xprt);
+ xprt->cwnd = RPC_CWNDSHIFT;
}
static void
--- a/net/sunrpc/xprtrdma/transport.c
+++ b/net/sunrpc/xprtrdma/transport.c
@@ -468,6 +468,12 @@ xprt_rdma_close(struct rpc_xprt *xprt)
xprt->reestablish_timeout = 0;
xprt_disconnect_done(xprt);
rpcrdma_ep_disconnect(ep, ia);
+
+ /* Prepare @xprt for the next connection by reinitializing
+* its credit grant to one (see RFC 8166, Section 3.3.3).
+*/
+ r_xprt->rx_buf.rb_credits = 1;
+ xprt->cwnd = RPC_CWNDSHIFT;
}
/**
[PATCH 4.18 158/350] xprtrdma: Reset credit grant properly after a disconnect
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Chuck Lever
[ Upstream commit ef739b2175dde9c05594f768cb78149f1ce2ac36 ]
On a fresh connection, an RPC/RDMA client is supposed to send only
one RPC Call until it gets a credit grant in the first RPC Reply
from the server [RFC 8166, Section 3.3.3].
There is a bug in the Linux client's credit accounting mechanism
introduced by commit e7ce710a8802 ("xprtrdma: Avoid deadlock when
credit window is reset"). On connect, it simply dumps all pending
RPC Calls onto the new connection.
Servers have been tolerant of this bad behavior. Currently no server
implementation ever changes its credit grant over reconnects, and
servers always repost enough Receives before connections are fully
established.
To correct this issue, ensure that the client resets both the credit
grant _and_ the congestion window when handling a reconnect.
Fixes: e7ce710a8802 ("xprtrdma: Avoid deadlock when credit ... ")
Signed-off-by: Chuck Lever
Cc: sta...@kernel.org
Signed-off-by: Anna Schumaker
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
net/sunrpc/xprtrdma/svc_rdma_backchannel.c |1 +
net/sunrpc/xprtrdma/transport.c|6 ++
2 files changed, 7 insertions(+)
--- a/net/sunrpc/xprtrdma/svc_rdma_backchannel.c
+++ b/net/sunrpc/xprtrdma/svc_rdma_backchannel.c
@@ -248,6 +248,7 @@ static void
xprt_rdma_bc_close(struct rpc_xprt *xprt)
{
dprintk("svcrdma: %s: xprt %p\n", __func__, xprt);
+ xprt->cwnd = RPC_CWNDSHIFT;
}
static void
--- a/net/sunrpc/xprtrdma/transport.c
+++ b/net/sunrpc/xprtrdma/transport.c
@@ -468,6 +468,12 @@ xprt_rdma_close(struct rpc_xprt *xprt)
xprt->reestablish_timeout = 0;
xprt_disconnect_done(xprt);
rpcrdma_ep_disconnect(ep, ia);
+
+ /* Prepare @xprt for the next connection by reinitializing
+* its credit grant to one (see RFC 8166, Section 3.3.3).
+*/
+ r_xprt->rx_buf.rb_credits = 1;
+ xprt->cwnd = RPC_CWNDSHIFT;
}
/**
[PATCH 4.18 158/350] xprtrdma: Reset credit grant properly after a disconnect
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Chuck Lever
[ Upstream commit ef739b2175dde9c05594f768cb78149f1ce2ac36 ]
On a fresh connection, an RPC/RDMA client is supposed to send only
one RPC Call until it gets a credit grant in the first RPC Reply
from the server [RFC 8166, Section 3.3.3].
There is a bug in the Linux client's credit accounting mechanism
introduced by commit e7ce710a8802 ("xprtrdma: Avoid deadlock when
credit window is reset"). On connect, it simply dumps all pending
RPC Calls onto the new connection.
Servers have been tolerant of this bad behavior. Currently no server
implementation ever changes its credit grant over reconnects, and
servers always repost enough Receives before connections are fully
established.
To correct this issue, ensure that the client resets both the credit
grant _and_ the congestion window when handling a reconnect.
Fixes: e7ce710a8802 ("xprtrdma: Avoid deadlock when credit ... ")
Signed-off-by: Chuck Lever
Cc: sta...@kernel.org
Signed-off-by: Anna Schumaker
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
net/sunrpc/xprtrdma/svc_rdma_backchannel.c |1 +
net/sunrpc/xprtrdma/transport.c|6 ++
2 files changed, 7 insertions(+)
--- a/net/sunrpc/xprtrdma/svc_rdma_backchannel.c
+++ b/net/sunrpc/xprtrdma/svc_rdma_backchannel.c
@@ -248,6 +248,7 @@ static void
xprt_rdma_bc_close(struct rpc_xprt *xprt)
{
dprintk("svcrdma: %s: xprt %p\n", __func__, xprt);
+ xprt->cwnd = RPC_CWNDSHIFT;
}
static void
--- a/net/sunrpc/xprtrdma/transport.c
+++ b/net/sunrpc/xprtrdma/transport.c
@@ -468,6 +468,12 @@ xprt_rdma_close(struct rpc_xprt *xprt)
xprt->reestablish_timeout = 0;
xprt_disconnect_done(xprt);
rpcrdma_ep_disconnect(ep, ia);
+
+ /* Prepare @xprt for the next connection by reinitializing
+* its credit grant to one (see RFC 8166, Section 3.3.3).
+*/
+ r_xprt->rx_buf.rb_credits = 1;
+ xprt->cwnd = RPC_CWNDSHIFT;
}
/**
Re: Grant
I, Mikhail Fridman have selected you specifically as one of my beneficiaries for my Charitable Donation of $5 Million Dollars, Check the link below for confirmation: https://www.rt.com/business/343781-mikhail-fridman-will-charity/ I await your earliest response for further directives. Best Regards, Mikhail Fridman.
Re: Grant
I, Mikhail Fridman have selected you specifically as one of my beneficiaries for my Charitable Donation of $5 Million Dollars, Check the link below for confirmation: https://www.rt.com/business/343781-mikhail-fridman-will-charity/ I await your earliest response for further directives. Best Regards, Mikhail Fridman.
Re: [Ksummit-discuss] The linux devs can rescind their license grant.
On Fri, Oct 26, 2018 at 12:12 AM NeilBrown wrote:
> On Thu, Oct 25 2018, Eric S. Raymond wrote:
> > Theodore Y. Ts'o :
> >> On Thu, Oct 25, 2018 at 03:39:01PM -0400, Eric S. Raymond wrote:
> >> > Under Jacobsen vs. Katzer (535 f 3d 1373 fed cir 2008) authors of
> >> > GPLed software have a specific right to relief (including injunctive
> >> > relief) against misappropriation of their software. That ruling (which
> >> > was the case of first impression on the binding status of the GPL)
> >> > reputational damage is *specifically* recognized as grounds for relief.
> >>
> >> I've read the legal briefs, and I'm pretty sure they don't say what
> >> you are claiming they say. Yes, I'm not a lawyer --- but that's OK
> >> --- neither are you.
> >
> > How much are you willing to gamble on not being wrong?
> >
> >> The *vast* majority of the "anti-CoC dissidents" who have been
> >> advancing this argument, have, as near as I can tell, little or no
> >> copyright ownership in the kernel.
> >
> > I do not have any facts with which to dispute this specific claim.
> > However, I do notice that a significant number of long-time
> > contributors have put themselves in the anti-CoC camp. I note Al Viro
> > as a recent example.
>
> I think you are blurring two groups here.
> Ted describes "anti-CoC dissidents" as people who are advancing an
> argument about rescinding their license. This is a smaller groups than
> the "ant-CoC camp" who don't really like the CoC. I suspect is it is a
> much smaller group when restricting to actual copyright holders.
>
> I am against the CoC as it stands, but rescinding any license is such an
> enormous over-reaction, I find the concept laughable.
Indeed. While I cannot comment on the legality of the rescinding, this
rescinding is definitely not compatible with "be nice to each other",
which is what all kernel developers who do not like the CoC as it
stands, and who I'm aware of, do like as a general principle.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [Ksummit-discuss] The linux devs can rescind their license grant.
On Fri, Oct 26, 2018 at 12:12 AM NeilBrown wrote:
> On Thu, Oct 25 2018, Eric S. Raymond wrote:
> > Theodore Y. Ts'o :
> >> On Thu, Oct 25, 2018 at 03:39:01PM -0400, Eric S. Raymond wrote:
> >> > Under Jacobsen vs. Katzer (535 f 3d 1373 fed cir 2008) authors of
> >> > GPLed software have a specific right to relief (including injunctive
> >> > relief) against misappropriation of their software. That ruling (which
> >> > was the case of first impression on the binding status of the GPL)
> >> > reputational damage is *specifically* recognized as grounds for relief.
> >>
> >> I've read the legal briefs, and I'm pretty sure they don't say what
> >> you are claiming they say. Yes, I'm not a lawyer --- but that's OK
> >> --- neither are you.
> >
> > How much are you willing to gamble on not being wrong?
> >
> >> The *vast* majority of the "anti-CoC dissidents" who have been
> >> advancing this argument, have, as near as I can tell, little or no
> >> copyright ownership in the kernel.
> >
> > I do not have any facts with which to dispute this specific claim.
> > However, I do notice that a significant number of long-time
> > contributors have put themselves in the anti-CoC camp. I note Al Viro
> > as a recent example.
>
> I think you are blurring two groups here.
> Ted describes "anti-CoC dissidents" as people who are advancing an
> argument about rescinding their license. This is a smaller groups than
> the "ant-CoC camp" who don't really like the CoC. I suspect is it is a
> much smaller group when restricting to actual copyright holders.
>
> I am against the CoC as it stands, but rescinding any license is such an
> enormous over-reaction, I find the concept laughable.
Indeed. While I cannot comment on the legality of the rescinding, this
rescinding is definitely not compatible with "be nice to each other",
which is what all kernel developers who do not like the CoC as it
stands, and who I'm aware of, do like as a general principle.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH AUTOSEL 4.19 112/146] xprtrdma: Reset credit grant properly after a disconnect
From: Chuck Lever
[ Upstream commit ef739b2175dde9c05594f768cb78149f1ce2ac36 ]
On a fresh connection, an RPC/RDMA client is supposed to send only
one RPC Call until it gets a credit grant in the first RPC Reply
from the server [RFC 8166, Section 3.3.3].
There is a bug in the Linux client's credit accounting mechanism
introduced by commit e7ce710a8802 ("xprtrdma: Avoid deadlock when
credit window is reset"). On connect, it simply dumps all pending
RPC Calls onto the new connection.
Servers have been tolerant of this bad behavior. Currently no server
implementation ever changes its credit grant over reconnects, and
servers always repost enough Receives before connections are fully
established.
To correct this issue, ensure that the client resets both the credit
grant _and_ the congestion window when handling a reconnect.
Fixes: e7ce710a8802 ("xprtrdma: Avoid deadlock when credit ... ")
Signed-off-by: Chuck Lever
Cc: sta...@kernel.org
Signed-off-by: Anna Schumaker
Signed-off-by: Sasha Levin
---
net/sunrpc/xprtrdma/svc_rdma_backchannel.c | 1 +
net/sunrpc/xprtrdma/transport.c| 6 ++
2 files changed, 7 insertions(+)
diff --git a/net/sunrpc/xprtrdma/svc_rdma_backchannel.c
b/net/sunrpc/xprtrdma/svc_rdma_backchannel.c
index a68180090554..b9827665ff35 100644
--- a/net/sunrpc/xprtrdma/svc_rdma_backchannel.c
+++ b/net/sunrpc/xprtrdma/svc_rdma_backchannel.c
@@ -248,6 +248,7 @@ static void
xprt_rdma_bc_close(struct rpc_xprt *xprt)
{
dprintk("svcrdma: %s: xprt %p\n", __func__, xprt);
+ xprt->cwnd = RPC_CWNDSHIFT;
}
static void
diff --git a/net/sunrpc/xprtrdma/transport.c b/net/sunrpc/xprtrdma/transport.c
index 143ce2579ba9..98cbc7b060ba 100644
--- a/net/sunrpc/xprtrdma/transport.c
+++ b/net/sunrpc/xprtrdma/transport.c
@@ -468,6 +468,12 @@ xprt_rdma_close(struct rpc_xprt *xprt)
xprt->reestablish_timeout = 0;
xprt_disconnect_done(xprt);
rpcrdma_ep_disconnect(ep, ia);
+
+ /* Prepare @xprt for the next connection by reinitializing
+* its credit grant to one (see RFC 8166, Section 3.3.3).
+*/
+ r_xprt->rx_buf.rb_credits = 1;
+ xprt->cwnd = RPC_CWNDSHIFT;
}
/**
--
2.17.1
[PATCH AUTOSEL 4.19 112/146] xprtrdma: Reset credit grant properly after a disconnect
From: Chuck Lever
[ Upstream commit ef739b2175dde9c05594f768cb78149f1ce2ac36 ]
On a fresh connection, an RPC/RDMA client is supposed to send only
one RPC Call until it gets a credit grant in the first RPC Reply
from the server [RFC 8166, Section 3.3.3].
There is a bug in the Linux client's credit accounting mechanism
introduced by commit e7ce710a8802 ("xprtrdma: Avoid deadlock when
credit window is reset"). On connect, it simply dumps all pending
RPC Calls onto the new connection.
Servers have been tolerant of this bad behavior. Currently no server
implementation ever changes its credit grant over reconnects, and
servers always repost enough Receives before connections are fully
established.
To correct this issue, ensure that the client resets both the credit
grant _and_ the congestion window when handling a reconnect.
Fixes: e7ce710a8802 ("xprtrdma: Avoid deadlock when credit ... ")
Signed-off-by: Chuck Lever
Cc: sta...@kernel.org
Signed-off-by: Anna Schumaker
Signed-off-by: Sasha Levin
---
net/sunrpc/xprtrdma/svc_rdma_backchannel.c | 1 +
net/sunrpc/xprtrdma/transport.c| 6 ++
2 files changed, 7 insertions(+)
diff --git a/net/sunrpc/xprtrdma/svc_rdma_backchannel.c
b/net/sunrpc/xprtrdma/svc_rdma_backchannel.c
index a68180090554..b9827665ff35 100644
--- a/net/sunrpc/xprtrdma/svc_rdma_backchannel.c
+++ b/net/sunrpc/xprtrdma/svc_rdma_backchannel.c
@@ -248,6 +248,7 @@ static void
xprt_rdma_bc_close(struct rpc_xprt *xprt)
{
dprintk("svcrdma: %s: xprt %p\n", __func__, xprt);
+ xprt->cwnd = RPC_CWNDSHIFT;
}
static void
diff --git a/net/sunrpc/xprtrdma/transport.c b/net/sunrpc/xprtrdma/transport.c
index 143ce2579ba9..98cbc7b060ba 100644
--- a/net/sunrpc/xprtrdma/transport.c
+++ b/net/sunrpc/xprtrdma/transport.c
@@ -468,6 +468,12 @@ xprt_rdma_close(struct rpc_xprt *xprt)
xprt->reestablish_timeout = 0;
xprt_disconnect_done(xprt);
rpcrdma_ep_disconnect(ep, ia);
+
+ /* Prepare @xprt for the next connection by reinitializing
+* its credit grant to one (see RFC 8166, Section 3.3.3).
+*/
+ r_xprt->rx_buf.rb_credits = 1;
+ xprt->cwnd = RPC_CWNDSHIFT;
}
/**
--
2.17.1
[PATCH AUTOSEL 4.18 098/126] xprtrdma: Reset credit grant properly after a disconnect
From: Chuck Lever
[ Upstream commit ef739b2175dde9c05594f768cb78149f1ce2ac36 ]
On a fresh connection, an RPC/RDMA client is supposed to send only
one RPC Call until it gets a credit grant in the first RPC Reply
from the server [RFC 8166, Section 3.3.3].
There is a bug in the Linux client's credit accounting mechanism
introduced by commit e7ce710a8802 ("xprtrdma: Avoid deadlock when
credit window is reset"). On connect, it simply dumps all pending
RPC Calls onto the new connection.
Servers have been tolerant of this bad behavior. Currently no server
implementation ever changes its credit grant over reconnects, and
servers always repost enough Receives before connections are fully
established.
To correct this issue, ensure that the client resets both the credit
grant _and_ the congestion window when handling a reconnect.
Fixes: e7ce710a8802 ("xprtrdma: Avoid deadlock when credit ... ")
Signed-off-by: Chuck Lever
Cc: sta...@kernel.org
Signed-off-by: Anna Schumaker
Signed-off-by: Sasha Levin
---
net/sunrpc/xprtrdma/svc_rdma_backchannel.c | 1 +
net/sunrpc/xprtrdma/transport.c| 6 ++
2 files changed, 7 insertions(+)
diff --git a/net/sunrpc/xprtrdma/svc_rdma_backchannel.c
b/net/sunrpc/xprtrdma/svc_rdma_backchannel.c
index a68180090554..b9827665ff35 100644
--- a/net/sunrpc/xprtrdma/svc_rdma_backchannel.c
+++ b/net/sunrpc/xprtrdma/svc_rdma_backchannel.c
@@ -248,6 +248,7 @@ static void
xprt_rdma_bc_close(struct rpc_xprt *xprt)
{
dprintk("svcrdma: %s: xprt %p\n", __func__, xprt);
+ xprt->cwnd = RPC_CWNDSHIFT;
}
static void
diff --git a/net/sunrpc/xprtrdma/transport.c b/net/sunrpc/xprtrdma/transport.c
index 143ce2579ba9..98cbc7b060ba 100644
--- a/net/sunrpc/xprtrdma/transport.c
+++ b/net/sunrpc/xprtrdma/transport.c
@@ -468,6 +468,12 @@ xprt_rdma_close(struct rpc_xprt *xprt)
xprt->reestablish_timeout = 0;
xprt_disconnect_done(xprt);
rpcrdma_ep_disconnect(ep, ia);
+
+ /* Prepare @xprt for the next connection by reinitializing
+* its credit grant to one (see RFC 8166, Section 3.3.3).
+*/
+ r_xprt->rx_buf.rb_credits = 1;
+ xprt->cwnd = RPC_CWNDSHIFT;
}
/**
--
2.17.1
