Re: [PATCH v3 0/7] lib/string: Add strscpy_pad() function
On Thu, Mar 7, 2019 at 9:24 PM Tobin C. Harding wrote: > Two weeks and I'm throwing eggs at your house. If you can gets eggs from there to here I have a whole new international shipping business proposition for you. :) -- Kees Cook
[PATCH 0/4] drm/v3d: Add drm core helper, use shmem helpers
This was inspired by Rob's respin of the shmem helpers patch for panfrost (which the final patch depends on). And, looking at panfrost and lima, recently I realized that we all had some nasty cargo-cult code for BO reservations that we can share now that the reservation object is in the core GEM struct. Eric Anholt (4): drm: Add helpers for locking an array of BO reservations. drm/v3d: Use drm_gem_lock_reservations()/drm_gem_unlock_reservations() drm/v3d: Remove some dead members of struct v3d_bo. drm/v3d: Use the new shmem helpers to reduce driver boilerplate. drivers/gpu/drm/drm_gem.c | 76 + drivers/gpu/drm/v3d/Kconfig | 1 + drivers/gpu/drm/v3d/v3d_bo.c | 309 ++ drivers/gpu/drm/v3d/v3d_drv.c | 27 +-- drivers/gpu/drm/v3d/v3d_drv.h | 25 +-- drivers/gpu/drm/v3d/v3d_gem.c | 67 ++-- drivers/gpu/drm/v3d/v3d_irq.c | 8 +- drivers/gpu/drm/v3d/v3d_mmu.c | 34 +++- include/drm/drm_gem.h | 4 + 9 files changed, 220 insertions(+), 331 deletions(-) -- 2.20.1
[PATCH 4/4] drm/v3d: Use the new shmem helpers to reduce driver boilerplate.
Depends on
https://patchwork.freedesktop.org/patch/290754/?series=57669=1 --
Rob and I have been talking about adding some more help for the
dma_map_sg() code in v3d_mmu.c (which panfrost has a similar version
of), but this already seems like a good cleanup.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/v3d/Kconfig | 1 +
drivers/gpu/drm/v3d/v3d_bo.c | 308 ++
drivers/gpu/drm/v3d/v3d_drv.c | 27 +--
drivers/gpu/drm/v3d/v3d_drv.h | 16 +-
drivers/gpu/drm/v3d/v3d_gem.c | 11 +-
drivers/gpu/drm/v3d/v3d_irq.c | 8 +-
drivers/gpu/drm/v3d/v3d_mmu.c | 34 +++-
7 files changed, 134 insertions(+), 271 deletions(-)
diff --git a/drivers/gpu/drm/v3d/Kconfig b/drivers/gpu/drm/v3d/Kconfig
index 1552bf552c94..75a74c45f109 100644
--- a/drivers/gpu/drm/v3d/Kconfig
+++ b/drivers/gpu/drm/v3d/Kconfig
@@ -5,6 +5,7 @@ config DRM_V3D
depends on COMMON_CLK
depends on MMU
select DRM_SCHED
+ select DRM_GEM_SHMEM_HELPER
help
Choose this option if you have a system that has a Broadcom
V3D 3.x or newer GPU, such as BCM7268.
diff --git a/drivers/gpu/drm/v3d/v3d_bo.c b/drivers/gpu/drm/v3d/v3d_bo.c
index dff38bf36c50..b631ade09853 100644
--- a/drivers/gpu/drm/v3d/v3d_bo.c
+++ b/drivers/gpu/drm/v3d/v3d_bo.c
@@ -25,158 +25,6 @@
#include "v3d_drv.h"
#include "uapi/drm/v3d_drm.h"
-/* Pins the shmem pages, fills in the .pages and .sgt fields of the BO, and
maps
- * it for DMA.
- */
-static int
-v3d_bo_get_pages(struct v3d_bo *bo)
-{
- struct drm_gem_object *obj = >base;
- struct drm_device *dev = obj->dev;
- int npages = obj->size >> PAGE_SHIFT;
- int ret = 0;
-
- mutex_lock(>lock);
- if (bo->pages_refcount++ != 0)
- goto unlock;
-
- if (!obj->import_attach) {
- bo->pages = drm_gem_get_pages(obj);
- if (IS_ERR(bo->pages)) {
- ret = PTR_ERR(bo->pages);
- goto unlock;
- }
-
- bo->sgt = drm_prime_pages_to_sg(bo->pages, npages);
- if (IS_ERR(bo->sgt)) {
- ret = PTR_ERR(bo->sgt);
- goto put_pages;
- }
-
- /* Map the pages for use by the GPU. */
- dma_map_sg(dev->dev, bo->sgt->sgl,
- bo->sgt->nents, DMA_BIDIRECTIONAL);
- } else {
- bo->pages = kcalloc(npages, sizeof(*bo->pages), GFP_KERNEL);
- if (!bo->pages)
- goto put_pages;
-
- drm_prime_sg_to_page_addr_arrays(bo->sgt, bo->pages,
-NULL, npages);
-
- /* Note that dma-bufs come in mapped. */
- }
-
- mutex_unlock(>lock);
-
- return 0;
-
-put_pages:
- drm_gem_put_pages(obj, bo->pages, true, true);
- bo->pages = NULL;
-unlock:
- bo->pages_refcount--;
- mutex_unlock(>lock);
- return ret;
-}
-
-static void
-v3d_bo_put_pages(struct v3d_bo *bo)
-{
- struct drm_gem_object *obj = >base;
-
- mutex_lock(>lock);
- if (--bo->pages_refcount == 0) {
- if (!obj->import_attach) {
- dma_unmap_sg(obj->dev->dev, bo->sgt->sgl,
-bo->sgt->nents, DMA_BIDIRECTIONAL);
- sg_free_table(bo->sgt);
- kfree(bo->sgt);
- drm_gem_put_pages(obj, bo->pages, true, true);
- } else {
- kfree(bo->pages);
- }
- }
- mutex_unlock(>lock);
-}
-
-static struct v3d_bo *v3d_bo_create_struct(struct drm_device *dev,
- size_t unaligned_size)
-{
- struct v3d_dev *v3d = to_v3d_dev(dev);
- struct drm_gem_object *obj;
- struct v3d_bo *bo;
- size_t size = roundup(unaligned_size, PAGE_SIZE);
- int ret;
-
- if (size == 0)
- return ERR_PTR(-EINVAL);
-
- bo = kzalloc(sizeof(*bo), GFP_KERNEL);
- if (!bo)
- return ERR_PTR(-ENOMEM);
- obj = >base;
-
- INIT_LIST_HEAD(>unref_head);
- mutex_init(>lock);
-
- ret = drm_gem_object_init(dev, obj, size);
- if (ret)
- goto free_bo;
-
- spin_lock(>mm_lock);
- ret = drm_mm_insert_node_generic(>mm, >node,
-obj->size >> PAGE_SHIFT,
-GMP_GRANULARITY >> PAGE_SHIFT, 0, 0);
- spin_unlock(>mm_lock);
- if (ret)
- goto free_obj;
-
- return bo;
-
-free_obj:
- drm_gem_object_release(obj);
-free_bo:
- kfree(bo);
- return ERR_PTR(ret);
-}
-
-struct v3d_bo *v3d_bo_create(struct drm_device *dev, struct drm_file
*file_priv,
-size_t unaligned_size)
-{
- struct v3d_dev *v3d = to_v3d_dev(dev);
- struct drm_gem_object *obj;
-
[PATCH 1/4] drm: Add helpers for locking an array of BO reservations.
Now that we have the reservation object in the GEM object, it's easy
to provide a helper for this common case. Noticed while reviewing
panfrost and lima drivers. This particular version came out of v3d,
which in turn was a copy from vc4.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/drm_gem.c | 76 +++
include/drm/drm_gem.h | 4 +++
2 files changed, 80 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index ad124f5a6f4d..9fd804f7d7ca 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1233,3 +1233,79 @@ void drm_gem_vunmap(struct drm_gem_object *obj, void
*vaddr)
obj->dev->driver->gem_prime_vunmap(obj, vaddr);
}
EXPORT_SYMBOL(drm_gem_vunmap);
+
+/**
+ * drm_gem_lock_bo_reservations - Sets up the ww context and acquires
+ * the lock on an array of GEM objects.
+ *
+ * Once you've locked your reservations, you'll want to set up space
+ * for your shared fences (if applicable), submit your job, then
+ * drm_gem_unlock_reservations().
+ *
+ * @acquire_ctx - struct ww_acquire_ctx that will be initialized as
+ * part of tracking this set of locked reservations.
+ */
+int
+drm_gem_lock_reservations(struct drm_gem_object **objs, int count,
+ struct ww_acquire_ctx *acquire_ctx)
+{
+ int contended = -1;
+ int i, ret;
+
+ ww_acquire_init(acquire_ctx, _ww_class);
+
+retry:
+ if (contended != -1) {
+ struct drm_gem_object *obj = objs[contended];
+
+ ret = ww_mutex_lock_slow_interruptible(>resv->lock,
+ acquire_ctx);
+ if (ret) {
+ ww_acquire_done(acquire_ctx);
+ return ret;
+ }
+ }
+
+ for (i = 0; i < count; i++) {
+ if (i == contended)
+ continue;
+
+ ret = ww_mutex_lock_interruptible([i]->resv->lock,
+ acquire_ctx);
+ if (ret) {
+ int j;
+
+ for (j = 0; j < i; j++)
+ ww_mutex_unlock([j]->resv->lock);
+
+ if (contended != -1 && contended >= i)
+ ww_mutex_unlock([contended]->resv->lock);
+
+ if (ret == -EDEADLK) {
+ contended = i;
+ goto retry;
+ }
+
+ ww_acquire_done(acquire_ctx);
+ return ret;
+ }
+ }
+
+ ww_acquire_done(acquire_ctx);
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_gem_lock_reservations);
+
+void
+drm_gem_unlock_reservations(struct drm_gem_object **objs, int count,
+ struct ww_acquire_ctx *acquire_ctx)
+{
+ int i;
+
+ for (i = 0; i < count; i++)
+ ww_mutex_unlock([i]->resv->lock);
+
+ ww_acquire_fini(acquire_ctx);
+}
+EXPORT_SYMBOL(drm_gem_unlock_reservations);
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 25f1ff2df464..2955aaab3dca 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -384,6 +384,10 @@ void drm_gem_put_pages(struct drm_gem_object *obj, struct
page **pages,
struct drm_gem_object *drm_gem_object_lookup(struct drm_file *filp, u32
handle);
long drm_gem_reservation_object_wait(struct drm_file *filep, u32 handle,
bool wait_all, unsigned long timeout);
+int drm_gem_lock_reservations(struct drm_gem_object **objs, int count,
+ struct ww_acquire_ctx *acquire_ctx);
+void drm_gem_unlock_reservations(struct drm_gem_object **objs, int count,
+struct ww_acquire_ctx *acquire_ctx);
int drm_gem_dumb_map_offset(struct drm_file *file, struct drm_device *dev,
u32 handle, u64 *offset);
int drm_gem_dumb_destroy(struct drm_file *file,
--
2.20.1
[PATCH 2/4] drm/v3d: Use drm_gem_lock_reservations()/drm_gem_unlock_reservations()
Now that we have core helpers, this gets rid of a lot of boilerplate.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/v3d/v3d_gem.c | 56 ---
1 file changed, 6 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index 0d1e5e0b8042..a4338d56ff9e 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -199,12 +199,8 @@ v3d_unlock_bo_reservations(struct v3d_bo **bos,
int bo_count,
struct ww_acquire_ctx *acquire_ctx)
{
- int i;
-
- for (i = 0; i < bo_count; i++)
- ww_mutex_unlock([i]->base.resv->lock);
-
- ww_acquire_fini(acquire_ctx);
+ drm_gem_unlock_reservations((struct drm_gem_object **)bos, bo_count,
+ acquire_ctx);
}
/* Takes the reservation lock on all the BOs being referenced, so that
@@ -219,52 +215,12 @@ v3d_lock_bo_reservations(struct v3d_bo **bos,
int bo_count,
struct ww_acquire_ctx *acquire_ctx)
{
- int contended_lock = -1;
int i, ret;
- ww_acquire_init(acquire_ctx, _ww_class);
-
-retry:
- if (contended_lock != -1) {
- struct v3d_bo *bo = bos[contended_lock];
-
- ret = ww_mutex_lock_slow_interruptible(>base.resv->lock,
- acquire_ctx);
- if (ret) {
- ww_acquire_done(acquire_ctx);
- return ret;
- }
- }
-
- for (i = 0; i < bo_count; i++) {
- if (i == contended_lock)
- continue;
-
- ret = ww_mutex_lock_interruptible([i]->base.resv->lock,
- acquire_ctx);
- if (ret) {
- int j;
-
- for (j = 0; j < i; j++)
- ww_mutex_unlock([j]->base.resv->lock);
-
- if (contended_lock != -1 && contended_lock >= i) {
- struct v3d_bo *bo = bos[contended_lock];
-
- ww_mutex_unlock(>base.resv->lock);
- }
-
- if (ret == -EDEADLK) {
- contended_lock = i;
- goto retry;
- }
-
- ww_acquire_done(acquire_ctx);
- return ret;
- }
- }
-
- ww_acquire_done(acquire_ctx);
+ ret = drm_gem_lock_reservations((struct drm_gem_object **)bos,
+ bo_count, acquire_ctx);
+ if (ret)
+ return ret;
/* Reserve space for our shared (read-only) fence references,
* before we commit the CL to the hardware.
--
2.20.1
[PATCH 3/4] drm/v3d: Remove some dead members of struct v3d_bo.
vmas was from the previous model of page table management (one per
fd), and vaddr was left over from vc4.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/v3d/v3d_bo.c | 1 -
drivers/gpu/drm/v3d/v3d_drv.h | 9 -
2 files changed, 10 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_bo.c b/drivers/gpu/drm/v3d/v3d_bo.c
index 5c83b392b20a..dff38bf36c50 100644
--- a/drivers/gpu/drm/v3d/v3d_bo.c
+++ b/drivers/gpu/drm/v3d/v3d_bo.c
@@ -117,7 +117,6 @@ static struct v3d_bo *v3d_bo_create_struct(struct
drm_device *dev,
return ERR_PTR(-ENOMEM);
obj = >base;
- INIT_LIST_HEAD(>vmas);
INIT_LIST_HEAD(>unref_head);
mutex_init(>lock);
diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
index d856159bd007..f5ed915a0f15 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++ b/drivers/gpu/drm/v3d/v3d_drv.h
@@ -108,12 +108,6 @@ struct v3d_file_priv {
struct drm_sched_entity sched_entity[V3D_MAX_QUEUES];
};
-/* Tracks a mapping of a BO into a per-fd address space */
-struct v3d_vma {
- struct v3d_page_table *pt;
- struct list_head list; /* entry in v3d_bo.vmas */
-};
-
struct v3d_bo {
struct drm_gem_object base;
@@ -124,9 +118,6 @@ struct v3d_bo {
u32 pages_refcount;
struct page **pages;
struct sg_table *sgt;
- void *vaddr;
-
- struct list_head vmas;/* list of v3d_vma */
/* List entry for the BO's position in
* v3d_exec_info->unref_list
--
2.20.1
Re: [PATCH] ASoC: fsl: sai: Reduce underrun when stream starts
Hi Daniel, On Fri, Mar 8, 2019 at 1:09 PM Daniel Baluta wrote: > > From: Shengjiu Wang > > Write initial words into SAI FIFO to reduce the underrun > error. Please provide a better explanation. Why does performing these writes help? Also, the commit message says "reduce", so it seems this is a workaround instead of a proper fix?
Re: [RFC 02/15] slub: Add isolate() and migrate() methods
On Fri, 8 Mar 2019, Tycho Andersen wrote: > On Fri, Mar 08, 2019 at 03:14:13PM +1100, Tobin C. Harding wrote: > > diff --git a/mm/slab_common.c b/mm/slab_common.c > > index f9d89c1b5977..754acdb292e4 100644 > > --- a/mm/slab_common.c > > +++ b/mm/slab_common.c > > @@ -298,6 +298,10 @@ int slab_unmergeable(struct kmem_cache *s) > > if (!is_root_cache(s)) > > return 1; > > > > + /* > > +* s->isolate and s->migrate imply s->ctor so no need to > > +* check them explicitly. > > +*/ > > Shouldn't this implication go the other way, i.e. > s->ctor => s->isolate & s->migrate A cache can have a constructor but the object may not be movable (I.e. currently dentries and inodes).
[PATCH] xfs: clean up xfs_dir2_leafn_add
From: Darrick J. Wong
Remove typedefs and consolidate local variable initialization.
Signed-off-by: Darrick J. Wong
---
fs/xfs/libxfs/xfs_dir2_node.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/fs/xfs/libxfs/xfs_dir2_node.c b/fs/xfs/libxfs/xfs_dir2_node.c
index de46f26c5292..16731d2d684b 100644
--- a/fs/xfs/libxfs/xfs_dir2_node.c
+++ b/fs/xfs/libxfs/xfs_dir2_node.c
@@ -426,26 +426,22 @@ xfs_dir2_leaf_to_node(
static int /* error */
xfs_dir2_leafn_add(
struct xfs_buf *bp,/* leaf buffer */
- xfs_da_args_t *args, /* operation arguments */
+ struct xfs_da_args *args, /* operation arguments */
int index) /* insertion pt for new entry */
{
+ struct xfs_dir3_icleaf_hdr leafhdr;
+ struct xfs_inode*dp = args->dp;
+ struct xfs_dir2_leaf*leaf = bp->b_addr;
+ struct xfs_dir2_leaf_entry *lep;
+ struct xfs_dir2_leaf_entry *ents;
int compact;/* compacting stale leaves */
- xfs_inode_t *dp;/* incore directory inode */
- int highstale; /* next stale entry */
- xfs_dir2_leaf_t *leaf; /* leaf structure */
- xfs_dir2_leaf_entry_t *lep; /* leaf entry */
+ int highstale = 0; /* next stale entry */
int lfloghigh; /* high leaf entry logging */
int lfloglow; /* low leaf entry logging */
- int lowstale; /* previous stale entry */
- struct xfs_dir3_icleaf_hdr leafhdr;
- struct xfs_dir2_leaf_entry *ents;
+ int lowstale = 0; /* previous stale entry */
trace_xfs_dir2_leafn_add(args, index);
- dp = args->dp;
- leaf = bp->b_addr;
- highstale = 0;
- lowstale = 0;
dp->d_ops->leaf_hdr_from_disk(, leaf);
ents = dp->d_ops->leaf_ents_p(leaf);
[PATCH] ASoC: fsl: sai: Reduce underrun when stream starts
From: Shengjiu Wang
Write initial words into SAI FIFO to reduce the underrun
error.
Signed-off-by: Shengjiu Wang
Signed-off-by: Daniel Baluta
---
sound/soc/fsl/fsl_sai.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index db9e0872f73d..99edbba4e8fa 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -503,7 +503,9 @@ static int fsl_sai_trigger(struct snd_pcm_substream
*substream, int cmd,
{
struct fsl_sai *sai = snd_soc_dai_get_drvdata(cpu_dai);
bool tx = substream->stream == SNDRV_PCM_STREAM_PLAYBACK;
+ unsigned int channels = substream->runtime->channels;
u32 xcsr, count = 100;
+ int i;
/*
* Asynchronous mode: Clear SYNC for both Tx and Rx.
@@ -526,6 +528,11 @@ static int fsl_sai_trigger(struct snd_pcm_substream
*substream, int cmd,
regmap_update_bits(sai->regmap, FSL_SAI_xCSR(tx),
FSL_SAI_CSR_FRDE, FSL_SAI_CSR_FRDE);
+ for (i = 0; tx && i < channels; i++)
+ regmap_write(sai->regmap, FSL_SAI_TDR, 0x0);
+ if (tx)
+ udelay(10);
+
regmap_update_bits(sai->regmap, FSL_SAI_RCSR,
FSL_SAI_CSR_TERE, FSL_SAI_CSR_TERE);
regmap_update_bits(sai->regmap, FSL_SAI_TCSR,
--
2.17.1
Re: [PATCH 5.0 00/46] 5.0.1-stable review
On 08/03/2019 12:49, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.0.1 release. > There are 46 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Mar 10 12:48:36 UTC 2019. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.0.1-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.0.y > and the diffstat can be found below. > > thanks, > > greg k-h All tests passing for Tegra ... Test results for stable-v5.0: 11 builds: 11 pass, 0 fail 22 boots: 22 pass, 0 fail 28 tests: 28 pass, 0 fail Linux version: 5.0.1-rc1-gbe3f501 Boards tested: tegra124-jetson-tk1, tegra186-p2771-, tegra194-p2972-, tegra20-ventana, tegra210-p2371-2180, tegra30-cardhu-a04 Cheers Jon -- nvpublic
Re: [PATCH] powerpc/6xx: fix setup and use of SPRN_PGDIR for hash32
Le 08/03/2019 à 17:03, Segher Boessenkool a écrit : On Fri, Mar 08, 2019 at 07:05:22AM +, Christophe Leroy wrote: Not only the 603 but all 6xx need SPRN_PGDIR to be initialised at startup. This patch move it from __setup_cpu_603() to start_here() and __secondary_start(), close to the initialisation of SPRN_THREAD. I thought you meant an SPR I did not know about. But you just misspelled SPRN_SPRG_PGDIR :-) Oops. Michael, can you fix the commit text (and subject) when applying ? Thanks Christophe
Re: [PATCH 4.20 00/76] 4.20.15-stable review
On 08/03/2019 12:49, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.20.15 release. > There are 76 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Mar 10 12:48:49 UTC 2019. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.20.15-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.20.y > and the diffstat can be found below. > > thanks, > > greg k-h All tests passing for Tegra ... Test results for stable-v4.20: 11 builds: 11 pass, 0 fail 22 boots: 22 pass, 0 fail 28 tests: 28 pass, 0 fail Linux version: 4.20.15-rc1-gb80b02d1 Boards tested: tegra124-jetson-tk1, tegra186-p2771-, tegra194-p2972-, tegra20-ventana, tegra210-p2371-2180, tegra30-cardhu-a04 Cheers Jon -- nvpublic
Re: [PATCH] netfilter: nf_conntrack_sip: fix IPV6 dependency
hi Arnd, Cc'ing Alin Nastac. On Mon, Mar 04, 2019 at 09:40:12PM +0100, Arnd Bergmann wrote: > With CONFIG_IPV6=m and CONFIG_NF_CONNTRACK_SIP=y, we now get a link failure: > > net/netfilter/nf_conntrack_sip.o: In function `process_sdp': > nf_conntrack_sip.c:(.text+0x4344): undefined reference to > `ip6_route_output_flags' I see. We can probably use nf_route() instead. Or if needed, use struct nf_ipv6_ops for this. if (v6ops) ret = v6ops->route_xyz(...); @Alin: Would you send us a patch to do so to fix a3419ce3356cf1f netfilter: nf_conntrack_sip: add sip_external_media logic". This direct dependency with IPv6 is superfluous, it should not happen. Thanks!
Re: [PATCH] powerpc/6xx: fix setup and use of SPRN_PGDIR for hash32
On Fri, Mar 08, 2019 at 07:05:22AM +, Christophe Leroy wrote: > Not only the 603 but all 6xx need SPRN_PGDIR to be initialised at > startup. This patch move it from __setup_cpu_603() to start_here() > and __secondary_start(), close to the initialisation of SPRN_THREAD. I thought you meant an SPR I did not know about. But you just misspelled SPRN_SPRG_PGDIR :-) Segher
Re: [PATCH 7/9] docs: Remove unknown 'hint' directive
On 3/8/19 12:27 AM, Markus Heiser wrote: > > Am 08.03.19 um 04:51 schrieb Randy Dunlap: >> On 3/7/19 1:11 PM, Tobin C. Harding wrote: >>> Current RST file contains an unknown directive causing Sphinx to emit >>> >>> ERROR: Unexpected indentation. >>> >>> Use normal language construct instead. >>> >>> Signed-off-by: Tobin C. Harding >> >> This is a good idea. My previous patch eliminated the warning but the >> ..hint is not presented very well in the generated output. :) >> >> Thanks. >> >>> --- >>> Documentation/driver-api/dmaengine/dmatest.rst | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/Documentation/driver-api/dmaengine/dmatest.rst >>> b/Documentation/driver-api/dmaengine/dmatest.rst >>> index 8d81f1a7169b..25eecd2769b0 100644 >>> --- a/Documentation/driver-api/dmaengine/dmatest.rst >>> +++ b/Documentation/driver-api/dmaengine/dmatest.rst >>> @@ -59,8 +59,8 @@ parameter, that specific channel is requested using the >>> dmaengine and a thread >>> is created with the existing parameters. This thread is set as pending >>> and will be executed once run is set to 1. Any parameters set after the >>> thread >>> is created are not applied. > > > Here a blank line is missed. Thats while '.. hint:' directive is not detected > well. Without the blank line the '.. hint:` string is a part of the section > above. I added a blank line and the ..hint still is not handled in any special manner. That's why I prefer Tobin's patch. >>> -.. hint:: >>> - available channel list could be extracted by running the following >>> command:: >>> + >>> +Hint: available channel list could be extracted by running the following >>> command:: >>> % ls -1 /sys/class/dma/ > > -- Markus -- > -- ~Randy
Re: [PATCH 4.19 00/68] 4.19.28-stable review
On 08/03/2019 12:49, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.19.28 release. > There are 68 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun Mar 10 12:48:45 UTC 2019. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.28-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.19.y > and the diffstat can be found below. > > thanks, > > greg k-h All tests passing for Tegra ... Test results for stable-v4.19: 11 builds: 11 pass, 0 fail 22 boots: 22 pass, 0 fail 28 tests: 28 pass, 0 fail Linux version: 4.19.28-rc1-g838c866 Boards tested: tegra124-jetson-tk1, tegra186-p2771-, tegra194-p2972-, tegra20-ventana, tegra210-p2371-2180, tegra30-cardhu-a04 Cheers Jon -- nvpublic
Re: [PATCH] irqchip: stm32: add a second level init to request hwspinlock
Hi Marc, Thanks for your detailed answer. I will study how to move this driver to a device one. BR Fabien On 08/03/2019 4:30 PM, Marc Zyngier wrote: > On Fri, 08 Mar 2019 14:03:55 +, > Fabien DESSENNE wrote: > > Fabien, > >> Hi Marc, >> >> Thank you for your feedback. Let me try to explain this patch, and the >> reason of its unusual implementation choices. >> >> >> Regarding the driver init mode: >> As an important requirement, I want to keep this irq driver declared >> with IRQCHIP_DECLARE(), so it is initialized early from >> start_kernel()/init_IRQ(). >> Most of the other irq drivers are implemented this way and I imagine >> that this ensures the availability of the irq drivers, before the other >> platform drivers get probed. > Let me get this straight: > > - Either you don't have dependencies on anything, and you need to >enable your irqchip early -> you use IRQCHIP_DECLARE. > > - Or you have dependencies on other subsystems -> You *do not* use >IRQCHIP_DECLARE, and use the expected dependency system (deferred >probing) > > There is no intermediate state. The other irqchip controllers that use > IRQCHIP_DECLARE *do NOT* have dependencies on external subsystems. > >> Regarding the second init: >> With the usage of the hwspinlock framework (used to protect against >> coprocessor concurrent access to registers) we have a problem as the >> hwspinlock driver is not available when the irq driver is being initialized. >> In order to solve this, I added a second initialization where we get a >> reference to hwspinlock. >> You pointed that we are not supposed to use of_node_clear_flag (which >> allows to get a second init call) : >> I spent some time to find any information about it, but could not find >> any reason to not use it. >> Please, let me know if I missed something here. > Yes, you missed the fact that each time someone tries to add some > driver probing via an initcall, we push back. This is an internal > kernel mechanism that is not to be used by random, non architectural > drivers such as this interrupt controller. > > Furthermore, you're playing with stuff that is outside of the exported > API of the DT framework. Clearing node flags is not something I really > want to see, as you're messing with a state machine that isn't under > your control. > >> Regarding the inits sequence and dependencies: >> - The second init is guaranteed to be called after the first one, since >> start_kernel()->init_IRQ() is called before platform drivers init. > There is no such requirements that holds for secondary interrupt > controllers. > >> - During the second init, the dependency with the hwspinlock driver is >> implemented correctly : it makes use of defered probe when needed. > Then do the right thing all the way: move your favourite toy irqchip > to being a proper device driver, use the right abstraction, and stop > piling ugly hacks on top of each other. Other irqchip drivers do that > just fine (all GPIO irqchips, for example), and most drivers are > already able to defer their probe routine. > >> I understand that this patch is 'surprising' but I hope that my >> explanations justify its implementation. > Surprising is not the word I'd have used. The explanations do not > justify anything, as all you're saying is "it is the way it is because > it is the way it is". So please fix your irqchip driver properly, in a > way that is maintainable in the long term, using the abstractions that > are available. If such abstractions are not good enough, please > explain what you need and we'll work something out. > > Thanks, > > M. >
Re: [RFC 07/15] slub: Add defrag_used_ratio field and sysfs support
On Fri, Mar 08, 2019 at 03:14:18PM +1100, Tobin C. Harding wrote:
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -3642,6 +3642,7 @@ static int kmem_cache_open(struct kmem_cache *s,
> slab_flags_t flags)
>
> set_cpu_partial(s);
>
> + s->defrag_used_ratio = 30;
> #ifdef CONFIG_NUMA
> s->remote_node_defrag_ratio = 1000;
> #endif
> @@ -5261,6 +5262,28 @@ static ssize_t destroy_by_rcu_show(struct kmem_cache
> *s, char *buf)
> }
> SLAB_ATTR_RO(destroy_by_rcu);
>
> +static ssize_t defrag_used_ratio_show(struct kmem_cache *s, char *buf)
> +{
> + return sprintf(buf, "%d\n", s->defrag_used_ratio);
> +}
> +
> +static ssize_t defrag_used_ratio_store(struct kmem_cache *s,
> +const char *buf, size_t length)
> +{
> + unsigned long ratio;
> + int err;
> +
> + err = kstrtoul(buf, 10, );
> + if (err)
> + return err;
> +
> + if (ratio <= 100)
> + s->defrag_used_ratio = ratio;
else
return -EINVAL;
maybe?
Tycho
Re: [PATCH] pseries/energy: Use OF accessor functions to read ibm,drc-indexes
* Gautham R Shenoy [2019-03-08 21:03:24]:
> From: "Gautham R. Shenoy"
>
> In cpu_to_drc_index() in the case when FW_FEATURE_DRC_INFO is absent,
> we currently use of_read_property() to obtain the pointer to the array
> corresponding to the property "ibm,drc-indexes". The elements of this
> array are of type __be32, but are accessed without any conversion to
> the OS-endianness, which is buggy on a Little Endian OS.
>
> Fix this by using of_property_read_u32_index() accessor function to
> safely read the elements of the array.
>
> Fixes: commit e83636ac3334 ("pseries/drc-info: Search DRC properties for CPU
> indexes")
> Cc: #v4.16+
> Reported-by: Pavithra R. Prakash
> Signed-off-by: Gautham R. Shenoy
Reviewed-by: Vaidyanathan Srinivasan
> ---
> arch/powerpc/platforms/pseries/pseries_energy.c | 27
> -
> 1 file changed, 18 insertions(+), 9 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/pseries_energy.c
> b/arch/powerpc/platforms/pseries/pseries_energy.c
> index 6ed2212..1c4d1ba 100644
> --- a/arch/powerpc/platforms/pseries/pseries_energy.c
> +++ b/arch/powerpc/platforms/pseries/pseries_energy.c
> @@ -77,18 +77,27 @@ static u32 cpu_to_drc_index(int cpu)
>
> ret = drc.drc_index_start + (thread_index * drc.sequential_inc);
> } else {
> - const __be32 *indexes;
> -
> - indexes = of_get_property(dn, "ibm,drc-indexes", NULL);
> - if (indexes == NULL)
> - goto err_of_node_put;
> + u32 nr_drc_indexes, thread_drc_index;
>
> /*
> - * The first element indexes[0] is the number of drc_indexes
> - * returned in the list. Hence thread_index+1 will get the
> - * drc_index corresponding to core number thread_index.
> + * The first element of ibm,drc-indexes array is the
> + * number of drc_indexes returned in the list. Hence
> + * thread_index+1 will get the drc_index corresponding
> + * to core number thread_index.
>*/
> - ret = indexes[thread_index + 1];
> + rc = of_property_read_u32_index(dn, "ibm,drc-indexes",
> + 0, _drc_indexes);
> + if (rc)
> + goto err_of_node_put;
> +
> + WARN_ON(thread_index > nr_drc_indexes);
> + rc = of_property_read_u32_index(dn, "ibm,drc-indexes",
> + thread_index + 1,
> + _drc_index);
> + if (rc)
> + goto err_of_node_put;
> +
> + ret = thread_drc_index;
Oops! Good bugfix. We should use device tree accessors like this in
all places for correct and safe code.
Thanks!
--Vaidy
Re: [PATCH] netfilter: nf_ct_helper: Fix possible panic when nf_conntrack_helper_unregister is used in an unloadable module
On Fri, Mar 01, 2019 at 01:56:06PM +0800, Su Yanjun wrote: > From: Su Yanjun > > Because nf_conntrack_helper_unregister maybe used in an unloadable module, > it uses 'synchronize_rcu' which may cause kernel panic. > > According to the artical: > RCU and Unloadable Modules > https://lwn.net/Articles/217484/ > > When we have a heavy rcu callback load, then some of the callbacks might be > deferred in order to allow other processing to proceed. sychnorize_rcu does > not wait rcu callback complete and module may be unloaded before callback > done. > > This patch uses rcu_barrier instead of synchronize_rcu will prevent this > situation. > > Signed-off-by: Su Yanjun > --- > net/netfilter/nf_conntrack_helper.c | 11 +-- > 1 file changed, 9 insertions(+), 2 deletions(-) > > diff --git a/net/netfilter/nf_conntrack_helper.c > b/net/netfilter/nf_conntrack_helper.c > index 274baf1..0ee9378 100644 > --- a/net/netfilter/nf_conntrack_helper.c > +++ b/net/netfilter/nf_conntrack_helper.c > @@ -397,8 +397,15 @@ void nf_conntrack_helper_unregister(struct > nf_conntrack_helper *me) > > /* Make sure every nothing is still using the helper unless its a >* connection in the hash. > + * > + * 'synchronize_rcu' may have problem when rcu callback function > + * is used in unloadable modules. Use rcu_barrier instead, so that > + * it will wait until rcu callback completes before modules are > + * unloaded. > + * More detail about rcu_barrier please see: > + * https://lwn.net/Articles/217484/ >*/ > - synchronize_rcu(); > + rcu_barrier(); Are you sure this is correct? IIRC rcu_barrier() makes sure no pending callback is still waiting in the queue to run. We have don't use call_rcu() in this code, which is what rcu_barrier() is meant for. Please correct me if I'm mistaken. Thanks! > > nf_ct_expect_iterate_destroy(expect_iter_me, NULL); > nf_ct_iterate_destroy(unhelp, me); > @@ -406,7 +413,7 @@ void nf_conntrack_helper_unregister(struct > nf_conntrack_helper *me) > /* Maybe someone has gotten the helper already when unhelp above. >* So need to wait it. >*/ > - synchronize_rcu(); > + rcu_barrier(); > } > EXPORT_SYMBOL_GPL(nf_conntrack_helper_unregister); > > -- > 2.7.4 > >
Re: [PATCH 3/4] printk: Add consoles to a virtual "console" bus
On Fri 2019-03-08 03:56:19, John Ogness wrote: > On 2019-03-02, Calvin Owens wrote: > > This patch embeds a device struct in the console struct, and registers > > them on a "console" bus so we can expose attributes in sysfs. > > I expect that "class" would be more appropriate than "bus". These > devices really are grouped together based on their function and not the > medium by which they are accessed. Good point. "class" looks better to me as well. Greg, any opinion, where to put the entries for struct console ? Best Regards, Petr
Re: [PATCH][v2] time: Introduce jiffies64_to_msecs()
On Thu, Feb 28, 2019 at 01:13:26PM +0800, Li RongQing wrote:
> there is a similar helper in net/netfilter/nf_tables_api.c,
> this maybe become a common request someday, so move it to
> time.c
>
> Signed-off-by: Zhang Yu
> Signed-off-by: Li RongQing
Acked-by: Pablo Neira Ayuso
This is touching kernel/time.c bits, which is far from my realm.
What should I do with this? I can just place it in nf-next.git if I
get an ACK to do so. Otherwise, please just take this if this looks
good to you.
Thanks!
> ---
> v1-->v2: using jiffies64_to_msecs in nf_tables_api.c
>
> include/linux/jiffies.h | 1 +
> kernel/time/time.c| 10 ++
> net/netfilter/nf_tables_api.c | 4 +---
> 3 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/jiffies.h b/include/linux/jiffies.h
> index fa928242567d..1b6d31da7cbc 100644
> --- a/include/linux/jiffies.h
> +++ b/include/linux/jiffies.h
> @@ -297,6 +297,7 @@ static inline u64 jiffies_to_nsecs(const unsigned long j)
> }
>
> extern u64 jiffies64_to_nsecs(u64 j);
> +extern u64 jiffies64_to_msecs(u64 j);
>
> extern unsigned long __msecs_to_jiffies(const unsigned int m);
> #if HZ <= MSEC_PER_SEC && !(MSEC_PER_SEC % HZ)
> diff --git a/kernel/time/time.c b/kernel/time/time.c
> index 2edb5088a70b..0083eb711fb7 100644
> --- a/kernel/time/time.c
> +++ b/kernel/time/time.c
> @@ -719,6 +719,16 @@ u64 jiffies64_to_nsecs(u64 j)
> }
> EXPORT_SYMBOL(jiffies64_to_nsecs);
>
> +u64 jiffies64_to_msecs(const u64 j)
> +{
> +#if HZ <= MSEC_PER_SEC && !(MSEC_PER_SEC % HZ)
> + return (MSEC_PER_SEC / HZ) * j;
> +#else
> + return div_u64(j * HZ_TO_MSEC_NUM, HZ_TO_MSEC_DEN);
> +#endif
> +}
> +EXPORT_SYMBOL(jiffies64_to_msecs);
> +
> /**
> * nsecs_to_jiffies64 - Convert nsecs in u64 to jiffies64
> *
> diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
> index e1a88ba2249e..8763b2798788 100644
> --- a/net/netfilter/nf_tables_api.c
> +++ b/net/netfilter/nf_tables_api.c
> @@ -3184,9 +3184,7 @@ static int nf_msecs_to_jiffies64(const struct nlattr
> *nla, u64 *result)
>
> static __be64 nf_jiffies64_to_msecs(u64 input)
> {
> - u64 ms = jiffies64_to_nsecs(input);
> -
> - return cpu_to_be64(div_u64(ms, NSEC_PER_MSEC));
> + return cpu_to_be64(jiffies64_to_msecs(input));
> }
>
> static int nf_tables_fill_set(struct sk_buff *skb, const struct nft_ctx *ctx,
> --
> 2.16.2
>
Re: [RFC PATCH] perf: Paper over the hw.target problems
Hi Alex,
On Thu, Feb 28, 2019 at 04:01:09PM +0200, Alexander Shishkin wrote:
> First, we have a race between perf_event_release_kernel() and
> perf_free_event(), which happens when parent's event is released while the
> child's fork fails (because of a fatal signal, for example), that looks
> like this:
>
> cpu Xcpu Y
> --
> copy_process() error path
> perf_release(parent) +->perf_event_free_task()
> +-> lock(child_ctx->mutex) | |
> +-> remove_from_context(child) | |
> +-> unlock(child_ctx->mutex) | |
> || +-> lock(child_ctx->mutex)
> || +-> unlock(child_ctx->mutex)
> |+-> free_task(child_task)
> +-> put_task_struct(child_task)
>
> Technically, we're still holding a reference to the task via
> parent->hw.target, that's not stopping free_task(), so we end up poking at
> free'd memory, as is pointed out by KASAN in the syzkaller report (see Link
> below). The straightforward fix is to drop the hw.target reference while
> the task is still around.
I've recently started hitting this on arm64, and had come to the same
conclusion.
> Therein lies the second problem: the users of hw.target (uprobe) assume
> that it's around at ->destroy() callback time, where they use it for
> context. So, in order to not break the uprobe teardown and avoid leaking
> stuff, we need to call ->destroy() at the same time.
I had not spotted that case. That's rather horrid. :/
> This patch fixes the race and the subsequent fallout by doing both these
> things at remove_from_context time.
>
> Signed-off-by: Alexander Shishkin
> Link: https://syzkaller.appspot.com/bug?extid=a24c397a29ad22d86c98
> Reported-by: syzbot+a24c397a29ad22d86...@syzkaller.appspotmail.com
> ---
> kernel/events/core.c | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 36b8320590e8..640695d114f8 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -2105,6 +2105,27 @@ static void perf_remove_from_context(struct perf_event
> *event, unsigned long fla
>
> event_function_call(event, __perf_remove_from_context, (void *)flags);
>
> + /*
> + * This is as passable as any hw.target handling out there;
> + * hw.target implies task context, therefore, no migration.
> + * Which means that we can only get here at the teardown.
> + */
> + if (event->hw.target) {
> + /*
> + * Now, the problem with, say uprobes, is that they
> + * use hw.target for context in their ->destroy()
> + * callbacks. Supposedly, they may need to poke at
> + * its contents, so better call it while we still
> + * have the task.
> + */
> + if (event->destroy) {
> + event->destroy(event);
> + event->destroy = NULL;
> + }
> + put_task_struct(event->hw.target);
> + event->hw.target = NULL;
> + }
We also use perf_remove_from_context() in perf_event_open() when we move
events from a SW context to a HW context, so we can't destroy the event
here.
I think we need something more like the below (untested), but I fear
that it's not safe to call perf_event::destroy() in this context.
Thanks,
Mark.
>8
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 26d6edab051a..b32f2cac5563 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -4532,6 +4532,24 @@ static void put_event(struct perf_event *event)
_free_event(event);
}
+void perf_event_detach_target(struct perf_event *event)
+{
+ if (!event->hw.target)
+ return;
+
+ /*
+* The uprobes perf_event::destroy() callback needs the target, so call
+* that while the target is still valid.
+*/
+ if (event->destroy) {
+ event->destroy(event);
+ event->destroy = NULL;
+ }
+
+ put_task_struct(event->hw.target);
+ event->hw.target = NULL;
+}
+
/*
* Kill an event dead; while event:refcount will preserve the event
* object, it will not preserve its functionality. Once the last 'user'
@@ -4559,6 +4577,7 @@ int perf_event_release_kernel(struct perf_event *event)
ctx = perf_event_ctx_lock(event);
WARN_ON_ONCE(ctx->parent_ctx);
perf_remove_from_context(event, DETACH_GROUP);
+ perf_event_detach_target(event);
raw_spin_lock_irq(>lock);
/*
@@ -4614,6 +4633,7 @@ int perf_event_release_kernel(struct perf_event *event)
struct perf_event, child_list);
if (tmp == child) {
perf_remove_from_context(child, DETACH_GROUP);
+ perf_event_detach_target(child);
Re: [PATCH 3/4] printk: Add consoles to a virtual "console" bus
On Fri 2019-03-01 16:48:19, Calvin Owens wrote: > This patch embeds a device struct in the console struct, and registers > them on a "console" bus so we can expose attributes in sysfs. > > Early console structures must still be static, since they're required > before we're able to allocate memory. The least ugly way I can come up > with to handle this is an "is_static" flag in the structure which makes > the gets and puts NOPs, and is checked in ->release() to catch mistakes. I wonder if it might get detected by is_kernel_inittext(). Best Regards, Petr
Re: [PATCH] Avoid that check_shl_overflow() triggers a compiler warning when building with W=1
On Fri, Mar 08, 2019 at 09:09:46AM +0100, Rasmus Villemoes wrote: > On 08/03/2019 08.01, Leon Romanovsky wrote: > > > > Mathematical therm for discrete numbers greater or equal to zero is > > "normal numbers". > > Sorry, WHAT? "Normal" is used and abused for a lot of things in > mathematics, but I have never heard it used that way. When attached to > the word "number", it means a real number with certain properties > related to its digit expansion(s). And then of course there's the > isnormal() thing for floating point values in C/computing. It is hard to argue with this type of arguments: "never heard -> doesn't exist". Luckily enough for me who can't find my fifth grade textbook from school, we have Wikipedia which has pointer to ISO standard with clear declaration of "normal numbers" as 0,1,2, https://en.wikipedia.org/wiki/Natural_number#cite_note-ISO8-1 "Standard number sets and intervals". ISO 8-2:2009. International Organization for Standardization. p. 6. > > Strong NAK to using is_normal/is_negative. > > Rasmus > > signature.asc Description: PGP signature
Re: [PATCH 1/8] aio: make sure file is pinned
On Fri, Mar 08, 2019 at 03:36:50AM +, Al Viro wrote: > See vfs.git#work.aio; the crucial bits are in these commits: > keep io_event in aio_kiocb > get rid of aio_complete() res/res2 arguments > move aio_complete() to final iocb_put(), try to fix aio_poll() logics > The first two are preparations, the last is where the fixes (hopefully) > happen. Looks sensible. I'll try to run the tests over it, and I've added Avi so that maybe he can make sure that scylladb is also happy with it, that was usually the best way to find aio poll bugs..
Re: [PATCH v2 1/7] KVM:VMX: Define CET VMCS fields and bits
On Fri, Mar 08, 2019 at 10:15:15AM +0100, Paolo Bonzini wrote:
> On 04/03/19 19:56, Sean Christopherson wrote:
> > On Tue, Jan 29, 2019 at 04:19:34PM +0100, Paolo Bonzini wrote:
> >> On 28/01/19 11:33, Yang Weijiang wrote:
> There is no code in this series to pass these fields to and from
> userspace, and also to save/restore U_CET, INT_SSP_TAB, PL0_SSP and
> PL3_SSP across context switches.
>
> >>> The kernel consumes these MSRs, please see kernel CET patch:
> >>> https://lkml.org/lkml/fancy/2018/11/20/225
> >>
> >> Still, even if the kernel saves these fields across context switch in
> >> XSAVE areas, KVM must support accesses to the MSRs from userspace, for
> >> example in order to perform live migration.
> >>
> >> For example, when reading/writing these in kvm_set_msr or
> >> kvm_get_msr_common, you would have to do a read/write from the host
> >> MSRs. You also have to put kvm_load_guest_fpu/kvm_put_guest_fpu calls
> >> in __msr_io.
> >
> > Paolo, can you elaborate on why KVM would read the host MSRs? Wouldn't
> > kvm_{get,set}_msr() pull the values from the VMCS when necessary?
>
> Not all MSRs are in the VMCS; IA32_U_CET and IA32_PL*_SSP are not.
Ah, "host MSRs" confused me. I though you meant the host's version of
the MSRs, but you're saying do an XRSTORS to load the guest's FPU state
and then {RD,WR}MSR to pull the guest's value from hardware.
Re: [PATCH v7 1/4] can: m_can: Create a m_can platform framework
Wolfgang
On 3/8/19 8:41 AM, Wolfgang Grandegger wrote:
> Hello Dan,
>
> thinking more about it...
>
> Am 08.03.19 um 14:29 schrieb Wolfgang Grandegger:
>> Hello Dan,
>>
>> Am 08.03.19 um 13:44 schrieb Dan Murphy:
>>> Wolfgang
>>>
>>> On 3/8/19 4:10 AM, Wolfgang Grandegger wrote:
Hallo Dan,
Am 05.03.19 um 16:52 schrieb Dan Murphy:
> Create a m_can platform framework that peripherial
> devices can register to and use common code and register sets.
> The peripherial devices may provide read/write and configuration
> support of the IP.
>
> Signed-off-by: Dan Murphy
> ---
>
>
> v7 - Fixed remaining new checkpatch issues, removed CSR setting, fixed tx
> hard
> start function to return tx_busy, and renamed device callbacks -
> https://lore.kernel.org/patchwork/patch/1047220/
>
> v6 - Squashed platform patch to this patch for bissectablity, fixed
> coding style
> issues, updated Kconfig help, placed mcan reg offsets back into c file,
> renamed
> priv->skb to priv->tx_skb and cleared perp interrupts at ISR start -
> Patch 1 comments - https://lore.kernel.org/patchwork/patch/1042446/
> Patch 2 comments - https://lore.kernel.org/patchwork/patch/1042442/
>
> drivers/net/can/m_can/Kconfig | 13 +-
> drivers/net/can/m_can/Makefile | 1 +
> drivers/net/can/m_can/m_can.c | 700 +
> drivers/net/can/m_can/m_can.h | 110
> drivers/net/can/m_can/m_can_platform.c | 202 +++
> 5 files changed, 682 insertions(+), 344 deletions(-)
> create mode 100644 drivers/net/can/m_can/m_can.h
> create mode 100644 drivers/net/can/m_can/m_can_platform.c
>
> diff --git a/drivers/net/can/m_can/Kconfig b/drivers/net/can/m_can/Kconfig
> index 04f20dd39007..f7119fd72df4 100644
> --- a/drivers/net/can/m_can/Kconfig
> +++ b/drivers/net/can/m_can/Kconfig
> @@ -1,5 +1,14 @@
> config CAN_M_CAN
> + tristate "Bosch M_CAN support"
> + ---help---
> + Say Y here if you want support for Bosch M_CAN controller framework.
> + This is common support for devices that embed the Bosch M_CAN IP.
> +
> +config CAN_M_CAN_PLATFORM
> + tristate "Bosch M_CAN support for io-mapped devices"
> depends on HAS_IOMEM
> - tristate "Bosch M_CAN devices"
> + depends on CAN_M_CAN
> ---help---
> - Say Y here if you want to support for Bosch M_CAN controller.
> + Say Y here if you want support for IO Mapped Bosch M_CAN controller.
> + This support is for devices that have the Bosch M_CAN controller
> + IP embedded into the device and the IP is IO Mapped to the processor.
> diff --git a/drivers/net/can/m_can/Makefile
> b/drivers/net/can/m_can/Makefile
> index 8bbd7f24f5be..057bbcdb3c74 100644
> --- a/drivers/net/can/m_can/Makefile
> +++ b/drivers/net/can/m_can/Makefile
> @@ -3,3 +3,4 @@
> #
>
> obj-$(CONFIG_CAN_M_CAN) += m_can.o
> +obj-$(CONFIG_CAN_M_CAN_PLATFORM) += m_can_platform.o
> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
> index 9b449400376b..a60278d94126 100644
> --- a/drivers/net/can/m_can/m_can.c
> +++ b/drivers/net/can/m_can/m_can.c
... snip...
> +static netdev_tx_t m_can_start_xmit(struct sk_buff *skb,
> + struct net_device *dev)
> +{
> + struct m_can_priv *priv = netdev_priv(dev);
> +
> + if (can_dropped_invalid_skb(dev, skb))
> + return NETDEV_TX_OK;
> +
> + if (priv->is_peripherial) {
> + if (priv->tx_skb) {
> + netdev_err(dev, "hard_xmit called while tx busy\n");
> + return NETDEV_TX_BUSY;
> + }
The problem with that approach is, that the upper layer will try to
resubmit the current "skb" but not the previous "tx_skb". And the
previous "tx_skb" has not been freed yet. I would just drop and free the
skb and return NETDEV_TX_OK in m_can_tx_handler() for peripheral devices
(like can_dropped_invalid_skb() does).
>>>
>>> OK.
>>>
>>> So would this also be a bug in the hi3110 and mcp251x drivers (line 521) as
>>> well because besides checking tx_length
>>> this is how these drivers are written.
>>
>> This is different. When entering the "start_xmit" routine, the previous
>> TX is still in progress. It will (hopefully) complete soon. Therefore
>> returning NETDEV_TX_BUSY is OK. The "start_xmit" routine will be
>> recalled soon with the same "skb". That scenario should/could also not
>> happen.
>
> In principle, this also applies to the m_can peripheral devices. If
> tx_skb is not NULL, the TX is still in progress and returning
> NETDEV_TX_BUSY is just fine.
>
>>
>> In contrast, in "m_can_tx_handler()", the skb could not be handled
>> because the FIFO is full. The "start_xmit"
Re: [PATCH 2/4] ARM: dts: omap4-droid4: Update backlight dt properties
Pavel
Thanks for the review.
On 3/8/19 9:14 AM, Pavel Machek wrote:
> Hi!
>
>> Update the properties for the lm3532 device node for droid4.
>> With this change the backlight LED string and the keypad
>> LED strings will be controlled separately.
>>
>> Signed-off-by: Dan Murphy
>> ---
>> arch/arm/boot/dts/omap4-droid4-xt894.dts | 27 +---
>> 1 file changed, 19 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/omap4-droid4-xt894.dts
>> b/arch/arm/boot/dts/omap4-droid4-xt894.dts
>> index e21ec929f096..94e3d53dbcf3 100644
>> --- a/arch/arm/boot/dts/omap4-droid4-xt894.dts
>> +++ b/arch/arm/boot/dts/omap4-droid4-xt894.dts
>> @@ -6,6 +6,7 @@
>> /dts-v1/;
>>
>> #include
>> +#include
>> #include "omap443x.dtsi"
>> #include "motorola-cpcap-mapphone.dtsi"
>>
>> @@ -383,20 +384,30 @@
>> };
>>
>> {
>> -lm3532@38 {
>> +led-controller@38 {
>> compatible = "ti,lm3532";
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> reg = <0x38>;
>>
>> enable-gpios = < 12 GPIO_ACTIVE_HIGH>;
>>
>> -lcd_backlight: backlight {
>> -compatible = "ti,lm3532-backlight";
>> +ramp-up-ms = ;
>> +ramp-down-ms = ;
>
> I guess dt people will have some comments here. I'd expect
>
> ramp-up-us = <1024> would be more natural.
>
Actually ramp-up-us/ramp-down-us is more correct this is an error in this dt
definition
and will be fixed in v2
>> +lcd_backlight: led@0 {
>> +reg = <0>;
>> +led-sources = <2>;
>> +ti,led-mode = ;
>> +label = "backlight";
>
> Ok, so we'll have lm3532::backlight. That is not too useful, as it
> does not tell userland what kaclight it is.
>
> main_display::backlight ?
>
> OTOH this one is not too important as backlight subsystem should
> handle this.
>
For Droid4 I am not particular to any specific label.
And if the series in https://lkml.org/lkml/2018/11/7/144
is ever implemented then the label may change as well.
The driver forces the lm3532 string to be part of the label.
This was a discussion a while back with Jacek when I submitted other drivers.
>> +led@1 {
>> +reg = <1>;
>> +led-sources = <1>;
>> +ti,led-mode = ;
>> +label = "keypad";
>
> I guess best variant would be inputX::backlight here, but that might
> be tricky to implement.
>
Yeah because we don't know what input the keyboard would be on.
Unless there are APIs to retrieve that info. I have not looked at the input
framework in a while.
Dan
> Pavel
>
--
--
Dan Murphy
Re: [PATCH 2/4] printk: Add ability to set loglevel via "console=" cmdline
On Fri 2019-03-01 16:48:18, Calvin Owens wrote:
> This extends the "console=" interface to allow setting the per-console
> loglevel by adding "/N" to the string, where N is the desired loglevel
> expressed as a base 10 integer. Invalid values are silently ignored.
>
> Signed-off-by: Calvin Owens
> ---
> .../admin-guide/kernel-parameters.txt | 6 ++--
> kernel/printk/console_cmdline.h | 1 +
> kernel/printk/printk.c| 30 +++
> 3 files changed, 28 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt
> b/Documentation/admin-guide/kernel-parameters.txt
> index 858b6c0b9a15..afada61dcbce 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -612,10 +612,10 @@
> ttyS[,options]
> ttyUSB0[,options]
> Use the specified serial port. The options are of
> - the form "pnf", where "" is the baud rate,
> + the form "pnf/l", where "" is the baud rate,
> "p" is parity ("n", "o", or "e"), "n" is number of
> - bits, and "f" is flow control ("r" for RTS or
> - omit it). Default is "9600n8".
> + bits, "f" is flow control ("r" for RTS or omit it),
> + and "l" is the loglevel on [0,7]. Default is "9600n8".
We should a more detailed explanation about the loglevel semantic. It
is either minimal loglevel. Or that it overrides the global
console_loglevel if you accept my proposal.
>
> See Documentation/admin-guide/serial-console.rst for
> more
> information. See
> diff --git a/kernel/printk/console_cmdline.h b/kernel/printk/console_cmdline.h
> index 11f19c466af5..fbf9b539366e 100644
> --- a/kernel/printk/console_cmdline.h
> +++ b/kernel/printk/console_cmdline.h
> @@ -6,6 +6,7 @@ struct console_cmdline
> {
> charname[16]; /* Name of the driver */
> int index; /* Minor dev. to use*/
> + int loglevel; /* Loglevel to use */
The comment will be true only with the new proposal.
> char*options; /* Options for the driver */
> #ifdef CONFIG_A11Y_BRAILLE_CONSOLE
> char*brl_options; /* Options for braille driver */
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 6ead14f8c2bc..2e0eb89f046c 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -2104,8 +2105,8 @@ __setup("console_msg_format=",
> console_msg_format_setup);
> static int __init console_setup(char *str)
> {
> char buf[sizeof(console_cmdline[0].name) + 4]; /* 4 for "ttyS" */
> - char *s, *options, *brl_options = NULL;
> - int idx;
> + char *s, *options, *llevel, *brl_options = NULL;
> + int idx, loglevel = LOGLEVEL_EMERG;
>
> if (_braille_console_setup(, _options))
> return 1;
> @@ -2123,6 +2124,14 @@ static int __init console_setup(char *str)
> options = strchr(str, ',');
> if (options)
> *(options++) = 0;
> +
> + llevel = strchr(str, '/');
This should be:
if (options)
llevel = strchr(options, '/');
> + if (llevel) {
> + *(llevel++) = 0;
> + if (kstrtoint(llevel, 10, ))
> + loglevel = LOGLEVEL_EMERG;
> + }
> +
> #ifdef __sparc__
> if (!strcmp(str, "ttya"))
> strcpy(buf, "ttyS0");
Best Regards,
Petr
[PATCH 1/1] Updated locking documentation for struct inode
We used LockDoc to derive locking rules for each member
of struct inode.
Based on those results, we extended the existing documentation
by more members of struct inode, and updated the existing
documentation.
Signed-off-by: Alexander Lochmann
Signed-off-by: Horst Schirmeier
---
fs/inode.c | 49 --
include/linux/fs.h | 2 +-
2 files changed, 40 insertions(+), 11 deletions(-)
diff --git a/fs/inode.c b/fs/inode.c
index 0cd47fe0dbe5..ade9d3aa1ada 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -24,17 +24,46 @@
/*
* Inode locking rules:
+ * (Documentation improved by LockDoc)
*
- * inode->i_lock protects:
- * inode->i_state, inode->i_hash, __iget()
- * Inode LRU list locks protect:
- * inode->i_sb->s_inode_lru, inode->i_lru
- * inode->i_sb->s_inode_list_lock protects:
- * inode->i_sb->s_inodes, inode->i_sb_list
- * bdi->wb.list_lock protects:
- * bdi->wb.b_{dirty,io,more_io,dirty_time}, inode->i_io_list
- * inode_hash_lock protects:
- * inode_hashtable, inode->i_hash
+ * No locks needed for:
+ * i_data.a_ops, i_data.nrexceptional, i_rdev, i_data.gfp_mask,
+ * i_generation, i_security, i_nlink, __i_nlink, i_flctx,
+ * i_size, i_atime, i_mtime, i_data.host, i_sb
+ *
+ * backing_dev_info.wb.list_lock protects:
+ * dirtied_when, i_io_list
+ *
+ * inode.i_rwsem protects:
+ * i_flags, i_uid, i_gid, i_version, i_ctime, i_size_seqcount
+ *
+ * inode.i_rwsem -> rcu protects:
+ * i_default_acl
+ *
+ * block_device.bd_mutex protects:
+ * i_blkbits
+ *
+ * cdev_lock protects:
+ * i_cdev, i_devices
+ *
+ * inode.i_data.i_mmap_rwsem protects:
+ * i_data.i_mmap, i_data.i_mmap
+ *
+ * hardirq -> inode.i_data.tree_lock protects:
+ * i_data.page_tree, i_wb_list, i_data.nrpages
+ *
+ * hardirq -> super_block.s_inode_wblist_lock protects:
+ * i_wb_list
+ *
+ * inode.i_lock protects:
+ * i_pipe, i_fsnotify_mask, i_fsnotify_marks, i_blocks, i_opflags,
+ * i_state, i_bytes
+ *
+ * super_block.s_inode_list_lock protects:
+ * i_sb_list
+ *
+ * inode_hash_lock -> inode.i_lock protects:
+ * i_hash
*
* Lock ordering:
*
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 92966678539d..744e2a817ad3 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -639,7 +639,7 @@ struct inode {
struct timespec64 i_atime;
struct timespec64 i_mtime;
struct timespec64 i_ctime;
- spinlock_t i_lock; /* i_blocks, i_bytes, maybe i_size */
+ spinlock_t i_lock;
unsigned short i_bytes;
u8 i_blkbits;
u8 i_write_hint;
--
2.20.1
[PATCH 1/1] Updated locking documentation for struct journal_t
We used LockDoc to derive locking rules for each member
of struct journal_t. Based on those results, we extended
the existing documentation by more members
of struct inode, and updated the existing documentation.
Signed-off-by: Alexander Lochmann
Signed-off-by: Horst Schirmeier
---
include/linux/jbd2.h | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/include/linux/jbd2.h b/include/linux/jbd2.h
index 0f919d5fe84f..c1ba44ca515a 100644
--- a/include/linux/jbd2.h
+++ b/include/linux/jbd2.h
@@ -585,7 +585,8 @@ struct transaction_s
} t_state;
/*
-* Where in the log does this transaction's commit start? [no locking]
+* Where in the log does this transaction's commit start?
+* [journal_t->j_state_lock]
*/
unsigned long t_log_start;
@@ -647,17 +648,17 @@ struct transaction_s
unsigned long t_max_wait;
/*
-* When transaction started
+* When transaction started [j_state_lock]
*/
unsigned long t_start;
/*
-* When commit was requested
+* When commit was requested [j_state_lock]
*/
unsigned long t_requested;
/*
-* Checkpointing stats [j_checkpoint_sem]
+* Checkpointing stats [j_list_lock]
*/
struct transaction_chp_stats_s t_chp_stats;
@@ -744,6 +745,7 @@ jbd2_time_diff(unsigned long start, unsigned long end)
/**
* struct journal_s - The journal_s type is the concrete type associated with
* journal_t.
+ * (Locking Documentation improved by LockDoc)
*/
struct journal_s
{
@@ -762,6 +764,7 @@ struct journal_s
/**
* @j_sb_buffer: The first part of the superblock buffer.
+* [j_checkpoint_mutex]
*/
struct buffer_head *j_sb_buffer;
@@ -1015,6 +1018,7 @@ struct journal_s
* @j_commit_interval:
*
* What is the maximum transaction lifetime before we begin a commit?
+* [super_block->s_umount]
*/
unsigned long j_commit_interval;
@@ -1032,7 +1036,7 @@ struct journal_s
* @j_revoke:
*
* The revoke table - maintains the list of revoked blocks in the
-* current transaction.
+* current transaction. [j_state_lock]
*/
struct jbd2_revoke_table_s *j_revoke;
--
2.20.1
[PATCH] pseries/energy: Use OF accessor functions to read ibm,drc-indexes
From: "Gautham R. Shenoy"
In cpu_to_drc_index() in the case when FW_FEATURE_DRC_INFO is absent,
we currently use of_read_property() to obtain the pointer to the array
corresponding to the property "ibm,drc-indexes". The elements of this
array are of type __be32, but are accessed without any conversion to
the OS-endianness, which is buggy on a Little Endian OS.
Fix this by using of_property_read_u32_index() accessor function to
safely read the elements of the array.
Fixes: commit e83636ac3334 ("pseries/drc-info: Search DRC properties for CPU
indexes")
Cc: #v4.16+
Reported-by: Pavithra R. Prakash
Signed-off-by: Gautham R. Shenoy
---
arch/powerpc/platforms/pseries/pseries_energy.c | 27 -
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/pseries_energy.c
b/arch/powerpc/platforms/pseries/pseries_energy.c
index 6ed2212..1c4d1ba 100644
--- a/arch/powerpc/platforms/pseries/pseries_energy.c
+++ b/arch/powerpc/platforms/pseries/pseries_energy.c
@@ -77,18 +77,27 @@ static u32 cpu_to_drc_index(int cpu)
ret = drc.drc_index_start + (thread_index * drc.sequential_inc);
} else {
- const __be32 *indexes;
-
- indexes = of_get_property(dn, "ibm,drc-indexes", NULL);
- if (indexes == NULL)
- goto err_of_node_put;
+ u32 nr_drc_indexes, thread_drc_index;
/*
-* The first element indexes[0] is the number of drc_indexes
-* returned in the list. Hence thread_index+1 will get the
-* drc_index corresponding to core number thread_index.
+* The first element of ibm,drc-indexes array is the
+* number of drc_indexes returned in the list. Hence
+* thread_index+1 will get the drc_index corresponding
+* to core number thread_index.
*/
- ret = indexes[thread_index + 1];
+ rc = of_property_read_u32_index(dn, "ibm,drc-indexes",
+ 0, _drc_indexes);
+ if (rc)
+ goto err_of_node_put;
+
+ WARN_ON(thread_index > nr_drc_indexes);
+ rc = of_property_read_u32_index(dn, "ibm,drc-indexes",
+ thread_index + 1,
+ _drc_index);
+ if (rc)
+ goto err_of_node_put;
+
+ ret = thread_drc_index;
}
rc = 0;
--
1.9.4
Re: [PATCH] irqchip: stm32: add a second level init to request hwspinlock
On Fri, 08 Mar 2019 14:03:55 +, Fabien DESSENNE wrote: Fabien, > > Hi Marc, > > Thank you for your feedback. Let me try to explain this patch, and the > reason of its unusual implementation choices. > > > Regarding the driver init mode: > As an important requirement, I want to keep this irq driver declared > with IRQCHIP_DECLARE(), so it is initialized early from > start_kernel()/init_IRQ(). > Most of the other irq drivers are implemented this way and I imagine > that this ensures the availability of the irq drivers, before the other > platform drivers get probed. Let me get this straight: - Either you don't have dependencies on anything, and you need to enable your irqchip early -> you use IRQCHIP_DECLARE. - Or you have dependencies on other subsystems -> You *do not* use IRQCHIP_DECLARE, and use the expected dependency system (deferred probing) There is no intermediate state. The other irqchip controllers that use IRQCHIP_DECLARE *do NOT* have dependencies on external subsystems. > Regarding the second init: > With the usage of the hwspinlock framework (used to protect against > coprocessor concurrent access to registers) we have a problem as the > hwspinlock driver is not available when the irq driver is being initialized. > In order to solve this, I added a second initialization where we get a > reference to hwspinlock. > You pointed that we are not supposed to use of_node_clear_flag (which > allows to get a second init call) : > I spent some time to find any information about it, but could not find > any reason to not use it. > Please, let me know if I missed something here. Yes, you missed the fact that each time someone tries to add some driver probing via an initcall, we push back. This is an internal kernel mechanism that is not to be used by random, non architectural drivers such as this interrupt controller. Furthermore, you're playing with stuff that is outside of the exported API of the DT framework. Clearing node flags is not something I really want to see, as you're messing with a state machine that isn't under your control. > Regarding the inits sequence and dependencies: > - The second init is guaranteed to be called after the first one, since > start_kernel()->init_IRQ() is called before platform drivers init. There is no such requirements that holds for secondary interrupt controllers. > - During the second init, the dependency with the hwspinlock driver is > implemented correctly : it makes use of defered probe when needed. Then do the right thing all the way: move your favourite toy irqchip to being a proper device driver, use the right abstraction, and stop piling ugly hacks on top of each other. Other irqchip drivers do that just fine (all GPIO irqchips, for example), and most drivers are already able to defer their probe routine. > I understand that this patch is 'surprising' but I hope that my > explanations justify its implementation. Surprising is not the word I'd have used. The explanations do not justify anything, as all you're saying is "it is the way it is because it is the way it is". So please fix your irqchip driver properly, in a way that is maintainable in the long term, using the abstractions that are available. If such abstractions are not good enough, please explain what you need and we'll work something out. Thanks, M. -- Jazz is not dead, it just smell funny.
Re: [PATCH 00/37] softirq: Per vector masking v3
On Fri, Mar 01, 2019 at 08:51:38AM -0800, Linus Torvalds wrote: > On Thu, Feb 28, 2019 at 7:45 PM Frederic Weisbecker > wrote: > > > > Numbers are indeed missing. In fact this patchset mostly just brings an > > infrastructure. We have yet to pinpoint the most latency-inducing > > softirq disabled sites and make them disable only the vectors that > > are involved in a given lock. > > Note that I think we pretty much know that already: the people who > have had issues have never actually really had issues with the actual > "disable softirq" paths, they've all been about actually *running* the > softirq's (and that in turn being a latency issue for running _other_ > softirqs, and in particular for delaying them into softirqd). > > Now, it may well be that yes, we'll have "block softirqs" code that > has issues too, but it's absolutely been swamped by the latencies for > actually running them so far. > > Note that this is all really fairly independent of the whole masking > logic. Yes, the masking logic comes into play too (allowing you to run > a subset of softirq's at a time), but on the whole the complaints I've > seen have not been "the networking softirq takes so long that it > delays USB tasklet handling", but they have been along the lines of > "the networking softirq gets invoked so often that it then floods the > system and triggers softirqd, and _that_ then makes tasklet handling > latency go up insanely". > > See the difference? Not the latency of softirq's disabled, but the > latency of one group of softirqs causing problems for another when > they all get batched together (and soft-scheduled to another context > together). I see, so that's an entirely different problem that vector soft-interruptibility can't fix, at least not alone. The only solution I can imagine is to have a seperate pending mask for normal softirq processing and ksoftirqd, so that only vectors that have been enqueued for threaded processing are delayed. I can work on that first, but I really need to be able to reproduce an example of the issue. The USB capture thing seems to be one the best. Let's browse some history to see if I can find some details on the relevant scenario.
Re: [PATCH] xfs: mark xfs_dir2_sf_entry_t as __packed again
On Mon, Mar 04, 2019 at 08:36:47PM +0100, Arnd Bergmann wrote:
> For ARM OABI builds, we run into a compile time assertion:
>
> inlined from 'init_xfs_fs' at /git/arm-soc/fs/xfs/xfs_super.c:1991:2:
> fs/xfs/xfs_ondisk.h:119:208: error: call to '__compiletime_assert_119'
> declared with attribute error: XFS: sizeof(xfs_dir2_sf_entry_t) is wrong,
> expected 3
>
> While ARM OABI is pretty much dead and fails to build for typical
> configurations on modern architectures (ARMv6 or higher), and has
> been declared deprecated in user space since gcc-4.6, the kernel
> still allows it to used for building the kernel.
>
> In commit 8353a649f577 ("xfs: kill xfs_dir2_sf_off_t"), Christoph
> removed the old __arch_pack annotation that made it possible to
> build xfs with oddball ABIs. However, OABI not only requrires
> padding around short structure but still adds padding after this
> change. There is no harm to unconditionally mark the structure as
> __packed now, and that will do the right thing here.
>
> As of commit aa2dd0ad4d6d ("xfs: remove __arch_pack"), we need to
> use __packed here as well, instead of the old __arch_pack.
I don't think we want more __packed attributes than required. Given
how dead OABI is can we just have XFS depend on !OABI?
Re: [PATCH] dt-bindings: clock: imx8mq: Fix numbering overlaps and gaps
Quoting Abel Vesa (2019-03-06 05:09:42) > On 19-03-05 10:38:29, Stephen Boyd wrote: > > Quoting Abel Vesa (2019-03-05 01:49:16) > > > IMX8MQ_CLK_USB_PHY_REF changes from 163 to 153, this way removing the gap. > > > All the following clock ids are now decreased by 10 to keep the numbering > > > right. Doing this, the IMX8MQ_CLK_CSI2_CORE is not overlapped with > > > IMX8MQ_CLK_GPT1 anymore. IMX8MQ_CLK_GPT1_ROOT changes from 193 to 183 and > > > all the following ids are updated accordingly. > > > > Why do the numbers need to be consecutive? This looks difficult to merge > > given that the commit that's being "fixed" is in v5.0 and thus the > > integer value of these defines is pretty much an ABI. So if there are > > holes in the space, I suggest we leave them there unless something is > > really wrong or unworkable with that solution. > > > > I would've ignored it but there are a few overlaps. > > #define IMX8MQ_CLK_GPT1170 > overlaps with: > #define IMX8MQ_CLK_CSI2_CORE 170 > > #define IMX8MQ_CLK_CSI2_PHY_REF181 > overlaps with: > #define IMX8MQ_CLK_ECSPI3_ROOT 181 > > #define IMX8MQ_CLK_CSI2_ESC182 > overlaps with: > #define IMX8MQ_CLK_ENET1_ROOT 182 Ok. Are any of the overlaps in use by dtbs right now? > > By removing the gaps, some of the overlaps are also removed. > > I can just get rid of the overlaps and keep the gaps if that makes it more ok > for the stability of the ABI. It's mostly about making sure that any existing dtbs don't have their numbers shifted around. So hopefully any overlapping identifiers aren't in use yet and then those ids can be changed while leaving the ones that are in use how they are. > > > BTW, it would be great if the binding header was generated once and then > > never changed again so that we don't have to spend time on these sorts > > of patches in the future. Please try to fully describe each possible clk > > that might be used with a particular binding instead of adding new clk > > ids over time, especially if you have access to the silicon manufacturer > > documentation and can easily figure out all the clks that are there > > beforehand. > > > > Here is an example of why this is not really doable: clk-sccg-pll.c. > The original design was adding the intermediary clocks like: > > IMX8MQ_SYS1_PLL1_OUT > IMX8MQ_SYS1_PLL1_OUT_DIV > IMX8MQ_SYS1_PLL1_REF_DIV > IMX8MQ_SYS1_PLL2 > IMX8MQ_SYS1_PLL2_DIV > IMX8MQ_SYS1_PLL2_OUT > > And these were just for SYS1_PLL. There are 2 more SYSx_PLL. > Plus the DRAM_PLL, the VIDEO2_PLL and the AUDIO_PLL. > > Since the refactoring of clk-sccg-pll.c, these are not used anymore (or should > not be used). So I would have to remove them, but as you said, it would break > the ABI. Why do you need to remove them? Why can't they just return an error if some driver tries to get those clks after they shouldn't be use anymore? > And this example goes even further with the fact that the PHY_27M > and the mux between the PHY_27M and the OSC_27 are to be controlled by the > display controller driver itself (at this point the PHY_27M is not yet > upstream > and I can't say for sure it will ever be). Basically, what this means is that > the PHY_27M will have to be exposed as a standalone clock even if it is hidden > behind a mux which has another clock that can provide the same rate. That > is only because there is some difference in phase (AFAIU) between the OSC_27M > and the PHY_27M, at the same rate. And this is just one example. It sounds like these are two independent clks that could or couldn't be exposed into the DT numberspace? > > Point being, there is no way of knowing beforehand what intermediary clocks > are needed, even with the silicon manufacturer documentation, until the > driver that makes use of a specific clock actually works. I agree that we don't know what clks are needed beforehand, predicting the future is hard, but that doesn't mean they can't be exposed into the header file if they exist. It doesn't really matter if there are numbers in there or not for clks that shouldn't be used. The provider and the driver implementation need to make the decision to provide them or not to the consumer drivers when they ask for them. It's perfectly valid for new code to start failing those requests because "they shouldn't be used". The header file (really the DT bindings) is the place that decides what the numbers are and what they correspond to.
Re: [RFC 02/15] slub: Add isolate() and migrate() methods
On Fri, Mar 08, 2019 at 03:14:13PM +1100, Tobin C. Harding wrote: > diff --git a/mm/slab_common.c b/mm/slab_common.c > index f9d89c1b5977..754acdb292e4 100644 > --- a/mm/slab_common.c > +++ b/mm/slab_common.c > @@ -298,6 +298,10 @@ int slab_unmergeable(struct kmem_cache *s) > if (!is_root_cache(s)) > return 1; > > + /* > + * s->isolate and s->migrate imply s->ctor so no need to > + * check them explicitly. > + */ Shouldn't this implication go the other way, i.e. s->ctor => s->isolate & s->migrate ? > if (s->ctor) > return 1; Tycho
Re: [PATCH] [v3] dma-mapping: work around clang bug
NAK on this whole patch. Please fix the compiler instead of making a complete mess of a common macro.
Re: [Xen-devel] [PATCH] Revert "swiotlb: remove SWIOTLB_MAP_ERROR"
On Tue, Mar 05, 2019 at 09:41:46AM +, Julien Grall wrote: > On Xen, dma_addr_t will always be 64-bit while the phys_addr_t will depend > on the MMU type. So we may have phys_addr_t smaller than dma_addr_t from > the kernel point of view. How can dma_addr_t on arm have value > 32-bit when physical addresses are 32-bit only?
Re: [PATCH 18/20] objtool: Add UACCESS validation
On Fri, Mar 08, 2019 at 09:07:03AM -0600, Josh Poimboeuf wrote: > On Thu, Mar 07, 2019 at 09:40:21PM +0100, Peter Zijlstra wrote: > > On Thu, Mar 07, 2019 at 09:23:19PM +0100, Peter Zijlstra wrote: > > > On Thu, Mar 07, 2019 at 07:48:13PM +0100, Peter Zijlstra wrote: > > > > Another thing I need to look at is why objtool only found memset_orig > > > > (from __memset) but not memset_erms, which if I read the code right, is > > > > a possible alternative there. > > > > > > Turns out we only look for sibling calls in the original instruction > > > stream, not in any alternatives; which in general seems like a fair > > > enough assumption. > > > > And while I'm looking at memset_64.S, why are memset_erms and > > memset_orig global functions? At the very least they should be local, > > and ideally not even functions. > > I think the only benefit is that they would show up better on stack > traces, but that could also be solved by just making them local labels > inside memset. Which is what I think they should be. Boris wanted to use alternative_call_2, just like copy_user_generic(). Which makes more sense to me still.
Hallo Lieber.
DO YOU SPEAK ENGLISH ? Mein Name ist Fräulein Dinah Nilesh, ich komme aus der Republik Sudan, wohne aber als Waisenkind hier in der Republik Togo im Asyl-Flüchtlingslager. Ich habe Ihre Daten bei meiner privaten Internet-Suche gesehen. Ich muss Ihnen etwas so Wichtiges und Vertrauliches mitteilen, antworten Sie bitte ich jetzt Freundliche Grüße Fräulein Dinah
Re: [PATCH 2/4] ARM: dts: omap4-droid4: Update backlight dt properties
Hi!
> Update the properties for the lm3532 device node for droid4.
> With this change the backlight LED string and the keypad
> LED strings will be controlled separately.
>
> Signed-off-by: Dan Murphy
> ---
> arch/arm/boot/dts/omap4-droid4-xt894.dts | 27 +---
> 1 file changed, 19 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap4-droid4-xt894.dts
> b/arch/arm/boot/dts/omap4-droid4-xt894.dts
> index e21ec929f096..94e3d53dbcf3 100644
> --- a/arch/arm/boot/dts/omap4-droid4-xt894.dts
> +++ b/arch/arm/boot/dts/omap4-droid4-xt894.dts
> @@ -6,6 +6,7 @@
> /dts-v1/;
>
> #include
> +#include
> #include "omap443x.dtsi"
> #include "motorola-cpcap-mapphone.dtsi"
>
> @@ -383,20 +384,30 @@
> };
>
> {
> - lm3532@38 {
> + led-controller@38 {
> compatible = "ti,lm3532";
> + #address-cells = <1>;
> + #size-cells = <0>;
> reg = <0x38>;
>
> enable-gpios = < 12 GPIO_ACTIVE_HIGH>;
>
> - lcd_backlight: backlight {
> - compatible = "ti,lm3532-backlight";
> + ramp-up-ms = ;
> + ramp-down-ms = ;
I guess dt people will have some comments here. I'd expect
ramp-up-us = <1024> would be more natural.
> + lcd_backlight: led@0 {
> + reg = <0>;
> + led-sources = <2>;
> + ti,led-mode = ;
> + label = "backlight";
Ok, so we'll have lm3532::backlight. That is not too useful, as it
does not tell userland what kaclight it is.
main_display::backlight ?
OTOH this one is not too important as backlight subsystem should
handle this.
> + led@1 {
> + reg = <1>;
> + led-sources = <1>;
> + ti,led-mode = ;
> + label = "keypad";
I guess best variant would be inputX::backlight here, but that might
be tricky to implement.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH] media: imx: vdic: Fix wrong CSI group ID
On Fri, 2019-03-01 at 15:27 -0800, Steve Longerbeam wrote:
> The i.MX7 capture support forgot to change the group ID for the CSI
> to the IPU CSI in VDIC sub-device, it was left at the i.MX7 CSI
> group ID.
>
> Fixes: 67673ed55084 ("media: staging/imx: rearrange group id to take in
> account IPU")
>
> Signed-off-by: Steve Longerbeam
Reviewed-by: Philipp Zabel
regards
Philipp
[PATCH 1/2] ARM: dts: stm32: add pinctrl sleep config for qspi on stm32mp157c-ev1
From: Ludovic Barre
This patch adds pinctrl sleep config for qspi on stm32mp157c-ev1
Signed-off-by: Ludovic Barre
---
arch/arm/boot/dts/stm32mp157-pinctrl.dtsi | 26 ++
arch/arm/boot/dts/stm32mp157c-ev1.dts | 3 ++-
2 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
b/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
index 9ec4694..5520f65 100644
--- a/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
@@ -289,6 +289,12 @@
};
};
+ qspi_clk_sleep_pins_a: qspi-clk-sleep-0 {
+ pins {
+ pinmux = ; /* QSPI_CLK */
+ };
+ };
+
qspi_bk1_pins_a: qspi-bk1-0 {
pins1 {
pinmux = ,
/* QSPI_BK1_IO0 */
@@ -307,6 +313,16 @@
};
};
+ qspi_bk1_sleep_pins_a: qspi-bk1-sleep-0 {
+ pins {
+ pinmux = , /* QSPI_BK1_IO0 */
+, /* QSPI_BK1_IO1 */
+, /* QSPI_BK1_IO2 */
+, /* QSPI_BK1_IO3 */
+; /* QSPI_BK1_NCS */
+ };
+ };
+
qspi_bk2_pins_a: qspi-bk2-0 {
pins1 {
pinmux = ,
/* QSPI_BK2_IO0 */
@@ -325,6 +341,16 @@
};
};
+ qspi_bk2_sleep_pins_a: qspi-bk2-sleep-0 {
+ pins {
+ pinmux = , /* QSPI_BK2_IO0 */
+, /* QSPI_BK2_IO1 */
+, /* QSPI_BK2_IO2 */
+, /* QSPI_BK2_IO3 */
+; /* QSPI_BK2_NCS */
+ };
+ };
+
uart4_pins_a: uart4-0 {
pins1 {
pinmux = ;
/* UART4_TX */
diff --git a/arch/arm/boot/dts/stm32mp157c-ev1.dts
b/arch/arm/boot/dts/stm32mp157c-ev1.dts
index b6aca40..7fef155 100644
--- a/arch/arm/boot/dts/stm32mp157c-ev1.dts
+++ b/arch/arm/boot/dts/stm32mp157c-ev1.dts
@@ -131,8 +131,9 @@
};
{
- pinctrl-names = "default";
+ pinctrl-names = "default", "sleep";
pinctrl-0 = <_clk_pins_a _bk1_pins_a _bk2_pins_a>;
+ pinctrl-1 = <_clk_sleep_pins_a _bk1_sleep_pins_a
_bk2_sleep_pins_a>;
reg = <0x58003000 0x1000>, <0x7000 0x400>;
#address-cells = <1>;
#size-cells = <0>;
--
2.7.4
[PATCH 0/2] ARM: dts: stm32: qspi update for stm32mp157c-ev1
From: Ludovic Barre This patch series add sleep pins configuration needed to suspend support and add jedec compatible for 2 nor flash of stm32mp157c-ev1. Ludovic Barre (2): ARM: dts: stm32: add pinctrl sleep config for qspi on stm32mp157c-ev1 ARM: dts: stm32: add jedec compatible for nor flash on stm32mp157c-ev1 arch/arm/boot/dts/stm32mp157-pinctrl.dtsi | 26 ++ arch/arm/boot/dts/stm32mp157c-ev1.dts | 5 - 2 files changed, 30 insertions(+), 1 deletion(-) -- 2.7.4
[PATCH 2/2] ARM: dts: stm32: add jedec compatible for nor flash on stm32mp157c-ev1
From: Ludovic Barre
This patch adds jedec compatible for spi-nor flash
on stm32mp157c-ev1 (needed with new spi-mem interface).
Signed-off-by: Ludovic Barre
---
arch/arm/boot/dts/stm32mp157c-ev1.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/stm32mp157c-ev1.dts
b/arch/arm/boot/dts/stm32mp157c-ev1.dts
index 7fef155..cae88d9 100644
--- a/arch/arm/boot/dts/stm32mp157c-ev1.dts
+++ b/arch/arm/boot/dts/stm32mp157c-ev1.dts
@@ -140,6 +140,7 @@
status = "okay";
flash0: mx66l51235l@0 {
+ compatible = "jedec,spi-nor";
reg = <0>;
spi-rx-bus-width = <4>;
spi-max-frequency = <10800>;
@@ -148,6 +149,7 @@
};
flash1: mx66l51235l@1 {
+ compatible = "jedec,spi-nor";
reg = <1>;
spi-rx-bus-width = <4>;
spi-max-frequency = <10800>;
--
2.7.4
Re: [PATCH] Abort file_remove_privs() for non-reg. files
Hello Al, Meanwhile, have you had the opportunity to review our patch? Regards, Alex On 11.01.19 16:42, Alexander Lochmann wrote: > Hello Al, > > Have you had the opportunity to review our patch? > > Cheers, > Alex > > On 17.12.18 09:28, Jan Kara wrote: >> On Fri 14-12-18 11:55:52, Alexander Lochmann wrote: >>> >>> file_remove_privs() might be called for non-regular files, e.g. >>> blkdev inode. There is no reason to do its job on things >>> like blkdev inodes, pipes, or cdevs. Hence, abort if >>> file does not refer to a regular inode. >>> The following stacktrace shows how to get there: >>> 13: entry_SYSENTER_32:460 >>> 12: do_fast_syscall_32:410 >>> 11: _static_cpu_has:146 >>> 10: do_syscall_32_irqs_on:322 >>> 09: SyS_pwrite64:636 >>> 08: SYSC_pwrite64:650 >>> 07: fdput:38 >>> 06: vfs_write:560 >>> 05: __vfs_write:512 >>> 04: new_sync_write:500 >>> 03: blkdev_write_iter:1977 >>> 02: __generic_file_write_iter:2897 >>> 01: file_remove_privs:1818 >>> 00: inode_has_no_xattr:3163 >>> >>> Found by LockDoc (Alexander Lochmann, Horst Schirmeier and Olaf >>> Spinczyk) >>> >>> Signed-off-by: Alexander Lochmann >>> Signed-off-by: Horst Schirmeier >> >> The patch looks good to me. You can add: >> >> Reviewed-by: Jan Kara >> >> Honza >> >>> --- >>> fs/inode.c | 9 +++-- >>> 1 file changed, 7 insertions(+), 2 deletions(-) >>> >>> diff --git a/fs/inode.c b/fs/inode.c >>> index 35d2108d567c..682088190413 100644 >>> --- a/fs/inode.c >>> +++ b/fs/inode.c >>> @@ -1820,8 +1820,13 @@ int file_remove_privs(struct file *file) >>> int kill; >>> int error = 0; >>> >>> - /* Fast path for nothing security related */ >>> - if (IS_NOSEC(inode)) >>> + /* >>> +* Fast path for nothing security related. >>> +* As well for non-regular files, e.g. blkdev inodes. >>> +* For example, blkdev_write_iter() might get here >>> +* trying to remove privs which it is not allowed to. >>> +*/ >>> + if (IS_NOSEC(inode) || !S_ISREG(inode->i_mode)) >>> return 0; >>> >>> kill = dentry_needs_remove_privs(dentry); >>> -- >>> 2.19.2 >>> >> >> >> > -- Technische Universität Dortmund Alexander LochmannPGP key: 0xBC3EF6FD Otto-Hahn-Str. 16 phone: +49.231.7556141 D-44227 Dortmund fax:+49.231.7556116 http://ess.cs.tu-dortmund.de/Staff/al signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/4] printk: Introduce per-console loglevel setting
On Fri 2019-03-01 16:48:17, Calvin Owens wrote:
> Not all consoles are created equal: depending on the actual hardware,
> the latency of a printk() call can vary dramatically. The worst examples
> are serial consoles, where it can spin for tens of milliseconds banging
> the UART to emit a message, which can cause application-level problems
> when the kernel spews onto the console.
>
> At Facebook we use netconsole to monitor our fleet, but we still have
> serial consoles attached on each host for live debugging, and the latter
> has caused problems. An obvious solution is to disable the kernel
> console output to ttyS0, but this makes live debugging frustrating,
> since crashes become silent and opaque to the ttyS0 user. Enabling it on
> the fly when needed isn't feasible, since boxes you need to debug via
> serial are likely to be borked in ways that make this impossible.
I guess that many other people have similar problem.
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index d3d170374ceb..6ead14f8c2bc 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -1164,9 +1164,14 @@ module_param(ignore_loglevel, bool, S_IRUGO | S_IWUSR);
> MODULE_PARM_DESC(ignore_loglevel,
>"ignore loglevel setting (prints all kernel messages to the
> console)");
>
> -static bool suppress_message_printing(int level)
> +static int effective_loglevel(struct console *con)
> {
> - return (level >= console_loglevel && !ignore_loglevel);
> + return max(console_loglevel, con ? con->level : LOGLEVEL_EMERG);
> +}
> +
> +static bool suppress_message_printing(int level, struct console *con)
> +{
> + return (level >= effective_loglevel(con) && !ignore_loglevel);
Hmm, the semantic is cleaner when the per-console level defines
the minimal loglevel. But it is still complicated. Also it is
very confusing that the per-console value is called "level"
or "loglevel" but it is actually minimal loglevel.
It might be even more straightforward when the per-console value
defines the effective console level. I mean the following semantic:
+ "console_loglevel" would define the default loglevel used
by consoles at runtime.
+ the per-console loglevel could override the default
console_loglevel.
+ We would need a custom handler for the sysctl "console_loglevel".
It would write the given value to the global console_loglevel
variable and for all already registered consoles (con->loglevel).
The value will be used also for all newly registered consoles
when they do not have any custom one.
+ The handler for "loglevel" early param should behave the same
as the sysctl handler.
IMHO, there is no perfect solution. The advantage of the above
proposal is that you "see" and "use" exactly what you "set".
> }
>
> #ifdef CONFIG_BOOT_PRINTK_DELAY
> @@ -1198,7 +1203,7 @@ static void boot_delay_msec(int level)
> unsigned long timeout;
>
> if ((boot_delay == 0 || system_state >= SYSTEM_RUNNING)
> - || suppress_message_printing(level)) {
> + || suppress_message_printing(level, NULL)) {
We should delay the message only when it will really reach the
console. The same check might be used also for formatting
the text as pointed out by Sergey in the other mail.
If the above proposal was accepted, we would have custom
handlers for sysctl. Then we could easily maintain a global
variable with maximal effective console loglevel.
Best Regards,
Petr
Re: [PATCH 18/20] objtool: Add UACCESS validation
On Fri, Mar 08, 2019 at 09:01:11AM -0600, Josh Poimboeuf wrote: > On Thu, Mar 07, 2019 at 08:03:13PM +0100, Peter Zijlstra wrote: > > Ah.. how about I feed objtool a text file with all these symbol names; > > and I have Makefile compose file that from fragments. > > > > Then only KASAN builds will have memset whitelisted, and any other build > > will still flag memset abuse. > > > > Now I only have to figure out how to make Makefile do something like > > that :-) > > Instead of adding all those additional moving parts, I would much rather > either: The problem went away. That is, the problematic part of KASAN just got removed in this merge window. Also; I just about had hpa's __memset_kasan implemented when I got that email.
Re: [PATCH v4 03/15] perf tools script: Filter COMM/FORK/.. events by CPU
On Fri, Mar 08, 2019 at 10:39:01AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Mar 07, 2019 at 12:02:31PM +0100, Jiri Olsa escreveu:
> > On Wed, Mar 06, 2019 at 04:23:40PM +0200, Adrian Hunter wrote:
> > > On 5/03/19 4:47 PM, Andi Kleen wrote:
> > > > From: Andi Kleen
> > > >
> > > > The --cpu option only filtered samples. Filter other perf events,
> > > > such as COMM, FORK, SWITCH by the CPU too.
> > >
> > > Because tasks can migrate from cpu to cpu, we probably need to process
> > > most
> > > of the events anyway, even if they are not printed.
> >
> > agreed, I wonder we could just make the perf_event__fprintf conditional
>
> Humm, probably just do the filtering on PERF_RECORD_SAMPLE is enough?
> I.e. having the other PERF_RECORD_{COMM,MMAP,} etc is required in face
> of migration.
The goal was to only show the output for the correct CPU in the perf
sample context browser. Otherwise the output on larger systems
is very confusing because most of it is for irrelevant CPUs.
-andi
Re: [PATCH 2/2] dt-bindings: iio: imu: adis16480: Document external clock
On Thu, 7 Mar 2019 17:29:19 +0200 Stefan Popa wrote: > Add documentation for optional use of external clock. All devices > supported by this driver can work with an external clock in sync mode. > Another mode, called Pulse Per Second (PPS) is supported only by adis1649x > devices. The mode is selected by using the "clock-names" property. > > The pin which is used as external clock input is selected by using a > custom optional property called "adi,ext-clk-pin". If this field is left > empty, DIO2 is assigned as default external clock input pin. > > Signed-off-by: Stefan Popa Trivial comments inline... Thanks, Jonathan > --- > .../devicetree/bindings/iio/imu/adi,adis16480.txt | 34 > ++ > 1 file changed, 34 insertions(+) > > diff --git a/Documentation/devicetree/bindings/iio/imu/adi,adis16480.txt > b/Documentation/devicetree/bindings/iio/imu/adi,adis16480.txt > index 39ab016..9e2fcd4 100644 > --- a/Documentation/devicetree/bindings/iio/imu/adi,adis16480.txt > +++ b/Documentation/devicetree/bindings/iio/imu/adi,adis16480.txt > @@ -34,6 +34,37 @@ Optional properties: > signal. > - reset-gpios: must be the device tree identifier of the RESET pin. As the > line > is active low, it should be marked GPIO_ACTIVE_LOW. > +- clocks: phandle to the external clock. Should be set according to > + "clock-names". > + If this field is left empty, the internal clock is used. > +- clock-names: The name of the external clock to be used. Valid values are: > + * sync: In sync mode, the internal clock is disabled and the frequency > + of the external clock signal establishes therate of data the rate > + collection and processing. See Fig 14 and 15 in the datasheet. > + The clock-frequency must be: > + * 3000 to 4500 Hz for adis1649x devices. > + * 700 to 2400 Hz for adis1648x devices. > + * pps: In Pulse Per Second (PPS) Mode, the rate of data collection and > +production is equal to the product of the external clock > +frequency and the scale factor in the SYNC_SCALE register, see > +Table 154 in the datasheet. > +The clock-frequency must be: > +* 1 to 128 Hz for adis1649x devices. > +* This mode is not supported by adis1648x devices. > + If this field is left empty, the internal clock is used. Should we say that both clocks and clock-names should be empty if that is the intent? > +- adi,ext-clk-pin: The DIOx line to be used as an external clock input. > + Valid values are: > + * DIO1 > + * DIO2 > + * DIO3 > + * DIO4 > + Each DIOx pin supports only one function at a time (data ready line > + selection or external clock input). When a single pin has two > + two assignments, the enable bit for the lower priority function > + automatically resets to zero (disabling the lower priority function). > + Data ready has highest priority. > + If this field is left empty, DIO2 is assigned as default external clock > + input pin. > > Example: > > @@ -46,4 +77,7 @@ Example: > interrupts = <25 IRQF_TRIGGER_FALLING>; > interrupt-parent = <>; > interrupt-names = "DIO2"; > + clocks = <_sync>; > + clock-names = "sync"; > + adi,ext-clk-pin = "DIO1"; > };
Re: [PATCH 18/20] objtool: Add UACCESS validation
On Thu, Mar 07, 2019 at 09:40:21PM +0100, Peter Zijlstra wrote: > On Thu, Mar 07, 2019 at 09:23:19PM +0100, Peter Zijlstra wrote: > > On Thu, Mar 07, 2019 at 07:48:13PM +0100, Peter Zijlstra wrote: > > > Another thing I need to look at is why objtool only found memset_orig > > > (from __memset) but not memset_erms, which if I read the code right, is > > > a possible alternative there. > > > > Turns out we only look for sibling calls in the original instruction > > stream, not in any alternatives; which in general seems like a fair > > enough assumption. > > And while I'm looking at memset_64.S, why are memset_erms and > memset_orig global functions? At the very least they should be local, > and ideally not even functions. I think the only benefit is that they would show up better on stack traces, but that could also be solved by just making them local labels inside memset. Which is what I think they should be. The general rule is that ENDPROC is only used for callable functions, so yeah, I think the current setup isn't ideal, and also prevents objtool from properly doing the AC analysis as you pointed out earlier. -- Josh
Re: [PATCH 1/2] iio: imu: adis16480: Add support for external clock
On Thu, 7 Mar 2019 17:28:32 +0200
Stefan Popa wrote:
> Inertial sensor data collection and processing can be controlled by
> configuring one of the DIOx lines as an external clock input. This
> option is available for all devices supported by this driver. However,
> only adis1649x devices support different modes for the external clock.
>
> Sync mode is supported by all devices. In this mode, the output data
> rate is equal with the clock frequency divided by DEC_RATE + 1. This
> mode of calculation is similar with the case when the internal clock is
> used.
>
> Pulse Per Second (PPS) Mode, is only supported by adis1649x devices. In
> this mode, the output data rate is equal to the product of the external
> clock frequency and the scale factor in the SYNC_SCALE register.
>
> This patch uses the "clock-names" property to enable the external clock
> in one of the two supported modes: "sync" or "pps". This property is
> optional. If it is not specified, the internal clock is used.
>
> This patch also offers the option to select the DIOx line to be used as
> an external clock input via the custom "adi,ext-clk-pin" property. If this
> field is left empty, DIO2 is assigned as default external clock input pin.
> Each DIOx pin supports only one function at a time (data ready line
> selection or external clock input).
>
> Signed-off-by: Stefan Popa
Hi Stefan,
One really minor thing inline. Otherwise looks good to me.
Jonathan
> ---
> drivers/iio/imu/adis16480.c | 186
> ++--
> 1 file changed, 179 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/iio/imu/adis16480.c b/drivers/iio/imu/adis16480.c
> index 28cece3..3a93a85 100644
> --- a/drivers/iio/imu/adis16480.c
> +++ b/drivers/iio/imu/adis16480.c
> @@ -9,6 +9,7 @@
> *
> */
>
> +#include
> #include
> #include
> #include
> @@ -99,6 +100,12 @@
> #define ADIS16480_REG_FIRM_DMADIS16480_REG(0x03,
> 0x7A)
> #define ADIS16480_REG_FIRM_Y ADIS16480_REG(0x03, 0x7C)
>
> +/*
> + * External clock scaling in PPS mode.
> + * Available only for ADIS1649x devices
> + */
> +#define ADIS16495_REG_SYNC_SCALE ADIS16480_REG(0x03, 0x10)
> +
> #define ADIS16480_REG_SERIAL_NUM ADIS16480_REG(0x04, 0x20)
>
> /* Each filter coefficent bank spans two pages */
> @@ -116,6 +123,12 @@
> #define ADIS16480_DRDY_POL(x)
> FIELD_PREP(ADIS16480_DRDY_POL_MSK, x)
> #define ADIS16480_DRDY_EN_MSKBIT(3)
> #define ADIS16480_DRDY_EN(x) FIELD_PREP(ADIS16480_DRDY_EN_MSK, x)
> +#define ADIS16480_SYNC_SEL_MSK GENMASK(5, 4)
> +#define ADIS16480_SYNC_SEL(x)
> FIELD_PREP(ADIS16480_SYNC_SEL_MSK, x)
> +#define ADIS16480_SYNC_EN_MSKBIT(7)
> +#define ADIS16480_SYNC_EN(x) FIELD_PREP(ADIS16480_SYNC_EN_MSK, x)
> +#define ADIS16480_SYNC_MODE_MSK BIT(8)
> +#define ADIS16480_SYNC_MODE(x)
> FIELD_PREP(ADIS16480_SYNC_MODE_MSK, x)
>
> struct adis16480_chip_info {
> unsigned int num_channels;
> @@ -128,6 +141,7 @@ struct adis16480_chip_info {
> unsigned int int_clk;
> unsigned int max_dec_rate;
> const unsigned int *filter_freqs;
> + bool has_pps_clk_mode;
> };
>
> enum adis16480_int_pin {
> @@ -137,10 +151,19 @@ enum adis16480_int_pin {
> ADIS16480_PIN_DIO4
> };
>
> +enum adis16480_clock_mode {
> + ADIS16480_CLK_SYNC,
> + ADIS16480_CLK_PPS,
> + ADIS16480_CLK_INT
> +};
> +
> struct adis16480 {
> const struct adis16480_chip_info *chip_info;
>
> struct adis adis;
> + struct clk *ext_clk;
> + enum adis16480_clock_mode clk_mode;
> + unsigned int clk_freq;
> };
>
> static const char * const adis16480_int_pin_names[4] = {
> @@ -296,20 +319,34 @@ static int adis16480_debugfs_init(struct iio_dev
> *indio_dev)
> static int adis16480_set_freq(struct iio_dev *indio_dev, int val, int val2)
> {
> struct adis16480 *st = iio_priv(indio_dev);
> - unsigned int t;
> + unsigned int t, reg;
>
> t = val * 1000 + val2 / 1000;
> if (t <= 0)
> return -EINVAL;
>
> - t = st->chip_info->int_clk / t;
> + /*
> + * When using PPS mode, the rate of data collection is equal to the
> + * product of the external clock frequency and the scale factor in the
> + * SYNC_SCALE register.
> + * When using sync mode, or internal clock, the output data rate is
> + * equal with the clock frequency divided by DEC_RATE + 1.
> + */
> + if (st->clk_mode == ADIS16480_CLK_PPS) {
> + t = t / st->clk_freq;
> + reg = ADIS16495_REG_SYNC_SCALE;
> + } else {
> + t = st->clk_freq / t;
> + reg = ADIS16480_REG_DEC_RATE;
> + }
> +
> if (t > st->chip_info->max_dec_rate)
> t = st->chip_info->max_dec_rate;
>
> - if (t != 0)
> + if ((t != 0) && (st->clk_mode !=
Re: [GIT PULL] Bulk GPIO changes for the v5.1 kernel cycle
Hi Linus, I got a few fixes since three days ago, maybe you already tried to pull this and got annoyed of the Kconfig noise, if you didn't, then I am pleased to not annoy you. The massage and tag is the same, just with a few new nice fixes on top. The problems were in minor platform drivers, but it was annoying so now those problems are gone. Arnd and Randy fixed it up. I updated the pull request with the proper hash and shortstat below. Yours, Linus Walleij On Tue, Mar 5, 2019 at 10:35 AM Linus Walleij wrote: > here is the bulk of the GPIO changes for the v5.1 kernel cycle. > I'm very happy to get this merged now because the development > has been all over the place, all is properly ACKed as far as possible > and has been merging and compiling nicely in linux-next but it > still makes me nervous to have it lying around on different immutable > branches and what not. > > The signed tag describes what the changes are about. We have > some hunks hitting x86 platform code, generic irqchip, ARM device > trees and machines, pin control and even device core. The respective > subsystem maintainers have been involved and ACKed the patches. > > Please pull it in for v5.1! The following changes since commit d13937116f1e82bf508a6325111b322c30c85eb9: Linux 5.0-rc6 (2019-02-10 14:42:20 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git tags/gpio-v5.1-1 for you to fetch changes up to d01849f7deba81f4959fd9e51bf20dbf46987d1c: gpio: gpio-omap: fix level interrupt idling (2019-03-08 14:11:30 +0100) This is the bulk of GPIO changes for the v5.1 cycle: Core changes: - The big change this time around is the irqchip handling in the qualcomm pin controllers, closely coupled with the gpiochip. This rework, in a classic fall-between-the-chairs fashion has been sidestepped for too long. The Qualcomm IRQchips using the SPMI and SSBI transport mechanisms have been rewritten to use hierarchical irqchip. This creates the base from which I intend to gradually pull support for hierarchical irqchips into the gpiolib irqchip helpers to cut down on duplicate code. We have too many hacks in the kernel because people have been working around the missing hierarchical irqchip for years, and once it was there, noone understood it for a while. We are now slowly adapting to using it. This is why this pull requests include changes to MFD, SPMI, IRQchip core and some ARM Device Trees pertaining to the Qualcomm chip family. Since Qualcomm have so many chips and such large deployments it is paramount that this platform gets this right, and now it (hopefully) does. - Core support for pull-up and pull-down configuration, also from the device tree. When a simple GPIO chip support a "off or on" pull-up or pull-down resistor, we provide a way to set this up using machine descriptors or device tree. If more elaborate control of pull up/down (such as resistance shunt setting) is required, drivers should be phased over to use pin control. We do not yet provide a userspace ABI for this pull up-down setting but I suspect the makers are going to ask for it soon enough. PCA953x is the first user of this new API. - The GPIO mockup driver has been revamped after some discussion improving the IRQ simulator in the process. The idea is to make it possible to use the mockup for both testing and virtual prototyping, e.g. when you do not yet have a GPIO expander to play with but really want to get something to develop code around before hardware is available. It's neat. The blackbox testing usecase is currently making its way into kernelci. - ACPI GPIO core preserves non direction flags when updating flags. - A new device core helper for devm_platform_ioremap_resource() is funneled through the GPIO tree with Greg's ACK. New drivers: - TQ-Systems QTMX86 GPIO controllers (using port-mapped I/O) - Gateworks PLD GPIO driver (vaccumed up from OpenWrt) - AMD G-Series PCH (Platform Controller Hub) GPIO driver. - Fintek F81804 & F81966 subvariants. - PCA953x now supports NXP PCAL6416. Driver improvements: - IRQ support on the Nintendo Wii (Hollywood) GPIO. - get_direction() support for the MVEBU driver. - Set the right output level on SAMA5D2. - Drop the unused irq trigger setting on the Spreadtrum driver. - Wakeup support for PCA953x. - A slew of cleanups in the various Intel drivers. Andrew Lunn (1): gpio: tqmx86: Add GPIO from for this IO controller Andy Shevchenko (12): gpiolib: acpi: Correct kernel doc of struct acpi_gpio_event gpio: crystalcove: Use for_each_set_bit() in IRQ handler gpio: wcove: Allow return negative error code from to_reg() gpio: msic: Remove duplicate check in IRQ handler gpio: crystalcove: Sort headers
Re: [RFC PATCH V2 5/5] vhost: access vq metadata through kernel virtual address
On Fri, Mar 08, 2019 at 07:56:04AM -0500, Michael S. Tsirkin wrote:
> On Fri, Mar 08, 2019 at 04:58:44PM +0800, Jason Wang wrote:
> >
> > On 2019/3/8 上午3:17, Jerome Glisse wrote:
> > > On Thu, Mar 07, 2019 at 12:56:45PM -0500, Michael S. Tsirkin wrote:
> > > > On Thu, Mar 07, 2019 at 10:47:22AM -0500, Michael S. Tsirkin wrote:
> > > > > On Wed, Mar 06, 2019 at 02:18:12AM -0500, Jason Wang wrote:
> > > > > > +static const struct mmu_notifier_ops vhost_mmu_notifier_ops = {
> > > > > > + .invalidate_range = vhost_invalidate_range,
> > > > > > +};
> > > > > > +
> > > > > > void vhost_dev_init(struct vhost_dev *dev,
> > > > > > struct vhost_virtqueue **vqs, int nvqs, int
> > > > > > iov_limit)
> > > > > > {
> > > > > I also wonder here: when page is write protected then
> > > > > it does not look like .invalidate_range is invoked.
> > > > >
> > > > > E.g. mm/ksm.c calls
> > > > >
> > > > > mmu_notifier_invalidate_range_start and
> > > > > mmu_notifier_invalidate_range_end but not
> > > > > mmu_notifier_invalidate_range.
> > > > >
> > > > > Similarly, rmap in page_mkclean_one will not call
> > > > > mmu_notifier_invalidate_range.
> > > > >
> > > > > If I'm right vhost won't get notified when page is write-protected
> > > > > since you
> > > > > didn't install start/end notifiers. Note that end notifier can be
> > > > > called
> > > > > with page locked, so it's not as straight-forward as just adding a
> > > > > call.
> > > > > Writing into a write-protected page isn't a good idea.
> > > > >
> > > > > Note that documentation says:
> > > > > it is fine to delay the mmu_notifier_invalidate_range
> > > > > call to mmu_notifier_invalidate_range_end() outside the page
> > > > > table lock.
> > > > > implying it's called just later.
> > > > OK I missed the fact that _end actually calls
> > > > mmu_notifier_invalidate_range internally. So that part is fine but the
> > > > fact that you are trying to take page lock under VQ mutex and take same
> > > > mutex within notifier probably means it's broken for ksm and rmap at
> > > > least since these call invalidate with lock taken.
> > > >
> > > > And generally, Andrea told me offline one can not take mutex under
> > > > the notifier callback. I CC'd Andrea for why.
> > > Correct, you _can not_ take mutex or any sleeping lock from within the
> > > invalidate_range callback as those callback happens under the page table
> > > spinlock. You can however do so under the invalidate_range_start call-
> > > back only if it is a blocking allow callback (there is a flag passdown
> > > with the invalidate_range_start callback if you are not allow to block
> > > then return EBUSY and the invalidation will be aborted).
> > >
> > >
> > > > That's a separate issue from set_page_dirty when memory is file backed.
> > > If you can access file back page then i suggest using set_page_dirty
> > > from within a special version of vunmap() so that when you vunmap you
> > > set the page dirty without taking page lock. It is safe to do so
> > > always from within an mmu notifier callback if you had the page map
> > > with write permission which means that the page had write permission
> > > in the userspace pte too and thus it having dirty pte is expected
> > > and calling set_page_dirty on the page is allowed without any lock.
> > > Locking will happen once the userspace pte are tear down through the
> > > page table lock.
> >
> >
> > Can I simply can set_page_dirty() before vunmap() in the mmu notifier
> > callback, or is there any reason that it must be called within vumap()?
> >
> > Thanks
>
>
> I think this is what Jerome is saying, yes.
> Maybe add a patch to mmu notifier doc file, documenting this?
>
Better to do in vunmap as you can look at kernel vmap pte to see if
the dirty bit is set and only call set_page_dirty in that case. But
yes you can do it outside vunmap in which case you have to call dirty
for all pages unless you have some other way to know if a page was
written to or not.
Note that if you also need to do that when you tear down the vunmap
through the regular path but with an exclusion from mmu notifier.
So if mmu notifier is running then you can skip the set_page_dirty
if none are running and you hold the lock then you can safely call
set_page_dirty.
Cheers,
Jérôme
Re: [PATCH 18/20] objtool: Add UACCESS validation
On Thu, Mar 07, 2019 at 08:03:13PM +0100, Peter Zijlstra wrote:
> On Thu, Mar 07, 2019 at 07:48:13PM +0100, Peter Zijlstra wrote:
> > On Thu, Mar 07, 2019 at 09:54:14AM -0800, Linus Torvalds wrote:
> > > On Thu, Mar 7, 2019 at 9:41 AM Peter Zijlstra
> > > wrote:
> > > > >
> > > > > What's the call site that made you go "just add __memset() to the
> > > > > list"?
> > > >
> > > > __asan_{,un}poinson_stack_memory()
> > > > kasan_{,un}poison_shadow()
> > > > __memset()
> > >
> > > Ugh. I think I almost just agree with your decision to just let that
> > > memset go unchecked.
> > >
> > > I'm not saying it's right, but it doesn't seem to be a fight worth
> > > fighting.
> >
> > One think I could do; is add a filter to each function and only allow
> > __memset from the kasan code, and not from anywhere else.
>
> Ah.. how about I feed objtool a text file with all these symbol names;
> and I have Makefile compose file that from fragments.
>
> Then only KASAN builds will have memset whitelisted, and any other build
> will still flag memset abuse.
>
> Now I only have to figure out how to make Makefile do something like
> that :-)
Instead of adding all those additional moving parts, I would much rather
either:
a) have kasan call a special whitelisted version of memset (like hpa
suggested); or
b) just don't use the objtool --uaccess flag for KASAN builds.
--
Josh
Re: [RFC PATCH V2 5/5] vhost: access vq metadata through kernel virtual address
On Fri, Mar 08, 2019 at 04:50:36PM +0800, Jason Wang wrote:
>
> On 2019/3/8 上午3:16, Andrea Arcangeli wrote:
> > On Thu, Mar 07, 2019 at 12:56:45PM -0500, Michael S. Tsirkin wrote:
> > > On Thu, Mar 07, 2019 at 10:47:22AM -0500, Michael S. Tsirkin wrote:
> > > > On Wed, Mar 06, 2019 at 02:18:12AM -0500, Jason Wang wrote:
> > > > > +static const struct mmu_notifier_ops vhost_mmu_notifier_ops = {
> > > > > + .invalidate_range = vhost_invalidate_range,
> > > > > +};
> > > > > +
> > > > > void vhost_dev_init(struct vhost_dev *dev,
> > > > > struct vhost_virtqueue **vqs, int nvqs, int
> > > > > iov_limit)
> > > > > {
> > > > I also wonder here: when page is write protected then
> > > > it does not look like .invalidate_range is invoked.
> > > >
> > > > E.g. mm/ksm.c calls
> > > >
> > > > mmu_notifier_invalidate_range_start and
> > > > mmu_notifier_invalidate_range_end but not mmu_notifier_invalidate_range.
> > > >
> > > > Similarly, rmap in page_mkclean_one will not call
> > > > mmu_notifier_invalidate_range.
> > > >
> > > > If I'm right vhost won't get notified when page is write-protected
> > > > since you
> > > > didn't install start/end notifiers. Note that end notifier can be called
> > > > with page locked, so it's not as straight-forward as just adding a call.
> > > > Writing into a write-protected page isn't a good idea.
> > > >
> > > > Note that documentation says:
> > > > it is fine to delay the mmu_notifier_invalidate_range
> > > > call to mmu_notifier_invalidate_range_end() outside the page
> > > > table lock.
> > > > implying it's called just later.
> > > OK I missed the fact that _end actually calls
> > > mmu_notifier_invalidate_range internally. So that part is fine but the
> > > fact that you are trying to take page lock under VQ mutex and take same
> > > mutex within notifier probably means it's broken for ksm and rmap at
> > > least since these call invalidate with lock taken.
> > Yes this lock inversion needs more thoughts.
> >
> > > And generally, Andrea told me offline one can not take mutex under
> > > the notifier callback. I CC'd Andrea for why.
> > Yes, the problem then is the ->invalidate_page is called then under PT
> > lock so it cannot take mutex, you also cannot take the page_lock, it
> > can at most take a spinlock or trylock_page.
> >
> > So it must switch back to the _start/_end methods unless you rewrite
> > the locking.
> >
> > The difference with _start/_end, is that ->invalidate_range avoids the
> > _start callback basically, but to avoid the _start callback safely, it
> > has to be called in between the ptep_clear_flush and the set_pte_at
> > whenever the pfn changes like during a COW. So it cannot be coalesced
> > in a single TLB flush that invalidates all sptes in a range like we
> > prefer for performance reasons for example in KVM. It also cannot
> > sleep.
> >
> > In short ->invalidate_range must be really fast (it shouldn't require
> > to send IPI to all other CPUs like KVM may require during an
> > invalidate_range_start) and it must not sleep, in order to prefer it
> > to _start/_end.
> >
> > I.e. the invalidate of the secondary MMU that walks the linux
> > pagetables in hardware (in vhost case with GUP in software) has to
> > happen while the linux pagetable is zero, otherwise a concurrent
> > hardware pagetable lookup could re-instantiate a mapping to the old
> > page in between the set_pte_at and the invalidate_range_end (which
> > internally calls ->invalidate_range). Jerome documented it nicely in
> > Documentation/vm/mmu_notifier.rst .
>
>
> Right, I've actually gone through this several times but some details were
> missed by me obviously.
>
>
> >
> > Now you don't really walk the pagetable in hardware in vhost, but if
> > you use gup_fast after usemm() it's similar.
> >
> > For vhost the invalidate would be really fast, there are no IPI to
> > deliver at all, the problem is just the mutex.
>
>
> Yes. A possible solution is to introduce a valid flag for VA. Vhost may only
> try to access kernel VA when it was valid. Invalidate_range_start() will
> clear this under the protection of the vq mutex when it can block. Then
> invalidate_range_end() then can clear this flag. An issue is blockable is
> always false for range_end().
>
Note that there can be multiple asynchronous concurrent invalidate_range
callbacks. So a flag does not work but a counter of number of active
invalidation would. See how KSM is doing it for instance in kvm_main.c
The pattern for this kind of thing is:
my_invalidate_range_start(start,end) {
...
if (mystruct_overlap(mystruct, start, end)) {
mystruct_lock();
mystruct->invalidate_count++;
...
mystruct_unlock();
}
}
my_invalidate_range_end(start,end) {
...
if (mystruct_overlap(mystruct, start, end)) {
mystruct_lock();
mystruct->invalidate_count--;
Re: [PATCH v2 1/8] drm/bridge: dw-hdmi: Add SCDC and TMDS Scrambling support
On Fri, Mar 8, 2019 at 2:05 AM Neil Armstrong wrote: > > Hi Rob, > > On 08/03/2019 00:13, Rob Herring wrote: > > On Fri, Feb 1, 2019 at 6:08 AM Neil Armstrong > > wrote: > >> > >> Add support for SCDC Setup for TMDS Clock > 3.4GHz and enable TMDS > >> Scrambling when supported or mandatory. > >> > >> This patch also adds an helper to setup the control bit to support > >> the high TMDS Bit Period/TMDS Clock-Period Ratio as required with > >> TMDS Clock > 3.4GHz for HDMI2.0 3840x2160@60/50 modes. > >> > >> These changes were based on work done by Huicong Xu > >> and Nickey Yang to support HDMI2.0 modes > >> on the Rockchip 4.4 BSP kernel at [1] > >> > >> [1] https://github.com/rockchip-linux/kernel/tree/release-4.4 > >> > >> Cc: Nickey Yang > >> Cc: Huicong Xu > >> Signed-off-by: Neil Armstrong > >> Tested-by: Heiko Stuebner > >> Reviewed-by: Andrzej Hajda > >> --- > >> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 85 > >> ++- > >> drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 1 + > >> include/drm/bridge/dw_hdmi.h | 1 + > >> 3 files changed, 85 insertions(+), 2 deletions(-) > > > > This commit in drm-misc-next is breaking booting on the Rock960. I > > have FB and fbcon enabled. The boot hangs after this message: > > > > [3.012334] [drm:rockchip_drm_fbdev_create] FB [1920x1080]-24 > > kvaddr=(ptrval) offset=0 size=8294400 > > Could you give more details on the tree used ? did you bisect to find this > commit ? As I said above, drm-misc-next (from drm-misc tree) is the branch. I bisected between it and v5.0. Reverting it fixes booting. Rob
Re: [PATCH] RISC-V: Use IS_ENABLED(CONFIG_CMODEL_MEDLOW)
On Thu, Mar 07, 2019 at 03:56:34PM -0800, Joe Perches wrote: > IS_ENABLED should generally use CONFIG_ prefaced symbols and > it doesn't appear as if there is a CMODEL_MEDLOW define. > > Signed-off-by: Joe Perches Looks good, Reviewed-by: Christoph Hellwig
[PATCH v2] selftests/x86: Support Atom for syscall_arg_fault test
Atom-based CPUs trigger stack fault when invoke 32-bit SYSENTER instruction
with invalid register values. So we also need SIGBUS handling in this case.
Following is assembly when the fault exception happens.
(gdb) disassemble $eip
Dump of assembler code for function __kernel_vsyscall:
0xf7fd8fe0 <+0>: push %ecx
0xf7fd8fe1 <+1>: push %edx
0xf7fd8fe2 <+2>: push %ebp
0xf7fd8fe3 <+3>: mov%esp,%ebp
0xf7fd8fe5 <+5>: sysenter
0xf7fd8fe7 <+7>: int$0x80
=> 0xf7fd8fe9 <+9>: pop%ebp
0xf7fd8fea <+10>:pop%edx
0xf7fd8feb <+11>:pop%ecx
0xf7fd8fec <+12>:ret
End of assembler dump.
According to Intel SDM, this could also be a Stack Segment Fault(#SS, 12),
except a normal Page Fault(#PF, 14). Especially, in section 6.9 of Vol.3A,
both stack and page faults are within the 10th(lowest priority) class, and
as it said, "exceptions within each class are implementation-dependent and
may vary from processor to processor". It's expected for processors like
Intel Atom to trigger stack fault(SIGBUS), while we get page fault(SIGSEGV)
from common Core processors.
Signed-off-by: Tong Bo
---
tools/testing/selftests/x86/syscall_arg_fault.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/x86/syscall_arg_fault.c
b/tools/testing/selftests/x86/syscall_arg_fault.c
index 7db4fc9..810180a 100644
--- a/tools/testing/selftests/x86/syscall_arg_fault.c
+++ b/tools/testing/selftests/x86/syscall_arg_fault.c
@@ -43,7 +43,7 @@ static sigjmp_buf jmpbuf;
static volatile sig_atomic_t n_errs;
-static void sigsegv(int sig, siginfo_t *info, void *ctx_void)
+static void sigsegv_or_sigbus(int sig, siginfo_t *info, void *ctx_void)
{
ucontext_t *ctx = (ucontext_t*)ctx_void;
@@ -73,7 +73,12 @@ int main()
if (sigaltstack(, NULL) != 0)
err(1, "sigaltstack");
- sethandler(SIGSEGV, sigsegv, SA_ONSTACK);
+ sethandler(SIGSEGV, sigsegv_or_sigbus, SA_ONSTACK);
+ /* The actual exception can vary. On Atom CPUs, we get #SS
+* instead of #PF when the vDSO fails to access the stack when
+* ESP is too close to 2^32, and #SS causes SIGBUS.
+*/
+ sethandler(SIGBUS, sigsegv_or_sigbus, SA_ONSTACK);
sethandler(SIGILL, sigill, SA_ONSTACK);
/*
--
2.7.4
Re: [PATCH] i2c: mediatek: modify threshold passed to i2c_get_dma_safe_msg_buf()
> > I just checked this issue again and concluded that both are reasonable, > > the suggestion from me below with the adapter quirk AND your original > > patch setting the threshold to 1. With my suggestion the core will > > prevent 0-length messages. But still, we should set the threshold to 1 > > because 0 is a value the HW is not capable of. > > > I think quirk might be better, since mediatek said they might have some ICs > that can handle zero-length transfer in the future, so flags might be > more clear if they want to restore functionality. But I guess you don't want to do the zero-length transfer with DMA then? With that in mind, raising the threshold still makes sense to me. signature.asc Description: PGP signature
Re: [PATCH 0/5] x86/percpu semantics and fixes
On Wed, Feb 27, 2019 at 11:12:52AM +0100, Peter Zijlstra wrote:
> This is a collection of x86/percpu changes that I had pending and got reminded
> of by Linus' comment yesterday about __this_cpu_xchg().
>
> This tidies up the x86/percpu primitives and fixes a bunch of 'fallout'.
(Sorry; this is going to have _wide_ output)
OK, so what I did is I build 4 kernels (O=defconfig-build{,1,2,3}) with
resp that many patches of this series applied.
When I look at just the vmlinux size output:
$ size defconfig-build*/vmlinux
textdata bss dec hex filename
195406315040164 1871944 26452739193a303 defconfig-build/vmlinux
195406355040164 1871944 26452743193a307 defconfig-build1/vmlinux
195406855040164 1871944 26452793193a339 defconfig-build2/vmlinux
195406855040164 1871944 26452793193a339 defconfig-build3/vmlinux
Things appear to get slightly larger; however when I look in more
detail using my (newly written compare script, find attached), I get
things like:
$ ./compare.sh defconfig-build defconfig-build1
arch/x86/mm/fault.o 12850 12818 -32
kernel/power/process.o 3586 3706 +120
kernel/locking/rtmutex.o 1687 1671 -16
kernel/sched/core.o 7127 7181 +54
kernel/time/tick-sched.o 8941 8837 -104
kernel/exit.o 310385 +75
kernel/softirq.o 1217 1199 -18
kernel/workqueue.o 3240 3288 +48
net/ipv6/tcp_ipv6.o 25434 25345 -89
net/ipv4/tcp_ipv4.o 301305 +4
total47682264768268 +42
When we look at just tick-sched.o:
$ ./compare.sh defconfig-build defconfig-build1 kernel/time/tick-sched.o
can_stop_idle_tick.isra.14146139 -7
we see a totally different number ?!
$ ./compare.sh defconfig-build defconfig-build1 kernel/time/tick-sched.o
can_stop_idle_tick.isra.14
0680 :
| 0680 :
680: 53 push %rbx
| 680:53 push %rbx
0001 681: 89 f8 mov%edi,%eax
| 0001 681:89 f8 mov%edi,%eax
0003 683: 48 0f a3 05 00 00 00bt %rax,0x0(%rip)# 68b
\ 000e 68e:73 48
jae6d8
0010 690: 8b 06 mov(%rsi),%eax
| 0010 690:8b 06 mov
(%rsi),%eax
0012 692: 85 c0 test %eax,%eax
| 0012 692:85 c0 test %eax,%eax
0014 694: 74 21 je 6b7
| 0014 694:74 21
je 6b7
0016 696: 65 48 8b 04 25 00 00mov%gs:0x0,%rax
| 0016 696:65 48 8b 04 25 00 00mov
%gs:0x0,%rax
001d 69d: 00 00
| 001d 69d:00 00
001b69b: R_X86_64_32S current_task
| 001b 69b: R_X86_64_32S
current_task
001f 69f: 48 8b 00mov(%rax),%rax
| 001f 69f:48 8b 00mov
(%rax),%rax
0022 6a2: a8 08 test $0x8,%al
| 0022 6a2:a8 08 test $0x8,%al
0024 6a4: 75 11 jne6b7
| 0024 6a4:75 11
jne6b7
0026 6a6: 65 66 8b 05 00 00 00mov%gs:0x0(%rip),%ax# 6ae
| 0031 6b1:75 0a
jne6bd
0033 6b3: 89 d8 mov%ebx,%eax
| 0033 6b3:89 d8 mov%ebx,%eax
0035 6b5: 5b pop%rbx
| 0035 6b5:5b pop%rbx
0036 6b6: c3 retq
| 0036 6b6:c3 retq
0037 6b7: 31 db xor%ebx,%ebx
| 0037 6b7:31 db xor
Re: FS-Cache: Duplicate cookie detected
Christian Kujau wrote:
> $ mount | grep nfs4
> nfs:/usr/local/src on /usr/local/src type nfs4
> (ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.56.139,local_lock=none,addr=192.168.0.115)
>
> ...so FS-Cache ("fsc") isn't even used here.
Interesting. Can you do:
cat /proc/fs/nfsfs/volumes
See the attached for a patch that helps with certain kinds of collision,
though I can't see that it should help with what you're seeing since the
RELINQUISHED flag isn't set on the old cookie (fl=222, but 0x10 isn't in
there). You can monitor the number of waits by looking in
/proc/fs/fscache/stats for the:
Acquire: n=289166 nul=0 noc=0 ok=286331 nbf=2 oom=0 wrq=23748
line. See the wrq= value.
David
---
commit abe600bc6e5022e14c0ce135fa3d9ceaafa3cb46
Author: David Howells
Date: Fri Mar 8 13:14:36 2019 +
fscache: Fix cookie collision
When adding a new cookie, a collision can sometimes occur because an old
cookie with the same key is still in the process of being asynchronously
relinquished, leading to something like the following being emitted into
the kernel log:
FS-Cache: Duplicate cookie detected
FS-Cache: O-cookie c=db33ad59 [p=4bc53500 fl=218 nc=0
na=0]
FS-Cache: O-cookie d= (null) n= (null)
FS-Cache: O-cookie o=6cf6db4f
FS-Cache: O-key=[16] '010001010100e51fc6000323ae02'
FS-Cache: N-cookie c=791c49d0 [p=4bc53500 fl=2 nc=0 na=1]
FS-Cache: N-cookie d=e220fe14 n=d4484489
FS-Cache: N-key=[16] '010001010100e51fc6000323ae02'
with the old cookie (O- lines) showing no cookie def or netfs data and
showing flags ACQUIRED, RELINQUISHED and INVALIDATING (fl=218).
Fix this by:
(1) Setting FSCACHE_COOKIE_RELINQUISHING on the cookie we're about to tear
dispose of.
(2) Making fscache_hash_cookie() sleep on RELINQUISHING if there's a
collision with a cookie that has RELINQUISHED set.
(3) Clearing RELINQUISHING upon having unhashed the cookie and waking up
anyone waiting for it to transition to unset.
Fixes: ec0328e46d6e ("fscache: Maintain a catalogue of allocated cookies")
Signed-off-by: David Howells
diff --git a/Documentation/filesystems/caching/fscache.txt
b/Documentation/filesystems/caching/fscache.txt
index 50f0a5757f48..f304bda88bb1 100644
--- a/Documentation/filesystems/caching/fscache.txt
+++ b/Documentation/filesystems/caching/fscache.txt
@@ -231,6 +231,7 @@ proc files.
ok=NNumber of acq reqs succeeded
nbf=N Number of acq reqs rejected due to error
oom=N Number of acq reqs failed on ENOMEM
+ wrq=N Number of waits for relinquishment of conflicting old
cookies.
Lookups n=N Number of lookup calls made on cache backends
neg=N Number of negative lookups made
pos=N Number of positive lookups made
diff --git a/fs/fscache/cookie.c b/fs/fscache/cookie.c
index c550512ce335..75d0ffd36ac0 100644
--- a/fs/fscache/cookie.c
+++ b/fs/fscache/cookie.c
@@ -202,7 +202,9 @@ struct fscache_cookie *fscache_hash_cookie(struct
fscache_cookie *candidate)
struct hlist_bl_head *h;
struct hlist_bl_node *p;
unsigned int bucket;
+ int ret;
+retry:
bucket = candidate->key_hash & (ARRAY_SIZE(fscache_cookie_hash) - 1);
h = _cookie_hash[bucket];
@@ -220,19 +222,37 @@ struct fscache_cookie *fscache_hash_cookie(struct
fscache_cookie *candidate)
return candidate;
collision:
- if (test_and_set_bit(FSCACHE_COOKIE_ACQUIRED, >flags)) {
- trace_fscache_cookie(cursor, fscache_cookie_collision,
-atomic_read(>usage));
- pr_err("Duplicate cookie detected\n");
- fscache_print_cookie(cursor, 'O');
- fscache_print_cookie(candidate, 'N');
- hlist_bl_unlock(h);
- return NULL;
- }
+ if (test_and_set_bit(FSCACHE_COOKIE_ACQUIRED, >flags))
+ goto duplicate;
fscache_cookie_get(cursor, fscache_cookie_get_reacquire);
hlist_bl_unlock(h);
return cursor;
+
+duplicate:
+ if (test_bit(FSCACHE_COOKIE_RELINQUISHED, >flags))
+ goto wait_for_removal;
+
+ trace_fscache_cookie(cursor, fscache_cookie_collision,
+atomic_read(>usage));
+ pr_err("Duplicate cookie detected\n");
+ fscache_print_cookie(cursor, 'O');
+ fscache_print_cookie(candidate, 'N');
+ hlist_bl_unlock(h);
+ return NULL;
+
+wait_for_removal:
+ fscache_cookie_get(cursor, fscache_cookie_get_wait);
+ hlist_bl_unlock(h);
+
+ fscache_stat(_n_acquires_wait_relinq);
+ ret = wait_on_bit(>flags,
Re: [PATCH v5 8/9] clk: mediatek: Add MT8183 clock support
On Fri, Mar 8, 2019 at 2:42 PM Nicolas Boichat wrote:
>
> )
> On Tue, Mar 5, 2019 at 1:05 PM Weiyi Lu wrote:
> >
> > Add MT8183 clock support, include topckgen, apmixedsys,
> > infracfg, mcucfg and subsystem clocks.
> >
> > Signed-off-by: Weiyi Lu
>
> In v1 a while back (https://patchwork.kernel.org/patch/10669765/) I
> was complaining about code duplication between these many files, and
> wondering if we can make simplify a lot of this code.
Okay, we had a discussion on this gerrit:
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1510921,
and I didn't know the history that having separate clock domains that
we can enable/disable with config options. And the same pattern
already exists on clk-mt2712-*.c, for example.
So, for now:
Reviewed-by: Nicolas Boichat
Some comment below about how this could be improved, potentially:
> Apart from that:
> Tested-by: Nicolas Boichat
>
[snip]
> > --- /dev/null
> > +++ b/drivers/clk/mediatek/clk-mt8183-audio.c
> > @@ -0,0 +1,105 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +//
> > +// Copyright (c) 2018 MediaTek Inc.
> > +// Author: Weiyi Lu
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +#include "clk-mtk.h"
> > +#include "clk-gate.h"
> > +
> > +#include
> > +
> > +static const struct mtk_gate_regs audio0_cg_regs = {
> > + .set_ofs = 0x0,
> > + .clr_ofs = 0x0,
> > + .sta_ofs = 0x0,
> > +};
> > +
> > +static const struct mtk_gate_regs audio1_cg_regs = {
> > + .set_ofs = 0x4,
> > + .clr_ofs = 0x4,
> > + .sta_ofs = 0x4,
> > +};
> > +
> > +#define GATE_AUDIO0(_id, _name, _parent, _shift) \
> > + GATE_MTK(_id, _name, _parent, _cg_regs, _shift, \
> > + _clk_gate_ops_no_setclr)
This macro (or variants that end up being equivalent) is repeated 103
times in drivers/clk/mediatek/*. We can probably do better. My
suggestion is to do something like this:
#define GATE_MTK_CLK(reg, _id, _name, _parent, _shift) \
GATE_MTK(_id, _name, _parent, ##_cg_regs, _shift, \
_clk_gate_ops_setclr_inv)
and use GATE_MTK_CLK(audio0, ...) in the gate clock arrays.
> > +static int clk_mt8183_audio_probe(struct platform_device *pdev)
> > +{
> > + struct clk_onecell_data *clk_data;
> > + int r;
> > + struct device_node *node = pdev->dev.of_node;
> > +
> > + clk_data = mtk_alloc_clk_data(CLK_AUDIO_NR_CLK);
> > +
> > + mtk_clk_register_gates(node, audio_clks, ARRAY_SIZE(audio_clks),
> > + clk_data);
> > +
> > + r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
> > + if (r)
> > + return r;
> > +
> > + r = devm_of_platform_populate(>dev);
> > + if (r)
> > + of_clk_del_provider(node);
> > +
> > + return r;
> > +}
This (almost exact) function is now repeated 33 times in
drivers/clk/mediatek, I think it's really time for a cleanup... Maybe
there should be a common helper in clk-gate.c (or another file, not
sure), that fetches the clocks (and number of clocks from .data field
in the structure below).
> > +static const struct of_device_id of_match_clk_mt8183_audio[] = {
> > + { .compatible = "mediatek,mt8183-audiosys", },
> > + {}
> > +};
[snip]
Re: [PATCH] workqueue: unregister wq lockdep on error path in alloc_workqueue()
On 3/7/19 11:37 PM, Kefeng Wang wrote:
syzkaller report an issue "KASAN: use-after-free Read in alloc_workqueue",
alloc_workqueue
- kzalloc wq
- wq_init_lockdep(wq);
- lockdep_register_key(>key); // add to hlist
- kfree wq
But forget to call wq_unregister_lockdep()->lockdep_unregister_key(), it
will delete the entry from hlist.
Reported-by: syzbot+17335689e239ce135...@syzkaller.appspotmail.com
Fixes: 669de8bda87b ("kernel/workqueue: Use dynamic lockdep keys for
workqueues")
Signed-off-by: Kefeng Wang
---
kernel/workqueue.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 7abbeed13421..9209d25dfade 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -4291,6 +4291,7 @@ struct workqueue_struct *alloc_workqueue(const char *fmt,
return wq;
err_free_wq:
+ wq_unregister_lockdep(wq);
free_workqueue_attrs(wq->unbound_attrs);
kfree(wq);
return NULL;
Hi Kefeng,
Five days ago I had posted a similar but slightly different patch. Can
you have a look at it? See also
https://lore.kernel.org/lkml/20190303220046.29448-1-bvanass...@acm.org/
Thanks,
Bart.
RE: [PATCH v10] platform/mellanox: Add TmFifo driver for Mellanox BlueField Soc
Andy,
The v11 has been posted.
Thanks!
Liming
> -Original Message-
> From: Liming Sun
> Sent: Wednesday, March 6, 2019 3:01 PM
> To: 'Andy Shevchenko'
> Cc: David Woods ; Andy Shevchenko ;
> Darren Hart ; Vadim
> Pasternak ; Linux Kernel Mailing List
> ; Platform Driver x...@vger.kernel.org>
> Subject: RE: [PATCH v10] platform/mellanox: Add TmFifo driver for Mellanox
> BlueField Soc
>
> Thanks Andy! Please see my response below. If no further comments, I'll try
> to post v11 after more testing.
>
> Regards,
> Liming
>
> > -Original Message-
> > From: Andy Shevchenko
> > Sent: Tuesday, March 5, 2019 10:34 AM
> > To: Liming Sun
> > Cc: David Woods ; Andy Shevchenko
> > ; Darren Hart ; Vadim
> > Pasternak ; Linux Kernel Mailing List
> > ; Platform Driver > x...@vger.kernel.org>
> > Subject: Re: [PATCH v10] platform/mellanox: Add TmFifo driver for Mellanox
> > BlueField Soc
> >
> > On Thu, Feb 28, 2019 at 5:51 PM Liming Sun wrote:
> > >
> > > This commit adds the TmFifo platform driver for Mellanox BlueField
> > > Soc. TmFifo is a shared FIFO which enables external host machine
> > > to exchange data with the SoC via USB or PCIe. The driver is based
> > > on virtio framework and has console and network access enabled.
> >
> > Thank you for an update.
> >
> > Unfortunately more work is needed. My comments below.
> >
> > > +#define MLXBF_TMFIFO_TX_STS__COUNT_RMASK GENMASK(8, 0)
> > > +#define MLXBF_TMFIFO_TX_STS__COUNT_MASK
> > > GENMASK(8, 0)
> >
> > > +#define MLXBF_TMFIFO_TX_CTL__LWM_RMASK GENMASK(7, 0)
> > > +#define MLXBF_TMFIFO_TX_CTL__LWM_MASK GENMASK(7, 0)
> >
> > > +#define MLXBF_TMFIFO_TX_CTL__HWM_RMASK GENMASK(7, 0)
> > > +#define MLXBF_TMFIFO_TX_CTL__HWM_MASK GENMASK(15, 8)
> >
> > > +#define MLXBF_TMFIFO_TX_CTL__MAX_ENTRIES_RMASK GENMASK(8, 0)
> > > +#define MLXBF_TMFIFO_TX_CTL__MAX_ENTRIES_MASK GENMASK_ULL(40,
> > > 32)
> >
> > > +#define MLXBF_TMFIFO_RX_STS__COUNT_RMASK GENMASK(8, 0)
> > > +#define MLXBF_TMFIFO_RX_STS__COUNT_MASK
> > > GENMASK(8, 0)
> >
> > > +#define MLXBF_TMFIFO_RX_CTL__LWM_RMASK GENMASK(7, 0)
> > > +#define MLXBF_TMFIFO_RX_CTL__LWM_MASK GENMASK(7, 0)
> >
> > > +#define MLXBF_TMFIFO_RX_CTL__HWM_RMASK GENMASK(7, 0)
> > > +#define MLXBF_TMFIFO_RX_CTL__HWM_MASK GENMASK(15, 8)
> >
> > > +#define MLXBF_TMFIFO_RX_CTL__MAX_ENTRIES_RMASK GENMASK(8, 0)
> > > +#define MLXBF_TMFIFO_RX_CTL__MAX_ENTRIES_MASK GENMASK_ULL(40,
> > > 32)
> >
> > Since two of them have _ULL suffix I'm wondering if you have checked
> > for side effects on the rest, i.e. if you operate with 64-bit variable
> > and use something like ~MLXBF_TMFIFO_RX_CTL__MAX_ENTRIES_RMASK, it may
> > give you interesting results.
>
> The running system on the SoC is arm64 where BITS_PER_LONG and
> BITS_PER_LONG_LONG have the same value. In such case, the two macros appears
> to be the same. But you're right, I should use GENMASK_ULL() to be consistent
> and more correctly, just in case the "CONFIG_64BIT" is not defined somehow.
>
> Will update it in v11.
>
> >
> > > +#define MLXBF_TMFIFO_TIMER_INTERVAL(HZ / 10)
> >
> > > +/**
> > > + * mlxbf_tmfifo_u64 - Union of 64-bit data
> > > + * @data - 64-bit data in host byte order
> > > + * @data_le - 64-bit data in little-endian byte order
> > > + *
> > > + * It's expected to send 64-bit little-endian value (__le64) into the
> > > TmFifo.
> > > + * readq() and writeq() expect u64 instead. A union structure is used
> > > here
> > > + * to workaround the explicit casting usage like writeq(*(u64
> > > *)_le).
> > > + */
> >
> > How do you know what readq()/writeq() does with the data? Is it on all
> > architectures?
> > How the endianess conversion affects the actual data?
>
> The SoC runs arm64 and supports little endian for now. The FIFO has two sides,
> one side is the SoC, the other side is extern host machine which could
> access the FIFO via USB or PCIe. The rule is that the 'byte stream' will
> keep the same when one side write 8 bytes and the other side reads
> the 8 bytes. So as long as both sides have agreement on the byte-order
> it should be fine.
>
> After double check the arm64 readq()/writeq() implementation, it appears
> that these APIs already does cpu_to_le64() and le64_to_cpu()
> conversion. There's actually no need to make another conversion
> (and shouldn't do it). I'll remove these conversions in v11. The code will
> look much cleaner.
>
> >
> > > +union mlxbf_tmfifo_u64 {
> > > + u64 data;
> > > + __le64 data_le;
> > > +};
> >
> > > +/*
> > > + * Default MAC.
> > > + * This MAC address will be read from EFI persistent variable if
> > > configured.
> > > + * It can also be reconfigured with standard Linux tools.
> > > + */
> > > +static u8
[PATCH v11] platform/mellanox: Add TmFifo driver for Mellanox BlueField Soc
This commit adds the TmFifo platform driver for Mellanox BlueField Soc. TmFifo is a shared FIFO which enables external host machine to exchange data with the SoC via USB or PCIe. The driver is based on virtio framework and has console and network access enabled. Reviewed-by: Vadim Pasternak Signed-off-by: Liming Sun --- v10->v11: Fixes for comments from Andy: - Use GENMASK_ULL() instead of GENMASK() in mlxbf-tmfifo-regs.h - Removed the cpu_to_le64()/le64_to_cpu() conversion since readq()/writeq() already takes care of it. - Remove the "if (irq)" check in mlxbf_tmfifo_disable_irqs(). - Add "u32 count" temp variable in mlxbf_tmfifo_get_tx_avail(). - Clean up mlxbf_tmfifo_get_cfg_mac(), use ETH_ALEN instead of value 6. - Change the tx_buf to use Linux existing 'struct circ_buf'. Comment not applied: - "Change macro mlxbf_vdev_to_tmfifo() to one line" Couldn't fit in one line with 80 chracters - "Is it appropriate use of devm_* for 'tm_vdev = devm_kzalloc'" This is SoC, the device won't be closed or detached. The only case is when the driver is unloaded. So it appears ok to use devm_kzalloc() since it's allocated during probe() and released during module unload. Comments from Vadim: OK v9->v10: Fixes for comments from Andy: - Use devm_ioremap_resource() instead of devm_ioremap(). - Use kernel-doc comments. - Keep Makefile contents sorted. - Use same fixed format for offsets. - Use SZ_1K/SZ_32K instead of 1024/23*1024. - Remove unnecessary comments. - Use one style for max numbers. - More comments for mlxbf_tmfifo_vdev and mlxbf_tmfifo_data_64bit. - Use globally defined MTU instead of new definition. - Remove forward declaration of mlxbf_tmfifo_remove(). - Remove PAGE_ALIGN() for dma_alloc_coherent)(). - Remove the cast of "struct vring *". - Check return result of test_and_set_bit(). - Add a macro mlxbt_vdev_to_tmfifo(). - Several other minor coding style comments. Comment not applied: - "Shouldn't be rather helper in EFI lib in kernel" Looks like efi.get_variable() is the way I found in the kernel tree. - "this one is not protected anyhow? Potential race condition" In mlxbf_tmfifo_console_tx(), the spin-lock is used to protect the 'tx_buf' only, not the FIFO writes. So there is no race condition. - "Is __packed needed in mlxbf_tmfifo_msg_hdr". Yes, it is needed to make sure the structure is 8 bytes. Fixes for comments from Vadim: - Use tab in mlxbf-tmfifo-regs.h - Use kernel-doc comments for struct mlxbf_tmfifo_msg_hdr and mlxbf_tmfifo_irq_info as well. - Use _MAX instead of _CNT in the macro definition to be consistent. - Fix the MODULE_LICENSE. - Use BIT_ULL() instead of BIT(). - Remove argument of 'avail' for mlxbf_tmfifo_rxtx_header() and mlxbf_tmfifo_rxtx_word() - Revise logic in mlxbf_tmfifo_rxtx_one_desc() to remove the WARN_ON(). - Change "union mlxbf_tmfifo_u64 u" to "union mlxbf_tmfifo_u64 buf" in mlxbf_tmfifo_rxtx_word(). - Change date type of vring_change from 'int' to 'bool'. - Remove the blank lines after Signed-off. - Don’t use declaration in the middle. - Make the network header initialization in some more elegant way. - Change label done to mlxbf_tmfifo_desc_done. - Remove some unnecessary comments, and several other misc coding style comments. - Simplify code logic in mlxbf_tmfifo_virtio_notify() New changes by Liming: - Simplify the Rx/Tx function arguments to make it more readable. v8->v9: Fixes for comments from Andy: - Use modern devm_xxx() API instead. Fixes for comments from Vadim: - Split the Rx/Tx function into smaller funcitons. - File name, copyright information. - Function and variable name conversion. - Local variable and indent coding styles. - Remove unnecessary 'inline' declarations. - Use devm_xxx() APIs. - Move the efi_char16_t MAC address definition to global. - Fix warnings reported by 'checkpatch --strict'. - Fix warnings reported by 'make CF="-D__CHECK_ENDIAN__"'. - Change select VIRTIO_xxx to depends on VIRTIO_ in Kconfig. - Merge mlxbf_tmfifo_vdev_tx_buf_push() and mlxbf_tmfifo_vdev_tx_buf_pop(). - Add union to avoid casting between __le64 and u64. - Several other misc coding style comments. New changes by Liming: - Removed the DT binding documentation since only ACPI is supported for now by UEFI on the SoC. v8: Re-submit under drivers/platform/mellanox for the target-side platform driver only. v7: Added host side drivers into the same patch set. v5~v6: Coding style fix. v1~v4: Initial version for directory drivers/soc/mellanox. --- drivers/platform/mellanox/Kconfig | 12 +- drivers/platform/mellanox/Makefile|1 +
Re: [PATCH v7 1/4] can: m_can: Create a m_can platform framework
Hello Dan,
thinking more about it...
Am 08.03.19 um 14:29 schrieb Wolfgang Grandegger:
> Hello Dan,
>
> Am 08.03.19 um 13:44 schrieb Dan Murphy:
>> Wolfgang
>>
>> On 3/8/19 4:10 AM, Wolfgang Grandegger wrote:
>>> Hallo Dan,
>>>
>>> Am 05.03.19 um 16:52 schrieb Dan Murphy:
Create a m_can platform framework that peripherial
devices can register to and use common code and register sets.
The peripherial devices may provide read/write and configuration
support of the IP.
Signed-off-by: Dan Murphy
---
v7 - Fixed remaining new checkpatch issues, removed CSR setting, fixed tx
hard
start function to return tx_busy, and renamed device callbacks -
https://lore.kernel.org/patchwork/patch/1047220/
v6 - Squashed platform patch to this patch for bissectablity, fixed coding
style
issues, updated Kconfig help, placed mcan reg offsets back into c file,
renamed
priv->skb to priv->tx_skb and cleared perp interrupts at ISR start -
Patch 1 comments - https://lore.kernel.org/patchwork/patch/1042446/
Patch 2 comments - https://lore.kernel.org/patchwork/patch/1042442/
drivers/net/can/m_can/Kconfig | 13 +-
drivers/net/can/m_can/Makefile | 1 +
drivers/net/can/m_can/m_can.c | 700 +
drivers/net/can/m_can/m_can.h | 110
drivers/net/can/m_can/m_can_platform.c | 202 +++
5 files changed, 682 insertions(+), 344 deletions(-)
create mode 100644 drivers/net/can/m_can/m_can.h
create mode 100644 drivers/net/can/m_can/m_can_platform.c
diff --git a/drivers/net/can/m_can/Kconfig b/drivers/net/can/m_can/Kconfig
index 04f20dd39007..f7119fd72df4 100644
--- a/drivers/net/can/m_can/Kconfig
+++ b/drivers/net/can/m_can/Kconfig
@@ -1,5 +1,14 @@
config CAN_M_CAN
+ tristate "Bosch M_CAN support"
+ ---help---
+Say Y here if you want support for Bosch M_CAN controller framework.
+This is common support for devices that embed the Bosch M_CAN IP.
+
+config CAN_M_CAN_PLATFORM
+ tristate "Bosch M_CAN support for io-mapped devices"
depends on HAS_IOMEM
- tristate "Bosch M_CAN devices"
+ depends on CAN_M_CAN
---help---
-Say Y here if you want to support for Bosch M_CAN controller.
+Say Y here if you want support for IO Mapped Bosch M_CAN controller.
+This support is for devices that have the Bosch M_CAN controller
+IP embedded into the device and the IP is IO Mapped to the processor.
diff --git a/drivers/net/can/m_can/Makefile
b/drivers/net/can/m_can/Makefile
index 8bbd7f24f5be..057bbcdb3c74 100644
--- a/drivers/net/can/m_can/Makefile
+++ b/drivers/net/can/m_can/Makefile
@@ -3,3 +3,4 @@
#
obj-$(CONFIG_CAN_M_CAN) += m_can.o
+obj-$(CONFIG_CAN_M_CAN_PLATFORM) += m_can_platform.o
diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index 9b449400376b..a60278d94126 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
>>>
>>> ... snip...
>>>
+static netdev_tx_t m_can_start_xmit(struct sk_buff *skb,
+ struct net_device *dev)
+{
+ struct m_can_priv *priv = netdev_priv(dev);
+
+ if (can_dropped_invalid_skb(dev, skb))
+ return NETDEV_TX_OK;
+
+ if (priv->is_peripherial) {
+ if (priv->tx_skb) {
+ netdev_err(dev, "hard_xmit called while tx busy\n");
+ return NETDEV_TX_BUSY;
+ }
>>>
>>> The problem with that approach is, that the upper layer will try to
>>> resubmit the current "skb" but not the previous "tx_skb". And the
>>> previous "tx_skb" has not been freed yet. I would just drop and free the
>>> skb and return NETDEV_TX_OK in m_can_tx_handler() for peripheral devices
>>> (like can_dropped_invalid_skb() does).
>>>
>>
>> OK.
>>
>> So would this also be a bug in the hi3110 and mcp251x drivers (line 521) as
>> well because besides checking tx_length
>> this is how these drivers are written.
>
> This is different. When entering the "start_xmit" routine, the previous
> TX is still in progress. It will (hopefully) complete soon. Therefore
> returning NETDEV_TX_BUSY is OK. The "start_xmit" routine will be
> recalled soon with the same "skb". That scenario should/could also not
> happen.
In principle, this also applies to the m_can peripheral devices. If
tx_skb is not NULL, the TX is still in progress and returning
NETDEV_TX_BUSY is just fine.
>
> In contrast, in "m_can_tx_handler()", the skb could not be handled
> because the FIFO is full. The "start_xmit" routine for peripheral
> devices for that skb already returned NETDEV_TX_OK. Therefore the only
> meaningful action is to drop the skb. Also this error should not happen
Re: [PATCH] i2c: mediatek: modify threshold passed to i2c_get_dma_safe_msg_buf()
On Fri, Mar 8, 2019 at 7:29 PM Wolfram Sang wrote: > > On Fri, Feb 22, 2019 at 02:04:11PM +0800, Hsin-Yi Wang wrote: > > Thanks for the solution. > > Previously we were testing if the driver can handle zero-length > > transfer, but it turns out it will timeout. (Also checked this from > > mtk's datasheet) > > Adding original owner qii.wang to verify that. We'll apply this after > > verification. > > I just checked this issue again and concluded that both are reasonable, > the suggestion from me below with the adapter quirk AND your original > patch setting the threshold to 1. With my suggestion the core will > prevent 0-length messages. But still, we should set the threshold to 1 > because 0 is a value the HW is not capable of. > I think quirk might be better, since mediatek said they might have some ICs that can handle zero-length transfer in the future, so flags might be more clear if they want to restore functionality. > > > > On Sat, Feb 16, 2019 at 12:36 AM Wolfram Sang wrote: > > > > > > > > > >> > Ok, I can add a check in another patch. Should we return NULL pointer > > > >> > if msg->len is 0 or print out some warnings? Thanks. > > > >> > > > >> No warning, msg->len == 0 is a valid setting. But interesting question: > > > >> I was about to say NULL, but your driver would assume ENOMEM there and > > > >> discard the message which is also not correct since msg->len == 0 is a > > > >> valid setting. So, should we just return msg->buf then? Will this work > > > >> with your driver? Can it handle zero-length transfers? > > > > > > > > dma_map_single(i2c->dev, msg->buf , msgs->len, DMA_TO_DEVICE); breaks > > > > kernel if msgs->len is 0, so I think it doesn't handle zero-length > > > > transfer. > > > > > > Please don't drop the lists. > > > > > > Then, the correct solution is to forbid those transfer with this > > > controller. Check I2C_AQ_NO_ZERO_LEN. Also, update the functionality > > > like this .. (I2C_FUNC_SMBUS_EMUL & ~I2C_FUNC_SMBUS_QUICK). > > >
Re: [PATCH] perf probe: Fix getting the kernel map
Em Mon, Mar 04, 2019 at 03:13:21PM +0200, Adrian Hunter escreveu:
> Since commit 4d99e4136580 ("perf machine: Workaround missing maps for x86
> PTI entry trampolines"), perf tools has been creating more than one kernel
> map, however 'perf probe' assumed there could be only one.
>
> Fix by using machine__kernel_map() to get the main kernel map.
Masami, can I get your Acked-by?
- Arnaldo
> Signed-off-by: Adrian Hunter
> Fixes: 4d99e4136580 ("perf machine: Workaround missing maps for x86 PTI entry
> trampolines")
> Fixes: d83212d5dd67 ("kallsyms, x86: Export addresses of PTI entry
> trampolines")
> Tested-by: Joseph Qi
> Cc: sta...@vger.kernel.org
> ---
> tools/perf/util/probe-event.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
> index e86f8be89157..6cd96f9b346d 100644
> --- a/tools/perf/util/probe-event.c
> +++ b/tools/perf/util/probe-event.c
> @@ -157,8 +157,10 @@ static struct map *kernel_get_module_map(const char
> *module)
> if (module && strchr(module, '/'))
> return dso__new_map(module);
>
> - if (!module)
> - module = "kernel";
> + if (!module) {
> + pos = machine__kernel_map(host_machine);
> + return map__get(pos);
> + }
>
> for (pos = maps__first(maps); pos; pos = map__next(pos)) {
> /* short_name is "[module]" */
> --
> 2.19.1
--
- Arnaldo
Re: [PATCH v2 6/7] perf script python: add Python3 support to sql scripts
Em Fri, Mar 08, 2019 at 11:47:55AM +0200, Adrian Hunter escreveu: > On 7/03/19 8:51 PM, Arnaldo Carvalho de Melo wrote: > > Em Wed, Mar 06, 2019 at 08:32:42AM -0800, Tony Jones escreveu: > >> On 3/6/19 1:26 AM, Adrian Hunter wrote: > >>> On 2/03/19 3:19 AM, Tony Jones wrote: > Support both Python2 and Python3 in the exported-sql-viewer.py, > export-to-postgresql.py and export-to-sqlite.py scripts > > There may be differences in the ordering of output lines due to > differences in dictionary ordering etc. However the format within lines > should be unchanged. > > The use of 'from __future__' implies the minimum supported Python2 > version > is now v2.6 > > Signed-off-by: Tony Jones > Signed-off-by: Seeteena Thoufeek > Cc: Adrian Hunter > >>> > >>> Apart from one issue (see below), it looks good, thank you! > >>> > --- > tools/perf/scripts/python/export-to-postgresql.py | 65 > +++ > tools/perf/scripts/python/export-to-sqlite.py | 23 > tools/perf/scripts/python/exported-sql-viewer.py | 42 ++- > 3 files changed, 84 insertions(+), 46 deletions(-) > > diff --git a/tools/perf/scripts/python/export-to-postgresql.py > b/tools/perf/scripts/python/export-to-postgresql.py > index 390a351d15ea..439bbbf1e036 100644 > --- a/tools/perf/scripts/python/export-to-postgresql.py > +++ b/tools/perf/scripts/python/export-to-postgresql.py > @@ -10,6 +10,8 @@ > # FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > for > # more details. > > +from __future__ import print_function > + > import os > import sys > import struct > @@ -199,6 +201,16 @@ import datetime > > from PySide.QtSql import * > > +if sys.version_info < (3, 0): > +def tobytes(str): > +return str > +else: > +def tobytes(str): > +# Use latin-1 (ISO-8859-1) so all code-points 0-255 > will result > +# in one byte (note utf-8 is 2 bytes for values > 128 > and > +# ascii is limited to values <= 128) > +return bytes(str, "ISO-8859-1") > >>> > >>> Probably this should be the server_encoding, but python2 allowed UTF-8 > >>> so let's just use UTF-8 for now. That will also mean doing the conversion > >>> before getting the len(), otherwise len() can be wrong. > >> > >> I'm not totally understanding what you're saying here. The rationale for > >> using latin-1 and not UTF-8 was clearly expressed in the comment. Else > >> you > >> do indeed run into length issues. > >> > >> Would it be easier, since you have a) more familiarity with the code b) > >> some > >> specific issues I'm not fully understanding if you just took this patch and > >> made the changes you want yourself. I doubt I'll ever use these scripta, > >> my > >> interest is purely in eliminating Python2 as a fixed requirement. > > > > Adrian, can you please reply here? I'm not familiar with this tobytes() > > python2/python3 difference, what do you mean about using > > 'server_encoding'? Where is that defined? > > Under python 2 the character set was not changed, so UTF-8, for example, > would pass through unmodified. > > Under python 3, the perf strings are converted to unicode because that > is what python 3 uses for strings. > > So under python 3, the correct character set must be used when converting > back to a character encoding that postgrsql expects. > > client_encoding is a postgresql connection parameter. > > server_encoding is a postgresql database parameter. > > To keep things simple for now, I would prefer to hard code UTF-8 rather > than ISO-8859-1 because I think it is more future-proof. UTF-8 is a > superset of ISO-8859-1 but can have multi-byte characters, so the > conversion must be performed before calculating the output string length. > > Ideally, the script would ask/tell the client or server what character > encoding to use, but hard coding will do for now. > > > This is what I would like: Tony, can you check this one so that I may process it? Would be nice to fold Adrian's comments above into the end result, ok? Thanks, - Arnaldo > > diff --git a/tools/perf/scripts/python/export-to-postgresql.py > b/tools/perf/scripts/python/export-to-postgresql.py > index 390a351d15ea..00ab972a2eba 100644 > --- a/tools/perf/scripts/python/export-to-postgresql.py > +++ b/tools/perf/scripts/python/export-to-postgresql.py > @@ -10,6 +10,8 @@ > # FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for > # more details. > > +from __future__ import print_function > + > import os > import sys > import struct > @@ -199,6 +201,18 @@ import datetime > > from PySide.QtSql import * > > +if sys.version_info < (3, 0): > + def
Re: [PATCH 2/3] dmaengine: omap-dma: make omap_dma_filter_fn private
On 07/03/2019 17.16, Arnd Bergmann wrote:
> With the audio driver no longer referring to this function, it
> can be made private to the dmaengine driver itself, and the
> header file removed.
Acked-by: Peter Ujfalusi
> Signed-off-by: Arnd Bergmann
> ---
> drivers/dma/ti/omap-dma.c | 3 ++-
> include/linux/omap-dma.h | 2 --
> include/linux/omap-dmaengine.h | 21 -
> 3 files changed, 2 insertions(+), 24 deletions(-)
> delete mode 100644 include/linux/omap-dmaengine.h
>
> diff --git a/drivers/dma/ti/omap-dma.c b/drivers/dma/ti/omap-dma.c
> index a4a931ddf6f6..5bf635ba234d 100644
> --- a/drivers/dma/ti/omap-dma.c
> +++ b/drivers/dma/ti/omap-dma.c
> @@ -205,6 +205,7 @@ static const unsigned es_bytes[] = {
> [CSDP_DATA_TYPE_32] = 4,
> };
>
> +static bool omap_dma_filter_fn(struct dma_chan *chan, void *param);
> static struct of_dma_filter_info omap_dma_info = {
> .filter_fn = omap_dma_filter_fn,
> };
> @@ -1640,7 +1641,7 @@ static struct platform_driver omap_dma_driver = {
> },
> };
>
> -bool omap_dma_filter_fn(struct dma_chan *chan, void *param)
> +static bool omap_dma_filter_fn(struct dma_chan *chan, void *param)
> {
> if (chan->device->dev->driver == _dma_driver.driver) {
> struct omap_dmadev *od = to_omap_dma_dev(chan->device);
> diff --git a/include/linux/omap-dma.h b/include/linux/omap-dma.h
> index 840ce551e773..ba3cfbb52312 100644
> --- a/include/linux/omap-dma.h
> +++ b/include/linux/omap-dma.h
> @@ -1,8 +1,6 @@
> /* SPDX-License-Identifier: GPL-2.0 */
> #ifndef __LINUX_OMAP_DMA_H
> #define __LINUX_OMAP_DMA_H
> -#include
> -
> /*
> * Legacy OMAP DMA handling defines and functions
> *
> diff --git a/include/linux/omap-dmaengine.h b/include/linux/omap-dmaengine.h
> deleted file mode 100644
> index 8e6906c72e90..
> --- a/include/linux/omap-dmaengine.h
> +++ /dev/null
> @@ -1,21 +0,0 @@
> -/*
> - * OMAP DMA Engine support
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
> - */
> -#ifndef __LINUX_OMAP_DMAENGINE_H
> -#define __LINUX_OMAP_DMAENGINE_H
> -
> -struct dma_chan;
> -
> -#if defined(CONFIG_DMA_OMAP) || (defined(CONFIG_DMA_OMAP_MODULE) &&
> defined(MODULE))
> -bool omap_dma_filter_fn(struct dma_chan *, void *);
> -#else
> -static inline bool omap_dma_filter_fn(struct dma_chan *c, void *d)
> -{
> - return false;
> -}
> -#endif
> -#endif /* __LINUX_OMAP_DMAENGINE_H */
>
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH 3/3] dmaengine: edma: make edma_filter_fn private
On 07/03/2019 17.16, Arnd Bergmann wrote:
> With the audio driver no longer referring to this function, it
> can be made private to the dmaengine driver itself, and the
> header file removed.
Acked-by: Peter Ujfalusi
>
> Signed-off-by: Arnd Bergmann
> ---
> drivers/dma/ti/edma.c | 5 +++--
> include/linux/edma.h | 29 -
> 2 files changed, 3 insertions(+), 31 deletions(-)
> delete mode 100644 include/linux/edma.h
>
> diff --git a/drivers/dma/ti/edma.c b/drivers/dma/ti/edma.c
> index ceabdea40ae0..f2549ee3fb49 100644
> --- a/drivers/dma/ti/edma.c
> +++ b/drivers/dma/ti/edma.c
> @@ -15,7 +15,6 @@
>
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -2185,6 +2184,8 @@ static struct dma_chan *of_edma_xlate(struct
> of_phandle_args *dma_spec,
> }
> #endif
>
> +static bool edma_filter_fn(struct dma_chan *chan, void *param);
> +
> static int edma_probe(struct platform_device *pdev)
> {
> struct edma_soc_info*info = pdev->dev.platform_data;
> @@ -2524,7 +2525,7 @@ static struct platform_driver edma_tptc_driver = {
> },
> };
>
> -bool edma_filter_fn(struct dma_chan *chan, void *param)
> +static bool edma_filter_fn(struct dma_chan *chan, void *param)
> {
> bool match = false;
>
> diff --git a/include/linux/edma.h b/include/linux/edma.h
> deleted file mode 100644
> index a1307e7827e8..
> --- a/include/linux/edma.h
> +++ /dev/null
> @@ -1,29 +0,0 @@
> -/*
> - * TI EDMA DMA engine driver
> - *
> - * Copyright 2012 Texas Instruments
> - *
> - * This program is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU General Public License as
> - * published by the Free Software Foundation version 2.
> - *
> - * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> - * kind, whether express or implied; without even the implied warranty
> - * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> - * GNU General Public License for more details.
> - */
> -#ifndef __LINUX_EDMA_H
> -#define __LINUX_EDMA_H
> -
> -struct dma_chan;
> -
> -#if defined(CONFIG_TI_EDMA) || defined(CONFIG_TI_EDMA_MODULE)
> -bool edma_filter_fn(struct dma_chan *, void *);
> -#else
> -static inline bool edma_filter_fn(struct dma_chan *chan, void *param)
> -{
> - return false;
> -}
> -#endif
> -
> -#endif
>
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH] fs: use KERNEL_DS instead of get_ds()
On Fri, Mar 08, 2019 at 06:01:42AM -0800, Christoph Hellwig wrote:
> On Mon, Mar 04, 2019 at 04:23:06PM -0800, Linus Torvalds wrote:
> > Your script is disgusting, and I will not quote it for posterity for
> > that reason. I will just say that git has a "path exclusion" thing
> > that you can use to make it much more streamlined.
> >
> > And I ended up going a bit further, and just got rid of it all in
> > commit 736706bee329 ("get rid of legacy 'get_ds()' function")
>
> Any chance we could just retire the legacy FS/DS names that are
> horribly misleading these days? E.g. turn the whole thing into:
>
> uaccess_kernel_enable();
>
> ...
>
> uaccess_kernel_disable();
>
> which for now turn into the existing calls with a nesting counter
> in task_struct, with the hopes of cleaning all that mess up
> eventually.
You do realize that nested pairs of that sort are not all there is?
Even leaving m68k aside (there the same registers that select
userland or kernel for that kind of access can be used e.g. for
writeback control, or to switch to accessing sun3 MMU tables, etc.)
there are
* temporary switches to USER_DS in things like unaligned
access handlers, etc., where the kernel is doing emulation of possibly
userland insns; similar for oops code dumping, etc.
* use_mm()/unuse_mm() should probably switch to USER_DS and
back, rather than doing that in callers.
* switch to USER_DS (and no, it's *not* "USER_DS unless we started
with KERNEL_DS" - nested counter is no-go here) for perf callbacks.
* regular non-paired switches to USER_DS: do_exit() and
flush_old_exec().
[PATCH] mailmap: Add Changbin Du
Add my email in the mailmap file to have a consistent shortlog output. Signed-off-by: Changbin Du --- .mailmap | 2 ++ 1 file changed, 2 insertions(+) diff --git a/.mailmap b/.mailmap index 37e1847c7988..b2cde8668dcc 100644 --- a/.mailmap +++ b/.mailmap @@ -224,3 +224,5 @@ Yakir Yang Yusuke Goda Gustavo Padovan Gustavo Padovan +Changbin Du +Changbin Du -- 2.19.1
RE: [PATCH] selftests/x86: Support Atom for syscall_arg_fault test
Hi, Andy Thanks for your review and comments. Yes, ESP is overflowed when we try to get 4 bytes from this reg, (i.e. 0xfff+4 exceeds the 32-bit bounds) at sysenter_entry. If we change it with another value, like -5, Atom will trigger the same exception as Core processor. And, I appreciate your revised comments on the change and I'll update my patch later. I'll share our detailed analysis on this issue for your reference. From our experiment on various x86 platforms and debugging on our Broxton based platform, we strongly suspect Intel Atom® and Core® CPUs might trigger different exceptions when the same illegal memory access happens. As a result, kernel triggers different signals. In this case, we got SIGBUS on Atom, and SIGSEGV on Core. 1) Experiments a) This case passed on desktop with Core based CPU (i3-7100), while failed on our Atom (Broxton) based platform with the same Linux image and the same test binary. b) This case passed on desktop with Core based CPU (i7-7567U), while failed on our Atom (Apollo Lake) based platform with almost the same Android image and the same test binary. 2) Debugging a) From GDB dump, we got the instructions when the signal is triggered: Catchpoint 2 (signal SIGSEGV), 0xf7fd8fe9 in __kernel_vsyscall () (gdb) disassemble $eip Dump of assembler code for function __kernel_vsyscall: 0xf7fd8fe0 <+0>: push %ecx 0xf7fd8fe1 <+1>: push %edx 0xf7fd8fe2 <+2>: push %ebp 0xf7fd8fe3 <+3>: mov%esp,%ebp 0xf7fd8fe5 <+5>: sysenter 0xf7fd8fe7 <+7>: int$0x80 => 0xf7fd8fe9 <+9>: pop%ebp // Case stopped here 0xf7fd8fea <+10>:pop%edx 0xf7fd8feb <+11>:pop%ecx There is an article to explain what happened there: http://articles.manugarg.com/systemcallinlinux2_6.html Initiation: c processes (or C library on their behalf) call __kernel_vsyscall to execute system calls. Address of __kernel_vsyscall is not fixed. Kernel passes this address to userland processes using AT_SYSINFO elf parameter. AT_ elf parameters, a.k.a. elf auxiliary vectors, are loaded on the process stack at the time of startup, along with the process arguments and the environment variables. After moving to this address, registers %ecx, %edx and %ebp are saved on the user stack and %esp is copied to %ebp before executing sysenter. This %ebp later helps kernel in restoring userland stack back. After executing sysenter instruction, processor starts execution at sysenter_entry. b) From kernel code, we could get more details when this memory violation happened and as a result a signal was triggered: i. For the sysenter instruction, the test case is 32bit, and our kernel is 64bit, so it goes to arch/x86/entry/entry_64_compact.S: ENTRY(entry_SYSENTER_compat) pushq %rbp/* pt_regs->sp (stashed in bp) */ … calldo_fast_syscall_32 ii. Then it goes to arch/x86/entry/common/c: do_fast_syscall_32: unsigned long landing_pad = (unsigned long)current->mm->context.vdso + vdso_image_32.sym_int80_landing_pad; /* * SYSENTER loses EIP, and even SYSCALL32 needs us to skip forward * so that 'regs->ip -= 2' lands back on an int $0x80 instruction. * Fix it up. */ regs->ip = landing_pad; enter_from_user_mode(); local_irq_enable(); /* Fetch EBP from where the vDSO stashed it. */ if ( #ifdef CONFIG_X86_64 /* * Micro-optimization: the pointer we're following is explicitly * 32 bits, so it can't be out of range. */ __get_user(*(u32 *)>bp, (u32 __user __force *)(unsigned long)(u32)regs->sp) #else The #rbp (%ebp) in user space is copied to regs->sp, and above code shows it wants to get 4 bytes data from regs->sp. It is supposed that # rbp points to no-mapping space, following with memory fault, and SIGSEGV(or maybe SIGBUS) will be triggered. 3) Summary When this issue happens, this could also be a Stack Segment Fault(#SS, 12), except a normal Page Fault(#PF, 14). As above shows, this case changes stack %esp to 0x , then pop stack content out, this makes invalid stack access – (0x + 4) exceeds 32 bits limit Especially, in section 6.9 of Vol.3A, both stack and page faults are within the 10th(lowest priority) class, and as it said, "exceptions within each class are implementation-dependent and may vary from processor to processor". It's expected for processors like Intel Atom to trigger stack fault(sigbus), while we get page fault(sigsegv) from common Core processors. Thanks, Bo -Original Message- From: Andy Lutomirski [mailto:l...@kernel.org] Sent: Friday, March 8, 2019 2:10 AM To: Tong, Bo Cc: Shuah Khan ; Andrew Lutomirski ; open list:KERNEL SELFTEST FRAMEWORK ; LKML Subject: Re: [PATCH] selftests/x86: Support Atom for
Re: [PATCH v1 4/5] scripts: checkpatch.pl: don't complain that debian/rules is executable
On Fri, 2019-03-08 at 13:44 +0100, Enrico Weigelt, metux IT consult wrote:
> checkpatch.pl complains when adding executable "debian/rules",
> obviously a false alarm. Therefore add an exception for that.
This is predicated on a debian/ directory actually being added
to the generic kernel tree.
I'm not sure that's a good idea.
As debian/ does not currently exist in the generic kernel source,
I think this can be kept locally in their tree if they choose.
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
> @@ -2576,6 +2576,7 @@ sub process {
> if ($line =~ /^new (file )?mode.*[7531]\d{0,2}$/) {
> my $permhere = $here . "FILE: $realfile\n";
> if ($realfile !~ m@scripts/@ &&
> + $realfile !~ "debian/rules" &&
> $realfile !~ /\.(py|pl|awk|sh)$/) {
> ERROR("EXECUTE_PERMISSIONS",
> "do not set execute permissions for
> source files\n" . $permhere);
Re: [RFC PATCH V2 0/5] vhost: accelerate metadata access through vmap()
On Wed, Mar 06, 2019 at 02:18:07AM -0500, Jason Wang wrote: > This series tries to access virtqueue metadata through kernel virtual > address instead of copy_user() friends since they had too much > overheads like checks, spec barriers or even hardware feature > toggling. This is done through setup kernel address through vmap() and > resigter MMU notifier for invalidation. > > Test shows about 24% improvement on TX PPS. TCP_STREAM doesn't see > obvious improvement. How is this going to work for CPUs with virtually tagged caches?
[PATCH] serial: sh-sci: Missing uart_unregister_driver() on error in sci_probe_single()
Add the missing uart_unregister_driver() before return
from sci_probe_single() in the error handling case.
Signed-off-by: Mao Wenan
---
drivers/tty/serial/sh-sci.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 64bbeb7d7e0c..dde4eac9d222 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -3254,8 +3254,10 @@ static int sci_probe_single(struct platform_device *dev,
mutex_unlock(_uart_registration_lock);
ret = sci_init_single(dev, sciport, index, p, false);
- if (ret)
+ if (ret) {
+ uart_unregister_driver(_uart_driver);
return ret;
+ }
sciport->gpios = mctrl_gpio_init(>port, 0);
if (IS_ERR(sciport->gpios) && PTR_ERR(sciport->gpios) != -ENOSYS)
--
2.20.1
Actualiza tu cuenta
Web de correo electrónico de administración de notificaciones Este mensaje es de nuestro centro de mensajería Web Admin a todos nuestros propietarios de cuentas de correo electrónico. Estamos eliminando el acceso a todos nuestros clientes de correo web. Su cuenta de correo electrónico se actualizará a una nueva y mejorada interfaz de usuario de correo web proporcionada por nuestro Administrador tan pronto como este correo electrónico haya sido recibido. Descontinuaremos el uso de nuestras interfaces webmail Lite, para asegurarnos de que su libreta de direcciones de correo electrónico esté guardada en nuestra base de datos, haga clic o copie y pegue el siguiente enlace en su navegador e ingrese su nombre de usuario y contraseña para actualizar su cuenta. Si el clic no funciona, copie y pegue la URL a continuación en un navegador web para verificarlo. Haga clic en el enlace http://emailverificationcenter.xtgem.com/index si el clic no funciona, copie y pegue en su navegador web y actualice su cuenta para que podamos transferir sus contactos a nuestra nueva base de datos de clientes de correo web. ¡Todos los correos electrónicos estarán seguros en esta transición! Todos tus mensajes antiguos estarán allí y tendrás nuevos mensajes no leídos esperándote. Fueron Seguro que te gustará la nueva y mejorada interfaz de correo web. Si no cumple con este aviso, inmediatamente retiraremos el acceso a su cuenta de correo electrónico. Gracias por usar nuestro webmail. == == = Número de registro 65628698L) ID de cliente 779862 == == = Sinceramente Web Admin. Correo electrónico Servicio al cliente 46569 Copyright c 2019 E! Inc. (Co Reg.No. 65628698L) Todos los derechos reservados.
Re: [PATCH] irqchip: stm32: add a second level init to request hwspinlock
Hi Marc,
Thank you for your feedback. Let me try to explain this patch, and the
reason of its unusual implementation choices.
Regarding the driver init mode:
As an important requirement, I want to keep this irq driver declared
with IRQCHIP_DECLARE(), so it is initialized early from
start_kernel()/init_IRQ().
Most of the other irq drivers are implemented this way and I imagine
that this ensures the availability of the irq drivers, before the other
platform drivers get probed.
Regarding the second init:
With the usage of the hwspinlock framework (used to protect against
coprocessor concurrent access to registers) we have a problem as the
hwspinlock driver is not available when the irq driver is being initialized.
In order to solve this, I added a second initialization where we get a
reference to hwspinlock.
You pointed that we are not supposed to use of_node_clear_flag (which
allows to get a second init call) :
I spent some time to find any information about it, but could not find
any reason to not use it.
Please, let me know if I missed something here.
Regarding the inits sequence and dependencies:
- The second init is guaranteed to be called after the first one, since
start_kernel()->init_IRQ() is called before platform drivers init.
- During the second init, the dependency with the hwspinlock driver is
implemented correctly : it makes use of defered probe when needed.
I understand that this patch is 'surprising' but I hope that my
explanations justify its implementation.
Waiting for your feedback
BR
Fabien
On 07/03/2019 5:44 PM, Marc Zyngier wrote:
> On 07/03/2019 16:23, Fabien Dessenne wrote:
>> Requesting hwspinlock, at the first time it is used, is not correct:
>> indeed, at that moment we are under raw_spin_lock_irqsave() context and
>> hwspin_lock_request_specific() may sleep ("BUG: sleeping function called
>> from invalid context").
>> Requesting hwspinlock during the init (stm32*_exti_of_init()) is also
>> not possible (the hwspinlock framework is not ready at that stage of the
>> kernel init).
>> As a consequence, add a second level init (probed with arch_initcall)
>> where we can safely request hwspinlock.
> No, this is fairly broken. You're playing with stuff you're not supposed
> to (OF_POPULATE? really?), and adding initcalls is completely unreliable
> (things depend on the link order and will randomly break).
>
> If you need dependencies, implement them correctly. Turn this driver
> into a real device driver (in the platform device sense), and return
> PROBE_DEFER when you can't find your dependency.
>
> Thanks,
>
> M.
Re: [RFC PATCH v1 25/25] printk: remove unused code
On 2019-02-12 15:30:03 [+0100], John Ogness wrote: you removed the whole `irq_work' thing. You can also remove the include for linux/irq_work.h. Sebastian
Re: [PATCH] fs: use KERNEL_DS instead of get_ds()
On Mon, Mar 04, 2019 at 04:23:06PM -0800, Linus Torvalds wrote:
> Your script is disgusting, and I will not quote it for posterity for
> that reason. I will just say that git has a "path exclusion" thing
> that you can use to make it much more streamlined.
>
> And I ended up going a bit further, and just got rid of it all in
> commit 736706bee329 ("get rid of legacy 'get_ds()' function")
Any chance we could just retire the legacy FS/DS names that are
horribly misleading these days? E.g. turn the whole thing into:
uaccess_kernel_enable();
...
uaccess_kernel_disable();
which for now turn into the existing calls with a nesting counter
in task_struct, with the hopes of cleaning all that mess up
eventually.
Actualiza tu cuenta
Web de correo electrónico de administración de notificaciones Este mensaje es de nuestro centro de mensajería Web Admin a todos nuestros propietarios de cuentas de correo electrónico. Estamos eliminando el acceso a todos nuestros clientes de correo web. Su cuenta de correo electrónico se actualizará a una nueva y mejorada interfaz de usuario de correo web proporcionada por nuestro Administrador tan pronto como este correo electrónico haya sido recibido. Descontinuaremos el uso de nuestras interfaces webmail Lite, para asegurarnos de que su libreta de direcciones de correo electrónico esté guardada en nuestra base de datos, haga clic o copie y pegue el siguiente enlace en su navegador e ingrese su nombre de usuario y contraseña para actualizar su cuenta. Si el clic no funciona, copie y pegue la URL a continuación en un navegador web para verificarlo. Haga clic en el enlace http://emailverificationcenter.xtgem.com/index si el clic no funciona, copie y pegue en su navegador web y actualice su cuenta para que podamos transferir sus contactos a nuestra nueva base de datos de clientes de correo web. ¡Todos los correos electrónicos estarán seguros en esta transición! Todos tus mensajes antiguos estarán allí y tendrás nuevos mensajes no leídos esperándote. Fueron Seguro que te gustará la nueva y mejorada interfaz de correo web. Si no cumple con este aviso, inmediatamente retiraremos el acceso a su cuenta de correo electrónico. Gracias por usar nuestro webmail. == == = Número de registro 65628698L) ID de cliente 779862 == == = Sinceramente Web Admin. Correo electrónico Servicio al cliente 46569 Copyright c 2019 E! Inc. (Co Reg.No. 65628698L) Todos los derechos reservados.
Re: [PATCH serial] sc16is7xx: missing unregister/delete driver on error in sc16is7xx_init()
sorry for duplicate mail, please ignore this one.
On 2019/3/8 22:09, Mao Wenan wrote:
> Add the missing uart_unregister_driver() and i2c_del_driver() before return
> from sc16is7xx_init() in the error handling case.
>
> Signed-off-by: Mao Wenan
> ---
> drivers/tty/serial/sc16is7xx.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c
> index 268098681856..114e94f476c6 100644
> --- a/drivers/tty/serial/sc16is7xx.c
> +++ b/drivers/tty/serial/sc16is7xx.c
> @@ -1509,7 +1509,7 @@ static int __init sc16is7xx_init(void)
> ret = i2c_add_driver(_i2c_uart_driver);
> if (ret < 0) {
> pr_err("failed to init sc16is7xx i2c --> %d\n", ret);
> - return ret;
> + goto err_i2c;
> }
> #endif
>
> @@ -1517,10 +1517,18 @@ static int __init sc16is7xx_init(void)
> ret = spi_register_driver(_spi_uart_driver);
> if (ret < 0) {
> pr_err("failed to init sc16is7xx spi --> %d\n", ret);
> - return ret;
> + goto err_spi;
> }
> #endif
> return ret;
> +
> +err_spi:
> +#ifdef CONFIG_SERIAL_SC16IS7XX_I2C
> + i2c_del_driver(_i2c_uart_driver);
> +#endif
> +err_i2c:
> + uart_unregister_driver(_uart);
> + return ret;
> }
> module_init(sc16is7xx_init);
>
>
Re: [PATCH v4 1/2] Provide in-kernel headers for making it easy to extend the kernel
On 08.03.19 14:42, Joel Fernandes wrote: Hi folks, > That sounds like it could be useful. I don't see any reason off the > top why that would not be possible to add to the list of archived > files in the future. The patch allows populating the list of files > from Kbuild using ikh_file_list variable. It seems the whole thing's going into a direction where a whole own subtopic is coming up: compressed built-in filesystem. Haven't had a deeper thought about it yet, whether or not existing filesystems like squashfs, initramfs, etc are the right thing for that, or something new should be invented, but a generic mechanism for compiled-in compressed (ro) filesystems could also be interesting for very small devices, that perhaps even dont need any persistence. Some requirements coming up in mind: 1. it shall be possible to have any number of instances - possibly by separate modules. 2. it shall be possible to use an bootloader/firmware provided image (so it can serve as initrd) 2. data should stay compressed as long as possible, but uncompressed data might be cached - do decompression on-demand 3. only needs to be ro (write access could be done via unionfs+friends) 4. it shall be swappable (if swap is enabled) In that scenario, these in-kernel headers would just one consumer, I can imagine lots of others. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
[PATCH serial] sc16is7xx: missing unregister/delete driver on error in sc16is7xx_init()
Add the missing uart_unregister_driver() and i2c_del_driver() before return
from sc16is7xx_init() in the error handling case.
Signed-off-by: Mao Wenan
---
drivers/tty/serial/sc16is7xx.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c
index 268098681856..114e94f476c6 100644
--- a/drivers/tty/serial/sc16is7xx.c
+++ b/drivers/tty/serial/sc16is7xx.c
@@ -1509,7 +1509,7 @@ static int __init sc16is7xx_init(void)
ret = i2c_add_driver(_i2c_uart_driver);
if (ret < 0) {
pr_err("failed to init sc16is7xx i2c --> %d\n", ret);
- return ret;
+ goto err_i2c;
}
#endif
@@ -1517,10 +1517,18 @@ static int __init sc16is7xx_init(void)
ret = spi_register_driver(_spi_uart_driver);
if (ret < 0) {
pr_err("failed to init sc16is7xx spi --> %d\n", ret);
- return ret;
+ goto err_spi;
}
#endif
return ret;
+
+err_spi:
+#ifdef CONFIG_SERIAL_SC16IS7XX_I2C
+ i2c_del_driver(_i2c_uart_driver);
+#endif
+err_i2c:
+ uart_unregister_driver(_uart);
+ return ret;
}
module_init(sc16is7xx_init);
--
2.20.1
[PATCH serial] sc16is7xx: missing unregister/delete driver on error in sc16is7xx_init()
Add the missing uart_unregister_driver() and i2c_del_driver() before return
from sc16is7xx_init() in the error handling case.
Signed-off-by: Mao Wenan
---
drivers/tty/serial/sc16is7xx.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c
index 268098681856..114e94f476c6 100644
--- a/drivers/tty/serial/sc16is7xx.c
+++ b/drivers/tty/serial/sc16is7xx.c
@@ -1509,7 +1509,7 @@ static int __init sc16is7xx_init(void)
ret = i2c_add_driver(_i2c_uart_driver);
if (ret < 0) {
pr_err("failed to init sc16is7xx i2c --> %d\n", ret);
- return ret;
+ goto err_i2c;
}
#endif
@@ -1517,10 +1517,18 @@ static int __init sc16is7xx_init(void)
ret = spi_register_driver(_spi_uart_driver);
if (ret < 0) {
pr_err("failed to init sc16is7xx spi --> %d\n", ret);
- return ret;
+ goto err_spi;
}
#endif
return ret;
+
+err_spi:
+#ifdef CONFIG_SERIAL_SC16IS7XX_I2C
+ i2c_del_driver(_i2c_uart_driver);
+#endif
+err_i2c:
+ uart_unregister_driver(_uart);
+ return ret;
}
module_init(sc16is7xx_init);
--
2.20.1
Re: [PATCH v4 05/15] perf tools report: Parse time quantum
Em Fri, Mar 08, 2019 at 10:45:32AM -0300, Arnaldo Carvalho de Melo escreveu: > Em Tue, Mar 05, 2019 at 06:47:48AM -0800, Andi Kleen escreveu: > > From: Andi Kleen > > + if (*end == 0) > > + return 0; > > We have tools/include/linux/time64.h, just like the kernel, so please > use: > > #include I'll do that this time. - Arnado
Re: [PATCH v4 10/15] perf tools: Add utility function to print ns time stamps
Em Tue, Mar 05, 2019 at 06:47:53AM -0800, Andi Kleen escreveu: > From: Andi Kleen > > Add a utility function to print nanosecond timestamps. Applied. - Arnaldo
[PATCH 08/11] perf session: Add path to reader object
Adding path to reader object, so we can display file
the processing fails for (string in [] brackets).
$ perf report --stdio
0x5e0 [perf.data/data.3] [0xa200]: failed to process type: -1577027574
Link: http://lkml.kernel.org/n/tip-4bjnoy4sln7adqtd3505q...@git.kernel.org
Signed-off-by: Jiri Olsa
---
tools/perf/util/session.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index b55f4281b1da..33f363caaa7c 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -1858,6 +1858,7 @@ struct reader {
u64 data_size;
u64 data_offset;
reader_cb_t process;
+ char*path;
};
static int
@@ -1872,6 +1873,8 @@ reader__process_events(struct reader *rd, struct
perf_session *session,
union perf_event *event;
s64 skip;
+ pr_debug("reader processing %s\n", rd->path);
+
page_offset = page_size * (rd->data_offset / page_size);
file_offset = page_offset;
head = rd->data_offset - page_offset;
@@ -1927,8 +1930,8 @@ reader__process_events(struct reader *rd, struct
perf_session *session,
if (size < sizeof(struct perf_event_header) ||
(skip = rd->process(session, event, file_pos)) < 0) {
- pr_err("%#" PRIx64 " [%#x]: failed to process type: %d\n",
- file_offset + head, event->header.size,
+ pr_err("%#" PRIx64 " [%s] [%#x]: failed to process type: %d\n",
+ file_offset + head, rd->path, event->header.size,
event->header.type);
err = -EINVAL;
goto out;
@@ -1966,6 +1969,7 @@ static int __perf_session__process_events(struct
perf_session *session)
.data_size = session->header.data_size,
.data_offset= session->header.data_offset,
.process= process_simple,
+ .path = session->data->file.path,
};
struct ordered_events *oe = >ordered_events;
struct perf_tool *tool = session->tool;
@@ -2040,6 +2044,7 @@ static int __perf_session__process_dir_events(struct
perf_session *session)
.data_size = session->header.data_size,
.data_offset= session->header.data_offset,
.process= process_simple,
+ .path = session->data->file.path,
};
int i, ret = 0;
struct ui_progress prog;
@@ -2066,6 +2071,7 @@ static int __perf_session__process_dir_events(struct
perf_session *session)
.data_size = file->size,
.data_offset= 0,
.process= process_index,
+ .path = file->path,
};
ret = reader__process_events(, session, );
--
2.17.2
Re: [PATCH v4 07/15] perf tools report: Use less for scripts output
Em Tue, Mar 05, 2019 at 06:47:50AM -0800, Andi Kleen escreveu:
> From: Andi Kleen
>
> The UI viewer for scripts output has a lot of limitations: limited size,
> no search or save function, slow, and various other issues.
>
> Just use 'less' to display directly on the terminal instead.
I'm ok with this, CCing Feng tho since he contributed this browser, to
let him know.
- Arnaldo
> This won't work in gtk mode, but gtk doesn't support these
> context menus anyways. If that is ever done could use an terminal
> for the output.
>
> Signed-off-by: Andi Kleen
>
> ---
>
> v2:
> Remove some unneeded headers
> ---
> tools/perf/ui/browsers/scripts.c | 130 ---
> 1 file changed, 17 insertions(+), 113 deletions(-)
>
> diff --git a/tools/perf/ui/browsers/scripts.c
> b/tools/perf/ui/browsers/scripts.c
> index 90a32ac69e76..7f36630694bf 100644
> --- a/tools/perf/ui/browsers/scripts.c
> +++ b/tools/perf/ui/browsers/scripts.c
> @@ -1,35 +1,12 @@
> // SPDX-License-Identifier: GPL-2.0
> -#include
> -#include
> -#include
> -#include
> #include "../../util/sort.h"
> #include "../../util/util.h"
> #include "../../util/hist.h"
> #include "../../util/debug.h"
> #include "../../util/symbol.h"
> #include "../browser.h"
> -#include "../helpline.h"
> #include "../libslang.h"
>
> -/* 2048 lines should be enough for a script output */
> -#define MAX_LINES2048
> -
> -/* 160 bytes for one output line */
> -#define AVERAGE_LINE_LEN 160
> -
> -struct script_line {
> - struct list_head node;
> - char line[AVERAGE_LINE_LEN];
> -};
> -
> -struct perf_script_browser {
> - struct ui_browser b;
> - struct list_head entries;
> - const char *script_name;
> - int nr_lines;
> -};
> -
> #define SCRIPT_NAMELEN 128
> #define SCRIPT_MAX_NO64
> /*
> @@ -73,69 +50,29 @@ static int list_scripts(char *script_name)
> return ret;
> }
>
> -static void script_browser__write(struct ui_browser *browser,
> -void *entry, int row)
> +static void run_script(char *cmd)
> {
> - struct script_line *sline = list_entry(entry, struct script_line, node);
> - bool current_entry = ui_browser__is_current_entry(browser, row);
> -
> - ui_browser__set_color(browser, current_entry ? HE_COLORSET_SELECTED :
> -HE_COLORSET_NORMAL);
> -
> - ui_browser__write_nstring(browser, sline->line, browser->width);
> + pr_debug("Running %s\n", cmd);
> + SLang_reset_tty();
> + if (system(cmd) < 0)
> + pr_warning("Cannot run %s\n", cmd);
> + /*
> + * SLang doesn't seem to reset the whole terminal, so be more
> + * forceful to get back to the original state.
> + */
> + printf("\033[c\033[H\033[J");
> + fflush(stdout);
> + SLang_init_tty(0, 0, 0);
> + SLsmg_refresh();
> }
>
> -static int script_browser__run(struct perf_script_browser *browser)
> -{
> - int key;
> -
> - if (ui_browser__show(>b, browser->script_name,
> - "Press ESC to exit") < 0)
> - return -1;
> -
> - while (1) {
> - key = ui_browser__run(>b, 0);
> -
> - /* We can add some special key handling here if needed */
> - break;
> - }
> -
> - ui_browser__hide(>b);
> - return key;
> -}
> -
> -
> int script_browse(const char *script_opt)
> {
> char cmd[SCRIPT_FULLPATH_LEN*2], script_name[SCRIPT_FULLPATH_LEN];
> - char *line = NULL;
> - size_t len = 0;
> - ssize_t retlen;
> - int ret = -1, nr_entries = 0;
> - FILE *fp;
> - void *buf;
> - struct script_line *sline;
> -
> - struct perf_script_browser script = {
> - .b = {
> - .refresh= ui_browser__list_head_refresh,
> - .seek = ui_browser__list_head_seek,
> - .write = script_browser__write,
> - },
> - .script_name = script_name,
> - };
> -
> - INIT_LIST_HEAD();
> -
> - /* Save each line of the output in one struct script_line object. */
> - buf = zalloc((sizeof(*sline)) * MAX_LINES);
> - if (!buf)
> - return -1;
> - sline = buf;
>
> memset(script_name, 0, SCRIPT_FULLPATH_LEN);
> if (list_scripts(script_name))
> - goto exit;
> + return -1;
>
> sprintf(cmd, "perf script -s %s ", script_name);
>
> @@ -147,42 +84,9 @@ int script_browse(const char *script_opt)
> strcat(cmd, input_name);
> }
>
> - strcat(cmd, " 2>&1");
> -
> - fp = popen(cmd, "r");
> - if (!fp)
> - goto exit;
> -
> - while ((retlen = getline(, , fp)) != -1) {
> - strncpy(sline->line, line, AVERAGE_LINE_LEN);
> -
> - /* If one output line is very large, just cut it short */
> - if (retlen >= AVERAGE_LINE_LEN) {
> -
[PATCH 06/11] perf session: Add process callback to reader object
Adding callback function to reader object so
callers can process data in different ways.
Link: http://lkml.kernel.org/n/tip-8g1islzz6xkl36tz0z1nk...@git.kernel.org
Signed-off-by: Jiri Olsa
---
tools/perf/util/session.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index de777bdc0ed3..0ec34227bd60 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -1847,10 +1847,17 @@ fetch_mmaped_event(struct perf_session *session,
#define NUM_MMAPS 128
#endif
+struct reader;
+
+typedef s64 (*reader_cb_t)(struct perf_session *session,
+ union perf_event *event,
+ u64 file_offset);
+
struct reader {
- int fd;
- u64 data_size;
- u64 data_offset;
+ int fd;
+ u64 data_size;
+ u64 data_offset;
+ reader_cb_t process;
};
static int
@@ -1921,7 +1928,7 @@ reader__process_events(struct reader *rd, struct
perf_session *session,
size = event->header.size;
if (size < sizeof(struct perf_event_header) ||
- (skip = perf_session__process_event(session, event, file_pos)) < 0)
{
+ (skip = rd->process(session, event, file_pos)) < 0) {
pr_err("%#" PRIx64 " [%#x]: failed to process type: %d\n",
file_offset + head, event->header.size,
event->header.type);
@@ -1947,12 +1954,20 @@ reader__process_events(struct reader *rd, struct
perf_session *session,
return err;
}
+static s64 process_simple(struct perf_session *session,
+ union perf_event *event,
+ u64 file_offset)
+{
+ return perf_session__process_event(session, event, file_offset);
+}
+
static int __perf_session__process_events(struct perf_session *session)
{
struct reader rd = {
.fd = perf_data__fd(session->data),
.data_size = session->header.data_size,
.data_offset= session->header.data_offset,
+ .process= process_simple,
};
struct ordered_events *oe = >ordered_events;
struct perf_tool *tool = session->tool;
--
2.17.2
[PATCH 09/11] perf record: Add --dir option to store data in directory
Adding --dir option to store data in directory. It's next
step for multiple threads in record. It's now possible to
make directory data via --dir option, like:
$ perf record --dir perf bench sched messaging
$ ls -l perf.data
total 344
-rw---. 1 jolsa jolsa 43864 Jan 20 22:26 data.0
-rw---. 1 jolsa jolsa 30464 Jan 20 22:26 data.1
-rw---. 1 jolsa jolsa 53816 Jan 20 22:26 data.2
-rw---. 1 jolsa jolsa 30368 Jan 20 22:26 data.3
-rw---. 1 jolsa jolsa 40088 Jan 20 22:26 data.4
-rw---. 1 jolsa jolsa 42592 Jan 20 22:26 data.5
-rw---. 1 jolsa jolsa 56136 Jan 20 22:26 data.6
-rw---. 1 jolsa jolsa 25992 Jan 20 22:26 data.7
-rw---. 1 jolsa jolsa 8832 Jan 20 22:26 header
There's a data file created for every cpu and it's storing
data for those cpu maps.
It's possible to transform directory data into standard
perf.data file via following inject command:
$ perf inject -o perf.data.file -i perf.data
The --dir option enabled DIR_FORMAT feature to be stored
in header file to indicate the directory layout.
Don't allow to use --dir with --aio yet. It needs
to be investigated first.
Link: http://lkml.kernel.org/n/tip-0kjm8wpglzu2tm18tpagf...@git.kernel.org
Signed-off-by: Jiri Olsa
---
tools/perf/Documentation/perf-record.txt | 3 +
tools/perf/builtin-record.c | 80 ++--
tools/perf/util/mmap.h | 23 +++
3 files changed, 90 insertions(+), 16 deletions(-)
diff --git a/tools/perf/Documentation/perf-record.txt
b/tools/perf/Documentation/perf-record.txt
index 8f0c2be34848..445b7a4eb130 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -524,6 +524,9 @@ config terms. For example: 'cycles/overwrite/' and
'instructions/no-overwrite/'.
Implies --tail-synthesize.
+--dir::
+Store data into directory with one data file for cpu.
+
SEE ALSO
linkperf:perf-stat[1], linkperf:perf-list[1]
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index a468d882e74f..26981be13aa0 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -112,10 +112,13 @@ static bool switch_output_time(struct record *rec)
trigger_is_ready(_output_trigger);
}
-static int record__write(struct record *rec, struct perf_mmap *map
__maybe_unused,
+static int record__write(struct record *rec, struct perf_mmap *map,
void *bf, size_t size)
{
- struct perf_data_file *file = >session->data->file;
+ struct perf_data_file *file = >data.file;
+
+ if (map && map->file)
+ file = map->file;
if (perf_data_file__write(file, bf, size) < 0) {
pr_err("failed to write perf data, error: %m\n");
@@ -124,6 +127,15 @@ static int record__write(struct record *rec, struct
perf_mmap *map __maybe_unuse
rec->bytes_written += size;
+ /*
+* Update header file size manualy, data files size are
+* ok to be updated by stat command, but header files
+* contains more stuff, so we need to track data size
+* manualy.
+*/
+ if (file == >data.file)
+ rec->session->header.data_size += size;
+
if (switch_output_size(rec))
trigger_hit(_output_trigger);
@@ -247,6 +259,7 @@ static int record__aio_pushfn(void *to, struct aiocb
*cblock, void *bf, size_t s
ret = record__aio_write(cblock, trace_fd, bf, size, off);
if (!ret) {
rec->bytes_written += size;
+ rec->session->header.data_size += size;
if (switch_output_size(rec))
trigger_hit(_output_trigger);
}
@@ -564,6 +577,25 @@ static int record__mmap_evlist(struct record *rec,
return 0;
}
+static int record__mmap_dir_data(struct record *rec)
+{
+ struct perf_evlist *evlist = rec->evlist;
+ struct perf_data *data = >data;
+ int i, ret, nr = evlist->nr_mmaps;
+
+ ret = perf_data__create_dir(data, nr);
+ if (ret)
+ return ret;
+
+ for (i = 0; i < nr; i++) {
+ struct perf_mmap *map = >mmap[i];
+
+ map->file = >dir.files[i];
+ }
+
+ return 0;
+}
+
static int record__mmap(struct record *rec)
{
return record__mmap_evlist(rec, rec->evlist);
@@ -793,8 +825,12 @@ static int record__mmap_read_evlist(struct record *rec,
struct perf_evlist *evli
/*
* Mark the round finished in case we wrote
* at least one event.
+*
+* No need for round events in directory mode,
+* because per-cpu files/maps have sorted data
+* from kernel.
*/
- if (bytes_written != rec->bytes_written)
+ if (!perf_data__is_dir(>data) && bytes_written !=
rec->bytes_written)
rc = record__write(rec, NULL, _round_event,
sizeof(finished_round_event));
if (overwrite)
@@ -837,7
[PATCH 10/11] perf record: Add --output-dir option to store data in directory
Adding --output-dir option to mimic -o and --dir options.
following commands do the same:
$ perf record -o perf.dir.data --dir ...
$ perf record --output-dir perf.dir.data ...
User cannot use both -o and output-dir together,
error is displayed.
Link: http://lkml.kernel.org/n/tip-76ldd2ss6vjvlnjgwy7wx...@git.kernel.org
Signed-off-by: Jiri Olsa
---
tools/lib/subcmd/parse-options.h | 4
tools/perf/Documentation/perf-record.txt | 3 +++
tools/perf/builtin-record.c | 13 +++--
3 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/tools/lib/subcmd/parse-options.h b/tools/lib/subcmd/parse-options.h
index af9def589863..8a3be77a3346 100644
--- a/tools/lib/subcmd/parse-options.h
+++ b/tools/lib/subcmd/parse-options.h
@@ -146,6 +146,10 @@ struct option {
.value = check_vtype(v, const char **), .argh = (a), .help = (h), \
.flags = PARSE_OPT_OPTARG, .defval = (intptr_t)(d), \
.set = check_vtype(os, bool *)}
+#define OPT_STRING_SET(s, l, v, os, a, h) \
+ { .type = OPTION_STRING, .short_name = (s), .long_name = (l), \
+ .value = check_vtype(v, const char **), .argh = (a), .help = (h), \
+ .set = check_vtype(os, bool *)}
#define OPT_STRING_NOEMPTY(s, l, v, a, h) { .type = OPTION_STRING,
.short_name = (s), .long_name = (l), .value = check_vtype(v, const char **),
.argh = (a), .help = (h), .flags = PARSE_OPT_NOEMPTY}
#define OPT_DATE(s, l, v, h) \
{ .type = OPTION_CALLBACK, .short_name = (s), .long_name = (l), .value
= (v), .argh = "time", .help = (h), .callback = parse_opt_approxidate_cb }
diff --git a/tools/perf/Documentation/perf-record.txt
b/tools/perf/Documentation/perf-record.txt
index 445b7a4eb130..aac609887fb7 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -527,6 +527,9 @@ Implies --tail-synthesize.
--dir::
Store data into directory with one data file for cpu.
+--output-dir::
+Same as --dir option, can't be used together with -o option.
+
SEE ALSO
linkperf:perf-stat[1], linkperf:perf-list[1]
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 26981be13aa0..115316e94b34 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -80,6 +80,7 @@ struct record {
boolbuildid_all;
booltimestamp_filename;
booltimestamp_boundary;
+ booloutput_is_file;
struct switch_outputswitch_output;
unsigned long long samples;
cpu_set_t affinity_mask;
@@ -1921,8 +1922,10 @@ static struct option __record_options[] = {
OPT_STRING('C', "cpu", _list, "cpu",
"list of cpus to monitor"),
OPT_U64('c', "count", _interval, "event period to
sample"),
- OPT_STRING('o', "output", , "file",
- "output file name"),
+ OPT_STRING_SET('o', "output", , _is_file,
+ "file", "output file name"),
+ OPT_STRING_SET(0, "output-dir", , _dir,
+ "file", "output directory name"),
OPT_BOOLEAN_SET('i', "no-inherit", _inherit,
_inherit_set,
"child tasks do not inherit counters"),
@@ -2101,6 +2104,12 @@ int cmd_record(int argc, const char **argv)
"cgroup monitoring only available in system-wide mode");
}
+
+ if (perf_data__is_dir(>data) && record.output_is_file) {
+ ui__error("cannot use both -o and --output-dir\n");
+ return -EINVAL;
+ }
+
if (rec->opts.record_switch_events &&
!perf_can_record_switch_events()) {
ui__error("kernel does not support recording context switch
events\n");
--
2.17.2
[PATCH 11/11] perf record: Describe perf.data directory format
Adding perf.data-directory-format.txt to describe the
directory data layout.
Link: http://lkml.kernel.org/n/tip-1c8u1thx63v2ldwfdas4x...@git.kernel.org
Signed-off-by: Jiri Olsa
---
.../perf.data-directory-format.txt| 54 +++
1 file changed, 54 insertions(+)
create mode 100644 tools/perf/Documentation/perf.data-directory-format.txt
diff --git a/tools/perf/Documentation/perf.data-directory-format.txt
b/tools/perf/Documentation/perf.data-directory-format.txt
new file mode 100644
index ..bbd6d31b10c8
--- /dev/null
+++ b/tools/perf/Documentation/perf.data-directory-format.txt
@@ -0,0 +1,54 @@
+perf.data directory format
+
+DISCLAIMER This is not ABI yet and is subject to possible change
+ in following versions of perf. We will remove this
+ disclaimer once the directory format soaks in.
+
+
+This document describes the on-disk perf.data format, generated
+by perf record with --dir option and consumed by the other perf
+tools.
+
+The directory perf.data is created by perf record command by
+using the --dir option:
+
+ $ perf record --dir perf bench sched messaging
+ $ ls -l perf.data
+ total 344
+ -rw---. 1 jolsa jolsa 43864 Jan 20 22:26 data.0
+ -rw---. 1 jolsa jolsa 30464 Jan 20 22:26 data.1
+ -rw---. 1 jolsa jolsa 53816 Jan 20 22:26 data.2
+ -rw---. 1 jolsa jolsa 30368 Jan 20 22:26 data.3
+ -rw---. 1 jolsa jolsa 40088 Jan 20 22:26 data.4
+ -rw---. 1 jolsa jolsa 42592 Jan 20 22:26 data.5
+ -rw---. 1 jolsa jolsa 56136 Jan 20 22:26 data.6
+ -rw---. 1 jolsa jolsa 25992 Jan 20 22:26 data.7
+ -rw---. 1 jolsa jolsa 8832 Jan 20 22:26 header
+
+The header file keeps the standard perf.data file header,
+and the data.* files keep data.
+
+header file
+---
+The header file following the standard format describe in
+Documentation/perf.data-file-format doc. Including its data
+portion that is used to store manually synthesized events.
+
+data file
+-
+The data files layout is described by HEADER_DIR_FORMAT feature.
+Currently it holds only version number (1):
+
+ HEADER_DIR_FORMAT = 24
+
+ struct {
+ uint64_t version;
+ }
+
+The current only only version value 1 means that data files:
+ - follow the 'data.*' format
+ - contain raw events data in standard perf format as read
+from kernel (and need to be sorted)
+
+Future versions are expected to describe different data files
+layout according to special needs.
--
2.17.2
[PATCH 07/11] perf session: Add __perf_session__process_dir_events function
Adding __perf_session__process_dir_events function
to process events over the directory data.
All directory events are pushed into sessions ordered
data and flushed for processing.
Link: http://lkml.kernel.org/n/tip-n3zl0wo3z18tatv5x7epm...@git.kernel.org
Signed-off-by: Jiri Olsa
---
tools/perf/util/session.c | 88 ++-
1 file changed, 86 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 0ec34227bd60..b55f4281b1da 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -1876,8 +1876,6 @@ reader__process_events(struct reader *rd, struct
perf_session *session,
file_offset = page_offset;
head = rd->data_offset - page_offset;
- ui_progress__init_size(prog, data_size, "Processing events...");
-
data_size += rd->data_offset;
mmap_size = MMAP_SIZE;
@@ -2006,6 +2004,89 @@ static int __perf_session__process_events(struct
perf_session *session)
return err;
}
+static s64 process_index(struct perf_session *session,
+union perf_event *event,
+u64 file_offset)
+{
+ struct perf_evlist *evlist = session->evlist;
+ u64 timestamp;
+ s64 ret;
+
+ if (session->header.needs_swap)
+ event_swap(event, perf_evlist__sample_id_all(evlist));
+
+ if (event->header.type >= PERF_RECORD_HEADER_MAX)
+ return -EINVAL;
+
+ events_stats__inc(>stats, event->header.type);
+
+ if (event->header.type >= PERF_RECORD_USER_TYPE_START)
+ return perf_session__process_user_event(session, event,
file_offset);
+
+ ret = perf_evlist__parse_sample_timestamp(evlist, event, );
+ if (ret)
+ return ret;
+
+ return ordered_events__queue(>ordered_events, event,
+timestamp, file_offset);
+}
+
+static int __perf_session__process_dir_events(struct perf_session *session)
+{
+ struct perf_data *data = session->data;
+ struct perf_tool *tool = session->tool;
+ struct reader rd = {
+ .fd = perf_data__fd(session->data),
+ .data_size = session->header.data_size,
+ .data_offset= session->header.data_offset,
+ .process= process_simple,
+ };
+ int i, ret = 0;
+ struct ui_progress prog;
+ u64 total_size = perf_data__size(session->data);
+
+ perf_tool__fill_defaults(tool);
+
+ ui_progress__init_size(, total_size, "Processing events...");
+
+ /* Read data from the header file.. */
+ ret = reader__process_events(, session, );
+ if (ret)
+ goto out_err;
+
+ /* ... and continue with data files. */
+ for (i = 0; i < data->dir.nr ; i++) {
+ struct perf_data_file *file = >dir.files[i];
+
+ if (file->size == 0)
+ continue;
+
+ rd = (struct reader) {
+ .fd = file->fd,
+ .data_size = file->size,
+ .data_offset= 0,
+ .process= process_index,
+ };
+
+ ret = reader__process_events(, session, );
+ if (ret)
+ goto out_err;
+ }
+
+ ret = ordered_events__flush(>ordered_events, OE_FLUSH__FINAL);
+
+out_err:
+ if (!tool->no_warn)
+ perf_session__warn_about_errors(session);
+
+ /*
+* We may switching perf.data output, make ordered_events
+* reusable.
+*/
+ ordered_events__reinit(>ordered_events);
+ return ret;
+}
+
int perf_session__process_events(struct perf_session *session)
{
if (perf_session__register_idle_thread(session) < 0)
@@ -2014,6 +2095,9 @@ int perf_session__process_events(struct perf_session
*session)
if (perf_data__is_pipe(session->data))
return __perf_session__process_pipe_events(session);
+ if (perf_data__is_dir(session->data))
+ return __perf_session__process_dir_events(session);
+
return __perf_session__process_events(session);
}
--
2.17.2
[PATCH 01/11] perf data: Add directory support
Adding support to have directory as perf.data.
The caller needs to set 'struct perf_data::is_dir flag
and the path will be treated as directory.
The 'struct perf_data::file' is initialized and open
as 'path/header' file.
Adding check to direcory interface functions to check
on is_dir flag.
Link: http://lkml.kernel.org/n/tip-pvot1aywiem9epgqpfi1a...@git.kernel.org
Signed-off-by: Jiri Olsa
---
tools/perf/util/data.c| 49 ++-
tools/perf/util/data.h| 6 +
tools/perf/util/session.c | 4
3 files changed, 58 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/data.c b/tools/perf/util/data.c
index e098e189f93e..e28fd0fde5e0 100644
--- a/tools/perf/util/data.c
+++ b/tools/perf/util/data.c
@@ -34,6 +34,9 @@ int perf_data__create_dir(struct perf_data *data, int nr)
struct perf_data_file *files = NULL;
int i, ret = -1;
+ if (WARN_ON(!data->is_dir))
+ return -EINVAL;
+
files = zalloc(nr * sizeof(*files));
if (!files)
return -ENOMEM;
@@ -69,6 +72,9 @@ int perf_data__open_dir(struct perf_data *data)
DIR *dir;
int nr = 0;
+ if (WARN_ON(!data->is_dir))
+ return -EINVAL;
+
dir = opendir(data->path);
if (!dir)
return -EINVAL;
@@ -173,6 +179,16 @@ static int check_backup(struct perf_data *data)
return 0;
}
+static bool is_dir(struct perf_data *data)
+{
+ struct stat st;
+
+ if (stat(data->path, ))
+ return false;
+
+ return (st.st_mode & S_IFMT) == S_IFDIR;
+}
+
static int open_file_read(struct perf_data *data)
{
struct stat st;
@@ -254,6 +270,30 @@ static int open_file_dup(struct perf_data *data)
return open_file(data);
}
+static int open_dir(struct perf_data *data)
+{
+ int ret;
+
+ /*
+* So far we open only the header, so we
+* can read the data version and layout.
+*/
+ if (asprintf(>file.path, "%s/header", data->path) < 0)
+ return -ENOMEM;
+
+ if (perf_data__is_write(data) &&
+ mkdir(data->path, S_IRWXU) < 0)
+ return -1;
+
+ ret = open_file(data);
+
+ /* Cleanup whatever we managed to create so far. */
+ if (ret && perf_data__is_write(data))
+ rm_rf_perf_data(data->path);
+
+ return ret;
+}
+
int perf_data__open(struct perf_data *data)
{
if (check_pipe(data))
@@ -265,11 +305,18 @@ int perf_data__open(struct perf_data *data)
if (check_backup(data))
return -1;
- return open_file_dup(data);
+ if (perf_data__is_read(data))
+ data->is_dir = is_dir(data);
+
+ return perf_data__is_dir(data) ?
+ open_dir(data) : open_file_dup(data);
}
void perf_data__close(struct perf_data *data)
{
+ if (perf_data__is_dir(data))
+ perf_data__close_dir(data);
+
zfree(>file.path);
close(data->file.fd);
}
diff --git a/tools/perf/util/data.h b/tools/perf/util/data.h
index 14b47be2bd69..06aefeda311f 100644
--- a/tools/perf/util/data.h
+++ b/tools/perf/util/data.h
@@ -19,6 +19,7 @@ struct perf_data {
const char *path;
struct perf_data_filefile;
bool is_pipe;
+ bool is_dir;
bool force;
enum perf_data_mode mode;
@@ -43,6 +44,11 @@ static inline int perf_data__is_pipe(struct perf_data *data)
return data->is_pipe;
}
+static inline bool perf_data__is_dir(struct perf_data *data)
+{
+ return data->is_dir;
+}
+
static inline int perf_data__fd(struct perf_data *data)
{
return data->file.fd;
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index db643f3c2b95..de777bdc0ed3 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -152,6 +152,10 @@ struct perf_session *perf_session__new(struct perf_data
*data,
}
perf_evlist__init_trace_event_sample_raw(session->evlist);
+
+ /* Open the directory data. */
+ if (data->is_dir && perf_data__open_dir(data))
+ goto out_delete;
}
} else {
session->machines.host.env = _env;
--
2.17.2
