* [PATCH v2 1/5] parse-options: add testcases for OPT_CMDMODE()
From: pbonzini @ 2020-02-20 14:15 UTC (permalink / raw)
To: git; +Cc: sunshine
In-Reply-To: <20200220141519.28315-1-pbonzini@redhat.com>
From: Paolo Bonzini <pbonzini@redhat.com>
Before modifying the implementation, ensure that general operation of
OPT_CMDMODE() and detection of incompatible options are covered.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
v1->v2: - split testcases to a separate patch [Junio]
- use test_i18ngrep [Eric]
t/helper/test-parse-options.c | 2 ++
t/t0040-parse-options.sh | 18 ++++++++++++++++++
2 files changed, 20 insertions(+)
diff --git a/t/helper/test-parse-options.c b/t/helper/test-parse-options.c
index af82db06ac..2051ce57db 100644
--- a/t/helper/test-parse-options.c
+++ b/t/helper/test-parse-options.c
@@ -121,6 +121,8 @@ int cmd__parse_options(int argc, const char **argv)
OPT_INTEGER('j', NULL, &integer, "get a integer, too"),
OPT_MAGNITUDE('m', "magnitude", &magnitude, "get a magnitude"),
OPT_SET_INT(0, "set23", &integer, "set integer to 23", 23),
+ OPT_CMDMODE(0, "mode1", &integer, "set integer to 1 (cmdmode option)", 1),
+ OPT_CMDMODE(0, "mode2", &integer, "set integer to 2 (cmdmode option)", 2),
OPT_CALLBACK('L', "length", &integer, "str",
"get length of <str>", length_callback),
OPT_FILENAME('F', "file", &file, "set file to <file>"),
diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
index 9d7c7fdaa2..3483b72db4 100755
--- a/t/t0040-parse-options.sh
+++ b/t/t0040-parse-options.sh
@@ -23,6 +23,8 @@ usage: test-tool parse-options <options>
-j <n> get a integer, too
-m, --magnitude <n> get a magnitude
--set23 set integer to 23
+ --mode1 set integer to 1 (cmdmode option)
+ --mode2 set integer to 2 (cmdmode option)
-L, --length <str> get length of <str>
-F, --file <file> set file to <file>
@@ -324,6 +326,22 @@ test_expect_success 'OPT_NEGBIT() works' '
test-tool parse-options --expect="boolean: 6" -bb --no-neg-or4
'
+test_expect_success 'OPT_CMDMODE() works' '
+ test-tool parse-options --expect="integer: 1" --mode1
+'
+
+test_expect_success 'OPT_CMDMODE() detects incompatibility' '
+ test_must_fail test-tool parse-options --mode1 --mode2 >output 2>output.err &&
+ test_must_be_empty output &&
+ test_i18ngrep "incompatible with --mode" output.err
+'
+
+test_expect_success 'OPT_CMDMODE() detects incompatibility with something else' '
+ test_must_fail test-tool parse-options --set23 --mode2 >output 2>output.err &&
+ test_must_be_empty output &&
+ test_i18ngrep "incompatible with something else" output.err
+'
+
test_expect_success 'OPT_COUNTUP() with PARSE_OPT_NODASH works' '
test-tool parse-options --expect="boolean: 6" + + + + + +
'
--
2.21.1
^ permalink raw reply related
* [PATCH v2 0/5] am: provide a replacement for "cat .git/rebase-apply/patch"
From: pbonzini @ 2020-02-20 14:15 UTC (permalink / raw)
To: git; +Cc: sunshine
From: Paolo Bonzini <pbonzini@redhat.com>
When "git am --show-current-patch" was added in commit 984913a210 ("am:
add --show-current-patch", 2018-02-12), "git am" started recommending it
as a replacement for .git/rebase-merge/patch. Unfortunately the suggestion
is misguided; for example, the output "git am --show-current-patch" cannot
be passed to "git apply" if it is encoded as quoted-printable or base64.
This series adds a new mode to "git am --show-current-patch" in order to
straighten the suggestion. "--show-current-patch" grows an optional
argument, where the default behavior can now also be obtained with
"--show-current-patch=raw" and ".git/rebase-apply/patch" can be retrieved
with "--show-current-patch=diff".
This requires a little surgery in patches 1 and 2 in order to convert
--show-current-patch from OPTION_CMDMODE to OPTION_CALLBACK. After this,
the last two patches implement the new syntax and feature.
Thanks,
Paolo
v1->v2: - split testcases to a separate patch [Junio]
- improve commit messages [Junio]
- fix spacing in designated initializer [Junio]
- use test_i18ngrep [Eric]
- replace abort with BUG [Eric]
- replace "diff|raw" with "(diff|raw)" in docs and help [Eric]
- improve docs wording [Eric]
Paolo Bonzini (5):
parse-options: add testcases for OPT_CMDMODE()
parse-options: convert "command mode" to a flag
am: convert "resume" variable to a struct
am: support --show-current-patch=raw as a synonym
for--show-current-patch
am: support --show-current-patch=diff to retrieve
.git/rebase-apply/patch
Documentation/git-am.txt | 10 +--
builtin/am.c | 96 ++++++++++++++++++++------
contrib/completion/git-completion.bash | 5 ++
parse-options.c | 20 +++---
parse-options.h | 8 +--
t/helper/test-parse-options.c | 2 +
t/t0040-parse-options.sh | 18 +++++
t/t4150-am.sh | 20 ++++++
8 files changed, 140 insertions(+), 39 deletions(-)
--
2.21.1
^ permalink raw reply
* Re: [PATCH 2/4] ceph: consider file's last read/write when calculating wanted caps
From: Jeff Layton @ 2020-02-20 14:14 UTC (permalink / raw)
To: Yan, Zheng, ceph-devel
In-Reply-To: <20200220122630.63170-2-zyan@redhat.com>
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.
> 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
* Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64
From: Joseph Myers @ 2020-02-20 14:14 UTC (permalink / raw)
To: Arnd Bergmann
Cc: fweimer@redhat.com, libc-alpha@sourceware.org, Andreas Schwab,
Vineet Gupta, palmerdabbelt@google.com, Lukasz Majewski,
zongbox@gmail.com, Alistair Francis,
adhemerval.zanella@linaro.org, macro@wdc.com, Alistair Francis,
arcml
In-Reply-To: <CAK8P3a3MTQf_fnEWiGVxzexZzYNQ34h29aNxH_YApmsVzY6OsA@mail.gmail.com>
On Thu, 20 Feb 2020, Arnd Bergmann wrote:
> But surely that structure layout would be the same on ARM and ARC
> as well as all other 32-bit architectures with _TIME_BITS=64, right?
Yes.
> What's wrong with having a single implementation for the most
> recent set of stat syscalls, with the older variants being only compiled
> for architectures that need them to support _TIME_BITS=32 and/or
> _FILE_OFFSET_BITS=32?
The ARC case should be a very simple patch, just changing a few
conditionals so the statx path can be used on an architecture that also
has the old syscalls. No conditionals for whether to build a particular
stat function, or for what that function is called, will be needed. No
conditionals for whether a syscall is available at runtime will be needed,
because at least initially the port will be assuming Linux 5.1 or later.
In the Arm case, the code will need to allow for runtime fallback to old
stat syscalls on kernels without statx, and will need to build the
function using the new layout under a new name. That's a much more
complicated change that can build on top of the ARC change.
--
Joseph S. Myers
joseph@codesourcery.com
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply
* Re: [RFC PATCH v3 25/27] qcow2: Add the 'extended_l2' option and the QCOW2_INCOMPAT_EXTL2 bit
From: Eric Blake @ 2020-02-20 14:12 UTC (permalink / raw)
To: Alberto Garcia, qemu-devel
Cc: Kevin Wolf, Anton Nefedov, qemu-block, Max Reitz,
Vladimir Sementsov-Ogievskiy, Denis V . Lunev
In-Reply-To: <a4892ab10ae557f30dd901d218f06239bca2cd7a.1577014346.git.berto@igalia.com>
On 12/22/19 5:37 AM, Alberto Garcia wrote:
> Now that the implementation of subclusters is complete we can finally
> add the necessary options to create and read images with this feature,
> which we call "extended L2 entries".
>
> Signed-off-by: Alberto Garcia <berto@igalia.com>
> ---
Preliminary review on just interface items (I may do a deeper dive into
the rest of the patch after getting through the series).
> +++ b/block/qcow2.c
> @@ -1383,6 +1383,12 @@ static int coroutine_fn qcow2_do_open(BlockDriverState *bs, QDict *options,
> s->subcluster_size = s->cluster_size / s->subclusters_per_cluster;
> s->subcluster_bits = ctz32(s->subcluster_size);
>
> + if (s->subcluster_size < (1 << MIN_CLUSTER_BITS)) {
> + error_setg(errp, "Unsupported subcluster size: %d", s->subcluster_size);
> + ret = -EINVAL;
> + goto fail;
> + }
> +
> /* Check support for various header values */
> if (header.refcount_order > 6) {
> error_setg(errp, "Reference count entry width too large; may not "
> @@ -2856,6 +2862,11 @@ int qcow2_update_header(BlockDriverState *bs)
> .bit = QCOW2_COMPAT_LAZY_REFCOUNTS_BITNR,
> .name = "lazy refcounts",
> },
> + {
> + .type = QCOW2_FEAT_TYPE_INCOMPATIBLE,
> + .bit = QCOW2_INCOMPAT_EXTL2_BITNR,
> + .name = "extended L2 entries",
> + },
I'd sort this to be grouped with the other INCOMPATIBLE bits (after
"external data file", rather than placing a COMPATIBLE bit in the middle.
Rebase conflict with my patches proposing the addition of an AUTOCLEAR
bit, here and in the impacted iotests. Should be trivial to resolve, by
whoever lands second.
> +++ b/qapi/block-core.json
> @@ -66,6 +66,9 @@
> # standalone (read-only) raw image without looking at qcow2
> # metadata (since: 4.0)
> #
> +# @extended-l2: true if the image has extended L2 entries; only valid for
> +# compat >= 1.1 (since 4.2)
> +#
5.0, now.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
^ permalink raw reply
* Re: NVMe/IB support
From: Max Gurtovoy @ 2020-02-20 14:13 UTC (permalink / raw)
To: Christoph Hellwig, Talker Alex; +Cc: linux-nvme
In-Reply-To: <20200219152053.GA13942@infradead.org>
On 2/19/2020 5:20 PM, Christoph Hellwig wrote:
> On Fri, Feb 07, 2020 at 03:43:22PM +0300, Talker Alex wrote:
>> Hi,
>>
>> is there really exist NVMe/IB solutions?
> All the original NVMeoF development was done on IB, just using the
> RDMA/CM IP based addressing.
I guess we can consider adding this code one day, for users that can't
use RDMA/CM (SRP supports both options).
>
> _______________________________________________
> linux-nvme mailing list
> linux-nvme@lists.infradead.org
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.infradead.org%2Fmailman%2Flistinfo%2Flinux-nvme&data=02%7C01%7Cmaxg%40mellanox.com%7C6a85529d21224f373a3708d7b54f5253%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C637177224606112903&sdata=QpJWMIFVoKqlWZLdlNcbvEnRS2RlLGmTzIiVNoB4ueA%3D&reserved=0
_______________________________________________
linux-nvme mailing list
linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply
* Re: [PATCH 2/5] KVM: arm64: Refactor filtering of ID registers
From: Andre Przywara @ 2020-02-20 14:12 UTC (permalink / raw)
To: Marc Zyngier; +Cc: kvmarm, linux-arm-kernel, kvm
In-Reply-To: <20200216185324.32596-3-maz@kernel.org>
On Sun, 16 Feb 2020 18:53:21 +0000
Marc Zyngier <maz@kernel.org> wrote:
Hi,
> Our current ID register filtering is starting to be a mess of if()
> statements, and isn't going to get any saner.
>
> Let's turn it into a switch(), which has a chance of being more
> readable.
Indeed, much better now.
> Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Thanks,
Andre
> ---
> arch/arm64/kvm/sys_regs.c | 22 +++++++++++++++-------
> 1 file changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index da82c4b03aab..682fedd7700f 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -9,6 +9,7 @@
> * Christoffer Dall <c.dall@virtualopensystems.com>
> */
>
> +#include <linux/bitfield.h>
> #include <linux/bsearch.h>
> #include <linux/kvm_host.h>
> #include <linux/mm.h>
> @@ -1070,6 +1071,8 @@ static bool access_arch_timer(struct kvm_vcpu *vcpu,
> return true;
> }
>
> +#define FEATURE(x) (GENMASK_ULL(x##_SHIFT + 3, x##_SHIFT))
> +
> /* Read a sanitised cpufeature ID register by sys_reg_desc */
> static u64 read_id_reg(const struct kvm_vcpu *vcpu,
> struct sys_reg_desc const *r, bool raz)
> @@ -1078,13 +1081,18 @@ static u64 read_id_reg(const struct kvm_vcpu *vcpu,
> (u32)r->CRn, (u32)r->CRm, (u32)r->Op2);
> u64 val = raz ? 0 : read_sanitised_ftr_reg(id);
>
> - if (id == SYS_ID_AA64PFR0_EL1 && !vcpu_has_sve(vcpu)) {
> - val &= ~(0xfUL << ID_AA64PFR0_SVE_SHIFT);
> - } else if (id == SYS_ID_AA64ISAR1_EL1 && !vcpu_has_ptrauth(vcpu)) {
> - val &= ~((0xfUL << ID_AA64ISAR1_APA_SHIFT) |
> - (0xfUL << ID_AA64ISAR1_API_SHIFT) |
> - (0xfUL << ID_AA64ISAR1_GPA_SHIFT) |
> - (0xfUL << ID_AA64ISAR1_GPI_SHIFT));
> + switch (id) {
> + case SYS_ID_AA64PFR0_EL1:
> + if (!vcpu_has_sve(vcpu))
> + val &= ~FEATURE(ID_AA64PFR0_SVE);
> + break;
> + case SYS_ID_AA64ISAR1_EL1:
> + if (!vcpu_has_ptrauth(vcpu))
> + val &= ~(FEATURE(ID_AA64ISAR1_APA) |
> + FEATURE(ID_AA64ISAR1_API) |
> + FEATURE(ID_AA64ISAR1_GPA) |
> + FEATURE(ID_AA64ISAR1_GPI));
> + break;
> }
>
> return val;
_______________________________________________
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 2/5] KVM: arm64: Refactor filtering of ID registers
From: Andre Przywara @ 2020-02-20 14:12 UTC (permalink / raw)
To: Marc Zyngier; +Cc: kvmarm, linux-arm-kernel, kvm
In-Reply-To: <20200216185324.32596-3-maz@kernel.org>
On Sun, 16 Feb 2020 18:53:21 +0000
Marc Zyngier <maz@kernel.org> wrote:
Hi,
> Our current ID register filtering is starting to be a mess of if()
> statements, and isn't going to get any saner.
>
> Let's turn it into a switch(), which has a chance of being more
> readable.
Indeed, much better now.
> Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Thanks,
Andre
> ---
> arch/arm64/kvm/sys_regs.c | 22 +++++++++++++++-------
> 1 file changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index da82c4b03aab..682fedd7700f 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -9,6 +9,7 @@
> * Christoffer Dall <c.dall@virtualopensystems.com>
> */
>
> +#include <linux/bitfield.h>
> #include <linux/bsearch.h>
> #include <linux/kvm_host.h>
> #include <linux/mm.h>
> @@ -1070,6 +1071,8 @@ static bool access_arch_timer(struct kvm_vcpu *vcpu,
> return true;
> }
>
> +#define FEATURE(x) (GENMASK_ULL(x##_SHIFT + 3, x##_SHIFT))
> +
> /* Read a sanitised cpufeature ID register by sys_reg_desc */
> static u64 read_id_reg(const struct kvm_vcpu *vcpu,
> struct sys_reg_desc const *r, bool raz)
> @@ -1078,13 +1081,18 @@ static u64 read_id_reg(const struct kvm_vcpu *vcpu,
> (u32)r->CRn, (u32)r->CRm, (u32)r->Op2);
> u64 val = raz ? 0 : read_sanitised_ftr_reg(id);
>
> - if (id == SYS_ID_AA64PFR0_EL1 && !vcpu_has_sve(vcpu)) {
> - val &= ~(0xfUL << ID_AA64PFR0_SVE_SHIFT);
> - } else if (id == SYS_ID_AA64ISAR1_EL1 && !vcpu_has_ptrauth(vcpu)) {
> - val &= ~((0xfUL << ID_AA64ISAR1_APA_SHIFT) |
> - (0xfUL << ID_AA64ISAR1_API_SHIFT) |
> - (0xfUL << ID_AA64ISAR1_GPA_SHIFT) |
> - (0xfUL << ID_AA64ISAR1_GPI_SHIFT));
> + switch (id) {
> + case SYS_ID_AA64PFR0_EL1:
> + if (!vcpu_has_sve(vcpu))
> + val &= ~FEATURE(ID_AA64PFR0_SVE);
> + break;
> + case SYS_ID_AA64ISAR1_EL1:
> + if (!vcpu_has_ptrauth(vcpu))
> + val &= ~(FEATURE(ID_AA64ISAR1_APA) |
> + FEATURE(ID_AA64ISAR1_API) |
> + FEATURE(ID_AA64ISAR1_GPA) |
> + FEATURE(ID_AA64ISAR1_GPI));
> + break;
> }
>
> return val;
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply
* Re: [PATCH 2/5] KVM: arm64: Refactor filtering of ID registers
From: Andre Przywara @ 2020-02-20 14:12 UTC (permalink / raw)
To: Marc Zyngier; +Cc: linux-arm-kernel, kvmarm, kvm
In-Reply-To: <20200216185324.32596-3-maz@kernel.org>
On Sun, 16 Feb 2020 18:53:21 +0000
Marc Zyngier <maz@kernel.org> wrote:
Hi,
> Our current ID register filtering is starting to be a mess of if()
> statements, and isn't going to get any saner.
>
> Let's turn it into a switch(), which has a chance of being more
> readable.
Indeed, much better now.
> Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Thanks,
Andre
> ---
> arch/arm64/kvm/sys_regs.c | 22 +++++++++++++++-------
> 1 file changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index da82c4b03aab..682fedd7700f 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -9,6 +9,7 @@
> * Christoffer Dall <c.dall@virtualopensystems.com>
> */
>
> +#include <linux/bitfield.h>
> #include <linux/bsearch.h>
> #include <linux/kvm_host.h>
> #include <linux/mm.h>
> @@ -1070,6 +1071,8 @@ static bool access_arch_timer(struct kvm_vcpu *vcpu,
> return true;
> }
>
> +#define FEATURE(x) (GENMASK_ULL(x##_SHIFT + 3, x##_SHIFT))
> +
> /* Read a sanitised cpufeature ID register by sys_reg_desc */
> static u64 read_id_reg(const struct kvm_vcpu *vcpu,
> struct sys_reg_desc const *r, bool raz)
> @@ -1078,13 +1081,18 @@ static u64 read_id_reg(const struct kvm_vcpu *vcpu,
> (u32)r->CRn, (u32)r->CRm, (u32)r->Op2);
> u64 val = raz ? 0 : read_sanitised_ftr_reg(id);
>
> - if (id == SYS_ID_AA64PFR0_EL1 && !vcpu_has_sve(vcpu)) {
> - val &= ~(0xfUL << ID_AA64PFR0_SVE_SHIFT);
> - } else if (id == SYS_ID_AA64ISAR1_EL1 && !vcpu_has_ptrauth(vcpu)) {
> - val &= ~((0xfUL << ID_AA64ISAR1_APA_SHIFT) |
> - (0xfUL << ID_AA64ISAR1_API_SHIFT) |
> - (0xfUL << ID_AA64ISAR1_GPA_SHIFT) |
> - (0xfUL << ID_AA64ISAR1_GPI_SHIFT));
> + switch (id) {
> + case SYS_ID_AA64PFR0_EL1:
> + if (!vcpu_has_sve(vcpu))
> + val &= ~FEATURE(ID_AA64PFR0_SVE);
> + break;
> + case SYS_ID_AA64ISAR1_EL1:
> + if (!vcpu_has_ptrauth(vcpu))
> + val &= ~(FEATURE(ID_AA64ISAR1_APA) |
> + FEATURE(ID_AA64ISAR1_API) |
> + FEATURE(ID_AA64ISAR1_GPA) |
> + FEATURE(ID_AA64ISAR1_GPI));
> + break;
> }
>
> return val;
^ permalink raw reply
* Re: [PATCH 1/2] xfs: ratelimit xfs_buf_ioerror_alert
From: Brian Foster @ 2020-02-20 14:12 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-xfs
In-Reply-To: <20200220040549.366547-2-hch@lst.de>
On Wed, Feb 19, 2020 at 08:05:48PM -0800, Christoph Hellwig wrote:
> Use printk_ratelimit() to limit the amount of messages printed from
> xfs_buf_ioerror_alert. Without that a failing device causes a large
> number of errors that doesn't really help debugging the underling
> issue.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> fs/xfs/xfs_buf.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c
> index 217e4f82a44a..e010680a665e 100644
> --- a/fs/xfs/xfs_buf.c
> +++ b/fs/xfs/xfs_buf.c
> @@ -1238,6 +1238,8 @@ xfs_buf_ioerror_alert(
> struct xfs_buf *bp,
> xfs_failaddr_t func)
> {
> + if (!printk_ratelimit())
> + return;
xfs_alert_ratelimited() ?
Brian
> xfs_alert(bp->b_mount,
> "metadata I/O error in \"%pS\" at daddr 0x%llx len %d error %d",
> func, (uint64_t)XFS_BUF_ADDR(bp), bp->b_length,
> --
> 2.24.1
>
^ permalink raw reply
* [PATCH 1/2] spi: fsl-lpspi: remove unneeded array
From: Oleksandr Suvorov @ 2020-02-20 14:11 UTC (permalink / raw)
To: linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Oleksandr Suvorov, Oleksandr Suvorov, Marcel Ziswiler,
Igor Opanyuk, Philippe Schenker, Mark Brown
In-Reply-To: <20200220141143.3902922-1-oleksandr.suvorov@toradex.com>
- replace the array with the shift operation
- remove the extra comparing operation.
Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
---
drivers/spi/spi-fsl-lpspi.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/spi/spi-fsl-lpspi.c b/drivers/spi/spi-fsl-lpspi.c
index d0b8cc741a24..298329b781d2 100644
--- a/drivers/spi/spi-fsl-lpspi.c
+++ b/drivers/spi/spi-fsl-lpspi.c
@@ -86,8 +86,6 @@
#define TCR_RXMSK BIT(19)
#define TCR_TXMSK BIT(18)
-static int clkdivs[] = {1, 2, 4, 8, 16, 32, 64, 128};
-
struct lpspi_config {
u8 bpw;
u8 chip_select;
@@ -331,15 +329,14 @@ static int fsl_lpspi_set_bitrate(struct fsl_lpspi_data *fsl_lpspi)
}
for (prescale = 0; prescale < 8; prescale++) {
- scldiv = perclk_rate /
- (clkdivs[prescale] * config.speed_hz) - 2;
+ scldiv = perclk_rate / config.speed_hz / (1 << prescale) - 2;
if (scldiv < 256) {
fsl_lpspi->config.prescale = prescale;
break;
}
}
- if (prescale == 8 && scldiv >= 256)
+ if (scldiv >= 256)
return -EINVAL;
writel(scldiv | (scldiv << 8) | ((scldiv >> 1) << 16),
--
2.24.1
^ permalink raw reply related
* [PATCH 0/2] trivial fixes for fsl-spi and spidev
From: Oleksandr Suvorov @ 2020-02-20 14:11 UTC (permalink / raw)
To: linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Oleksandr Suvorov, Oleksandr Suvorov, Marcel Ziswiler,
Igor Opanyuk, Philippe Schenker, Mark Brown
- the memory optimization in fsl-spi
- the fix of the max speed setting bug in spidev
Oleksandr Suvorov (2):
spi: fsl-lpspi: remove unneeded array
spi: spidev: fix a max speed setting
drivers/spi/spi-fsl-lpspi.c | 7 ++-----
drivers/spi/spidev.c | 10 ++++++----
2 files changed, 8 insertions(+), 9 deletions(-)
--
2.24.1
^ permalink raw reply
* [PATCH 2/2] spi: spidev: fix a max speed setting
From: Oleksandr Suvorov @ 2020-02-20 14:11 UTC (permalink / raw)
To: linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Oleksandr Suvorov, Oleksandr Suvorov, Marcel Ziswiler,
Igor Opanyuk, Philippe Schenker, Mark Brown
In-Reply-To: <20200220141143.3902922-1-oleksandr.suvorov@toradex.com>
SPI_IOC_WR_MAX_SPEED_HZ command always sets spi->max_speed_hz
to the initial value come from DT.
It leads to set a wrong max speed with IOCTL call.
Fix the logic of a max speed assignment.
Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
---
drivers/spi/spidev.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spidev.c b/drivers/spi/spidev.c
index 1e217e3e9486..b9b3ac70eb18 100644
--- a/drivers/spi/spidev.c
+++ b/drivers/spi/spidev.c
@@ -449,11 +449,13 @@ spidev_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
spi->max_speed_hz = tmp;
retval = spi_setup(spi);
- if (retval >= 0)
+ if (retval) {
+ spi->max_speed_hz = save;
+ } else {
spidev->speed_hz = tmp;
- else
- dev_dbg(&spi->dev, "%d Hz (max)\n", tmp);
- spi->max_speed_hz = save;
+ dev_dbg(&spi->dev, "%d Hz (max)\n",
+ spidev->speed_hz);
+ }
}
break;
--
2.24.1
^ permalink raw reply related
* [PATCH 1/2] spi: fsl-lpspi: remove unneeded array
From: Oleksandr Suvorov @ 2020-02-20 14:11 UTC (permalink / raw)
To: linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Oleksandr Suvorov, Oleksandr Suvorov, Marcel Ziswiler,
Igor Opanyuk, Philippe Schenker, Mark Brown
In-Reply-To: <20200220141143.3902922-1-oleksandr.suvorov-2KBjVHiyJgBBDgjK7y7TUQ@public.gmane.org>
- replace the array with the shift operation
- remove the extra comparing operation.
Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov-2KBjVHiyJgBBDgjK7y7TUQ@public.gmane.org>
---
drivers/spi/spi-fsl-lpspi.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/spi/spi-fsl-lpspi.c b/drivers/spi/spi-fsl-lpspi.c
index d0b8cc741a24..298329b781d2 100644
--- a/drivers/spi/spi-fsl-lpspi.c
+++ b/drivers/spi/spi-fsl-lpspi.c
@@ -86,8 +86,6 @@
#define TCR_RXMSK BIT(19)
#define TCR_TXMSK BIT(18)
-static int clkdivs[] = {1, 2, 4, 8, 16, 32, 64, 128};
-
struct lpspi_config {
u8 bpw;
u8 chip_select;
@@ -331,15 +329,14 @@ static int fsl_lpspi_set_bitrate(struct fsl_lpspi_data *fsl_lpspi)
}
for (prescale = 0; prescale < 8; prescale++) {
- scldiv = perclk_rate /
- (clkdivs[prescale] * config.speed_hz) - 2;
+ scldiv = perclk_rate / config.speed_hz / (1 << prescale) - 2;
if (scldiv < 256) {
fsl_lpspi->config.prescale = prescale;
break;
}
}
- if (prescale == 8 && scldiv >= 256)
+ if (scldiv >= 256)
return -EINVAL;
writel(scldiv | (scldiv << 8) | ((scldiv >> 1) << 16),
--
2.24.1
^ permalink raw reply related
* Re: [Xen-devel] [PATCH] rwlock: allow recursive read locking when already locked in write mode
From: Roger Pau Monné @ 2020-02-20 14:11 UTC (permalink / raw)
To: Jan Beulich
Cc: Jürgen Groß, Stefano Stabellini, Julien Grall, Wei Liu,
Konrad Rzeszutek Wilk, George Dunlap, Andrew Cooper, Ian Jackson,
xen-devel
In-Reply-To: <ecf1c47c-4cbb-c7c4-7ccf-d3620a1992b3@suse.com>
On Thu, Feb 20, 2020 at 01:48:54PM +0100, Jan Beulich wrote:
> On 20.02.2020 13:02, Roger Pau Monne wrote:
> > I've done some testing and at least the CPU down case is fixed now.
> > Posting early in order to get feedback on the approach taken.
>
> Looks good, thanks, just a question and two comments:
>
> > --- a/xen/include/xen/rwlock.h
> > +++ b/xen/include/xen/rwlock.h
> > @@ -20,21 +20,30 @@ typedef struct {
> > #define DEFINE_RWLOCK(l) rwlock_t l = RW_LOCK_UNLOCKED
> > #define rwlock_init(l) (*(l) = (rwlock_t)RW_LOCK_UNLOCKED)
> >
> > -/*
> > - * Writer states & reader shift and bias.
> > - *
> > - * Writer field is 8 bit to allow for potential optimisation, see
> > - * _write_unlock().
> > - */
> > -#define _QW_WAITING 1 /* A writer is waiting */
> > -#define _QW_LOCKED 0xff /* A writer holds the lock */
> > -#define _QW_WMASK 0xff /* Writer mask.*/
> > -#define _QR_SHIFT 8 /* Reader count shift */
> > +/* Writer states & reader shift and bias. */
> > +#define _QW_WAITING 1 /* A writer is waiting */
> > +#define _QW_LOCKED 3 /* A writer holds the lock */
>
> Aiui things would work equally well if 2 was used here?
I think so, I left it as 3 because previously LOCKED would also
include WAITING, and I didn't want to change it in case I've missed
some code path that was relying on that.
>
> > +#define _QW_WMASK 3 /* Writer mask */
> > +#define _QW_CPUSHIFT 2 /* Writer CPU shift */
> > +#define _QW_CPUMASK 0x3ffc /* Writer CPU mask */
>
> At least on x86, the shift involved here is quite certainly
> more expensive than using wider immediates on AND and CMP
> resulting from the _QW_MASK-based comparisons. I'd therefore
> like to suggest to put the CPU in the low 12 bits.
Hm right. The LOCKED and WAITING bits don't need shifting anyway.
>
> Another option is to use the recurse_cpu field of the
> associated spin lock: The field is used for recursive locks
> only, and hence the only conflict would be with
> _spin_is_locked(), which we don't (and in the future then
> also shouldn't) use on this lock.
I looked into that also, but things get more complicated AFAICT, as it's
not possible to atomically fetch the state of the lock and the owner
CPU at the same time. Neither you could set the LOCKED bit and the CPU
at the same time.
>
> > @@ -166,7 +180,8 @@ static inline void _write_unlock(rwlock_t *lock)
> > * If the writer field is atomic, it can be cleared directly.
> > * Otherwise, an atomic subtraction will be used to clear it.
> > */
> > - atomic_sub(_QW_LOCKED, &lock->cnts);
> > + ASSERT(_is_write_locked_by_me(atomic_read(&lock->cnts)));
> > + atomic_sub(_write_lock_val(), &lock->cnts);
>
> I think this would be more efficient with atomic_and(), not
> the least because of the then avoided smp_processor_id().
> Whether to mask off just _QW_WMASK or also the CPU number of
> the last write owner would need to be determined. But with
> using subtraction, in case of problems it'll likely be
> harder to understand what actually went on, from looking at
> the resulting state of the lock (this is in part a pre-
> existing problem, but gets worse with subtraction of CPU
> numbers).
Right, a mask would be better. Right now both need to be cleared (the
LOCKED and the CPU fields) as there's code that relies on !lock->cnts
as a way to determine that the lock is not read or write locked. If we
left the CPU lying around those checks would need to be adjusted.
Thanks, Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* [PATCH 0/2] trivial fixes for fsl-spi and spidev
From: Oleksandr Suvorov @ 2020-02-20 14:11 UTC (permalink / raw)
To: linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Oleksandr Suvorov, Oleksandr Suvorov, Marcel Ziswiler,
Igor Opanyuk, Philippe Schenker, Mark Brown
- the memory optimization in fsl-spi
- the fix of the max speed setting bug in spidev
Oleksandr Suvorov (2):
spi: fsl-lpspi: remove unneeded array
spi: spidev: fix a max speed setting
drivers/spi/spi-fsl-lpspi.c | 7 ++-----
drivers/spi/spidev.c | 10 ++++++----
2 files changed, 8 insertions(+), 9 deletions(-)
--
2.24.1
^ permalink raw reply
* [dpdk-dev] [PATCH v2] cmdline: increase maximum line length
From: Wisam Jaddo @ 2020-02-20 14:10 UTC (permalink / raw)
To: dev, rasland, thomas; +Cc: olivier.matz, bernard.iremonger, stable
The current length of buffer is not enough to
fit all allowed items/actions, thus it will
block a lot of testing.
Cc: stable@dpdk.org
Signed-off-by: Wisam Jaddo <wisamm@mellanox.com>
---
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
* [PATCH liburing] man/io_uring_setup.2: fix 'sq_thread_idle' description
From: Stefano Garzarella @ 2020-02-20 14:08 UTC (permalink / raw)
To: Jens Axboe; +Cc: io-uring, linux-kernel
In the kernel we are using msecs_to_jiffies() to convert the
'sq_thread_idle' parameter, provided by the user, in jiffies.
So, the value is interpreted in milliseconds and not microseconds.
Fixes: 59bb09c553eb ("man: add io_uring_setup.2 man page")
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
---
man/io_uring_setup.2 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/man/io_uring_setup.2 b/man/io_uring_setup.2
index 4057e4b..20c67dc 100644
--- a/man/io_uring_setup.2
+++ b/man/io_uring_setup.2
@@ -82,7 +82,7 @@ doing a single system call.
If the kernel thread is idle for more than
.I sq_thread_idle
-microseconds, it will set the
+milliseconds, it will set the
.B IORING_SQ_NEED_WAKEUP
bit in the
.I flags
--
2.24.1
^ permalink raw reply related
* Re: [PATCH v8 15/15] bugreport: summarize contents of alternates file
From: Johannes Schindelin @ 2020-02-20 14:08 UTC (permalink / raw)
To: Emily Shaffer; +Cc: git
In-Reply-To: <20200220015858.181086-16-emilyshaffer@google.com>
Hi Emily,
On Wed, 19 Feb 2020, Emily Shaffer wrote:
> In some cases, it could be that the user is having a problem with an
> object which isn't present in their normal object directory. We can get
> a hint that that might be the case by examining the list of alternates
> where their object may be stored instead. Since paths to alternates may
> be sensitive, we'll instead count how many alternates have been
> specified and note how many of them exist or are broken.
>
> While object-cache.h describes a function "foreach_alt_odb()", this
> function does not provide information on broken alternates, which are
> skipped over in "link_alt_odb_entry()". Since the goal is to identify
> missing alternates, we can gather the contents of
> .git/objects/info/alternates manually.
Makes sense.
> diff --git a/bugreport.c b/bugreport.c
> index 1d61e0f642..1640a71086 100644
> --- a/bugreport.c
> +++ b/bugreport.c
> @@ -255,6 +255,48 @@ static void get_object_info_summary(struct strbuf *obj_info, int nongit)
> strbuf_release(&dirpath);
> }
>
> +static void get_alternates_summary(struct strbuf *alternates_info, int nongit)
> +{
> + struct strbuf alternates_path = STRBUF_INIT;
> + struct strbuf alternate = STRBUF_INIT;
I am not sure that those variables and the parameter need to repeat
"alternate", I find it rather distracting. If it were me, I would rename
the parameter to `info`, the first strbuf to `path` and the second to
`line`. This function is so specific to read the alternates file that it
is quite obvious what their roles are.
> + FILE *file;
> + size_t exists = 0, broken = 0;
> +
> + if (nongit) {
> + strbuf_addstr(alternates_info,
> + "not run from a git repository - alternates unavailable\n");
> + return;
> + }
> +
> + strbuf_addstr(&alternates_path, get_object_directory());
> + strbuf_complete(&alternates_path, '/');
> + strbuf_addstr(&alternates_path, "info/alternates");
> +
> + file = fopen(alternates_path.buf, "r");
> + if (!file) {
> + strbuf_addstr(alternates_info, "No alternates file found.\n");
> + strbuf_release(&alternates_path);
> + return;
> + }
> +
> + while (strbuf_getline(&alternate, file) != EOF) {
> + if (!access(alternate.buf, F_OK))
Should we make sure that the alternate is actually valid objects directory
here? Like, look whether it is a directory, not a file or a (possibly
dangling) symbolic link. This seems to be the only check
`alt_odb_usable()` performs, so that should probably be good enough here,
too.
> + exists++;
> + else
> + broken++;
> + }
> +
> + strbuf_addf(alternates_info,
> + "%zd alternates found (%zd working, %zd broken)\n",
Sadly, `%zd` is not portable. Therefore, `pu` (and `es/bugreport`) do not
even _build_ on Windows. I need this to make it work:
-- snip --
diff --git a/bugreport.c b/bugreport.c
index 3770aa73fae..5033668e22f 100644
--- a/bugreport.c
+++ b/bugreport.c
@@ -287,10 +287,11 @@ static void get_alternates_summary(struct strbuf *alternates_info, int nongit)
}
strbuf_addf(alternates_info,
- "%zd alternates found (%zd working, %zd broken)\n",
- exists + broken,
- exists,
- broken);
+ "%"PRIuMAX" alternates found "
+ "(%"PRIuMAX" working, %"PRIuMAX" broken)\n",
+ (uintmax_t)(exists + broken),
+ (uintmax_t)exists,
+ (uintmax_t)broken);
fclose(file);
strbuf_release(&alternate);
-- snap --
Could you incorporate that into the next iteration, please?
Thanks,
Dscho
> + exists + broken,
> + exists,
> + broken);
> +
> + fclose(file);
> + strbuf_release(&alternate);
> + strbuf_release(&alternates_path);
> +}
> +
> static const char * const bugreport_usage[] = {
> N_("git bugreport [-o|--output-directory <file>] [-s|--suffix <format>]"),
> NULL
> @@ -355,6 +397,9 @@ int cmd_main(int argc, const char **argv)
> get_header(&buffer, "Object Info Summary");
> get_object_info_summary(&buffer, nongit_ok);
>
> + get_header(&buffer, "Alternates");
> + get_alternates_summary(&buffer, nongit_ok);
> +
> report = fopen_for_writing(report_path.buf);
>
> if (report == NULL) {
> --
> 2.25.0.265.gbab2e86ba0-goog
>
>
^ permalink raw reply related
* Re: [PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio graph card
From: Peter Ujfalusi @ 2020-02-20 14:07 UTC (permalink / raw)
To: Tony Lindgren
Cc: Kuninori Morimoto, Mark Brown, Liam Girdwood, Jaroslav Kysela,
Takashi Iwai, alsa-devel, linux-kernel, linux-omap, Aaro Koskinen,
Arthur D ., Jarkko Nikula, Merlijn Wajer, Pavel Machek,
Sebastian Reichel
In-Reply-To: <20200218152833.GH35972@atomide.com>
On 18/02/2020 17.28, Tony Lindgren wrote:
> * Peter Ujfalusi <peter.ujfalusi@ti.com> [200218 12:44]:
>> Hi Tony,
>>
>> On 18/02/2020 1.10, Tony Lindgren wrote:
>>> * Peter Ujfalusi <peter.ujfalusi@ti.com> [200217 12:10]:
>>>> On 14/02/2020 19.03, Tony Lindgren wrote:
>>>>> But right now in droid4 voice call case mcbsp is just the i2s transport,
>>>>> and everything happens betwee the modem and the cpcap pmic.
>>>>
>>>> Iow you don't need McBSP DAI at all. If you would have added the dummy
>>>> codec to McBSP !3 and use that, it would work in a same way, or to DMIC
>>>> or McPDM...
>>>>
>>>> The McBSP ops are NULL for the dummy dai, so McBSP is turned off.
>>>
>>> Hmm yeah I don't know if the cpcap codec on the same mcbsp needs
>>> mcbsp for voice call.
>>>
>>> According to Sebastian sounds like mcbsp can be idle at that point.
>>>
>>> But what about capture of voice call at the mcbsp from the
>>> TDM slot? In that case mcbsp would be active.
>>
>> Sure, but with the dummy dai it won't....
>
> Right. I'm not attached to the dummy dai, but looks like currently
> snd-soc-audio-graph-card won't work without it.
The generic cards will link up a dummy dai/codec when it is needed by DPMC.
> And we potentially
> do need a place to configure TDM slot specific stuff for mcbsp.
Yes, but you still have one port and one endpoint should not change the
configuration which is already in used for the other endpoint.
>> If I understand correctly the HW setup:
>> McBSP2 -> CPCAP_hifi (only playback)
>>
>> CPCAP_voice is the i2s clock master.
>> McBSP3, CPCAP_voice, MDM6600 and WL1285 are all connected together via
>> i2s lines.
>>
>> In case of Voice call with analog mic/speaker only CPCAP_voice and
>> MDM6600 is used.
>> In case of Voice call with BT only MDM6600 and WL1285 is used (but
>> CPCAP_voice must provide the clocks?)
>
> Yes my guess is cpcap voice is the clock master in that case.
> It should show up from the cpcap register dump from Android with
> audio playing to a bluetooth headset.
OK.
>> In case you would have any algorithm running on OMAP4 for the calls,
>> then you will have McBSP3 inserted and used between MDM6600 and
>> CPAC_voice/WL1285.
>> Similarly, if you would like to tap in and record the data from the bus
>> you will have McBSP3 enabled.
>>
>> The simplest use cases you want to support:
>> A. McBSP3 <-> CPCAP_voice (playback/capture)
>> B. MDM6600 <-> CPCAP_voice (handset mic/speaker voice call)
>> C. MDM6600 <-> WL1285 (BT voice call)
>> D. McBSP3 <-> BT (VoIP?)
>>
>> I would not bother with recording the call as you would need tom
>> reconfigure the McBSP playback pin (is it even possible) as input to
>> OMAP4, I think..
>
> Oh, I think there are Android apps to do that though.. Never tried
> if they work on droid4. But if they do, doing a register dump of
> mcbsp3 would show up how it's configured.
I don't see how you could record the data from the line which is
connected to McBSP_DX pin (the pin is output).
But I might be missing something.
>> B/C is codec2codec, McBSP3 is not involved at all.
>> A/D is when McBSP3 is used only.
>>
>> Imho this can be represented as
>> McBSP2: 1 port
>> 1.1: to CPCAP_hifi
>>
>> McBSP3: 1 port, 2 endpoint
>> 2.1: to CPCAP_voice
>> 2.2: to WL1285
>> CPCAP: 2 ports
>> hifi: 3.1: to McBSP2
>> voice: 4.1: to McBSP3
>> 4.2: to MDM6600
>> MDM6600: 2 ports
>> 5.1: to CPAC_voice
>> 5.2: to WL1285
>> WL1285: 2 ports
>> 6.1: to McBSP3
>> 6.2: to MDM6600
>>
>> The machine driver should switch between the graph links based on the
>> use case for the interconnected devices:
>> A: 2.2 <-> 4.1
>> B: 4.2 <-> 5.1
>> C: 6.2 <-> 5.1
>> D: 2.2 <-> 6.1
>
> OK
>
>> Can a generic card provide such a functionality?
>
> I think the link for the patches you posted is patching the
> snd-soc-audio-graph-card already?
Yes it does, but the functionality is there via custom machine drivers.
What I afraid is that such a complex wiring as the Droid4 have it might
be not possible to use a generic - fits everything - driver without
making it a customized one ;)
Otho, if the only thing is the machine level DAPM switching and linking
the paths then it might be relatively straight forward to extend the
simple-card family.
>> In case of B/C you should not have a running stream imho.
>> In all cases CPCAP_voice should be able to run the clocks on i2s, even
>> if it is not used by the audio setup.
>> Not sure if you can just turn Wl1285 as master, but it is possible that
>> it is master, but silent when it is not used?
>
> Yeah, no idea.. But that's easy to configure in the dts based on
> the graph bindings :)
Yep, indeed.
>> I'm not sure if we should span out dummy dais for endpoints within a
>> port. Imho the port _is_ the dai. Different endpoints might use
>> different TDM slots on the port (or the same slot, which makes them
>> exclusive).
>
> Right. So right now it seems that for snd-soc-audio-graph-card
> needs the dummy dai, but it's unclear what would need to be
> changed to not use a dummy dai for mcbsp.
Since simple-card family can and will connect up dummy dai/codec when
needed based on the setup, I would look at that and make it do so.
> The dts snippets I posted earlier do follow the graph bindings
> as far as I know. But just to confirm, do you see any need to
> move things around there?
It also states that a port is a physical port which can have multiple
endpoints. But multiple endpoint != DAI. port == dai.
>>>>>>>> I know it was discussed, but can not find the mail:
>>>>>>>> Can you brief again on the audio connection?
>>>>>>>
>>>>>>> Below is a link to a mailing list thread where Sebastian describes
>>>>>>> the audio connection:
>>>>>>>
>>>>>>> https://lkml.org/lkml/2018/3/28/881
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>>>> Do you have branch with working code?
>>>>>>>
>>>>>>> Yeah I have slightly older set of the patches in my droid4-pending-v5.5
>>>>>>> kernel.org git branch with voice calls working.
>>>>>>
>>>>>> I think I should put my droid4 out and try to get it working...
>>>>>> Do you have a link for dummies to follow to get started? ;)
>>>>>
>>>>> Probably the easiest one to use right now is the Maemo-leste devuan based
>>>>> test image using v5.5 kernel + modem and audio patches:
>>>>>
>>>>> https://leste.maemo.org/Motorola_Droid_4
>>>>>
>>>>> Just use a decent speed micro-sd card rated "a1" for example.
>>>>
>>>> Cool. Now I can dual boot the droid4 :D
>>>> I needed to rewrite the /etc/shadow to get a known root password so I
>>>> can log in.
>>>
>>> Not sure if you mean password for the droid4-kexecboot or the
>>> Linux distro you installed..
>>
>> It was for the maemo-leste.
>> Bringing up Gentoo will be a bit harder as I don't have wifi stuff in my
>> reference image...
>
> Gentoo cool :)
>
> I've had good luck with just plain alpine armv7 edge, the package
> updates work very fast for a slow system. The musl stuff requires
> running stellarium with 3d acceleration in a minimal devuan or
> whatever chroot environment though for stellarium etc..
I see, I might go via the lazy route and take buildroot ;)
>>> But for droid4-kexecboot, you
>>> can configure it to automatically download new kernels over wlan.
>>> There's some info on the machine specific password and how to
>>> configure wlan in the droid4-kexecboot buildroot commits here:
>>>
>>> https://github.com/tmlind/buildroot/commits/droid4-kexecboot-2017.11
>>>
>>>> Wifi is up, so in theory I can scp kernel/dtb to /boot/boot/ and update
>>>> the /boot/boot/boot.cfg to boot my kernel, right?
>>>
>>> Yeah you can update kernels and modules over wlan from the distro(s)
>>> you have configured, and also from droid4-kexecboot as above.
>>
>> I need to try droid4-kexecboot's wifi support then.
>
> Yeah you need to configure wpa_supplicant.conf and wlan.conf or
> whatever it was called. And make sure you have copied the old
> stock v3.0.8 kernel wlan modules and firmware as mentioned in
> the droid4-kexecboot git readme and install files.
OK.
> Oh, and also read about the flags you need to use for mkfs.ext4 if
> doing mkfs.ext4 on a PC, the old v3.0.8 kernel won't understand
> all the new flags if you want a partition to be readable for the
> droid4-kexecboot bootloader. And also the all the old Android
> distros currently still stuck with the ancient v3.0.8 kernel :p
I see, thanks for the warning!
>
> Regards,
>
> Tony
>
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply
* Re: [PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio graph card
From: Peter Ujfalusi @ 2020-02-20 14:07 UTC (permalink / raw)
To: Tony Lindgren
Cc: alsa-devel, linux-omap, Kuninori Morimoto, Aaro Koskinen,
linux-kernel, Merlijn Wajer, Takashi Iwai, Liam Girdwood,
Mark Brown, Pavel Machek, Sebastian Reichel, Arthur D .,
Jarkko Nikula
In-Reply-To: <20200218152833.GH35972@atomide.com>
On 18/02/2020 17.28, Tony Lindgren wrote:
> * Peter Ujfalusi <peter.ujfalusi@ti.com> [200218 12:44]:
>> Hi Tony,
>>
>> On 18/02/2020 1.10, Tony Lindgren wrote:
>>> * Peter Ujfalusi <peter.ujfalusi@ti.com> [200217 12:10]:
>>>> On 14/02/2020 19.03, Tony Lindgren wrote:
>>>>> But right now in droid4 voice call case mcbsp is just the i2s transport,
>>>>> and everything happens betwee the modem and the cpcap pmic.
>>>>
>>>> Iow you don't need McBSP DAI at all. If you would have added the dummy
>>>> codec to McBSP !3 and use that, it would work in a same way, or to DMIC
>>>> or McPDM...
>>>>
>>>> The McBSP ops are NULL for the dummy dai, so McBSP is turned off.
>>>
>>> Hmm yeah I don't know if the cpcap codec on the same mcbsp needs
>>> mcbsp for voice call.
>>>
>>> According to Sebastian sounds like mcbsp can be idle at that point.
>>>
>>> But what about capture of voice call at the mcbsp from the
>>> TDM slot? In that case mcbsp would be active.
>>
>> Sure, but with the dummy dai it won't....
>
> Right. I'm not attached to the dummy dai, but looks like currently
> snd-soc-audio-graph-card won't work without it.
The generic cards will link up a dummy dai/codec when it is needed by DPMC.
> And we potentially
> do need a place to configure TDM slot specific stuff for mcbsp.
Yes, but you still have one port and one endpoint should not change the
configuration which is already in used for the other endpoint.
>> If I understand correctly the HW setup:
>> McBSP2 -> CPCAP_hifi (only playback)
>>
>> CPCAP_voice is the i2s clock master.
>> McBSP3, CPCAP_voice, MDM6600 and WL1285 are all connected together via
>> i2s lines.
>>
>> In case of Voice call with analog mic/speaker only CPCAP_voice and
>> MDM6600 is used.
>> In case of Voice call with BT only MDM6600 and WL1285 is used (but
>> CPCAP_voice must provide the clocks?)
>
> Yes my guess is cpcap voice is the clock master in that case.
> It should show up from the cpcap register dump from Android with
> audio playing to a bluetooth headset.
OK.
>> In case you would have any algorithm running on OMAP4 for the calls,
>> then you will have McBSP3 inserted and used between MDM6600 and
>> CPAC_voice/WL1285.
>> Similarly, if you would like to tap in and record the data from the bus
>> you will have McBSP3 enabled.
>>
>> The simplest use cases you want to support:
>> A. McBSP3 <-> CPCAP_voice (playback/capture)
>> B. MDM6600 <-> CPCAP_voice (handset mic/speaker voice call)
>> C. MDM6600 <-> WL1285 (BT voice call)
>> D. McBSP3 <-> BT (VoIP?)
>>
>> I would not bother with recording the call as you would need tom
>> reconfigure the McBSP playback pin (is it even possible) as input to
>> OMAP4, I think..
>
> Oh, I think there are Android apps to do that though.. Never tried
> if they work on droid4. But if they do, doing a register dump of
> mcbsp3 would show up how it's configured.
I don't see how you could record the data from the line which is
connected to McBSP_DX pin (the pin is output).
But I might be missing something.
>> B/C is codec2codec, McBSP3 is not involved at all.
>> A/D is when McBSP3 is used only.
>>
>> Imho this can be represented as
>> McBSP2: 1 port
>> 1.1: to CPCAP_hifi
>>
>> McBSP3: 1 port, 2 endpoint
>> 2.1: to CPCAP_voice
>> 2.2: to WL1285
>> CPCAP: 2 ports
>> hifi: 3.1: to McBSP2
>> voice: 4.1: to McBSP3
>> 4.2: to MDM6600
>> MDM6600: 2 ports
>> 5.1: to CPAC_voice
>> 5.2: to WL1285
>> WL1285: 2 ports
>> 6.1: to McBSP3
>> 6.2: to MDM6600
>>
>> The machine driver should switch between the graph links based on the
>> use case for the interconnected devices:
>> A: 2.2 <-> 4.1
>> B: 4.2 <-> 5.1
>> C: 6.2 <-> 5.1
>> D: 2.2 <-> 6.1
>
> OK
>
>> Can a generic card provide such a functionality?
>
> I think the link for the patches you posted is patching the
> snd-soc-audio-graph-card already?
Yes it does, but the functionality is there via custom machine drivers.
What I afraid is that such a complex wiring as the Droid4 have it might
be not possible to use a generic - fits everything - driver without
making it a customized one ;)
Otho, if the only thing is the machine level DAPM switching and linking
the paths then it might be relatively straight forward to extend the
simple-card family.
>> In case of B/C you should not have a running stream imho.
>> In all cases CPCAP_voice should be able to run the clocks on i2s, even
>> if it is not used by the audio setup.
>> Not sure if you can just turn Wl1285 as master, but it is possible that
>> it is master, but silent when it is not used?
>
> Yeah, no idea.. But that's easy to configure in the dts based on
> the graph bindings :)
Yep, indeed.
>> I'm not sure if we should span out dummy dais for endpoints within a
>> port. Imho the port _is_ the dai. Different endpoints might use
>> different TDM slots on the port (or the same slot, which makes them
>> exclusive).
>
> Right. So right now it seems that for snd-soc-audio-graph-card
> needs the dummy dai, but it's unclear what would need to be
> changed to not use a dummy dai for mcbsp.
Since simple-card family can and will connect up dummy dai/codec when
needed based on the setup, I would look at that and make it do so.
> The dts snippets I posted earlier do follow the graph bindings
> as far as I know. But just to confirm, do you see any need to
> move things around there?
It also states that a port is a physical port which can have multiple
endpoints. But multiple endpoint != DAI. port == dai.
>>>>>>>> I know it was discussed, but can not find the mail:
>>>>>>>> Can you brief again on the audio connection?
>>>>>>>
>>>>>>> Below is a link to a mailing list thread where Sebastian describes
>>>>>>> the audio connection:
>>>>>>>
>>>>>>> https://lkml.org/lkml/2018/3/28/881
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>>>> Do you have branch with working code?
>>>>>>>
>>>>>>> Yeah I have slightly older set of the patches in my droid4-pending-v5.5
>>>>>>> kernel.org git branch with voice calls working.
>>>>>>
>>>>>> I think I should put my droid4 out and try to get it working...
>>>>>> Do you have a link for dummies to follow to get started? ;)
>>>>>
>>>>> Probably the easiest one to use right now is the Maemo-leste devuan based
>>>>> test image using v5.5 kernel + modem and audio patches:
>>>>>
>>>>> https://leste.maemo.org/Motorola_Droid_4
>>>>>
>>>>> Just use a decent speed micro-sd card rated "a1" for example.
>>>>
>>>> Cool. Now I can dual boot the droid4 :D
>>>> I needed to rewrite the /etc/shadow to get a known root password so I
>>>> can log in.
>>>
>>> Not sure if you mean password for the droid4-kexecboot or the
>>> Linux distro you installed..
>>
>> It was for the maemo-leste.
>> Bringing up Gentoo will be a bit harder as I don't have wifi stuff in my
>> reference image...
>
> Gentoo cool :)
>
> I've had good luck with just plain alpine armv7 edge, the package
> updates work very fast for a slow system. The musl stuff requires
> running stellarium with 3d acceleration in a minimal devuan or
> whatever chroot environment though for stellarium etc..
I see, I might go via the lazy route and take buildroot ;)
>>> But for droid4-kexecboot, you
>>> can configure it to automatically download new kernels over wlan.
>>> There's some info on the machine specific password and how to
>>> configure wlan in the droid4-kexecboot buildroot commits here:
>>>
>>> https://github.com/tmlind/buildroot/commits/droid4-kexecboot-2017.11
>>>
>>>> Wifi is up, so in theory I can scp kernel/dtb to /boot/boot/ and update
>>>> the /boot/boot/boot.cfg to boot my kernel, right?
>>>
>>> Yeah you can update kernels and modules over wlan from the distro(s)
>>> you have configured, and also from droid4-kexecboot as above.
>>
>> I need to try droid4-kexecboot's wifi support then.
>
> Yeah you need to configure wpa_supplicant.conf and wlan.conf or
> whatever it was called. And make sure you have copied the old
> stock v3.0.8 kernel wlan modules and firmware as mentioned in
> the droid4-kexecboot git readme and install files.
OK.
> Oh, and also read about the flags you need to use for mkfs.ext4 if
> doing mkfs.ext4 on a PC, the old v3.0.8 kernel won't understand
> all the new flags if you want a partition to be readable for the
> droid4-kexecboot bootloader. And also the all the old Android
> distros currently still stuck with the ancient v3.0.8 kernel :p
I see, thanks for the warning!
>
> Regards,
>
> Tony
>
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply
* Re: [PATCH v2] test-vmstate: Fix memleaks in test_load_qlist
From: Laurent Vivier @ 2020-02-20 14:06 UTC (permalink / raw)
To: kuhn.chenqun, qemu-devel
Cc: thuth, ehabkost, quintela, qemu-trivial, dgilbert,
zhang.zhanghailiang
In-Reply-To: <20200220134103.26224-1-kuhn.chenqun@huawei.com>
Le 20/02/2020 à 14:41, kuhn.chenqun@huawei.com a écrit :
> From: Chen Qun <kuhn.chenqun@huawei.com>
>
> There is memleak in test_load_qlist().It's not a big deal,
> but test-vmstate will fail if sanitizers is enabled.
>
> In addition, "ret" is written twice with the same value
> in test_gtree_load_iommu().
>
> Reported-by: Euler Robot <euler.robot@huawei.com>
> Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com>
> ---
> tests/test-vmstate.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/tests/test-vmstate.c b/tests/test-vmstate.c
> index cea363dd69..f7b3868881 100644
> --- a/tests/test-vmstate.c
> +++ b/tests/test-vmstate.c
> @@ -1241,7 +1241,6 @@ static void test_gtree_load_iommu(void)
> TestGTreeIOMMU *orig_iommu = create_iommu();
> QEMUFile *fsave, *fload;
> char eof;
> - int ret;
>
> fsave = open_test_file(true);
> qemu_put_buffer(fsave, iommu_dump, sizeof(iommu_dump));
> @@ -1250,10 +1249,8 @@ static void test_gtree_load_iommu(void)
>
> fload = open_test_file(false);
> vmstate_load_state(fload, &vmstate_iommu, dest_iommu, 1);
> - ret = qemu_file_get_error(fload);
> eof = qemu_get_byte(fload);
> - ret = qemu_file_get_error(fload);
> - g_assert(!ret);
> + g_assert(!qemu_file_get_error(fload));/
> g_assert_cmpint(orig_iommu->id, ==, dest_iommu->id);
> g_assert_cmpint(eof, ==, QEMU_VM_EOF);
>
> @@ -1395,6 +1392,7 @@ static void test_load_qlist(void)
> compare_containers(orig_container, dest_container);
> free_container(orig_container);
> free_container(dest_container);
> + qemu_fclose(fload);
> }
>
> typedef struct TmpTestStruct {
>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
^ permalink raw reply
* Re: [PATCH v2] arm64:kgdb: Fix kernel single-stepping
From: Daniel Thompson @ 2020-02-20 14:06 UTC (permalink / raw)
To: minyard
Cc: Catalin Marinas, Will Deacon, linux-kernel, linux-arm-kernel,
Corey Minyard
In-Reply-To: <20200219152403.3495-1-minyard@acm.org>
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:
Tested-by: Daniel Thompson <daniel.thompson@linaro.org>
Daniel.
_______________________________________________
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 v2] arm64:kgdb: Fix kernel single-stepping
From: Daniel Thompson @ 2020-02-20 14:06 UTC (permalink / raw)
To: minyard
Cc: Will Deacon, Catalin Marinas, linux-arm-kernel, linux-kernel,
Corey Minyard
In-Reply-To: <20200219152403.3495-1-minyard@acm.org>
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:
Tested-by: Daniel Thompson <daniel.thompson@linaro.org>
Daniel.
^ permalink raw reply
* Re: [PATCH 8/8] libfrog: always fsync when flushing a device
From: Brian Foster @ 2020-02-20 14:06 UTC (permalink / raw)
To: Darrick J. Wong; +Cc: sandeen, linux-xfs
In-Reply-To: <158216295197.601264.12572804096602430873.stgit@magnolia>
On Wed, Feb 19, 2020 at 05:42:31PM -0800, Darrick J. Wong wrote:
> From: Darrick J. Wong <darrick.wong@oracle.com>
>
> Always call fsync() when we're flushing a device, even if it is a block
> device. It's probably redundant to call fsync /and/ BLKFLSBUF, but the
> latter has odd behavior so we want to make sure the standard flush
> methods have a chance to run first.
>
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> ---
Reviewed-by: Brian Foster <bfoster@redhat.com>
> libfrog/linux.c | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
>
> diff --git a/libfrog/linux.c b/libfrog/linux.c
> index 60bc1dc4..40a839d1 100644
> --- a/libfrog/linux.c
> +++ b/libfrog/linux.c
> @@ -155,14 +155,18 @@ platform_flush_device(
> if (major(device) == RAMDISK_MAJOR)
> return 0;
>
> + ret = fsync(fd);
> + if (ret)
> + return ret;
> +
> ret = fstat(fd, &st);
> if (ret)
> return ret;
>
> - if (S_ISREG(st.st_mode))
> - return fsync(fd);
> + if (S_ISBLK(st.st_mode))
> + return ioctl(fd, BLKFLSBUF, 0);
>
> - return ioctl(fd, BLKFLSBUF, 0);
> + return 0;
> }
>
> void
>
^ 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.