* [GIT PULL] s390 updates for 5.2-rc6
From: Heiko Carstens @ 2019-06-20 12:17 UTC (permalink / raw)
To: Linus Torvalds
Cc: Vasily Gorbik, Christian Borntraeger, linux-kernel, linux-s390
Hello Linus,
The following changes since commit d1fdb6d8f6a4109a4263176c84b899076a5f8008:
Linux 5.2-rc4 (2019-06-08 20:24:46 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git tags/s390-5.2-5
for you to fetch changes up to 11aff183225c5cf48fae074cd99d8f18ba84ed34:
vfio-ccw: Destroy kmem cache region on module exit (2019-06-13 15:52:28 +0200)
----------------------------------------------------------------
s390 updates for 5.2-rc6
- Disable address-of-packed-member warning in s390 specific boot code
to get rid of a gcc9 warning which otherwise is already disabled
for the whole kernel.
- Fix yet another compiler error seen with CONFIG_OPTIMIZE_INLINING
enabled.
- Fix memory leak in vfio-ccw code on module exit.
----------------------------------------------------------------
Farhan Ali (1):
vfio-ccw: Destroy kmem cache region on module exit
Guenter Roeck (1):
s390/ctl_reg: mark __ctl_set_bit and __ctl_clear_bit as __always_inline
Heiko Carstens (1):
s390/boot: disable address-of-packed-member warning
arch/s390/Makefile | 1 +
arch/s390/include/asm/ctl_reg.h | 4 ++--
drivers/s390/cio/vfio_ccw_drv.c | 1 +
3 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/s390/Makefile b/arch/s390/Makefile
index de8521f..e48013c 100644
--- a/arch/s390/Makefile
+++ b/arch/s390/Makefile
@@ -30,6 +30,7 @@ KBUILD_CFLAGS_DECOMPRESSOR += -DDISABLE_BRANCH_PROFILING -D__NO_FORTIFY
KBUILD_CFLAGS_DECOMPRESSOR += -fno-delete-null-pointer-checks -msoft-float
KBUILD_CFLAGS_DECOMPRESSOR += -fno-asynchronous-unwind-tables
KBUILD_CFLAGS_DECOMPRESSOR += $(call cc-option,-ffreestanding)
+KBUILD_CFLAGS_DECOMPRESSOR += $(call cc-disable-warning, address-of-packed-member)
KBUILD_CFLAGS_DECOMPRESSOR += $(if $(CONFIG_DEBUG_INFO),-g)
KBUILD_CFLAGS_DECOMPRESSOR += $(if $(CONFIG_DEBUG_INFO_DWARF4), $(call cc-option, -gdwarf-4,))
UTS_MACHINE := s390x
diff --git a/arch/s390/include/asm/ctl_reg.h b/arch/s390/include/asm/ctl_reg.h
index 4600453..3bda757 100644
--- a/arch/s390/include/asm/ctl_reg.h
+++ b/arch/s390/include/asm/ctl_reg.h
@@ -55,7 +55,7 @@
: "i" (low), "i" (high)); \
} while (0)
-static inline void __ctl_set_bit(unsigned int cr, unsigned int bit)
+static __always_inline void __ctl_set_bit(unsigned int cr, unsigned int bit)
{
unsigned long reg;
@@ -64,7 +64,7 @@ static inline void __ctl_set_bit(unsigned int cr, unsigned int bit)
__ctl_load(reg, cr, cr);
}
-static inline void __ctl_clear_bit(unsigned int cr, unsigned int bit)
+static __always_inline void __ctl_clear_bit(unsigned int cr, unsigned int bit)
{
unsigned long reg;
diff --git a/drivers/s390/cio/vfio_ccw_drv.c b/drivers/s390/cio/vfio_ccw_drv.c
index ee8767f..9125f7f 100644
--- a/drivers/s390/cio/vfio_ccw_drv.c
+++ b/drivers/s390/cio/vfio_ccw_drv.c
@@ -299,6 +299,7 @@ static void __exit vfio_ccw_sch_exit(void)
css_driver_unregister(&vfio_ccw_sch_driver);
isc_unregister(VFIO_CCW_ISC);
kmem_cache_destroy(vfio_ccw_io_region);
+ kmem_cache_destroy(vfio_ccw_cmd_region);
destroy_workqueue(vfio_ccw_work_q);
}
module_init(vfio_ccw_sch_init);
^ permalink raw reply related
* Warning!!! Email Update
From: archiver.kernel.org @ 2019-06-20 2:37 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/html, Size: 7119 bytes --]
^ permalink raw reply
* Re: [PATCH RFC] kvm: x86: Expose AVX512_BF16 feature to guest
From: Paolo Bonzini @ 2019-06-20 12:16 UTC (permalink / raw)
To: Jing Liu, kvm; +Cc: linux-kernel, jing2.liu
In-Reply-To: <1561029712-11848-2-git-send-email-jing2.liu@linux.intel.com>
On 20/06/19 13:21, Jing Liu wrote:
> + for (i = 1; i <= times; i++) {
> + if (*nent >= maxnent)
> + goto out;
> + do_cpuid_1_ent(&entry[i], function, i);
> + entry[i].eax &= F(AVX512_BF16);
> + entry[i].ebx = 0;
> + entry[i].ecx = 0;
> + entry[i].edx = 0;
> + entry[i].flags |= KVM_CPUID_FLAG_SIGNIFCANT_INDEX;
> + ++*nent;
This woud be wrong for i > 1, so instead make this
if (entry->eax >= 1)
and define F(AVX512_BF16) as a new constant kvm_cpuid_7_1_eax_features.
Paolo
^ permalink raw reply
* Re: [igt-dev] [PATCH i-g-t 5/5] docs: Embed subtest descriptions in the documentation
From: Petri Latvala @ 2019-06-20 12:16 UTC (permalink / raw)
To: Arkadiusz Hiler; +Cc: igt-dev, Daniel Vetter
In-Reply-To: <20190620113819.6pkxoqcgn6e5bdnk@ahiler-desk1.fi.intel.com>
On Thu, Jun 20, 2019 at 02:38:19PM +0300, Arkadiusz Hiler wrote:
> On Thu, Jun 20, 2019 at 02:11:59PM +0300, Petri Latvala wrote:
> > On Thu, Jun 20, 2019 at 01:52:25PM +0300, Arkadiusz Hiler wrote:
> > > On Thu, Jun 20, 2019 at 11:20:18AM +0300, Petri Latvala wrote:
> > > > On Mon, Jun 17, 2019 at 01:54:43PM +0300, Arkadiusz Hiler wrote:
> > > > > This rewrites generate_description_xml in Python, so that we generate
> > > > > properly escaped XML. The switch also makes the code more manageable.
> > > > >
> > > > > Changes in the generated docbook:
> > > > >
> > > > > 1. subtests are not simply listed anymore, they are now another (sub)section
> > > > >
> > > > > 2. subtests are now linkable,
> > > > > e.g. docs/igt-kms-tests.html#kms_hdmi_inject@inject-4k
> > > > >
> > > > > 3. subtest's section now includes output of --describe
> > > > >
> > > > > Python is required already by gtk-doc and we are not using anything
> > > > > other than the standard library.
> > > >
> > > > Python yes, but what about python3? My Debian installation is ancient
> > > > even on Debian standards and gtk-doc-tools depends on python2. I'm too
> > > > lazy to check if the version used by gitlab-CI depends on python3, so
> > > > asking instead: Do you have a fork in gitlab for this? :P
> > >
> > > It works on Fedora:
> > >
> > > % head -n 1 $(which gtkdoc-mkhtml)
> > > #!/usr/bin/python3
> > >
> > > https://gitlab.freedesktop.org/drm/igt-gpu-tools/blob/master/.gitlab-ci.yml#L174
> > >
> > >
> > > But for explicitness I can squash in:
> > >
> > > diff --git a/docs/reference/igt-gpu-tools/meson.build b/docs/reference/igt-gpu-tools/meson.build
> > > index e2bdc495..b3a4c0bd 100644
> > > --- a/docs/reference/igt-gpu-tools/meson.build
> > > +++ b/docs/reference/igt-gpu-tools/meson.build
> > > @@ -45,6 +45,7 @@ test_groups = [
> > > 'vgem',
> > > ]
> > >
> > > +find_program('python3') # required by doc generators
> > > gen_description = find_program('generate_description_xml.py')
> > > gen_programs = find_program('generate_programs_xml.sh')
> >
> >
> > For explicitness I'd prefer something the doc building can depend on
> > to automatically not build them if you don't have python3.
>
> I forgot that we have this weird conditional subdir().
>
> diff --git a/meson.build b/meson.build
> index 6268c58d..1d07af63 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -289,7 +289,8 @@ subdir('overlay')
> subdir('man')
>
> gtk_doc = dependency('gtk-doc', required : build_docs)
> -if build_tests and gtk_doc.found()
> +python3 = find_program('python3', required : build_docs)
> +if build_tests and gtk_doc.found() and python3.found()
> subdir('docs')
> elif build_docs.enabled()
> error('Documentation requires building tests')
LGTM.
Series is
Acked-by: Petri Latvala <petri.latvala@intel.com>
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* Re: [PATCH v3 0/4] x86: Always try to fill acpi_rsdp_addr in boot params
From: Simon Horman @ 2019-06-20 12:16 UTC (permalink / raw)
To: Kairui Song; +Cc: Dave Young, kexec, Lianbo Jiang, Baoquan He
In-Reply-To: <CACPcB9dOSwe1s2Z5W3ccwXSR_h_Y33cqnt2d=TPZ4hX+fpqdrA@mail.gmail.com>
On Mon, Jun 10, 2019 at 04:10:30PM +0800, Kairui Song wrote:
> On Fri, May 31, 2019 at 5:27 PM Simon Horman <horms@verge.net.au> wrote:
> >
> > On Fri, May 24, 2019 at 02:23:17PM +0800, Kairui Song wrote:
> > > This patch sync the behavior of user space kexec and kexec_file_load,
> > > they will both fill the boot_params.acpi_rsdp_addr with a valid RSDP
> > > value, to make sure second kernel can always get the RSDP consistently.
> > >
> > > This will make it effortless to boot newer version of kernel (5.0+)
> > > without specifying acpi_rsdp= cmdline on EFI system even with EFI
> > > service disabled. Should not change any behavior with older kernels.
> > >
> > > Update from V2:
> > > - Drop unneeded 'packed' attribute for boot parameters structure
> > > - Don't trust kernel cmdline as a reliable acpi rsdp source
> > >
> > > Update from V1:
> > > - Split into multiple patches for a cleaner structure, content is not
> > > changed.
> >
> > Thanks Kairui,
> >
> > applied.
>
> Hi Simon,
>
> I still haven't see this series get merged yet in the git repo, any update?
Sorry about that, it should be there now.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* Re: [PATCH RFC 0/5] x86/KVM/svm: get rid of hardcoded instructions lengths
From: Paolo Bonzini @ 2019-06-20 12:14 UTC (permalink / raw)
To: Vitaly Kuznetsov, kvm
Cc: linux-kernel, Radim Krčmář, Joerg Roedel,
Jim Mattson
In-Reply-To: <20190620110240.25799-1-vkuznets@redhat.com>
On 20/06/19 13:02, Vitaly Kuznetsov wrote:
>
> P.S. If you'd like to test the series you'll have to have a CPU without
> NRIP_SAVE feature or forcefully disable it, something like:
>
> index 8d4e50428b68..93c7eaad7915 100644
> --- a/arch/x86/kernel/cpu/amd.c
> +++ b/arch/x86/kernel/cpu/amd.c
> @@ -922,6 +922,9 @@ static void init_amd(struct cpuinfo_x86 *c)
> /* AMD CPUs don't reset SS attributes on SYSRET, Xen does. */
> if (!cpu_has(c, X86_FEATURE_XENPV))
> set_cpu_bug(c, X86_BUG_SYSRET_SS_ATTRS);
> +
> + /* No nrips */
> + clear_cpu_cap(c, X86_FEATURE_NRIPS);
> }
>
> #ifdef CONFIG_X86_32
Let's add a module parameter instead. Patch sent (forgot to Cc you).
Paolo
^ permalink raw reply
* [PATCH] KVM: svm: add nrips module parameter
From: Paolo Bonzini @ 2019-06-20 12:13 UTC (permalink / raw)
To: linux-kernel, kvm
Allow testing code for old processors that lack the next RIP save
feature, by disabling usage of the next_rip field.
Nested hypervisors however get the feature unconditionally.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
arch/x86/kvm/svm.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 735b8c01895e..fe046c13f03b 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -367,6 +367,10 @@ struct amd_svm_iommu_ir {
module_param(avic, int, S_IRUGO);
#endif
+/* enable/disable Next RIP Save */
+static int nrips = true;
+module_param(nrips, int, 0444);
+
/* enable/disable Virtual VMLOAD VMSAVE */
static int vls = true;
module_param(vls, int, 0444);
@@ -773,7 +777,7 @@ static void skip_emulated_instruction(struct kvm_vcpu *vcpu)
{
struct vcpu_svm *svm = to_svm(vcpu);
- if (svm->vmcb->control.next_rip != 0) {
+ if (nrips && svm->vmcb->control.next_rip != 0) {
WARN_ON_ONCE(!static_cpu_has(X86_FEATURE_NRIPS));
svm->next_rip = svm->vmcb->control.next_rip;
}
@@ -810,7 +814,7 @@ static void svm_queue_exception(struct kvm_vcpu *vcpu)
kvm_deliver_exception_payload(&svm->vcpu);
- if (nr == BP_VECTOR && !static_cpu_has(X86_FEATURE_NRIPS)) {
+ if (nr == BP_VECTOR && !nrips) {
unsigned long rip, old_rip = kvm_rip_read(&svm->vcpu);
/*
@@ -1367,6 +1371,11 @@ static __init int svm_hardware_setup(void)
} else
kvm_disable_tdp();
+ if (nrips) {
+ if (!boot_cpu_has(X86_FEATURE_NRIPS))
+ nrips = false;
+ }
+
if (avic) {
if (!npt_enabled ||
!boot_cpu_has(X86_FEATURE_AVIC) ||
@@ -3938,7 +3947,7 @@ static int rdpmc_interception(struct vcpu_svm *svm)
{
int err;
- if (!static_cpu_has(X86_FEATURE_NRIPS))
+ if (!nrips)
return emulate_on_interception(svm);
err = kvm_rdpmc(&svm->vcpu);
--
1.8.3.1
^ permalink raw reply related
* Re: WARNING in perf_reg_value
From: Peter Zijlstra @ 2019-06-20 12:13 UTC (permalink / raw)
To: Liang, Kan
Cc: Vince Weaver, syzbot, acme, acme, alexander.shishkin, bp, eranian,
hpa, jolsa, jolsa, linux-kernel, mingo, mingo, syzkaller-bugs,
tglx, torvalds, x86
In-Reply-To: <8ec677d7-f891-1c8b-33bd-16506974fafb@linux.intel.com>
On Wed, Jun 19, 2019 at 05:15:32PM -0400, Liang, Kan wrote:
> Here are the patches posted.
> https://lkml.org/lkml/2019/5/28/1022
How many times do I have to tell that lkml.org links are frigging
useless?
Now I have to copy/paste them into a browser, pray the site works today,
and then copy paste the subject back into my mua and hopefully find the
thread.
If you'd used the canonical form, I'd instantly have a msgid and I
could've search for that directly, without having to have to touch a
browser or hope the interweb actually works.
^ permalink raw reply
* [PULL] drm-intel-fixes
From: Jani Nikula @ 2019-06-20 12:13 UTC (permalink / raw)
To: Dave Airlie, Daniel Vetter
Cc: dim-tools, Maxime Ripard, intel-gfx, dri-devel, Rodrigo Vivi,
Sean Paul
Hi Dave & Daniel -
drm-intel-fixes-2019-06-20:
drm/i915 fixes for v5.2-rc6:
- GVT: Fix reserved PVINFO register write (Weinan)
- Avoid clobbering M/N values in fastset fuzzy checks (Ville)
BR,
Jani.
The following changes since commit 9e0babf2c06c73cda2c0cd37a1653d823adb40ec:
Linux 5.2-rc5 (2019-06-16 08:49:45 -1000)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2019-06-20
for you to fetch changes up to 475df5d0f3eb2d031e4505f84d8fba75baaf2e80:
drm/i915: Don't clobber M/N values during fastset check (2019-06-19 15:57:09 +0300)
----------------------------------------------------------------
drm/i915 fixes for v5.2-rc6:
- GVT: Fix reserved PVINFO register write (Weinan)
- Avoid clobbering M/N values in fastset fuzzy checks (Ville)
----------------------------------------------------------------
Jani Nikula (1):
Merge tag 'gvt-fixes-2019-06-19' of https://github.com/intel/gvt-linux into drm-intel-fixes
Ville Syrjälä (1):
drm/i915: Don't clobber M/N values during fastset check
Weinan Li (1):
drm/i915/gvt: ignore unexpected pvinfo write
drivers/gpu/drm/i915/gvt/handlers.c | 15 ++++++++------
drivers/gpu/drm/i915/intel_display.c | 38 +++++++++++++++++++++++++++---------
2 files changed, 38 insertions(+), 15 deletions(-)
--
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] deprecate -mem-path fallback to anonymous RAM
From: Daniel P. Berrangé @ 2019-06-20 11:52 UTC (permalink / raw)
To: Igor Mammedov; +Cc: libvir-list, qemu-devel, ehabkost
In-Reply-To: <20190620114116.27254-1-imammedo@redhat.com>
On Thu, Jun 20, 2019 at 07:41:16AM -0400, Igor Mammedov wrote:
> Fallback might affect guest or worse whole host performance
> or functionality if backing file were used to share guest RAM
> with another process.
>
> Patch deprecates fallback so that we could remove it in future
> and ensure that QEMU will provide expected behavior and fail if
> it can't use user provided backing file.
>
> Signed-off-by: Igor Mammedov <imammedo@redhat.com>
> ---
> PS:
> Patch is written on top of
> [PATCH v4 0/3] numa: deprecate '-numa node, mem' and default memory distribution
> to avoid conflicts in qemu-deprecated.texi
>
> numa.c | 4 ++--
> qemu-deprecated.texi | 8 ++++++++
> 2 files changed, 10 insertions(+), 2 deletions(-)
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v17 02/10] ACPI: add some GHES structures and macros definition
From: Igor Mammedov @ 2019-06-20 12:10 UTC (permalink / raw)
To: Dongjiu Geng
Cc: pbonzini, mst, shannon.zhaosl, peter.maydell, lersek, james.morse,
mtosatti, rth, ehabkost, zhengxiang9, jonathan.cameron, xuwei5,
kvm, qemu-devel, qemu-arm, linuxarm
In-Reply-To: <1557832703-42620-3-git-send-email-gengdongjiu@huawei.com>
On Tue, 14 May 2019 04:18:15 -0700
Dongjiu Geng <gengdongjiu@huawei.com> wrote:
> Add Generic Error Status Block structures and some macros
> definitions, which is referred to the ACPI 4.0 or ACPI 6.2. The
> HEST table generation and CPER record will use them.
>
> Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
> ---
> include/hw/acpi/acpi-defs.h | 52 +++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 52 insertions(+)
>
> diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h
> index f9aa4bd..d1996fb 100644
> --- a/include/hw/acpi/acpi-defs.h
> +++ b/include/hw/acpi/acpi-defs.h
> @@ -224,6 +224,25 @@ typedef struct AcpiMultipleApicTable AcpiMultipleApicTable;
> #define ACPI_APIC_RESERVED 16 /* 16 and greater are reserved */
>
> /*
> + * Values for Hardware Error Notification Type field
> + */
> +enum AcpiHestNotifyType {
> + ACPI_HEST_NOTIFY_POLLED = 0,
> + ACPI_HEST_NOTIFY_EXTERNAL = 1,
> + ACPI_HEST_NOTIFY_LOCAL = 2,
> + ACPI_HEST_NOTIFY_SCI = 3,
> + ACPI_HEST_NOTIFY_NMI = 4,
> + ACPI_HEST_NOTIFY_CMCI = 5, /* ACPI 5.0: 18.3.2.7, Table 18-290 */
> + ACPI_HEST_NOTIFY_MCE = 6, /* ACPI 5.0: 18.3.2.7, Table 18-290 */
> + ACPI_HEST_NOTIFY_GPIO = 7, /* ACPI 6.0: 18.3.2.7, Table 18-332 */
> + ACPI_HEST_NOTIFY_SEA = 8, /* ACPI 6.1: 18.3.2.9, Table 18-345 */
> + ACPI_HEST_NOTIFY_SEI = 9, /* ACPI 6.1: 18.3.2.9, Table 18-345 */
> + ACPI_HEST_NOTIFY_GSIV = 10, /* ACPI 6.1: 18.3.2.9, Table 18-345 */
> + ACPI_HEST_NOTIFY_SDEI = 11, /* ACPI 6.2: 18.3.2.9, Table 18-383 */
> + ACPI_HEST_NOTIFY_RESERVED = 12 /* 12 and greater are reserved */
> +};
> +
> +/*
> * MADT sub-structures (Follow MULTIPLE_APIC_DESCRIPTION_TABLE)
> */
> #define ACPI_SUB_HEADER_DEF /* Common ACPI sub-structure header */\
> @@ -400,6 +419,39 @@ struct AcpiSystemResourceAffinityTable {
> } QEMU_PACKED;
> typedef struct AcpiSystemResourceAffinityTable AcpiSystemResourceAffinityTable;
>
> +/*
> + * Generic Error Status Block
> + */
> +struct AcpiGenericErrorStatus {
> + /* It is a bitmask composed of ACPI_GEBS_xxx macros */
> + uint32_t block_status;
> + uint32_t raw_data_offset;
> + uint32_t raw_data_length;
> + uint32_t data_length;
> + uint32_t error_severity;
> +} QEMU_PACKED;
> +typedef struct AcpiGenericErrorStatus AcpiGenericErrorStatus;
there shouldn't be packed structures,
is it a leftover from previous version?
> +
> +/*
> + * Masks for block_status flags above
> + */
> +#define ACPI_GEBS_UNCORRECTABLE 1
> +
> +/*
> + * Values for error_severity field above
> + */
> +enum AcpiGenericErrorSeverity {
> + ACPI_CPER_SEV_RECOVERABLE,
> + ACPI_CPER_SEV_FATAL,
> + ACPI_CPER_SEV_CORRECTED,
> + ACPI_CPER_SEV_NONE,
> +};
> +
> +/*
> + * Generic Hardware Error Source version 2
> + */
> +#define ACPI_HEST_SOURCE_GENERIC_ERROR_V2 10
> +
> #define ACPI_SRAT_PROCESSOR_APIC 0
> #define ACPI_SRAT_MEMORY 1
> #define ACPI_SRAT_PROCESSOR_x2APIC 2
^ permalink raw reply
* Re: [PATCH v7 1/5] usb: fsl: Set USB_EN bit to select ULPI phy
From: Greg Kroah-Hartman @ 2019-06-20 12:10 UTC (permalink / raw)
To: Yinbo Zhu
Cc: Alan Stern, xiaobo.xie, jiafei.pan, Ramneek Mehresh,
Nikhil Badola, Ran Wang, linux-usb, linux-kernel
In-Reply-To: <20190614085433.22344-1-yinbo.zhu@nxp.com>
On Fri, Jun 14, 2019 at 04:54:29PM +0800, Yinbo Zhu wrote:
> From: Nikhil Badola <nikhil.badola@freescale.com>
>
> Set USB_EN bit to select ULPI phy for USB controller version 2.5
>
> Signed-off-by: Nikhil Badola <nikhil.badola@freescale.com>
> Signed-off-by: Yinbo Zhu <yinbo.zhu@nxp.com>
> ---
> drivers/usb/host/ehci-fsl.c | 6 ++++++
> 1 file changed, 6 insertions(+)
What changed from v1-v7? That should always go below the --- line.
Please fix up when you resend v8.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] time/tick-broadcast: Fix tick_broadcast_offline() lockdep complaint
From: Peter Zijlstra @ 2019-06-20 12:10 UTC (permalink / raw)
To: Paul E. McKenney; +Cc: linux-kernel, mingo, frederic, tglx
In-Reply-To: <20190619181903.GA14233@linux.ibm.com>
On Wed, Jun 19, 2019 at 11:19:03AM -0700, Paul E. McKenney wrote:
> [ Hearing no objections and given no test failures in multiple weeks of
> rcutorture testing, I intend to submit this to the upcoming merge
> window. Thoughts? ]
I can't remember seeing this before; but then, there's a ton of unread
email in the inbox :-(
> Some debugging code showed that the culprit was sched_cpu_dying().
> It had irqs enabled after return from sched_tick_stop(). Which in turn
> had irqs enabled after return from cancel_delayed_work_sync(). Which is a
> wrapper around __cancel_work_timer(). Which can sleep in the case where
> something else is concurrently trying to cancel the same delayed work,
> and as Thomas Gleixner pointed out on IRC, sleeping is a decidedly bad
> idea when you are invoked from take_cpu_down(), regardless of the state
> you leave interrupts in upon return.
>
> Code inspection located no reason why the delayed work absolutely
> needed to be canceled from sched_tick_stop(): The work is not
> bound to the outgoing CPU by design, given that the whole point is
> to collect statistics without disturbing the outgoing CPU.
>
> This commit therefore simply drops the cancel_delayed_work_sync() from
> sched_tick_stop(). Instead, a new ->state field is added to the tick_work
> structure so that the delayed-work handler function sched_tick_remote()
> can avoid reposting itself. A cpu_is_offline() check is also added to
> sched_tick_remote() to avoid mucking with the state of an offlined CPU
> (though it does appear safe to do so). The sched_tick_start() and
> sched_tick_stop() functions also update ->state, and sched_tick_start()
> also schedules the delayed work if ->state indicates that it is not
> already in flight.
>
> Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 102dfcf0a29a..8409c83aa5fa 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -3050,14 +3050,44 @@ void scheduler_tick(void)
>
> struct tick_work {
> int cpu;
> + int state;
> struct delayed_work work;
> };
> +// Values for ->state, see diagram below.
> +#define TICK_SCHED_REMOTE_OFFLINE 0
> +#define TICK_SCHED_REMOTE_RUNNING 1
> +#define TICK_SCHED_REMOTE_OFFLINING 2
That seems a daft set of values; consider { RUNNING, OFFLINING, OFFLINE }
and see below.
> +
> +// State diagram for ->state:
> +//
> +//
> +// +----->OFFLINE--------------------------+
> +// | |
> +// | |
> +// | | sched_tick_start()
> +// | sched_tick_remote() |
> +// | |
> +// | V
> +// | +---------->RUNNING
> +// | | |
> +// | | |
> +// | | |
> +// | sched_tick_start() | | sched_tick_stop()
> +// | | |
> +// | | |
> +// | | |
> +// +--------------------OFFLINING<---------+
> +//
> +//
> +// Other transitions get WARN_ON_ONCE(), except that sched_tick_remote()
> +// and sched_tick_start() are happy to leave the state in RUNNING.
Can we please stick to old skool C comments?
Also, I find it harder to read that needed, maybe a little something
like so:
/*
* OFFLINE
* | ^
* | | tick_remote()
* | |
* +--OFFLINING
* | ^
* tick_start() | | tick_stop()
* v |
* RUNNING
*/
> static struct tick_work __percpu *tick_work_cpu;
>
> static void sched_tick_remote(struct work_struct *work)
> {
> struct delayed_work *dwork = to_delayed_work(work);
> + int os;
this should go at the end, reverse xmas tree preference and all that.
> struct tick_work *twork = container_of(dwork, struct tick_work, work);
> int cpu = twork->cpu;
> struct rq *rq = cpu_rq(cpu);
> @@ -3077,7 +3107,7 @@ static void sched_tick_remote(struct work_struct *work)
>
> rq_lock_irq(rq, &rf);
> curr = rq->curr;
> - if (is_idle_task(curr))
> + if (is_idle_task(curr) || cpu_is_offline(cpu))
> goto out_unlock;
>
> update_rq_clock(rq);
> @@ -3097,13 +3127,22 @@ static void sched_tick_remote(struct work_struct *work)
> /*
> * Run the remote tick once per second (1Hz). This arbitrary
> * frequency is large enough to avoid overload but short enough
> - * to keep scheduler internal stats reasonably up to date.
> + * to keep scheduler internal stats reasonably up to date. But
> + * first update state to reflect hotplug activity if required.
> */
> - queue_delayed_work(system_unbound_wq, dwork, HZ);
> + do {
> + os = READ_ONCE(twork->state);
> + WARN_ON_ONCE(os == TICK_SCHED_REMOTE_OFFLINE);
> + if (os == TICK_SCHED_REMOTE_RUNNING)
> + break;
> + } while (cmpxchg(&twork->state, os, TICK_SCHED_REMOTE_OFFLINE) != os);
> + if (os == TICK_SCHED_REMOTE_RUNNING)
> + queue_delayed_work(system_unbound_wq, dwork, HZ);
> }
>
> static void sched_tick_start(int cpu)
> {
> + int os;
> struct tick_work *twork;
>
> if (housekeeping_cpu(cpu, HK_FLAG_TICK))
> @@ -3112,14 +3151,23 @@ static void sched_tick_start(int cpu)
> WARN_ON_ONCE(!tick_work_cpu);
>
> twork = per_cpu_ptr(tick_work_cpu, cpu);
> - twork->cpu = cpu;
> - INIT_DELAYED_WORK(&twork->work, sched_tick_remote);
> - queue_delayed_work(system_unbound_wq, &twork->work, HZ);
> + do {
> + os = READ_ONCE(twork->state);
> + if (WARN_ON_ONCE(os == TICK_SCHED_REMOTE_RUNNING))
> + break;
> + // Either idle or offline for a short period
> + } while (cmpxchg(&twork->state, os, TICK_SCHED_REMOTE_RUNNING) != os);
> + if (os == TICK_SCHED_REMOTE_OFFLINE) {
> + twork->cpu = cpu;
> + INIT_DELAYED_WORK(&twork->work, sched_tick_remote);
> + queue_delayed_work(system_unbound_wq, &twork->work, HZ);
> + }
> }
>
> #ifdef CONFIG_HOTPLUG_CPU
> static void sched_tick_stop(int cpu)
> {
> + int os;
> struct tick_work *twork;
>
> if (housekeeping_cpu(cpu, HK_FLAG_TICK))
> @@ -3128,7 +3176,13 @@ static void sched_tick_stop(int cpu)
> WARN_ON_ONCE(!tick_work_cpu);
>
> twork = per_cpu_ptr(tick_work_cpu, cpu);
> - cancel_delayed_work_sync(&twork->work);
> + // There cannot be competing actions, but don't rely on stop_machine.
> + do {
> + os = READ_ONCE(twork->state);
> + WARN_ON_ONCE(os != TICK_SCHED_REMOTE_RUNNING);
> + // Either idle or offline for a short period
> + } while (cmpxchg(&twork->state, os, TICK_SCHED_REMOTE_OFFLINING) != os);
> + // Don't cancel, as this would mess up the state machine.
> }
> #endif /* CONFIG_HOTPLUG_CPU */
While not wrong, it seems overly complicated; can't we do something
like:
tick:
state = atomic_read(->state);
if (state) {
WARN_ON_ONCE(state != OFFLINING);
if (atomic_inc_not_zero(->state))
return;
}
queue_delayed_work();
stop:
/*
* This is hotplug; even without stop-machine, there cannot be
* concurrency on offlining specific CPUs.
*/
state = atomic_read(->state);
WARN_ON_ONCE(state != RUNNING);
atomic_set(->state, OFFLINING);
start:
state = atomic_xchg(->state, RUNNING);
WARN_ON_ONCE(state == RUNNING);
if (state == OFFLINE) {
// ...
queue_delayed_work();
}
^ permalink raw reply
* RE: [EXT] Re: [PATCH net-next 4/4] qed: Add devlink support for configuration attributes.
From: Sudarsana Reddy Kalluru @ 2019-06-20 12:09 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem@davemloft.net, netdev@vger.kernel.org, Michal Kalderon,
Ariel Elior, Jiri Pirko
In-Reply-To: <20190617155411.53cf07cf@cakuba.netronome.com>
> -----Original Message-----
> From: Jakub Kicinski <jakub.kicinski@netronome.com>
> Sent: Tuesday, June 18, 2019 4:24 AM
> To: Sudarsana Reddy Kalluru <skalluru@marvell.com>
> Cc: davem@davemloft.net; netdev@vger.kernel.org; Michal Kalderon
> <mkalderon@marvell.com>; Ariel Elior <aelior@marvell.com>; Jiri Pirko
> <jiri@resnulli.us>
> Subject: [EXT] Re: [PATCH net-next 4/4] qed: Add devlink support for
> configuration attributes.
>
> External Email
>
> ----------------------------------------------------------------------
> On Mon, 17 Jun 2019 04:45:28 -0700, Sudarsana Reddy Kalluru wrote:
> > This patch adds implementation for devlink callbacks for reading/
> > configuring the device attributes.
> >
> > Signed-off-by: Sudarsana Reddy Kalluru <skalluru@marvell.com>
> > Signed-off-by: Ariel Elior <aelior@marvell.com>
>
> You need to provide documentation for your parameters, plus some of them
> look like they should potentially be port params, not device params.
Thanks a lot for your review. Will add the required documentation. In case of Marvell adapter, any of the device/adapter/port parameters can be read/configurable via any PF (ethdev) on the port. Hence adding the commands at device level. Hope this is fine.
^ permalink raw reply
* Re: [PATCH v7 4/5] usb: host: Stops USB controller init if PLL fails to lock
From: Greg Kroah-Hartman @ 2019-06-20 12:10 UTC (permalink / raw)
To: Yinbo Zhu
Cc: Alan Stern, xiaobo.xie, jiafei.pan, Ramneek Mehresh,
Nikhil Badola, Ran Wang, linux-usb, linux-kernel
In-Reply-To: <20190614085433.22344-4-yinbo.zhu@nxp.com>
On Fri, Jun 14, 2019 at 04:54:32PM +0800, Yinbo Zhu wrote:
> From: Ramneek Mehresh <ramneek.mehresh@freescale.com>
>
> USB erratum-A006918 workaround tries to start internal PHY inside
> uboot (when PLL fails to lock). However, if the workaround also
> fails, then USB initialization is also stopped inside Linux.
> Erratum-A006918 workaround failure creates "fsl,erratum_a006918"
> node in device-tree. Presence of this node in device-tree is
> used to stop USB controller initialization in Linux
>
> Signed-off-by: Ramneek Mehresh <ramneek.mehresh@freescale.com>
> Signed-off-by: Suresh Gupta <suresh.gupta@freescale.com>
> Signed-off-by: Yinbo Zhu <yinbo.zhu@nxp.com>
> ---
> Change in v7:
> keep v5 version "fall through"
>
> drivers/usb/host/ehci-fsl.c | 9 +++++++++
> drivers/usb/host/fsl-mph-dr-of.c | 3 ++-
> 2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
> index 8f3bf3efb038..ef3dfd33a62e 100644
> --- a/drivers/usb/host/ehci-fsl.c
> +++ b/drivers/usb/host/ehci-fsl.c
> @@ -236,6 +236,15 @@ static int ehci_fsl_setup_phy(struct usb_hcd *hcd,
> portsc |= PORT_PTS_PTW;
> /* fall through */
> case FSL_USB2_PHY_UTMI:
> + /* Presence of this node "has_fsl_erratum_a006918"
> + * in device-tree is used to stop USB controller
> + * initialization in Linux
> + */
> + if (pdata->has_fsl_erratum_a006918) {
> + dev_warn(dev, "USB PHY clock invalid\n");
> + return -EINVAL;
> + }
> +
You need a /* fall through */ comment here, right?
thanks,
greg k-h
^ permalink raw reply
* Re: cifs: Fix tracing build error with O=
From: Masahiro Yamada @ 2019-06-20 11:56 UTC (permalink / raw)
To: Herbert Xu; +Cc: stfrench, linux-cifs, Linux Kernel Mailing List
In-Reply-To: <20190620075838.sthw4kjpp2gt6t6j@gondor.apana.org.au>
On Thu, Jun 20, 2019 at 4:58 PM Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> On Thu, Jun 20, 2019 at 06:54:42AM +0000, yamada.masahiro@socionext.com wrote:
> >
> > I cannot reproduce the build error on the latest Linus tree.
> >
> >
> > $ make O=build allmodconfig fs/cifs/
> >
> > perfectly works for me.
>
> I was trying to build just the fs/cifs directory with
>
> make O=build M=fs/cifs
>
> But I see now that this can't possibly work as M= only supports
> absolute paths. As M= is supposed to replace SUBDIRS=, what are
> we supposed to do to build just a directory?
Documentation/kbuild/kbuild.txt says
M= and KBUILD_EXTMOD (and older form SUBDIRS= too)
are for building external modules.
Yet, many people still wrongly use them to build
in-kernel directories just because they seem to work
(but do not really).
The similar question, and the answer is here:
https://lkml.org/lkml/2019/1/17/584
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH v3 0/6] crypto: switch to crypto API for ESSIV generation
From: Milan Broz @ 2019-06-20 12:09 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-crypto, Herbert Xu, Eric Biggers, device-mapper development,
linux-fscrypt, Gilad Ben-Yossef
In-Reply-To: <CAKv+Gu9jk8KxWykTcKeh6k0HUb47wgx7iZYuwwN8AUyErFLXxA@mail.gmail.com>
On 20/06/2019 13:54, Ard Biesheuvel wrote:
> On Thu, 20 Jun 2019 at 13:22, Milan Broz <gmazyland@gmail.com> wrote:
>>
>> On 19/06/2019 18:29, Ard Biesheuvel wrote:
>>> This series creates an ESSIV template that produces a skcipher or AEAD
>>> transform based on a tuple of the form '<skcipher>,<cipher>,<shash>'
>>> (or '<aead>,<cipher>,<shash>' for the AEAD case). It exposes the
>>> encapsulated sync or async skcipher/aead by passing through all operations,
>>> while using the cipher/shash pair to transform the input IV into an ESSIV
>>> output IV.
>>>
>>> This matches what both users of ESSIV in the kernel do, and so it is proposed
>>> as a replacement for those, in patches #2 and #4.
>>>
>>> This code has been tested using the fscrypt test suggested by Eric
>>> (generic/549), as well as the mode-test script suggested by Milan for
>>> the dm-crypt case. I also tested the aead case in a virtual machine,
>>> but it definitely needs some wider testing from the dm-crypt experts.
>>>
>>> Changes since v2:
>>> - fixed a couple of bugs that snuck in after I'd done the bulk of my
>>> testing
>>> - some cosmetic tweaks to the ESSIV template skcipher setkey function
>>> to align it with the aead one
>>> - add a test case for essiv(cbc(aes),aes,sha256)
>>> - add an accelerated implementation for arm64 that combines the IV
>>> derivation and the actual en/decryption in a single asm routine
>>
>> I run tests for the whole patchset, including some older scripts and seems
>> it works for dm-crypt now.
>>
>
> Thanks Milan, that is really helpful.
>
> Does this include configurations that combine authenc with essiv?
Hm, seems that we are missing these in luks2-integrity-test. I'll add them there.
I also used this older test
https://gitlab.com/omos/dm-crypt-test-scripts/blob/master/root/test_dmintegrity.sh
(just aes-gcm-random need to be commented out, we never supported this format, it was
written for some devel version)
But seems ESSIV is there tested only without AEAD composition...
So yes, this AEAD part need more testing.
Milan
^ permalink raw reply
* Re: [PATCH net] ipvs: fix tinfo memory leak in start_sync_thread
From: Simon Horman @ 2019-06-20 12:09 UTC (permalink / raw)
To: Julian Anastasov; +Cc: lvs-devel, Pablo Neira Ayuso, netfilter-devel
In-Reply-To: <20190618200736.7531-1-ja@ssi.bg>
On Tue, Jun 18, 2019 at 11:07:36PM +0300, Julian Anastasov wrote:
> syzkaller reports for memory leak in start_sync_thread [1]
>
> As Eric points out, kthread may start and stop before the
> threadfn function is called, so there is no chance the
> data (tinfo in our case) to be released in thread.
>
> Fix this by releasing tinfo in the controlling code instead.
>
> [1]
> BUG: memory leak
> unreferenced object 0xffff8881206bf700 (size 32):
> comm "syz-executor761", pid 7268, jiffies 4294943441 (age 20.470s)
> hex dump (first 32 bytes):
> 00 40 7c 09 81 88 ff ff 80 45 b8 21 81 88 ff ff .@|......E.!....
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> backtrace:
> [<0000000057619e23>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline]
> [<0000000057619e23>] slab_post_alloc_hook mm/slab.h:439 [inline]
> [<0000000057619e23>] slab_alloc mm/slab.c:3326 [inline]
> [<0000000057619e23>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553
> [<0000000086ce5479>] kmalloc include/linux/slab.h:547 [inline]
> [<0000000086ce5479>] start_sync_thread+0x5d2/0xe10 net/netfilter/ipvs/ip_vs_sync.c:1862
> [<000000001a9229cc>] do_ip_vs_set_ctl+0x4c5/0x780 net/netfilter/ipvs/ip_vs_ctl.c:2402
> [<00000000ece457c8>] nf_sockopt net/netfilter/nf_sockopt.c:106 [inline]
> [<00000000ece457c8>] nf_setsockopt+0x4c/0x80 net/netfilter/nf_sockopt.c:115
> [<00000000942f62d4>] ip_setsockopt net/ipv4/ip_sockglue.c:1258 [inline]
> [<00000000942f62d4>] ip_setsockopt+0x9b/0xb0 net/ipv4/ip_sockglue.c:1238
> [<00000000a56a8ffd>] udp_setsockopt+0x4e/0x90 net/ipv4/udp.c:2616
> [<00000000fa895401>] sock_common_setsockopt+0x38/0x50 net/core/sock.c:3130
> [<0000000095eef4cf>] __sys_setsockopt+0x98/0x120 net/socket.c:2078
> [<000000009747cf88>] __do_sys_setsockopt net/socket.c:2089 [inline]
> [<000000009747cf88>] __se_sys_setsockopt net/socket.c:2086 [inline]
> [<000000009747cf88>] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2086
> [<00000000ded8ba80>] do_syscall_64+0x76/0x1a0 arch/x86/entry/common.c:301
> [<00000000893b4ac8>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> Reported-by: syzbot+7e2e50c8adfccd2e5041@syzkaller.appspotmail.com
> Suggested-by: Eric Biggers <ebiggers@kernel.org>
> Fixes: 998e7a76804b ("ipvs: Use kthread_run() instead of doing a double-fork via kernel_thread()")
> Signed-off-by: Julian Anastasov <ja@ssi.bg>
Thanks Julian.
Pablo, please consider this for inclusion in nf.
Acked-by: Simon Horman <horms@verge.net.au>
^ permalink raw reply
* Re: [PATCH v3 0/6] crypto: switch to crypto API for ESSIV generation
From: Milan Broz @ 2019-06-20 12:09 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Herbert Xu, Eric Biggers, linux-fscrypt, Gilad Ben-Yossef,
device-mapper development, linux-crypto
In-Reply-To: <CAKv+Gu9jk8KxWykTcKeh6k0HUb47wgx7iZYuwwN8AUyErFLXxA@mail.gmail.com>
On 20/06/2019 13:54, Ard Biesheuvel wrote:
> On Thu, 20 Jun 2019 at 13:22, Milan Broz <gmazyland@gmail.com> wrote:
>>
>> On 19/06/2019 18:29, Ard Biesheuvel wrote:
>>> This series creates an ESSIV template that produces a skcipher or AEAD
>>> transform based on a tuple of the form '<skcipher>,<cipher>,<shash>'
>>> (or '<aead>,<cipher>,<shash>' for the AEAD case). It exposes the
>>> encapsulated sync or async skcipher/aead by passing through all operations,
>>> while using the cipher/shash pair to transform the input IV into an ESSIV
>>> output IV.
>>>
>>> This matches what both users of ESSIV in the kernel do, and so it is proposed
>>> as a replacement for those, in patches #2 and #4.
>>>
>>> This code has been tested using the fscrypt test suggested by Eric
>>> (generic/549), as well as the mode-test script suggested by Milan for
>>> the dm-crypt case. I also tested the aead case in a virtual machine,
>>> but it definitely needs some wider testing from the dm-crypt experts.
>>>
>>> Changes since v2:
>>> - fixed a couple of bugs that snuck in after I'd done the bulk of my
>>> testing
>>> - some cosmetic tweaks to the ESSIV template skcipher setkey function
>>> to align it with the aead one
>>> - add a test case for essiv(cbc(aes),aes,sha256)
>>> - add an accelerated implementation for arm64 that combines the IV
>>> derivation and the actual en/decryption in a single asm routine
>>
>> I run tests for the whole patchset, including some older scripts and seems
>> it works for dm-crypt now.
>>
>
> Thanks Milan, that is really helpful.
>
> Does this include configurations that combine authenc with essiv?
Hm, seems that we are missing these in luks2-integrity-test. I'll add them there.
I also used this older test
https://gitlab.com/omos/dm-crypt-test-scripts/blob/master/root/test_dmintegrity.sh
(just aes-gcm-random need to be commented out, we never supported this format, it was
written for some devel version)
But seems ESSIV is there tested only without AEAD composition...
So yes, this AEAD part need more testing.
Milan
^ permalink raw reply
* Re: [RFC PATCH 7/7] rslib: Fix remaining decoder flaws
From: Ferdinand Blomqvist @ 2019-06-20 12:09 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: linux-kernel
In-Reply-To: <alpine.DEB.2.21.1906172249580.1963@nanos.tec.linutronix.de>
Hi,
On 2019-06-17 23:00:27, Thomas Gleixner wrote:
>On Sat, 30 Mar 2019, Ferdinand Blomqvist wrote:
>> The decoder is flawed in the following ways:
>
>...
>
>Aside of the fact that I had to wrap my brain around this crime I committed
>more than a decade ago, all of this was really a pleasure to review.
>
>Thanks a lot for putting that effort in! I'm looking forward to V2 of that.
>
>Thanks,
>
> tglx
Thanks for the review and comments! Will submit V2 shortly. Hopefully it
addresses all concerns and suggestions in a satisfactory way.
Best,
Ferdinand
^ permalink raw reply
* Re: [PATCH] usb: remove redundant 'default n' from Kconfig-s
From: Greg Kroah-Hartman @ 2019-06-20 12:08 UTC (permalink / raw)
To: Felipe Balbi
Cc: Bartlomiej Zolnierkiewicz, Minas Harutyunyan, linux-kernel,
linux-usb
In-Reply-To: <874l4ngxl5.fsf@linux.intel.com>
On Tue, Jun 18, 2019 at 10:29:58AM +0300, Felipe Balbi wrote:
> Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> writes:
>
> > 'default n' is the default value for any bool or tristate Kconfig
> > setting so there is no need to write it explicitly.
> >
> > Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
> > is not set' for visible symbols") the Kconfig behavior is the same
> > regardless of 'default n' being present or not:
> >
> > ...
> > One side effect of (and the main motivation for) this change is making
> > the following two definitions behave exactly the same:
> >
> > config FOO
> > bool
> >
> > config FOO
> > bool
> > default n
> >
> > With this change, neither of these will generate a
> > '# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
> > That might make it clearer to people that a bare 'default n' is
> > redundant.
> > ...
> >
> > Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
>
> Fine by me. Greg if you want to take this directly (since it touches
> things all over the place):
>
> Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
>
> If you prefer that I put this in my pull request to you, just let me know.
I think I already took this :)
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v4 0/7] tcg/ppc: Add vector opcodes
From: Howard Spoelstra @ 2019-06-20 11:51 UTC (permalink / raw)
To: Mark Cave-Ayland; +Cc: Richard Henderson, qemu-devel qemu-devel, David Gibson
In-Reply-To: <085d6881-f518-9888-a13e-081cdc09de46@ilande.co.uk>
Hi,
As reported before, qemu-system-ppc still crashes with a segmentation fault
on Lubuntu 16 on a G5. Built from current tcg-ppc-vsx branch.
Linux hsp-G5-Lubuntu 4.4.0-143-powerpc64-smp #169-Ubuntu SMP Thu Feb 7
08:25:49 UTC 2019 ppc64 ppc64 ppc64 GNU/Linux
hsp@hsp-G5-Lubuntu:~$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/powerpc-linux-gnu/5/lto-wrapper
Target: powerpc-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.4.0-6ubuntu1~16.04.11'
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-powerpc/jre
--enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-powerpc
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-powerpc
--with-arch-directory=ppc --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-secureplt --disable-softfloat
--with-cpu=default32 --disable-softfloat
--enable-targets=powerpc-linux,powerpc64-linux --enable-multiarch
--disable-werror --with-long-double-128 --enable-multilib
--enable-checking=release --build=powerpc-linux-gnu
--host=powerpc-linux-gnu --target=powerpc-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.11)
<https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg06561.html>
Best,
Howard.
^ permalink raw reply
* Re: [dpdk-dev] [PATCH 2/3] ipsec: fix transport mode for ipv6 with extensions
From: Akhil Goyal @ 2019-06-20 12:07 UTC (permalink / raw)
To: Marcin Smoczynski, marko.kovacevic@intel.com, orika@mellanox.com,
bruce.richardson@intel.com, pablo.de.lara.guarch@intel.com,
radu.nicolau@intel.com, tomasz.kantecki@intel.com,
konstantin.ananyev@intel.com, bernard.iremonger@intel.com,
olivier.matz@6wind.com
Cc: dev@dpdk.org
In-Reply-To: <20190508104717.13448-2-marcinx.smoczynski@intel.com>
Hi Marcin,
>
> Reconstructing IPv6 header after encryption or decryption requires
> updating 'next header' value in the preceding protocol header, which
> is determined by parsing IPv6 header and iteratively looking for
> next IPv6 header extension.
>
> It is required that 'l3_len' in the mbuf metadata contains a total
> length of the IPv6 header with header extensions up to ESP header.
>
> Signed-off-by: Marcin Smoczynski <marcinx.smoczynski@intel.com>
> ---
> lib/Makefile | 3 ++-
> lib/librte_ipsec/iph.h | 55 ++++++++++++++++++++++++++++++++++++------
> 2 files changed, 49 insertions(+), 9 deletions(-)
>
> diff --git a/lib/Makefile b/lib/Makefile
> index 791e0d991..3ad579f68 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -108,7 +108,8 @@ DEPDIRS-librte_gso += librte_mempool
> DIRS-$(CONFIG_RTE_LIBRTE_BPF) += librte_bpf
> DEPDIRS-librte_bpf := librte_eal librte_mempool librte_mbuf librte_ethdev
> DIRS-$(CONFIG_RTE_LIBRTE_IPSEC) += librte_ipsec
> -DEPDIRS-librte_ipsec := librte_eal librte_mbuf librte_cryptodev librte_security
> +DEPDIRS-librte_ipsec := librte_eal librte_mbuf librte_cryptodev librte_security \
> + librte_net
A nit.
Please update the comment in lib/meson.build file for the dependencies. Currently it is only for crypto and security.
> DIRS-$(CONFIG_RTE_LIBRTE_TELEMETRY) += librte_telemetry
> DEPDIRS-librte_telemetry := librte_eal librte_metrics librte_ethdev
> DIRS-$(CONFIG_RTE_LIBRTE_RCU) += librte_rcu
> diff --git a/lib/librte_ipsec/iph.h b/lib/librte_ipsec/iph.h
> index 58930cf18..082e4e73e 100644
> --- a/lib/librte_ipsec/iph.h
> +++ b/lib/librte_ipsec/iph.h
> @@ -5,6 +5,8 @@
> #ifndef _IPH_H_
> #define _IPH_H_
>
> +#include <rte_ip.h>
> +
> /**
> * @file iph.h
> * Contains functions/structures/macros to manipulate IPv4/IPv6 headers
> @@ -40,24 +42,61 @@ static inline int
> update_trs_l3hdr(const struct rte_ipsec_sa *sa, void *p, uint32_t plen,
> uint32_t l2len, uint32_t l3len, uint8_t proto)
> {
> - struct ipv4_hdr *v4h;
> - struct ipv6_hdr *v6h;
> int32_t rc;
>
> + /* IPv4 */
> if ((sa->type & RTE_IPSEC_SATP_IPV_MASK) == RTE_IPSEC_SATP_IPV4) {
> + struct ipv4_hdr *v4h;
> +
> v4h = p;
> rc = v4h->next_proto_id;
> v4h->next_proto_id = proto;
> v4h->total_length = rte_cpu_to_be_16(plen - l2len);
> - } else if (l3len == sizeof(*v6h)) {
> + /* IPv6 */
> + } else {
> + struct ipv6_hdr *v6h;
> + uint8_t *next_proto_off;
> +
> v6h = p;
> - rc = v6h->proto;
> - v6h->proto = proto;
> +
> + /* basic IPv6 header with no extensions */
> + if (l3len == sizeof(struct ipv6_hdr))
> + next_proto_off = &v6h->proto;
Is this next_proto_off a pointer to an offset or the value of the next_proto. So IMO the name should be next_proto or it should be p_nh
> +
> + /* IPv6 with extensions */
> + else {
> + size_t ext_len;
> + int nh;
> + uint8_t *pd, *plimit;
> +
> + /* locate last extension within l3len bytes */
> + pd = (uint8_t *)p;
> + plimit = pd + l3len;
> + ext_len = sizeof(struct ipv6_hdr);
> + nh = v6h->proto;
> + while (pd + ext_len < plimit) {
> + pd += ext_len;
> + nh = rte_ipv6_get_next_ext(pd, nh, &ext_len);
> + if (unlikely(nh < 0))
> + return -EINVAL;
> + }
> +
> + /* invalid l3len - extension exceeds header length */
> + if (unlikely(pd + ext_len != plimit))
> + return -EINVAL;
> +
> + /* save last extension offset */
> + next_proto_off = pd;
> + }
> +
> + /* update header type; return original value */
> + rc = *next_proto_off;
> + *next_proto_off = proto;
> +
> + /* fix packet length */
> v6h->payload_len = rte_cpu_to_be_16(plen - l2len -
> sizeof(*v6h));
> - /* need to add support for IPv6 with options */
> - } else
> - rc = -ENOTSUP;
> + }
>
> return rc;
> }
> --
> 2.21.0.windows.1
^ permalink raw reply
* Re: crypto: crypto4xx - properly set IV after de- and encrypt breaks kernel 4.4
From: Christian Lamparter @ 2019-06-20 12:07 UTC (permalink / raw)
To: Hauke Mehrtens; +Cc: herbert, davem, gregkh, stable, linux-crypto, Amit Pundir
In-Reply-To: <9d744c3b-d4ff-b84b-527b-fc050794499b@hauke-m.de>
On Thursday, June 20, 2019 11:36:50 AM CEST Hauke Mehrtens wrote:
> Hi,
>
> The patch "crypto: crypto4xx - properly set IV after de- and encrypt"
> causes a compile error on kernel 4.4.
3.18 as well.
>
> When I revert this commit it compiles for me again:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e9a60ab1609a7d975922adad1bf9c46ac6954584
>
> I do not have hardware to test if it is really working.
I have a few APM821XX. But please note drivers without
commit b66c685a482117d4e9ee987d252ca673689a5302
Author: Christian Lamparter <chunkeey@gmail.com>
Date: Fri Dec 22 21:18:36 2017 +0100
crypto: crypto4xx - support Revision B parts
don't work on those and I do have my doubts that 460EX
series (and older) would either. I also don't believe that
the inital driver as it was submitted would have worked.
From what I've seen in their SDK, they patched the testmgr
at the time to either disable tests or provided their own...
so, might as well revert these patches for 4.4 and 3.18.
Because...
> drivers/crypto/amcc/crypto4xx_core.c: In function
> 'crypto4xx_ablkcipher_done':
> drivers/crypto/amcc/crypto4xx_core.c:649:21: warning: dereferencing
> 'void *' pointer
> if (pd_uinfo->sa_va->sa_command_0.bf.save_iv == SA_SAVE_IV) {
This would probably need
9e0a0b3a1 ("crypto: crypto4xx - pointer arithmetic overhaul") which is
a big patch.
> ^
> drivers/crypto/amcc/crypto4xx_core.c:649:21: error: request for member
> 'sa_command_0' in something not a structure or union
> drivers/crypto/amcc/crypto4xx_core.c:650:38: error: implicit declaration
> of function 'crypto_skcipher_reqtfm' [-Werror=implicit-function-declaration]
> struct crypto_skcipher *skcipher = crypto_skcipher_reqtfm(req);
> ^
This would require adding #include <crypto/skcipher.h> to crypto4xx_core.c
The patch that added it upstream was
ce05ffe10457 ("crypto: crypto4xx - convert to skcipher")
But this is more than just a one-liner.
> drivers/crypto/amcc/crypto4xx_core.c:650:61: error: 'req' undeclared
> (first use in this function)
> struct crypto_skcipher *skcipher = crypto_skcipher_reqtfm(req);
> ^
> drivers/crypto/amcc/crypto4xx_core.c:650:61: note: each undeclared
> identifier is reported only once for each function it appears in
see "#include <crypto/skcipher.h>"
> drivers/crypto/amcc/crypto4xx_core.c:652:3: error: implicit declaration
> of function 'crypto4xx_memcpy_from_le32'
> [-Werror=implicit-function-declaration]
> crypto4xx_memcpy_from_le32((u32 *)req->iv,
> ^
crypto4xx_memcpy_from_le32 is from
4865b122d4af ("crypto: crypto4xx - use the correct LE32 format for IV and key defs")
I think crypto4xx_memcpy_le() could work in this place.
But again I do have my doubts that the device works
without said patch.
> drivers/crypto/amcc/crypto4xx_core.c:653:19: warning: dereferencing
> 'void *' pointer
> pd_uinfo->sr_va->save_iv,
> ^
> drivers/crypto/amcc/crypto4xx_core.c:653:19: error: request for member
> 'save_iv' in something not a structure or union
See "crypto: crypto4xx - pointer arithmetic overhaul".
> drivers/crypto/amcc/crypto4xx_core.c:654:4: error: implicit declaration
> of function 'crypto_skcipher_ivsize' [-Werror=implicit-function-declaration]
> crypto_skcipher_ivsize(skcipher));
> ^
see "#include <crypto/skcipher.h>"
(Yeaah, there seems to be a limit of what automatic cherry-picking of
patches can do :( )
^ permalink raw reply
* [PATCH] xmm7modem: disabling reporting of intermediate results for CGDATA
From: Antara Borwankar @ 2019-06-20 12:07 UTC (permalink / raw)
To: ofono
[-- Attachment #1: Type: text/plain, Size: 1130 bytes --]
Setting <connect_flag> in AT+XDATACHANNEL set command to 0. This will
disable intermediate result reporting of "CONNECT" and "NO CARRIER"
on control channel.
This resolves the issue of getting failure response for offline-modem
since "NO CARRIER" is received as result of AT+CFUN operation instead
of "OK".
---
drivers/ifxmodem/gprs-context.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ifxmodem/gprs-context.c b/drivers/ifxmodem/gprs-context.c
index 2de6b4f..7bacb73 100644
--- a/drivers/ifxmodem/gprs-context.c
+++ b/drivers/ifxmodem/gprs-context.c
@@ -406,7 +406,7 @@ static void cgcontrdp_cb(gboolean ok, GAtResult *result, gpointer user_data)
interface = ofono_gprs_context_get_interface(gc);
datapath = get_datapath(modem, interface);
- snprintf(buf, sizeof(buf), "AT+XDATACHANNEL=1,1,\"%s\",\"%s\",2,%u",
+ snprintf(buf, sizeof(buf), "AT+XDATACHANNEL=1,1,\"%s\",\"%s\",0,%u",
ctrlpath, datapath, gcd->active_context);
g_at_chat_send(gcd->chat, buf, none_prefix, NULL, NULL, NULL);
snprintf(buf, sizeof(buf), "AT+CGDATA=\"M-RAW_IP\",%u",
--
1.9.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.