aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/tools/perf/scripts/python/exported-sql-viewer.py
diff options
context:
space:
mode:
authorAlexander Aring <aahringo@redhat.com>2022-10-27 16:45:23 -0400
committerDavid Teigland <teigland@redhat.com>2022-11-08 12:59:41 -0600
commit3872f87b09e2f274ecf477895f9d1f9b9bdcf04b (patch)
treec5efa5696f783858819af4ef7a28ad84290a4498 /tools/perf/scripts/python/exported-sql-viewer.py
parentfs: dlm: allow different allocation context per _create_message (diff)
downloadwireguard-linux-3872f87b09e2f274ecf477895f9d1f9b9bdcf04b.tar.xz
wireguard-linux-3872f87b09e2f274ecf477895f9d1f9b9bdcf04b.zip
fs: dlm: remove ls_remove_wait waitqueue
This patch removes the ls_remove_wait waitqueue handling. The current handling tries to wait before a lookup is send out for a identically resource name which is going to be removed. Hereby the remove message should be send out before the new lookup message. The reason is that after a lookup request and response will actually use the specific remote rsb. A followed remove message would delete the rsb on the remote side but it's still being used. To reach a similar behaviour we simple send the remove message out while the rsb lookup lock is held and the rsb is removed from the toss list. Other find_rsb() calls would never have the change to get a rsb back to live while a remove message will be send out (without holding the lock). This behaviour requires a non-sleepable context which should be provided now and might be the reason why it was not implemented so in the first place. Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com>
Diffstat (limited to 'tools/perf/scripts/python/exported-sql-viewer.py')
0 files changed, 0 insertions, 0 deletions