Lockdep complains about potential recursive locking during mount
because the client configuration log is holding a lock on the MGC
obd_device to prevent it from being torn down, while also getting
mutexes on the MDC and OSC devices as they are instantiated:
Lustre: Mounted myth-client
=============================================
[ INFO: possible recursive locking detected ]
4.7.0-rc2-vm-nfs+ #127 Tainted: G C
---------------------------------------------
May be due to missing lock nesting notation
2 locks held by ll_cfg_requeue/5928:
#0: (&cli->cl_sem){.+.+.+}, at: mgc_requeue_thread+0x15d/0x730 [mgc]
#1: (&cld->cld_lock){+.+.+.}, at: mgc_process_log+0x5e/0xf80 [mgc]
CPU: 0 PID: 5928 Comm: ll_cfg_requeue
Call Trace:
[<ffffffff814a0855>] dump_stack+0x86/0xc1
[<ffffffff810e7766>] __lock_acquire+0x726/0x1210
[<ffffffff810e86be>] lock_acquire+0xfe/0x1f0
[<ffffffff81888171>] down_read+0x51/0xa0
[<ffffffffa04a8477>] sptlrpc_conf_client_adapt+0x47/0x150 [ptlrpc]
[<ffffffffa0186b16>] mdc_set_info_async+0x2b6/0x470 [mdc]
[<ffffffffa0294090>] class_notify_sptlrpc_conf+0x190/0x360 [obdclass]
[<ffffffffa01a9e85>] mgc_process_log+0x925/0xf80 [mgc]
[<ffffffffa01abafa>] mgc_requeue_thread+0x1fa/0x730 [mgc]
[<ffffffff810af331>] kthread+0x101/0x120
[<ffffffff8188ad6f>] ret_from_fork+0x1f/0x40
Add a separate lock class for the MGC callpath, since it will always
be held first, and none of the other obd_device locks should ever
be held concurrently.
Signed-off-by: Andreas Dilger <andreas.dilger@intel.com>
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
kthread_run might sleep during an allocation, and so
it's considered unsafe to call with a state that's not
RUNNABLE.
Move the state setting to after kthread_run call.
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
A deadlock is possible during ccc_prep_size()->ldlm_lock_match() vs
cl_io_lock() which is waiting for a matched lock and conflicts with
already taken lock before ccc_prep_size().
It is better to send an additional lock request to avoid deadlock.
Seagate-bug-id: MRP-3312
Signed-off-by: Andriy Skulysh <andriy.skulysh@seagate.com>
Reviewed-on: http://review.whamcloud.com/18738
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7829
Reviewed-by: Jinshan Xiong <jinshan.xiong@intel.com>
Reviewed-by: Bobi Jam <bobijam@hotmail.com>
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ac5b148109 ("staging: lustre: osc: Track and limit
"unstable" pages") added a new sysfs variable, but corresponding bit of
documentation was not forgotten.
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bit field 'oi_lockless' and 'oi_is_active' has one bit and is signed
which is confusing.
Signed-off-by: Dmitry Eremin <dmitry.eremin@intel.com>
Reviewed-on: http://review.whamcloud.com/19196
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7258
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: James Simmons <uja.ornl@yahoo.com>
Reviewed-by: Frank Zago <fzago@cray.com>
Reviewed-by: John L. Hammond <john.hammond@intel.com>
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
req_capsule_server_get() through __req_capsule_get in ll_dir_ioctl()
returns a pointer to a PTLRPC request or reply buffer, which is assigned
to struct mdt_body.
If the command is IOC_MDS_GETFILEINFO then the inode "st.st_ino" should
be assigned from one extracted from mdt_body through cl_fid_build_ino().
Signed-off-by: John Hammond <john.hammond@intel.com>
Signed-off-by: akam kumar bharathi <azurelustre@gmail.com>
Reviewed-on: http://review.whamcloud.com/17618
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5954
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There are a couple of cases in ll_revalidate_dentry() where
we are pretty sure the dentry is valid, so check for them early
and save more expensive checks for later.
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mark dentries that came to us via NFS in a special way so that
we can tell them apart during open and activate open cache
(we really don't want to do open/close RPC for every NFS IO).
This became needed since dentry revlidate no longer reimplements
any RPCs for lookup, and as such if a dentry is valid,
ll_revalidate_dentry returns 1 and ll_lookup_it() is never visited
during opens, we get straght into ll_file_open() without a valid
intent/RPC. This used to be only true for NFS, so opencache was
engaged needlessly, and it carries a cost of it's own if there is
in fact no repetitive file opening-closing going on
Signed-off-by: Oleg Drokin <oleg.drokin@intel.com>
Reviewed-on: http://review.whamcloud.com/20354
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8019
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: Li Xi <lixi@ddn.com>
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
LASSERT should never be done on data that is
received to over the network. Return EINVAL
when server returns invalid fid despite of
it_status == 0.
Signed-off-by: Sergey Cheremencev <sergey.cheremencev@seagate.com>
Seagate-bug-id: MRP-3073
Reviewed-on: http://review.whamcloud.com/17985
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7422
Reviewed-by: John L. Hammond <john.hammond@intel.com>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
While atime on close is supposed to only increase, there's
a bug in some older server versions where atime from a client
is taken no matter the value that allows a stale client atime
to overwrite a correct value.
Update atime in close rpc to 0 to help such servers out.
Signed-off-by: Niu Yawei <yawei.niu@intel.com>
Reviewed-on: http://review.whamcloud.com/19932
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8041
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: Jinshan Xiong <jinshan.xiong@intel.com>
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The watched obd device may still not setup while onu_upcall
invoked. So we need verify it in cl_ocd_update.
Signed-off-by: Yang Sheng <yang.sheng@intel.com>
Reviewed-on: http://review.whamcloud.com/19597
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8027
Reviewed-by: Niu Yawei <yawei.niu@intel.com>
Reviewed-by: Lai Siyao <lai.siyao@intel.com>
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add a const qualifier to several struct lustre_handle * parameters in
the LDLM interface.
Signed-off-by: John L. Hammond <john.hammond@intel.com>
Reviewed-on: http://review.whamcloud.com/17071
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7403
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: James Simmons <uja.ornl@yahoo.com>
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change the void *it_data member of struct lookup_intent to struct
ptlrpc_request *it_request.
Signed-off-by: John L. Hammond <john.hammond@intel.com>
Reviewed-on: http://review.whamcloud.com/17070
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7403
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: James Simmons <uja.ornl@yahoo.com>
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
They are just one-liners, so no point in having them exported
and called through a different module.
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Replace the union in struct lookup_intent with the members of struct
lustre_indent_data. Remove the then unused struct lustre_intent_data.
Signed-off-by: John L. Hammond <john.hammond@intel.com>
Reviewed-on: http://review.whamcloud.com/17069
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7403
Reviewed-by: James Simmons <uja.ornl@yahoo.com>
Reviewed-by: Dmitry Eremin <dmitry.eremin@intel.com>
Reviewed-by: Frank Zago <fzago@cray.com>
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
LU_OBJECT_DEBUG expects non \n terminated message from the caller,
so it should add it's own to keep debug logger happy.
Signed-off-by: Bob Glossman <bob.glossman@intel.com>
Reviewed-on: http://review.whamcloud.com/19960
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8094
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: Alex Zhuravlev <alexey.zhuravlev@intel.com>
Reviewed-by: John L. Hammond <john.hammond@intel.com>
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
as it adds own \n, so any extra \n break log format.
Signed-off-by: Alex Zhuravlev <alexey.zhuravlev@intel.com>
Reviewed-on: http://review.whamcloud.com/17494
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7521
Reviewed-by: James Simmons <uja.ornl@yahoo.com>
Reviewed-by: John L. Hammond <john.hammond@intel.com>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The lli_trunc_sem is taken in 'read' mode in both
ll_page_mkwrite and vvp_io_fault_start. This can lead to a
deadlock with another thread which asks for the semaphore
in write mode between thse two read calls.
Since all users of lli_trunc_sem are in the vvp layer, we
can satisfy the requirement to exclude truncate by taking
the semaphore only in vvp_io_fault_start.
Signed-off-by: Patrick Farrell <paf@cray.com>
Reviewed-on: http://review.whamcloud.com/19315
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7981
Reviewed-by: Jinshan Xiong <jinshan.xiong@intel.com>
Reviewed-by: Andriy Skulysh <andriy.skulysh@seagate.com>
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The reverse order of request_out_callback() and reply_in_callback()
puts the RPC into UNREGISTERING state, which is waiting for RPC &
bulk md unlink, whereas only RPC md unlink has been called so far.
If bulk is lost, even expired_set does not check for UNREGISTERING
state.
The same for write if server returns an error.
This phase is ambiguous, split to UNREG_RPC and UNREG_BULK.
Signed-off-by: Vitaly Fertman <vitaly.fertman@seagate.com>
Seagate-bug-id: MRP-2953, MRP-3206
Reviewed-by: Andriy Skulysh <andriy.skulysh@seagate.com>
Reviewed-by: Alexey Leonidovich Lyashkov <alexey.lyashkov@seagate.com>
Tested-by: Elena V. Gryaznova <elena.gryaznova@seagate.com>
Reviewed-on: http://review.whamcloud.com/19953
Reviewed-by: Chris Horn <hornc@cray.com>
Reviewed-by: Ann Koehler <amk@cray.com>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Combine __ptlrpc_request_bufs_pack into ptlrpc_request_bufs_pack
because it was an unnecessary wrapper otherwise.
Signed-off-by: Ben Evans <bevans@cray.com>
Reviewed-on: http://review.whamcloud.com/16765
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7269
Reviewed-by: Frank Zago <fzago@cray.com>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: John L. Hammond <john.hammond@intel.com>
Reviewed-by: Chris Horn <hornc@cray.com>
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
A race between unregister_reply & early reply.
When buffers are busy for the early transfer, they cannon be unlinked
by unregister_reply, so the RPC gets into UNREGISTERING state. The
coming reply_in_callback for the early RPC already has unlinked flag
set due to previous mdunlink attempt, but we handle it properly only
for UNILNK event, whereas this is PUT in this case.
Signed-off-by: Vitaly Fertman <vitaly.fertman@seagate.com>
Seagate-bug-id: MRP-3323
Reviewed-by: Alexey Leonidovich Lyashkov <alexey.lyashkov@seagate.com>
Reviewed-by: Andriy Skulysh <andriy.skulysh@seagate.com>
Tested-by: Parinay Vijayprakash Kondekar <parinay.kondekar@seagate.com>
Reviewed-on: http://review.whamcloud.com/18934
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7434
Reviewed-by: Chris Horn <hornc@cray.com>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch changes a few things:
- There is no guarantee that request_out_callback will happen
before reply_in_callback, if a request got reply and unlinked
reply buffer before request_out_callback is called, then the
thread waiting on ptlrpc_request_set will miss wakeup event.
This may seriously impact performance of some IO workloads or
result in RPC timeout
- To make code more easier to understand, this patch changes
action-bits "rq_req_unlink" and "rq_reply_unlink" to
status-bits "rq_req_unlinked" and "rq_reply_unlinked"
Signed-off-by: Liang Zhen <liang.zhen@intel.com>
Reviewed-on: http://review.whamcloud.com/12158
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5696
Reviewed-by: Johann Lombardi <johann.lombardi@intel.com>
Reviewed-by: Li Wei <wei.g.li@intel.com>
Reviewed-by: Mike Pershin <mike.pershin@intel.com>
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ptlrpc_request has some structure members are only for client side,
and some others are only for server side, this patch moved these
members to different structure then putting into an union.
By doing this, size of ptlrpc_request is decreased about 300 bytes,
besides saving memory, it also can reduce memory footprint while
processing.
Signed-off-by: Liang Zhen <liang.zhen@intel.com>
Reviewed-on: http://review.whamcloud.com/8806
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-181
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: Bobi Jam <bobijam@gmail.com>
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When imprting clio simplification patch, the check for
pbject got reversed by mistake when converting from
if (obj == NULL) it somehow became (if (obj) which is obviously wrong,
and so when it does hit, a crash was happening as result.
Fix the condition and all if fine now.
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
With huge number of pages to scan by osc_lock_weight() it is likely
CLP_GANG_RESCHED is returned from osc_page_gang_lookup() and the scan
will be repeated again from the start. To be sure that the scan is
progressing across those restarts, next scan should be started from
the last scanned page index plus one.
Xyratex-bug-id: MRP-2145
Signed-off-by: Alexander Zarochentsev <alexander.zarochentsev@seagate.com>
Signed-off-by: Jinshan Xiong <jinshan.xiong@intel.com>
Reviewed-on: http://review.whamcloud.com/12362
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5781
Reviewed-by: Bobi Jam <bobijam@hotmail.com>
Reviewed-by: James Simmons <uja.ornl@gmail.com>
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There has been several Lustre Client crashes reported by sites
running with Lustre versions 2.1/2.5, all showing the same
dentry->d_hash->next corrupted pointer cause.
This patch fixes a regression that has been introduced since a
long time by commit :
(LU-506 kernel: FC15 - support dcache scalability changes.)
where i_lock protection usage has been removed and
that is likely to cause racy condition during dentry [un]hashing
and to be the root cause of these crashes.
Signed-off-by: Bruno Faccini <bruno.faccini@intel.com>
Reviewed-on: http://review.whamcloud.com/19287
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7973
Reviewed-by: Lai Siyao <lai.siyao@intel.com>
Reviewed-by: Yang Sheng <yang.sheng@intel.com>
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
These are just doing spin_lock/unlock on inode's i_lock,
so just do the spinlock directly to make the code more clear
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In the FIFO cases of ll_atomic_open() and ll_lookup_nd() remove
spurious calls to ptlrpc_req_finished(). Explain that these cases are
unreachable in practice anyway.
Signed-off-by: John L. Hammond <john.hammond@intel.com>
Reviewed-on: http://review.whamcloud.com/17068
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7402
Reviewed-by: Dmitry Eremin <dmitry.eremin@intel.com>
Reviewed-by: Lai Siyao <lai.siyao@intel.com>
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Since the inflight request holds import refcount as well as export,
sometimes obd_disconnect() in client_common_put_super() can't put
the last refcount of OSC import (e.g. due to network disconnection),
this will cause cl_cache being accessed after free.
To fix this issue, ccc_users is used as cl_cache refcount, and
lov/llite/osc all hold one cl_cache refcount respectively, to avoid
the race that a new OST is being added into the system when the client
is mounted.
The following cl_cache functions are added:
- cl_cache_init(): allocate and initialize cl_cache
- cl_cache_incref(): increase cl_cache refcount
- cl_cache_decref(): decrease cl_cache refcount and free the cache
if refcount=0.
Signed-off-by: Emoly Liu <emoly.liu@intel.com>
Reviewed-on: http://review.whamcloud.com/13746
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6173
Reviewed-by: Niu Yawei <yawei.niu@intel.com>
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There are several obsolete sub commands for lfs to work with
remote client. We do not support that anymore, and should be
deleted along with any kernel code related to remote client.
Signed-off-by: Fan Yong <fan.yong@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6971
Reviewed-on: http://review.whamcloud.com/19789
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: James Simmons <uja.ornl@yahoo.com>
Reviewed-by: Lai Siyao <lai.siyao@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
Signed-off-by: James Simmons <jsimmons@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Return nth positive child after given or NULL if there's
less than n left. dcache_readdir() and dcache_dir_lseek()
switched to it.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Make sure that directory is locked shared in dcache_dir_lseek();
for dcache_readdir() it's already tru, and that's enough to make
simple_positive() stable.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
amdgpu_cgs_acpi_eval_object() returned the value of variable "result"
without initializing it first.
This bug has been found by compiling the kernel with clang. The
compiler complained:
drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c:972:14: error: variable
'result' is used uninitialized whenever 'for' loop exits because its
condition is false [-Werror,-Wsometimes-uninitialized]
for (i = 0; i < count; i++) {
^~~~~~~~~
drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c:1011:9: note: uninitialized
use occurs here
return result;
^~~~~~
drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c:972:14: note: remove the
condition if it is always true
for (i = 0; i < count; i++) {
^~~~~~~~~
drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c:864:12: note: initialize the
variable 'result' to silence this warning
int result;
^
= 0
Fixes: 3f1d35a03b ("drm/amdgpu: implement new cgs interface for acpi
function")
Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
Cc: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
! has higher precedence than bitwise & so we need to add parenthesis
for this to work as intended.
Fixes: 048765ad5a ('amdgpu: fix asic initialization for virtualized environments (v2)')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
... instead of the previous ORIGIN_GTT. This should actually
invalidate FBC once something is written on the frontbuffer using WC
mmaps. The problem with ORIGIN_GTT is that the automatic hardware
tracking is not able to detect the WC writes as it can detect the GTT
writes.
This should help fix the SKL bug where nothing happens when you type
your username/password on lightdm.
This patch was originally pasted on an email by Chris and converted to
an actual git patch by Paulo.
v2 (from Paulo):
- Make it a full variable instead of a bit-field (Daniel)
- Use WRITE_ONCE (Chris)
v3 (from Paulo):
- Remove huge comment since now we have WRITE_ONCE (Chris)
- Remove uneeded new line (Chris)
- Add Chris' Signed-off-by, authorized via IRC
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466185599-26401-1-git-send-email-paulo.r.zanoni@intel.com
The DDX driver changes its behavior depending on the value it reads
from i915.enable_fbc, so sanitize the value in order to allow it to
know what's going on. It uses this in order to choose the defaults for
the TearFree option. Before this patch, it would read -1 and always
assume that FBC was disabled, so it wouldn't force TearFree.
v2: Extract intel_sanitize_fbc_option() (Chris).
v3: Rebase.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1460574069-14005-1-git-send-email-paulo.r.zanoni@intel.com
We ignore ORIGIN_GTT because the hardware tracking can recognize GTT
writes and take care of them. We also ignore ORIGIN_FLIP because we
deal with flips without relying on the frontbuffer tracking
infrastructure. On the other hand, a flush is a flush and means we're
good to go, so we need to update busy_bits in order to reflect that,
even if we're not going to do anything else about it.
How to reproduce the bug fixed by this patch:
- boot SKL up to the desktop environment
- stop the display manager
- run any of the igt/kms_frontbuffer_tracking/*fbc*onoff* subtests
- the tests will fail
The steps above will create the right conditions for us to lose track
of busy_bits. If you, for example, run the full set of FBC tests, the
onoff subtests will succeed.
Also notice that the "bug" is that we'll just keep FBC disabled on
cases where it could be enabled, so it's not something the users can
perceive, it just affects power consumption numbers on properly
configured machines.
Testcase: igt/kms_frontbuffer_tracking/*fbc*onoff* (see above)
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459804638-3588-2-git-send-email-paulo.r.zanoni@intel.com
>From https://bugs.freedesktop.org/show_bug.cgi?id=96461 :
This was kind of a difficult bug to track down. If you're using a
Haswell system running GNOME and you have fbc completely enabled and
working, playing videos can result in video artifacts. Steps to
reproduce:
- Run GNOME
- Ensure FBC is enabled and active
- Download a movie, I used the ogg version of Big Buck Bunny for this
- Run `gst-launch-1.0 filesrc location='some_movie.ogg' ! decodebin !
glimagesink` in a terminal
- Watch for about over a minute, you'll see small horizontal lines go
down the screen.
For the time being, disable FBC for Haswell by default.
Stefan Richter reported kernel freezes (no video artifacts) when fbc
is on. (E3-1245 v3 with HD P4600; openbox and some KDE and LXDE
applications, thread begins at https://lkml.org/lkml/2016/4/26/813).
We also got reports from Steven Honeyman on openbox+roxterm.
v2 (From Paulo):
- Add extra information to the commit message
- Add Fixes tag
- Rebase
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96461
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96464
Fixes: a98ee79317 ("drm/i915/fbc: enable FBC by default on HSW and BDW")
Cc: stable@vger.kernel.org
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Lyude <cpaul@redhat.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1465487895-7401-1-git-send-email-cpaul@redhat.com
The use of config_enabled() against config options is ambiguous.
Now, IS_ENABLED() is implemented purely with macro expansion, so
let's replace config_enabled() with IS_ENABLED().
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Michal Marek <mmarek@suse.com>
The typical usage of IS_ENABLED() is
if (IS_ENABLED(CONFIG_FOO)) {
...
}
or
#if IS_ENABLED(CONFIG_FOO)
...
#endif
The current implementation of IS_ENABLED() includes "||" operator,
which works well in those expressions like above.
However, there is a case where we want to evaluate a config option
beyond those use cases.
For example, the OF_TABLE() in include/asm-generic/vmlinux.lds.h
needs to evaluate a config option in macro expansion:
#define ___OF_TABLE(cfg, name) _OF_TABLE_##cfg(name)
#define __OF_TABLE(cfg, name) ___OF_TABLE(cfg, name)
#define OF_TABLE(cfg, name) __OF_TABLE(config_enabled(cfg), name)
#define _OF_TABLE_0(name)
#define _OF_TABLE_1(name) \
...
Here, we can not use IS_ENABLED() because of the "||" operator in
its define. It is true config_enabled() works well, but it is a bit
ambiguous to be used against config options.
This commit makes IS_ENABLED() available in more generic context by
calculating "or" with macro expansion only.
Do likewise for IS_REACHABLE().
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Michal Marek <mmarek@suse.com>
For the same reason as commit 02d699f1f4 ("include/linux/kconfig.h:
ese macros which are already defined"), it is better to use macros
IS_BUILTIN() and IS_MODULE() for defining IS_REACHABLE().
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Michal Marek <mmarek@suse.com>
Here the need is for a macro that checks whether the given symbol is
defined or not, which has nothing to do with config.
The new macro __is_defined() is a better fit for this case.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Michal Marek <mmarek@suse.com>
The macro MODULE is not a config option, it is a per-file build
option. So, config_enabled(MODULE) is not sensible. (There is
another case in include/linux/export.h, where config_enabled() is
used against a non-config option.)
This commit renames some macros in include/linux/kconfig.h for the
use for non-config macros and replaces config_enabled(MODULE) with
__is_defined(MODULE).
I am keeping config_enabled() because it is still referenced from
some places, but I expect it would be deprecated in the future.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Michal Marek <mmarek@suse.com>
Documentation/coccinelle.txt suggests using the SPFLAGS
make variable to pass additional options to spatch.
Reorder the way SPFLAGS is added to FLAGS, to allow
for options in the SPFLAGS to override the default
--very-quiet option.
Similarly, rearrage the FLAGS for org or report mode.
This allows for overriding of the default --no-show-diff
option through SPFLAGS.
Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
Cc: Gilles Muller <Gilles.Muller@lip6.fr>
Acked-by: Nicolas Palix <nicolas.palix@imag.fr>
Acked-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Michal Marek <mmarek@suse.com>
Again this is neatly protected by the dev->master_mutex now. There is
a driver callback both for set and drop, but it's only used by vmwgfx.
And vmwgfx has it's own solid locking for shared resources (besides
dev->master_mutex), hence is all safe. Let's drop another place where
the drm legacy bkl is used.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466148814-8194-6-git-send-email-daniel.vetter@ffwll.ch
All protected by dev->master_mutex. And there's no driver callbacks,
which means no need to sync with old dri1 horror show drivers at all.
Hence safe to drop the drm legacy BKL from these paths.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466148814-8194-5-git-send-email-daniel.vetter@ffwll.ch
Simplifies cleanup, and there's no reason drivers should ever care
about authmagic at all - it's all handled in the core.
And with that, Ladies and Gentlemen, it's time to pop the champagen
and celebrate: dev->struct_mutex is now officially gone from modern
drivers, and if a driver is using gem_free_object_unlocked and doesn't
do anything else silly it's positively impossible to ever touch
dev->struct_mutex at runtime, anywhere.
Well except for the mutex_init on driver load ;-)
v2: Rebased.
Cc: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466148814-8194-4-git-send-email-daniel.vetter@ffwll.ch
It's related, and soon authmagic will also use the master_mutex.
There is an ever-so-slightly semantic change here:
- authmagic will only be cleaned up for primary_client drm_minors. But
it's impossible to create authmagic on render/control nodes, so this
is fine.
- The cleanup is moved down a bit in the release processing. Doesn't
matter at all since authmagic is purely internal logic used by the
core ioctl access checks, and when we're in a file's release
callback no one can do ioctls any more.
v2: Rebased.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466148814-8194-3-git-send-email-daniel.vetter@ffwll.ch
Another place gone where modern drivers could have hit
dev->struct_mutex.
To avoid too deeply nesting control flow rework it a bit.
v2: Review from Chris:
- remove spurious newline.
- fix file_priv->master like for the !file_priv->is_master case.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466148814-8194-2-git-send-email-daniel.vetter@ffwll.ch
