* Please pull mmc mmc-2-19-2020
From: Tom Rini @ 2020-02-20 13:28 UTC (permalink / raw)
To: u-boot
In-Reply-To: <DB7PR04MB449084B2D116FE705FCDFD3A88130@DB7PR04MB4490.eurprd04.prod.outlook.com>
On Thu, Feb 20, 2020 at 06:52:18AM +0000, Peng Fan wrote:
> > Subject: Re: Please pull mmc mmc-2-19-2020
> >
> > Hi Peng,
> >
> > On Thu, Feb 20, 2020 at 1:34 PM Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Feb 20, 2020 at 01:56:41AM +0000, Peng Fan wrote:
> > >
> > > > Hi Tom
> > > >
> > > > Please pull mmc-2-29-2020.
> > > >
> > >
> > > NAK, this breaks nios2:
> > > nios2: + 10m50 3c120
> > > +(10m50,3c120) ../drivers/net/altera_tse.c: In function 'altera_tse_probe':
> > > +(10m50,3c120) ../drivers/net/altera_tse.c:646:15: error: implicit
> > declaration of function 'dma_alloc_coherent'; did you mean 'lmb_alloc_addr'?
> > [-Werror=implicit-function-declaration]
> > > +(10m50,3c120) desc_mem = dma_alloc_coherent(len, &addr);
> > > +(10m50,3c120) ^~~~~~~~~~~~~~~~~~
> > > +(10m50,3c120) lmb_alloc_addr
> > > +(10m50,3c120) ../drivers/net/altera_tse.c:646:13: error: assignment
> > makes pointer from integer without a cast [-Werror=int-conversion]
> > > +(10m50,3c120) ^
> > > +(10m50,3c120) cc1: all warnings being treated as errors
> > > +(10m50,3c120) make[2]: *** [drivers/net/altera_tse.o] Error 1
> > > +(10m50,3c120) make[1]: *** [drivers/net] Error 2
> > > +(10m50,3c120) make: *** [sub-make] Error 2
>
> I not met such issue in github ci.
Travis is indeed missing nios2 tests but it's in GitLab / Azure.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200220/2ede6cda/attachment.sig>
^ permalink raw reply
* Re: [RFC PATCH v3 01/27] qcow2: Add calculate_l2_meta()
From: Max Reitz @ 2020-02-20 13:28 UTC (permalink / raw)
To: Alberto Garcia, qemu-devel
Cc: Kevin Wolf, Anton Nefedov, qemu-block,
Vladimir Sementsov-Ogievskiy, Denis V . Lunev
In-Reply-To: <2d53eae8fe9b9ab262daee45b662f631c3ba3899.1577014346.git.berto@igalia.com>
[-- Attachment #1.1: Type: text/plain, Size: 521 bytes --]
On 22.12.19 12:36, Alberto Garcia wrote:
> handle_alloc() creates a QCowL2Meta structure in order to update the
> image metadata and perform the necessary copy-on-write operations.
>
> This patch moves that code to a separate function so it can be used
> from other places.
>
> Signed-off-by: Alberto Garcia <berto@igalia.com>
> ---
> block/qcow2-cluster.c | 77 +++++++++++++++++++++++++++++--------------
> 1 file changed, 53 insertions(+), 24 deletions(-)
Reviewed-by: Max Reitz <mreitz@redhat.com>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [Intel-gfx] [PATCH v17 3/7] drm/i915: Init obj state in intel_atomic_get_old/new_global_obj_state
From: Lisovskiy, Stanislav @ 2020-02-20 13:29 UTC (permalink / raw)
To: intel-gfx@lists.freedesktop.org, jani.nikula@linux.intel.com
In-Reply-To: <f770e54f703754728615e4516e583cdc5906f461.camel@intel.com>
On Thu, 2020-02-20 at 15:11 +0200, stanislav.lisovskiy@intel.com wrote:
> On Thu, 2020-02-20 at 14:40 +0200, Jani Nikula wrote:
> > On Thu, 20 Feb 2020, Stanislav Lisovskiy <
> > stanislav.lisovskiy@intel.com> wrote:
> > > We might be willing to call intel_atomic_get_old_global_obj_state
> > > and intel_atomic_get_new_global_obj_state right away, however
> > > those are not initializing global obj state as
> > > intel_atomic_get_global_obj_state does.
> > > Extracted initializing part to separate function and now using
> > > this
> > > also in intel_atomic_get_old_global_obj_state and
> > > intel_atomic_get_new_global_obj_state
> > >
> > > v2: - Fixed typo in function call
> > >
> > > Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com
> > > >
> > > ---
> > > drivers/gpu/drm/i915/display/intel_bw.c | 28
> > > ++++++++++++++++++++++++-
> > > drivers/gpu/drm/i915/display/intel_bw.h | 9 ++++++++
> > > 2 files changed, 36 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> > > b/drivers/gpu/drm/i915/display/intel_bw.c
> > > index 58b264bc318d..ff57277e8880 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_bw.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> > > @@ -374,7 +374,33 @@ static unsigned int
> > > intel_bw_data_rate(struct
> > > drm_i915_private *dev_priv,
> > > return data_rate;
> > > }
> > >
> > > -static struct intel_bw_state *
> > > +struct intel_bw_state *
> > > +intel_atomic_get_old_bw_state(struct intel_atomic_state *state)
> > > +{
> > > + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> > > + struct intel_global_state *bw_state;
> > > +
> > > + bw_state = intel_atomic_get_old_global_obj_state(state,
> > > &dev_priv->bw_obj);
> > > + if (IS_ERR(bw_state))
> > > + return ERR_CAST(bw_state);
> > > +
> > > + return to_intel_bw_state(bw_state);
> > > +}
> > > +
> > > +struct intel_bw_state *
> > > +intel_atomic_get_new_bw_state(struct intel_atomic_state *state)
> > > +{
> > > + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> > > + struct intel_global_state *bw_state;
> > > + bw_state = intel_atomic_get_new_global_obj_state(state,
> > > &dev_priv->bw_obj);
> > > +
> > > + if (IS_ERR(bw_state))
> > > + return ERR_CAST(bw_state);
> > > +
> > > + return to_intel_bw_state(bw_state);
> > > +}
> > > +
> > > +struct intel_bw_state *
> > > intel_atomic_get_bw_state(struct intel_atomic_state *state)
> > > {
> > > struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> > > diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
> > > b/drivers/gpu/drm/i915/display/intel_bw.h
> > > index a8aa7624c5aa..ac004d6f4276 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_bw.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> > > @@ -24,6 +24,15 @@ struct intel_bw_state {
> > >
> > > #define to_intel_bw_state(x) container_of((x), struct
> > > intel_bw_state, base)
> > >
> > > +struct intel_bw_state *
> > > +intel_atomic_get_old_bw_state(struct intel_atomic_state *state);
> > > +
> > > +struct intel_bw_state *
> > > +intel_atomic_get_new_bw_state(struct intel_atomic_state *state);
> > > +
> > > +struct intel_bw_state *
> > > +intel_atomic_get_bw_state(struct intel_atomic_state *state);
> > > +
> >
> > I'm trying to promote a convention that a module foo_bar.[ch] would
> > export functions prefixed foo_bar_. Here, intel_bw_* like below.
>
> I'm fine with that. However most of the functions in this file have
> intel_atomic_* prefix, so if I now follow this convention it won't be
> consistent with current naming in the file.
Actually, I was wrong. Was looking into intel_global_state.c instead of
intel_bw.c. Yes, that totally makes sense.
Stan
>
> Anyway if this is now mandatory, will change it. Just will wait now
> first if CI doesn't blow up with this series, as I haven't rebased it
> for a while..
>
> Stan
>
> >
> > BR,
> > Jani.
> >
> >
> > > void intel_bw_init_hw(struct drm_i915_private *dev_priv);
> > > int intel_bw_init(struct drm_i915_private *dev_priv);
> > > int intel_bw_atomic_check(struct intel_atomic_state *state);
> >
> >
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* rt_task_bind blocking: inter-process ?
From: LOCHE Daniel @ 2020-02-20 13:29 UTC (permalink / raw)
To: xenomai
Hello everyone,
I a currently factoring my application to go from a multi-thread one to
a multi-process one (C++11).
I am using Xenomai 3.0.5 on Linux Mint 18.04 (on a Intel 8250U
computer), 90% alchemy library (10% posix).
(either processes or tasks, let's call all of those "tasks" here after
for easier understanding)
*Context : *Basically, during the setup phase of the execution,
previously I was reading a list of "task" parameters from a file
and launched consequently the correct amount of rt_task_create() /
launch() from my main process.
All my RT_TASK links to the threads were stored in the main thread to
manage them.
Now, I have to go through a fork() for every task, followed by a
rt_task_shadow(). OK.
But to get in my main process the link to the RT_TASK of every xenomai
process created, I have to use rt_task_bind().
Issue is here : whatever arguments I give to rt_task_bind(), it blocks
as long as the searched task name exists... don't know why.
Here is a sample code bellow ... what is wrong exactly ? Is it possible
to use rt_task_bind with inter-process tasks..? Why the "TM_NONBLOCK"
does nothing..? Thanks for your help.
Daniel
#include <alchemy/task.h>
#include <alchemy/timer.h>
#include <sys/types.h>
#include <unistd.h>
int main ()
{
const char* taskNames[3] = {"task0", "task1", "task2"};
for (int i = 0, i < 3, ++i)
{
pid_t pid = fork()
if (pid) //
{
sleep(1); // wait a little before going through another
fork.
} else { // child process
RT_TASK _t;
rt_task_shadow(&_t, taskNames[i], 50, 0);
rt_printf("Success creating task %s", taskNames[i]);
sleep(15); /* placeholder, should do real-time stuff
here, then end process. */
exit(EXIT_SUCCESS);
}
}
// Only "main" process goes here.
RT_TASK _t;
for (int i = 0, i < 3, ++i)
{
int ret = rt_task_bind(&t, taskNames[i], TM_NONBLOCK); // <==
HERE. TM_NONBLOCK, TM_INFINITE or a time value, changes nothing....
never goes here.
if (ret) printf("Error : could not bind task. Error #%d", ret);
else printf("Bind to task %s done.", taskNames[i]);
}
/* Do stuff here on the binded tasks */
exit(EXIT_SUCCESS);
}
^ permalink raw reply
* Re: [arm64, debug] PTRACE_SINGLESTEP does not single-step a valid instruction
From: Will Deacon @ 2020-02-20 13:29 UTC (permalink / raw)
To: Mark Rutland; +Cc: Luis Machado, linux-arm-kernel
In-Reply-To: <20200220130222.GA28634@lakrids.cambridge.arm.com>
Hi Mark,
Thanks for having a look.
On Thu, Feb 20, 2020 at 01:02:22PM +0000, Mark Rutland wrote:
> On Thu, Feb 13, 2020 at 12:01:16PM +0000, Will Deacon wrote:
> > diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
> > index cd6e5fa48b9c..d479fbcbd0d2 100644
> > --- a/arch/arm64/kernel/ptrace.c
> > +++ b/arch/arm64/kernel/ptrace.c
> > @@ -1934,8 +1934,8 @@ static int valid_native_regs(struct user_pt_regs *regs)
> > */
> > int valid_user_regs(struct user_pt_regs *regs, struct task_struct *task)
> > {
> > - if (!test_tsk_thread_flag(task, TIF_SINGLESTEP))
> > - regs->pstate &= ~DBG_SPSR_SS;
> > + /* https://lore.kernel.org/lkml/20191118131525.GA4180@willie-the-truck */
> > + user_regs_reset_single_step(regs, task);
>
> I think this change means we do the right thing for signal entry/return
> and ptrace messing with the regs. Instruction emulation seems to do the
> right thing via skip_faulting_instruction().
>
> I think there are a few more single-step edge cases lying around (e.g.
> uprobes, rseq), but it looks like those have to be fixed separately. I
> fear fixing uprobes might require a largler structural change to single
> step, but ignoring uprobes the changes above seem to be sound.
Rseq should just abort when delivering the step signal and I'm not sure I
see the issue with uprobes. Can you elaborate on your concerns a bit,
please?
> If userspace doesn't consume the SS value today, I wonder if we should
> hide it when dumping the SPSR to userspace, so that userspace has a
> consistent view regardless of whether it's being stepped.
You can't really hide it though, because '0' has a meaning so I don't think
it gains us a lot other than increasing the scope of the change.
> I'll try to dig into the uprobes stuff this afternoon, just in case that
> needs us to do something substantially different.
Thanks.
> The existing logic in valid_user_regs() doesn't make sense to me, given
> SPSR_EL1.SS is immaterial unless MSCDR_EL1.SS == 1. I'm not sure if that
> was overzealous or I've forgotten an edge case that we cared about in
> the past.
I think it was just part of sanitising the registers to a consistent value,
but I agree that it wouldn't have a functional impact.
> > diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
> > index 339882db5a91..bc54bdbfd760 100644
> > --- a/arch/arm64/kernel/signal.c
> > +++ b/arch/arm64/kernel/signal.c
> > @@ -505,8 +505,12 @@ static int restore_sigframe(struct pt_regs *regs,
> > forget_syscall(regs);
> >
> > err |= !valid_user_regs(®s->user_regs, current);
> > - if (err == 0)
> > +
> > + if (err == 0) {
> > + /* Make it look like we stepped the sigreturn system call */
> > + user_fastforward_single_step(current);
> > err = parse_user_sigframe(&user, sf);
> > + }
>
> I don't understand this. AFAICT we don't likewise for other SVCs, so
> either I'm missing that, or there's something else I'm missing.
>
> Why do we need to step sigreturn but not SVC generally?
Because we restore the SPSR from the sigframe during sigreturn, so we will
end up with PSTATE.SS set when it should be cleared.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] Btrfs: fix deadlock during fast fsync when logging prealloc extents beyond eof
From: fdmanana @ 2020-02-20 13:29 UTC (permalink / raw)
To: linux-btrfs
From: Filipe Manana <fdmanana@suse.com>
While logging the prealloc extents of an inode during a fast fsync we call
btrfs_truncate_inode_items(), through btrfs_log_prealloc_extents(), while
holding a read lock on a leaf of the inode's root (not the log root, the
fs/subvol root), and then that function locks the file range in the inode's
iotree. This can lead to a deadlock when:
* the fsync is ranged
* the file has prealloc extents beyond eof
* writeback for a range different from the fsync range starts
during the fsync
* the size of the file is not sector size aligned
Because when finishing an ordered extent we lock first a file range and
then try to COW the fs/subvol tree to insert an extent item.
The following diagram shows how the deadlock can happen.
CPU 1 CPU 2
btrfs_sync_file()
--> for range [0, 1Mb[
--> inode has a size of
1Mb and has 1 prealloc
extent beyond the
i_size, starting at offset
4Mb
flushes all delalloc for the
range [0Mb, 1Mb[ and waits
for the respective ordered
extents to complete
--> before task at CPU 1 locks the
inode, a write into file range
[1Mb, 2Mb + 1Kb[ is made
--> i_size is updated to 2Mb + 1Kb
--> writeback is started for that
range, [1Mb, 2Mb + 4Kb[
--> end offset rounded up to
be sector size aligned
btrfs_log_dentry_safe()
btrfs_log_inode_parent()
btrfs_log_inode()
btrfs_log_changed_extents()
btrfs_log_prealloc_extents()
--> does a search on the
inode's root
--> holds a read lock on
leaf X
btrfs_finish_ordered_io()
--> locks range [1Mb, 2Mb + 4Kb[
--> end offset rounded up
to be sector size aligned
--> tries to cow leaf X, through
insert_reserved_file_extent()
--> already locked by the
task at CPU 1
btrfs_truncate_inode_items()
--> gets an i_size of
2Mb + 1Kb, which is
not sector size
aligned
--> tries to lock file
range [2Mb, (u64)-1[
--> the start range
is rounded down
from 2Mb + 1K
to 2Mb to be sector
size aligned
--> but the subrange
[2Mb, 2Mb + 4Kb[ is
already locked by
task at CPU 2 which
is waiting to get a
write lock on leaf X
for which we are
holding a read lock
*** deadlock ***
This results in a stack trace like the following, triggered by test case
generic/561 from fstests:
[ 2779.973608] INFO: task kworker/u8:6:247 blocked for more than 120 seconds.
[ 2779.979536] Not tainted 5.6.0-rc2-btrfs-next-53 #1
[ 2779.984503] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 2779.990136] kworker/u8:6 D 0 247 2 0x80004000
[ 2779.990457] Workqueue: btrfs-endio-write btrfs_work_helper [btrfs]
[ 2779.990466] Call Trace:
[ 2779.990491] ? __schedule+0x384/0xa30
[ 2779.990521] schedule+0x33/0xe0
[ 2779.990616] btrfs_tree_read_lock+0x19e/0x2e0 [btrfs]
[ 2779.990632] ? remove_wait_queue+0x60/0x60
[ 2779.990730] btrfs_read_lock_root_node+0x2f/0x40 [btrfs]
[ 2779.990782] btrfs_search_slot+0x510/0x1000 [btrfs]
[ 2779.990869] btrfs_lookup_file_extent+0x4a/0x70 [btrfs]
[ 2779.990944] __btrfs_drop_extents+0x161/0x1060 [btrfs]
[ 2779.990987] ? mark_held_locks+0x6d/0xc0
[ 2779.990994] ? __slab_alloc.isra.49+0x99/0x100
[ 2779.991060] ? insert_reserved_file_extent.constprop.19+0x64/0x300 [btrfs]
[ 2779.991145] insert_reserved_file_extent.constprop.19+0x97/0x300 [btrfs]
[ 2779.991222] ? start_transaction+0xdd/0x5c0 [btrfs]
[ 2779.991291] btrfs_finish_ordered_io+0x4f4/0x840 [btrfs]
[ 2779.991405] btrfs_work_helper+0xaa/0x720 [btrfs]
[ 2779.991432] process_one_work+0x26d/0x6a0
[ 2779.991460] worker_thread+0x4f/0x3e0
[ 2779.991481] ? process_one_work+0x6a0/0x6a0
[ 2779.991489] kthread+0x103/0x140
[ 2779.991499] ? kthread_create_worker_on_cpu+0x70/0x70
[ 2779.991515] ret_from_fork+0x3a/0x50
(...)
[ 2780.026211] INFO: task fsstress:17375 blocked for more than 120 seconds.
[ 2780.027480] Not tainted 5.6.0-rc2-btrfs-next-53 #1
[ 2780.028482] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 2780.030035] fsstress D 0 17375 17373 0x00004000
[ 2780.030038] Call Trace:
[ 2780.030044] ? __schedule+0x384/0xa30
[ 2780.030052] schedule+0x33/0xe0
[ 2780.030075] lock_extent_bits+0x20c/0x320 [btrfs]
[ 2780.030094] ? btrfs_truncate_inode_items+0xf4/0x1150 [btrfs]
[ 2780.030098] ? rcu_read_lock_sched_held+0x59/0xa0
[ 2780.030102] ? remove_wait_queue+0x60/0x60
[ 2780.030122] btrfs_truncate_inode_items+0x133/0x1150 [btrfs]
[ 2780.030151] ? btrfs_set_path_blocking+0xb2/0x160 [btrfs]
[ 2780.030165] ? btrfs_search_slot+0x379/0x1000 [btrfs]
[ 2780.030195] btrfs_log_changed_extents.isra.8+0x841/0x93e [btrfs]
[ 2780.030202] ? do_raw_spin_unlock+0x49/0xc0
[ 2780.030215] ? btrfs_get_num_csums+0x10/0x10 [btrfs]
[ 2780.030239] btrfs_log_inode+0xf83/0x1124 [btrfs]
[ 2780.030251] ? __mutex_unlock_slowpath+0x45/0x2a0
[ 2780.030275] btrfs_log_inode_parent+0x2a0/0xe40 [btrfs]
[ 2780.030282] ? dget_parent+0xa1/0x370
[ 2780.030309] btrfs_log_dentry_safe+0x4a/0x70 [btrfs]
[ 2780.030329] btrfs_sync_file+0x3f3/0x490 [btrfs]
[ 2780.030339] do_fsync+0x38/0x60
[ 2780.030343] __x64_sys_fdatasync+0x13/0x20
[ 2780.030345] do_syscall_64+0x5c/0x280
[ 2780.030348] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 2780.030356] RIP: 0033:0x7f2d80f6d5f0
[ 2780.030361] Code: Bad RIP value.
[ 2780.030362] RSP: 002b:00007ffdba3c8548 EFLAGS: 00000246 ORIG_RAX: 000000000000004b
[ 2780.030364] RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f2d80f6d5f0
[ 2780.030365] RDX: 00007ffdba3c84b0 RSI: 00007ffdba3c84b0 RDI: 0000000000000003
[ 2780.030367] RBP: 000000000000004a R08: 0000000000000001 R09: 00007ffdba3c855c
[ 2780.030368] R10: 0000000000000078 R11: 0000000000000246 R12: 00000000000001f4
[ 2780.030369] R13: 0000000051eb851f R14: 00007ffdba3c85f0 R15: 0000557a49220d90
So fix this by making btrfs_truncate_inode_items() not lock the range in
the inode's iotree when the target root is a log root, since it's not
needed to lock the range for log roots as the protection from the inode's
lock and log_mutex are all that's needed.
Fixes: 28553fa992cb28 ("Btrfs: fix race between shrinking truncate and fiemap")
Signed-off-by: Filipe Manana <fdmanana@suse.com>
---
fs/btrfs/inode.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 594ced31a7a8..6fb9096e0e9f 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -4119,8 +4119,9 @@ int btrfs_truncate_inode_items(struct btrfs_trans_handle *trans,
return -ENOMEM;
path->reada = READA_BACK;
- lock_extent_bits(&BTRFS_I(inode)->io_tree, lock_start, (u64)-1,
- &cached_state);
+ if (root->root_key.objectid != BTRFS_TREE_LOG_OBJECTID)
+ lock_extent_bits(&BTRFS_I(inode)->io_tree, lock_start, (u64)-1,
+ &cached_state);
/*
* We want to drop from the next block forward in case this new size is
@@ -4411,11 +4412,10 @@ int btrfs_truncate_inode_items(struct btrfs_trans_handle *trans,
if (!ret && last_size > new_size)
last_size = new_size;
btrfs_inode_safe_disk_i_size_write(inode, last_size);
+ unlock_extent_cached(&BTRFS_I(inode)->io_tree, lock_start,
+ (u64)-1, &cached_state);
}
- unlock_extent_cached(&BTRFS_I(inode)->io_tree, lock_start, (u64)-1,
- &cached_state);
-
btrfs_free_path(path);
return ret;
}
--
2.25.0
^ permalink raw reply related
* Re: [Bug 206405] kernel crash during boot debian server on qemu+kvm
From: Bartlomiej Zolnierkiewicz @ 2020-02-20 13:30 UTC (permalink / raw)
To: bugzilla-daemon; +Cc: linux-ide
In-Reply-To: <bug-206405-11633-Dt7buLdEpp@https.bugzilla.kernel.org/>
On 2/19/20 10:25 PM, bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=206405
>
> --- Comment #3 from anthony (antdev66@gmail.com) ---
> same problem in version 5.5.5
Hi,
Please check v5.6-rc2 and if it doesn't help please try to do
bisection between v5.4 and v5.5 kernel versions as described in:
Documentation/admin-guide/bug-bisect.rst
Also could you please explain what prevents you from migration to
libata drivers (CONFIG_ATA) from the IDE subsystem (CONFIG_IDE, it
has been deprecated many years ago and is scheduled for removal)?
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* [Bug 206405] kernel crash during boot debian server on qemu+kvm
From: bugzilla-daemon @ 2020-02-20 13:30 UTC (permalink / raw)
To: linux-ide
In-Reply-To: <bug-206405-11633@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=206405
--- Comment #4 from b.zolnierkie@samsung.com ---
On 2/19/20 10:25 PM, bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=206405
>
> --- Comment #3 from anthony (antdev66@gmail.com) ---
> same problem in version 5.5.5
Hi,
Please check v5.6-rc2 and if it doesn't help please try to do
bisection between v5.4 and v5.5 kernel versions as described in:
Documentation/admin-guide/bug-bisect.rst
Also could you please explain what prevents you from migration to
libata drivers (CONFIG_ATA) from the IDE subsystem (CONFIG_IDE, it
has been deprecated many years ago and is scheduled for removal)?
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [PATCH] drm/virtio: fix virtio-gpu resource id creation race
From: Emil Velikov @ 2020-02-20 13:30 UTC (permalink / raw)
To: John Bates; +Cc: David Airlie, Gerd Hoffmann, ML dri-devel, Gurchetan Singh
In-Reply-To: <20200219204002.220744-1-jbates@chromium.org>
Hi John,
On Thu, 20 Feb 2020 at 08:45, John Bates <jbates@chromium.org> wrote:
>
> The previous code was not thread safe and caused
> undefined behavior from spurious duplicate resource IDs.
> In this patch, an atomic_t is used instead. We no longer
> see any duplicate IDs in tests with this change.
>
> Signed-off-by: John Bates <jbates@chromium.org>
Adding a fixes tag like below makes it easier to track. Especially for
Greg and team who are working on stable kernels.
Fixes: 3e93bc2a58aa ("drm/virtio: make resource id workaround runtime
switchable.")
HTH
Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v1 1/2] scsi: ufs: add required delay after gating reference clock
From: Stanley Chu @ 2020-02-20 13:30 UTC (permalink / raw)
To: Can Guo
Cc: linux-scsi, martin.petersen, Asutosh Das, hongwus, avri.altman,
alim.akhtar, jejb, beanhuo, matthias.bgg, bvanassche,
linux-mediatek, linux-arm-kernel, linux-kernel, kuohong.wang,
peter.wang, chun-hung.wu, andy.teng
In-Reply-To: <bbb0b0637d9667d4691a9a28f9988dea@codeaurora.org>
Hi Can,
On Wed, 2020-02-19 at 18:33 +0800, Can Guo wrote:
> Hi Stanley,
>
> On 2020-02-19 17:11, Stanley Chu wrote:
> > Hi Can,
> >
> > On Wed, 2020-02-19 at 10:35 +0800, Can Guo wrote:
> >
> >> Since we all need this delay here, how about put the delay in the
> >> entrence of ufshcd_setup_clocks(), before vops_setup_clocks()?
> >> If so, we can remove all the delays we added in our vops since the
> >> delay anyways delays everything inside ufshcd_setup_clocks().
> >>
> >
> > Always putting the delay in the entrance of ufshcd_setup_clocks() may
> > add unwanted delay for vendors, just like your current implementation,
> > or some other vendors who do not want to disable the reference clock.
> >
> > I think current patch is more reasonable because the delay is applied
> > to
> > clock only named as "ref_clk" specifically.
> >
> > If you needs to keep "ref_clk" in DT, would you consider to remove the
> > delay in your ufs_qcom_dev_ref_clk_ctrl() and let the delay happens via
> > common ufshcd_setup_clocks() only? However you may still need delay if
> > call path comes from ufs_qcom_pwr_change_notify().
> >
> > What do you think?
> >
>
> I agree current change is more reasonable from what it looks, but the
> fact
> is that I canont remove the delay in ufs_qcom_dev_ref_clk_ctrl() even
> with
> this change. On our platforms, ref_clk in DT serves multipule purposes,
> the ref_clk provided to UFS device is actually controlled in
> ufs_qcom_dev_ref_clk_ctrl(), which comes before where this change kicks
> start,
> so if I remove the delay in ufs_qcom_dev_ref_clk_ctrl(), this change
> cannot
> provide us the correct delay before gate the ref_clk provided to UFS
> device.
> > Always putting the delay in the entrance of ufshcd_setup_clocks() may
> > add unwanted delay for vendors, just like your current implementation,
> > or some other vendors who do not want to disable the reference clock.
>
> I meant if we put the delay in the entrance, I will be able to remove
> the delay in ufs_qcom_dev_ref_clk_ctrl(). Meanwhile, we can add proper
> checks before the delay to make sure it is initiated only if ref_clk
> needs
> to be disabled, i.e:
>
> if(!on && !skip_ref_clk && hba->dev_info.clk_gating_wait_us)
> usleep_range();
>
> Does this look better to you?
Firstly thanks so much for above details.
Again this statement may also add unwanted delay if some other vendors
does not have "ref_clk" in DT or they don't/can't disable the reference
clock provided to UFS device.
>
> Anyways, we will see regressions with this change on our platforms, can
> we
> have more discussions before get it merged? It should be OK if you go
> with
> patch #2 alone first, right? Thanks.
Now the fact is that this change will impact your flow and it seems no
solid conclusion yet. Sure I could drop patch #1 and submit patch #2
only first : )
Thanks,
Stanley Chu
^ permalink raw reply
* Re: [PATCH v1 1/2] scsi: ufs: add required delay after gating reference clock
From: Stanley Chu @ 2020-02-20 13:30 UTC (permalink / raw)
To: Can Guo
Cc: chun-hung.wu, linux-scsi, martin.petersen, andy.teng, jejb,
peter.wang, kuohong.wang, linux-kernel, avri.altman,
linux-mediatek, linux-arm-kernel, alim.akhtar, matthias.bgg,
beanhuo, bvanassche, hongwus, Asutosh Das
In-Reply-To: <bbb0b0637d9667d4691a9a28f9988dea@codeaurora.org>
Hi Can,
On Wed, 2020-02-19 at 18:33 +0800, Can Guo wrote:
> Hi Stanley,
>
> On 2020-02-19 17:11, Stanley Chu wrote:
> > Hi Can,
> >
> > On Wed, 2020-02-19 at 10:35 +0800, Can Guo wrote:
> >
> >> Since we all need this delay here, how about put the delay in the
> >> entrence of ufshcd_setup_clocks(), before vops_setup_clocks()?
> >> If so, we can remove all the delays we added in our vops since the
> >> delay anyways delays everything inside ufshcd_setup_clocks().
> >>
> >
> > Always putting the delay in the entrance of ufshcd_setup_clocks() may
> > add unwanted delay for vendors, just like your current implementation,
> > or some other vendors who do not want to disable the reference clock.
> >
> > I think current patch is more reasonable because the delay is applied
> > to
> > clock only named as "ref_clk" specifically.
> >
> > If you needs to keep "ref_clk" in DT, would you consider to remove the
> > delay in your ufs_qcom_dev_ref_clk_ctrl() and let the delay happens via
> > common ufshcd_setup_clocks() only? However you may still need delay if
> > call path comes from ufs_qcom_pwr_change_notify().
> >
> > What do you think?
> >
>
> I agree current change is more reasonable from what it looks, but the
> fact
> is that I canont remove the delay in ufs_qcom_dev_ref_clk_ctrl() even
> with
> this change. On our platforms, ref_clk in DT serves multipule purposes,
> the ref_clk provided to UFS device is actually controlled in
> ufs_qcom_dev_ref_clk_ctrl(), which comes before where this change kicks
> start,
> so if I remove the delay in ufs_qcom_dev_ref_clk_ctrl(), this change
> cannot
> provide us the correct delay before gate the ref_clk provided to UFS
> device.
> > Always putting the delay in the entrance of ufshcd_setup_clocks() may
> > add unwanted delay for vendors, just like your current implementation,
> > or some other vendors who do not want to disable the reference clock.
>
> I meant if we put the delay in the entrance, I will be able to remove
> the delay in ufs_qcom_dev_ref_clk_ctrl(). Meanwhile, we can add proper
> checks before the delay to make sure it is initiated only if ref_clk
> needs
> to be disabled, i.e:
>
> if(!on && !skip_ref_clk && hba->dev_info.clk_gating_wait_us)
> usleep_range();
>
> Does this look better to you?
Firstly thanks so much for above details.
Again this statement may also add unwanted delay if some other vendors
does not have "ref_clk" in DT or they don't/can't disable the reference
clock provided to UFS device.
>
> Anyways, we will see regressions with this change on our platforms, can
> we
> have more discussions before get it merged? It should be OK if you go
> with
> patch #2 alone first, right? Thanks.
Now the fact is that this change will impact your flow and it seems no
solid conclusion yet. Sure I could drop patch #1 and submit patch #2
only first : )
Thanks,
Stanley Chu
_______________________________________________
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 v1 1/2] scsi: ufs: add required delay after gating reference clock
From: Stanley Chu @ 2020-02-20 13:30 UTC (permalink / raw)
To: Can Guo
Cc: chun-hung.wu, linux-scsi, martin.petersen, andy.teng, jejb,
peter.wang, kuohong.wang, linux-kernel, avri.altman,
linux-mediatek, linux-arm-kernel, alim.akhtar, matthias.bgg,
beanhuo, bvanassche, hongwus, Asutosh Das
In-Reply-To: <bbb0b0637d9667d4691a9a28f9988dea@codeaurora.org>
Hi Can,
On Wed, 2020-02-19 at 18:33 +0800, Can Guo wrote:
> Hi Stanley,
>
> On 2020-02-19 17:11, Stanley Chu wrote:
> > Hi Can,
> >
> > On Wed, 2020-02-19 at 10:35 +0800, Can Guo wrote:
> >
> >> Since we all need this delay here, how about put the delay in the
> >> entrence of ufshcd_setup_clocks(), before vops_setup_clocks()?
> >> If so, we can remove all the delays we added in our vops since the
> >> delay anyways delays everything inside ufshcd_setup_clocks().
> >>
> >
> > Always putting the delay in the entrance of ufshcd_setup_clocks() may
> > add unwanted delay for vendors, just like your current implementation,
> > or some other vendors who do not want to disable the reference clock.
> >
> > I think current patch is more reasonable because the delay is applied
> > to
> > clock only named as "ref_clk" specifically.
> >
> > If you needs to keep "ref_clk" in DT, would you consider to remove the
> > delay in your ufs_qcom_dev_ref_clk_ctrl() and let the delay happens via
> > common ufshcd_setup_clocks() only? However you may still need delay if
> > call path comes from ufs_qcom_pwr_change_notify().
> >
> > What do you think?
> >
>
> I agree current change is more reasonable from what it looks, but the
> fact
> is that I canont remove the delay in ufs_qcom_dev_ref_clk_ctrl() even
> with
> this change. On our platforms, ref_clk in DT serves multipule purposes,
> the ref_clk provided to UFS device is actually controlled in
> ufs_qcom_dev_ref_clk_ctrl(), which comes before where this change kicks
> start,
> so if I remove the delay in ufs_qcom_dev_ref_clk_ctrl(), this change
> cannot
> provide us the correct delay before gate the ref_clk provided to UFS
> device.
> > Always putting the delay in the entrance of ufshcd_setup_clocks() may
> > add unwanted delay for vendors, just like your current implementation,
> > or some other vendors who do not want to disable the reference clock.
>
> I meant if we put the delay in the entrance, I will be able to remove
> the delay in ufs_qcom_dev_ref_clk_ctrl(). Meanwhile, we can add proper
> checks before the delay to make sure it is initiated only if ref_clk
> needs
> to be disabled, i.e:
>
> if(!on && !skip_ref_clk && hba->dev_info.clk_gating_wait_us)
> usleep_range();
>
> Does this look better to you?
Firstly thanks so much for above details.
Again this statement may also add unwanted delay if some other vendors
does not have "ref_clk" in DT or they don't/can't disable the reference
clock provided to UFS device.
>
> Anyways, we will see regressions with this change on our platforms, can
> we
> have more discussions before get it merged? It should be OK if you go
> with
> patch #2 alone first, right? Thanks.
Now the fact is that this change will impact your flow and it seems no
solid conclusion yet. Sure I could drop patch #1 and submit patch #2
only first : )
Thanks,
Stanley Chu
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* [igt-dev] ✓ Fi.CI.BAT: success for tools/i915-perf: workaround overzelous compiler warnings
From: Patchwork @ 2020-02-20 13:31 UTC (permalink / raw)
To: Lionel Landwerlin; +Cc: igt-dev
In-Reply-To: <20200220125152.1188880-1-lionel.g.landwerlin@intel.com>
== Series Details ==
Series: tools/i915-perf: workaround overzelous compiler warnings
URL : https://patchwork.freedesktop.org/series/73709/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7973 -> IGTPW_4192
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4192/index.html
Known issues
------------
Here are the changes found in IGTPW_4192 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_exec_suspend@basic-s0:
- fi-ilk-650: [PASS][1] -> [DMESG-WARN][2] ([i915#116])
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-ilk-650/igt@gem_exec_suspend@basic-s0.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4192/fi-ilk-650/igt@gem_exec_suspend@basic-s0.html
* igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq: [PASS][3] -> [DMESG-WARN][4] ([i915#92]) +1 similar issue
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-skl-6770hq/igt@i915_pm_rpm@module-reload.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4192/fi-skl-6770hq/igt@i915_pm_rpm@module-reload.html
* igt@i915_selftest@live_gem_contexts:
- fi-byt-n2820: [PASS][5] -> [DMESG-FAIL][6] ([i915#1052])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4192/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html
* igt@i915_selftest@live_hangcheck:
- fi-skl-guc: [PASS][7] -> [INCOMPLETE][8] ([fdo#108744])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-skl-guc/igt@i915_selftest@live_hangcheck.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4192/fi-skl-guc/igt@i915_selftest@live_hangcheck.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-skl-6770hq: [PASS][9] -> [SKIP][10] ([fdo#109271]) +4 similar issues
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-skl-6770hq/igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4192/fi-skl-6770hq/igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence.html
* igt@kms_pipe_crc_basic@read-crc-pipe-c:
- fi-skl-6770hq: [PASS][11] -> [DMESG-WARN][12] ([i915#106])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-skl-6770hq/igt@kms_pipe_crc_basic@read-crc-pipe-c.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4192/fi-skl-6770hq/igt@kms_pipe_crc_basic@read-crc-pipe-c.html
* igt@kms_prop_blob@basic:
- fi-tgl-y: [PASS][13] -> [DMESG-WARN][14] ([CI#94] / [i915#402])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-tgl-y/igt@kms_prop_blob@basic.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4192/fi-tgl-y/igt@kms_prop_blob@basic.html
#### Possible fixes ####
* igt@i915_selftest@live_gem_contexts:
- fi-cml-s: [DMESG-FAIL][15] ([i915#877]) -> [PASS][16]
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4192/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [FAIL][17] ([i915#217]) -> [PASS][18]
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-icl-u2/igt@kms_chamelium@hdmi-hpd-fast.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4192/fi-icl-u2/igt@kms_chamelium@hdmi-hpd-fast.html
#### Warnings ####
* igt@amdgpu/amd_prime@amd-to-i915:
- fi-icl-u3: [SKIP][19] ([fdo#109315]) -> [SKIP][20] ([fdo#109315] / [i915#585])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-icl-u3/igt@amdgpu/amd_prime@amd-to-i915.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4192/fi-icl-u3/igt@amdgpu/amd_prime@amd-to-i915.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][21] ([fdo#111407]) -> [FAIL][22] ([fdo#111096] / [i915#323])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4192/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
[CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94
[fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[i915#1052]: https://gitlab.freedesktop.org/drm/intel/issues/1052
[i915#106]: https://gitlab.freedesktop.org/drm/intel/issues/106
[i915#116]: https://gitlab.freedesktop.org/drm/intel/issues/116
[i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217
[i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#585]: https://gitlab.freedesktop.org/drm/intel/issues/585
[i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
Participating hosts (49 -> 47)
------------------------------
Additional (4): fi-kbl-soraka fi-skl-lmem fi-ivb-3770 fi-pnv-d510
Missing (6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus
Build changes
-------------
* CI: CI-20190529 -> None
* IGT: IGT_5453 -> IGTPW_4192
CI-20190529: 20190529
CI_DRM_7973: 07350317e4b2be54b1de7f1e73f77875df5e43f3 @ git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_4192: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4192/index.html
IGT_5453: cae9a5881ed2c5be2c2518a255740b612a927f9a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4192/index.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* Re: [PATCH v3 1/5] powerpc: Rename current_stack_pointer() to current_stack_frame()
From: Christophe Leroy @ 2020-02-20 13:26 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20200220115141.2707-1-mpe@ellerman.id.au>
Le 20/02/2020 à 12:51, Michael Ellerman a écrit :
> current_stack_pointer(), which was called __get_SP(), used to just
> return the value in r1.
>
> But that caused problems in some cases, so it was turned into a
> function in commit bfe9a2cfe91a ("powerpc: Reimplement __get_SP() as a
> function not a define").
>
> Because it's a function in a separate compilation unit to all its
> callers, it has the effect of causing a stack frame to be created, and
> then returns the address of that frame. This is good in some cases
> like those described in the above commit, but in other cases it's
> overkill, we just need to know what stack page we're on.
>
> On some other arches current_stack_pointer is just a register global
> giving the stack pointer, and we'd like to do that too. So rename our
> current_stack_pointer() to current_stack_frame() to make that
> possible.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
LGTM
I was afraid to do that and risk invisible conflicts hence bugs by
reusing the same name for different purpose, but that's the best
solution for sure.
Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
> ---
> arch/powerpc/include/asm/perf_event.h | 2 +-
> arch/powerpc/include/asm/reg.h | 2 +-
> arch/powerpc/kernel/irq.c | 4 ++--
> arch/powerpc/kernel/misc.S | 4 ++--
> arch/powerpc/kernel/process.c | 2 +-
> arch/powerpc/kernel/stacktrace.c | 6 +++---
> 6 files changed, 10 insertions(+), 10 deletions(-)
>
> v3: New.
>
> diff --git a/arch/powerpc/include/asm/perf_event.h b/arch/powerpc/include/asm/perf_event.h
> index 7426d7a90e1e..eed3954082fa 100644
> --- a/arch/powerpc/include/asm/perf_event.h
> +++ b/arch/powerpc/include/asm/perf_event.h
> @@ -32,7 +32,7 @@
> do { \
> (regs)->result = 0; \
> (regs)->nip = __ip; \
> - (regs)->gpr[1] = current_stack_pointer(); \
> + (regs)->gpr[1] = current_stack_frame(); \
> asm volatile("mfmsr %0" : "=r" ((regs)->msr)); \
> } while (0)
>
> diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
> index 1aa46dff0957..1b1ffdba6097 100644
> --- a/arch/powerpc/include/asm/reg.h
> +++ b/arch/powerpc/include/asm/reg.h
> @@ -1448,7 +1448,7 @@ static inline void mtsrin(u32 val, u32 idx)
>
> #define proc_trap() asm volatile("trap")
>
> -extern unsigned long current_stack_pointer(void);
> +extern unsigned long current_stack_frame(void);
>
> extern unsigned long scom970_read(unsigned int address);
> extern void scom970_write(unsigned int address, unsigned long value);
> diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
> index 5c9b11878555..02118c18434d 100644
> --- a/arch/powerpc/kernel/irq.c
> +++ b/arch/powerpc/kernel/irq.c
> @@ -602,7 +602,7 @@ static inline void check_stack_overflow(void)
> #ifdef CONFIG_DEBUG_STACKOVERFLOW
> long sp;
>
> - sp = current_stack_pointer() & (THREAD_SIZE-1);
> + sp = current_stack_frame() & (THREAD_SIZE-1);
>
> /* check for stack overflow: is there less than 2KB free? */
> if (unlikely(sp < 2048)) {
> @@ -647,7 +647,7 @@ void do_IRQ(struct pt_regs *regs)
> void *cursp, *irqsp, *sirqsp;
>
> /* Switch to the irq stack to handle this */
> - cursp = (void *)(current_stack_pointer() & ~(THREAD_SIZE - 1));
> + cursp = (void *)(current_stack_frame() & ~(THREAD_SIZE - 1));
> irqsp = hardirq_ctx[raw_smp_processor_id()];
> sirqsp = softirq_ctx[raw_smp_processor_id()];
>
> diff --git a/arch/powerpc/kernel/misc.S b/arch/powerpc/kernel/misc.S
> index 974f65f79a8e..65f9f731c229 100644
> --- a/arch/powerpc/kernel/misc.S
> +++ b/arch/powerpc/kernel/misc.S
> @@ -110,7 +110,7 @@ _GLOBAL(longjmp)
> li r3, 1
> blr
>
> -_GLOBAL(current_stack_pointer)
> +_GLOBAL(current_stack_frame)
> PPC_LL r3,0(r1)
> blr
> -EXPORT_SYMBOL(current_stack_pointer)
> +EXPORT_SYMBOL(current_stack_frame)
> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> index e730b8e522b0..110db94cdf3c 100644
> --- a/arch/powerpc/kernel/process.c
> +++ b/arch/powerpc/kernel/process.c
> @@ -2051,7 +2051,7 @@ void show_stack(struct task_struct *tsk, unsigned long *stack)
> sp = (unsigned long) stack;
> if (sp == 0) {
> if (tsk == current)
> - sp = current_stack_pointer();
> + sp = current_stack_frame();
> else
> sp = tsk->thread.ksp;
> }
> diff --git a/arch/powerpc/kernel/stacktrace.c b/arch/powerpc/kernel/stacktrace.c
> index e2a46cfed5fd..c477b8585a29 100644
> --- a/arch/powerpc/kernel/stacktrace.c
> +++ b/arch/powerpc/kernel/stacktrace.c
> @@ -57,7 +57,7 @@ void save_stack_trace(struct stack_trace *trace)
> {
> unsigned long sp;
>
> - sp = current_stack_pointer();
> + sp = current_stack_frame();
>
> save_context_stack(trace, sp, current, 1);
> }
> @@ -71,7 +71,7 @@ void save_stack_trace_tsk(struct task_struct *tsk, struct stack_trace *trace)
> return;
>
> if (tsk == current)
> - sp = current_stack_pointer();
> + sp = current_stack_frame();
> else
> sp = tsk->thread.ksp;
>
> @@ -131,7 +131,7 @@ static int __save_stack_trace_tsk_reliable(struct task_struct *tsk,
> }
>
> if (tsk == current)
> - sp = current_stack_pointer();
> + sp = current_stack_frame();
> else
> sp = tsk->thread.ksp;
>
>
^ permalink raw reply
* Re: [PATCH v2 02/42] KVM: s390/interrupt: do not pin adapter interrupt pages
From: Christian Borntraeger @ 2020-02-20 13:31 UTC (permalink / raw)
To: David Hildenbrand, Janosch Frank
Cc: KVM, Cornelia Huck, Thomas Huth, Ulrich Weigand, Claudio Imbrenda,
linux-s390, Michael Mueller, Vasily Gorbik
In-Reply-To: <073d3666-480e-5ba5-a46b-4cbd615f4174@redhat.com>
On 17.02.20 10:43, David Hildenbrand wrote:
> On 14.02.20 23:26, Christian Borntraeger wrote:
>> From: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
>>
>> The adapter interrupt page containing the indicator bits is currently
>> pinned. That means that a guest with many devices can pin a lot of
>> memory pages in the host. This also complicates the reference tracking
>> which is needed for memory management handling of protected virtual
>> machines. It might also have some strange side effects for madvise
>> MADV_DONTNEED and other things.
>>
>> We can simply try to get the userspace page set the bits and free the
>> page. By storing the userspace address in the irq routing entry instead
>> of the guest address we can actually avoid many lookups and list walks
>> so that this variant is very likely not slower.
>>
>> If userspace messes around with the memory slots the worst thing that
>> can happen is that we write to some other memory within that process.
>> As we get the the page with FOLL_WRITE this can also not be used to
>> write to shared read-only pages.
>>
>> Signed-off-by: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
>> [borntraeger@de.ibm.com: patch simplification]
>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>> ---
>> Documentation/virt/kvm/devices/s390_flic.rst | 11 +-
>> arch/s390/include/asm/kvm_host.h | 3 -
>> arch/s390/kvm/interrupt.c | 170 ++++++-------------
>> 3 files changed, 53 insertions(+), 131 deletions(-)
>>
>> diff --git a/Documentation/virt/kvm/devices/s390_flic.rst b/Documentation/virt/kvm/devices/s390_flic.rst
>> index 954190da7d04..ea96559ba501 100644
>> --- a/Documentation/virt/kvm/devices/s390_flic.rst
>> +++ b/Documentation/virt/kvm/devices/s390_flic.rst
>> @@ -108,16 +108,9 @@ Groups:
>> mask or unmask the adapter, as specified in mask
>>
>> KVM_S390_IO_ADAPTER_MAP
>> - perform a gmap translation for the guest address provided in addr,
>> - pin a userspace page for the translated address and add it to the
>> - list of mappings
>> -
>> - .. note:: A new mapping will be created unconditionally; therefore,
>> - the calling code should avoid making duplicate mappings.
>> -
>> + This is now a no-op. The mapping is purely done by the irq route.
>> KVM_S390_IO_ADAPTER_UNMAP
>> - release a userspace page for the translated address specified in addr
>> - from the list of mappings
>> + This is now a no-op. The mapping is purely done by the irq route.
>>
>
> The interface should have accepted a hva from the very start and not
> guest addresses ...
right, but that is history.
>
> [...]
>> + /*
>> + * We resolve the gpa to hva when setting the IRQ routing. the set_irq
>> + * code uses get_user_pages_remote to do the actual write.
>
> nit: "get_user_pages_remote()"
ack.
>
>> + */
>> case KVM_S390_IO_ADAPTER_MAP:
>> - ret = kvm_s390_adapter_map(dev->kvm, req.id, req.addr);
>> - break;
>> case KVM_S390_IO_ADAPTER_UNMAP:
>> - ret = kvm_s390_adapter_unmap(dev->kvm, req.id, req.addr);
>> - break;
>> + return 0;
>> default:
>> ret = -EINVAL;
>> }
>> @@ -2699,19 +2622,21 @@ static unsigned long get_ind_bit(__u64 addr, unsigned long bit_nr, bool swap)
>> return swap ? (bit ^ (BITS_PER_LONG - 1)) : bit;
>> }
>>
>> -static struct s390_map_info *get_map_info(struct s390_io_adapter *adapter,
>> - u64 addr)
>> +static struct page *get_map_page(struct kvm *kvm,
>> + struct s390_io_adapter *adapter,
>> + u64 uaddr)
>> {
>> - struct s390_map_info *map;
>> + struct page *page = NULL;
>>
>> if (!adapter)
>> return NULL;
>
> AFAIKs, this check is not necessary.
Right otherwise we would crash earlier.
>
>> -
>> - list_for_each_entry(map, &adapter->maps, list) {
>> - if (map->guest_addr == addr)
>> - return map;
>> - }
>> - return NULL;
>> + if (!uaddr)
>> + return NULL;
>
> I do wonder if that check is necessary. I don't think so but might be
> missing something.
Nothing should break when we remove this check. get_user_pages_remote will
also return NULL (as newer kernels usually forbid mapping things at 0).
Will remove.
[...]
>> @@ -2818,23 +2746,27 @@ int kvm_set_routing_entry(struct kvm *kvm,
>> struct kvm_kernel_irq_routing_entry *e,
>> const struct kvm_irq_routing_entry *ue)
>> {
>> - int ret;
>> + u64 uaddr;
>>
>> switch (ue->type) {
>> + /* we store the userspace addresses instead of the guest addresses */
>> case KVM_IRQ_ROUTING_S390_ADAPTER:
>> e->set = set_adapter_int;
>> - e->adapter.summary_addr = ue->u.adapter.summary_addr;
>> - e->adapter.ind_addr = ue->u.adapter.ind_addr;
>> + uaddr = gmap_translate(kvm->arch.gmap, ue->u.adapter.summary_addr);
>> + if (uaddr == -EFAULT)
>> + return -EFAULT;
>> + e->adapter.summary_addr = uaddr;
>> + uaddr = gmap_translate(kvm->arch.gmap, ue->u.adapter.ind_addr);
>> + if (uaddr == -EFAULT)
>> + return -EFAULT;
>
> AFAIK, leaving e->adapter.summary_addr set is not an issue.
>
> Interesting, in kvm_s390_adapter_map(), we didn't synchronize again slot
> updates when doing the gmap_translate(), which looks wrong to me ...
>
> It seems to be the same thing here. I do wonder if it is safe to do a
> gmap_translate() here, looks like this can race with
> kvm_arch_commit_memory_region().
>
> I would have assumed we need e.g., the slots_lock while doing the
> gmap_translate() - or a srcu_read_lock(&vcpu->kvm->srcu) or similar ...
gmap_translate does this via the gmap and it holds the mm sem. gmap_unmap_segment
takes the same lock. So I think we are ok here.
>
> Apart from that, looks good to me.
>
^ permalink raw reply
* [Xen-devel] [XEN PATCH v2] libxl: wait for console path before firing console_available
From: Paweł Marczewski @ 2020-02-20 13:31 UTC (permalink / raw)
To: xen-devel
Cc: Anthony PERARD, Paweł Marczewski, Ian Jackson,
Marek Marczykowski-Górecki, Wei Liu
If we skip the bootloader, the TTY path will be set for xenconsoled.
However, there is no guarantee that this will happen by the time we
want to call the console_available callback, so we have to wait.
Signed-off-by: Paweł Marczewski <pawel@invisiblethingslab.com>
---
Changed since v1:
* use xswait mechanism to add a timeout
As mentioned before, this is to fix a race condition that appears when
using libxl via libvirt and not using bootloader (console_available
fires too early).
I have tested the patch on Qubes OS 4.1 (with Xen 4.13), and it seems
to solve the problem. I also checked the timeout: when xenconsoled is
stopped, libxl waits for 10 seconds and then aborts domain creation.
tools/libxl/libxl_create.c | 43 +++++++++++++++++++++++++++++++++---
tools/libxl/libxl_internal.h | 1 +
2 files changed, 41 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 3a7364e2ac..4b150d92b9 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1190,6 +1190,33 @@ static void domcreate_console_available(libxl__egc *egc,
dcs->aop_console_how.for_event));
}
+static void console_xswait_callback(libxl__egc *egc, libxl__xswait_state *xswa,
+ int rc, const char *p)
+{
+ EGC_GC;
+ libxl__domain_create_state *dcs = CONTAINER_OF(xswa, *dcs, console_xswait);
+ char *dompath = libxl__xs_get_dompath(gc, dcs->guest_domid);
+ char *tty_path = GCSPRINTF("%s/console/tty", dompath);
+ char *tty;
+
+ if (rc) {
+ if (rc == ERROR_TIMEDOUT)
+ LOG(ERROR, "%s: timed out", xswa->what);
+ libxl__xswait_stop(gc, xswa);
+ domcreate_complete(egc, dcs, rc);
+ return;
+ }
+
+ tty = libxl__xs_read(gc, XBT_NULL, tty_path);
+
+ if (tty && tty[0] != '\0') {
+ libxl__xswait_stop(gc, xswa);
+
+ domcreate_console_available(egc, dcs);
+ domcreate_complete(egc, dcs, 0);
+ }
+}
+
static void domcreate_bootloader_done(libxl__egc *egc,
libxl__bootloader_state *bl,
int rc)
@@ -1728,9 +1755,18 @@ static void domcreate_attach_devices(libxl__egc *egc,
return;
}
- domcreate_console_available(egc, dcs);
-
- domcreate_complete(egc, dcs, 0);
+ dcs->console_xswait.ao = ao;
+ dcs->console_xswait.what = GCSPRINTF("domain %d console tty", domid);
+ dcs->console_xswait.path = GCSPRINTF("%s/console/tty",
+ libxl__xs_get_dompath(gc, domid));
+ dcs->console_xswait.timeout_ms = 10 * 1000;
+ dcs->console_xswait.callback = console_xswait_callback;
+ ret = libxl__xswait_start(gc, &dcs->console_xswait);
+ if (ret) {
+ LOG(ERROR, "unable to set up watch for domain %d console path",
+ domid);
+ goto error_out;
+ }
return;
@@ -1861,6 +1897,7 @@ static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
libxl__ao_progress_gethow(&cdcs->dcs.aop_console_how, aop_console_how);
cdcs->domid_out = domid;
+ libxl__xswait_init(&cdcs->dcs.console_xswait);
initiate_domain_create(egc, &cdcs->dcs);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4936446069..d8129417dc 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -4180,6 +4180,7 @@ struct libxl__domain_create_state {
/* necessary if the domain creation failed and we have to destroy it */
libxl__domain_destroy_state dds;
libxl__multidev multidev;
+ libxl__xswait_state console_xswait;
};
_hidden int libxl__device_nic_set_devids(libxl__gc *gc,
--
2.21.1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related
* [PATCH] mt76: mt76u: rely only on data buffer for usb control messagges
From: Lorenzo Bianconi @ 2020-02-20 13:31 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, stf_xl
Starting from commit 'a6bfb6d13f33 ("mt76: usb: use max packet length
for m76u_copy")' reg_val does not share memory with usb data buffer.
On non-coherent devices this approach can corrupt data pointer since data
and reg_val share the same cache-line, resulting in the following crash:
[ 371.544901] CPU 0 Unable to handle kernel paging request at virtual address 00000000, epc == 8042fbb0
[ 371.558521] CPU: 0 PID: 11 Comm: kworker/u2:2 Not tainted 4.14.160 #0
[ 371.565204] Workqueue: mt76u mt76u_deinit [mt76_usb]
[ 371.570331] task: 83823ac0 task.stack: 8386c000
[ 371.575004] $ 0 : 00000000 80590000 00000000 00000000
[ 371.580407] $ 4 : 82edaad0 00000002 83823ac0 fffffff8
[ 371.585810] $ 8 : fffffffd 0000fc00 8052da00 00000000
[ 371.591212] $12 : 000b2285 ae53a1a9 00108845 89da44c4
[ 371.596615] $16 : 82edaad0 82ed9d20 00001798 832edf00
[ 371.602019] $20 : 00000000 8386dda8 80530000 fffffffe
[ 371.607421] $24 : 8051d040 76274d1b
[ 371.612824] $28 : 8386c000 8386dd88 82edaad4 830d4d50
[ 371.618228] Hi : 000000f7
[ 371.621203] Lo : 33333371
[ 371.624196] epc : 8042fbb0 __mutex_lock.isra.2+0x134/0x378
[ 371.630043] ra : 830d4d50 mt76u_deinit+0x418/0xa6c [mt76_usb]
[ 371.636237] Status: 1000fc03KERNEL EXL IE
[ 371.640557] Cause : 0080000c (ExcCode 03)
[ 371.644696] BadVA : 00000000
[ 371.647671] PrId : 00019374 (MIPS 24Kc)
[ 371.726123] usbcore nls_base usb_common
[ 371.730180] Process kworker/u2:2 (pid: 11, threadinfo=8386c000, task=83823ac0, tls=00000000)
[ 371.738884] Stack : 833d009c 83210b4c 82ed8bc0 8386ddac 000001ff 8008ac50 8386ddac 83b74b00
[ 371.747519] 82edaad4 00000000 83b74b48 83210c38 82edaad0 82ed9d20 00001798 832edf00
[ 371.756157] 00000000 00000000 80530000 fffffffe 80530000 830d4d50 00000040 8389d850
[ 371.764794] 8052d9d8 8389d850 8386de30 82ed9d20 8386de5f 831c27bc 833d48ec 8052d9d8
[ 371.773431] 83823ac0 83823af0 82edab00 82ed9d20 8386de5f 831c5c30 00000000 8052d9a8
[ 371.782069] ...
[ 371.784598] Call Trace:
[ 371.787130] [<8042fbb0>] __mutex_lock.isra.2+0x134/0x378
[ 371.792622] [<830d4d50>] mt76u_deinit+0x418/0xa6c [mt76_usb]
[ 371.808546]
[ 371.810920] ---[ end trace c62f0601f6730eb0 ]---
[ 371.818101] Kernel panic - not syncing: Fatal exception
[ 371.824420] Rebooting in 3 seconds..
Fix the issue relying only on data buffer to send/receive usb control messages
Fixes: a6bfb6d13f33 ("mt76: usb: use max packet length for m76u_copy")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt76.h | 1 -
drivers/net/wireless/mediatek/mt76/usb.c | 8 ++++----
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h b/drivers/net/wireless/mediatek/mt76/mt76.h
index 2e57e7c6bd29..aca477434858 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -403,7 +403,6 @@ struct mt76_mcu {
#define MCU_RESP_URB_SIZE 1024
struct mt76_usb {
struct mutex usb_ctrl_mtx;
- __le32 reg_val;
u8 *data;
u16 data_len;
diff --git a/drivers/net/wireless/mediatek/mt76/usb.c b/drivers/net/wireless/mediatek/mt76/usb.c
index 2c0dbc36f9aa..3535577db1c6 100644
--- a/drivers/net/wireless/mediatek/mt76/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/usb.c
@@ -70,10 +70,10 @@ static u32 ___mt76u_rr(struct mt76_dev *dev, u8 req, u32 addr)
ret = __mt76u_vendor_request(dev, req,
USB_DIR_IN | USB_TYPE_VENDOR,
- addr >> 16, addr, &usb->reg_val,
+ addr >> 16, addr, usb->data,
sizeof(__le32));
if (ret == sizeof(__le32))
- data = le32_to_cpu(usb->reg_val);
+ data = get_unaligned_le32(usb->data);
trace_usb_reg_rr(dev, addr, data);
return data;
@@ -125,10 +125,10 @@ static void ___mt76u_wr(struct mt76_dev *dev, u8 req,
{
struct mt76_usb *usb = &dev->usb;
- usb->reg_val = cpu_to_le32(val);
+ put_unaligned_le32(val, usb->data);
__mt76u_vendor_request(dev, req,
USB_DIR_OUT | USB_TYPE_VENDOR,
- addr >> 16, addr, &usb->reg_val,
+ addr >> 16, addr, usb->data,
sizeof(__le32));
trace_usb_reg_wr(dev, addr, val);
}
--
2.24.1
^ permalink raw reply related
* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
From: Robin Murphy @ 2020-02-20 13:32 UTC (permalink / raw)
To: Marc Zyngier, Marek Szyprowski
Cc: Vladimir Murzin, Russell King, kvm, Arnd Bergmann,
Suzuki K Poulose, Quentin Perret, Christoffer Dall,
Krzysztof Kozlowski, Bartlomiej Zolnierkiewicz, James Morse,
Julien Thierry, Paolo Bonzini, Will Deacon, kvmarm,
linux-arm-kernel
In-Reply-To: <43446bd5e884ae92f243799cbe748871@kernel.org>
On 20/02/2020 1:15 pm, Marc Zyngier wrote:
> Hi Marek,
>
> On 2020-02-20 12:44, Marek Szyprowski wrote:
>> Hi Marc,
>>
>> On 10.02.2020 15:13, Marc Zyngier wrote:
>>> KVM/arm was merged just over 7 years ago, and has lived a very quiet
>>> life so far. It mostly works if you're prepared to deal with its
>>> limitations, it has been a good prototype for the arm64 version,
>>> but it suffers a few problems:
>>>
>>> - It is incomplete (no debug support, no PMU)
>>> - It hasn't followed any of the architectural evolutions
>>> - It has zero users (I don't count myself here)
>>> - It is more and more getting in the way of new arm64 developments
>>
>> That is a bit sad information. Mainline Exynos finally got everything
>> that was needed to run it on the quite popular Samsung Exynos5422-based
>> Odroid XU4/HC1/MC1 boards. According to the Odroid related forums it is
>> being used. We also use it internally at Samsung.
>
> Something like "too little, too late" springs to mind, but let's be
> constructive. Is anyone using it in a production environment, where
> they rely on the latest mainline kernel having KVM support?
>
> The current proposal is to still have KVM support in 5.6, as well as
> ongoing support for stable kernels. If that's not enough, can you please
> explain your precise use case?
Presumably there's no *technical* reason why the stable subset of v7
support couldn't be stripped down and brought back private to arch/arm
if somebody really wants and is willing to step up and look after it?
Robin.
^ permalink raw reply
* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
From: Robin Murphy @ 2020-02-20 13:32 UTC (permalink / raw)
To: Marc Zyngier, Marek Szyprowski
Cc: Russell King, kvm, Arnd Bergmann, Krzysztof Kozlowski,
Bartlomiej Zolnierkiewicz, linux-arm-kernel, Paolo Bonzini,
Will Deacon, kvmarm
In-Reply-To: <43446bd5e884ae92f243799cbe748871@kernel.org>
On 20/02/2020 1:15 pm, Marc Zyngier wrote:
> Hi Marek,
>
> On 2020-02-20 12:44, Marek Szyprowski wrote:
>> Hi Marc,
>>
>> On 10.02.2020 15:13, Marc Zyngier wrote:
>>> KVM/arm was merged just over 7 years ago, and has lived a very quiet
>>> life so far. It mostly works if you're prepared to deal with its
>>> limitations, it has been a good prototype for the arm64 version,
>>> but it suffers a few problems:
>>>
>>> - It is incomplete (no debug support, no PMU)
>>> - It hasn't followed any of the architectural evolutions
>>> - It has zero users (I don't count myself here)
>>> - It is more and more getting in the way of new arm64 developments
>>
>> That is a bit sad information. Mainline Exynos finally got everything
>> that was needed to run it on the quite popular Samsung Exynos5422-based
>> Odroid XU4/HC1/MC1 boards. According to the Odroid related forums it is
>> being used. We also use it internally at Samsung.
>
> Something like "too little, too late" springs to mind, but let's be
> constructive. Is anyone using it in a production environment, where
> they rely on the latest mainline kernel having KVM support?
>
> The current proposal is to still have KVM support in 5.6, as well as
> ongoing support for stable kernels. If that's not enough, can you please
> explain your precise use case?
Presumably there's no *technical* reason why the stable subset of v7
support couldn't be stripped down and brought back private to arch/arm
if somebody really wants and is willing to step up and look after it?
Robin.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply
* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
From: Robin Murphy @ 2020-02-20 13:32 UTC (permalink / raw)
To: Marc Zyngier, Marek Szyprowski
Cc: Vladimir Murzin, Russell King, kvm, Arnd Bergmann, Quentin Perret,
Suzuki K Poulose, Christoffer Dall, Krzysztof Kozlowski,
Bartlomiej Zolnierkiewicz, James Morse, linux-arm-kernel,
Paolo Bonzini, Will Deacon, kvmarm, Julien Thierry
In-Reply-To: <43446bd5e884ae92f243799cbe748871@kernel.org>
On 20/02/2020 1:15 pm, Marc Zyngier wrote:
> Hi Marek,
>
> On 2020-02-20 12:44, Marek Szyprowski wrote:
>> Hi Marc,
>>
>> On 10.02.2020 15:13, Marc Zyngier wrote:
>>> KVM/arm was merged just over 7 years ago, and has lived a very quiet
>>> life so far. It mostly works if you're prepared to deal with its
>>> limitations, it has been a good prototype for the arm64 version,
>>> but it suffers a few problems:
>>>
>>> - It is incomplete (no debug support, no PMU)
>>> - It hasn't followed any of the architectural evolutions
>>> - It has zero users (I don't count myself here)
>>> - It is more and more getting in the way of new arm64 developments
>>
>> That is a bit sad information. Mainline Exynos finally got everything
>> that was needed to run it on the quite popular Samsung Exynos5422-based
>> Odroid XU4/HC1/MC1 boards. According to the Odroid related forums it is
>> being used. We also use it internally at Samsung.
>
> Something like "too little, too late" springs to mind, but let's be
> constructive. Is anyone using it in a production environment, where
> they rely on the latest mainline kernel having KVM support?
>
> The current proposal is to still have KVM support in 5.6, as well as
> ongoing support for stable kernels. If that's not enough, can you please
> explain your precise use case?
Presumably there's no *technical* reason why the stable subset of v7
support couldn't be stripped down and brought back private to arch/arm
if somebody really wants and is willing to step up and look after it?
Robin.
_______________________________________________
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 rdma-next 2/2] RDMA/opa_vnic: Delete driver version
From: Dennis Dalessandro @ 2020-02-20 13:32 UTC (permalink / raw)
To: Leon Romanovsky, Doug Ledford, Jason Gunthorpe
Cc: Leon Romanovsky, RDMA mailing list
In-Reply-To: <20200220071239.231800-3-leon@kernel.org>
On 2/20/2020 2:12 AM, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@mellanox.com>
>
> The default version provided by "ethtool -i" it the correct way
> to identify Driver version. There is no need to overwrite it.
>
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> ---
> drivers/infiniband/ulp/opa_vnic/opa_vnic_ethtool.c | 2 --
> drivers/infiniband/ulp/opa_vnic/opa_vnic_internal.h | 1 -
> drivers/infiniband/ulp/opa_vnic/opa_vnic_vema.c | 5 -----
> 3 files changed, 8 deletions(-)
>
> diff --git a/drivers/infiniband/ulp/opa_vnic/opa_vnic_ethtool.c b/drivers/infiniband/ulp/opa_vnic/opa_vnic_ethtool.c
> index 8ad7da989a0e..42d557dff19d 100644
> --- a/drivers/infiniband/ulp/opa_vnic/opa_vnic_ethtool.c
> +++ b/drivers/infiniband/ulp/opa_vnic/opa_vnic_ethtool.c
> @@ -125,8 +125,6 @@ static void vnic_get_drvinfo(struct net_device *netdev,
> struct ethtool_drvinfo *drvinfo)
> {
> strlcpy(drvinfo->driver, opa_vnic_driver_name, sizeof(drvinfo->driver));
> - strlcpy(drvinfo->version, opa_vnic_driver_version,
> - sizeof(drvinfo->version));
> strlcpy(drvinfo->bus_info, dev_name(netdev->dev.parent),
> sizeof(drvinfo->bus_info));
> }
Is there a patch series to get rid of drvinfo->version? Seems to me if
we don't want drivers to set it then we don't need it to begin with do we?
Regardless I don't have any objections to the patch. We've been down
this road with version numbers and I believe this was added to vnic
specifically to fill in something for ethtool.
Reviewed-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
-Denny
^ permalink raw reply
* Re: [PATCH v9 1/3] Acceptance tests: introduce BUILD_DIR and SOURCE_DIR
From: Wainer dos Santos Moschetta @ 2020-02-20 13:31 UTC (permalink / raw)
To: Cleber Rosa, qemu-devel
Cc: Fam Zheng, Eduardo Habkost, Alex Bennée, Willian Rampazzo,
Philippe Mathieu-Daudé, Beraldo Leal
In-Reply-To: <20200220020652.16276-2-crosa@redhat.com>
On 2/19/20 11:06 PM, Cleber Rosa wrote:
> Some tests may benefit from using resources from a build directory.
> This introduces three variables that can help tests find resources in
> those directories.
>
> First, a BUILD_DIR is assumed to exist, given that the primary form of
> running the acceptance tests is from a build directory (which may or
> may not be the same as the source tree, that is, the SOURCE_DIR).
>
> If the directory containing the acceptance tests happens to be a link
> to a directory, it's assumed to it points to the source tree
> (SOURCE_DIR), which is the behavior defined on the QEMU Makefiles. If
> the directory containing the acceptance tests is not a link, then a
> in-tree build is assumed, and the BUILD_DIR and SOURCE_DIR have the
> same value.
>
> Signed-off-by: Cleber Rosa <crosa@redhat.com>
> ---
> tests/acceptance/avocado_qemu/__init__.py | 25 +++++++++++++++++------
> 1 file changed, 19 insertions(+), 6 deletions(-)
Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com>
Also tested with QEMU built outside of source dir:
Tested-by: Wainer dos Santos Moschetta <wainersm@redhat.com>
>
> diff --git a/tests/acceptance/avocado_qemu/__init__.py b/tests/acceptance/avocado_qemu/__init__.py
> index d4358eb431..59e7b4f763 100644
> --- a/tests/acceptance/avocado_qemu/__init__.py
> +++ b/tests/acceptance/avocado_qemu/__init__.py
> @@ -16,8 +16,21 @@ import tempfile
>
> import avocado
>
> -SRC_ROOT_DIR = os.path.join(os.path.dirname(__file__), '..', '..', '..')
> -sys.path.append(os.path.join(SRC_ROOT_DIR, 'python'))
> +#: The QEMU build root directory. It may also be the source directory
> +#: if building from the source dir, but it's safer to use BUILD_DIR for
> +#: that purpose. Be aware that if this code is moved outside of a source
> +#: and build tree, it will not be accurate.
> +BUILD_DIR = os.path.dirname(os.path.dirname(os.path.dirname(os.path.dirname(__file__))))
> +
> +if os.path.islink(os.path.dirname(os.path.dirname(__file__))):
> + # The link to the acceptance tests dir in the source code directory
> + lnk = os.path.dirname(os.path.dirname(__file__))
> + #: The QEMU root source directory
> + SOURCE_DIR = os.path.dirname(os.path.dirname(os.readlink(lnk)))
> +else:
> + SOURCE_DIR = BUILD_DIR
> +
> +sys.path.append(os.path.join(SOURCE_DIR, 'python'))
>
> from qemu.machine import QEMUMachine
>
> @@ -49,10 +62,10 @@ def pick_default_qemu_bin(arch=None):
> if is_readable_executable_file(qemu_bin_relative_path):
> return qemu_bin_relative_path
>
> - qemu_bin_from_src_dir_path = os.path.join(SRC_ROOT_DIR,
> + qemu_bin_from_bld_dir_path = os.path.join(BUILD_DIR,
> qemu_bin_relative_path)
> - if is_readable_executable_file(qemu_bin_from_src_dir_path):
> - return qemu_bin_from_src_dir_path
> + if is_readable_executable_file(qemu_bin_from_bld_dir_path):
> + return qemu_bin_from_bld_dir_path
>
>
> def _console_interaction(test, success_message, failure_message,
> @@ -153,7 +166,7 @@ class Test(avocado.Test):
> self.qemu_bin = self.params.get('qemu_bin',
> default=default_qemu_bin)
> if self.qemu_bin is None:
> - self.cancel("No QEMU binary defined or found in the source tree")
> + self.cancel("No QEMU binary defined or found in the build tree")
>
> def _new_vm(self, *args):
> vm = QEMUMachine(self.qemu_bin, sock_dir=tempfile.mkdtemp())
^ permalink raw reply
* Re: [RFC PATCH v3 4/6] media: tegra: Add Tegra210 Video input driver
From: Hans Verkuil @ 2020-02-20 13:33 UTC (permalink / raw)
To: Sowjanya Komatineni, thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
jonathanh-DDmLM1+adcrQT0dZR+AlfA, frankc-DDmLM1+adcrQT0dZR+AlfA,
helen.koike-ZGY8ohtN/8qB+jHODAdFcQ, sboyd-DgEjT+Ai2ygdnm+yROfE0A
Cc: linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <b301c247-537d-d78e-b057-a3225b10de7e-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
(Replying to myself so I can explain this a bit more)
On 2/20/20 1:44 PM, Hans Verkuil wrote:
>> +
>> +static int tegra_csi_tpg_channels_alloc(struct tegra_csi *csi)
>> +{
>> + struct device_node *node = csi->dev->of_node;
>> + unsigned int port_num;
>> + int ret;
>> + struct tegra_csi_channel *item;
>> + unsigned int tpg_channels = csi->soc->csi_max_channels;
>> +
>> + /* allocate CSI channel for each CSI x2 ports */
>> + for (port_num = 0; port_num < tpg_channels; port_num++) {
>> + item = devm_kzalloc(csi->dev, sizeof(*item), GFP_KERNEL);
>
> Using devm_*alloc can be dangerous. If someone unbinds the driver, then
> all memory allocated with devm_ is immediately freed. But if an application
> still has a filehandle open, then when it closes it it might still reference
> this already-freed memory.
>
> I recommend that you avoid using devm_*alloc for media drivers.
A good test is to unbind & bind the driver:
cd /sys/devices/platform/50000000.host1x/54080000.vi/driver
echo -n 54080000.vi >unbind
echo -n 54080000.vi >bind
First just do this without the driver being used. That already
gives me 'list_del corruption' kernel messages (list debugging
is turned on in my kernel).
Note that this first test is basically identical to a rmmod/modprobe
of the driver. But when I compiled the driver as a module it didn't
create any video device nodes! Nor did I see any errors in the kernel
log. I didn't pursue this, and perhaps I did something wrong, but it's
worth taking a look at.
The next step would be to have a video node open with:
v4l2-ctl --sleep 10
then while it is sleeping unbind the driver and see what happens
when v4l2-ctl exits.
Worst case is when you are streaming:
v4l2-ctl --stream-mmap
and then unbind.
In general, the best way to get this to work correctly is:
1) don't use devm_*alloc
2) set the release callback of struct v4l2_device and do all freeing there.
3) in the platform remove() callback you call media_device_unregister()
and video_unregister_device().
It's worth getting this right in this early stage, rather than fixing it
in the future.
Regards,
Hans
^ permalink raw reply
* Re: [RFC PATCH v3 4/6] media: tegra: Add Tegra210 Video input driver
From: Hans Verkuil @ 2020-02-20 13:33 UTC (permalink / raw)
To: Sowjanya Komatineni, thierry.reding, jonathanh, frankc,
helen.koike, sboyd
Cc: linux-media, devicetree, linux-clk, linux-tegra, linux-kernel
In-Reply-To: <b301c247-537d-d78e-b057-a3225b10de7e@xs4all.nl>
(Replying to myself so I can explain this a bit more)
On 2/20/20 1:44 PM, Hans Verkuil wrote:
>> +
>> +static int tegra_csi_tpg_channels_alloc(struct tegra_csi *csi)
>> +{
>> + struct device_node *node = csi->dev->of_node;
>> + unsigned int port_num;
>> + int ret;
>> + struct tegra_csi_channel *item;
>> + unsigned int tpg_channels = csi->soc->csi_max_channels;
>> +
>> + /* allocate CSI channel for each CSI x2 ports */
>> + for (port_num = 0; port_num < tpg_channels; port_num++) {
>> + item = devm_kzalloc(csi->dev, sizeof(*item), GFP_KERNEL);
>
> Using devm_*alloc can be dangerous. If someone unbinds the driver, then
> all memory allocated with devm_ is immediately freed. But if an application
> still has a filehandle open, then when it closes it it might still reference
> this already-freed memory.
>
> I recommend that you avoid using devm_*alloc for media drivers.
A good test is to unbind & bind the driver:
cd /sys/devices/platform/50000000.host1x/54080000.vi/driver
echo -n 54080000.vi >unbind
echo -n 54080000.vi >bind
First just do this without the driver being used. That already
gives me 'list_del corruption' kernel messages (list debugging
is turned on in my kernel).
Note that this first test is basically identical to a rmmod/modprobe
of the driver. But when I compiled the driver as a module it didn't
create any video device nodes! Nor did I see any errors in the kernel
log. I didn't pursue this, and perhaps I did something wrong, but it's
worth taking a look at.
The next step would be to have a video node open with:
v4l2-ctl --sleep 10
then while it is sleeping unbind the driver and see what happens
when v4l2-ctl exits.
Worst case is when you are streaming:
v4l2-ctl --stream-mmap
and then unbind.
In general, the best way to get this to work correctly is:
1) don't use devm_*alloc
2) set the release callback of struct v4l2_device and do all freeing there.
3) in the platform remove() callback you call media_device_unregister()
and video_unregister_device().
It's worth getting this right in this early stage, rather than fixing it
in the future.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH v5 03/12] ceph: add infrastructure for waiting for async create to complete
From: Yan, Zheng @ 2020-02-20 13:33 UTC (permalink / raw)
To: Jeff Layton
Cc: ceph-devel, Ilya Dryomov, Sage Weil, Zheng Yan, Patrick Donnelly,
Xiubo Li
In-Reply-To: <89ba8857af29c0e877d22e2188f86142f316454a.camel@kernel.org>
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.
> 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.
>
> > > 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>
>
^ 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.