* Re: [PATCH 2/4] ceph: consider file's last read/write when calculating wanted caps
From: Yan, Zheng @ 2020-02-20 14:53 UTC (permalink / raw)
To: Jeff Layton; +Cc: Yan, Zheng, ceph-devel
In-Reply-To: <2e6b793f2c6de6f4a8b075f9415460cb575d95df.camel@kernel.org>
On Thu, Feb 20, 2020 at 10:18 PM Jeff Layton <jlayton@kernel.org> wrote:
>
> On Thu, 2020-02-20 at 20:26 +0800, Yan, Zheng wrote:
> > When getting caps for read/write, update corresponding file's last
> > read/write. If a file hasn't been read/write for 'caps_wanted_delay_max'
> > seconds, ignore the file when calculating wanted caps.
> >
>
> Please explain in the changelog how the new info is to be stored, given
> that it is quite complex.
>
> > Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
> > ---
> > fs/ceph/caps.c | 149 ++++++++++++++++++++++++-----------
> > fs/ceph/file.c | 23 +++---
> > fs/ceph/inode.c | 15 +++-
> > fs/ceph/ioctl.c | 4 +-
> > fs/ceph/super.h | 16 +++-
> > include/linux/ceph/ceph_fs.h | 1 +
> > 6 files changed, 145 insertions(+), 63 deletions(-)
> >
> > diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c
> > index 293920d013ff..ccdc47bd7cf0 100644
> > --- a/fs/ceph/caps.c
> > +++ b/fs/ceph/caps.c
> > @@ -971,18 +971,44 @@ int __ceph_caps_used(struct ceph_inode_info *ci)
> > return used;
> > }
> >
> > +#define FMODE_WAIT_BIAS 1000
> > +
> > /*
> > * wanted, by virtue of open file modes
> > */
> > int __ceph_caps_file_wanted(struct ceph_inode_info *ci)
> > {
> > + struct ceph_mount_options *opt =
> > + ceph_inode_to_client(&ci->vfs_inode)->mount_options;
> > + unsigned long used_cutoff =
> > + round_jiffies(jiffies - opt->caps_wanted_delay_max * HZ);
> > + unsigned long idle_cutoff =
> > + round_jiffies(jiffies - opt->caps_wanted_delay_min * HZ);
> > int i, bits = 0;
> > +
> > for (i = 0; i < CEPH_FILE_MODE_BITS; i++) {
> > - if (ci->i_nr_by_mode[i])
> > + if (ci->i_file_by_mode[i].nr >= FMODE_WAIT_BIAS) {
> > + /* there are cap waiters or lots of open files */
> > bits |= 1 << i;
> > + } else if (ci->i_file_by_mode[i].nr > 0) {
> > + if (i == CEPH_FILE_MODE_PIN ||
> > + time_after(ci->i_file_by_mode[i].last_used,
> > + used_cutoff))
> > + bits |= 1 << i;
> > + } else if ((ci->i_file_by_mode[i].last_used & 1)) {
> > + if (time_after(ci->i_file_by_mode[i].last_used,
> > + idle_cutoff)) {
> > + bits |= 1 << i;
> > + } else {
> > + ci->i_file_by_mode[i].last_used &= ~1UL;
> > + }
> > + }
> > }
> > if (bits == 0)
> > return 0;
> > + if (bits == 1 && !S_ISDIR(ci->vfs_inode.i_mode))
> > + return 0;
> > +
> > return ceph_caps_for_mode(bits >> 1);
> > }
> >
> > @@ -1021,14 +1047,6 @@ int __ceph_caps_mds_wanted(struct ceph_inode_info *ci, bool check)
> > return mds_wanted;
> > }
> >
> > -/*
> > - * called under i_ceph_lock
> > - */
> > -static int __ceph_is_single_caps(struct ceph_inode_info *ci)
> > -{
> > - return rb_first(&ci->i_caps) == rb_last(&ci->i_caps);
> > -}
> > -
> > int ceph_is_any_caps(struct inode *inode)
> > {
> > struct ceph_inode_info *ci = ceph_inode(inode);
> > @@ -1856,10 +1874,6 @@ void ceph_check_caps(struct ceph_inode_info *ci, int flags,
> > if (ci->i_ceph_flags & CEPH_I_FLUSH)
> > flags |= CHECK_CAPS_FLUSH;
> >
> > - if (!(flags & CHECK_CAPS_AUTHONLY) ||
> > - (ci->i_auth_cap && __ceph_is_single_caps(ci)))
> > - __cap_delay_cancel(mdsc, ci);
> > -
> > goto retry_locked;
> > retry:
> > spin_lock(&ci->i_ceph_lock);
> > @@ -2081,9 +2095,16 @@ void ceph_check_caps(struct ceph_inode_info *ci, int flags,
> > goto retry; /* retake i_ceph_lock and restart our cap scan. */
> > }
> >
> > - /* Reschedule delayed caps release if we delayed anything */
> > - if (delayed)
> > - __cap_delay_requeue(mdsc, ci, false);
> > + if (list_empty(&ci->i_cap_delay_list)) {
> > + if (delayed) {
> > + /* Reschedule delayed caps release if we delayed anything */
> > + __cap_delay_requeue(mdsc, ci, false);
> > + } else if ((file_wanted & ~CEPH_CAP_PIN) &&
> > + !(used & (CEPH_CAP_FILE_RD | CEPH_CAP_ANY_FILE_WR))) {
> > + /* periodically re-calculate caps wanted by open files */
> > + __cap_delay_requeue(mdsc, ci, true);
> > + }
> > + }
> >
> > spin_unlock(&ci->i_ceph_lock);
> >
> > @@ -2549,8 +2570,9 @@ static void __take_cap_refs(struct ceph_inode_info *ci, int got,
> > * FIXME: how does a 0 return differ from -EAGAIN?
> > */
> > enum {
> > - NON_BLOCKING = 1,
> > - CHECK_FILELOCK = 2,
> > + /* first 8 bits are reserved for CEPH_FILE_MODE_FOO */
> > + NON_BLOCKING = (1 << 8),
> > + CHECK_FILELOCK = (1 << 9),
> > };
> >
> > static int try_get_cap_refs(struct inode *inode, int need, int want,
> > @@ -2560,7 +2582,6 @@ static int try_get_cap_refs(struct inode *inode, int need, int want,
> > struct ceph_mds_client *mdsc = ceph_inode_to_client(inode)->mdsc;
> > int ret = 0;
> > int have, implemented;
> > - int file_wanted;
> > bool snap_rwsem_locked = false;
> >
> > dout("get_cap_refs %p need %s want %s\n", inode,
> > @@ -2576,15 +2597,6 @@ static int try_get_cap_refs(struct inode *inode, int need, int want,
> > goto out_unlock;
> > }
> >
> > - /* make sure file is actually open */
> > - file_wanted = __ceph_caps_file_wanted(ci);
> > - if ((file_wanted & need) != need) {
> > - dout("try_get_cap_refs need %s file_wanted %s, EBADF\n",
> > - ceph_cap_string(need), ceph_cap_string(file_wanted));
> > - ret = -EBADF;
> > - goto out_unlock;
> > - }
> > -
> > /* finish pending truncate */
> > while (ci->i_truncate_pending) {
> > spin_unlock(&ci->i_ceph_lock);
> > @@ -2692,6 +2704,9 @@ static int try_get_cap_refs(struct inode *inode, int need, int want,
> > ceph_cap_string(have), ceph_cap_string(need));
> > }
> > out_unlock:
> > +
> > + __ceph_touch_fmode(ci, mdsc, flags);
> > +
> > spin_unlock(&ci->i_ceph_lock);
> > if (snap_rwsem_locked)
> > up_read(&mdsc->snap_rwsem);
> > @@ -2729,10 +2744,22 @@ static void check_max_size(struct inode *inode, loff_t endoff)
> > ceph_check_caps(ci, CHECK_CAPS_AUTHONLY, NULL);
> > }
> >
> > +static inline int get_used_file_mode(int need, int want)
> > +{
> > + int fmode = 0;
> > + if (need & CEPH_CAP_FILE_RD)
> > + fmode |= CEPH_FILE_MODE_RD;
> > + if (need & CEPH_CAP_FILE_WR)
> > + fmode |= CEPH_FILE_MODE_WR;
> > + if (want & CEPH_CAP_FILE_LAZYIO)
> > + fmode |= CEPH_FILE_MODE_LAZY;
> > + return fmode;
> > +}
> > +
> > int ceph_try_get_caps(struct inode *inode, int need, int want,
> > bool nonblock, int *got)
> > {
> > - int ret;
> > + int ret, flags;
> >
> > BUG_ON(need & ~CEPH_CAP_FILE_RD);
> > BUG_ON(want & ~(CEPH_CAP_FILE_CACHE|CEPH_CAP_FILE_LAZYIO|CEPH_CAP_FILE_SHARED));
> > @@ -2740,8 +2767,11 @@ int ceph_try_get_caps(struct inode *inode, int need, int want,
> > if (ret < 0)
> > return ret;
> >
> > - ret = try_get_cap_refs(inode, need, want, 0,
> > - (nonblock ? NON_BLOCKING : 0), got);
> > + flags = get_used_file_mode(need, want);
> > + if (nonblock)
> > + flags |= NON_BLOCKING;
> > +
> > + ret = try_get_cap_refs(inode, need, want, 0, flags, got);
> > return ret == -EAGAIN ? 0 : ret;
> > }
> >
> > @@ -2767,11 +2797,15 @@ int ceph_get_caps(struct file *filp, int need, int want,
> > fi->filp_gen != READ_ONCE(fsc->filp_gen))
> > return -EBADF;
> >
> > + flags = get_used_file_mode(need, want);
> > +
> > while (true) {
> > if (endoff > 0)
> > check_max_size(inode, endoff);
> >
> > - flags = atomic_read(&fi->num_locks) ? CHECK_FILELOCK : 0;
> > + flags &= CEPH_FILE_MODE_MASK;
> > + if (atomic_read(&fi->num_locks))
> > + flags |= CHECK_FILELOCK;
> > _got = 0;
> > ret = try_get_cap_refs(inode, need, want, endoff,
> > flags, &_got);
> > @@ -2791,6 +2825,8 @@ int ceph_get_caps(struct file *filp, int need, int want,
> > list_add(&cw.list, &mdsc->cap_wait_list);
> > spin_unlock(&mdsc->caps_list_lock);
> >
> > + /* make sure used fmode not timeout */
> > + ceph_get_fmode(ci, flags, FMODE_WAIT_BIAS);
> > add_wait_queue(&ci->i_cap_wq, &wait);
> >
> > flags |= NON_BLOCKING;
> > @@ -2804,6 +2840,7 @@ int ceph_get_caps(struct file *filp, int need, int want,
> > }
> >
> > remove_wait_queue(&ci->i_cap_wq, &wait);
> > + ceph_put_fmode(ci, flags, FMODE_WAIT_BIAS);
> >
> > spin_lock(&mdsc->caps_list_lock);
> > list_del(&cw.list);
> > @@ -2823,7 +2860,7 @@ int ceph_get_caps(struct file *filp, int need, int want,
> > if (ret < 0) {
> > if (ret == -ESTALE) {
> > /* session was killed, try renew caps */
> > - ret = ceph_renew_caps(inode);
> > + ret = ceph_renew_caps(inode, flags);
> > if (ret == 0)
> > continue;
> > }
> > @@ -4121,13 +4158,41 @@ void ceph_flush_dirty_caps(struct ceph_mds_client *mdsc)
> > dout("flush_dirty_caps done\n");
> > }
> >
> > +void __ceph_touch_fmode(struct ceph_inode_info *ci,
> > + struct ceph_mds_client *mdsc, int fmode)
> > +{
> > + int i;
> > + int bits = (fmode << 1);
> > + unsigned long now = jiffies | 1;
> > + for (i = 1; i < CEPH_FILE_MODE_BITS; i++) {
> > + if (bits & (1 << i))
> > + ci->i_file_by_mode[i].last_used = now;
> > + }
> > +
> > + /* queue periodic check */
> > + if (bits && list_empty(&ci->i_cap_delay_list))
> > + __cap_delay_requeue(mdsc, ci, true);
> > +}
> > +
> > +void ceph_get_fmode(struct ceph_inode_info *ci, int fmode, int count)
> > +{
> > + int i;
> > + int bits = (fmode << 1) | 1;
> > + spin_lock(&ci->i_ceph_lock);
> > + for (i = 0; i < CEPH_FILE_MODE_BITS; i++) {
> > + if (bits & (1 << i))
> > + ci->i_file_by_mode[i].nr += count;
> > + }
> > + spin_unlock(&ci->i_ceph_lock);
> > +}
> > +
> > void __ceph_get_fmode(struct ceph_inode_info *ci, int fmode)
> > {
> > int i;
> > int bits = (fmode << 1) | 1;
> > for (i = 0; i < CEPH_FILE_MODE_BITS; i++) {
> > if (bits & (1 << i))
> > - ci->i_nr_by_mode[i]++;
> > + ci->i_file_by_mode[i].nr++;
> > }
> > }
> >
> > @@ -4136,26 +4201,18 @@ void __ceph_get_fmode(struct ceph_inode_info *ci, int fmode)
> > * we may need to release capabilities to the MDS (or schedule
> > * their delayed release).
> > */
> > -void ceph_put_fmode(struct ceph_inode_info *ci, int fmode)
> > +void ceph_put_fmode(struct ceph_inode_info *ci, int fmode, int count)
> > {
> > - int i, last = 0;
> > + int i;
> > int bits = (fmode << 1) | 1;
> > spin_lock(&ci->i_ceph_lock);
> > for (i = 0; i < CEPH_FILE_MODE_BITS; i++) {
> > if (bits & (1 << i)) {
> > - BUG_ON(ci->i_nr_by_mode[i] == 0);
> > - if (--ci->i_nr_by_mode[i] == 0)
> > - last++;
> > + BUG_ON(ci->i_file_by_mode[i].nr < count);
> > + ci->i_file_by_mode[i].nr -= count;
> > }
> > }
> > - dout("put_fmode %p fmode %d {%d,%d,%d,%d}\n",
> > - &ci->vfs_inode, fmode,
> > - ci->i_nr_by_mode[0], ci->i_nr_by_mode[1],
> > - ci->i_nr_by_mode[2], ci->i_nr_by_mode[3]);
> > spin_unlock(&ci->i_ceph_lock);
> > -
> > - if (last && ci->i_vino.snap == CEPH_NOSNAP)
> > - ceph_check_caps(ci, 0, NULL);
> > }
> >
> > /*
> > diff --git a/fs/ceph/file.c b/fs/ceph/file.c
> > index 7e0190b1f821..f28f420bad23 100644
> > --- a/fs/ceph/file.c
> > +++ b/fs/ceph/file.c
> > @@ -213,7 +213,7 @@ static int ceph_init_file_info(struct inode *inode, struct file *file,
> > struct ceph_dir_file_info *dfi =
> > kmem_cache_zalloc(ceph_dir_file_cachep, GFP_KERNEL);
> > if (!dfi) {
> > - ceph_put_fmode(ci, fmode); /* clean up */
> > + ceph_put_fmode(ci, fmode, 1); /* clean up */
> > return -ENOMEM;
> > }
> >
> > @@ -224,7 +224,7 @@ static int ceph_init_file_info(struct inode *inode, struct file *file,
> > } else {
> > fi = kmem_cache_zalloc(ceph_file_cachep, GFP_KERNEL);
> > if (!fi) {
> > - ceph_put_fmode(ci, fmode); /* clean up */
> > + ceph_put_fmode(ci, fmode, 1); /* clean up */
> > return -ENOMEM;
> > }
> >
> > @@ -263,7 +263,7 @@ static int ceph_init_file(struct inode *inode, struct file *file, int fmode)
> > case S_IFLNK:
> > dout("init_file %p %p 0%o (symlink)\n", inode, file,
> > inode->i_mode);
> > - ceph_put_fmode(ceph_inode(inode), fmode); /* clean up */
> > + ceph_put_fmode(ceph_inode(inode), fmode, 1); /* clean up */
> > break;
> >
> > default:
> > @@ -273,7 +273,7 @@ static int ceph_init_file(struct inode *inode, struct file *file, int fmode)
> > * we need to drop the open ref now, since we don't
> > * have .release set to ceph_release.
> > */
> > - ceph_put_fmode(ceph_inode(inode), fmode); /* clean up */
> > + ceph_put_fmode(ceph_inode(inode), fmode, 1); /* clean up */
> > BUG_ON(inode->i_fop->release == ceph_release);
> >
> > /* call the proper open fop */
> > @@ -285,14 +285,15 @@ static int ceph_init_file(struct inode *inode, struct file *file, int fmode)
> > /*
> > * try renew caps after session gets killed.
> > */
> > -int ceph_renew_caps(struct inode *inode)
> > +int ceph_renew_caps(struct inode *inode, int fmode)
> > {
> > - struct ceph_mds_client *mdsc = ceph_sb_to_client(inode->i_sb)->mdsc;
> > + struct ceph_mds_client *mdsc = ceph_inode_to_client(inode)->mdsc;
> > struct ceph_inode_info *ci = ceph_inode(inode);
> > struct ceph_mds_request *req;
> > int err, flags, wanted;
> >
> > spin_lock(&ci->i_ceph_lock);
> > + __ceph_touch_fmode(ci, mdsc, fmode);
> > wanted = __ceph_caps_file_wanted(ci);
> > if (__ceph_is_any_real_caps(ci) &&
> > (!(wanted & CEPH_CAP_ANY_WR) || ci->i_auth_cap)) {
> > @@ -405,6 +406,7 @@ int ceph_open(struct inode *inode, struct file *file)
> > } else if (ceph_snap(inode) != CEPH_NOSNAP &&
> > (ci->i_snap_caps & wanted) == wanted) {
> > __ceph_get_fmode(ci, fmode);
> > + __ceph_touch_fmode(ci, mdsc, fmode);
> > spin_unlock(&ci->i_ceph_lock);
> > return ceph_init_file(inode, file, fmode);
> > }
> > @@ -525,7 +527,7 @@ int ceph_atomic_open(struct inode *dir, struct dentry *dentry,
> > }
> > out_req:
> > if (!req->r_err && req->r_target_inode)
> > - ceph_put_fmode(ceph_inode(req->r_target_inode), req->r_fmode);
> > + ceph_put_fmode(ceph_inode(req->r_target_inode), req->r_fmode, 1);
> > ceph_mdsc_put_request(req);
> > out_ctx:
> > ceph_release_acl_sec_ctx(&as_ctx);
> > @@ -542,7 +544,7 @@ int ceph_release(struct inode *inode, struct file *file)
> > dout("release inode %p dir file %p\n", inode, file);
> > WARN_ON(!list_empty(&dfi->file_info.rw_contexts));
> >
> > - ceph_put_fmode(ci, dfi->file_info.fmode);
> > + ceph_put_fmode(ci, dfi->file_info.fmode, 1);
> >
> > if (dfi->last_readdir)
> > ceph_mdsc_put_request(dfi->last_readdir);
> > @@ -554,7 +556,8 @@ int ceph_release(struct inode *inode, struct file *file)
> > dout("release inode %p regular file %p\n", inode, file);
> > WARN_ON(!list_empty(&fi->rw_contexts));
> >
> > - ceph_put_fmode(ci, fi->fmode);
> > + ceph_put_fmode(ci, fi->fmode, 1);
> > +
> > kmem_cache_free(ceph_file_cachep, fi);
> > }
> >
> > @@ -1560,7 +1563,7 @@ static ssize_t ceph_write_iter(struct kiocb *iocb, struct iov_iter *from)
> > if (dirty)
> > __mark_inode_dirty(inode, dirty);
> > if (ceph_quota_is_max_bytes_approaching(inode, iocb->ki_pos))
> > - ceph_check_caps(ci, CHECK_CAPS_NODELAY, NULL);
> > + ceph_check_caps(ci, CHECK_CAPS_AUTHONLY, NULL);
> > }
> >
> > dout("aio_write %p %llx.%llx %llu~%u dropping cap refs on %s\n",
> > diff --git a/fs/ceph/inode.c b/fs/ceph/inode.c
> > index 094b8fc37787..b279bd8e168e 100644
> > --- a/fs/ceph/inode.c
> > +++ b/fs/ceph/inode.c
> > @@ -478,8 +478,10 @@ struct inode *ceph_alloc_inode(struct super_block *sb)
> > ci->i_head_snapc = NULL;
> > ci->i_snap_caps = 0;
> >
> > - for (i = 0; i < CEPH_FILE_MODE_BITS; i++)
> > - ci->i_nr_by_mode[i] = 0;
> > + for (i = 0; i < CEPH_FILE_MODE_BITS; i++) {
> > + ci->i_file_by_mode[i].nr = 0;
> > + ci->i_file_by_mode[i].last_used = 0;
> > + }
> >
> > mutex_init(&ci->i_truncate_mutex);
> > ci->i_truncate_seq = 0;
> > @@ -637,7 +639,7 @@ int ceph_fill_file_size(struct inode *inode, int issued,
> > if ((issued & (CEPH_CAP_FILE_CACHE|
> > CEPH_CAP_FILE_BUFFER)) ||
> > mapping_mapped(inode->i_mapping) ||
> > - __ceph_caps_file_wanted(ci)) {
> > + __ceph_is_file_opened(ci)) {
> > ci->i_truncate_pending++;
> > queue_trunc = 1;
> > }
> > @@ -1010,6 +1012,13 @@ static int fill_inode(struct inode *inode, struct page *locked_page,
> > fill_inline = true;
> > }
> >
> > + if (cap_fmode >= 0) {
> > + if (!info_caps)
> > + pr_warn("mds issued no caps on %llx.%llx\n",
> > + ceph_vinop(inode));
> > + __ceph_touch_fmode(ci, mdsc, cap_fmode);
> > + }
> > +
> > spin_unlock(&ci->i_ceph_lock);
> >
> > if (fill_inline)
> > diff --git a/fs/ceph/ioctl.c b/fs/ceph/ioctl.c
> > index c90f03beb15d..da0ee54ae5bc 100644
> > --- a/fs/ceph/ioctl.c
> > +++ b/fs/ceph/ioctl.c
> > @@ -243,11 +243,13 @@ static long ceph_ioctl_lazyio(struct file *file)
> > struct ceph_file_info *fi = file->private_data;
> > struct inode *inode = file_inode(file);
> > struct ceph_inode_info *ci = ceph_inode(inode);
> > + struct ceph_mds_client *mdsc = ceph_inode_to_client(inode)->mdsc;
> >
> > if ((fi->fmode & CEPH_FILE_MODE_LAZY) == 0) {
> > spin_lock(&ci->i_ceph_lock);
> > fi->fmode |= CEPH_FILE_MODE_LAZY;
> > - ci->i_nr_by_mode[ffs(CEPH_FILE_MODE_LAZY)]++;
> > + ci->i_file_by_mode[ffs(CEPH_FILE_MODE_LAZY)].nr++;
> > + __ceph_touch_fmode(ci, mdsc, CEPH_FILE_MODE_LAZY);
> > spin_unlock(&ci->i_ceph_lock);
> > dout("ioctl_layzio: file %p marked lazy\n", file);
> >
> > diff --git a/fs/ceph/super.h b/fs/ceph/super.h
> > index d370f89df358..029823643b8b 100644
> > --- a/fs/ceph/super.h
> > +++ b/fs/ceph/super.h
> > @@ -361,7 +361,10 @@ struct ceph_inode_info {
> > dirty|flushing caps */
> > unsigned i_snap_caps; /* cap bits for snapped files */
> >
> > - int i_nr_by_mode[CEPH_FILE_MODE_BITS]; /* open file counts */
> > + struct {
> > + int nr;
> > + unsigned long last_used;
> > + } i_file_by_mode[CEPH_FILE_MODE_BITS]; /* open file counts */
> >
>
> Ok, so we're growing ceph_inode_info by 40 bytes here (on 64-bit arch).
>
> That's quite a bit, actually, but it turns out that there are 32 bytes
> worth of holes in ceph_inode_info now. It'd be good to reorganize the
> struct for better packing before you do this, so that this at least
> won't make memory consumption too much worse.
>
> There other ways we could approach this too that would be more space
> efficient. We don't really need to keep a timestamp for each mode bit.
> All we're really interested in is what modes were used in the last time
> interval.
>
> We could keep an active and inactive set of CEPH_FILE_MODE bits (which
> are just a single byte each), and a timestamp representing the switch
> between the two.
>
> As we use the file, we'd set bits in the active mask if the timestamp is
> less than half the time interval old. If it's more than half the
> interval, copy the active mask to the inactive one and zero out the
> active mask first.
>
> When you go to check what modes have been used you can do the switch
> again first if the timestamp is too old. To see what bits were actually
> used, you just logically or the active and inactive sets together.
>
> That would take a lot less space per inode.
The problem is there is no reliable tick for interval. besides, we can
not have patch 4 if use active bit. patch 4 simplifies code a lot. I
really like to keep it. we can just track last use of read/write,
which uses 16 bytes. this patch removes i_hold_caps_min. So only need
8 more bytes.
>
> > struct mutex i_truncate_mutex;
> > u32 i_truncate_seq; /* last truncate to smaller size */
> > @@ -673,6 +676,10 @@ extern int __ceph_caps_revoking_other(struct ceph_inode_info *ci,
> > extern int ceph_caps_revoking(struct ceph_inode_info *ci, int mask);
> > extern int __ceph_caps_used(struct ceph_inode_info *ci);
> >
> > +static inline bool __ceph_is_file_opened(struct ceph_inode_info *ci)
> > +{
> > + return ci->i_file_by_mode[0].nr;
> > +}
> > extern int __ceph_caps_file_wanted(struct ceph_inode_info *ci);
> > extern int __ceph_caps_wanted(struct ceph_inode_info *ci);
> >
> > @@ -1074,7 +1081,10 @@ extern int ceph_try_get_caps(struct inode *inode,
> >
> > /* for counting open files by mode */
> > extern void __ceph_get_fmode(struct ceph_inode_info *ci, int mode);
> > -extern void ceph_put_fmode(struct ceph_inode_info *ci, int mode);
> > +extern void ceph_get_fmode(struct ceph_inode_info *ci, int mode, int count);
> > +extern void ceph_put_fmode(struct ceph_inode_info *ci, int mode, int count);
> > +extern void __ceph_touch_fmode(struct ceph_inode_info *ci,
> > + struct ceph_mds_client *mdsc, int fmode);
> >
> > /* addr.c */
> > extern const struct address_space_operations ceph_aops;
> > @@ -1086,7 +1096,7 @@ extern void ceph_pool_perm_destroy(struct ceph_mds_client* mdsc);
> > /* file.c */
> > extern const struct file_operations ceph_file_fops;
> >
> > -extern int ceph_renew_caps(struct inode *inode);
> > +extern int ceph_renew_caps(struct inode *inode, int fmode);
> > extern int ceph_open(struct inode *inode, struct file *file);
> > extern int ceph_atomic_open(struct inode *dir, struct dentry *dentry,
> > struct file *file, unsigned flags, umode_t mode);
> > diff --git a/include/linux/ceph/ceph_fs.h b/include/linux/ceph/ceph_fs.h
> > index cb21c5cf12c3..8017130a08a1 100644
> > --- a/include/linux/ceph/ceph_fs.h
> > +++ b/include/linux/ceph/ceph_fs.h
> > @@ -564,6 +564,7 @@ struct ceph_filelock {
> > #define CEPH_FILE_MODE_RDWR 3 /* RD | WR */
> > #define CEPH_FILE_MODE_LAZY 4 /* lazy io */
> > #define CEPH_FILE_MODE_BITS 4
> > +#define CEPH_FILE_MODE_MASK ((1 << CEPH_FILE_MODE_BITS) - 1)
> >
> > int ceph_flags_to_mode(int flags);
> >
>
> --
> Jeff Layton <jlayton@kernel.org>
>
^ permalink raw reply
* [dpdk-dev] [PATCH v3] cmdline: increase maximum line length
From: Wisam Jaddo @ 2020-02-20 14:53 UTC (permalink / raw)
To: dev, rasland, thomas; +Cc: olivier.matz, bernard.iremonger, stable
In-Reply-To: <1582204709-7992-1-git-send-email-wisamm@mellanox.com>
This increase due to the usage of cmdline in dpdk applications
as config commands such as testpmd do for rte_flow rules creation.
The current size of buffer is not enough to fill
many cases of rte_flow commands validation/creation.
rte_flow now can have outer items, inner items, modify
actions, meta data actions, duplicate action, fate action and
more in one single rte flow, thus 512 char will not be enough
to validate such rte flow rules.
Such change shouldn't affect the memory since the cmdline
reading again using the same buffer.
Cc: stable@dpdk.org
Signed-off-by: Wisam Jaddo <wisamm@mellanox.com>
---
changes in v3
* Fix commit title
Previous title was not that clear of what the change is
* Add more clarification for what we need such increase
* Explain why it won't cause any memory issue
---
---
lib/librte_cmdline/cmdline_rdline.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_cmdline/cmdline_rdline.h b/lib/librte_cmdline/cmdline_rdline.h
index d217029..8193e1d 100644
--- a/lib/librte_cmdline/cmdline_rdline.h
+++ b/lib/librte_cmdline/cmdline_rdline.h
@@ -39,7 +39,7 @@ extern "C" {
#endif
/* configuration */
-#define RDLINE_BUF_SIZE 512
+#define RDLINE_BUF_SIZE 2048
#define RDLINE_PROMPT_SIZE 32
#define RDLINE_VT100_BUF_SIZE 8
#define RDLINE_HISTORY_BUF_SIZE BUFSIZ
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v5 03/12] ceph: add infrastructure for waiting for async create to complete
From: Jeff Layton @ 2020-02-20 14:53 UTC (permalink / raw)
To: Yan, Zheng
Cc: ceph-devel, Ilya Dryomov, Sage Weil, Zheng Yan, Patrick Donnelly,
Xiubo Li
In-Reply-To: <CAAM7YAk0B5ANUT+B8sK1ddgFxBcinVXjiF9KpAdfU5chKWDX1g@mail.gmail.com>
On Thu, 2020-02-20 at 21:33 +0800, Yan, Zheng wrote:
> On Thu, Feb 20, 2020 at 9:01 PM Jeff Layton <jlayton@kernel.org> wrote:
> > On Thu, 2020-02-20 at 11:32 +0800, Yan, Zheng wrote:
> > > On Wed, Feb 19, 2020 at 9:27 PM Jeff Layton <jlayton@kernel.org> wrote:
> > > > When we issue an async create, we must ensure that any later on-the-wire
> > > > requests involving it wait for the create reply.
> > > >
> > > > Expand i_ceph_flags to be an unsigned long, and add a new bit that
> > > > MDS requests can wait on. If the bit is set in the inode when sending
> > > > caps, then don't send it and just return that it has been delayed.
> > > >
> > > > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > > > ---
> > > > fs/ceph/caps.c | 13 ++++++++++++-
> > > > fs/ceph/dir.c | 2 +-
> > > > fs/ceph/mds_client.c | 20 +++++++++++++++++++-
> > > > fs/ceph/mds_client.h | 7 +++++++
> > > > fs/ceph/super.h | 4 +++-
> > > > 5 files changed, 42 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c
> > > > index d05717397c2a..85e13aa359d2 100644
> > > > --- a/fs/ceph/caps.c
> > > > +++ b/fs/ceph/caps.c
> > > > @@ -511,7 +511,7 @@ static void __cap_delay_requeue(struct ceph_mds_client *mdsc,
> > > > struct ceph_inode_info *ci,
> > > > bool set_timeout)
> > > > {
> > > > - dout("__cap_delay_requeue %p flags %d at %lu\n", &ci->vfs_inode,
> > > > + dout("__cap_delay_requeue %p flags 0x%lx at %lu\n", &ci->vfs_inode,
> > > > ci->i_ceph_flags, ci->i_hold_caps_max);
> > > > if (!mdsc->stopping) {
> > > > spin_lock(&mdsc->cap_delay_lock);
> > > > @@ -1294,6 +1294,13 @@ static int __send_cap(struct ceph_mds_client *mdsc, struct ceph_cap *cap,
> > > > int delayed = 0;
> > > > int ret;
> > > >
> > > > + /* Don't send anything if it's still being created. Return delayed */
> > > > + if (ci->i_ceph_flags & CEPH_I_ASYNC_CREATE) {
> > > > + spin_unlock(&ci->i_ceph_lock);
> > > > + dout("%s async create in flight for %p\n", __func__, inode);
> > > > + return 1;
> > > > + }
> > > > +
> > >
> > > Maybe it's better to check this in ceph_check_caps(). Other callers
> > > of __send_cap() shouldn't encounter async creating inode
> > >
> >
> > I've been looking, but what actually guarantees that?
> >
> > Only ceph_check_caps calls it for UPDATE, but the other two callers call
> > it for FLUSH. I don't see what prevents the kernel from (e.g.) calling
> > write_inode before the create reply comes in, particularly if we just
> > create and then close the file.
> >
>
> I missed write_inode case. but make __send_cap() skip sending message
> can cause problem. For example, if we skip a message that flush dirty
> caps. call ceph_check_caps() again may not re-do the flush.
>
Ugh. Ok, so I guess we'll need to fix that first. I assume that making
sure the flush is redone after being delayed is the right thing to do
here?
> > As a side note, I still struggle with the fact thatthere seems to be no
> > coherent overall description of the cap protocol. What distinguishes a
> > FLUSH from an UPDATE, for instance? The MDS code and comments seem to
> > treat them somewhat interchangeably.
> >
>
> UPDATE is super set of FLUSH, UPDATE can always replace FLUSH.
>
I'll toss this note onto my jumble of notes, for my (eventual) planned
document that describes the cap protocol.
> > > > held = cap->issued | cap->implemented;
> > > > revoking = cap->implemented & ~cap->issued;
> > > > retain &= ~revoking;
> > > > @@ -2250,6 +2257,10 @@ int ceph_fsync(struct file *file, loff_t start, loff_t end, int datasync)
> > > > if (datasync)
> > > > goto out;
> > > >
> > > > + ret = ceph_wait_on_async_create(inode);
> > > > + if (ret)
> > > > + goto out;
> > > > +
> > > > dirty = try_flush_caps(inode, &flush_tid);
> > > > dout("fsync dirty caps are %s\n", ceph_cap_string(dirty));
> > > >
> > > > diff --git a/fs/ceph/dir.c b/fs/ceph/dir.c
> > > > index a87274935a09..5b83bda57056 100644
> > > > --- a/fs/ceph/dir.c
> > > > +++ b/fs/ceph/dir.c
> > > > @@ -752,7 +752,7 @@ static struct dentry *ceph_lookup(struct inode *dir, struct dentry *dentry,
> > > > struct ceph_dentry_info *di = ceph_dentry(dentry);
> > > >
> > > > spin_lock(&ci->i_ceph_lock);
> > > > - dout(" dir %p flags are %d\n", dir, ci->i_ceph_flags);
> > > > + dout(" dir %p flags are 0x%lx\n", dir, ci->i_ceph_flags);
> > > > if (strncmp(dentry->d_name.name,
> > > > fsc->mount_options->snapdir_name,
> > > > dentry->d_name.len) &&
> > > > diff --git a/fs/ceph/mds_client.c b/fs/ceph/mds_client.c
> > > > index 94d18e643a3d..38eb9dd5062b 100644
> > > > --- a/fs/ceph/mds_client.c
> > > > +++ b/fs/ceph/mds_client.c
> > > > @@ -2730,7 +2730,7 @@ static void kick_requests(struct ceph_mds_client *mdsc, int mds)
> > > > int ceph_mdsc_submit_request(struct ceph_mds_client *mdsc, struct inode *dir,
> > > > struct ceph_mds_request *req)
> > > > {
> > > > - int err;
> > > > + int err = 0;
> > > >
> > > > /* take CAP_PIN refs for r_inode, r_parent, r_old_dentry */
> > > > if (req->r_inode)
> > > > @@ -2743,6 +2743,24 @@ int ceph_mdsc_submit_request(struct ceph_mds_client *mdsc, struct inode *dir,
> > > > ceph_get_cap_refs(ceph_inode(req->r_old_dentry_dir),
> > > > CEPH_CAP_PIN);
> > > >
> > > > + if (req->r_inode) {
> > > > + err = ceph_wait_on_async_create(req->r_inode);
> > > > + if (err) {
> > > > + dout("%s: wait for async create returned: %d\n",
> > > > + __func__, err);
> > > > + return err;
> > > > + }
> > > > + }
> > > > +
> > > > + if (!err && req->r_old_inode) {
> > > > + err = ceph_wait_on_async_create(req->r_old_inode);
> > > > + if (err) {
> > > > + dout("%s: wait for async create returned: %d\n",
> > > > + __func__, err);
> > > > + return err;
> > > > + }
> > > > + }
> > > > +
> > > > dout("submit_request on %p for inode %p\n", req, dir);
> > > > mutex_lock(&mdsc->mutex);
> > > > __register_request(mdsc, req, dir);
> > > > diff --git a/fs/ceph/mds_client.h b/fs/ceph/mds_client.h
> > > > index 95ac00e59e66..8043f2b439b1 100644
> > > > --- a/fs/ceph/mds_client.h
> > > > +++ b/fs/ceph/mds_client.h
> > > > @@ -538,4 +538,11 @@ extern void ceph_mdsc_open_export_target_sessions(struct ceph_mds_client *mdsc,
> > > > extern int ceph_trim_caps(struct ceph_mds_client *mdsc,
> > > > struct ceph_mds_session *session,
> > > > int max_caps);
> > > > +static inline int ceph_wait_on_async_create(struct inode *inode)
> > > > +{
> > > > + struct ceph_inode_info *ci = ceph_inode(inode);
> > > > +
> > > > + return wait_on_bit(&ci->i_ceph_flags, CEPH_ASYNC_CREATE_BIT,
> > > > + TASK_INTERRUPTIBLE);
> > > > +}
> > > > #endif
> > > > diff --git a/fs/ceph/super.h b/fs/ceph/super.h
> > > > index 3430d7ffe8f7..bfb03adb4a08 100644
> > > > --- a/fs/ceph/super.h
> > > > +++ b/fs/ceph/super.h
> > > > @@ -316,7 +316,7 @@ struct ceph_inode_info {
> > > > u64 i_inline_version;
> > > > u32 i_time_warp_seq;
> > > >
> > > > - unsigned i_ceph_flags;
> > > > + unsigned long i_ceph_flags;
> > > > atomic64_t i_release_count;
> > > > atomic64_t i_ordered_count;
> > > > atomic64_t i_complete_seq[2];
> > > > @@ -524,6 +524,8 @@ static inline struct inode *ceph_find_inode(struct super_block *sb,
> > > > #define CEPH_I_ERROR_WRITE (1 << 10) /* have seen write errors */
> > > > #define CEPH_I_ERROR_FILELOCK (1 << 11) /* have seen file lock errors */
> > > > #define CEPH_I_ODIRECT (1 << 12) /* inode in direct I/O mode */
> > > > +#define CEPH_ASYNC_CREATE_BIT (13) /* async create in flight for this */
> > > > +#define CEPH_I_ASYNC_CREATE (1 << CEPH_ASYNC_CREATE_BIT)
> > > >
> > > > /*
> > > > * Masks of ceph inode work.
> > > > --
> > > > 2.24.1
> > > >
> >
> > --
> > Jeff Layton <jlayton@kernel.org>
> >
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 09/10] arm64: tegra: enable AHUB modules for few Tegra chips
From: Jon Hunter @ 2020-02-20 14:52 UTC (permalink / raw)
To: Sameer Pujar, perex, tiwai, robh+dt
Cc: devicetree, alsa-devel, atalambedu, lgirdwood, linux-kernel,
viswanathl, sharadg, broonie, thierry.reding, linux-tegra, digetx,
rlokhande, mkumard, dramesh
In-Reply-To: <1582180492-25297-10-git-send-email-spujar@nvidia.com>
On 20/02/2020 06:34, Sameer Pujar wrote:
> This patch enables AHUB, ADMAIF modules for following Tegra platforms.
> Along with this specific instances of I/O modules are enabled as per
> the board design.
>
> * Jetson TX1
> - I2S1, I2S2, I2S3, I2S4 and I2S5
> - DMIC1, DMIC2 and DMIC3
>
> * Jetson TX2
> - I2S1, I2S2, I2S3, I2S4, I2S5 and I2S6
> - DMIC1, DMIC2 and DMIC3
> - DSPK2
>
> * Jetson AGX Xavier
> - I2S1, I2S2, I2S4 and I2S6
> - DMIC2 and DMIC3
> - DSPK1
>
> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> ---
> arch/arm64/boot/dts/nvidia/tegra186-p2771-0000.dts | 48 ++++++++++++++++++++++
> arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts | 36 ++++++++++++++++
> arch/arm64/boot/dts/nvidia/tegra210-p2371-2180.dts | 40 ++++++++++++++++++
> 3 files changed, 124 insertions(+)
Thanks!
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH v3 10/10] arm64: defconfig: enable AHUB components for Tegra210 and later
From: Jon Hunter @ 2020-02-20 14:52 UTC (permalink / raw)
To: Sameer Pujar, perex, tiwai, robh+dt
Cc: broonie, lgirdwood, thierry.reding, digetx, alsa-devel,
devicetree, linux-tegra, linux-kernel, sharadg, mkumard,
viswanathl, rlokhande, dramesh, atalambedu
In-Reply-To: <1582180492-25297-11-git-send-email-spujar@nvidia.com>
On 20/02/2020 06:34, Sameer Pujar wrote:
> This patch enables following configs:
> +CONFIG_TEGRA_ACONNECT=m
> +CONFIG_SND_SOC_TEGRA=m
> +CONFIG_SND_SOC_TEGRA210_AHUB=m
> +CONFIG_SND_SOC_TEGRA210_DMIC=m
> +CONFIG_SND_SOC_TEGRA210_I2S=m
> +CONFIG_SND_SOC_TEGRA186_DSPK=m
> +CONFIG_SND_SOC_TEGRA210_ADMAIF=m
>
> This patch helps to register AHUB and its clients (I2S, DMIC, DSPK, ADMAIF)
> with ASoC core. Since AHUB is child of ACONNECT, config TEGRA_ACONNECT is
> enabled as well.
>
> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> ---
> arch/arm64/configs/defconfig | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index c8801be..784ca4f 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -207,6 +207,7 @@ CONFIG_FW_LOADER_USER_HELPER=y
> CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y
> CONFIG_HISILICON_LPC=y
> CONFIG_SIMPLE_PM_BUS=y
> +CONFIG_TEGRA_ACONNECT=m
> CONFIG_MTD=y
> CONFIG_MTD_BLOCK=y
> CONFIG_MTD_RAW_NAND=y
> @@ -590,6 +591,12 @@ CONFIG_SND_SOC_RK3399_GRU_SOUND=m
> CONFIG_SND_SOC_SAMSUNG=y
> CONFIG_SND_SOC_RCAR=m
> CONFIG_SND_SUN4I_SPDIF=m
> +CONFIG_SND_SOC_TEGRA=m
> +CONFIG_SND_SOC_TEGRA210_AHUB=m
> +CONFIG_SND_SOC_TEGRA210_DMIC=m
> +CONFIG_SND_SOC_TEGRA210_I2S=m
> +CONFIG_SND_SOC_TEGRA186_DSPK=m
> +CONFIG_SND_SOC_TEGRA210_ADMAIF=m
> CONFIG_SND_SOC_AK4613=m
> CONFIG_SND_SOC_ES7134=m
> CONFIG_SND_SOC_ES7241=m
Thanks!
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH v3 10/10] arm64: defconfig: enable AHUB components for Tegra210 and later
From: Jon Hunter @ 2020-02-20 14:52 UTC (permalink / raw)
To: Sameer Pujar, perex-/Fr2/VpizcU, tiwai-IBi9RG/b67k,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: broonie-DgEjT+Ai2ygdnm+yROfE0A, lgirdwood-Re5JQEeQqe8AvxtiuMwx3w,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
digetx-Re5JQEeQqe8AvxtiuMwx3w, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
sharadg-DDmLM1+adcrQT0dZR+AlfA, mkumard-DDmLM1+adcrQT0dZR+AlfA,
viswanathl-DDmLM1+adcrQT0dZR+AlfA,
rlokhande-DDmLM1+adcrQT0dZR+AlfA, dramesh-DDmLM1+adcrQT0dZR+AlfA,
atalambedu-DDmLM1+adcrQT0dZR+AlfA
In-Reply-To: <1582180492-25297-11-git-send-email-spujar-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On 20/02/2020 06:34, Sameer Pujar wrote:
> This patch enables following configs:
> +CONFIG_TEGRA_ACONNECT=m
> +CONFIG_SND_SOC_TEGRA=m
> +CONFIG_SND_SOC_TEGRA210_AHUB=m
> +CONFIG_SND_SOC_TEGRA210_DMIC=m
> +CONFIG_SND_SOC_TEGRA210_I2S=m
> +CONFIG_SND_SOC_TEGRA186_DSPK=m
> +CONFIG_SND_SOC_TEGRA210_ADMAIF=m
>
> This patch helps to register AHUB and its clients (I2S, DMIC, DSPK, ADMAIF)
> with ASoC core. Since AHUB is child of ACONNECT, config TEGRA_ACONNECT is
> enabled as well.
>
> Signed-off-by: Sameer Pujar <spujar-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> arch/arm64/configs/defconfig | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index c8801be..784ca4f 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -207,6 +207,7 @@ CONFIG_FW_LOADER_USER_HELPER=y
> CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y
> CONFIG_HISILICON_LPC=y
> CONFIG_SIMPLE_PM_BUS=y
> +CONFIG_TEGRA_ACONNECT=m
> CONFIG_MTD=y
> CONFIG_MTD_BLOCK=y
> CONFIG_MTD_RAW_NAND=y
> @@ -590,6 +591,12 @@ CONFIG_SND_SOC_RK3399_GRU_SOUND=m
> CONFIG_SND_SOC_SAMSUNG=y
> CONFIG_SND_SOC_RCAR=m
> CONFIG_SND_SUN4I_SPDIF=m
> +CONFIG_SND_SOC_TEGRA=m
> +CONFIG_SND_SOC_TEGRA210_AHUB=m
> +CONFIG_SND_SOC_TEGRA210_DMIC=m
> +CONFIG_SND_SOC_TEGRA210_I2S=m
> +CONFIG_SND_SOC_TEGRA186_DSPK=m
> +CONFIG_SND_SOC_TEGRA210_ADMAIF=m
> CONFIG_SND_SOC_AK4613=m
> CONFIG_SND_SOC_ES7134=m
> CONFIG_SND_SOC_ES7241=m
Thanks!
Reviewed-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH v2] arm64:kgdb: Fix kernel single-stepping
From: Corey Minyard @ 2020-02-20 14:52 UTC (permalink / raw)
To: Daniel Thompson
Cc: Will Deacon, Catalin Marinas, linux-arm-kernel, linux-kernel,
Corey Minyard
In-Reply-To: <20200220140650.tryvv3ishkxduujk@holly.lan>
On Thu, Feb 20, 2020 at 02:06:50PM +0000, Daniel Thompson wrote:
> On Wed, Feb 19, 2020 at 09:24:03AM -0600, minyard@acm.org wrote:
> > From: Corey Minyard <cminyard@mvista.com>
> >
> > I was working on a single-step bug on kgdb on an ARM64 system, and I saw
> > this scenario:
> >
> > * A single step is setup to return to el1
> > * The ERET return to el1
> > * An interrupt is pending and runs before the instruction
> > * As soon as PSTATE.D (the debug disable bit) is cleared, the single
> > step happens in that location, not where it should have.
> >
> > This appears to be due to PSTATE.SS not being cleared when the exception
> > happens. Per section D.2.12.5 of the ARMv8 reference manual, that
> > appears to be incorrect, it says "As part of exception entry, the PE
> > does all of the following: ... Sets PSTATE.SS to 0."
> >
> > However, I appear to not be the first person who has noticed this. In
> > the el0-only portion of the kernel_entry macro in entry.S, I found the
> > following comment: "Ensure MDSCR_EL1.SS is clear, since we can unmask
> > debug exceptions when scheduling." Exactly the same scenario, except
> > coming from a userland single step, not a kernel one.
> >
> > As I was studying this, though, I realized that the following scenario
> > had an issue:
> >
> > * Kernel enables MDSCR.SS, MDSCR.KDE, MDSCR.MDE (unnecessary), and
> > PSTATE.SS to enable a single step in el1, for kgdb or kprobes,
> > on the current CPU's MDSCR register and the process' PSTATE.SS
> > register.
> > * Kernel returns from the exception with ERET.
> > * An interrupt or page fault happens on the instruction, causing the
> > instruction to not be run, but the exception handler runs.
> > * The exception causes the task to migrate to a new core.
> > * The return from the exception runs on a different processor now,
> > where the MDSCR values are not set up for a single step.
> > * The single step fails to happen.
> >
> > This is bad for kgdb, of course, but it seems really bad for kprobes if
> > this happens.
> >
> > To fix both these problems, rework the handling of single steps to clear
> > things out upon entry to the kernel from el1, and then to set up single
> > step when returning to el1, and not do the setup in debug-monitors.c.
> > This means that single stepping does not use
> > enable/disable_debug_monitors(); it is no longer necessary to track
> > those flags for single stepping. This is much like single stepping is
> > handled for el0. A new flag is added in pt_regs to enable single
> > stepping from el1. Unfortunately, the old value of PSTATE.SS cannot be
> > used for this because of the hardware bug mentioned earlier.
> >
> > As part of this, there is an interaction between single stepping and the
> > other users of debug monitors with the MDSCR.KDE bit. That bit has to
> > be set for both hardware breakpoints at el1 and single stepping at el1.
> > A new variable was created to store the cpu-wide value of MDSCR.KDE; the
> > single stepping code makes sure not to clear that bit on kernel entry if
> > it's set in the per-cpu variable.
> >
> > After fixing this and doing some more testing, I ran into another issue:
> >
> > * Kernel enables the pt_regs single step
> > * Kernel returns from the exception with ERET.
> > * An interrupt or page fault happens on the instruction, causing the
> > instruction to not be run, but the exception handler runs.
> > * The exception handling hits a breakpoint and stops.
> > * The user continues from the breakpoint, so the kernel is no longer
> > expecting a single step.
> > * On the return from the first exception, the single step flag in
> > pt_regs is still set, so a single step trap happens.
> > * The kernel keels over from an unexpected single step.
> >
> > There's no easy way to find the pt_regs that has the single step flag
> > set. So a thread info flag was added so that the single step could be
> > disabled in this case. Both that flag and the flag in pt_regs must be
> > set to enable a single step.
> >
> > Signed-off-by: Corey Minyard <cminyard@mvista.com>
>
> I've pointed the kgdbtest suite at this patch (and run one of the
> historically unstable test cases an extra 100 times just in case).
>
> kgdbtest hasn't got great coverage, runs the code in qemu and some
> of the strongest tests are still marked XFAIL on arm64 (for reasons
> unrelated to stepping).
>
> So the best I can say based on the above is that the test suite does not
> observe any regression (but equally no improvement). Nevertheless FWIW:
Thanks for testing this. This is not a surprise, you would either have
to have a broken processor like the one I'm using, or you would have to
have a migration occur on the instruction being single-stepped, which
would be extremely unlikely.
Since I've already gained some experience here, I'll try to look at
fixing things here for ARM64.
-corey
>
>
> Tested-by: Daniel Thompson <daniel.thompson@linaro.org>
>
>
> Daniel.
^ permalink raw reply
* Re: [PATCH v3 09/10] arm64: tegra: enable AHUB modules for few Tegra chips
From: Jon Hunter @ 2020-02-20 14:52 UTC (permalink / raw)
To: Sameer Pujar, perex, tiwai, robh+dt
Cc: broonie, lgirdwood, thierry.reding, digetx, alsa-devel,
devicetree, linux-tegra, linux-kernel, sharadg, mkumard,
viswanathl, rlokhande, dramesh, atalambedu
In-Reply-To: <1582180492-25297-10-git-send-email-spujar@nvidia.com>
On 20/02/2020 06:34, Sameer Pujar wrote:
> This patch enables AHUB, ADMAIF modules for following Tegra platforms.
> Along with this specific instances of I/O modules are enabled as per
> the board design.
>
> * Jetson TX1
> - I2S1, I2S2, I2S3, I2S4 and I2S5
> - DMIC1, DMIC2 and DMIC3
>
> * Jetson TX2
> - I2S1, I2S2, I2S3, I2S4, I2S5 and I2S6
> - DMIC1, DMIC2 and DMIC3
> - DSPK2
>
> * Jetson AGX Xavier
> - I2S1, I2S2, I2S4 and I2S6
> - DMIC2 and DMIC3
> - DSPK1
>
> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> ---
> arch/arm64/boot/dts/nvidia/tegra186-p2771-0000.dts | 48 ++++++++++++++++++++++
> arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts | 36 ++++++++++++++++
> arch/arm64/boot/dts/nvidia/tegra210-p2371-2180.dts | 40 ++++++++++++++++++
> 3 files changed, 124 insertions(+)
Thanks!
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH v3 09/10] arm64: tegra: enable AHUB modules for few Tegra chips
From: Jon Hunter @ 2020-02-20 14:52 UTC (permalink / raw)
To: Sameer Pujar, perex-/Fr2/VpizcU, tiwai-IBi9RG/b67k,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: broonie-DgEjT+Ai2ygdnm+yROfE0A, lgirdwood-Re5JQEeQqe8AvxtiuMwx3w,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
digetx-Re5JQEeQqe8AvxtiuMwx3w, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
sharadg-DDmLM1+adcrQT0dZR+AlfA, mkumard-DDmLM1+adcrQT0dZR+AlfA,
viswanathl-DDmLM1+adcrQT0dZR+AlfA,
rlokhande-DDmLM1+adcrQT0dZR+AlfA, dramesh-DDmLM1+adcrQT0dZR+AlfA,
atalambedu-DDmLM1+adcrQT0dZR+AlfA
In-Reply-To: <1582180492-25297-10-git-send-email-spujar-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On 20/02/2020 06:34, Sameer Pujar wrote:
> This patch enables AHUB, ADMAIF modules for following Tegra platforms.
> Along with this specific instances of I/O modules are enabled as per
> the board design.
>
> * Jetson TX1
> - I2S1, I2S2, I2S3, I2S4 and I2S5
> - DMIC1, DMIC2 and DMIC3
>
> * Jetson TX2
> - I2S1, I2S2, I2S3, I2S4, I2S5 and I2S6
> - DMIC1, DMIC2 and DMIC3
> - DSPK2
>
> * Jetson AGX Xavier
> - I2S1, I2S2, I2S4 and I2S6
> - DMIC2 and DMIC3
> - DSPK1
>
> Signed-off-by: Sameer Pujar <spujar-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> arch/arm64/boot/dts/nvidia/tegra186-p2771-0000.dts | 48 ++++++++++++++++++++++
> arch/arm64/boot/dts/nvidia/tegra194-p2972-0000.dts | 36 ++++++++++++++++
> arch/arm64/boot/dts/nvidia/tegra210-p2371-2180.dts | 40 ++++++++++++++++++
> 3 files changed, 124 insertions(+)
Thanks!
Reviewed-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* [PATCH 3/3] power: charger: max14577: Add proper dt-compatible strings
From: Marek Szyprowski @ 2020-02-20 14:51 UTC (permalink / raw)
To: linux-pm, linux-kernel
Cc: Marek Szyprowski, Krzysztof Kozlowski, Bartlomiej Zolnierkiewicz,
Chanwoo Choi, MyungJoo Ham, Sebastian Reichel, Mark Brown
In-Reply-To: <20200220145127.21273-1-m.szyprowski@samsung.com>
Add device tree compatible strings and create proper modalias structures
to let this driver load automatically if compiled as module, because
max14577 MFD driver creates MFD cells with such compatible strings.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
drivers/power/supply/max14577_charger.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/power/supply/max14577_charger.c b/drivers/power/supply/max14577_charger.c
index 8a59feac6468..891ba9f6f295 100644
--- a/drivers/power/supply/max14577_charger.c
+++ b/drivers/power/supply/max14577_charger.c
@@ -623,6 +623,15 @@ static const struct platform_device_id max14577_charger_id[] = {
};
MODULE_DEVICE_TABLE(platform, max14577_charger_id);
+static const struct of_device_id of_max14577_charger_dt_match[] = {
+ { .compatible = "maxim,max77836-charger",
+ .data = (void *)MAXIM_DEVICE_TYPE_MAX77836, },
+ { .compatible = "maxim,max14577-charger",
+ .data = (void *)MAXIM_DEVICE_TYPE_MAX14577, },
+ { },
+};
+MODULE_DEVICE_TABLE(of, of_max14577_charger_dt_match);
+
static struct platform_driver max14577_charger_driver = {
.driver = {
.name = "max14577-charger",
--
2.17.1
^ permalink raw reply related
* [PATCH 2/3] extcon: max14577: Add proper dt-compatible strings
From: Marek Szyprowski @ 2020-02-20 14:51 UTC (permalink / raw)
To: linux-pm, linux-kernel
Cc: Marek Szyprowski, Krzysztof Kozlowski, Bartlomiej Zolnierkiewicz,
Chanwoo Choi, MyungJoo Ham, Sebastian Reichel, Mark Brown
In-Reply-To: <20200220145127.21273-1-m.szyprowski@samsung.com>
Add device tree compatible strings and create proper modalias structures
to let this driver load automatically if compiled as module, because
max14577 MFD driver creates MFD cells with such compatible strings.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
drivers/extcon/extcon-max14577.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/extcon/extcon-max14577.c b/drivers/extcon/extcon-max14577.c
index 32f663436e6e..6df814cffe37 100644
--- a/drivers/extcon/extcon-max14577.c
+++ b/drivers/extcon/extcon-max14577.c
@@ -782,6 +782,15 @@ static const struct platform_device_id max14577_muic_id[] = {
};
MODULE_DEVICE_TABLE(platform, max14577_muic_id);
+static const struct of_device_id of_max14577_muic_dt_match[] = {
+ { .compatible = "maxim,max77836-muic",
+ .data = (void *)MAXIM_DEVICE_TYPE_MAX77836, },
+ { .compatible = "maxim,max14577-muic",
+ .data = (void *)MAXIM_DEVICE_TYPE_MAX14577, },
+ { },
+};
+MODULE_DEVICE_TABLE(of, of_max14577_muic_dt_match);
+
static struct platform_driver max14577_muic_driver = {
.driver = {
.name = "max14577-muic",
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v1 0/2] perf report: Support annotation of code without symbols
From: Jiri Olsa @ 2020-02-20 14:51 UTC (permalink / raw)
To: Jin, Yao
Cc: acme, jolsa, peterz, mingo, alexander.shishkin, Linux-kernel, ak,
kan.liang, yao.jin
In-Reply-To: <1fc1c4f5-ca94-ebd7-fae0-28765070662f@linux.intel.com>
On Thu, Feb 20, 2020 at 10:42:11PM +0800, Jin, Yao wrote:
>
>
> On 2/20/2020 8:06 PM, Jiri Olsa wrote:
> > On Thu, Feb 20, 2020 at 08:03:18PM +0800, Jin, Yao wrote:
> > >
> > >
> > > On 2/20/2020 7:56 PM, Jiri Olsa wrote:
> > > > On Thu, Feb 20, 2020 at 08:59:00AM +0800, Jin Yao wrote:
> > > > > For perf report on stripped binaries it is currently impossible to do
> > > > > annotation. The annotation state is all tied to symbols, but there are
> > > > > either no symbols, or symbols are not covering all the code.
> > > > >
> > > > > We should support the annotation functionality even without symbols.
> > > > >
> > > > > The first patch uses al_addr to print because it's easy to dump
> > > > > the instructions from this address in binary for branch mode.
> > > > >
> > > > > The second patch supports the annotation on stripped binary.
> > > > >
> > > > > Jin Yao (2):
> > > > > perf util: Print al_addr when symbol is not found
> > > > > perf annotate: Support interactive annotation of code without symbols
> > > >
> > > > looks good, but I'm getting crash when annotating unresolved kernel address:
> > > >
> > > > jirka
> > > >
> > > >
> > >
> > > Thanks for reporting the issue.
> > >
> > > I guess you are trying the "0xffffffff81c00ae7", let me try to reproduce
> > > this issue.
> >
> > yes, I also checked and it did not happen before
> >
> > jirka
> >
>
> Hi Jiri,
>
> Can you try this fix?
>
> diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
> index ff5711899234..5144528b2931 100644
> --- a/tools/perf/ui/browsers/hists.c
> +++ b/tools/perf/ui/browsers/hists.c
> @@ -2497,7 +2497,7 @@ add_annotate_opt(struct hist_browser *browser,
> struct map_symbol *ms,
> u64 addr)
> {
> - if (ms->map->dso->annotate_warned)
> + if (!ms->map || !ms->map->dso || ms->map->dso->annotate_warned)
> return 0;
>
> if (!ms->sym) {
>
> It's tested OK at my side.
yep, the crash is gone
thanks,
jirka
^ permalink raw reply
* [PATCH 1/3] regulator: max14577: Add proper dt-compatible strings
From: Marek Szyprowski @ 2020-02-20 14:51 UTC (permalink / raw)
To: linux-pm, linux-kernel
Cc: Marek Szyprowski, Krzysztof Kozlowski, Bartlomiej Zolnierkiewicz,
Chanwoo Choi, MyungJoo Ham, Sebastian Reichel, Mark Brown
In-Reply-To: <CGME20200220145134eucas1p288ae1910d3e8d12dc12f010ed0b07b45@eucas1p2.samsung.com>
Add device tree compatible strings and create proper modalias structures
to let this driver load automatically if compiled as module, because
max14577 MFD driver creates MFD cells with such compatible strings.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
drivers/regulator/max14577-regulator.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/regulator/max14577-regulator.c b/drivers/regulator/max14577-regulator.c
index 07a150c9bbf2..19e779dd961e 100644
--- a/drivers/regulator/max14577-regulator.c
+++ b/drivers/regulator/max14577-regulator.c
@@ -238,6 +238,15 @@ static const struct platform_device_id max14577_regulator_id[] = {
};
MODULE_DEVICE_TABLE(platform, max14577_regulator_id);
+static const struct of_device_id of_max14577_regulator_dt_match[] = {
+ { .compatible = "maxim,max77836-regulator",
+ .data = (void *)MAXIM_DEVICE_TYPE_MAX77836, },
+ { .compatible = "maxim,max14577-regulator",
+ .data = (void *)MAXIM_DEVICE_TYPE_MAX14577, },
+ { },
+};
+MODULE_DEVICE_TABLE(of, of_max14577_regulator_dt_match);
+
static struct platform_driver max14577_regulator_driver = {
.driver = {
.name = "max14577-regulator",
--
2.17.1
^ permalink raw reply related
* Re: [RFC PATCH v3 05/27] qcow2: Document the Extended L2 Entries feature
From: Alberto Garcia @ 2020-02-20 14:49 UTC (permalink / raw)
To: Eric Blake, qemu-devel
Cc: Kevin Wolf, Anton Nefedov, qemu-block, Max Reitz,
Vladimir Sementsov-Ogievskiy, Denis V . Lunev
In-Reply-To: <3a946970-5a26-6c40-a212-0aefdccef509@redhat.com>
On Thu 20 Feb 2020 03:28:17 PM CET, Eric Blake wrote:
>> +An image uses Extended L2 Entries if bit 3 is set on the incompatible_features
>> +field of the header.
>> +
>> +In these images standard data clusters are divided into 32 subclusters of the
>> +same size. They are contiguous and start from the beginning of the cluster.
>> +Subclusters can be allocated independently and the L2 entry contains information
>> +indicating the status of each one of them. Compressed data clusters don't have
>> +subclusters so they are treated like in images without this feature.
>
> Grammar; I'd suggest:
>
> ...don't have subclusters, so they are treated the same as in images
> without this feature.
Ok
> Are they truly the same, or do you still need to document that the
> extra 64 bits of the extended L2 entry are all zero?
It is documented later in the same patch ("Subcluster Allocation Bitmap
for compressed clusters").
By the way, this series treats an L2 entry as invalid if any of those
bits is not zero, but I think I'll change that. Conceivably those bits
could be used for a future compatible feature, but it can only be
compatible if the previous versions ignore those bits.
>> + 32 - 63 Subcluster reads as zeros (one bit per subcluster)
>> +
>> + 1: the subcluster reads as zeros. In this case the
>> + allocation status bit must be unset. The host
>> + cluster offset field may or may not be set.
>
> Why must the allocation bit be unset? When we preallocate, we want a
> cluster to reserve space, but still read as zero, so the combination
> of both bits set makes sense to me.
Since 00 means unallocated and 01 allocated, there are two options left
to represent the "reads as zero" case: 10 and 11.
I think that one could argue for either one and there is no "right"
choice. I chose the former because I understood the allocation bit as
"the guest visible data is obtained from the raw data in that
subcluster" but the other option also makes sense.
Berto
^ permalink raw reply
* Re: [PATCH v2] arm64:kgdb: Fix kernel single-stepping
From: Corey Minyard @ 2020-02-20 14:50 UTC (permalink / raw)
To: Marc Zyngier
Cc: Catalin Marinas, Will Deacon, linux-kernel, linux-arm-kernel,
Corey Minyard
In-Reply-To: <1416dca51b52dff349923184f41d48e8@kernel.org>
On Thu, Feb 20, 2020 at 02:21:36PM +0000, Marc Zyngier wrote:
> On 2020-02-19 15:24, minyard@acm.org wrote:
> > From: Corey Minyard <cminyard@mvista.com>
>
> [...]
>
> > After studying the EL0 handling for this, I realized an issue with using
> > MDSCR to check if single step is enabled: it can be expensive on a VM.
> > So check the task flag first to see if single step is enabled. Then
> > check MDSCR if the task flag is set.
>
> Very tangential remark: I'd really like people *not* to try and optimize
> Linux based on the behaviour of a hypervisor. In general, reading a
> system register is fast, and the fact that it traps on a given hypervisor
> at some point may not be true in the future, nor be a valid assumption
> across hypervisors.
Normally I would agree, but I based this upon git commit
https://github.com/torvalds/linux/commit/2a2830703a2371b47f7b50b1d35cb15dc0e2b717
which seemed to say that it was a significant enough factor to do in the
EL0 case.
-corey
>
> M.
> --
> Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 0/3] arm: allwinner: Wire up USB ports
From: Peter Maydell @ 2020-02-20 14:50 UTC (permalink / raw)
To: Guenter Roeck; +Cc: Beniamino Galvani, qemu-arm, Gerd Hoffmann, QEMU Developers
In-Reply-To: <20200217204812.9857-1-linux@roeck-us.net>
On Mon, 17 Feb 2020 at 20:48, Guenter Roeck <linux@roeck-us.net> wrote:
>
> Instantiate EHCI and OHCI controllers on Allwinner A10.
>
> The first patch in the series moves the declaration of EHCISysBusState
> from hcd-ohci.c to hcd-ohci.h. This lets us add the structure to
> AwA10State. Similar, TYPE_SYSBUS_OHCI is moved to be able to use it
> outside its driver.
>
> The second patch introduces the ehci-sysbus property "companion-enable".
> This lets us use object_property_set_bool() to enable companion mode.
>
> The third patch instantiates EHCI and OHCI ports for Allwinner-A10
> and marks the OHCI ports as companions of the respective EHCI ports.
>
> Tested by attaching various high speed and full speed devices, and by
> booting from USB drive.
>
> v3: Rebased to master
> v2: Add summary
> Rewrite to instantiate OHCI in companion mode; add patch 2/3
> Merge EHCI and OHCI instantiation into a single patch
>
Applied to target-arm.next, thanks.
-- PMM
^ permalink raw reply
* Re: [PATCH v2] arm64:kgdb: Fix kernel single-stepping
From: Corey Minyard @ 2020-02-20 14:50 UTC (permalink / raw)
To: Marc Zyngier
Cc: Will Deacon, Catalin Marinas, linux-arm-kernel, Corey Minyard,
linux-kernel
In-Reply-To: <1416dca51b52dff349923184f41d48e8@kernel.org>
On Thu, Feb 20, 2020 at 02:21:36PM +0000, Marc Zyngier wrote:
> On 2020-02-19 15:24, minyard@acm.org wrote:
> > From: Corey Minyard <cminyard@mvista.com>
>
> [...]
>
> > After studying the EL0 handling for this, I realized an issue with using
> > MDSCR to check if single step is enabled: it can be expensive on a VM.
> > So check the task flag first to see if single step is enabled. Then
> > check MDSCR if the task flag is set.
>
> Very tangential remark: I'd really like people *not* to try and optimize
> Linux based on the behaviour of a hypervisor. In general, reading a
> system register is fast, and the fact that it traps on a given hypervisor
> at some point may not be true in the future, nor be a valid assumption
> across hypervisors.
Normally I would agree, but I based this upon git commit
https://github.com/torvalds/linux/commit/2a2830703a2371b47f7b50b1d35cb15dc0e2b717
which seemed to say that it was a significant enough factor to do in the
EL0 case.
-corey
>
> M.
> --
> Jazz is not dead. It just smells funny...
^ permalink raw reply
* Re: [PATCH v3 08/10] arm64: tegra: add AHUB components for few Tegra chips
From: Jon Hunter @ 2020-02-20 14:49 UTC (permalink / raw)
To: Sameer Pujar, perex, tiwai, robh+dt
Cc: devicetree, alsa-devel, atalambedu, lgirdwood, linux-kernel,
viswanathl, sharadg, broonie, thierry.reding, linux-tegra, digetx,
rlokhande, mkumard, dramesh
In-Reply-To: <1582180492-25297-9-git-send-email-spujar@nvidia.com>
On 20/02/2020 06:34, Sameer Pujar wrote:
> This patch adds few AHUB modules for Tegra210, Tegra186 and Tegra194.
> Following modules are common to all above SoCs,
> * AHUB added as a child node under ACONNECT
> * AHUB includes many HW accelerators and below components are added
> as its children.
> * ADMAIF
> * I2S
> * DMIC
> * DSPK (added for Tegra186 and Tegra194 only, since Tegra210 does
> not have this module)
>
> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> ---
> arch/arm64/boot/dts/nvidia/tegra186.dtsi | 231 ++++++++++++++++++++++++++++-
> arch/arm64/boot/dts/nvidia/tegra194.dtsi | 239 ++++++++++++++++++++++++++++++-
> arch/arm64/boot/dts/nvidia/tegra210.dtsi | 145 +++++++++++++++++++
> 3 files changed, 613 insertions(+), 2 deletions(-)
Thanks!
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH 0/5] Support Argon2 KDF in LUKS2
From: Patrick Steinhardt @ 2020-02-20 14:50 UTC (permalink / raw)
To: The development of GNU GRUB
Cc: Daniel Kiper, gmazyland, leif, agraf, pjones, mjg59, phcoder
In-Reply-To: <20200213114259.j5oalczscie6unyr@tomti.i.net-space.pl>
[-- Attachment #1: Type: text/plain, Size: 1871 bytes --]
On Thu, Feb 13, 2020 at 12:42:59PM +0100, Daniel Kiper wrote:
> On Wed, Feb 12, 2020 at 08:47:49AM +0100, Patrick Steinhardt wrote:
> > On Tue, Feb 11, 2020 at 10:53:59PM +0100, Daniel Kiper wrote:
> > > > GRUB's codebase. This included both stripping off unneeded
> > > > functionality as well as converting the code to use our own coding
> > >
> > > Stripping unneeded functionality is OK. However, I think that it does
> > > not make sense to convert coding style to the GRUB one. Especially if we
> > > do not do that for other modules. So, I would leave coding style in
> > > Argon2 module as is and save your precious minutes for something more
> > > productive... ;-)
> >
> >
> > Fair enough, I'll send out a v2 with the original coding style. I
> > thought as much when I was ready with v1, but was too lazy to do the
> > work and change back the coding style.
> >
> > Anyway, to save myself another roundtrip: would you prefer to merge
> > Argon2 functionality into a single file like I've done it right now or
> > to retain the original set of files? The reason why I've opted for the
> > latter is mainly to be able to annotate more functions as static.
>
> I think that you should retain original set of files. And please add
> a description to the docs/grub-dev.texi how to update Argon2 lib in
> the future.
>
> Daniel
In the ideal case, we'd just compile Argon2 with the POSIX compat layer
so that we wouldn't need to modify most of the types and functions used
by it, like uint32, malloc, etc. As a result, libgrubkern.a would grow a
dependency on C{,PP}FLAGS_POSIX, though. I did notice compilation errors
in other modules when trying that, so my question is which path to go:
fix resulting incompatibilities when adding POSIX includes or just
replace types and function calls in Argon2 code?
Patrick
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3 08/10] arm64: tegra: add AHUB components for few Tegra chips
From: Jon Hunter @ 2020-02-20 14:49 UTC (permalink / raw)
To: Sameer Pujar, perex, tiwai, robh+dt
Cc: broonie, lgirdwood, thierry.reding, digetx, alsa-devel,
devicetree, linux-tegra, linux-kernel, sharadg, mkumard,
viswanathl, rlokhande, dramesh, atalambedu
In-Reply-To: <1582180492-25297-9-git-send-email-spujar@nvidia.com>
On 20/02/2020 06:34, Sameer Pujar wrote:
> This patch adds few AHUB modules for Tegra210, Tegra186 and Tegra194.
> Following modules are common to all above SoCs,
> * AHUB added as a child node under ACONNECT
> * AHUB includes many HW accelerators and below components are added
> as its children.
> * ADMAIF
> * I2S
> * DMIC
> * DSPK (added for Tegra186 and Tegra194 only, since Tegra210 does
> not have this module)
>
> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> ---
> arch/arm64/boot/dts/nvidia/tegra186.dtsi | 231 ++++++++++++++++++++++++++++-
> arch/arm64/boot/dts/nvidia/tegra194.dtsi | 239 ++++++++++++++++++++++++++++++-
> arch/arm64/boot/dts/nvidia/tegra210.dtsi | 145 +++++++++++++++++++
> 3 files changed, 613 insertions(+), 2 deletions(-)
Thanks!
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH v3 08/10] arm64: tegra: add AHUB components for few Tegra chips
From: Jon Hunter @ 2020-02-20 14:49 UTC (permalink / raw)
To: Sameer Pujar, perex-/Fr2/VpizcU, tiwai-IBi9RG/b67k,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: broonie-DgEjT+Ai2ygdnm+yROfE0A, lgirdwood-Re5JQEeQqe8AvxtiuMwx3w,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
digetx-Re5JQEeQqe8AvxtiuMwx3w, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
sharadg-DDmLM1+adcrQT0dZR+AlfA, mkumard-DDmLM1+adcrQT0dZR+AlfA,
viswanathl-DDmLM1+adcrQT0dZR+AlfA,
rlokhande-DDmLM1+adcrQT0dZR+AlfA, dramesh-DDmLM1+adcrQT0dZR+AlfA,
atalambedu-DDmLM1+adcrQT0dZR+AlfA
In-Reply-To: <1582180492-25297-9-git-send-email-spujar-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On 20/02/2020 06:34, Sameer Pujar wrote:
> This patch adds few AHUB modules for Tegra210, Tegra186 and Tegra194.
> Following modules are common to all above SoCs,
> * AHUB added as a child node under ACONNECT
> * AHUB includes many HW accelerators and below components are added
> as its children.
> * ADMAIF
> * I2S
> * DMIC
> * DSPK (added for Tegra186 and Tegra194 only, since Tegra210 does
> not have this module)
>
> Signed-off-by: Sameer Pujar <spujar-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> arch/arm64/boot/dts/nvidia/tegra186.dtsi | 231 ++++++++++++++++++++++++++++-
> arch/arm64/boot/dts/nvidia/tegra194.dtsi | 239 ++++++++++++++++++++++++++++++-
> arch/arm64/boot/dts/nvidia/tegra210.dtsi | 145 +++++++++++++++++++
> 3 files changed, 613 insertions(+), 2 deletions(-)
Thanks!
Reviewed-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH 18/18] genirq: Remove setup_irq() and remove_irq()
From: Linus Walleij @ 2020-02-20 14:49 UTC (permalink / raw)
To: afzal mohammed
Cc: linux-kernel@vger.kernel.org, Thomas Gleixner, Marc Zyngier,
Peter Xu, Brian Masney, Maulik Shah, Lokesh Vutla
In-Reply-To: <0570d4c790f89fa070835fbaa4a106ec07ae6b76.1581478324.git.afzal.mohd.ma@gmail.com>
On Wed, Feb 12, 2020 at 9:06 AM afzal mohammed <afzal.mohd.ma@gmail.com> wrote:
> Now that all the users of setup_irq() & remove_irq() has been replaced
> by request_irq() & free_irq() respectively, delete them.
>
> Signed-off-by: afzal mohammed <afzal.mohd.ma@gmail.com>
Nice, cutting down and simplifying core code.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 16/18] clocksource: Replace setup_irq() by request_irq()
From: Linus Walleij @ 2020-02-20 14:48 UTC (permalink / raw)
To: afzal mohammed
Cc: Kate Stewart, Fabio Estevam, linux-samsung-soc, Kevin Hilman,
Daniel Lezcano, Allison Randal, Krzysztof Kozlowski, Kukjin Kim,
bcm-kernel-feedback-list, NXP Linux Team, Uwe Kleine-König,
Ray Jui, Sascha Hauer, Florian Fainelli, linux-rpi-kernel,
open list:ARM/Amlogic Meson..., Thomas Gleixner, Linux ARM,
Barry Song, Scott Branden, Enrico Weigelt,
linux-kernel@vger.kernel.org, Tony Prisk, Pengutronix Kernel Team,
Greg Kroah-Hartman, Shawn Guo, Nicolas Saenz Julienne
In-Reply-To: <109d17402bc75ed186a2e151dfda1edf05463b5a.1581478324.git.afzal.mohd.ma@gmail.com>
On Wed, Feb 12, 2020 at 9:05 AM afzal mohammed <afzal.mohd.ma@gmail.com> wrote:
> request_irq() is preferred over setup_irq(). Existing callers of
> setup_irq() reached mostly via 'init_IRQ()' & 'time_init()', while
> memory allocators are ready by 'mm_init()'.
>
> Per tglx[1], setup_irq() existed in olden days when allocators were not
> ready by the time early interrupts were initialized.
>
> Hence replace setup_irq() by request_irq().
>
> Seldom remove_irq() usage has been observed coupled with setup_irq(),
> wherever that has been found, it too has been replaced by free_irq().
>
> [1] https://lkml.kernel.org/r/alpine.DEB.2.20.1710191609480.1971@nanos
>
> Signed-off-by: afzal mohammed <afzal.mohd.ma@gmail.com>
This makes the kernel a better place.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
^ permalink raw reply
* Re: [PATCH 16/18] clocksource: Replace setup_irq() by request_irq()
From: Linus Walleij @ 2020-02-20 14:48 UTC (permalink / raw)
To: afzal mohammed
Cc: Kate Stewart, Fabio Estevam, linux-samsung-soc, Kevin Hilman,
Daniel Lezcano, Allison Randal, Krzysztof Kozlowski, Kukjin Kim,
bcm-kernel-feedback-list, NXP Linux Team, Uwe Kleine-König,
Ray Jui, Sascha Hauer, Florian Fainelli, linux-rpi-kernel,
open list:ARM/Amlogic Meson..., Thomas Gleixner, Linux ARM,
Barry Song, Scott Branden, Enrico Weigelt,
linux-kernel@vger.kernel.org, Tony Prisk, Pengutronix Kernel Team,
Greg Kroah-Hartman, Shawn Guo, Nicolas Saenz Julienne
In-Reply-To: <109d17402bc75ed186a2e151dfda1edf05463b5a.1581478324.git.afzal.mohd.ma@gmail.com>
On Wed, Feb 12, 2020 at 9:05 AM afzal mohammed <afzal.mohd.ma@gmail.com> wrote:
> request_irq() is preferred over setup_irq(). Existing callers of
> setup_irq() reached mostly via 'init_IRQ()' & 'time_init()', while
> memory allocators are ready by 'mm_init()'.
>
> Per tglx[1], setup_irq() existed in olden days when allocators were not
> ready by the time early interrupts were initialized.
>
> Hence replace setup_irq() by request_irq().
>
> Seldom remove_irq() usage has been observed coupled with setup_irq(),
> wherever that has been found, it too has been replaced by free_irq().
>
> [1] https://lkml.kernel.org/r/alpine.DEB.2.20.1710191609480.1971@nanos
>
> Signed-off-by: afzal mohammed <afzal.mohd.ma@gmail.com>
This makes the kernel a better place.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* S variable for svn fetcher Was: State of OE world - 2020-02-18
From: Martin Jansa @ 2020-02-20 14:48 UTC (permalink / raw)
To: Khem Raj; +Cc: openembeded-devel
In-Reply-To: <CAMKF1squjefU4rg3Rzn6Xn85mLkRHwWr5jha3YU18Z3rT3J-2g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2571 bytes --]
On Wed, Feb 19, 2020 at 09:29:58AM -0800, Khem Raj wrote:
> http://www.openembedded.org/wiki/Bitbake_World_Status
>
> == Failed tasks /media/ra_build_share/buildlogs/oe/world/dunfell/2020-02-18 ==
>
> INFO: jenkins-job.sh-1.8.46 Complete log available at
> /media/ra_build_share/buildlogs/oe/world/dunfell//media/ra_build_share/buildlogs/oe/world/dunfell/log.report.20200219_150007.log
>
> === common (0) ===
>
> === common-x86 (0) ===
>
> === qemuarm (0) ===
>
> === qemuarm64 (0) ===
>
> === qemux86 (0) ===
>
> === qemux86_64 (0) ===
Looks great! Thanks
I was running some world builds recently as well and was surprised that
there are a few failing recipes in meta-oe:
s3c24xx-gpio
s3c64xx-gpio
wmiconfig
usbpath
which are all using svn fetcher.
Any idea why these aren't shown in our build? I was able to reproduce
this on thud as well as latest master build:
/OE/build/oe-core/meta-openembedded/meta-oe/recipes-support/usbpath/usbpath_svn.bb:do_patch
/OE/build/oe-core/meta-openembedded/meta-oe/recipes-support/samsung-soc-utils/s3c64xx-gpio_svn.bb:do_compile
/OE/build/oe-core/meta-openembedded/meta-oe/recipes-support/samsung-soc-utils/s3c24xx-gpio_svn.bb:do_compile
/OE/build/oe-core/meta-openembedded/meta-oe/recipes-support/samsung-soc-utils/s3c64xx-gpio_svn.bb:do_populate_lic
/OE/build/oe-core/meta-openembedded/meta-oe/recipes-support/samsung-soc-utils/s3c24xx-gpio_svn.bb:do_populate_lic
/OE/build/oe-core/meta-openembedded/meta-oe/recipes-support/wmiconfig/wmiconfig_svn.bb:do_patch
they have all the same root cause and that is that the
S variable points to directory where the sources used to be, but now
they are checked out somewhere else, e.g. s3c24xx-gpio:
LIC_FILES_CHKSUM = "file://gpio.c;endline=12;md5=cfb91c686857b2e60852b4925d90a3e1"
SRC_URI = "svn://svn.openmoko.org/trunk/src/target;module=gpio;protocol=http"
S = "${WORKDIR}/gpio"
And now S looks like this:
$ ls /OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/s3c24xx-gpio/1.0+svnr4949-r2/gpio/
branches trunk
While before I believe it was checking out just this directory (as ${WORKDIR}/gpio):
$ ls /OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/s3c24xx-gpio/1.0+svnr4949-r2/gpio/trunk/src/target/gpio/
gpio.c gpio-glamo.c gpio-s3c6410.c Makefile README
Anyone still actively using svn fetcher for something?
I'll check with even older bitbake to see when it changed, but it's
still surprising that you wouldn't be seeing it with latest bitbake
in world builds.
Cheers,
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 201 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.