* Re: [PATCH v2 31/42] KVM: s390: protvirt: Report CPU state to Ultravisor
From: David Hildenbrand @ 2020-02-20 10:52 UTC (permalink / raw)
To: Christian Borntraeger, Janosch Frank
Cc: KVM, Cornelia Huck, Thomas Huth, Ulrich Weigand, Claudio Imbrenda,
linux-s390, Michael Mueller, Vasily Gorbik, Janosch Frank
In-Reply-To: <95f7cd6a-c8d4-a119-d87e-7b25929e0b5c@de.ibm.com>
On 19.02.20 20:46, Christian Borntraeger wrote:
> I could add a comment to all other users of kvm_s390_vcpu_start/stop like
>
>
> /*
> * no need to check the return value of vcpu_stop as it can only have
> * an error for protvirt, but protvirt means user cpu state
> */
> if (!kvm_s390_user_cpu_state_ctrl(vcpu->kvm))
> kvm_s390_vcpu_stop(vcpu);
>
>
> to make clear why we do not check the return everywhere
>
Makes sense!
--
Thanks,
David / dhildenb
^ permalink raw reply
* [tpm2] Infineon SLB 9670 lifetime
From: Tomasz Przybysz @ 2020-02-20 10:53 UTC (permalink / raw)
To: tpm2
[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]
Hi,
Do you know ?
From data sheet:
SLB 9670 TPM2.0
SLB 9670 TCG Family 2 Level 00 Rev. 01.16 Data Sheet, Revision 1.0, 2015-11-05:
1.1 Power Management
In the SLB 9670, power management is handled internally; no explicit power-down or standby mode is
available. The device automatically enters a low-power state after each successful command/response
transaction. If a transaction is started on the SPI bus from the host platform, the device will wake immediately
and will return to the low-power mode after the transaction has been finished.
4.2 Functional Operating Range
1) The useful lifetime of the device is 5 (five) years with a duty cycle (that means, a power-on time) of 100%. A useful
lifetime of 7 (seven) years can be guaranteed for a duty cycle of 70%. For both scenarios, it is assumed that the device
will be used for calculations for approximately 5% of the maximum useful lifetime.
Is it true? This is disqualification. Industrial equipment should work much longer, 15-20 years. It's not suitable for industrial equipment.
It's good for ink toner cartridge.
Best regards,
Tom
[-- Attachment #2: attachment.htm --]
[-- Type: text/html, Size: 2065 bytes --]
^ permalink raw reply
* Re: [Xen-devel] [PATCH v4 3/3] x86/hyperv: L0 assisted TLB flush
From: Durrant, Paul @ 2020-02-20 10:53 UTC (permalink / raw)
To: Wei Liu, Xen Development List
Cc: Andrew Cooper, Roger Pau Monné, Wei Liu, Jan Beulich,
Michael Kelley
In-Reply-To: <20200219114411.26922-4-liuwe@microsoft.com>
> -----Original Message-----
> From: Wei Liu <wei.liu.xen@gmail.com> On Behalf Of Wei Liu
> Sent: 19 February 2020 11:44
> To: Xen Development List <xen-devel@lists.xenproject.org>
> Cc: Michael Kelley <mikelley@microsoft.com>; Durrant, Paul
> <pdurrant@amazon.co.uk>; Wei Liu <liuwe@microsoft.com>; Wei Liu
> <wl@xen.org>; Jan Beulich <jbeulich@suse.com>; Andrew Cooper
> <andrew.cooper3@citrix.com>; Roger Pau Monné <roger.pau@citrix.com>
> Subject: [PATCH v4 3/3] x86/hyperv: L0 assisted TLB flush
>
> Implement L0 assisted TLB flush for Xen on Hyper-V. It takes advantage
> of several hypercalls:
>
> * HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST
> * HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX
> * HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE
> * HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX
>
> Pick the most efficient hypercalls available.
>
> Signed-off-by: Wei Liu <liuwe@microsoft.com>
Reviewed-by: Paul Durrant <pdurrant@amazon.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH] perf stat: Align the output for interval aggregation mode
From: Jiri Olsa @ 2020-02-20 10:53 UTC (permalink / raw)
To: Jin Yao
Cc: acme, jolsa, peterz, mingo, alexander.shishkin, Linux-kernel, ak,
kan.liang, yao.jin
In-Reply-To: <20200218071614.25736-1-yao.jin@linux.intel.com>
On Tue, Feb 18, 2020 at 03:16:14PM +0800, Jin Yao wrote:
> There is a slight misalignment in -A -I output.
>
> For example,
>
> perf stat -e cpu/event=cpu-cycles/ -a -A -I 1000
>
> # time CPU counts unit events
> 1.000440863 CPU0 1,068,388 cpu/event=cpu-cycles/
> 1.000440863 CPU1 875,954 cpu/event=cpu-cycles/
> 1.000440863 CPU2 3,072,538 cpu/event=cpu-cycles/
> 1.000440863 CPU3 4,026,870 cpu/event=cpu-cycles/
> 1.000440863 CPU4 5,919,630 cpu/event=cpu-cycles/
> 1.000440863 CPU5 2,714,260 cpu/event=cpu-cycles/
> 1.000440863 CPU6 2,219,240 cpu/event=cpu-cycles/
> 1.000440863 CPU7 1,299,232 cpu/event=cpu-cycles/
>
> The value of counts is not aligned with the column "counts" and
> the event name is not aligned with the column "events".
>
> With this patch, the output is,
>
> perf stat -e cpu/event=cpu-cycles/ -a -A -I 1000
>
> # time CPU counts unit events
> 1.000423009 CPU0 997,421 cpu/event=cpu-cycles/
> 1.000423009 CPU1 1,422,042 cpu/event=cpu-cycles/
> 1.000423009 CPU2 484,651 cpu/event=cpu-cycles/
> 1.000423009 CPU3 525,791 cpu/event=cpu-cycles/
> 1.000423009 CPU4 1,370,100 cpu/event=cpu-cycles/
> 1.000423009 CPU5 442,072 cpu/event=cpu-cycles/
> 1.000423009 CPU6 205,643 cpu/event=cpu-cycles/
> 1.000423009 CPU7 1,302,250 cpu/event=cpu-cycles/
>
> Now output is aligned.
>
> Signed-off-by: Jin Yao <yao.jin@linux.intel.com>
Acked-by: Jiri Olsa <jolsa@redhat.com>
thanks,
jirka
> ---
> tools/perf/util/stat-display.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/tools/perf/util/stat-display.c b/tools/perf/util/stat-display.c
> index bc31fccc0057..95b29c9cba36 100644
> --- a/tools/perf/util/stat-display.c
> +++ b/tools/perf/util/stat-display.c
> @@ -114,11 +114,11 @@ static void aggr_printout(struct perf_stat_config *config,
> fprintf(config->output, "S%d-D%d-C%*d%s",
> cpu_map__id_to_socket(id),
> cpu_map__id_to_die(id),
> - config->csv_output ? 0 : -5,
> + config->csv_output ? 0 : -3,
> cpu_map__id_to_cpu(id), config->csv_sep);
> } else {
> - fprintf(config->output, "CPU%*d%s ",
> - config->csv_output ? 0 : -5,
> + fprintf(config->output, "CPU%*d%s",
> + config->csv_output ? 0 : -7,
> evsel__cpus(evsel)->map[id],
> config->csv_sep);
> }
> --
> 2.17.1
>
^ permalink raw reply
* [ndctl PATCH 8/8] libndctl,papr_scm: Add support for reporting bad shutdown
From: Vaibhav Jain @ 2020-02-20 10:49 UTC (permalink / raw)
To: linux-nvdimm; +Cc: Vaibhav Jain, Aneesh Kumar K . V, Alastair D'Silva
In-Reply-To: <20200220104928.198625-1-vaibhav@linux.ibm.com>
Provide support for dimm-op 'smart_get_shutdown_state' implemented as
papr_smart_get_shutdown_state() to report a bad shutdown that couldn't
flush contents of nvdimm to flash memory properly.
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
---
ndctl/lib/papr_scm.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/ndctl/lib/papr_scm.c b/ndctl/lib/papr_scm.c
index a01649d3a9fe..8a6fec992aff 100644
--- a/ndctl/lib/papr_scm.c
+++ b/ndctl/lib/papr_scm.c
@@ -231,13 +231,22 @@ static unsigned int papr_smart_get_health(struct ndctl_cmd *cmd)
return 1 << (p->health.dimm_health - 1);
}
+static unsigned int papr_smart_get_shutdown_state(struct ndctl_cmd *cmd)
+{
+ struct dimm_priv *p = cmd->dimm->dimm_user_data;
+
+ /* Update dimm state and return f_flush */
+ return update_dimm_stats(cmd->dimm, cmd) ?
+ 0 : p->health.dimm_bad_shutdown;
+}
+
static unsigned int papr_smart_get_flags(struct ndctl_cmd *cmd)
{
/* In case of error return empty flags * */
if (update_dimm_stats(cmd->dimm, cmd))
return 0;
- return ND_SMART_HEALTH_VALID;
+ return ND_SMART_HEALTH_VALID | ND_SMART_SHUTDOWN_VALID;
}
static int papr_dimm_init(struct ndctl_dimm *dimm)
@@ -279,4 +288,5 @@ struct ndctl_dimm_ops * const papr_scm_dimm_ops = &(struct ndctl_dimm_ops) {
.smart_get_flags = papr_smart_get_flags,
.new_smart = papr_new_smart_health,
.smart_get_health = papr_smart_get_health,
+ .smart_get_shutdown_state = papr_smart_get_shutdown_state,
};
--
2.24.1
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
^ permalink raw reply related
* Re: [PATCH 1/2] tty: serial: samsung_tty: build it for any platform
From: Krzysztof Kozlowski @ 2020-02-20 10:54 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-serial, Kukjin Kim, Donghoon Yu, Hyunki Koo, HYUN-KI KOO,
Shinbeom Choi, Jiri Slaby, linux-arm-kernel, linux-samsung-soc,
linux-kernel
In-Reply-To: <20200220102628.3371996-1-gregkh@linuxfoundation.org>
On Thu, Feb 20, 2020 at 11:26:27AM +0100, Greg Kroah-Hartman wrote:
> There is no need to tie this driver to only a specific SoC, or compile
> test, so remove that dependancy from the Kconfig rules.
>
> Cc: Kukjin Kim <kgene@kernel.org>
> Cc: Donghoon Yu <hoony.yu@samsung.com>
> Cc: Hyunki Koo <kkoos00@naver.com>
> Cc: HYUN-KI KOO <hyunki00.koo@samsung.com>
> Cc: Shinbeom Choi <sbeom.choi@samsung.com>
> Cc: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Jiri Slaby <jslaby@suse.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-samsung-soc@vger.kernel.org
> Cc: linux-serial@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> drivers/tty/serial/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] tty: serial: samsung_tty: build it for any platform
From: Krzysztof Kozlowski @ 2020-02-20 10:54 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Donghoon Yu, linux-samsung-soc, linux-kernel, Shinbeom Choi,
Hyunki Koo, Kukjin Kim, linux-arm-kernel, linux-serial,
Jiri Slaby, HYUN-KI KOO
In-Reply-To: <20200220102628.3371996-1-gregkh@linuxfoundation.org>
On Thu, Feb 20, 2020 at 11:26:27AM +0100, Greg Kroah-Hartman wrote:
> There is no need to tie this driver to only a specific SoC, or compile
> test, so remove that dependancy from the Kconfig rules.
>
> Cc: Kukjin Kim <kgene@kernel.org>
> Cc: Donghoon Yu <hoony.yu@samsung.com>
> Cc: Hyunki Koo <kkoos00@naver.com>
> Cc: HYUN-KI KOO <hyunki00.koo@samsung.com>
> Cc: Shinbeom Choi <sbeom.choi@samsung.com>
> Cc: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Jiri Slaby <jslaby@suse.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-samsung-soc@vger.kernel.org
> Cc: linux-serial@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> drivers/tty/serial/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 03/22] x86: Replace ist_enter() with nmi_enter()
From: Borislav Petkov @ 2020-02-20 10:54 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-kernel, linux-arch, rostedt, mingo, joel, gregkh, gustavo,
tglx, paulmck, josh, mathieu.desnoyers, jiangshanlai, luto,
tony.luck, frederic, dan.carpenter, mhiramat
In-Reply-To: <20200219150744.547288232@infradead.org>
On Wed, Feb 19, 2020 at 03:47:27PM +0100, Peter Zijlstra wrote:
> @@ -1220,7 +1220,7 @@ static void mce_kill_me_maybe(struct cal
> * MCE broadcast. However some CPUs might be broken beyond repair,
> * so be always careful when synchronizing with others.
> */
> -void do_machine_check(struct pt_regs *regs, long error_code)
> +notrace void do_machine_check(struct pt_regs *regs, long error_code)
Is there a convention where the notrace marker should come in the
function signature? I see all possible combinations while grepping...
> {
> DECLARE_BITMAP(valid_banks, MAX_NR_BANKS);
> DECLARE_BITMAP(toclear, MAX_NR_BANKS);
> @@ -1254,10 +1254,10 @@ void do_machine_check(struct pt_regs *re
> */
> int lmce = 1;
>
> - if (__mc_check_crashing_cpu(cpu))
> - return;
> + nmi_enter();
>
> - ist_enter(regs);
> + if (__mc_check_crashing_cpu(cpu))
> + goto out;
>
> this_cpu_inc(mce_exception_count);
>
Should that __mc_check_crashing_cpu() happen before nmi_enter? The
function is doing only a bunch of checks and clearing MSRs for bystander
CPUs...
> @@ -1346,7 +1346,7 @@ void do_machine_check(struct pt_regs *re
> sync_core();
>
> if (worst != MCE_AR_SEVERITY && !kill_it)
> - goto out_ist;
> + goto out;
>
> /* Fault was in user mode and we need to take some action */
> if ((m.cs & 3) == 3) {
> @@ -1362,10 +1362,11 @@ void do_machine_check(struct pt_regs *re
> mce_panic("Failed kernel mode recovery", &m, msg);
> }
>
> -out_ist:
> - ist_exit(regs);
> +out:
> + nmi_exit();
> }
> EXPORT_SYMBOL_GPL(do_machine_check);
> +NOKPROBE_SYMBOL(do_machine_check);
Yah, that's a good idea regardless.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply
* Re: [PATCH v3 09/17] s390: protvirt: Move STSI data over SIDAD
From: Cornelia Huck @ 2020-02-20 10:54 UTC (permalink / raw)
To: Janosch Frank; +Cc: qemu-s390x, mihajlov, qemu-devel, david
In-Reply-To: <20200214151636.8764-10-frankja@linux.ibm.com>
On Fri, 14 Feb 2020 10:16:28 -0500
Janosch Frank <frankja@linux.ibm.com> wrote:
> For protected guests, we need to put the STSI emulation results into
> the SIDA, so SIE will write them into the guest at the next entry.
>
> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
> ---
> target/s390x/kvm.c | 15 ++++++++++++---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c
> index eec0b92479..fe669ed24c 100644
> --- a/target/s390x/kvm.c
> +++ b/target/s390x/kvm.c
> @@ -1772,11 +1772,16 @@ static int handle_tsch(S390CPU *cpu)
>
> static void insert_stsi_3_2_2(S390CPU *cpu, __u64 addr, uint8_t ar)
> {
> + CPUS390XState *env = &cpu->env;
> SysIB_322 sysib;
> int del;
>
> - if (s390_cpu_virt_mem_read(cpu, addr, ar, &sysib, sizeof(sysib))) {
> - return;
> + if (env->pv) {
> + s390_cpu_pv_mem_read(cpu, 0, &sysib, sizeof(sysib));
This is only introduced by the next patch, right?
> + } else {
> + if (s390_cpu_virt_mem_read(cpu, addr, ar, &sysib, sizeof(sysib))) {
> + return;
> + }
> }
> /* Shift the stack of Extended Names to prepare for our own data */
> memmove(&sysib.ext_names[1], &sysib.ext_names[0],
> @@ -1815,7 +1820,11 @@ static void insert_stsi_3_2_2(S390CPU *cpu, __u64 addr, uint8_t ar)
> /* Insert UUID */
> memcpy(sysib.vm[0].uuid, &qemu_uuid, sizeof(sysib.vm[0].uuid));
>
> - s390_cpu_virt_mem_write(cpu, addr, ar, &sysib, sizeof(sysib));
> + if (env->pv) {
> + s390_cpu_pv_mem_write(cpu, 0, &sysib, sizeof(sysib));
> + } else {
> + s390_cpu_virt_mem_write(cpu, addr, ar, &sysib, sizeof(sysib));
> + }
> }
>
> static int handle_stsi(S390CPU *cpu)
^ permalink raw reply
* Re: [Intel-gfx] [PATCH 01/12] drm: Nuke mode->hsync
From: Emil Velikov @ 2020-02-20 10:55 UTC (permalink / raw)
To: Ville Syrjala; +Cc: Intel Graphics Development, ML dri-devel
In-Reply-To: <20200219203544.31013-2-ville.syrjala@linux.intel.com>
On Wed, 19 Feb 2020 at 20:35, Ville Syrjala
<ville.syrjala@linux.intel.com> wrote:
>
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Let's just calculate the hsync rate on demand. No point in wasting
> space storing it and risking the cached value getting out of sync
> with reality.
>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
> drivers/gpu/drm/drm_modes.c | 14 ++------------
> drivers/gpu/drm/i915/display/intel_display.c | 1 -
> include/drm/drm_modes.h | 10 ----------
> 3 files changed, 2 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index d4d64518e11b..fe7e872a6239 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -752,24 +752,14 @@ EXPORT_SYMBOL(drm_mode_set_name);
> * @mode: mode
> *
> * Returns:
> - * @modes's hsync rate in kHz, rounded to the nearest integer. Calculates the
> - * value first if it is not yet set.
> + * @modes's hsync rate in kHz, rounded to the nearest integer
> */
> int drm_mode_hsync(const struct drm_display_mode *mode)
> {
> - unsigned int calc_val;
> -
> - if (mode->hsync)
> - return mode->hsync;
> -
> if (mode->htotal <= 0)
> return 0;
>
> - calc_val = (mode->clock * 1000) / mode->htotal; /* hsync in Hz */
> - calc_val += 500; /* round to 1000Hz */
> - calc_val /= 1000; /* truncate to kHz */
> -
> - return calc_val;
> + return DIV_ROUND_CLOSEST(mode->clock, mode->htotal);
> }
> EXPORT_SYMBOL(drm_mode_hsync);
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
> index ee7d54ccd3e6..fab914819489 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -8867,7 +8867,6 @@ void intel_mode_from_pipe_config(struct drm_display_mode *mode,
>
> mode->clock = pipe_config->hw.adjusted_mode.crtc_clock;
>
> - mode->hsync = drm_mode_hsync(mode);
With this gone, we could make drm_mode_hsync() internal and move it to
drm_foo_internal.h.
Making it obvious that drivers, should be copy/pasting it.
Regardless, the patch is:
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
-Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [Intel-gfx] [PATCH 01/12] drm: Nuke mode->hsync
From: Emil Velikov @ 2020-02-20 10:55 UTC (permalink / raw)
To: Ville Syrjala; +Cc: Intel Graphics Development, ML dri-devel
In-Reply-To: <20200219203544.31013-2-ville.syrjala@linux.intel.com>
On Wed, 19 Feb 2020 at 20:35, Ville Syrjala
<ville.syrjala@linux.intel.com> wrote:
>
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Let's just calculate the hsync rate on demand. No point in wasting
> space storing it and risking the cached value getting out of sync
> with reality.
>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
> drivers/gpu/drm/drm_modes.c | 14 ++------------
> drivers/gpu/drm/i915/display/intel_display.c | 1 -
> include/drm/drm_modes.h | 10 ----------
> 3 files changed, 2 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index d4d64518e11b..fe7e872a6239 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -752,24 +752,14 @@ EXPORT_SYMBOL(drm_mode_set_name);
> * @mode: mode
> *
> * Returns:
> - * @modes's hsync rate in kHz, rounded to the nearest integer. Calculates the
> - * value first if it is not yet set.
> + * @modes's hsync rate in kHz, rounded to the nearest integer
> */
> int drm_mode_hsync(const struct drm_display_mode *mode)
> {
> - unsigned int calc_val;
> -
> - if (mode->hsync)
> - return mode->hsync;
> -
> if (mode->htotal <= 0)
> return 0;
>
> - calc_val = (mode->clock * 1000) / mode->htotal; /* hsync in Hz */
> - calc_val += 500; /* round to 1000Hz */
> - calc_val /= 1000; /* truncate to kHz */
> -
> - return calc_val;
> + return DIV_ROUND_CLOSEST(mode->clock, mode->htotal);
> }
> EXPORT_SYMBOL(drm_mode_hsync);
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
> index ee7d54ccd3e6..fab914819489 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -8867,7 +8867,6 @@ void intel_mode_from_pipe_config(struct drm_display_mode *mode,
>
> mode->clock = pipe_config->hw.adjusted_mode.crtc_clock;
>
> - mode->hsync = drm_mode_hsync(mode);
With this gone, we could make drm_mode_hsync() internal and move it to
drm_foo_internal.h.
Making it obvious that drivers, should be copy/pasting it.
Regardless, the patch is:
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
-Emil
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH 2/2] tty: serial: samsung_tty: remove SERIAL_SAMSUNG_DEBUG
From: Krzysztof Kozlowski @ 2020-02-20 10:55 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-serial, Kukjin Kim, Donghoon Yu, Hyunki Koo, HYUN-KI KOO,
Shinbeom Choi, Jiri Slaby, linux-arm-kernel, linux-samsung-soc,
linux-kernel
In-Reply-To: <20200220102628.3371996-2-gregkh@linuxfoundation.org>
On Thu, Feb 20, 2020 at 11:26:28AM +0100, Greg Kroah-Hartman wrote:
> Since a05025d0ce72 ("tty: serial: samsung_tty: use standard debugging
> macros") this configuration option is not used at all, so remove it from
> the Kconfig file.
>
> Cc: Kukjin Kim <kgene@kernel.org>
> Cc: Donghoon Yu <hoony.yu@samsung.com>
> Cc: Hyunki Koo <kkoos00@naver.com>
> Cc: HYUN-KI KOO <hyunki00.koo@samsung.com>
> Cc: Shinbeom Choi <sbeom.choi@samsung.com>
> Cc: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Jiri Slaby <jslaby@suse.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-samsung-soc@vger.kernel.org
> Cc: linux-serial@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> drivers/tty/serial/Kconfig | 9 ---------
> 1 file changed, 9 deletions(-)
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] tty: serial: samsung_tty: remove SERIAL_SAMSUNG_DEBUG
From: Krzysztof Kozlowski @ 2020-02-20 10:55 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Donghoon Yu, linux-samsung-soc, linux-kernel, Shinbeom Choi,
Hyunki Koo, Kukjin Kim, linux-arm-kernel, linux-serial,
Jiri Slaby, HYUN-KI KOO
In-Reply-To: <20200220102628.3371996-2-gregkh@linuxfoundation.org>
On Thu, Feb 20, 2020 at 11:26:28AM +0100, Greg Kroah-Hartman wrote:
> Since a05025d0ce72 ("tty: serial: samsung_tty: use standard debugging
> macros") this configuration option is not used at all, so remove it from
> the Kconfig file.
>
> Cc: Kukjin Kim <kgene@kernel.org>
> Cc: Donghoon Yu <hoony.yu@samsung.com>
> Cc: Hyunki Koo <kkoos00@naver.com>
> Cc: HYUN-KI KOO <hyunki00.koo@samsung.com>
> Cc: Shinbeom Choi <sbeom.choi@samsung.com>
> Cc: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Jiri Slaby <jslaby@suse.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-samsung-soc@vger.kernel.org
> Cc: linux-serial@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> drivers/tty/serial/Kconfig | 9 ---------
> 1 file changed, 9 deletions(-)
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH -next] Documentation/power: fix pm_qos_interface.rst format warning
From: Rafael J. Wysocki @ 2020-02-20 10:55 UTC (permalink / raw)
To: Randy Dunlap
Cc: Linux PM list, linux-doc@vger.kernel.org, Jonathan Corbet,
Rafael J. Wysocki
In-Reply-To: <561e2780-111a-1939-43fb-ae32d7abce8d@infradead.org>
On Mon, Feb 17, 2020 at 5:54 AM Randy Dunlap <rdunlap@infradead.org> wrote:
>
> From: Randy Dunlap <rdunlap@infradead.org>
>
> Fix Sphinx warnings by indenting the bullet list (and making it
> unnumbered).
>
> Documentation/power/pm_qos_interface.rst:12: WARNING: Unexpected indentation.
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Cc: linux-pm@vger.kernel.org
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: linux-doc@vger.kernel.org
> ---
> Documentation/power/pm_qos_interface.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> --- linux-next-20200217.orig/Documentation/power/pm_qos_interface.rst
> +++ linux-next-20200217/Documentation/power/pm_qos_interface.rst
> @@ -7,8 +7,8 @@ performance expectations by drivers, sub
> one of the parameters.
>
> Two different PM QoS frameworks are available:
> -1. CPU latency QoS.
> -2. The per-device PM QoS framework provides the API to manage the
> + * CPU latency QoS.
> + * The per-device PM QoS framework provides the API to manage the
> per-device latency constraints and PM QoS flags.
>
> The latency unit used in the PM QoS framework is the microsecond (usec).
Applied, thanks!
^ permalink raw reply
* Re: [Intel-gfx] [PATCH 02/12] drm/exynos: Use mode->clock instead of reverse calculating it from the vrefresh
From: Emil Velikov @ 2020-02-20 10:56 UTC (permalink / raw)
To: Ville Syrjala
Cc: Kyungmin Park, Seung-Woo Kim, Intel Graphics Development,
ML dri-devel, Joonyoung Shim
In-Reply-To: <20200219203544.31013-3-ville.syrjala@linux.intel.com>
On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
<ville.syrjala@linux.intel.com> wrote:
>
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> htotal*vtotal*vrefresh ~= clock. So just use say "clock" when we mean it.
>
> Cc: Inki Dae <inki.dae@samsung.com>
> Cc: Joonyoung Shim <jy0922.shim@samsung.com>
> Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
-Emil
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH 02/12] drm/exynos: Use mode->clock instead of reverse calculating it from the vrefresh
From: Emil Velikov @ 2020-02-20 10:56 UTC (permalink / raw)
To: Ville Syrjala
Cc: Kyungmin Park, Seung-Woo Kim, Intel Graphics Development,
ML dri-devel, Joonyoung Shim
In-Reply-To: <20200219203544.31013-3-ville.syrjala@linux.intel.com>
On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
<ville.syrjala@linux.intel.com> wrote:
>
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> htotal*vtotal*vrefresh ~= clock. So just use say "clock" when we mean it.
>
> Cc: Inki Dae <inki.dae@samsung.com>
> Cc: Joonyoung Shim <jy0922.shim@samsung.com>
> Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
-Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v5] tools/perf/metricgroup: Fix printing event names of metric group with multiple events incase of overlapping events
From: Jiri Olsa @ 2020-02-20 10:56 UTC (permalink / raw)
To: Kajol Jain
Cc: acme, linux-kernel, linux-perf-users, Jiri Olsa,
Alexander Shishkin, Andi Kleen, Kan Liang, Peter Zijlstra,
Jin Yao, Madhavan Srinivasan, Anju T Sudhakar, Ravi Bangoria
In-Reply-To: <20200220050104.14094-1-kjain@linux.ibm.com>
On Thu, Feb 20, 2020 at 10:31:04AM +0530, Kajol Jain wrote:
SNIP
> + i++;
> + if (i == idnum)
> + break;
> }
> }
> }
> @@ -144,7 +142,10 @@ static struct evsel *find_evsel_group(struct evlist *perf_evlist,
> !strcmp(ev->name, metric_events[i]->name)) {
> ev->metric_leader = metric_events[i];
> }
> + j++;
> }
> + ev = metric_events[i];
> + evlist_used[ev->idx] = true;
> }
>
> return metric_events[0];
> @@ -160,6 +161,14 @@ static int metricgroup__setup_events(struct list_head *groups,
> int ret = 0;
> struct egroup *eg;
> struct evsel *evsel;
> + bool *evlist_used;
> +
> + evlist_used = (bool *)calloc(perf_evlist->core.nr_entries,
> + sizeof(bool));
no need for the (bool *) cast
other than that
Acked-by: Jiri Olsa <jolsa@redhat.com>
thanks,
jirka
^ permalink raw reply
* Re: [PATCH v2 1/2] docs: Convert qemu-cpu-models.texi to rST
From: Peter Maydell @ 2020-02-20 10:56 UTC (permalink / raw)
To: Kashyap Chamarthy
Cc: Markus Armbruster, Daniel P. Berrange, QEMU Developers,
Eduardo Habkost
In-Reply-To: <20200220102308.GE24572@paraplu>
On Thu, 20 Feb 2020 at 10:23, Kashyap Chamarthy <kchamart@redhat.com> wrote:
>
> On Wed, Feb 19, 2020 at 05:57:16PM +0000, Peter Maydell wrote:
> > On Wed, 19 Feb 2020 at 16:40, Kashyap Chamarthy <kchamart@redhat.com> wrote:
> > > Peter, how are you able to generate those *.7 `nroff` man pages? When I
> > > do 'make sphinxbuild' from my build dir ($HOME/buld/qemu), I only see:
> >
> > Just run 'make'.
>
> I did that, but I was missing the "--enable-docs" with my `configure`
> invocation (which I didn't post in full on the list, but only on IRC
> yesterday). Thanks, Markus, for spotting that.
Yeah, if you don't have the necessary tools then we'll
silently not build the docs (per configure's usual default
of "probe and enable only if possible").
thanks
-- PMM
^ permalink raw reply
* [Intel-gfx] [PATCH] drm/i915: remove the other slab_dependencies
From: Matthew Auld @ 2020-02-20 10:57 UTC (permalink / raw)
To: intel-gfx
The real one can be found in i915_scheduler.c.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
---
drivers/gpu/drm/i915/i915_request.c | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
index 6daf18dbb3d4..dbd882fe22ef 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -51,7 +51,6 @@ struct execute_cb {
static struct i915_global_request {
struct i915_global base;
struct kmem_cache *slab_requests;
- struct kmem_cache *slab_dependencies;
struct kmem_cache *slab_execute_cbs;
} global;
@@ -1614,14 +1613,12 @@ long i915_request_wait(struct i915_request *rq,
static void i915_global_request_shrink(void)
{
- kmem_cache_shrink(global.slab_dependencies);
kmem_cache_shrink(global.slab_execute_cbs);
kmem_cache_shrink(global.slab_requests);
}
static void i915_global_request_exit(void)
{
- kmem_cache_destroy(global.slab_dependencies);
kmem_cache_destroy(global.slab_execute_cbs);
kmem_cache_destroy(global.slab_requests);
}
@@ -1651,16 +1648,9 @@ int __init i915_global_request_init(void)
if (!global.slab_execute_cbs)
goto err_requests;
- global.slab_dependencies = KMEM_CACHE(i915_dependency,
- SLAB_HWCACHE_ALIGN |
- SLAB_RECLAIM_ACCOUNT);
- if (!global.slab_dependencies)
- goto err_execute_cbs;
-
i915_global_register(&global.base);
return 0;
-err_execute_cbs:
kmem_cache_destroy(global.slab_execute_cbs);
err_requests:
kmem_cache_destroy(global.slab_requests);
--
2.20.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* Re: [PATCH 1/2] docs: power: Drop reference to interface.rst
From: Rafael J. Wysocki @ 2020-02-20 10:57 UTC (permalink / raw)
To: Jonathan Neuschäfer
Cc: open list:DOCUMENTATION, Rafael J. Wysocki, Len Brown,
Pavel Machek, Linux PM, Linux Kernel Mailing List
In-Reply-To: <20200218145819.17314-1-j.neuschaefer@gmx.net>
On Tue, Feb 18, 2020 at 3:59 PM Jonathan Neuschäfer
<j.neuschaefer@gmx.net> wrote:
>
> It has been merged into sleep-states.rst.
>
> Fixes: c21502efdaed ("Documentation: admin-guide: PM: Update sleep states documentation")
> Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
> ---
> Documentation/power/index.rst | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/Documentation/power/index.rst b/Documentation/power/index.rst
> index 002e42745263..ced8a8007434 100644
> --- a/Documentation/power/index.rst
> +++ b/Documentation/power/index.rst
> @@ -13,7 +13,6 @@ Power Management
> drivers-testing
> energy-model
> freezing-of-tasks
> - interface
> opp
> pci
> pm_qos_interface
> --
Applied as a fix for 5.6, thanks!
^ permalink raw reply
* Re: [PATCH v2 2/2] phy: intel: Add driver support for Combophy
From: Andy Shevchenko @ 2020-02-20 10:57 UTC (permalink / raw)
To: Dilip Kota
Cc: linux-kernel, devicetree, kishon, robh, cheol.yong.kim,
chuanhua.lei, qi-ming.wu, yixin.zhu
In-Reply-To: <3c73c805-55a6-dcc0-4cd4-dd452f1d002d@linux.intel.com>
On Thu, Feb 20, 2020 at 05:58:41PM +0800, Dilip Kota wrote:
> On 2/19/2020 6:14 PM, Andy Shevchenko wrote:
> > On Wed, Feb 19, 2020 at 11:31:30AM +0800, Dilip Kota wrote:
...
> > return regmap_update_bits(..., mask, val);
> >
> > ?
> Still it is taking more than 80 characters with mask, need to be in 2 lines
>
> return regmap_update_bits(...,
> mask, val);
It's up to maintainer, I was talking about use of temporary variable for mask.
> > > +static int intel_cbphy_pcie_refclk_cfg(struct intel_cbphy_iphy *iphy, bool set)
> > > +{
> > > + struct intel_combo_phy *cbphy = iphy->parent;
> > > + const u32 pad_dis_cfg_off = 0x174;
> > > + u32 val, bitn;
> > > +
> > > + bitn = cbphy->id * 2 + iphy->id;
> > > +
> > > + /* Register: 0 is enable, 1 is disable */
> > > + val = set ? 0 : BIT(bitn);
> > > +
> > > + return regmap_update_bits(cbphy->syscfg, pad_dis_cfg_off, BIT(bitn),
> > > + val);
> > Ditto.
> Here it can with go in single line with mask,
Here I meant all changes from previous function, yes, temporary variable mask
in particular.
> > > +}
...
> > > + case PHY_PCIE_MODE:
> > > + cb_mode = (aggr == PHY_DL_MODE) ?
> > > + PCIE_DL_MODE : PCIE0_PCIE1_MODE;
> > I think one line is okay here.
> its taking 82 characters.
Up to maintainer, but I consider the two lines approach is worse to read.
> > > + break;
...
> > > + ret = intel_cbphy_iphy_cfg(iphy,
> > > + intel_cbphy_pcie_en_pad_refclk);
> > One line is fine here.
> It is taking 81 characters, so kept in 2 lines.
Ditto.
> > > + if (ret)
> > > + return ret;
...
> > > + ret = intel_cbphy_iphy_cfg(iphy,
> > > + intel_cbphy_pcie_dis_pad_refclk);
> > Ditto.
> 82 characters here.
Ditto.
> > > + if (ret)
> > > + return ret;
...
> > > + ret = fwnode_property_get_reference_args(dev_fwnode(dev),
> > > + "intel,syscfg", NULL, 1, 0,
> > > + &ref);
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > + fwnode_handle_put(ref.fwnode);
> > Why here?
>
> Instructed to do:
>
> " Caller is responsible to call fwnode_handle_put() on the returned
> args->fwnode pointer"
Right...
> > > + cbphy->id = ref.args[0];
> > > + cbphy->syscfg = device_node_to_regmap(ref.fwnode->dev->of_node);
...and here you called unreferenced one. Is it okay?
If it's still being referenced, that is fine, but otherwise it may gone already.
> > > + ret = fwnode_property_get_reference_args(dev_fwnode(dev), "intel,hsio",
> > > + NULL, 1, 0, &ref);
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > + fwnode_handle_put(ref.fwnode);
> > > + cbphy->bid = ref.args[0];
> > > + cbphy->hsiocfg = device_node_to_regmap(ref.fwnode->dev->of_node);
> > Ditto.
> >
> > > + if (!device_property_read_u32(dev, "intel,phy-mode", &prop)) {
> > Hmm... Why to mix device_property_*() vs. fwnode_property_*() ?
> device_property_* are wrapper functions to fwnode_property_*().
> Calling the fwnode_property_*() ending up doing the same work of
> device_property_*().
>
> If the best practice is to maintain symmetry, will call fwnode_property_*().
The best practice to keep consistency as much as possible.
If you call two similar APIs in one scope, it's not okay.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v6 1/4] lib: new helper kstrtodev_t()
From: Uwe Kleine-König @ 2020-02-20 10:57 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Sascha Hauer, open list:SERIAL DRIVERS, Greg Kroah-Hartman,
Linux Kernel Mailing List, Jacek Anaszewski, Pavel Machek,
Jiri Slaby, Linux LED Subsystem, Dan Murphy
In-Reply-To: <CAHp75VcxXWputX1y90t8f-c0a3dw2CHU6=ebQ+o6e8Z1GymiDw@mail.gmail.com>
Hello Andy,
On Thu, Feb 20, 2020 at 12:22:36PM +0200, Andy Shevchenko wrote:
> On Thu, Feb 20, 2020 at 9:49 AM Uwe Kleine-König
> <u.kleine-koenig@pengutronix.de> wrote:
> > On Wed, Feb 19, 2020 at 09:50:54PM +0200, Andy Shevchenko wrote:
> > > On Thu, Feb 13, 2020 at 11:27 AM Uwe Kleine-König <uwe@kleine-koenig.org> wrote:
> > > >
> > > > This function is in the same spirit as the other kstrto* functions and
> > > > uses the same calling convention. It expects the input string to be in
> > > > the format %u:%u and implements stricter parsing than sscanf as it
> > > > returns an error on trailing data (other than the usual \n).
>
> ...
>
> > > On top of that, why kstrtodev_t is so important? How many users are
> > > already in the kernel to get an advantage out of it?
> >
> > Does it need to be important? It matches the other kstrto* functions and
> > so it seemed more natural to me to put it near the other functions. I'm
> > not aware of other potential users and surprised you seem to suggest
> > this as a requirement.
>
> Yes it does. The kstrtox() are quite generic, what you are proposing
> is rather one particular case with blurry understanding how many users
> will be out of it.
In my understanding one user is a hard requirement.
> If you had told "look, we have 1234 users which may benefit out of
> it", I would have given no comment against.
Sure, having >1000 potential users would be a good argument pro this
function. But having only one isn't a good contra IMHO.
> > > What to do with all other possible variants ("%d:%d", "%dx%d" and its
> > > %u variant, etc)?
> >
> > I don't see how %d:%d is relevant, major and minor cannot be negative
> > can they? I never saw 'x' as separator between major and minor. I
> > considered shortly parsing %u, but given that (I think) this is an
> > internal representation only I chose to not make it more visible than it
> > already is.
>
> See above, if we are going to make it generic, perhaps better to cover
> more possible users, right?
> Otherwise your change provokes pile of (replaced)
> kstrto_resolution() /* %ux:%u */
> kstrto_range() /* %d:%d */
> kstrto_you_name_it()
Given there are respective types that this can be stored to, I don't
object more functions of this type and don't see a good reason to not
add such a function. And in my eyes I prefer to have such a function in
a visible place (i.e. where all the other kstrto* functions are) to
prevent code duplication.
Also I don't understand yet, what you want me to do. Assume I'd be
willing to use simple_strtoul, I'd still want to have a function that
gives me a dev_t from a given string. Should I put this directly in my
led-trigger driver?
> > > Why simple_strto*() can't be used?
> >
> > I didn't really consider it, but looking in more detail I don't like it
> > much. Without having tried it I think simple_strtoull accepts
> > "1000000000000000000000000000000000000000000" returning some arbitrary
> > value without an error indication.
>
> So what? User has a lot of possibilities to shoot into the foot.
> Since you interpret this as device major:minor, not founding a device
> will be first level of error, next one when your code will try to do
> something out of it. It shouldn't be a problem of kstrtox generic
> helpers.
I fail to follow your argument here. In my eyes if the user writes a
valid major:minor it should work, and if they write an invalid one this
should result in an error and not a usage of a device that just happens
to have the major:minor that simple_strtoull happens to return for the
two components.
> > And given that I was asked for strict
> > parsing (i.e. not accepting 2:4:something) I'd say using simple_strto*
> > is a step backwards. Also simple_strtoul() has "This function is obsolete.
> > Please use kstrtoul instead." in its docstring which seems to apply to
> > the other simple_strto*() functions, too.
>
> I specifically fixed a doc string to approve its use in the precisely
> cases you have here.
Can you please be a bit more constructive here and point to the change
you talk about? I didn't find a commit in next.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
^ permalink raw reply
* [meta-oe][sumo][PATCH] strongswan: avoid charon crash
From: Saloni Jain @ 2020-02-20 10:58 UTC (permalink / raw)
To: openembedded-core@lists.openembedded.org, Khem Raj
Cc: Nisha Parrakat, Rahul Taya, Aditya Tayade, Anuj Chougule
[-- Attachment #1: Type: text/plain, Size: 6611 bytes --]
From: Anuj Chougule <Anuj.Chougule@kpit.com>
This is a possible fix to charon that crashed early due to invalid
memory access.
Important frames from Backtraces :
8 0x00007f607246e160 in memcpy (__len=1704, __src=<optimized out>, __dest=<optimized out>)
at /usr/include/bits/string_fortified.h:34
No locals.
9 memcpy_noop (n=1704, src=<optimized out>, dst=<optimized out>)
at /usr/src/debug/strongswan/5.7.2-r0/strongswan-5.7.2/src/libstrongswan/utils/utils/memory.h:47
n = 1704
src = <optimized out>
dst = <optimized out>
10 chunk_create_clone (ptr=<optimized out>, chunk=...)
at /usr/src/debug/strongswan/5.7.2-r0/strongswan-5.7.2/src/libstrongswan/utils/chunk.c:48
clone = <optimized out>
11 0x00007f606ebae810 in load_from_blob (blob=..., type=type@entry=CRED_PRIVATE_KEY, subtype=subtype@entry=1,
subject=subject@entry=0x0, flags=flags@entry=X509_NONE)
at /usr/src/debug/strongswan/5.7.2-r0/strongswan-5.7.2/src/libstrongswan/plugins/pem/pem_builder.c:399
x = <optimized out>
cred = 0x0
---Type <return> to continue, or q <return> to quit---
pgp = false
12 0x00007f606ebaf0e4 in load_from_file (flags=X509_NONE, subject=0x0, subtype=1, type=CRED_PRIVATE_KEY,
file=0x7f6069d21a20 "/var/opt/public/sps/sps_necema/data/public/IPsec/secureboot_on/IPsec-internal_key.pem")
at /usr/src/debug/strongswan/5.7.2-r0/strongswan-5.7.2/src/libstrongswan/plugins/pem/pem_builder.c:452
cred = <optimized out>
chunk = 0x7f6054005430
13 pem_load (type=CRED_PRIVATE_KEY, subtype=1, args=<optimized out>)
at /usr/src/debug/strongswan/5.7.2-r0/strongswan-5.7.2/src/libstrongswan/plugins/pem/pem_builder.c:498
file = 0x7f6069d21a20 "/var/opt/public/sps/sps_necema/data/public/IPsec/secureboot_on/IPsec-internal_key.pem"
pem = <optimized out>
subject = 0x0
flags = 0
Problem lies in frame 12 & 11.
(gdb) f 12
12 0x00007f606ebaf0e4 in load_from_file (flags=X509_NONE, subject=0x0, subtype=1, type=CRED_PRIVATE_KEY,
file=0x7f6069d21a20 "/var/opt/public/sps/sps_necema/data/public/IPsec/secureboot_on/IPsec-internal_key.pem")
at /usr/src/debug/strongswan/5.7.2-r0/strongswan-5.7.2/src/libstrongswan/plugins/pem/pem_builder.c:452
452 in /usr/src/debug/strongswan/5.7.2-r0/strongswan-5.7.2/src/libstrongswan/plugins/pem/pem_builder.c
(gdb) info locals
cred = <optimized out>
chunk = 0x7f6054005430
(gdb) print *chunk
$21 = {ptr = 0x7f60728b7000 <error: Cannot access memory at address 0x7f60728b7000>, len = 1704}
(gdb) f 11
11 0x00007f606ebae810 in load_from_blob (blob=..., type=type@entry=CRED_PRIVATE_KEY, subtype=subtype@entry=1, subject=subject@entry=0x0,
flags=flags@entry=X509_NONE) at /usr/src/debug/strongswan/5.7.2-r0/strongswan-5.7.2/src/libstrongswan/plugins/pem/pem_builder.c:399
399 in /usr/src/debug/strongswan/5.7.2-r0/strongswan-5.7.2/src/libstrongswan/plugins/pem/pem_builder.c
(gdb) info args
blob = {ptr = 0x7f60728b7000 <error: Cannot access memory at address 0x7f60728b7000>, len = 140052215328768}
type = CRED_PRIVATE_KEY
subtype = 1
subject = 0x0
flags = X509_NONE
(gdb) print blob
$22 = {ptr = 0x7f60728b7000 <error: Cannot access memory at address 0x7f60728b7000>, len = 140052215328768}
Source code snippet :
static void *load_from_file(char *file, credential_type_t type, int subtype,
identification_t *subject, x509_flag_t flags)
{
void *cred;
chunk_t *chunk;
chunk = chunk_map(file, FALSE);
if (!chunk)
{
DBG1(DBG_LIB, " opening '%s' failed: %s", file, strerror(errno));
return NULL;
}
cred = load_from_blob(*chunk, type, subtype, subject, flags);
chunk_unmap(chunk);
return cred;
}
Local variable chunk is an uninitialised pointer in load_from_file()
(frame 12 above) which is expected to get initialised through
chunk_map() & then passed to load_from_blob() as a parameter.
But somehow, the chunk pointer has not got initialised &
got passed as it is to load_from_blob() in frame 11 above.
As this contains a garbage address, when method load_from_blob()
tried cloning the memory regions through chunk_clone() ->
chunk_create_clone() -> memcpy() -> memcpy_noop(), it crashed with
SIGBUS (frames 10, 9, 8).
It could also be that chunk_map() has a bug which does not memmap()
the full or correct areas.
Upstream-Status: Pending
Tested By: Anuj Chougule <Anuj.Chougule@kpit.com>
Signed-off-by: Anuj Chougule <Anuj.Chougule@kpit.com>
Signed-off-by: Saloni Jain <Saloni.Jain@kpit.com>
---
.../strongswan/files/fix-charon-crash.patch | 23 ++++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 recipes-support/strongswan/files/fix-charon-crash.patch
diff --git a/recipes-support/strongswan/files/fix-charon-crash.patch b/recipes-support/strongswan/files/fix-charon-crash.patch
new file mode 100644
index 0000000..95e71a2
--- /dev/null
+++ b/recipes-support/strongswan/files/fix-charon-crash.patch
@@ -0,0 +1,23 @@
+strongswan: avoid charon crash
+
+Variable chunk is an uninitialised pointer,which
+is expected to get initialised through method chunk_map()
+& then passed to load_from_blob() as a parameter.
+But somehow, if the chunk pointer did not get initialised & gets
+passed as it is to load_from_blob(), it may lead crash as this
+contains a garbage address.
+
+Signed-off-by: Anuj Chougule <Anuj.Chougule@kpit.com>
+Upstream-Status: Pending
+
+--- a/src/libstrongswan/plugins/pem/pem_builder.c
++++ b/src/libstrongswan/plugins/pem/pem_builder.c
+@@ -441,7 +441,7 @@ static void *load_from_file(char *file, credential_type_t type, int subtype,
+ identification_t *subject, x509_flag_t flags)
+ {
+ void *cred;
+- chunk_t *chunk;
++ chunk_t *chunk = NULL;
+
+ chunk = chunk_map(file, FALSE);
+ if (!chunk)
--
2.7.4
This message contains information that may be privileged or confidential and is the property of the KPIT Technologies Ltd. It is intended only 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. KPIT Technologies Ltd. does not accept any liability for virus infected mails.
[-- Attachment #2: Type: text/html, Size: 10472 bytes --]
^ permalink raw reply related
* [MODERATED] Re: [PATCH 1/2] more sampling fun 1
From: Andrew Cooper @ 2020-02-20 11:00 UTC (permalink / raw)
To: speck
In-Reply-To: <20200220101340.GB30404@zn.tnic>
[-- Attachment #1: Type: text/plain, Size: 488 bytes --]
On 20/02/2020 10:13, speck for Borislav Petkov wrote:
> On Thu, Feb 20, 2020 at 10:10:03AM +0000, speck for Andrew Cooper wrote:
>> Because it is under embargo until May 12th.
> Maybe 2/2 is - which I don't have in my mbox - but by staring only at
> 1/2 there's nothing to embargo there AFAICT.
>
Right, but a lone patch (coming pre-reviewed even!) adding stepping
support into the speculative model checking is going to be about as
subtle as the KPTI work was :)
~Andrew
^ permalink raw reply
* [Xen-devel] [linux-4.4 test] 147279: regressions - FAIL
From: osstest service owner @ 2020-02-20 11:00 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 147279 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147279/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 139698
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 139698
Tests which are failing intermittently (not blocking):
test-amd64-amd64-qemuu-nested-amd 14 xen-boot/l1 fail in 147111 pass in 147279
test-armhf-armhf-xl-credit1 7 xen-boot fail in 147111 pass in 147279
test-amd64-i386-xl-xsm 23 leak-check/check fail in 147111 pass in 147279
test-armhf-armhf-libvirt 19 leak-check/check fail in 147111 pass in 147279
test-amd64-amd64-xl-rtds 16 guest-localmigrate fail pass in 147111
test-amd64-i386-libvirt-xsm 18 guest-start/debian.repeat fail pass in 147186
test-armhf-armhf-libvirt-raw 11 guest-start fail pass in 147186
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail in 147111 REGR. vs. 139698
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-raw 12 migrate-support-check fail in 147111 never pass
test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail in 147111 never pass
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass
test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
test-amd64-i386-xl-pvshim 12 guest-start fail never pass
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass
test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass
test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt 13 migrate-support-check fail never pass
test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-i386-libvirt 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass
test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass
test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
test-armhf-armhf-xl 13 migrate-support-check fail never pass
test-armhf-armhf-xl 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass
test-armhf-armhf-libvirt 13 migrate-support-check fail never pass
test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass
test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass
test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass
version targeted for testing:
linux 76e5c6fd6d163f1aa63969cc982e79be1fee87a7
baseline version:
linux dc16a7e5f36d65b25a1b66ade14356773ed52875
Last test of basis 139698 2019-08-04 07:48:30 Z 200 days
Failing since 139773 2019-08-06 16:40:26 Z 197 days 110 attempts
Testing same since 147111 2020-02-16 03:37:56 Z 4 days 3 attempts
------------------------------------------------------------
1097 people touched revisions under test,
not listing them all
jobs:
build-amd64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl pass
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass
test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass
test-amd64-amd64-libvirt-xsm pass
test-amd64-i386-libvirt-xsm fail
test-amd64-amd64-xl-xsm pass
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvhv2-amd fail
test-amd64-i386-qemut-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemut-debianhvm-amd64 pass
test-amd64-i386-xl-qemut-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-freebsd10-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 fail
test-amd64-amd64-xl-qemut-win7-amd64 fail
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-amd64-xl-qemut-ws16-amd64 fail
test-amd64-i386-xl-qemut-ws16-amd64 fail
test-amd64-amd64-xl-qemuu-ws16-amd64 fail
test-amd64-i386-xl-qemuu-ws16-amd64 fail
test-armhf-armhf-xl-arndale pass
test-amd64-amd64-xl-credit1 pass
test-armhf-armhf-xl-credit1 pass
test-amd64-amd64-xl-credit2 pass
test-armhf-armhf-xl-credit2 pass
test-armhf-armhf-xl-cubietruck pass
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail
test-amd64-amd64-examine pass
test-armhf-armhf-examine pass
test-amd64-i386-examine pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-amd64-qemuu-nested-intel fail
test-amd64-amd64-xl-pvhv2-intel fail
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt pass
test-amd64-i386-libvirt pass
test-amd64-amd64-xl-multivcpu pass
test-armhf-armhf-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pair pass
test-amd64-i386-libvirt-pair pass
test-amd64-amd64-amd64-pvgrub pass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-xl-pvshim pass
test-amd64-i386-xl-pvshim fail
test-amd64-amd64-pygrub pass
test-amd64-amd64-xl-qcow2 pass
test-armhf-armhf-libvirt-raw fail
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds fail
test-armhf-armhf-xl-rtds pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass
test-amd64-amd64-xl-shadow pass
test-amd64-i386-xl-shadow pass
test-amd64-amd64-libvirt-vhd pass
test-armhf-armhf-xl-vhd pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
(No revision log; it would be 55417 lines long.)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
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.