Re: [PATCH v5] dma-buf: Add DmaBufTotal counter in meminfo
On Tue, Apr 20, 2021 at 09:26:00AM +, peter.enderb...@sony.com wrote:
> On 4/20/21 10:58 AM, Daniel Vetter wrote:
> > On Sat, Apr 17, 2021 at 06:38:35PM +0200, Peter Enderborg wrote:
> >> This adds a total used dma-buf memory. Details
> >> can be found in debugfs, however it is not for everyone
> >> and not always available. dma-buf are indirect allocated by
> >> userspace. So with this value we can monitor and detect
> >> userspace applications that have problems.
> >>
> >> Signed-off-by: Peter Enderborg
> > So there have been tons of discussions around how to track dma-buf and
> > why, and I really need to understand the use-cass here first I think. proc
> > uapi is as much forever as anything else, and depending what you're doing
> > this doesn't make any sense at all:
> >
> > - on most linux systems dma-buf are only instantiated for shared buffer.
> > So there this gives you a fairly meaningless number and not anything
> > reflecting gpu memory usage at all.
> >
> > - on Android all buffers are allocated through dma-buf afaik. But there
> > we've recently had some discussions about how exactly we should track
> > all this, and the conclusion was that most of this should be solved by
> > cgroups long term. So if this is for Android, then I don't think adding
> > random quick stop-gaps to upstream is a good idea (because it's a pretty
> > long list of patches that have come up on this).
> >
> > So what is this for?
>
> For the overview. dma-buf today only have debugfs for info. Debugfs
> is not allowed by google to use in andoid. So this aggregate the information
> so we can get information on what going on on the system.
>
> And the LKML standard respond to that is "SHOW ME THE CODE".
Yes. Except this extends to how exactly this is supposed to be used in
userspace and acted upon.
> When the top memgc has a aggregated information on dma-buf it is maybe
> a better source to meminfo. But then it also imply that dma-buf requires
> memcg.
>
> And I dont see any problem to replace this with something better with it is
> ready.
The thing is, this is uapi. Once it's merged we cannot, ever, replace it.
It must be kept around forever, or a very close approximation thereof. So
merging this with the justification that we can fix it later on or replace
isn't going to happen.
-Daniel
>
> > -Daniel
> >
> >> ---
> >> drivers/dma-buf/dma-buf.c | 12
> >> fs/proc/meminfo.c | 5 -
> >> include/linux/dma-buf.h | 1 +
> >> 3 files changed, 17 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> >> index f264b70c383e..4dc37cd4293b 100644
> >> --- a/drivers/dma-buf/dma-buf.c
> >> +++ b/drivers/dma-buf/dma-buf.c
> >> @@ -37,6 +37,7 @@ struct dma_buf_list {
> >> };
> >>
> >> static struct dma_buf_list db_list;
> >> +static atomic_long_t dma_buf_global_allocated;
> >>
> >> static char *dmabuffs_dname(struct dentry *dentry, char *buffer, int
> >> buflen)
> >> {
> >> @@ -79,6 +80,7 @@ static void dma_buf_release(struct dentry *dentry)
> >>if (dmabuf->resv == (struct dma_resv *)[1])
> >>dma_resv_fini(dmabuf->resv);
> >>
> >> + atomic_long_sub(dmabuf->size, _buf_global_allocated);
> >>module_put(dmabuf->owner);
> >>kfree(dmabuf->name);
> >>kfree(dmabuf);
> >> @@ -586,6 +588,7 @@ struct dma_buf *dma_buf_export(const struct
> >> dma_buf_export_info *exp_info)
> >>mutex_lock(_list.lock);
> >>list_add(>list_node, _list.head);
> >>mutex_unlock(_list.lock);
> >> + atomic_long_add(dmabuf->size, _buf_global_allocated);
> >>
> >>return dmabuf;
> >>
> >> @@ -1346,6 +1349,15 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, struct
> >> dma_buf_map *map)
> >> }
> >> EXPORT_SYMBOL_GPL(dma_buf_vunmap);
> >>
> >> +/**
> >> + * dma_buf_allocated_pages - Return the used nr of pages
> >> + * allocated for dma-buf
> >> + */
> >> +long dma_buf_allocated_pages(void)
> >> +{
> >> + return atomic_long_read(_buf_global_allocated) >> PAGE_SHIFT;
> >> +}
> >> +
> >> #ifdef CONFIG_DEBUG_FS
> >> static int dma_buf_debug_show(struct seq_file *s, void *unused)
> >> {
> >> diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c
> >> index 6f
Re: [PATCH 2/2] drm/gma500: remove trailing whitespaces
recv_size;
> -
> +
> for (i = 0; i < recv_bytes; i += 4)
> unpack_aux(REG_READ(ch_data + i),
> recv + i, recv_bytes - i);
> @@ -870,7 +870,7 @@ cdv_intel_dp_i2c_init(struct gma_connector *connector,
> ret = i2c_dp_aux_add_bus(_dp->adapter);
> if (is_edp(encoder))
> cdv_intel_edp_panel_vdd_off(encoder);
> -
> +
> return ret;
> }
>
> @@ -1291,13 +1291,13 @@ cdv_intel_get_adjust_train(struct gma_encoder
> *encoder)
> if (this_p > p)
> p = this_p;
> }
> -
> +
> if (v >= CDV_DP_VOLTAGE_MAX)
> v = CDV_DP_VOLTAGE_MAX | DP_TRAIN_MAX_SWING_REACHED;
>
> if (p == DP_TRAIN_PRE_EMPHASIS_MASK)
> p |= DP_TRAIN_MAX_PRE_EMPHASIS_REACHED;
> -
> +
> for (lane = 0; lane < 4; lane++)
> intel_dp->train_set[lane] = v | p;
> }
> @@ -1358,7 +1358,6 @@ cdv_intel_dp_set_link_train(struct gma_encoder *encoder,
> uint32_t dp_reg_value,
> uint8_t dp_train_pat)
> {
> -
> struct drm_device *dev = encoder->base.dev;
> int ret;
> struct cdv_intel_dp *intel_dp = encoder->dev_priv;
> @@ -1384,7 +1383,6 @@ static bool
> cdv_intel_dplink_set_level(struct gma_encoder *encoder,
> uint8_t dp_train_pat)
> {
> -
> int ret;
> struct cdv_intel_dp *intel_dp = encoder->dev_priv;
>
> @@ -1462,7 +1460,7 @@ cdv_intel_dp_set_vswing_premph(struct gma_encoder
> *encoder, uint8_t signal_level
> /* ;gfx_dpio_set_reg(0x8124, 0x4000) */
> index = 2 * premph + 1;
> cdv_sb_write(dev, ddi_reg->PreEmph2, dp_vswing_premph_table[index]);
> - return;
> + return;
> }
>
>
> @@ -1481,8 +1479,8 @@ cdv_intel_dp_start_link_train(struct gma_encoder
> *encoder)
>
> DP |= DP_PORT_EN;
> DP &= ~DP_LINK_TRAIN_MASK;
> -
> - reg = DP;
> +
> + reg = DP;
> reg |= DP_LINK_TRAIN_PAT_1;
> /* Enable output, wait for it to become active */
> REG_WRITE(intel_dp->output_reg, reg);
> @@ -1556,7 +1554,7 @@ cdv_intel_dp_start_link_train(struct gma_encoder
> *encoder)
> if (!clock_recovery) {
> DRM_DEBUG_KMS("failure in DP patter 1 training, train set
> %x\n", intel_dp->train_set[0]);
> }
> -
> +
> intel_dp->DP = DP;
> }
>
> @@ -1747,7 +1745,7 @@ static int cdv_intel_dp_get_modes(struct drm_connector
> *connector)
> if (is_edp(intel_encoder)) {
> struct drm_device *dev = connector->dev;
> struct drm_psb_private *dev_priv = dev->dev_private;
> -
> +
> cdv_intel_edp_panel_vdd_off(intel_encoder);
> if (ret) {
> if (edp && !intel_dp->panel_fixed_mode) {
> @@ -1942,11 +1940,11 @@ static void cdv_disable_intel_clock_gating(struct
> drm_device *dev)
> DPCUNIT_CLOCK_GATE_DISABLE |
> DPLSUNIT_CLOCK_GATE_DISABLE |
> DPOUNIT_CLOCK_GATE_DISABLE |
> - DPIOUNIT_CLOCK_GATE_DISABLE);
> + DPIOUNIT_CLOCK_GATE_DISABLE);
>
> REG_WRITE(DSPCLK_GATE_D, reg_value);
>
> - udelay(500);
> + udelay(500);
> }
>
> void
> @@ -1990,7 +1988,7 @@ cdv_intel_dp_init(struct drm_device *dev, struct
> psb_intel_mode_device *mode_dev
> gma_encoder->dev_priv=intel_dp;
> intel_dp->encoder = gma_encoder;
> intel_dp->output_reg = output_reg;
> -
> +
> drm_encoder_helper_add(encoder, _intel_dp_helper_funcs);
> drm_connector_helper_add(connector,
> _intel_dp_connector_helper_funcs);
>
> @@ -2027,7 +2025,7 @@ cdv_intel_dp_init(struct drm_device *dev, struct
> psb_intel_mode_device *mode_dev
> pp_on = REG_READ(PP_CONTROL);
> pp_on &= ~PANEL_UNLOCK_MASK;
> pp_on |= PANEL_UNLOCK_REGS;
> -
> +
> REG_WRITE(PP_CONTROL, pp_on);
>
> pwm_ctrl = REG_READ(BLC_PWM_CTL2);
> @@ -2037,7 +2035,7 @@ cdv_intel_dp_init(struct drm_device *dev, struct
> psb_intel_mode_device *mode_dev
> pp_on = REG_READ(PP_ON_DELAYS);
> pp_off = REG_READ(PP_OFF_DELAYS);
> pp_div = REG_READ(PP_DIVISOR);
> -
> +
> /* Pull timing values out of registers */
> cur.t1_t3 = (pp_on & PANEL_POWER_UP_DELAY_MASK) >>
> PANEL_POWER_UP_DELAY_SHIFT;
> @@ -2085,9 +2083,9 @@ cdv_intel_dp_init(struct drm_device *dev, struct
> psb_intel_mode_device *mode_dev
> goto err_connector;
> } else {
> DRM_DEBUG_KMS("DPCD: Rev=%x LN_Rate=%x LN_CNT=%x
> LN_DOWNSP=%x\n",
> - intel_dp->dpcd[0], intel_dp->dpcd[1],
> + intel_dp->dpcd[0], intel_dp->dpcd[1],
> intel_dp->dpcd[2], intel_dp->dpcd[3]);
> -
> +
> }
> /* The CDV reference driver moves pnale backlight setup into
> the displays that
> have a backlight: this is a good idea and one we should
> probably adopt, however
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v5] dma-buf: Add DmaBufTotal counter in meminfo
On Sat, Apr 17, 2021 at 06:38:35PM +0200, Peter Enderborg wrote:
> This adds a total used dma-buf memory. Details
> can be found in debugfs, however it is not for everyone
> and not always available. dma-buf are indirect allocated by
> userspace. So with this value we can monitor and detect
> userspace applications that have problems.
>
> Signed-off-by: Peter Enderborg
So there have been tons of discussions around how to track dma-buf and
why, and I really need to understand the use-cass here first I think. proc
uapi is as much forever as anything else, and depending what you're doing
this doesn't make any sense at all:
- on most linux systems dma-buf are only instantiated for shared buffer.
So there this gives you a fairly meaningless number and not anything
reflecting gpu memory usage at all.
- on Android all buffers are allocated through dma-buf afaik. But there
we've recently had some discussions about how exactly we should track
all this, and the conclusion was that most of this should be solved by
cgroups long term. So if this is for Android, then I don't think adding
random quick stop-gaps to upstream is a good idea (because it's a pretty
long list of patches that have come up on this).
So what is this for?
-Daniel
> ---
> drivers/dma-buf/dma-buf.c | 12
> fs/proc/meminfo.c | 5 -
> include/linux/dma-buf.h | 1 +
> 3 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index f264b70c383e..4dc37cd4293b 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -37,6 +37,7 @@ struct dma_buf_list {
> };
>
> static struct dma_buf_list db_list;
> +static atomic_long_t dma_buf_global_allocated;
>
> static char *dmabuffs_dname(struct dentry *dentry, char *buffer, int buflen)
> {
> @@ -79,6 +80,7 @@ static void dma_buf_release(struct dentry *dentry)
> if (dmabuf->resv == (struct dma_resv *)[1])
> dma_resv_fini(dmabuf->resv);
>
> + atomic_long_sub(dmabuf->size, _buf_global_allocated);
> module_put(dmabuf->owner);
> kfree(dmabuf->name);
> kfree(dmabuf);
> @@ -586,6 +588,7 @@ struct dma_buf *dma_buf_export(const struct
> dma_buf_export_info *exp_info)
> mutex_lock(_list.lock);
> list_add(>list_node, _list.head);
> mutex_unlock(_list.lock);
> + atomic_long_add(dmabuf->size, _buf_global_allocated);
>
> return dmabuf;
>
> @@ -1346,6 +1349,15 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, struct
> dma_buf_map *map)
> }
> EXPORT_SYMBOL_GPL(dma_buf_vunmap);
>
> +/**
> + * dma_buf_allocated_pages - Return the used nr of pages
> + * allocated for dma-buf
> + */
> +long dma_buf_allocated_pages(void)
> +{
> + return atomic_long_read(_buf_global_allocated) >> PAGE_SHIFT;
> +}
> +
> #ifdef CONFIG_DEBUG_FS
> static int dma_buf_debug_show(struct seq_file *s, void *unused)
> {
> diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c
> index 6fa761c9cc78..ccc7c40c8db7 100644
> --- a/fs/proc/meminfo.c
> +++ b/fs/proc/meminfo.c
> @@ -16,6 +16,7 @@
> #ifdef CONFIG_CMA
> #include
> #endif
> +#include
> #include
> #include "internal.h"
>
> @@ -145,7 +146,9 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
> show_val_kb(m, "CmaFree:",
> global_zone_page_state(NR_FREE_CMA_PAGES));
> #endif
> -
> +#ifdef CONFIG_DMA_SHARED_BUFFER
> + show_val_kb(m, "DmaBufTotal:", dma_buf_allocated_pages());
> +#endif
> hugetlb_report_meminfo(m);
>
> arch_report_meminfo(m);
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index efdc56b9d95f..5b05816bd2cd 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -507,4 +507,5 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct
> *,
>unsigned long);
> int dma_buf_vmap(struct dma_buf *dmabuf, struct dma_buf_map *map);
> void dma_buf_vunmap(struct dma_buf *dmabuf, struct dma_buf_map *map);
> +long dma_buf_allocated_pages(void);
> #endif /* __DMA_BUF_H__ */
> --
> 2.17.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH 27/40] drm/ttm/ttm_device: Demote kernel-doc abuses
On Fri, Apr 16, 2021 at 05:32:52PM +0200, Christian König wrote: > Am 16.04.21 um 16:37 schrieb Lee Jones: > > Fixes the following W=1 kernel build warning(s): > > > > drivers/gpu/drm/ttm/ttm_device.c:42: warning: Function parameter or > > member 'ttm_global_mutex' not described in 'DEFINE_MUTEX' > > drivers/gpu/drm/ttm/ttm_device.c:42: warning: expecting prototype for > > ttm_global_mutex(). Prototype was for DEFINE_MUTEX() instead > > drivers/gpu/drm/ttm/ttm_device.c:112: warning: Function parameter or > > member 'ctx' not described in 'ttm_global_swapout' > > drivers/gpu/drm/ttm/ttm_device.c:112: warning: Function parameter or > > member 'gfp_flags' not described in 'ttm_global_swapout' > > drivers/gpu/drm/ttm/ttm_device.c:112: warning: expecting prototype for A > > buffer object shrink method that tries to swap out the first(). Prototype > > was for ttm_global_swapout() instead > > > > Cc: Christian Koenig > > Cc: Huang Rui > > Cc: David Airlie > > Cc: Daniel Vetter > > Cc: dri-de...@lists.freedesktop.org > > Signed-off-by: Lee Jones > > Reviewed-by: Christian König Can you pls also land all the patches you reviewed from Lee into drm-misc-next? Just so they wont' get lost. Will all head in for 5.14. -Daniel > > > --- > > drivers/gpu/drm/ttm/ttm_device.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/ttm/ttm_device.c > > b/drivers/gpu/drm/ttm/ttm_device.c > > index 9b787b3caeb50..a8bec8358350d 100644 > > --- a/drivers/gpu/drm/ttm/ttm_device.c > > +++ b/drivers/gpu/drm/ttm/ttm_device.c > > @@ -36,7 +36,7 @@ > > #include "ttm_module.h" > > -/** > > +/* > >* ttm_global_mutex - protecting the global state > >*/ > > DEFINE_MUTEX(ttm_global_mutex); > > @@ -104,7 +104,7 @@ static int ttm_global_init(void) > > return ret; > > } > > -/** > > +/* > >* A buffer object shrink method that tries to swap out the first > >* buffer object on the global::swap_lru list. > >*/ > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH v4] dma-buf: Add DmaBufTotal counter in meminfo
On Sat, Apr 17, 2021 at 01:54:08PM +0200, Christian König wrote:
> Am 17.04.21 um 13:20 schrieb peter.enderb...@sony.com:
> > On 4/17/21 12:59 PM, Christian König wrote:
> > > Am 17.04.21 um 12:40 schrieb Peter Enderborg:
> > > > This adds a total used dma-buf memory. Details
> > > > can be found in debugfs, however it is not for everyone
> > > > and not always available. dma-buf are indirect allocated by
> > > > userspace. So with this value we can monitor and detect
> > > > userspace applications that have problems.
> > > >
> > > > Signed-off-by: Peter Enderborg
> > > Reviewed-by: Christian König
> > >
> > > How do you want to upstream this?
> > I don't understand that question. The patch applies on Torvalds 5.12-rc7,
> > but I guess 5.13 is what we work on right now.
>
> Yeah, but how do you want to get it into Linus tree?
>
> I can push it together with other DMA-buf patches through drm-misc-next and
> then Dave will send it to Linus for inclusion in 5.13.
Small correction, we've already frozen for the merge window so this will
land in 5.14.
-Daniel
>
> But could be that you are pushing multiple changes towards Linus through
> some other branch. In this case I'm fine if you pick that way instead if you
> want to keep your patches together for some reason.
>
> Christian.
>
> >
> > > > ---
> > > > drivers/dma-buf/dma-buf.c | 13 +
> > > > fs/proc/meminfo.c | 5 -
> > > > include/linux/dma-buf.h | 1 +
> > > > 3 files changed, 18 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> > > > index f264b70c383e..197e5c45dd26 100644
> > > > --- a/drivers/dma-buf/dma-buf.c
> > > > +++ b/drivers/dma-buf/dma-buf.c
> > > > @@ -37,6 +37,7 @@ struct dma_buf_list {
> > > > };
> > > > static struct dma_buf_list db_list;
> > > > +static atomic_long_t dma_buf_global_allocated;
> > > > static char *dmabuffs_dname(struct dentry *dentry, char *buffer,
> > > > int buflen)
> > > > {
> > > > @@ -79,6 +80,7 @@ static void dma_buf_release(struct dentry *dentry)
> > > > if (dmabuf->resv == (struct dma_resv *)[1])
> > > > dma_resv_fini(dmabuf->resv);
> > > > + atomic_long_sub(dmabuf->size, _buf_global_allocated);
> > > > module_put(dmabuf->owner);
> > > > kfree(dmabuf->name);
> > > > kfree(dmabuf);
> > > > @@ -586,6 +588,7 @@ struct dma_buf *dma_buf_export(const struct
> > > > dma_buf_export_info *exp_info)
> > > > mutex_lock(_list.lock);
> > > > list_add(>list_node, _list.head);
> > > > mutex_unlock(_list.lock);
> > > > + atomic_long_add(dmabuf->size, _buf_global_allocated);
> > > > return dmabuf;
> > > > @@ -1346,6 +1349,16 @@ void dma_buf_vunmap(struct dma_buf *dmabuf,
> > > > struct dma_buf_map *map)
> > > > }
> > > > EXPORT_SYMBOL_GPL(dma_buf_vunmap);
> > > > +/**
> > > > + * dma_buf_allocated_pages - Return the used nr of pages
> > > > + * allocated for dma-buf
> > > > + */
> > > > +long dma_buf_allocated_pages(void)
> > > > +{
> > > > + return atomic_long_read(_buf_global_allocated) >> PAGE_SHIFT;
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(dma_buf_allocated_pages);
> > > > +
> > > > #ifdef CONFIG_DEBUG_FS
> > > > static int dma_buf_debug_show(struct seq_file *s, void *unused)
> > > > {
> > > > diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c
> > > > index 6fa761c9cc78..ccc7c40c8db7 100644
> > > > --- a/fs/proc/meminfo.c
> > > > +++ b/fs/proc/meminfo.c
> > > > @@ -16,6 +16,7 @@
> > > > #ifdef CONFIG_CMA
> > > > #include
> > > > #endif
> > > > +#include
> > > > #include
> > > > #include "internal.h"
> > > > @@ -145,7 +146,9 @@ static int meminfo_proc_show(struct seq_file *m,
> > > > void *v)
> > > > show_val_kb(m, "CmaFree: ",
> > > > global_zone_page_state(NR_FREE_CMA_PAGES));
> > > > #endif
> > > > -
> > > > +#ifdef CONFIG_DMA_SHARED_BUFFER
> > > > + show_val_kb(m, "DmaBufTotal: ", dma_buf_allocated_pages());
> > > > +#endif
> > > > hugetlb_report_meminfo(m);
> > > > arch_report_meminfo(m);
> > > > diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> > > > index efdc56b9d95f..5b05816bd2cd 100644
> > > > --- a/include/linux/dma-buf.h
> > > > +++ b/include/linux/dma-buf.h
> > > > @@ -507,4 +507,5 @@ int dma_buf_mmap(struct dma_buf *, struct
> > > > vm_area_struct *,
> > > > unsigned long);
> > > > int dma_buf_vmap(struct dma_buf *dmabuf, struct dma_buf_map *map);
> > > > void dma_buf_vunmap(struct dma_buf *dmabuf, struct dma_buf_map *map);
> > > > +long dma_buf_allocated_pages(void);
> > > > #endif /* __DMA_BUF_H__ */
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH] drm: Fix fbcon blank on QEMU graphics drivers
On Fri, Apr 16, 2021 at 2:53 PM Takashi Iwai wrote:
>
> Currently the DRM fbcon helper for console blank,
> drm_fb_helper_blank(), simply calls drm_fb_helper_dpms() and always
> returns zero, supposing the driver dealing with DPMS or atomic
> crtc->active flip to handle blanking the screen. It works on most of
> devices, but broken on most of KVM/QEMU graphics: bochs, qxl and
> cirrus drivers just ignore crtc->active state change as blanking (or
> cirrus ignoring DPMS). In practice, when you run like
> % setterm --blank force
> on a VT console, the screen freezes without actually blanking.
>
> A simple fix for this problem would be not to rely on DPMS but let
> fbcon performs the generic blank code. This can be achieved just by
> returning an error from drm_fb_helper_blank().
>
> In this patch, we add a flag, no_dpms_blank, to drm_fb_helper for
> indicating that the driver doesn't handle blank via DPMS or
> crtc->active flip. When this flag is set, drm_fb_helper_blank()
> simply returns an error, so that fbcon falls back to its generic blank
> handler. The flag is set to both bochs and qxl drivers in this patch,
> while cirrus is left untouched as it's declared as to-be-deprecated.
>
> Link: https://lore.kernel.org/dri-devel/20170726205636.19144-1-ti...@suse.de/
> BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1095700
> Signed-off-by: Takashi Iwai
Uh we're supposed to fix these drivers to actually blank (scan out
black, worst case), not paper over it in higher levels. Atomic kms is
meant to be a somewhat useful abstraction. So now fbcon blanks, but
your desktop still just freezes.
> ---
>
> Here I whip a dead horse again, revisiting the long-standing issue
> stated in the previous patch set in 2017:
> https://lore.kernel.org/dri-devel/20170726205636.19144-1-ti...@suse.de/
>
> I thought to refresh the previous patch set at first, but it seems
> invalid for the atomic modeset case. And for the atomic, it's even
> more difficult to propagate the return from the bottom to up.
> So I ended up with this approach as it's much simpler.
Yeah that's because atomic assume you can at least blank your screen to black.
-Daniel
> But if there is any better way (even simpler or more robust), I'd
> happily rewrite, too.
>
> ---
> drivers/gpu/drm/bochs/bochs_drv.c | 3 +++
> drivers/gpu/drm/drm_fb_helper.c | 5 +
> drivers/gpu/drm/qxl/qxl_drv.c | 3 +++
> include/drm/drm_fb_helper.h | 8
> 4 files changed, 19 insertions(+)
>
> diff --git a/drivers/gpu/drm/bochs/bochs_drv.c
> b/drivers/gpu/drm/bochs/bochs_drv.c
> index b469624fe40d..816899a266ff 100644
> --- a/drivers/gpu/drm/bochs/bochs_drv.c
> +++ b/drivers/gpu/drm/bochs/bochs_drv.c
> @@ -132,6 +132,9 @@ static int bochs_pci_probe(struct pci_dev *pdev,
> goto err_unload;
>
> drm_fbdev_generic_setup(dev, 32);
> + if (dev->fb_helper)
> + dev->fb_helper->no_dpms_blank = true;
> +
> return ret;
>
> err_unload:
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index f6baa2046124..b892f02ff2f1 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -332,9 +332,14 @@ static void drm_fb_helper_dpms(struct fb_info *info, int
> dpms_mode)
> */
> int drm_fb_helper_blank(int blank, struct fb_info *info)
> {
> + struct drm_fb_helper *fb_helper = info->par;
> +
> if (oops_in_progress)
> return -EBUSY;
>
> + if (fb_helper->no_dpms_blank)
> + return -EINVAL;
> +
> switch (blank) {
> /* Display: On; HSync: On, VSync: On */
> case FB_BLANK_UNBLANK:
> diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
> index 1864467f1063..58ecfaeed7c1 100644
> --- a/drivers/gpu/drm/qxl/qxl_drv.c
> +++ b/drivers/gpu/drm/qxl/qxl_drv.c
> @@ -120,6 +120,9 @@ qxl_pci_probe(struct pci_dev *pdev, const struct
> pci_device_id *ent)
> goto modeset_cleanup;
>
> drm_fbdev_generic_setup(>ddev, 32);
> + if (qdev->fb_helper)
> + qdev->fb_helper->no_dpms_blank = true;
> +
> return 0;
>
> modeset_cleanup:
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index 3b273f9ca39a..151be4219c32 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -176,6 +176,14 @@ struct drm_fb_helper {
> */
> bool deferred_setup;
>
> + /**
> +* @no_dpms_blank:
> +*
> +* A flag indicating that the driver doesn't support blanking.
> + * Then fbcon core code falls ba
[PULL] drm-fixes
Hi Linus, I pinged the usual suspects, only intel fixes pending. drm-next also looks ready, minus the big pull request summary Dave will have to type next week. Cheers, Daniel drm-fixes-2021-04-16: drm/i915 fixes Cheers, Daniel The following changes since commit d434405aaab7d0ebc516b68a8fc4100922d7f5ef: Linux 5.12-rc7 (2021-04-11 15:16:13 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-04-16 for you to fetch changes up to 4d2e1288372ccc5ac60290bc10cace49c9bfa6d0: Merge tag 'drm-intel-fixes-2021-04-15' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2021-04-15 15:24:17 +0200) drm/i915 fixes Daniel Vetter (1): Merge tag 'drm-intel-fixes-2021-04-15' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Hans de Goede (1): drm/i915/display/vlv_dsi: Do not skip panel_pwr_cycle_delay when disabling the panel Lyude Paul (1): drm/i915/dpcd_bl: Don't try vesa interface unless specified by VBT Ville Syrjälä (1): drm/i915: Don't zero out the Y plane's watermarks drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 1 - drivers/gpu/drm/i915/display/vlv_dsi.c| 4 ++-- drivers/gpu/drm/i915/intel_pm.c | 4 ++-- 3 files changed, 4 insertions(+), 5 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH 1/2] mm/vmscan: add sync_shrinkers function
On Thu, Apr 15, 2021 at 01:56:23PM +0200, Christian König wrote:
> To be able to switch to a spinlock and reduce lock contention in the TTM
> shrinker we don't want to hold a mutex while unmapping and freeing pages
> from the pool.
>
> But then we somehow need to prevent a race between (for example) the shrinker
> trying to free pages and hotplug trying to remove the device which those pages
> belong to.
>
> Taking and releasing the shrinker semaphore on the write side after
> unmapping and freeing all pages should make sure that no shrinker is running
> in
> paralell any more.
>
> Signed-off-by: Christian König
> ---
> include/linux/shrinker.h | 1 +
> mm/vmscan.c | 10 ++
> 2 files changed, 11 insertions(+)
>
> diff --git a/include/linux/shrinker.h b/include/linux/shrinker.h
> index 0f80123650e2..6b75dc372fce 100644
> --- a/include/linux/shrinker.h
> +++ b/include/linux/shrinker.h
> @@ -92,4 +92,5 @@ extern void register_shrinker_prepared(struct shrinker
> *shrinker);
> extern int register_shrinker(struct shrinker *shrinker);
> extern void unregister_shrinker(struct shrinker *shrinker);
> extern void free_prealloced_shrinker(struct shrinker *shrinker);
> +extern void sync_shrinkers(void);
> #endif
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 562e87cbd7a1..46cd9c215d73 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -408,6 +408,16 @@ void unregister_shrinker(struct shrinker *shrinker)
> }
> EXPORT_SYMBOL(unregister_shrinker);
>
> +/**
> + * sync_shrinker - Wait for all running shrinkers to complete.
Maybe make it clear this is a barrier type thing, it wont stop shrinkers
at all, just synchronize with them.
Acked-by: Daniel Vetter
But needs an ack from Andrew for merging through drm-misc-next before we
push it there.
-Daniel
> + */
> +void sync_shrinkers(void)
> +{
> + down_write(_rwsem);
> + up_write(_rwsem);
> +}
> +EXPORT_SYMBOL(sync_shrinkers);
> +
> #define SHRINK_BATCH 128
>
> static unsigned long do_shrink_slab(struct shrink_control *shrinkctl,
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH] efifb: Check efifb_pci_dev before using it
On Tue, Apr 13, 2021 at 8:02 PM Alex Deucher wrote:
>
> On Tue, Apr 13, 2021 at 1:05 PM Kai-Heng Feng
> wrote:
> >
> > On some platforms like Hyper-V and RPi4 with UEFI firmware, efifb is not
> > a PCI device.
> >
> > So make sure efifb_pci_dev is found before using it.
> >
> > Fixes: a6c0fd3d5a8b ("efifb: Ensure graphics device for efifb stays at PCI
> > D0")
> > BugLink: https://bugs.launchpad.net/bugs/1922403
> > Signed-off-by: Kai-Heng Feng
>
> Reviewed-by: Alex Deucher
fbdev is in drm-misc, so maybe you can push this one too?
-Daniel
>
> > ---
> > drivers/video/fbdev/efifb.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
> > index f58a545b3bf3..8ea8f079cde2 100644
> > --- a/drivers/video/fbdev/efifb.c
> > +++ b/drivers/video/fbdev/efifb.c
> > @@ -575,7 +575,8 @@ static int efifb_probe(struct platform_device *dev)
> > goto err_fb_dealoc;
> > }
> > fb_info(info, "%s frame buffer device\n", info->fix.id);
> > - pm_runtime_get_sync(_pci_dev->dev);
> > + if (efifb_pci_dev)
> > + pm_runtime_get_sync(_pci_dev->dev);
> > return 0;
> >
> > err_fb_dealoc:
> > @@ -602,7 +603,8 @@ static int efifb_remove(struct platform_device *pdev)
> > unregister_framebuffer(info);
> > sysfs_remove_groups(>dev.kobj, efifb_groups);
> > framebuffer_release(info);
> > - pm_runtime_put(_pci_dev->dev);
> > + if (efifb_pci_dev)
> > + pm_runtime_put(_pci_dev->dev);
> >
> > return 0;
> > }
> > --
> > 2.30.2
> >
> > _______
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH 0/8] drm/msm: Swappable GEM objects
On Mon, Apr 12, 2021 at 08:23:33AM -0700, Rob Clark wrote: > On Mon, Apr 12, 2021 at 7:28 AM Daniel Vetter wrote: > > > > On Thu, Apr 08, 2021 at 08:23:42AM -0700, Rob Clark wrote: > > > On Thu, Apr 8, 2021 at 4:15 AM Daniel Vetter wrote: > > > > > > > > On Mon, Apr 05, 2021 at 10:45:23AM -0700, Rob Clark wrote: > > > > > From: Rob Clark > > > > > > > > > > One would normally hope not to be under enough memory pressure to need > > > > > to swap GEM objects to disk backed swap. But memory backed zram swap > > > > > (as enabled on chromebooks, for example) can actually be quite fast > > > > > and useful on devices with less RAM. On a 4GB device, opening up ~4 > > > > > memory intensive web pages (in separate windows rather than tabs, to > > > > > try > > > > > and prevent tab discard), I see ~500MB worth of GEM objects, of which > > > > > maybe only 10% are active at any time, and with unpin/evict enabled, > > > > > only about half resident (which is a number that gets much lower if > > > > > you > > > > > simulate extreme memory pressure). Assuming a 2:1 compression ratio > > > > > (I > > > > > see a bit higher in practice, but cannot isolate swapped out GEM pages > > > > > vs other), that is like having an extra 100+MB of RAM, or more under > > > > > higher memory pressure. > > > > > > > > > > Rob Clark (8): > > > > > drm/msm: ratelimit GEM related WARN_ON()s > > > > > drm/msm: Reorganize msm_gem_shrinker_scan() > > > > > drm/msm: Clear msm_obj->sgt in put_pages() > > > > > drm/msm: Split iova purge and close > > > > > drm/msm: Add $debugfs/gem stats on resident objects > > > > > drm/msm: Track potentially evictable objects > > > > > drm/msm: Small msm_gem_purge() fix > > > > > drm/msm: Support evicting GEM objects to swap > > > > > > > > Given how much entertainement shrinkers are, should we aim for more > > > > common > > > > code here? > > > > > > > > Christian has tons of fun with adding something like this for ttm (well > > > > different shades of grey). i915 is going to adopt ttm, at least for > > > > discrete. > > > > > > > > The locking is also an utter pain, and msm seems to still live a lot in > > > > its own land here. I think as much as possible a standard approach here > > > > would be really good, ideally maybe as building blocks shared between > > > > ttm > > > > and gem-shmem drivers ... > > > > > > I don't disagree.. but also replacing the engines on an airplane > > > mid-flight isn't a great option either.. ;-) > > > > > > The hard part (esp. wrt to locking) is tracking the state of a given > > > bo.. ie. is it active, active+purgable, inactive+purgable, > > > inactive+unpinnable, etc. Currently the shmem helpers don't really > > > provide anything here. If they did, I suppose they could provide some > > > shrinker helpers as well. Unfortunately these days I barely have > > > enough time for drm/msm, let alone bolting this onto the shmem > > > helpers. I would recommend that if someone wanted to do this, that > > > they look at recent drm/msm shrinker patches that I've sent (ie. make > > > shrinker->count() lockless, and drop the locks in shrinker->scan() > > > body.. when the system is under heavy memory pressure, you start > > > getting shrinker called from all the threads so contention for mm_lock > > > can be a really bad problem) > > > > > > (Well, the other potential problem is that drm/msm has a lot of > > > different possible iommu pairings across the generations, so there is > > > some potential here to uncover exciting new bugs.. the locking at > > > least is the same for all the generations and pretty easy to test with > > > and without lockdep with some tests that push essentially all memory > > > into swap) > > > > So what we aimed for with i915 and discrete gpu is to first align on > > locking with dma_resv_lock for all buffer state, plus a bunch of > > lru/allocator locks for lists and stuff. > > > > And then with more aligned locking, figure out how to maybe share more > > code. > > > > The trouble is that right now neither shmem helpers, nor drivers using > >
Re: [PATCH 0/8] drm/msm: Swappable GEM objects
On Thu, Apr 08, 2021 at 08:23:42AM -0700, Rob Clark wrote: > On Thu, Apr 8, 2021 at 4:15 AM Daniel Vetter wrote: > > > > On Mon, Apr 05, 2021 at 10:45:23AM -0700, Rob Clark wrote: > > > From: Rob Clark > > > > > > One would normally hope not to be under enough memory pressure to need > > > to swap GEM objects to disk backed swap. But memory backed zram swap > > > (as enabled on chromebooks, for example) can actually be quite fast > > > and useful on devices with less RAM. On a 4GB device, opening up ~4 > > > memory intensive web pages (in separate windows rather than tabs, to try > > > and prevent tab discard), I see ~500MB worth of GEM objects, of which > > > maybe only 10% are active at any time, and with unpin/evict enabled, > > > only about half resident (which is a number that gets much lower if you > > > simulate extreme memory pressure). Assuming a 2:1 compression ratio (I > > > see a bit higher in practice, but cannot isolate swapped out GEM pages > > > vs other), that is like having an extra 100+MB of RAM, or more under > > > higher memory pressure. > > > > > > Rob Clark (8): > > > drm/msm: ratelimit GEM related WARN_ON()s > > > drm/msm: Reorganize msm_gem_shrinker_scan() > > > drm/msm: Clear msm_obj->sgt in put_pages() > > > drm/msm: Split iova purge and close > > > drm/msm: Add $debugfs/gem stats on resident objects > > > drm/msm: Track potentially evictable objects > > > drm/msm: Small msm_gem_purge() fix > > > drm/msm: Support evicting GEM objects to swap > > > > Given how much entertainement shrinkers are, should we aim for more common > > code here? > > > > Christian has tons of fun with adding something like this for ttm (well > > different shades of grey). i915 is going to adopt ttm, at least for > > discrete. > > > > The locking is also an utter pain, and msm seems to still live a lot in > > its own land here. I think as much as possible a standard approach here > > would be really good, ideally maybe as building blocks shared between ttm > > and gem-shmem drivers ... > > I don't disagree.. but also replacing the engines on an airplane > mid-flight isn't a great option either.. ;-) > > The hard part (esp. wrt to locking) is tracking the state of a given > bo.. ie. is it active, active+purgable, inactive+purgable, > inactive+unpinnable, etc. Currently the shmem helpers don't really > provide anything here. If they did, I suppose they could provide some > shrinker helpers as well. Unfortunately these days I barely have > enough time for drm/msm, let alone bolting this onto the shmem > helpers. I would recommend that if someone wanted to do this, that > they look at recent drm/msm shrinker patches that I've sent (ie. make > shrinker->count() lockless, and drop the locks in shrinker->scan() > body.. when the system is under heavy memory pressure, you start > getting shrinker called from all the threads so contention for mm_lock > can be a really bad problem) > > (Well, the other potential problem is that drm/msm has a lot of > different possible iommu pairings across the generations, so there is > some potential here to uncover exciting new bugs.. the locking at > least is the same for all the generations and pretty easy to test with > and without lockdep with some tests that push essentially all memory > into swap) So what we aimed for with i915 and discrete gpu is to first align on locking with dma_resv_lock for all buffer state, plus a bunch of lru/allocator locks for lists and stuff. And then with more aligned locking, figure out how to maybe share more code. The trouble is that right now neither shmem helpers, nor drivers using them, are really using dma_resv_lock to protect their per-buffer state. So yeah it's a bit an awkward situation, and I don't know myself really how to get out of it. Lack of people with tons of free time doesn't help much. So best case I think is that every time we touch helpers or drivers locking in a big way, we check whether it's at least slightly going towards dma_resv_lock or not. And at least make sure we're not going backwards, and maybe not spin wheels at standstill. I guess my question is, what would be good to have to make sure we at least all agree on the overall direction? -Daniel > > BR, > -R > > > -Daniel > > > > > > > > drivers/gpu/drm/msm/msm_drv.c | 2 +- > > > drivers/gpu/drm/msm/msm_drv.h | 13 ++- > > > drivers/gpu/drm/msm/msm_gem.c | 155 + > > > drivers/gpu/drm/msm/msm_gem.h | 68 +-- > &g
Re: [PATCH] vt_ioctl: make VT_RESIZEX behave like VT_RESIZE
On Mon, Apr 12, 2021 at 12:15 AM Linus Torvalds
wrote:
>
> On Sun, Apr 11, 2021 at 2:43 PM Maciej W. Rozycki wrote:
> >
> > So it does trigger with vgacon and my old server, which I have started
> > experimenting with and for a start I have switched to a new kernel for an
> > unrelated purpose (now that I have relieved it from all its usual tasks
> > except for the last remaining one for which I haven't got the required
> > user software ported to the new system yet):
> >
> > "struct vt_consize"->v_vlin is ignored. Please report if you need this.
> > "struct vt_consize"->v_clin is ignored. Please report if you need this.
>
> Note that it's entirely possible that things continue to work well
> despite this warning. It's unclear to me from your email if you
> actually see any difference (and apparently you're not able to see it
> right now due to not being close to the machine).
Original search didn't turn up any users of VT_RESIZEX, this is the
first. And looking at the source code I think we could outright remove
support for VT_RESIZEX (but make it silent) and everything should keep
working:
/*
* ALWAYS do a VT_RESIZE, even if we already did a VT_RESIZEX
on a 1.3.3 or higher kernel,
* until those kernel programmers make this unambiguous
*/
if (do_VT_RESIZE(curr_textmode->cols, curr_textmode->rows,
resize1x1)) sresize=TRUE;
if (check_kernel_version(1,3,3, "VT_RESIZEX"))
{
/*
* VDisplay must de divided by 2 for DoubleScan modes,
* or VT_RESIZEX will fail -- until someone fixes the kernel
* so it understands about doublescan modes.
*/
if (do_VT_RESIZEX(curr_textmode->cols,
curr_textmode->rows,
curr_textmode->VDisplay /
(MOFLG_ISSET(curr_textmode, ATTR_DOUBLESCAN) ? 2 : 1),
curr_textmode->FontHeight,
curr_textmode->HDisplay/8*curr_textmode->FontWidth,
curr_textmode->FontWidth, resize1x1)) sresize=TRUE;
}
The functions are just straightforward wrappers. There's also no cvs
repo, changelog or old releases before 2000 that would shed some light
on why this code even exists.
I think we can just tune down the pr_info_once to pr_debug and done.
Maybe a comment about where the single user we're aware of is.
-Daniel
>
> The fact that v_vlin/v_clin are ignored doesn't necessarily mean that
> they are different from what they were before, so the warning may be a
> non-issue.
>
> > It continues using svgatextmode with its glass (CRT) VT to set my usual
> > 80x37 text mode (720x576 pixel resolution) by manipulating the VGA clock
> > chip and the CRT controller appropriately for a nice refresh rate of 85Hz:
> >
> > Chipset = `TVGA8900', Textmode clock = 44.90 MHz, 80x37 chars, CharCell =
> > 9x16. Refresh = 52.51kHz/84.7Hz.
>
> That doesn't seem necessarily wrong to me.
>
> > So what's the supposed impact of this change that prompted the inclusion
> > of the messages?
>
> There _may_ be no impact at all apart from the messages.
>
> The code _used_ to set the scan lines (v_vlin) and font height
> (v_clin) from those numbers if they were non-zero, and now it just
> ignores them and warns instead.
>
> The code now just sets the font height from the actual font size when
> the font is set. Which is honestly the only thing that ever made
> sense. Trying to set it with v_clin is ignored, but it's entirely
> possible - maybe even likely - that your user of VT_RESIZEX sets it to
> the same values it already has.
>
> Exactly because setting a font line number to anything else than the
> font size isn't exactly sensible.
>
> But if your screen looks different than it used to, that is obviously
> interesting and says something actually changed (outside of the
> message itself).
>
>Linus
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH 3/3] mm: unexport follow_pfn
On Thu, Apr 08, 2021 at 01:40:59PM +0200, Paolo Bonzini wrote:
> On 08/04/21 12:05, Daniel Vetter wrote:
> > On Mon, Mar 29, 2021 at 10:31:01AM -0300, Jason Gunthorpe wrote:
> > > On Tue, Mar 16, 2021 at 04:33:03PM +0100, Daniel Vetter wrote:
> > > > Both kvm (in bd2fae8da794 ("KVM: do not assume PTE is writable after
> > > > follow_pfn")) and vfio (in 07956b6269d3 ("vfio/type1: Use
> > > > follow_pte()")) have lost their callsites of follow_pfn(). All the
> > > > other ones have been switched over to unsafe_follow_pfn because they
> > > > cannot be fixed without breaking userspace api.
> > > >
> > > > Argueably the vfio code is still racy, but that's kinda a bigger
> > >
> > > vfio and kvm
> >
> > Hm I thought kvm is non-racy due to the mmu notifier catch races?
>
> No, but the plan is indeed to have some struct for each page that uses
> follow_pfn and update it from the MMU notifiers.
Thanks for clarifying, I've fixed the commit message to mention both vfio
and kvm as Jason suggested. I didn't know that the follow_pte usage in kvm
still has some gaps wrt what's invalidated with mmu notifiers.
Thanks, Daniel
>
> Paolo
>
> > >
> > > > picture. But since it does leak the pte beyond where it drops the pt
> > > > lock, without anything else like an mmu notifier guaranteeing
> > > > coherence, the problem is at least clearly visible in the vfio code.
> > > > So good enough with me.
> > > >
> > > > I've decided to keep the explanation that after dropping the pt lock
> > > > you must have an mmu notifier if you keep using the pte somehow by
> > > > adjusting it and moving it into the kerneldoc for the new follow_pte()
> > > > function.
> > > >
> > > > Cc: 3...@google.com
> > > > Cc: Jann Horn
> > > > Cc: Paolo Bonzini
> > > > Cc: Jason Gunthorpe
> > > > Cc: Cornelia Huck
> > > > Cc: Peter Xu
> > > > Cc: Alex Williamson
> > > > Cc: linux...@kvack.org
> > > > Cc: linux-arm-ker...@lists.infradead.org
> > > > Cc: linux-samsung-...@vger.kernel.org
> > > > Cc: linux-me...@vger.kernel.org
> > > > Cc: k...@vger.kernel.org
> > > > Signed-off-by: Daniel Vetter
> > > > ---
> > > > include/linux/mm.h | 2 --
> > > > mm/memory.c| 26 +-
> > > > mm/nommu.c | 13 +
> > > > 3 files changed, 6 insertions(+), 35 deletions(-)
> > >
> > > Reviewed-by: Jason Gunthorpe
> >
> > Thanks for your r-b tags, I'll add them.
> > -Daniel
> >
> > >
> > > Jason
> >
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH] drm/syncobj: use newly allocated stub fences
+ if (flags & DRM_SYNCOBJ_CREATE_SIGNALED) {
> + ret = drm_syncobj_assign_null_handle(syncobj);
> + if (ret < 0) {
> + drm_syncobj_put(syncobj);
> + return ret;
> + }
> + }
>
> if (fence)
> drm_syncobj_replace_fence(syncobj, fence);
> @@ -1322,8 +1331,11 @@ drm_syncobj_signal_ioctl(struct drm_device *dev, void
> *data,
> if (ret < 0)
> return ret;
>
> - for (i = 0; i < args->count_handles; i++)
> - drm_syncobj_assign_null_handle(syncobjs[i]);
> + for (i = 0; i < args->count_handles; i++) {
> + ret = drm_syncobj_assign_null_handle(syncobjs[i]);
> + if (ret < 0)
> + break;
> + }
>
> drm_syncobj_array_free(syncobjs, args->count_handles);
>
> diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
> index 9f12efaaa93a..6ffb4b2c6371 100644
> --- a/include/linux/dma-fence.h
> +++ b/include/linux/dma-fence.h
> @@ -587,6 +587,7 @@ static inline signed long dma_fence_wait(struct dma_fence
> *fence, bool intr)
> }
>
> struct dma_fence *dma_fence_get_stub(void);
> +struct dma_fence *dma_fence_allocate_private_stub(void);
> u64 dma_fence_context_alloc(unsigned num);
>
> #define DMA_FENCE_TRACE(f, fmt, args...) \
> --
> 2.31.0.208.g409f899ff0-goog
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv
On Thu, Apr 08, 2021 at 12:20:50PM +0200, Arnd Bergmann wrote: > On Thu, Apr 8, 2021 at 11:22 AM David Hildenbrand wrote: > > > > Random drivers should not override a user configuration of core knobs > > (e.g., CONFIG_DMA_CMA=n). Use "imply" instead, to still respect > > dependencies and manual overrides. > > > > "This is similar to "select" as it enforces a lower limit on another > > symbol except that the "implied" symbol's value may still be set to n > > from a direct dependency or with a visible prompt." > > > > Implying DRM_CMA should be sufficient, as that depends on CMA. > > > > Note: If this is a real dependency, we should use "depends on DMA_CMA" > > instead - but I assume the driver can work without CMA just fine -- > > esp. when we wouldn't have HAVE_DMA_CONTIGUOUS right now. > > 'imply' is almost never the right solution, and it tends to cause more > problems than it solves. > > In particular, it does not prevent a configuration with 'DRM_CMA=m' > and 'DRMA_ASPEED_GFX=y', or any build failures from such > a configuration. > > If you want this kind of soft dependency, you need > 'depends on DRM_CMA || !DRM_CMA'. The problem is that depends on is a real pain for users to find their drivers. This is why we have a ton of select, because the kconfig ui tends to suck. If you want to change this, we need automatic conflict resolution like apt and other package managers have, with suggestions how to fix the config if you want to enable a driver, but some of its requirements are missing. The current approach of hiding driver symbols complete if any of their dependencies are off is really not great. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH -next] gma500: Use DEFINE_SPINLOCK() for spinlock
On Tue, Apr 06, 2021 at 07:55:14PM +0800, Huang Guobin wrote: > From: Guobin Huang > > spinlock can be initialized automatically with DEFINE_SPINLOCK() > rather than explicitly calling spin_lock_init(). > > Reported-by: Hulk Robot > Signed-off-by: Guobin Huang Applied to drm-misc-next, thanks for your patch. -Daniel > --- > drivers/gpu/drm/gma500/power.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/gma500/power.c b/drivers/gpu/drm/gma500/power.c > index 56ef88237ef6..f07641dfa5a4 100644 > --- a/drivers/gpu/drm/gma500/power.c > +++ b/drivers/gpu/drm/gma500/power.c > @@ -36,7 +36,7 @@ > #include > > static struct mutex power_mutex; /* Serialize power ops */ > -static spinlock_t power_ctrl_lock; /* Serialize power claim */ > +static DEFINE_SPINLOCK(power_ctrl_lock); /* Serialize power claim */ > > /** > * gma_power_init - initialise power manager > @@ -55,7 +55,6 @@ void gma_power_init(struct drm_device *dev) > dev_priv->display_power = true; /* We start active */ > dev_priv->display_count = 0;/* Currently no users */ > dev_priv->suspended = false;/* And not suspended */ > - spin_lock_init(_ctrl_lock); > mutex_init(_mutex); > > if (dev_priv->ops->init_pm) > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH 0/8] drm/msm: Swappable GEM objects
On Mon, Apr 05, 2021 at 10:45:23AM -0700, Rob Clark wrote: > From: Rob Clark > > One would normally hope not to be under enough memory pressure to need > to swap GEM objects to disk backed swap. But memory backed zram swap > (as enabled on chromebooks, for example) can actually be quite fast > and useful on devices with less RAM. On a 4GB device, opening up ~4 > memory intensive web pages (in separate windows rather than tabs, to try > and prevent tab discard), I see ~500MB worth of GEM objects, of which > maybe only 10% are active at any time, and with unpin/evict enabled, > only about half resident (which is a number that gets much lower if you > simulate extreme memory pressure). Assuming a 2:1 compression ratio (I > see a bit higher in practice, but cannot isolate swapped out GEM pages > vs other), that is like having an extra 100+MB of RAM, or more under > higher memory pressure. > > Rob Clark (8): > drm/msm: ratelimit GEM related WARN_ON()s > drm/msm: Reorganize msm_gem_shrinker_scan() > drm/msm: Clear msm_obj->sgt in put_pages() > drm/msm: Split iova purge and close > drm/msm: Add $debugfs/gem stats on resident objects > drm/msm: Track potentially evictable objects > drm/msm: Small msm_gem_purge() fix > drm/msm: Support evicting GEM objects to swap Given how much entertainement shrinkers are, should we aim for more common code here? Christian has tons of fun with adding something like this for ttm (well different shades of grey). i915 is going to adopt ttm, at least for discrete. The locking is also an utter pain, and msm seems to still live a lot in its own land here. I think as much as possible a standard approach here would be really good, ideally maybe as building blocks shared between ttm and gem-shmem drivers ... -Daniel > > drivers/gpu/drm/msm/msm_drv.c | 2 +- > drivers/gpu/drm/msm/msm_drv.h | 13 ++- > drivers/gpu/drm/msm/msm_gem.c | 155 + > drivers/gpu/drm/msm/msm_gem.h | 68 +-- > drivers/gpu/drm/msm/msm_gem_shrinker.c | 129 > drivers/gpu/drm/msm/msm_gpu_trace.h| 13 +++ > 6 files changed, 272 insertions(+), 108 deletions(-) > > -- > 2.30.2 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] drm/drm_internal.h: Remove repeated struct declaration
On Thu, Apr 01, 2021 at 04:17:03PM +0800, Wan Jiabing wrote: > struct drm_gem_object is declared twice. One is declared > at 40th line. The blew one is not needed. Remove the duplicate. > > Signed-off-by: Wan Jiabing Pushed to drm-misc-next, thanks for your patch. -Daniel > --- > drivers/gpu/drm/drm_internal.h | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h > index fad2249ee67b..1265de2b9d90 100644 > --- a/drivers/gpu/drm/drm_internal.h > +++ b/drivers/gpu/drm/drm_internal.h > @@ -170,7 +170,6 @@ void drm_sysfs_connector_remove(struct drm_connector > *connector); > void drm_sysfs_lease_event(struct drm_device *dev); > > /* drm_gem.c */ > -struct drm_gem_object; > int drm_gem_init(struct drm_device *dev); > int drm_gem_handle_create_tail(struct drm_file *file_priv, > struct drm_gem_object *obj, > -- > 2.25.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: linux-next: build warning after merge of the drm-intel-fixes tree
On Mon, Mar 29, 2021 at 09:23:35PM +0300, Imre Deak wrote:
> Hi Stephen,
>
> thanks for the report.
>
> On Mon, Mar 29, 2021 at 09:01:17AM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > On Fri, 26 Mar 2021 19:58:38 +1100 Stephen Rothwell
> > wrote:
> > >
> > > After merging the drm-intel-fixes tree, today's linux-next build
> > > (htmldocs) produced this warning:
> > >
> > > Documentation/gpu/i915:22: /drivers/gpu/drm/i915/intel_runtime_pm.c:423:
> > > WARNING: Inline strong start-string without end-string.
>
> The problem seems to be the
>
> @ignore_usecount=true
>
> part in __intel_runtime_pm_get_if_active()'s docbook documentation. I
> can't see the problem with it, it was meant as a reference to the
> function parameter, granted I'm not sure what's the proper markup syntax
> for this.
>
> I will follow up with the following change which suppresses the warning
> and renders the html as expected unless someone can suggest a better
> way:
>
> - * If @ignore_usecount=true, a reference will be acquired even if there is no
> + * If @ignore_usecount is true, a reference will be acquired even if there
> is no
Yeah you can't just use most pseudo-code in kerneldoc because it's
interpreted as raw .rst. So would need some .rst quoting of some sorts to
make it render correctly.
Usually for pseudo-code I go with blockquotes (started with :: at the end
of the previous line, plus indenting), that gives you also a nice
fixed-width font and everything.
Aside from the hyperlink stuff plain English works best in the text parts.
-Daniel
>
> --Imre
>
> > >
> > > Introduced by commit
> > >
> > > 8840e3bd981f ("drm/i915: Fix the GT fence revocation runtime PM logic")
> >
> > This warning now exists in Linus' tree.
> >
> > --
> > Cheers,
> > Stephen Rothwell
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH 3/3] mm: unexport follow_pfn
On Mon, Mar 29, 2021 at 10:31:01AM -0300, Jason Gunthorpe wrote:
> On Tue, Mar 16, 2021 at 04:33:03PM +0100, Daniel Vetter wrote:
> > Both kvm (in bd2fae8da794 ("KVM: do not assume PTE is writable after
> > follow_pfn")) and vfio (in 07956b6269d3 ("vfio/type1: Use
> > follow_pte()")) have lost their callsites of follow_pfn(). All the
> > other ones have been switched over to unsafe_follow_pfn because they
> > cannot be fixed without breaking userspace api.
> >
> > Argueably the vfio code is still racy, but that's kinda a bigger
>
> vfio and kvm
Hm I thought kvm is non-racy due to the mmu notifier catch races?
>
> > picture. But since it does leak the pte beyond where it drops the pt
> > lock, without anything else like an mmu notifier guaranteeing
> > coherence, the problem is at least clearly visible in the vfio code.
> > So good enough with me.
> >
> > I've decided to keep the explanation that after dropping the pt lock
> > you must have an mmu notifier if you keep using the pte somehow by
> > adjusting it and moving it into the kerneldoc for the new follow_pte()
> > function.
> >
> > Cc: 3...@google.com
> > Cc: Jann Horn
> > Cc: Paolo Bonzini
> > Cc: Jason Gunthorpe
> > Cc: Cornelia Huck
> > Cc: Peter Xu
> > Cc: Alex Williamson
> > Cc: linux...@kvack.org
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux-samsung-...@vger.kernel.org
> > Cc: linux-me...@vger.kernel.org
> > Cc: k...@vger.kernel.org
> > Signed-off-by: Daniel Vetter
> > ---
> > include/linux/mm.h | 2 --
> > mm/memory.c| 26 +++++-
> > mm/nommu.c | 13 +
> > 3 files changed, 6 insertions(+), 35 deletions(-)
>
> Reviewed-by: Jason Gunthorpe
Thanks for your r-b tags, I'll add them.
-Daniel
>
> Jason
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH 3/3] mm: unexport follow_pfn
On Wed, Mar 24, 2021 at 08:17:10PM +0100, Daniel Vetter wrote:
> On Wed, Mar 24, 2021 at 09:52:11AM -0300, Jason Gunthorpe wrote:
> > On Tue, Mar 16, 2021 at 04:33:03PM +0100, Daniel Vetter wrote:
> > > Both kvm (in bd2fae8da794 ("KVM: do not assume PTE is writable after
> > > follow_pfn")) and vfio (in 07956b6269d3 ("vfio/type1: Use
> > > follow_pte()")) have lost their callsites of follow_pfn(). All the
> > > other ones have been switched over to unsafe_follow_pfn because they
> > > cannot be fixed without breaking userspace api.
> > >
> > > Argueably the vfio code is still racy, but that's kinda a bigger
> > > picture. But since it does leak the pte beyond where it drops the pt
> > > lock, without anything else like an mmu notifier guaranteeing
> > > coherence, the problem is at least clearly visible in the vfio code.
> > > So good enough with me.
> > >
> > > I've decided to keep the explanation that after dropping the pt lock
> > > you must have an mmu notifier if you keep using the pte somehow by
> > > adjusting it and moving it into the kerneldoc for the new follow_pte()
> > > function.
> > >
> > > Cc: 3...@google.com
> > > Cc: Jann Horn
> > > Cc: Paolo Bonzini
> > > Cc: Jason Gunthorpe
> > > Cc: Cornelia Huck
> > > Cc: Peter Xu
> > > Cc: Alex Williamson
> > > Cc: linux...@kvack.org
> > > Cc: linux-arm-ker...@lists.infradead.org
> > > Cc: linux-samsung-...@vger.kernel.org
> > > Cc: linux-me...@vger.kernel.org
> > > Cc: k...@vger.kernel.org
> > > Signed-off-by: Daniel Vetter
> > > ---
> > > include/linux/mm.h | 2 --
> > > mm/memory.c| 26 +-
> > > mm/nommu.c | 13 +
> > > 3 files changed, 6 insertions(+), 35 deletions(-)
> >
> > I think this is the right thing to do.
>
> Was just about to smash this into the topic branch for testing in
> linux-next. Feel like an ack on the series, or at least the two mm
> patches?
Pushed them to my topic branch for a bit of testing in linux-next,
hopefully goes all fine for a pull for 5.13.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [RFC PATCH 1/2] mm,drm/ttm: Block fast GUP to TTM huge pages
d allocate enough page > > table entries to consume it, regardless of alignment. > > Completely agree with Jason. Filling in the CPU page tables is > relatively cheap if you fill in a large continuous range. > > In other words filling in 1GiB of a linear range is *much* less overhead > than filling in 1<<18 4KiB faults. > > I would say that this is always preferable even if the CPU only wants to > update a single byte. > > > And why shouldn't DAX switch to this kind of interface anyhow? It is > > basically exactly the same problem. The underlying filesystem block > > size is *not* necessarily aligned to the CPU page table sizes and DAX > > would benefit from better handling of this mismatch. > > > >> On top of this, unless we want to do the walk trying increasingly smaller > >> sizes of vmf_insert_xxx(), we'd have to use apply_to_page_range() and teach > >> it about transhuge page table entries, because pagewalk.c can't be used (It > >> can't populate page tables). That also means apply_to_page_range() needs to > >> be complicated with page table locks since transhuge pages aren't stable > >> and > >> can be zapped and refaulted under us while we do the walk. > > I didn't say it would be simple :) But we also need to stop hacking > > around the sides of all this huge page stuff and come up with sensible > > APIs that drivers can actually implement correctly. Exposing drivers > > to specific kinds of page levels really feels like the wrong level of > > abstraction. > > > > Once we start doing this we should do it everywhere, the io_remap_pfn > > stuff should be able to create huge special IO pages as well, for > > instance. > > Oh, yes please! > > We easily have 16GiB of VRAM which is linear mapped into the kernel > space for each GPU instance. > > Doing that with 1GiB mapping instead of 4KiB would be quite a win. io_remap_pfn is for userspace mmaps. Kernel mappings should be as big as possible already I think for everything. -Daniel > Regards, > Christian. > > > > >> On top of this, the user-space address allocator needs to know how large > >> gpu > >> pages are aligned in buffer objects to have a reasonable chance of aligning > >> with CPU huge page boundaries which is a requirement to be able to insert a > >> huge CPU page table entry, so the driver would basically need the drm > >> helper > >> that can do this alignment anyway. > > Don't you have this problem anyhow? > > > > Jason > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] drivers: gpu: drm: xen_drm_front_drm_info is declared twice
On Thu, Mar 25, 2021 at 10:16 AM Daniel Vetter wrote: > > On Thu, Mar 25, 2021 at 7:53 AM Oleksandr Andrushchenko > wrote: > > > > Hi, > > > > On 3/25/21 8:19 AM, Wan Jiabing wrote: > > > struct xen_drm_front_drm_info has been declared. > > > Remove the duplicate. > > > > > > Signed-off-by: Wan Jiabing > > > > Thank you for the patch, > > > > Reviewed-by: Oleksandr Andrushchenko > > > > Will apply to drm-misc-next-fixes > > drm-misc-next-fixes is the wrong tree, bugfixes outside of the merge > window belong into drm-misc-fixes. Please consult > > https://drm.pages.freedesktop.org/maintainer-tools/committer-drm-misc.html#where-do-i-apply-my-patch > > We need to hard-reset drm-misc-next-fixes back, please re-apply the > patches (both of them) to drm-misc-fixes. Also adding drm-misc > maintainers. Also simple cleanup like this should be pushed to drm-misc-next, not any of the -fixes branches. -Daniel > -Daniel > > > > > Thank you, > > > > Oleksandr > > > > > --- > > > drivers/gpu/drm/xen/xen_drm_front_conn.h | 1 - > > > 1 file changed, 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/xen/xen_drm_front_conn.h > > > b/drivers/gpu/drm/xen/xen_drm_front_conn.h > > > index 3adacba9a23b..e5f4314899ee 100644 > > > --- a/drivers/gpu/drm/xen/xen_drm_front_conn.h > > > +++ b/drivers/gpu/drm/xen/xen_drm_front_conn.h > > > @@ -16,7 +16,6 @@ > > > struct drm_connector; > > > struct xen_drm_front_drm_info; > > > > > > -struct xen_drm_front_drm_info; > > > > > > int xen_drm_front_conn_init(struct xen_drm_front_drm_info *drm_info, > > > struct drm_connector *connector); > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] drivers: gpu: drm: xen_drm_front_drm_info is declared twice
On Thu, Mar 25, 2021 at 7:53 AM Oleksandr Andrushchenko wrote: > > Hi, > > On 3/25/21 8:19 AM, Wan Jiabing wrote: > > struct xen_drm_front_drm_info has been declared. > > Remove the duplicate. > > > > Signed-off-by: Wan Jiabing > > Thank you for the patch, > > Reviewed-by: Oleksandr Andrushchenko > > Will apply to drm-misc-next-fixes drm-misc-next-fixes is the wrong tree, bugfixes outside of the merge window belong into drm-misc-fixes. Please consult https://drm.pages.freedesktop.org/maintainer-tools/committer-drm-misc.html#where-do-i-apply-my-patch We need to hard-reset drm-misc-next-fixes back, please re-apply the patches (both of them) to drm-misc-fixes. Also adding drm-misc maintainers. -Daniel > > Thank you, > > Oleksandr > > > --- > > drivers/gpu/drm/xen/xen_drm_front_conn.h | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/xen/xen_drm_front_conn.h > > b/drivers/gpu/drm/xen/xen_drm_front_conn.h > > index 3adacba9a23b..e5f4314899ee 100644 > > --- a/drivers/gpu/drm/xen/xen_drm_front_conn.h > > +++ b/drivers/gpu/drm/xen/xen_drm_front_conn.h > > @@ -16,7 +16,6 @@ > > struct drm_connector; > > struct xen_drm_front_drm_info; > > > > -struct xen_drm_front_drm_info; > > > > int xen_drm_front_conn_init(struct xen_drm_front_drm_info *drm_info, > > struct drm_connector *connector); -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH 3/3] mm: unexport follow_pfn
On Wed, Mar 24, 2021 at 09:52:11AM -0300, Jason Gunthorpe wrote:
> On Tue, Mar 16, 2021 at 04:33:03PM +0100, Daniel Vetter wrote:
> > Both kvm (in bd2fae8da794 ("KVM: do not assume PTE is writable after
> > follow_pfn")) and vfio (in 07956b6269d3 ("vfio/type1: Use
> > follow_pte()")) have lost their callsites of follow_pfn(). All the
> > other ones have been switched over to unsafe_follow_pfn because they
> > cannot be fixed without breaking userspace api.
> >
> > Argueably the vfio code is still racy, but that's kinda a bigger
> > picture. But since it does leak the pte beyond where it drops the pt
> > lock, without anything else like an mmu notifier guaranteeing
> > coherence, the problem is at least clearly visible in the vfio code.
> > So good enough with me.
> >
> > I've decided to keep the explanation that after dropping the pt lock
> > you must have an mmu notifier if you keep using the pte somehow by
> > adjusting it and moving it into the kerneldoc for the new follow_pte()
> > function.
> >
> > Cc: 3...@google.com
> > Cc: Jann Horn
> > Cc: Paolo Bonzini
> > Cc: Jason Gunthorpe
> > Cc: Cornelia Huck
> > Cc: Peter Xu
> > Cc: Alex Williamson
> > Cc: linux...@kvack.org
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux-samsung-...@vger.kernel.org
> > Cc: linux-me...@vger.kernel.org
> > Cc: k...@vger.kernel.org
> > Signed-off-by: Daniel Vetter
> > ---
> > include/linux/mm.h | 2 --
> > mm/memory.c| 26 +-
> > mm/nommu.c | 13 +
> > 3 files changed, 6 insertions(+), 35 deletions(-)
>
> I think this is the right thing to do.
Was just about to smash this into the topic branch for testing in
linux-next. Feel like an ack on the series, or at least the two mm
patches?
-Daniel
>
> Alex is working on fixing VFIO and while kvm is still racy using
> follow pte, I think they are working on it too?
>
> Jason
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH] i915_vma: Rename vma_lookup to i915_vma_lookup
On Tue, Mar 23, 2021 at 01:42:21PM +, Liam Howlett wrote:
> Use i915 prefix to avoid name collision with future vma_lookup() in mm.
>
> Signed-off-by: Liam R. Howlett
> Reviewed-by: Matthew Wilcox (Oracle)
Applied to i915-gem-next branch for 5.13. We have a bit a branch shuffling
going on right now so unusal path, it should show up in linux-next through
drm-next hopefully this week still.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_vma.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
> index caa9b041616b..ee0028c697f6 100644
> --- a/drivers/gpu/drm/i915/i915_vma.c
> +++ b/drivers/gpu/drm/i915/i915_vma.c
> @@ -230,7 +230,7 @@ vma_create(struct drm_i915_gem_object *obj,
> }
>
> static struct i915_vma *
> -vma_lookup(struct drm_i915_gem_object *obj,
> +i915_vma_lookup(struct drm_i915_gem_object *obj,
> struct i915_address_space *vm,
> const struct i915_ggtt_view *view)
> {
> @@ -278,7 +278,7 @@ i915_vma_instance(struct drm_i915_gem_object *obj,
> GEM_BUG_ON(!atomic_read(>open));
>
> spin_lock(>vma.lock);
> - vma = vma_lookup(obj, vm, view);
> + vma = i915_vma_lookup(obj, vm, view);
> spin_unlock(>vma.lock);
>
> /* vma_create() will resolve the race if another creates the vma */
> --
> 2.30.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [RFC PATCH 1/2] mm,drm/ttm: Block fast GUP to TTM huge pages
On Tue, Mar 23, 2021 at 09:42:18PM +0100, Thomas Hellström (Intel) wrote:
>
> On 3/23/21 8:52 PM, Williams, Dan J wrote:
> > On Sun, 2021-03-21 at 19:45 +0100, Thomas Hellström (Intel) wrote:
> > > TTM sets up huge page-table-entries both to system- and device
> > > memory,
> > > and we don't want gup to assume there are always valid backing struct
> > > pages for these. For PTEs this is handled by setting the pte_special
> > > bit,
> > > but for the huge PUDs and PMDs, we have neither pmd_special nor
> > > pud_special. Normally, huge TTM entries are identified by looking at
> > > vma_is_special_huge(), but fast gup can't do that, so as an
> > > alternative
> > > define _devmap entries for which there are no backing dev_pagemap as
> > > special, update documentation and make huge TTM entries _devmap,
> > > after
> > > verifying that there is no backing dev_pagemap.
> > Please do not abuse p{m,u}d_devmap like this. I'm in the process of
> > removing get_devpagemap() from the gup-fast path [1]. Instead there
> > should be space for p{m,u}d_special in the page table entries (at least
> > for x86-64). So the fix is to remove that old assumption that huge
> > pages can never be special.
> >
> > [1]:
> > http://lore.kernel.org/r/161604050866.1463742.7759521510383551055.st...@dwillia2-desk3.amr.corp.intel.com
> >
> Hmm, yes with that patch it will obviously not work as intended.
>
> Given that, I think we'll need to disable the TTM huge pages for now until
> we can sort out and agree on using a page table entry bit.
Yeah :-/
I think going full pud/pmd_mkspecial should then also mesh well with
Jason's request to wrap it all up into a vmf_insert_* helper, so at least
it would all look rather pretty in the end.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [RFC PATCH 1/2] mm,drm/ttm: Block fast GUP to TTM huge pages
On Tue, Mar 23, 2021 at 06:06:53PM +0100, Thomas Hellström (Intel) wrote: > > On 3/23/21 5:37 PM, Jason Gunthorpe wrote: > > On Tue, Mar 23, 2021 at 05:34:51PM +0100, Thomas Hellström (Intel) wrote: > > > > > > > @@ -210,6 +211,20 @@ static vm_fault_t ttm_bo_vm_insert_huge(struct > > > > > vm_fault *vmf, > > > > > if ((pfn & (fault_page_size - 1)) != 0) > > > > > goto out_fallback; > > > > > + /* > > > > > + * Huge entries must be special, that is marking them as devmap > > > > > + * with no backing device map range. If there is a backing > > > > > + * range, Don't insert a huge entry. > > > > > + * If this check turns out to be too much of a performance hit, > > > > > + * we can instead have drivers indicate whether they may have > > > > > + * backing device map ranges and if not, skip this lookup. > > > > > + */ > > > > I think we can do this statically: > > > > - if it's system memory we know there's no devmap for it, and we do the > > > > trick to block gup_fast > > > Yes, that should work. > > > > - if it's iomem, we know gup_fast wont work anyway if don't set PFN_DEV, > > > > so might as well not do that > > > I think gup_fast will unfortunately mistake a huge iomem page for an > > > ordinary page and try to access a non-existant struct page for it, unless > > > we > > > do the devmap trick. > > > > > > And the lookup would then be for the rare case where a driver would have > > > already registered a dev_pagemap for an iomem area which may also be > > > mapped > > > through TTM (like the patch from Felix a couple of weeks ago). If a driver > > > can promise not to do that, then we can safely remove the lookup. > > Isn't the devmap PTE flag arch optional? Does this fall back to not > > using huge pages on arches that don't support it? > > Good point. No, currently it's only conditioned on transhuge page support. > Need to condition it on also devmap support. > > > > > Also, I feel like this code to install "pte_special" huge pages does > > not belong in the drm subsystem.. > > I could add helpers in huge_memory.c: > > vmf_insert_pfn_pmd_prot_special() and > vmf_insert_pfn_pud_prot_special() The somewhat annoying thing is that we'd need an error code so we fall back to pte fault handling. That's at least my understanding of how pud/pmd fault handling works. Not sure how awkward that is going to be with the overall fault handling flow. But aside from that I think this makes tons of sense. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH v2 1/3] drm: bridge/panel: Cleanup connector on bridge detach
On Wed, Mar 24, 2021 at 04:15:37AM +0200, Laurent Pinchart wrote:
> On Wed, Jan 20, 2021 at 06:38:03PM +0100, Daniel Vetter wrote:
> > On Wed, Jan 20, 2021 at 6:12 PM Paul Cercueil wrote:
> > > Le mer. 20 janv. 2021 à 17:03, Daniel Vetter a écrit :
> > > > On Wed, Jan 20, 2021 at 1:35 PM Paul Cercueil wrote:
> > > >>
> > > >> If we don't call drm_connector_cleanup() manually in
> > > >> panel_bridge_detach(), the connector will be cleaned up with the other
> > > >> DRM objects in the call to drm_mode_config_cleanup(). However, since
> > > >> our
> > > >> drm_connector is devm-allocated, by the time drm_mode_config_cleanup()
> > > >> will be called, our connector will be long gone. Therefore, the
> > > >> connector must be cleaned up when the bridge is detached to avoid
> > > >> use-after-free conditions.
> > > >
> > > > For -fixes this sounds ok, but for -next I think switching to drmm_
> > > > would be much better.
> > >
> > > The API would need to change to have access to the drm_device struct,
> > > though. That would be quite a big patch, there are a few dozens source
> > > files that use this API already.
> >
> > Hm right pure drmm_ doesn't work for panel or bridge since it's
> > usually a separate driver. But devm_ also doesn't work. I think what
> > we need here is two-stage: first kmalloc the panel (or bridge, it's
> > really the same) in the panel/bridge driver load. Then when we bind it
> > to the drm_device we can tie it into the managed resources with
> > drmm_add_action_or_reset. Passing the drm_device to the point where we
> > allocate the panel/bridge doesn't work for these.
> >
> > I think minimally we need a FIXME here and ack from Laurent on how
> > this should be solved at least, since panel bridge is used rather
> > widely.
>
> Bridge removal is completely broken. If you unbind a bridge driver from
> the device, the bridge will be unregistered and resources freed, without
> the display driver knowing about this. The lifetime of the drm_bridge
> structure itself isn't the only issue to be addressed here, it's broader
> than that, and needs to consider that the display driver could be
> calling the bridge operations concurrently to the removal.
So for the "unloading bridge should first unload display" problem that was
supposed to get fixed with device links. There was at least a patch for
that, and I Rafel from pm side did all the core changes to make it work.
But it didn't land I think, so things keep on sucking.
Ofc the lifetime of the bridge structure is then an additional problem on
top here.
> We need a volunteer with enough motivation to solve this subsystem-wide
> :-) In the meantime, whatever shortcut addresses immediate issues is
> probably fine, as yak-shaving in this area would definitely not be
> reasonable.
I guess drm/bridge keeps on disappointing :-/
-Daniel
>
> > > >> v2: Cleanup connector only if it was created
> > > >>
> > > >> Fixes: 13dfc0540a57 ("drm/bridge: Refactor out the panel wrapper from
> > > >> the lvds-encoder bridge.")
> > > >> Cc: # 4.12+
> > > >> Cc: Andrzej Hajda
> > > >> Cc: Neil Armstrong
> > > >> Cc: Laurent Pinchart
> > > >> Cc: Jonas Karlman
> > > >> Cc: Jernej Skrabec
> > > >> Signed-off-by: Paul Cercueil
> > > >> ---
> > > >> drivers/gpu/drm/bridge/panel.c | 6 ++
> > > >> 1 file changed, 6 insertions(+)
> > > >>
> > > >> diff --git a/drivers/gpu/drm/bridge/panel.c
> > > >> b/drivers/gpu/drm/bridge/panel.c
> > > >> index 0ddc37551194..df86b0ee0549 100644
> > > >> --- a/drivers/gpu/drm/bridge/panel.c
> > > >> +++ b/drivers/gpu/drm/bridge/panel.c
> > > >> @@ -87,6 +87,12 @@ static int panel_bridge_attach(struct drm_bridge
> > > >> *bridge,
> > > >>
> > > >> static void panel_bridge_detach(struct drm_bridge *bridge)
> > > >> {
> > > >> + struct panel_bridge *panel_bridge =
> > > >> drm_bridge_to_panel_bridge(bridge);
> > > >> + struct drm_connector *connector = _bridge->connector;
> > > >> +
> > > >> + /* Cleanup the connector if we know it was initialized */
> > > >> + if (!!panel_bridge->connector.dev)
> > > >> + drm_connector_cleanup(connector);
> > > >> }
> > > >>
> > > >> static void panel_bridge_pre_enable(struct drm_bridge *bridge)
>
> --
> Regards,
>
> Laurent Pinchart
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [RFC PATCH 2/2] mm,drm/ttm: Use VM_PFNMAP for TTM vmas
On Sun, Mar 21, 2021 at 07:45:29PM +0100, Thomas Hellström (Intel) wrote:
> To block fast gup we need to make sure TTM ptes are always special.
> With MIXEDMAP we, on architectures that don't support pte_special,
> insert normal ptes, but OTOH on those architectures, fast is not
> supported.
> At the same time, the function documentation to vm_normal_page() suggests
> that ptes pointing to system memory pages of MIXEDMAP vmas are always
> normal, but that doesn't seem consistent with what's implemented in
> vmf_insert_mixed(). I'm thus not entirely sure this patch is actually
> needed.
>
> But to make sure and to avoid also normal (non-fast) gup, make all
> TTM vmas PFNMAP. With PFNMAP we can't allow COW mappings
> anymore so make is_cow_mapping() available and use it to reject
> COW mappigs at mmap time.
>
> There was previously a comment in the code that WC mappings together
> with x86 PAT + PFNMAP was bad for performance. However from looking at
> vmf_insert_mixed() it looks like in the current code PFNMAP and MIXEDMAP
> are handled the same for architectures that support pte_special. This
> means there should not be a performance difference anymore, but this
> needs to be verified.
>
> Cc: Christian Koenig
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Andrew Morton
> Cc: Jason Gunthorpe
> Cc: linux...@kvack.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Thomas Hellström (Intel)
> ---
> drivers/gpu/drm/ttm/ttm_bo_vm.c | 22 --
> include/linux/mm.h | 5 +
> mm/internal.h | 5 -
> 3 files changed, 13 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> index 1c34983480e5..708c6fb9be81 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> @@ -372,12 +372,7 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf,
>* at arbitrary times while the data is mmap'ed.
>* See vmf_insert_mixed_prot() for a discussion.
>*/
> - if (vma->vm_flags & VM_MIXEDMAP)
> - ret = vmf_insert_mixed_prot(vma, address,
> - __pfn_to_pfn_t(pfn,
> PFN_DEV),
> - prot);
> - else
> - ret = vmf_insert_pfn_prot(vma, address, pfn, prot);
> + ret = vmf_insert_pfn_prot(vma, address, pfn, prot);
>
> /* Never error on prefaulted PTEs */
> if (unlikely((ret & VM_FAULT_ERROR))) {
> @@ -555,18 +550,14 @@ static void ttm_bo_mmap_vma_setup(struct
> ttm_buffer_object *bo, struct vm_area_s
>* Note: We're transferring the bo reference to
>* vma->vm_private_data here.
>*/
> -
> vma->vm_private_data = bo;
>
> /*
> - * We'd like to use VM_PFNMAP on shared mappings, where
> - * (vma->vm_flags & VM_SHARED) != 0, for performance reasons,
> - * but for some reason VM_PFNMAP + x86 PAT + write-combine is very
> - * bad for performance. Until that has been sorted out, use
> - * VM_MIXEDMAP on all mappings. See freedesktop.org bug #75719
> + * PFNMAP forces us to block COW mappings in mmap(),
> + * and with MIXEDMAP we would incorrectly allow fast gup
> + * on TTM memory on architectures that don't have pte_special.
>*/
> - vma->vm_flags |= VM_MIXEDMAP;
> - vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP;
> + vma->vm_flags |= VM_PFNMAP | VM_IO | VM_DONTEXPAND | VM_DONTDUMP;
> }
>
> int ttm_bo_mmap(struct file *filp, struct vm_area_struct *vma,
> @@ -579,6 +570,9 @@ int ttm_bo_mmap(struct file *filp, struct vm_area_struct
> *vma,
> if (unlikely(vma->vm_pgoff < DRM_FILE_PAGE_OFFSET_START))
> return -EINVAL;
>
> + if (unlikely(is_cow_mapping(vma->vm_flags)))
> + return -EINVAL;
> +
> bo = ttm_bo_vm_lookup(bdev, vma->vm_pgoff, vma_pages(vma));
> if (unlikely(!bo))
> return -EINVAL;
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 77e64e3eac80..c6ebf7f9ddbb 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -686,6 +686,11 @@ static inline bool vma_is_accessible(struct
> vm_area_struct *vma)
> return vma->vm_flags & VM_ACCESS_FLAGS;
> }
>
> +static inline bool is_cow_mapping(vm_flags_t flags)
Bit a bikeshed, but I wonder whether the public interface shouldn't be
vma_is_cow_mapping. Or whether this shouldn't be rejected somewhere else,
since
Re: [RFC PATCH 1/2] mm,drm/ttm: Block fast GUP to TTM huge pages
On Sun, Mar 21, 2021 at 07:45:28PM +0100, Thomas Hellström (Intel) wrote:
> TTM sets up huge page-table-entries both to system- and device memory,
> and we don't want gup to assume there are always valid backing struct
> pages for these. For PTEs this is handled by setting the pte_special bit,
> but for the huge PUDs and PMDs, we have neither pmd_special nor
> pud_special. Normally, huge TTM entries are identified by looking at
> vma_is_special_huge(), but fast gup can't do that, so as an alternative
> define _devmap entries for which there are no backing dev_pagemap as
> special, update documentation and make huge TTM entries _devmap, after
> verifying that there is no backing dev_pagemap.
>
> One other alternative would be to block TTM huge page-table-entries
> completely, and while currently only vmwgfx use them, they would be
> beneficial to other graphis drivers moving forward as well.
>
> Cc: Christian Koenig
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Andrew Morton
> Cc: Jason Gunthorpe
> Cc: linux...@kvack.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Thomas Hellström (Intel)
> ---
> drivers/gpu/drm/ttm/ttm_bo_vm.c | 17 -
> mm/gup.c| 21 +++--
> mm/memremap.c | 5 +
> 3 files changed, 32 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> index 6dc96cf66744..1c34983480e5 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> @@ -195,6 +195,7 @@ static vm_fault_t ttm_bo_vm_insert_huge(struct vm_fault
> *vmf,
> pfn_t pfnt;
> struct ttm_tt *ttm = bo->ttm;
> bool write = vmf->flags & FAULT_FLAG_WRITE;
> + struct dev_pagemap *pagemap;
>
> /* Fault should not cross bo boundary. */
> page_offset &= ~(fault_page_size - 1);
> @@ -210,6 +211,20 @@ static vm_fault_t ttm_bo_vm_insert_huge(struct vm_fault
> *vmf,
> if ((pfn & (fault_page_size - 1)) != 0)
> goto out_fallback;
>
> + /*
> + * Huge entries must be special, that is marking them as devmap
> + * with no backing device map range. If there is a backing
> + * range, Don't insert a huge entry.
> + * If this check turns out to be too much of a performance hit,
> + * we can instead have drivers indicate whether they may have
> + * backing device map ranges and if not, skip this lookup.
> + */
I think we can do this statically:
- if it's system memory we know there's no devmap for it, and we do the
trick to block gup_fast
- if it's iomem, we know gup_fast wont work anyway if don't set PFN_DEV,
so might as well not do that
I think that would cover all cases without this check here?
-Daniel
> + pagemap = get_dev_pagemap(pfn, NULL);
> + if (pagemap) {
> + put_dev_pagemap(pagemap);
> + goto out_fallback;
> + }
> +
> /* Check that memory is contiguous. */
> if (!bo->mem.bus.is_iomem) {
> for (i = 1; i < fault_page_size; ++i) {
> @@ -223,7 +238,7 @@ static vm_fault_t ttm_bo_vm_insert_huge(struct vm_fault
> *vmf,
> }
> }
>
> - pfnt = __pfn_to_pfn_t(pfn, PFN_DEV);
> + pfnt = __pfn_to_pfn_t(pfn, PFN_DEV | PFN_MAP);
> if (fault_page_size == (HPAGE_PMD_SIZE >> PAGE_SHIFT))
> ret = vmf_insert_pfn_pmd_prot(vmf, pfnt, pgprot, write);
> #ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
> diff --git a/mm/gup.c b/mm/gup.c
> index e40579624f10..1b6a127f0bdd 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -1993,6 +1993,17 @@ static void __maybe_unused undo_dev_pagemap(int *nr,
> int nr_start,
> }
>
> #ifdef CONFIG_ARCH_HAS_PTE_SPECIAL
> +/*
> + * If we can't determine whether or not a pte is special, then fail
> immediately
> + * for ptes. Note, we can still pin HugeTLB as it is guaranteed not to be
> + * special. For THP, special huge entries are indicated by xxx_devmap()
> + * returning true, but a corresponding call to get_dev_pagemap() will
> + * return NULL.
> + *
> + * For a futex to be placed on a THP tail page, get_futex_key requires a
> + * get_user_pages_fast_only implementation that can pin pages. Thus it's
> still
> + * useful to have gup_huge_pmd even if we can't operate on ptes.
> + */
> static int gup_pte_range(pmd_t pmd, unsigned long addr, unsigned long end,
>unsigned int flags, struct page **pages, int *nr)
> {
> @@ -2069,16 +2080,6 @@ static int gup_pte_range(pmd_t pmd, unsigned long
> addr, unsigned long end,
> return ret;
> }
> #el
Re: [PATCH 2/2] vgaarb: avoid -Wempty-body warnings
On Mon, Mar 22, 2021 at 11:53:00AM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Building with W=1 shows a few warnings for an empty macro:
>
> drivers/gpu/drm/qxl/qxl_drv.c: In function 'qxl_pci_probe':
> drivers/gpu/drm/qxl/qxl_drv.c:131:50: error: suggest braces around empty body
> in an 'if' statement [-Werror=empty-body]
> 131 | vga_put(pdev, VGA_RSRC_LEGACY_IO);
> | ^
> drivers/gpu/drm/qxl/qxl_drv.c: In function 'qxl_pci_remove':
> drivers/gpu/drm/qxl/qxl_drv.c:159:50: error: suggest braces around empty body
> in an 'if' statement [-Werror=empty-body]
> 159 | vga_put(pdev, VGA_RSRC_LEGACY_IO);
>
> Change this to an inline function to make it more robust and avoid
> the warning.
>
> Signed-off-by: Arnd Bergmann
Both applied to drm-misc-next for 5.13, thanks for your patches.
-Daniel
> ---
> include/linux/vgaarb.h | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/vgaarb.h b/include/linux/vgaarb.h
> index fc6dfeba04a5..dc6ddce92066 100644
> --- a/include/linux/vgaarb.h
> +++ b/include/linux/vgaarb.h
> @@ -112,7 +112,9 @@ static inline int vga_get_uninterruptible(struct pci_dev
> *pdev,
> #if defined(CONFIG_VGA_ARB)
> extern void vga_put(struct pci_dev *pdev, unsigned int rsrc);
> #else
> -#define vga_put(pdev, rsrc)
> +static inline void vga_put(struct pci_dev *pdev, unsigned int rsrc)
> +{
> +}
> #endif
>
>
> --
> 2.29.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [RESEND 00/53] Rid GPU from W=1 warnings
On Fri, Mar 19, 2021 at 08:24:07AM +, Lee Jones wrote: > On Thu, 18 Mar 2021, Daniel Vetter wrote: > > > On Wed, Mar 17, 2021 at 9:32 PM Daniel Vetter wrote: > > > > > > On Wed, Mar 17, 2021 at 9:17 AM Lee Jones wrote: > > > > > > > > On Thu, 11 Mar 2021, Lee Jones wrote: > > > > > > > > > On Thu, 11 Mar 2021, Daniel Vetter wrote: > > > > > > > > > > > On Mon, Mar 08, 2021 at 09:19:32AM +, Lee Jones wrote: > > > > > > > On Fri, 05 Mar 2021, Roland Scheidegger wrote: > > > > > > > > > > > > > > > The vmwgfx ones look all good to me, so for > > > > > > > > 23-53: Reviewed-by: Roland Scheidegger > > > > > > > > That said, they were already signed off by Zack, so not sure > > > > > > > > what > > > > > > > > happened here. > > > > > > > > > > > > > > Yes, they were accepted at one point, then dropped without a > > > > > > > reason. > > > > > > > > > > > > > > Since I rebased onto the latest -next, I had to pluck them back > > > > > > > out of > > > > > > > a previous one. > > > > > > > > > > > > They should show up in linux-next again. We merge patches for next > > > > > > merge > > > > > > window even during the current merge window, but need to make sure > > > > > > they > > > > > > don't pollute linux-next. Occasionally the cut off is wrong so > > > > > > patches > > > > > > show up, and then get pulled again. > > > > > > > > > > > > Unfortunately especially the 5.12 merge cycle was very wobbly due > > > > > > to some > > > > > > confusion here. But your patches should all be in linux-next again > > > > > > (they > > > > > > are queued up for 5.13 in drm-misc-next, I checked that). > > > > > > > > > > > > Sorry for the confusion here. > > > > > > > > > > Oh, I see. Well so long as they don't get dropped, I'll be happy. > > > > > > > > > > Thanks for the explanation Daniel > > > > > > > > After rebasing today, all of my GPU patches have remained. Would > > > > someone be kind enough to check that everything is still in order > > > > please? > > > > > > It's still broken somehow. I've kiced Maxime and Maarten again, > > > they're also on this thread. > > > > You're patches have made it into drm-next meanwhile, so they should > > show up in linux-next through that tree at least. Except if that one > > also has some trouble. > > Thanks for letting me know. > > I see some patches made it back in, others didn't. > > I'll resend the stragglers - bear with. The vmwgfx ones should all be back, the others I guess just werent ever applied. I'll vacuum them all up if you resend. Apologies for the wobbly ride. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] drm: Few typo fixes
On Thu, Mar 18, 2021 at 04:07:39PM +0530, Bhaskar Chowdhury wrote: > > s/instatiated/instantiated/ > s/unreference/unreferenced/ > > Signed-off-by: Bhaskar Chowdhury Queued for 5.13 in drm-misc-next, thanks for your patch. -Daniel > --- > drivers/gpu/drm/drm_property.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c > index 6ee04803c362..27c824a6eb60 100644 > --- a/drivers/gpu/drm/drm_property.c > +++ b/drivers/gpu/drm/drm_property.c > @@ -43,7 +43,7 @@ > * property types and ranges. > * > * Properties don't store the current value directly, but need to be > - * instatiated by attaching them to a _mode_object with > + * instantiated by attaching them to a _mode_object with > * drm_object_attach_property(). > * > * Property values are only 64bit. To support bigger piles of data (like > gamma > @@ -644,7 +644,7 @@ EXPORT_SYMBOL(drm_property_blob_get); > * @id: id of the blob property > * > * If successful, this takes an additional reference to the blob property. > - * callers need to make sure to eventually unreference the returned property > + * callers need to make sure to eventually unreferenced the returned property > * again, using drm_property_blob_put(). > * > * Return: > -- > 2.26.2 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [RESEND 00/53] Rid GPU from W=1 warnings
On Wed, Mar 17, 2021 at 9:32 PM Daniel Vetter wrote: > > On Wed, Mar 17, 2021 at 9:17 AM Lee Jones wrote: > > > > On Thu, 11 Mar 2021, Lee Jones wrote: > > > > > On Thu, 11 Mar 2021, Daniel Vetter wrote: > > > > > > > On Mon, Mar 08, 2021 at 09:19:32AM +, Lee Jones wrote: > > > > > On Fri, 05 Mar 2021, Roland Scheidegger wrote: > > > > > > > > > > > The vmwgfx ones look all good to me, so for > > > > > > 23-53: Reviewed-by: Roland Scheidegger > > > > > > That said, they were already signed off by Zack, so not sure what > > > > > > happened here. > > > > > > > > > > Yes, they were accepted at one point, then dropped without a reason. > > > > > > > > > > Since I rebased onto the latest -next, I had to pluck them back out of > > > > > a previous one. > > > > > > > > They should show up in linux-next again. We merge patches for next merge > > > > window even during the current merge window, but need to make sure they > > > > don't pollute linux-next. Occasionally the cut off is wrong so patches > > > > show up, and then get pulled again. > > > > > > > > Unfortunately especially the 5.12 merge cycle was very wobbly due to > > > > some > > > > confusion here. But your patches should all be in linux-next again (they > > > > are queued up for 5.13 in drm-misc-next, I checked that). > > > > > > > > Sorry for the confusion here. > > > > > > Oh, I see. Well so long as they don't get dropped, I'll be happy. > > > > > > Thanks for the explanation Daniel > > > > After rebasing today, all of my GPU patches have remained. Would > > someone be kind enough to check that everything is still in order > > please? > > It's still broken somehow. I've kiced Maxime and Maarten again, > they're also on this thread. You're patches have made it into drm-next meanwhile, so they should show up in linux-next through that tree at least. Except if that one also has some trouble. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [RESEND 00/53] Rid GPU from W=1 warnings
On Wed, Mar 17, 2021 at 9:17 AM Lee Jones wrote: > > On Thu, 11 Mar 2021, Lee Jones wrote: > > > On Thu, 11 Mar 2021, Daniel Vetter wrote: > > > > > On Mon, Mar 08, 2021 at 09:19:32AM +, Lee Jones wrote: > > > > On Fri, 05 Mar 2021, Roland Scheidegger wrote: > > > > > > > > > The vmwgfx ones look all good to me, so for > > > > > 23-53: Reviewed-by: Roland Scheidegger > > > > > That said, they were already signed off by Zack, so not sure what > > > > > happened here. > > > > > > > > Yes, they were accepted at one point, then dropped without a reason. > > > > > > > > Since I rebased onto the latest -next, I had to pluck them back out of > > > > a previous one. > > > > > > They should show up in linux-next again. We merge patches for next merge > > > window even during the current merge window, but need to make sure they > > > don't pollute linux-next. Occasionally the cut off is wrong so patches > > > show up, and then get pulled again. > > > > > > Unfortunately especially the 5.12 merge cycle was very wobbly due to some > > > confusion here. But your patches should all be in linux-next again (they > > > are queued up for 5.13 in drm-misc-next, I checked that). > > > > > > Sorry for the confusion here. > > > > Oh, I see. Well so long as they don't get dropped, I'll be happy. > > > > Thanks for the explanation Daniel > > After rebasing today, all of my GPU patches have remained. Would > someone be kind enough to check that everything is still in order > please? It's still broken somehow. I've kiced Maxime and Maarten again, they're also on this thread. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH 2/3] media/videobuf1|2: Mark follow_pfn usage as unsafe
On Wed, Mar 17, 2021 at 8:22 AM Christoph Hellwig wrote: > On Tue, Mar 16, 2021 at 04:52:44PM +0100, Daniel Vetter wrote: > > My understanding is mostly, but with some objections. And I kinda > > don't want to let this die in a bikeshed and then not getting rid of > > follow_pfn as a result. There's enough people who acked this, and the > > full removal got some nack from Mauro iirc. > > Hmm, ok I must have missed that. I defintively prefer your series over > doing nothing, but killing the dead horse ASAP would be even better. I have a bunch of slow-burner things I need to fix in this area of driver mmaps vs get_user_/follow_ conflicts anyway, I'll add a note to put the horse out of it's misery in due time. We have a few problems still where things might get pinned or used where it really shouldn't be. Can I count that as an ack on the series? You've touched this quite a bit recently. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH 2/3] media/videobuf1|2: Mark follow_pfn usage as unsafe
On Tue, Mar 16, 2021 at 4:46 PM Christoph Hellwig wrote:
>
> On Tue, Mar 16, 2021 at 04:33:02PM +0100, Daniel Vetter wrote:
> > The media model assumes that buffers are all preallocated, so that
> > when a media pipeline is running we never miss a deadline because the
> > buffers aren't allocated or available.
> >
> > This means we cannot fix the v4l follow_pfn usage through
> > mmu_notifier, without breaking how this all works. The only real fix
> > is to deprecate userptr support for VM_IO | VM_PFNMAP mappings and
> > tell everyone to cut over to dma-buf memory sharing for zerocopy.
> >
> > userptr for normal memory will keep working as-is, this only affects
> > the zerocopy userptr usage enabled in 50ac952d2263 ("[media]
> > videobuf2-dma-sg: Support io userptr operations on io memory").
>
> Maybe I'm missing something, but wasn't the conclusion last time that
> this hackish early device to device copy support can just go away?
My understanding is mostly, but with some objections. And I kinda
don't want to let this die in a bikeshed and then not getting rid of
follow_pfn as a result. There's enough people who acked this, and the
full removal got some nack from Mauro iirc.
Maybe if no bug report ever shows up for 1-2 years we can sunset it
for real
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 3/3] mm: unexport follow_pfn
Both kvm (in bd2fae8da794 ("KVM: do not assume PTE is writable after
follow_pfn")) and vfio (in 07956b6269d3 ("vfio/type1: Use
follow_pte()")) have lost their callsites of follow_pfn(). All the
other ones have been switched over to unsafe_follow_pfn because they
cannot be fixed without breaking userspace api.
Argueably the vfio code is still racy, but that's kinda a bigger
picture. But since it does leak the pte beyond where it drops the pt
lock, without anything else like an mmu notifier guaranteeing
coherence, the problem is at least clearly visible in the vfio code.
So good enough with me.
I've decided to keep the explanation that after dropping the pt lock
you must have an mmu notifier if you keep using the pte somehow by
adjusting it and moving it into the kerneldoc for the new follow_pte()
function.
Cc: 3...@google.com
Cc: Jann Horn
Cc: Paolo Bonzini
Cc: Jason Gunthorpe
Cc: Cornelia Huck
Cc: Peter Xu
Cc: Alex Williamson
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: k...@vger.kernel.org
Signed-off-by: Daniel Vetter
---
include/linux/mm.h | 2 --
mm/memory.c| 26 +-
mm/nommu.c | 13 +
3 files changed, 6 insertions(+), 35 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index caec8b25d66f..304588e2f829 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1693,8 +1693,6 @@ int follow_invalidate_pte(struct mm_struct *mm, unsigned
long address,
pmd_t **pmdpp, spinlock_t **ptlp);
int follow_pte(struct mm_struct *mm, unsigned long address,
pte_t **ptepp, spinlock_t **ptlp);
-int follow_pfn(struct vm_area_struct *vma, unsigned long address,
- unsigned long *pfn);
int unsafe_follow_pfn(struct vm_area_struct *vma, unsigned long address,
unsigned long *pfn);
int follow_phys(struct vm_area_struct *vma, unsigned long address,
diff --git a/mm/memory.c b/mm/memory.c
index e8a145505b69..317e653c8aeb 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4724,7 +4724,10 @@ int follow_invalidate_pte(struct mm_struct *mm, unsigned
long address,
* should be taken for read.
*
* KVM uses this function. While it is arguably less bad than ``follow_pfn``,
- * it is not a good general-purpose API.
+ * it is not a good general-purpose API: If callers use the pte after they've
+ * unlocked @ptlp they must ensure coherency with pte updates by using a
+ * _notifier to follow updates. Any caller not following these requirements
+ * must use unsafe_follow_pfn() instead.
*
* Return: zero on success, -ve otherwise.
*/
@@ -4735,25 +4738,7 @@ int follow_pte(struct mm_struct *mm, unsigned long
address,
}
EXPORT_SYMBOL_GPL(follow_pte);
-/**
- * follow_pfn - look up PFN at a user virtual address
- * @vma: memory mapping
- * @address: user virtual address
- * @pfn: location to store found PFN
- *
- * Only IO mappings and raw PFN mappings are allowed. Note that callers must
- * ensure coherency with pte updates by using a _notifier to follow
updates.
- * If this is not feasible, or the access to the @pfn is only very short term,
- * use follow_pte_pmd() instead and hold the pagetable lock for the duration of
- * the access instead. Any caller not following these requirements must use
- * unsafe_follow_pfn() instead.
- *
- * This function does not allow the caller to read the permissions
- * of the PTE. Do not use it.
- *
- * Return: zero and the pfn at @pfn on success, -ve otherwise.
- */
-int follow_pfn(struct vm_area_struct *vma, unsigned long address,
+static int follow_pfn(struct vm_area_struct *vma, unsigned long address,
unsigned long *pfn)
{
int ret = -EINVAL;
@@ -4770,7 +4755,6 @@ int follow_pfn(struct vm_area_struct *vma, unsigned long
address,
pte_unmap_unlock(ptep, ptl);
return 0;
}
-EXPORT_SYMBOL_GPL(follow_pfn);
/**
* unsafe_follow_pfn - look up PFN at a user virtual address
diff --git a/mm/nommu.c b/mm/nommu.c
index 1dc983f50e2c..cee29d0791b3 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -111,17 +111,7 @@ unsigned int kobjsize(const void *objp)
return page_size(page);
}
-/**
- * follow_pfn - look up PFN at a user virtual address
- * @vma: memory mapping
- * @address: user virtual address
- * @pfn: location to store found PFN
- *
- * Only IO mappings and raw PFN mappings are allowed.
- *
- * Returns zero and the pfn at @pfn on success, -ve otherwise.
- */
-int follow_pfn(struct vm_area_struct *vma, unsigned long address,
+static int follow_pfn(struct vm_area_struct *vma, unsigned long address,
unsigned long *pfn)
{
if (!(vma->vm_flags & (VM_IO | VM_PFNMAP)))
@@ -130,7 +120,6 @@ int follow_pfn(struct vm_area_struct *vma, unsigned long
address,
*pfn = address >> PAGE_SHIFT;
return 0;
}
-EXPORT_SYMBOL_GPL(follow_pfn);
/**
* unsafe_follow_pfn - look
[PATCH 2/3] media/videobuf1|2: Mark follow_pfn usage as unsafe
The media model assumes that buffers are all preallocated, so that
when a media pipeline is running we never miss a deadline because the
buffers aren't allocated or available.
This means we cannot fix the v4l follow_pfn usage through
mmu_notifier, without breaking how this all works. The only real fix
is to deprecate userptr support for VM_IO | VM_PFNMAP mappings and
tell everyone to cut over to dma-buf memory sharing for zerocopy.
userptr for normal memory will keep working as-is, this only affects
the zerocopy userptr usage enabled in 50ac952d2263 ("[media]
videobuf2-dma-sg: Support io userptr operations on io memory").
Acked-by: Tomasz Figa
Acked-by: Hans Verkuil
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Pawel Osciak
Cc: Marek Szyprowski
Cc: Kyungmin Park
Cc: Tomasz Figa
Cc: Laurent Dufour
Cc: Vlastimil Babka
Cc: Daniel Jordan
Cc: Michel Lespinasse
Signed-off-by: Daniel Vetter
--
v3:
- Reference the commit that enabled the zerocopy userptr use case to
make it abundandtly clear that this patch only affects that, and not
normal memory userptr. The old commit message already explained that
normal memory userptr is unaffected, but I guess that was not clear
enough.
---
drivers/media/common/videobuf2/frame_vector.c | 2 +-
drivers/media/v4l2-core/videobuf-dma-contig.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/common/videobuf2/frame_vector.c
b/drivers/media/common/videobuf2/frame_vector.c
index a0e65481a201..1a82ec13ea00 100644
--- a/drivers/media/common/videobuf2/frame_vector.c
+++ b/drivers/media/common/videobuf2/frame_vector.c
@@ -70,7 +70,7 @@ int get_vaddr_frames(unsigned long start, unsigned int
nr_frames,
break;
while (ret < nr_frames && start + PAGE_SIZE <= vma->vm_end) {
- err = follow_pfn(vma, start, [ret]);
+ err = unsafe_follow_pfn(vma, start, [ret]);
if (err) {
if (ret == 0)
ret = err;
diff --git a/drivers/media/v4l2-core/videobuf-dma-contig.c
b/drivers/media/v4l2-core/videobuf-dma-contig.c
index 52312ce2ba05..821c4a76ab96 100644
--- a/drivers/media/v4l2-core/videobuf-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf-dma-contig.c
@@ -183,7 +183,7 @@ static int videobuf_dma_contig_user_get(struct
videobuf_dma_contig_memory *mem,
user_address = untagged_baddr;
while (pages_done < (mem->size >> PAGE_SHIFT)) {
- ret = follow_pfn(vma, user_address, _pfn);
+ ret = unsafe_follow_pfn(vma, user_address, _pfn);
if (ret)
break;
--
2.30.0
[PATCH 1/3] mm: Add unsafe_follow_pfn
Way back it was a reasonable assumptions that iomem mappings never
change the pfn range they point at. But this has changed:
- gpu drivers dynamically manage their memory nowadays, invalidating
ptes with unmap_mapping_range when buffers get moved
- contiguous dma allocations have moved from dedicated carvetouts to
cma regions. This means if we miss the unmap the pfn might contain
pagecache or anon memory (well anything allocated with GFP_MOVEABLE)
- even /dev/mem now invalidates mappings when the kernel requests that
iomem region when CONFIG_IO_STRICT_DEVMEM is set, see 3234ac664a87
("/dev/mem: Revoke mappings when a driver claims the region")
Accessing pfns obtained from ptes without holding all the locks is
therefore no longer a good idea.
Unfortunately there's some users where this is not fixable (like v4l
userptr of iomem mappings) or involves a pile of work (vfio type1
iommu). For now annotate these as unsafe and splat appropriately.
This patch adds an unsafe_follow_pfn, which later patches will then
roll out to all appropriate places.
Also mark up follow_pfn as EXPORT_SYMBOL_GPL. The only safe way to use
that by drivers/modules is together with an mmu_notifier, and that's
all _GPL stuff.
Signed-off-by: Daniel Vetter
Cc: Christoph Hellwig
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: k...@vger.kernel.org
Signed-off-by: Daniel Vetter
--
v5: Suggestions from Christoph
- reindent for less weirdness
- use IS_ENABLED instead of #ifdef
- same checks for nommu, for consistency
- EXPORT_SYMBOL_GPL for follow_pfn.
- kerneldoc was already updated in previous versions to explain when
follow_pfn can be used safely
---
include/linux/mm.h | 2 ++
mm/memory.c| 34 --
mm/nommu.c | 27 ++-
security/Kconfig | 13 +
4 files changed, 73 insertions(+), 3 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 64a71bf20536..caec8b25d66f 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1695,6 +1695,8 @@ int follow_pte(struct mm_struct *mm, unsigned long
address,
pte_t **ptepp, spinlock_t **ptlp);
int follow_pfn(struct vm_area_struct *vma, unsigned long address,
unsigned long *pfn);
+int unsafe_follow_pfn(struct vm_area_struct *vma, unsigned long address,
+ unsigned long *pfn);
int follow_phys(struct vm_area_struct *vma, unsigned long address,
unsigned int flags, unsigned long *prot, resource_size_t *phys);
int generic_access_phys(struct vm_area_struct *vma, unsigned long addr,
diff --git a/mm/memory.c b/mm/memory.c
index 5efa07fb6cdc..e8a145505b69 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4741,7 +4741,12 @@ EXPORT_SYMBOL_GPL(follow_pte);
* @address: user virtual address
* @pfn: location to store found PFN
*
- * Only IO mappings and raw PFN mappings are allowed.
+ * Only IO mappings and raw PFN mappings are allowed. Note that callers must
+ * ensure coherency with pte updates by using a _notifier to follow
updates.
+ * If this is not feasible, or the access to the @pfn is only very short term,
+ * use follow_pte_pmd() instead and hold the pagetable lock for the duration of
+ * the access instead. Any caller not following these requirements must use
+ * unsafe_follow_pfn() instead.
*
* This function does not allow the caller to read the permissions
* of the PTE. Do not use it.
@@ -4765,7 +4770,32 @@ int follow_pfn(struct vm_area_struct *vma, unsigned long
address,
pte_unmap_unlock(ptep, ptl);
return 0;
}
-EXPORT_SYMBOL(follow_pfn);
+EXPORT_SYMBOL_GPL(follow_pfn);
+
+/**
+ * unsafe_follow_pfn - look up PFN at a user virtual address
+ * @vma: memory mapping
+ * @address: user virtual address
+ * @pfn: location to store found PFN
+ *
+ * Only IO mappings and raw PFN mappings are allowed.
+ *
+ * Returns zero and the pfn at @pfn on success, -ve otherwise.
+ */
+int unsafe_follow_pfn(struct vm_area_struct *vma, unsigned long address,
+ unsigned long *pfn)
+{
+ if (IS_ENABLED(CONFIG_STRICT_FOLLOW_PFN)) {
+ pr_info("unsafe follow_pfn usage rejected, see
CONFIG_STRICT_FOLLOW_PFN\n");
+ return -EINVAL;
+ }
+
+ WARN_ONCE(1, "unsafe follow_pfn usage\n");
+ add_taint(TAINT_USER, LOCKDEP_STILL_OK);
+
+ return follow_pfn(vma, address, pfn);
+}
+EXPORT_SYMBOL(unsafe_follow_pfn);
#ifdef CONFIG_HAVE_IOREMAP_PROT
int follow_phys(struct vm_area_struct *vma,
diff --git a/mm/nommu.c b/mm/nommu.c
index 5c9ab799c0e6..1dc983f50e2c 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -130,7 +130,32 @@ int follow_pfn(struct vm_area_struct *vma, unsigned long
address,
*pfn = address &
[PATCH 0/3] switch to unsafe_follow_pfn
Hi all, This are the leftovers from my pull that landed in 5.12: https://lore.kernel.org/dri-devel/CAKMK7uHQ=6ojcrgucutib456rwdcfwsnexv8pqsfspodtj6...@mail.gmail.com/ Only changes compared to the old submission are: - dropped vfio and kvm patch - add patch to just remove follow_pfn at the end Assuming no objections I'd like to lande these three patches in my topic branch for 5.13, for sufficient amounts of testing in linux-next before the merge window. Ack/review especially on the two mm patches very much thought after. Cheers, Daniel Daniel Vetter (3): mm: Add unsafe_follow_pfn media/videobuf1|2: Mark follow_pfn usage as unsafe mm: unexport follow_pfn drivers/media/common/videobuf2/frame_vector.c | 2 +- drivers/media/v4l2-core/videobuf-dma-contig.c | 2 +- include/linux/mm.h| 4 +- mm/memory.c | 46 --- mm/nommu.c| 28 --- security/Kconfig | 13 ++ 6 files changed, 68 insertions(+), 27 deletions(-) -- 2.30.0
Re: [syzbot] upstream boot error: WARNING in vkms_vblank_simulate
On Fri, Mar 12, 2021 at 05:10:43PM +0100, Dmitry Vyukov wrote: > On Fri, Mar 12, 2021 at 3:22 PM Daniel Vetter wrote: > > > > On Fri, Mar 12, 2021 at 11:46:27AM +0100, Dmitry Vyukov wrote: > > > On Fri, Mar 12, 2021 at 11:26 AM syzbot > > > wrote: > > > > > > > > Hello, > > > > > > > > syzbot found the following issue on: > > > > > > > > HEAD commit:f78d76e7 Merge tag 'drm-fixes-2021-03-12-1' of > > > > git://anong.. > > > > git tree: upstream > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=11c16ba2d0 > > > > kernel config: > > > > https://syzkaller.appspot.com/x/.config?x=dc02c6afcb046874 > > > > dashboard link: > > > > https://syzkaller.appspot.com/bug?extid=333bd014262fd5d0a418 > > > > userspace arch: arm > > > > > > > > IMPORTANT: if you fix the issue, please add the following tag to the > > > > commit: > > > > Reported-by: syzbot+333bd014262fd5d0a...@syzkaller.appspotmail.com > > > > > > This WARNING seems to be happening just randomly. > > > It was already reported as: > > > > > > #syz dup: WARNING in vkms_vblank_simulate (2) > > > https://syzkaller.appspot.com/bug?id=9b10491371879700d6a21c15684c2232ff015084 > > > > > > It now has whooping 48589 crashes and also crashes slow qemu tcg > > > instances. > > > > Yeah your box is too slow. We're trying to simulate hw here, which means > > if we can process less than 1 hrtimer per vblank (standard every 16ms) > > then we scream, because things go very wrong with the simulated hw. And > > the hrtimer is really not that big, all the expensive processing is pushed > > to worker, where we have code to handle if it falls back too much. > > > > So either patch this out or make the code robust against a kernel that > > somehow can't process a single hrtimer every 16ms. > > -Daniel > > Majority of these happen on the latest Intel CPUs. If that's not fast, > then I don't know what' fast :) > WARNING must not be used for timing-triggerable conditions. pr_warn is > more appropriate here. I assume the call stack and the rest of the > info that WARNING prints is completely useless, it's only the binary > condition, right. Hm, maybe we do have some bug somewhere left still. But yeah if pr_warn does not trigger a full abort with syzbot then we can do that I guess. Care to submit that pathc please with a short explainer why it upsets syzbot? Thanks, Daniel > > > > > > [ cut here ] > > > > WARNING: CPU: 0 PID: 0 at drivers/gpu/drm/vkms/vkms_crtc.c:21 > > > > vkms_vblank_simulate+0x26c/0x2f4 drivers/gpu/drm/vkms/vkms_crtc.c:41 > > > > Modules linked in: > > > > CPU: 0 PID: 0 Comm: swapper/0 Not tainted > > > > 5.12.0-rc2-syzkaller-00338-gf78d76e72a46 #0 > > > > Hardware name: linux,dummy-virt (DT) > > > > pstate: 2085 (nzCv daIf -PAN -UAO -TCO BTYPE=--) > > > > pc : vkms_vblank_simulate+0x26c/0x2f4 > > > > drivers/gpu/drm/vkms/vkms_crtc.c:21 > > > > lr : hrtimer_forward_now include/linux/hrtimer.h:510 [inline] > > > > lr : vkms_vblank_simulate+0x90/0x2f4 drivers/gpu/drm/vkms/vkms_crtc.c:19 > > > > sp : 6a693cd0 > > > > x29: 6a693cd0 x28: 0c9d1e58 > > > > x27: dfff8000 x26: 6a67f540 > > > > x25: 1fffed4cfeb1 x24: 1fffed4cfeaa > > > > x23: 0c9d0d30 x22: 00fe4c00 > > > > x21: 6a67f540 x20: 0c9d0e58 > > > > x19: 0c9d1e58 x18: 6a6a1b48 > > > > x17: 1fffe1952345 x16: > > > > x15: 8000197bf810 x14: 1fffed4d2750 > > > > x13: 0001 x12: 0033 > > > > x11: 12fb4936 x10: 0007 > > > > x9 : 12fb4943 x8 : 800017d14c00 > > > > x7 : f1f1f1f1 x6 : dfff8000 > > > > x5 : 7fff x4 : 0008e44f6b90 > > > > x3 : 0008e54db790 x2 : 0008e44f6b90 > > > > x1 : 0008e54db790 x0 : 0002 > > > > Call trace: > > > > vkms_vblank_simulate+0x26c/0x2f4 drivers/gpu/drm/vkms/vkms_crtc.c:41 > > > > __run_hrtimer kernel/time/hrtimer.c:1519 [inline] > > > > __hrtimer_run_queues+0x590/0xe40 kernel/time/hrtimer.c:1583 > > > > hrtimer_interrupt+0x2d4/0x810 kernel/time/hrtimer.c:1645
Re: [PATCH 3/3] RFC: dma-buf: Add an API for importing and exporting sync files (v5)
On Mon, Mar 15, 2021 at 10:11 PM Jason Ekstrand wrote: > > On Wed, Sep 30, 2020 at 4:55 AM Daniel Vetter wrote: > > > > On Wed, Sep 30, 2020 at 11:39:06AM +0200, Michel Dänzer wrote: > > > On 2020-03-17 10:21 p.m., Jason Ekstrand wrote: > > > > Explicit synchronization is the future. At least, that seems to be what > > > > most userspace APIs are agreeing on at this point. However, most of our > > > > Linux APIs (both userspace and kernel UAPI) are currently built around > > > > implicit synchronization with dma-buf. While work is ongoing to change > > > > many of the userspace APIs and protocols to an explicit synchronization > > > > model, switching over piecemeal is difficult due to the number of > > > > potential components involved. On the kernel side, many drivers use > > > > dma-buf including GPU (3D/compute), display, v4l, and others. In > > > > userspace, we have X11, several Wayland compositors, 3D drivers, compute > > > > drivers (OpenCL etc.), media encode/decode, and the list goes on. > > > > > > > > This patch provides a path forward by allowing userspace to manually > > > > manage the fences attached to a dma-buf. Alternatively, one can think > > > > of this as making dma-buf's implicit synchronization simply a carrier > > > > for an explicit fence. This is accomplished by adding two IOCTLs to > > > > dma-buf for importing and exporting a sync file to/from the dma-buf. > > > > This way a userspace component which is uses explicit synchronization, > > > > such as a Vulkan driver, can manually set the write fence on a buffer > > > > before handing it off to an implicitly synchronized component such as a > > > > Wayland compositor or video encoder. In this way, each of the different > > > > components can be upgraded to an explicit synchronization model one at a > > > > time as long as the userspace pieces connecting them are aware of it and > > > > import/export fences at the right times. > > > > > > > > There is a potential race condition with this API if userspace is not > > > > careful. A typical use case for implicit synchronization is to wait for > > > > the dma-buf to be ready, use it, and then signal it for some other > > > > component. Because a sync_file cannot be created until it is guaranteed > > > > to complete in finite time, userspace can only signal the dma-buf after > > > > it has already submitted the work which uses it to the kernel and has > > > > received a sync_file back. There is no way to atomically submit a > > > > wait-use-signal operation. This is not, however, really a problem with > > > > this API so much as it is a problem with explicit synchronization > > > > itself. The way this is typically handled is to have very explicit > > > > ownership transfer points in the API or protocol which ensure that only > > > > one component is using it at any given time. Both X11 (via the PRESENT > > > > extension) and Wayland provide such ownership transfer points via > > > > explicit present and idle messages. > > > > > > > > The decision was intentionally made in this patch to make the import and > > > > export operations IOCTLs on the dma-buf itself rather than as a DRM > > > > IOCTL. This makes it the import/export operation universal across all > > > > components which use dma-buf including GPU, display, v4l, and others. > > > > It also means that a userspace component can do the import/export > > > > without access to the DRM fd which may be tricky to get in cases where > > > > the client communicates with DRM via a userspace API such as OpenGL or > > > > Vulkan. At a future date we may choose to add direct import/export APIs > > > > to components such as drm_syncobj to avoid allocating a file descriptor > > > > and going through two ioctls. However, that seems to be something of a > > > > micro-optimization as import/export operations are likely to happen at a > > > > rate of a few per frame of rendered or decoded video. > > > > > > > > v2 (Jason Ekstrand): > > > > - Use a wrapper dma_fence_array of all fences including the new one > > > > when importing an exclusive fence. > > > > > > > > v3 (Jason Ekstrand): > > > > - Lock around setting shared fences as well as exclusive > > > > - Mark SIGNAL_SYNC_FILE as a re
Re: [PATCH 2/2] PCI: Revoke mappings like devmem
On Sat, Mar 13, 2021 at 10:57 PM Bjorn Helgaas wrote:
>
> [+cc Krzysztof, Pali, Oliver]
>
> On Thu, Feb 04, 2021 at 05:58:31PM +0100, Daniel Vetter wrote:
> > Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims
> > the region") /dev/kmem zaps ptes when the kernel requests exclusive
> > acccess to an iomem region. And with CONFIG_IO_STRICT_DEVMEM, this is
> > the default for all driver uses.
> >
> > Except there's two more ways to access PCI BARs: sysfs and proc mmap
> > support. Let's plug that hole.
>
> IIUC, the idea is that if a driver calls request_mem_region() on a PCI
> BAR, we prevent access to the BAR via sysfs. I guess I'm OK with that
> if it's a real security improvement or something.
Yup.
> But the downside of this implementation is that it depends on
> iomem_get_mapping(), which doesn't work until after fs_initcalls,
> which means the sysfs files cannot be static attributes of devices
> added before that. PCI devices are typically enumerated in
> subsys_initcall.
>
> Krzysztof is converting PCI sysfs files (config, rom, reset, vpd, etc)
> to static attributes. This is a major improvement that could get rid
> of pci_create_sysfs_dev_files(), the late_initcall pci_sysfs_init(),
> and the "sysfs_initialized" hack. This would fix a race reported by
> Pali [1] (thanks to Oliver for the idea [2]).
>
> EXCEPT that this revoke change means the "resource%d", "legacy_io",
> and "legacy_mem" files cannot be static attributes because of
> iomem_get_mapping().
>
> Any ideas on how to deal with this? Having to keep the
> pci_sysfs_init() initcall just for these few files seems like the tail
> wagging the dog.
It's a bit "pick your ugly". Either we have the late init call (not
pretty), or the sysfs side needs a callback to fish out the
address_space for the mmap at open() time, which didn't stir up much
enthusiams with Greg because we need a new callback just for these
mmio files. Either approach works.
-Daniel
> [1] https://lore.kernel.org/r/20200716110423.xtfyb3n6tn5ixedh@pali
> [2]
> https://lore.kernel.org/r/caosf1chss03dbsdo4pmttmp0tceu5kscn704zewlkgxqzbf...@mail.gmail.com
>
> > For revoke_devmem() to work we need to link our vma into the same
> > address_space, with consistent vma->vm_pgoff. ->pgoff is already
> > adjusted, because that's how (io_)remap_pfn_range works, but for the
> > mapping we need to adjust vma->vm_file->f_mapping. The cleanest way is
> > to adjust this at at ->open time:
> >
> > - for sysfs this is easy, now that binary attributes support this. We
> > just set bin_attr->mapping when mmap is supported
> > - for procfs it's a bit more tricky, since procfs pci access has only
> > one file per device, and access to a specific resources first needs
> > to be set up with some ioctl calls. But mmap is only supported for
> > the same resources as sysfs exposes with mmap support, and otherwise
> > rejected, so we can set the mapping unconditionally at open time
> > without harm.
> >
> > A special consideration is for arch_can_pci_mmap_io() - we need to
> > make sure that the ->f_mapping doesn't alias between ioport and iomem
> > space. There's only 2 ways in-tree to support mmap of ioports: generic
> > pci mmap (ARCH_GENERIC_PCI_MMAP_RESOURCE), and sparc as the single
> > architecture hand-rolling. Both approach support ioport mmap through a
> > special pfn range and not through magic pte attributes. Aliasing is
> > therefore not a problem.
> >
> > The only difference in access checks left is that sysfs PCI mmap does
> > not check for CAP_RAWIO. I'm not really sure whether that should be
> > added or not.
> >
> > Acked-by: Bjorn Helgaas
> > Reviewed-by: Dan Williams
> > Signed-off-by: Daniel Vetter
> > Cc: Stephen Rothwell
> > Cc: Jason Gunthorpe
> > Cc: Kees Cook
> > Cc: Dan Williams
> > Cc: Andrew Morton
> > Cc: John Hubbard
> > Cc: Jérôme Glisse
> > Cc: Jan Kara
> > Cc: Dan Williams
> > Cc: Greg Kroah-Hartman
> > Cc: linux...@kvack.org
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux-samsung-...@vger.kernel.org
> > Cc: linux-me...@vger.kernel.org
> > Cc: Bjorn Helgaas
> > Cc: linux-...@vger.kernel.org
> > ---
> > drivers/pci/pci-sysfs.c | 4
> > drivers/pci/proc.c | 1 +
> > 2 files changed, 5 insertions(+)
> >
> > diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> > index 0c45b4f7b214..f8afd54ca3e1 100644
> > --- a/drivers/pci/pci-sysfs.c
> > +++ b/driver
Re: [syzbot] upstream boot error: WARNING in vkms_vblank_simulate
nel/irq/irqdesc.c:692 > > handle_domain_irq include/linux/irqdesc.h:176 [inline] > > gic_handle_irq+0x5c/0x1b0 drivers/irqchip/irq-gic.c:370 > > el1_irq+0xb4/0x180 arch/arm64/kernel/entry.S:669 > > arch_local_irq_enable+0xc/0x14 arch/arm64/include/asm/irqflags.h:37 > > default_idle_call+0x64/0xf4 kernel/sched/idle.c:112 > > cpuidle_idle_call kernel/sched/idle.c:194 [inline] > > do_idle+0x38c/0x4ec kernel/sched/idle.c:300 > > cpu_startup_entry+0x28/0x80 kernel/sched/idle.c:397 > > rest_init+0x1d0/0x2cc init/main.c:721 > > arch_call_rest_init+0x10/0x1c > > start_kernel+0x3b0/0x3e8 init/main.c:1064 > > 0x0 > > > > > > --- > > This report is generated by a bot. It may contain errors. > > See https://goo.gl/tpsmEJ for more information about syzbot. > > syzbot engineers can be reached at syzkal...@googlegroups.com. > > > > syzbot will keep track of this issue. See: > > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. > > > > -- > > You received this message because you are subscribed to the Google Groups > > "syzkaller-bugs" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to syzkaller-bugs+unsubscr...@googlegroups.com. > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/syzkaller-bugs/9cd8d505bd545452%40google.com. -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH v2] fb_defio: Remove custom address_space_operations
On Wed, Mar 10, 2021 at 06:55:30PM +, Matthew Wilcox (Oracle) wrote:
> There's no need to give the page an address_space. Leaving the
> page->mapping as NULL will cause the VM to handle set_page_dirty()
> the same way that it's handled now, and that was the only reason to
> set the address_space in the first place.
>
> Signed-off-by: Matthew Wilcox (Oracle)
> Reviewed-by: Christoph Hellwig
> Reviewed-by: William Kucharski
Thanks for your patch, merged to drm-misc-next for 5.13.
While I have an expert here, does this mean that for a VM_PFNMAP we could
pull of the same trick without any struct page backing, assuming we pulle
the per-page dirty state into some tracking of our own?
I'm asking since for DRM drivers we currently have a fairly awkward
situation with a bounce buffer in system memory going on that we copy out
of, because we can't directly use the gpu buffers. If we can track
directly in the gpu buffers, maybe even as some kind of overlay over the
vma, we could avoid that copy.
Otoh no one cares about fbcon performance, so *shrug*.
Cheers, Daniel
> ---
> v2: Delete local variable definitions
> drivers/video/fbdev/core/fb_defio.c | 35 -
> drivers/video/fbdev/core/fbmem.c| 4
> include/linux/fb.h | 3 ---
> 3 files changed, 42 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fb_defio.c
> b/drivers/video/fbdev/core/fb_defio.c
> index a591d291b231..b292887a2481 100644
> --- a/drivers/video/fbdev/core/fb_defio.c
> +++ b/drivers/video/fbdev/core/fb_defio.c
> @@ -52,13 +52,6 @@ static vm_fault_t fb_deferred_io_fault(struct vm_fault
> *vmf)
> return VM_FAULT_SIGBUS;
>
> get_page(page);
> -
> - if (vmf->vma->vm_file)
> - page->mapping = vmf->vma->vm_file->f_mapping;
> - else
> - printk(KERN_ERR "no mapping available\n");
> -
> - BUG_ON(!page->mapping);
> page->index = vmf->pgoff;
>
> vmf->page = page;
> @@ -151,17 +144,6 @@ static const struct vm_operations_struct
> fb_deferred_io_vm_ops = {
> .page_mkwrite = fb_deferred_io_mkwrite,
> };
>
> -static int fb_deferred_io_set_page_dirty(struct page *page)
> -{
> - if (!PageDirty(page))
> - SetPageDirty(page);
> - return 0;
> -}
> -
> -static const struct address_space_operations fb_deferred_io_aops = {
> - .set_page_dirty = fb_deferred_io_set_page_dirty,
> -};
> -
> int fb_deferred_io_mmap(struct fb_info *info, struct vm_area_struct *vma)
> {
> vma->vm_ops = _deferred_io_vm_ops;
> @@ -212,29 +194,12 @@ void fb_deferred_io_init(struct fb_info *info)
> }
> EXPORT_SYMBOL_GPL(fb_deferred_io_init);
>
> -void fb_deferred_io_open(struct fb_info *info,
> - struct inode *inode,
> - struct file *file)
> -{
> - file->f_mapping->a_ops = _deferred_io_aops;
> -}
> -EXPORT_SYMBOL_GPL(fb_deferred_io_open);
> -
> void fb_deferred_io_cleanup(struct fb_info *info)
> {
> struct fb_deferred_io *fbdefio = info->fbdefio;
> - struct page *page;
> - int i;
>
> BUG_ON(!fbdefio);
> cancel_delayed_work_sync(>deferred_work);
> -
> - /* clear out the mapping that we setup */
> - for (i = 0 ; i < info->fix.smem_len; i += PAGE_SIZE) {
> - page = fb_deferred_io_page(info, i);
> - page->mapping = NULL;
> - }
> -
> mutex_destroy(>lock);
> }
> EXPORT_SYMBOL_GPL(fb_deferred_io_cleanup);
> diff --git a/drivers/video/fbdev/core/fbmem.c
> b/drivers/video/fbdev/core/fbmem.c
> index 06f5805de2de..372b52a2befa 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -1415,10 +1415,6 @@ __releases(>lock)
> if (res)
> module_put(info->fbops->owner);
> }
> -#ifdef CONFIG_FB_DEFERRED_IO
> - if (info->fbdefio)
> - fb_deferred_io_open(info, inode, file);
> -#endif
> out:
> unlock_fb_info(info);
> if (res)
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index ecfbcc0553a5..a8dccd23c249 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -659,9 +659,6 @@ static inline void __fb_pad_aligned_buffer(u8 *dst, u32
> d_pitch,
> /* drivers/video/fb_defio.c */
> int fb_deferred_io_mmap(struct fb_info *info, struct vm_area_struct *vma);
> extern void fb_deferred_io_init(struct fb_info *info);
> -extern void fb_deferred_io_open(struct fb_info *info,
> - struct inode *inode,
> - struct file *file);
Re: [RESEND 00/53] Rid GPU from W=1 warnings
On Mon, Mar 08, 2021 at 09:19:32AM +, Lee Jones wrote: > On Fri, 05 Mar 2021, Roland Scheidegger wrote: > > > The vmwgfx ones look all good to me, so for > > 23-53: Reviewed-by: Roland Scheidegger > > That said, they were already signed off by Zack, so not sure what > > happened here. > > Yes, they were accepted at one point, then dropped without a reason. > > Since I rebased onto the latest -next, I had to pluck them back out of > a previous one. They should show up in linux-next again. We merge patches for next merge window even during the current merge window, but need to make sure they don't pollute linux-next. Occasionally the cut off is wrong so patches show up, and then get pulled again. Unfortunately especially the 5.12 merge cycle was very wobbly due to some confusion here. But your patches should all be in linux-next again (they are queued up for 5.13 in drm-misc-next, I checked that). Sorry for the confusion here. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] drm/radeon: fix copy of uninitialized variable back to userspace
On Wed, Mar 03, 2021 at 08:42:31AM +0100, Christian König wrote:
> Am 03.03.21 um 01:27 schrieb Colin King:
> > From: Colin Ian King
> >
> > Currently the ioctl command RADEON_INFO_SI_BACKEND_ENABLED_MASK can
> > copy back uninitialised data in value_tmp that pointer *value points
> > to. This can occur when rdev->family is less than CHIP_BONAIRE and
> > less than CHIP_TAHITI. Fix this by adding in a missing -EINVAL
> > so that no invalid value is copied back to userspace.
> >
> > Addresses-Coverity: ("Uninitialized scalar variable)
> > Cc: sta...@vger.kernel.org # 3.13+
> > Fixes: 439a1cfffe2c ("drm/radeon: expose render backend mask to the
> > userspace")
> > Signed-off-by: Colin Ian King
>
> Reviewed-by: Christian König
>
> Let's hope that this doesn't break UAPI.
If it does I think the only difference would be errno userspace sees
(aside from the stack garbage, which we could also emulate). Switching to
return 0; is easy. So no worries this would be a problem :-)
-Daniel
>
> Christian.
>
> > ---
> > drivers/gpu/drm/radeon/radeon_kms.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
> > b/drivers/gpu/drm/radeon/radeon_kms.c
> > index 2479d6ab7a36..58876bb4ef2a 100644
> > --- a/drivers/gpu/drm/radeon/radeon_kms.c
> > +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> > @@ -518,6 +518,7 @@ int radeon_info_ioctl(struct drm_device *dev, void
> > *data, struct drm_file *filp)
> > *value = rdev->config.si.backend_enable_mask;
> > } else {
> > DRM_DEBUG_KMS("BACKEND_ENABLED_MASK is si+ only!\n");
> > + return -EINVAL;
> > }
> > break;
> > case RADEON_INFO_MAX_SCLK:
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH 04/44] vgacon: comment on vga_rolled_over
On Tue, Mar 02, 2021 at 07:21:34AM +0100, Jiri Slaby wrote: > Long time ago, I figured out what this number is good for and documented > that locally. But never submitted, so do it now. > > Signed-off-by: Jiri Slaby > Cc: dri-de...@lists.freedesktop.org > Cc: linux-fb...@vger.kernel.org I think Greg volunteered to take care of these ... Also my brain is toast and I'm not even close to ready to grok vc code to review this properly :-/ Cheers, Daniel > --- > drivers/video/console/vgacon.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c > index 962c12be9774..0d26e821e73b 100644 > --- a/drivers/video/console/vgacon.c > +++ b/drivers/video/console/vgacon.c > @@ -96,7 +96,7 @@ static bool vga_is_gfx; > static bool vga_512_chars; > static int vga_video_font_height; > static int vga_scan_lines __read_mostly; > -static unsigned int vga_rolled_over; > +static unsigned int vga_rolled_over; /* last vc_origin offset before wrap */ > > static bool vgacon_text_mode_force; > static bool vga_hardscroll_enabled; > -- > 2.30.1 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: KMSAN: kernel-infoleak in compat_drm_wait_vblank
On Wed, Mar 03, 2021 at 04:37:18PM +0100, Michel Dänzer wrote: > On 2021-02-22 10:15 a.m., syzbot wrote: > > Hello, > > > > syzbot found the following issue on: > > > > HEAD commit:29ad81a1 arch/x86: add missing include to sparsemem.h > > git tree: https://github.com/google/kmsan.git master > > console output: https://syzkaller.appspot.com/x/log.txt?x=111e6312d0 > > kernel config: https://syzkaller.appspot.com/x/.config?x=c8e3b38ca92283e > > dashboard link: https://syzkaller.appspot.com/bug?extid=620cf21140fc7e772a5d > > compiler: Debian clang version 11.0.1-2 > > userspace arch: i386 > > > > Unfortunately, I don't have any reproducer for this issue yet. > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > Reported-by: syzbot+620cf21140fc7e772...@syzkaller.appspotmail.com > > > > = > > BUG: KMSAN: kernel-infoleak in kmsan_copy_to_user+0x9c/0xb0 > > mm/kmsan/kmsan_hooks.c:249 > > CPU: 1 PID: 26999 Comm: syz-executor.2 Not tainted 5.11.0-rc7-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+0x21c/0x280 lib/dump_stack.c:120 > > kmsan_report+0xfb/0x1e0 mm/kmsan/kmsan_report.c:118 > > kmsan_internal_check_memory+0x484/0x520 mm/kmsan/kmsan.c:437 > > kmsan_copy_to_user+0x9c/0xb0 mm/kmsan/kmsan_hooks.c:249 > > instrument_copy_to_user include/linux/instrumented.h:121 [inline] > > _copy_to_user+0x1ac/0x270 lib/usercopy.c:33 > > copy_to_user include/linux/uaccess.h:209 [inline] > > compat_drm_wait_vblank+0x36f/0x450 drivers/gpu/drm/drm_ioc32.c:866 > > drm_compat_ioctl+0x3f6/0x590 drivers/gpu/drm/drm_ioc32.c:995 > > __do_compat_sys_ioctl fs/ioctl.c:842 [inline] > > __se_compat_sys_ioctl+0x53d/0x1100 fs/ioctl.c:793 > > __ia32_compat_sys_ioctl+0x4a/0x70 fs/ioctl.c:793 > > do_syscall_32_irqs_on arch/x86/entry/common.c:79 [inline] > > __do_fast_syscall_32+0x102/0x160 arch/x86/entry/common.c:141 > > do_fast_syscall_32+0x6a/0xc0 arch/x86/entry/common.c:166 > > do_SYSENTER_32+0x73/0x90 arch/x86/entry/common.c:209 > > entry_SYSENTER_compat_after_hwframe+0x4d/0x5c > > RIP: 0023:0xf7f47549 > > Code: 03 74 c0 01 10 05 03 74 b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 > > 08 03 74 d8 01 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 > > 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 > > RSP: 002b:f55415fc EFLAGS: 0296 ORIG_RAX: 0036 > > RAX: ffda RBX: 0003 RCX: c018643a > > RDX: 2100 RSI: RDI: > > RBP: R08: R09: > > R10: R11: R12: > > R13: R14: R15: > > > > Uninit was stored to memory at: > > kmsan_save_stack_with_flags mm/kmsan/kmsan.c:121 [inline] > > kmsan_internal_chain_origin+0xad/0x130 mm/kmsan/kmsan.c:289 > > __msan_chain_origin+0x57/0xa0 mm/kmsan/kmsan_instr.c:147 > > compat_drm_wait_vblank+0x43c/0x450 drivers/gpu/drm/drm_ioc32.c:865 > > drm_compat_ioctl+0x3f6/0x590 drivers/gpu/drm/drm_ioc32.c:995 > > __do_compat_sys_ioctl fs/ioctl.c:842 [inline] > > __se_compat_sys_ioctl+0x53d/0x1100 fs/ioctl.c:793 > > __ia32_compat_sys_ioctl+0x4a/0x70 fs/ioctl.c:793 > > do_syscall_32_irqs_on arch/x86/entry/common.c:79 [inline] > > __do_fast_syscall_32+0x102/0x160 arch/x86/entry/common.c:141 > > do_fast_syscall_32+0x6a/0xc0 arch/x86/entry/common.c:166 > > do_SYSENTER_32+0x73/0x90 arch/x86/entry/common.c:209 > > entry_SYSENTER_compat_after_hwframe+0x4d/0x5c > > > > Local variable req@compat_drm_wait_vblank created at: > > compat_drm_wait_vblank+0x7b/0x450 drivers/gpu/drm/drm_ioc32.c:849 > > compat_drm_wait_vblank+0x7b/0x450 drivers/gpu/drm/drm_ioc32.c:849 > > > > Bytes 12-15 of 16 are uninitialized > > Memory access of size 16 starts at 88814ffe3c98 > > Data copied to user address 2100 > > = > > compat_drm_wait_vblank would need to initialize > > req.reply.tval_usec = req32.reply.tval_usec; > > before calling drm_ioctl_kernel, since it's not aliased by any > req.request.* member, and drm_wait_vblank_ioctl doesn't always write to > it. I've fixed this in commit e926c474ebee404441c838d18224cd6f246a71b7 Author: Daniel Vetter Date: Mon Feb 22 11:06:43 2021 +0100 drm/compat: Clear bounce structures Or at least tried to. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] drm: make drm_send_event_helper static
On Mon, Mar 01, 2021 at 04:19:50PM +0800, Jiapeng Chong wrote:
> Fix the following sparse warning:
>
> drivers/gpu/drm/drm_file.c:789:6: warning: symbol
> 'drm_send_event_helper' was not declared. Should it be static?
>
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Chong
> ---
> drivers/gpu/drm/drm_file.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index 7efbccf..23d8ad4 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -786,8 +786,8 @@ void drm_event_cancel_free(struct drm_device *dev,
> * The timestamp variant of dma_fence_signal is used when the caller
> * sends a valid timestamp.
> */
> -void drm_send_event_helper(struct drm_device *dev,
> -struct drm_pending_event *e, ktime_t timestamp)
> +static void drm_send_event_helper(struct drm_device *dev, struct
> drm_pending_event *e,
> +ktime_t timestamp)
For static inline functions we also remove the kerneldoc, there's not
really anything important in there. Can you pls do that and respin your
patch?
Thanks, Daniel
> {
> assert_spin_locked(>event_lock);
>
> --
> 1.8.3.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH] MAINTAINERS: update drm bug reporting URL
On Sun, Feb 28, 2021 at 05:36:58PM +0100, Pavel Turinský wrote: > The original bugzilla seems to be read-only now, linking to the gitlab > for new bugs. > > Signed-off-by: Pavel Turinský > Cc: triv...@kernel.org Queued up for 5.12, thanks for your patch. -Daniel > --- > MAINTAINERS | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index bfc1b86e3e73..434adb869522 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -5793,7 +5793,7 @@ M: David Airlie > M: Daniel Vetter > L: dri-de...@lists.freedesktop.org > S: Maintained > -B: https://bugs.freedesktop.org/ > +B: https://gitlab.freedesktop.org/drm > C: irc://chat.freenode.net/dri-devel > T: git git://anongit.freedesktop.org/drm/drm > F: Documentation/devicetree/bindings/display/ > -- > 2.20.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] dma-buf: heaps: Set VM_PFNMAP in mmap for system and cma heaps
On Fri, Feb 26, 2021 at 5:09 AM John Stultz wrote: > > Per discussion and patches here: > > https://lore.kernel.org/dri-devel/20210223105951.912577-1-daniel.vet...@ffwll.ch/ > > Daniel is planning on making VM_PFNMAP required on dmabufs. > > Thus to avoid the warn_on noise, set the VM_PFNMAP in the > system and cma heap's mmap handler. > > Cc: Daniel Vetter > Cc: Jason Gunthorpe > Cc: Christian Koenig > Cc: Sumit Semwal > Cc: Liam Mark > Cc: Chris Goldsworthy > Cc: Laura Abbott > Cc: Brian Starkey > Cc: Hridya Valsaraju > Cc: Suren Baghdasaryan > Cc: Sandeep Patil > Cc: Daniel Mentz > Cc: Ørjan Eide > Cc: Robin Murphy > Cc: Ezequiel Garcia > Cc: Simon Ser > Cc: James Jones > Cc: linux-me...@vger.kernel.org > Cc: dri-de...@lists.freedesktop.org > Signed-off-by: John Stultz System heap uses remap_pfn_range so looks fine, but cma heap inserts pages, and that's not fine for VM_PFNMAP. You need to use vm_insert_pfn or remap_pfn_range or one of the related pfn mapping functions for that too. I think this should splat when you run it. Also note that remap_pfn_range updates the vma flags already correctly for you, so you probably don't want to do that. Also given that both deal with struct page there's a ton of divergence between these two that doesn't make much sense. Maybe could even share the code fully, aside from how you allocate the struct pages. -Daniel > --- > drivers/dma-buf/heaps/cma_heap.c| 1 + > drivers/dma-buf/heaps/system_heap.c | 4 +++- > 2 files changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/dma-buf/heaps/cma_heap.c > b/drivers/dma-buf/heaps/cma_heap.c > index 364fc2f3e499..34bc3987f942 100644 > --- a/drivers/dma-buf/heaps/cma_heap.c > +++ b/drivers/dma-buf/heaps/cma_heap.c > @@ -185,6 +185,7 @@ static int cma_heap_mmap(struct dma_buf *dmabuf, struct > vm_area_struct *vma) > > vma->vm_ops = _heap_vm_ops; > vma->vm_private_data = buffer; > + vma->vm_flags |= VM_PFNMAP; > > return 0; > } > diff --git a/drivers/dma-buf/heaps/system_heap.c > b/drivers/dma-buf/heaps/system_heap.c > index 3548b20cb98c..8995e3cbfcaf 100644 > --- a/drivers/dma-buf/heaps/system_heap.c > +++ b/drivers/dma-buf/heaps/system_heap.c > @@ -228,8 +228,10 @@ static int system_heap_mmap(struct dma_buf *dmabuf, > struct vm_area_struct *vma) > return ret; > addr += PAGE_SIZE; > if (addr >= vma->vm_end) > - return 0; > + break; > } > + > + vma->vm_flags |= VM_PFNMAP; > return 0; > } > > -- > 2.25.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] drm/nouveau/pci: rework AGP dependency
defined(CONFIG_AGP) || (defined(CONFIG_AGP_MODULE) && defined(MODULE))
> > #ifndef __NVKM_PCI_AGP_H__
> > #define __NVKM_PCI_AGP_H__
> >
> > +/* SPDX-License-Identifier: MIT */
> > +#include "priv.h"
> > +#if IS_ENABLED(CONFIG_AGP)
> > void nvkm_agp_ctor(struct nvkm_pci *);
> > void nvkm_agp_dtor(struct nvkm_pci *);
> > void nvkm_agp_preinit(struct nvkm_pci *);
> > int nvkm_agp_init(struct nvkm_pci *);
> > void nvkm_agp_fini(struct nvkm_pci *);
> > -#endif
> > #else
> > static inline void nvkm_agp_ctor(struct nvkm_pci *pci) {}
> > static inline void nvkm_agp_dtor(struct nvkm_pci *pci) {}
> > @@ -17,3 +16,5 @@ static inline void nvkm_agp_preinit(struct nvkm_pci *pci)
> > {}
> > static inline int nvkm_agp_init(struct nvkm_pci *pci) { return -ENOSYS; }
> > static inline void nvkm_agp_fini(struct nvkm_pci *pci) {}
> > #endif
> > +
> > +#endif
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [RFC PATCH] drm/vkms: Add support for virtual hardware mode
On Thu, Feb 25, 2021 at 2:27 PM Gerd Hoffmann wrote: > > On Thu, Feb 25, 2021 at 11:32:08AM +0100, Daniel Vetter wrote: > > On Thu, Feb 25, 2021 at 11:25:20AM +0100, Gerd Hoffmann wrote: > > > On Thu, Feb 25, 2021 at 10:09:42AM +0100, Daniel Vetter wrote: > > > > On Wed, Feb 24, 2021 at 11:55 AM Sumera Priyadarsini > > > > wrote: > > > > > > > > > > Add a virtual hardware or vblank-less mode as a module to enable > > > > > VKMS to emulate virtual graphic drivers. This mode can be enabled > > > > > by setting enable_virtual_hw=1 at the time of loading VKMS. > > > > > > > > > > A new function vkms_crtc_composer() has been added to bypass the > > > > > vblank mode and is called directly in the atomic hook in > > > > > vkms_atomic_begin(). However, some crc captures still use vblanks > > > > > which causes the crc-based igt tests to crash. Currently, I am unsure > > > > > about how to approach one-shot implementation of crc reads so I am > > > > > still working on that. > > > > > > > > Gerd, Zack: For virtual hw like virtio-gpu or vmwgfx that does > > > > one-shot upload and damage tracking, what do you think is the best way > > > > to capture crc for validation? Assuming that's even on the plans > > > > anywhere ... > > > > > > > > Ideally it'd be a crc that the host side captures, so that we really > > > > have end-to-end validation, including the damage uploads and all that. > > > > > > Disclaimer: Not knowing much about the crc thing beside having noticed > > > it exists and seems to be used for display content checking. > > > > > > > For vkms we're going for now with one-shot crc generation after each > > > > atomic flip (or DIRTYFB ioctl call). Will need a pile of igt changes, > > > > but seems like the most fitting model. > > > > Other option would be that we'd wire up something on the kernel side > > > > that generates a crc on-demand every time igt reads a new crc value > > > > (maybe with some rate limiting). But that's not really how virtual hw > > > > works when everything is pushed explicitly to the host side. > > > > > > igt runs inside the guest, right? > > > > Yup. There's some debugfs files for capture crc on a specific CRTC. So > > supporting this would mean some virtio-gpu revision so you could ask the > > host side for a crc when you do a screen update, and the host side would > > send that back to you on a virtio channel as some kind of message. > > Waded through the source code a bit. So, the vkms crc code merges all > planes (specifically the cursor plane) before calculating the crc. > Which is a bit of a problem, we try to avoid that and rarely actually > merge the planes anywhere in the virtualization stack. Instead we > prefer to pass through the cursor plane separately, so we can -- for > example -- use that to simply set the cursor sprite of the qemu gtk > window. It's much more snappy because moving+rendering the pointer > doesn't need a round-trip to the guest then. > > So, it would be quite some effort on the host side, we would have to > merge planes just for crc calculation. > > > > You can ask qemu to write out a screen dump. > > Hmm, the (hardware) cursor is not in the screen dump either. > > A software cursor (when using for example cirrus which has no cursor > plane) would be there. > > > > Another option to access the screen would be vnc. > > vnc clients can get the cursor sprite. They can't get the position > though, only set it (it's a one-way ticket in the vnc protocol). > Typically not a problem because desktops set the position in response > to the pointer events so guest + host position match nevertheless. > But for test cases which don't look at input events and set the cursor > to a fixed place this is a problem ... Hm yeah that sounds like a bit too much to wire through, and kinda defeats end-to-end testing if qemu would take a separate path for crc generation. -Daniel > > > On-demand crc via debugfs or ioctl would work too, but yes that wouldn't > > > verify the host-side. At least not without virtio protocol extensions. > > > We could add a new command asking the host to crc the display and return > > > the result for on-demand crc. Or add a crc request flag to an existing > > > command (VIRTIO_GPU_CMD_RESOURCE_FLUSH probably). > > > > Yup, I think that's what would be needed. The q
Re: [RFC PATCH] drm/vkms: Add support for virtual hardware mode
On Thu, Feb 25, 2021 at 11:25:20AM +0100, Gerd Hoffmann wrote: > On Thu, Feb 25, 2021 at 10:09:42AM +0100, Daniel Vetter wrote: > > On Wed, Feb 24, 2021 at 11:55 AM Sumera Priyadarsini > > wrote: > > > > > > Add a virtual hardware or vblank-less mode as a module to enable > > > VKMS to emulate virtual graphic drivers. This mode can be enabled > > > by setting enable_virtual_hw=1 at the time of loading VKMS. > > > > > > A new function vkms_crtc_composer() has been added to bypass the > > > vblank mode and is called directly in the atomic hook in > > > vkms_atomic_begin(). However, some crc captures still use vblanks > > > which causes the crc-based igt tests to crash. Currently, I am unsure > > > about how to approach one-shot implementation of crc reads so I am > > > still working on that. > > > > Gerd, Zack: For virtual hw like virtio-gpu or vmwgfx that does > > one-shot upload and damage tracking, what do you think is the best way > > to capture crc for validation? Assuming that's even on the plans > > anywhere ... > > > > Ideally it'd be a crc that the host side captures, so that we really > > have end-to-end validation, including the damage uploads and all that. > > Disclaimer: Not knowing much about the crc thing beside having noticed > it exists and seems to be used for display content checking. > > > For vkms we're going for now with one-shot crc generation after each > > atomic flip (or DIRTYFB ioctl call). Will need a pile of igt changes, > > but seems like the most fitting model. > > Other option would be that we'd wire up something on the kernel side > > that generates a crc on-demand every time igt reads a new crc value > > (maybe with some rate limiting). But that's not really how virtual hw > > works when everything is pushed explicitly to the host side. > > igt runs inside the guest, right? Yup. There's some debugfs files for capture crc on a specific CRTC. So supporting this would mean some virtio-gpu revision so you could ask the host side for a crc when you do a screen update, and the host side would send that back to you on a virtio channel as some kind of message. > You can ask qemu to write out a screen dump. Reading that and calculate > a crc from it should be easy. But the tricky part is how to coordinate > guest and host then. qemu autotesting typically runs on the host, > connected to qemu (monitor) and guest (ssh or serial console) so it can > control both host and guest side. > > Another option to access the screen would be vnc. With user networking > and a guest forwarding rule it should be possible to allow the guest > access the qemu vnc server for its own display. Would be more effort to > capture the display, but it would for the most part take the host out of > the picture. The guest could coordinate everything on its own then. > > On-demand crc via debugfs or ioctl would work too, but yes that wouldn't > verify the host-side. At least not without virtio protocol extensions. > We could add a new command asking the host to crc the display and return > the result for on-demand crc. Or add a crc request flag to an existing > command (VIRTIO_GPU_CMD_RESOURCE_FLUSH probably). Yup, I think that's what would be needed. The question here is, what do you think would be the most natural way for virtio host side stack to support this? If it ever happens ofc. igt does support some other ways to capture crc (chamelium boards acting as display sink). The nice thing with having this in the kernel driver as part of the "hardware" is that you can guarantee that the frames are a match. Maybe more relevant for real hw with vblank, where it's also interesting to know whether the screen did update on the right frame. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [RFC PATCH] drm/vkms: Add support for virtual hardware mode
>
> return vkms_create(config);
> }
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index 35540c7c4416..d4a45518639c 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.h
> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> @@ -85,6 +85,7 @@ struct vkms_device;
> struct vkms_config {
> bool writeback;
> bool cursor;
> + bool virtual_hw;
> /* only set when instantiated */
> struct vkms_device *dev;
> };
> @@ -127,6 +128,7 @@ int vkms_verify_crc_source(struct drm_crtc *crtc, const
> char *source_name,
> /* Composer Support */
> void vkms_composer_worker(struct work_struct *work);
> void vkms_set_composer(struct vkms_output *out, bool enabled);
> +void vkms_crtc_composer(struct vkms_crtc_state *crtc_state);
>
> /* Writeback */
> int vkms_enable_writeback_connector(struct vkms_device *vkmsdev);
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PULL] fixes around VM_PFNMAP and follow_pfn for 5.12 merge window
On Tue, Feb 23, 2021 at 2:42 AM Linus Torvalds
wrote:
>
> On Mon, Feb 22, 2021 at 2:25 AM Daniel Vetter wrote:
> >
> > Cc all the mailing lists ... my usual script crashed and I had to
> > hand-roll the email and screwed it up ofc :-/
>
> Oh, and my reply thus also became just a reply to you personally.
>
> So repeating it here, in case somebody has comments about that
> access_process_vm() issue.
>
> On Mon, Feb 22, 2021 at 2:23 AM Daniel Vetter wrote:
> >
> > I've stumbled over this for my own learning and then realized there's a
> > bunch of races around VM_PFNMAP mappings vs follow pfn.
> >
> > If you're happy with this [..]
>
> Happy? No. But it seems an improvement.
>
> I did react to some of this: commit 0fb1b1ed7dd9 ("/dev/mem: Only set
> filp->f_mapping") talks about _what_ it does, but not so much _why_ it
> does it. It doesn't seem to actually matter, and seems almost
> incidental (because you've looked at f_mapping and i_mapping just
> didn't matter but was adjacent.
Yeah it doesn't matter, it just confused me, so I wrote a patch to
remove it and get experts to tell me it actually really doesn't
matter. So that's really the entirety of that one. Like I said, I
mostly stumbled into this rat hole because I had some questions,
wanted to understand stuff better, and the code did not provide
consistent answers :-)
> And generic_access_phys() remains horrific. Does anything actually use
> this outside of the odd magical access_remote_vm() code?
>
> I'm wondering if that code shouldn't just be removed entirely. It's
> quite old, I'm not sure it's really relevant. See commit 28b2ee20c7cb
> ("access_process_vm device memory infrastructure").
>
> I guess you do debug the X server, but still.. Do you actually ever
> look at device memory through the debugger? I'd hope that you'd use an
> access function and make gdb call it in the context of the debuggee?
tbh I had no idea this exists, but yeah I've fired up gdb on some of
the register dumper tools we have that use the pci mmap files, and
after fixing some thinko in the first version it was still working
after the conversion.
>From a quick git grep almost nothing wires this up, so yeah no idea
whether it's still used. Definitely not useful for X hackery anymore.
It is wired up for uio framework, and I guess for debugging userspace
drivers this comes handy. Although letting your debugger do
reads/writes to device registers sounds scary.
-Daniel
> Whatever. I've pulled it, and I'm not _unhappy_ with it, but I'd also
> not call myself overly giddy and over the moon happy about this code.
>
> Linus
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH] fbdev: atyfb: add stubs for aty_{ld,st}_lcd()
On Sun, Feb 21, 2021 at 07:28:53PM -0800, Randy Dunlap wrote:
> Fix build errors when these functions are not defined.
>
> ../drivers/video/fbdev/aty/atyfb_base.c: In function 'aty_power_mgmt':
> ../drivers/video/fbdev/aty/atyfb_base.c:2002:7: error: implicit declaration
> of function 'aty_ld_lcd'; did you mean 'aty_ld_8'?
> [-Werror=implicit-function-declaration]
> 2002 | pm = aty_ld_lcd(POWER_MANAGEMENT, par);
> ../drivers/video/fbdev/aty/atyfb_base.c:2004:2: error: implicit declaration
> of function 'aty_st_lcd'; did you mean 'aty_st_8'?
> [-Werror=implicit-function-declaration]
> 2004 | aty_st_lcd(POWER_MANAGEMENT, pm, par);
>
> Signed-off-by: Randy Dunlap
> Reported-by: kernel test robot
> Cc: linux-fb...@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: Bartlomiej Zolnierkiewicz
> Cc: Sam Ravnborg
> Cc: Daniel Vetter
> Cc: David Airlie
> Cc: Jani Nikula
stuffed into drm-misc-next-fixes for 5.12, thanks for your patch.
-Daniel
> ---
> drivers/video/fbdev/aty/atyfb_base.c |9 +
> 1 file changed, 9 insertions(+)
>
> --- linux-next-20210219.orig/drivers/video/fbdev/aty/atyfb_base.c
> +++ linux-next-20210219/drivers/video/fbdev/aty/atyfb_base.c
> @@ -175,6 +175,15 @@ u32 aty_ld_lcd(int index, const struct a
> return aty_ld_le32(LCD_DATA, par);
> }
> }
> +#else /* defined(CONFIG_PMAC_BACKLIGHT) || defined(CONFIG_FB_ATY_BACKLIGHT) \
> + defined(CONFIG_FB_ATY_GENERIC_LCD) */
> +void aty_st_lcd(int index, u32 val, const struct atyfb_par *par)
> +{ }
> +
> +u32 aty_ld_lcd(int index, const struct atyfb_par *par)
> +{
> + return 0;
> +}
> #endif /* defined(CONFIG_PMAC_BACKLIGHT) || defined
> (CONFIG_FB_ATY_GENERIC_LCD) */
>
> #ifdef CONFIG_FB_ATY_GENERIC_LCD
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PULL] fixes around VM_PFNMAP and follow_pfn for 5.12 merge window
Cc all the mailing lists ... my usual script crashed and I had to
hand-roll the email and screwed it up ofc :-/
-Daniel
On Mon, Feb 22, 2021 at 11:23 AM Daniel Vetter wrote:
>
> Hi Linus,
>
> Another small pull from you to ponder.
>
> This is the first part of a patch series I've been working on for a while:
>
> https://lore.kernel.org/dri-devel/20201127164131.2244124-1-daniel.vet...@ffwll.ch/
>
> I've stumbled over this for my own learning and then realized there's a
> bunch of races around VM_PFNMAP mappings vs follow pfn.
>
> If you're happy with this then I'll follow up with the media patches to
> mark their leftover use of follow_pfn as unsafe (it's uapi, so unfixable
> issue, all we can do is a config option to harden the kernel). Plus
> hopefully kvm and vfio are then fixed too (you've been on the recent kvm
> thread where this popped up again) so that we can sunset follow_pfn usage
> completely.
>
> The last two patches have only been in linux-next in their current form
> for a week, there was some issue for platforms with HAVE_PCI_LEGACY (not
> that many) which took some sorting out. But looks all good now.
>
> Cheers, Daniel
>
> The following changes since commit 7c53f6b671f4aba70ff15e1b05148b10d58c2837:
>
> Linux 5.11-rc3 (2021-01-10 14:34:50 -0800)
>
> are available in the Git repository at:
>
> git://anongit.freedesktop.org/drm/drm
> tags/topic/iomem-mmap-vs-gup-2021-02-22
>
> for you to fetch changes up to 636b21b50152d4e203223ee337aca1cb3c1bfe53:
>
> PCI: Revoke mappings like devmem (2021-02-11 15:59:19 +0100)
>
>
> Fixes around VM_FPNMAP and follow_pfn
>
> - replace mm/frame_vector.c by get_user_pages in misc/habana and
> drm/exynos drivers, then move that into media as it's sole user
> - close race in generic_access_phys
> - s390 pci ioctl fix of this series landed in 5.11 already
> - properly revoke iomem mappings (/dev/mem, pci files)
>
>
> Daniel Vetter (13):
> drm/exynos: Stop using frame_vector helpers
> drm/exynos: Use FOLL_LONGTERM for g2d cmdlists
> misc/habana: Stop using frame_vector helpers
> misc/habana: Use FOLL_LONGTERM for userptr
> mm/frame-vector: Use FOLL_LONGTERM
> media: videobuf2: Move frame_vector into media subsystem
> mm: Close race in generic_access_phys
> PCI: Obey iomem restrictions for procfs mmap
> /dev/mem: Only set filp->f_mapping
> resource: Move devmem revoke code to resource framework
> sysfs: Support zapping of binary attr mmaps
> PCI: Also set up legacy files only after sysfs init
> PCI: Revoke mappings like devmem
>
> drivers/char/mem.c| 86
> +
> drivers/gpu/drm/exynos/Kconfig| 1 -
> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 48
> -
> drivers/media/common/videobuf2/Kconfig| 1 -
> drivers/media/common/videobuf2/Makefile | 1 +
> {mm => drivers/media/common/videobuf2}/frame_vector.c | 55
> +++---
> drivers/media/common/videobuf2/videobuf2-memops.c | 3 +--
> drivers/media/platform/omap/Kconfig | 1 -
> drivers/misc/habanalabs/Kconfig | 1 -
> drivers/misc/habanalabs/common/habanalabs.h | 6 +++--
> drivers/misc/habanalabs/common/memory.c | 52
> +++-
> drivers/pci/pci-sysfs.c | 11 +
> drivers/pci/proc.c| 6 +
> fs/sysfs/file.c | 11 +
> include/linux/ioport.h| 6 +
> include/linux/mm.h| 45
> ++
> include/linux/sysfs.h | 2 ++
> include/media/frame_vector.h | 47
>
> include/media/videobuf2-core.h| 1 +
> kernel/resource.c | 98
> ++-
> mm/Kconfig| 3 ---
> mm/Makefile | 1 -
> mm/memory.c | 46
> ++++++++---
> 23 files changed, 287 insertions(+), 245 deletions(-)
> rename {mm => drivers/media/common/videobuf2}/frame_vector.c (85%)
> create mode 100644 include/media/frame_vector.h
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PULL] topic/kcmp-kconfig
Hi Linus, One patch pull request for you to ponder in the hopefully less stressful 2nd week of the merge window :-) It's also marked cc: stable so people can stop building kernels that don't work so well. topic/kcmp-kconfig-2021-02-22: kconfig for kcmp syscall drm userspaces uses this, systemd uses this, makes sense to pull it out from the checkpoint-restore bundle. Kees reviewed this from security pov and is happy with the final version. LWN coverage: https://lwn.net/Articles/845448/ Cheers, Daniel The following changes since commit f40ddce88593482919761f74910f42f4b84c004b: Linux 5.11 (2021-02-14 14:32:24 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/topic/kcmp-kconfig-2021-02-22 for you to fetch changes up to bfe3911a91047557eb0e620f95a370aee6a248c7: kcmp: Support selection of SYS_kcmp without CHECKPOINT_RESTORE (2021-02-16 09:59:41 +0100) kconfig for kcmp syscall drm userspaces uses this, systemd uses this, makes sense to pull it out from the checkpoint-restore bundle. Kees reviewed this from security pov and is happy with the final version. LWN coverage: https://lwn.net/Articles/845448/ Chris Wilson (1): kcmp: Support selection of SYS_kcmp without CHECKPOINT_RESTORE drivers/gpu/drm/Kconfig | 3 +++ fs/eventpoll.c| 4 ++-- include/linux/eventpoll.h | 2 +- init/Kconfig | 11 +++ kernel/Makefile | 2 +- tools/testing/selftests/seccomp/seccomp_bpf.c | 2 +- 6 files changed, 19 insertions(+), 5 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] mutex: nuke mutex_trylock_recursive
On Tue, Feb 16, 2021 at 09:21:46AM +0100, Christian König wrote:
> The last user went away in the 5.11 cycle.
>
> Signed-off-by: Christian König
Nice.
Reviewed-by: Daniel Vetter
I think would be good to still stuff this into 5.12 before someone
resurrects this zombie.
-Daniel
> ---
> include/linux/mutex.h | 25 -
> kernel/locking/mutex.c | 10 --
> scripts/checkpatch.pl | 6 --
> 3 files changed, 41 deletions(-)
>
> diff --git a/include/linux/mutex.h b/include/linux/mutex.h
> index dcd185cbfe79..0cd631a19727 100644
> --- a/include/linux/mutex.h
> +++ b/include/linux/mutex.h
> @@ -199,29 +199,4 @@ extern void mutex_unlock(struct mutex *lock);
>
> extern int atomic_dec_and_mutex_lock(atomic_t *cnt, struct mutex *lock);
>
> -/*
> - * These values are chosen such that FAIL and SUCCESS match the
> - * values of the regular mutex_trylock().
> - */
> -enum mutex_trylock_recursive_enum {
> - MUTEX_TRYLOCK_FAILED= 0,
> - MUTEX_TRYLOCK_SUCCESS = 1,
> - MUTEX_TRYLOCK_RECURSIVE,
> -};
> -
> -/**
> - * mutex_trylock_recursive - trylock variant that allows recursive locking
> - * @lock: mutex to be locked
> - *
> - * This function should not be used, _ever_. It is purely for hysterical GEM
> - * raisins, and once those are gone this will be removed.
> - *
> - * Returns:
> - * - MUTEX_TRYLOCK_FAILED- trylock failed,
> - * - MUTEX_TRYLOCK_SUCCESS - lock acquired,
> - * - MUTEX_TRYLOCK_RECURSIVE - we already owned the lock.
> - */
> -extern /* __deprecated */ __must_check enum mutex_trylock_recursive_enum
> -mutex_trylock_recursive(struct mutex *lock);
> -
> #endif /* __LINUX_MUTEX_H */
> diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
> index 5352ce50a97e..adb935090768 100644
> --- a/kernel/locking/mutex.c
> +++ b/kernel/locking/mutex.c
> @@ -86,16 +86,6 @@ bool mutex_is_locked(struct mutex *lock)
> }
> EXPORT_SYMBOL(mutex_is_locked);
>
> -__must_check enum mutex_trylock_recursive_enum
> -mutex_trylock_recursive(struct mutex *lock)
> -{
> - if (unlikely(__mutex_owner(lock) == current))
> - return MUTEX_TRYLOCK_RECURSIVE;
> -
> - return mutex_trylock(lock);
> -}
> -EXPORT_SYMBOL(mutex_trylock_recursive);
> -
> static inline unsigned long __owner_flags(unsigned long owner)
> {
> return owner & MUTEX_FLAGS;
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 92e888ed939f..15f7f4fa6b99 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -7069,12 +7069,6 @@ sub process {
> }
> }
>
> -# check for mutex_trylock_recursive usage
> - if ($line =~ /mutex_trylock_recursive/) {
> - ERROR("LOCKING",
> - "recursive locking is bad, do not use this
> ever.\n" . $herecurr);
> - }
> -
> # check for lockdep_set_novalidate_class
> if ($line =~ /^.\s*lockdep_set_novalidate_class\s*\(/ ||
> $line =~ /__lockdep_no_validate__\s*\)/ ) {
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: DMA-buf and uncached system memory
On Mon, Feb 15, 2021 at 09:58:08AM +0100, Christian König wrote: > Hi guys, > > we are currently working an Freesync and direct scan out from system memory > on AMD APUs in A+A laptops. > > On problem we stumbled over is that our display hardware needs to scan out > from uncached system memory and we currently don't have a way to communicate > that through DMA-buf. > > For our specific use case at hand we are going to implement something driver > specific, but the question is should we have something more generic for > this? > > After all the system memory access pattern is a PCIe extension and as such > something generic. Yes it's a problem, and it's a complete mess. So the defacto rules are: 1. importer has to do coherent transactions to snoop cpu caches. This way both modes work: - if the buffer is cached, we're fine - if the buffer is not cached, but the exporter has flushed all the caches, you're mostly just wasting time on inefficient bus cycles. Also this doesn't work if your CPU doesn't just drop clean cachelines. Like I thing some ARM are prone to do, not idea about AMD, Intel is guaranteed to drop them which is why the uncached scanout for integrated Intel + amd discrete "works". 2. exporters picks the mode freely, and can even change it at runtime (i915 does this, since we don't have an "allocate for scanout" flag wired through consistently). This doesn't work on arm, there the rule is "all devices in the same system must use the same mode". 3. This should be solved at the dma-buf layer, but the dma-api refuses to tell you this information (at least for dma_alloc_coherent). And I'm not going to deal with the bikeshed that would bring into my inbox. Or at least there's always been screaming that drivers shouldn't peek behind the abstraction. So I think if AMD also guarantees to drop clean cachelines just do the same thing we do right now for intel integrated + discrete amd, but in reserve. It's fragile, but it does work. What we imo shouldn't do is driver private interfaces here, that's just going to make the problem worse long term. Or at least driver-private interfaces that spawn across drivers behind dma-buf, because imo this is really a problem that dma-buf should solve. If you do want to solve this at the dma-buf level I can try and point you at the respective i915 and amdgpu code that makes the magic work - I've had to fix it a few times in the past. I'm not sure whether we'd need to pass the dynamic nature through though, i.e. whether we want to be able to scan out imported dma-buf and hence request they be used in uncached mode. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH v3] kcmp: Support selection of SYS_kcmp without CHECKPOINT_RESTORE
On Mon, Feb 08, 2021 at 02:12:00PM -0800, Kees Cook wrote:
> On Fri, Feb 05, 2021 at 10:00:12PM +, Chris Wilson wrote:
> > Userspace has discovered the functionality offered by SYS_kcmp and has
> > started to depend upon it. In particular, Mesa uses SYS_kcmp for
> > os_same_file_description() in order to identify when two fd (e.g. device
> > or dmabuf) point to the same struct file. Since they depend on it for
> > core functionality, lift SYS_kcmp out of the non-default
> > CONFIG_CHECKPOINT_RESTORE into the selectable syscall category.
> >
> > Rasmus Villemoes also pointed out that systemd uses SYS_kcmp to
> > deduplicate the per-service file descriptor store.
> >
> > Note that some distributions such as Ubuntu are already enabling
> > CHECKPOINT_RESTORE in their configs and so, by extension, SYS_kcmp.
> >
> > References: https://gitlab.freedesktop.org/drm/intel/-/issues/3046
> > Signed-off-by: Chris Wilson
>
> Thanks!
>
> Reviewed-by: Kees Cook
Thanks for reviews, I stuffed it into a topic branch and plan to
send it to Linus later this week.
Cheers, Daniel
>
> -Kees
>
> > Cc: Kees Cook
> > Cc: Andy Lutomirski
> > Cc: Will Drewry
> > Cc: Andrew Morton
> > Cc: Dave Airlie
> > Cc: Daniel Vetter
> > Cc: Lucas Stach
> > Cc: Rasmus Villemoes
> > Cc: Cyrill Gorcunov
> > Cc: sta...@vger.kernel.org
> > Acked-by: Daniel Vetter # DRM depends on kcmp
> > Acked-by: Rasmus Villemoes # systemd uses kcmp
> >
> > ---
> > v2:
> > - Default n.
> > - Borrrow help message from man kcmp.
> > - Export get_epoll_tfile_raw_ptr() for CONFIG_KCMP
> > v3:
> > - Select KCMP for CONFIG_DRM
> > ---
> > drivers/gpu/drm/Kconfig | 3 +++
> > fs/eventpoll.c| 4 ++--
> > include/linux/eventpoll.h | 2 +-
> > init/Kconfig | 11 +++
> > kernel/Makefile | 2 +-
> > tools/testing/selftests/seccomp/seccomp_bpf.c | 2 +-
> > 6 files changed, 19 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > index 0973f408d75f..af6c6d214d91 100644
> > --- a/drivers/gpu/drm/Kconfig
> > +++ b/drivers/gpu/drm/Kconfig
> > @@ -15,6 +15,9 @@ menuconfig DRM
> > select I2C_ALGOBIT
> > select DMA_SHARED_BUFFER
> > select SYNC_FILE
> > +# gallium uses SYS_kcmp for os_same_file_description() to de-duplicate
> > +# device and dmabuf fd. Let's make sure that is available for our
> > userspace.
> > + select KCMP
> > help
> > Kernel-level support for the Direct Rendering Infrastructure (DRI)
> > introduced in XFree86 4.0. If you say Y here, you need to select
> > diff --git a/fs/eventpoll.c b/fs/eventpoll.c
> > index a829af074eb5..3196474cbe24 100644
> > --- a/fs/eventpoll.c
> > +++ b/fs/eventpoll.c
> > @@ -979,7 +979,7 @@ static struct epitem *ep_find(struct eventpoll *ep,
> > struct file *file, int fd)
> > return epir;
> > }
> >
> > -#ifdef CONFIG_CHECKPOINT_RESTORE
> > +#ifdef CONFIG_KCMP
> > static struct epitem *ep_find_tfd(struct eventpoll *ep, int tfd, unsigned
> > long toff)
> > {
> > struct rb_node *rbp;
> > @@ -1021,7 +1021,7 @@ struct file *get_epoll_tfile_raw_ptr(struct file
> > *file, int tfd,
> >
> > return file_raw;
> > }
> > -#endif /* CONFIG_CHECKPOINT_RESTORE */
> > +#endif /* CONFIG_KCMP */
> >
> > /**
> > * Adds a new entry to the tail of the list in a lockless way, i.e.
> > diff --git a/include/linux/eventpoll.h b/include/linux/eventpoll.h
> > index 0350393465d4..593322c946e6 100644
> > --- a/include/linux/eventpoll.h
> > +++ b/include/linux/eventpoll.h
> > @@ -18,7 +18,7 @@ struct file;
> >
> > #ifdef CONFIG_EPOLL
> >
> > -#ifdef CONFIG_CHECKPOINT_RESTORE
> > +#ifdef CONFIG_KCMP
> > struct file *get_epoll_tfile_raw_ptr(struct file *file, int tfd, unsigned
> > long toff);
> > #endif
> >
> > diff --git a/init/Kconfig b/init/Kconfig
> > index b77c60f8b963..9cc7436b2f73 100644
> > --- a/init/Kconfig
> > +++ b/init/Kconfig
> > @@ -1194,6 +1194,7 @@ endif # NAMESPACES
> > config CHECKPOINT_RESTORE
> > bool "Checkpoint/restore support"
> > select PROC_CHILDREN
> > + select KCMP
> > default n
> > help
> > Enables additional kernel featu
Re: [PATCH] video: use getter/setter functions
On Wed, Feb 10, 2021 at 04:12:58PM +, Lee Jones wrote:
> On Wed, 10 Feb 2021, Daniel Vetter wrote:
>
> > On Wed, Feb 10, 2021 at 08:23:41AM +, Lee Jones wrote:
> > > On Tue, 09 Feb 2021, Julia Lawall wrote:
> > >
> > > > Use getter and setter functions, for platform_device structures and a
> > > > spi_device structure.
> > > >
> > > > Signed-off-by: Julia Lawall
> > > >
> > > > ---
> > > > drivers/video/backlight/qcom-wled.c |
> > > >2 +-
> > >
> > > This patch is fine.
> > >
> > > Could you please split it out and submit it separately though please.
> >
> > Or just apply the entire patch through backlight tree, there's nothing
> > going on in fbdev anyway I think.
> >
> > Acked-by: Daniel Vetter
>
> I can do that. Is that an fbdev Ack?
Yeah defacto I'm somehow stuck with that as maintainer of last resort :-)
Iirc we've got an S: orphaned entry pointing at drm.git trees.
-Daniel
>
> > > > drivers/video/fbdev/amifb.c |
> > > >4 ++--
> > > > drivers/video/fbdev/da8xx-fb.c |
> > > >4 ++--
> > > > drivers/video/fbdev/imxfb.c |
> > > >2 +-
> > > > drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c |
> > > >6 +++---
> > > > drivers/video/fbdev/omap2/omapfb/dss/dpi.c |
> > > >4 ++--
> > > > drivers/video/fbdev/omap2/omapfb/dss/dsi.c |
> > > >4 ++--
> > > > drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c |
> > > >2 +-
> > > > drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c |
> > > >2 +-
> > > > drivers/video/fbdev/xilinxfb.c |
> > > >2 +-
> > > > 10 files changed, 16 insertions(+), 16 deletions(-)
> > >
> > > ...]
> > >
> > > > diff --git a/drivers/video/backlight/qcom-wled.c
> > > > b/drivers/video/backlight/qcom-wled.c
> > > > index 3bc7800eb0a9..091f07e7c145 100644
> > > > --- a/drivers/video/backlight/qcom-wled.c
> > > > +++ b/drivers/video/backlight/qcom-wled.c
> > > > @@ -1692,7 +1692,7 @@ static int wled_probe(struct platform_device
> > > > *pdev)
> > > >
> > > > static int wled_remove(struct platform_device *pdev)
> > > > {
> > > > - struct wled *wled = dev_get_drvdata(>dev);
> > > > + struct wled *wled = platform_get_drvdata(pdev);
> > > >
> > > > mutex_destroy(>lock);
> > > > cancel_delayed_work_sync(>ovp_work);
> > >
> > > For my own reference (apply this as-is to your sign-off block):
> > >
> > > Acked-for-Backlight-by: Lee Jones
> > >
> >
>
> --
> Lee Jones [李琼斯]
> Senior Technical Lead - Developer Services
> Linaro.org │ Open source software for Arm SoCs
> Follow Linaro: Facebook | Twitter | Blog
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v3 4/6] drm/sprd: add Unisoc's drm display controller driver
On Thu, Feb 11, 2021 at 04:21:51PM +0800, Kevin Tang wrote: > Daniel Vetter 于2021年2月3日周三 下午10:15写道： > > > On Tue, Jan 05, 2021 at 09:46:05PM +0800, Kevin Tang wrote: > > > Adds DPU(Display Processor Unit) support for the Unisoc's display > > subsystem. > > > It's support multi planes, scaler, rotation, PQ(Picture Quality) and > > more. > > > > > > Cc: Orson Zhai > > > Cc: Chunyan Zhang > > > Signed-off-by: Kevin Tang > > > > > > v2: > > > - Use drm_xxx to replace all DRM_XXX. > > > - Use kzalloc to replace devm_kzalloc for sprd_dpu structure init. > > > > > > v3: > > > - Remove dpu_layer stuff layer and commit layers by aotmic_update > > > > Scrolling through the code looks very tidy, only thing I spotted is > > that you could use the new drmm_ infrastructure we just landed. See > > comments below, with that addressed: > > > > Hi daniel, drmm_helpers seem still on drm-misc, so i need to switch to > drm-misc(not mainline) and then update my patch on drm-misc? Best practice is generally to base your work on top of linux-next, but drm-misc-next for drm drivers is usally a good target too. The code should all land in 5.12, plus new drivers will land for 5.13 only anyway (5.12 is in feature freeze already). -Daniel > > > > > Acked-by: Daniel Vetter > > > --- > > > drivers/gpu/drm/sprd/Kconfig| 1 + > > > drivers/gpu/drm/sprd/Makefile | 4 +- > > > drivers/gpu/drm/sprd/sprd_dpu.c | 985 > > > > > drivers/gpu/drm/sprd/sprd_dpu.h | 120 + > > > drivers/gpu/drm/sprd/sprd_drm.c | 1 + > > > drivers/gpu/drm/sprd/sprd_drm.h | 2 + > > > 6 files changed, insertions(+), 2 deletions(-) > > > create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.c > > > create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.h > > > > > > diff --git a/drivers/gpu/drm/sprd/Kconfig b/drivers/gpu/drm/sprd/Kconfig > > > index 6e80cc9..9b4ef9a 100644 > > > --- a/drivers/gpu/drm/sprd/Kconfig > > > +++ b/drivers/gpu/drm/sprd/Kconfig > > > @@ -3,6 +3,7 @@ config DRM_SPRD > > > depends on ARCH_SPRD || COMPILE_TEST > > > depends on DRM && OF > > > select DRM_KMS_HELPER > > > + select VIDEOMODE_HELPERS > > > select DRM_GEM_CMA_HELPER > > > select DRM_KMS_CMA_HELPER > > > select DRM_MIPI_DSI > > > diff --git a/drivers/gpu/drm/sprd/Makefile > > b/drivers/gpu/drm/sprd/Makefile > > > index 86d95d9..6c25bfa 100644 > > > --- a/drivers/gpu/drm/sprd/Makefile > > > +++ b/drivers/gpu/drm/sprd/Makefile > > > @@ -1,5 +1,5 @@ > > > # SPDX-License-Identifier: GPL-2.0 > > > > > > -subdir-ccflags-y += -I$(srctree)/$(src) > > > +obj-y := sprd_drm.o \ > > > + sprd_dpu.o > > > > > > -obj-y := sprd_drm.o > > > diff --git a/drivers/gpu/drm/sprd/sprd_dpu.c > > b/drivers/gpu/drm/sprd/sprd_dpu.c > > > new file mode 100644 > > > index 000..d562d44 > > > --- /dev/null > > > +++ b/drivers/gpu/drm/sprd/sprd_dpu.c > > > @@ -0,0 +1,985 @@ > > > +// SPDX-License-Identifier: GPL-2.0 > > > +/* > > > + * Copyright (C) 2020 Unisoc Inc. > > > + */ > > > + > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > + > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > + > > > +#include "sprd_drm.h" > > > +#include "sprd_dpu.h" > > > + > > > +/* Global control registers */ > > > +#define REG_DPU_CTRL 0x04 > > > +#define REG_DPU_CFG0 0x08 > > > +#define REG_PANEL_SIZE 0x20 > > > +#define REG_BLEND_SIZE 0x24 > > > +#define REG_BG_COLOR 0x2C > > > + > > > +/* Layer0 control registers */ > > > +#define REG_LAY_BASE_ADDR0 0x30 > > > +#define REG_LAY_BASE_ADDR1 0x34 > > > +#define REG_LAY_BASE_ADDR2 0x38 > > > +#define REG_LAY_CTRL 0x40 > > > +#define REG_LAY_SIZE 0x44 > > > +#define REG_LAY_PITCH0x48 > > > +#define REG_LAY_POS 0x4C > > > +#define REG_
Re: [PATCH] PCI: Also set up legacy files only after sysfs init
On Wed, Feb 10, 2021 at 10:40 PM Bjorn Helgaas wrote:
>
> On Fri, Feb 05, 2021 at 02:36:32PM +0100, Daniel Vetter wrote:
> > We are already doing this for all the regular sysfs files on PCI
> > devices, but not yet on the legacy io files on the PCI buses. Thus far
> > no problem, but in the next patch I want to wire up iomem revoke
> > support. That needs the vfs up and running already to make sure that
> > iomem_get_mapping() works.
> >
> > Wire it up exactly like the existing code in
> > pci_create_sysfs_dev_files(). Note that pci_remove_legacy_files()
> > doesn't need a check since the one for pci_bus->legacy_io is
> > sufficient.
> >
> > An alternative solution would be to implement a callback in sysfs to
> > set up the address space from iomem_get_mapping() when userspace calls
> > mmap(). This also works, but Greg didn't really like that just to work
> > around an ordering issue when the kernel loads initially.
> >
> > v2: Improve commit message (Bjorn)
> >
> > Signed-off-by: Daniel Vetter
>
> Acked-by: Bjorn Helgaas
>
> I wish we weren't extending a known-racy mechanism to do this, but at
> least we're not *adding* a brand new race.
Yeah it's not great. Thanks for looking at both again, I'll fix up the
typos on the 2nd one and merge them both.
Cheers, Daniel
>
> > Cc: Stephen Rothwell
> > Cc: Jason Gunthorpe
> > Cc: Kees Cook
> > Cc: Dan Williams
> > Cc: Andrew Morton
> > Cc: John Hubbard
> > Cc: Jérôme Glisse
> > Cc: Jan Kara
> > Cc: Dan Williams
> > Cc: Greg Kroah-Hartman
> > Cc: linux...@kvack.org
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux-samsung-...@vger.kernel.org
> > Cc: linux-me...@vger.kernel.org
> > Cc: Bjorn Helgaas
> > Cc: linux-...@vger.kernel.org
> > ---
> > drivers/pci/pci-sysfs.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> > index fb072f4b3176..0c45b4f7b214 100644
> > --- a/drivers/pci/pci-sysfs.c
> > +++ b/drivers/pci/pci-sysfs.c
> > @@ -927,6 +927,9 @@ void pci_create_legacy_files(struct pci_bus *b)
> > {
> > int error;
> >
> > + if (!sysfs_initialized)
> > + return;
> > +
> > b->legacy_io = kcalloc(2, sizeof(struct bin_attribute),
> > GFP_ATOMIC);
> > if (!b->legacy_io)
> > @@ -1448,6 +1451,7 @@ void pci_remove_sysfs_dev_files(struct pci_dev *pdev)
> > static int __init pci_sysfs_init(void)
> > {
> > struct pci_dev *pdev = NULL;
> > + struct pci_bus *pbus = NULL;
> > int retval;
> >
> > sysfs_initialized = 1;
> > @@ -1459,6 +1463,9 @@ static int __init pci_sysfs_init(void)
> > }
> > }
> >
> > + while ((pbus = pci_find_next_bus(pbus)))
> > + pci_create_legacy_files(pbus);
> > +
> > return 0;
> > }
> > late_initcall(pci_sysfs_init);
> > --
> > 2.30.0
> >
> >
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH] PCI: Also set up legacy files only after sysfs init
Hi Bjorn,
Can you ack this for merging through my topic branch with the other
follow_pfn/iomem revoke fixes for 5.12?
If not, what's the plan for getting this (or equivalent functionality)
in for 5.13? I have more of these follow_pfn/iomem revoke patches on
top, so I'd like to get the first cut merged sooner than later if
possible. And the other prep work has been in -next since -rc1.
Thanks, Daniel
On Fri, Feb 5, 2021 at 2:36 PM Daniel Vetter wrote:
>
> We are already doing this for all the regular sysfs files on PCI
> devices, but not yet on the legacy io files on the PCI buses. Thus far
> no problem, but in the next patch I want to wire up iomem revoke
> support. That needs the vfs up and running already to make sure that
> iomem_get_mapping() works.
>
> Wire it up exactly like the existing code in
> pci_create_sysfs_dev_files(). Note that pci_remove_legacy_files()
> doesn't need a check since the one for pci_bus->legacy_io is
> sufficient.
>
> An alternative solution would be to implement a callback in sysfs to
> set up the address space from iomem_get_mapping() when userspace calls
> mmap(). This also works, but Greg didn't really like that just to work
> around an ordering issue when the kernel loads initially.
>
> v2: Improve commit message (Bjorn)
>
> Signed-off-by: Daniel Vetter
> Cc: Stephen Rothwell
> Cc: Jason Gunthorpe
> Cc: Kees Cook
> Cc: Dan Williams
> Cc: Andrew Morton
> Cc: John Hubbard
> Cc: Jérôme Glisse
> Cc: Jan Kara
> Cc: Dan Williams
> Cc: Greg Kroah-Hartman
> Cc: linux...@kvack.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-me...@vger.kernel.org
> Cc: Bjorn Helgaas
> Cc: linux-...@vger.kernel.org
> ---
> drivers/pci/pci-sysfs.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> index fb072f4b3176..0c45b4f7b214 100644
> --- a/drivers/pci/pci-sysfs.c
> +++ b/drivers/pci/pci-sysfs.c
> @@ -927,6 +927,9 @@ void pci_create_legacy_files(struct pci_bus *b)
> {
> int error;
>
> + if (!sysfs_initialized)
> + return;
> +
> b->legacy_io = kcalloc(2, sizeof(struct bin_attribute),
>GFP_ATOMIC);
> if (!b->legacy_io)
> @@ -1448,6 +1451,7 @@ void pci_remove_sysfs_dev_files(struct pci_dev *pdev)
> static int __init pci_sysfs_init(void)
> {
> struct pci_dev *pdev = NULL;
> + struct pci_bus *pbus = NULL;
> int retval;
>
> sysfs_initialized = 1;
> @@ -1459,6 +1463,9 @@ static int __init pci_sysfs_init(void)
> }
> }
>
> + while ((pbus = pci_find_next_bus(pbus)))
> + pci_create_legacy_files(pbus);
> +
> return 0;
> }
> late_initcall(pci_sysfs_init);
> --
> 2.30.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [RFC][PATCH v6 1/7] drm: Add a sharable drm page-pool implementation
On Wed, Feb 10, 2021 at 5:39 PM Suren Baghdasaryan wrote:
>
> On Wed, Feb 10, 2021 at 5:06 AM Daniel Vetter wrote:
> >
> > On Tue, Feb 09, 2021 at 12:16:51PM -0800, Suren Baghdasaryan wrote:
> > > On Tue, Feb 9, 2021 at 12:03 PM Daniel Vetter wrote:
> > > >
> > > > On Tue, Feb 9, 2021 at 6:46 PM Christian König
> > > > wrote:
> > > > >
> > > > >
> > > > >
> > > > > Am 09.02.21 um 18:33 schrieb Suren Baghdasaryan:
> > > > > > On Tue, Feb 9, 2021 at 4:57 AM Christian König
> > > > > > wrote:
> > > > > >> Am 09.02.21 um 13:11 schrieb Christian König:
> > > > > >>> [SNIP]
> > > > > >>>>>> +void drm_page_pool_add(struct drm_page_pool *pool, struct
> > > > > >>>>>> page *page)
> > > > > >>>>>> +{
> > > > > >>>>>> + spin_lock(>lock);
> > > > > >>>>>> + list_add_tail(>lru, >items);
> > > > > >>>>>> + pool->count++;
> > > > > >>>>>> + atomic_long_add(1 << pool->order, _pages);
> > > > > >>>>>> + spin_unlock(>lock);
> > > > > >>>>>> +
> > > > > >>>>>> + mod_node_page_state(page_pgdat(page),
> > > > > >>>>>> NR_KERNEL_MISC_RECLAIMABLE,
> > > > > >>>>>> + 1 << pool->order);
> > > > > >>>>> Hui what? What should that be good for?
> > > > > >>>> This is a carryover from the ION page pool implementation:
> > > > > >>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Ftree%2Fdrivers%2Fstaging%2Fandroid%2Fion%2Fion_page_pool.c%3Fh%3Dv5.10%23n28data=04%7C01%7Cchristian.koenig%40amd.com%7Cdff8edcd4d147a5b08d8cd20cff2%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637484888114923580%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=9%2BIBC0tezSV6Ci4S3kWfW%2BQvJm4mdunn3dF6C0kyfCw%3Dreserved=0
> > > > > >>>>
> > > > > >>>>
> > > > > >>>> My sense is it helps with the vmstat/meminfo accounting so folks
> > > > > >>>> can
> > > > > >>>> see the cached pages are shrinkable/freeable. This maybe falls
> > > > > >>>> under
> > > > > >>>> other dmabuf accounting/stats discussions, so I'm happy to
> > > > > >>>> remove it
> > > > > >>>> for now, or let the drivers using the shared page pool logic
> > > > > >>>> handle
> > > > > >>>> the accounting themselves?
> > > > > >> Intentionally separated the discussion for that here.
> > > > > >>
> > > > > >> As far as I can see this is just bluntly incorrect.
> > > > > >>
> > > > > >> Either the page is reclaimable or it is part of our pool and
> > > > > >> freeable
> > > > > >> through the shrinker, but never ever both.
> > > > > > IIRC the original motivation for counting ION pooled pages as
> > > > > > reclaimable was to include them into /proc/meminfo's MemAvailable
> > > > > > calculations. NR_KERNEL_MISC_RECLAIMABLE defined as "reclaimable
> > > > > > non-slab kernel pages" seems like a good place to account for them
> > > > > > but
> > > > > > I might be wrong.
> > > > >
> > > > > Yeah, that's what I see here as well. But exactly that is utterly
> > > > > nonsense.
> > > > >
> > > > > Those pages are not "free" in the sense that get_free_page could
> > > > > return
> > > > > them directly.
> > > >
> > > > Well on Android that is kinda true, because Android has it's
> > > > oom-killer (way back it was just a shrinker callback, not sure how it
> > > > works now), which just shot down all the background apps. So at least
> > > > some of that (everything used by background apps) is indeed
> > > > reclaimable on Android.
> &
Re: [PATCH 0/3] drm/ttm: constify static vm_operations_structs
On Wed, Feb 10, 2021 at 08:45:56AM +0100, Christian König wrote: > Reviewed-by: Christian König for the series. Smash it into -misc? -Daniel > > Am 10.02.21 um 00:48 schrieb Rikard Falkeborn: > > Constify a few static vm_operations_struct that are never modified. Their > > only usage is to assign their address to the vm_ops field in the > > vm_area_struct, which is a pointer to const vm_operations_struct. Make them > > const to allow the compiler to put them in read-only memory. > > > > With this series applied, all static struct vm_operations_struct in the > > kernel tree are const. > > > > Rikard Falkeborn (3): > >drm/amdgpu/ttm: constify static vm_operations_struct > >drm/radeon/ttm: constify static vm_operations_struct > >drm/nouveau/ttm: constify static vm_operations_struct > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +- > > drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 +- > > drivers/gpu/drm/radeon/radeon_ttm.c | 2 +- > > 3 files changed, 3 insertions(+), 3 deletions(-) > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] video: use getter/setter functions
On Wed, Feb 10, 2021 at 08:23:41AM +, Lee Jones wrote:
> On Tue, 09 Feb 2021, Julia Lawall wrote:
>
> > Use getter and setter functions, for platform_device structures and a
> > spi_device structure.
> >
> > Signed-off-by: Julia Lawall
> >
> > ---
> > drivers/video/backlight/qcom-wled.c |
> > 2 +-
>
> This patch is fine.
>
> Could you please split it out and submit it separately though please.
Or just apply the entire patch through backlight tree, there's nothing
going on in fbdev anyway I think.
Acked-by: Daniel Vetter
>
> > drivers/video/fbdev/amifb.c |
> > 4 ++--
> > drivers/video/fbdev/da8xx-fb.c |
> > 4 ++--
> > drivers/video/fbdev/imxfb.c |
> > 2 +-
> > drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c |
> > 6 +++---
> > drivers/video/fbdev/omap2/omapfb/dss/dpi.c |
> > 4 ++--
> > drivers/video/fbdev/omap2/omapfb/dss/dsi.c |
> > 4 ++--
> > drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c |
> > 2 +-
> > drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c |
> > 2 +-
> > drivers/video/fbdev/xilinxfb.c |
> > 2 +-
> > 10 files changed, 16 insertions(+), 16 deletions(-)
>
> ...]
>
> > diff --git a/drivers/video/backlight/qcom-wled.c
> > b/drivers/video/backlight/qcom-wled.c
> > index 3bc7800eb0a9..091f07e7c145 100644
> > --- a/drivers/video/backlight/qcom-wled.c
> > +++ b/drivers/video/backlight/qcom-wled.c
> > @@ -1692,7 +1692,7 @@ static int wled_probe(struct platform_device *pdev)
> >
> > static int wled_remove(struct platform_device *pdev)
> > {
> > - struct wled *wled = dev_get_drvdata(>dev);
> > + struct wled *wled = platform_get_drvdata(pdev);
> >
> > mutex_destroy(>lock);
> > cancel_delayed_work_sync(>ovp_work);
>
> For my own reference (apply this as-is to your sign-off block):
>
> Acked-for-Backlight-by: Lee Jones
>
> --
> Lee Jones [李琼斯]
> Senior Technical Lead - Developer Services
> Linaro.org │ Open source software for Arm SoCs
> Follow Linaro: Facebook | Twitter | Blog
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH] drm: use getter/setter functions
On Tue, Feb 09, 2021 at 10:13:04PM +0100, Julia Lawall wrote:
> Use getter and setter functions, for platform_device structures and a
> mipi_dsi_device structure.
>
> Signed-off-by: Julia Lawall
Applied to drm-misc-next, thanks for the patch.
-Daniel
>
> ---
> drivers/gpu/drm/aspeed/aspeed_gfx_drv.c |2 +-
> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c |2 +-
> drivers/gpu/drm/panel/panel-lvds.c |2 +-
> drivers/gpu/drm/panel/panel-seiko-43wvf1g.c |4 ++--
> drivers/gpu/drm/panel/panel-simple.c|2 +-
> drivers/gpu/drm/rockchip/rockchip_lvds.c|2 +-
> 6 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index 4e2dad314c79..9858079f9e14 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -4800,7 +4800,7 @@ static int panel_simple_dsi_probe(struct
> mipi_dsi_device *dsi)
>
> err = mipi_dsi_attach(dsi);
> if (err) {
> - struct panel_simple *panel = dev_get_drvdata(>dev);
> + struct panel_simple *panel = mipi_dsi_get_drvdata(dsi);
>
> drm_panel_remove(>base);
> }
> diff --git a/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c
> b/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c
> index 0ee508576231..3939b25e 100644
> --- a/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c
> +++ b/drivers/gpu/drm/panel/panel-seiko-43wvf1g.c
> @@ -267,7 +267,7 @@ static int seiko_panel_probe(struct device *dev,
>
> static int seiko_panel_remove(struct platform_device *pdev)
> {
> - struct seiko_panel *panel = dev_get_drvdata(>dev);
> + struct seiko_panel *panel = platform_get_drvdata(pdev);
>
> drm_panel_remove(>base);
> drm_panel_disable(>base);
> @@ -277,7 +277,7 @@ static int seiko_panel_remove(struct platform_device
> *pdev)
>
> static void seiko_panel_shutdown(struct platform_device *pdev)
> {
> - struct seiko_panel *panel = dev_get_drvdata(>dev);
> + struct seiko_panel *panel = platform_get_drvdata(pdev);
>
> drm_panel_disable(>base);
> }
> diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c
> b/drivers/gpu/drm/rockchip/rockchip_lvds.c
> index 654bc52d9ff3..bd5ba10822c2 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
> @@ -725,7 +725,7 @@ static int rockchip_lvds_probe(struct platform_device
> *pdev)
>
> static int rockchip_lvds_remove(struct platform_device *pdev)
> {
> - struct rockchip_lvds *lvds = dev_get_drvdata(>dev);
> + struct rockchip_lvds *lvds = platform_get_drvdata(pdev);
>
> component_del(>dev, _lvds_component_ops);
> clk_unprepare(lvds->pclk);
> diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> index 457ec04950f7..c7707338bfdb 100644
> --- a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> +++ b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> @@ -284,7 +284,7 @@ static int aspeed_gfx_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> - dev_set_drvdata(>dev, priv);
> + platform_set_drvdata(pdev, priv);
>
> ret = sysfs_create_group(>dev.kobj, _sysfs_attr_group);
> if (ret)
> diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> index d0c65610ebb5..989a05bc8197 100644
> --- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> @@ -2457,7 +2457,7 @@ static int cdns_mhdp_probe(struct platform_device *pdev)
>
> static int cdns_mhdp_remove(struct platform_device *pdev)
> {
> - struct cdns_mhdp_device *mhdp = dev_get_drvdata(>dev);
> + struct cdns_mhdp_device *mhdp = platform_get_drvdata(pdev);
> unsigned long timeout = msecs_to_jiffies(100);
> bool stop_fw = false;
> int ret;
> diff --git a/drivers/gpu/drm/panel/panel-lvds.c
> b/drivers/gpu/drm/panel/panel-lvds.c
> index 66c7d765b8f7..59a8d99e777d 100644
> --- a/drivers/gpu/drm/panel/panel-lvds.c
> +++ b/drivers/gpu/drm/panel/panel-lvds.c
> @@ -244,7 +244,7 @@ static int panel_lvds_probe(struct platform_device *pdev)
>
> static int panel_lvds_remove(struct platform_device *pdev)
> {
> - struct panel_lvds *lvds = dev_get_drvdata(>dev);
> + struct panel_lvds *lvds = platform_get_drvdata(pdev);
>
> drm_panel_remove(>panel);
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [RFC][PATCH v6 1/7] drm: Add a sharable drm page-pool implementation
On Tue, Feb 09, 2021 at 12:16:51PM -0800, Suren Baghdasaryan wrote:
> On Tue, Feb 9, 2021 at 12:03 PM Daniel Vetter wrote:
> >
> > On Tue, Feb 9, 2021 at 6:46 PM Christian König
> > wrote:
> > >
> > >
> > >
> > > Am 09.02.21 um 18:33 schrieb Suren Baghdasaryan:
> > > > On Tue, Feb 9, 2021 at 4:57 AM Christian König
> > > > wrote:
> > > >> Am 09.02.21 um 13:11 schrieb Christian König:
> > > >>> [SNIP]
> > > >>>>>> +void drm_page_pool_add(struct drm_page_pool *pool, struct page
> > > >>>>>> *page)
> > > >>>>>> +{
> > > >>>>>> + spin_lock(>lock);
> > > >>>>>> + list_add_tail(>lru, >items);
> > > >>>>>> + pool->count++;
> > > >>>>>> + atomic_long_add(1 << pool->order, _pages);
> > > >>>>>> + spin_unlock(>lock);
> > > >>>>>> +
> > > >>>>>> + mod_node_page_state(page_pgdat(page),
> > > >>>>>> NR_KERNEL_MISC_RECLAIMABLE,
> > > >>>>>> + 1 << pool->order);
> > > >>>>> Hui what? What should that be good for?
> > > >>>> This is a carryover from the ION page pool implementation:
> > > >>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Ftree%2Fdrivers%2Fstaging%2Fandroid%2Fion%2Fion_page_pool.c%3Fh%3Dv5.10%23n28data=04%7C01%7Cchristian.koenig%40amd.com%7Cdff8edcd4d147a5b08d8cd20cff2%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637484888114923580%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=9%2BIBC0tezSV6Ci4S3kWfW%2BQvJm4mdunn3dF6C0kyfCw%3Dreserved=0
> > > >>>>
> > > >>>>
> > > >>>> My sense is it helps with the vmstat/meminfo accounting so folks can
> > > >>>> see the cached pages are shrinkable/freeable. This maybe falls under
> > > >>>> other dmabuf accounting/stats discussions, so I'm happy to remove it
> > > >>>> for now, or let the drivers using the shared page pool logic handle
> > > >>>> the accounting themselves?
> > > >> Intentionally separated the discussion for that here.
> > > >>
> > > >> As far as I can see this is just bluntly incorrect.
> > > >>
> > > >> Either the page is reclaimable or it is part of our pool and freeable
> > > >> through the shrinker, but never ever both.
> > > > IIRC the original motivation for counting ION pooled pages as
> > > > reclaimable was to include them into /proc/meminfo's MemAvailable
> > > > calculations. NR_KERNEL_MISC_RECLAIMABLE defined as "reclaimable
> > > > non-slab kernel pages" seems like a good place to account for them but
> > > > I might be wrong.
> > >
> > > Yeah, that's what I see here as well. But exactly that is utterly
> > > nonsense.
> > >
> > > Those pages are not "free" in the sense that get_free_page could return
> > > them directly.
> >
> > Well on Android that is kinda true, because Android has it's
> > oom-killer (way back it was just a shrinker callback, not sure how it
> > works now), which just shot down all the background apps. So at least
> > some of that (everything used by background apps) is indeed
> > reclaimable on Android.
> >
> > But that doesn't hold on Linux in general, so we can't really do this
> > for common code.
> >
> > Also I had a long meeting with Suren, John and other googles
> > yesterday, and the aim is now to try and support all the Android gpu
> > memory accounting needs with cgroups. That should work, and it will
> > allow Android to handle all the Android-ism in a clean way in upstream
> > code. Or that's at least the plan.
> >
> > I think the only thing we identified that Android still needs on top
> > is the dma-buf sysfs stuff, so that shared buffers (which on Android
> > are always dma-buf, and always stay around as dma-buf fd throughout
> > their lifetime) can be listed/analyzed with full detail.
> >
> > But aside from this the plan for all the per-process or per-heap
> > account, oom-killer integration and everything else is planned to be
> > done with cgroups.
>
&
Re: [PATCH 0/9] Add support for SVM atomics in Nouveau
On Tue, Feb 09, 2021 at 12:53:27PM -0800, John Hubbard wrote:
> On 2/9/21 5:37 AM, Daniel Vetter wrote:
> > On Tue, Feb 9, 2021 at 1:57 PM Alistair Popple wrote:
> > >
> > > On Tuesday, 9 February 2021 9:27:05 PM AEDT Daniel Vetter wrote:
> > > > >
> > > > > Recent changes to pin_user_pages() prevent the creation of pinned
> > > > > pages in
> > > > > ZONE_MOVABLE. This series allows pinned pages to be created in
> > > ZONE_MOVABLE
> > > > > as attempts to migrate may fail which would be fatal to userspace.
> > > > >
> > > > > In this case migration of the pinned page is unnecessary as the page
> > > > > can
> > > be
> > > > > unpinned at anytime by having the driver revoke atomic permission as
> > > > > it
> > > > > does for the migrate_to_ram() callback. However a method of calling
> > > > > this
> > > > > when memory needs to be moved has yet to be resolved so any
> > > > > discussion is
> > > > > welcome.
> > > >
> > > > Why do we need to pin for gpu atomics? You still have the callback for
> > > > cpu faults, so you
> > > > can move the page as needed, and hence a long-term pin sounds like the
> > > > wrong approach.
> > >
> > > Technically a real long term unmoveable pin isn't required, because as
> > > you say
> > > the page can be moved as needed at any time. However I needed some way of
> > > stopping the CPU page from being freed once the userspace mappings for it
> > > had
> > > been removed. Obviously I could have just used get_page() but from the
> > > perspective of page migration the result is much the same as a pin - a
> > > page
> > > which can't be moved because of the extra refcount.
> >
> > long term pin vs short term page reference aren't fully fleshed out.
> > But the rule more or less is:
> > - short term page reference: _must_ get released in finite time for
> > migration and other things, either because you have a callback, or
> > because it's just for direct I/O, which will complete. This means
> > short term pins will delay migration, but not foul it complete
>
>
> GPU atomic operations to sysmem are hard to categorize, because because
> application
> programmers could easily write programs that do a long series of atomic
> operations.
> Such a program would be a little weird, but it's hard to rule out.
Yeah, but we can forcefully break this whenever we feel like by revoking
the page, moving it, and then reinstating the gpu pte again and let it
continue.
If that's no possible then what we need here instead is an mlock() type of
thing I think.
> > - long term pin: the page cannot be moved, all migration must fail.
> > Also this will have an impact on COW behaviour for fork (but not sure
> > where those patches are, John Hubbard will know).
>
>
> That would be Jason's commit 57efa1fe59576 ("mm/gup: prevent gup_fast from
> racing
> with COW during fork"), which is in linux-next 20201216.
Nice, thanks for the pointer.
>
>
> >
> > So I think for your use case here you want a) short term page
> > reference to make sure it doesn't disappear plus b) callback to make
> > sure migrate isn't blocked.
> >
> > Breaking ZONE_MOVEABLE with either allowing long term pins or failing
> > migrations because you don't release your short term page reference
> > isn't good.
> >
> > > The normal solution of registering an MMU notifier to unpin the page when
> > > it
> > > needs to be moved also doesn't work as the CPU page tables now point to
> > > the
> > > device-private page and hence the migration code won't call any invalidate
> > > notifiers for the CPU page.
> >
> > Yeah you need some other callback for migration on the page directly.
> > it's a bit awkward since there is one already for struct
> > address_space, but that's own by the address_space/page cache, not
> > HMM. So I think we need something else, maybe something for each
> > ZONE_DEVICE?
> >
>
> This direction sounds at least...possible. Using MMU notifiers instead of pins
> is definitely appealing. I'm not quite clear on the callback idea above, but
> overall it seems like taking advantage of the ZONE_DEVICE tracking of pages
> (without having to put anything additional in each struct page), could work.
>
> Additional notes or ideas here are definitely welcome.
Well I don't have ideas for the details
Re: [RFC][PATCH v6 1/7] drm: Add a sharable drm page-pool implementation
On Tue, Feb 9, 2021 at 6:46 PM Christian König wrote:
>
>
>
> Am 09.02.21 um 18:33 schrieb Suren Baghdasaryan:
> > On Tue, Feb 9, 2021 at 4:57 AM Christian König
> > wrote:
> >> Am 09.02.21 um 13:11 schrieb Christian König:
> >>> [SNIP]
> >>>>>> +void drm_page_pool_add(struct drm_page_pool *pool, struct page *page)
> >>>>>> +{
> >>>>>> + spin_lock(>lock);
> >>>>>> + list_add_tail(>lru, >items);
> >>>>>> + pool->count++;
> >>>>>> + atomic_long_add(1 << pool->order, _pages);
> >>>>>> + spin_unlock(>lock);
> >>>>>> +
> >>>>>> + mod_node_page_state(page_pgdat(page),
> >>>>>> NR_KERNEL_MISC_RECLAIMABLE,
> >>>>>> + 1 << pool->order);
> >>>>> Hui what? What should that be good for?
> >>>> This is a carryover from the ION page pool implementation:
> >>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Ftree%2Fdrivers%2Fstaging%2Fandroid%2Fion%2Fion_page_pool.c%3Fh%3Dv5.10%23n28data=04%7C01%7Cchristian.koenig%40amd.com%7Cdff8edcd4d147a5b08d8cd20cff2%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637484888114923580%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=9%2BIBC0tezSV6Ci4S3kWfW%2BQvJm4mdunn3dF6C0kyfCw%3Dreserved=0
> >>>>
> >>>>
> >>>> My sense is it helps with the vmstat/meminfo accounting so folks can
> >>>> see the cached pages are shrinkable/freeable. This maybe falls under
> >>>> other dmabuf accounting/stats discussions, so I'm happy to remove it
> >>>> for now, or let the drivers using the shared page pool logic handle
> >>>> the accounting themselves?
> >> Intentionally separated the discussion for that here.
> >>
> >> As far as I can see this is just bluntly incorrect.
> >>
> >> Either the page is reclaimable or it is part of our pool and freeable
> >> through the shrinker, but never ever both.
> > IIRC the original motivation for counting ION pooled pages as
> > reclaimable was to include them into /proc/meminfo's MemAvailable
> > calculations. NR_KERNEL_MISC_RECLAIMABLE defined as "reclaimable
> > non-slab kernel pages" seems like a good place to account for them but
> > I might be wrong.
>
> Yeah, that's what I see here as well. But exactly that is utterly nonsense.
>
> Those pages are not "free" in the sense that get_free_page could return
> them directly.
Well on Android that is kinda true, because Android has it's
oom-killer (way back it was just a shrinker callback, not sure how it
works now), which just shot down all the background apps. So at least
some of that (everything used by background apps) is indeed
reclaimable on Android.
But that doesn't hold on Linux in general, so we can't really do this
for common code.
Also I had a long meeting with Suren, John and other googles
yesterday, and the aim is now to try and support all the Android gpu
memory accounting needs with cgroups. That should work, and it will
allow Android to handle all the Android-ism in a clean way in upstream
code. Or that's at least the plan.
I think the only thing we identified that Android still needs on top
is the dma-buf sysfs stuff, so that shared buffers (which on Android
are always dma-buf, and always stay around as dma-buf fd throughout
their lifetime) can be listed/analyzed with full detail.
But aside from this the plan for all the per-process or per-heap
account, oom-killer integration and everything else is planned to be
done with cgroups. Android (for now) only needs to account overall gpu
memory since none of it is swappable on android drivers anyway, plus
no vram, so not much needed.
Cheers, Daniel
>
> Regards,
> Christian.
>
> >
> >> In the best case this just messes up the accounting, in the worst case
> >> it can cause memory corruption.
> >>
> >> Christian.
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH 0/9] Add support for SVM atomics in Nouveau
On Tue, Feb 9, 2021 at 2:35 PM Jason Gunthorpe wrote: > > On Tue, Feb 09, 2021 at 11:57:28PM +1100, Alistair Popple wrote: > > On Tuesday, 9 February 2021 9:27:05 PM AEDT Daniel Vetter wrote: > > > > > > > > Recent changes to pin_user_pages() prevent the creation of pinned pages > > > > in > > > > ZONE_MOVABLE. This series allows pinned pages to be created in > > ZONE_MOVABLE > > > > as attempts to migrate may fail which would be fatal to userspace. > > > > > > > > In this case migration of the pinned page is unnecessary as the page can > > be > > > > unpinned at anytime by having the driver revoke atomic permission as it > > > > does for the migrate_to_ram() callback. However a method of calling this > > > > when memory needs to be moved has yet to be resolved so any discussion > > > > is > > > > welcome. > > > > > > Why do we need to pin for gpu atomics? You still have the callback for > > > cpu faults, so you > > > can move the page as needed, and hence a long-term pin sounds like the > > > wrong approach. > > > > Technically a real long term unmoveable pin isn't required, because as you > > say > > the page can be moved as needed at any time. However I needed some way of > > stopping the CPU page from being freed once the userspace mappings for it > > had > > been removed. > > The issue is you took the page out of the PTE it belongs to, which > makes it orphaned and unlocatable by the rest of the mm? > > Ideally this would leave the PTE in place so everything continues to > work, just disable CPU access to it. > > Maybe some kind of special swap entry? I probably should have read the patches more in detail, I was assuming the ZONE_DEVICE is only for vram. At least I thought the requirement for gpu atomics was that the page is in vram, but maybe I'm mixing up how this works on nvidia with how it works in other places. Iirc we had a long discussion about this at lpc19 that ended with the conclusion that we must be able to migrate, and sometimes migration is blocked. But the details ellude me now. Either way ZONE_DEVICE for not vram/device memory sounds wrong. Is that really going on here? -Daniel > > I also don't much like the use of ZONE_DEVICE here, that should only > be used for actual device memory, not as a temporary proxy for CPU > pages.. Having two struct pages refer to the same physical memory is > pretty ugly. > > > The normal solution of registering an MMU notifier to unpin the page when it > > needs to be moved also doesn't work as the CPU page tables now point to the > > device-private page and hence the migration code won't call any invalidate > > notifiers for the CPU page. > > The fact the page is lost from the MM seems to be the main issue here. > > > Yes, I would like to avoid the long term pin constraints as well if > > possible I > > just haven't found a solution yet. Are you suggesting it might be possible > > to > > add a callback in the page migration logic to specially deal with moving > > these > > pages? > > How would migration even find the page? > > Jason -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH 0/9] Add support for SVM atomics in Nouveau
On Tue, Feb 9, 2021 at 1:57 PM Alistair Popple wrote: > > On Tuesday, 9 February 2021 9:27:05 PM AEDT Daniel Vetter wrote: > > > > > > Recent changes to pin_user_pages() prevent the creation of pinned pages in > > > ZONE_MOVABLE. This series allows pinned pages to be created in > ZONE_MOVABLE > > > as attempts to migrate may fail which would be fatal to userspace. > > > > > > In this case migration of the pinned page is unnecessary as the page can > be > > > unpinned at anytime by having the driver revoke atomic permission as it > > > does for the migrate_to_ram() callback. However a method of calling this > > > when memory needs to be moved has yet to be resolved so any discussion is > > > welcome. > > > > Why do we need to pin for gpu atomics? You still have the callback for > > cpu faults, so you > > can move the page as needed, and hence a long-term pin sounds like the > > wrong approach. > > Technically a real long term unmoveable pin isn't required, because as you say > the page can be moved as needed at any time. However I needed some way of > stopping the CPU page from being freed once the userspace mappings for it had > been removed. Obviously I could have just used get_page() but from the > perspective of page migration the result is much the same as a pin - a page > which can't be moved because of the extra refcount. long term pin vs short term page reference aren't fully fleshed out. But the rule more or less is: - short term page reference: _must_ get released in finite time for migration and other things, either because you have a callback, or because it's just for direct I/O, which will complete. This means short term pins will delay migration, but not foul it complete - long term pin: the page cannot be moved, all migration must fail. Also this will have an impact on COW behaviour for fork (but not sure where those patches are, John Hubbard will know). So I think for your use case here you want a) short term page reference to make sure it doesn't disappear plus b) callback to make sure migrate isn't blocked. Breaking ZONE_MOVEABLE with either allowing long term pins or failing migrations because you don't release your short term page reference isn't good. > The normal solution of registering an MMU notifier to unpin the page when it > needs to be moved also doesn't work as the CPU page tables now point to the > device-private page and hence the migration code won't call any invalidate > notifiers for the CPU page. Yeah you need some other callback for migration on the page directly. it's a bit awkward since there is one already for struct address_space, but that's own by the address_space/page cache, not HMM. So I think we need something else, maybe something for each ZONE_DEVICE? > > That would avoid all the hacking around long term pin constraints, because > > for real unmoveable long term pinned memory we really want to have all > > these checks. So I think we might be missing some other callbacks to be > > able to move these pages, instead of abusing longterm pins for lack of > > better tools. > > Yes, I would like to avoid the long term pin constraints as well if possible I > just haven't found a solution yet. Are you suggesting it might be possible to > add a callback in the page migration logic to specially deal with moving these > pages? s/possible/need to type some code to address it/ I think. But also I'm not much of an expert on this, I've only just started learning how this all fits together coming from the gpu side. There's a _lot_ of finesse involved. Cheers, Daniel > > Thanks, Alistair > > > Cheers, Daniel > > > > > > > > > > > > Alistair Popple (9): > > > mm/migrate.c: Always allow device private pages to migrate > > > mm/migrate.c: Allow pfn flags to be passed to migrate_vma_setup() > > > mm/migrate: Add a unmap and pin migration mode > > > Documentation: Add unmap and pin to HMM > > > hmm-tests: Add test for unmap and pin > > > nouveau/dmem: Only map migrating pages > > > nouveau/svm: Refactor nouveau_range_fault > > > nouveau/dmem: Add support for multiple page types > > > nouveau/svm: Implement atomic SVM access > > > > > > Documentation/vm/hmm.rst | 22 +- > > > arch/powerpc/kvm/book3s_hv_uvmem.c| 4 +- > > > drivers/gpu/drm/nouveau/include/nvif/if000c.h | 1 + > > > drivers/gpu/drm/nouveau/nouveau_dmem.c| 190 +++--- > > > drivers/gpu/drm/nouveau/nouveau_dmem.h| 9 + > > > drivers/gpu/drm/nouveau/nouveau_svm.c | 148 +++--- > > > drivers/gpu/
Re: [PATCH 0/9] Add support for SVM atomics in Nouveau
On Tue, Feb 09, 2021 at 12:07:13PM +1100, Alistair Popple wrote: > This series adds support to Nouveau for atomic memory operations on OpenCL > shared virtual memory (SVM). This is achieved using the atomic PTE bits on > the GPU to only permit atomic operations to system memory when a page is > not mapped in userspace on the CPU. > > This is implemented by adding a mode to migrate_vma_pages() which unmaps > and isolates existing pages from the CPU and pins them. The original > userspace page table entries are migrated to point to device private pages > allocated by the driver. This allows the driver to enable GPU atomic access > to the page as it will receive a callback when CPU userspace needs to > access it. > > In response to this callback the driver revokes the atomic access > permission from the GPU and migrates entries to point back to the original > page. The original page is unpinned as part of the migration operation > which also returns it to the LRU. > > Patch 3 contains the bulk of the memory management changes to implement > unmap and pin. > > Patches 6-9 extend Nouveau to use the new mode to allow system wide atomics > for OpenCL SVM to be implemented on Nouveau. > > This has been tested using the latest upstream Mesa userspace with a simple > OpenCL test program which checks the results of atomic GPU operations on a > buffer whilst also writing to the same buffer from the CPU. > > Problems yet to be addressed: > > Recent changes to pin_user_pages() prevent the creation of pinned pages in > ZONE_MOVABLE. This series allows pinned pages to be created in ZONE_MOVABLE > as attempts to migrate may fail which would be fatal to userspace. > > In this case migration of the pinned page is unnecessary as the page can be > unpinned at anytime by having the driver revoke atomic permission as it > does for the migrate_to_ram() callback. However a method of calling this > when memory needs to be moved has yet to be resolved so any discussion is > welcome. Why do we need to pin for gpu atomics? You still have the callback for cpu faults, so you can move the page as needed, and hence a long-term pin sounds like the wrong approach. That would avoid all the hacking around long term pin constraints, because for real unmoveable long term pinned memory we really want to have all these checks. So I think we might be missing some other callbacks to be able to move these pages, instead of abusing longterm pins for lack of better tools. Cheers, Daniel > > Alistair Popple (9): > mm/migrate.c: Always allow device private pages to migrate > mm/migrate.c: Allow pfn flags to be passed to migrate_vma_setup() > mm/migrate: Add a unmap and pin migration mode > Documentation: Add unmap and pin to HMM > hmm-tests: Add test for unmap and pin > nouveau/dmem: Only map migrating pages > nouveau/svm: Refactor nouveau_range_fault > nouveau/dmem: Add support for multiple page types > nouveau/svm: Implement atomic SVM access > > Documentation/vm/hmm.rst | 22 +- > arch/powerpc/kvm/book3s_hv_uvmem.c| 4 +- > drivers/gpu/drm/nouveau/include/nvif/if000c.h | 1 + > drivers/gpu/drm/nouveau/nouveau_dmem.c| 190 +++--- > drivers/gpu/drm/nouveau/nouveau_dmem.h| 9 + > drivers/gpu/drm/nouveau/nouveau_svm.c | 148 +++--- > drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 1 + > .../drm/nouveau/nvkm/subdev/mmu/vmmgp100.c| 6 + > include/linux/migrate.h | 2 + > include/linux/migrate_mode.h | 1 + > lib/test_hmm.c| 109 -- > lib/test_hmm_uapi.h | 1 + > mm/migrate.c | 82 +--- > tools/testing/selftests/vm/hmm-tests.c| 49 + > 14 files changed, 524 insertions(+), 101 deletions(-) > > -- > 2.20.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH v6 3/3] drm/fourcc: Switch to %p4cc format modifier
On Mon, Feb 8, 2021 at 9:20 PM Sakari Ailus
wrote:
>
> Instead of constructing the FourCC code manually, use the %p4cc printk
> modifier to print it. Also leave a message to avoid using this function.
>
> The next step would be to convert the users to use %p4cc directly instead
> and removing the function.
>
> Signed-off-by: Sakari Ailus
> ---
> drivers/gpu/drm/drm_fourcc.c | 16 +++-
> 1 file changed, 3 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 03262472059c..4ff40f2f27c0 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -30,11 +30,6 @@
> #include
> #include
>
> -static char printable_char(int c)
> -{
> - return isascii(c) && isprint(c) ? c : '?';
> -}
> -
> /**
> * drm_mode_legacy_fb_format - compute drm fourcc code from legacy
> description
> * @bpp: bits per pixels
> @@ -134,17 +129,12 @@ EXPORT_SYMBOL(drm_driver_legacy_fb_format);
> * drm_get_format_name - fill a string with a drm fourcc format's name
> * @format: format to compute name of
> * @buf: caller-supplied buffer
> + *
> + * Please use %p4cc printk format modifier instead of this function.
I think would be nice if we could roll this out and outright delete
this one here ... Quick git grep says there's not that many, and %p4cc
is quite a bit shorter than what we have now.
-Daniel
> */
> const char *drm_get_format_name(uint32_t format, struct drm_format_name_buf
> *buf)
> {
> - snprintf(buf->str, sizeof(buf->str),
> -"%c%c%c%c %s-endian (0x%08x)",
> -printable_char(format & 0xff),
> -printable_char((format >> 8) & 0xff),
> -printable_char((format >> 16) & 0xff),
> -printable_char((format >> 24) & 0x7f),
> -format & DRM_FORMAT_BIG_ENDIAN ? "big" : "little",
> -format);
> + snprintf(buf->str, sizeof(buf->str), "%p4cc", );
>
> return buf->str;
> }
> --
> 2.29.2
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [RFC][PATCH 2/2] dma-buf: heaps: Fix the name used when exporting dmabufs to be the actual heap name
On Mon, Feb 8, 2021 at 9:51 PM John Stultz wrote: > On Mon, Feb 8, 2021 at 2:08 AM Daniel Vetter wrote: > > On Sat, Feb 06, 2021 at 05:47:48AM +, John Stultz wrote: > > > By default dma_buf_export() sets the exporter name to be > > > KBUILD_MODNAME. Unfortunately this may not be identical to the > > > string used as the heap name (ie: "system" vs "system_heap"). > > > > > > This can cause some minor confusion with tooling, and there is > > > the future potential where multiple heap types may be exported > > > by the same module (but would all have the same name). > > > > > > So to avoid all this, set the exporter exp_name to the heap name. > > > > > > Cc: Daniel Vetter > > > Cc: Sumit Semwal > > > Cc: Liam Mark > > > Cc: Chris Goldsworthy > > > Cc: Laura Abbott > > > Cc: Brian Starkey > > > Cc: Hridya Valsaraju > > > Cc: Suren Baghdasaryan > > > Cc: Sandeep Patil > > > Cc: Daniel Mentz > > > Cc: Ørjan Eide > > > Cc: Robin Murphy > > > Cc: Ezequiel Garcia > > > Cc: Simon Ser > > > Cc: James Jones > > > Cc: linux-me...@vger.kernel.org > > > Cc: dri-de...@lists.freedesktop.org > > > Signed-off-by: John Stultz > > > > Looks reasonable to me. > > > > I guess the main worry is "does this mean heap names become uapi", in > > which case I'm maybe not so sure anymore how this will tie into the > > overall gpu memory accounting story. > > > > Since for dma-buf heaps one name per buffer is perfectly fine, since > > dma-buf heaps aren't very dynamic. But on discrete gpu drivers buffers > > move, so baking in the assumption that "exporter name = resource usage for > > this buffer" is broken. > > I suspect I'm missing a subtlety in what you're describing. My sense > of the exporter name doesn't account for a buffer's usage, it just > describes what code allocated it and implicitly which dmabuf_ops > handles it. Maybe could you give a more specific example of what > you're hoping to avoid? Just paranoia really - on the linux side where we allocate most buffers (even shared ones) with the driver, that allocator info isn't that meaningful, it really just tells you which code allocated/exported that dma-buf. But on Android, where all shared buffers come from specific heaps, it is rather meaningful information. So I wondered whether e.g. the android dmabuf debug tool uses that to collect per-heap stats, but sounds like no right now. Plus with the chat we've had I think we have a long-term plan for how to expose that information properly. > To me this patch is mostly just a consistency/least-surprise thing, so > the heaps exporter name matches the string used for the heap's chardev > device (the interface used to allocate it) in output like > debugfs/dma_buf/bufinfo. Yeah for debug this makes sense. a-b: me if you want that somewhere on the patches. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] kernel: Expose SYS_kcmp by default
On Mon, Feb 8, 2021 at 12:49 PM Michel Dänzer wrote: > > On 2021-02-05 9:53 p.m., Daniel Vetter wrote: > > On Fri, Feb 5, 2021 at 7:37 PM Kees Cook wrote: > >> > >> On Fri, Feb 05, 2021 at 04:37:52PM +, Chris Wilson wrote: > >>> Userspace has discovered the functionality offered by SYS_kcmp and has > >>> started to depend upon it. In particular, Mesa uses SYS_kcmp for > >>> os_same_file_description() in order to identify when two fd (e.g. device > >>> or dmabuf) point to the same struct file. Since they depend on it for > >>> core functionality, lift SYS_kcmp out of the non-default > >>> CONFIG_CHECKPOINT_RESTORE into the selectable syscall category. > >>> > >>> Signed-off-by: Chris Wilson > >>> Cc: Kees Cook > >>> Cc: Andy Lutomirski > >>> Cc: Will Drewry > >>> Cc: Andrew Morton > >>> Cc: Dave Airlie > >>> Cc: Daniel Vetter > >>> Cc: Lucas Stach > >>> --- > >>> init/Kconfig | 11 +++ > >>> kernel/Makefile | 2 +- > >>> tools/testing/selftests/seccomp/seccomp_bpf.c | 2 +- > >>> 3 files changed, 13 insertions(+), 2 deletions(-) > >>> > >>> diff --git a/init/Kconfig b/init/Kconfig > >>> index b77c60f8b963..f62fca13ac5b 100644 > >>> --- a/init/Kconfig > >>> +++ b/init/Kconfig > >>> @@ -1194,6 +1194,7 @@ endif # NAMESPACES > >>> config CHECKPOINT_RESTORE > >>>bool "Checkpoint/restore support" > >>>select PROC_CHILDREN > >>> + select KCMP > >>>default n > >>>help > >>> Enables additional kernel features in a sake of > >>> checkpoint/restore. > >>> @@ -1737,6 +1738,16 @@ config ARCH_HAS_MEMBARRIER_CALLBACKS > >>> config ARCH_HAS_MEMBARRIER_SYNC_CORE > >>>bool > >>> > >>> +config KCMP > >>> + bool "Enable kcmp() system call" if EXPERT > >>> + default y > >> > >> I would expect this to be not default-y, especially if > >> CHECKPOINT_RESTORE does a "select" on it. > >> > >> This is a really powerful syscall, but it is bounded by ptrace access > >> controls, and uses pointer address obfuscation, so it may be okay to > >> expose this. As it is, at least Ubuntu already has > >> CONFIG_CHECKPOINT_RESTORE, so really, there's probably not much > >> difference on exposure. > >> > >> So, if you drop the "default y", I'm fine with this. > > > > It was maybe stupid, but our userspace started relying on fd > > comaprison through sys_kcomp. So for better or worse, if you want to > > run the mesa3d gl/vk stacks, you need this. > > That's overstating things somewhat. The vast majority of applications > will work fine regardless (as they did before Mesa started using this > functionality). Only some special ones will run into issues, because the > user-space drivers incorrectly assume two file descriptors reference > different descriptions. > > > > Was maybe not the brighest ideas, but since enough distros had this > > enabled by defaults, > > Right, that (and the above) is why I considered it fair game to use. > What should I have done instead? (TBH I was surprised that this > functionality isn't generally available) Yeah that one is fine, but I thought we've discussed (irc or something) more uses for de-duping dma-buf and stuff like that. But quick grep says that hasn't landed yet, so I got a bit confused (or just dreamt). Looking at this again I'm kinda surprised the drmfd de-duping blows up on normal linux distros, but I guess it can all happen. > > it wasn't really discovered, and now we're > > shipping this everywhere. > > You're making it sound like this snuck in secretly somehow, which is not > true of course. > > > > Ofc we can leave the default n, but the select if CONFIG_DRM is > > unfortunately needed I think. > > Per above, not sure this is really true. We seem to be going boom on linux distros now, maybe userspace got more creative in abusing stuff? The entire thing is small enough that imo we don't really have to care, e.g. we also unconditionally select dma-buf, despite that on most systems there's only 1 gpu, and you're never going to end up with a buffer sharing case that needs any of that code (aside from the "here's an fd" part). But I guess we can limit to just KCMP_FILE like you suggest in another reply. Just feels a bit like overkill. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [RFC][PATCH 2/2] dma-buf: heaps: Fix the name used when exporting dmabufs to be the actual heap name
On Sat, Feb 06, 2021 at 05:47:48AM +, John Stultz wrote: > By default dma_buf_export() sets the exporter name to be > KBUILD_MODNAME. Unfortunately this may not be identical to the > string used as the heap name (ie: "system" vs "system_heap"). > > This can cause some minor confusion with tooling, and there is > the future potential where multiple heap types may be exported > by the same module (but would all have the same name). > > So to avoid all this, set the exporter exp_name to the heap name. > > Cc: Daniel Vetter > Cc: Sumit Semwal > Cc: Liam Mark > Cc: Chris Goldsworthy > Cc: Laura Abbott > Cc: Brian Starkey > Cc: Hridya Valsaraju > Cc: Suren Baghdasaryan > Cc: Sandeep Patil > Cc: Daniel Mentz > Cc: Ørjan Eide > Cc: Robin Murphy > Cc: Ezequiel Garcia > Cc: Simon Ser > Cc: James Jones > Cc: linux-me...@vger.kernel.org > Cc: dri-de...@lists.freedesktop.org > Signed-off-by: John Stultz Looks reasonable to me. I guess the main worry is "does this mean heap names become uapi", in which case I'm maybe not so sure anymore how this will tie into the overall gpu memory accounting story. Since for dma-buf heaps one name per buffer is perfectly fine, since dma-buf heaps aren't very dynamic. But on discrete gpu drivers buffers move, so baking in the assumption that "exporter name = resource usage for this buffer" is broken. So I'm not sure we shouldn't instead name all the dma-buf heaps as "dma-buf heaps" to stop this :-) -Daniel > --- > drivers/dma-buf/heaps/cma_heap.c| 1 + > drivers/dma-buf/heaps/system_heap.c | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/drivers/dma-buf/heaps/cma_heap.c > b/drivers/dma-buf/heaps/cma_heap.c > index 364fc2f3e499..62465d61ccc7 100644 > --- a/drivers/dma-buf/heaps/cma_heap.c > +++ b/drivers/dma-buf/heaps/cma_heap.c > @@ -339,6 +339,7 @@ static int cma_heap_allocate(struct dma_heap *heap, > buffer->pagecount = pagecount; > > /* create the dmabuf */ > + exp_info.exp_name = dma_heap_get_name(heap); > exp_info.ops = _heap_buf_ops; > exp_info.size = buffer->len; > exp_info.flags = fd_flags; > diff --git a/drivers/dma-buf/heaps/system_heap.c > b/drivers/dma-buf/heaps/system_heap.c > index 17e0e9a68baf..2d4afc79c700 100644 > --- a/drivers/dma-buf/heaps/system_heap.c > +++ b/drivers/dma-buf/heaps/system_heap.c > @@ -388,6 +388,7 @@ static int system_heap_allocate(struct dma_heap *heap, > } > > /* create the dmabuf */ > + exp_info.exp_name = dma_heap_get_name(heap); > exp_info.ops = _heap_buf_ops; > exp_info.size = buffer->len; > exp_info.flags = fd_flags; > -- > 2.25.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH 1/2] PCI: also set up legacy files only after sysfs init
On Thu, Feb 4, 2021 at 11:24 PM Pali Rohár wrote:
>
> On Thursday 04 February 2021 15:50:19 Bjorn Helgaas wrote:
> > [+cc Oliver, Pali, Krzysztof]
>
> Just to note that extending or using sysfs_initialized introduces
> another race condition into kernel code which results in PCI fatal
> errors. Details are in email discussion which Bjorn already sent.
Yeah I wondered why this doesn't race, but since the history goes back
to pre-git times I figured it would have been addressed somehow
already if it indeed does race.
-Daniel
> > s/also/Also/ in subject
> >
> > On Thu, Feb 04, 2021 at 05:58:30PM +0100, Daniel Vetter wrote:
> > > We are already doing this for all the regular sysfs files on PCI
> > > devices, but not yet on the legacy io files on the PCI buses. Thus far
> > > now problem, but in the next patch I want to wire up iomem revoke
> > > support. That needs the vfs up an running already to make so that
> > > iomem_get_mapping() works.
> >
> > s/now problem/no problem/
> > s/an running/and running/
> > s/so that/sure that/ ?
> >
> > iomem_get_mapping() doesn't exist; I don't know what that should be.
> >
> > > Wire it up exactly like the existing code. Note that
> > > pci_remove_legacy_files() doesn't need a check since the one for
> > > pci_bus->legacy_io is sufficient.
> >
> > I'm not sure exactly what you mean by "the existing code." I could
> > probably figure it out, but it would save time to mention the existing
> > function here.
> >
> > This looks like another instance where we should really apply Oliver's
> > idea of converting these to attribute_groups [1].
> >
> > The cover letter mentions options discussed with Greg in [2], but I
> > don't think the "sysfs_initialized" hack vs attribute_groups was part
> > of that discussion.
> >
> > It's not absolutely a show-stopper, but it *is* a shame to extend the
> > sysfs_initialized hack if attribute_groups could do this more cleanly
> > and help solve more than one issue.
> >
> > Bjorn
> >
> > [1]
> > https://lore.kernel.org/r/caosf1chss03dbsdo4pmttmp0tceu5kscn704zewlkgxqzbf...@mail.gmail.com
> > [2]
> > https://lore.kernel.org/dri-devel/cakmk7ugrddrbtj0oyzqqc0cgrqwc2f3tfju9vlfm2jjufaz...@mail.gmail.com/
> >
> > > Signed-off-by: Daniel Vetter
> > > Cc: Stephen Rothwell
> > > Cc: Jason Gunthorpe
> > > Cc: Kees Cook
> > > Cc: Dan Williams
> > > Cc: Andrew Morton
> > > Cc: John Hubbard
> > > Cc: Jérôme Glisse
> > > Cc: Jan Kara
> > > Cc: Dan Williams
> > > Cc: Greg Kroah-Hartman
> > > Cc: linux...@kvack.org
> > > Cc: linux-arm-ker...@lists.infradead.org
> > > Cc: linux-samsung-...@vger.kernel.org
> > > Cc: linux-me...@vger.kernel.org
> > > Cc: Bjorn Helgaas
> > > Cc: linux-...@vger.kernel.org
> > > ---
> > > drivers/pci/pci-sysfs.c | 7 +++
> > > 1 file changed, 7 insertions(+)
> > >
> > > diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> > > index fb072f4b3176..0c45b4f7b214 100644
> > > --- a/drivers/pci/pci-sysfs.c
> > > +++ b/drivers/pci/pci-sysfs.c
> > > @@ -927,6 +927,9 @@ void pci_create_legacy_files(struct pci_bus *b)
> > > {
> > > int error;
> > >
> > > + if (!sysfs_initialized)
> > > + return;
> > > +
> > > b->legacy_io = kcalloc(2, sizeof(struct bin_attribute),
> > >GFP_ATOMIC);
> > > if (!b->legacy_io)
> > > @@ -1448,6 +1451,7 @@ void pci_remove_sysfs_dev_files(struct pci_dev
> > > *pdev)
> > > static int __init pci_sysfs_init(void)
> > > {
> > > struct pci_dev *pdev = NULL;
> > > + struct pci_bus *pbus = NULL;
> > > int retval;
> > >
> > > sysfs_initialized = 1;
> > > @@ -1459,6 +1463,9 @@ static int __init pci_sysfs_init(void)
> > > }
> > > }
> > >
> > > + while ((pbus = pci_find_next_bus(pbus)))
> > > + pci_create_legacy_files(pbus);
> > > +
> > > return 0;
> > > }
> > > late_initcall(pci_sysfs_init);
> > > --
> > > 2.30.0
> > >
> > >
> > > ___
> > > linux-arm-kernel mailing list
> > > linux-arm-ker...@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: linux-next: manual merge of the drivers-x86 tree with the drm-misc tree
On Fri, Feb 5, 2021 at 12:14 PM Patrik Jakobsson wrote: > > On Fri, Feb 5, 2021 at 12:07 PM Andy Shevchenko > wrote: > > > > On Thu, Feb 4, 2021 at 11:04 AM Andy Shevchenko > > wrote: > > >> Today's linux-next merge of the drivers-x86 tree got a conflict in: > > > > > > Thanks. I already asked Patrik yesterday day if DRM missed to pull an > > > immutable tag I provided. I think they can pull and resolve conflicts > > > themselves. Alternatively it would be easy to resolve by Linus by > > > removing Kconfig lines along with mentioned files, > > > > Patrik, I have sent a PR again, so you may consider pulling it, thanks! > > Daniel, is this something you can pull into drm or ask one of the > drm-misc maintainers to do? We've already created the conflict, and my understanding is that Linus wants to have visibility into conflict-y stuff and doesn't mind at all resolving conflicts. Hence for 5.12 I think we're fine as-is. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH] PCI: Also set up legacy files only after sysfs init
We are already doing this for all the regular sysfs files on PCI
devices, but not yet on the legacy io files on the PCI buses. Thus far
no problem, but in the next patch I want to wire up iomem revoke
support. That needs the vfs up and running already to make sure that
iomem_get_mapping() works.
Wire it up exactly like the existing code in
pci_create_sysfs_dev_files(). Note that pci_remove_legacy_files()
doesn't need a check since the one for pci_bus->legacy_io is
sufficient.
An alternative solution would be to implement a callback in sysfs to
set up the address space from iomem_get_mapping() when userspace calls
mmap(). This also works, but Greg didn't really like that just to work
around an ordering issue when the kernel loads initially.
v2: Improve commit message (Bjorn)
Signed-off-by: Daniel Vetter
Cc: Stephen Rothwell
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: Greg Kroah-Hartman
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Bjorn Helgaas
Cc: linux-...@vger.kernel.org
---
drivers/pci/pci-sysfs.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index fb072f4b3176..0c45b4f7b214 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -927,6 +927,9 @@ void pci_create_legacy_files(struct pci_bus *b)
{
int error;
+ if (!sysfs_initialized)
+ return;
+
b->legacy_io = kcalloc(2, sizeof(struct bin_attribute),
GFP_ATOMIC);
if (!b->legacy_io)
@@ -1448,6 +1451,7 @@ void pci_remove_sysfs_dev_files(struct pci_dev *pdev)
static int __init pci_sysfs_init(void)
{
struct pci_dev *pdev = NULL;
+ struct pci_bus *pbus = NULL;
int retval;
sysfs_initialized = 1;
@@ -1459,6 +1463,9 @@ static int __init pci_sysfs_init(void)
}
}
+ while ((pbus = pci_find_next_bus(pbus)))
+ pci_create_legacy_files(pbus);
+
return 0;
}
late_initcall(pci_sysfs_init);
--
2.30.0
Re: [PATCH v2] kernel: Expose SYS_kcmp by default
On Fri, Feb 5, 2021 at 10:28 PM Chris Wilson wrote: > > Quoting Kees Cook (2021-02-05 21:20:33) > > On Fri, Feb 05, 2021 at 09:16:01PM +, Chris Wilson wrote: > > > The subject should of course be changed, as it is no longer being > > > enabled by default. > > > > "default n" is redundant. > > I thought being explicit would be preferred. There are a few other > default n, so at least it's not the odd-one-out! > > > I thought Daniel said CONFIG_DRM needed to > > "select" it too, though? > > Yes. We will need to select it for any DRM driver so that the Vulkan/GL > stacks can rely on having SYS_kcmp. That deserves to be handled and > explain within drm/Kconfig, and as they are already shipping with calls > to SYS_kcmp we may have to ask for a stable backport. Oh I dreamed and thought it's part of this patch already. So v3 with matching subject to enabled it for drm? -Daniel > > > Otherwise, yeah, this looks good. Was the > > export due to the 0-day bot failure reports? > > Yes. > -Chris -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] kernel: Expose SYS_kcmp by default
On Fri, Feb 5, 2021 at 7:37 PM Kees Cook wrote: > > On Fri, Feb 05, 2021 at 04:37:52PM +, Chris Wilson wrote: > > Userspace has discovered the functionality offered by SYS_kcmp and has > > started to depend upon it. In particular, Mesa uses SYS_kcmp for > > os_same_file_description() in order to identify when two fd (e.g. device > > or dmabuf) point to the same struct file. Since they depend on it for > > core functionality, lift SYS_kcmp out of the non-default > > CONFIG_CHECKPOINT_RESTORE into the selectable syscall category. > > > > Signed-off-by: Chris Wilson > > Cc: Kees Cook > > Cc: Andy Lutomirski > > Cc: Will Drewry > > Cc: Andrew Morton > > Cc: Dave Airlie > > Cc: Daniel Vetter > > Cc: Lucas Stach > > --- > > init/Kconfig | 11 +++ > > kernel/Makefile | 2 +- > > tools/testing/selftests/seccomp/seccomp_bpf.c | 2 +- > > 3 files changed, 13 insertions(+), 2 deletions(-) > > > > diff --git a/init/Kconfig b/init/Kconfig > > index b77c60f8b963..f62fca13ac5b 100644 > > --- a/init/Kconfig > > +++ b/init/Kconfig > > @@ -1194,6 +1194,7 @@ endif # NAMESPACES > > config CHECKPOINT_RESTORE > > bool "Checkpoint/restore support" > > select PROC_CHILDREN > > + select KCMP > > default n > > help > > Enables additional kernel features in a sake of checkpoint/restore. > > @@ -1737,6 +1738,16 @@ config ARCH_HAS_MEMBARRIER_CALLBACKS > > config ARCH_HAS_MEMBARRIER_SYNC_CORE > > bool > > > > +config KCMP > > + bool "Enable kcmp() system call" if EXPERT > > + default y > > I would expect this to be not default-y, especially if > CHECKPOINT_RESTORE does a "select" on it. > > This is a really powerful syscall, but it is bounded by ptrace access > controls, and uses pointer address obfuscation, so it may be okay to > expose this. As it is, at least Ubuntu already has > CONFIG_CHECKPOINT_RESTORE, so really, there's probably not much > difference on exposure. > > So, if you drop the "default y", I'm fine with this. It was maybe stupid, but our userspace started relying on fd comaprison through sys_kcomp. So for better or worse, if you want to run the mesa3d gl/vk stacks, you need this. Was maybe not the brighest ideas, but since enough distros had this enabled by defaults, it wasn't really discovered, and now we're shipping this everywhere. Ofc we can leave the default n, but the select if CONFIG_DRM is unfortunately needed I think. For that part: Acked-by: Daniel Vetter Also adding Dave Airlie for his take. -Daniel > > -Kees > > > + help > > + Enable the file descriptor comparison system call. It provides > > + user-space with the ability to compare two fd to see if they > > + point to the same file, and check other attributes. > > + > > + If unsure, say Y. > > + > > config RSEQ > > bool "Enable rseq() system call" if EXPERT > > default y > > diff --git a/kernel/Makefile b/kernel/Makefile > > index aa7368c7eabf..320f1f3941b7 100644 > > --- a/kernel/Makefile > > +++ b/kernel/Makefile > > @@ -51,7 +51,7 @@ obj-y += livepatch/ > > obj-y += dma/ > > obj-y += entry/ > > > > -obj-$(CONFIG_CHECKPOINT_RESTORE) += kcmp.o > > +obj-$(CONFIG_KCMP) += kcmp.o > > obj-$(CONFIG_FREEZER) += freezer.o > > obj-$(CONFIG_PROFILING) += profile.o > > obj-$(CONFIG_STACKTRACE) += stacktrace.o > > diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c > > b/tools/testing/selftests/seccomp/seccomp_bpf.c > > index 26c72f2b61b1..1b6c7d33c4ff 100644 > > --- a/tools/testing/selftests/seccomp/seccomp_bpf.c > > +++ b/tools/testing/selftests/seccomp/seccomp_bpf.c > > @@ -315,7 +315,7 @@ TEST(kcmp) > > ret = __filecmp(getpid(), getpid(), 1, 1); > > EXPECT_EQ(ret, 0); > > if (ret != 0 && errno == ENOSYS) > > - SKIP(return, "Kernel does not support kcmp() (missing > > CONFIG_CHECKPOINT_RESTORE?)"); > > + SKIP(return, "Kernel does not support kcmp() (missing > > CONFIG_KCMP?)"); > > } > > > > TEST(mode_strict_support) > > -- > > 2.20.1 > > > > -- > Kees Cook -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH 1/2] PCI: also set up legacy files only after sysfs init
On Fri, Feb 5, 2021 at 11:04 AM Pali Rohár wrote: > > On Friday 05 February 2021 10:59:50 Daniel Vetter wrote: > > On Thu, Feb 4, 2021 at 11:24 PM Pali Rohár wrote: > > > > > > On Thursday 04 February 2021 15:50:19 Bjorn Helgaas wrote: > > > > [+cc Oliver, Pali, Krzysztof] > > > > > > Just to note that extending or using sysfs_initialized introduces > > > another race condition into kernel code which results in PCI fatal > > > errors. Details are in email discussion which Bjorn already sent. > > > > Yeah I wondered why this doesn't race. > > It races, but with smaller probability. I have not seen this race > condition on x86. But I was able to reproduce it with native PCIe > drivers on ARM64 (Marvell Armada 3720; pci-aardvark). In mentioned > discussion I wrote when this race condition happen. But I understand > that it is hard to simulate it. btw I looked at your patch, and isn't that just reducing the race window? I think we have a very similar problem in drm, where the drm_dev_register() for the overall device (which also registers all drm_connector) can race with the hotplug of an individual connector in drm_connector_register() which is hotplugged at runtime. I went with a per-connector registered boolean + a lock to make sure that really only one of the two call paths can end up registering the connector. Part of registering connectors is setting up sysfs files, so I think it's exactly the same problem as here. Cheers, Daniel > > > but since the history goes back > > to pre-git times I figured it would have been addressed somehow > > already if it indeed does race. > > -Daniel > > > > > > s/also/Also/ in subject > > > > > > > > On Thu, Feb 04, 2021 at 05:58:30PM +0100, Daniel Vetter wrote: > > > > > We are already doing this for all the regular sysfs files on PCI > > > > > devices, but not yet on the legacy io files on the PCI buses. Thus far > > > > > now problem, but in the next patch I want to wire up iomem revoke > > > > > support. That needs the vfs up an running already to make so that > > > > > iomem_get_mapping() works. > > > > > > > > s/now problem/no problem/ > > > > s/an running/and running/ > > > > s/so that/sure that/ ? > > > > > > > > iomem_get_mapping() doesn't exist; I don't know what that should be. > > > > > > > > > Wire it up exactly like the existing code. Note that > > > > > pci_remove_legacy_files() doesn't need a check since the one for > > > > > pci_bus->legacy_io is sufficient. > > > > > > > > I'm not sure exactly what you mean by "the existing code." I could > > > > probably figure it out, but it would save time to mention the existing > > > > function here. > > > > > > > > This looks like another instance where we should really apply Oliver's > > > > idea of converting these to attribute_groups [1]. > > > > > > > > The cover letter mentions options discussed with Greg in [2], but I > > > > don't think the "sysfs_initialized" hack vs attribute_groups was part > > > > of that discussion. > > > > > > > > It's not absolutely a show-stopper, but it *is* a shame to extend the > > > > sysfs_initialized hack if attribute_groups could do this more cleanly > > > > and help solve more than one issue. > > > > > > > > Bjorn > > > > > > > > [1] > > > > https://lore.kernel.org/r/caosf1chss03dbsdo4pmttmp0tceu5kscn704zewlkgxqzbf...@mail.gmail.com > > > > [2] > > > > https://lore.kernel.org/dri-devel/cakmk7ugrddrbtj0oyzqqc0cgrqwc2f3tfju9vlfm2jjufaz...@mail.gmail.com/ > > > > > > > > > Signed-off-by: Daniel Vetter > > > > > Cc: Stephen Rothwell > > > > > Cc: Jason Gunthorpe > > > > > Cc: Kees Cook > > > > > Cc: Dan Williams > > > > > Cc: Andrew Morton > > > > > Cc: John Hubbard > > > > > Cc: Jérôme Glisse > > > > > Cc: Jan Kara > > > > > Cc: Dan Williams > > > > > Cc: Greg Kroah-Hartman > > > > > Cc: linux...@kvack.org > > > > > Cc: linux-arm-ker...@lists.infradead.org > > > > > Cc: linux-samsung-...@vger.kernel.org > > > > > Cc: linux-me...@vger.kernel.org > > > > > Cc: Bjorn Helgaas > > > > > Cc: linux-...@vger.kernel.org > > &
[tip: x86/sgx] x86/sgx: Drop racy follow_pfn() check
The following commit has been merged into the x86/sgx branch of tip:
Commit-ID: dc9b7be557ca94301ea5c06c0d72307e642ffb18
Gitweb:
https://git.kernel.org/tip/dc9b7be557ca94301ea5c06c0d72307e642ffb18
Author:Daniel Vetter
AuthorDate:Thu, 04 Feb 2021 19:45:19 +01:00
Committer: Borislav Petkov
CommitterDate: Fri, 05 Feb 2021 10:45:11 +01:00
x86/sgx: Drop racy follow_pfn() check
PTE insertion is fundamentally racy, and this check doesn't do anything
useful. Quoting Sean:
"Yeah, it can be whacked. The original, never-upstreamed code asserted
that the resolved PFN matched the PFN being installed by the fault
handler as a sanity check on the SGX driver's EPC management. The
WARN assertion got dropped for whatever reason, leaving that useless
chunk."
Jason stumbled over this as a new user of follow_pfn(), and I'm trying
to get rid of unsafe callers of that function so it can be locked down
further.
This is independent prep work for the referenced patch series:
https://lore.kernel.org/dri-devel/20201127164131.2244124-1-daniel.vet...@ffwll.ch/
Fixes: 947c6e11fa43 ("x86/sgx: Add ptrace() support for the SGX driver")
Reported-by: Jason Gunthorpe
Signed-off-by: Daniel Vetter
Signed-off-by: Borislav Petkov
Reviewed-by: Jarkko Sakkinen
Link: https://lkml.kernel.org/r/20210204184519.2809313-1-daniel.vet...@ffwll.ch
---
arch/x86/kernel/cpu/sgx/encl.c | 8
1 file changed, 8 deletions(-)
diff --git a/arch/x86/kernel/cpu/sgx/encl.c b/arch/x86/kernel/cpu/sgx/encl.c
index ee50a50..20a2dd5 100644
--- a/arch/x86/kernel/cpu/sgx/encl.c
+++ b/arch/x86/kernel/cpu/sgx/encl.c
@@ -141,7 +141,6 @@ static vm_fault_t sgx_vma_fault(struct vm_fault *vmf)
struct sgx_encl_page *entry;
unsigned long phys_addr;
struct sgx_encl *encl;
- unsigned long pfn;
vm_fault_t ret;
encl = vma->vm_private_data;
@@ -168,13 +167,6 @@ static vm_fault_t sgx_vma_fault(struct vm_fault *vmf)
phys_addr = sgx_get_epc_phys_addr(entry->epc_page);
- /* Check if another thread got here first to insert the PTE. */
- if (!follow_pfn(vma, addr, )) {
- mutex_unlock(>lock);
-
- return VM_FAULT_NOPAGE;
- }
-
ret = vmf_insert_pfn(vma, addr, PFN_DOWN(phys_addr));
if (ret != VM_FAULT_NOPAGE) {
mutex_unlock(>lock);
Re: [PATCH 1/2] PCI: also set up legacy files only after sysfs init
On Thu, Feb 4, 2021 at 10:50 PM Bjorn Helgaas wrote:
>
> [+cc Oliver, Pali, Krzysztof]
>
> s/also/Also/ in subject
>
> On Thu, Feb 04, 2021 at 05:58:30PM +0100, Daniel Vetter wrote:
> > We are already doing this for all the regular sysfs files on PCI
> > devices, but not yet on the legacy io files on the PCI buses. Thus far
> > now problem, but in the next patch I want to wire up iomem revoke
> > support. That needs the vfs up an running already to make so that
> > iomem_get_mapping() works.
>
> s/now problem/no problem/
> s/an running/and running/
> s/so that/sure that/ ?
>
> iomem_get_mapping() doesn't exist; I don't know what that should be.
Series is based on top of linux-next, where iomem_get_mapping exists.
This patch fixes the 2nd patch in this series, which I had to take out
of my branch because it failed.
> > Wire it up exactly like the existing code. Note that
> > pci_remove_legacy_files() doesn't need a check since the one for
> > pci_bus->legacy_io is sufficient.
>
> I'm not sure exactly what you mean by "the existing code." I could
> probably figure it out, but it would save time to mention the existing
> function here.
Sorry, I meant the existing code in pci_create_sysfs_dev_files().
> This looks like another instance where we should really apply Oliver's
> idea of converting these to attribute_groups [1].
>
> The cover letter mentions options discussed with Greg in [2], but I
> don't think the "sysfs_initialized" hack vs attribute_groups was part
> of that discussion.
Hm not sure the attribute_groups works. The problem is that I cant set
up the attributes before the vfs layer is initialized, because before
that point the iomem_get_mapping function doesn't return anything
useful (well it crashes), because it needs to have an inode available.
So if you want to set up the attributes earlier, we'd need some kind
of callback, which Greg didn't like.
> It's not absolutely a show-stopper, but it *is* a shame to extend the
> sysfs_initialized hack if attribute_groups could do this more cleanly
> and help solve more than one issue.
So I think I have yet another init ordering problem here, but not sure.
-Daniel
>
> Bjorn
>
> [1]
> https://lore.kernel.org/r/caosf1chss03dbsdo4pmttmp0tceu5kscn704zewlkgxqzbf...@mail.gmail.com
> [2]
> https://lore.kernel.org/dri-devel/cakmk7ugrddrbtj0oyzqqc0cgrqwc2f3tfju9vlfm2jjufaz...@mail.gmail.com/
>
> > Signed-off-by: Daniel Vetter
> > Cc: Stephen Rothwell
> > Cc: Jason Gunthorpe
> > Cc: Kees Cook
> > Cc: Dan Williams
> > Cc: Andrew Morton
> > Cc: John Hubbard
> > Cc: Jérôme Glisse
> > Cc: Jan Kara
> > Cc: Dan Williams
> > Cc: Greg Kroah-Hartman
> > Cc: linux...@kvack.org
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux-samsung-...@vger.kernel.org
> > Cc: linux-me...@vger.kernel.org
> > Cc: Bjorn Helgaas
> > Cc: linux-...@vger.kernel.org
> > ---
> > drivers/pci/pci-sysfs.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> > index fb072f4b3176..0c45b4f7b214 100644
> > --- a/drivers/pci/pci-sysfs.c
> > +++ b/drivers/pci/pci-sysfs.c
> > @@ -927,6 +927,9 @@ void pci_create_legacy_files(struct pci_bus *b)
> > {
> > int error;
> >
> > + if (!sysfs_initialized)
> > + return;
> > +
> > b->legacy_io = kcalloc(2, sizeof(struct bin_attribute),
> > GFP_ATOMIC);
> > if (!b->legacy_io)
> > @@ -1448,6 +1451,7 @@ void pci_remove_sysfs_dev_files(struct pci_dev *pdev)
> > static int __init pci_sysfs_init(void)
> > {
> > struct pci_dev *pdev = NULL;
> > + struct pci_bus *pbus = NULL;
> > int retval;
> >
> > sysfs_initialized = 1;
> > @@ -1459,6 +1463,9 @@ static int __init pci_sysfs_init(void)
> > }
> > }
> >
> > + while ((pbus = pci_find_next_bus(pbus)))
> > + pci_create_legacy_files(pbus);
> > +
> > return 0;
> > }
> > late_initcall(pci_sysfs_init);
> > --
> > 2.30.0
> >
> >
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH] x86/sgx: Drop racy follow_pfn check
On Fri, Feb 5, 2021 at 3:26 AM Jarkko Sakkinen wrote: > > On Thu, Feb 04, 2021 at 07:45:19PM +0100, Daniel Vetter wrote: > > References: > > https://lore.kernel.org/dri-devel/20201127164131.2244124-1-daniel.vet...@ffwll.ch/ > > What is the difference between this and "Link:" anyway? Afaik References: is for other reading (bug reports, discussions, other patch series), Link: is for patch submission itself (which I think some subsystem do an entire chain of, on each revision). My scripts aren't good enough that they add the Link: before submitting, I add them when I apply patches (since most patches I get don't have them anyway). btw since the final patch to remove follow_pfn won't be ready for 5.12 merge window (kvm and vfio have some work to do) I think it's best if you just queue this up in your tree? Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH 1/2] PCI: also set up legacy files only after sysfs init
We are already doing this for all the regular sysfs files on PCI
devices, but not yet on the legacy io files on the PCI buses. Thus far
now problem, but in the next patch I want to wire up iomem revoke
support. That needs the vfs up an running already to make so that
iomem_get_mapping() works.
Wire it up exactly like the existing code. Note that
pci_remove_legacy_files() doesn't need a check since the one for
pci_bus->legacy_io is sufficient.
Signed-off-by: Daniel Vetter
Cc: Stephen Rothwell
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: Greg Kroah-Hartman
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Bjorn Helgaas
Cc: linux-...@vger.kernel.org
---
drivers/pci/pci-sysfs.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index fb072f4b3176..0c45b4f7b214 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -927,6 +927,9 @@ void pci_create_legacy_files(struct pci_bus *b)
{
int error;
+ if (!sysfs_initialized)
+ return;
+
b->legacy_io = kcalloc(2, sizeof(struct bin_attribute),
GFP_ATOMIC);
if (!b->legacy_io)
@@ -1448,6 +1451,7 @@ void pci_remove_sysfs_dev_files(struct pci_dev *pdev)
static int __init pci_sysfs_init(void)
{
struct pci_dev *pdev = NULL;
+ struct pci_bus *pbus = NULL;
int retval;
sysfs_initialized = 1;
@@ -1459,6 +1463,9 @@ static int __init pci_sysfs_init(void)
}
}
+ while ((pbus = pci_find_next_bus(pbus)))
+ pci_create_legacy_files(pbus);
+
return 0;
}
late_initcall(pci_sysfs_init);
--
2.30.0
[PATCH] x86/sgx: Drop racy follow_pfn check
PTE insertion is fundamentally racy, and this check doesn't do
anything useful. Quoting Sean:
"Yeah, it can be whacked. The original, never-upstreamed code asserted that the
resolved PFN matched the PFN being installed by the fault handler as a sanity
check on the SGX driver's EPC management. The WARN assertion got dropped for
whatever reason, leaving that useless chunk."
Jason stumbled over this as a new user of follow_pfn, and I'm trying
to get rid of unsafe callers of that function so it can be locked down
further.
This is independent prep work for the referenced patch series.
References:
https://lore.kernel.org/dri-devel/20201127164131.2244124-1-daniel.vet...@ffwll.ch/
Reported-by: Jason Gunthorpe
Cc: Jason Gunthorpe
Cc: Sean Christopherson
Fixes: 947c6e11fa43 ("x86/sgx: Add ptrace() support for the SGX driver")
Cc: Jarkko Sakkinen
Cc: Borislav Petkov
Cc: linux-...@vger.kernel.org
Signed-off-by: Daniel Vetter
---
arch/x86/kernel/cpu/sgx/encl.c | 8
1 file changed, 8 deletions(-)
diff --git a/arch/x86/kernel/cpu/sgx/encl.c b/arch/x86/kernel/cpu/sgx/encl.c
index ee50a5010277..20a2dd5ba2b4 100644
--- a/arch/x86/kernel/cpu/sgx/encl.c
+++ b/arch/x86/kernel/cpu/sgx/encl.c
@@ -141,7 +141,6 @@ static vm_fault_t sgx_vma_fault(struct vm_fault *vmf)
struct sgx_encl_page *entry;
unsigned long phys_addr;
struct sgx_encl *encl;
- unsigned long pfn;
vm_fault_t ret;
encl = vma->vm_private_data;
@@ -168,13 +167,6 @@ static vm_fault_t sgx_vma_fault(struct vm_fault *vmf)
phys_addr = sgx_get_epc_phys_addr(entry->epc_page);
- /* Check if another thread got here first to insert the PTE. */
- if (!follow_pfn(vma, addr, )) {
- mutex_unlock(>lock);
-
- return VM_FAULT_NOPAGE;
- }
-
ret = vmf_insert_pfn(vma, addr, PFN_DOWN(phys_addr));
if (ret != VM_FAULT_NOPAGE) {
mutex_unlock(>lock);
--
2.30.0
[PATCH 2/2] PCI: Revoke mappings like devmem
Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims
the region") /dev/kmem zaps ptes when the kernel requests exclusive
acccess to an iomem region. And with CONFIG_IO_STRICT_DEVMEM, this is
the default for all driver uses.
Except there's two more ways to access PCI BARs: sysfs and proc mmap
support. Let's plug that hole.
For revoke_devmem() to work we need to link our vma into the same
address_space, with consistent vma->vm_pgoff. ->pgoff is already
adjusted, because that's how (io_)remap_pfn_range works, but for the
mapping we need to adjust vma->vm_file->f_mapping. The cleanest way is
to adjust this at at ->open time:
- for sysfs this is easy, now that binary attributes support this. We
just set bin_attr->mapping when mmap is supported
- for procfs it's a bit more tricky, since procfs pci access has only
one file per device, and access to a specific resources first needs
to be set up with some ioctl calls. But mmap is only supported for
the same resources as sysfs exposes with mmap support, and otherwise
rejected, so we can set the mapping unconditionally at open time
without harm.
A special consideration is for arch_can_pci_mmap_io() - we need to
make sure that the ->f_mapping doesn't alias between ioport and iomem
space. There's only 2 ways in-tree to support mmap of ioports: generic
pci mmap (ARCH_GENERIC_PCI_MMAP_RESOURCE), and sparc as the single
architecture hand-rolling. Both approach support ioport mmap through a
special pfn range and not through magic pte attributes. Aliasing is
therefore not a problem.
The only difference in access checks left is that sysfs PCI mmap does
not check for CAP_RAWIO. I'm not really sure whether that should be
added or not.
Acked-by: Bjorn Helgaas
Reviewed-by: Dan Williams
Signed-off-by: Daniel Vetter
Cc: Stephen Rothwell
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: Greg Kroah-Hartman
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Bjorn Helgaas
Cc: linux-...@vger.kernel.org
---
drivers/pci/pci-sysfs.c | 4
drivers/pci/proc.c | 1 +
2 files changed, 5 insertions(+)
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 0c45b4f7b214..f8afd54ca3e1 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -942,6 +942,7 @@ void pci_create_legacy_files(struct pci_bus *b)
b->legacy_io->read = pci_read_legacy_io;
b->legacy_io->write = pci_write_legacy_io;
b->legacy_io->mmap = pci_mmap_legacy_io;
+ b->legacy_io->mapping = iomem_get_mapping();
pci_adjust_legacy_attr(b, pci_mmap_io);
error = device_create_bin_file(>dev, b->legacy_io);
if (error)
@@ -954,6 +955,7 @@ void pci_create_legacy_files(struct pci_bus *b)
b->legacy_mem->size = 1024*1024;
b->legacy_mem->attr.mode = 0600;
b->legacy_mem->mmap = pci_mmap_legacy_mem;
+ b->legacy_io->mapping = iomem_get_mapping();
pci_adjust_legacy_attr(b, pci_mmap_mem);
error = device_create_bin_file(>dev, b->legacy_mem);
if (error)
@@ -1169,6 +1171,8 @@ static int pci_create_attr(struct pci_dev *pdev, int num,
int write_combine)
res_attr->mmap = pci_mmap_resource_uc;
}
}
+ if (res_attr->mmap)
+ res_attr->mapping = iomem_get_mapping();
res_attr->attr.name = res_attr_name;
res_attr->attr.mode = 0600;
res_attr->size = pci_resource_len(pdev, num);
diff --git a/drivers/pci/proc.c b/drivers/pci/proc.c
index 3a2f90beb4cb..9bab07302bbf 100644
--- a/drivers/pci/proc.c
+++ b/drivers/pci/proc.c
@@ -298,6 +298,7 @@ static int proc_bus_pci_open(struct inode *inode, struct
file *file)
fpriv->write_combine = 0;
file->private_data = fpriv;
+ file->f_mapping = iomem_get_mapping();
return 0;
}
--
2.30.0
[PATCH 0/2] pci sysfs file iomem revoke support
Hi all, This is a revised version of patch 12 from my series to lock down some follow_pfn vs VM_SPECIAL races: https://lore.kernel.org/dri-devel/cakwvodnsrsntgpeuqjyaotsktp2dr9208y66hqg_h1e2lkf...@mail.gmail.com/ Stephen reported an issue on HAVE_PCI_LEGACY platforms which this patch set tries to address. Previous patches are all still in linux-next. Stephen, would be awesome if you can give this a spin. Björn/Greg, review on the first patch is needed, I think that's the cleanest approach from all the options I discussed with Greg in this thread: https://lore.kernel.org/dri-devel/cakmk7ugrddrbtj0oyzqqc0cgrqwc2f3tfju9vlfm2jjufaz...@mail.gmail.com/ Cheers, Daniel Cc: Stephen Rothwell Cc: Jason Gunthorpe Cc: Kees Cook Cc: Dan Williams Cc: Andrew Morton Cc: John Hubbard Cc: Jérôme Glisse Cc: Jan Kara Cc: Dan Williams Cc: Greg Kroah-Hartman Cc: linux...@kvack.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-samsung-...@vger.kernel.org Cc: linux-me...@vger.kernel.org Cc: Bjorn Helgaas Cc: linux-...@vger.kernel.org Daniel Vetter (2): PCI: also set up legacy files only after sysfs init PCI: Revoke mappings like devmem drivers/pci/pci-sysfs.c | 11 +++ drivers/pci/proc.c | 1 + 2 files changed, 12 insertions(+) -- 2.30.0
Re: [Linaro-mm-sig] [PATCH 1/2] mm: replace BUG_ON in vm_insert_page with a return of an error
On Thu, Feb 04, 2021 at 09:16:32AM +0100, Christian König wrote: > Am 03.02.21 um 22:41 schrieb Suren Baghdasaryan: > > [SNIP] > > > > How many semi-unrelated buffer accounting schemes does google come up > > > > with? > > > > > > > > We're at three with this one. > > > > > > > > And also we _cannot_ required that all dma-bufs are backed by struct > > > > page, so requiring struct page to make this work is a no-go. > > > > > > > > Second, we do not want to all get_user_pages and friends to work on > > > > dma-buf, it causes all kinds of pain. Yes on SoC where dma-buf are > > > > exclusively in system memory you can maybe get away with this, but > > > > dma-buf is supposed to work in more places than just Android SoCs. > > > I just realized that vm_inser_page doesn't even work for CMA, it would > > > upset get_user_pages pretty badly - you're trying to pin a page in > > > ZONE_MOVEABLE but you can't move it because it's rather special. > > > VM_SPECIAL is exactly meant to catch this stuff. > > Thanks for the input, Daniel! Let me think about the cases you pointed out. > > > > IMHO, the issue with PSS is the difficulty of calculating this metric > > without struct page usage. I don't think that problem becomes easier > > if we use cgroups or any other API. I wanted to enable existing PSS > > calculation mechanisms for the dmabufs known to be backed by struct > > pages (since we know how the heap allocated that memory), but sounds > > like this would lead to problems that I did not consider. > > Yeah, using struct page indeed won't work. We discussed that multiple times > now and Daniel even has a patch to mangle the struct page pointers inside > the sg_table object to prevent abuse in that direction. > > On the other hand I totally agree that we need to do something on this side > which goes beyong what cgroups provide. > > A few years ago I came up with patches to improve the OOM killer to include > resources bound to the processes through file descriptors. I unfortunately > can't find them of hand any more and I'm currently to busy to dig them up. > > In general I think we need to make it possible that both the in kernel OOM > killer as well as userspace processes and handlers have access to that kind > of data. > > The fdinfo approach as suggested in the other thread sounds like the easiest > solution to me. Yeah for OOM handling cgroups alone isn't enough as the interface - we need to make sure that oom killer takes into account the system memory usage (ideally zone aware, for CMA pools). But to track that we still need that infrastructure first I think. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] drm/msm/kms: Make a lock_class_key for each crtc mutex
On Wed, Feb 03, 2021 at 02:11:09PM -0800, Rob Clark wrote:
> On Wed, Feb 3, 2021 at 1:58 PM Stephen Boyd wrote:
> >
> > Quoting Rob Clark (2021-02-03 09:29:09)
> > > On Wed, Feb 3, 2021 at 2:10 AM Daniel Vetter wrote:
> > > >
> > > > On Tue, Feb 02, 2021 at 08:51:25AM -0800, Rob Clark wrote:
> > > > > On Tue, Feb 2, 2021 at 7:46 AM Daniel Vetter wrote:
> > > > > >
> > > > > > On Mon, Jan 25, 2021 at 03:49:01PM -0800, Stephen Boyd wrote:
> > > > > > > This is because lockdep thinks all the locks taken in
> > > > > > > lock_crtcs() are
> > > > > > > the same lock, when they actually aren't. That's because we call
> > > > > > > mutex_init() in msm_kms_init() and that assigns on static key for
> > > > > > > every
> > > > > > > lock initialized in this loop. Let's allocate a dynamic number of
> > > > > > > lock_class_keys and assign them to each lock so that lockdep can
> > > > > > > figure
> > > > > > > out an AA deadlock isn't possible here.
> > > > > > >
> > > > > > > Fixes: b3d91800d9ac ("drm/msm: Fix race condition in msm driver
> > > > > > > with async layer updates")
> > > > > > > Cc: Krishna Manikandan
> > > > > > > Signed-off-by: Stephen Boyd
> > > > > >
> > > > > > This smells like throwing more bad after initial bad code ...
> > > > > >
> > > > > > First a rant:
> > > > > > https://blog.ffwll.ch/2020/08/lockdep-false-positives.html
> > > >
> > > > Some technical on the patch itself: I think you want
> > > > mutex_lock_nested(crtc->lock, drm_crtc_index(crtc)), not your own
> > > > locking
> > > > classes hand-rolled. It's defacto the same, but much more obviously
> > > > correct since self-documenting.
> > >
> > > hmm, yeah, that is a bit cleaner.. but this patch is already on
> > > msm-next, maybe I'll add a patch on top to change it
> >
> > How many CRTCs are there? The subclass number tops out at 8, per
> > MAX_LOCKDEP_SUBCLASSES so if we have more than that many bits possible
> > then it will fail.
Hm good point, tbh the mutex_lock_nested annotations isn't super awesome
either, it would be kinda neat if we could put that annotation into
mutex_lock_init fairly statically (and at that point we could allos resize
the array fairly easily I think at runtime).
The nice thing with the nesting index is just that it makes it a bit more
obvious that there's a static nesting going on and why it's ok.
-Daniel
> conveniently MAX_CRTCS is 8.. realistically I don't *think* you'd ever
> see more than 2 or 3
>
> BR,
> -R
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v7 12/17] PCI: Revoke mappings like devmem
On Wed, Feb 3, 2021 at 5:14 PM Daniel Vetter wrote:
>
> On Tue, Jan 19, 2021 at 5:03 PM Daniel Vetter wrote:
> >
> > On Tue, Jan 19, 2021 at 4:20 PM Greg Kroah-Hartman
> > wrote:
> > >
> > > On Tue, Jan 19, 2021 at 03:34:47PM +0100, Daniel Vetter wrote:
> > > > On Tue, Jan 19, 2021 at 3:32 PM Greg Kroah-Hartman
> > > > wrote:
> > > > >
> > > > > On Tue, Jan 19, 2021 at 09:17:55AM +0100, Daniel Vetter wrote:
> > > > > > On Fri, Nov 27, 2020 at 5:42 PM Daniel Vetter
> > > > > > wrote:
> > > > > > >
> > > > > > > Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver
> > > > > > > claims
> > > > > > > the region") /dev/kmem zaps ptes when the kernel requests
> > > > > > > exclusive
> > > > > > > acccess to an iomem region. And with CONFIG_IO_STRICT_DEVMEM,
> > > > > > > this is
> > > > > > > the default for all driver uses.
> > > > > > >
> > > > > > > Except there's two more ways to access PCI BARs: sysfs and proc
> > > > > > > mmap
> > > > > > > support. Let's plug that hole.
> > > > > > >
> > > > > > > For revoke_devmem() to work we need to link our vma into the same
> > > > > > > address_space, with consistent vma->vm_pgoff. ->pgoff is already
> > > > > > > adjusted, because that's how (io_)remap_pfn_range works, but for
> > > > > > > the
> > > > > > > mapping we need to adjust vma->vm_file->f_mapping. The cleanest
> > > > > > > way is
> > > > > > > to adjust this at at ->open time:
> > > > > > >
> > > > > > > - for sysfs this is easy, now that binary attributes support
> > > > > > > this. We
> > > > > > > just set bin_attr->mapping when mmap is supported
> > > > > > > - for procfs it's a bit more tricky, since procfs pci access has
> > > > > > > only
> > > > > > > one file per device, and access to a specific resources first
> > > > > > > needs
> > > > > > > to be set up with some ioctl calls. But mmap is only supported
> > > > > > > for
> > > > > > > the same resources as sysfs exposes with mmap support, and
> > > > > > > otherwise
> > > > > > > rejected, so we can set the mapping unconditionally at open time
> > > > > > > without harm.
> > > > > > >
> > > > > > > A special consideration is for arch_can_pci_mmap_io() - we need to
> > > > > > > make sure that the ->f_mapping doesn't alias between ioport and
> > > > > > > iomem
> > > > > > > space. There's only 2 ways in-tree to support mmap of ioports:
> > > > > > > generic
> > > > > > > pci mmap (ARCH_GENERIC_PCI_MMAP_RESOURCE), and sparc as the single
> > > > > > > architecture hand-rolling. Both approach support ioport mmap
> > > > > > > through a
> > > > > > > special pfn range and not through magic pte attributes. Aliasing
> > > > > > > is
> > > > > > > therefore not a problem.
> > > > > > >
> > > > > > > The only difference in access checks left is that sysfs PCI mmap
> > > > > > > does
> > > > > > > not check for CAP_RAWIO. I'm not really sure whether that should
> > > > > > > be
> > > > > > > added or not.
> > > > > > >
> > > > > > > Acked-by: Bjorn Helgaas
> > > > > > > Reviewed-by: Dan Williams
> > > > > > > Signed-off-by: Daniel Vetter
> > > > > > > Cc: Jason Gunthorpe
> > > > > > > Cc: Kees Cook
> > > > > > > Cc: Dan Williams
> > > > > > > Cc: Andrew Morton
> > > > > > > Cc: John Hubbard
> > > > > > > Cc: Jérôme Glisse
> > > > > > > Cc: Jan Kara
> > > > > > > Cc: Dan Williams
> > > > > > > Cc: Greg Kroah-Hartman
> > > > > > > Cc: linux...@kvack.org
> > > >
Re: [Linaro-mm-sig] [PATCH v3] dmabuf: Add the capability to expose DMA-BUF stats in sysfs
On Thu, Feb 4, 2021 at 9:13 AM Christian König wrote: > > Am 03.02.21 um 21:14 schrieb Hridya Valsaraju: > > On Wed, Feb 3, 2021 at 2:25 AM Daniel Vetter wrote: > >> On Mon, Feb 01, 2021 at 01:02:30PM -0800, Hridya Valsaraju wrote: > >>> On Mon, Feb 1, 2021 at 10:37 AM Daniel Vetter wrote: > >>>> On Thu, Jan 28, 2021 at 1:03 PM Sumit Semwal > >>>> wrote: > >>>>> On Thu, 28 Jan 2021 at 17:23, Christian König > >>>>> wrote: > >>>>>> Am 28.01.21 um 12:00 schrieb Sumit Semwal: > >>>>>>> Hi Hridya, > >>>>>>> > >>>>>>> On Wed, 27 Jan 2021 at 17:36, Greg KH > >>>>>>> wrote: > >>>>>>>> On Tue, Jan 26, 2021 at 12:42:36PM -0800, Hridya Valsaraju wrote: > >>>>>>>>> This patch allows statistics to be enabled for each DMA-BUF in > >>>>>>>>> sysfs by enabling the config CONFIG_DMABUF_SYSFS_STATS. > >>>>>>>>> > >>>>>>>>> The following stats will be exposed by the interface: > >>>>>>>>> > >>>>>>>>> /sys/kernel/dmabuf/buffers//exporter_name > >>>>>>>>> /sys/kernel/dmabuf/buffers//size > >>>>>>>>> /sys/kernel/dmabuf/buffers//attachments//device > >>>>>>>>> /sys/kernel/dmabuf/buffers//attachments//map_counter > >>>>>>>>> > >>>>>>>>> The inode_number is unique for each DMA-BUF and was added earlier > >>>>>>>>> [1] > >>>>>>>>> in order to allow userspace to track DMA-BUF usage across different > >>>>>>>>> processes. > >>>>>>>>> > >>>>>>>>> Currently, this information is exposed in > >>>>>>>>> /sys/kernel/debug/dma_buf/bufinfo. > >>>>>>>>> However, since debugfs is considered unsafe to be mounted in > >>>>>>>>> production, > >>>>>>>>> it is being duplicated in sysfs. > >>>>>>>>> > >>>>>>>>> This information will be used to derive DMA-BUF > >>>>>>>>> per-exporter stats and per-device usage stats for Android Bug > >>>>>>>>> reports. > >>>>>>>>> The corresponding userspace changes can be found at [2]. > >>>>>>>>> Telemetry tools will also capture this information(along with other > >>>>>>>>> memory metrics) periodically as well as on important events like a > >>>>>>>>> foreground app kill (which might have been triggered by Low Memory > >>>>>>>>> Killer). It will also contribute to provide a snapshot of the system > >>>>>>>>> memory usage on other events such as OOM kills and Application Not > >>>>>>>>> Responding events. > >>>>>>>>> > >>>>>>>>> A shell script that can be run on a classic Linux environment to > >>>>>>>>> read > >>>>>>>>> out the DMA-BUF statistics can be found at [3](suggested by John > >>>>>>>>> Stultz). > >>>>>>>>> > >>>>>>>>> The patch contains the following improvements over the previous > >>>>>>>>> version: > >>>>>>>>> 1) Each attachment is represented by its own directory to allow > >>>>>>>>> creating > >>>>>>>>> a symlink to the importing device and to also provide room for > >>>>>>>>> future > >>>>>>>>> expansion. > >>>>>>>>> 2) The number of distinct mappings of each attachment is exposed in > >>>>>>>>> a > >>>>>>>>> separate file. > >>>>>>>>> 3) The per-buffer statistics are now in /sys/kernel/dmabuf/buffers > >>>>>>>>> inorder to make the interface expandable in future. > >>>>>>>>> > >>>>>>>>> All of the improvements above are based on suggestions/feedback from > >>>>>>>>> Daniel Vetter and Christian König. > >&
