Re: [PATCH] drm: Replace drm_modeset_lock/unlock_all with DRM_MODESET_LOCK_ALL_* helpers
On 29.04.2020 10:57, Jani Nikula wrote:
> On Tue, 28 Apr 2020, Michal Orzel wrote:
>> As suggested by the TODO list for the kernel DRM subsystem, replace
>> the deprecated functions that take/drop modeset locks with new helpers.
>>
>> Signed-off-by: Michal Orzel
>> ---
>> drivers/gpu/drm/drm_mode_object.c | 10 ++
>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_mode_object.c
>> b/drivers/gpu/drm/drm_mode_object.c
>> index 35c2719..901b078 100644
>> --- a/drivers/gpu/drm/drm_mode_object.c
>> +++ b/drivers/gpu/drm/drm_mode_object.c
>> @@ -402,12 +402,13 @@ int drm_mode_obj_get_properties_ioctl(struct
>> drm_device *dev, void *data,
>> {
>> struct drm_mode_obj_get_properties *arg = data;
>> struct drm_mode_object *obj;
>> +struct drm_modeset_acquire_ctx ctx;
>> int ret = 0;
>>
>> if (!drm_core_check_feature(dev, DRIVER_MODESET))
>> return -EOPNOTSUPP;
>>
>> -drm_modeset_lock_all(dev);
>> +DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
>
> I cry a little every time I look at the DRM_MODESET_LOCK_ALL_BEGIN and
> DRM_MODESET_LOCK_ALL_END macros. :(
>
> Currently only six users... but there are ~60 calls to
> drm_modeset_lock_all{,_ctx} that I presume are to be replaced. I wonder
> if this will come back and haunt us.
>
> BR,
> Jani.
Hm, so we can either replace all of these calls(I think it's a better option)
or abandon the idea of removing this deprecated function.
In the latter scenario, it'd be beneficial to remove this from TODO.
Best regards
Michal
>
>
>>
>> obj = drm_mode_object_find(dev, file_priv, arg->obj_id, arg->obj_type);
>> if (!obj) {
>> @@ -427,7 +428,7 @@ int drm_mode_obj_get_properties_ioctl(struct drm_device
>> *dev, void *data,
>> out_unref:
>> drm_mode_object_put(obj);
>> out:
>> -drm_modeset_unlock_all(dev);
>> +DRM_MODESET_LOCK_ALL_END(ctx, ret);
>> return ret;
>> }
>>
>> @@ -449,12 +450,13 @@ static int set_property_legacy(struct drm_mode_object
>> *obj,
>> {
>> struct drm_device *dev = prop->dev;
>> struct drm_mode_object *ref;
>> +struct drm_modeset_acquire_ctx ctx;
>> int ret = -EINVAL;
>>
>> if (!drm_property_change_valid_get(prop, prop_value, ))
>> return -EINVAL;
>>
>> -drm_modeset_lock_all(dev);
>> +DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
>> switch (obj->type) {
>> case DRM_MODE_OBJECT_CONNECTOR:
>> ret = drm_connector_set_obj_prop(obj, prop, prop_value);
>> @@ -468,7 +470,7 @@ static int set_property_legacy(struct drm_mode_object
>> *obj,
>> break;
>> }
>> drm_property_change_valid_put(prop, ref);
>> -drm_modeset_unlock_all(dev);
>> +DRM_MODESET_LOCK_ALL_END(ctx, ret);
>>
>> return ret;
>> }
>
Re: [RFC 1/3] powernv/cpuidle : Support for pre-entry and post exit of stop state in firmware
Hi Nick, Have you posted out the kernel side of "opal v4" patchset? I could only find the opal patchset. Thanks, Abhishek On 04/28/2020 06:38 AM, Nicholas Piggin wrote: Thanks for picking this up and pushing it along. I do plan to come back and take another look at it all, but what we do need to do first is get a coherent approach to this proposed new calling convention and OS ops. It's fine to work on this in the meantime, but to start merging things my idea is: - OPAL must leave r13-r15 untouched for the OS. - OS ops are made available only for a "v4" OS that uses the new calling convention, including kernel stack. - OS ops baseline (all OSes must provide) will be console / printk facility, trap handling and crash/symbol decoding on behalf of OPAL, and runtime virtual memory. Other OS ops features can be added in the versioned structure, including this. I'm trying to get back to cleaning these things up and start getting them merged now. Any comments or review on those would be helpful. Thanks, Nick
Re: [PATCH v3 1/1] scsi: pm: Balance pm_only counter of request queue during system resume
Hi Bart, On 2020-04-30 13:08, Bart Van Assche wrote: On 2020-04-29 21:10, Can Guo wrote: During system resume, scsi_resume_device() decreases a request queue's pm_only counter if the scsi device was quiesced before. But after that, if the scsi device's RPM status is RPM_SUSPENDED, the pm_only counter is still held (non-zero). Current scsi resume hook only sets the RPM status of the scsi device and its request queue to RPM_ACTIVE, but leaves the pm_only counter unchanged. This may make the request queue's pm_only counter remain non-zero after resume hook returns, hence those who are waiting on the mq_freeze_wq would never be woken up. Fix this by calling blk_post_runtime_resume() if pm_only is non-zero to balance the pm_only counter which is held by the scsi device's RPM ops. How was this issue discovered? How has this patch been tested? Thanks, Bart. As the issue was found after system resumes, so the issue was discovered during system suspend/resume test, and it is very easy to be replicated. After system resumes, if this issue hits some scsi devices, all bios sent to their request queues are blocked, which may cause a system hang if the scsi devices are vital to system functionality. To make sure the patch work well, we have tested system suspend/resume and made sure no system hang happen due to request queues got blocked by imbalanced pm_only counter. Thanks, Can Guo.
Re: [PATCH 8/9] perf intel-pt: Update documentation about itrace G and L options
On 30/04/20 2:03 am, Andi Kleen wrote: >> +One caveat with the G and L options is that they work poorly with "Large >> PEBS". >> +Large PEBS means PEBS records will be accumulated by hardware and the >> written >> +into the event buffer in one go. That reduces interrupts, but can give very >> +late timestamps. Because the Intel PT trace is synchronized by timestamps, > > Are you refering to Broadwell here? I was testing on Coffee Lake > > On Skylake/Goldmont the PEBS event contains the TSC and the time stamp > reported by > perf should report the time the event was sampled based on that TSC. > Or is that not working for some reason? I guess it is not working like that, but perf tools would probably need special rules to sort the events because the they would break the rules of PERF_RECORD_FINISHED_ROUND, wouldn't they?
Re: [PATCH] crypto: bcm - Fix unused assignment
On Sat, Apr 25, 2020 at 10:24:14PM +0800, Tang Bin wrote: > Delete unused initialized value in cipher.c file. > > Signed-off-by: Zhang Shengju > Signed-off-by: Tang Bin > --- > drivers/crypto/bcm/cipher.c | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: bcm - Remove the unnecessary cast for PTR_ERR().
On Sat, Apr 25, 2020 at 10:22:58PM +0800, Tang Bin wrote: > It's not necessary to specify 'int' casting for PTR_ERR(). > > Signed-off-by: Zhang Shengju > Signed-off-by: Tang Bin > --- > drivers/crypto/bcm/cipher.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH -next] hwrng: cctrng - Make some symbols static
Zou Wei wrote: > Fix the following sparse warnings: > > drivers/char/hw_random/cctrng.c:316:6: warning: symbol > 'cc_trng_compwork_handler' was not declared. Should it be static? > drivers/char/hw_random/cctrng.c:451:6: warning: symbol > 'cc_trng_startwork_handler' was not declared. Should it be static? > > Reported-by: Hulk Robot > Signed-off-by: Zou Wei > --- > drivers/char/hw_random/cctrng.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v3 0/3] crypto: fix some DRBG Kconfig deps
On Fri, Apr 24, 2020 at 01:40:44PM +, Corentin Labbe wrote: > Hello > > Fix serie try to fix some DRBG depencies in Kconfig > > Change since v2: > - added patch #2 > > Changes since v1: > - Updated commit message with recursive dependency > > Corentin Labbe (3): > crypto: drbg: DRBG should select SHA512 > crypto: CRYPTO_CTR no longer need CRYPTO_SEQIV > crypto: drbg: DRBG_CTR should select CTR > > crypto/Kconfig | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) Patches 2-3 applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH crypto-stable v3 1/2] crypto: arch/lib - limit simd usage to 4k chunks
On Wed, Apr 22, 2020 at 05:18:53PM -0600, Jason A. Donenfeld wrote:
> The initial Zinc patchset, after some mailing list discussion, contained
> code to ensure that kernel_fpu_enable would not be kept on for more than
> a 4k chunk, since it disables preemption. The choice of 4k isn't totally
> scientific, but it's not a bad guess either, and it's what's used in
> both the x86 poly1305, blake2s, and nhpoly1305 code already (in the form
> of PAGE_SIZE, which this commit corrects to be explicitly 4k for the
> former two).
>
> Ard did some back of the envelope calculations and found that
> at 5 cycles/byte (overestimate) on a 1ghz processor (pretty slow), 4k
> means we have a maximum preemption disabling of 20us, which Sebastian
> confirmed was probably a good limit.
>
> Unfortunately the chunking appears to have been left out of the final
> patchset that added the glue code. So, this commit adds it back in.
>
> Fixes: 84e03fa39fbe ("crypto: x86/chacha - expose SIMD ChaCha routine as
> library function")
> Fixes: b3aad5bad26a ("crypto: arm64/chacha - expose arm64 ChaCha routine as
> library function")
> Fixes: a44a3430d71b ("crypto: arm/chacha - expose ARM ChaCha routine as
> library function")
> Fixes: d7d7b8535662 ("crypto: x86/poly1305 - wire up faster implementations
> for kernel")
> Fixes: f569ca164751 ("crypto: arm64/poly1305 - incorporate OpenSSL/CRYPTOGAMS
> NEON implementation")
> Fixes: a6b803b3ddc7 ("crypto: arm/poly1305 - incorporate OpenSSL/CRYPTOGAMS
> NEON implementation")
> Fixes: ed0356eda153 ("crypto: blake2s - x86_64 SIMD implementation")
> Cc: Eric Biggers
> Cc: Ard Biesheuvel
> Cc: Sebastian Andrzej Siewior
> Cc: sta...@vger.kernel.org
> Signed-off-by: Jason A. Donenfeld
> ---
> Changes v2->v3:
> - [Eric] Split nhpoly1305 changes into separate commit, since it's not
>related to the library interface.
>
> Changes v1->v2:
> - [Ard] Use explicit 4k chunks instead of PAGE_SIZE.
> - [Eric] Prefer do-while over for (;;).
>
> arch/arm/crypto/chacha-glue.c| 14 +++---
> arch/arm/crypto/poly1305-glue.c | 15 +++
> arch/arm64/crypto/chacha-neon-glue.c | 14 +++---
> arch/arm64/crypto/poly1305-glue.c| 15 +++
> arch/x86/crypto/blake2s-glue.c | 10 --
> arch/x86/crypto/chacha_glue.c| 14 +++---
> arch/x86/crypto/poly1305_glue.c | 13 ++---
> 7 files changed, 65 insertions(+), 30 deletions(-)
All applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH -next] crypto: hisilicon/qm - Make qm_controller_reset() static
On Thu, Apr 23, 2020 at 10:22:36AM +0800, Zou Wei wrote: > Fix the following sparse warning: > > drivers/crypto/hisilicon/qm.c:3079:5: warning: symbol 'qm_controller_reset' > was not declared. Should it be static? > > Reported-by: Hulk Robot > Signed-off-by: Zou Wei > --- > drivers/crypto/hisilicon/qm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] padata: add separate cpuhp node for CPUHP_PADATA_DEAD
On Tue, Apr 21, 2020 at 12:34:55PM -0400, Daniel Jordan wrote:
> Removing the pcrypt module triggers this:
>
> general protection fault, probably for non-canonical
> address 0xdead0122
> CPU: 5 PID: 264 Comm: modprobe Not tainted 5.6.0+ #2
> Hardware name: QEMU Standard PC
> RIP: 0010:__cpuhp_state_remove_instance+0xcc/0x120
> Call Trace:
>padata_sysfs_release+0x74/0xce
>kobject_put+0x81/0xd0
>padata_free+0x12/0x20
>pcrypt_exit+0x43/0x8ee [pcrypt]
>
> padata instances wrongly use the same hlist node for the online and dead
> states, so __padata_free()'s second cpuhp remove call chokes on the node
> that the first poisoned.
>
> cpuhp multi-instance callbacks only walk forward in cpuhp_step->list and
> the same node is linked in both the online and dead lists, so the list
> corruption that results from padata_alloc() adding the node to a second
> list without removing it from the first doesn't cause problems as long
> as no instances are freed.
>
> Avoid the issue by giving each state its own node.
>
> Fixes: 894c9ef9780c ("padata: validate cpumask without removed CPU during
> offline")
> Signed-off-by: Daniel Jordan
> Cc: Herbert Xu
> Cc: Steffen Klassert
> Cc: linux-cry...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: sta...@vger.kernel.org # v5.4+
> ---
> include/linux/padata.h | 6 --
> kernel/padata.c| 14 --
> 2 files changed, 12 insertions(+), 8 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] lib/mpi: Fix 64-bit MIPS build with Clang
On Tue, Apr 21, 2020 at 02:47:04PM -0700, Nathan Chancellor wrote:
> When building 64r6_defconfig with CONFIG_MIPS32_O32 disabled and
> CONFIG_CRYPTO_RSA enabled:
>
> lib/mpi/generic_mpih-mul1.c:37:24: error: invalid use of a cast in a
> inline asm context requiring an l-value: remove the cast
> or build with -fheinous-gnu-extensions
> umul_ppmm(prod_high, prod_low, s1_ptr[j], s2_limb);
> ~^
> lib/mpi/longlong.h:664:22: note: expanded from macro 'umul_ppmm'
> : "=d" ((UDItype)(w0))
> ~~^~~
> lib/mpi/generic_mpih-mul1.c:37:13: error: invalid use of a cast in a
> inline asm context requiring an l-value: remove the cast
> or build with -fheinous-gnu-extensions
> umul_ppmm(prod_high, prod_low, s1_ptr[j], s2_limb);
> ~~^~~~
> lib/mpi/longlong.h:668:22: note: expanded from macro 'umul_ppmm'
> : "=d" ((UDItype)(w1))
> ~~^~~
> 2 errors generated.
>
> This special case for umul_ppmm for MIPS64r6 was added in
> commit bbc25bee37d2b ("lib/mpi: Fix umul_ppmm() for MIPS64r6"), due to
> GCC being inefficient and emitting a __multi3 intrinsic.
>
> There is no such issue with clang; with this patch applied, I can build
> this configuration without any problems and there are no link errors
> like mentioned in the commit above (which I can still reproduce with
> GCC 9.3.0 when that commit is reverted). Only use this definition when
> GCC is being used.
>
> This really should have been caught by commit b0c091ae04f67 ("lib/mpi:
> Eliminate unused umul_ppmm definitions for MIPS") when I was messing
> around in this area but I was not testing 64-bit MIPS at the time.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/885
> Reported-by: Dmitry Golovin
> Signed-off-by: Nathan Chancellor
> ---
> lib/mpi/longlong.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] crypto: ccp: Add support for SEV-ES to the PSP driver
On Tue, Apr 21, 2020 at 12:44:49PM -0500, Tom Lendacky wrote: > To provide support for SEV-ES, the hypervisor must provide an area of > memory to the PSP. Once this Trusted Memory Region (TMR) is provided to > the PSP, the contents of this area of memory are no longer available to > the x86. > > Update the PSP driver to allocate a 1MB region for the TMR that is 1MB > aligned and then provide it to the PSP through the SEV INIT command. > > Signed-off-by: Tom Lendacky > > --- > > Changes since v1: > - No need to over-allocate the memory area to obtain the required > alignment when using the page allocator. > --- > drivers/crypto/ccp/sev-dev.c | 43 > include/linux/psp-sev.h | 2 ++ > include/uapi/linux/psp-sev.h | 2 ++ > 3 files changed, 47 insertions(+) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v7 4/7] OPP: Add support for parsing interconnect bandwidth
On 24-04-20, 12:20, Matthias Kaehlcke wrote:
> On Fri, Apr 24, 2020 at 06:54:01PM +0300, Georgi Djakov wrote:
> > + for (i = 0; i < num_paths; i++) {
> > + opp_table->paths[i] = of_icc_get_by_index(dev, i);
> > + if (IS_ERR(opp_table->paths[i])) {
> > + ret = PTR_ERR(opp_table->paths[i]);
> > + if (ret != -EPROBE_DEFER) {
> > + dev_err(dev, "%s: Unable to get path%d: %d\n",
> > + __func__, i, ret);
> > + }
>
> nit: curly braces not needed
Again, braces are preferred across multi-line blocks. Please keep it.
--
viresh
Re: [PATCH] net/mlx5: reduce stack usage in qp_read_field
On Tue, Apr 28, 2020 at 11:23:47PM +0200, Arnd Bergmann wrote:
> Moving the mlx5_ifc_query_qp_out_bits structure on the stack was a bit
> excessive and now causes the compiler to complain on 32-bit architectures:
>
> drivers/net/ethernet/mellanox/mlx5/core/debugfs.c: In function
> 'qp_read_field':
> drivers/net/ethernet/mellanox/mlx5/core/debugfs.c:274:1: error: the frame
> size of 1104 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
>
> Revert the previous patch partially to use dynamically allocation as
> the code did before. Unfortunately there is no good error handling
> in case the allocation fails.
>
> Fixes: 57a6c5e992f5 ("net/mlx5: Replace hand written QP context struct with
> automatic getters")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/net/ethernet/mellanox/mlx5/core/debugfs.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
Thanks Arnd, I'll pick it to mlx5-next.
I was under impression that the frame size was increased a long
time ago. Is this 1K limit still effective for all archs?
Or is it is 32-bit leftover?
Thanks
Re: [PATCH v7 2/7] OPP: Add helpers for reading the binding properties
On 24-04-20, 10:30, Matthias Kaehlcke wrote:
> Hi Georgi,
>
> On Fri, Apr 24, 2020 at 06:53:59PM +0300, Georgi Djakov wrote:
> > From: Saravana Kannan
> >
> > The opp-hz DT property is not mandatory and we may use another property
> > as a key in the OPP table. Add helper functions to simplify the reading
> > and comparing the keys.
> >
> > Signed-off-by: Saravana Kannan
> > Signed-off-by: Georgi Djakov
> > ---
> > v7:
> > * Extracted just the helpers from patch v6, as Viresh advised to split it.
> >
> > v6: https://lore.kernel.org/r/20191207002424.201796-3-sarava...@google.com
> >
> > drivers/opp/core.c | 15 +--
> > drivers/opp/of.c | 42 ++
> > drivers/opp/opp.h | 1 +
> > 3 files changed, 40 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> > index ba43e6a3dc0a..c9c1bbe6ae27 100644
> > --- a/drivers/opp/core.c
> > +++ b/drivers/opp/core.c
> > @@ -1272,11 +1272,21 @@ static bool _opp_supported_by_regulators(struct
> > dev_pm_opp *opp,
> > return true;
> > }
> >
> > +int _opp_compare_key(struct dev_pm_opp *opp1, struct dev_pm_opp *opp2)
> > +{
> > + if (opp1->rate != opp2->rate)
> > + return opp1->rate < opp2->rate ? -1 : 1;
> > + if (opp1->level != opp2->level)
> > + return opp1->level < opp2->level ? -1 : 1;
> > + return 0;
> > +}
> > +
> > static int _opp_is_duplicate(struct device *dev, struct dev_pm_opp
> > *new_opp,
> > struct opp_table *opp_table,
> > struct list_head **head)
> > {
> > struct dev_pm_opp *opp;
> > + int opp_cmp;
> >
> > /*
> > * Insert new OPP in order of increasing frequency and discard if
> > @@ -1287,12 +1297,13 @@ static int _opp_is_duplicate(struct device *dev,
> > struct dev_pm_opp *new_opp,
> > * loop.
> > */
> > list_for_each_entry(opp, _table->opp_list, node) {
> > - if (new_opp->rate > opp->rate) {
> > + opp_cmp = _opp_compare_key(new_opp, opp);
> > + if (opp_cmp > 0) {
> > *head = >node;
> > continue;
> > }
> >
> > - if (new_opp->rate < opp->rate)
> > + if (opp_cmp < 0)
> > return 0;
> >
> > /* Duplicate OPPs */
> > diff --git a/drivers/opp/of.c b/drivers/opp/of.c
> > index 9cd8f0adacae..e33169c7e045 100644
> > --- a/drivers/opp/of.c
> > +++ b/drivers/opp/of.c
> > @@ -521,6 +521,28 @@ void dev_pm_opp_of_remove_table(struct device *dev)
> > }
> > EXPORT_SYMBOL_GPL(dev_pm_opp_of_remove_table);
> >
> > +static int _read_opp_key(struct dev_pm_opp *new_opp, struct device_node
> > *np,
> > +bool *rate_not_available)
> > +{
> > + u64 rate;
> > + int ret;
> > +
> > + ret = of_property_read_u64(np, "opp-hz", );
> > + if (!ret) {
> > + /*
> > +* Rate is defined as an unsigned long in clk API, and so
> > +* casting explicitly to its type. Must be fixed once rate is 64
> > +* bit guaranteed in clk API.
> > +*/
> > + new_opp->rate = (unsigned long)rate;
> > + }
>
> nit: curly braces are not needed
In fact they are as the comment is present within the if block (which
is the right thing to do). Yes the code will compile fine without
braces, but coding guideline suggests it around multi-line-statements.
> > + *rate_not_available = !!ret;
> > +
> > + of_property_read_u32(np, "opp-level", _opp->level);
> > +
> > + return ret;
> > +}
> > +
> > /**
> > * _opp_add_static_v2() - Allocate static OPPs (As per 'v2' DT bindings)
> > * @opp_table: OPP table
> > @@ -558,26 +580,14 @@ static struct dev_pm_opp *_opp_add_static_v2(struct
> > opp_table *opp_table,
> > if (!new_opp)
> > return ERR_PTR(-ENOMEM);
> >
> > - ret = of_property_read_u64(np, "opp-hz", );
> > + ret = _read_opp_key(new_opp, np, _not_available);
> > if (ret < 0) {
> > - /* "opp-hz" is optional for devices like power domains. */
> > - if (!opp_table->is_genpd) {
> > - dev_err(dev, "%s: opp-hz not found\n", __func__);
> > - goto free_opp;
> > - }
> > + if (!opp_table->is_genpd)
> > + dev_err(dev, "%s: opp key field not found\n", __func__);
Looks like the logic got changed here ? We used to goto free_opp only
if !is_genpd earlier..
> >
> > - rate_not_available = true;
> > - } else {
> > - /*
> > -* Rate is defined as an unsigned long in clk API, and so
> > -* casting explicitly to its type. Must be fixed once rate is 64
> > -* bit guaranteed in clk API.
> > -*/
> > - new_opp->rate = (unsigned long)rate;
> > + goto free_opp;
> > }
> >
> > - of_property_read_u32(np, "opp-level", _opp->level);
> > -
> > /* Check if the OPP supports
Re: [PATCH v7 1/7] dt-bindings: opp: Introduce opp-peak-kBps and opp-avg-kBps bindings
On 24-04-20, 18:53, Georgi Djakov wrote: > From: Saravana Kannan > > Interconnects often quantify their performance points in terms of > bandwidth. So, add opp-peak-kBps (required) and opp-avg-kBps (optional) to > allow specifying Bandwidth OPP tables in DT. > > opp-peak-kBps is a required property that replaces opp-hz for Bandwidth OPP > tables. > > opp-avg-kBps is an optional property that can be used in Bandwidth OPP > tables. > > Signed-off-by: Saravana Kannan > Signed-off-by: Georgi Djakov > --- > v7: > * I have dropped Rob's Reviewed-by, because of the minor change below: > * In order to store the bandwidth values for multiple paths, the > opp-peak-kBps and opp-avg-kBps are now defined as arrays of integers, > instead of just integers. > * Improved wording (Viresh) > > v6: https://lore.kernel.org/r/20191207002424.201796-2-sarava...@google.com > > Documentation/devicetree/bindings/opp/opp.txt | 20 --- > .../devicetree/bindings/property-units.txt| 4 > 2 files changed, 21 insertions(+), 3 deletions(-) > > diff --git a/Documentation/devicetree/bindings/opp/opp.txt > b/Documentation/devicetree/bindings/opp/opp.txt > index 68592271461f..a8a6a3bfcfcb 100644 > --- a/Documentation/devicetree/bindings/opp/opp.txt > +++ b/Documentation/devicetree/bindings/opp/opp.txt > @@ -83,9 +83,17 @@ properties. > > Required properties: > - opp-hz: Frequency in Hz, expressed as a 64-bit big-endian integer. This is > a > - required property for all device nodes but devices like power domains. The > - power domain nodes must have another (implementation dependent) property > which > - uniquely identifies the OPP nodes. > + required property for all device nodes except for devices like power > domains > + or bandwidth opp tables. The devices which don't have this property must > have bandwidth opp table ? > + another (implementation dependent) property which uniquely identifies the > OPP > + nodes. > + > + > +- opp-peak-kBps: Peak bandwidth in kilobytes per second, expressed as an > array > + of 32-bit big-endian integers. Each element of the array represents the > + peak bandwidth value of each interconnect path. The number of elements > should > + match the number of interconnect paths. This is a required property for > + bandwidth OPP tables. > > Optional properties: > - opp-microvolt: voltage in micro Volts. > @@ -132,6 +140,12 @@ Optional properties: > - opp-level: A value representing the performance level of the device, >expressed as a 32-bit integer. > > +- opp-avg-kBps: Average bandwidth in kilobytes per second, expressed as an > array > + of 32-bit big-endian integers. Each element of the array represents the > + average bandwidth value of each interconnect path. The number of elements > + should match the number of interconnect paths. This property is only > + meaningful in OPP tables where opp-peak-kBps is present. > + > - clock-latency-ns: Specifies the maximum possible transition latency (in >nanoseconds) for switching to this OPP from any other OPP. > > diff --git a/Documentation/devicetree/bindings/property-units.txt > b/Documentation/devicetree/bindings/property-units.txt > index e9b8360b3288..c80a110c1e26 100644 > --- a/Documentation/devicetree/bindings/property-units.txt > +++ b/Documentation/devicetree/bindings/property-units.txt > @@ -41,3 +41,7 @@ Temperature > Pressure > > -kpascal : kilopascal > + > +Throughput > + > +-kBps: kilobytes per second -- viresh
Re: [PATCH v3 1/1] scsi: pm: Balance pm_only counter of request queue during system resume
On 2020-04-29 21:10, Can Guo wrote: > During system resume, scsi_resume_device() decreases a request queue's > pm_only counter if the scsi device was quiesced before. But after that, > if the scsi device's RPM status is RPM_SUSPENDED, the pm_only counter is > still held (non-zero). Current scsi resume hook only sets the RPM status > of the scsi device and its request queue to RPM_ACTIVE, but leaves the > pm_only counter unchanged. This may make the request queue's pm_only > counter remain non-zero after resume hook returns, hence those who are > waiting on the mq_freeze_wq would never be woken up. Fix this by calling > blk_post_runtime_resume() if pm_only is non-zero to balance the pm_only > counter which is held by the scsi device's RPM ops. How was this issue discovered? How has this patch been tested? Thanks, Bart.
Re: [PATCH net-next v3 2/2] net: phy: tja11xx: add support for master-slave configuration
On Wed, Apr 29, 2020 at 08:20:53PM +0200, Andrew Lunn wrote:
> > +static int tja11xx_config_aneg(struct phy_device *phydev)
> > +{
> > + u16 ctl = 0;
> > + int ret;
> > +
> > + switch (phydev->master_slave_set) {
> > + case PORT_MODE_CFG_MASTER_FORCE:
> > + case PORT_MODE_CFG_MASTER_PREFERRED:
> > + ctl |= MII_CFG1_MASTER_SLAVE;
> > + break;
> > + case PORT_MODE_CFG_SLAVE_FORCE:
> > + case PORT_MODE_CFG_SLAVE_PREFERRED:
> > + break;
> > + case PORT_MODE_CFG_UNKNOWN:
> > + return 0;
> > + default:
> > + phydev_warn(phydev, "Unsupported Master/Slave mode\n");
> > + return -ENOTSUPP;
> > + }
>
> Does the hardware actually support PORT_MODE_CFG_SLAVE_PREFERRED and
> PORT_MODE_CFG_MASTER_PREFERRED? I thought that required autoneg, which
> this PHY does not support? So i would of expected these two values to
> return ENOTSUPP?
I do not have strong opinion here. Will change it.
Regards,
Oleksij
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
signature.asc
Description: PGP signature
Re: [PATCH] misc: fastrpc: fix memory leak
On Wed 29 Apr 08:29 PDT 2020, Srinivas Kandagatla wrote:
> if misc_register() fails, previously allocated data is left without freeing,
> this could result in memory leak.
s/could/will/
>
> So fix it!
>
As Markus pointed out, a Fixes: tag would be in order to make sure this
is backported properly.
PS: although unlikely, if of_platform_populate() where to fail we're
leaking both the contet and the misc device.
Regards,
Bjorn
> Signed-off-by: Srinivas Kandagatla
> ---
> drivers/misc/fastrpc.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
> index e3e085e33d46..9065d3e71ff7 100644
> --- a/drivers/misc/fastrpc.c
> +++ b/drivers/misc/fastrpc.c
> @@ -1613,8 +1613,10 @@ static int fastrpc_rpmsg_probe(struct rpmsg_device
> *rpdev)
> domains[domain_id]);
> data->miscdev.fops = _fops;
> err = misc_register(>miscdev);
> - if (err)
> + if (err) {
> + kfree(data);
> return err;
> + }
>
> kref_init(>refcount);
>
> --
> 2.21.0
>
Re: [PATCH] arm: mm: use __pfn_to_section() to get mem_section
On 04/30/2020 09:34 AM, Guixiong Wei wrote: > Use __pfn_to_section() to get mem_section, instead of open-coding it. There is no open coding here. __pfn_to_section() helper which already wraps around __nr_to_section(pfn_to_section_nr(pfn)), should be used directly instead. > No semantic changes. and functional change. Please reword the commit message. > > Signed-off-by: Guixiong Wei > --- > arch/arm64/mm/init.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c > index e42727e3568e..d2df416b840e 100644 > --- a/arch/arm64/mm/init.c > +++ b/arch/arm64/mm/init.c > @@ -272,7 +272,7 @@ int pfn_valid(unsigned long pfn) > if (pfn_to_section_nr(pfn) >= NR_MEM_SECTIONS) > return 0; > > - if (!valid_section(__nr_to_section(pfn_to_section_nr(pfn > + if (!valid_section(__pfn_to_section(pfn)) Looks good. > return 0; > #endif > return memblock_is_map_memory(addr); >
Re: [PATCH net-next v3 1/2] ethtool: provide UAPI for PHY master/slave configuration.
Hi Michal, On Wed, Apr 29, 2020 at 09:52:22PM +0200, Michal Kubecek wrote: > On Tue, Apr 28, 2020 at 09:53:07AM +0200, Oleksij Rempel wrote: > > This UAPI is needed for BroadR-Reach 100BASE-T1 devices. Due to lack of > > auto-negotiation support, we needed to be able to configure the > > MASTER-SLAVE role of the port manually or from an application in user > > space. > > > > The same UAPI can be used for 1000BASE-T or MultiGBASE-T devices to > > force MASTER or SLAVE role. See IEEE 802.3-2018: > > 22.2.4.3.7 MASTER-SLAVE control register (Register 9) > > 22.2.4.3.8 MASTER-SLAVE status register (Register 10) > > 40.5.2 MASTER-SLAVE configuration resolution > > 45.2.1.185.1 MASTER-SLAVE config value (1.2100.14) > > 45.2.7.10 MultiGBASE-T AN control 1 register (Register 7.32) > > > > The MASTER-SLAVE role affects the clock configuration: > > > > --- > > When the PHY is configured as MASTER, the PMA Transmit function shall > > source TX_TCLK from a local clock source. When configured as SLAVE, the > > PMA Transmit function shall source TX_TCLK from the clock recovered from > > data stream provided by MASTER. > > > > iMX6Q KSZ9031XXX > > --\/---\/\ > > || ||| > > MAC || PHY Slave |<-->| PHY Master | > > |<--- 125 MHz ---+-<--/ || \ | > > --/\---/\/ > >^ > > \-TX_TCLK > > > > --- > > > > Since some clock or link related issues are only reproducible in a > > specific MASTER-SLAVE-role, MAC and PHY configuration, it is beneficial > > to provide generic (not 100BASE-T1 specific) interface to the user space > > for configuration flexibility and trouble shooting. > > > > Signed-off-by: Oleksij Rempel > > --- > [...] > > diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c > > index 72c69a9c8a98a..a6a774beb2f90 100644 > > --- a/drivers/net/phy/phy.c > > +++ b/drivers/net/phy/phy.c > > @@ -285,6 +285,9 @@ int phy_ethtool_ksettings_set(struct phy_device *phydev, > > duplex != DUPLEX_FULL))) > > return -EINVAL; > > > > + if (!ethtool_validate_master_slave_cfg(cmd->base.master_slave_cfg)) > > + return -EINVAL; > > + > > Unless we can/want to pass extack down here, I would prefer to have the > sanity check in ethtool_update_linkmodes() or ethtool_set_linkmodes() so > that we can set meaningful error message and offending attribute in > extack. (It could be even part of the policy.) Also, with the check only > here, drivers/devices not calling phy_ethtool_set_link_ksettings() > (directly or via phy_ethtool_set_link_ksettings()) and not handling the > new members themselves would silently ignore any value from userspace. ok > > phydev->autoneg = autoneg; > > > > phydev->speed = speed; > [...] > > +static int genphy_setup_master_slave(struct phy_device *phydev) > > +{ > > + u16 ctl = 0; > > + > > + if (!phydev->is_gigabit_capable) > > + return 0; > > Shouldn't we rather return -EOPNOTSUPP if value different from > CFG_UNKNOWN was requested? sounds plausible. > > + > > + switch (phydev->master_slave_set) { > > + case PORT_MODE_CFG_MASTER_PREFERRED: > > + ctl |= CTL1000_PREFER_MASTER; > > + break; > > + case PORT_MODE_CFG_SLAVE_PREFERRED: > > + break; > > + case PORT_MODE_CFG_MASTER_FORCE: > > + ctl |= CTL1000_AS_MASTER; > > + /* fallthrough */ > > + case PORT_MODE_CFG_SLAVE_FORCE: > > + ctl |= CTL1000_ENABLE_MASTER; > > + break; > > + case PORT_MODE_CFG_UNKNOWN: > > + return 0; > > + default: > > + phydev_warn(phydev, "Unsupported Master/Slave mode\n"); > > + return 0; > > + } > [...] > > diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h > > index 92f737f101178..eb680e3d6bda5 100644 > > --- a/include/uapi/linux/ethtool.h > > +++ b/include/uapi/linux/ethtool.h > > @@ -1666,6 +1666,31 @@ static inline int ethtool_validate_duplex(__u8 > > duplex) > > return 0; > > } > > > > +/* Port mode */ > > +#define PORT_MODE_CFG_UNKNOWN 0 > > +#define PORT_MODE_CFG_MASTER_PREFERRED 1 > > +#define PORT_MODE_CFG_SLAVE_PREFERRED 2 > > +#define PORT_MODE_CFG_MASTER_FORCE 3 > > +#define PORT_MODE_CFG_SLAVE_FORCE 4 > > +#define PORT_MODE_STATE_UNKNOWN0 > > +#define PORT_MODE_STATE_MASTER 1 > > +#define PORT_MODE_STATE_SLAVE 2 > > +#define PORT_MODE_STATE_ERR3 > > You have "MASTER_SLAVE" or "master_slave" everywhere but "PORT_MODE" in > these constants which is inconsistent.
Re: [RFC 1/5] soundwire: bus_type: add sdw_master_device support
On 30-04-20, 11:24, Bard liao wrote: > > On 4/28/2020 3:51 PM, Vinod Koul wrote: > > On 28-04-20, 08:55, Greg KH wrote: > > > On Tue, Apr 28, 2020 at 12:19:51PM +0530, Vinod Koul wrote: > > > > On 28-04-20, 08:37, Greg KH wrote: > > > > > On Tue, Apr 28, 2020 at 10:01:44AM +0530, Vinod Koul wrote: > > > > > > > > That is not true for everyone, it is only true for Intel, pls > > > > > > > > call that > > > > > > > > out as well... > > > > > > > Why is it not true for everyone? How else do you get the pm > > > > > > > stuff back > > > > > > > to your hardware? > > > > > > The rest of the world would do using the real controller device. For > > > > > > example the soundwire controller on Qualcomm devices is enumerated > > > > > > as a > > > > > > DT device and is using these... > > > > > > > > > > > > If Intel had a standalone controller or enumerated as individual > > > > > > functions, it would have been a PCI device and would manage as such > > > > > If it is not a standalone controller, what exactly is it? I thought > > > > > it > > > > > was an acpi device, am I mistaken? > > > > > > > > > > What is the device that the proper soundwire controller driver binds > > > > > to > > > > > on an Intel-based system? > > > > The HDA controller which is a PCI device. The device represent HDA > > > > function, DSP and Soundwire controller instances (yes it is typically > > > > more than one instance) > > > Then those "instances" should be split up into individual devices that a > > > driver can bind to. See the work happening on the "virtual" bus for > > > examples of how that can be done. > > Yes removing platform devices is the goal for Intel now :) Pierre & Bard > > have been diligently trying to solve this. > > > > Only difference is the means to end goal. I am not convinced that this > > should be in soundwire subsystem. > > > > Looks like folks are trying to review and port to use this bus. Makes > > sense to me.. > > https://lore.kernel.org/netdev/c5197d2f-3840-d304-6b09-d334cae81...@linux.intel.com/ > > > > > A platform device better not be being used here, I'm afraid to look at > > > the code now... > > Well if the plan for 'virtual-bus' goes well, it should be a simple > > replacement of platform->virtual for Intel driver. Rest of the driver > > should not be impacted :) > > We can't expect when will 'virtual-bus' be upstream and it's not feasible > to wait forever. Can we move forward with current solution and switch to > 'virtual-bus' whenever it is upstream? the move from platform-device to virtual-device should happen once the virtual-bus' is accepted upstream. till then imo you should continue with current platform device and once you have virtual-bus upstream, replace it with virtual-device. Note: I am going to hold you on that :) Rest of the pieces like sdw_master_device and sysfs parts are not dependent upon this and should be sent for review and we can merge when ready, hopefully for 5.8. Thanks -- ~Vinod
Re: [PATCH 10/10] efi/libstub: Check return value of efi_parse_options
Hi Arvind,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on efi/next]
[also build test WARNING on next-20200429]
[cannot apply to v5.7-rc3]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Arvind-Sankar/efi-some-cleanups-refactoring-for-efi-next/20200430-051025
base: https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git next
config: arm-defconfig (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project
1ccde533425a4ba9d379510206ad680ff9702129)
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm cross compiling tool for clang build
# apt-get install binutils-arm-linux-gnueabi
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
All warnings (new ones prefixed by >>):
>> drivers/firmware/efi/libstub/efi-stub.c:220:7: warning: variable 'si' is
>> used uninitialized whenever 'if' condition is true
>> [-Wsometimes-uninitialized]
if (status != EFI_SUCCESS) {
^
drivers/firmware/efi/libstub/efi-stub.c:339:19: note: uninitialized use
occurs here
free_screen_info(si);
^~
drivers/firmware/efi/libstub/efi-stub.c:220:3: note: remove the 'if' if its
condition is always false
if (status != EFI_SUCCESS) {
^~~~
drivers/firmware/efi/libstub/efi-stub.c:212:7: warning: variable 'si' is
used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
if (status != EFI_SUCCESS) {
^
drivers/firmware/efi/libstub/efi-stub.c:339:19: note: uninitialized use
occurs here
free_screen_info(si);
^~
drivers/firmware/efi/libstub/efi-stub.c:212:3: note: remove the 'if' if its
condition is always false
if (status != EFI_SUCCESS) {
^~~~
drivers/firmware/efi/libstub/efi-stub.c:161:24: note: initialize the
variable 'si' to silence this warning
struct screen_info *si;
^
= NULL
2 warnings generated.
vim +220 drivers/firmware/efi/libstub/efi-stub.c
119
120 /*
121 * This function handles the architcture specific differences between
arm and
122 * arm64 regarding where the kernel image must be loaded and any memory
that
123 * must be reserved. On failure it is required to free all
124 * all allocations it has made.
125 */
126 efi_status_t handle_kernel_image(unsigned long *image_addr,
127 unsigned long *image_size,
128 unsigned long *reserve_addr,
129 unsigned long *reserve_size,
130 unsigned long dram_base,
131 efi_loaded_image_t *image);
132
133 asmlinkage void __noreturn efi_enter_kernel(unsigned long entrypoint,
134 unsigned long fdt_addr,
135 unsigned long fdt_size);
136
137 /*
138 * EFI entry point for the arm/arm64 EFI stubs. This is the entrypoint
139 * that is described in the PE/COFF header. Most of the code is the
same
140 * for both archictectures, with the arch-specific code provided in the
141 * handle_kernel_image() function.
142 */
143 efi_status_t efi_entry(efi_handle_t handle, efi_system_table_t
*sys_table_arg)
144 {
145 efi_loaded_image_t *image;
146 efi_status_t status;
147 unsigned long image_addr;
148 unsigned long image_size = 0;
149 unsigned long dram_base;
150 /* addr/point and size pairs for memory management*/
151 unsigned long initrd_addr = 0;
152 unsigned long initrd_size = 0;
153 unsigned long fdt_addr = 0; /* Original DTB */
154 unsigned long fdt_size = 0;
155 char *cmdline_ptr = NULL;
156 int cmdline_size = 0;
157 efi_guid_t loaded_image_proto = LOADED_IMAGE_PROTOCOL_GUID;
158 unsigned long reserve_addr = 0;
159 unsigned long reserve_size = 0;
160 enum efi_secureboot_
Re: [PATCH v3 1/3] crypto: drbg: DRBG should select SHA512
On Fri, Apr 24, 2020 at 01:40:45PM +, Corentin Labbe wrote: > Since DRBG could use SHA384/SHA512, it should select it. > > Signed-off-by: Corentin Labbe > --- > crypto/Kconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/crypto/Kconfig b/crypto/Kconfig > index c24a47406f8f..6d27fc6a7bf5 100644 > --- a/crypto/Kconfig > +++ b/crypto/Kconfig > @@ -1810,10 +1810,12 @@ config CRYPTO_DRBG_HMAC > default y > select CRYPTO_HMAC > select CRYPTO_SHA256 > + select CRYPTO_SHA512 > > config CRYPTO_DRBG_HASH > bool "Enable Hash DRBG" > select CRYPTO_SHA256 > + select CRYPTO_SHA512 > help > Enable the Hash DRBG variant as defined in NIST SP800-90A. The default hash drbg is sha256, the others are only optional. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: BPF vs objtool again
On Wed, Apr 29, 2020 at 09:24:00PM -0700, Alexei Starovoitov wrote:
> > This would actually be contingent on RETPOLINE, not FRAME_POINTER.
> >
> > (FRAME_POINTER was the other issue with the "optimize" attribute, which
> > we're reverting so it'll no longer be a problem.)
> >
> > So if you're not concerned about the retpoline text growth, it could be
> > as simple as:
> >
> > #define CONT ({ insn++; goto *jumptable[insn->code]; })
> > #define CONT_JMP ({ insn++; goto *jumptable[insn->code]; })
> >
> >
> > Or, if you wanted to avoid the text growth, it could be:
> >
> > #ifdef CONFIG_RETPOLINE
>
> I'm a bit lost. So objtool is fine with the asm when retpoline is on?
Yeah, it's confusing... this has been quite an adventure with GCC.
Objtool is fine with the RETPOLINE double goto. It's only the
!RETPOLINE double goto which is the problem, because that triggers
more GCC weirdness (see 3193c0836f20).
> Then pls do:
> #if defined(CONFIG_RETPOLINE) || !defined(CONFIG_X86)
>
> since there is no need to mess with other archs.
Getting rid of select_insn altogether would make the code a lot simpler,
but it's your call. I'll make a patch soon.
--
Josh
Re: [PATCH net-next v3 1/2] ethtool: provide UAPI for PHY master/slave configuration.
Hi Andrew,
On Wed, Apr 29, 2020 at 08:16:14PM +0200, Andrew Lunn wrote:
> On Tue, Apr 28, 2020 at 09:53:07AM +0200, Oleksij Rempel wrote:
>
> Hi Oleksij
>
> Sorry for taking a while to review this. I was busy fixing the FEC
> driver which i broke :-(
Not problem.
Interesting, what is wrong with FEC? We use it a lot.
> > --- a/Documentation/networking/ethtool-netlink.rst
> > +++ b/Documentation/networking/ethtool-netlink.rst
> > @@ -399,6 +399,8 @@ Kernel response contents:
> >``ETHTOOL_A_LINKMODES_PEER`` bitset partner link modes
> >``ETHTOOL_A_LINKMODES_SPEED`` u32 link speed (Mb/s)
> >``ETHTOOL_A_LINKMODES_DUPLEX``u8 duplex mode
> > + ``ETHTOOL_A_LINKMODES_MASTER_SLAVE_CFG`` u8 Master/slave port mode
> > + ``ETHTOOL_A_LINKMODES_MASTER_SLAVE_STATE`` u8 Master/slave port
> > mode
> > == ==
>
> I've not used Sphinx for a while. But it used to be, tables had to be
> correctly aligned. I think you need to pad the other rows with spaces.
>
> Also, the comments should differ. The first is how we want it
> configured, the second is the current state.
ok
> >
> > For ``ETHTOOL_A_LINKMODES_OURS``, value represents advertised modes and
> > mask
> > @@ -421,6 +423,7 @@ Request contents:
> >``ETHTOOL_A_LINKMODES_PEER`` bitset partner link modes
> >``ETHTOOL_A_LINKMODES_SPEED`` u32 link speed (Mb/s)
> >``ETHTOOL_A_LINKMODES_DUPLEX``u8 duplex mode
> > + ``ETHTOOL_A_LINKMODES_MASTER_SLAVE_CFG`` u8 Master/slave port mode
> > == ==
>
> Same table cleanup needed here.
>
> > +static int genphy_read_master_slave(struct phy_device *phydev)
> > +{
> > + int cfg, state = 0;
> > + u16 val;
> > +
> > + phydev->master_slave_get = 0;
> > + phydev->master_slave_state = 0;
>
> Could you use the _UNKNOWN #defined here?
ok
> > diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
> > index 92f737f101178..eb680e3d6bda5 100644
> > --- a/include/uapi/linux/ethtool.h
> > +++ b/include/uapi/linux/ethtool.h
> > @@ -1666,6 +1666,31 @@ static inline int ethtool_validate_duplex(__u8
> > duplex)
> > return 0;
> > }
> >
> > +static inline int ethtool_validate_master_slave_cfg(__u8 cfg)
> > +{
> > + switch (cfg) {
> > + case PORT_MODE_CFG_MASTER_PREFERRED:
> > + case PORT_MODE_CFG_SLAVE_PREFERRED:
> > + case PORT_MODE_CFG_MASTER_FORCE:
> > + case PORT_MODE_CFG_SLAVE_FORCE:
> > + case PORT_MODE_CFG_UNKNOWN:
> > + return 1;
> > + }
> > +
> > + return 0;
> > +}
>
> Does this need to be an inline function?
Yes, otherwise we get a lot of "defined but not used " warnings.
Regards,
Oleksij
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
signature.asc
Description: PGP signature
Re: [PATCH] sound:hdmi:fix without unlocked before return
On 2020/4/29 15:27, Takashi Iwai wrote: On Sun, 26 Apr 2020 15:17:22 +0200, Wu Bo wrote: Fix the following coccicheck warning: sound/pci/hda/patch_hdmi.c:1852:2-8: preceding lock on line 1846 After add sanity check to pass klockwork check, The spdif_mutex should be unlock before return true in check_non_pcm_per_cvt(). Signed-off-by: Wu Bo Applied now with the correction of subject and Fixes tag as well as Cc-to-stable tag. thanks, Takashi . Thank you, I am sorry to forget to modify the V2 Patch version in time. thanks, Wu Bo
Re: [PATCH] dma-buf: Documentation: fix: `make htmldocs` warnings
On Wed, Apr 29, 2020 at 11:27:22PM -0300, Vitor Massaru Iha wrote: > On Wed, 2020-04-29 at 19:06 -0700, Randy Dunlap wrote: > > On 4/29/20 6:59 PM, Vitor Massaru Iha wrote: > > > Add missed ":" on kernel-doc function parameter. > > > > > > This patch fixes this warnings from `make htmldocs`: > > > ./drivers/dma-buf/dma-buf.c:678: warning: Function parameter or > > > member 'importer_ops' not described in 'dma_buf_dynamic_attach' > > > ./drivers/dma-buf/dma-buf.c:678: warning: Function parameter or > > > member 'importer_priv' not described in 'dma_buf_dynamic_attach' > > > > > > Signed-off-by: Vitor Massaru Iha > > > --- > > > drivers/dma-buf/dma-buf.c | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > > > index ccc9eda1bc28..0756d2155745 100644 > > > --- a/drivers/dma-buf/dma-buf.c > > > +++ b/drivers/dma-buf/dma-buf.c > > > @@ -655,8 +655,8 @@ EXPORT_SYMBOL_GPL(dma_buf_put); > > > * calls attach() of dma_buf_ops to allow device-specific attach > > > functionality > > > * @dmabuf: [in]buffer to attach device to. > > > * @dev: [in]device to be attached. > > > - * @importer_ops [in]importer operations for the > > > attachment > > > - * @importer_priv[in]importer private pointer for the > > > attachment > > > + * @importer_ops:[in]importer operations for the > > > attachment > > > + * @importer_priv: [in]importer private pointer for the > > > attachment > > > * > > > * Returns struct dma_buf_attachment pointer for this attachment. > > > Attachments > > > * must be cleaned up by calling dma_buf_detach(). > > > > > > > Sumit said that he would be applying my patch from April 7: > > https://lore.kernel.org/linux-media/7bcbe6fe-0b4b-87da-d003-b68a26eb4...@infradead.org/ > > > > thanks. > > Sorry. I didn't check if the patch has already been sent. Sumit - patch from Randy is neither applied to drm-misc-next nor drm-misc-fixes. A reminder in case it was lost somewhere. Sam
[PATCH v2 0/2] Add support for MaxLinear/Exar USB to serial converters
From: Manivannan Sadhasivam Hello, This series adds support for MaxLinear/Exar USB to serial converters. This driver only supports XR21V141X series but provision has been made to support other series in future. This driver is inspired from the initial one submitted by Patong Yang: https://patchwork.kernel.org/patch/10543261/ While the initial driver was a custom tty USB driver exposing whole new serial interface ttyXRUSBn, this version is completely based on USB serial core thus exposing the interfaces as ttyUSBn. This will avoid the overhead of exposing a new USB serial interface which the userspace tools are unaware of. This series has been tested with Hikey970 board hosting XR21V141X chip. Thanks, Mani Changes in v2: * Dropped the code related to handling variable register size. It's all u8 now. * Dropped the header file and moved the contents to driver itself. * Added Linus's reviewed-by tag for gpiochip patch. * Added PID to gpiochip label * Dropped gpiochip for interface 0 Manivannan Sadhasivam (2): usb: serial: Add MaxLinear/Exar USB to Serial driver usb: serial: xr_serial: Add gpiochip support drivers/usb/serial/Kconfig | 9 + drivers/usb/serial/Makefile| 1 + drivers/usb/serial/xr_serial.c | 833 + 3 files changed, 843 insertions(+) create mode 100644 drivers/usb/serial/xr_serial.c -- 2.17.1
[PATCH v2 2/2] usb: serial: xr_serial: Add gpiochip support
From: Manivannan Sadhasivam
Add gpiochip support for Maxlinear/Exar USB to serial converter
for controlling the available gpios.
Cc: Linus Walleij
Cc: linux-g...@vger.kernel.org
Reviewed-by: Linus Walleij
Signed-off-by: Manivannan Sadhasivam
---
drivers/usb/serial/xr_serial.c | 197 -
1 file changed, 196 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/serial/xr_serial.c b/drivers/usb/serial/xr_serial.c
index d607906e46ad..fa99e6bfffa2 100644
--- a/drivers/usb/serial/xr_serial.c
+++ b/drivers/usb/serial/xr_serial.c
@@ -7,6 +7,7 @@
* Copyright (c) 2020 Manivannan Sadhasivam
*/
+#include
#include
#include
#include
@@ -32,6 +33,11 @@ struct xr_uart_regs {
};
struct xr_port_private {
+#ifdef CONFIG_GPIOLIB
+ struct gpio_chip gc;
+ bool gpio_registered;
+ u8 gpio_altfunc;
+#endif
const struct xr_uart_regs *regs;
u16 idProduct;
u8 reg_width;
@@ -570,6 +576,194 @@ static void xr_break_ctl(struct tty_struct *tty, int
break_state)
state);
}
+#ifdef CONFIG_GPIOLIB
+
+static int xr_gpio_request(struct gpio_chip *gc, unsigned int offset)
+{
+ struct usb_serial_port *port = gpiochip_get_data(gc);
+ struct xr_port_private *port_priv = usb_get_serial_port_data(port);
+
+ /* Check if the requested GPIO is occupied */
+ if (port_priv->gpio_altfunc & BIT(offset))
+ return -ENODEV;
+
+ return 0;
+}
+
+static int xr_gpio_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct usb_serial_port *port = gpiochip_get_data(gc);
+ struct xr_port_private *port_priv = usb_get_serial_port_data(port);
+ int ret;
+ u8 gpio_status;
+
+ ret = xr_get_reg(port, XR21V141X_UART_REG_BLOCK,
+port_priv->regs->gpio_status, _status);
+ if (ret)
+ return ret;
+
+ return !!(gpio_status & BIT(gpio));
+}
+
+static void xr_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ struct usb_serial_port *port = gpiochip_get_data(gc);
+ struct xr_port_private *port_priv = usb_get_serial_port_data(port);
+
+ if (val)
+ xr_set_reg(port, XR21V141X_UART_REG_BLOCK,
+ port_priv->regs->gpio_set, BIT(gpio));
+ else
+ xr_set_reg(port, XR21V141X_UART_REG_BLOCK,
+ port_priv->regs->gpio_clr, BIT(gpio));
+}
+
+static int xr_gpio_direction_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct usb_serial_port *port = gpiochip_get_data(gc);
+ struct xr_port_private *port_priv = usb_get_serial_port_data(port);
+ int ret;
+ u8 gpio_dir;
+
+ ret = xr_get_reg(port, XR21V141X_UART_REG_BLOCK,
+port_priv->regs->gpio_dir, _dir);
+ if (ret)
+ return ret;
+
+ /* Logic 0 = input and Logic 1 = output */
+ return !(gpio_dir & BIT(gpio));
+}
+
+static int xr_gpio_direction_input(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct usb_serial_port *port = gpiochip_get_data(gc);
+ struct xr_port_private *port_priv = usb_get_serial_port_data(port);
+ int ret;
+ u8 gpio_dir;
+
+ ret = xr_get_reg(port, XR21V141X_UART_REG_BLOCK,
+port_priv->regs->gpio_dir, _dir);
+ if (ret)
+ return ret;
+
+ gpio_dir &= ~BIT(gpio);
+
+ return xr_set_reg(port, XR21V141X_UART_REG_BLOCK,
+ port_priv->regs->gpio_dir, gpio_dir);
+}
+
+static int xr_gpio_direction_output(struct gpio_chip *gc, unsigned int gpio,
+ int val)
+{
+ struct usb_serial_port *port = gpiochip_get_data(gc);
+ struct xr_port_private *port_priv = usb_get_serial_port_data(port);
+ int ret;
+ u8 gpio_dir;
+
+ ret = xr_get_reg(port, XR21V141X_UART_REG_BLOCK,
+port_priv->regs->gpio_dir, _dir);
+ if (ret)
+ return ret;
+
+ gpio_dir |= BIT(gpio);
+
+ ret = xr_set_reg(port, XR21V141X_UART_REG_BLOCK,
+port_priv->regs->gpio_dir, gpio_dir);
+ if (ret)
+ return ret;
+
+ xr_gpio_set(gc, gpio, val);
+
+ return 0;
+}
+
+static int xr21v141x_gpio_init(struct usb_serial_port *port)
+{
+ struct xr_port_private *port_priv = usb_get_serial_port_data(port);
+ int ret;
+ u8 gpio_mode;
+
+ port_priv->gc.ngpio = 6;
+
+ ret = xr_get_reg(port, XR21V141X_UART_REG_BLOCK,
+port_priv->regs->gpio_mode, _mode);
+ if (ret)
+ return ret;
+
+ /* Mark all pins which are not in GPIO mode */
+ if (gpio_mode & UART_MODE_RTS_CTS)
+ port_priv->gpio_altfunc |= (BIT(4) | BIT(5));
+ else if (gpio_mode & UART_MODE_DTR_DSR)
+ port_priv->gpio_altfunc |= (BIT(2) | BIT(3));
+ else if (gpio_mode & UART_MODE_RS485)
+
[PATCH v2 1/2] usb: serial: Add MaxLinear/Exar USB to Serial driver
From: Manivannan Sadhasivam
Add support for MaxLinear/Exar USB to Serial converters. This driver
only supports XR21V141X series but provision has been made to support
other series in future.
This driver is inspired from the initial one submitted by Patong Yang:
https://patchwork.kernel.org/patch/10543261/
While the initial driver was a custom tty USB driver exposing whole
new serial interface ttyXRUSBn, this version is completely based on USB
serial core thus exposing the interfaces as ttyUSBn. This will avoid
the overhead of exposing a new USB serial interface which the userspace
tools are unaware of.
Signed-off-by: Manivannan Sadhasivam
---
drivers/usb/serial/Kconfig | 9 +
drivers/usb/serial/Makefile| 1 +
drivers/usb/serial/xr_serial.c | 638 +
3 files changed, 648 insertions(+)
create mode 100644 drivers/usb/serial/xr_serial.c
diff --git a/drivers/usb/serial/Kconfig b/drivers/usb/serial/Kconfig
index 25d7e0c36d38..8f6ad9f94735 100644
--- a/drivers/usb/serial/Kconfig
+++ b/drivers/usb/serial/Kconfig
@@ -644,6 +644,15 @@ config USB_SERIAL_UPD78F0730
To compile this driver as a module, choose M here: the
module will be called upd78f0730.
+config USB_SERIAL_XR
+ tristate "USB MaxLinear/Exar USB to Serial driver"
+ help
+ Say Y here if you want to use MaxLinear/Exar USB to Serial converter
+ devices.
+
+ To compile this driver as a module, choose M here: the
+ module will be called xr_serial.
+
config USB_SERIAL_DEBUG
tristate "USB Debugging Device"
help
diff --git a/drivers/usb/serial/Makefile b/drivers/usb/serial/Makefile
index 2d491e434f11..4f69c2a3aff3 100644
--- a/drivers/usb/serial/Makefile
+++ b/drivers/usb/serial/Makefile
@@ -62,4 +62,5 @@ obj-$(CONFIG_USB_SERIAL_VISOR)+=
visor.o
obj-$(CONFIG_USB_SERIAL_WISHBONE) += wishbone-serial.o
obj-$(CONFIG_USB_SERIAL_WHITEHEAT) += whiteheat.o
obj-$(CONFIG_USB_SERIAL_XIRCOM)+= keyspan_pda.o
+obj-$(CONFIG_USB_SERIAL_XR)+= xr_serial.o
obj-$(CONFIG_USB_SERIAL_XSENS_MT) += xsens_mt.o
diff --git a/drivers/usb/serial/xr_serial.c b/drivers/usb/serial/xr_serial.c
new file mode 100644
index ..d607906e46ad
--- /dev/null
+++ b/drivers/usb/serial/xr_serial.c
@@ -0,0 +1,638 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * MaxLinear/Exar USB to Serial driver
+ *
+ * Based on initial driver written by Patong Yang
+ *
+ * Copyright (c) 2020 Manivannan Sadhasivam
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct xr_uart_regs {
+ u8 enable;
+ u8 format;
+ u8 flow_ctrl;
+ u8 xon_char;
+ u8 xoff_char;
+ u8 loopback;
+ u8 tx_break;
+ u8 rs485_delay;
+ u8 gpio_mode;
+ u8 gpio_dir;
+ u8 gpio_int_mask;
+ u8 gpio_set;
+ u8 gpio_clr;
+ u8 gpio_status;
+};
+
+struct xr_port_private {
+ const struct xr_uart_regs *regs;
+ u16 idProduct;
+ u8 reg_width;
+};
+
+struct xr_txrx_clk_mask {
+ u16 tx;
+ u16 rx0;
+ u16 rx1;
+};
+
+#define XR21V141X_ID 0x1410
+#define XR_INT_OSC_HZ 4800
+
+/* USB Requests */
+#define XR_SET_XR21V141X 0
+#define XR_GET_XR21V141X 1
+
+#define XR21V141X_CLOCK_DIVISOR_0 0x4
+#define XR21V141X_CLOCK_DIVISOR_1 0x5
+#define XR21V141X_CLOCK_DIVISOR_2 0x6
+#define XR21V141X_TX_CLOCK_MASK_0 0x7
+#define XR21V141X_TX_CLOCK_MASK_1 0x8
+#define XR21V141X_RX_CLOCK_MASK_0 0x9
+#define XR21V141X_RX_CLOCK_MASK_1 0xa
+
+/* XR21V141X register blocks */
+#define XR21V141X_UART_REG_BLOCK 0
+#define XR21V141X_URM_REG_BLOCK4
+#define XR21V141X_UART_CUSTOM_BLOCK0x66
+
+/* XR21V141X UART Manager Registers */
+#define XR21V141X_URM_FIFO_ENABLE_REG 0x10
+#define XR21V141X_URM_ENABLE_TX_FIFO 0x1
+#define XR21V141X_URM_ENABLE_RX_FIFO 0x2
+
+#define XR21V141X_URM_RX_FIFO_RESET0x18
+#define XR21V141X_URM_TX_FIFO_RESET0x1c
+
+#define UART_ENABLE_TX 0x1
+#define UART_ENABLE_RX 0x2
+
+#define UART_MODE_RI BIT(0)
+#define UART_MODE_CD BIT(1)
+#define UART_MODE_DSR BIT(2)
+#define UART_MODE_DTR BIT(3)
+#define UART_MODE_CTS BIT(4)
+#define UART_MODE_RTS BIT(5)
+
+#define UART_BREAK_ON 0xff
+#define UART_BREAK_OFF 0
+
+#define UART_DATA_MASK GENMASK(3, 0)
+#define UART_DATA_70x7
+#define UART_DATA_80x8
+
+#define UART_PARITY_MASK GENMASK(6, 4)
+#define UART_PARITY_SHIFT 0x4
+#define UART_PARITY_NONE 0x0
+#define UART_PARITY_ODD0x1
+#define UART_PARITY_EVEN
[PATCH v4 12/16] powerpc/watchpoint: Use builtin ALIGN*() macros
Currently we calculate hw aligned start and end addresses manually.
Replace them with builtin ALIGN_DOWN() and ALIGN() macros.
So far end_addr was inclusive but this patch makes it exclusive (by
avoiding -1) for better readability.
Suggested-by: Christophe Leroy
Signed-off-by: Ravi Bangoria
Reviewed-by: Michael Neuling
---
arch/powerpc/include/asm/hw_breakpoint.h | 5 +++--
arch/powerpc/kernel/hw_breakpoint.c | 12 ++--
arch/powerpc/kernel/process.c | 8
arch/powerpc/kernel/ptrace/ptrace-noadv.c | 2 +-
4 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/include/asm/hw_breakpoint.h
b/arch/powerpc/include/asm/hw_breakpoint.h
index d472b2eb757e..add5aa076919 100644
--- a/arch/powerpc/include/asm/hw_breakpoint.h
+++ b/arch/powerpc/include/asm/hw_breakpoint.h
@@ -34,10 +34,11 @@ struct arch_hw_breakpoint {
#define HW_BRK_TYPE_PRIV_ALL (HW_BRK_TYPE_USER | HW_BRK_TYPE_KERNEL | \
HW_BRK_TYPE_HYP)
+/* Minimum granularity */
#ifdef CONFIG_PPC_8xx
-#define HW_BREAKPOINT_ALIGN 0x3
+#define HW_BREAKPOINT_SIZE 0x4
#else
-#define HW_BREAKPOINT_ALIGN 0x7
+#define HW_BREAKPOINT_SIZE 0x8
#endif
#define DABR_MAX_LEN 8
diff --git a/arch/powerpc/kernel/hw_breakpoint.c
b/arch/powerpc/kernel/hw_breakpoint.c
index 319a761b7412..ab0dd22fed5f 100644
--- a/arch/powerpc/kernel/hw_breakpoint.c
+++ b/arch/powerpc/kernel/hw_breakpoint.c
@@ -145,10 +145,10 @@ int arch_bp_generic_fields(int type, int *gen_bp_type)
*<---8 bytes--->
*
* In this case, we should configure hw as:
- * start_addr = address & ~HW_BREAKPOINT_ALIGN
+ * start_addr = address & ~(HW_BREAKPOINT_SIZE - 1)
* len = 16 bytes
*
- * @start_addr and @end_addr are inclusive.
+ * @start_addr is inclusive but @end_addr is exclusive.
*/
static int hw_breakpoint_validate_len(struct arch_hw_breakpoint *hw)
{
@@ -156,14 +156,14 @@ static int hw_breakpoint_validate_len(struct
arch_hw_breakpoint *hw)
u16 hw_len;
unsigned long start_addr, end_addr;
- start_addr = hw->address & ~HW_BREAKPOINT_ALIGN;
- end_addr = (hw->address + hw->len - 1) | HW_BREAKPOINT_ALIGN;
- hw_len = end_addr - start_addr + 1;
+ start_addr = ALIGN_DOWN(hw->address, HW_BREAKPOINT_SIZE);
+ end_addr = ALIGN(hw->address + hw->len, HW_BREAKPOINT_SIZE);
+ hw_len = end_addr - start_addr;
if (dawr_enabled()) {
max_len = DAWR_MAX_LEN;
/* DAWR region can't cross 512 bytes boundary */
- if ((start_addr >> 9) != (end_addr >> 9))
+ if (ALIGN(start_addr, SZ_512M) != ALIGN(end_addr - 1, SZ_512M))
return -EINVAL;
} else if (IS_ENABLED(CONFIG_PPC_8xx)) {
/* 8xx can setup a range without limitation */
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 41a59a37383b..dcf9c5b4ac59 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -800,12 +800,12 @@ static inline int set_breakpoint_8xx(struct
arch_hw_breakpoint *brk)
unsigned long lctrl1 = LCTRL1_CTE_GT | LCTRL1_CTF_LT | LCTRL1_CRWE_RW |
LCTRL1_CRWF_RW;
unsigned long lctrl2 = LCTRL2_LW0EN | LCTRL2_LW0LADC | LCTRL2_SLW0EN;
- unsigned long start_addr = brk->address & ~HW_BREAKPOINT_ALIGN;
- unsigned long end_addr = (brk->address + brk->len - 1) |
HW_BREAKPOINT_ALIGN;
+ unsigned long start_addr = ALIGN_DOWN(brk->address, HW_BREAKPOINT_SIZE);
+ unsigned long end_addr = ALIGN(brk->address + brk->len,
HW_BREAKPOINT_SIZE);
if (start_addr == 0)
lctrl2 |= LCTRL2_LW0LA_F;
- else if (end_addr == ~0U)
+ else if (end_addr == 0)
lctrl2 |= LCTRL2_LW0LA_E;
else
lctrl2 |= LCTRL2_LW0LA_EandF;
@@ -821,7 +821,7 @@ static inline int set_breakpoint_8xx(struct
arch_hw_breakpoint *brk)
lctrl1 |= LCTRL1_CRWE_WO | LCTRL1_CRWF_WO;
mtspr(SPRN_CMPE, start_addr - 1);
- mtspr(SPRN_CMPF, end_addr + 1);
+ mtspr(SPRN_CMPF, end_addr);
mtspr(SPRN_LCTRL1, lctrl1);
mtspr(SPRN_LCTRL2, lctrl2);
diff --git a/arch/powerpc/kernel/ptrace/ptrace-noadv.c
b/arch/powerpc/kernel/ptrace/ptrace-noadv.c
index 08cb8c1b504c..697c7e4b5877 100644
--- a/arch/powerpc/kernel/ptrace/ptrace-noadv.c
+++ b/arch/powerpc/kernel/ptrace/ptrace-noadv.c
@@ -216,7 +216,7 @@ long ppc_set_hwdebug(struct task_struct *child, struct
ppc_hw_breakpoint *bp_inf
if ((unsigned long)bp_info->addr >= TASK_SIZE)
return -EIO;
- brk.address = bp_info->addr & ~HW_BREAKPOINT_ALIGN;
+ brk.address = ALIGN_DOWN(bp_info->addr, HW_BREAKPOINT_SIZE);
brk.type = HW_BRK_TYPE_TRANSLATE;
brk.len = DABR_MAX_LEN;
if (bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_READ)
--
2.21.1
[PATCH v4 11/16] powerpc/watchpoint: Introduce is_ptrace_bp() function
Introduce is_ptrace_bp() function and move the check inside the
function. We will utilize it more in later set of patches.
Signed-off-by: Ravi Bangoria
Reviewed-by: Michael Neuling
---
arch/powerpc/kernel/hw_breakpoint.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/hw_breakpoint.c
b/arch/powerpc/kernel/hw_breakpoint.c
index 772b2c953220..319a761b7412 100644
--- a/arch/powerpc/kernel/hw_breakpoint.c
+++ b/arch/powerpc/kernel/hw_breakpoint.c
@@ -90,6 +90,11 @@ void arch_uninstall_hw_breakpoint(struct perf_event *bp)
hw_breakpoint_disable();
}
+static bool is_ptrace_bp(struct perf_event *bp)
+{
+ return bp->overflow_handler == ptrace_triggered;
+}
+
/*
* Perform cleanup of arch-specific counters during unregistration
* of the perf-event
@@ -324,7 +329,7 @@ int hw_breakpoint_handler(struct die_args *args)
* one-shot mode. The ptrace-ed process will receive the SIGTRAP signal
* generated in do_dabr().
*/
- if (bp->overflow_handler == ptrace_triggered) {
+ if (is_ptrace_bp(bp)) {
perf_bp_event(bp, regs);
rc = NOTIFY_DONE;
goto out;
--
2.21.1
[PATCH v4 13/16] powerpc/watchpoint: Prepare handler to handle more than one watcnhpoint
Currently we assume that we have only one watchpoint supported by hw.
Get rid of that assumption and use dynamic loop instead. This should
make supporting more watchpoints very easy.
With more than one watchpoint, exception handler need to know which
DAWR caused the exception, and hw currently does not provide it. So
we need sw logic for the same. To figure out which DAWR caused the
exception, check all different combinations of user specified range,
dawr address range, actual access range and dawrx constrains. For ex,
if user specified range and actual access range overlaps but dawrx is
configured for readonly watchpoint and the instruction is store, this
DAWR must not have caused exception.
Signed-off-by: Ravi Bangoria
Reviewed-by: Michael Neuling
---
arch/powerpc/include/asm/processor.h | 2 +-
arch/powerpc/include/asm/sstep.h | 2 +
arch/powerpc/kernel/hw_breakpoint.c | 400 +--
arch/powerpc/kernel/process.c| 3 -
4 files changed, 315 insertions(+), 92 deletions(-)
diff --git a/arch/powerpc/include/asm/processor.h
b/arch/powerpc/include/asm/processor.h
index 668c02c67b61..251f50eec9fa 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -185,7 +185,7 @@ struct thread_struct {
* Helps identify source of single-step exception and subsequent
* hw-breakpoint enablement
*/
- struct perf_event *last_hit_ubp;
+ struct perf_event *last_hit_ubp[HBP_NUM_MAX];
#endif /* CONFIG_HAVE_HW_BREAKPOINT */
struct arch_hw_breakpoint hw_brk[HBP_NUM_MAX]; /* hardware breakpoint
info */
unsigned long trap_nr;/* last trap # on this thread */
diff --git a/arch/powerpc/include/asm/sstep.h b/arch/powerpc/include/asm/sstep.h
index 769f055509c9..38919b27a6fa 100644
--- a/arch/powerpc/include/asm/sstep.h
+++ b/arch/powerpc/include/asm/sstep.h
@@ -48,6 +48,8 @@ enum instruction_type {
#define INSTR_TYPE_MASK0x1f
+#define OP_IS_LOAD(type) ((LOAD <= (type) && (type) <= LOAD_VSX) ||
(type) == LARX)
+#define OP_IS_STORE(type) ((STORE <= (type) && (type) <= STORE_VSX) ||
(type) == STCX)
#define OP_IS_LOAD_STORE(type) (LOAD <= (type) && (type) <= STCX)
/* Compute flags, ORed in with type */
diff --git a/arch/powerpc/kernel/hw_breakpoint.c
b/arch/powerpc/kernel/hw_breakpoint.c
index ab0dd22fed5f..28d57d841642 100644
--- a/arch/powerpc/kernel/hw_breakpoint.c
+++ b/arch/powerpc/kernel/hw_breakpoint.c
@@ -30,7 +30,7 @@
* Stores the breakpoints currently in use on each breakpoint address
* register for every cpu
*/
-static DEFINE_PER_CPU(struct perf_event *, bp_per_reg);
+static DEFINE_PER_CPU(struct perf_event *, bp_per_reg[HBP_NUM_MAX]);
/*
* Returns total number of data or instruction breakpoints available.
@@ -42,6 +42,17 @@ int hw_breakpoint_slots(int type)
return 0; /* no instruction breakpoints available */
}
+static bool single_step_pending(void)
+{
+ int i;
+
+ for (i = 0; i < nr_wp_slots(); i++) {
+ if (current->thread.last_hit_ubp[i])
+ return true;
+ }
+ return false;
+}
+
/*
* Install a perf counter breakpoint.
*
@@ -54,16 +65,26 @@ int hw_breakpoint_slots(int type)
int arch_install_hw_breakpoint(struct perf_event *bp)
{
struct arch_hw_breakpoint *info = counter_arch_bp(bp);
- struct perf_event **slot = this_cpu_ptr(_per_reg);
+ struct perf_event **slot;
+ int i;
+
+ for (i = 0; i < nr_wp_slots(); i++) {
+ slot = this_cpu_ptr(_per_reg[i]);
+ if (!*slot) {
+ *slot = bp;
+ break;
+ }
+ }
- *slot = bp;
+ if (WARN_ONCE(i == nr_wp_slots(), "Can't find any breakpoint slot"))
+ return -EBUSY;
/*
* Do not install DABR values if the instruction must be single-stepped.
* If so, DABR will be populated in single_step_dabr_instruction().
*/
- if (current->thread.last_hit_ubp != bp)
- __set_breakpoint(0, info);
+ if (!single_step_pending())
+ __set_breakpoint(i, info);
return 0;
}
@@ -79,15 +100,22 @@ int arch_install_hw_breakpoint(struct perf_event *bp)
*/
void arch_uninstall_hw_breakpoint(struct perf_event *bp)
{
- struct perf_event **slot = this_cpu_ptr(_per_reg);
+ struct arch_hw_breakpoint null_brk = {0};
+ struct perf_event **slot;
+ int i;
- if (*slot != bp) {
- WARN_ONCE(1, "Can't find the breakpoint");
- return;
+ for (i = 0; i < nr_wp_slots(); i++) {
+ slot = this_cpu_ptr(_per_reg[i]);
+ if (*slot == bp) {
+ *slot = NULL;
+ break;
+ }
}
- *slot = NULL;
- hw_breakpoint_disable();
+ if (WARN_ONCE(i == nr_wp_slots(), "Can't find any
[PATCH v4 08/16] powerpc/watchpoint: Disable all available watchpoints when !dawr_force_enable
Instead of disabling only first watchpoint, disable all available
watchpoints while clearing dawr_force_enable.
Callback function is used only for disabling watchpoint, rename it
to disable_dawrs_cb(). And null_brk parameter is not really required
while disabling watchpoint, remove it.
Signed-off-by: Ravi Bangoria
Reviewed-by: Michael Neuling
---
arch/powerpc/kernel/dawr.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/dawr.c b/arch/powerpc/kernel/dawr.c
index 8114ad3a8574..500f52fa4711 100644
--- a/arch/powerpc/kernel/dawr.c
+++ b/arch/powerpc/kernel/dawr.c
@@ -50,9 +50,13 @@ int set_dawr(int nr, struct arch_hw_breakpoint *brk)
return 0;
}
-static void set_dawr_cb(void *info)
+static void disable_dawrs_cb(void *info)
{
- set_dawr(0, info);
+ struct arch_hw_breakpoint null_brk = {0};
+ int i;
+
+ for (i = 0; i < nr_wp_slots(); i++)
+ set_dawr(i, _brk);
}
static ssize_t dawr_write_file_bool(struct file *file,
@@ -74,7 +78,7 @@ static ssize_t dawr_write_file_bool(struct file *file,
/* If we are clearing, make sure all CPUs have the DAWR cleared */
if (!dawr_force_enable)
- smp_call_function(set_dawr_cb, _brk, 0);
+ smp_call_function(disable_dawrs_cb, NULL, 0);
return rc;
}
--
2.21.1
[PATCH v4 07/16] powerpc/watchpoint: Get watchpoint count dynamically while disabling them
Instead of disabling only one watchpoint, get num of available
watchpoints dynamically and disable all of them.
Signed-off-by: Ravi Bangoria
Reviewed-by: Michael Neuling
---
arch/powerpc/include/asm/hw_breakpoint.h | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/include/asm/hw_breakpoint.h
b/arch/powerpc/include/asm/hw_breakpoint.h
index 1120c7d9db58..d472b2eb757e 100644
--- a/arch/powerpc/include/asm/hw_breakpoint.h
+++ b/arch/powerpc/include/asm/hw_breakpoint.h
@@ -78,14 +78,14 @@ extern void ptrace_triggered(struct perf_event *bp,
struct perf_sample_data *data, struct pt_regs *regs);
static inline void hw_breakpoint_disable(void)
{
- struct arch_hw_breakpoint brk;
-
- brk.address = 0;
- brk.type = 0;
- brk.len = 0;
- brk.hw_len = 0;
- if (ppc_breakpoint_available())
- __set_breakpoint(0, );
+ int i;
+ struct arch_hw_breakpoint null_brk = {0};
+
+ if (!ppc_breakpoint_available())
+ return;
+
+ for (i = 0; i < nr_wp_slots(); i++)
+ __set_breakpoint(i, _brk);
}
extern void thread_change_pc(struct task_struct *tsk, struct pt_regs *regs);
int hw_breakpoint_handler(struct die_args *args);
--
2.21.1
[PATCH v4 05/16] powerpc/watchpoint: Provide DAWR number to set_dawr
Introduce new parameter 'nr' to set_dawr() which indicates which DAWR
should be programed.
Signed-off-by: Ravi Bangoria
Reviewed-by: Michael Neuling
---
arch/powerpc/include/asm/hw_breakpoint.h | 4 ++--
arch/powerpc/kernel/dawr.c | 15 ++-
arch/powerpc/kernel/process.c| 2 +-
3 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/include/asm/hw_breakpoint.h
b/arch/powerpc/include/asm/hw_breakpoint.h
index 518b41eef924..5b3b02834e0b 100644
--- a/arch/powerpc/include/asm/hw_breakpoint.h
+++ b/arch/powerpc/include/asm/hw_breakpoint.h
@@ -104,10 +104,10 @@ static inline bool dawr_enabled(void)
{
return dawr_force_enable;
}
-int set_dawr(struct arch_hw_breakpoint *brk);
+int set_dawr(int nr, struct arch_hw_breakpoint *brk);
#else
static inline bool dawr_enabled(void) { return false; }
-static inline int set_dawr(struct arch_hw_breakpoint *brk) { return -1; }
+static inline int set_dawr(int nr, struct arch_hw_breakpoint *brk) { return
-1; }
#endif
#endif /* __KERNEL__ */
diff --git a/arch/powerpc/kernel/dawr.c b/arch/powerpc/kernel/dawr.c
index e91b613bf137..8114ad3a8574 100644
--- a/arch/powerpc/kernel/dawr.c
+++ b/arch/powerpc/kernel/dawr.c
@@ -16,7 +16,7 @@
bool dawr_force_enable;
EXPORT_SYMBOL_GPL(dawr_force_enable);
-int set_dawr(struct arch_hw_breakpoint *brk)
+int set_dawr(int nr, struct arch_hw_breakpoint *brk)
{
unsigned long dawr, dawrx, mrd;
@@ -39,15 +39,20 @@ int set_dawr(struct arch_hw_breakpoint *brk)
if (ppc_md.set_dawr)
return ppc_md.set_dawr(dawr, dawrx);
- mtspr(SPRN_DAWR0, dawr);
- mtspr(SPRN_DAWRX0, dawrx);
+ if (nr == 0) {
+ mtspr(SPRN_DAWR0, dawr);
+ mtspr(SPRN_DAWRX0, dawrx);
+ } else {
+ mtspr(SPRN_DAWR1, dawr);
+ mtspr(SPRN_DAWRX1, dawrx);
+ }
return 0;
}
static void set_dawr_cb(void *info)
{
- set_dawr(info);
+ set_dawr(0, info);
}
static ssize_t dawr_write_file_bool(struct file *file,
@@ -60,7 +65,7 @@ static ssize_t dawr_write_file_bool(struct file *file,
/* Send error to user if they hypervisor won't allow us to write DAWR */
if (!dawr_force_enable &&
firmware_has_feature(FW_FEATURE_LPAR) &&
- set_dawr(_brk) != H_SUCCESS)
+ set_dawr(0, _brk) != H_SUCCESS)
return -ENODEV;
rc = debugfs_write_file_bool(file, user_buf, count, ppos);
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 8479c762aef2..7488adf4d61c 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -806,7 +806,7 @@ void __set_breakpoint(struct arch_hw_breakpoint *brk)
if (dawr_enabled())
// Power8 or later
- set_dawr(brk);
+ set_dawr(0, brk);
else if (IS_ENABLED(CONFIG_PPC_8xx))
set_breakpoint_8xx(brk);
else if (!cpu_has_feature(CPU_FTR_ARCH_207S))
--
2.21.1
[PATCH v4 14/16] powerpc/watchpoint: Don't allow concurrent perf and ptrace events
With Book3s DAWR, ptrace and perf watchpoints on powerpc behaves
differently. Ptrace watchpoint works in one-shot mode and generates
signal before executing instruction. It's ptrace user's job to
single-step the instruction and re-enable the watchpoint. OTOH, in
case of perf watchpoint, kernel emulates/single-steps the instruction
and then generates event. If perf and ptrace creates two events with
same or overlapping address ranges, it's ambiguous to decide who
should single-step the instruction. Because of this issue, don't
allow perf and ptrace watchpoint at the same time if their address
range overlaps.
Signed-off-by: Ravi Bangoria
Reviewed-by: Michael Neuling
---
arch/powerpc/include/asm/hw_breakpoint.h | 2 +
arch/powerpc/kernel/hw_breakpoint.c | 221 +++
kernel/events/hw_breakpoint.c| 16 ++
3 files changed, 239 insertions(+)
diff --git a/arch/powerpc/include/asm/hw_breakpoint.h
b/arch/powerpc/include/asm/hw_breakpoint.h
index add5aa076919..f42a55eb77d2 100644
--- a/arch/powerpc/include/asm/hw_breakpoint.h
+++ b/arch/powerpc/include/asm/hw_breakpoint.h
@@ -70,6 +70,8 @@ extern int hw_breakpoint_exceptions_notify(struct
notifier_block *unused,
unsigned long val, void *data);
int arch_install_hw_breakpoint(struct perf_event *bp);
void arch_uninstall_hw_breakpoint(struct perf_event *bp);
+int arch_reserve_bp_slot(struct perf_event *bp);
+void arch_release_bp_slot(struct perf_event *bp);
void arch_unregister_hw_breakpoint(struct perf_event *bp);
void hw_breakpoint_pmu_read(struct perf_event *bp);
extern void flush_ptrace_hw_breakpoint(struct task_struct *tsk);
diff --git a/arch/powerpc/kernel/hw_breakpoint.c
b/arch/powerpc/kernel/hw_breakpoint.c
index 28d57d841642..c8623708c9c7 100644
--- a/arch/powerpc/kernel/hw_breakpoint.c
+++ b/arch/powerpc/kernel/hw_breakpoint.c
@@ -123,6 +123,227 @@ static bool is_ptrace_bp(struct perf_event *bp)
return bp->overflow_handler == ptrace_triggered;
}
+struct breakpoint {
+ struct list_head list;
+ struct perf_event *bp;
+ bool ptrace_bp;
+};
+
+static DEFINE_PER_CPU(struct breakpoint *, cpu_bps[HBP_NUM_MAX]);
+static LIST_HEAD(task_bps);
+
+static struct breakpoint *alloc_breakpoint(struct perf_event *bp)
+{
+ struct breakpoint *tmp;
+
+ tmp = kzalloc(sizeof(*tmp), GFP_KERNEL);
+ if (!tmp)
+ return ERR_PTR(-ENOMEM);
+ tmp->bp = bp;
+ tmp->ptrace_bp = is_ptrace_bp(bp);
+ return tmp;
+}
+
+static bool bp_addr_range_overlap(struct perf_event *bp1, struct perf_event
*bp2)
+{
+ __u64 bp1_saddr, bp1_eaddr, bp2_saddr, bp2_eaddr;
+
+ bp1_saddr = ALIGN_DOWN(bp1->attr.bp_addr, HW_BREAKPOINT_SIZE);
+ bp1_eaddr = ALIGN(bp1->attr.bp_addr + bp1->attr.bp_len,
HW_BREAKPOINT_SIZE);
+ bp2_saddr = ALIGN_DOWN(bp2->attr.bp_addr, HW_BREAKPOINT_SIZE);
+ bp2_eaddr = ALIGN(bp2->attr.bp_addr + bp2->attr.bp_len,
HW_BREAKPOINT_SIZE);
+
+ return (bp1_saddr < bp2_eaddr && bp1_eaddr > bp2_saddr);
+}
+
+static bool alternate_infra_bp(struct breakpoint *b, struct perf_event *bp)
+{
+ return is_ptrace_bp(bp) ? !b->ptrace_bp : b->ptrace_bp;
+}
+
+static bool can_co_exist(struct breakpoint *b, struct perf_event *bp)
+{
+ return !(alternate_infra_bp(b, bp) && bp_addr_range_overlap(b->bp, bp));
+}
+
+static int task_bps_add(struct perf_event *bp)
+{
+ struct breakpoint *tmp;
+
+ tmp = alloc_breakpoint(bp);
+ if (IS_ERR(tmp))
+ return PTR_ERR(tmp);
+
+ list_add(>list, _bps);
+ return 0;
+}
+
+static void task_bps_remove(struct perf_event *bp)
+{
+ struct list_head *pos, *q;
+
+ list_for_each_safe(pos, q, _bps) {
+ struct breakpoint *tmp = list_entry(pos, struct breakpoint,
list);
+
+ if (tmp->bp == bp) {
+ list_del(>list);
+ kfree(tmp);
+ break;
+ }
+ }
+}
+
+/*
+ * If any task has breakpoint from alternate infrastructure,
+ * return true. Otherwise return false.
+ */
+static bool all_task_bps_check(struct perf_event *bp)
+{
+ struct breakpoint *tmp;
+
+ list_for_each_entry(tmp, _bps, list) {
+ if (!can_co_exist(tmp, bp))
+ return true;
+ }
+ return false;
+}
+
+/*
+ * If same task has breakpoint from alternate infrastructure,
+ * return true. Otherwise return false.
+ */
+static bool same_task_bps_check(struct perf_event *bp)
+{
+ struct breakpoint *tmp;
+
+ list_for_each_entry(tmp, _bps, list) {
+ if (tmp->bp->hw.target == bp->hw.target &&
+ !can_co_exist(tmp, bp))
+ return true;
+ }
+ return false;
+}
+
+static int cpu_bps_add(struct perf_event *bp)
+{
+ struct breakpoint **cpu_bp;
+ struct breakpoint *tmp;
+ int i = 0;
+
+ tmp =
[PATCH v4 15/16] powerpc/watchpoint/xmon: Don't allow breakpoint overwriting
Xmon allows overwriting breakpoints because it's supported by only
one dawr. But with multiple dawrs, overwriting becomes ambiguous
or unnecessary complicated. So let's not allow it.
Signed-off-by: Ravi Bangoria
Reviewed-by: Michael Neuling
---
arch/powerpc/xmon/xmon.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index d8c0f01e4b24..99e9138661e4 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -1382,6 +1382,10 @@ bpt_cmds(void)
printf("Hardware data breakpoint not supported on this
cpu\n");
break;
}
+ if (dabr.enabled) {
+ printf("Couldn't find free breakpoint register\n");
+ break;
+ }
mode = 7;
cmd = inchar();
if (cmd == 'r')
--
2.21.1
[PATCH v4 16/16] powerpc/watchpoint/xmon: Support 2nd dawr
Add support for 2nd DAWR in xmon. With this, we can have two
simultaneous breakpoints from xmon.
Signed-off-by: Ravi Bangoria
Reviewed-by: Michael Neuling
---
arch/powerpc/xmon/xmon.c | 101 ++-
1 file changed, 69 insertions(+), 32 deletions(-)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 99e9138661e4..01da49b666db 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -111,7 +111,7 @@ struct bpt {
#define NBPTS 256
static struct bpt bpts[NBPTS];
-static struct bpt dabr;
+static struct bpt dabr[HBP_NUM_MAX];
static struct bpt *iabr;
static unsigned bpinstr = 0x7fe8; /* trap */
@@ -787,10 +787,17 @@ static int xmon_sstep(struct pt_regs *regs)
static int xmon_break_match(struct pt_regs *regs)
{
+ int i;
+
if ((regs->msr & (MSR_IR|MSR_PR|MSR_64BIT)) != (MSR_IR|MSR_64BIT))
return 0;
- if (dabr.enabled == 0)
- return 0;
+ for (i = 0; i < nr_wp_slots(); i++) {
+ if (dabr[i].enabled)
+ goto found;
+ }
+ return 0;
+
+found:
xmon_core(regs, 0);
return 1;
}
@@ -929,13 +936,16 @@ static void insert_bpts(void)
static void insert_cpu_bpts(void)
{
+ int i;
struct arch_hw_breakpoint brk;
- if (dabr.enabled) {
- brk.address = dabr.address;
- brk.type = (dabr.enabled & HW_BRK_TYPE_DABR) |
HW_BRK_TYPE_PRIV_ALL;
- brk.len = DABR_MAX_LEN;
- __set_breakpoint(0, );
+ for (i = 0; i < nr_wp_slots(); i++) {
+ if (dabr[i].enabled) {
+ brk.address = dabr[i].address;
+ brk.type = (dabr[i].enabled & HW_BRK_TYPE_DABR) |
HW_BRK_TYPE_PRIV_ALL;
+ brk.len = 8;
+ __set_breakpoint(i, );
+ }
}
if (iabr)
@@ -1349,6 +1359,35 @@ static long check_bp_loc(unsigned long addr)
return 1;
}
+static int find_free_data_bpt(void)
+{
+ int i;
+
+ for (i = 0; i < nr_wp_slots(); i++) {
+ if (!dabr[i].enabled)
+ return i;
+ }
+ printf("Couldn't find free breakpoint register\n");
+ return -1;
+}
+
+static void print_data_bpts(void)
+{
+ int i;
+
+ for (i = 0; i < nr_wp_slots(); i++) {
+ if (!dabr[i].enabled)
+ continue;
+
+ printf(" data "REG" [", dabr[i].address);
+ if (dabr[i].enabled & 1)
+ printf("r");
+ if (dabr[i].enabled & 2)
+ printf("w");
+ printf("]\n");
+ }
+}
+
static char *breakpoint_help_string =
"Breakpoint command usage:\n"
"bshow breakpoints\n"
@@ -1382,10 +1421,9 @@ bpt_cmds(void)
printf("Hardware data breakpoint not supported on this
cpu\n");
break;
}
- if (dabr.enabled) {
- printf("Couldn't find free breakpoint register\n");
+ i = find_free_data_bpt();
+ if (i < 0)
break;
- }
mode = 7;
cmd = inchar();
if (cmd == 'r')
@@ -1394,15 +1432,15 @@ bpt_cmds(void)
mode = 6;
else
termch = cmd;
- dabr.address = 0;
- dabr.enabled = 0;
- if (scanhex()) {
- if (!is_kernel_addr(dabr.address)) {
+ dabr[i].address = 0;
+ dabr[i].enabled = 0;
+ if (scanhex([i].address)) {
+ if (!is_kernel_addr(dabr[i].address)) {
printf(badaddr);
break;
}
- dabr.address &= ~HW_BRK_TYPE_DABR;
- dabr.enabled = mode | BP_DABR;
+ dabr[i].address &= ~HW_BRK_TYPE_DABR;
+ dabr[i].enabled = mode | BP_DABR;
}
force_enable_xmon();
@@ -1441,7 +1479,9 @@ bpt_cmds(void)
for (i = 0; i < NBPTS; ++i)
bpts[i].enabled = 0;
iabr = NULL;
- dabr.enabled = 0;
+ for (i = 0; i < nr_wp_slots(); i++)
+ dabr[i].enabled = 0;
+
printf("All breakpoints cleared\n");
break;
}
@@ -1475,14 +1515,7 @@ bpt_cmds(void)
if (xmon_is_ro || !scanhex()) {
/* print all breakpoints */
printf(" typeaddress\n");
- if (dabr.enabled) {
- printf(" data "REG" [",
[PATCH v4 09/16] powerpc/watchpoint: Convert thread_struct->hw_brk to an array
So far powerpc hw supported only one watchpoint. But Future Power
architecture is introducing 2nd DAWR. Convert thread_struct->hw_brk
into an array.
Signed-off-by: Ravi Bangoria
Reviewed-by: Michael Neuling
---
arch/powerpc/include/asm/processor.h | 2 +-
arch/powerpc/kernel/process.c | 60 ++-
arch/powerpc/kernel/ptrace/ptrace-noadv.c | 40 ++-
arch/powerpc/kernel/ptrace/ptrace32.c | 4 +-
arch/powerpc/kernel/signal.c | 13 +++--
5 files changed, 78 insertions(+), 41 deletions(-)
diff --git a/arch/powerpc/include/asm/processor.h
b/arch/powerpc/include/asm/processor.h
index a71bdd6bc284..668c02c67b61 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -187,7 +187,7 @@ struct thread_struct {
*/
struct perf_event *last_hit_ubp;
#endif /* CONFIG_HAVE_HW_BREAKPOINT */
- struct arch_hw_breakpoint hw_brk; /* info on the hardware breakpoint */
+ struct arch_hw_breakpoint hw_brk[HBP_NUM_MAX]; /* hardware breakpoint
info */
unsigned long trap_nr;/* last trap # on this thread */
u8 load_slb;/* Ages out SLB preload cache entries */
u8 load_fp;
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 351fbd8d2c5b..6d1b7cede900 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -711,21 +711,49 @@ void switch_booke_debug_regs(struct debug_reg *new_debug)
EXPORT_SYMBOL_GPL(switch_booke_debug_regs);
#else /* !CONFIG_PPC_ADV_DEBUG_REGS */
#ifndef CONFIG_HAVE_HW_BREAKPOINT
-static void set_breakpoint(struct arch_hw_breakpoint *brk)
+static void set_breakpoint(int i, struct arch_hw_breakpoint *brk)
{
preempt_disable();
- __set_breakpoint(0, brk);
+ __set_breakpoint(i, brk);
preempt_enable();
}
static void set_debug_reg_defaults(struct thread_struct *thread)
{
- thread->hw_brk.address = 0;
- thread->hw_brk.type = 0;
- thread->hw_brk.len = 0;
- thread->hw_brk.hw_len = 0;
- if (ppc_breakpoint_available())
- set_breakpoint(>hw_brk);
+ int i;
+ struct arch_hw_breakpoint null_brk = {0};
+
+ for (i = 0; i < nr_wp_slots(); i++) {
+ thread->hw_brk[i] = null_brk;
+ if (ppc_breakpoint_available())
+ set_breakpoint(i, >hw_brk[i]);
+ }
+}
+
+static inline bool hw_brk_match(struct arch_hw_breakpoint *a,
+ struct arch_hw_breakpoint *b)
+{
+ if (a->address != b->address)
+ return false;
+ if (a->type != b->type)
+ return false;
+ if (a->len != b->len)
+ return false;
+ /* no need to check hw_len. it's calculated from address and len */
+ return true;
+}
+
+static void switch_hw_breakpoint(struct task_struct *new)
+{
+ int i;
+
+ for (i = 0; i < nr_wp_slots(); i++) {
+ if (likely(hw_brk_match(this_cpu_ptr(_brk[i]),
+ >thread.hw_brk[i])))
+ continue;
+
+ __set_breakpoint(i, >thread.hw_brk[i]);
+ }
}
#endif /* !CONFIG_HAVE_HW_BREAKPOINT */
#endif /* CONFIG_PPC_ADV_DEBUG_REGS */
@@ -829,19 +857,6 @@ bool ppc_breakpoint_available(void)
}
EXPORT_SYMBOL_GPL(ppc_breakpoint_available);
-static inline bool hw_brk_match(struct arch_hw_breakpoint *a,
- struct arch_hw_breakpoint *b)
-{
- if (a->address != b->address)
- return false;
- if (a->type != b->type)
- return false;
- if (a->len != b->len)
- return false;
- /* no need to check hw_len. it's calculated from address and len */
- return true;
-}
-
#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
static inline bool tm_enabled(struct task_struct *tsk)
@@ -1174,8 +1189,7 @@ struct task_struct *__switch_to(struct task_struct *prev,
* schedule DABR
*/
#ifndef CONFIG_HAVE_HW_BREAKPOINT
- if (unlikely(!hw_brk_match(this_cpu_ptr(_brk[0]),
>thread.hw_brk)))
- __set_breakpoint(0, >thread.hw_brk);
+ switch_hw_breakpoint(new);
#endif /* CONFIG_HAVE_HW_BREAKPOINT */
#endif
diff --git a/arch/powerpc/kernel/ptrace/ptrace-noadv.c
b/arch/powerpc/kernel/ptrace/ptrace-noadv.c
index 12962302d6a4..0dbb35392dd2 100644
--- a/arch/powerpc/kernel/ptrace/ptrace-noadv.c
+++ b/arch/powerpc/kernel/ptrace/ptrace-noadv.c
@@ -67,11 +67,16 @@ int ptrace_get_debugreg(struct task_struct *child, unsigned
long addr,
/* We only support one DABR and no IABRS at the moment */
if (addr > 0)
return -EINVAL;
- dabr_fake = ((child->thread.hw_brk.address & (~HW_BRK_TYPE_DABR)) |
-(child->thread.hw_brk.type & HW_BRK_TYPE_DABR));
+ dabr_fake = ((child->thread.hw_brk[0].address & (~HW_BRK_TYPE_DABR)) |
+
[PATCH v4 10/16] powerpc/watchpoint: Use loop for thread_struct->ptrace_bps
ptrace_bps is already an array of size HBP_NUM_MAX. But we use
hardcoded index 0 while fetching/updating it. Convert such code
to loop over array.
ptrace interface to use multiple watchpoint remains same. eg:
two PPC_PTRACE_SETHWDEBUG calls will create two watchpoint if
hw underneath supports it.
Signed-off-by: Ravi Bangoria
Reviewed-by: Michael Neuling
---
arch/powerpc/kernel/hw_breakpoint.c | 7 --
arch/powerpc/kernel/process.c | 6 -
arch/powerpc/kernel/ptrace/ptrace-noadv.c | 28 +--
3 files changed, 31 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/kernel/hw_breakpoint.c
b/arch/powerpc/kernel/hw_breakpoint.c
index 5826f1f2cab9..772b2c953220 100644
--- a/arch/powerpc/kernel/hw_breakpoint.c
+++ b/arch/powerpc/kernel/hw_breakpoint.c
@@ -419,10 +419,13 @@ NOKPROBE_SYMBOL(hw_breakpoint_exceptions_notify);
*/
void flush_ptrace_hw_breakpoint(struct task_struct *tsk)
{
+ int i;
struct thread_struct *t = >thread;
- unregister_hw_breakpoint(t->ptrace_bps[0]);
- t->ptrace_bps[0] = NULL;
+ for (i = 0; i < nr_wp_slots(); i++) {
+ unregister_hw_breakpoint(t->ptrace_bps[i]);
+ t->ptrace_bps[i] = NULL;
+ }
}
void hw_breakpoint_pmu_read(struct perf_event *bp)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 6d1b7cede900..41a59a37383b 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1604,6 +1604,9 @@ int copy_thread_tls(unsigned long clone_flags, unsigned
long usp,
void (*f)(void);
unsigned long sp = (unsigned long)task_stack_page(p) + THREAD_SIZE;
struct thread_info *ti = task_thread_info(p);
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ int i;
+#endif
klp_init_thread_info(p);
@@ -1663,7 +1666,8 @@ int copy_thread_tls(unsigned long clone_flags, unsigned
long usp,
p->thread.ksp_limit = (unsigned long)end_of_stack(p);
#endif
#ifdef CONFIG_HAVE_HW_BREAKPOINT
- p->thread.ptrace_bps[0] = NULL;
+ for (i = 0; i < nr_wp_slots(); i++)
+ p->thread.ptrace_bps[i] = NULL;
#endif
p->thread.fp_save_area = NULL;
diff --git a/arch/powerpc/kernel/ptrace/ptrace-noadv.c
b/arch/powerpc/kernel/ptrace/ptrace-noadv.c
index 0dbb35392dd2..08cb8c1b504c 100644
--- a/arch/powerpc/kernel/ptrace/ptrace-noadv.c
+++ b/arch/powerpc/kernel/ptrace/ptrace-noadv.c
@@ -168,6 +168,19 @@ int ptrace_set_debugreg(struct task_struct *task, unsigned
long addr, unsigned l
return 0;
}
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+static int find_empty_ptrace_bp(struct thread_struct *thread)
+{
+ int i;
+
+ for (i = 0; i < nr_wp_slots(); i++) {
+ if (!thread->ptrace_bps[i])
+ return i;
+ }
+ return -1;
+}
+#endif
+
static int find_empty_hw_brk(struct thread_struct *thread)
{
int i;
@@ -217,8 +230,9 @@ long ppc_set_hwdebug(struct task_struct *child, struct
ppc_hw_breakpoint *bp_inf
len = 1;
else
return -EINVAL;
- bp = thread->ptrace_bps[0];
- if (bp)
+
+ i = find_empty_ptrace_bp(thread);
+ if (i < 0)
return -ENOSPC;
/* Create a new breakpoint request if one doesn't exist already */
@@ -228,13 +242,13 @@ long ppc_set_hwdebug(struct task_struct *child, struct
ppc_hw_breakpoint *bp_inf
arch_bp_generic_fields(brk.type, _type);
bp = register_user_hw_breakpoint(, ptrace_triggered, NULL, child);
- thread->ptrace_bps[0] = bp;
+ thread->ptrace_bps[i] = bp;
if (IS_ERR(bp)) {
- thread->ptrace_bps[0] = NULL;
+ thread->ptrace_bps[i] = NULL;
return PTR_ERR(bp);
}
- return 1;
+ return i + 1;
#endif /* CONFIG_HAVE_HW_BREAKPOINT */
if (bp_info->addr_mode != PPC_BREAKPOINT_MODE_EXACT)
@@ -263,10 +277,10 @@ long ppc_del_hwdebug(struct task_struct *child, long data)
return -EINVAL;
#ifdef CONFIG_HAVE_HW_BREAKPOINT
- bp = thread->ptrace_bps[0];
+ bp = thread->ptrace_bps[data - 1];
if (bp) {
unregister_hw_breakpoint(bp);
- thread->ptrace_bps[0] = NULL;
+ thread->ptrace_bps[data - 1] = NULL;
} else {
ret = -ENOENT;
}
--
2.21.1
[PATCH v4 06/16] powerpc/watchpoint: Provide DAWR number to __set_breakpoint
Introduce new parameter 'nr' to __set_breakpoint() which indicates
which DAWR should be programed. Also convert current_brk variable
to an array.
Signed-off-by: Ravi Bangoria
Reviewed-by: Michael Neuling
---
arch/powerpc/include/asm/debug.h | 2 +-
arch/powerpc/include/asm/hw_breakpoint.h | 2 +-
arch/powerpc/kernel/hw_breakpoint.c | 8
arch/powerpc/kernel/process.c| 14 +++---
arch/powerpc/kernel/signal.c | 2 +-
arch/powerpc/xmon/xmon.c | 2 +-
6 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/include/asm/debug.h b/arch/powerpc/include/asm/debug.h
index 7756026b95ca..ec57daf87f40 100644
--- a/arch/powerpc/include/asm/debug.h
+++ b/arch/powerpc/include/asm/debug.h
@@ -45,7 +45,7 @@ static inline int debugger_break_match(struct pt_regs *regs)
{ return 0; }
static inline int debugger_fault_handler(struct pt_regs *regs) { return 0; }
#endif
-void __set_breakpoint(struct arch_hw_breakpoint *brk);
+void __set_breakpoint(int nr, struct arch_hw_breakpoint *brk);
bool ppc_breakpoint_available(void);
#ifdef CONFIG_PPC_ADV_DEBUG_REGS
extern void do_send_trap(struct pt_regs *regs, unsigned long address,
diff --git a/arch/powerpc/include/asm/hw_breakpoint.h
b/arch/powerpc/include/asm/hw_breakpoint.h
index 5b3b02834e0b..1120c7d9db58 100644
--- a/arch/powerpc/include/asm/hw_breakpoint.h
+++ b/arch/powerpc/include/asm/hw_breakpoint.h
@@ -85,7 +85,7 @@ static inline void hw_breakpoint_disable(void)
brk.len = 0;
brk.hw_len = 0;
if (ppc_breakpoint_available())
- __set_breakpoint();
+ __set_breakpoint(0, );
}
extern void thread_change_pc(struct task_struct *tsk, struct pt_regs *regs);
int hw_breakpoint_handler(struct die_args *args);
diff --git a/arch/powerpc/kernel/hw_breakpoint.c
b/arch/powerpc/kernel/hw_breakpoint.c
index 4120349e2abe..5826f1f2cab9 100644
--- a/arch/powerpc/kernel/hw_breakpoint.c
+++ b/arch/powerpc/kernel/hw_breakpoint.c
@@ -63,7 +63,7 @@ int arch_install_hw_breakpoint(struct perf_event *bp)
* If so, DABR will be populated in single_step_dabr_instruction().
*/
if (current->thread.last_hit_ubp != bp)
- __set_breakpoint(info);
+ __set_breakpoint(0, info);
return 0;
}
@@ -221,7 +221,7 @@ void thread_change_pc(struct task_struct *tsk, struct
pt_regs *regs)
info = counter_arch_bp(tsk->thread.last_hit_ubp);
regs->msr &= ~MSR_SE;
- __set_breakpoint(info);
+ __set_breakpoint(0, info);
tsk->thread.last_hit_ubp = NULL;
}
@@ -346,7 +346,7 @@ int hw_breakpoint_handler(struct die_args *args)
if (!(info->type & HW_BRK_TYPE_EXTRANEOUS_IRQ))
perf_bp_event(bp, regs);
- __set_breakpoint(info);
+ __set_breakpoint(0, info);
out:
rcu_read_unlock();
return rc;
@@ -379,7 +379,7 @@ static int single_step_dabr_instruction(struct die_args
*args)
if (!(info->type & HW_BRK_TYPE_EXTRANEOUS_IRQ))
perf_bp_event(bp, regs);
- __set_breakpoint(info);
+ __set_breakpoint(0, info);
current->thread.last_hit_ubp = NULL;
/*
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 7488adf4d61c..351fbd8d2c5b 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -637,7 +637,7 @@ void do_break (struct pt_regs *regs, unsigned long address,
}
#endif /* CONFIG_PPC_ADV_DEBUG_REGS */
-static DEFINE_PER_CPU(struct arch_hw_breakpoint, current_brk);
+static DEFINE_PER_CPU(struct arch_hw_breakpoint, current_brk[HBP_NUM_MAX]);
#ifdef CONFIG_PPC_ADV_DEBUG_REGS
/*
@@ -714,7 +714,7 @@ EXPORT_SYMBOL_GPL(switch_booke_debug_regs);
static void set_breakpoint(struct arch_hw_breakpoint *brk)
{
preempt_disable();
- __set_breakpoint(brk);
+ __set_breakpoint(0, brk);
preempt_enable();
}
@@ -800,13 +800,13 @@ static inline int set_breakpoint_8xx(struct
arch_hw_breakpoint *brk)
return 0;
}
-void __set_breakpoint(struct arch_hw_breakpoint *brk)
+void __set_breakpoint(int nr, struct arch_hw_breakpoint *brk)
{
- memcpy(this_cpu_ptr(_brk), brk, sizeof(*brk));
+ memcpy(this_cpu_ptr(_brk[nr]), brk, sizeof(*brk));
if (dawr_enabled())
// Power8 or later
- set_dawr(0, brk);
+ set_dawr(nr, brk);
else if (IS_ENABLED(CONFIG_PPC_8xx))
set_breakpoint_8xx(brk);
else if (!cpu_has_feature(CPU_FTR_ARCH_207S))
@@ -1174,8 +1174,8 @@ struct task_struct *__switch_to(struct task_struct *prev,
* schedule DABR
*/
#ifndef CONFIG_HAVE_HW_BREAKPOINT
- if (unlikely(!hw_brk_match(this_cpu_ptr(_brk),
>thread.hw_brk)))
- __set_breakpoint(>thread.hw_brk);
+ if (unlikely(!hw_brk_match(this_cpu_ptr(_brk[0]),
>thread.hw_brk)))
+ __set_breakpoint(0, >thread.hw_brk);
#endif /*
[PATCH v4 04/16] powerpc/watchpoint/ptrace: Return actual num of available watchpoints
User can ask for num of available watchpoints(dbginfo.num_data_bps) using ptrace(PPC_PTRACE_GETHWDBGINFO). Return actual number of available watchpoints on the machine rather than hardcoded 1. Signed-off-by: Ravi Bangoria Reviewed-by: Michael Neuling --- arch/powerpc/kernel/ptrace/ptrace-noadv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/kernel/ptrace/ptrace-noadv.c b/arch/powerpc/kernel/ptrace/ptrace-noadv.c index f87e7c5c3bf3..12962302d6a4 100644 --- a/arch/powerpc/kernel/ptrace/ptrace-noadv.c +++ b/arch/powerpc/kernel/ptrace/ptrace-noadv.c @@ -44,7 +44,7 @@ void ppc_gethwdinfo(struct ppc_debug_info *dbginfo) dbginfo->version = 1; dbginfo->num_instruction_bps = 0; if (ppc_breakpoint_available()) - dbginfo->num_data_bps = 1; + dbginfo->num_data_bps = nr_wp_slots(); else dbginfo->num_data_bps = 0; dbginfo->num_condition_regs = 0; -- 2.21.1
[PATCH v4 01/16] powerpc/watchpoint: Rename current DAWR macros
Future Power architecture is introducing second DAWR. Use real
register names from ISA for current macros:
s/SPRN_DAWR/SPRN_DAWR0/
s/SPRN_DAWRX/SPRN_DAWRX0/
Signed-off-by: Ravi Bangoria
Reviewed-by: Michael Neuling
---
arch/powerpc/include/asm/reg.h | 4 ++--
arch/powerpc/kernel/dawr.c | 4 ++--
arch/powerpc/kvm/book3s_hv.c| 12 ++--
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 18 +-
arch/powerpc/xmon/xmon.c| 2 +-
5 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index da5cab038e25..156ee89fa9be 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -283,14 +283,14 @@
#define CTRL_CT1 0x4000 /* thread 1 */
#define CTRL_TE 0x00c0 /* thread enable */
#define CTRL_RUNLATCH0x1
-#define SPRN_DAWR 0xB4
+#define SPRN_DAWR0 0xB4
#define SPRN_RPR 0xBA/* Relative Priority Register */
#define SPRN_CIABR 0xBB
#define CIABR_PRIV 0x3
#define CIABR_PRIV_USER 1
#define CIABR_PRIV_SUPER 2
#define CIABR_PRIV_HYPER 3
-#define SPRN_DAWRX 0xBC
+#define SPRN_DAWRX00xBC
#define DAWRX_USER __MASK(0)
#define DAWRX_KERNEL __MASK(1)
#define DAWRX_HYP__MASK(2)
diff --git a/arch/powerpc/kernel/dawr.c b/arch/powerpc/kernel/dawr.c
index cc14aa6c4a1b..e91b613bf137 100644
--- a/arch/powerpc/kernel/dawr.c
+++ b/arch/powerpc/kernel/dawr.c
@@ -39,8 +39,8 @@ int set_dawr(struct arch_hw_breakpoint *brk)
if (ppc_md.set_dawr)
return ppc_md.set_dawr(dawr, dawrx);
- mtspr(SPRN_DAWR, dawr);
- mtspr(SPRN_DAWRX, dawrx);
+ mtspr(SPRN_DAWR0, dawr);
+ mtspr(SPRN_DAWRX0, dawrx);
return 0;
}
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 93493f0cbfe8..db07199f0977 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -3392,8 +3392,8 @@ static int kvmhv_load_hv_regs_and_go(struct kvm_vcpu
*vcpu, u64 time_limit,
int trap;
unsigned long host_hfscr = mfspr(SPRN_HFSCR);
unsigned long host_ciabr = mfspr(SPRN_CIABR);
- unsigned long host_dawr = mfspr(SPRN_DAWR);
- unsigned long host_dawrx = mfspr(SPRN_DAWRX);
+ unsigned long host_dawr = mfspr(SPRN_DAWR0);
+ unsigned long host_dawrx = mfspr(SPRN_DAWRX0);
unsigned long host_psscr = mfspr(SPRN_PSSCR);
unsigned long host_pidr = mfspr(SPRN_PID);
@@ -3422,8 +3422,8 @@ static int kvmhv_load_hv_regs_and_go(struct kvm_vcpu
*vcpu, u64 time_limit,
mtspr(SPRN_SPURR, vcpu->arch.spurr);
if (dawr_enabled()) {
- mtspr(SPRN_DAWR, vcpu->arch.dawr);
- mtspr(SPRN_DAWRX, vcpu->arch.dawrx);
+ mtspr(SPRN_DAWR0, vcpu->arch.dawr);
+ mtspr(SPRN_DAWRX0, vcpu->arch.dawrx);
}
mtspr(SPRN_CIABR, vcpu->arch.ciabr);
mtspr(SPRN_IC, vcpu->arch.ic);
@@ -3475,8 +3475,8 @@ static int kvmhv_load_hv_regs_and_go(struct kvm_vcpu
*vcpu, u64 time_limit,
(local_paca->kvm_hstate.fake_suspend << PSSCR_FAKE_SUSPEND_LG));
mtspr(SPRN_HFSCR, host_hfscr);
mtspr(SPRN_CIABR, host_ciabr);
- mtspr(SPRN_DAWR, host_dawr);
- mtspr(SPRN_DAWRX, host_dawrx);
+ mtspr(SPRN_DAWR0, host_dawr);
+ mtspr(SPRN_DAWRX0, host_dawrx);
mtspr(SPRN_PID, host_pidr);
/*
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index 780a499c7114..70de3325d0e9 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -707,8 +707,8 @@ BEGIN_FTR_SECTION
END_FTR_SECTION_IFSET(CPU_FTR_ARCH_300)
BEGIN_FTR_SECTION
mfspr r5, SPRN_CIABR
- mfspr r6, SPRN_DAWR
- mfspr r7, SPRN_DAWRX
+ mfspr r6, SPRN_DAWR0
+ mfspr r7, SPRN_DAWRX0
mfspr r8, SPRN_IAMR
std r5, STACK_SLOT_CIABR(r1)
std r6, STACK_SLOT_DAWR(r1)
@@ -803,8 +803,8 @@ END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_207S)
beq 1f
ld r5, VCPU_DAWR(r4)
ld r6, VCPU_DAWRX(r4)
- mtspr SPRN_DAWR, r5
- mtspr SPRN_DAWRX, r6
+ mtspr SPRN_DAWR0, r5
+ mtspr SPRN_DAWRX0, r6
1:
ld r7, VCPU_CIABR(r4)
ld r8, VCPU_TAR(r4)
@@ -1766,8 +1766,8 @@ BEGIN_FTR_SECTION
* If the DAWR doesn't work, it's ok to write these here as
* this value should always be zero
*/
- mtspr SPRN_DAWR, r6
- mtspr SPRN_DAWRX, r7
+ mtspr SPRN_DAWR0, r6
+ mtspr SPRN_DAWRX0, r7
END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
BEGIN_FTR_SECTION
ld r5, STACK_SLOT_TID(r1)
@@ -2577,8 +2577,8 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
mfmsr r6
andi. r6, r6, MSR_DR /* in real mode? */
bne
Re: [PATCH v2 2/3] powerpc/numa: Prefer node id queried from vphn
* Gautham R Shenoy [2020-04-29 12:22:29]:
> Hello Srikar,
>
>
> > + if (nid == NUMA_NO_NODE) {
> > + cpu = of_get_cpu_node(i, NULL);
> > + if (cpu) {
>
> Why are we not retaining the BUG_ON(!cpu) assert here ?
>
> > + nid = of_node_to_nid_single(cpu);
> > + of_node_put(cpu);
> > + }
> > + }
>
> Is it possible at this point that both vphn_get_nid(i) and
> of_node_to_nid_single(cpu) returns NUMA_NO_NODE ? If so,
> should we still call node_set_online() below ?
Yeah, I think It makes sense to retain the BUG_ON and if check.
Will incorporate both of them in the next version.
>
>
> > node_set_online(nid);
> > }
> >
> > --
> > 2.20.1
> >
> --
> Thanks and Regards
> gautham.
--
Thanks and Regards
Srikar Dronamraju
[PATCH v4 00/16] powerpc/watchpoint: Preparation for more than one watchpoint
So far, powerpc Book3S code has been written with an assumption of only one watchpoint. But future power architecture is introducing second watchpoint register (DAWR). Even though this patchset does not enable 2nd DAWR, it make the infrastructure ready so that enabling 2nd DAWR should just be a matter of changing count. Existing functionality works fine with the patchset. I've tested it with perf, ptrace(gdb), xmon. All hw-breakpoint selftests are passing as well. And I've build tested for 8xx and 'AMCC 44x, 46x or 47x'. Note: kvm or PowerVM guest is not enabled yet. v3: https://lore.kernel.org/linuxppc-dev/20200414031659.58875-1-ravi.bango...@linux.ibm.com v3->v4: - Reduce the scope of local variables to increase readability at some places, suggested by Christophe. - Added Michael Neuling's Reviewed by for the series. - Rebased to powerpc/next Ravi Bangoria (16): powerpc/watchpoint: Rename current DAWR macros powerpc/watchpoint: Add SPRN macros for second DAWR powerpc/watchpoint: Introduce function to get nr watchpoints dynamically powerpc/watchpoint/ptrace: Return actual num of available watchpoints powerpc/watchpoint: Provide DAWR number to set_dawr powerpc/watchpoint: Provide DAWR number to __set_breakpoint powerpc/watchpoint: Get watchpoint count dynamically while disabling them powerpc/watchpoint: Disable all available watchpoints when !dawr_force_enable powerpc/watchpoint: Convert thread_struct->hw_brk to an array powerpc/watchpoint: Use loop for thread_struct->ptrace_bps powerpc/watchpoint: Introduce is_ptrace_bp() function powerpc/watchpoint: Use builtin ALIGN*() macros powerpc/watchpoint: Prepare handler to handle more than one watcnhpoint powerpc/watchpoint: Don't allow concurrent perf and ptrace events powerpc/watchpoint/xmon: Don't allow breakpoint overwriting powerpc/watchpoint/xmon: Support 2nd dawr arch/powerpc/include/asm/cputable.h | 6 +- arch/powerpc/include/asm/debug.h | 2 +- arch/powerpc/include/asm/hw_breakpoint.h | 32 +- arch/powerpc/include/asm/processor.h | 6 +- arch/powerpc/include/asm/reg.h| 6 +- arch/powerpc/include/asm/sstep.h | 2 + arch/powerpc/kernel/dawr.c| 23 +- arch/powerpc/kernel/hw_breakpoint.c | 645 ++ arch/powerpc/kernel/process.c | 85 +-- arch/powerpc/kernel/ptrace/ptrace-noadv.c | 72 ++- arch/powerpc/kernel/ptrace/ptrace32.c | 4 +- arch/powerpc/kernel/signal.c | 13 +- arch/powerpc/kvm/book3s_hv.c | 12 +- arch/powerpc/kvm/book3s_hv_rmhandlers.S | 18 +- arch/powerpc/xmon/xmon.c | 99 +++- kernel/events/hw_breakpoint.c | 16 + 16 files changed, 814 insertions(+), 227 deletions(-) -- 2.21.1
[PATCH v4 03/16] powerpc/watchpoint: Introduce function to get nr watchpoints dynamically
So far we had only one watchpoint, so we have hardcoded HBP_NUM to 1.
But future Power architecture is introducing 2nd DAWR and thus kernel
should be able to dynamically find actual number of watchpoints
supported by hw it's running on. Introduce function for the same.
Also convert HBP_NUM macro to HBP_NUM_MAX, which will now represent
maximum number of watchpoints supported by Powerpc.
Signed-off-by: Ravi Bangoria
Reviewed-by: Michael Neuling
---
arch/powerpc/include/asm/cputable.h | 6 +-
arch/powerpc/include/asm/hw_breakpoint.h | 5 +
arch/powerpc/include/asm/processor.h | 2 +-
arch/powerpc/kernel/hw_breakpoint.c | 2 +-
4 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch/powerpc/include/asm/cputable.h
index 40a4d3c6fd99..c67b94f3334c 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -614,7 +614,11 @@ enum {
};
#endif /* __powerpc64__ */
-#define HBP_NUM 1
+/*
+ * Maximum number of hw breakpoint supported on powerpc. Number of
+ * breakpoints supported by actual hw might be less than this.
+ */
+#define HBP_NUM_MAX1
#endif /* !__ASSEMBLY__ */
diff --git a/arch/powerpc/include/asm/hw_breakpoint.h
b/arch/powerpc/include/asm/hw_breakpoint.h
index f2f8d8aa8e3b..518b41eef924 100644
--- a/arch/powerpc/include/asm/hw_breakpoint.h
+++ b/arch/powerpc/include/asm/hw_breakpoint.h
@@ -43,6 +43,11 @@ struct arch_hw_breakpoint {
#define DABR_MAX_LEN 8
#define DAWR_MAX_LEN 512
+static inline int nr_wp_slots(void)
+{
+ return HBP_NUM_MAX;
+}
+
#ifdef CONFIG_HAVE_HW_BREAKPOINT
#include
#include
diff --git a/arch/powerpc/include/asm/processor.h
b/arch/powerpc/include/asm/processor.h
index bfa336fbcfeb..a71bdd6bc284 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -180,7 +180,7 @@ struct thread_struct {
int fpexc_mode; /* floating-point exception mode */
unsigned intalign_ctl; /* alignment handling control */
#ifdef CONFIG_HAVE_HW_BREAKPOINT
- struct perf_event *ptrace_bps[HBP_NUM];
+ struct perf_event *ptrace_bps[HBP_NUM_MAX];
/*
* Helps identify source of single-step exception and subsequent
* hw-breakpoint enablement
diff --git a/arch/powerpc/kernel/hw_breakpoint.c
b/arch/powerpc/kernel/hw_breakpoint.c
index 72f461bd70fb..4120349e2abe 100644
--- a/arch/powerpc/kernel/hw_breakpoint.c
+++ b/arch/powerpc/kernel/hw_breakpoint.c
@@ -38,7 +38,7 @@ static DEFINE_PER_CPU(struct perf_event *, bp_per_reg);
int hw_breakpoint_slots(int type)
{
if (type == TYPE_DATA)
- return HBP_NUM;
+ return nr_wp_slots();
return 0; /* no instruction breakpoints available */
}
--
2.21.1
[PATCH v4 02/16] powerpc/watchpoint: Add SPRN macros for second DAWR
Future Power architecture is introducing second DAWR. Add SPRN_ macros for the same. Signed-off-by: Ravi Bangoria Reviewed-by: Michael Neuling --- arch/powerpc/include/asm/reg.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h index 156ee89fa9be..062e74cf41fd 100644 --- a/arch/powerpc/include/asm/reg.h +++ b/arch/powerpc/include/asm/reg.h @@ -284,6 +284,7 @@ #define CTRL_TE 0x00c0 /* thread enable */ #define CTRL_RUNLATCH0x1 #define SPRN_DAWR0 0xB4 +#define SPRN_DAWR1 0xB5 #define SPRN_RPR 0xBA/* Relative Priority Register */ #define SPRN_CIABR 0xBB #define CIABR_PRIV 0x3 @@ -291,6 +292,7 @@ #define CIABR_PRIV_SUPER 2 #define CIABR_PRIV_HYPER 3 #define SPRN_DAWRX00xBC +#define SPRN_DAWRX10xBD #define DAWRX_USER __MASK(0) #define DAWRX_KERNEL __MASK(1) #define DAWRX_HYP__MASK(2) -- 2.21.1
Re: [PATCH V2] fs/ceph:fix double unlock in handle_cap_export()
On 2020/4/30 10:50, Yan, Zheng wrote:
On Wed, Apr 29, 2020 at 8:49 AM Wu Bo wrote:
On 2020/4/28 22:48, Jeff Layton wrote:
On Tue, 2020-04-28 at 21:13 +0800, Wu Bo wrote:
if the ceph_mdsc_open_export_target_session() return fails,
should add a lock to avoid twice unlocking.
Because the lock will be released at the retry or out_unlock tag.
The problem looks real, but...
--
v1 -> v2:
add spin_lock(>i_ceph_lock) before goto out_unlock tag.
Signed-off-by: Wu Bo
---
fs/ceph/caps.c | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c
index 185db76..414c0e2 100644
--- a/fs/ceph/caps.c
+++ b/fs/ceph/caps.c
@@ -3731,22 +3731,25 @@ static void handle_cap_export(struct inode *inode,
struct ceph_mds_caps *ex,
/* open target session */
tsession = ceph_mdsc_open_export_target_session(mdsc, target);
-if (!IS_ERR(tsession)) {
-if (mds > target) {
-mutex_lock(>s_mutex);
-mutex_lock_nested(>s_mutex,
- SINGLE_DEPTH_NESTING);
-} else {
-mutex_lock(>s_mutex);
-mutex_lock_nested(>s_mutex,
- SINGLE_DEPTH_NESTING);
-}
-new_cap = ceph_get_cap(mdsc, NULL);
-} else {
+if (IS_ERR(tsession)) {
WARN_ON(1);
tsession = NULL;
target = -1;
+mutex_lock(>s_mutex);
+spin_lock(>i_ceph_lock);
+goto out_unlock;
Why did you make this case goto out_unlock instead of retrying as it did
before?
If the problem occurs, target = -1, and goto retry lable, you need to
call __get_cap_for_mds() or even call __ceph_remove_cap(), and then jump
to out_unlock lable. All I think is unnecessary, goto out_unlock instead
of retrying directly.
__ceph_remove_cap() must be called even if opening target session
failed. I think adding a mutex_lock(>s_mutex) to the
IS_ERR(tsession) block should be enough.
Yes，I will send the V3 patch later.
Thanks.
Wu Bo
+}
+
+if (mds > target) {
+mutex_lock(>s_mutex);
+mutex_lock_nested(>s_mutex,
+SINGLE_DEPTH_NESTING);
+} else {
+mutex_lock(>s_mutex);
+mutex_lock_nested(>s_mutex,
+SINGLE_DEPTH_NESTING);
}
+new_cap = ceph_get_cap(mdsc, NULL);
goto retry;
out_unlock:
.
linux-next: manual merge of the driver-core tree with the driver-core.current tree
Hi all,
Today's linux-next merge of the driver-core tree got a conflict in:
drivers/base/dd.c
between commits:
ce68929f07de ("driver core: Revert default driver_deferred_probe_timeout
value to 0")
4ccc03e28ec3 ("driver core: Use dev_warn() instead of dev_WARN() for
deferred_probe_timeout warnings")
35a672363ab3 ("driver core: Ensure wait_for_device_probe() waits until the
deferred_probe_timeout fires")
from the driver-core.current tree and commit:
eb7fbc9fb118 ("driver core: Add missing '\n' in log messages")
from the driver-core tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/base/dd.c
index 94037be7f5d7,efe6df5bff26..
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@@ -258,8 -266,8 +258,8 @@@ int driver_deferred_probe_check_state(s
return -ENODEV;
}
- if (!driver_deferred_probe_timeout) {
- dev_WARN(dev, "deferred probe timeout, ignoring dependency\n");
+ if (!driver_deferred_probe_timeout && initcalls_done) {
- dev_warn(dev, "deferred probe timeout, ignoring dependency");
++ dev_warn(dev, "deferred probe timeout, ignoring dependency\n");
return -ETIMEDOUT;
}
@@@ -275,8 -283,7 +275,8 @@@ static void deferred_probe_timeout_work
flush_work(_probe_work);
list_for_each_entry_safe(private, p, _probe_pending_list,
deferred_probe)
- dev_info(private->device, "deferred probe pending");
+ dev_info(private->device, "deferred probe pending\n");
+ wake_up(_timeout_waitqueue);
}
static DECLARE_DELAYED_WORK(deferred_probe_timeout_work,
deferred_probe_timeout_work_func);
pgp4NzQSGcGYN.pgp
Description: OpenPGP digital signature
Re: BPF vs objtool again
On Wed, Apr 29, 2020 at 10:53:15PM -0500, Josh Poimboeuf wrote:
> On Wed, Apr 29, 2020 at 07:10:52PM -0700, Alexei Starovoitov wrote:
> > > For example:
> > >
> > > #define GOTO({ goto *jumptable[insn->code]; })
> > >
> > > and then replace all 'goto select_insn' with 'GOTO;'
> > >
> > > The problem is that with RETPOLINE=y, the function text size grows from
> > > 5k to 7k, because for each of the 160+ retpoline JMPs, GCC (stupidly)
> > > reloads the jump table register into a scratch register.
> >
> > that would be a tiny change, right?
> > I'd rather go with that and gate it with 'ifdef CONFIG_FRAME_POINTER'
> > Like:
> > #ifndef CONFIG_FRAME_POINTER
> > #define CONT ({ insn++; goto select_insn; })
> > #define CONT_JMP ({ insn++; goto select_insn; })
> > #else
> > #define CONT ({ insn++; goto *jumptable[insn->code]; })
> > #define CONT_JMP ({ insn++; goto *jumptable[insn->code]; })
> > #endif
> >
> > The reason this CONT and CONT_JMP macros are there because a combination
> > of different gcc versions together with different cpus make branch predictor
> > behave 'unpredictably'.
> >
> > I've played with CONT and CONT_JMP either both doing direct goto or
> > indirect goto and observed quite different performance characteristics
> > from the interpreter.
> > What you see right now was the best tune I could get from a set of cpus
> > I had to play with and compilers. If I did the same tuning today the outcome
> > could have been different.
> > So I think it's totally fine to use above code. I think some cpus may
> > actually
> > see performance gains with certain versions of gcc.
> > The retpoline text increase is unfortunate but when retpoline is on
> > other security knobs should be on too. In particular
> > CONFIG_BPF_JIT_ALWAYS_ON
> > should be on as well. Which will remove interpreter from .text completely.
>
> This would actually be contingent on RETPOLINE, not FRAME_POINTER.
>
> (FRAME_POINTER was the other issue with the "optimize" attribute, which
> we're reverting so it'll no longer be a problem.)
>
> So if you're not concerned about the retpoline text growth, it could be
> as simple as:
>
> #define CONT ({ insn++; goto *jumptable[insn->code]; })
> #define CONT_JMP ({ insn++; goto *jumptable[insn->code]; })
>
>
> Or, if you wanted to avoid the text growth, it could be:
>
> #ifdef CONFIG_RETPOLINE
I'm a bit lost. So objtool is fine with the asm when retpoline is on?
Then pls do:
#if defined(CONFIG_RETPOLINE) || !defined(CONFIG_X86)
since there is no need to mess with other archs.
> /*
> * Avoid a 40% increase in function text size by getting GCC to generate a
> * single retpoline jump instead of 160+.
> */
> #define CONT ({ insn++; goto select_insn; })
> #define CONT_JMP ({ insn++; goto select_insn; })
>
> select_insn:
> goto *jumptable[insn->code];
>
> #else /* !CONFIG_RETPOLINE */
> #define CONT ({ insn++; goto *jumptable[insn->code]; })
> #define CONT_JMP ({ insn++; goto *jumptable[insn->code]; })
> #endif /* CONFIG_RETPOLINE */
>
>
> But since this is legacy path, I think the first one is much nicer.
>
>
> Also, JMP_TAIL_CALL has a "goto select_insn", is it ok to convert that
> to CONT?
yep
Re: [PATCH] hw_breakpoint: Remove unused '__register_perf_hw_breakpoint' declaration
Hi Mark,
Thanks for the review.
On Tue, Apr 28, 2020 at 3:37 PM Mark Rutland wrote:
>
> Hi Bhupesh,
>
> On Tue, Apr 28, 2020 at 02:22:17PM +0530, Bhupesh Sharma wrote:
> > commit b326e9560a28 ("hw-breakpoints: Use overflow handler instead of
> > the event callback") removed '__register_perf_hw_breakpoint' function
> > usage and replaced it with 'register_perf_hw_breakpoint' function.
> >
> > Remove the left-over unused '__register_perf_hw_breakpoint' declaration
> > from 'hw_breakpoint.h' as well.
> >
> > Cc: Mark Rutland
> > Cc: Will Deacon
> > Cc: Catalin Marinas
> > Signed-off-by: Bhupesh Sharma
>
> This is generic code, so I'm a bit confused as to why you've sent it to
> us. I'd expect this to go via the perf core maintainers (cc'd).
Oops, my bad. Seems my git patch sending script messed up while
picking up the perf maintainers (who should have been Cc'ed on the
patch) :(
Thanks for adding them in the Cc list.
Hi Peter, Frederic, Ingo - Kindly help review this patch and help
apply the patch (if suitable).
Thanks,
Bhupesh
> FWIW, this looks sane to me, so:
>
> Acked-by: Mark Rutland
>
> Mark.
>
> > ---
> > include/linux/hw_breakpoint.h | 3 ---
> > 1 file changed, 3 deletions(-)
> >
> > diff --git a/include/linux/hw_breakpoint.h b/include/linux/hw_breakpoint.h
> > index 6058c3844a76..fe1302da8e0f 100644
> > --- a/include/linux/hw_breakpoint.h
> > +++ b/include/linux/hw_breakpoint.h
> > @@ -72,7 +72,6 @@ register_wide_hw_breakpoint(struct perf_event_attr *attr,
> > void *context);
> >
> > extern int register_perf_hw_breakpoint(struct perf_event *bp);
> > -extern int __register_perf_hw_breakpoint(struct perf_event *bp);
> > extern void unregister_hw_breakpoint(struct perf_event *bp);
> > extern void unregister_wide_hw_breakpoint(struct perf_event * __percpu
> > *cpu_events);
> >
> > @@ -115,8 +114,6 @@ register_wide_hw_breakpoint(struct perf_event_attr
> > *attr,
> > void *context) { return NULL; }
> > static inline int
> > register_perf_hw_breakpoint(struct perf_event *bp) { return -ENOSYS; }
> > -static inline int
> > -__register_perf_hw_breakpoint(struct perf_event *bp) { return
> > -ENOSYS; }
> > static inline void unregister_hw_breakpoint(struct perf_event *bp) { }
> > static inline void
> > unregister_wide_hw_breakpoint(struct perf_event * __percpu *cpu_events)
> > { }
> > --
> > 2.7.4
> >
>
Re: [PATCH 3/5] swiotlb: Add alloc and free APIs
Hi Srivatsa,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on vhost/linux-next]
[also build test ERROR on xen-tip/linux-next linus/master v5.7-rc3
next-20200429]
[cannot apply to swiotlb/linux-next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Srivatsa-Vaddagiri/virtio-on-Type-1-hypervisor/20200429-032334
base: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git linux-next
config: i386-randconfig-b002-20200429 (attached as .config)
compiler: gcc-7 (Ubuntu 7.5.0-6ubuntu2) 7.5.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
In file included from drivers/gpu/drm/i915/i915_scatterlist.h:12:0,
from drivers/gpu/drm/i915/i915_scatterlist.c:7:
include/linux/swiotlb.h: In function 'swiotlb_alloc':
>> include/linux/swiotlb.h:231:9: error: 'DMA_MAPPING_ERROR' undeclared (first
>> use in this function); did you mean 'APM_NO_ERROR'?
return DMA_MAPPING_ERROR;
^
APM_NO_ERROR
include/linux/swiotlb.h:231:9: note: each undeclared identifier is reported
only once for each function it appears in
vim +231 include/linux/swiotlb.h
226
227 static inline phys_addr_t swiotlb_alloc(struct swiotlb_pool *pool,
228 size_t alloc_size, unsigned long tbl_dma_addr,
229 unsigned long mask)
230 {
> 231 return DMA_MAPPING_ERROR;
232 }
233
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH v5 0/5] Track and expose idle PURR and SPURR ticks
Hello Michael, On Thu, Apr 30, 2020 at 12:34:52PM +1000, Michael Ellerman wrote: > Gautham R Shenoy writes: > > On Mon, Apr 20, 2020 at 03:46:35PM -0700, Tyrel Datwyler wrote: > >> On 4/7/20 1:47 AM, Gautham R. Shenoy wrote: > >> > From: "Gautham R. Shenoy" > >> > > >> > Hi, > >> > > >> > This is the fifth version of the patches to track and expose idle PURR > >> > and SPURR ticks. These patches are required by tools such as lparstat > >> > to compute system utilization for capacity planning purposes. > ... > >> > > >> > Gautham R. Shenoy (5): > >> > powerpc: Move idle_loop_prolog()/epilog() functions to header file > >> > powerpc/idle: Store PURR snapshot in a per-cpu global variable > >> > powerpc/pseries: Account for SPURR ticks on idle CPUs > >> > powerpc/sysfs: Show idle_purr and idle_spurr for every CPU > >> > Documentation: Document sysfs interfaces purr, spurr, idle_purr, > >> > idle_spurr > >> > > >> > Documentation/ABI/testing/sysfs-devices-system-cpu | 39 + > >> > arch/powerpc/include/asm/idle.h| 93 > >> > ++ > >> > arch/powerpc/kernel/sysfs.c| 82 > >> > ++- > >> > arch/powerpc/platforms/pseries/setup.c | 8 +- > >> > drivers/cpuidle/cpuidle-pseries.c | 39 ++--- > >> > 5 files changed, 224 insertions(+), 37 deletions(-) > >> > create mode 100644 arch/powerpc/include/asm/idle.h > >> > > >> > >> Reviewed-by: Tyrel Datwyler > > > > Thanks for reviewing the patches. > > > >> > >> Any chance this is going to be merged in the near future? There is a > >> patchset to > >> update lparstat in the powerpc-utils package to calculate PURR/SPURR cpu > >> utilization that I would like to merge, but have been holding off to make > >> sure > >> we are synced with this proposed patchset. > > > > Michael, could you please consider this for 5.8 ? > > Yes. Has it been tested on KVM at all? No. I haven't tested this on KVM. Will do that today. > > cheers -- Thanks and Regards gautham.
Re: [Nouveau] [PATCH] drm/nouveau: Fix regression by audio component transition
Good catch! The OR is definitely a far better choice than the head
here, as it's what we use to select the GPU-side HDA registers too.
Merged.
On Thu, 16 Apr 2020 at 17:54, Takashi Iwai wrote:
>
> Since the commit 742db30c4ee6 ("drm/nouveau: Add HD-audio component
> notifier support"), the nouveau driver notifies and pokes the HD-audio
> HPD and ELD via audio component, but this seems broken. The culprit
> is the naive assumption that crtc->index corresponds to the HDA pin.
> Actually this rather corresponds to the MST dev_id (alias "pipe" in
> the audio component framework) while the actual port number is given
> from the output ior id number.
>
> This patch corrects the assignment of port and dev_id arguments in the
> audio component ops to recover from the HDMI/DP audio regression.
>
> Fixes: 742db30c4ee6 ("drm/nouveau: Add HD-audio component notifier support")
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207223
> Cc:
> Signed-off-by: Takashi Iwai
> ---
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 16 ++--
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index a3dc2ba19fb2..3a9fd565079d 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -481,15 +481,16 @@ nv50_dac_create(struct drm_connector *connector, struct
> dcb_output *dcbe)
> * audio component binding for ELD notification
> */
> static void
> -nv50_audio_component_eld_notify(struct drm_audio_component *acomp, int port)
> +nv50_audio_component_eld_notify(struct drm_audio_component *acomp, int port,
> + int dev_id)
> {
> if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify)
> acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr,
> -port, -1);
> +port, dev_id);
> }
>
> static int
> -nv50_audio_component_get_eld(struct device *kdev, int port, int pipe,
> +nv50_audio_component_get_eld(struct device *kdev, int port, int dev_id,
> bool *enabled, unsigned char *buf, int max_bytes)
> {
> struct drm_device *drm_dev = dev_get_drvdata(kdev);
> @@ -505,7 +506,8 @@ nv50_audio_component_get_eld(struct device *kdev, int
> port, int pipe,
> nv_encoder = nouveau_encoder(encoder);
> nv_connector = nouveau_encoder_connector_get(nv_encoder);
> nv_crtc = nouveau_crtc(encoder->crtc);
> - if (!nv_connector || !nv_crtc || nv_crtc->index != port)
> + if (!nv_connector || !nv_crtc || nv_encoder->or != port ||
> + nv_crtc->index != dev_id)
> continue;
> *enabled = drm_detect_monitor_audio(nv_connector->edid);
> if (*enabled) {
> @@ -599,7 +601,8 @@ nv50_audio_disable(struct drm_encoder *encoder, struct
> nouveau_crtc *nv_crtc)
>
> nvif_mthd(>disp->object, 0, , sizeof(args));
>
> - nv50_audio_component_eld_notify(drm->audio.component, nv_crtc->index);
> + nv50_audio_component_eld_notify(drm->audio.component, nv_encoder->or,
> + nv_crtc->index);
> }
>
> static void
> @@ -633,7 +636,8 @@ nv50_audio_enable(struct drm_encoder *encoder, struct
> drm_display_mode *mode)
> nvif_mthd(>disp->object, 0, ,
> sizeof(args.base) + drm_eld_size(args.data));
>
> - nv50_audio_component_eld_notify(drm->audio.component, nv_crtc->index);
> + nv50_audio_component_eld_notify(drm->audio.component, nv_encoder->or,
> + nv_crtc->index);
> }
>
>
> /**
> --
> 2.16.4
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [PATCH 0/2] Build ORC fast lookup table in scripts/sorttable tool
On Wed, Apr 29, 2020 at 11:06:58PM -0500, Josh Poimboeuf wrote: > On Thu, Apr 30, 2020 at 10:32:17AM +0800, changhuaixin wrote: > > > > > > > On Apr 29, 2020, at 4:49 PM, Peter Zijlstra wrote: > > > > > > On Wed, Apr 29, 2020 at 02:46:24PM +0800, Huaixin Chang wrote: > > >> Move building of fast lookup table from boot to sorttable tool. This > > >> saves us > > >> 6380us boot time on Intel(R) Xeon(R) CPU E5-2682 v4 @ 2.50GHz with cores. > > > > > > And what does it add to the build time? > > > > It takes a little more than 7ms to build fast lookup table in > > sorttable on the same CPU. And it is on the critical path. > > Thanks, I like it. It will help make the in-kernel unwinder even > simpler. And it will enable unwinding from early boot. > > Maybe someday we can move all the table sorting code into objtool, once > we have objtool running on vmlinux.o. > > I'll try to review the patches soon. BTW, another cool feature would be for sorttable to run on modules during the module linking phase. -- Josh
[PATCH v3 1/1] scsi: pm: Balance pm_only counter of request queue during system resume
During system resume, scsi_resume_device() decreases a request queue's
pm_only counter if the scsi device was quiesced before. But after that,
if the scsi device's RPM status is RPM_SUSPENDED, the pm_only counter is
still held (non-zero). Current scsi resume hook only sets the RPM status
of the scsi device and its request queue to RPM_ACTIVE, but leaves the
pm_only counter unchanged. This may make the request queue's pm_only
counter remain non-zero after resume hook returns, hence those who are
waiting on the mq_freeze_wq would never be woken up. Fix this by calling
blk_post_runtime_resume() if pm_only is non-zero to balance the pm_only
counter which is held by the scsi device's RPM ops.
(struct request_queue)0xFF815B69E938
pm_only = (counter = 2),
rpm_status = 0,
dev = 0xFF815B0511A0,
((struct device)0xFF815B0511A0)).power
is_suspended = FALSE,
runtime_status = RPM_ACTIVE,
(struct scsi_device)0xFF815b051000
request_queue = 0xFF815B69E938,
sdev_state = SDEV_RUNNING,
quiesced_by = 0x0,
B::v.f_/task_
-000|__switch_to
-001|context_switch
-001|__schedule
-002|schedule
-003|blk_queue_enter(q = 0xFF815B69E938, flags = 0)
-004|generic_make_request
-005|submit_bio
Signed-off-by: Can Guo
---
Change since v2:
- Rebased on 5.8-scsi-queue
Change since v1:
- Added more debugging context info
drivers/scsi/scsi_pm.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/scsi_pm.c b/drivers/scsi/scsi_pm.c
index 3717eea..4804029 100644
--- a/drivers/scsi/scsi_pm.c
+++ b/drivers/scsi/scsi_pm.c
@@ -93,8 +93,10 @@ static int scsi_dev_type_resume(struct device *dev,
*/
if (!err && scsi_is_sdev_device(dev)) {
struct scsi_device *sdev = to_scsi_device(dev);
-
- blk_set_runtime_active(sdev->request_queue);
+ if (blk_queue_pm_only(sdev->request_queue))
+ blk_post_runtime_resume(sdev->request_queue, 0);
+ else
+ blk_set_runtime_active(sdev->request_queue);
}
}
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project.
Re: [PATCH 0/2] Build ORC fast lookup table in scripts/sorttable tool
On Thu, Apr 30, 2020 at 10:32:17AM +0800, changhuaixin wrote: > > > > On Apr 29, 2020, at 4:49 PM, Peter Zijlstra wrote: > > > > On Wed, Apr 29, 2020 at 02:46:24PM +0800, Huaixin Chang wrote: > >> Move building of fast lookup table from boot to sorttable tool. This saves > >> us > >> 6380us boot time on Intel(R) Xeon(R) CPU E5-2682 v4 @ 2.50GHz with cores. > > > > And what does it add to the build time? > > It takes a little more than 7ms to build fast lookup table in > sorttable on the same CPU. And it is on the critical path. Thanks, I like it. It will help make the in-kernel unwinder even simpler. And it will enable unwinding from early boot. Maybe someday we can move all the table sorting code into objtool, once we have objtool running on vmlinux.o. I'll try to review the patches soon. -- Josh
[PATCH] arm: mm: use __pfn_to_section() to get mem_section
Use __pfn_to_section() to get mem_section, instead of open-coding it. No semantic changes. Signed-off-by: Guixiong Wei --- arch/arm64/mm/init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c index e42727e3568e..d2df416b840e 100644 --- a/arch/arm64/mm/init.c +++ b/arch/arm64/mm/init.c @@ -272,7 +272,7 @@ int pfn_valid(unsigned long pfn) if (pfn_to_section_nr(pfn) >= NR_MEM_SECTIONS) return 0; - if (!valid_section(__nr_to_section(pfn_to_section_nr(pfn + if (!valid_section(__pfn_to_section(pfn))) return 0; #endif return memblock_is_map_memory(addr); -- 2.17.1
Re: [PATCH] efi/tpm: fix section mismatch warning
On Wed, Apr 29, 2020 at 09:01:08PM +0200, Arnd Bergmann wrote:
> Building with gcc-10 causes a harmless warning about a section mismatch:
>
> WARNING: modpost: vmlinux.o(.text.unlikely+0x5e191): Section mismatch in
> reference from the function tpm2_calc_event_log_size() to the function
> .init.text:early_memunmap()
> The function tpm2_calc_event_log_size() references
> the function __init early_memunmap().
> This is often because tpm2_calc_event_log_size lacks a __init
> annotation or the annotation of early_memunmap is wrong.
>
> Add the missing annotation.
>
> Fixes: e658c82be556 ("efi/tpm: Only set 'efi_tpm_final_log_size' after
> successful event log parsing")
> Signed-off-by: Arnd Bergmann
Acked-by: Jarkko Sakkinen
/Jarkko
[PATCH v2] dt-bindings: arm-smmu: Add sc7180 compatible string and mem_iface clock
This patch adds a new compatible string for sc7180 and also an additional clock listing needed to power the TBUs and the TCU. Signed-off-by: Sharat Masetty --- v2: Addressed review comments from Doug Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml index 6515dbe..ba5dba4 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml @@ -28,6 +28,7 @@ properties: - enum: - qcom,msm8996-smmu-v2 - qcom,msm8998-smmu-v2 + - qcom,sc7180-smmu-v2 - qcom,sdm845-smmu-v2 - const: qcom,smmu-v2 @@ -113,16 +114,23 @@ properties: present in such cases. clock-names: +minItems: 2 +maxItems: 3 items: - const: bus - const: iface + - const: mem_iface clocks: +minItems: 2 +maxItems: 3 items: - description: bus clock required for downstream bus access and for the smmu ptw - description: interface clock required to access smmu's registers through the TCU's programming interface. + - description: clock required for the inner working of SMMU TBUs and the + TCU like the pagetable walks and the TLB flushes. power-domains: maxItems: 1 -- 1.9.1
Re: [PATCH 1/1] drm/nouveau: Use generic helper to check _PR3 presence
Thanks!
On Thu, 23 Apr 2020 at 17:37, Kai-Heng Feng wrote:
>
> Replace nouveau_pr3_present() in favor of a more generic one,
> pci_pr3_present().
>
> Also the presence of upstream bridge _PR3 doesn't need to go hand in
> hand with device's _DSM, so check _PR3 before _DSM.
>
> Signed-off-by: Kai-Heng Feng
> ---
> drivers/gpu/drm/nouveau/nouveau_acpi.c | 44 ++
> 1 file changed, 10 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c
> b/drivers/gpu/drm/nouveau/nouveau_acpi.c
> index fe3a10255c36..b84dff1b0f28 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
> @@ -212,37 +212,6 @@ static const struct vga_switcheroo_handler
> nouveau_dsm_handler = {
> .get_client_id = nouveau_dsm_get_client_id,
> };
>
> -/*
> - * Firmware supporting Windows 8 or later do not use _DSM to put the device
> into
> - * D3cold, they instead rely on disabling power resources on the parent.
> - */
> -static bool nouveau_pr3_present(struct pci_dev *pdev)
> -{
> - struct pci_dev *parent_pdev = pci_upstream_bridge(pdev);
> - struct acpi_device *parent_adev;
> -
> - if (!parent_pdev)
> - return false;
> -
> - if (!parent_pdev->bridge_d3) {
> - /*
> -* Parent PCI bridge is currently not power managed.
> -* Since userspace can change these afterwards to be on
> -* the safe side we stick with _DSM and prevent usage of
> -* _PR3 from the bridge.
> -*/
> - pci_d3cold_disable(pdev);
> - return false;
> - }
> -
> - parent_adev = ACPI_COMPANION(_pdev->dev);
> - if (!parent_adev)
> - return false;
> -
> - return parent_adev->power.flags.power_resources &&
> - acpi_has_method(parent_adev->handle, "_PR3");
> -}
> -
> static void nouveau_dsm_pci_probe(struct pci_dev *pdev, acpi_handle
> *dhandle_out,
> bool *has_mux, bool *has_opt,
> bool *has_opt_flags, bool *has_pr3)
> @@ -250,6 +219,16 @@ static void nouveau_dsm_pci_probe(struct pci_dev *pdev,
> acpi_handle *dhandle_out
> acpi_handle dhandle;
> bool supports_mux;
> int optimus_funcs;
> + struct pci_dev *parent_pdev;
> +
> + *has_pr3 = false;
> + parent_pdev = pci_upstream_bridge(pdev);
> + if (parent_pdev) {
> + if (parent_pdev->bridge_d3)
> + *has_pr3 = pci_pr3_present(parent_pdev);
> + else
> + pci_d3cold_disable(pdev);
> + }
>
> dhandle = ACPI_HANDLE(>dev);
> if (!dhandle)
> @@ -270,7 +249,6 @@ static void nouveau_dsm_pci_probe(struct pci_dev *pdev,
> acpi_handle *dhandle_out
> *has_mux = supports_mux;
> *has_opt = !!optimus_funcs;
> *has_opt_flags = optimus_funcs & (1 << NOUVEAU_DSM_OPTIMUS_FLAGS);
> - *has_pr3 = false;
>
> if (optimus_funcs) {
> uint32_t result;
> @@ -280,8 +258,6 @@ static void nouveau_dsm_pci_probe(struct pci_dev *pdev,
> acpi_handle *dhandle_out
> (result & OPTIMUS_ENABLED) ? "enabled" : "disabled",
> (result & OPTIMUS_DYNAMIC_PWR_CAP) ? "dynamic power,
> " : "",
> (result & OPTIMUS_HDA_CODEC_MASK) ? "hda bios codec
> supported" : "");
> -
> - *has_pr3 = nouveau_pr3_present(pdev);
> }
> }
>
> --
> 2.17.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v29 00/20] Intel SGX foundations
On Wed, Apr 29, 2020 at 08:14:59AM -0700, Sean Christopherson wrote: > On Wed, Apr 29, 2020 at 08:23:29AM +0300, Jarkko Sakkinen wrote: > > On Sun, Apr 26, 2020 at 11:57:53AM -0500, Dr. Greg wrote: > > > On Wed, Apr 22, 2020 at 12:52:56AM +0300, Jarkko Sakkinen wrote: > > > > > > Good day, I hope the weekend is going well for everyone. > > > > > > > Intel(R) SGX is a set of CPU instructions that can be used by > > > > applications > > > > to set aside private regions of code and data. The code outside the > > > > enclave > > > > is disallowed to access the memory inside the enclave by the CPU access > > > > control. > > > > > > > > ... [ elided ] .. > > > > > > > > The current implementation requires that the firmware sets > > > > IA32_SGXLEPUBKEYHASH* MSRs as writable so that ultimately the kernel can > > > > decide what enclaves it wants run. The implementation does not create > > > > any bottlenecks to support read-only MSRs later on. > > > > > > It seems highly unlikely that a driver implementation with any type of > > > support for read-only launch control registers would ever get into the > > > kernel. All one needs to do is review the conversations that Matthew > > > Garrett's lockdown patches engender to get a sense of that, ie: > > > > > > https://lwn.net/Articles/818277/ > > > > We do not require read-only MSRs. > > Greg is pointing out the opposite, that supporting read-only MSRs is highly > unlikely to ever be supported in the mainline kernel. In a nutshell, what is wrong in the current code changes and what *exactly* should we change? This is way too high level at the moment at least for my limited brain capacity. /Jarkko
Re: [PATCH -next] KVM: MIPS/VZ: Remove unneeded semicolon
Reviewed-by: Huacai Chen
On Thu, Apr 30, 2020 at 11:08 AM Zou Wei wrote:
>
> Fixes coccicheck warnings:
>
> arch/mips/kvm/vz.c:1186:4-5: Unneeded semicolon
> arch/mips/kvm/vz.c:1195:3-4: Unneeded semicolon
> arch/mips/kvm/vz.c:1949:3-4: Unneeded semicolon
> arch/mips/kvm/vz.c:1121:2-3: Unneeded semicolon
> arch/mips/kvm/vz.c:2188:3-4: Unneeded semicolon
>
> Reported-by: Hulk Robot
> Signed-off-by: Zou Wei
> ---
> arch/mips/kvm/vz.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/mips/kvm/vz.c b/arch/mips/kvm/vz.c
> index dde2088..389dd0f 100644
> --- a/arch/mips/kvm/vz.c
> +++ b/arch/mips/kvm/vz.c
> @@ -1118,7 +1118,7 @@ static enum emulation_result kvm_vz_gpsi_cache(union
> mips_instruction inst,
> break;
> default:
> break;
> - };
> + }
>
> kvm_err("@ %#lx/%#lx CACHE (cache: %#x, op: %#x, base[%d]: %#lx,
> offset: %#x\n",
> curr_pc, vcpu->arch.gprs[31], cache, op, base,
> arch->gprs[base],
> @@ -1183,7 +1183,7 @@ static enum emulation_result
> kvm_trap_vz_handle_gpsi(u32 cause, u32 *opc,
> trace_kvm_hwr(vcpu, KVM_TRACE_RDHWR,
> KVM_TRACE_HWR(rd, sel), 0);
> goto unknown;
> - };
> + }
>
> trace_kvm_hwr(vcpu, KVM_TRACE_RDHWR,
> KVM_TRACE_HWR(rd, sel), arch->gprs[rt]);
> @@ -1192,7 +1192,7 @@ static enum emulation_result
> kvm_trap_vz_handle_gpsi(u32 cause, u32 *opc,
> break;
> default:
> goto unknown;
> - };
> + }
> break;
> unknown:
>
> @@ -1946,7 +1946,7 @@ static int kvm_vz_get_one_reg(struct kvm_vcpu *vcpu,
> default:
> *v = (long)kvm_read_c0_guest_prid(cop0);
> break;
> - };
> + }
> break;
> case KVM_REG_MIPS_CP0_EBASE:
> *v = kvm_vz_read_gc0_ebase();
> @@ -2185,7 +2185,7 @@ static int kvm_vz_set_one_reg(struct kvm_vcpu *vcpu,
> default:
> kvm_write_c0_guest_prid(cop0, v);
> break;
> - };
> + }
> break;
> case KVM_REG_MIPS_CP0_EBASE:
> kvm_vz_write_gc0_ebase(v);
> --
> 2.6.2
>
Re: [PATCH -next] drm/nouveau/acr: Use kmemdup instead of kmalloc and memcpy
Thanks!
On Wed, 22 Apr 2020 at 16:56, Zou Wei wrote:
>
> Fixes coccicheck warning:
>
> drivers/gpu/drm/nouveau/nvkm/subdev/acr/hsfw.c:103:23-30: WARNING opportunity
> for kmemdup
> drivers/gpu/drm/nouveau/nvkm/subdev/acr/hsfw.c:113:22-29: WARNING opportunity
> for kmemdup
>
> Fixes: 22dcda45a3d1 ("drm/nouveau/acr: implement new subdev to replace
> "secure boot"")
> Reported-by: Hulk Robot
> Signed-off-by: Zou Wei
> ---
> drivers/gpu/drm/nouveau/nvkm/subdev/acr/hsfw.c | 12
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/acr/hsfw.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/acr/hsfw.c
> index aecce2d..667fa01 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/acr/hsfw.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/acr/hsfw.c
> @@ -100,25 +100,21 @@ nvkm_acr_hsfw_load_image(struct nvkm_acr *acr, const
> char *name, int ver,
> hsfw->data_size = lhdr->data_size;
>
> hsfw->sig.prod.size = fwhdr->sig_prod_size;
> - hsfw->sig.prod.data = kmalloc(hsfw->sig.prod.size, GFP_KERNEL);
> + hsfw->sig.prod.data = kmemdup(fw->data + fwhdr->sig_prod_offset + sig,
> + hsfw->sig.prod.size, GFP_KERNEL);
> if (!hsfw->sig.prod.data) {
> ret = -ENOMEM;
> goto done;
> }
>
> - memcpy(hsfw->sig.prod.data, fw->data + fwhdr->sig_prod_offset + sig,
> - hsfw->sig.prod.size);
> -
> hsfw->sig.dbg.size = fwhdr->sig_dbg_size;
> - hsfw->sig.dbg.data = kmalloc(hsfw->sig.dbg.size, GFP_KERNEL);
> + hsfw->sig.dbg.data = kmemdup(fw->data + fwhdr->sig_dbg_offset + sig,
> +hsfw->sig.dbg.size, GFP_KERNEL);
> if (!hsfw->sig.dbg.data) {
> ret = -ENOMEM;
> goto done;
> }
>
> - memcpy(hsfw->sig.dbg.data, fw->data + fwhdr->sig_dbg_offset + sig,
> - hsfw->sig.dbg.size);
> -
> hsfw->sig.patch_loc = loc;
> done:
> nvkm_firmware_put(fw);
> --
> 2.6.2
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] KVM: MIPS/Emulate: Remove unneeded semicolon
Reviewed-by: Huacai Chen On Thu, Apr 30, 2020 at 11:13 AM Zou Wei wrote: > > Fixes coccicheck warnings: > > arch/mips/kvm/emulate.c:1793:3-4: Unneeded semicolon > arch/mips/kvm/emulate.c:1968:3-4: Unneeded semicolon > > Reported-by: Hulk Robot > Signed-off-by: Zou Wei > --- > arch/mips/kvm/emulate.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/mips/kvm/emulate.c b/arch/mips/kvm/emulate.c > index 754094b..5c88bd1 100644 > --- a/arch/mips/kvm/emulate.c > +++ b/arch/mips/kvm/emulate.c > @@ -1790,7 +1790,7 @@ static enum emulation_result > kvm_mips_guest_cache_op(int (*fn)(unsigned long), > return EMULATE_EXCEPT; > default: > break; > - }; > + } > } > } > > @@ -1965,7 +1965,7 @@ enum emulation_result kvm_mips_emulate_inst(u32 cause, > u32 *opc, > break; > default: > goto unknown; > - }; > + } > break; > unknown: > #endif > -- > 2.6.2 >
Re: BPF vs objtool again
On Wed, Apr 29, 2020 at 07:10:52PM -0700, Alexei Starovoitov wrote:
> > For example:
> >
> > #define GOTO({ goto *jumptable[insn->code]; })
> >
> > and then replace all 'goto select_insn' with 'GOTO;'
> >
> > The problem is that with RETPOLINE=y, the function text size grows from
> > 5k to 7k, because for each of the 160+ retpoline JMPs, GCC (stupidly)
> > reloads the jump table register into a scratch register.
>
> that would be a tiny change, right?
> I'd rather go with that and gate it with 'ifdef CONFIG_FRAME_POINTER'
> Like:
> #ifndef CONFIG_FRAME_POINTER
> #define CONT ({ insn++; goto select_insn; })
> #define CONT_JMP ({ insn++; goto select_insn; })
> #else
> #define CONT ({ insn++; goto *jumptable[insn->code]; })
> #define CONT_JMP ({ insn++; goto *jumptable[insn->code]; })
> #endif
>
> The reason this CONT and CONT_JMP macros are there because a combination
> of different gcc versions together with different cpus make branch predictor
> behave 'unpredictably'.
>
> I've played with CONT and CONT_JMP either both doing direct goto or
> indirect goto and observed quite different performance characteristics
> from the interpreter.
> What you see right now was the best tune I could get from a set of cpus
> I had to play with and compilers. If I did the same tuning today the outcome
> could have been different.
> So I think it's totally fine to use above code. I think some cpus may actually
> see performance gains with certain versions of gcc.
> The retpoline text increase is unfortunate but when retpoline is on
> other security knobs should be on too. In particular CONFIG_BPF_JIT_ALWAYS_ON
> should be on as well. Which will remove interpreter from .text completely.
This would actually be contingent on RETPOLINE, not FRAME_POINTER.
(FRAME_POINTER was the other issue with the "optimize" attribute, which
we're reverting so it'll no longer be a problem.)
So if you're not concerned about the retpoline text growth, it could be
as simple as:
#define CONT ({ insn++; goto *jumptable[insn->code]; })
#define CONT_JMP ({ insn++; goto *jumptable[insn->code]; })
Or, if you wanted to avoid the text growth, it could be:
#ifdef CONFIG_RETPOLINE
/*
* Avoid a 40% increase in function text size by getting GCC to generate a
* single retpoline jump instead of 160+.
*/
#define CONT ({ insn++; goto select_insn; })
#define CONT_JMP ({ insn++; goto select_insn; })
select_insn:
goto *jumptable[insn->code];
#else /* !CONFIG_RETPOLINE */
#define CONT ({ insn++; goto *jumptable[insn->code]; })
#define CONT_JMP ({ insn++; goto *jumptable[insn->code]; })
#endif /* CONFIG_RETPOLINE */
But since this is legacy path, I think the first one is much nicer.
Also, JMP_TAIL_CALL has a "goto select_insn", is it ok to convert that
to CONT?
--
Josh
[PATCH -next] drm/amd/display: Fix unsigned comparison to zero
Fixes coccicheck warning:
drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c:1398:60-61:
WARNING: Unsigned expression compared with zero: j >= 0
Fixes: 238387774232 ("drm/amd/display: fix rn soc bb update")
Reported-by: Hulk Robot
Signed-off-by: Zou Wei
---
drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
index ceaf70a..419cdde 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
@@ -1384,7 +1384,8 @@ static void update_bw_bounding_box(struct dc *dc, struct
clk_bw_params *bw_param
struct dcn21_resource_pool *pool = TO_DCN21_RES_POOL(dc->res_pool);
struct clk_limit_table *clk_table = _params->clk_table;
struct _vcs_dpi_voltage_scaling_st clock_limits[DC__VOLTAGE_STATES];
- unsigned int i, j, closest_clk_lvl;
+ unsigned int i, closest_clk_lvl;
+ int j;
// Default clock levels are used for diags, which may lead to
overclocking.
if (!IS_DIAG_DC(dc->ctx->dce_environment)) {
--
2.6.2
Re: [GIT PULL] Please pull proc and exec work for 5.7-rc1
On Wed, Apr 29, 2020 at 8:41 PM Jann Horn wrote: > > | So a ptrace() user (or [...] wouldn't even see the impossible EAGAIN error. > > So I assumed you explicitly wanted ptrace() to restart, too. I was > just pointing out that that didn't make sense to me. I'm actually ok with the restart option, simply because I continue to maintain that the program is buggy. "Anything goes". To not be buggy, the program needs to install a SIGCHLD handler so that it can reap its (pseudo-)children. At which point it doesn't actually make any difference whether we fix the kernel or not, because then the non-buggy program will just work - even with a non-modified kernel. Honestly, the main argument for the kernel doing anything different at all is that from a user-mode perspective, silently hanging in the kernel waiting for something to happen is likely the least easy to debug. But if you do a return to user space - even if it's to just rinse and repeat - it's at least not "silent" any more, even if the main noise it makes is just to waste 100% CPU time. At least that's a big hint to somebody to take a look. But yes, we can make ptrace() - and _only_ ptrace() - then not repeat, and return a new error code that it has never returned before. Like EAGAIN. Mainly because in that case we're only breaking semantics of something that was already broken - unlike "write()", which has perfectly well-defined semantics and wasn't broken. Linus
Re: [PATCH v29 00/20] Intel SGX foundations
On Wed, Apr 29, 2020 at 05:27:48PM +0200, Jethro Beekman wrote: > On 2020-04-21 23:52, Jarkko Sakkinen wrote: > > Intel(R) SGX is a set of CPU instructions that can be used by applications > > to set aside private regions of code and data. The code outside the enclave > > is disallowed to access the memory inside the enclave by the CPU access > > control. > > > > There is a new hardware unit in the processor called Memory Encryption > > Engine (MEE) starting from the Skylake microacrhitecture. BIOS can define > > one or many MEE regions that can hold enclave data by configuring them with > > PRMRR registers. > > > > The MEE automatically encrypts the data leaving the processor package to > > the MEE regions. The data is encrypted using a random key whose life-time > > is exactly one power cycle. > > > > The current implementation requires that the firmware sets > > IA32_SGXLEPUBKEYHASH* MSRs as writable so that ultimately the kernel can > > decide what enclaves it wants run. The implementation does not create > > any bottlenecks to support read-only MSRs later on. > > > > You can tell if your CPU supports SGX by looking into /proc/cpuinfo: > > > > cat /proc/cpuinfo | grep sgx > > Let's merge this. So can I tag reviewed-by's? /Jarkko
Re: [GIT PULL] Please pull proc and exec work for 5.7-rc1
On Thu, Apr 30, 2020 at 5:26 AM Linus Torvalds wrote: > On Wed, Apr 29, 2020 at 8:00 PM Jann Horn wrote: > > > > But if we go with Bernd's approach together with your restart > > suggestion, > > So repeat after me: Bernd's approach _without_ the restart is unacceptable. > > It's unacceptable because it breaks things that currently work, and > returns EAGAIN in situations where that is simple not a valid error > code. Sure, makes sense to me. I'm not eager to start randomly throwing EAGAIN where it couldn't happen before either (and I initially missed that Bernd's patch did that for procfs files, too). > That bug has nothing to do with ptrace(). It's literally a "write()" > to a file in /proc. > > What is so hard to get about this basic thing? You said: | So a ptrace() user (or [...] wouldn't even see the impossible EAGAIN error. So I assumed you explicitly wanted ptrace() to restart, too. I was just pointing out that that didn't make sense to me.
Re:Re: [PATCH] clk/meson: fixes memleak issue in init err branch
From: Martin Blumenstingl Date: 2020-04-30 01:43:55 To: Jerome Brunet Cc: Bernard Zhao ,Neil Armstrong ,Stephen Boyd ,Kevin Hilman ,linux-amlo...@lists.infradead.org,linux-...@vger.kernel.org,linux-kernel@vger.kernel.org,opensource.ker...@vivo.com Subject: Re: [PATCH] clk/meson: fixes memleak issue in init err branch>Hi Jerome, > >On Wed, Apr 29, 2020 at 2:37 PM Jerome Brunet wrote: >> >> >> On Wed 29 Apr 2020 at 05:14, Bernard Zhao wrote: >> >> > In common init function, when run into err branch, we didn`t >> > use kfree to release kzmalloc area, this may bring in memleak >> >> Thx for reporting this Bernard. >> I'm not a fan of adding kfree everywhere. I'd much prefer a label and >> clear error exit path. >> >> That being said, the allocation is probably not the only thing that >> needs to be undone in case of error. I guess this is due to conversion >> to CLK_OF_DECLARE_DRIVER() which forced to drop all the devm_ >> This was done because the clock controller was required early in the >> boot sequence. >> >> There is 2 paths to properly solve this: >> 1) Old school: manually undo everything with every error exit condition >>Doable but probably a bit messy >> 2) Convert back the driver to a real platform driver and use devm_. >>We would still need the controller to register early but I wonder if >>we could use the same method as drivers/clk/mediatek/clk-mt2701.c and >>use arch_initcall() ? >> >> Martin, you did the initial conversion, what do you think of option 2 ? >I tried it with the attached patch >unfortunately my "m8b_clkc_test_probe" is still run too late > >> Would it still answer the problem you were trying to solve back then ? >I'm afraid it does not: >- the resets are needed early for SMP initialization >- the clocks are needed even earlier for timer registration (we have >both, the ARM TWD timer and some Amlogic custom timer. both have clock >inputs) > >> One added benefit of option 2 is we could drop CLK_OF_DECLARE_DRIVER(). >> We could even do the same in for the other SoCs, which I suppose would >> avoid a fair amount of probe deferral. >it would be great, indeed >but this will only work once timer initialization and SMP boot can >happen at a later stage > >If the clock controller registration fails the board won't boot. Yes, >cleaning up memory is good, but in this specific case it will add a >couple of extra CPU cycles before the kernel is dead >So, if we want to ignore that fact then I agree with your first option >(undoing things the "old school" way). > Hi I am not sure whether my understanding is correct. I feels that the failure of our module can not block the entire kernel from starting. Maybe we should throw an exception, clear the status, as "old way", and continue to execute the kernel. And if our module requires that the kernel cannot continue to run when the exception occurs, then we do not need to return in the error branch, also we do not need to kfree, just BUG_ON(). Regards, Bernard >Martin
Re: rcu_barrier() + membarrier() + scheduler deadlock?
> On Apr 29, 2020, at 11:22 PM, Paul E. McKenney wrote: > > On Wed, Apr 29, 2020 at 11:00:58PM -0400, Qian Cai wrote: >> Doing some fuzzers on many CPUs triggers a deadlock really quickly. I can >> see that there were several tasks had been stuck for a while, >> >> CPUA: >> slab_caches_to_rcu_destroy_workfn() >> rcu_barrier() >> wait_for_completion() >> >> CPUB: >> sched_setaffinity() >> __set_cpus_allowed_ptr() >> stop_one_cpu() >> >> CPUC: >> __x64_sys_membarrier >> synchronize_rcu() >> __wait_rcu_gp() >> wait_for_completion() >> >> Lockdep did not flag anything useful at all. Any clue? > > CPUA and CPUC are most likely both waiting for a grace period to complete. > > CPUA will be blocking CPU hotplug (get_online_cpus()) in case that > matters. I am not seeing any obvious wait for an RCU grace period > in CPUB. > > But which task's affinity is being set? That of the grace-period kthread? I am not sure. One of task's sched_setaffinity() can’t die, so here is the log from that task. # grep setaffinity rootfs/tmp/trinity-child20.log [child20:131] [313] sched_setaffinity(pid=0, len=0x13939393, user_mask_ptr=0x7fa3d7c37000) = -1 (Bad address) [child20:131] [574] sched_setaffinity(pid=196, len=0xf000, user_mask_ptr=0x8) = -1 (Bad address) [child20:131] [589] sched_setaffinity(pid=0, len=100, user_mask_ptr=0x1) = -1 (Bad address) [child20:131] [615] sched_setaffinity(pid=0, len=1, user_mask_ptr=0x8) = -1 (Bad address) [child20:589] [17] sched_setaffinity(pid=0, len=8, user_mask_ptr=0x7fa3d7c39000) = -1 (Invalid argument) [child20:589] [346] sched_setaffinity(pid=0, len=167, user_mask_ptr=0x1) = -1 (Bad address) [child20:926] [44] sched_setaffinity(pid=0, len=4096, user_mask_ptr=0x7fa3d7c3c000) = -1 (Invalid argument) [child20:926] [124] sched_setaffinity(pid=0, len=1, user_mask_ptr=0x7fa3d7c38000) = 0 [child20:1007] [217] sched_setaffinity(pid=0, len=4096, user_mask_ptr=0x7fa3d7c38000) = 0 [child20:1007] [235] sched_setaffinity(pid=0, len=8, user_mask_ptr=0x0) = -1 (Bad address) [child20:1122] [63] sched_setaffinity(pid=0, len=777, user_mask_ptr=0x4) = -1 (Bad address) [child20:1122] [509] sched_setaffinity(pid=0, len=4096, user_mask_ptr=0x7fa3d803c000) = 0 [child20:1122] [902] sched_setaffinity(pid=1750, len=1, user_mask_ptr=0x8) = -1 (Bad address) [child20:1824] [57] sched_setaffinity(pid=1723, len=0x1fa56, user_mask_ptr=0x1) = -1 (Bad address) [child20:1853] [92] sched_setaffinity(pid=1741, len=4096, user_mask_ptr=0x7fa3d843c000) = 0 [child20:2058] [114] sched_setaffinity(pid=2019, len=23, user_mask_ptr=0x8) = -1 (Bad address) > If not, are there rcuo kthreads present? Either way, preventing any of I did not catch that. I might just be that workqueue was unable to handle fuzzers loads on many CPUs. I had another 32-CPU server stuck in flush_work(). Not sure if it is related. > RCU's kthreads from running could block potentially both CPUA and CPUC. > Though in the case of the grace-period kthread, I would expect to see > an RCU CPU stall warning. > > Could you please share your .config? https://raw.githubusercontent.com/cailca/linux-mm/master/x86.config [53294.651754][T149877] futex_wake_op: trinity-c25 tries to shift op by -17; fix this program [53323.947396][T150988] futex_wake_op: trinity-c6 tries to shift op by -5; fix this program [53458.295837][ T215] INFO: task kworker/u64:0:8 blocked for more than 122 seconds. [53458.304063][ T215] Tainted: G O L 5.7.0-rc3-next-20200429 #1 [53458.311568][ T215] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [53458.320190][ T215] kworker/u64:0 D10584 8 2 0x90004000 [53458.326668][ T215] Workqueue: netns cleanup_net [53458.331330][ T215] Call Trace: [53458.334510][ T215] __schedule+0x47b/0xa50 [53458.338765][ T215] ? wait_for_completion+0x80/0x120 [53458.343920][ T215] schedule+0x59/0xd0 [53458.348013][ T215] schedule_timeout+0x10a/0x150 [53458.352762][ T215] ? wait_for_completion+0x80/0x120 [53458.357881][ T215] ? _raw_spin_unlock_irq+0x30/0x40 [53458.362997][ T215] ? trace_hardirqs_on+0x22/0x100 [53458.367948][ T215] ? wait_for_completion+0x80/0x120 [53458.373195][ T215] wait_for_completion+0xb4/0x120 [53458.378149][ T215] __flush_work+0x3ff/0x6e0 [53458.382586][ T215] ? init_pwq+0x210/0x210 [53458.386840][ T215] flush_work+0x20/0x30 [53458.390891][ T215] rollback_registered_many+0x3d6/0x950 [53458.396438][ T215] ? mark_held_locks+0x4e/0x80 [53458.401339][ T215] unregister_netdevice_many+0x5d/0x200 [53458.406816][ T215] default_device_exit_batch+0x213/0x240 [53458.412348][ T215] ? do_wait_intr_irq+0xe0/0xe0 [53458.417225][ T215] ? dev_change_net_namespace+0x6d0/0x6d0 [53458.423000][ T215] ops_exit_list+0xa2/0xc0 [53458.427367][ T215] c
Re: [PATCH v7 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver
On Tue, Apr 28, 2020 at 12:05:08PM +0200, Daniel Vetter wrote:
> On Fri, Apr 24, 2020 at 08:12:04PM +0800, Nicolas Boichat wrote:
> > On Fri, Apr 24, 2020 at 2:51 PM Xin Ji wrote:
> > >
> > > On Thu, Apr 23, 2020 at 07:55:15PM +0800, Nicolas Boichat wrote:
> > > > Hi,
> > > >
> > > > Just commenting on the mode_fixup function that was added in v7.
> > > >
> > > [snip]
> > > > > + /*
> > > > > +* once illegal timing detected, use default HFP, HSYNC, HBP
> > > > > +*/
> > > > > + if (hblanking < HBLANKING_MIN || (hfp < HP_MIN && hbp <
> > > > > HP_MIN)) {
> > > >
> > > > should this be adj_hblanking/adj_hfp/adj_hbp?
> > > NO, need check original HFP and HBP, if they are not legal, driver need
> > > set default value to adj_hsync, adj_hfp, adj_hbp.
> > > >
> > > > > + adj_hsync = SYNC_LEN_DEF;
> > > > > + adj_hfp = HFP_HBP_DEF;
> > > > > + adj_hbp = HFP_HBP_DEF;
> > > > > + vref = adj->clock * 1000 / (adj->htotal *
> > > > > adj->vtotal);
> > > > > + if (hblanking < HBLANKING_MIN) {
> > > > > + delta_adj = HBLANKING_MIN - hblanking;
> > > > > + adj_clock = vref * delta_adj * adj->vtotal;
> > > > > + adj->clock += DIV_ROUND_UP(adj_clock, 1000);
> > > > > + } else {
> > > > > + delta_adj = hblanking - HBLANKING_MIN;
> > > > > + adj_clock = vref * delta_adj * adj->vtotal;
> > > > > + adj->clock -= DIV_ROUND_UP(adj_clock, 1000);
> > > > > + }
> > > > > +
> > > > > + DRM_WARN("illegal hblanking timing, use default.\n");
> > > > > + DRM_WARN("hfp(%d),hbp(%d),hsync(%d).\n", hfp, hbp,
> > > > > hsync);
> > > >
> > > > How likely is it that this mode is going to work? Can you just return
> > > > false here to reject the mode?
> > > We want to set the default minimal Hblancking value, then it may display,
> > > otherwise. If we just return false, there is no display for sure.
> >
> > Right, understand your argument. I'm pondering if it's not just better
> > to reject the mode rather than trying a timing that is definitely
> > quite different from what the monitor was asking for. No super strong
> > opinion, I'll let other people on the list weigh in.
>
> Yeah mode_fixup is supposed to be used to adjust the mode in intermediate
> stages (e.g. if you go from progressive to interlaced only at the end of
> your pipeline or something like that). It's not meant for adjusting the
> mode yout actually put out through a hdmi or dp connector. For fixed
> panels adjusting modes to fit the panel is also fairly common, but not for
> external outputs.
>
> Since this is a DP bridge I'd say no adjusting, just reject what doesn't
> fit.
We have found some panel which HBP less than 8, if we reject to adjust
video timing, then there is no display. The customer does not accept it,
they push us to fix it, the only resolve way is to adjust timing.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
Re: rcu_barrier() + membarrier() + scheduler deadlock?
On Wed, Apr 29, 2020 at 08:22:38PM -0700, Paul E. McKenney wrote: > On Wed, Apr 29, 2020 at 11:00:58PM -0400, Qian Cai wrote: > > Doing some fuzzers on many CPUs triggers a deadlock really quickly. I can > > see that there were several tasks had been stuck for a while, > > > > CPUA: > > slab_caches_to_rcu_destroy_workfn() > > rcu_barrier() > > wait_for_completion() > > > > CPUB: > > sched_setaffinity() > > __set_cpus_allowed_ptr() > > stop_one_cpu() > > > > CPUC: > > __x64_sys_membarrier > > synchronize_rcu() > > __wait_rcu_gp() > > wait_for_completion() > > > > Lockdep did not flag anything useful at all. Any clue? > > CPUA and CPUC are most likely both waiting for a grace period to complete. > > CPUA will be blocking CPU hotplug (get_online_cpus()) in case that > matters. I am not seeing any obvious wait for an RCU grace period > in CPUB. > > But which task's affinity is being set? That of the grace-period kthread? > If not, are there rcuo kthreads present? Either way, preventing any of > RCU's kthreads from running could block potentially both CPUA and CPUC. > Though in the case of the grace-period kthread, I would expect to see > an RCU CPU stall warning. > > Could you please share your .config? And there are a number of tasks below marked "can't die". So maybe something more fundamental is stuck? Thanx, Paul > > [52885.040113][T150406] futex_wake_op: trinity-c9 tries to shift op by > > -1189; fix this program > > [52890.366916][T150196] futex_wake_op: trinity-c3 tries to shift op by -1; > > fix this program > > [52896.369779][T151054] futex_wake_op: trinity-c23 tries to shift op by > > 710; fix this program > > [52901.770688][ T310] INFO: task kworker/36:2:142207 blocked for more than > > 122 seconds. > > [52901.811471][ T310] Tainted: G L > > 5.7.0-rc3-next-20200429 #2 > > [52901.849148][ T310] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > > disables this message. > > [52901.889803][ T310] kworker/36:2D29104 142207 2 0x90004000 > > [52901.919461][ T310] Workqueue: events slab_caches_to_rcu_destroy_workfn > > [52901.950935][ T310] Call Trace: > > [52901.965369][ T310] __schedule+0x77e/0x1070 > > [52901.986211][ T310] ? __sched_text_start+0x8/0x8 > > [52902.008267][ T310] ? trace_hardirqs_on+0x3a/0x160 > > [52902.031764][ T310] schedule+0x95/0x160 > > [52902.050729][ T310] schedule_timeout+0x47c/0x6a0 > > [52902.072897][ T310] ? print_irqtrace_events+0x110/0x110 > > [52902.098316][ T310] ? usleep_range+0x100/0x100 > > [52902.119664][ T310] ? mark_held_locks+0x86/0xb0 > > [52902.141397][ T310] ? _raw_spin_unlock_irq+0x27/0x40 > > [52902.165326][ T310] ? _raw_spin_unlock_irq+0x27/0x40 > > [52902.189622][ T310] ? lockdep_hardirqs_on+0x1b0/0x2c0 > > [52902.213641][ T310] ? wait_for_completion+0x116/0x1a0 > > [52902.238757][ T310] ? trace_hardirqs_on+0x3a/0x160 > > [52902.261648][ T310] wait_for_completion+0x11e/0x1a0 > > [52902.285516][ T310] ? wait_for_completion_interruptible+0x220/0x220 > > [52902.316342][ T310] ? rcu_read_lock_held+0xc0/0xc0 > > [52902.340298][ T310] rcu_barrier+0x2c5/0x440 > > [52902.361736][ T310] slab_caches_to_rcu_destroy_workfn+0x95/0xe0 > > [52902.391109][ T310] process_one_work+0x57e/0xb90 > > [52902.413244][ T310] ? pwq_dec_nr_in_flight+0x170/0x170 > > [52902.437957][ T310] ? worker_thread+0x14b/0x5b0 > > [52902.460357][ T310] worker_thread+0x63/0x5b0 > > [52902.481267][ T310] ? process_one_work+0xb90/0xb90 > > [52902.504818][ T310] kthread+0x1f7/0x220 > > [52902.523542][ T310] ? kthread_create_worker_on_cpu+0xc0/0xc0 > > [52902.550801][ T310] ret_from_fork+0x3a/0x50 > > [52902.560427][T151328] futex_wake_op: trinity-c10 tries to shift op by -1; > > fix this program > > [52902.571250][ T310] INFO: task trinity-c18:145344 can't die for more > > than 123 seconds. > > [52902.648554][ T310] trinity-c18 R running task26944 145344 > > 74932 0x10004004 > > [52902.700179][ T310] Call Trace: > > [52902.715039][ T310] __schedule+0x77e/0x1070 > > [52902.735531][ T310] ? __sched_text_start+0x8/0x8 > > [52902.757922][ T310] ? do_syscall_64+0x28d/0xaf0 > > [52902.779731][ T310] ? do_syscall_64+0x28d/0xaf0 > > [52902.802215][ T310] schedule+0x95/0x160 > > [52902.821375][ T310] do_syscall_64+0x23e/0xaf0 > > [52902.843517][ T310] ? perf_call_bpf_enter+0x1a0/0x1a0 > > [52902.87
[RFC PATCH] fs: Move @f_count to different cacheline with @f_mode
From: Yuqi Jin
__fget_files does check the @f_mode with mask variable and will do some
atomic operations on @f_count while both are on the same cacheline.
Many CPU cores do file access and it will cause much conflicts on @f_count.
If we could make the two members into different cachelines, it shall relax
the siutations.
We have tested this on ARM64 and X86, the result is as follows:
Syscall of unixbench has been run on Huawei Kunpeng920 with this patch:
24 x System Call Overhead 1
System Call Overhead3160841.4 lps (10.0 s, 1 samples)
System Benchmarks Partial Index BASELINE RESULTINDEX
System Call Overhead 15000.03160841.4 2107.2
System Benchmarks Index Score (Partial Only) 2107.2
Without this patch:
24 x System Call Overhead 1
System Call Overhead456.0 lps (10.0 s, 1 samples)
System Benchmarks Partial Index BASELINE RESULTINDEX
System Call Overhead 15000.0456.0 1481.6
System Benchmarks Index Score (Partial Only) 1481.6
And on Intel 6248 platform with this patch:
40 CPUs in system; running 24 parallel copies of tests
System Call Overhead4288509.1 lps (10.0 s, 1 samples)
System Benchmarks Partial Index BASELINE RESULTINDEX
System Call Overhead 15000.04288509.1 2859.0
System Benchmarks Index Score (Partial Only) 2859.0
Without this patch:
40 CPUs in system; running 24 parallel copies of tests
System Call Overhead3666313.0 lps (10.0 s, 1 samples)
System Benchmarks Partial Index BASELINE RESULTINDEX
System Call Overhead 15000.03666313.0 2444.2
System Benchmarks Index Score (Partial Only) 2444.2
Cc: Alexander Viro
Signed-off-by: Yuqi Jin
Signed-off-by: Shaokun Zhang
---
include/linux/fs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 4f6f59b4f22a..90e76283f0fd 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -953,7 +953,6 @@ struct file {
*/
spinlock_t f_lock;
enum rw_hintf_write_hint;
- atomic_long_t f_count;
unsigned intf_flags;
fmode_t f_mode;
struct mutexf_pos_lock;
@@ -976,6 +975,7 @@ struct file {
#endif /* #ifdef CONFIG_EPOLL */
struct address_space*f_mapping;
errseq_tf_wb_err;
+ atomic_long_t f_count;
} __randomize_layout
__attribute__((aligned(4))); /* lest something weird decides that 2 is OK */
--
2.7.4
Re: How to upload fpga firmware
On Mon, Apr 27, 2020 at 08:44:33AM +0200, Sascha Hauer wrote: > On Fri, Apr 24, 2020 at 08:59:49PM -0700, Moritz Fischer wrote: > > Hi Sascha, > > > > On Thu, Apr 23, 2020 at 08:23:31AM +0200, Sascha Hauer wrote: > > > Hi Moritz, > > > > > > On Wed, Apr 22, 2020 at 06:36:48PM -0700, Moritz Fischer wrote: > > > > Hi Sascha, > > > > > > > > On Wed, Apr 22, 2020 at 01:44:32PM +0200, Sascha Hauer wrote: > > > > > Hi, > > > > > > > > > > I wonder what can be done with the mainline state of drivers/fpga/. > > > > > The > > > > > entry to the framework seems to be fpga_mgr_load(). The only user of > > > > > this function is fpga_region_program_fpga(). This in turn is only > > > > > called > > > > > in response of applying a device tree overlay. A device tree overlay > > > > > is > > > > > applied with of_overlay_fdt_apply() which has no users in the Kernel. > > > > > > > > Yes. It is waiting for dt_overlays one way or another. I personally > > > > don't currently have the bandwidth to work actively on this. > > > > > > > > > My current task is to load a firmware to a FPGA. The code all seems to > > > > > be there in the Kernel, it only lacks a way to trigger it. I am not > > > > > very > > > > > interested in device tree overlays since the FPGA appears as a PCI > > > > > device (although applying a dtbo could enable the PCIe controller > > > > > device > > > > > tree node). Is there some mainline way to upload FPGA firmware? At the > > > > > moment we are using the attached patch to trigger loading the firmware > > > > > from userspace. Would something like this be acceptable for mainline? > > > > > > > > We've looked into this sort of patches over the years and never came to > > > > a general interface that really works. > > > > > > > > The OPAE folks (and other users I know of) usually use FPGA Manager with > > > > a higher layer on top of it that moves the bitstream into the kernel via > > > > an ioctl(). > > > > > > > > One concept I had toyed with mentally, but haven't really gotten around > > > > to implement is a 'discoverable' region, that would deal with the > > > > necessary re-enumeration via a callback and have a sysfs interface > > > > similar to what the patch below has. > > > > This would essentially cover use-cases where you have a discoverable > > > > device implemented in FPGA logic, such as say an FPGA hanging off of > > > > PCIe bus that can get loaded over USB, a CPLD or some other side-band > > > > mechanism. After loading the image you'd have to rescan the PCIe bus - > > > > which - imho is the kernel's job. > > > > > > > > What I really wanna avoid is creating another /dev/fpga0 / /dev/xdevcfg > > > > that completely leaves the kernel in the dark about the fact that it > > > > reconfigures a bit of hardware hanging off the bus. > > > > > > Yes, makes sense. While this would suffice my needs at the moment it > > > really sounds like a dead end. > > > > > > > > > > > In my ideal world you'd create a pci driver that binds to your device, > > > > and creates mfd style subdevices for whatever you'd want your design to > > > > do. One of these devices would be an FPGA and a FPGA region attached to > > > > that FPGA manager. Your top level driver would co-ordinate the fact that > > > > you are re-programming parts of the FPGA and create / destroy devices as > > > > needed for the hardware contained in the bitstream. > > > > > > In my case there is no pci device visible before loading the firmware, > > > so creating a pci driver is not an option. Maybe pci host controllers > > > could register themselves as fpga-bridges. With this we could put the > > > pci host controller (or the pci device, AFAIK there is a PCI device tree > > > binding) where the fpga is connected into the fpga-bridges phandles list > > > of the fpga-region. > > > > Can you talk a bit more about the system you're working with? Is there > > some sort of sideband mechanism to load the image? What exposes the > > image loading capaibility? A CPLD, an ASIC, USB device, JTAG? > > We have two systems. One uploads the FPGA firmware via SPI passive > serial mode (compatible fpga-arria10-passive-serial). The other system > has a ftdi FT232H USB/serial converter chip working in synchronous FIFO > mode, connected to the FPGA via a CPLD. The series from Anatolij Gustchin > here https://patchwork.kernel.org/cover/10824743/ would have been useful > for us, although of course our CPLD has a different protocol. On this > system we currently ended up with a small custom driver which bypasses > FPGA manager and only uploads the firmware at USB connect time. Yeah this seems imho the only legit use-case for a something like the sysfs entry for the fpga-region. That being said once we add that, it's going to become ABI and everyone is gonna use that instead of implementing a proper driver using FPGA Regions to deal with re-enumeration. We don't really have a good way of modelling systems where the bus is 100% discoverable
Re: [GIT PULL] Please pull proc and exec work for 5.7-rc1
On Wed, Apr 29, 2020 at 8:00 PM Jann Horn wrote: > > But if we go with Bernd's approach together with your restart > suggestion, So repeat after me: Bernd's approach _without_ the restart is unacceptable. It's unacceptable because it breaks things that currently work, and returns EAGAIN in situations where that is simple not a valid error code. His original patch also happens to be unacceptable because it's an unmaintainable mess, but that's independent of the bug it introduced. That bug has nothing to do with ptrace(). It's literally a "write()" to a file in /proc. What is so hard to get about this basic thing? > then simply doing PTRACE_ATTACH on two threads A and B > would be enough to livelock, right? The same case that just causes a recursive wait. Yes. No worse off than we were. And the fact is, *THAT* case looks truly trivial to work around. Just make the ptrace() code - but not the fs/proc/base.c code - do something like if (lock_exec_creds(tsk)) return -EINTR; and now ptrace() doesn't repeat (simply because it doesn't return that ERESTARTNOINTR. It would go through that "return through signal handling code" in the kernel, but it wouldn't actually retry the system call). But I'm getting less and less interested in trying to "fix" this problem, when people don't seem to realize that the important case is to not break _good_ programs, and the pointless buggy garbage test-case is entirely uninteresting. It's buggy user code. If it causes a wait or a livelock, nobody sane should care in the least. Fix the bug in user space. Introducing new bugs in the kernel where they didn't exist before - in order to try to work around buggy user-space that has never ever worked - is not acceptable. Linus
Re: [PATCH v6] MIPS: Loongson: Add DMA support for LS7A
于 2020年4月30日 GMT+08:00 上午10:31:07, Tiezhu Yang 写到:
>In the current market, the most used bridge chip on the Loongson
>platform are RS780E and LS7A, the RS780E bridge chip is already
>supported by the mainline kernel.
>
>In order to use the default implementation of __phys_to_dma() and
>__dma_to_phys() in dma-direct.h, remove CONFIG_ARCH_HAS_PHYS_TO_DMA
>and then set the bus's DMA limit to 36 bit for RS780E to maintain
>downward compatibility.
>
>Signed-off-by: Tiezhu Yang
>---
>
>Hi Christoph and Jiaxun,
>
>Thank you very much for your suggestions.
I'm probably going to refine this before we implement full devicetree boot,
but that's in far future.
LGTM to me for now.
Thanks.
Reviewed-by: Jiaxun Yang
>
>v5:
> - use the default implementation of __phys_to_dma()
>and __dma_to_phys() in dma-direct.h
>
>v6:
> - make loongson_dma_config() static
> - put ls7a things before rs780 things
>
> arch/mips/Kconfig | 1 -
> arch/mips/include/asm/mach-loongson64/boot_param.h | 5 +
> arch/mips/loongson64/dma.c | 22 +++---
> arch/mips/loongson64/env.c | 2 ++
> 4 files changed, 18 insertions(+), 12 deletions(-)
>
>diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
>index 9f15539..12b6bdb 100644
>--- a/arch/mips/Kconfig
>+++ b/arch/mips/Kconfig
>@@ -1454,7 +1454,6 @@ choice
> config CPU_LOONGSON64
> bool "Loongson 64-bit CPU"
> depends on SYS_HAS_CPU_LOONGSON64
>- select ARCH_HAS_PHYS_TO_DMA
> select CPU_MIPSR2
> select CPU_HAS_PREFETCH
> select CPU_SUPPORTS_64BIT_KERNEL
>diff --git a/arch/mips/include/asm/mach-loongson64/boot_param.h
>b/arch/mips/include/asm/mach-loongson64/boot_param.h
>index f082d87..0c07a96 100644
>--- a/arch/mips/include/asm/mach-loongson64/boot_param.h
>+++ b/arch/mips/include/asm/mach-loongson64/boot_param.h
>@@ -197,6 +197,7 @@ enum loongson_bridge_type {
> RS780E = 2
> };
>
>+struct pci_dev;
> struct loongson_system_configuration {
> u32 nr_cpus;
> u32 nr_nodes;
>@@ -221,9 +222,13 @@ struct loongson_system_configuration {
> u32 nr_sensors;
> struct sensor_device sensors[MAX_SENSORS];
> u64 workarounds;
>+ void (*dma_config)(struct pci_dev *pdev);
> };
>
> extern struct efi_memory_map_loongson *loongson_memmap;
> extern struct loongson_system_configuration loongson_sysconf;
>
>+extern void ls7a_dma_config(struct pci_dev *pdev);
>+extern void rs780e_dma_config(struct pci_dev *pdev);
>+
> #endif
>diff --git a/arch/mips/loongson64/dma.c b/arch/mips/loongson64/dma.c
>index 5e86635..ef40b0d 100644
>--- a/arch/mips/loongson64/dma.c
>+++ b/arch/mips/loongson64/dma.c
>@@ -1,24 +1,24 @@
> // SPDX-License-Identifier: GPL-2.0
>-#include
>+#include
> #include
> #include
>
>-dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr)
>+void ls7a_dma_config(struct pci_dev *pdev)
> {
>- /* We extract 2bit node id (bit 44~47, only bit 44~45 used now) from
>- * Loongson-3's 48bit address space and embed it into 40bit */
>- long nid = (paddr >> 44) & 0x3;
>- return ((nid << 44) ^ paddr) | (nid << 37);
> }
>
>-phys_addr_t __dma_to_phys(struct device *dev, dma_addr_t daddr)
>+void rs780e_dma_config(struct pci_dev *pdev)
> {
>- /* We extract 2bit node id (bit 44~47, only bit 44~45 used now) from
>- * Loongson-3's 48bit address space and embed it into 40bit */
>- long nid = (daddr >> 37) & 0x3;
>- return ((nid << 37) ^ daddr) | (nid << 44);
>+ pdev->dev.bus_dma_limit = DMA_BIT_MASK(36);
> }
>
>+static void loongson_dma_config(struct pci_dev *pdev)
>+{
>+ loongson_sysconf.dma_config(pdev);
>+}
>+
>+DECLARE_PCI_FIXUP_EARLY(PCI_ANY_ID, PCI_ANY_ID, loongson_dma_config);
>+
> void __init plat_swiotlb_setup(void)
> {
> swiotlb_init(1);
>diff --git a/arch/mips/loongson64/env.c b/arch/mips/loongson64/env.c
>index 71f4aaf..496f401 100644
>--- a/arch/mips/loongson64/env.c
>+++ b/arch/mips/loongson64/env.c
>@@ -192,8 +192,10 @@ void __init prom_init_env(void)
> if (vendor == PCI_VENDOR_ID_LOONGSON && device == 0x7a00) {
> pr_info("The bridge chip is LS7A\n");
> loongson_sysconf.bridgetype = LS7A;
>+ loongson_sysconf.dma_config = ls7a_dma_config;
> } else {
> pr_info("The bridge chip is RS780E or SR5690\n");
> loongson_sysconf.bridgetype = RS780E;
>+ loongson_sysconf.dma_config = rs780e_dma_config;
> }
> }
--
Jiaxun Yang
Re: [LTP] [PATCH v4 3/3] syscalls/pipe2_03: Add new test for pipe2 O_DIRECT flag
Hi Linus On Sun, Apr 26, 2020 at 4:59 AM Li Wang wrote: From kernel code seems you are right. The pipe indeed takes use of PAGE_SIZE(ppc64le: 64kB) to split the writes data in the packetized mode (marked by O_DIRECT). But in the manual page, O_DIRECT indicates us the PIPE_BUF is the correct atomic unit. The manual is correct. PIPE_BUF is the size we _guarantee_ can be used atomically. The fact that in practice we do have bigger buffers on some platforms is an implementation detail. Yes, that implementation detail can be visible, but basically any test code that tries to test for "what if we use a bigger bug that PIPE_BUF" is buggy. It's simply not guaranteed to work any more. O_DIRECT is kind of immaterial, except it's just one of those things where the atomic size is slightly more visible. But basically, packetized pipes with bigger packets than PIPE_BUF is random behavior. It may work. It may not. Thanks for your explanation. I am more curious about the user scene of this flag. @Li, so how to design this test? In this test, we don't have complex scene to test this automic unit. Best Regards Yang Xu Linus
Re: rcu_barrier() + membarrier() + scheduler deadlock?
On Wed, Apr 29, 2020 at 11:00:58PM -0400, Qian Cai wrote: > Doing some fuzzers on many CPUs triggers a deadlock really quickly. I can > see that there were several tasks had been stuck for a while, > > CPUA: > slab_caches_to_rcu_destroy_workfn() > rcu_barrier() > wait_for_completion() > > CPUB: > sched_setaffinity() > __set_cpus_allowed_ptr() > stop_one_cpu() > > CPUC: > __x64_sys_membarrier > synchronize_rcu() > __wait_rcu_gp() > wait_for_completion() > > Lockdep did not flag anything useful at all. Any clue? CPUA and CPUC are most likely both waiting for a grace period to complete. CPUA will be blocking CPU hotplug (get_online_cpus()) in case that matters. I am not seeing any obvious wait for an RCU grace period in CPUB. But which task's affinity is being set? That of the grace-period kthread? If not, are there rcuo kthreads present? Either way, preventing any of RCU's kthreads from running could block potentially both CPUA and CPUC. Though in the case of the grace-period kthread, I would expect to see an RCU CPU stall warning. Could you please share your .config? Thanx, Paul > [52885.040113][T150406] futex_wake_op: trinity-c9 tries to shift op by -1189; > fix this program > [52890.366916][T150196] futex_wake_op: trinity-c3 tries to shift op by -1; > fix this program > [52896.369779][T151054] futex_wake_op: trinity-c23 tries to shift op by 710; > fix this program > [52901.770688][ T310] INFO: task kworker/36:2:142207 blocked for more than > 122 seconds. > [52901.811471][ T310] Tainted: G L > 5.7.0-rc3-next-20200429 #2 > [52901.849148][ T310] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > disables this message. > [52901.889803][ T310] kworker/36:2D29104 142207 2 0x90004000 > [52901.919461][ T310] Workqueue: events slab_caches_to_rcu_destroy_workfn > [52901.950935][ T310] Call Trace: > [52901.965369][ T310] __schedule+0x77e/0x1070 > [52901.986211][ T310] ? __sched_text_start+0x8/0x8 > [52902.008267][ T310] ? trace_hardirqs_on+0x3a/0x160 > [52902.031764][ T310] schedule+0x95/0x160 > [52902.050729][ T310] schedule_timeout+0x47c/0x6a0 > [52902.072897][ T310] ? print_irqtrace_events+0x110/0x110 > [52902.098316][ T310] ? usleep_range+0x100/0x100 > [52902.119664][ T310] ? mark_held_locks+0x86/0xb0 > [52902.141397][ T310] ? _raw_spin_unlock_irq+0x27/0x40 > [52902.165326][ T310] ? _raw_spin_unlock_irq+0x27/0x40 > [52902.189622][ T310] ? lockdep_hardirqs_on+0x1b0/0x2c0 > [52902.213641][ T310] ? wait_for_completion+0x116/0x1a0 > [52902.238757][ T310] ? trace_hardirqs_on+0x3a/0x160 > [52902.261648][ T310] wait_for_completion+0x11e/0x1a0 > [52902.285516][ T310] ? wait_for_completion_interruptible+0x220/0x220 > [52902.316342][ T310] ? rcu_read_lock_held+0xc0/0xc0 > [52902.340298][ T310] rcu_barrier+0x2c5/0x440 > [52902.361736][ T310] slab_caches_to_rcu_destroy_workfn+0x95/0xe0 > [52902.391109][ T310] process_one_work+0x57e/0xb90 > [52902.413244][ T310] ? pwq_dec_nr_in_flight+0x170/0x170 > [52902.437957][ T310] ? worker_thread+0x14b/0x5b0 > [52902.460357][ T310] worker_thread+0x63/0x5b0 > [52902.481267][ T310] ? process_one_work+0xb90/0xb90 > [52902.504818][ T310] kthread+0x1f7/0x220 > [52902.523542][ T310] ? kthread_create_worker_on_cpu+0xc0/0xc0 > [52902.550801][ T310] ret_from_fork+0x3a/0x50 > [52902.560427][T151328] futex_wake_op: trinity-c10 tries to shift op by -1; > fix this program > [52902.571250][ T310] INFO: task trinity-c18:145344 can't die for more than > 123 seconds. > [52902.648554][ T310] trinity-c18 R running task26944 145344 74932 > 0x10004004 > [52902.700179][ T310] Call Trace: > [52902.715039][ T310] __schedule+0x77e/0x1070 > [52902.735531][ T310] ? __sched_text_start+0x8/0x8 > [52902.757922][ T310] ? do_syscall_64+0x28d/0xaf0 > [52902.779731][ T310] ? do_syscall_64+0x28d/0xaf0 > [52902.802215][ T310] schedule+0x95/0x160 > [52902.821375][ T310] do_syscall_64+0x23e/0xaf0 > [52902.843517][ T310] ? perf_call_bpf_enter+0x1a0/0x1a0 > [52902.871003][ T310] ? ftrace_syscall_enter+0x4b0/0x4b0 > [52902.896034][ T310] ? syscall_return_slowpath+0x580/0x580 > [52902.922153][ T310] ? entry_SYSCALL_64_after_hwframe+0x3e/0xb3 > [52902.950409][ T310] ? trace_hardirqs_off_caller+0x3a/0x150 > [52902.976721][ T310] ? trace_hardirqs_off_thunk+0x1a/0x1c > [52903.002409][ T310] entry_SYSCALL_64_after_hwframe+0x49/0xb3 > [52903.030018][ T310] RIP: 0033:0x7fa3d9cd670d > [52903.050021][ T310] Code: Bad RIP value. > [52903.068733][ T310] RSP: 002b:7fff1d6588c8 EFLAGS: 0246 ORIG_RAX: > 00cb > [52903.107680][ T310] RAX:
Beantragen Sie eine dringende Gutschrift
-- Sind Sie ein Geschftsmann oder eine Geschftsfrau? Befinden Sie sich in einer Finanzkrise oder bentigen Sie Mittel, um ein eigenes Unternehmen zu grnden? Bentigen Sie einen Kredit, um Ihre Schulden zu begleichen, Ihre Rechnungen zu bezahlen oder ein gutes Geschft zu erffnen? Haben Sie eine niedrige Kreditwrdigkeit und es fllt Ihnen schwer, einen Kapitalkredit von lokalen Banken und anderen Finanzinstituten zu erhalten? Hier ist Ihre Chance, einen Kredit von unserem Unternehmen zu erhalten. Wir bieten Privatpersonen Kredite fr folgende Zwecke und mehr an. Privatkredit, Geschftsausweitung, Unternehmensgrndung, Bildung, Schuldenkonsolidierung, Hartgeldkredite. Wir bieten Darlehen zu einem niedrigen Zinssatz von 2%. Bewerben Sie sich jetzt per E-Mail: (invest-morgan.stan...@outlook.co.id)
[PATCH -next] KVM: MIPS/Emulate: Remove unneeded semicolon
Fixes coccicheck warnings: arch/mips/kvm/emulate.c:1793:3-4: Unneeded semicolon arch/mips/kvm/emulate.c:1968:3-4: Unneeded semicolon Reported-by: Hulk Robot Signed-off-by: Zou Wei --- arch/mips/kvm/emulate.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/mips/kvm/emulate.c b/arch/mips/kvm/emulate.c index 754094b..5c88bd1 100644 --- a/arch/mips/kvm/emulate.c +++ b/arch/mips/kvm/emulate.c @@ -1790,7 +1790,7 @@ static enum emulation_result kvm_mips_guest_cache_op(int (*fn)(unsigned long), return EMULATE_EXCEPT; default: break; - }; + } } } @@ -1965,7 +1965,7 @@ enum emulation_result kvm_mips_emulate_inst(u32 cause, u32 *opc, break; default: goto unknown; - }; + } break; unknown: #endif -- 2.6.2
Re: [PATCH v3 3/4] MIPS: VDSO: Use $(LD) instead of $(CC) to link VDSO
On Wed, Apr 29, 2020 at 06:46:33PM +0100, Maciej W. Rozycki wrote: > On Mon, 27 Apr 2020, Nathan Chancellor wrote: > > > > Can you actually record in the change description what the difference in > > > the relevant link command is, as shown where `V=1' has been used with > > > `make' invocation? > > > > That will be rather unweildy to put in the commit message since > > currently, $(CC) + $(KBUILD_CFLAGS) is being used but I can if it is > > really desired. Otherwise, I can just put it where I put the changelog. > > Umm, is the difference so huge? I think a note along the lines of: > > "[...] This change adds/removes[*]: > > > > from the invocation of [...], which is required for [...]" > > -- only quoting what's actually changed will be sufficient. Reword as > required. Otherwise it's hard to guess now what the change actually does, > and it will be even harder for someone who comes across it and tries to > understand it the future, when the context might be hard to reproduce. > > [*] Delete as appropriate. > > Maciej I ended up figuring out a way to get the difference proper into the commit message in v4. Please take a look. Cheers, Nathan
Re: How to update a piece of flash for FPGA firmware?
Hi Matthew, Yilun On Tue, Apr 28, 2020 at 03:06:07PM -0700, matthew.gerl...@linux.intel.com wrote: > Hi Yilun, > > You raise some very interesting questions. Please see > my comments below. > > Matthew > > On Tue, 28 Apr 2020, Xu Yilun wrote: > > > Hi, > > > > I wonder if an updating of FPGA Flash (but cannot reload) could be > > implemented as fpga-mgr? > > > > I have the pcie based FPGA card. The bitstream for FPGA static region is > > stored on flash chip. Board will load the bitstream to FPGA on system > > power cycle. The flash chip could be accessed through "PCIE -> ... -> > > Flash update engine -> Flash". So the update of the FPGA static region is > > basicly updating the flash chip through PCIE and rebooting system. > > I think you mean power cycle when you say "rebooting system" above, but > your point is worth highlighting. During this flash update the > FPGA is actually fully configured and running its application. Typically, > during a fpga-mgr update of the static region or partial reconfiguration > region, the actual contents of the fpga region is "changing" during the > update. Yeah, this sounds more like a flash driver with MTD or maybe NVMEM? That's probably how I'd do it. Depending on your (Q)SPI controller you might already have a driver for that, and you'd just have to instantiate it as a sub-device. > > > > > Should I implement the flash update engine as a fpga-mgr device? On one > > hand it is just a flash write, FPGA functionality is actually not > > changed before reboot. Does fpga-mgr requires bitstream takes function > > immediately after write_complete()? On the other hand, the flash write > > do affects FPGA static region on next boot. Operating on the > > corresponding fpga region makes kernel fully aware of what is being > > done. > > When an fpga-mgr is used in a device tree overlay flow, one gains > the benefit the enumeration of the nodes in the overlay after the > update has completed. I'm not sure how to model 'on next reboot' part. > > > > > Actually the FPGA card do has the capability to reload bitstream at > > runtime. But it will cause the whole PCIE device lost, static region is > > also destroyed. We need to rescan PCI to get it back. So I think > > basically this is the same case as system reboot from FPGA's > > perspective. > > Yes, on those cards that have the ability to power cycle themselves (i.e. > fully reconfigure the FPGA from flash), the PCIe connection to the card > is broken because of a surprise link down PCIe error. As you say a PCI > rescan (i.e. re-enumeration of the entire card) is required. Since > the card has to be re-scanned at the PCI level anyway, there may not be much > benefit to using the fpga-mgr in this flow. Agreed. > > I wonder if these kinds of more disruptive updates are better suited to > something firmware updates rather than fpga updates? Yeah. Cheers, Moritz
[PATCH 0/2] perf stat: Support overall statistics for interval mode
Currently perf-stat supports to print counts at regular interval (-I), but it's not very easy for user to get the overall statistics. With this patchset, it supports to report the summary at the end of interval output. For example, root@kbl-ppc:~# perf stat -e cycles -I1000 --interval-count 2 # time counts unit events 1.000412064 2,281,114 cycles 2.001383658 2,547,880 cycles Performance counter stats for 'system wide': 4,828,994 cycles 2.002860349 seconds time elapsed root@kbl-ppc:~# perf stat -e cycles,instructions -I1000 --interval-count 2 # time counts unit events 1.000389902 1,536,093 cycles 1.000389902420,226 instructions #0.27 insn per cycle 2.001433453 2,213,952 cycles 2.001433453735,465 instructions #0.33 insn per cycle Performance counter stats for 'system wide': 3,750,045 cycles 1,155,691 instructions #0.31 insn per cycle 2.003023361 seconds time elapsed root@kbl-ppc:~# perf stat -M CPI,IPC -I1000 --interval-count 2 # time counts unit events 1.000435121905,303 inst_retired.any # 2.9 CPI 1.000435121 2,663,333 cycles 1.000435121914,702 inst_retired.any # 0.3 IPC 1.000435121 2,676,559 cpu_clk_unhalted.thread 2.001615941 1,951,092 inst_retired.any # 1.8 CPI 2.001615941 3,551,357 cycles 2.001615941 1,950,837 inst_retired.any # 0.5 IPC 2.001615941 3,551,044 cpu_clk_unhalted.thread Performance counter stats for 'system wide': 2,856,395 inst_retired.any # 2.2 CPI 6,214,690 cycles 2,865,539 inst_retired.any # 0.5 IPC 6,227,603 cpu_clk_unhalted.thread 2.003403078 seconds time elapsed Jin Yao (2): perf evsel: Create counts for collecting summary data perf stat: Report summary for interval mode tools/perf/builtin-stat.c | 14 ++- tools/perf/util/evsel.c | 10 - tools/perf/util/evsel.h | 1 + tools/perf/util/stat.c| 77 +++ tools/perf/util/stat.h| 5 +++ 5 files changed, 103 insertions(+), 4 deletions(-) -- 2.17.1
[PATCH 1/2] perf evsel: Create counts for collecting summary data
It would be useful to support the overall statistics for perf-stat
interval mode. For example, report the summary at the end of
"perf-stat -I" output.
But since perf-stat can support many aggregation modes, such as
--per-thread, --per-socket, -M and etc, we need a solution which
doesn't bring much complexity.
The idea is to create new 'evsel->summary_counts' which sums up the
counts delta per interval. Before reporting the summary, we copy the
data from evsel->summary_counts to evsel->counts, and next we just
follow current code.
Signed-off-by: Jin Yao
---
tools/perf/util/evsel.c | 10 --
tools/perf/util/evsel.h | 1 +
tools/perf/util/stat.c | 20
3 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 6a571d322bb2..7e878583f7a4 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1286,22 +1286,28 @@ void evsel__delete(struct evsel *evsel)
void perf_evsel__compute_deltas(struct evsel *evsel, int cpu, int thread,
struct perf_counts_values *count)
{
- struct perf_counts_values tmp;
+ struct perf_counts_values tmp, *summary;
- if (!evsel->prev_raw_counts)
+ if (!evsel->prev_raw_counts || !evsel->summary_counts)
return;
if (cpu == -1) {
tmp = evsel->prev_raw_counts->aggr;
evsel->prev_raw_counts->aggr = *count;
+ summary = >summary_counts->aggr;
} else {
tmp = *perf_counts(evsel->prev_raw_counts, cpu, thread);
*perf_counts(evsel->prev_raw_counts, cpu, thread) = *count;
+ summary = perf_counts(evsel->summary_counts, cpu, thread);
}
count->val = count->val - tmp.val;
count->ena = count->ena - tmp.ena;
count->run = count->run - tmp.run;
+
+ summary->val += count->val;
+ summary->ena += count->ena;
+ summary->run += count->run;
}
void perf_counts_values__scale(struct perf_counts_values *count,
diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h
index bf999e3c50c7..3dd690235f9b 100644
--- a/tools/perf/util/evsel.h
+++ b/tools/perf/util/evsel.h
@@ -46,6 +46,7 @@ struct evsel {
char*filter;
struct perf_counts *counts;
struct perf_counts *prev_raw_counts;
+ struct perf_counts *summary_counts;
int idx;
unsigned long max_events;
unsigned long nr_events_printed;
diff --git a/tools/perf/util/stat.c b/tools/perf/util/stat.c
index 242476eb808c..cf09cd7675c2 100644
--- a/tools/perf/util/stat.c
+++ b/tools/perf/util/stat.c
@@ -171,6 +171,24 @@ static void perf_evsel__reset_prev_raw_counts(struct evsel
*evsel)
}
}
+static int perf_evsel__alloc_summary_counts(struct evsel *evsel,
+ int ncpus, int nthreads)
+{
+ struct perf_counts *counts;
+
+ counts = perf_counts__new(ncpus, nthreads);
+ if (counts)
+ evsel->summary_counts = counts;
+
+ return counts ? 0 : -ENOMEM;
+}
+
+static void perf_evsel__free_summary_counts(struct evsel *evsel)
+{
+ perf_counts__delete(evsel->summary_counts);
+ evsel->summary_counts = NULL;
+}
+
static int perf_evsel__alloc_stats(struct evsel *evsel, bool alloc_raw)
{
int ncpus = perf_evsel__nr_cpus(evsel);
@@ -178,6 +196,7 @@ static int perf_evsel__alloc_stats(struct evsel *evsel,
bool alloc_raw)
if (perf_evsel__alloc_stat_priv(evsel) < 0 ||
perf_evsel__alloc_counts(evsel, ncpus, nthreads) < 0 ||
+ perf_evsel__alloc_summary_counts(evsel, ncpus, nthreads) < 0 ||
(alloc_raw && perf_evsel__alloc_prev_raw_counts(evsel, ncpus,
nthreads) < 0))
return -ENOMEM;
@@ -208,6 +227,7 @@ void perf_evlist__free_stats(struct evlist *evlist)
perf_evsel__free_stat_priv(evsel);
perf_evsel__free_counts(evsel);
perf_evsel__free_prev_raw_counts(evsel);
+ perf_evsel__free_summary_counts(evsel);
}
}
--
2.17.1
[PATCH 2/2] perf stat: Report summary for interval mode
Currently perf-stat supports to print counts at regular interval (-I),
but it's not very easy for user to get the overall statistics.
The patch uses 'evsel->summary_counts' to sum up the per interval counts
and copy the counts to 'evsel->counts' after printing the interval results.
Next, we just follow the non-interval processing.
Let's see some examples,
root@kbl-ppc:~# perf stat -e cycles -I1000 --interval-count 2
# time counts unit events
1.000412064 2,281,114 cycles
2.001383658 2,547,880 cycles
Performance counter stats for 'system wide':
4,828,994 cycles
2.002860349 seconds time elapsed
root@kbl-ppc:~# perf stat -e cycles,instructions -I1000 --interval-count 2
# time counts unit events
1.000389902 1,536,093 cycles
1.000389902420,226 instructions #0.27
insn per cycle
2.001433453 2,213,952 cycles
2.001433453735,465 instructions #0.33
insn per cycle
Performance counter stats for 'system wide':
3,750,045 cycles
1,155,691 instructions #0.31 insn per cycle
2.003023361 seconds time elapsed
root@kbl-ppc:~# perf stat -M CPI,IPC -I1000 --interval-count 2
# time counts unit events
1.000435121905,303 inst_retired.any # 2.9
CPI
1.000435121 2,663,333 cycles
1.000435121914,702 inst_retired.any # 0.3
IPC
1.000435121 2,676,559 cpu_clk_unhalted.thread
2.001615941 1,951,092 inst_retired.any # 1.8
CPI
2.001615941 3,551,357 cycles
2.001615941 1,950,837 inst_retired.any # 0.5
IPC
2.001615941 3,551,044 cpu_clk_unhalted.thread
Performance counter stats for 'system wide':
2,856,395 inst_retired.any # 2.2 CPI
6,214,690 cycles
2,865,539 inst_retired.any # 0.5 IPC
6,227,603 cpu_clk_unhalted.thread
2.003403078 seconds time elapsed
Signed-off-by: Jin Yao
---
tools/perf/builtin-stat.c | 14 --
tools/perf/util/stat.c| 57 +++
tools/perf/util/stat.h| 5
3 files changed, 74 insertions(+), 2 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 3f050d85c277..338bd35e9901 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -355,6 +355,7 @@ static void read_counters(struct timespec *rs)
static void process_interval(void)
{
struct timespec ts, rs;
+ struct stats walltime_nsecs_stats_bak;
clock_gettime(CLOCK_MONOTONIC, );
diff_timespec(, , _time);
@@ -367,9 +368,11 @@ static void process_interval(void)
pr_err("failed to write stat round event\n");
}
+ walltime_nsecs_stats_bak = walltime_nsecs_stats;
init_stats(_nsecs_stats);
update_stats(_nsecs_stats, stat_config.interval * 100);
print_counters(, 0, NULL);
+ walltime_nsecs_stats = walltime_nsecs_stats_bak;
}
static void enable_counters(void)
@@ -732,7 +735,14 @@ static int __run_perf_stat(int argc, const char **argv,
int run_idx)
* avoid arbitrary skew, we must read all counters before closing any
* group leaders.
*/
- read_counters(&(struct timespec) { .tv_nsec = t1-t0 });
+ if (!interval)
+ read_counters(&(struct timespec) { .tv_nsec = t1-t0 });
+ else {
+ stat_config.interval = 0;
+ stat_config.summary = true;
+ perf_evlist__copy_summary_counts(evsel_list);
+ perf_evlist__process_summary_counts(_config, evsel_list);
+ }
/*
* We need to keep evsel_list alive, because it's processed
@@ -2149,7 +2159,7 @@ int cmd_stat(int argc, const char **argv)
}
}
- if (!forever && status != -1 && !interval)
+ if (!forever && status != -1 && (!interval || stat_config.summary))
print_counters(NULL, argc, argv);
if (STAT_RECORD) {
diff --git a/tools/perf/util/stat.c b/tools/perf/util/stat.c
index cf09cd7675c2..a247ea9ea669 100644
--- a/tools/perf/util/stat.c
+++ b/tools/perf/util/stat.c
@@ -249,6 +249,63 @@ void perf_evlist__reset_prev_raw_counts(struct evlist
*evlist)
perf_evsel__reset_prev_raw_counts(evsel);
}
+static void perf_evsel__copy_summary_counts(struct evsel *evsel)
+{
+ int ncpus = perf_evsel__nr_cpus(evsel);
+ int nthreads = perf_thread_map__nr(evsel->core.threads);
+
+ for (int thread = 0; thread < nthreads; thread++) {
+ for (int cpu = 0; cpu < ncpus; cpu++) {
+
[PATCH -next] KVM: MIPS/VZ: Remove unneeded semicolon
Fixes coccicheck warnings:
arch/mips/kvm/vz.c:1186:4-5: Unneeded semicolon
arch/mips/kvm/vz.c:1195:3-4: Unneeded semicolon
arch/mips/kvm/vz.c:1949:3-4: Unneeded semicolon
arch/mips/kvm/vz.c:1121:2-3: Unneeded semicolon
arch/mips/kvm/vz.c:2188:3-4: Unneeded semicolon
Reported-by: Hulk Robot
Signed-off-by: Zou Wei
---
arch/mips/kvm/vz.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/mips/kvm/vz.c b/arch/mips/kvm/vz.c
index dde2088..389dd0f 100644
--- a/arch/mips/kvm/vz.c
+++ b/arch/mips/kvm/vz.c
@@ -1118,7 +1118,7 @@ static enum emulation_result kvm_vz_gpsi_cache(union
mips_instruction inst,
break;
default:
break;
- };
+ }
kvm_err("@ %#lx/%#lx CACHE (cache: %#x, op: %#x, base[%d]: %#lx,
offset: %#x\n",
curr_pc, vcpu->arch.gprs[31], cache, op, base, arch->gprs[base],
@@ -1183,7 +1183,7 @@ static enum emulation_result kvm_trap_vz_handle_gpsi(u32
cause, u32 *opc,
trace_kvm_hwr(vcpu, KVM_TRACE_RDHWR,
KVM_TRACE_HWR(rd, sel), 0);
goto unknown;
- };
+ }
trace_kvm_hwr(vcpu, KVM_TRACE_RDHWR,
KVM_TRACE_HWR(rd, sel), arch->gprs[rt]);
@@ -1192,7 +1192,7 @@ static enum emulation_result kvm_trap_vz_handle_gpsi(u32
cause, u32 *opc,
break;
default:
goto unknown;
- };
+ }
break;
unknown:
@@ -1946,7 +1946,7 @@ static int kvm_vz_get_one_reg(struct kvm_vcpu *vcpu,
default:
*v = (long)kvm_read_c0_guest_prid(cop0);
break;
- };
+ }
break;
case KVM_REG_MIPS_CP0_EBASE:
*v = kvm_vz_read_gc0_ebase();
@@ -2185,7 +2185,7 @@ static int kvm_vz_set_one_reg(struct kvm_vcpu *vcpu,
default:
kvm_write_c0_guest_prid(cop0, v);
break;
- };
+ }
break;
case KVM_REG_MIPS_CP0_EBASE:
kvm_vz_write_gc0_ebase(v);
--
2.6.2
Re: [PATCH v5 0/5] Allow ld.lld to link the MIPS VDSO
On Wed, Apr 29, 2020 at 09:04:42AM +0200, Sedat Dilek wrote: > On Wed, Apr 29, 2020 at 12:14 AM Nathan Chancellor > wrote: > > > Patch 1 adds ld.lld support to Kconfig so that we can avoid certain > > ld.bfd checks. > > > > Is it possible to introduce and add LD_IS_BFD Kconfig for ld.bfd in this > series? > Most people agreed on this name AFAICS. > What do people think? > > - Sedat - What is the use case for LD_IS_BFD right now? I am not sure I see a reason to add a CONFIG value that won't see any immediate use. Cheers, Nathan
Re: [PATCH v4 1/5] kbuild: add CONFIG_LD_IS_LLD
On Wed, Apr 29, 2020 at 09:13:40AM +0200, Sedat Dilek wrote: > On Wed, Apr 29, 2020 at 12:14 AM Nathan Chancellor > wrote: > > > > From: Sami Tolvanen > > > > Similarly to the CC_IS_CLANG config, add LD_IS_LLD to avoid GNU ld > > specific logic such as ld-version or ld-ifversion and gain the > > ability to select potential features that depend on the linker at > > configuration time such as LTO. > > > > Signed-off-by: Sami Tolvanen > > Acked-by: Masahiro Yamada > > [nc: Reword commit message] > > Signed-off-by: Nathan Chancellor > > Tested-by: Sedat Dilek > Reviewed-by: Sedat Dilek > > Testing on Debian/testing AMD64 (since Linux v5.3): > #1: LLVM/Clang/LLD version 9.0 and 10.0 > #2: Debian's GCC 9.3 with ld.lld-9 and ld.lld-10 > > I am linking my Linux-kernels with ld.lld despite there are issues - > then check with ld.bfd. What issues are these? Have they been reported? Cheers, Nathan > - Sedat - > > > --- > > > > v3 -> v4: > > > > * No changes. > > > > v2 -> v3: > > > > * Add Masahiro's ack. > > > > v1 -> v2: > > > > * No changes. > > > > Sami, please scream if you are unhappy with how I worded this commit. > > > > init/Kconfig | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/init/Kconfig b/init/Kconfig > > index 9e22ee8fbd75e..c15ee42b82726 100644 > > --- a/init/Kconfig > > +++ b/init/Kconfig > > @@ -23,6 +23,9 @@ config LD_VERSION > > config CC_IS_CLANG > > def_bool $(success,$(CC) --version | head -n 1 | grep -q clang) > > > > +config LD_IS_LLD > > + def_bool $(success,$(LD) -v | head -n 1 | grep -q LLD) > > + > > config CLANG_VERSION > > int > > default $(shell,$(srctree)/scripts/clang-version.sh $(CC)) > > > > base-commit: 96c9a7802af7d500a582d89a8b864584fe878c1b > > -- > > 2.26.2 > >
[PATCH v2] dt-bindings: thermal: Convert UniPhier thermal monitor to json-schema
Convert the UniPhier thermal monitor binding to DT schema format.
Signed-off-by: Kunihiko Hayashi
---
Changes since v1:
- Add maxItems to "socionext,tmod-calibration" property
- Fix indents in examples
.../thermal/socionext,uniphier-thermal.yaml| 59
.../bindings/thermal/uniphier-thermal.txt | 65 --
2 files changed, 59 insertions(+), 65 deletions(-)
create mode 100644
Documentation/devicetree/bindings/thermal/socionext,uniphier-thermal.yaml
delete mode 100644
Documentation/devicetree/bindings/thermal/uniphier-thermal.txt
diff --git
a/Documentation/devicetree/bindings/thermal/socionext,uniphier-thermal.yaml
b/Documentation/devicetree/bindings/thermal/socionext,uniphier-thermal.yaml
new file mode 100644
index 000..bb9594b
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/socionext,uniphier-thermal.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/socionext,uniphier-thermal.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Socionext UniPhier thermal monitor
+
+description: |
+ This describes the devicetree bindings for thermal monitor supported by
+ PVT(Process, Voltage and Temperature) monitoring unit implemented on
+ Socionext UniPhier SoCs.
+
+maintainers:
+ - Kunihiko Hayashi
+
+properties:
+ compatible:
+enum:
+ - socionext,uniphier-pxs2-thermal
+ - socionext,uniphier-ld20-thermal
+ - socionext,uniphier-pxs3-thermal
+
+ interrupts:
+maxItems: 1
+
+ "#thermal-sensor-cells":
+const: 0
+
+ socionext,tmod-calibration:
+allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32-array
+ - maxItems: 2
+description:
+ A pair of calibrated values referred from PVT, in case that the values
+ aren't set on SoC, like a reference board.
+
+required:
+ - compatible
+ - interrupts
+ - "#thermal-sensor-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+// The UniPhier thermal should be a subnode of a "syscon" compatible node.
+
+sysctrl@6184 {
+compatible = "socionext,uniphier-ld20-sysctrl",
+ "simple-mfd", "syscon";
+reg = <0x6184 0x1>;
+
+pvtctl: thermal {
+compatible = "socionext,uniphier-ld20-thermal";
+interrupts = <0 3 1>;
+#thermal-sensor-cells = <0>;
+};
+};
diff --git a/Documentation/devicetree/bindings/thermal/uniphier-thermal.txt
b/Documentation/devicetree/bindings/thermal/uniphier-thermal.txt
deleted file mode 100644
index ceb92a9..000
--- a/Documentation/devicetree/bindings/thermal/uniphier-thermal.txt
+++ /dev/null
@@ -1,65 +0,0 @@
-* UniPhier Thermal bindings
-
-This describes the devicetree bindings for thermal monitor supported by
-PVT(Process, Voltage and Temperature) monitoring unit implemented on Socionext
-UniPhier SoCs.
-
-Required properties:
-- compatible :
- - "socionext,uniphier-pxs2-thermal" : For UniPhier PXs2 SoC
- - "socionext,uniphier-ld20-thermal" : For UniPhier LD20 SoC
- - "socionext,uniphier-pxs3-thermal" : For UniPhier PXs3 SoC
-- interrupts : IRQ for the temperature alarm
-- #thermal-sensor-cells : Should be 0. See ./thermal.txt for details.
-
-Optional properties:
-- socionext,tmod-calibration: A pair of calibrated values referred from PVT,
- in case that the values aren't set on SoC,
- like a reference board.
-
-Example:
-
- sysctrl@6184 {
- compatible = "socionext,uniphier-ld20-sysctrl",
-"simple-mfd", "syscon";
- reg = <0x6184 0x1>;
- ...
- pvtctl: pvtctl {
- compatible = "socionext,uniphier-ld20-thermal";
- interrupts = <0 3 1>;
- #thermal-sensor-cells = <0>;
- };
- ...
- };
-
- thermal-zones {
- cpu_thermal {
- polling-delay-passive = <250>; /* 250ms */
- polling-delay = <1000>; /* 1000ms */
- thermal-sensors = <>;
-
- trips {
- cpu_crit: cpu_crit {
- temperature = <11>; /* 110C */
- hysteresis = <2000>;
- type = "critical";
- };
- cpu_alert: cpu_alert {
- temperature = <10>; /* 100C */
- hysteresis = <2000>;
- type = "passive";
- };
- };
-
- cooling-maps {
- map0 {
-
Re: [GIT PULL] Please pull proc and exec work for 5.7-rc1
On Thu, Apr 30, 2020 at 4:20 AM Linus Torvalds wrote: > On Wed, Apr 29, 2020 at 6:08 PM Bernd Edlinger > wrote: > > > > I added the BIG FAT WARNNIG comments as a mitigation for that. > > Did you like those comments? > > No. > > What's the point olf saying "THIS CODE IS GARBAGE" and then expecting > that to make it ok? > > No,m that doesn't make it ok. It just means that it should have been > done differently. > > > Yes, exactly, the point is the caller is expected to call wait in that > > scenario, otherwise the -EAGAIN just repeats forever, that is an API > > change, yes, but something unavoidable, and the patch tries hard to > > limit it to cases where the live-lock or pseudo-dead-lock is unavoidable > > anyway. > > I'm getting really fed up with your insistence on that KNOWN BROKEN > garbage test-case. > > It's shit. The test-case is wrong. I've told you before. > > Your patch as-is breaks other cases that are *not* wrong in the kernel > currently, and that don't have test-cases because they JustWork(tm). > > The livelock isn't interesting. The test-case that shows it is pure > garbage, and is written wrong. > > IF that test-case hadn't been buggy in the first place, it would have > had ignored its child (or had a handler for SIGCHLD), and not > livelocked. But if we go with Bernd's approach together with your restart suggestion, then simply doing PTRACE_ATTACH on two threads A and B would be enough to livelock, right? tracer: PTRACE_ATTACHes to A B: enters de_thread() tracer: attempts to PTRACE_ATTACH to B Now the tracer will loop on PTRACE_ATTACH, right?
rcu_barrier() + membarrier() + scheduler deadlock?
Doing some fuzzers on many CPUs triggers a deadlock really quickly. I can see that there were several tasks had been stuck for a while, CPUA: slab_caches_to_rcu_destroy_workfn() rcu_barrier() wait_for_completion() CPUB: sched_setaffinity() __set_cpus_allowed_ptr() stop_one_cpu() CPUC: __x64_sys_membarrier synchronize_rcu() __wait_rcu_gp() wait_for_completion() Lockdep did not flag anything useful at all. Any clue? [52885.040113][T150406] futex_wake_op: trinity-c9 tries to shift op by -1189; fix this program [52890.366916][T150196] futex_wake_op: trinity-c3 tries to shift op by -1; fix this program [52896.369779][T151054] futex_wake_op: trinity-c23 tries to shift op by 710; fix this program [52901.770688][ T310] INFO: task kworker/36:2:142207 blocked for more than 122 seconds. [52901.811471][ T310] Tainted: G L 5.7.0-rc3-next-20200429 #2 [52901.849148][ T310] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [52901.889803][ T310] kworker/36:2D29104 142207 2 0x90004000 [52901.919461][ T310] Workqueue: events slab_caches_to_rcu_destroy_workfn [52901.950935][ T310] Call Trace: [52901.965369][ T310] __schedule+0x77e/0x1070 [52901.986211][ T310] ? __sched_text_start+0x8/0x8 [52902.008267][ T310] ? trace_hardirqs_on+0x3a/0x160 [52902.031764][ T310] schedule+0x95/0x160 [52902.050729][ T310] schedule_timeout+0x47c/0x6a0 [52902.072897][ T310] ? print_irqtrace_events+0x110/0x110 [52902.098316][ T310] ? usleep_range+0x100/0x100 [52902.119664][ T310] ? mark_held_locks+0x86/0xb0 [52902.141397][ T310] ? _raw_spin_unlock_irq+0x27/0x40 [52902.165326][ T310] ? _raw_spin_unlock_irq+0x27/0x40 [52902.189622][ T310] ? lockdep_hardirqs_on+0x1b0/0x2c0 [52902.213641][ T310] ? wait_for_completion+0x116/0x1a0 [52902.238757][ T310] ? trace_hardirqs_on+0x3a/0x160 [52902.261648][ T310] wait_for_completion+0x11e/0x1a0 [52902.285516][ T310] ? wait_for_completion_interruptible+0x220/0x220 [52902.316342][ T310] ? rcu_read_lock_held+0xc0/0xc0 [52902.340298][ T310] rcu_barrier+0x2c5/0x440 [52902.361736][ T310] slab_caches_to_rcu_destroy_workfn+0x95/0xe0 [52902.391109][ T310] process_one_work+0x57e/0xb90 [52902.413244][ T310] ? pwq_dec_nr_in_flight+0x170/0x170 [52902.437957][ T310] ? worker_thread+0x14b/0x5b0 [52902.460357][ T310] worker_thread+0x63/0x5b0 [52902.481267][ T310] ? process_one_work+0xb90/0xb90 [52902.504818][ T310] kthread+0x1f7/0x220 [52902.523542][ T310] ? kthread_create_worker_on_cpu+0xc0/0xc0 [52902.550801][ T310] ret_from_fork+0x3a/0x50 [52902.560427][T151328] futex_wake_op: trinity-c10 tries to shift op by -1; fix this program [52902.571250][ T310] INFO: task trinity-c18:145344 can't die for more than 123 seconds. [52902.648554][ T310] trinity-c18 R running task26944 145344 74932 0x10004004 [52902.700179][ T310] Call Trace: [52902.715039][ T310] __schedule+0x77e/0x1070 [52902.735531][ T310] ? __sched_text_start+0x8/0x8 [52902.757922][ T310] ? do_syscall_64+0x28d/0xaf0 [52902.779731][ T310] ? do_syscall_64+0x28d/0xaf0 [52902.802215][ T310] schedule+0x95/0x160 [52902.821375][ T310] do_syscall_64+0x23e/0xaf0 [52902.843517][ T310] ? perf_call_bpf_enter+0x1a0/0x1a0 [52902.871003][ T310] ? ftrace_syscall_enter+0x4b0/0x4b0 [52902.896034][ T310] ? syscall_return_slowpath+0x580/0x580 [52902.922153][ T310] ? entry_SYSCALL_64_after_hwframe+0x3e/0xb3 [52902.950409][ T310] ? trace_hardirqs_off_caller+0x3a/0x150 [52902.976721][ T310] ? trace_hardirqs_off_thunk+0x1a/0x1c [52903.002409][ T310] entry_SYSCALL_64_after_hwframe+0x49/0xb3 [52903.030018][ T310] RIP: 0033:0x7fa3d9cd670d [52903.050021][ T310] Code: Bad RIP value. [52903.068733][ T310] RSP: 002b:7fff1d6588c8 EFLAGS: 0246 ORIG_RAX: 00cb [52903.107680][ T310] RAX: RBX: 00cb RCX: 7fa3d9cd670d [52903.144861][ T310] RDX: 7fa3d7c38000 RSI: 0004 RDI: [52903.182189][ T310] RBP: 00cb R08: ca23 R09: 00b3 [52903.219290][ T310] R10: 2ab3d706 R11: 0246 R12: 0002 [52903.256653][ T310] R13: 7fa3d8608058 R14: 7fa3d9b956c0 R15: 7fa3d8608000 [52903.294988][ T310] INFO: task trinity-c24:146199 can't die for more than 124 seconds. [52903.333911][ T310] trinity-c24 R running task26944 146199 74932 0x1004 [52903.377051][ T310] Call Trace: [52903.393139][ T310] __schedule+0x77e/0x1070 [52903.413685][ T310] ? __sched_text_start+0x8/0x8 [52903.435602][ T310] ? check_flags.part.28+0x86/0x220 [52903.459452][ T310] preempt_schedule_common+0x16/0x50 [52903.483985][ T310] _cond_resched+0x22/0x30 [52903.504130][ T310] stop_one_cpu+0xd7/0x140 [52903.524695][ T310] ? stop_cpus.constprop.3+0x130/0x130 [52903.550266][ T310] ? task_rq_unlock+0x6e/0x80 [52903.572005][ T310] ? sched_ttwu_pending+0x1b0/0x1b0 [52903.5
Re: [PATCH V2 00/16] arm64/cpufeature: Introduce ID_PFR2, ID_DFR1, ID_MMFR5 and other changes
On 04/30/2020 02:56 AM, Will Deacon wrote: > Hi Anshuman, > > On Wed, Apr 29, 2020 at 03:07:15PM +0530, Anshuman Khandual wrote: >> On 04/14/2020 03:18 PM, Anshuman Khandual wrote: >>> This series is primarily motivated from an adhoc list from Mark Rutland >>> during our previous ID_ISAR6 discussion [1]. The current proposal also >>> accommodates some more suggestions from Will and Suzuki. >>> >>> This series adds missing 32 bit system registers (ID_PFR2, ID_DFR1 and >>> ID_MMFR5), adds missing features bits on all existing system registers >>> (32 and 64 bit) and some other miscellaneous changes. While here it also >>> includes a patch which does macro replacement for various open bits shift >>> encodings for various CPU ID registers. There is a slight re-order of the >>> patches here as compared to the previous version (V1). >>> >>> This series is based on v5.7-rc1. All feature bits enabled here can be >>> referred in ARM DDI 0487F.a specification. Though I have tried to select >>> appropriate values for each new feature being added here, there might be >>> some inconsistencies (or mistakes). In which case, please do let me know >>> if anything needs to change. Thank you. >>> >>> [1] https://patchwork.kernel.org/patch/11287805/ >>> >>> Cc: Catalin Marinas >>> Cc: Will Deacon >>> Cc: Mark Rutland >>> Cc: Marc Zyngier >>> Cc: James Morse >>> Cc: Suzuki K Poulose >>> Cc: kvm...@lists.cs.columbia.edu >>> Cc: linux-arm-ker...@lists.infradead.org >>> Cc: linux-kernel@vger.kernel.org >>> >>> Changes in V2: >>> >>> - Added Suggested-by tag from Mark Rutland for all changes he had proposed >>> - Added comment for SpecSEI feature on why it is HIGHER_SAFE per Suzuki >>> - Added a patch which makes ID_AA64DFR0_DOUBLELOCK a signed feature per >>> Suzuki >>> - Added ID_DFR1 and ID_MMFR5 system register definitions per Will >>> - Added remaining features bits for relevant 64 bit system registers per >>> Will >>> - Changed commit message on [PATCH 5/7] regarding TraceFilt feature per >>> Suzuki >>> - Changed ID_PFR2.CSV3 (FTR_STRICT -> FTR_NONSTRICT) as 64 bit registers >>> per Will >>> - Changed ID_PFR0.CSV2 (FTR_STRICT -> FTR_NONSTRICT) as 64 bit registers >>> per Will >>> - Changed some commit messages >> >> Just a gentle ping. I am wondering if you had a chance to glance >> through this updated series. > > Please can you resend based on for-next/cpufeature? Sure, will do.
Re: [PATCH] dt-bindings: thermal: Convert UniPhier thermal monitor to json-schema
Hi Rob, On 2020/04/29 1:20, Rob Herring wrote: On Thu, Apr 16, 2020 at 02:12:15PM +0900, Kunihiko Hayashi wrote: Convert the UniPhier thermal monitor binding to DT schema format. Signed-off-by: Kunihiko Hayashi --- .../thermal/socionext,uniphier-thermal.yaml| 57 +++ .../bindings/thermal/uniphier-thermal.txt | 65 -- 2 files changed, 57 insertions(+), 65 deletions(-) create mode 100644 Documentation/devicetree/bindings/thermal/socionext,uniphier-thermal.yaml delete mode 100644 Documentation/devicetree/bindings/thermal/uniphier-thermal.txt diff --git a/Documentation/devicetree/bindings/thermal/socionext,uniphier-thermal.yaml b/Documentation/devicetree/bindings/thermal/socionext,uniphier-thermal.yaml new file mode 100644 index 000..bdddc5b --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/socionext,uniphier-thermal.yaml @@ -0,0 +1,57 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/thermal/socionext,uniphier-thermal.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Socionext UniPhier thermal monitor + +description: | + This describes the devicetree bindings for thermal monitor supported by + PVT(Process, Voltage and Temperature) monitoring unit implemented on + Socionext UniPhier SoCs. + +maintainers: + - Kunihiko Hayashi + +properties: + compatible: +enum: + - socionext,uniphier-pxs2-thermal + - socionext,uniphier-ld20-thermal + - socionext,uniphier-pxs3-thermal + + interrupts: +maxItems: 1 + + "#thermal-sensor-cells": +const: 0 + + socionext,tmod-calibration: +$ref: /schemas/types.yaml#/definitions/uint32-array +description: + A pair of calibrated values referred from PVT, in case that the values + aren't set on SoC, like a reference board. So?: maxItems: 2 Okay, I'll add that in v2. Thank you, --- Best Regards Kunihiko Hayashi
Re: [PATCH V2] fs/ceph:fix double unlock in handle_cap_export()
On Wed, Apr 29, 2020 at 8:49 AM Wu Bo wrote:
>
> On 2020/4/28 22:48, Jeff Layton wrote:
> > On Tue, 2020-04-28 at 21:13 +0800, Wu Bo wrote:
> >> if the ceph_mdsc_open_export_target_session() return fails,
> >> should add a lock to avoid twice unlocking.
> >> Because the lock will be released at the retry or out_unlock tag.
> >>
> >
> > The problem looks real, but...
> >
> >> --
> >> v1 -> v2:
> >> add spin_lock(>i_ceph_lock) before goto out_unlock tag.
> >>
> >> Signed-off-by: Wu Bo
> >> ---
> >> fs/ceph/caps.c | 27 +++
> >> 1 file changed, 15 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c
> >> index 185db76..414c0e2 100644
> >> --- a/fs/ceph/caps.c
> >> +++ b/fs/ceph/caps.c
> >> @@ -3731,22 +3731,25 @@ static void handle_cap_export(struct inode *inode,
> >> struct ceph_mds_caps *ex,
> >>
> >> /* open target session */
> >> tsession = ceph_mdsc_open_export_target_session(mdsc, target);
> >> -if (!IS_ERR(tsession)) {
> >> -if (mds > target) {
> >> -mutex_lock(>s_mutex);
> >> -mutex_lock_nested(>s_mutex,
> >> - SINGLE_DEPTH_NESTING);
> >> -} else {
> >> -mutex_lock(>s_mutex);
> >> -mutex_lock_nested(>s_mutex,
> >> - SINGLE_DEPTH_NESTING);
> >> -}
> >> -new_cap = ceph_get_cap(mdsc, NULL);
> >> -} else {
> >> +if (IS_ERR(tsession)) {
> >> WARN_ON(1);
> >> tsession = NULL;
> >> target = -1;
> >> +mutex_lock(>s_mutex);
> >> +spin_lock(>i_ceph_lock);
> >> +goto out_unlock;
> >
> > Why did you make this case goto out_unlock instead of retrying as it did
> > before?
> >
>
> If the problem occurs, target = -1, and goto retry lable, you need to
> call __get_cap_for_mds() or even call __ceph_remove_cap(), and then jump
> to out_unlock lable. All I think is unnecessary, goto out_unlock instead
> of retrying directly.
>
__ceph_remove_cap() must be called even if opening target session
failed. I think adding a mutex_lock(>s_mutex) to the
IS_ERR(tsession) block should be enough.
> Thanks.
> Wu Bo
>
> >> +}
> >> +
> >> +if (mds > target) {
> >> +mutex_lock(>s_mutex);
> >> +mutex_lock_nested(>s_mutex,
> >> +SINGLE_DEPTH_NESTING);
> >> +} else {
> >> +mutex_lock(>s_mutex);
> >> +mutex_lock_nested(>s_mutex,
> >> +SINGLE_DEPTH_NESTING);
> >> }
> >> +new_cap = ceph_get_cap(mdsc, NULL);
> >> goto retry;
> >>
> >> out_unlock:
> >
>
>
[PATCH -next] dlm: Remove unneeded semicolon
Fixes coccicheck warning: fs/dlm/rcom.c:566:2-3: Unneeded semicolon Reported-by: Hulk Robot Signed-off-by: Zou Wei --- fs/dlm/rcom.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/dlm/rcom.c b/fs/dlm/rcom.c index e3d9f72..4daf5dc 100644 --- a/fs/dlm/rcom.c +++ b/fs/dlm/rcom.c @@ -563,7 +563,7 @@ void dlm_receive_rcom(struct dlm_ls *ls, struct dlm_rcom *rc, int nodeid) lock = 1; reply = 1; break; - }; + } spin_lock(>ls_recover_lock); status = ls->ls_recover_status; -- 2.6.2
