Re: [PATCH v2 3/3] isa: Make the remove callback for isa drivers return void
On 22/01/2021 10:24, Uwe Kleine-König wrote:
> The driver core ignores the return value of the remove callback, so
> don't give isa drivers the chance to provide a value.
>
> Adapt all isa_drivers with a remove callbacks accordingly; they all
> return 0 unconditionally anyhow.
>
> Acked-by: Marc Kleine-Budde # for
> drivers/net/can/sja1000/tscan1.c
> Acked-by: William Breathitt Gray
> Acked-by: Wolfram Sang # for drivers/i2c/
> Reviewed-by: Takashi Iway # for sound/
> Signed-off-by: Uwe Kleine-König
For the media/radio drivers:
Reviewed-by: Hans Verkuil
Thanks,
Hans
> ---
> drivers/base/isa.c | 2 +-
> drivers/i2c/busses/i2c-elektor.c | 4 +---
> drivers/i2c/busses/i2c-pca-isa.c | 4 +---
> drivers/input/touchscreen/htcpen.c | 4 +---
> drivers/media/radio/radio-isa.c | 4 +---
> drivers/media/radio/radio-isa.h | 2 +-
> drivers/media/radio/radio-sf16fmr2.c | 4 +---
> drivers/net/can/sja1000/tscan1.c | 4 +---
> drivers/net/ethernet/3com/3c509.c| 3 +--
> drivers/scsi/advansys.c | 3 +--
> drivers/scsi/aha1542.c | 3 +--
> drivers/scsi/fdomain_isa.c | 3 +--
> drivers/scsi/g_NCR5380.c | 5 ++---
> drivers/watchdog/pcwd.c | 4 +---
> include/linux/isa.h | 2 +-
> sound/isa/ad1848/ad1848.c| 3 +--
> sound/isa/adlib.c| 3 +--
> sound/isa/cmi8328.c | 3 +--
> sound/isa/cmi8330.c | 3 +--
> sound/isa/cs423x/cs4231.c| 3 +--
> sound/isa/cs423x/cs4236.c| 3 +--
> sound/isa/es1688/es1688.c| 3 +--
> sound/isa/es18xx.c | 5 ++---
> sound/isa/galaxy/galaxy.c| 3 +--
> sound/isa/gus/gusclassic.c | 3 +--
> sound/isa/gus/gusextreme.c | 3 +--
> sound/isa/gus/gusmax.c | 3 +--
> sound/isa/gus/interwave.c| 3 +--
> sound/isa/msnd/msnd_pinnacle.c | 3 +--
> sound/isa/opl3sa2.c | 3 +--
> sound/isa/opti9xx/miro.c | 3 +--
> sound/isa/opti9xx/opti92x-ad1848.c | 5 ++---
> sound/isa/sb/jazz16.c| 3 +--
> sound/isa/sb/sb16.c | 3 +--
> sound/isa/sb/sb8.c | 3 +--
> sound/isa/sc6000.c | 3 +--
> sound/isa/sscape.c | 3 +--
> sound/isa/wavefront/wavefront.c | 3 +--
> 38 files changed, 41 insertions(+), 83 deletions(-)
>
> diff --git a/drivers/base/isa.c b/drivers/base/isa.c
> index 2772f5d1948a..aa4737667026 100644
> --- a/drivers/base/isa.c
> +++ b/drivers/base/isa.c
> @@ -51,7 +51,7 @@ static int isa_bus_remove(struct device *dev)
> struct isa_driver *isa_driver = dev->platform_data;
>
> if (isa_driver && isa_driver->remove)
> - return isa_driver->remove(dev, to_isa_dev(dev)->id);
> + isa_driver->remove(dev, to_isa_dev(dev)->id);
>
> return 0;
> }
> diff --git a/drivers/i2c/busses/i2c-elektor.c
> b/drivers/i2c/busses/i2c-elektor.c
> index 140426db28df..b72a3c3ef2ab 100644
> --- a/drivers/i2c/busses/i2c-elektor.c
> +++ b/drivers/i2c/busses/i2c-elektor.c
> @@ -282,7 +282,7 @@ static int elektor_probe(struct device *dev, unsigned int
> id)
> return -ENODEV;
> }
>
> -static int elektor_remove(struct device *dev, unsigned int id)
> +static void elektor_remove(struct device *dev, unsigned int id)
> {
> i2c_del_adapter(&pcf_isa_ops);
>
> @@ -298,8 +298,6 @@ static int elektor_remove(struct device *dev, unsigned
> int id)
> iounmap(base_iomem);
> release_mem_region(base, 2);
> }
> -
> - return 0;
> }
>
> static struct isa_driver i2c_elektor_driver = {
> diff --git a/drivers/i2c/busses/i2c-pca-isa.c
> b/drivers/i2c/busses/i2c-pca-isa.c
> index f27bc1e55385..85e8cf58e8bf 100644
> --- a/drivers/i2c/busses/i2c-pca-isa.c
> +++ b/drivers/i2c/busses/i2c-pca-isa.c
> @@ -161,7 +161,7 @@ static int pca_isa_probe(struct device *dev, unsigned int
> id)
> return -ENODEV;
> }
>
> -static int pca_isa_remove(struct device *dev, unsigned int id)
> +static void pca_isa_remove(struct device *dev, unsigned int id)
> {
> i2c_del_adapter(&pca_isa_ops);
>
> @@ -170,8 +170,6 @@ static int pca_isa_remove(struct device *dev, unsigned
> int id)
> free_irq(irq, &pca_isa_ops);
> }
> release_region(base, IO_SIZE);
> -
> - return 0;
> }
>
> static struct isa_driver pca_isa_driver = {
> diff --git a/drivers/input/touchscreen/htcpen.c
> b/drivers/input/touchscreen/htcpen.c
> index 2f261a34f9c2..056ba76087e8 100644
> --- a/drivers/input/touchscreen/htcpen.c
> +++ b/drivers/input/touchscreen/htcpen.c
> @@ -171,7 +171,7 @@ static int htcpen_isa_probe(struct device *dev, unsigned
> int id)
> return err;
> }
>
> -static int htcpen_isa_remove(struct device *dev, unsigned int id)
> +static void htcpen_isa_remove(struct device *dev, unsigned int id)
>
Re: [PATCH v4 2/5] docs: Document colorimetry class
On 20/01/2021 10:26, Stanimir Varbanov wrote: > Add a document for ext control colorimetry class. > > Signed-off-by: Stanimir Varbanov > --- > .../userspace-api/media/v4l/common.rst| 1 + > .../media/v4l/ext-ctrls-colorimetry.rst | 19 +++ > .../media/v4l/vidioc-g-ext-ctrls.rst | 4 > 3 files changed, 24 insertions(+) > create mode 100644 > Documentation/userspace-api/media/v4l/ext-ctrls-colorimetry.rst > > diff --git a/Documentation/userspace-api/media/v4l/common.rst > b/Documentation/userspace-api/media/v4l/common.rst > index 8c263c5a85d8..ea0435182e44 100644 > --- a/Documentation/userspace-api/media/v4l/common.rst > +++ b/Documentation/userspace-api/media/v4l/common.rst > @@ -51,6 +51,7 @@ applicable to all devices. > ext-ctrls-fm-tx > ext-ctrls-fm-rx > ext-ctrls-detect > +ext-ctrls-colorimetry > fourcc > format > planar-apis > diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-colorimetry.rst > b/Documentation/userspace-api/media/v4l/ext-ctrls-colorimetry.rst > new file mode 100644 > index ..6b0cd2054e84 > --- /dev/null > +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-colorimetry.rst > @@ -0,0 +1,19 @@ > +.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later > + > +.. _colorimetry-controls: > + > +* > +Colorimetry Control Reference > +* > + > +Below are controls within the Colorimetry control class. This needs a bit more work since it doesn't explain anything :-) See how it is done in other ext-ctrls-*.rst files. Regards, Hans > + > +Colorimetry Control IDs > +--- > + > +.. _colorimetry-control-id: > + > +``V4L2_CID_COLORIMETRY_CLASS (class)`` > +The Colorimetry class descriptor. Calling > +:ref:`VIDIOC_QUERYCTRL` for this control will > +return a description of this control class. > diff --git a/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst > b/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst > index b9c62affbb5a..8a95ebdd499a 100644 > --- a/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst > +++ b/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst > @@ -394,6 +394,10 @@ still cause this situation. >- 0xa4 >- The class containing stateless codec controls. These controls are > described in :ref:`codec-stateless-controls`. > +* - ``V4L2_CTRL_CLASS_COLORIMETRY`` > + - 0xa5 > + - The class containing colorimetry controls. These controls are > + described in :ref:`colorimetry-controls`. > > Return Value > >
Re: [PATCH] kernel-doc: Make the description of return value readable
Em Mon, 25 Jan 2021 10:19:04 +0200 Jarkko Sakkinen escreveu: > The description on how to describe return values is over-complicated, and > hard to follow. For alien reason, the body of the section is a note, and > the first paragraph speaks about 'Return', albeit the section name is > actually 'Return:'. > > To give a better help when both implementing and reviewing patches, provide > a straight-forward guideline, how to decribe return values, instead of > providing a note that starts by "blacklisting" one of the infinite possible > options of doing it wrong. > > This decreases the cumulative amount of time, which is probably > substantial, on this otherwise somewhat trivial topic. > > Signed-off-by: Jarkko Sakkinen > --- > Documentation/doc-guide/kernel-doc.rst | 34 +++--- > 1 file changed, 9 insertions(+), 25 deletions(-) > > diff --git a/Documentation/doc-guide/kernel-doc.rst > b/Documentation/doc-guide/kernel-doc.rst > index 79aaa55d6bcf..dc5e1722c150 100644 > --- a/Documentation/doc-guide/kernel-doc.rst > +++ b/Documentation/doc-guide/kernel-doc.rst > @@ -136,34 +136,18 @@ Examples:: > Return values > ~ > > -The return value, if any, should be described in a dedicated section > -named ``Return``. > +The return value, if any, should be described in a dedicated section named > +``Return:``. > > -.. note:: > - > - #) The multi-line descriptive text you provide does *not* recognize > - line breaks, so if you try to format some text nicely, as in:: > - > - * Return: > - * 0 - OK > - * -EINVAL - invalid argument > - * -ENOMEM - out of memory > - > - this will all run together and produce:: > - > - Return: 0 - OK -EINVAL - invalid argument -ENOMEM - out of memory > - > - So, in order to produce the desired line breaks, you need to use a > - ReST list, e. g.:: > +In order to describe multiple return values, a ReST list should be used. That > +way Sphinx knows how to line-up them properly:: > > - * Return: > - * * 0 - OK to runtime suspend the device > - * * -EBUSY - Device should not be runtime suspended > + * Return: > + * - 0: The run-time is allowed to suspend the device. > + * - -EBUSY:Device should not be suspended. > > - #) If the descriptive text you provide has lines that begin with > - some phrase followed by a colon, each of those phrases will be taken > - as a new section heading, which probably won't produce the desired > - effect. > +Using a dash rather than asterisk an is probably a better idea, because it > does > +not meddle as much with the C-comments. Well, there are different opinions with that regards... Some devs think that using: - -EBUSY is confusing. I ended agreeing with that. That's why the recommendation is to use an asterisk. Thanks, Mauro
Re: [PATCH v2 4/4] hwmon: Support Aspeed AST2600 PWM/Fan tachometer
Hi Guenter, The 01/24/2021 00:14, Guenter Roeck wrote: > On Wed, Jan 13, 2021 at 07:08:48AM +, Troy Lee wrote: > > Add Aspeed AST2600 PWM/Fan tacho driver. AST2600 has 16 PWM channel and > > 16 FAN tacho channel. > > > > Changes since v1: > > - fixed review comments > > - fixed double-looped calculation of div_h and div_l > > - moving configuration to device tree > > - register hwmon driver with devm_hwmon_device_register_with_info() > > > > Signed-off-by: Troy Lee > > checkpatch says: > > total: 0 errors, 9 warnings, 26 checks, 779 lines checked > > This is a bit much. Please run checkpatch --strict and fix the issues > it reports. Please also fix the issues reported by 0-day as well as > the issues reported by the bindings robot, and resubmit. > > Thanks, > Guenter I'll fix the WARNINGs and CHECKs. Thanks, Troy Lee
[PATCH 2/4] sched/fair: Move avg_scan_cost calculations under SIS_PROP
As noted by Vincent Guittot, avg_scan_costs are calculated for SIS_PROP
even if SIS_PROP is disabled. Move the time calculations under a SIS_PROP
check and while we are at it, exclude the cost of initialising the CPU
mask from the average scan cost.
Signed-off-by: Mel Gorman
---
kernel/sched/fair.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 9f5682aeda2e..c8d8e185cf3b 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6153,6 +6153,8 @@ static int select_idle_cpu(struct task_struct *p, struct
sched_domain *sd, int t
if (!this_sd)
return -1;
+ cpumask_and(cpus, sched_domain_span(sd), p->cpus_ptr);
+
if (sched_feat(SIS_PROP)) {
u64 avg_cost, avg_idle, span_avg;
@@ -6168,11 +6170,9 @@ static int select_idle_cpu(struct task_struct *p, struct
sched_domain *sd, int t
nr = div_u64(span_avg, avg_cost);
else
nr = 4;
- }
-
- time = cpu_clock(this);
- cpumask_and(cpus, sched_domain_span(sd), p->cpus_ptr);
+ time = cpu_clock(this);
+ }
for_each_cpu_wrap(cpu, cpus, target) {
if (!--nr)
@@ -6181,8 +6181,10 @@ static int select_idle_cpu(struct task_struct *p, struct
sched_domain *sd, int t
break;
}
- time = cpu_clock(this) - time;
- update_avg(&this_sd->avg_scan_cost, time);
+ if (sched_feat(SIS_PROP)) {
+ time = cpu_clock(this) - time;
+ update_avg(&this_sd->avg_scan_cost, time);
+ }
return cpu;
}
--
2.26.2
RE: [PATCH][next] drm/i915/hdcp: Fix return of value in uninitialized variable ret
It is already merged to drm-intel-next
https://cgit.freedesktop.org/drm/drm-intel/commit/?h=drm-intel-next&id=40a6cead28f841ac350bd38dd7260ecacd5eab03
> -Original Message-
> From: Jani Nikula
> Sent: Friday, January 22, 2021 8:51 PM
> To: Colin King ; Joonas Lahtinen
> ; Vivi, Rodrigo ;
> David Airlie ; Daniel Vetter ; C,
> Ramalingam
> ; Gupta, Anshuman ;
> Shankar, Uma ; intel-...@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org
> Cc: kernel-janit...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH][next] drm/i915/hdcp: Fix return of value in uninitialized
> variable ret
>
> On Fri, 22 Jan 2021, Colin King wrote:
> > From: Colin Ian King
> >
> > Currently when there are other connectors on the port using HDCP the
> > function _intel_hdcp_disable returns a garbage uninitialized value in
> > variable ret. I believe the intention is to return 0, so return this
> > literal value instead of the value in ret.
> >
> > Addresses-Coverity: ("Uninitialized scalar return")
> > Fixes: 899c8762f981 ("drm/i915/hdcp: Configure HDCP2.2 MST steram
> > encryption status")
> > Signed-off-by: Colin Ian King
>
> Thanks, but there's already a fix in progress:
>
> http://lore.kernel.org/r/20210119064655.1605-3-anshuman.gu...@intel.com
>
> BR,
> Jani.
>
>
> > ---
> > drivers/gpu/drm/i915/display/intel_hdcp.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > index db8dff2eeb0a..a0e7b0bf892b 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > @@ -883,7 +883,7 @@ static int _intel_hdcp_disable(struct intel_connector
> *connector)
> > * until it disabled HDCP encryption for all connectors in MST topology.
> > */
> > if (dig_port->num_hdcp_streams > 0)
> > - return ret;
> > + return 0;
> >
> > hdcp->hdcp_encrypted = false;
> > intel_de_write(dev_priv, HDCP_CONF(dev_priv, cpu_transcoder, port),
> > 0);
>
> --
> Jani Nikula, Intel Open Source Graphics Center
[PATCH 2/3] pinctrl: at91-pio4: add support for slew-rate
SAMA7G5 supports slew rate configuration. Adapt the driver for this.
For switching frequencies lower than 50MHz the slew rate needs to
be enabled. Since most of the pins on SAMA7G5 fall into this category
enabled the slew rate by default.
Signed-off-by: Claudiu Beznea
---
drivers/pinctrl/pinctrl-at91-pio4.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-at91-pio4.c
b/drivers/pinctrl/pinctrl-at91-pio4.c
index d267367d94b9..c59ab0bfb945 100644
--- a/drivers/pinctrl/pinctrl-at91-pio4.c
+++ b/drivers/pinctrl/pinctrl-at91-pio4.c
@@ -36,6 +36,7 @@
#defineATMEL_PIO_DIR_MASK BIT(8)
#defineATMEL_PIO_PUEN_MASK BIT(9)
#defineATMEL_PIO_PDEN_MASK BIT(10)
+#defineATMEL_PIO_SR_MASK BIT(11)
#defineATMEL_PIO_IFEN_MASK BIT(12)
#defineATMEL_PIO_IFSCEN_MASK BIT(13)
#defineATMEL_PIO_OPD_MASK BIT(14)
@@ -76,10 +77,12 @@
* @nbanks: number of PIO banks
* @last_bank_count: number of lines in the last bank (can be less than
* the rest of the banks).
+ * @sr: slew rate support
*/
struct atmel_pioctrl_data {
unsigned nbanks;
unsigned last_bank_count;
+ unsigned int sr;
};
struct atmel_group {
@@ -117,6 +120,7 @@ struct atmel_pin {
* @pm_suspend_backup: backup/restore register values on suspend/resume
* @dev: device entry for the Atmel PIO controller.
* @node: node of the Atmel PIO controller.
+ * @sr: slew rate support
*/
struct atmel_pioctrl {
void __iomem*reg_base;
@@ -138,6 +142,7 @@ struct atmel_pioctrl {
} *pm_suspend_backup;
struct device *dev;
struct device_node *node;
+ unsigned intsr;
};
static const char * const atmel_functions[] = {
@@ -760,6 +765,13 @@ static int atmel_conf_pin_config_group_get(struct
pinctrl_dev *pctldev,
return -EINVAL;
arg = 1;
break;
+ case PIN_CONFIG_SLEW_RATE:
+ if (!atmel_pioctrl->sr)
+ return -EOPNOTSUPP;
+ if (!(res & ATMEL_PIO_SR_MASK))
+ return -EINVAL;
+ arg = 1;
+ break;
case ATMEL_PIN_CONFIG_DRIVE_STRENGTH:
if (!(res & ATMEL_PIO_DRVSTR_MASK))
return -EINVAL;
@@ -793,6 +805,10 @@ static int atmel_conf_pin_config_group_set(struct
pinctrl_dev *pctldev,
dev_dbg(pctldev->dev, "%s: pin=%u, config=0x%lx\n",
__func__, pin_id, configs[i]);
+ /* Keep slew rate enabled by default. */
+ if (atmel_pioctrl->sr)
+ conf |= ATMEL_PIO_SR_MASK;
+
switch (param) {
case PIN_CONFIG_BIAS_DISABLE:
conf &= (~ATMEL_PIO_PUEN_MASK);
@@ -850,6 +866,13 @@ static int atmel_conf_pin_config_group_set(struct
pinctrl_dev *pctldev,
ATMEL_PIO_SODR);
}
break;
+ case PIN_CONFIG_SLEW_RATE:
+ if (!atmel_pioctrl->sr)
+ break;
+ /* And remove it if explicitly requested. */
+ if (arg == 0)
+ conf &= ~ATMEL_PIO_SR_MASK;
+ break;
case ATMEL_PIN_CONFIG_DRIVE_STRENGTH:
switch (arg) {
case ATMEL_PIO_DRVSTR_LO:
@@ -901,6 +924,8 @@ static void atmel_conf_pin_config_dbg_show(struct
pinctrl_dev *pctldev,
seq_printf(s, "%s ", "open-drain");
if (conf & ATMEL_PIO_SCHMITT_MASK)
seq_printf(s, "%s ", "schmitt");
+ if (atmel_pioctrl->sr && (conf & ATMEL_PIO_SR_MASK))
+ seq_printf(s, "%s ", "slew-rate");
if (conf & ATMEL_PIO_DRVSTR_MASK) {
switch ((conf & ATMEL_PIO_DRVSTR_MASK) >>
ATMEL_PIO_DRVSTR_OFFSET) {
case ATMEL_PIO_DRVSTR_ME:
@@ -994,6 +1019,7 @@ static const struct atmel_pioctrl_data
atmel_sama5d2_pioctrl_data = {
static const struct atmel_pioctrl_data microchip_sama7g5_pioctrl_data = {
.nbanks = 5,
.last_bank_count= 8, /* sama7g5 has only PE0 to PE7 */
+ .sr = 1,
};
static const struct of_device_id atmel_pctrl_of_match[] = {
@@ -1039,6 +1065,7 @@ static int atmel_pinctrl_probe(struct platform_device
*pdev)
atmel_pioctrl->npins -= ATMEL_PIO_NPINS_PER_BANK;
atmel_pioctrl->npins += atmel_pioctrl_data->last_bank_count;
}
+ atmel_pioctrl->sr = atmel_pioctrl_data->sr;
atmel_pioctrl->reg_base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(atmel_pioctrl->reg_b
Re: [PATCH 3/4] ubifs: Update directory size when creating whiteouts
在 2021/1/25 15:55, Richard Weinberger 写道: The idea was that in the !whiteout case, sz_change is always 0. Oh, sz_change was initialized to 0, I missed it. Thanks.
Re: [v4 PATCH 07/11] mm: vmscan: add per memcg shrinker nr_deferred
On 22.01.2021 02:06, Yang Shi wrote:
> Currently the number of deferred objects are per shrinker, but some slabs,
> for example,
> vfs inode/dentry cache are per memcg, this would result in poor isolation
> among memcgs.
>
> The deferred objects typically are generated by __GFP_NOFS allocations, one
> memcg with
> excessive __GFP_NOFS allocations may blow up deferred objects, then other
> innocent memcgs
> may suffer from over shrink, excessive reclaim latency, etc.
>
> For example, two workloads run in memcgA and memcgB respectively, workload in
> B is vfs
> heavy workload. Workload in A generates excessive deferred objects, then B's
> vfs cache
> might be hit heavily (drop half of caches) by B's limit reclaim or global
> reclaim.
>
> We observed this hit in our production environment which was running vfs
> heavy workload
> shown as the below tracing log:
>
> <...>-409454 [016] 28286961.747146: mm_shrink_slab_start:
> super_cache_scan+0x0/0x1a0 9a83046f3458:
> nid: 1 objects to shrink 3641681686040 gfp_flags
> GFP_HIGHUSER_MOVABLE|__GFP_ZERO pgs_scanned 1 lru_pgs 15721
> cache items 246404277 delta 31345 total_scan 123202138
> <...>-409454 [022] 28287105.928018: mm_shrink_slab_end:
> super_cache_scan+0x0/0x1a0 9a83046f3458:
> nid: 1 unused scan count 3641681686040 new scan count 3641798379189
> total_scan 602
> last shrinker return val 123186855
>
> The vfs cache and page cache ration was 10:1 on this machine, and half of
> caches were dropped.
> This also resulted in significant amount of page caches were dropped due to
> inodes eviction.
>
> Make nr_deferred per memcg for memcg aware shrinkers would solve the
> unfairness and bring
> better isolation.
>
> When memcg is not enabled (!CONFIG_MEMCG or memcg disabled), the shrinker's
> nr_deferred
> would be used. And non memcg aware shrinkers use shrinker's nr_deferred all
> the time.
>
> Signed-off-by: Yang Shi
> ---
> include/linux/memcontrol.h | 7 +++---
> mm/vmscan.c| 49 +-
> 2 files changed, 36 insertions(+), 20 deletions(-)
>
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index 62b888b88a5f..e0384367e07d 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -93,12 +93,13 @@ struct lruvec_stat {
> };
>
> /*
> - * Bitmap of shrinker::id corresponding to memcg-aware shrinkers,
> - * which have elements charged to this memcg.
> + * Bitmap and deferred work of shrinker::id corresponding to memcg-aware
> + * shrinkers, which have elements charged to this memcg.
> */
> struct shrinker_info {
> struct rcu_head rcu;
> - unsigned long map[];
> + unsigned long *map;
> + atomic_long_t *nr_deferred;
> };
>
> /*
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 018e1beb24c9..722aa71b13b2 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -192,11 +192,13 @@ static void free_shrinker_info_rcu(struct rcu_head
> *head)
> kvfree(container_of(head, struct shrinker_info, rcu));
> }
>
> -static int expand_one_shrinker_info(struct mem_cgroup *memcg,
> -int size, int old_size)
> +static int expand_one_shrinker_info(struct mem_cgroup *memcg, int nr_max,
> + int m_size, int d_size,
> + int old_m_size, int old_d_size)
> {
> struct shrinker_info *new, *old;
> int nid;
> + int size = m_size + d_size;
>
> for_each_node(nid) {
> old = rcu_dereference_protected(
> @@ -209,9 +211,16 @@ static int expand_one_shrinker_info(struct mem_cgroup
> *memcg,
> if (!new)
> return -ENOMEM;
>
> - /* Set all old bits, clear all new bits */
> - memset(new->map, (int)0xff, old_size);
> - memset((void *)new->map + old_size, 0, size - old_size);
> + new->map = (unsigned long *)(new + 1);
> + new->nr_deferred = (atomic_long_t *)(new->map +
> + nr_max / BITS_PER_LONG + 1);
Why not
new->nr_deferred = (void *)new->map + m_size;
?
> +
> + /* map: set all old bits, clear all new bits */
> + memset(new->map, (int)0xff, old_m_size);
> + memset((void *)new->map + old_m_size, 0, m_size - old_m_size);
> + /* nr_deferred: copy old values, clear all new values */
> + memcpy(new->nr_deferred, old->nr_deferred, old_d_size);
> + memset((void *)new->nr_deferred + old_d_size, 0, d_size -
> old_d_size);
>
> rcu_assign_pointer(memcg->nodeinfo[nid]->shrinker_info, new);
> call_rcu(&old->rcu, free_shrinker_info_rcu);
> @@ -226,9 +235,6 @@ void free_shrinker_info(struct mem_cgroup *memcg)
> struct shrinker_info *info;
> int nid;
>
> - if (mem_cgroup_is_root(memcg))
> - return;
> -
> for_each_node(nid) {
>
Re: [RFC PATCH] perf: Handle multiple formatted AUX records
Hi Peter
On 1/25/21 10:25 AM, Peter Zijlstra wrote:
On Fri, Jan 22, 2021 at 03:18:29PM +, Suzuki K Poulose wrote:
CoreSight PMU supports aux-buffer for the ETM tracing. The trace
generated by the ETM (associated with individual CPUs, like Intel PT)
is captured by a separate IP (CoreSight TMC-ETR/ETF until now).
The TMC-ETR applies formatting of the raw ETM trace data, as it
can collect traces from multiple ETMs, with the TraceID to indicate
the source of a given trace packet.
Arm Trace Buffer Extension is new "sink" IP, attached to individual
CPUs and thus do not provide additional formatting, like TMC-ETR.
Additionally, a system could have both TRBE *and* TMC-ETR for
the trace collection. e.g, TMC-ETR could be used as a single
trace buffer to collect data from multiple ETMs to correlate
the traces from different CPUs. It is possible to have a
perf session where some events end up collecting the trace
in TMC-ETR while the others in TRBE. Thus we need a way
to identify the type of the trace for each AUX record.
This patch adds a new flag to indicate the trace format
for the given record. Also, includes the changes that
demonstrates how this can be used in the CoreSight PMU
to solve the problem.
Signed-off-by: Suzuki K Poulose
---
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index b15e3447cd9f..ea7dcc7b30f0 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -1109,6 +1109,7 @@ enum perf_callchain_context {
#define PERF_AUX_FLAG_OVERWRITE 0x02/* snapshot from
overwrite mode */
#define PERF_AUX_FLAG_PARTIAL 0x04/* record contains gaps */
#define PERF_AUX_FLAG_COLLISION 0x08/* sample collided with
another */
+#define PERF_AUX_FLAG_ALT_FMT 0x10/* this record is in alternate
trace format */
Since we have a whole u64, do we want to reserve a whole nibble (or
maybe even a byte) for a format type? Because with a single bit like
this, we'll kick ourselves when we end up with the need for a 3rd format
type.
Sure, makes sense. We could do:
#define PERF_AUX_FLAG_PMU_FORMAT_TYPE_MASK 0xff00
Additionally, the values could be allocated by individual PMUs and
interpreted by the corresponding counterpart. That way we don't
have to worry about centralized allocation of the "TYPE" fields.
e,g:
#define PERF_AUX_FLAG_CORESIGHT_FORMAT_CORESIGHT0x
#define PERF_AUX_FLAG_CORESIGHT_FORMAT_RAW 0x0100
#define PERF_AUX_FLAG_RANDOM_PMU_FORMAT_FMT10x
#define PERF_AUX_FLAG_RANDOM_PMU_FORMAT_FMT20x0100
What do you think ?
Cheers
Suzuki
Re: [PATCH v2] x86/perf: Use static_call for x86_pmu.guest_get_msrs
On Fri, Jan 22, 2021 at 11:03:24AM +0800, Like Xu wrote: > Clean up that CONFIG_RETPOLINE crud and replace the > indirect call x86_pmu.guest_get_msrs with static_call(). > Looks good in principle, but the robot complains about a missing func decl. I think you removed a little too much when you killed the inline thing.
[PATCH v5 02/21] arm64: Fix outdated TCR setup comment
The arm64 kernel has long be able to use more than 39bit VAs. Since day one, actually. Let's rewrite the offending comment. Signed-off-by: Marc Zyngier Acked-by: Catalin Marinas Acked-by: David Brazdil --- arch/arm64/mm/proc.S | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S index 1f7ee8c8b7b8..ece785477bdc 100644 --- a/arch/arm64/mm/proc.S +++ b/arch/arm64/mm/proc.S @@ -464,8 +464,8 @@ SYM_FUNC_START(__cpu_setup) #endif msr mair_el1, x5 /* -* Set/prepare TCR and TTBR. We use 512GB (39-bit) address range for -* both user and kernel. +* Set/prepare TCR and TTBR. TCR_EL1.T1SZ gets further +* adjusted if the kernel is compiled with 52bit VA support. */ mov_q x10, TCR_TxSZ(VA_BITS) | TCR_CACHE_FLAGS | TCR_SMP_FLAGS | \ TCR_TG_FLAGS | TCR_KASLR_FLAGS | TCR_ASID16 | \ -- 2.29.2
[PATCH v5 01/21] arm64: Fix labels in el2_setup macros
If someone happens to write the following code: b 1f init_el2_state vhe 1: [...] they will be in for a long debugging session, as the label "1f" will be resolved *inside* the init_el2_state macro instead of after it. Not really what one expects. Instead, rewite the EL2 setup macros to use unambiguous labels, thanks to the usual macro counter trick. Acked-by: Catalin Marinas Signed-off-by: Marc Zyngier Acked-by: David Brazdil --- arch/arm64/include/asm/el2_setup.h | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/arch/arm64/include/asm/el2_setup.h b/arch/arm64/include/asm/el2_setup.h index a7f5a1bbc8ac..540116de80bf 100644 --- a/arch/arm64/include/asm/el2_setup.h +++ b/arch/arm64/include/asm/el2_setup.h @@ -45,24 +45,24 @@ mrs x1, id_aa64dfr0_el1 sbfxx0, x1, #ID_AA64DFR0_PMUVER_SHIFT, #4 cmp x0, #1 - b.lt1f // Skip if no PMU present + b.lt.Lskip_pmu_\@ // Skip if no PMU present mrs x0, pmcr_el0// Disable debug access traps ubfxx0, x0, #11, #5 // to EL2 and allow access to -1: +.Lskip_pmu_\@: cselx2, xzr, x0, lt // all PMU counters from EL1 /* Statistical profiling */ ubfxx0, x1, #ID_AA64DFR0_PMSVER_SHIFT, #4 - cbz x0, 3f // Skip if SPE not present + cbz x0, .Lskip_spe_\@ // Skip if SPE not present .ifeqs "\mode", "nvhe" mrs_s x0, SYS_PMBIDR_EL1 // If SPE available at EL2, and x0, x0, #(1 << SYS_PMBIDR_EL1_P_SHIFT) - cbnzx0, 2f // then permit sampling of physical + cbnzx0, .Lskip_spe_el2_\@ // then permit sampling of physical mov x0, #(1 << SYS_PMSCR_EL2_PCT_SHIFT | \ 1 << SYS_PMSCR_EL2_PA_SHIFT) msr_s SYS_PMSCR_EL2, x0 // addresses and physical counter -2: +.Lskip_spe_el2_\@: mov x0, #(MDCR_EL2_E2PB_MASK << MDCR_EL2_E2PB_SHIFT) orr x2, x2, x0 // If we don't have VHE, then // use EL1&0 translation. @@ -71,7 +71,7 @@ // and disable access from EL1 .endif -3: +.Lskip_spe_\@: msr mdcr_el2, x2// Configure debug traps .endm @@ -79,9 +79,9 @@ .macro __init_el2_lor mrs x1, id_aa64mmfr1_el1 ubfxx0, x1, #ID_AA64MMFR1_LOR_SHIFT, 4 - cbz x0, 1f + cbz x0, .Lskip_lor_\@ msr_s SYS_LORC_EL1, xzr -1: +.Lskip_lor_\@: .endm /* Stage-2 translation */ @@ -93,7 +93,7 @@ .macro __init_el2_gicv3 mrs x0, id_aa64pfr0_el1 ubfxx0, x0, #ID_AA64PFR0_GIC_SHIFT, #4 - cbz x0, 1f + cbz x0, .Lskip_gicv3_\@ mrs_s x0, SYS_ICC_SRE_EL2 orr x0, x0, #ICC_SRE_EL2_SRE// Set ICC_SRE_EL2.SRE==1 @@ -103,7 +103,7 @@ mrs_s x0, SYS_ICC_SRE_EL2 // Read SRE back, tbz x0, #0, 1f // and check that it sticks msr_s SYS_ICH_HCR_EL2, xzr// Reset ICC_HCR_EL2 to defaults -1: +.Lskip_gicv3_\@: .endm .macro __init_el2_hstr @@ -128,14 +128,14 @@ .macro __init_el2_nvhe_sve mrs x1, id_aa64pfr0_el1 ubfxx1, x1, #ID_AA64PFR0_SVE_SHIFT, #4 - cbz x1, 1f + cbz x1, .Lskip_sve_\@ bic x0, x0, #CPTR_EL2_TZ// Also disable SVE traps msr cptr_el2, x0// Disable copro. traps to EL2 isb mov x1, #ZCR_ELx_LEN_MASK // SVE: Enable full vector msr_s SYS_ZCR_EL2, x1 // length for EL1. -1: +.Lskip_sve_\@: .endm .macro __init_el2_nvhe_prepare_eret -- 2.29.2
[PATCH] cmd_dtc: Enable generation of device tree symbols
Adding the -@ switch to dtc results in the binary devicetrees containing a list of symbolic references and their paths. This is necessary to apply device tree overlays e.g. on Raspberry Pi as described on https://www.raspberrypi.org/documentation/configuration/device-tree.md. Obviously the downside of this change is an increas of the size of the generated dtbs, for an arm out-of-tree build (multi_v7_defconfig): $ du -s arch/arm/boot/dts* 101380 arch/arm/boot/dts-pre 114308 arch/arm/boot/dts-post so this is in average an increase of 12.8% in size. Signed-off-by: Uwe Kleine-König --- scripts/Makefile.lib | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 213677a5ed33..0683a5808f7f 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -319,7 +319,7 @@ $(obj)/%.dtb.S: $(obj)/%.dtb FORCE quiet_cmd_dtc = DTC $@ cmd_dtc = $(HOSTCC) -E $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $< ; \ - $(DTC) -O $(patsubst .%,%,$(suffix $@)) -o $@ -b 0 \ + $(DTC) -@ -O $(patsubst .%,%,$(suffix $@)) -o $@ -b 0 \ $(addprefix -i,$(dir $<) $(DTC_INCLUDE)) $(DTC_FLAGS) \ -d $(depfile).dtc.tmp $(dtc-tmp) ; \ cat $(depfile).pre.tmp $(depfile).dtc.tmp > $(depfile) -- 2.29.2
Re: [PATCH 2/5] mm,memory_hotplug: Allocate memmap from the added memory range
On 25.01.21 11:39, Oscar Salvador wrote: > On Tue, Jan 19, 2021 at 02:58:41PM +0100, David Hildenbrand wrote: >> IIRC, there is a conflict with the hpage vmemmap freeing patch set, >> right? How are we going to handle that? > > First of all, sorry for the lateness David, was a bit busy. > > AFAIK, there is no conflict at the moment. > hpage vmemmap populates with basepages (PMD support is disabled). I don't see how that makes a difference? We end up consuming the altmap via vmemmap_alloc_block_buf(). Read below, most probably I am missing something. > > But even with PMD support enabled, I cannot see how it can interfere. > > From the mhp point of view vmemmap pages only matter when allocating it and > when freeing it. > The only moment we would have to worry about is when we have to get rid of > them > (aka: the memory range that describe is being hot-removed), but the hpage > vmemmap patchset makes sure that by the time we return from > dissolve_free_huge_page > the vemmap pages look as they did before the remapping. Aehm I don't think that's the case. there might be a vmemmap but these are then other pages than the altmap. > > But as I said, we do not have to worry about this one as that feature only > works > when populating with base pages. I'm confused. 1. Assume we hotplug memory, online it to ZONE_MOVABLE. The vmemmap gets allocated from altmap space. 2. Allocate huge pages. The vmemmap gets freed, which ends up freeing pages in the altmap space that are even PageReserved() and not even accounted properly in managed pages. Problem? 3. Try offlining memory, skip the altmap space. The altmap pages might now be used for something else in the meantime. Problem? This should hold with both, basepages and hugepages in the vmemmap. What am I missing? [...] >> IIRC, it could happen that if we add two consecutive memory blocks, that >> the second one might reuse parts of the vmemmap residing on the first >> memory block. If you remove the first one, you might be in trouble. >> >> E.g., on x86-64 >> vmemmap_populate()->vmemmap_populate_hugepages()->vmemmap_alloc_block_buf(): >> - Populate a huge page >> >> vmemmap_free()->remove_pagetable()...->remove_pmd_table(): >> - memchr_inv() will leave the hugepage populated. >> >> Do we want to fence that off, maybe in mhp_supports_memmap_on_memory()? >> Or do we somehow want to fix that? We should never populate partial huge >> pages from an altmap ... >> >> But maybe I am missing something. > > No, you are not missing anything. > > I think that remove_pmd_table() should be fixed. > vmemmap_populate_hugepages() allocates PMD_SIZE chunk and marks the PMD as > PAGE_KERNEL_LARGE, so when remove_pmd_table() sees that 1) the PMD > is large and 2) the chunk is not aligned, the memset() should be writing > PAGE_INUSE for a PMD chunk. I tried to handle such stuff (dealing with partially present vmemmap on a PMD) a little bit smarter in the s390x code I added recently. Anyhow, we should never ever consume memory from an altmap when it might cover more than the added range; that really only works with anon memory, but not with memory from the altmap space. > > I do not really a see a reason why this should not happen. > Actually, we will be leaving pagetables behind as we never get to free > the PMD chunk when sizeof(struct page) is not a multiple of 2MB. > > I plan to fix remove_pmd_table(), but for now let us not allow to use this > feature > if the size of a struct page is not 64. > Let us keep it simply for the time being, shall we? Fine with me, as long as we never ever accidentally allocate more from the altmap than we actually need - the vmemmap must either span complete PMDs or we have to fallback to PTEs for the problematic parts. So while we require "IS_ALIGNED(nr_vmemmap_pages, pageblock_nr_pages)", we actually require here "IS_ALIGNED(nr_vmemmap_pages, PMD_SIZE >> PAGE_SHIFT)" IIUC. (+ alignment of the start address) For x86-64 this holds, for arm64 as well at least for 4k base pages. I *hope* 64k base pages never ever use PMDs (512MB) in the vmemmap when hotplugging :D (did not check, but I assume they don't, would be horribly ugly otherwise) > >>> /* set above range as isolated */ >>> - ret = start_isolate_page_range(start_pfn, end_pfn, >>> + ret = start_isolate_page_range(buddy_start_pfn, end_pfn, >>>MIGRATE_MOVABLE, >>>MEMORY_OFFLINE | REPORT_FAILURE); >> >> If buddy_start_pfn is not aligned to pageblocks, >> start_isolate_page_range will BUG_ON(). another sign that we need to >> check that somewhere while adding that nr_vmemmap_pages is suitable. > > Will come up with a way to 1) ensure that vmemmap pages is aligned and > 2) disallow to use the feature in case it cannot be aligned for some reason. > > >> Let's avoid using the "memblock" terminology. Just call it >> "get_nr_vmemmap_pages_cb" or maybe "detect_memmap_on_memory_cb" > > Fine. > >>>
[PATCH] ath9k: fix build error with LEDS_CLASS=m
From: Arnd Bergmann
When CONFIG_ATH9K is built-in but LED support is in a loadable
module, both ath9k drivers fails to link:
x86_64-linux-ld: drivers/net/wireless/ath/ath9k/gpio.o: in function
`ath_deinit_leds':
gpio.c:(.text+0x36): undefined reference to `led_classdev_unregister'
x86_64-linux-ld: drivers/net/wireless/ath/ath9k/gpio.o: in function
`ath_init_leds':
gpio.c:(.text+0x179): undefined reference to `led_classdev_register_ext'
The problem is that the 'imply' keyword does not enforce any dependency
but is only a weak hint to Kconfig to enable another symbol from a
defconfig file.
Change imply to a 'depends on LEDS_CLASS' that prevents the incorrect
configuration but still allows building the driver without LED support.
The 'select MAC80211_LEDS' is now ensures that the LED support is
actually used if it is present, and the added Kconfig dependency
on MAC80211_LEDS ensures that it cannot be enabled manually when it
has no effect.
Fixes: 197f466e93f5 ("ath9k_htc: Do not select MAC80211_LEDS by default")
Signed-off-by: Arnd Bergmann
---
drivers/net/wireless/ath/ath9k/Kconfig | 8 ++--
net/mac80211/Kconfig | 2 +-
2 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/Kconfig
b/drivers/net/wireless/ath/ath9k/Kconfig
index a84bb9b6573f..e150d82eddb6 100644
--- a/drivers/net/wireless/ath/ath9k/Kconfig
+++ b/drivers/net/wireless/ath/ath9k/Kconfig
@@ -21,11 +21,9 @@ config ATH9K_BTCOEX_SUPPORT
config ATH9K
tristate "Atheros 802.11n wireless cards support"
depends on MAC80211 && HAS_DMA
+ select MAC80211_LEDS if LEDS_CLASS=y || LEDS_CLASS=MAC80211
select ATH9K_HW
select ATH9K_COMMON
- imply NEW_LEDS
- imply LEDS_CLASS
- imply MAC80211_LEDS
help
This module adds support for wireless adapters based on
Atheros IEEE 802.11n AR5008, AR9001 and AR9002 family
@@ -176,11 +174,9 @@ config ATH9K_PCI_NO_EEPROM
config ATH9K_HTC
tristate "Atheros HTC based wireless cards support"
depends on USB && MAC80211
+ select MAC80211_LEDS if LEDS_CLASS=y || LEDS_CLASS=MAC80211
select ATH9K_HW
select ATH9K_COMMON
- imply NEW_LEDS
- imply LEDS_CLASS
- imply MAC80211_LEDS
help
Support for Atheros HTC based cards.
Chipsets supported: AR9271
diff --git a/net/mac80211/Kconfig b/net/mac80211/Kconfig
index cd9a9bd242ba..51ec8256b7fa 100644
--- a/net/mac80211/Kconfig
+++ b/net/mac80211/Kconfig
@@ -69,7 +69,7 @@ config MAC80211_MESH
config MAC80211_LEDS
bool "Enable LED triggers"
depends on MAC80211
- depends on LEDS_CLASS
+ depends on LEDS_CLASS=y || LEDS_CLASS=MAC80211
select LEDS_TRIGGERS
help
This option enables a few LED triggers for different
--
2.29.2
Re: [RFC PATCH] kvm: arm64: Try stage2 block mapping for host device MMIO
Hi Marc,
On 2021/1/22 17:45, Marc Zyngier wrote:
> On 2021-01-22 08:36, Keqian Zhu wrote:
>> The MMIO region of a device maybe huge (GB level), try to use block
>> mapping in stage2 to speedup both map and unmap.
>>
>> Especially for unmap, it performs TLBI right after each invalidation
>> of PTE. If all mapping is of PAGE_SIZE, it takes much time to handle
>> GB level range.
>
> This is only on VM teardown, right? Or do you unmap the device more ofet?
> Can you please quantify the speedup and the conditions this occurs in?
Yes, and there are some other paths (includes what your patch series handles)
will do the unmap action:
1、guest reboot without S2FWB: stage2_unmap_vm（）which only unmaps guest regular
RAM.
2、userspace deletes memslot: kvm_arch_flush_shadow_memslot().
3、rollback of device MMIO mapping: kvm_arch_prepare_memory_region().
4、rollback of dirty log tracking: If we enable hugepage for guest RAM, after
dirty log is stopped,
the newly created block mappings will unmap
all page mappings.
5、mmu notifier: kvm_unmap_hva_range(). AFAICS, we will use this path when VM
teardown or guest resets pass-through devices.
The bugfix[1] gives the reason for
unmapping MMIO region when guest resets pass-through devices.
unmap related to MMIO region, as this patch solves:
point 1 is not applied.
point 2 occurs when userspace unplug pass-through devices.
point 3 can occurs, but rarely.
point 4 is not applied.
point 5 occurs when VM teardown or guest resets pass-through devices.
And I had a look at your patch series, it can solve:
For VM teardown, elide CMO and perform VMALL instead of individually (But
current kernel do not go through this path when VM teardown).
For rollback of dirty log tracking, elide CMO.
For kvm_unmap_hva_range, if event is MMU_NOTIFY_UNMAP. elide CMO.
(But I doubt the CMOs in unmap. As we perform CMOs in user_mem_abort when
install new stage2 mapping for VM,
maybe the CMO in unmap is unnecessary under all conditions :-) ?)
So it shows that we are solving different parts of unmap, so they are not
conflicting. At least this patch can
still speedup map of device MMIO region, and speedup unmap of device MMIO
region even if we do not need to perform
CMO and TLBI ;-).
speedup: unmap 8GB MMIO on FPGA.
beforeafter opt
cost30+ minutes949ms
Thanks,
Keqian
>
> I have the feeling that we are just circling around another problem,
> which is that we could rely on a VM-wide TLBI when tearing down the
> guest. I worked on something like that[1] a long while ago, and parked
> it for some reason. Maybe it is worth reviving.
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=kvm-arm64/elide-cmo-tlbi
>
>>
>> Signed-off-by: Keqian Zhu
>> ---
>> arch/arm64/include/asm/kvm_pgtable.h | 11 +++
>> arch/arm64/kvm/hyp/pgtable.c | 15 +++
>> arch/arm64/kvm/mmu.c | 12
>> 3 files changed, 34 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/kvm_pgtable.h
>> b/arch/arm64/include/asm/kvm_pgtable.h
>> index 52ab38db04c7..2266ac45f10c 100644
>> --- a/arch/arm64/include/asm/kvm_pgtable.h
>> +++ b/arch/arm64/include/asm/kvm_pgtable.h
>> @@ -82,6 +82,17 @@ struct kvm_pgtable_walker {
>> const enum kvm_pgtable_walk_flagsflags;
>> };
>>
>> +/**
>> + * kvm_supported_pgsize() - Get the max supported page size of a mapping.
>> + * @pgt:Initialised page-table structure.
>> + * @addr:Virtual address at which to place the mapping.
>> + * @end:End virtual address of the mapping.
>> + * @phys:Physical address of the memory to map.
>> + *
>> + * The smallest return value is PAGE_SIZE.
>> + */
>> +u64 kvm_supported_pgsize(struct kvm_pgtable *pgt, u64 addr, u64 end, u64
>> phys);
>> +
>> /**
>> * kvm_pgtable_hyp_init() - Initialise a hypervisor stage-1 page-table.
>> * @pgt:Uninitialised page-table structure to initialise.
>> diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
>> index bdf8e55ed308..ab11609b9b13 100644
>> --- a/arch/arm64/kvm/hyp/pgtable.c
>> +++ b/arch/arm64/kvm/hyp/pgtable.c
>> @@ -81,6 +81,21 @@ static bool kvm_block_mapping_supported(u64 addr,
>> u64 end, u64 phys, u32 level)
>> return IS_ALIGNED(addr, granule) && IS_ALIGNED(phys, granule);
>> }
>>
>> +u64 kvm_supported_pgsize(struct kvm_pgtable *pgt, u64 addr, u64 end, u64
>> phys)
>> +{
>> +u32 lvl;
>> +u64 pgsize = PAGE_SIZE;
>> +
>> +for (lvl = pgt->start_level; lvl < KVM_PGTABLE_MAX_LEVELS; lvl++) {
>> +if (kvm_block_mapping_supported(addr, end, phys, lvl)) {
>> +pgsize = kvm_granule_size(lvl);
>> +break;
>> +}
>> +}
>> +
>> +return pgsize;
>> +}
>> +
>> static u32 kvm_pgtable_idx(struct kvm_pgtable_walk_data *data, u32 level)
>> {
>> u64 shift = kvm_granule_shift(level);
>> diff --gi
Re: [PATCH] ath9k: fix build error with LEDS_CLASS=m
On Mon, 25 Jan 2021 at 12:36, Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> When CONFIG_ATH9K is built-in but LED support is in a loadable
> module, both ath9k drivers fails to link:
>
> x86_64-linux-ld: drivers/net/wireless/ath/ath9k/gpio.o: in function
> `ath_deinit_leds':
> gpio.c:(.text+0x36): undefined reference to `led_classdev_unregister'
> x86_64-linux-ld: drivers/net/wireless/ath/ath9k/gpio.o: in function
> `ath_init_leds':
> gpio.c:(.text+0x179): undefined reference to `led_classdev_register_ext'
>
> The problem is that the 'imply' keyword does not enforce any dependency
> but is only a weak hint to Kconfig to enable another symbol from a
> defconfig file.
>
> Change imply to a 'depends on LEDS_CLASS' that prevents the incorrect
> configuration but still allows building the driver without LED support.
>
> The 'select MAC80211_LEDS' is now ensures that the LED support is
> actually used if it is present, and the added Kconfig dependency
> on MAC80211_LEDS ensures that it cannot be enabled manually when it
> has no effect.
But we do not want to have this dependency (selecting MAC80211_LEDS).
I fixed this problem here:
https://lore.kernel.org/lkml/20201227143034.1134829-1-k...@kernel.org/
Maybe let's take this approach?
Best regards,
Krzysztof
>
> Fixes: 197f466e93f5 ("ath9k_htc: Do not select MAC80211_LEDS by default")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/net/wireless/ath/ath9k/Kconfig | 8 ++--
> net/mac80211/Kconfig | 2 +-
> 2 files changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/Kconfig
> b/drivers/net/wireless/ath/ath9k/Kconfig
> index a84bb9b6573f..e150d82eddb6 100644
> --- a/drivers/net/wireless/ath/ath9k/Kconfig
> +++ b/drivers/net/wireless/ath/ath9k/Kconfig
> @@ -21,11 +21,9 @@ config ATH9K_BTCOEX_SUPPORT
> config ATH9K
> tristate "Atheros 802.11n wireless cards support"
> depends on MAC80211 && HAS_DMA
> + select MAC80211_LEDS if LEDS_CLASS=y || LEDS_CLASS=MAC80211
> select ATH9K_HW
> select ATH9K_COMMON
> - imply NEW_LEDS
> - imply LEDS_CLASS
> - imply MAC80211_LEDS
> help
> This module adds support for wireless adapters based on
> Atheros IEEE 802.11n AR5008, AR9001 and AR9002 family
> @@ -176,11 +174,9 @@ config ATH9K_PCI_NO_EEPROM
> config ATH9K_HTC
> tristate "Atheros HTC based wireless cards support"
> depends on USB && MAC80211
> + select MAC80211_LEDS if LEDS_CLASS=y || LEDS_CLASS=MAC80211
> select ATH9K_HW
> select ATH9K_COMMON
> - imply NEW_LEDS
> - imply LEDS_CLASS
> - imply MAC80211_LEDS
> help
> Support for Atheros HTC based cards.
> Chipsets supported: AR9271
> diff --git a/net/mac80211/Kconfig b/net/mac80211/Kconfig
> index cd9a9bd242ba..51ec8256b7fa 100644
> --- a/net/mac80211/Kconfig
> +++ b/net/mac80211/Kconfig
> @@ -69,7 +69,7 @@ config MAC80211_MESH
> config MAC80211_LEDS
> bool "Enable LED triggers"
> depends on MAC80211
> - depends on LEDS_CLASS
> + depends on LEDS_CLASS=y || LEDS_CLASS=MAC80211
> select LEDS_TRIGGERS
> help
> This option enables a few LED triggers for different
> --
> 2.29.2
>
Re: [PATCH v3 2/4] drm/qxl: unpin release objects
> > Just calling ttm_bo_unpin() here makes lockdep unhappy.
>
> How does that one splat? But yeah if that's a problem should be
> explained in the comment. I'd then also only do a pin_count--; to make
> sure you can still catch other pin leaks if you have them. Setting it
> to 0 kinda defeats the warning.
Figured the unpin is at the completely wrong place while trying to
reproduce the lockdep splat ...
take care,
Gerd
>From 43befab4a935114e8620af62781666fa81288255 Mon Sep 17 00:00:00 2001
From: Gerd Hoffmann
Date: Mon, 25 Jan 2021 13:10:50 +0100
Subject: [PATCH] drm/qxl: unpin release objects
Balances the qxl_create_bo(..., pinned=true, ...);
call in qxl_release_bo_alloc().
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_release.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/qxl/qxl_release.c
b/drivers/gpu/drm/qxl/qxl_release.c
index c52412724c26..28013fd1f8ea 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -347,6 +347,7 @@ int qxl_alloc_release_reserved(struct qxl_device *qdev,
unsigned long size,
mutex_lock(&qdev->release_mutex);
if (qdev->current_release_bo_offset[cur_idx] + 1 >=
releases_per_bo[cur_idx]) {
+ qxl_bo_unpin(qdev->current_release_bo[cur_idx]);
qxl_bo_unref(&qdev->current_release_bo[cur_idx]);
qdev->current_release_bo_offset[cur_idx] = 0;
qdev->current_release_bo[cur_idx] = NULL;
--
2.29.2
Re: [PATCH v3 18/21] dt-bindings: allwinner: Add H616 compatible strings
On Sun, 17 Jan 2021 22:28:47 -0600 Samuel Holland wrote: Hi, > On 1/17/21 8:08 PM, Andre Przywara wrote: > > Add simple "allwinner,sun50i-h616-xxx" compatible names to existing > > bindings, and pair them with an existing fallback compatible string, > > as the devices are compatible. > > This covers I2C, infrared, RTC and SPI. > > > > Use enums to group all compatible devices together. > > > > Signed-off-by: Andre Przywara > > Acked-by: Rob Herring > > Acked-by: Wolfram Sang # for I2C > > --- > > .../bindings/i2c/marvell,mv64xxx-i2c.yaml | 21 +++ > > .../media/allwinner,sun4i-a10-ir.yaml | 16 ++ > > .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 3 +++ > > .../bindings/spi/allwinner,sun6i-a31-spi.yaml | 1 + > > 4 files changed, 17 insertions(+), 24 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml > > b/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml > > index 5b5ae402f97a..eb72dd571def 100644 > > --- a/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml > > +++ b/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml > > @@ -18,21 +18,14 @@ properties: > >- const: allwinner,sun4i-a10-i2c > >- const: allwinner,sun6i-a31-i2c > >- items: > > - - const: allwinner,sun8i-a23-i2c > > + - enum: > > + - allwinner,sun8i-a23-i2c > > + - allwinner,sun8i-a83t-i2c > > + - allwinner,sun50i-a64-i2c > > + - allwinner,sun50i-a100-i2c > > + - allwinner,sun50i-h6-i2c > > + - allwinner,sun50i-h616-i2c > >- const: allwinner,sun6i-a31-i2c > > - - items: > > - - const: allwinner,sun8i-a83t-i2c > > - - const: allwinner,sun6i-a31-i2c > > - - items: > > - - const: allwinner,sun50i-a64-i2c > > - - const: allwinner,sun6i-a31-i2c > > - - items: > > - - const: allwinner,sun50i-a100-i2c > > - - const: allwinner,sun6i-a31-i2c > > - - items: > > - - const: allwinner,sun50i-h6-i2c > > - - const: allwinner,sun6i-a31-i2c > > - > >- const: marvell,mv64xxx-i2c > >- const: marvell,mv78230-i2c > >- const: marvell,mv78230-a0-i2c > > diff --git > > a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml > > b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml > > index 5fa19d4aeaf3..6d8395d6bca0 100644 > > --- a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml > > +++ b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml > > @@ -20,16 +20,12 @@ properties: > >- const: allwinner,sun5i-a13-ir > >- const: allwinner,sun6i-a31-ir > >- items: > > - - const: allwinner,sun8i-a83t-ir > > - - const: allwinner,sun6i-a31-ir > > - - items: > > - - const: allwinner,sun8i-r40-ir > > - - const: allwinner,sun6i-a31-ir > > - - items: > > - - const: allwinner,sun50i-a64-ir > > - - const: allwinner,sun6i-a31-ir > > - - items: > > - - const: allwinner,sun50i-h6-ir > > + - enum: > > + - allwinner,sun8i-a83t-ir > > + - allwinner,sun8i-r40-ir > > + - allwinner,sun50i-a64-ir > > + - allwinner,sun50i-h6-ir > > + - allwinner,sun50i-h616-ir > >- const: allwinner,sun6i-a31-ir > > > >reg: > > diff --git > > a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > > b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > > index 37c2a601c3fa..97928efd2bc9 100644 > > --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > > +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml > > @@ -26,6 +26,9 @@ properties: > >- const: allwinner,sun50i-a64-rtc > >- const: allwinner,sun8i-h3-rtc > >- const: allwinner,sun50i-h6-rtc > > + - items: > > + - const: allwinner,sun50i-h616-rtc > > + - const: allwinner,sun50i-h6-rtc > > Since H6, the RTC manages the 24 MHz DCXO, so it provides a fourth clock > output. If this is easy to change later, then it is fine for now, but > maybe it is better to get the H616 binding correct from the beginning? So you mean that RTC register +0x160 controls the system HOSC clock, so the main input clock for all the PLLs and other clocks? And by clearing bit 1 in there we can stop this? And if that is the case, do you suggest that we should model this in the DT, so that the fixed-clock "<&osc24M>" should be replaced with "<&rtc 3>"? So from a "the DT describes the hardware" point of view that would probably the right way, but not sure if Linux is happy about that. At the very least that would mean to extend the RTC driver to export a fourth clock, and all devices would now depend on the RTC (also
Re: [PATCH v3 00/17] KVM: x86/pmu: Add support to enable Guest PEBS via DS
On Mon, Jan 25, 2021 at 08:07:06PM +0800, Xu, Like wrote: > So under the premise that counter cross-mapping is allowed, > how can hypercall help fix it ? Hypercall or otherwise exposing the mapping, will let the guest fix it up when it already touches the data. Which avoids the host from having to access the guest memory and is faster, no?
[PATCH 4/4] perf vendor events arm64: Reference common and uarch events for A76
Reduce duplication in the JSONs by referencing standard events from
armv8-common-and-microarch.json
In general the "PublicDescription" fields are not modified when somewhat
significantly worded differently than the standard.
Apart from that, description and names for events slightly different to
standard are changed (to standard) for consistency.
Signed-off-by: John Garry
---
.../arch/arm64/arm/cortex-a76-n1/branch.json | 12 +-
.../arch/arm64/arm/cortex-a76-n1/bus.json | 19 ++-
.../arch/arm64/arm/cortex-a76-n1/cache.json | 118 ++
.../arm64/arm/cortex-a76-n1/exception.json| 10 +-
.../arm64/arm/cortex-a76-n1/instruction.json | 45 +++
.../arch/arm64/arm/cortex-a76-n1/memory.json | 6 +-
.../arch/arm64/arm/cortex-a76-n1/other.json | 4 +-
.../arm64/arm/cortex-a76-n1/pipeline.json | 12 +-
8 files changed, 76 insertions(+), 150 deletions(-)
diff --git a/tools/perf/pmu-events/arch/arm64/arm/cortex-a76-n1/branch.json
b/tools/perf/pmu-events/arch/arm64/arm/cortex-a76-n1/branch.json
index b5e5d055c70d..ec0dc92288ab 100644
--- a/tools/perf/pmu-events/arch/arm64/arm/cortex-a76-n1/branch.json
+++ b/tools/perf/pmu-events/arch/arm64/arm/cortex-a76-n1/branch.json
@@ -1,14 +1,10 @@
[
{
-"PublicDescription": "Mispredicted or not predicted branch
speculatively executed. This event counts any predictable branch instruction
which is mispredicted either due to dynamic misprediction or because the MMU is
off and the branches are statically predicted not taken.",
-"EventCode": "0x10",
-"EventName": "BR_MIS_PRED",
-"BriefDescription": "Mispredicted or not predicted branch
speculatively executed."
+"PublicDescription": "This event counts any predictable branch
instruction which is mispredicted either due to dynamic misprediction or
because the MMU is off and the branches are statically predicted not taken",
+"ArchStdEvent": "BR_MIS_PRED",
},
{
-"PublicDescription": "Predictable branch speculatively executed. This
event counts all predictable branches.",
-"EventCode": "0x12",
-"EventName": "BR_PRED",
-"BriefDescription": "Predictable branch speculatively executed."
+"PublicDescription": "This event counts all predictable branches.",
+"ArchStdEvent": "BR_PRED",
}
]
diff --git a/tools/perf/pmu-events/arch/arm64/arm/cortex-a76-n1/bus.json
b/tools/perf/pmu-events/arch/arm64/arm/cortex-a76-n1/bus.json
index fce7309ae624..6263929efce2 100644
--- a/tools/perf/pmu-events/arch/arm64/arm/cortex-a76-n1/bus.json
+++ b/tools/perf/pmu-events/arch/arm64/arm/cortex-a76-n1/bus.json
@@ -1,24 +1,21 @@
[
{
-"EventCode": "0x11",
-"EventName": "CPU_CYCLES",
+"PublicDescription": "The number of core clock cycles"
+"ArchStdEvent": "CPU_CYCLES",
"BriefDescription": "The number of core clock cycles."
},
{
-"PublicDescription": "Bus access. This event counts for every beat of
data transferred over the data channels between the core and the SCU. If both
read and write data beats are transferred on a given cycle, this event is
counted twice on that cycle. This event counts the sum of BUS_ACCESS_RD and
BUS_ACCESS_WR.",
-"EventCode": "0x19",
-"EventName": "BUS_ACCESS",
-"BriefDescription": "Bus access."
+"PublicDescription": "This event counts for every beat of data
transferred over the data channels between the core and the SCU. If both read
and write data beats are transferred on a given cycle, this event is counted
twice on that cycle. This event counts the sum of BUS_ACCESS_RD and
BUS_ACCESS_WR.",
+"ArchStdEvent": "BUS_ACCESS",
},
{
-"EventCode": "0x1D",
-"EventName": "BUS_CYCLES",
-"BriefDescription": "Bus cycles. This event duplicates CPU_CYCLES."
+"PublicDescription": "This event duplicates CPU_CYCLES."
+"ArchStdEvent": "BUS_CYCLES",
},
{
-"ArchStdEvent": "BUS_ACCESS_RD"
+"ArchStdEvent": "BUS_ACCESS_RD",
},
{
-"ArchStdEvent": "BUS_ACCESS_WR"
+"ArchStdEvent": "BUS_ACCESS_WR",
}
]
diff --git a/tools/perf/pmu-events/arch/arm64/arm/cortex-a76-n1/cache.json
b/tools/perf/pmu-events/arch/arm64/arm/cortex-a76-n1/cache.json
index 24594081c199..cd67bb9df139 100644
--- a/tools/perf/pmu-events/arch/arm64/arm/cortex-a76-n1/cache.json
+++ b/tools/perf/pmu-events/arch/arm64/arm/cortex-a76-n1/cache.json
@@ -1,133 +1,95 @@
[
{
-"PublicDescription": "L1 instruction cache refill. This event counts
any instruction fetch which misses in the cache.",
-"EventCode": "0x01",
-"EventName": "L1I_CACHE_REFILL",
-"BriefDescription": "L1 instruction cache refill"
+"PublicDescription": "This event counts any instruction fetch which
misses in the cache.",
+"ArchStdEvent": "L1I_CACHE_REFILL",
},
{
-"PublicDescr
[PATCH 2/4] perf vendor events arm64: Add common and uarch event JSON
Add a common and microarch JSON, which can be referenced from CPU JSONs.
For now, brief and public description are as event brief event
description from the ARMv8 ARM [0], D7-11.
The list of events is not complete, as not all events will be referenced
yet.
Reference document is at the following:
[0] https://documentation-service.arm.com/static/5fa3bd1eb209f547eebd4141?token=
Signed-off-by: John Garry
---
.../arm64/armv8-common-and-microarch.json | 248 ++
1 file changed, 248 insertions(+)
create mode 100644
tools/perf/pmu-events/arch/arm64/armv8-common-and-microarch.json
diff --git a/tools/perf/pmu-events/arch/arm64/armv8-common-and-microarch.json
b/tools/perf/pmu-events/arch/arm64/armv8-common-and-microarch.json
new file mode 100644
index ..430a023ccf6a
--- /dev/null
+++ b/tools/perf/pmu-events/arch/arm64/armv8-common-and-microarch.json
@@ -0,0 +1,248 @@
+[
+{
+"PublicDescription": "Instruction architecturally executed, Condition
code check pass, software increment",
+"EventCode": "0x00",
+"EventName": "SW_INCR",
+"BriefDescription": "Instruction architecturally executed, Condition
code check pass, software increment"
+},
+{
+"PublicDescription": "Level 1 instruction cache refill",
+"EventCode": "0x01",
+"EventName": "L1I_CACHE_REFILL",
+"BriefDescription": "Level 1 instruction cache refill"
+},
+{
+"PublicDescription": "Attributable Level 1 instruction TLB refill",
+"EventCode": "0x02",
+"EventName": "L1I_TLB_REFILL",
+"BriefDescription": "Attributable Level 1 instruction TLB refill"
+},
+{
+"PublicDescription": "Level 1 data cache refill",
+"EventCode": "0x03",
+"EventName": "L1D_CACHE_REFILL",
+"BriefDescription": "Level 1 data cache refill"
+},
+{
+"PublicDescription": "Level 1 data cache access",
+"EventCode": "0x04",
+"EventName": "L1D_CACHE",
+"BriefDescription": "Level 1 data cache access"
+},
+{
+"PublicDescription": "Attributable Level 1 data TLB refill",
+"EventCode": "0x05",
+"EventName": "L1D_TLB_REFILL",
+"BriefDescription": "Attributable Level 1 data TLB refill"
+},
+{
+"PublicDescription": "Instruction architecturally executed",
+"EventCode": "0x08",
+"EventName": "INST_RETIRED",
+"BriefDescription": "Instruction architecturally executed"
+},
+{
+"PublicDescription": "Exception taken",
+"EventCode": "0x09",
+"EventName": "EXC_TAKEN",
+"BriefDescription": "Exception taken"
+},
+{
+"PublicDescription": "Instruction architecturally executed, condition
check pass, exception return",
+"EventCode": "0x0a",
+"EventName": "EXC_RETURN",
+"BriefDescription": "Instruction architecturally executed, condition
check pass, exception return"
+},
+{
+"PublicDescription": "Instruction architecturally executed, condition
code check pass, write to CONTEXTIDR",
+"EventCode": "0x0b",
+"EventName": "CID_WRITE_RETIRED",
+"BriefDescription": "Instruction architecturally executed, condition
code check pass, write to CONTEXTIDR"
+},
+{
+"PublicDescription": "Mispredicted or not predicted branch
speculatively executed",
+"EventCode": "0x10",
+"EventName": "BR_MIS_PRED",
+"BriefDescription": "Mispredicted or not predicted branch
speculatively executed"
+},
+{
+"PublicDescription": "Cycle",
+"EventCode": "0x11",
+"EventName": "CPU_CYCLES",
+"BriefDescription": "Cycle"
+},
+{
+"PublicDescription": "Predictable branch speculatively executed",
+"EventCode": "0x12",
+"EventName": "BR_PRED",
+"BriefDescription": "Predictable branch speculatively executed"
+},
+{
+"PublicDescription": "Data memory access",
+"EventCode": "0x13",
+"EventName": "MEM_ACCESS",
+"BriefDescription": "Data memory access"
+},
+{
+"PublicDescription": "Attributable Level 1 instruction cache access",
+"EventCode": "0x14",
+"EventName": "L1I_CACHE",
+"BriefDescription": "Attributable Level 1 instruction cache access"
+},
+{
+"PublicDescription": "Attributable Level 1 data cache write-back",
+"EventCode": "0x15",
+"EventName": "L1D_CACHE_WB",
+"BriefDescription": "Attributable Level 1 data cache write-back"
+},
+{
+"PublicDescription": "Level 2 data cache access",
+"EventCode": "0x16",
+"EventName": "L2D_CACHE",
+"BriefDescription": "Level 2 data cache access"
+},
+{
+"PublicDescription": "Level 2 data refill",
+"EventCode": "0x17",
+"EventName": "L2D_CACHE_REFILL",
+"BriefDescription": "Level 2 data re
[PATCH v3] iio: adc: stm32-adc: enable timestamping for non-DMA usage
For non-DMA usage, we have an easy way to associate a timestamp with a
sample: iio_pollfunc_store_time stores a timestamp in the primary
trigger IRQ handler and stm32_adc_trigger_handler runs in the IRQ thread
to push out the buffer along with the timestamp.
For this to work, the driver needs to register an IIO_TIMESTAMP channel.
Do this.
For DMA, it's not as easy, because we don't push the buffers out of
stm32_adc_trigger, but out of stm32_adc_dma_buffer_done, which runs in
a tasklet scheduled after a DMA completion.
Preferably, the DMA controller would copy us the timestamp into that buffer
as well. Until this is implemented, restrict timestamping support to
only PIO. For low-frequency sampling, PIO is probably good enough.
Cc: Holger Assmann
Acked-by: Fabrice Gasnier
Signed-off-by: Ahmad Fatoum
---
v2 -> v3:
- explicitly specify alignment (Jonathan)
- increase buffer size to hold additional timestamp
v1 -> v2:
- Added comment about timestamping being PIO only (Fabrice)
- Added missing DMA resource clean up in error path (Fabrice)
- Added Fabrice's Acked-by
---
drivers/iio/adc/stm32-adc.c | 39 +
1 file changed, 31 insertions(+), 8 deletions(-)
diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c
index c067c994dae2..ab2f440d7afb 100644
--- a/drivers/iio/adc/stm32-adc.c
+++ b/drivers/iio/adc/stm32-adc.c
@@ -177,7 +177,7 @@ struct stm32_adc_cfg {
* @offset:ADC instance register offset in ADC block
* @cfg: compatible configuration data
* @completion:end of single conversion completion
- * @buffer:data buffer
+ * @buffer:data buffer + 8 bytes for timestamp if enabled
* @clk: clock for this adc instance
* @irq: interrupt for this adc instance
* @lock: spinlock
@@ -200,7 +200,7 @@ struct stm32_adc {
u32 offset;
const struct stm32_adc_cfg *cfg;
struct completion completion;
- u16 buffer[STM32_ADC_MAX_SQ];
+ u16 buffer[STM32_ADC_MAX_SQ + 8] __aligned(8);
struct clk *clk;
int irq;
spinlock_t lock; /* interrupt lock */
@@ -1718,7 +1718,7 @@ static void stm32_adc_chan_init_one(struct iio_dev
*indio_dev,
}
}
-static int stm32_adc_chan_of_init(struct iio_dev *indio_dev)
+static int stm32_adc_chan_of_init(struct iio_dev *indio_dev, bool timestamping)
{
struct device_node *node = indio_dev->dev.of_node;
struct stm32_adc *adc = iio_priv(indio_dev);
@@ -1766,6 +1766,9 @@ static int stm32_adc_chan_of_init(struct iio_dev
*indio_dev)
return -EINVAL;
}
+ if (timestamping)
+ num_channels++;
+
channels = devm_kcalloc(&indio_dev->dev, num_channels,
sizeof(struct iio_chan_spec), GFP_KERNEL);
if (!channels)
@@ -1816,6 +1819,19 @@ static int stm32_adc_chan_of_init(struct iio_dev
*indio_dev)
stm32_adc_smpr_init(adc, channels[i].channel, smp);
}
+ if (timestamping) {
+ struct iio_chan_spec *timestamp = &channels[scan_index];
+
+ timestamp->type = IIO_TIMESTAMP;
+ timestamp->channel = -1;
+ timestamp->scan_index = scan_index;
+ timestamp->scan_type.sign = 's';
+ timestamp->scan_type.realbits = 64;
+ timestamp->scan_type.storagebits = 64;
+
+ scan_index++;
+ }
+
indio_dev->num_channels = scan_index;
indio_dev->channels = channels;
@@ -1875,6 +1891,7 @@ static int stm32_adc_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
irqreturn_t (*handler)(int irq, void *p) = NULL;
struct stm32_adc *adc;
+ bool timestamping = false;
int ret;
if (!pdev->dev.of_node)
@@ -1931,16 +1948,22 @@ static int stm32_adc_probe(struct platform_device *pdev)
if (ret < 0)
return ret;
- ret = stm32_adc_chan_of_init(indio_dev);
- if (ret < 0)
- return ret;
-
ret = stm32_adc_dma_request(dev, indio_dev);
if (ret < 0)
return ret;
- if (!adc->dma_chan)
+ if (!adc->dma_chan) {
+ /* For PIO mode only, iio_pollfunc_store_time stores a timestamp
+* in the primary trigger IRQ handler and
stm32_adc_trigger_handler
+* runs in the IRQ thread to push out buffer along with
timestamp.
+*/
handler = &stm32_adc_trigger_handler;
+ timestamping = true;
+ }
+
+ ret = stm32_adc_chan_of_init(indio_dev, timestamping);
+ if (ret < 0)
+ goto err_dma_disable;
ret = iio_triggered_buffer_setup(indio_dev,
[PATCH v3] x86/perf: Use static_call for x86_pmu.guest_get_msrs
Clean up that CONFIG_RETPOLINE crud and replace the
indirect call x86_pmu.guest_get_msrs with static_call().
Suggested-by: Peter Zijlstra (Intel)
Reported-by: kernel test robot
Signed-off-by: Like Xu
---
v2->v3 Changelog:
- fix compiler warning from [-Wmissing-prototypes]
v1->v2 Changelog:
- fix compiler error from redifinition
arch/x86/events/core.c| 20
arch/x86/events/intel/core.c | 20
arch/x86/include/asm/perf_event.h | 6 +-
3 files changed, 21 insertions(+), 25 deletions(-)
diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index e37de298a495..cf0a52c80408 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -81,6 +81,8 @@ DEFINE_STATIC_CALL_NULL(x86_pmu_swap_task_ctx,
*x86_pmu.swap_task_ctx);
DEFINE_STATIC_CALL_NULL(x86_pmu_drain_pebs, *x86_pmu.drain_pebs);
DEFINE_STATIC_CALL_NULL(x86_pmu_pebs_aliases, *x86_pmu.pebs_aliases);
+DEFINE_STATIC_CALL_NULL(x86_pmu_guest_get_msrs, *x86_pmu.guest_get_msrs);
+
u64 __read_mostly hw_cache_event_ids
[PERF_COUNT_HW_CACHE_MAX]
[PERF_COUNT_HW_CACHE_OP_MAX]
@@ -665,6 +667,12 @@ void x86_pmu_disable_all(void)
}
}
+struct perf_guest_switch_msr *perf_guest_get_msrs(int *nr)
+{
+ return static_call(x86_pmu_guest_get_msrs)(nr);
+}
+EXPORT_SYMBOL_GPL(perf_guest_get_msrs);
+
/*
* There may be PMI landing after enabled=0. The PMI hitting could be before or
* after disable_all.
@@ -1923,6 +1931,8 @@ static void x86_pmu_static_call_update(void)
static_call_update(x86_pmu_drain_pebs, x86_pmu.drain_pebs);
static_call_update(x86_pmu_pebs_aliases, x86_pmu.pebs_aliases);
+
+ static_call_update(x86_pmu_guest_get_msrs, x86_pmu.guest_get_msrs);
}
static void _x86_pmu_read(struct perf_event *event)
@@ -1930,6 +1940,13 @@ static void _x86_pmu_read(struct perf_event *event)
x86_perf_event_update(event);
}
+static inline struct perf_guest_switch_msr *
+perf_guest_get_msrs_nop(int *nr)
+{
+ *nr = 0;
+ return NULL;
+}
+
static int __init init_hw_perf_events(void)
{
struct x86_pmu_quirk *quirk;
@@ -2001,6 +2018,9 @@ static int __init init_hw_perf_events(void)
if (!x86_pmu.read)
x86_pmu.read = _x86_pmu_read;
+ if (!x86_pmu.guest_get_msrs)
+ x86_pmu.guest_get_msrs = perf_guest_get_msrs_nop;
+
x86_pmu_static_call_update();
/*
diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index d4569bfa83e3..93adf53cce5f 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -3680,26 +3680,6 @@ static int intel_pmu_hw_config(struct perf_event *event)
return 0;
}
-#ifdef CONFIG_RETPOLINE
-static struct perf_guest_switch_msr *core_guest_get_msrs(int *nr);
-static struct perf_guest_switch_msr *intel_guest_get_msrs(int *nr);
-#endif
-
-struct perf_guest_switch_msr *perf_guest_get_msrs(int *nr)
-{
-#ifdef CONFIG_RETPOLINE
- if (x86_pmu.guest_get_msrs == intel_guest_get_msrs)
- return intel_guest_get_msrs(nr);
- else if (x86_pmu.guest_get_msrs == core_guest_get_msrs)
- return core_guest_get_msrs(nr);
-#endif
- if (x86_pmu.guest_get_msrs)
- return x86_pmu.guest_get_msrs(nr);
- *nr = 0;
- return NULL;
-}
-EXPORT_SYMBOL_GPL(perf_guest_get_msrs);
-
static struct perf_guest_switch_msr *intel_guest_get_msrs(int *nr)
{
struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events);
diff --git a/arch/x86/include/asm/perf_event.h
b/arch/x86/include/asm/perf_event.h
index b9a7fd0a27e2..e2a4c785e4e3 100644
--- a/arch/x86/include/asm/perf_event.h
+++ b/arch/x86/include/asm/perf_event.h
@@ -483,11 +483,7 @@ static inline void perf_check_microcode(void) { }
extern struct perf_guest_switch_msr *perf_guest_get_msrs(int *nr);
extern int x86_perf_get_lbr(struct x86_pmu_lbr *lbr);
#else
-static inline struct perf_guest_switch_msr *perf_guest_get_msrs(int *nr)
-{
- *nr = 0;
- return NULL;
-}
+struct perf_guest_switch_msr *perf_guest_get_msrs(int *nr);
static inline int x86_perf_get_lbr(struct x86_pmu_lbr *lbr)
{
return -1;
--
2.29.2
Re: [PATCH v3 0/5] Scan for an idle sibling in a single pass
On 2021/1/25 17:04, Mel Gorman wrote: > On Mon, Jan 25, 2021 at 12:29:47PM +0800, Li, Aubrey wrote: > hackbench -l 2560 -g 1 on 8 cores arm64 > v5.11-rc4 : 1.355 (+/- 7.96) > + sis improvement : 1.923 (+/- 25%) > + the patch below : 1.332 (+/- 4.95) > > hackbench -l 2560 -g 256 on 8 cores arm64 > v5.11-rc4 : 2.116 (+/- 4.62%) > + sis improvement : 2.216 (+/- 3.84%) > + the patch below : 2.113 (+/- 3.01%) > >> >> 4 benchmarks reported out during weekend, with patch 3 on a x86 4s system >> with 24 cores per socket and 2 HT per core, total 192 CPUs. >> >> It looks like mid-load has notable changes on my side: >> - netperf 50% num of threads in TCP mode has 27.25% improved >> - tbench 50% num of threads has 9.52% regression >> > > It's interesting that patch 3 would make any difference on x64 given that > it's SMT2. The scan depth should have been similar. It's somewhat expected > that it will not be a universal win, particularly once the utilisation > is high enough to spill over in sched domains (25%, 50%, 75% utilisation > being interesting on 4-socket systems). In such cases, double scanning can > still show improvements for workloads that idle rapidly like tbench and > hackbench even though it's expensive. The extra scanning gives more time > for a CPU to go idle enough to be selected which can improve throughput > but at the cost of wake-up latency, aha, sorry for the confusion. Since you and Vincent discussed to drop patch3, I just mentioned I tested 5 patches with patch3, not patch3 alone. > > Hopefully v4 can be tested as well which is now just a single scan. > Sure, may I know the baseline of v4? Thanks, -Aubrey
[PATCH] i915: Fix DRM_I915_WERROR dependencies
From: Arnd Bergmann
CONFIG_DRM_I915_DEBUG now selects CONFIG_DRM_I915_WERROR, but fails
to honor its dependencies:
WARNING: unmet direct dependencies detected for DRM_I915_WERROR
Depends on [n]: HAS_IOMEM [=y] && DRM_I915 [=m] && EXPERT [=y] &&
!COMPILE_TEST [=y]
Selected by [m]:
- DRM_I915_DEBUG [=y] && HAS_IOMEM [=y] && EXPERT [=y] && DRM_I915 [=m]
Change the 'select' to a conditional one that doesn't trigger -Werror
warnings for allmodconfig builds and other compile tests.
Fixes: 4f86975f539d ("drm/i915: Add DEBUG_GEM to the recommended CI config")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/i915/Kconfig.debug | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index be76054c01d8..97793b28d007 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -31,9 +31,9 @@ config DRM_I915_DEBUG
select DRM_DEBUG_SELFTEST
select DMABUF_SELFTESTS
select SW_SYNC # signaling validation framework (igt/syncobj*)
- select DRM_I915_WERROR
- select DRM_I915_DEBUG_GEM
- select DRM_I915_DEBUG_GEM_ONCE
+ select DRM_I915_WERROR if !COMPILE_TEST
+ select DRM_I915_DEBUG_GEM if !COMPILE_TEST
+ select DRM_I915_DEBUG_GEM_ONCE if !COMPILE_TEST
select DRM_I915_DEBUG_MMIO
select DRM_I915_DEBUG_RUNTIME_PM
select DRM_I915_SW_FENCE_DEBUG_OBJECTS
--
2.29.2
Re: [PATCH] kasan: export kasan_poison
On 1/25/21 11:28 AM, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The unit test module fails to build after adding a reference
> to kasan_poison:
>
> ERROR: modpost: "kasan_poison" [lib/test_kasan.ko] undefined!
>
> Export this symbol to make it available to loadable modules.
>
> Fixes: b9b322c2bba9 ("kasan: add match-all tag tests")
> Signed-off-by: Arnd Bergmann
Thanks I just stumbled on the same issue ;)
Reviewed-by: Vincenzo Frascino
> ---
> mm/kasan/shadow.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/mm/kasan/shadow.c b/mm/kasan/shadow.c
> index de6b3f074742..32e7a5c148e6 100644
> --- a/mm/kasan/shadow.c
> +++ b/mm/kasan/shadow.c
> @@ -94,6 +94,7 @@ void kasan_poison(const void *address, size_t size, u8
> value)
>
> __memset(shadow_start, value, shadow_end - shadow_start);
> }
> +EXPORT_SYMBOL_GPL(kasan_poison);
>
> void kasan_unpoison(const void *address, size_t size)
> {
>
--
Regards,
Vincenzo
[PATCH] PCI: endpoint: Select configfs dependency
From: Arnd Bergmann
The newly added pci-epf-ntb driver uses configfs, which
causes a link failure when that is disabled at compile-time:
arm-linux-gnueabi-ld: drivers/pci/endpoint/functions/pci-epf-ntb.o: in function
`epf_ntb_add_cfs':
pci-epf-ntb.c:(.text+0x954): undefined reference to
`config_group_init_type_name'
Add a 'select' statement to Kconfig to ensure it's always there,
which is the common way to enable it for other configfs users.
Fixes: 7dc64244f9e9 ("PCI: endpoint: Add EP function driver to provide NTB
functionality")
Signed-off-by: Arnd Bergmann
---
drivers/pci/endpoint/functions/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pci/endpoint/functions/Kconfig
b/drivers/pci/endpoint/functions/Kconfig
index 24bfb2af65a1..5d35fcd613ef 100644
--- a/drivers/pci/endpoint/functions/Kconfig
+++ b/drivers/pci/endpoint/functions/Kconfig
@@ -16,6 +16,7 @@ config PCI_EPF_TEST
config PCI_EPF_NTB
tristate "PCI Endpoint NTB driver"
depends on PCI_ENDPOINT
+ select CONFIGFS_FS
help
Select this configuration option to enable the NTB driver
for PCI Endpoint. NTB driver implements NTB controller
--
2.29.2
[RFC v3 net-next] net: core: devlink: add 'dropped' stats field for DROP trap action
Whenever query statistics is issued for trap with DROP action,
devlink subsystem would also fill-in statistics 'dropped' field.
In case if device driver did't register callback for hard drop
statistics querying, 'dropped' field will be omitted and not filled.
Add trap_drop_counter_get callback implementation to the netdevsim.
Add new test cases for netdevsim, to test both the callback
functionality, as well as drop statistics alteration check.
Signed-off-by: Oleksandr Mazur
---
V3:
1) Mark subject as RFC instead of PATCH.
V2:
1) Change commit description / subject.
2) Remove HARD_DROP action.
3) Remove devlink UAPI changes.
4) Rename hard statistics get callback to be 'trap_drop_counter_get'
5) Make callback get called for existing trap action - DROP:
whenever statistics for trap with DROP action is queried,
devlink subsystem would call-in callback to get stats from HW;
6) Add changes to the netdevsim support implemented changes
(as well as changes to make it possible to test netdevsim with
these changes).
7) Add new test cases to the netdevsim's kselftests to test new
changes provided with this patchset;
Test-results:
# selftests: drivers/net/netdevsim: devlink_trap.sh
# TEST: Initialization[ OK ]
# TEST: Trap action [ OK ]
# TEST: Trap metadata [ OK ]
# TEST: Non-existing trap [ OK ]
# TEST: Non-existing trap action [ OK ]
# TEST: Trap statistics [ OK ]
# TEST: Trap group action [ OK ]
# TEST: Non-existing trap group [ OK ]
# TEST: Trap group statistics [ OK ]
# TEST: Trap policer [ OK ]
# TEST: Trap policer binding [ OK ]
# TEST: Port delete [ OK ]
# TEST: Device delete [ OK ]
ok 1 selftests: drivers/net/netdevsim: devlink_trap.sh
drivers/net/netdevsim/dev.c | 21 +++
drivers/net/netdevsim/netdevsim.h | 1 +
include/net/devlink.h | 10
net/core/devlink.c| 55 +--
.../drivers/net/netdevsim/devlink_trap.sh | 10
.../selftests/net/forwarding/devlink_lib.sh | 26 +
6 files changed, 119 insertions(+), 4 deletions(-)
diff --git a/drivers/net/netdevsim/dev.c b/drivers/net/netdevsim/dev.c
index 816af1f55e2c..1fc8c7a2a1e3 100644
--- a/drivers/net/netdevsim/dev.c
+++ b/drivers/net/netdevsim/dev.c
@@ -231,6 +231,9 @@ static int nsim_dev_debugfs_init(struct nsim_dev *nsim_dev)
debugfs_create_bool("fail_trap_policer_counter_get", 0600,
nsim_dev->ddir,
&nsim_dev->fail_trap_policer_counter_get);
+ debugfs_create_bool("fail_trap_drop_counter_get", 0600,
+ nsim_dev->ddir,
+ &nsim_dev->fail_trap_drop_counter_get);
nsim_udp_tunnels_debugfs_create(nsim_dev);
return 0;
}
@@ -416,6 +419,7 @@ struct nsim_trap_data {
struct delayed_work trap_report_dw;
struct nsim_trap_item *trap_items_arr;
u64 *trap_policers_cnt_arr;
+ u64 trap_hard_drop_cnt;
struct nsim_dev *nsim_dev;
spinlock_t trap_lock; /* Protects trap_items_arr */
};
@@ -892,6 +896,22 @@ nsim_dev_devlink_trap_policer_counter_get(struct devlink
*devlink,
return 0;
}
+int nsim_dev_devlink_trap_drop_counter_get(struct devlink *devlink,
+ const struct devlink_trap *trap,
+ u64 *p_drops)
+{
+ struct nsim_dev *nsim_dev = devlink_priv(devlink);
+ u64 *cnt;
+
+ if (nsim_dev->fail_trap_drop_counter_get)
+ return -EINVAL;
+
+ cnt = &nsim_dev->trap_data->trap_hard_drop_cnt;
+ *p_drops = (*cnt)++;
+
+ return 0;
+}
+
static const struct devlink_ops nsim_dev_devlink_ops = {
.supported_flash_update_params = DEVLINK_SUPPORT_FLASH_UPDATE_COMPONENT
|
DEVLINK_SUPPORT_FLASH_UPDATE_OVERWRITE_MASK,
@@ -905,6 +925,7 @@ static const struct devlink_ops nsim_dev_devlink_ops = {
.trap_group_set = nsim_dev_devlink_trap_group_set,
.trap_policer_set = nsim_dev_devlink_trap_policer_set,
.trap_policer_counter_get = nsim_dev_devlink_trap_policer_counter_get,
+ .trap_drop_counter_get = nsim_dev_devlink_trap_drop_counter_get,
};
#define NSIM_DEV_MAX_MACS_DEFAULT 32
diff --git a/drivers/net/netdevsim/netdevsim.h
b/drivers/ne
Re: [PATCH net-next] net: core: devlink: add new trap action HARD_DROP
Thu, Jan 21, 2021 at 06:36:05PM CET, k...@kernel.org wrote: >On Thu, 21 Jan 2021 14:21:52 +0200 Ido Schimmel wrote: >> On Thu, Jan 21, 2021 at 01:29:37PM +0200, Oleksandr Mazur wrote: >> > Add new trap action HARD_DROP, which can be used by the >> > drivers to register traps, where it's impossible to get >> > packet reported to the devlink subsystem by the device >> > driver, because it's impossible to retrieve dropped packet >> > from the device itself. >> > In order to use this action, driver must also register >> > additional devlink operation - callback that is used >> > to retrieve number of packets that have been dropped by >> > the device. >> >> Are these global statistics about number of packets the hardware dropped >> for a specific reason or are these per-port statistics? >> >> It's a creative use of devlink-trap interface, but I think it makes >> sense. Better to re-use an existing interface than creating yet another >> one. > >Not sure if I agree, if we can't trap why is it a trap? >It's just a counter. >+1 Device might be unable to trap only the 'DROP' packets, and this information should be transparent for the user. I agree on the statement, that new action might be an overhead. I could continue on with the solution Ido Schimmel proposed: since no new action would be needed and no UAPI changes are required, i could simply do the dropped statistics (additional field) output added upon trap stats queiring. (In case if driver registerd callback, of course; and do so only for DROP actions)
[RFC PATCH v3 09/13] virtio/vsock: add SEQPACKET receive logic
This modifies current receive logic for SEQPACKET support:
1) Inserts 'SEQ_BEGIN' packet to socket's rx queue.
2) Inserts 'RW' packet to socket's rx queue, but without merging with
buffer of last packet in queue.
3) Performs check for packet and socket types on receive(if mismatch,
then reset connection).
Signed-off-by: Arseny Krasnov
---
net/vmw_vsock/virtio_transport_common.c | 79 ++---
1 file changed, 58 insertions(+), 21 deletions(-)
diff --git a/net/vmw_vsock/virtio_transport_common.c
b/net/vmw_vsock/virtio_transport_common.c
index dcce35d7b462..90f9feef9d8f 100644
--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -397,6 +397,14 @@ virtio_transport_stream_do_dequeue(struct vsock_sock *vsk,
return err;
}
+static u16 virtio_transport_get_type(struct sock *sk)
+{
+ if (sk->sk_type == SOCK_STREAM)
+ return VIRTIO_VSOCK_TYPE_STREAM;
+ else
+ return VIRTIO_VSOCK_TYPE_SEQPACKET;
+}
+
static inline void virtio_transport_del_n_free_pkt(struct virtio_vsock_pkt
*pkt)
{
list_del(&pkt->list);
@@ -1050,39 +1058,49 @@ virtio_transport_recv_enqueue(struct vsock_sock *vsk,
struct virtio_vsock_pkt *pkt)
{
struct virtio_vsock_sock *vvs = vsk->trans;
- bool can_enqueue, free_pkt = false;
+ bool free_pkt = false;
pkt->len = le32_to_cpu(pkt->hdr.len);
pkt->off = 0;
spin_lock_bh(&vvs->rx_lock);
- can_enqueue = virtio_transport_inc_rx_pkt(vvs, pkt);
- if (!can_enqueue) {
+ if (!virtio_transport_inc_rx_pkt(vvs, pkt)) {
free_pkt = true;
goto out;
}
- /* Try to copy small packets into the buffer of last packet queued,
-* to avoid wasting memory queueing the entire buffer with a small
-* payload.
-*/
- if (pkt->len <= GOOD_COPY_LEN && !list_empty(&vvs->rx_queue)) {
- struct virtio_vsock_pkt *last_pkt;
+ switch (le16_to_cpu(pkt->hdr.type)) {
+ case VIRTIO_VSOCK_TYPE_STREAM: {
+ /* Try to copy small packets into the buffer of last packet
queued,
+* to avoid wasting memory queueing the entire buffer with a
small
+* payload.
+*/
+ if (pkt->len <= GOOD_COPY_LEN && !list_empty(&vvs->rx_queue)) {
+ struct virtio_vsock_pkt *last_pkt;
- last_pkt = list_last_entry(&vvs->rx_queue,
- struct virtio_vsock_pkt, list);
+ last_pkt = list_last_entry(&vvs->rx_queue,
+ struct virtio_vsock_pkt,
list);
- /* If there is space in the last packet queued, we copy the
-* new packet in its buffer.
-*/
- if (pkt->len <= last_pkt->buf_len - last_pkt->len) {
- memcpy(last_pkt->buf + last_pkt->len, pkt->buf,
- pkt->len);
- last_pkt->len += pkt->len;
- free_pkt = true;
- goto out;
+ /* If there is space in the last packet queued, we copy
the
+* new packet in its buffer.
+*/
+ if (pkt->len <= last_pkt->buf_len - last_pkt->len) {
+ memcpy(last_pkt->buf + last_pkt->len, pkt->buf,
+ pkt->len);
+ last_pkt->len += pkt->len;
+ free_pkt = true;
+ goto out;
+ }
}
+
+ break;
+ }
+ case VIRTIO_VSOCK_TYPE_SEQPACKET: {
+ break;
+ }
+ default:
+ goto out;
}
list_add_tail(&pkt->list, &vvs->rx_queue);
@@ -1101,6 +1119,14 @@ virtio_transport_recv_connected(struct sock *sk,
int err = 0;
switch (le16_to_cpu(pkt->hdr.op)) {
+ case VIRTIO_VSOCK_OP_SEQ_BEGIN: {
+ struct virtio_vsock_sock *vvs = vsk->trans;
+
+ spin_lock_bh(&vvs->rx_lock);
+ list_add_tail(&pkt->list, &vvs->rx_queue);
+ spin_unlock_bh(&vvs->rx_lock);
+ return err;
+ }
case VIRTIO_VSOCK_OP_RW:
virtio_transport_recv_enqueue(vsk, pkt);
sk->sk_data_ready(sk);
@@ -1247,6 +1273,12 @@ virtio_transport_recv_listen(struct sock *sk, struct
virtio_vsock_pkt *pkt,
return 0;
}
+static bool virtio_transport_valid_type(u16 type)
+{
+ return (type == VIRTIO_VSOCK_TYPE_STREAM) ||
+ (type == VIRTIO_VSOCK_TYPE_SEQPACKET);
+}
+
/* We are under the virtio-vsock's vsock->rx_lock or vhost-vsock's vq->mutex
* lock.
*/
@@ -1272,7 +1304,7 @@ void virtio_transport_recv_pk
[PATCH] blk: wbt: remove unused parameter from wbt_should_throttle
From: Lei Chen
The first parameter rwb is not used for this function.
So just remove it.
Signed-off-by: Lei Chen
---
block/blk-wbt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/block/blk-wbt.c b/block/blk-wbt.c
index 0321ca8..42aed01 100644
--- a/block/blk-wbt.c
+++ b/block/blk-wbt.c
@@ -518,7 +518,7 @@ static void __wbt_wait(struct rq_wb *rwb, enum wbt_flags
wb_acct,
rq_qos_wait(rqw, &data, wbt_inflight_cb, wbt_cleanup_cb);
}
-static inline bool wbt_should_throttle(struct rq_wb *rwb, struct bio *bio)
+static inline bool wbt_should_throttle(struct bio *bio)
{
switch (bio_op(bio)) {
case REQ_OP_WRITE:
@@ -545,7 +545,7 @@ static enum wbt_flags bio_to_wbt_flags(struct rq_wb *rwb,
struct bio *bio)
if (bio_op(bio) == REQ_OP_READ) {
flags = WBT_READ;
- } else if (wbt_should_throttle(rwb, bio)) {
+ } else if (wbt_should_throttle(bio)) {
if (current_is_kswapd())
flags |= WBT_KSWAPD;
if (bio_op(bio) == REQ_OP_DISCARD)
--
1.8.3.1
[RFC 1/3] bitfield: build kunit tests without structleak plugin
From: Arnd Bergmann The structleak plugin causes the stack frame size to grow immensely: lib/bitfield_kunit.c: In function 'test_bitfields_constants': lib/bitfield_kunit.c:93:1: error: the frame size of 7440 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] Turn it off in this file. Signed-off-by: Arnd Bergmann --- lib/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/Makefile b/lib/Makefile index b5307d3eec1a..6a7300f0f02f 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -348,6 +348,7 @@ obj-$(CONFIG_PLDMFW) += pldmfw/ # KUnit tests obj-$(CONFIG_BITFIELD_KUNIT) += bitfield_kunit.o +CFLAGS_REMOVE_bitfield_kunit.o += -fplugin-arg-structleak_plugin-byref -fplugin-arg-structleak_plugin-byref-all obj-$(CONFIG_LIST_KUNIT_TEST) += list-test.o obj-$(CONFIG_LINEAR_RANGES_TEST) += test_linear_ranges.o obj-$(CONFIG_BITS_TEST) += test_bits.o -- 2.29.2
[RFC 2/3] drivers/base: build kunit tests without structleak plugin
From: Arnd Bergmann The structleak plugin causes the stack frame size to grow immensely: drivers/base/test/property-entry-test.c: In function 'pe_test_reference': drivers/base/test/property-entry-test.c:481:1: error: the frame size of 2640 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] 481 | } | ^ drivers/base/test/property-entry-test.c: In function 'pe_test_uints': drivers/base/test/property-entry-test.c:99:1: error: the frame size of 2592 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] Turn it off in this file. Signed-off-by: Arnd Bergmann --- drivers/base/test/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/base/test/Makefile b/drivers/base/test/Makefile index 3ca56367c84b..2f15fae8625f 100644 --- a/drivers/base/test/Makefile +++ b/drivers/base/test/Makefile @@ -2,3 +2,4 @@ obj-$(CONFIG_TEST_ASYNC_DRIVER_PROBE) += test_async_driver_probe.o obj-$(CONFIG_KUNIT_DRIVER_PE_TEST) += property-entry-test.o +CFLAGS_REMOVE_property-entry-test.o += -fplugin-arg-structleak_plugin-byref -fplugin-arg-structleak_plugin-byref-all -- 2.29.2
Re: [PATCH v2 04/16] rpmsg: ctrl: implement the ioctl function to create device
Hi Mathieu,
On 1/22/21 9:59 PM, Mathieu Poirier wrote:
> On Fri, Jan 22, 2021 at 02:05:27PM +0100, Arnaud POULIQUEN wrote:
>> Hi Mathieu,
>>
>> On 1/22/21 12:52 AM, Mathieu Poirier wrote:
>>> On Tue, Dec 22, 2020 at 11:57:14AM +0100, Arnaud Pouliquen wrote:
Implement the ioctl function that parses the list of
rpmsg drivers registered to create an associated device.
To be ISO user API, in a first step, the driver_override
is only allowed for the RPMsg raw service, supported by the
rpmsg_char driver.
Signed-off-by: Arnaud Pouliquen
---
drivers/rpmsg/rpmsg_ctrl.c | 43 --
1 file changed, 41 insertions(+), 2 deletions(-)
diff --git a/drivers/rpmsg/rpmsg_ctrl.c b/drivers/rpmsg/rpmsg_ctrl.c
index 065e2e304019..8381b5b2b794 100644
--- a/drivers/rpmsg/rpmsg_ctrl.c
+++ b/drivers/rpmsg/rpmsg_ctrl.c
@@ -56,12 +56,51 @@ static int rpmsg_ctrl_dev_open(struct inode *inode,
struct file *filp)
return 0;
}
+static const char *rpmsg_ctrl_get_drv_name(u32 service)
+{
+ struct rpmsg_ctl_info *drv_info;
+
+ list_for_each_entry(drv_info, &rpmsg_drv_list, node) {
+ if (drv_info->ctrl->service == service)
+ return drv_info->ctrl->drv_name;
+ }
+
>>>
>>> I'm unsure about the above... To me this looks like what the .match()
>>> function
>>> of a bus would do. And when I read Bjorn's comment he brought up the
>>> auxiliary_bus. I don't know about the auxiliary_bus but it is worth looking
>>> into. Registering with a bus would streamline a lot of the code in this
>>> patchset.
>>
>> As answered Bjorn, we already have the RPMsg bus to manage the rpmsg devices.
>> Look like duplication from my POV, except if the IOCTL does not manage
>> channel
>> but only endpoint.
>>
>> In my design I considered that the rpmsg_ctrl creates a channel associated
>> to a
>> rpmsg_device such as the RPMsg ns_announcement.
>>
>> Based on this assumption, if we implement the auxiliary_bus (or other) for
>> the
>> rpmsg_ctrl a RPMsg driver will have to manage the probe by rpmsg_bus and by
>> the
>> auxillary bus. The probe from the auxiliary bus would lead to the creation
>> of an
>> RPMsg device on the rpmsg_bus, so a duplication with cross dependencies and
>> would probably make tricky the remove part.
>>
>> That said, I think the design depends on the functionality that should be
>> implemented in the rpmsg_ctrl. Here is an alternative approach based on the
>> auxiliary bus, which I'm starting to think about:
>>
>> The current approach of the rpmsg_char driver is to use the IOCTRL interface
>> to
>> instantiate a cdev with an endpoint (the RPMsg device is associated with the
>> ioctl dev). This would correspond to the use of an auxiliary bus to manage
>> local
>> endpoint creations.
>>
>> We could therefore consider an RPMsg name service based on an RPmsg device.
>> This
>> RPMsg device would register a kind of "RPMsg service endpoint" driver on the
>> auxiliary rpmsg_ioctl bus.
>> The rpmsg_ctrl will be used to instantiate the endpoints for this RPMsg
>> device.
>> on user application request the rpmsg_ctrl will call the appropriate
>> auxiliary
>> device to create an endpoint.
>>
>> If we consider that one objective of this series is to allow application to
>> initiate the communication with the remote processor, so to be able to
>> initiate
>> the service (ns announcement sent to the remote processor).
>> This implies that:
>> -either the RPMsg device has been probed first by a remote ns announcement
>> or by
>> a Linux kernel driver using the "driver_override", to register an auxiliary
>> device. In this case an endpoint will be created associated to the RPMsg
>> service
>> - or create a RPMsg device on first ioctl endpoint creation request, if it
>> does
>> not exist (that could trig a NS announcement to remote processor).
>>
>> But I'm not sure that this approach would work with QCOM RPMsg backends...
>>
>
> I don't think there is a way forward with this set without a clear
> understanding
> of the Glink and SMD drivers. I have already spent a fair amount of time in
> the
> Glink driver and will continue on Monday with SMD.
>
>>>
>>> I'm out of time for today - I will continue tomorrow.
>>
>> It seems to me that the main point to step forward is to clarify the global
>> design and features of the rpmsg-ctrl.
>> Depending on the decision taken, this series could be trashed and rewritten
>> from
>> a blank page...To not lost to much time on the series don't hesitate to limit
>> the review to the minimum.
>>
>
> I doubt you will ever get clear guidelines on the whole solution. I will get
> back to you once I am done with the SMD driver, which should be in the
> latter part of next week.
Thanks for your time past on this topic!
I don't expect a clear guidance but that we clarify the objective of this RPMsg
[RFC 3/3] thunderbolt: build kunit tests without structleak plugin
From: Arnd Bergmann
The structleak plugin causes the stack frame size to grow immensely:
drivers/thunderbolt/test.c:1529:1: error: the frame size of 1176 bytes is
larger than 1024 bytes [-Werror=frame-larger-than=]
Turn it off in this file.
Signed-off-by: Arnd Bergmann
---
drivers/thunderbolt/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/thunderbolt/Makefile b/drivers/thunderbolt/Makefile
index 7aa48f6c41d9..e571c0495a84 100644
--- a/drivers/thunderbolt/Makefile
+++ b/drivers/thunderbolt/Makefile
@@ -7,6 +7,7 @@ thunderbolt-objs += nvm.o retimer.o quirks.o
thunderbolt-${CONFIG_ACPI} += acpi.o
thunderbolt-$(CONFIG_DEBUG_FS) += debugfs.o
thunderbolt-${CONFIG_USB4_KUNIT_TEST} += test.o
+CFLAGS_REMOVE_test.o += -fplugin-arg-structleak_plugin-byref
-fplugin-arg-structleak_plugin-byref-all
thunderbolt_dma_test-${CONFIG_USB4_DMA_TEST} += dma_test.o
obj-$(CONFIG_USB4_DMA_TEST) += thunderbolt_dma_test.o
--
2.29.2
Re: [PATCH v2 0/4] MIPS: process: Some fixes and improvements about get_frame_info()
On Thu, Jan 21, 2021 at 01:31:34PM +0800, Jinyang He wrote: > Not familiar with microMIPS. Not test on microMIPS. > > Changelog v2: > - Thanks to Thomas for suggesting that remove and sort header includes. > [PATCH 1/4] for details. > - Thanks to Jiaxun for test v1 and told me it stuck at loading init. > I mistakenly thought that r_format.rs and pool32a_format.rs are the same. > See [PATCH 4/4] for details. > > Jinyang He (4): > MIPS: process: Remove unnecessary headers inclusion > MIPS: microMIPS: Fix the judgment of mm_jr16_op and mm_jalr_op > MIPS: Fix get_frame_info() handing of function size > MIPS: Add is_jr_ra_ins() to end the loop early > > arch/mips/kernel/process.c | 87 > ++ > 1 file changed, 50 insertions(+), 37 deletions(-) I've re-added linux/random.h and asm/mips-cps.h in your first patch and applied all four patches to mips-next. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
[PATCH] amdgpu: fix clang build warning
From: Arnd Bergmann
clang warns about the -mhard-float command line arguments
on architectures that do not support this:
clang: error: argument unused during compilation: '-mhard-float'
[-Werror,-Wunused-command-line-argument]
Move this into the gcc-specific arguments.
Fixes: e77165bf7b02 ("drm/amd/display: Add DCN3 blocks to Makefile")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/dc/dcn30/Makefile | 6 --
drivers/gpu/drm/amd/display/dc/dcn301/Makefile | 3 ++-
drivers/gpu/drm/amd/display/dc/dcn302/Makefile | 3 ++-
3 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/Makefile
b/drivers/gpu/drm/amd/display/dc/dcn30/Makefile
index c20331eb62e0..dfd77b3cc84d 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/Makefile
@@ -32,8 +32,8 @@ DCN30 = dcn30_init.o dcn30_hubbub.o dcn30_hubp.o dcn30_dpp.o
dcn30_optc.o \
ifdef CONFIG_X86
-CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_resource.o := -mhard-float -msse
-CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_optc.o := -mhard-float -msse
+CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_resource.o := -msse
+CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_optc.o := -msse
endif
ifdef CONFIG_PPC64
@@ -45,6 +45,8 @@ ifdef CONFIG_CC_IS_GCC
ifeq ($(call cc-ifversion, -lt, 0701, y), y)
IS_OLD_GCC = 1
endif
+CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_resource.o += -mhard-float
+CFLAGS_$(AMDDALPATH)/dc/dcn30/dcn30_optc.o += -mhard-float
endif
ifdef CONFIG_X86
diff --git a/drivers/gpu/drm/amd/display/dc/dcn301/Makefile
b/drivers/gpu/drm/amd/display/dc/dcn301/Makefile
index 3ca7d911d25c..09264716d1dc 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn301/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn301/Makefile
@@ -14,7 +14,7 @@ DCN301 = dcn301_init.o dcn301_resource.o dcn301_dccg.o \
dcn301_dio_link_encoder.o dcn301_hwseq.o dcn301_panel_cntl.o
dcn301_hubbub.o
ifdef CONFIG_X86
-CFLAGS_$(AMDDALPATH)/dc/dcn301/dcn301_resource.o := -mhard-float -msse
+CFLAGS_$(AMDDALPATH)/dc/dcn301/dcn301_resource.o := -msse
endif
ifdef CONFIG_PPC64
@@ -25,6 +25,7 @@ ifdef CONFIG_CC_IS_GCC
ifeq ($(call cc-ifversion, -lt, 0701, y), y)
IS_OLD_GCC = 1
endif
+CFLAGS_$(AMDDALPATH)/dc/dcn301/dcn301_resource.o += -mhard-float
endif
ifdef CONFIG_X86
diff --git a/drivers/gpu/drm/amd/display/dc/dcn302/Makefile
b/drivers/gpu/drm/amd/display/dc/dcn302/Makefile
index 8d4924b7dc22..101620a8867a 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn302/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn302/Makefile
@@ -13,7 +13,7 @@
DCN3_02 = dcn302_init.o dcn302_hwseq.o dcn302_resource.o
ifdef CONFIG_X86
-CFLAGS_$(AMDDALPATH)/dc/dcn302/dcn302_resource.o := -mhard-float -msse
+CFLAGS_$(AMDDALPATH)/dc/dcn302/dcn302_resource.o := -msse
endif
ifdef CONFIG_PPC64
@@ -24,6 +24,7 @@ ifdef CONFIG_CC_IS_GCC
ifeq ($(call cc-ifversion, -lt, 0701, y), y)
IS_OLD_GCC = 1
endif
+CFLAGS_$(AMDDALPATH)/dc/dcn302/dcn302_resource.o += -mhard-float
endif
ifdef CONFIG_X86
--
2.29.2
Re: [PATCH 2/3] blk-mq: Always complete remote completions requests in softirq
On Sat, Jan 23, 2021 at 09:10:26PM +0100, Sebastian Andrzej Siewior wrote: > Controllers with multiple queues have their IRQ-handelers pinned to a > CPU. The core shouldn't need to complete the request on a remote CPU. > > Remove this case and always raise the softirq to complete the request. What about changing blk_mq_trigger_softirq to take a void * argument and thus removing __blk_mq_complete_request_remote entirely?
[PATCH v2 net-next] net: core: devlink: add 'dropped' stats field for DROP trap action
Whenever query statistics is issued for trap with DROP action,
devlink subsystem would also fill-in statistics 'dropped' field.
In case if device driver did't register callback for hard drop
statistics querying, 'dropped' field will be omitted and not filled.
Add trap_drop_counter_get callback implementation to the netdevsim.
Add new test cases for netdevsim, to test both the callback
functionality, as well as drop statistics alteration check.
Signed-off-by: Oleksandr Mazur
---
V2:
1) Change commit description / subject.
2) Remove HARD_DROP action.
3) Remove devlink UAPI changes.
4) Rename hard statistics get callback to be 'trap_drop_counter_get'
5) Make callback get called for existing trap action - DROP:
whenever statistics for trap with DROP action is queried,
devlink subsystem would call-in callback to get stats from HW;
6) Add changes to the netdevsim support implemented changes
(as well as changes to make it possible to test netdevsim with
these changes).
7) Add new test cases to the netdevsim's kselftests to test new
changes provided with this patchset;
Test-results:
# selftests: drivers/net/netdevsim: devlink_trap.sh
# TEST: Initialization[ OK ]
# TEST: Trap action [ OK ]
# TEST: Trap metadata [ OK ]
# TEST: Non-existing trap [ OK ]
# TEST: Non-existing trap action [ OK ]
# TEST: Trap statistics [ OK ]
# TEST: Trap group action [ OK ]
# TEST: Non-existing trap group [ OK ]
# TEST: Trap group statistics [ OK ]
# TEST: Trap policer [ OK ]
# TEST: Trap policer binding [ OK ]
# TEST: Port delete [ OK ]
# TEST: Device delete [ OK ]
ok 1 selftests: drivers/net/netdevsim: devlink_trap.sh
drivers/net/netdevsim/dev.c | 21 +++
drivers/net/netdevsim/netdevsim.h | 1 +
include/net/devlink.h | 10
net/core/devlink.c| 55 +--
.../drivers/net/netdevsim/devlink_trap.sh | 10
.../selftests/net/forwarding/devlink_lib.sh | 26 +
6 files changed, 119 insertions(+), 4 deletions(-)
diff --git a/drivers/net/netdevsim/dev.c b/drivers/net/netdevsim/dev.c
index 816af1f55e2c..1fc8c7a2a1e3 100644
--- a/drivers/net/netdevsim/dev.c
+++ b/drivers/net/netdevsim/dev.c
@@ -231,6 +231,9 @@ static int nsim_dev_debugfs_init(struct nsim_dev *nsim_dev)
debugfs_create_bool("fail_trap_policer_counter_get", 0600,
nsim_dev->ddir,
&nsim_dev->fail_trap_policer_counter_get);
+ debugfs_create_bool("fail_trap_drop_counter_get", 0600,
+ nsim_dev->ddir,
+ &nsim_dev->fail_trap_drop_counter_get);
nsim_udp_tunnels_debugfs_create(nsim_dev);
return 0;
}
@@ -416,6 +419,7 @@ struct nsim_trap_data {
struct delayed_work trap_report_dw;
struct nsim_trap_item *trap_items_arr;
u64 *trap_policers_cnt_arr;
+ u64 trap_hard_drop_cnt;
struct nsim_dev *nsim_dev;
spinlock_t trap_lock; /* Protects trap_items_arr */
};
@@ -892,6 +896,22 @@ nsim_dev_devlink_trap_policer_counter_get(struct devlink
*devlink,
return 0;
}
+int nsim_dev_devlink_trap_drop_counter_get(struct devlink *devlink,
+ const struct devlink_trap *trap,
+ u64 *p_drops)
+{
+ struct nsim_dev *nsim_dev = devlink_priv(devlink);
+ u64 *cnt;
+
+ if (nsim_dev->fail_trap_drop_counter_get)
+ return -EINVAL;
+
+ cnt = &nsim_dev->trap_data->trap_hard_drop_cnt;
+ *p_drops = (*cnt)++;
+
+ return 0;
+}
+
static const struct devlink_ops nsim_dev_devlink_ops = {
.supported_flash_update_params = DEVLINK_SUPPORT_FLASH_UPDATE_COMPONENT
|
DEVLINK_SUPPORT_FLASH_UPDATE_OVERWRITE_MASK,
@@ -905,6 +925,7 @@ static const struct devlink_ops nsim_dev_devlink_ops = {
.trap_group_set = nsim_dev_devlink_trap_group_set,
.trap_policer_set = nsim_dev_devlink_trap_policer_set,
.trap_policer_counter_get = nsim_dev_devlink_trap_policer_counter_get,
+ .trap_drop_counter_get = nsim_dev_devlink_trap_drop_counter_get,
};
#define NSIM_DEV_MAX_MACS_DEFAULT 32
diff --git a/drivers/net/netdevsim/netdevsim.h
b/drivers/net/netdevsim/netdevsim.h
index 48163c5f2ec9..b0d8e
Re: [PATCH 0/4] perf vendor events arm64: Some tidy-up/refactoring
On 25/01/2021 11:53, John Garry wrote: + Missed reviewers for https://lore.kernel.org/lkml/1611575600-2440-1-git-send-email-john.ga...@huawei.com/T/#u There is much event duplication in the common and uarch events for A76 and Ampere eMag support, so factor out into a common JSON. Since the wording for events may differ between CPU datasheet and the architecture reference manual, the current wording is kept. This is unless there are minor differences. In addition, event names are renamed to be same as architecture reference manual, to keep commonality. Also a minor fix is included for the Ampere eMag JSON. John Garry (4): perf vendor events arm64: Fix Ampere eMag event typo perf vendor events arm64: Add common and uarch event JSON perf vendor events arm64: Reference common and uarch events for Ampere eMag perf vendor events arm64: Reference common and uarch events for A76 .../arch/arm64/ampere/emag/branch.json| 8 +- .../arch/arm64/ampere/emag/bus.json | 5 +- .../arch/arm64/ampere/emag/cache.json | 58 +--- .../arch/arm64/ampere/emag/clock.json | 4 +- .../arch/arm64/ampere/emag/exception.json | 10 +- .../arch/arm64/ampere/emag/instruction.json | 34 +-- .../arch/arm64/ampere/emag/memory.json| 11 +- .../arch/arm64/arm/cortex-a76-n1/branch.json | 12 +- .../arch/arm64/arm/cortex-a76-n1/bus.json | 19 +- .../arch/arm64/arm/cortex-a76-n1/cache.json | 118 +++-- .../arm64/arm/cortex-a76-n1/exception.json| 10 +- .../arm64/arm/cortex-a76-n1/instruction.json | 45 +--- .../arch/arm64/arm/cortex-a76-n1/memory.json | 6 +- .../arch/arm64/arm/cortex-a76-n1/other.json | 4 +- .../arm64/arm/cortex-a76-n1/pipeline.json | 12 +- .../arm64/armv8-common-and-microarch.json | 248 ++ 16 files changed, 356 insertions(+), 248 deletions(-) create mode 100644 tools/perf/pmu-events/arch/arm64/armv8-common-and-microarch.json
[PATCH] arm64: kfence: fix header inclusion
From: Arnd Bergmann
Randconfig builds started warning about a missing function declaration
after set_memory_valid() is moved to a new file:
In file included from mm/kfence/core.c:26:
arch/arm64/include/asm/kfence.h:17:2: error: implicit declaration of function
'set_memory_valid' [-Werror,-Wimplicit-function-declaration]
Include the correct header again.
Fixes: 9e18ec3cfabd ("set_memory: allow querying whether set_direct_map_*() is
actually enabled")
Fixes: 204555ff8bd6 ("arm64, kfence: enable KFENCE for ARM64")
Signed-off-by: Arnd Bergmann
---
arch/arm64/include/asm/kfence.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/kfence.h b/arch/arm64/include/asm/kfence.h
index d061176d57ea..aa855c6a0ae6 100644
--- a/arch/arm64/include/asm/kfence.h
+++ b/arch/arm64/include/asm/kfence.h
@@ -8,7 +8,7 @@
#ifndef __ASM_KFENCE_H
#define __ASM_KFENCE_H
-#include
+#include
static inline bool arch_kfence_init_pool(void) { return true; }
--
2.29.2
Re: [PATCH v3 00/17] KVM: x86/pmu: Add support to enable Guest PEBS via DS
On Mon, Jan 25, 2021 at 04:08:22PM +0800, Like Xu wrote: > Hi Peter, > > On 2021/1/22 17:56, Peter Zijlstra wrote: > > On Fri, Jan 15, 2021 at 10:51:38AM -0800, Sean Christopherson wrote: > > > On Fri, Jan 15, 2021, Andi Kleen wrote: > > > > > I'm asking about ucode/hardare. Is the "guest pebs buffer write -> > > > > > PEBS PMI" > > > > > guaranteed to be atomic? > > > > > > > > Of course not. > > > > > > So there's still a window where the guest could observe the bad counter > > > index, > > > correct? > > > > Guest could do a hypercall to fix up the DS area before it tries to read > > it I suppose. Or the HV could expose the index mapping and have the > > guest fix up it. > > A weird (malicious) guest would read unmodified PEBS records in the > guest PEBS buffer from other vCPUs without the need for hypercall or > index mapping from HV. > > Do you see any security issues on this host index leak window? > > > > > Adding a little virt crud on top shouldn't be too hard. > > > > The patches 13-17 in this version has modified the guest PEBS buffer > to correct the index mapping information in the guest PEBS records. Right, but given there is no atomicity between writing the DS area and triggering the PMI (as already established earlier in this thread), a malicious guest can already access this information, no?
[PATCH] mmc: brcmstb: Fix sdhci_pltfm_suspend link error
From: Arnd Bergmann
sdhci_pltfm_suspend() is only available when CONFIG_PM_SLEEP
support is built into the kernel, which caused a regression
in a recent bugfix:
ld.lld: error: undefined symbol: sdhci_pltfm_suspend
>>> referenced by sdhci-brcmstb.c
>>> mmc/host/sdhci-brcmstb.o:(sdhci_brcmstb_shutdown) in archive
>>> drivers/built-in.a
Making the call conditional on the symbol fixes the link
error.
Fixes: 5b191dcba719 ("mmc: sdhci-brcmstb: Fix mmc timeout errors on S5 suspend")
Fixes: e7b5d63a82fe ("mmc: sdhci-brcmstb: Add shutdown callback")
Cc: sta...@vger.kernel.org
Signed-off-by: Arnd Bergmann
---
It would be helpful if someone could test this to ensure that the
driver works correctly even when CONFIG_PM_SLEEP is disabled
---
drivers/mmc/host/sdhci-brcmstb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci-brcmstb.c b/drivers/mmc/host/sdhci-brcmstb.c
index f9780c65ebe9..dc9280b149db 100644
--- a/drivers/mmc/host/sdhci-brcmstb.c
+++ b/drivers/mmc/host/sdhci-brcmstb.c
@@ -314,7 +314,8 @@ static int sdhci_brcmstb_probe(struct platform_device *pdev)
static void sdhci_brcmstb_shutdown(struct platform_device *pdev)
{
- sdhci_pltfm_suspend(&pdev->dev);
+ if (IS_ENABLED(CONFIG_PM_SLEEP))
+ sdhci_pltfm_suspend(&pdev->dev);
}
MODULE_DEVICE_TABLE(of, sdhci_brcm_of_match);
--
2.29.2
Re: [PATCH] i915: Fix DRM_I915_WERROR dependencies
Quoting Arnd Bergmann (2021-01-25 12:26:44) > From: Arnd Bergmann > > CONFIG_DRM_I915_DEBUG now selects CONFIG_DRM_I915_WERROR, but fails > to honor its dependencies: > > WARNING: unmet direct dependencies detected for DRM_I915_WERROR > Depends on [n]: HAS_IOMEM [=y] && DRM_I915 [=m] && EXPERT [=y] && > !COMPILE_TEST [=y] > Selected by [m]: > - DRM_I915_DEBUG [=y] && HAS_IOMEM [=y] && EXPERT [=y] && DRM_I915 [=m] DRM_I915_DEBUG now depends on !COMPILE_TEST and EXPERT. -Chris
RE: [PATCH] drm/amd/display: use div_s64() for 64-bit division
[AMD Public Use]
Hi Arnd Bergmann,
Thanks for your patch. This link error during compile has been fixed by below
commit and been submitted to drm-next branch already.
5da047444e82 drm/amd/display: fix 64-bit division issue on 32-bit OS
Regards,
Guchun
-Original Message-
From: amd-gfx On Behalf Of Arnd Bergmann
Sent: Monday, January 25, 2021 7:40 PM
To: Wentland, Harry ; Li, Sun peng (Leo)
; Deucher, Alexander ; Koenig,
Christian ; David Airlie ; Daniel
Vetter ; Aberback, Joshua ; Lakha,
Bhawanpreet ; Kazlauskas, Nicholas
Cc: Arnd Bergmann ; Chalmers, Wesley ;
Zhuo, Qingqing ; Siqueira, Rodrigo
; linux-kernel@vger.kernel.org;
amd-...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Jacky Liao
; Leung, Martin
Subject: [PATCH] drm/amd/display: use div_s64() for 64-bit division
From: Arnd Bergmann
The open-coded 64-bit division causes a link error on 32-bit
machines:
ERROR: modpost: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: modpost: "__divdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
Use the div_s64() to perform the division here. One of them was an unsigned
division originally, but it looks like signed division was intended, so use
that to consistently allow a negative delay.
Fixes: ea7154d8d9fb ("drm/amd/display: Update
dcn30_apply_idle_power_optimizations() code")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
index dff83c6a142a..a133e399e76d 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
@@ -772,8 +772,8 @@ bool dcn30_apply_idle_power_optimizations(struct dc *dc,
bool enable)
cursor_cache_enable ?
&cursor_attr : NULL)) {
unsigned int v_total =
stream->adjust.v_total_max ?
stream->adjust.v_total_max :
stream->timing.v_total;
- unsigned int refresh_hz = (unsigned long long)
stream->timing.pix_clk_100hz *
- 100LL / (v_total *
stream->timing.h_total);
+ unsigned int refresh_hz = div_s64((unsigned
long long) stream->timing.pix_clk_100hz *
+ 100LL, v_total *
stream->timing.h_total);
/*
* one frame time in microsec:
@@ -800,8 +800,8 @@ bool dcn30_apply_idle_power_optimizations(struct dc *dc,
bool enable)
unsigned int denom = refresh_hz * 6528;
unsigned int stutter_period =
dc->current_state->perf_params.stutter_period_us;
- tmr_delay = (((100LL + 2 * stutter_period *
refresh_hz) *
- (100LL +
dc->debug.mall_additional_timer_percent) + denom - 1) /
+ tmr_delay = div_s64(((100LL + 2 *
stutter_period * refresh_hz) *
+ (100LL +
dc->debug.mall_additional_timer_percent) + denom - 1),
denom) - 64LL;
/* scale should be increased until it fits into
6 bits */ @@ -815,8 +815,8 @@ bool dcn30_apply_idle_power_optimizations(struct
dc *dc, bool enable)
}
denom *= 2;
- tmr_delay = (((100LL + 2 *
stutter_period * refresh_hz) *
- (100LL +
dc->debug.mall_additional_timer_percent) + denom - 1) /
+ tmr_delay = div_s64(((100LL + 2 *
stutter_period * refresh_hz) *
+ (100LL +
dc->debug.mall_additional_timer_percent) + denom - 1),
denom) - 64LL;
}
--
2.29.2
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=04%7C01%7Cguchun.chen%40amd.com%7C4bb97aae9edc4153392c08d8c1260048%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637471716255231899%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kLdkVHfkYx%2Bd249%2BmtG5GJTq295Pxzw7mgTe0FD8QvY%3D&reserved=0
KASAN: slab-out-of-bounds Write in record_print_text
Hello,
syzbot found the following issue on:
HEAD commit:e6806137 Merge tag 'irq_urgent_for_v5.11_rc5' of git://git..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10c59c6f50
kernel config: https://syzkaller.appspot.com/x/.config?x=be33d8015c9de024
dashboard link: https://syzkaller.appspot.com/bug?extid=a42d84593d6a89a76f26
compiler: gcc (GCC) 10.1.0-syz 20200507
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1575e6b4d0
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17aea4e8d0
The issue was bisected to:
commit f0e386ee0c0b71ea6f7238506a4d0965a2dbef11
Author: John Ogness
Date: Thu Jan 14 17:04:12 2021 +
printk: fix buffer overflow potential for print_text()
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17f30130d0
final oops: https://syzkaller.appspot.com/x/report.txt?x=140b0130d0
console output: https://syzkaller.appspot.com/x/log.txt?x=100b0130d0
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+a42d84593d6a89a76...@syzkaller.appspotmail.com
Fixes: f0e386ee0c0b ("printk: fix buffer overflow potential for print_text()")
==
BUG: KASAN: slab-out-of-bounds in record_print_text+0x33f/0x380
kernel/printk/printk.c:1401
Write of size 1 at addr 88801c2faf40 by task in:imklog/8158
CPU: 1 PID: 8158 Comm: in:imklog Not tainted 5.11.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:79 [inline]
dump_stack+0x107/0x163 lib/dump_stack.c:120
print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:230
__kasan_report mm/kasan/report.c:396 [inline]
kasan_report.cold+0x79/0xd5 mm/kasan/report.c:413
record_print_text+0x33f/0x380 kernel/printk/printk.c:1401
syslog_print+0x2bb/0x430 kernel/printk/printk.c:1459
do_syslog.part.0+0x2a8/0x7c0 kernel/printk/printk.c:1586
do_syslog+0x49/0x60 kernel/printk/printk.c:1567
kmsg_read+0x90/0xb0 fs/proc/kmsg.c:40
pde_read fs/proc/inode.c:321 [inline]
proc_reg_read+0x119/0x300 fs/proc/inode.c:331
vfs_read+0x1b5/0x570 fs/read_write.c:494
ksys_read+0x12d/0x250 fs/read_write.c:634
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7f3e2eec922d
Code: c1 20 00 00 75 10 b8 00 00 00 00 0f 05 48 3d 01 f0 ff ff 73 31 c3 48 83
ec 08 e8 4e fc ff ff 48 89 04 24 b8 00 00 00 00 0f 05 <48> 8b 3c 24 48 89 c2 e8
97 fc ff ff 48 89 d0 48 83 c4 08 48 3d 01
RSP: 002b:7f3e2c865580 EFLAGS: 0293 ORIG_RAX:
RAX: ffda RBX: RCX: 7f3e2eec922d
RDX: 1fa0 RSI: 7f3e2c865da0 RDI: 0004
RBP: 55d0880849d0 R08: R09: 0401
R10: 0001 R11: 0293 R12: 7f3e2c865da0
R13: 1fa0 R14: 1f9f R15: 7f3e2c865df3
Allocated by task 8158:
kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38
kasan_set_track mm/kasan/common.c:46 [inline]
set_alloc_info mm/kasan/common.c:401 [inline]
kasan_kmalloc.constprop.0+0x82/0xa0 mm/kasan/common.c:429
kmalloc include/linux/slab.h:552 [inline]
syslog_print+0xb2/0x430 kernel/printk/printk.c:1430
do_syslog.part.0+0x2a8/0x7c0 kernel/printk/printk.c:1586
do_syslog+0x49/0x60 kernel/printk/printk.c:1567
kmsg_read+0x90/0xb0 fs/proc/kmsg.c:40
pde_read fs/proc/inode.c:321 [inline]
proc_reg_read+0x119/0x300 fs/proc/inode.c:331
vfs_read+0x1b5/0x570 fs/read_write.c:494
ksys_read+0x12d/0x250 fs/read_write.c:634
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
The buggy address belongs to the object at 88801c2fa800
which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 832 bytes to the right of
1024-byte region [88801c2fa800, 88801c2fac00)
The buggy address belongs to the page:
page:eb65f4f5 refcount:1 mapcount:0 mapping: index:0x0
pfn:0x1c2f8
head:eb65f4f5 order:2 compound_mapcount:0 compound_pincount:0
flags: 0xfff0010200(slab|head)
raw: 00fff0010200 dead0100 dead0122 888010041140
raw: 80080008 0001
page dumped because: kasan: bad access detected
Memory state around the buggy address:
88801c2fae00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
88801c2fae80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>88801c2faf00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
88801c2faf80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
88801c2fb000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for
Re: [PATCH v3] iio: adc: stm32-adc: enable timestamping for non-DMA usage
On 1/25/21 12:21 PM, Ahmad Fatoum wrote:
> For non-DMA usage, we have an easy way to associate a timestamp with a
> sample: iio_pollfunc_store_time stores a timestamp in the primary
> trigger IRQ handler and stm32_adc_trigger_handler runs in the IRQ thread
> to push out the buffer along with the timestamp.
>
> For this to work, the driver needs to register an IIO_TIMESTAMP channel.
> Do this.
>
> For DMA, it's not as easy, because we don't push the buffers out of
> stm32_adc_trigger, but out of stm32_adc_dma_buffer_done, which runs in
> a tasklet scheduled after a DMA completion.
>
> Preferably, the DMA controller would copy us the timestamp into that buffer
> as well. Until this is implemented, restrict timestamping support to
> only PIO. For low-frequency sampling, PIO is probably good enough.
>
> Cc: Holger Assmann
> Acked-by: Fabrice Gasnier
> Signed-off-by: Ahmad Fatoum
> ---
> v2 -> v3:
> - explicitly specify alignment (Jonathan)
> - increase buffer size to hold additional timestamp
> v1 -> v2:
> - Added comment about timestamping being PIO only (Fabrice)
> - Added missing DMA resource clean up in error path (Fabrice)
> - Added Fabrice's Acked-by
> ---
> drivers/iio/adc/stm32-adc.c | 39 +
> 1 file changed, 31 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c
> index c067c994dae2..ab2f440d7afb 100644
> --- a/drivers/iio/adc/stm32-adc.c
> +++ b/drivers/iio/adc/stm32-adc.c
> @@ -177,7 +177,7 @@ struct stm32_adc_cfg {
> * @offset: ADC instance register offset in ADC block
> * @cfg: compatible configuration data
> * @completion: end of single conversion completion
> - * @buffer: data buffer
> + * @buffer: data buffer + 8 bytes for timestamp if enabled
^
> * @clk: clock for this adc instance
> * @irq: interrupt for this adc instance
> * @lock:spinlock
> @@ -200,7 +200,7 @@ struct stm32_adc {
> u32 offset;
> const struct stm32_adc_cfg *cfg;
> struct completion completion;
> - u16 buffer[STM32_ADC_MAX_SQ];
> + u16 buffer[STM32_ADC_MAX_SQ + 8] __aligned(8);
^^ ^
How does that fit together?
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
signature.asc
Description: OpenPGP digital signature
[PATCH] perf test: Add parse-metric memory bandwidth testcase
Event duration_time in a metric expression requires special handling.
Improve test coverage by including a metric whose expression includes
duration_time. The actual metric is a copied from the L1D_Cache_Fill_BW
metric on my broadwell machine.
Signed-off-by: John Garry
---
Based on acme perf/core + "perf metricgroup: Fix for metrics containing
duration_time"
diff --git a/tools/perf/tests/parse-metric.c b/tools/perf/tests/parse-metric.c
index ce7be37f0d88..6dc1db1626ad 100644
--- a/tools/perf/tests/parse-metric.c
+++ b/tools/perf/tests/parse-metric.c
@@ -69,6 +69,10 @@ static struct pmu_event pme_test[] = {
.metric_expr= "1/m3",
.metric_name= "M3",
},
+{
+ .metric_expr= "64 * l1d.replacement / 10 / duration_time",
+ .metric_name= "L1D_Cache_Fill_BW",
+},
{
.name = NULL,
}
@@ -107,6 +111,8 @@ static void load_runtime_stat(struct runtime_stat *st,
struct evlist *evlist,
evlist__for_each_entry(evlist, evsel) {
count = find_value(evsel->name, vals);
perf_stat__update_shadow_stats(evsel, count, 0, st);
+ if (!strcmp(evsel->name, "duration_time"))
+ update_stats(&walltime_nsecs_stats, count);
}
}
@@ -321,6 +327,23 @@ static int test_recursion_fail(void)
return 0;
}
+static int test_memory_bandwidth(void)
+{
+ double ratio;
+ struct value vals[] = {
+ { .event = "l1d.replacement", .val = 400 },
+ { .event = "duration_time", .val = 2 },
+ { .event = NULL, },
+ };
+
+ TEST_ASSERT_VAL("failed to compute metric",
+ compute_metric("L1D_Cache_Fill_BW", vals, &ratio) == 0);
+ TEST_ASSERT_VAL("L1D_Cache_Fill_BW, wrong ratio",
+ 1.28 == ratio);
+
+ return 0;
+}
+
static int test_metric_group(void)
{
double ratio1, ratio2;
@@ -353,5 +376,6 @@ int test__parse_metric(struct test *test __maybe_unused,
int subtest __maybe_unu
TEST_ASSERT_VAL("DCache_L2 failed", test_dcache_l2() == 0);
TEST_ASSERT_VAL("recursion fail failed", test_recursion_fail() == 0);
TEST_ASSERT_VAL("test metric group", test_metric_group() == 0);
+ TEST_ASSERT_VAL("Memory bandwidth", test_memory_bandwidth() == 0);
return 0;
}
--
2.26.2
[PATCH -next] usb: core: Remove unused including
Fix the following versioncheck warning: drivers/usb/core/hcd.c:14:1: unused including Reported-by: Hulk Robot Signed-off-by: Zou Wei --- drivers/usb/core/hcd.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c index 3f03813..53bc93d 100644 --- a/drivers/usb/core/hcd.c +++ b/drivers/usb/core/hcd.c @@ -11,7 +11,6 @@ #include #include -#include #include #include #include -- 2.6.2
[PATCH v3 3/3] drm/bridge: anx7625: add MIPI DPI input feature support
Add MIPI rx DPI input support
Reported-by: kernel test robot
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 326 --
drivers/gpu/drm/bridge/analogix/anx7625.h | 20 +-
2 files changed, 285 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 04536cc..c7fc92b 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -150,18 +150,18 @@ static int anx7625_write_and(struct anx7625_data *ctx,
return anx7625_reg_write(ctx, client, offset, (val & (mask)));
}
-static int anx7625_write_and_or(struct anx7625_data *ctx,
- struct i2c_client *client,
- u8 offset, u8 and_mask, u8 or_mask)
+static int anx7625_config_bit_matrix(struct anx7625_data *ctx)
{
- int val;
+ int i, ret;
- val = anx7625_reg_read(ctx, client, offset);
- if (val < 0)
- return val;
+ ret = anx7625_write_or(ctx, ctx->i2c.tx_p2_client,
+ AUDIO_CONTROL_REGISTER, 0x80);
+ for (i = 0; i < 13; i++)
+ ret |= anx7625_reg_write(ctx, ctx->i2c.tx_p2_client,
+VIDEO_BIT_MATRIX_12 + i,
+0x18 + i);
- return anx7625_reg_write(ctx, client,
-offset, (val & and_mask) | (or_mask));
+ return ret;
}
static int anx7625_read_ctrl_status_p0(struct anx7625_data *ctx)
@@ -195,6 +195,60 @@ static int wait_aux_op_finish(struct anx7625_data *ctx)
return 0;
}
+static int anx7625_aux_dpcd_read(struct anx7625_data *ctx,
+u8 addrh, u8 addrm, u8 addrl,
+u8 len, u8 *buf)
+{
+ struct device *dev = &ctx->client->dev;
+ int ret;
+ u8 cmd;
+
+ if (len > MAX_DPCD_BUFFER_SIZE) {
+ DRM_DEV_ERROR(dev, "exceed aux buffer len.\n");
+ return -EINVAL;
+ }
+
+ cmd = ((len - 1) << 4) | 0x09;
+
+ /* Set command and length */
+ ret = anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
+ AP_AUX_COMMAND, cmd);
+
+ /* Set aux access address */
+ ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
+AP_AUX_ADDR_7_0, addrl);
+ ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
+AP_AUX_ADDR_15_8, addrm);
+ ret |= anx7625_write_and(ctx, ctx->i2c.rx_p0_client,
+AP_AUX_ADDR_19_16, addrh);
+
+ /* Enable aux access */
+ ret |= anx7625_write_or(ctx, ctx->i2c.rx_p0_client,
+ AP_AUX_CTRL_STATUS, AP_AUX_CTRL_OP_EN);
+
+ if (ret < 0) {
+ DRM_DEV_ERROR(dev, "cannot access aux related register.\n");
+ return -EIO;
+ }
+
+ usleep_range(2000, 2100);
+
+ ret = wait_aux_op_finish(ctx);
+ if (ret) {
+ DRM_DEV_ERROR(dev, "aux IO error: wait aux op finish.\n");
+ return ret;
+ }
+
+ ret = anx7625_reg_block_read(ctx, ctx->i2c.rx_p0_client,
+AP_AUX_BUFF_START, len, buf);
+ if (ret < 0) {
+ DRM_DEV_ERROR(dev, "read dpcd register failed\n");
+ return -EIO;
+ }
+
+ return 0;
+}
+
static int anx7625_video_mute_control(struct anx7625_data *ctx,
u8 status)
{
@@ -219,38 +273,6 @@ static int anx7625_video_mute_control(struct anx7625_data
*ctx,
return ret;
}
-static int anx7625_config_audio_input(struct anx7625_data *ctx)
-{
- struct device *dev = &ctx->client->dev;
- int ret;
-
- /* Channel num */
- ret = anx7625_reg_write(ctx, ctx->i2c.tx_p2_client,
- AUDIO_CHANNEL_STATUS_6, I2S_CH_2 << 5);
-
- /* FS */
- ret |= anx7625_write_and_or(ctx, ctx->i2c.tx_p2_client,
- AUDIO_CHANNEL_STATUS_4,
- 0xf0, AUDIO_FS_48K);
- /* Word length */
- ret |= anx7625_write_and_or(ctx, ctx->i2c.tx_p2_client,
- AUDIO_CHANNEL_STATUS_5,
- 0xf0, AUDIO_W_LEN_24_24MAX);
- /* I2S */
- ret |= anx7625_write_or(ctx, ctx->i2c.tx_p2_client,
- AUDIO_CHANNEL_STATUS_6, I2S_SLAVE_MODE);
- ret |= anx7625_write_and(ctx, ctx->i2c.tx_p2_client,
-AUDIO_CONTROL_REGISTER, ~TDM_TIMING_MODE);
- /* Audio change flag */
- ret |= anx7625_write_or(ctx, ctx->i2c.rx_p0_client,
- AP_AV_STATUS, AP_AUDIO_CHG);
-
- if (ret < 0)
- DRM_DEV_ERROR(dev, "fail to config audio.\n");
-
- return ret;
-}
-
/*
Re: [PATCH RFC v1 00/15] iommu/virtio: Nested stage support with Arm
Hi Shameer, On 1/22/21 9:19 PM, Shameerali Kolothum Thodi wrote: Hi Vivek, -Original Message- From: Vivek Kumar Gautam [mailto:vivek.gau...@arm.com] Sent: 21 January 2021 17:34 To: Auger Eric ; linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; io...@lists.linux-foundation.org; virtualizat...@lists.linux-foundation.org Cc: j...@8bytes.org; will.dea...@arm.com; m...@redhat.com; robin.mur...@arm.com; jean-phili...@linaro.org; alex.william...@redhat.com; kevin.t...@intel.com; jacob.jun@linux.intel.com; yi.l@intel.com; lorenzo.pieral...@arm.com; Shameerali Kolothum Thodi Subject: Re: [PATCH RFC v1 00/15] iommu/virtio: Nested stage support with Arm Hi Eric, On 1/19/21 2:33 PM, Auger Eric wrote: Hi Vivek, On 1/15/21 1:13 PM, Vivek Gautam wrote: This patch-series aims at enabling Nested stage translation in guests using virtio-iommu as the paravirtualized iommu. The backend is supported with Arm SMMU-v3 that provides nested stage-1 and stage-2 translation. This series derives its purpose from various efforts happening to add support for Shared Virtual Addressing (SVA) in host and guest. On Arm, most of the support for SVA has already landed. The support for nested stage translation and fault reporting to guest has been proposed [1]. The related changes required in VFIO [2] framework have also been put forward. This series proposes changes in virtio-iommu to program PASID tables and related stage-1 page tables. A simple iommu-pasid-table library is added for this purpose that interacts with vendor drivers to allocate and populate PASID tables. In Arm SMMUv3 we propose to pull the Context Descriptor (CD) management code out of the arm-smmu-v3 driver and add that as a glue vendor layer to support allocating CD tables, and populating them with right values. These CD tables are essentially the PASID tables and contain stage-1 page table configurations too. A request to setup these CD tables come from virtio-iommu driver using the iommu-pasid-table library when running on Arm. The virtio-iommu then pass these PASID tables to the host using the right virtio backend and support in VMM. For testing we have added necessary support in kvmtool. The changes in kvmtool are based on virtio-iommu development branch by Jean-Philippe Brucker [3]. The tested kernel branch contains following in the order bottom to top on the git hash - a) v5.11-rc3 b) arm-smmu-v3 [1] and vfio [2] changes from Eric to add nested page table support for Arm. c) Smmu test engine patches from Jean-Philippe's branch [4] d) This series e) Domain nesting info patches [5][6][7]. f) Changes to add arm-smmu-v3 specific nesting info (to be sent to the list). This kernel is tested on Neoverse reference software stack with Fixed virtual platform. Public version of the software stack and FVP is available here[8][9]. A big thanks to Jean-Philippe for his contributions towards this work and for his valuable guidance. [1] https://lore.kernel.org/linux-iommu/20201118112151.25412-1-eric.auger @redhat.com/T/ [2] https://lore.kernel.org/kvmarm/20201116110030.32335-12-eric.auger@red hat.com/T/ [3] https://jpbrucker.net/git/kvmtool/log/?h=virtio-iommu/devel [4] https://jpbrucker.net/git/linux/log/?h=sva/smmute [5] https://lore.kernel.org/kvm/1599734733-6431-2-git-send-email-yi.l.liu @intel.com/ [6] https://lore.kernel.org/kvm/1599734733-6431-3-git-send-email-yi.l.liu @intel.com/ [7] https://lore.kernel.org/kvm/1599734733-6431-4-git-send-email-yi.l.liu @intel.com/ [8] https://developer.arm.com/tools-and-software/open-source-software/arm -platforms-software/arm-ecosystem-fvps [9] https://git.linaro.org/landing-teams/working/arm/arm-reference-platfo rms.git/about/docs/rdn1edge/user-guide.rst Could you share a public branch where we could find all the kernel pieces. Thank you in advance Apologies for the delay. It took a bit of time to sort things out for a public branch. The branch is available in my github now. Please have a look. https://github.com/vivek-arm/linux/tree/5.11-rc3-nested-pgtbl-arm-smmuv3-vi rtio-iommu > Thanks for this. Do you have a corresponding kvmtool branch mentioned above as public? Thanks for showing interest. I will publish the kvmtool branch asap. Though the current development is based on Jean's branch for virtio-iommu [1], I plan to rebase the changes to master soon. Thanks & regards Vivek [1] https://jpbrucker.net/git/kvmtool/log/?h=virtio-iommu/devel Thanks, Shameer
Re: [PATCH v4 1/3] arm64: Improve kernel address detection of __is_lm_address()
Hi Vincenzo, On Fri, Jan 22, 2021 at 03:56:40PM +, Vincenzo Frascino wrote: > Currently, the __is_lm_address() check just masks out the top 12 bits > of the address, but if they are 0, it still yields a true result. > This has as a side effect that virt_addr_valid() returns true even for > invalid virtual addresses (e.g. 0x0). > > Improve the detection checking that it's actually a kernel address > starting at PAGE_OFFSET. > > Cc: Catalin Marinas > Cc: Will Deacon > Suggested-by: Catalin Marinas > Reviewed-by: Catalin Marinas > Signed-off-by: Vincenzo Frascino Looking around, it seems that there are some existing uses of virt_addr_valid() that expect it to reject addresses outside of the TTBR1 range. For example, check_mem_type() in drivers/tee/optee/call.c. Given that, I think we need something that's easy to backport to stable. This patch itself looks fine, but it's not going to backport very far, so I suspect we might need to write a preparatory patch that adds an explicit range check to virt_addr_valid() which can be trivially backported. For this patch: Acked-by: Mark Rutland Thanks, Mark. > --- > arch/arm64/include/asm/memory.h | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h > index 18fce223b67b..99d7e1494aaa 100644 > --- a/arch/arm64/include/asm/memory.h > +++ b/arch/arm64/include/asm/memory.h > @@ -247,9 +247,11 @@ static inline const void *__tag_set(const void *addr, u8 > tag) > > > /* > - * The linear kernel range starts at the bottom of the virtual address space. > + * Check whether an arbitrary address is within the linear map, which > + * lives in the [PAGE_OFFSET, PAGE_END) interval at the bottom of the > + * kernel's TTBR1 address range. > */ > -#define __is_lm_address(addr)(((u64)(addr) & ~PAGE_OFFSET) < > (PAGE_END - PAGE_OFFSET)) > +#define __is_lm_address(addr)(((u64)(addr) ^ PAGE_OFFSET) < > (PAGE_END - PAGE_OFFSET)) > > #define __lm_to_phys(addr) (((addr) & ~PAGE_OFFSET) + PHYS_OFFSET) > #define __kimg_to_phys(addr) ((addr) - kimage_voffset) > -- > 2.30.0 >
RE: [RFC PATCH v3 0/2] scheduler: expose the topology of clusters and add cluster scheduler
> -Original Message- > From: Dietmar Eggemann [mailto:dietmar.eggem...@arm.com] > Sent: Wednesday, January 13, 2021 1:53 AM > To: Song Bao Hua (Barry Song) ; Morten Rasmussen > ; Tim Chen > Cc: valentin.schnei...@arm.com; catalin.mari...@arm.com; w...@kernel.org; > r...@rjwysocki.net; vincent.guit...@linaro.org; l...@kernel.org; > gre...@linuxfoundation.org; Jonathan Cameron ; > mi...@redhat.com; pet...@infradead.org; juri.le...@redhat.com; > rost...@goodmis.org; bseg...@google.com; mgor...@suse.de; > mark.rutl...@arm.com; sudeep.ho...@arm.com; aubrey...@linux.intel.com; > linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; > linux-a...@vger.kernel.org; linux...@openeuler.org; xuwei (O) > ; Zengtao (B) ; tiantao (H) > > Subject: Re: [RFC PATCH v3 0/2] scheduler: expose the topology of clusters and > add cluster scheduler > > On 08/01/2021 22:30, Song Bao Hua (Barry Song) wrote: > > > >> -Original Message- > >> From: Morten Rasmussen [mailto:morten.rasmus...@arm.com] > >> Sent: Saturday, January 9, 2021 4:13 AM > >> To: Tim Chen > >> Cc: Song Bao Hua (Barry Song) ; > >> valentin.schnei...@arm.com; catalin.mari...@arm.com; w...@kernel.org; > >> r...@rjwysocki.net; vincent.guit...@linaro.org; l...@kernel.org; > >> gre...@linuxfoundation.org; Jonathan Cameron > ; > >> mi...@redhat.com; pet...@infradead.org; juri.le...@redhat.com; > >> dietmar.eggem...@arm.com; rost...@goodmis.org; bseg...@google.com; > >> mgor...@suse.de; mark.rutl...@arm.com; sudeep.ho...@arm.com; > >> aubrey...@linux.intel.com; linux-arm-ker...@lists.infradead.org; > >> linux-kernel@vger.kernel.org; linux-a...@vger.kernel.org; > >> linux...@openeuler.org; xuwei (O) ; Zengtao (B) > >> ; tiantao (H) > >> Subject: Re: [RFC PATCH v3 0/2] scheduler: expose the topology of clusters > and > >> add cluster scheduler > >> > >> On Thu, Jan 07, 2021 at 03:16:47PM -0800, Tim Chen wrote: > >>> On 1/6/21 12:30 AM, Barry Song wrote: > ARM64 server chip Kunpeng 920 has 6 clusters in each NUMA node, and each > cluster has 4 cpus. All clusters share L3 cache data while each cluster > has local L3 tag. On the other hand, each cluster will share some > internal system bus. This means cache is much more affine inside one > cluster > than across clusters. > >>> > >>> There is a similar need for clustering in x86. Some x86 cores could share > >> L2 caches that > >>> is similar to the cluster in Kupeng 920 (e.g. on Jacobsville there are 6 > clusters > >>> of 4 Atom cores, each cluster sharing a separate L2, and 24 cores sharing > >> L3). > >>> Having a sched domain at the L2 cluster helps spread load among > >>> L2 domains. This will reduce L2 cache contention and help with > >>> performance for low to moderate load scenarios. > >> > >> IIUC, you are arguing for the exact opposite behaviour, i.e. balancing > >> between L2 caches while Barry is after consolidating tasks within the > >> boundaries of a L3 tag cache. One helps cache utilization, the other > >> communication latency between tasks. Am I missing something? > > > > Morten, this is not true. > > > > we are both actually looking for the same behavior. My patch also > > has done the exact same behavior of spreading with Tim's patch. > > That's the case for the load-balance path because of the extra Sched > Domain (SD) (CLS/MC_L2) below MC. > > But in wakeup you add code which leads to a different packing strategy. Yes, but I put a note for the 1st case: "Case 1. we have two tasks *without* any relationship running in a system with 2 clusters and 8 cpus" so for tasks without wake-up relationship, the current patch will only result in spreading. Anyway, I will also test Tim's benchmark in kunpeng920 with the SCHED_CLUTER to see what will happen. Till now, benchmark has only covered the case to figure out the benefit of changing wake-up path. I would also be interested in figuring out what we have got from the change of load_balance(). > > It looks like that Tim's workload (SPECrate mcf) shows a performance > boost solely because of the changes the additional MC_L2 SD introduces > in load balance. The wakeup path is unchanged, i.e. llc-packing. IMHO we > have to carefully distinguish between packing vs. spreading in wakeup > and load-balance here. > > > Considering the below two cases: > > Case 1. we have two tasks without any relationship running in a system with > 2 clusters and 8 cpus. > > > > Without the sched_domain of cluster, these two tasks might be put as below: > > +---++-+ > > | ++ ++ || | > > | |task| |task| || | > > | |1 | |2 | || | > > | ++ ++ || | > > | || | > > | cluster1|| cluster2| > > +---++-+ > > With the s
[PATCH v3 2/3] drm/bridge: anx7625: fix not correct return value
At some time, the original code may return non zero value, force return 0
if operation finished
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 65cc059..04536cc 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -189,10 +189,10 @@ static int wait_aux_op_finish(struct anx7625_data *ctx)
AP_AUX_CTRL_STATUS);
if (val < 0 || (val & 0x0F)) {
DRM_DEV_ERROR(dev, "aux status %02x\n", val);
- val = -EIO;
+ return -EIO;
}
- return val;
+ return 0;
}
static int anx7625_video_mute_control(struct anx7625_data *ctx,
--
2.7.4
Re: [PATCH 1/4] ARM: dts: qcom: msm8974: add gpu support
On 1/24/21 11:05 PM, Pavel Machek wrote: > On Sun 2021-01-24 15:56:07, Iskren Chernev wrote: >> From: Brian Masney >> >> Add support for the a3xx GPU > > This is phone, right? Can I ask phone-de...@vger.kernel.org to be > cc-ed? CC-ing phone-de...@vger.kernel.org. I'm not sure why you didn't do it :-/ > > Thank you, > Pavel > > Regards, Iskren
[PATCH v2 0/2] Move ...mce/therm_throt.c to drivers/thermal/
From: Borislav Petkov
Hi,
here's v2 which addresses peterz's comments to patch 2.
@thermal folks, lemme know if you have any objections otherwise I'll
route this through the tip tree.
Thx.
Changelog:
==
v1:
so this has come up a bunch of times in the past and PeterZ is right
- that thing doesn't have anything to do with the MCE glue so move it
where it belongs.
Thx.
Borislav Petkov (2):
x86/mce: Get rid of mcheck_intel_therm_init()
thermal: Move therm_throt there from x86/mce
arch/x86/Kconfig | 4 --
arch/x86/include/asm/irq.h| 4 ++
arch/x86/include/asm/mce.h| 22 ---
arch/x86/include/asm/thermal.h| 21 ++
arch/x86/kernel/cpu/intel.c | 3 ++
arch/x86/kernel/cpu/mce/Makefile | 2 -
arch/x86/kernel/cpu/mce/core.c| 1 -
arch/x86/kernel/cpu/mce/intel.c | 1 -
arch/x86/kernel/irq.c | 29 ++
drivers/thermal/intel/Kconfig | 4 ++
drivers/thermal/intel/Makefile| 1 +
.../thermal/intel}/therm_throt.c | 39 +++
drivers/thermal/intel/x86_pkg_temp_thermal.c | 3 +-
13 files changed, 70 insertions(+), 64 deletions(-)
create mode 100644 arch/x86/include/asm/thermal.h
rename {arch/x86/kernel/cpu/mce => drivers/thermal/intel}/therm_throt.c (96%)
--
2.29.2
[PATCH v2 1/2] x86/mce: Get rid of mcheck_intel_therm_init()
From: Borislav Petkov
Move the APIC_LVTTHMR read which needs to happen on the BSP, to
intel_init_thermal(). One less boot dependency.
No functional changes.
Signed-off-by: Borislav Petkov
---
arch/x86/include/asm/mce.h| 6 --
arch/x86/kernel/cpu/mce/core.c| 1 -
arch/x86/kernel/cpu/mce/therm_throt.c | 14 +++---
3 files changed, 3 insertions(+), 18 deletions(-)
diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index 56cdeaac76a0..def9aa5e1fa4 100644
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -304,12 +304,6 @@ extern int (*platform_thermal_package_notify)(__u64
msr_val);
* callback has rate control */
extern bool (*platform_thermal_package_rate_control)(void);
-#ifdef CONFIG_X86_THERMAL_VECTOR
-extern void mcheck_intel_therm_init(void);
-#else
-static inline void mcheck_intel_therm_init(void) { }
-#endif
-
/*
* Used by APEI to report memory error via /dev/mcelog
*/
diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
index e133ce1e562b..c68e21b4ea0d 100644
--- a/arch/x86/kernel/cpu/mce/core.c
+++ b/arch/x86/kernel/cpu/mce/core.c
@@ -2178,7 +2178,6 @@ __setup("mce", mcheck_enable);
int __init mcheck_init(void)
{
- mcheck_intel_therm_init();
mce_register_decode_chain(&early_nb);
mce_register_decode_chain(&mce_uc_nb);
mce_register_decode_chain(&mce_default_nb);
diff --git a/arch/x86/kernel/cpu/mce/therm_throt.c
b/arch/x86/kernel/cpu/mce/therm_throt.c
index a7cd2d203ced..5b1aa0f30655 100644
--- a/arch/x86/kernel/cpu/mce/therm_throt.c
+++ b/arch/x86/kernel/cpu/mce/therm_throt.c
@@ -633,23 +633,15 @@ static int intel_thermal_supported(struct cpuinfo_x86 *c)
return 1;
}
-void __init mcheck_intel_therm_init(void)
-{
- /*
-* This function is only called on boot CPU. Save the init thermal
-* LVT value on BSP and use that value to restore APs' thermal LVT
-* entry BIOS programmed later
-*/
- if (intel_thermal_supported(&boot_cpu_data))
- lvtthmr_init = apic_read(APIC_LVTTHMR);
-}
-
void intel_init_thermal(struct cpuinfo_x86 *c)
{
unsigned int cpu = smp_processor_id();
int tm2 = 0;
u32 l, h;
+ if ((c == &boot_cpu_data) && intel_thermal_supported(c))
+ lvtthmr_init = apic_read(APIC_LVTTHMR);
+
if (!intel_thermal_supported(c))
return;
--
2.29.2
[PATCH v2 2/2] thermal: Move therm_throt there from x86/mce
From: Borislav Petkov
This functionality has nothing to do with MCE, move it to the thermal
framework and untangle it from MCE.
Have thermal_set_handler() check the build-time assigned default handler
stub was the one used before therm_throt assigns a new one.
Requested-by: Peter Zijlstra
Signed-off-by: Borislav Petkov
---
arch/x86/Kconfig | 4 ---
arch/x86/include/asm/irq.h| 4 +++
arch/x86/include/asm/mce.h| 16 --
arch/x86/include/asm/thermal.h| 21 ++
arch/x86/kernel/cpu/intel.c | 3 ++
arch/x86/kernel/cpu/mce/Makefile | 2 --
arch/x86/kernel/cpu/mce/intel.c | 1 -
arch/x86/kernel/irq.c | 29 +++
drivers/thermal/intel/Kconfig | 4 +++
drivers/thermal/intel/Makefile| 1 +
.../thermal/intel}/therm_throt.c | 25 ++--
drivers/thermal/intel/x86_pkg_temp_thermal.c | 3 +-
12 files changed, 67 insertions(+), 46 deletions(-)
create mode 100644 arch/x86/include/asm/thermal.h
rename {arch/x86/kernel/cpu/mce => drivers/thermal/intel}/therm_throt.c (97%)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 21f851179ff0..9989db3a9bf5 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1158,10 +1158,6 @@ config X86_MCE_INJECT
If you don't know what a machine check is and you don't do kernel
QA it is safe to say n.
-config X86_THERMAL_VECTOR
- def_bool y
- depends on X86_MCE_INTEL
-
source "arch/x86/events/Kconfig"
config X86_LEGACY_VM86
diff --git a/arch/x86/include/asm/irq.h b/arch/x86/include/asm/irq.h
index 528c8a71fe7f..ad65fe7dceb1 100644
--- a/arch/x86/include/asm/irq.h
+++ b/arch/x86/include/asm/irq.h
@@ -53,4 +53,8 @@ void arch_trigger_cpumask_backtrace(const struct cpumask
*mask,
#define arch_trigger_cpumask_backtrace arch_trigger_cpumask_backtrace
#endif
+#ifdef CONFIG_X86_THERMAL_VECTOR
+void thermal_set_handler(void (*handler)(void));
+#endif
+
#endif /* _ASM_X86_IRQ_H */
diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index def9aa5e1fa4..ddfb3cad8dff 100644
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -288,22 +288,6 @@ extern void (*mce_threshold_vector)(void);
/* Deferred error interrupt handler */
extern void (*deferred_error_int_vector)(void);
-/*
- * Thermal handler
- */
-
-void intel_init_thermal(struct cpuinfo_x86 *c);
-
-/* Interrupt Handler for core thermal thresholds */
-extern int (*platform_thermal_notify)(__u64 msr_val);
-
-/* Interrupt Handler for package thermal thresholds */
-extern int (*platform_thermal_package_notify)(__u64 msr_val);
-
-/* Callback support of rate control, return true, if
- * callback has rate control */
-extern bool (*platform_thermal_package_rate_control)(void);
-
/*
* Used by APEI to report memory error via /dev/mcelog
*/
diff --git a/arch/x86/include/asm/thermal.h b/arch/x86/include/asm/thermal.h
new file mode 100644
index ..58b0e0a4af6e
--- /dev/null
+++ b/arch/x86/include/asm/thermal.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_X86_THERMAL_H
+#define _ASM_X86_THERMAL_H
+
+/* Interrupt Handler for package thermal thresholds */
+extern int (*platform_thermal_package_notify)(__u64 msr_val);
+
+/* Interrupt Handler for core thermal thresholds */
+extern int (*platform_thermal_notify)(__u64 msr_val);
+
+/* Callback support of rate control, return true, if
+ * callback has rate control */
+extern bool (*platform_thermal_package_rate_control)(void);
+
+#ifdef CONFIG_X86_THERMAL_VECTOR
+void intel_init_thermal(struct cpuinfo_x86 *c);
+#else
+static inline void intel_init_thermal(struct cpuinfo_x86 *c) { }
+#endif
+
+#endif /* _ASM_X86_THERMAL_H */
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 59a1e3ce3f14..71221af87cb1 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_X86_64
#include
@@ -719,6 +720,8 @@ static void init_intel(struct cpuinfo_x86 *c)
tsx_disable();
split_lock_init();
+
+ intel_init_thermal(c);
}
#ifdef CONFIG_X86_32
diff --git a/arch/x86/kernel/cpu/mce/Makefile b/arch/x86/kernel/cpu/mce/Makefile
index 9f020c994154..015856abdbb1 100644
--- a/arch/x86/kernel/cpu/mce/Makefile
+++ b/arch/x86/kernel/cpu/mce/Makefile
@@ -9,8 +9,6 @@ obj-$(CONFIG_X86_MCE_THRESHOLD) += threshold.o
mce-inject-y := inject.o
obj-$(CONFIG_X86_MCE_INJECT) += mce-inject.o
-obj-$(CONFIG_X86_THERMAL_VECTOR) += therm_throt.o
-
obj-$(CONFIG_ACPI_APEI)+= apei.o
obj-$(CONFIG_X86_MCELOG_LEGACY)+= dev-mcelog.o
diff --git a/arch/x86/kernel/cpu/mce/intel.c b/arch/x86/kernel/cpu/mce/intel.c
index c2476fe0682e..e309476743b7 100644
--- a/arch/x86/kernel/cpu/mce/intel.c
+++ b/
Re: [PATCH v4 1/4] mm: cma: introduce gfp flag in cma_alloc instead of no_warn
On Thu 21-01-21 09:54:59, Minchan Kim wrote:
> The upcoming patch will introduce __GFP_NORETRY semantic
> in alloc_contig_range which is a failfast mode of the API.
> Instead of adding a additional parameter for gfp, replace
> no_warn with gfp flag.
>
> To keep old behaviors, it follows the rule below.
>
> no_warn gfp_flags
>
> false GFP_KERNEL
> trueGFP_KERNEL|__GFP_NOWARN
> gfp & __GFP_NOWARN GFP_KERNEL | (gfp & __GFP_NOWARN)
>
> Reviewed-by: Suren Baghdasaryan
> Signed-off-by: Minchan Kim
[...]
> diff --git a/mm/cma.c b/mm/cma.c
> index 0ba69cd16aeb..d50627686fec 100644
> --- a/mm/cma.c
> +++ b/mm/cma.c
> @@ -419,13 +419,13 @@ static inline void cma_debug_show_areas(struct cma
> *cma) { }
> * @cma: Contiguous memory region for which the allocation is performed.
> * @count: Requested number of pages.
> * @align: Requested alignment of pages (in PAGE_SIZE order).
> - * @no_warn: Avoid printing message about failed allocation
> + * @gfp_mask: GFP mask to use during the cma allocation.
Call out supported gfp flags explicitly. Have a look at kvmalloc_node
for a guidance.
--
Michal Hocko
SUSE Labs
[PATCH 0/1] mfd: da9063: Support SMBus and I2C mode
On an NXP i.MX6 Solo processor we are running an application which makes use of real-time threads (SCHED_RR). In combination with a DA9063 we experienced (rare) random shut-downs and reboots. We found that the issue was caused by a combination of the (default) DA9063 SMBus mode and non-atomic I2C transactions of the i.MX6 I2C driver. Because a transaction could be idle for longer than the SMBus clock time-out due to a real-time thread the DA9063 would time-out and receive the second half of the transaction as an unintended message. The solution we are giving to review in this patch is to allow using the I2C mode of the DA9063. We kindly ask for feedback and eventually hope for an integration to the mainline. Because we are on a vendor kernel we were not able to test this patch on the current mainline kernel. Though, we tested a (very similar) patch on our (close to mainline) Linux 4.14 and 5.4 vendor kernels. Hubert Streidl (1): mfd: da9063: Support SMBus and I2C mode Documentation/devicetree/bindings/mfd/da9063.txt | 7 +++ drivers/mfd/da9063-core.c| 9 + drivers/mfd/da9063-i2c.c | 13 + include/linux/mfd/da9063/core.h | 1 + include/linux/mfd/da9063/registers.h | 3 +++ 5 files changed, 33 insertions(+) -- 2.25.1
Re: [PATCH] ath9k: fix build error with LEDS_CLASS=m
On Mon, Jan 25, 2021 at 12:40 PM Krzysztof Kozlowski wrote: > On Mon, 25 Jan 2021 at 12:36, Arnd Bergmann wrote: > > > > From: Arnd Bergmann > > > > When CONFIG_ATH9K is built-in but LED support is in a loadable > > module, both ath9k drivers fails to link: > > > > x86_64-linux-ld: drivers/net/wireless/ath/ath9k/gpio.o: in function > > `ath_deinit_leds': > > gpio.c:(.text+0x36): undefined reference to `led_classdev_unregister' > > x86_64-linux-ld: drivers/net/wireless/ath/ath9k/gpio.o: in function > > `ath_init_leds': > > gpio.c:(.text+0x179): undefined reference to `led_classdev_register_ext' > > > > The problem is that the 'imply' keyword does not enforce any dependency > > but is only a weak hint to Kconfig to enable another symbol from a > > defconfig file. > > > > Change imply to a 'depends on LEDS_CLASS' that prevents the incorrect > > configuration but still allows building the driver without LED support. > > > > The 'select MAC80211_LEDS' is now ensures that the LED support is > > actually used if it is present, and the added Kconfig dependency > > on MAC80211_LEDS ensures that it cannot be enabled manually when it > > has no effect. > > But we do not want to have this dependency (selecting MAC80211_LEDS). > I fixed this problem here: > https://lore.kernel.org/lkml/20201227143034.1134829-1-k...@kernel.org/ > Maybe let's take this approach? Generally speaking, I don't like to have a device driver specific Kconfig setting 'select' a subsystem', for two reasons: - you suddenly get asked for tons of new LED specific options when enabling seemingly benign options - Mixing 'depends on' and 'select' leads to bugs with circular dependencies that usually require turning some other 'select' into 'depends on'. The problem with LEDS_CLASS in particular is that there is a mix of drivers using one vs the other roughly 50:50. Arnd
Re: [PATCH net-next v2 2/2] net: dsa: mt7530: MT7530 optional GPIO support
On Mon, Jan 25, 2021 at 5:43 AM DENG Qingfang wrote: > MT7530's LED controller can drive up to 15 LED/GPIOs. > > Add support for GPIO control and allow users to use its GPIOs by > setting gpio-controller property in device tree. > > Signed-off-by: DENG Qingfang Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH v4 2/4] mm: failfast mode with __GFP_NORETRY in alloc_contig_range
On Mon 25-01-21 14:12:02, Michal Hocko wrote: > On Thu 21-01-21 09:55:00, Minchan Kim wrote: > > Contiguous memory allocation can be stalled due to waiting > > on page writeback and/or page lock which causes unpredictable > > delay. It's a unavoidable cost for the requestor to get *big* > > contiguous memory but it's expensive for *small* contiguous > > memory(e.g., order-4) because caller could retry the request > > in different range where would have easy migratable pages > > without stalling. > > > > This patch introduce __GFP_NORETRY as compaction gfp_mask in > > alloc_contig_range so it will fail fast without blocking > > when it encounters pages needed waiting. > > I am not against controling how hard this allocator tries with gfp mask > but this changelog is rather void on any data and any user. OK, I can see that a user is in the last patch. -- Michal Hocko SUSE Labs
Re: [PATCH net-next v2 1/2] dt-bindings: net: dsa: add MT7530 GPIO controller binding
On Mon, Jan 25, 2021 at 5:43 AM DENG Qingfang wrote: > Add device tree binding to support MT7530 GPIO controller. > > Signed-off-by: DENG Qingfang Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: 5.11 new lockdep warning related to led-class code (also may involve ata / piix controller)
Hi,
On 1/13/21 9:59 AM, Hans de Goede wrote:
> Hi,
>
> On 1/12/21 11:30 PM, Pavel Machek wrote:
>> Hi!
>>
>>> Booting a 5.11-rc2 kernel with lockdep enabled inside a virtualbox vm
>>> (which still
>>> emulates good old piix ATA controllers) I get the below lockdep splat early
>>> on during boot:
>>>
>>> This seems to be led-class related but also seems to have a (P)ATA
>>> part to it. To the best of my knowledge this is a new problem in
>>> 5.11 .
>>
>> This is on my for-next branch:
>>
>> commit 9a5ad5c5b2d25508996f10ee6b428d5df91d9160 (HEAD -> for-next,
>> origin/for-next)
>>
>> leds: trigger: fix potential deadlock with libata
>>
>> We have the following potential deadlock condition:
>>
>>
>> WARNING: possible irq lock inversion dependency detected
>> 5.10.0-rc2+ #25 Not tainted
>>
>> swapper/3/0 just changed the state of lock:
>> 8880063bd618 (&host->lock){-...}-{2:2}, at:
>> ata_bmdma_interrupt+0x27/0x200
>> but this lock took another, HARDIRQ-READ-unsafe lock in the past:
>> (&trig->leddev_list_lock){.+.?}-{2:2}
>>
>> If I'm not mistaken, that should fix your issue.
>
> I can confirm that this fixes things, thanks.
>
> I assume that this will be part of some future 5.11 fixes pull-req?
This *regression* fix seems to still have not landed in 5.11-rc5, can
we please get this on its way to Linus ?
Regards,
Hans
Re: [PATCH bpf-next v3 3/3] xsk: build skb by page
On Mon, Jan 25, 2021 at 1:43 PM Xuan Zhuo wrote:
>
> On Mon, 25 Jan 2021 08:44:38 +0100, Magnus Karlsson
> wrote:
> > On Mon, Jan 25, 2021 at 3:27 AM Xuan Zhuo
> > wrote:
> > >
> > > On Fri, 22 Jan 2021 19:37:06 +0100, Magnus Karlsson
> > > wrote:
> > > > On Fri, Jan 22, 2021 at 6:26 PM Alexander Lobakin
> > > > wrote:
> > > > >
> > > > > From: Xuan Zhuo
> > > > > Date: Fri, 22 Jan 2021 23:39:15 +0800
> > > > >
> > > > > > On Fri, 22 Jan 2021 13:55:14 +0100, Magnus Karlsson
> > > > > > wrote:
> > > > > > > On Fri, Jan 22, 2021 at 1:39 PM Alexander Lobakin
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > From: Magnus Karlsson
> > > > > > > > Date: Fri, 22 Jan 2021 13:18:47 +0100
> > > > > > > >
> > > > > > > > > On Fri, Jan 22, 2021 at 12:57 PM Alexander Lobakin
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > From: Alexander Lobakin
> > > > > > > > > > Date: Fri, 22 Jan 2021 11:47:45 +
> > > > > > > > > >
> > > > > > > > > > > From: Eric Dumazet
> > > > > > > > > > > Date: Thu, 21 Jan 2021 16:41:33 +0100
> > > > > > > > > > >
> > > > > > > > > > > > On 1/21/21 2:47 PM, Xuan Zhuo wrote:
> > > > > > > > > > > > > This patch is used to construct skb based on page to
> > > > > > > > > > > > > save memory copy
> > > > > > > > > > > > > overhead.
> > > > > > > > > > > > >
> > > > > > > > > > > > > This function is implemented based on
> > > > > > > > > > > > > IFF_TX_SKB_NO_LINEAR. Only the
> > > > > > > > > > > > > network card priv_flags supports IFF_TX_SKB_NO_LINEAR
> > > > > > > > > > > > > will use page to
> > > > > > > > > > > > > directly construct skb. If this feature is not
> > > > > > > > > > > > > supported, it is still
> > > > > > > > > > > > > necessary to copy data to construct skb.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Performance Testing
> > > > > > > > > > > > >
> > > > > > > > > > > > > The test environment is Aliyun ECS server.
> > > > > > > > > > > > > Test cmd:
> > > > > > > > > > > > > ```
> > > > > > > > > > > > > xdpsock -i eth0 -t -S -s
> > > > > > > > > > > > > ```
> > > > > > > > > > > > >
> > > > > > > > > > > > > Test result data:
> > > > > > > > > > > > >
> > > > > > > > > > > > > size64 512 10241500
> > > > > > > > > > > > > copy1916747 1775988 1600203 1440054
> > > > > > > > > > > > > page1974058 1953655 1945463 1904478
> > > > > > > > > > > > > percent 3.0%10.0% 21.58% 32.3%
> > > > > > > > > > > > >
> > > > > > > > > > > > > Signed-off-by: Xuan Zhuo
> > > > > > > > > > > > > Reviewed-by: Dust Li
> > > > > > > > > > > > > ---
> > > > > > > > > > > > > net/xdp/xsk.c | 104
> > > > > > > > > > > > > --
> > > > > > > > > > > > > 1 file changed, 86 insertions(+), 18 deletions(-)
> > > > > > > > > > > > >
> > > > > > > > > > > > > diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
> > > > > > > > > > > > > index 4a83117..38af7f1 100644
> > > > > > > > > > > > > --- a/net/xdp/xsk.c
> > > > > > > > > > > > > +++ b/net/xdp/xsk.c
> > > > > > > > > > > > > @@ -430,6 +430,87 @@ static void
> > > > > > > > > > > > > xsk_destruct_skb(struct sk_buff *skb)
> > > > > > > > > > > > > sock_wfree(skb);
> > > > > > > > > > > > > }
> > > > > > > > > > > > >
> > > > > > > > > > > > > +static struct sk_buff *xsk_build_skb_zerocopy(struct
> > > > > > > > > > > > > xdp_sock *xs,
> > > > > > > > > > > > > + struct
> > > > > > > > > > > > > xdp_desc *desc)
> > > > > > > > > > > > > +{
> > > > > > > > > > > > > + u32 len, offset, copy, copied;
> > > > > > > > > > > > > + struct sk_buff *skb;
> > > > > > > > > > > > > + struct page *page;
> > > > > > > > > > > > > + void *buffer;
> > > > > > > > > > > > > + int err, i;
> > > > > > > > > > > > > + u64 addr;
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + skb = sock_alloc_send_skb(&xs->sk, 0, 1, &err);
> > > > > > > > > > > > > + if (unlikely(!skb))
> > > > > > > > > > > > > + return ERR_PTR(err);
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + addr = desc->addr;
> > > > > > > > > > > > > + len = desc->len;
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + buffer = xsk_buff_raw_get_data(xs->pool, addr);
> > > > > > > > > > > > > + offset = offset_in_page(buffer);
> > > > > > > > > > > > > + addr = buffer - xs->pool->addrs;
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + for (copied = 0, i = 0; copied < len; i++) {
> > > > > > > > > > > > > + page = xs->pool->umem->pgs[addr >>
> > > > > > > > > > > > > PAGE_SHIFT];
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + get_page(page);
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + copy = min_t(u32, PAGE_SIZE - offset, len -
> > > > > > > > > > > > > copied);
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + skb_fill_page_desc(skb, i, page, offset,
> > > > > > > > > > > > > copy);
> > > > > > > > > > > > > +
Re: KASAN: slab-out-of-bounds Write in record_print_text
On 2021-01-25, syzbot
wrote:
> syzbot found the following issue on:
>
> HEAD commit:e6806137 Merge tag 'irq_urgent_for_v5.11_rc5' of git://git..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=10c59c6f50
> kernel config: https://syzkaller.appspot.com/x/.config?x=be33d8015c9de024
> dashboard link: https://syzkaller.appspot.com/bug?extid=a42d84593d6a89a76f26
> compiler: gcc (GCC) 10.1.0-syz 20200507
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1575e6b4d0
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17aea4e8d0
>
> The issue was bisected to:
>
> commit f0e386ee0c0b71ea6f7238506a4d0965a2dbef11
> Author: John Ogness
> Date: Thu Jan 14 17:04:12 2021 +
>
> printk: fix buffer overflow potential for print_text()
Thank you syzbot for your valuable work. A fix has already been posted
and queued:
https://lkml.kernel.org/r/20210124202728.4718-1-john.ogn...@linutronix.de
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17f30130d0
> final oops: https://syzkaller.appspot.com/x/report.txt?x=140b0130d0
> console output: https://syzkaller.appspot.com/x/log.txt?x=100b0130d0
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+a42d84593d6a89a76...@syzkaller.appspotmail.com
> Fixes: f0e386ee0c0b ("printk: fix buffer overflow potential for print_text()")
>
> ==
> BUG: KASAN: slab-out-of-bounds in record_print_text+0x33f/0x380
> kernel/printk/printk.c:1401
> Write of size 1 at addr 88801c2faf40 by task in:imklog/8158
>
> CPU: 1 PID: 8158 Comm: in:imklog Not tainted 5.11.0-rc4-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:79 [inline]
> dump_stack+0x107/0x163 lib/dump_stack.c:120
> print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:230
> __kasan_report mm/kasan/report.c:396 [inline]
> kasan_report.cold+0x79/0xd5 mm/kasan/report.c:413
> record_print_text+0x33f/0x380 kernel/printk/printk.c:1401
> syslog_print+0x2bb/0x430 kernel/printk/printk.c:1459
> do_syslog.part.0+0x2a8/0x7c0 kernel/printk/printk.c:1586
> do_syslog+0x49/0x60 kernel/printk/printk.c:1567
> kmsg_read+0x90/0xb0 fs/proc/kmsg.c:40
> pde_read fs/proc/inode.c:321 [inline]
> proc_reg_read+0x119/0x300 fs/proc/inode.c:331
> vfs_read+0x1b5/0x570 fs/read_write.c:494
> ksys_read+0x12d/0x250 fs/read_write.c:634
> do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
> RIP: 0033:0x7f3e2eec922d
> Code: c1 20 00 00 75 10 b8 00 00 00 00 0f 05 48 3d 01 f0 ff ff 73 31 c3 48 83
> ec 08 e8 4e fc ff ff 48 89 04 24 b8 00 00 00 00 0f 05 <48> 8b 3c 24 48 89 c2
> e8 97 fc ff ff 48 89 d0 48 83 c4 08 48 3d 01
> RSP: 002b:7f3e2c865580 EFLAGS: 0293 ORIG_RAX:
> RAX: ffda RBX: RCX: 7f3e2eec922d
> RDX: 1fa0 RSI: 7f3e2c865da0 RDI: 0004
> RBP: 55d0880849d0 R08: R09: 0401
> R10: 0001 R11: 0293 R12: 7f3e2c865da0
> R13: 1fa0 R14: 1f9f R15: 7f3e2c865df3
>
> Allocated by task 8158:
> kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38
> kasan_set_track mm/kasan/common.c:46 [inline]
> set_alloc_info mm/kasan/common.c:401 [inline]
> kasan_kmalloc.constprop.0+0x82/0xa0 mm/kasan/common.c:429
> kmalloc include/linux/slab.h:552 [inline]
> syslog_print+0xb2/0x430 kernel/printk/printk.c:1430
> do_syslog.part.0+0x2a8/0x7c0 kernel/printk/printk.c:1586
> do_syslog+0x49/0x60 kernel/printk/printk.c:1567
> kmsg_read+0x90/0xb0 fs/proc/kmsg.c:40
> pde_read fs/proc/inode.c:321 [inline]
> proc_reg_read+0x119/0x300 fs/proc/inode.c:331
> vfs_read+0x1b5/0x570 fs/read_write.c:494
> ksys_read+0x12d/0x250 fs/read_write.c:634
> do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> The buggy address belongs to the object at 88801c2fa800
> which belongs to the cache kmalloc-1k of size 1024
> The buggy address is located 832 bytes to the right of
> 1024-byte region [88801c2fa800, 88801c2fac00)
> The buggy address belongs to the page:
> page:eb65f4f5 refcount:1 mapcount:0 mapping:
> index:0x0 pfn:0x1c2f8
> head:eb65f4f5 order:2 compound_mapcount:0 compound_pincount:0
> flags: 0xfff0010200(slab|head)
> raw: 00fff0010200 dead0100 dead0122 888010041140
> raw: 80080008 0001
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> 88801c2fae00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> 88801c2fae80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>>88801c2faf00: fc fc fc fc fc fc fc fc f
Re: [PATCH 1/1] process_madvise.2: Add process_madvise man page
On Wed 20-01-21 12:23:37, Suren Baghdasaryan wrote: [...] > MADV_COLD (since Linux 5.4.1) > Deactivate a given range of pages by moving them from active to > inactive LRU list. This is done to accelerate the reclaim of these > pages. The advice might be ignored for some pages in the range when it > is not applicable. I do not think we want to talk about active/inactive LRU lists here. Wouldn't it be sufficient to say Deactive a given range of pages which will make them a more probable reclaim target should there be a memory pressure. This is a non-destructive operation. Other than that, looks good to me from the content POV. Thanks! -- Michal Hocko SUSE Labs
Re: [PATCH v2 00/14] PHY: Add support in Sierra to use external clock
On 22/12/20 12:35 pm, Kishon Vijay Abraham I wrote: > The previous version of the patch series can be found @ [1] > > Changes from v1: > 1) Remove the part that prevents configuration if the SERDES is already >configured and focus only on using external clock and the associated >cleanups > 2) Change patch ordering > 3) Use exclusive reset control APIs > 4) Fix error handling code > 5) Include DT patches in this series (I can send this separately to DT > MAINTAINER once the driver patches are merged) > > [1] -> http://lore.kernel.org/r/20201103035556.21260-1-kis...@ti.com > I have couple of reports from kernel test robot. If there are any other comments on this series, I can fix them. Thanks Kishon > Kishon Vijay Abraham I (14): > phy: cadence: Sierra: Fix PHY power_on sequence > phy: ti: j721e-wiz: Invoke wiz_init() before > of_platform_device_create() > dt-bindings: phy: cadence-sierra: Add bindings for the PLLs within > SERDES > phy: ti: j721e-wiz: Get PHY properties only for "phy" or "link" > subnode > phy: cadence: cadence-sierra: Create PHY only for "phy" or "link" > sub-nodes > phy: cadence: cadence-sierra: Move all clk_get_*() to a separate > function > phy: cadence: cadence-sierra: Move all reset_control_get*() to a > separate function > phy: cadence: cadence-sierra: Explicitly request exclusive reset > control > phy: cadence: sierra: Model reference receiver as clocks (gate clocks) > phy: cadence: sierra: Enable pll_cmnlc and pll_cmnlc1 clocks > arm64: dts: ti: k3-j721e-main: Add DT nodes for clocks within Sierra > SERDES > arm64: dts: ti: k3-j721e-main: Fix external refclk input to SERDES > arm64: dts: ti: k3-j721e-common-proc-board: Use external clock for > SERDES > arm64: dts: ti: k3-j721e-common-proc-board: Re-name "link" name as > "phy" > > .../bindings/phy/phy-cadence-sierra.yaml | 89 ++- > .../dts/ti/k3-j721e-common-proc-board.dts | 57 +- > arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 186 -- > drivers/phy/cadence/phy-cadence-sierra.c | 543 -- > drivers/phy/ti/phy-j721e-wiz.c| 21 +- > 5 files changed, 808 insertions(+), 88 deletions(-) >
Re: [PATCH] sched/fair: Rate limit calls to update_blocked_averages() for NOHZ
On Fri, 22 Jan 2021 at 19:39, Qais Yousef wrote: > > On 01/22/21 17:56, Vincent Guittot wrote: > > > --- > > > kernel/sched/fair.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > > > index 04a3ce20da67..fe2dc0024db5 100644 > > > --- a/kernel/sched/fair.c > > > +++ b/kernel/sched/fair.c > > > @@ -8381,7 +8381,7 @@ static bool update_nohz_stats(struct rq *rq, bool > > > force) > > > if (!cpumask_test_cpu(cpu, nohz.idle_cpus_mask)) > > > return false; > > > > > > - if (!force && !time_after(jiffies, > > > rq->last_blocked_load_update_tick)) > > > + if (!force && !time_after(jiffies, > > > rq->last_blocked_load_update_tick + (HZ/20))) > > > > This condition is there to make sure to update blocked load at most > > once a tick in order to filter newly idle case otherwise the rate > > limit is already done by load balance interval > > This hard coded (HZ/20) looks really like an ugly hack > > This was meant as an RFC patch to discuss the problem really. > > Joel is seeing update_blocked_averages() taking ~100us. Half of it seems in > processing __update_blocked_fair() and the other half in > sugov_update_shared(). > So roughly 50us each. Note that each function is calling an iterator in Can I assume that a freq change happens if sugov_update_shared() takes 50us ? which would mean that the update was useful at the end ? > return. Correct me if my numbers are wrong Joel. > > Running on a little core on low frequency these numbers don't look too odd. > So I'm not seeing how we can speed these functions up. > > But since update_sg_lb_stats() will end up with multiple calls to > update_blocked_averages() in one go, this latency adds up quickly. > > One noticeable factor in Joel's system is the presence of a lot of cgroups. > Which is essentially what makes __update_blocked_fair() expensive, and it > seems > to always return something has decayed so we end up with a call to > sugov_update_shared() in every call. > > I think we should limit the expensive call to update_blocked_averages() but At the opposite, some will complain that block values stay stall to high value and prevent any useful adjustment. Also update_blocked average is already rate limited with idle and busy load_balance Seems like the problem raised by Joel is the number of newly idle load balance > I honestly don't know what would be the right way to do it :-/ > > Or maybe there's another better alternative too.. > > Thanks > > -- > Qais Yousef > > > > > > return true; > > > > > > update_blocked_averages(cpu); > > > -- > > > 2.30.0.280.ga3ce27912f-goog > > >
Re: [PATCH] [5.8 regression] net: ks8851: fix link error
On Mon, Jan 25, 2021 at 01:19:20PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> An object file cannot be built for both loadable module and built-in
> use at the same time:
>
> arm-linux-gnueabi-ld: drivers/net/ethernet/micrel/ks8851_common.o: in
> function `ks8851_probe_common':
> ks8851_common.c:(.text+0xf80): undefined reference to `__this_module'
>
> Change the ks8851_common code to be a standalone module instead,
> and use Makefile logic to ensure this is built-in if at least one
> of its two users is.
>
> Fixes: 797047f875b5 ("net: ks8851: Implement Parallel bus operations")
> Signed-off-by: Arnd Bergmann
Reviewed-by: Andrew Lunn
Andrew
Re: [PATCH v2 2/4] KVM: SVM: Add emulation support for #GP triggered by SVM instructions
On Thu, 2021-01-21 at 14:40 -0800, Sean Christopherson wrote: > On Thu, Jan 21, 2021, Maxim Levitsky wrote: > > BTW, on unrelated note, currently the smap test is broken in kvm-unit tests. > > I bisected it to commit 322cdd6405250a2a3e48db199f97a45ef519e226 > > > > It seems that the following hack (I have no idea why it works, > > since I haven't dug deep into the area 'fixes', the smap test for me) > > > > -#define USER_BASE (1 << 24) > > +#define USER_BASE (1 << 25) > > https://lkml.kernel.org/r/2021012808.619347-2-imbre...@linux.ibm.com > Thanks! Best regards, Maxim Levitsky
Re: [PATCH] m68k: let clk_enable() return immediately if clk is NULL
Hi Defang,
On 28/12/20 12:07 pm, Defang Bo wrote:
Similar to commit<742859adc721>("m68k: let clk_disable() return immediately if clk
is NULL").
there should be a check for clk to prevent NULL pointer dereference.
Signed-off-by: Defang Bo
I have applied this to the m68knommu git tree, for-next branch -
with blank line added as per Geert's suggestion.
Regards
Greg
---
arch/m68k/coldfire/clk.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/m68k/coldfire/clk.c b/arch/m68k/coldfire/clk.c
index 7bc666e..6decd11 100644
--- a/arch/m68k/coldfire/clk.c
+++ b/arch/m68k/coldfire/clk.c
@@ -90,6 +90,9 @@ EXPORT_SYMBOL(clk_get);
int clk_enable(struct clk *clk)
{
unsigned long flags;
+ if (!clk)
+ return -EINVAL;
+
spin_lock_irqsave(&clk_lock, flags);
if ((clk->enabled++ == 0) && clk->clk_ops)
clk->clk_ops->enable(clk);
Re: [PATCH] dsa: vsc73xx: add support for vlan filtering
On Mon, Jan 25, 2021 at 12:45 AM Vladimir Oltean wrote: > Anyhow, you did not approve or disprove the tag_8021q idea. I just don't understand it well enough so I didn't know what to say about that... > With VLAN trunking on the CPU port, how would per-port traffic be > managed? Would it be compatible with hardware-accelerated bridging > (which this driver still does not support)? I think in vendor code it is done like it is done on the RTL8366RB: one VLAN per port, so the filtering inside the switch isolate the ports by assigning them one VLAN each and the PTAG of the packets make sure they can only reach the desired port. (+/- my half-assed knowledge of how VLAN actually works, one day I think I understand it, next day I don't understand it anymore) Yours, Linus Walleij
Re: [PATCH] kgdb: use new API for breakpoint tasklet
On Mon, 25 Jan 2021 at 12:03, Daniel Thompson
wrote:
>
> On Sat, Jan 23, 2021 at 07:42:37PM +0100, Emil Renner Berthing wrote:
> > This converts the kgdb_tasklet_breakpoint to use the new API in
> > commit 12cc923f1ccc ("tasklet: Introduce new initialization API")
> >
> > The new API changes the argument passed to the callback function, but
> > fortunately the argument isn't used so it is straight forward to use
> > DECLARE_TASKLET() rather than DECLARE_TASKLET_OLD().
>
> This patch overlaps with a more ambitious patch from Davidlohr.
> Perhaps you can join in with the other thread since the discussion
> there is unresolved. See:
> https://lkml.org/lkml/2021/1/14/1320
Ah, that's cool. Getting rid of tasklets is much better than merely
trying to get rid of the old tasklet API. Please ignore this patch
then.
/Emil
>
> Daniel.
>
>
> >
> > Signed-off-by: Emil Renner Berthing
> > ---
> > kernel/debug/debug_core.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
> > index af6e8b4fb359..98d44c2bb0a4 100644
> > --- a/kernel/debug/debug_core.c
> > +++ b/kernel/debug/debug_core.c
> > @@ -1090,13 +1090,13 @@ static void kgdb_unregister_callbacks(void)
> > * such as is the case with kgdboe, where calling a breakpoint in the
> > * I/O driver itself would be fatal.
> > */
> > -static void kgdb_tasklet_bpt(unsigned long ing)
> > +static void kgdb_tasklet_bpt(struct tasklet_struct *unused)
> > {
> > kgdb_breakpoint();
> > atomic_set(&kgdb_break_tasklet_var, 0);
> > }
> >
> > -static DECLARE_TASKLET_OLD(kgdb_tasklet_breakpoint, kgdb_tasklet_bpt);
> > +static DECLARE_TASKLET(kgdb_tasklet_breakpoint, kgdb_tasklet_bpt);
> >
> > void kgdb_schedule_breakpoint(void)
> > {
> > --
> > 2.30.0
> >
Re: linux-next: build warning after merge of the xfs tree
On Mon, Jan 25, 2021 at 09:55:32AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the xfs tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> fs/xfs/xfs_log.c: In function 'xfs_log_cover':
> fs/xfs/xfs_log.c::16: warning: unused variable 'log' [-Wunused-variable]
> | struct xlog *log = mp->m_log;
> |^~~
>
> Introduced by commit
>
> 303591a0a947 ("xfs: cover the log during log quiesce")
>
Oops, patch below. Feel free to apply or squash into the original
commit.
Brian
--- 8< ---
>From 6078f06e2bd4c82111a85a2032c39a56654b0be6 Mon Sep 17 00:00:00 2001
From: Brian Foster
Date: Mon, 25 Jan 2021 08:22:56 -0500
Subject: [PATCH] xfs: fix unused log variable in xfs_log_cover()
The log variable is only used in kernels with asserts enabled.
Remove it and open code the dereference to avoid unused variable
warnings.
Signed-off-by: Brian Foster
---
fs/xfs/xfs_log.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/xfs/xfs_log.c b/fs/xfs/xfs_log.c
index 58699881c100..d8b814227734 100644
--- a/fs/xfs/xfs_log.c
+++ b/fs/xfs/xfs_log.c
@@ -1108,12 +1108,11 @@ static int
xfs_log_cover(
struct xfs_mount*mp)
{
- struct xlog *log = mp->m_log;
int error = 0;
boolneed_covered;
- ASSERT((xlog_cil_empty(log) && xlog_iclogs_empty(log) &&
- !xfs_ail_min_lsn(log->l_ailp)) ||
+ ASSERT((xlog_cil_empty(mp->m_log) && xlog_iclogs_empty(mp->m_log) &&
+ !xfs_ail_min_lsn(mp->m_log->l_ailp)) ||
XFS_FORCED_SHUTDOWN(mp));
if (!xfs_log_writable(mp))
--
2.26.2
Re: [PATCH 1/2] ecryptfs: fix uid translation for setxattr on security.capability
On Fri, Jan 22, 2021 at 7:31 PM Tyler Hicks wrote:
>
> On 2021-01-19 17:22:03, Miklos Szeredi wrote:
> > Prior to commit 7c03e2cda4a5 ("vfs: move cap_convert_nscap() call into
> > vfs_setxattr()") the translation of nscap->rootid did not take stacked
> > filesystems (overlayfs and ecryptfs) into account.
> >
> > That patch fixed the overlay case, but made the ecryptfs case worse.
>
> Thanks for sending a fix!
>
> I know that you don't have an eCryptfs setup to test with but I'm at a
> loss about how to test this from the userns/fscaps side of things. Do
> you have a sequence of unshare/setcap/getcap commands that I can run on
> a file inside of an eCryptfs mount to verify that the bug exists after
> 7c03e2cda4a5 and then again to verify that this patch fixes the bug?
You need two terminals:
$ =
# = root
$ unshare -Um
$ echo $$
# echo "0 1000 1" > uid_map
# cp uid_map gid_map
# echo 1000 2000 1 >> uid_map
# echo 2000 3000 1 >> uid_map
# cat uid_map > /proc//uid_map
# cat gid_map > /proc//gid_map
$ mkdir ~/tmp ~/mnt
$ mount -t tmpfs tmpfs ~/tmp
$ pwd
/home/
# nsenter -t -m
# [setup ecryptfs on /home//mnt using /home//tmp]
$ cd ~/mnt
$ touch test
$ /sbin/setcap -n 1000 cap_dac_override+eip test
$ /sbin/getcap -n test
test = cap_dac_override+eip [rootid=1000]
Without the patch, I'm thinking that it will do a double translate and
end up with rootid=2000 in the user namespace, but I might well have
messed it up...
Let me know how this goes.
Thanks,
Miklos
Re: [PATCH net-next v2 2/2] net: dsa: mt7530: MT7530 optional GPIO support
On Mon, Jan 25, 2021 at 12:43:22PM +0800, DENG Qingfang wrote: > MT7530's LED controller can drive up to 15 LED/GPIOs. > > Add support for GPIO control and allow users to use its GPIOs by > setting gpio-controller property in device tree. > > Signed-off-by: DENG Qingfang Reviewed-by: Andrew Lunn Andrew
Re: [PATCH] ath9k: fix build error with LEDS_CLASS=m
On Mon, 25 Jan 2021 at 14:09, Arnd Bergmann wrote: > > On Mon, Jan 25, 2021 at 12:40 PM Krzysztof Kozlowski wrote: > > On Mon, 25 Jan 2021 at 12:36, Arnd Bergmann wrote: > > > > > > From: Arnd Bergmann > > > > > > When CONFIG_ATH9K is built-in but LED support is in a loadable > > > module, both ath9k drivers fails to link: > > > > > > x86_64-linux-ld: drivers/net/wireless/ath/ath9k/gpio.o: in function > > > `ath_deinit_leds': > > > gpio.c:(.text+0x36): undefined reference to `led_classdev_unregister' > > > x86_64-linux-ld: drivers/net/wireless/ath/ath9k/gpio.o: in function > > > `ath_init_leds': > > > gpio.c:(.text+0x179): undefined reference to `led_classdev_register_ext' > > > > > > The problem is that the 'imply' keyword does not enforce any dependency > > > but is only a weak hint to Kconfig to enable another symbol from a > > > defconfig file. > > > > > > Change imply to a 'depends on LEDS_CLASS' that prevents the incorrect > > > configuration but still allows building the driver without LED support. > > > > > > The 'select MAC80211_LEDS' is now ensures that the LED support is > > > actually used if it is present, and the added Kconfig dependency > > > on MAC80211_LEDS ensures that it cannot be enabled manually when it > > > has no effect. > > > > But we do not want to have this dependency (selecting MAC80211_LEDS). > > I fixed this problem here: > > https://lore.kernel.org/lkml/20201227143034.1134829-1-k...@kernel.org/ > > Maybe let's take this approach? > > Generally speaking, I don't like to have a device driver specific Kconfig > setting 'select' a subsystem', for two reasons: > > - you suddenly get asked for tons of new LED specific options when > enabling seemingly benign options > > - Mixing 'depends on' and 'select' leads to bugs with circular > dependencies that usually require turning some other 'select' > into 'depends on'. > > The problem with LEDS_CLASS in particular is that there is a mix of drivers > using one vs the other roughly 50:50. Yes, you are right, I also don't like it. However it was like this before my commit so I am not introducing a new issue. The point is that in your choice the MAC80211_LEDS will be selected if LEDS_CLASS is present, which is exactly what I was trying to fix/remove. My WiFi dongle does not have a LED and it causes a periodic (every second) event. However I still have LEDS_CLASS for other LEDS in the system. Best regards, Krzysztof On Mon, 25 Jan 2021 at 14:09, Arnd Bergmann wrote: > > On Mon, Jan 25, 2021 at 12:40 PM Krzysztof Kozlowski wrote: > > On Mon, 25 Jan 2021 at 12:36, Arnd Bergmann wrote: > > > > > > From: Arnd Bergmann > > > > > > When CONFIG_ATH9K is built-in but LED support is in a loadable > > > module, both ath9k drivers fails to link: > > > > > > x86_64-linux-ld: drivers/net/wireless/ath/ath9k/gpio.o: in function > > > `ath_deinit_leds': > > > gpio.c:(.text+0x36): undefined reference to `led_classdev_unregister' > > > x86_64-linux-ld: drivers/net/wireless/ath/ath9k/gpio.o: in function > > > `ath_init_leds': > > > gpio.c:(.text+0x179): undefined reference to `led_classdev_register_ext' > > > > > > The problem is that the 'imply' keyword does not enforce any dependency > > > but is only a weak hint to Kconfig to enable another symbol from a > > > defconfig file. > > > > > > Change imply to a 'depends on LEDS_CLASS' that prevents the incorrect > > > configuration but still allows building the driver without LED support. > > > > > > The 'select MAC80211_LEDS' is now ensures that the LED support is > > > actually used if it is present, and the added Kconfig dependency > > > on MAC80211_LEDS ensures that it cannot be enabled manually when it > > > has no effect. > > > > But we do not want to have this dependency (selecting MAC80211_LEDS). > > I fixed this problem here: > > https://lore.kernel.org/lkml/20201227143034.1134829-1-k...@kernel.org/ > > Maybe let's take this approach? > > Generally speaking, I don't like to have a device driver specific Kconfig > setting 'select' a subsystem', for two reasons: > > - you suddenly get asked for tons of new LED specific options when > enabling seemingly benign options > > - Mixing 'depends on' and 'select' leads to bugs with circular > dependencies that usually require turning some other 'select' > into 'depends on'. > > The problem with LEDS_CLASS in particular is that there is a mix of drivers > using one vs the other roughly 50:50. > > Arnd
Re: [PATCH bpf-next v3 3/3] xsk: build skb by page
From: Xuan Zhuo
Date: Mon, 25 Jan 2021 11:10:43 +0800
> On Fri, 22 Jan 2021 16:24:17 +, Alexander Lobakin wrote:
> > From: Xuan Zhuo
> > Date: Fri, 22 Jan 2021 23:36:29 +0800
> >
> > > On Fri, 22 Jan 2021 12:08:00 +, Alexander Lobakin
> > > wrote:
> > > > From: Alexander Lobakin
> > > > Date: Fri, 22 Jan 2021 11:55:35 +
> > > >
> > > > > From: Alexander Lobakin
> > > > > Date: Fri, 22 Jan 2021 11:47:45 +
> > > > >
> > > > > > From: Eric Dumazet
> > > > > > Date: Thu, 21 Jan 2021 16:41:33 +0100
> > > > > >
> > > > > > > On 1/21/21 2:47 PM, Xuan Zhuo wrote:
> > > > > > > > This patch is used to construct skb based on page to save
> > > > > > > > memory copy
> > > > > > > > overhead.
> > > > > > > >
> > > > > > > > This function is implemented based on IFF_TX_SKB_NO_LINEAR.
> > > > > > > > Only the
> > > > > > > > network card priv_flags supports IFF_TX_SKB_NO_LINEAR will use
> > > > > > > > page to
> > > > > > > > directly construct skb. If this feature is not supported, it is
> > > > > > > > still
> > > > > > > > necessary to copy data to construct skb.
> > > > > > > >
> > > > > > > > Performance Testing
> > > > > > > >
> > > > > > > > The test environment is Aliyun ECS server.
> > > > > > > > Test cmd:
> > > > > > > > ```
> > > > > > > > xdpsock -i eth0 -t -S -s
> > > > > > > > ```
> > > > > > > >
> > > > > > > > Test result data:
> > > > > > > >
> > > > > > > > size64 512 10241500
> > > > > > > > copy1916747 1775988 1600203 1440054
> > > > > > > > page1974058 1953655 1945463 1904478
> > > > > > > > percent 3.0%10.0% 21.58% 32.3%
> > > > > > > >
> > > > > > > > Signed-off-by: Xuan Zhuo
> > > > > > > > Reviewed-by: Dust Li
> > > > > > > > ---
> > > > > > > > net/xdp/xsk.c | 104
> > > > > > > > --
> > > > > > > > 1 file changed, 86 insertions(+), 18 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
> > > > > > > > index 4a83117..38af7f1 100644
> > > > > > > > --- a/net/xdp/xsk.c
> > > > > > > > +++ b/net/xdp/xsk.c
> > > > > > > > @@ -430,6 +430,87 @@ static void xsk_destruct_skb(struct
> > > > > > > > sk_buff *skb)
> > > > > > > > sock_wfree(skb);
> > > > > > > > }
> > > > > > > >
> > > > > > > > +static struct sk_buff *xsk_build_skb_zerocopy(struct xdp_sock
> > > > > > > > *xs,
> > > > > > > > + struct xdp_desc
> > > > > > > > *desc)
> > > > > > > > +{
> > > > > > > > + u32 len, offset, copy, copied;
> > > > > > > > + struct sk_buff *skb;
> > > > > > > > + struct page *page;
> > > > > > > > + void *buffer;
> > > > > > > > + int err, i;
> > > > > > > > + u64 addr;
> > > > > > > > +
> > > > > > > > + skb = sock_alloc_send_skb(&xs->sk, 0, 1, &err);
> > > >
> > > > Also,
> > > > maybe we should allocate it with NET_SKB_PAD so NIC drivers could
> > > > use some reserved space?
> > > >
> > > > skb = sock_alloc_send_skb(&xs->sk, NET_SKB_PAD, 1,
> > > > &err);
> > > > ...
> > > > skb_reserve(skb, NET_SKB_PAD);
> > > >
> > > > Eric, what do you think?
> > >
> > > I think you are right. Some space should be added to continuous
> > > equipment. This
> > > space should also be added in the copy mode below. Is LL_RESERVED_SPACE
> > > more
> > > appropriate?
> >
> > No. If you look at __netdev_alloc_skb() and __napi_alloc_skb(), they
> > reserve NET_SKB_PAD at the beginning of linear area. Documentation of
> > __build_skb() also says that driver should reserve NET_SKB_PAD before
> > the actual frame, so it is a standartized hardware-independent
> > headroom.
>
> I understand that these scenarios are in the case of receiving packets, and
> the
> increased space is used by the protocol stack, especially RPS. I don't know if
> this also applies to the sending scenario?
>
> > Leaving that space in skb->head will allow developers to implement
> > IFF_TX_SKB_NO_LINEAR in a wider variety of drivers, especially when
> > a driver has to prepend some sort of data before the actual frame.
> > Since it's usually of a size of one cacheline, shouldn't be a big
> > deal.
> >
>
> I agree with this. Some network cards require some space. For example,
> virtio-net needs to add a virtio_net_hdr_mrg_rxbuf before skb->data, so my
> original understanding is used here. When we send the skb to the
> driver, the driver may need a memory space. So I refer to the
> implementation of __ip_append_data, I feel that adding
> LL_RESERVED_SPACE is a suitable solution.
>
> I feel that I may still not understand the use scene you mentioned. Can you
> elaborate on what you understand this space will be used for?
LL_RESERVED_SPACE() consists of L2 header size (Ethernet for the most
cases) and dev->needed_headroom. That is not a value to count on, as:
- L2 header is already here in XSK buffer;
- not all drivers set
Re: [RFC PATCH] kvm: arm64: Try stage2 block mapping for host device MMIO
I forget to give the link of the bugfix I mentioned below :-).
[1] https://lkml.org/lkml/2020/5/1/1294
On 2021/1/25 19:25, Keqian Zhu wrote:
> Hi Marc,
>
> On 2021/1/22 17:45, Marc Zyngier wrote:
>> On 2021-01-22 08:36, Keqian Zhu wrote:
>>> The MMIO region of a device maybe huge (GB level), try to use block
>>> mapping in stage2 to speedup both map and unmap.
>>>
>>> Especially for unmap, it performs TLBI right after each invalidation
>>> of PTE. If all mapping is of PAGE_SIZE, it takes much time to handle
>>> GB level range.
>>
>> This is only on VM teardown, right? Or do you unmap the device more ofet?
>> Can you please quantify the speedup and the conditions this occurs in?
>
> Yes, and there are some other paths (includes what your patch series handles)
> will do the unmap action:
>
> 1、guest reboot without S2FWB: stage2_unmap_vm（）which only unmaps guest
> regular RAM.
> 2、userspace deletes memslot: kvm_arch_flush_shadow_memslot().
> 3、rollback of device MMIO mapping: kvm_arch_prepare_memory_region().
> 4、rollback of dirty log tracking: If we enable hugepage for guest RAM, after
> dirty log is stopped,
>the newly created block mappings will
> unmap all page mappings.
> 5、mmu notifier: kvm_unmap_hva_range(). AFAICS, we will use this path when VM
> teardown or guest resets pass-through devices.
> The bugfix[1] gives the reason for
> unmapping MMIO region when guest resets pass-through devices.
>
> unmap related to MMIO region, as this patch solves:
> point 1 is not applied.
> point 2 occurs when userspace unplug pass-through devices.
> point 3 can occurs, but rarely.
> point 4 is not applied.
> point 5 occurs when VM teardown or guest resets pass-through devices.
>
> And I had a look at your patch series, it can solve:
> For VM teardown, elide CMO and perform VMALL instead of individually (But
> current kernel do not go through this path when VM teardown).
> For rollback of dirty log tracking, elide CMO.
> For kvm_unmap_hva_range, if event is MMU_NOTIFY_UNMAP. elide CMO.
>
> (But I doubt the CMOs in unmap. As we perform CMOs in user_mem_abort when
> install new stage2 mapping for VM,
> maybe the CMO in unmap is unnecessary under all conditions :-) ?)
>
> So it shows that we are solving different parts of unmap, so they are not
> conflicting. At least this patch can
> still speedup map of device MMIO region, and speedup unmap of device MMIO
> region even if we do not need to perform
> CMO and TLBI ;-).
>
> speedup: unmap 8GB MMIO on FPGA.
>
>beforeafter opt
> cost30+ minutes949ms
>
> Thanks,
> Keqian
>
>>
>> I have the feeling that we are just circling around another problem,
>> which is that we could rely on a VM-wide TLBI when tearing down the
>> guest. I worked on something like that[1] a long while ago, and parked
>> it for some reason. Maybe it is worth reviving.
>>
>> [1]
>> https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=kvm-arm64/elide-cmo-tlbi
>>
>>>
>>> Signed-off-by: Keqian Zhu
>>> ---
>>> arch/arm64/include/asm/kvm_pgtable.h | 11 +++
>>> arch/arm64/kvm/hyp/pgtable.c | 15 +++
>>> arch/arm64/kvm/mmu.c | 12
>>> 3 files changed, 34 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/arm64/include/asm/kvm_pgtable.h
>>> b/arch/arm64/include/asm/kvm_pgtable.h
>>> index 52ab38db04c7..2266ac45f10c 100644
>>> --- a/arch/arm64/include/asm/kvm_pgtable.h
>>> +++ b/arch/arm64/include/asm/kvm_pgtable.h
>>> @@ -82,6 +82,17 @@ struct kvm_pgtable_walker {
>>> const enum kvm_pgtable_walk_flagsflags;
>>> };
>>>
>>> +/**
>>> + * kvm_supported_pgsize() - Get the max supported page size of a mapping.
>>> + * @pgt:Initialised page-table structure.
>>> + * @addr:Virtual address at which to place the mapping.
>>> + * @end:End virtual address of the mapping.
>>> + * @phys:Physical address of the memory to map.
>>> + *
>>> + * The smallest return value is PAGE_SIZE.
>>> + */
>>> +u64 kvm_supported_pgsize(struct kvm_pgtable *pgt, u64 addr, u64 end, u64
>>> phys);
>>> +
>>> /**
>>> * kvm_pgtable_hyp_init() - Initialise a hypervisor stage-1 page-table.
>>> * @pgt:Uninitialised page-table structure to initialise.
>>> diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
>>> index bdf8e55ed308..ab11609b9b13 100644
>>> --- a/arch/arm64/kvm/hyp/pgtable.c
>>> +++ b/arch/arm64/kvm/hyp/pgtable.c
>>> @@ -81,6 +81,21 @@ static bool kvm_block_mapping_supported(u64 addr,
>>> u64 end, u64 phys, u32 level)
>>> return IS_ALIGNED(addr, granule) && IS_ALIGNED(phys, granule);
>>> }
>>>
>>> +u64 kvm_supported_pgsize(struct kvm_pgtable *pgt, u64 addr, u64 end, u64
>>> phys)
>>> +{
>>> +u32 lvl;
>>> +u64 pgsize = PAGE_SIZE;
>>> +
>>> +for (lvl = pgt->start_level; lvl < KVM_PGTABLE_MAX_LEVELS; lvl++) {
>>> +if (kvm_block_mapping_su
Re: [PATCH] x86/kgdb: Allow removal of early BPs
Hi,
I wanted to ask about the status of the patch. Let us know if there are any
other steps we can undertake.
Kind regards
Lorena
On Fri 2020-12-18 16:44:21, Daniel Thompson wrote:
> Hi Stefan
>
> On Mon, Dec 14, 2020 at 03:13:12PM +0100, Stefan Saecherl wrote:
> > The problem is that breakpoints that are set early (e.g. via kgdbwait)
> > cannot be deleted after boot completed (to be precise after mark_rodata_ro
> > ran).
> >
> > When setting a breakpoint early there are executable pages that are
> > writable so the copy_to_kernel_nofault call in kgdb_arch_set_breakpoint
> > succeeds and the breakpoint is saved as type BP_BREAKPOINT.
> >
> > Later in the boot write access to these pages is restricted. So when
> > removing the breakpoint the copy_to_kernel_nofault call in
> > kgdb_arch_remove_breakpoint is destined to fail and the breakpoint removal
> > fails. So after copy_to_kernel_nofault failed try to text_poke_kgdb which
> > can work around nonwriteability.
> >
> > One thing to consider when doing this is that code can go away during boot
> > (e.g. .init.text). Previously kgdb_arch_remove_breakpoint handled this case
> > gracefully by just having copy_to_kernel_nofault fail but if one then calls
> > text_poke_kgdb the system dies due to the BUG_ON we moved out of
> > __text_poke. To avoid this __text_poke now returns an error in case of a
> > nonpresent code page and the error is handled at call site.
> >
> > Checkpatch complains about two uses of BUG_ON but the new code should not
> > trigger BUG_ON in cases where the old didn't.
> >
> > Co-developed-by: Lorena Kretzschmar
> > Signed-off-by: Lorena Kretzschmar
> > Signed-off-by: Stefan Saecherl
>
> I took this to be a gap in the kgdbtest suite so I added a couple of
> tests that cover this area. Before this patch they failed now they
> pass (at least they do for ARCH=x86).
>
> I don't see any new failures either, so:
>
> Tested-by: Daniel Thompson
>
>
> Daniel.
>
>
>
> > ---
> > arch/x86/kernel/alternative.c | 16 +++
> > arch/x86/kernel/kgdb.c| 54 ---
> > 2 files changed, 48 insertions(+), 22 deletions(-)
> >
> > diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
> > index 2400ad62f330..0f145d837885 100644
> > --- a/arch/x86/kernel/alternative.c
> > +++ b/arch/x86/kernel/alternative.c
> > @@ -878,11 +878,9 @@ static void *__text_poke(void *addr, const void
> > *opcode, size_t len)
> > if (cross_page_boundary)
> > pages[1] = virt_to_page(addr + PAGE_SIZE);
> > }
> > - /*
> > -* If something went wrong, crash and burn since recovery paths are not
> > -* implemented.
> > -*/
> > - BUG_ON(!pages[0] || (cross_page_boundary && !pages[1]));
> > +
> > + if (!pages[0] || (cross_page_boundary && !pages[1]))
> > + return ERR_PTR(-EFAULT);
> >
> > /*
> > * Map the page without the global bit, as TLB flushing is done with
> > @@ -976,7 +974,13 @@ void *text_poke(void *addr, const void *opcode, size_t
> > len)
> > {
> > lockdep_assert_held(&text_mutex);
> >
> > - return __text_poke(addr, opcode, len);
> > + addr = __text_poke(addr, opcode, len);
> > + /*
> > +* If something went wrong, crash and burn since recovery paths are not
> > +* implemented.
> > +*/
> > + BUG_ON(IS_ERR(addr));
> > + return addr;
> > }
> >
> > /**
> > diff --git a/arch/x86/kernel/kgdb.c b/arch/x86/kernel/kgdb.c
> > index ff7878df96b4..e98c9c43db7c 100644
> > --- a/arch/x86/kernel/kgdb.c
> > +++ b/arch/x86/kernel/kgdb.c
> > @@ -731,6 +731,7 @@ void kgdb_arch_set_pc(struct pt_regs *regs, unsigned
> > long ip)
> > int kgdb_arch_set_breakpoint(struct kgdb_bkpt *bpt)
> > {
> > int err;
> > + void *addr;
> >
> > bpt->type = BP_BREAKPOINT;
> > err = copy_from_kernel_nofault(bpt->saved_instr, (char *)bpt->bpt_addr,
> > @@ -747,8 +748,14 @@ int kgdb_arch_set_breakpoint(struct kgdb_bkpt *bpt)
> > */
> > if (mutex_is_locked(&text_mutex))
> > return -EBUSY;
> > - text_poke_kgdb((void *)bpt->bpt_addr, arch_kgdb_ops.gdb_bpt_instr,
> > - BREAK_INSTR_SIZE);
> > +
> > + addr = text_poke_kgdb((void *)bpt->bpt_addr,
> > arch_kgdb_ops.gdb_bpt_instr,
> > + BREAK_INSTR_SIZE);
> > + /* This should never trigger because the above call to
> > copy_from_kernel_nofault
> > +* already succeeded.
> > +*/
> > + BUG_ON(IS_ERR(addr));
> > +
> > bpt->type = BP_POKE_BREAKPOINT;
> >
> > return 0;
> > @@ -756,21 +763,36 @@ int kgdb_arch_set_breakpoint(struct kgdb_bkpt *bpt)
> >
> > int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
> > {
> > - if (bpt->type != BP_POKE_BREAKPOINT)
> > - goto knl_write;
> > - /*
> > -* It is safe to call text_poke_kgdb() because normal kernel execution
> > -* is stopped on all cores, so long as the text_mutex is not locked.
> > -*/
> > - if (mutex_
Re: [RFC PATCH v3 03/13] af_vsock: implement SEQPACKET rx loop
25.01.2021 14:12, Arseny Krasnov пишет: This adds receive loop for SEQPACKET. It looks like receive loop for SEQPACKET, ^^^ You meant "STREAM"?
[PATCH] optee: simplify i2c access
From: Arnd Bergmann
Storing a bogus i2c_client structure on the stack adds overhead and
causes a compile-time warning:
drivers/tee/optee/rpc.c:493:6: error: stack frame size of 1056 bytes in
function 'optee_handle_rpc' [-Werror,-Wframe-larger-than=]
void optee_handle_rpc(struct tee_context *ctx, struct optee_rpc_param *param,
Change the implementation of handle_rpc_func_cmd_i2c_transfer() to
open-code the i2c_transfer() call, which makes it easier to read
and avoids the warning.
Fixes: c05210ab9757 ("drivers: optee: allow op-tee to access devices on the i2c
bus")
Signed-off-by: Arnd Bergmann
---
drivers/tee/optee/rpc.c | 31 ---
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/tee/optee/rpc.c b/drivers/tee/optee/rpc.c
index 1e3614e4798f..6cbb3643c6c4 100644
--- a/drivers/tee/optee/rpc.c
+++ b/drivers/tee/optee/rpc.c
@@ -54,8 +54,9 @@ static void handle_rpc_func_cmd_get_time(struct optee_msg_arg
*arg)
static void handle_rpc_func_cmd_i2c_transfer(struct tee_context *ctx,
struct optee_msg_arg *arg)
{
- struct i2c_client client = { 0 };
struct tee_param *params;
+ struct i2c_adapter *adapter;
+ struct i2c_msg msg = { };
size_t i;
int ret = -EOPNOTSUPP;
u8 attr[] = {
@@ -85,48 +86,48 @@ static void handle_rpc_func_cmd_i2c_transfer(struct
tee_context *ctx,
goto bad;
}
- client.adapter = i2c_get_adapter(params[0].u.value.b);
- if (!client.adapter)
+ adapter = i2c_get_adapter(params[0].u.value.b);
+ if (!adapter)
goto bad;
if (params[1].u.value.a & OPTEE_MSG_RPC_CMD_I2C_FLAGS_TEN_BIT) {
- if (!i2c_check_functionality(client.adapter,
+ if (!i2c_check_functionality(adapter,
I2C_FUNC_10BIT_ADDR)) {
- i2c_put_adapter(client.adapter);
+ i2c_put_adapter(adapter);
goto bad;
}
- client.flags = I2C_CLIENT_TEN;
+ msg.flags = I2C_M_TEN;
}
- client.addr = params[0].u.value.c;
- snprintf(client.name, I2C_NAME_SIZE, "i2c%d", client.adapter->nr);
+ msg.addr = params[0].u.value.c;
+ msg.buf = params[2].u.memref.shm->kaddr;
+ msg.len = params[2].u.memref.size;
switch (params[0].u.value.a) {
case OPTEE_MSG_RPC_CMD_I2C_TRANSFER_RD:
- ret = i2c_master_recv(&client, params[2].u.memref.shm->kaddr,
- params[2].u.memref.size);
+ msg.flags |= I2C_M_RD;
break;
case OPTEE_MSG_RPC_CMD_I2C_TRANSFER_WR:
- ret = i2c_master_send(&client, params[2].u.memref.shm->kaddr,
- params[2].u.memref.size);
break;
default:
- i2c_put_adapter(client.adapter);
+ i2c_put_adapter(adapter);
goto bad;
}
+ ret = i2c_transfer(adapter, &msg, 1);
+
if (ret < 0) {
arg->ret = TEEC_ERROR_COMMUNICATION;
} else {
- params[3].u.value.a = ret;
+ params[3].u.value.a = msg.len;
if (optee_to_msg_param(arg->params, arg->num_params, params))
arg->ret = TEEC_ERROR_BAD_PARAMETERS;
else
arg->ret = TEEC_SUCCESS;
}
- i2c_put_adapter(client.adapter);
+ i2c_put_adapter(adapter);
kfree(params);
return;
bad:
--
2.29.2
Re: [PATCH v2] sched/fair: check for idle core
On Mon, 25 Jan 2021, Vincent Guittot wrote:
> On Mon, 25 Jan 2021 at 10:20, Julia Lawall wrote:
> >
> >
> >
> > On Mon, 25 Jan 2021, Mel Gorman wrote:
> >
> > > On Sun, Jan 24, 2021 at 09:38:14PM +0100, Julia Lawall wrote:
> > > >
> > > >
> > > > On Tue, 27 Oct 2020, Mel Gorman wrote:
> > > >
> > > > > On Thu, Oct 22, 2020 at 03:15:50PM +0200, Julia Lawall wrote:
> > > > > > Fixes: 11f10e5420f6 ("sched/fair: Use load instead of runnable load
> > > > > > in wakeup path")
> > > > > > Signed-off-by: Julia Lawall
> > > > > > Reviewed-by Vincent Guittot
> > > > > >
> > > > >
> > > > > While not a universal win, it was mostly a win or neutral. In few
> > > > > cases
> > > > > where there was a problem, one benchmark I'm a bit suspicious of
> > > > > generally
> > > > > as occasionally it generates bad results for unknown and unpredictable
> > > > > reasons. In another, it was very machine specific and the differences
> > > > > were small in absolte time rather than relative time. Other tests on
> > > > > the
> > > > > same machine were fine so overall;
> > > > >
> > > > > Acked-by: Mel Gorman
> > > >
> > > > Recently, we have been testing the phoronix multicore benchmarks. On
> > > > v5.9
> > > > with this patch, the preparation time of phoronix slows down, from ~23
> > > > seconds to ~28 seconds. In v5.11-rc4, we see 29 seconds. It's not yet
> > > > clear what causes the problem. But perhaps the patch should be removed
> > > > from v5.11, until the problem is understood.
> > > >
> > > > commit d8fcb81f1acf651a0e50eacecca43d0524984f87
> > > >
> > >
> > > I'm not 100% convinved given that it was a mix of wins and losses. In
> > > the wakup path in general, universal wins almost never happen. It's not
> > > 100% clear from your mail what happens during the preparation patch. If
> > > it included time to download the benchmarks and install then it would be
> > > inherently variable due to network time (if download) or cache hotness
> > > (if installing/compiling). While preparation time can be interesting --
> > > for example, if preparation involves reading a lot of files from disk,
> > > it's not universally interesting when it's not the critical phase of a
> > > benchmark.
> >
> > The benchmark is completely downloaded prior to the runs. There seems to
> > be some perturbation to the activation of containerd. Normally it is
> > even: * * * *
>
> Does it impact the benchmark results too or only the preparation prior
> to running the benchmark ?
Looking at a few of the benchmarks, there is no clear pattern which is
better. But there is not a big degradation, like from 23 to 28 seconds
for the preparation time. I will report back when we figure out more.
julia
>
> >
> > and with the patch it becomes more like: * ** **
> >
> > That is every other one is on time, and every other one is late.
> >
> > But I don't know why this happens.
> >
> > julia
> >
> > >
> > > I think it would be better to wait until the problem is fully understood
> > > to see if it's a timing artifact (e.g. a race between when prev_cpu is
> > > observed to be idle and when it is busy).
>
> I agree that a better understanding of what is happening is necessary
> before any changes
>
> > >
> > > --
> > > Mel Gorman
> > > SUSE Labs
> > >
>
Re: [PATCH 2/5] mm,memory_hotplug: Allocate memmap from the added memory range
On 25.01.21 12:18, Oscar Salvador wrote: > On Mon, Jan 25, 2021 at 11:57:20AM +0100, David Hildenbrand wrote: >> I'm confused. >> >> 1. Assume we hotplug memory, online it to ZONE_MOVABLE. The vmemmap gets >> allocated from altmap space. > > The vmemmap could have never been allocated from altmap in case hpage vmemmap > feature is enabled. > > Have a look at [1]. > If is_hugetlb_free_vmemmap_enabled(), vmemmap_populate() ends up calling > vmemmap_populate_basepages(). Oh, it calls "vmemmap_populate_basepages(start, end, node, NULL);" the "NULL" part is the important bit. > > And since no memory was consumed from altmap, and hence > altmap_alloc_block_buf() > was never called, vmem_altmap->alloc will be 0, and > memory_block->nr_vmemmap_pages > will be 0 as well. > > But on a second though, true is that we will get in trouble if hpage vmemmap > feature ever gets to work with vmemmap_populate_hugepages. > I will queue that to look in a new future. This seriously needs comments and documentation. The problem is where to document as long as one of both series is not merged yet :) At least in the cover letter, because this is not obvious how both things will play along. Thanks! -- Thanks, David / dhildenb
[RFC PATCH v3 13/13] vsock_test: add SOCK_SEQPACKET tests
This adds two tests of SOCK_SEQPACKET socket: both transfer data and then
test MSG_EOR and MSG_TRUNC flags. Cases for connect(), bind(), etc. are
not tested, because it is same as for stream socket.
Signed-off-by: Arseny Krasnov
---
tools/testing/vsock/util.c | 32 ++--
tools/testing/vsock/util.h | 3 +
tools/testing/vsock/vsock_test.c | 126 +++
3 files changed, 156 insertions(+), 5 deletions(-)
diff --git a/tools/testing/vsock/util.c b/tools/testing/vsock/util.c
index 93cbd6f603f9..2acbb7703c6a 100644
--- a/tools/testing/vsock/util.c
+++ b/tools/testing/vsock/util.c
@@ -84,7 +84,7 @@ void vsock_wait_remote_close(int fd)
}
/* Connect to and return the file descriptor. */
-int vsock_stream_connect(unsigned int cid, unsigned int port)
+static int vsock_connect(unsigned int cid, unsigned int port, int type)
{
union {
struct sockaddr sa;
@@ -101,7 +101,7 @@ int vsock_stream_connect(unsigned int cid, unsigned int
port)
control_expectln("LISTENING");
- fd = socket(AF_VSOCK, SOCK_STREAM, 0);
+ fd = socket(AF_VSOCK, type, 0);
timeout_begin(TIMEOUT);
do {
@@ -120,11 +120,21 @@ int vsock_stream_connect(unsigned int cid, unsigned int
port)
return fd;
}
+int vsock_stream_connect(unsigned int cid, unsigned int port)
+{
+ return vsock_connect(cid, port, SOCK_STREAM);
+}
+
+int vsock_seqpacket_connect(unsigned int cid, unsigned int port)
+{
+ return vsock_connect(cid, port, SOCK_SEQPACKET);
+}
+
/* Listen on and return the first incoming connection. The remote
* address is stored to clientaddrp. clientaddrp may be NULL.
*/
-int vsock_stream_accept(unsigned int cid, unsigned int port,
- struct sockaddr_vm *clientaddrp)
+static int vsock_accept(unsigned int cid, unsigned int port,
+ struct sockaddr_vm *clientaddrp, int type)
{
union {
struct sockaddr sa;
@@ -145,7 +155,7 @@ int vsock_stream_accept(unsigned int cid, unsigned int port,
int client_fd;
int old_errno;
- fd = socket(AF_VSOCK, SOCK_STREAM, 0);
+ fd = socket(AF_VSOCK, type, 0);
if (bind(fd, &addr.sa, sizeof(addr.svm)) < 0) {
perror("bind");
@@ -189,6 +199,18 @@ int vsock_stream_accept(unsigned int cid, unsigned int
port,
return client_fd;
}
+int vsock_stream_accept(unsigned int cid, unsigned int port,
+ struct sockaddr_vm *clientaddrp)
+{
+ return vsock_accept(cid, port, clientaddrp, SOCK_STREAM);
+}
+
+int vsock_seqpacket_accept(unsigned int cid, unsigned int port,
+ struct sockaddr_vm *clientaddrp)
+{
+ return vsock_accept(cid, port, clientaddrp, SOCK_SEQPACKET);
+}
+
/* Transmit one byte and check the return value.
*
* expected_ret:
diff --git a/tools/testing/vsock/util.h b/tools/testing/vsock/util.h
index e53dd09d26d9..a3375ad2fb7f 100644
--- a/tools/testing/vsock/util.h
+++ b/tools/testing/vsock/util.h
@@ -36,8 +36,11 @@ struct test_case {
void init_signals(void);
unsigned int parse_cid(const char *str);
int vsock_stream_connect(unsigned int cid, unsigned int port);
+int vsock_seqpacket_connect(unsigned int cid, unsigned int port);
int vsock_stream_accept(unsigned int cid, unsigned int port,
struct sockaddr_vm *clientaddrp);
+int vsock_seqpacket_accept(unsigned int cid, unsigned int port,
+ struct sockaddr_vm *clientaddrp);
void vsock_wait_remote_close(int fd);
void send_byte(int fd, int expected_ret, int flags);
void recv_byte(int fd, int expected_ret, int flags);
diff --git a/tools/testing/vsock/vsock_test.c b/tools/testing/vsock/vsock_test.c
index 5a4fb80fa832..db6cc49fa5e4 100644
--- a/tools/testing/vsock/vsock_test.c
+++ b/tools/testing/vsock/vsock_test.c
@@ -14,6 +14,8 @@
#include
#include
#include
+#include
+#include
#include "timeout.h"
#include "control.h"
@@ -279,6 +281,120 @@ static void test_stream_msg_peek_server(const struct
test_opts *opts)
close(fd);
}
+#define MESSAGES_CNT 7
+#define MESSAGE_EOR_IDX (MESSAGES_CNT / 2)
+static void test_seqpacket_msg_send_client(const struct test_opts *opts)
+{
+ int fd;
+
+ fd = vsock_seqpacket_connect(opts->peer_cid, 1234);
+ if (fd < 0) {
+ perror("connect");
+ exit(EXIT_FAILURE);
+ }
+
+ /* Send several messages, one with MSG_EOR flag */
+ for (int i = 0; i < MESSAGES_CNT; i++)
+ send_byte(fd, 1, (i != MESSAGE_EOR_IDX) ? 0 : MSG_EOR);
+
+ control_writeln("SENDDONE");
+ close(fd);
+}
+
+static void test_seqpacket_msg_send_server(const struct test_opts *opts)
+{
+ int fd;
+ char buf[16];
+ struct msghdr msg = {0};
+ struct iovec iov = {0};
+
+ fd = vsock_seqpacket_accept(VMADDR_CID_ANY, 1234, NULL);
+ if (fd < 0) {
+ perror("accept");
+
Re: [PATCH 1/2] ecryptfs: fix uid translation for setxattr on security.capability
On Mon, Jan 25, 2021 at 2:25 PM Miklos Szeredi wrote:
>
> On Fri, Jan 22, 2021 at 7:31 PM Tyler Hicks wrote:
> >
> > On 2021-01-19 17:22:03, Miklos Szeredi wrote:
> > > Prior to commit 7c03e2cda4a5 ("vfs: move cap_convert_nscap() call into
> > > vfs_setxattr()") the translation of nscap->rootid did not take stacked
> > > filesystems (overlayfs and ecryptfs) into account.
> > >
> > > That patch fixed the overlay case, but made the ecryptfs case worse.
> >
> > Thanks for sending a fix!
> >
> > I know that you don't have an eCryptfs setup to test with but I'm at a
> > loss about how to test this from the userns/fscaps side of things. Do
> > you have a sequence of unshare/setcap/getcap commands that I can run on
> > a file inside of an eCryptfs mount to verify that the bug exists after
> > 7c03e2cda4a5 and then again to verify that this patch fixes the bug?
>
> You need two terminals:
> $ =
> # = root
>
> $ unshare -Um
> $ echo $$
>
> # echo "0 1000 1" > uid_map
NOTE: is assumed to have uid=1000, so this and following
"1000" values need to be fixed up if it's not the case.
Thanks,
Miklos
[PATCH] drm/i915/gvt: fix uninitialized return in intel_gvt_update_reg_whitelist()
Smatch found an uninitialized variable bug in this code:
drivers/gpu/drm/i915/gvt/cmd_parser.c:3191 intel_gvt_update_reg_whitelist()
error: uninitialized symbol 'ret'.
The first thing that Smatch complains about is that "ret" isn't set if
we don't enter the "for_each_engine(engine, &dev_priv->gt, id) {" loop.
Presumably we always have at least one engine so that's a false
positive.
But it's definitely a bug to not set "ret" if i915_gem_object_pin_map()
fails.
Let's fix the bug and silence the false positive.
Fixes: 493f30cd086e ("drm/i915/gvt: parse init context to update cmd accessible
reg whitelist")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/i915/gvt/cmd_parser.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c
b/drivers/gpu/drm/i915/gvt/cmd_parser.c
index 7fb91de06557..d54ea0e4681d 100644
--- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
+++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
@@ -3103,7 +3103,7 @@ void intel_gvt_update_reg_whitelist(struct intel_vgpu
*vgpu)
struct intel_vgpu_submission *s = &vgpu->submission;
struct i915_request *requests[I915_NUM_ENGINES] = {};
bool is_ctx_pinned[I915_NUM_ENGINES] = {};
- int ret;
+ int ret = 0;
if (gvt->is_reg_whitelist_updated)
return;
@@ -3157,6 +3157,7 @@ void intel_gvt_update_reg_whitelist(struct intel_vgpu
*vgpu)
if (IS_ERR(vaddr)) {
gvt_err("failed to pin init ctx obj, ring=%d,
err=%lx\n",
id, PTR_ERR(vaddr));
+ ret = PTR_ERR(vaddr);
goto out;
}
--
2.29.2
[PATCH 2/7] USB: serial: cp210x: fix modem-control handling
The vendor request used to set the flow-control settings also sets the
state of the modem-control lines.
Add state variables to keep track of the modem-control lines to avoid
always asserting the lines whenever the flow-control settings are
updated.
This specifically also avoids asserting DTR/RTS when opening a port with
the line speed set to B0.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/cp210x.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index 7e4a09b42c99..9378b4bba34b 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -269,6 +269,8 @@ struct cp210x_port_private {
struct mutexmutex;
boolcrtscts;
+ booldtr;
+ boolrts;
};
static struct usb_serial_driver cp210x_device = {
@@ -1162,7 +1164,10 @@ static void cp210x_set_flow_control(struct tty_struct
*tty,
ctl_hs &= ~CP210X_SERIAL_DCD_HANDSHAKE;
ctl_hs &= ~CP210X_SERIAL_DSR_SENSITIVITY;
ctl_hs &= ~CP210X_SERIAL_DTR_MASK;
- ctl_hs |= CP210X_SERIAL_DTR_SHIFT(CP210X_SERIAL_DTR_ACTIVE);
+ if (port_priv->dtr)
+ ctl_hs |= CP210X_SERIAL_DTR_SHIFT(CP210X_SERIAL_DTR_ACTIVE);
+ else
+ ctl_hs |= CP210X_SERIAL_DTR_SHIFT(CP210X_SERIAL_DTR_INACTIVE);
if (C_CRTSCTS(tty)) {
ctl_hs |= CP210X_SERIAL_CTS_HANDSHAKE;
@@ -1172,7 +1177,10 @@ static void cp210x_set_flow_control(struct tty_struct
*tty,
} else {
ctl_hs &= ~CP210X_SERIAL_CTS_HANDSHAKE;
flow_repl &= ~CP210X_SERIAL_RTS_MASK;
- flow_repl |= CP210X_SERIAL_RTS_SHIFT(CP210X_SERIAL_RTS_ACTIVE);
+ if (port_priv->rts)
+ flow_repl |=
CP210X_SERIAL_RTS_SHIFT(CP210X_SERIAL_RTS_ACTIVE);
+ else
+ flow_repl |=
CP210X_SERIAL_RTS_SHIFT(CP210X_SERIAL_RTS_INACTIVE);
port_priv->crtscts = false;
}
@@ -1287,25 +1295,29 @@ static int cp210x_tiocmset_port(struct usb_serial_port
*port,
u16 control = 0;
int ret;
+ mutex_lock(&port_priv->mutex);
+
if (set & TIOCM_RTS) {
+ port_priv->rts = true;
control |= CONTROL_RTS;
control |= CONTROL_WRITE_RTS;
}
if (set & TIOCM_DTR) {
+ port_priv->dtr = true;
control |= CONTROL_DTR;
control |= CONTROL_WRITE_DTR;
}
if (clear & TIOCM_RTS) {
+ port_priv->rts = false;
control &= ~CONTROL_RTS;
control |= CONTROL_WRITE_RTS;
}
if (clear & TIOCM_DTR) {
+ port_priv->dtr = false;
control &= ~CONTROL_DTR;
control |= CONTROL_WRITE_DTR;
}
- mutex_lock(&port_priv->mutex);
-
/*
* SET_MHS cannot be used to control RTS when auto-RTS is enabled.
* Note that RTS is still deasserted when disabling the UART on close.
--
2.26.2
[PATCH 5/7] USB: serial: cp210x: clean up printk zero padding
Use the 0-flag and a field width to specify zero-padding consistently in printk messages. Signed-off-by: Johan Hovold --- drivers/usb/serial/cp210x.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c index 36ae44818c13..4ba3fb096bf1 100644 --- a/drivers/usb/serial/cp210x.c +++ b/drivers/usb/serial/cp210x.c @@ -1319,7 +1319,7 @@ static int cp210x_tiocmset_port(struct usb_serial_port *port, if (port_priv->crtscts) control &= ~CONTROL_WRITE_RTS; - dev_dbg(&port->dev, "%s - control = 0x%.4x\n", __func__, control); + dev_dbg(&port->dev, "%s - control = 0x%04x\n", __func__, control); ret = cp210x_write_u16_reg(port, CP210X_SET_MHS, control); @@ -1353,7 +1353,7 @@ static int cp210x_tiocmget(struct tty_struct *tty) |((control & CONTROL_RING)? TIOCM_RI : 0) |((control & CONTROL_DCD) ? TIOCM_CD : 0); - dev_dbg(&port->dev, "%s - control = 0x%.2x\n", __func__, control); + dev_dbg(&port->dev, "%s - control = 0x%02x\n", __func__, control); return result; } -- 2.26.2
Re: 回复: 回复: [PATCH 3/3] kvfree_rcu: use migrate_disable/enable()
>
>
> 发件人: Uladzislau Rezki
> 发送时间: 2021年1月25日 5:57
> 收件人: Zhang, Qiang
> 抄送: Uladzislau Rezki (Sony); LKML; RCU; Paul E . McKenney; Michael Ellerman;
> Andrew Morton; Daniel Axtens; Frederic Weisbecker; Neeraj Upadhyay; Joel
> Fernandes; Peter Zijlstra; Michal Hocko; Thomas Gleixner; Theodore Y . Ts'o;
> Sebastian Andrzej Siewior; Oleksiy Avramchenko
> 主题: Re: 回复: [PATCH 3/3] kvfree_rcu: use migrate_disable/enable()
>
> >Hello, Zhang.
>
> > >
> > >发件人: Uladzislau Rezki (Sony)
> > >发送时间: 2021年1月21日 0:21
> > >收件人: LKML; RCU; Paul E . McKenney; Michael Ellerman
> > >抄送: Andrew Morton; Daniel Axtens; Frederic Weisbecker; Neeraj >Upadhyay;
> > >Joel Fernandes; Peter Zijlstra; Michal Hocko; Thomas >Gleixner; Theodore Y
> > >. Ts'o; Sebastian Andrzej Siewior; Uladzislau >Rezki; Oleksiy Avramchenko
> > >主题: [PATCH 3/3] kvfree_rcu: use migrate_disable/enable()
> > >
> > >Since the page is obtained in a fully preemptible context, dropping
> > >the lock can lead to migration onto another CPU. As a result a prev.
> > >bnode of that CPU may be underutilised, because a decision has been
> > >made for a CPU that was run out of free slots to store a pointer.
> > >
> > >migrate_disable/enable() are now independent of RT, use it in order
> > >to prevent any migration during a page request for a specific CPU it
> > >is requested for.
> >
> >
> > Hello Rezki
> >
> > The critical migrate_disable/enable() area is not allowed to block, under
> > RT and non RT.
> > There is such a description in preempt.h
> >
> >
> > * Notes on the implementation.
> > *
> > * The implementation is particularly tricky since existing code patterns
> > * dictate neither migrate_disable() nor migrate_enable() is allowed to
> > block.
> > * This means that it cannot use cpus_read_lock() to serialize against
> > hotplug,
> > * nor can it easily migrate itself into a pending affinity mask change on
> > * migrate_enable().
> >
> >How i interpret it is migrate_enable()/migrate_disable() are not allowed to
> >use any blocking primitives, such as rwsem/mutexes/etc. in order to mark a
> >current context as non-migratable.
> >
> >void migrate_disable(void)
> >{
> > struct task_struct *p = current;
> >
> > if (p->migration_disabled) {
> > p->migration_disabled++;
> > return;
> > }
>
> > preempt_disable();
> > this_rq()->nr_pinned++;
> > p->migration_disabled = 1;
> > preempt_enable();
> >}
> >
> >It does nothing that prevents you from doing schedule() or even wait for any
> >event(mutex slow path behaviour), when the process is removed from the
> >run-queue.
> >I mean after the migrate_disable() is invoked. Or i miss something?
>
> Hello Rezki
>
> Sorry, there's something wrong with the previous description.
> There are the following scenarios
>
> Due to migrate_disable will increase this_rq()->nr_pinned , after that
> if get_free_page be blocked, and this time, CPU going offline,
> the sched_cpu_wait_empty() be called in per-cpu "cpuhp/%d" task,
> and be blocked.
>
But after the migrate_disable() is invoked a CPU can not be brought down.
If there are pinned tasks a "hotplug path" will be blocked on
balance_hotplug_wait()
call.
> blocked:
> sched_cpu_wait_empty()
> {
> struct rq *rq = this_rq();
>rcuwait_wait_event(&rq->hotplug_wait,
>rq->nr_running == 1 && !rq_has_pinned_tasks(rq),
>TASK_UNINTERRUPTIBLE);
> }
>
Exactly.
> wakeup:
> balance_push()
> {
> if (is_per_cpu_kthread(push_task) ||
> is_migration_disabled(push_task)) {
>
> if (!rq->nr_running && !rq_has_pinned_tasks(rq) &&
> rcuwait_active(&rq->hotplug_wait)) {
> raw_spin_unlock(&rq->lock);
> rcuwait_wake_up(&rq->hotplug_wait);
> raw_spin_lock(&rq->lock);
> }
> return;
> }
> }
>
> One of the conditions for this function to wake up is "rq->nr_pinned == 0"
> that is to say between migrate_disable/enable, if blocked will defect CPU
> going
> offline longer blocking time.
>
Indeed, the hotplug time is affected. For example in case of waiting for
a mutex to be released, an owner will wakeup waiters. But this is expectable.
>
> I'm not sure that's a problem，and I didn't find it in the kernel code
> between
> migrate_disable/enable possible sleep calls.
>
For example z3fold.c:
/* Add to the appropriate unbuddied list */
static inline void add_to_unbuddied(struct z3fold_pool *pool,
struct z3fold_header *zhdr)
{
if (zhdr->first_chunks == 0 || zhdr->last_chunks == 0 ||
zhdr->middle_chunks == 0) {
struct list_head *unbuddied;
int freechunks = num_free_chunks(zhdr);
migrate_disable();
unbuddied = this_cpu_ptr(pool->unbuddied);
[PATCH 1/7] USB: serial: cp210x: suppress modem-control errors
The CP210X_SET_MHS request cannot be used to control RTS when hardware
flow control (auto-RTS) is enabled and instead returns an error which is
currently logged as:
cp210x ttyUSB0: failed set request 0x7 status: -32
when opening and closing a port (and on TIOCMSET requests).
Add a crtscts flag to keep track of the hardware flow-control setting
and use it to suppress any request to change RTS when auto-RTS is
enabled.
Note that RTS is still deasserted when disabling the UART as part of
close.
Reported-by: Pho Tran
Signed-off-by: Johan Hovold
---
drivers/usb/serial/cp210x.c | 33 ++---
1 file changed, 30 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index d813a052738f..7e4a09b42c99 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#define DRIVER_DESC "Silicon Labs CP210x RS232 serial adaptor driver"
@@ -264,7 +265,10 @@ struct cp210x_port_private {
u8 bInterfaceNumber;
boolevent_mode;
enum cp210x_event_state event_state;
- u8 lsr;
+ u8 lsr;
+
+ struct mutexmutex;
+ boolcrtscts;
};
static struct usb_serial_driver cp210x_device = {
@@ -1117,6 +1121,7 @@ static bool cp210x_termios_change(const struct ktermios
*a, const struct ktermio
static void cp210x_set_flow_control(struct tty_struct *tty,
struct usb_serial_port *port, struct ktermios *old_termios)
{
+ struct cp210x_port_private *port_priv = usb_get_serial_port_data(port);
struct cp210x_special_chars chars;
struct cp210x_flow_ctl flow_ctl;
u32 flow_repl;
@@ -1143,10 +1148,12 @@ static void cp210x_set_flow_control(struct tty_struct
*tty,
return;
}
+ mutex_lock(&port_priv->mutex);
+
ret = cp210x_read_reg_block(port, CP210X_GET_FLOW, &flow_ctl,
sizeof(flow_ctl));
if (ret)
- return;
+ goto out_unlock;
ctl_hs = le32_to_cpu(flow_ctl.ulControlHandshake);
flow_repl = le32_to_cpu(flow_ctl.ulFlowReplace);
@@ -1161,10 +1168,12 @@ static void cp210x_set_flow_control(struct tty_struct
*tty,
ctl_hs |= CP210X_SERIAL_CTS_HANDSHAKE;
flow_repl &= ~CP210X_SERIAL_RTS_MASK;
flow_repl |=
CP210X_SERIAL_RTS_SHIFT(CP210X_SERIAL_RTS_FLOW_CTL);
+ port_priv->crtscts = true;
} else {
ctl_hs &= ~CP210X_SERIAL_CTS_HANDSHAKE;
flow_repl &= ~CP210X_SERIAL_RTS_MASK;
flow_repl |= CP210X_SERIAL_RTS_SHIFT(CP210X_SERIAL_RTS_ACTIVE);
+ port_priv->crtscts = false;
}
if (I_IXOFF(tty))
@@ -1188,6 +1197,8 @@ static void cp210x_set_flow_control(struct tty_struct
*tty,
cp210x_write_reg_block(port, CP210X_SET_FLOW, &flow_ctl,
sizeof(flow_ctl));
+out_unlock:
+ mutex_unlock(&port_priv->mutex);
}
static void cp210x_set_termios(struct tty_struct *tty,
@@ -1272,7 +1283,9 @@ static int cp210x_tiocmset(struct tty_struct *tty,
static int cp210x_tiocmset_port(struct usb_serial_port *port,
unsigned int set, unsigned int clear)
{
+ struct cp210x_port_private *port_priv = usb_get_serial_port_data(port);
u16 control = 0;
+ int ret;
if (set & TIOCM_RTS) {
control |= CONTROL_RTS;
@@ -1291,9 +1304,22 @@ static int cp210x_tiocmset_port(struct usb_serial_port
*port,
control |= CONTROL_WRITE_DTR;
}
+ mutex_lock(&port_priv->mutex);
+
+ /*
+* SET_MHS cannot be used to control RTS when auto-RTS is enabled.
+* Note that RTS is still deasserted when disabling the UART on close.
+*/
+ if (port_priv->crtscts)
+ control &= ~CONTROL_WRITE_RTS;
+
dev_dbg(&port->dev, "%s - control = 0x%.4x\n", __func__, control);
- return cp210x_write_u16_reg(port, CP210X_SET_MHS, control);
+ ret = cp210x_write_u16_reg(port, CP210X_SET_MHS, control);
+
+ mutex_unlock(&port_priv->mutex);
+
+ return ret;
}
static void cp210x_dtr_rts(struct usb_serial_port *port, int on)
@@ -1770,6 +1796,7 @@ static int cp210x_port_probe(struct usb_serial_port *port)
return -ENOMEM;
port_priv->bInterfaceNumber = cp210x_interface_num(serial);
+ mutex_init(&port_priv->mutex);
usb_set_serial_port_data(port, port_priv);
--
2.26.2
[PATCH 7/7] USB: serial: cp210x: clean up auto-RTS handling
Clear the RTS bits of the flow-control request before determining the
new value when updating the settings.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/cp210x.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index f00b736f3cd3..cc4f63a06f9e 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -1163,9 +1163,9 @@ static void cp210x_set_flow_control(struct tty_struct
*tty,
else
ctl_hs |= CP210X_SERIAL_DTR_INACTIVE;
+ flow_repl &= ~CP210X_SERIAL_RTS_MASK;
if (C_CRTSCTS(tty)) {
ctl_hs |= CP210X_SERIAL_CTS_HANDSHAKE;
- flow_repl &= ~CP210X_SERIAL_RTS_MASK;
if (port_priv->rts)
flow_repl |= CP210X_SERIAL_RTS_FLOW_CTL;
else
@@ -1173,7 +1173,6 @@ static void cp210x_set_flow_control(struct tty_struct
*tty,
port_priv->crtscts = true;
} else {
ctl_hs &= ~CP210X_SERIAL_CTS_HANDSHAKE;
- flow_repl &= ~CP210X_SERIAL_RTS_MASK;
if (port_priv->rts)
flow_repl |= CP210X_SERIAL_RTS_ACTIVE;
else
--
2.26.2
[PATCH 4/7] USB: serial: cp210x: clean up flow-control debug message
Shorten the flow-control debug message by abbreviating the field names and reducing the value width to two characters. The latter improves readability since all but the least significant byte will almost always be zero anyway. Signed-off-by: Johan Hovold --- drivers/usb/serial/cp210x.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c index aa874641374a..36ae44818c13 100644 --- a/drivers/usb/serial/cp210x.c +++ b/drivers/usb/serial/cp210x.c @@ -1191,8 +1191,8 @@ static void cp210x_set_flow_control(struct tty_struct *tty, flow_ctl.ulXonLimit = cpu_to_le32(128); flow_ctl.ulXoffLimit = cpu_to_le32(128); - dev_dbg(&port->dev, "%s - ulControlHandshake=0x%08x, ulFlowReplace=0x%08x\n", - __func__, ctl_hs, flow_repl); + dev_dbg(&port->dev, "%s - ctrl = 0x%02x, flow = 0x%02x\n", __func__, + ctl_hs, flow_repl); flow_ctl.ulControlHandshake = cpu_to_le32(ctl_hs); flow_ctl.ulFlowReplace = cpu_to_le32(flow_repl); -- 2.26.2
Re: [PATCH] bridge: Use PTR_ERR_OR_ZERO instead if(IS_ERR(...)) + PTR_ERR
On 25/01/2021 04:39, Jiapeng Zhong wrote: > coccicheck suggested using PTR_ERR_OR_ZERO() and looking at the code. > > Fix the following coccicheck warnings: > > ./net/bridge/br_multicast.c:1295:7-13: WARNING: PTR_ERR_OR_ZERO can be > used. > > Reported-by: Abaci > Signed-off-by: Jiapeng Zhong > --- > net/bridge/br_multicast.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c > index 257ac4e..2229d10 100644 > --- a/net/bridge/br_multicast.c > +++ b/net/bridge/br_multicast.c > @@ -1292,7 +1292,7 @@ static int br_multicast_add_group(struct net_bridge *br, > pg = __br_multicast_add_group(br, port, group, src, filter_mode, > igmpv2_mldv1, false); > /* NULL is considered valid for host joined groups */ > - err = IS_ERR(pg) ? PTR_ERR(pg) : 0; > + err = PTR_ERR_OR_ZERO(pg); > spin_unlock(&br->multicast_lock); > > return err; > This should be targeted at net-next. Acked-by: Nikolay Aleksandrov
[PATCH 6/7] USB: serial: cp210x: fix RTS handling
Clearing TIOCM_RTS should always deassert RTS and setting the same bit
should enable auto-RTS if hardware flow control is enabled.
This allows user space to throttle input directly at the source also
when hardware-assisted flow control is enabled and makes dtr_rts()
always deassert both lines during close (when HUPCL is set).
Signed-off-by: Johan Hovold
---
drivers/usb/serial/cp210x.c | 47 +++--
1 file changed, 40 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index 4ba3fb096bf1..f00b736f3cd3 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -1166,7 +1166,10 @@ static void cp210x_set_flow_control(struct tty_struct
*tty,
if (C_CRTSCTS(tty)) {
ctl_hs |= CP210X_SERIAL_CTS_HANDSHAKE;
flow_repl &= ~CP210X_SERIAL_RTS_MASK;
- flow_repl |= CP210X_SERIAL_RTS_FLOW_CTL;
+ if (port_priv->rts)
+ flow_repl |= CP210X_SERIAL_RTS_FLOW_CTL;
+ else
+ flow_repl |= CP210X_SERIAL_RTS_INACTIVE;
port_priv->crtscts = true;
} else {
ctl_hs &= ~CP210X_SERIAL_CTS_HANDSHAKE;
@@ -1286,6 +1289,8 @@ static int cp210x_tiocmset_port(struct usb_serial_port
*port,
unsigned int set, unsigned int clear)
{
struct cp210x_port_private *port_priv = usb_get_serial_port_data(port);
+ struct cp210x_flow_ctl flow_ctl;
+ u32 ctl_hs, flow_repl;
u16 control = 0;
int ret;
@@ -1313,16 +1318,44 @@ static int cp210x_tiocmset_port(struct usb_serial_port
*port,
}
/*
-* SET_MHS cannot be used to control RTS when auto-RTS is enabled.
-* Note that RTS is still deasserted when disabling the UART on close.
+* Use SET_FLOW to set DTR and enable/disable auto-RTS when hardware
+* flow control is enabled.
*/
- if (port_priv->crtscts)
- control &= ~CONTROL_WRITE_RTS;
+ if (port_priv->crtscts && control & CONTROL_WRITE_RTS) {
+ ret = cp210x_read_reg_block(port, CP210X_GET_FLOW, &flow_ctl,
+ sizeof(flow_ctl));
+ if (ret)
+ goto out_unlock;
- dev_dbg(&port->dev, "%s - control = 0x%04x\n", __func__, control);
+ ctl_hs = le32_to_cpu(flow_ctl.ulControlHandshake);
+ flow_repl = le32_to_cpu(flow_ctl.ulFlowReplace);
- ret = cp210x_write_u16_reg(port, CP210X_SET_MHS, control);
+ ctl_hs &= ~CP210X_SERIAL_DTR_MASK;
+ if (port_priv->dtr)
+ ctl_hs |= CP210X_SERIAL_DTR_ACTIVE;
+ else
+ ctl_hs |= CP210X_SERIAL_DTR_INACTIVE;
+ flow_repl &= ~CP210X_SERIAL_RTS_MASK;
+ if (port_priv->rts)
+ flow_repl |= CP210X_SERIAL_RTS_FLOW_CTL;
+ else
+ flow_repl |= CP210X_SERIAL_RTS_INACTIVE;
+
+ flow_ctl.ulControlHandshake = cpu_to_le32(ctl_hs);
+ flow_ctl.ulFlowReplace = cpu_to_le32(flow_repl);
+
+ dev_dbg(&port->dev, "%s - ctrl = 0x%02x, flow = 0x%02x\n",
+ __func__, ctl_hs, flow_repl);
+
+ ret = cp210x_write_reg_block(port, CP210X_SET_FLOW, &flow_ctl,
+ sizeof(flow_ctl));
+ } else {
+ dev_dbg(&port->dev, "%s - control = 0x%04x\n", __func__,
control);
+
+ ret = cp210x_write_u16_reg(port, CP210X_SET_MHS, control);
+ }
+out_unlock:
mutex_unlock(&port_priv->mutex);
return ret;
--
2.26.2
Re: [PATCH v2 04/17] mfd: bd718x7: simplify by cleaning unnecessary device data
On Tue, 19 Jan 2021, Matti Vaittinen wrote: > Most ROHM PMIC sub-devices only use the regmap pointer from > parent device. They can obtain this by dev_get_regamap so in > most cases the MFD device does not need to allocate and populate > the driver data. Simplify drivers by removing this. > > The BD70528 still needs the access to watchdog mutex so keep > rohm_regmap_dev in use on BD70528 RTC and WDG drivers for now. > > Signed-off-by: Matti Vaittinen > --- > > No changes since v1 > > drivers/mfd/rohm-bd718x7.c | 43 > include/linux/mfd/rohm-bd718x7.h | 13 -- > 2 files changed, 16 insertions(+), 40 deletions(-) For my own reference (apply this as-is to your sign-off block): Acked-for-MFD-by: Lee Jones -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
