Let the mdsmap schema know about the new field 'max_xattr_size'. This prevents
the following error:
tasks.mgr.dashboard.helper._ValError: \
In `input['fs_map']['filesystems'][0]['mdsmap']`: unknown keys: {'max_xattr_size'}
URL: https://tracker.ceph.com/issues/55725
Signed-off-by: Luís Henriques <lhenriques@suse.de>
When doing a sync setxattr (MDS_OP_SETXATTR) to set the first xattr in an
inode it is possible for the client to set a huge xattr key/value that would
exceed the limit. Prevent this from from happening by checking the size
against the maximum allowed size.
URL: https://tracker.ceph.com/issues/55725
Signed-off-by: Luís Henriques <lhenriques@suse.de>
Commit eb915d0eec ("cephfs: fix write_buf's _len overflow problem") added
a limit to the total size of xattrs. This limit is respected by clients
doing a "sync" operation, i.e. MDS_OP_SETXATTR. However, clients with
CAP_XATTR_EXCL can still buffer these operations and ignore these limits.
This patch prevents clients from crashing the MDSs by also imposing the
xattr limits even when they have the Xx caps. Replaces the per-MDS knob
"max_xattr_pairs_size" by the new mdsmap setting that the clients can
access.
Unfortunately, clients that misbehave, i.e. old clients that don't respect
this xattrs limit and buffer their xattrs, will see them vanishing.
URL: https://tracker.ceph.com/issues/55725
Signed-off-by: Luís Henriques <lhenriques@suse.de>
This new configuration option will allow to define the maximum size for a
filesystem xattrs blob. This is a filesystem-wide knob that will replace
the per-MDS mds_max_xattr_pairs_size option.
Note:
The kernel client patch to handle this new configuration was merged before
the corresponding ceph-side pull-request. This was unfortunate because in
the meantime PR #43284 was merged and the encoding/decoding of
'bal_rank_mask' got in between. Hence the 'max_xattr_size' is being
encoding/decoded before 'bal_rank_mask'.
URL: https://tracker.ceph.com/issues/55725
Signed-off-by: Luís Henriques <lhenriques@suse.de>
* refs/pull/48720/head:
qa: fix api failure issue caused during a dashboard test
PendingReleaseNotes: noted new MDSMap field refuse_client_session
qa: added two testcases
client: do not initiate session if flag refuse_client_session is set
mds: do not reconnect when refuse_client_session is set
mds: add new feature to block clients from establishing sessions
Reviewed-by: Rishabh Dave <ridave@redhat.com>
Reviewed-by: Kotresh Hiremath Ravishankar <khiremat@redhat.com>
Reviewed-by: Patrick Donnelly <pdonnell@redhat.com>
Reviewed-by: Milind Changire <mchangir@redhat.com>
Reviewed-by: Ramana Raja <rraja@redhat.com>
Reviewed-by: Venky Shankar <vshankar@redhat.com>
rocksdb: Upgrade rocksdb to latest facebook's v7.9.2
Reviewed-by: Radoslaw Zarzynski <rzarzyns@redhat.com>
Reviewed-by: Mark Nelson <mnelson@redhat.com>
This feature is prompted by a desire to audit contents of
a cluster safely. Currently, such task is done by a privileged
account, which can damage the data by accident. In this
situation, using an account that can only read is an application
of the least privilege.
Note that the reader is a role in RBAC. So, an account can have
both a reader role and a normal user role. The latter allows it to
write the audit report into the cluster, if the operator wants that.
In OpenStack terms, this reader is known as "system reader persona".
Signed-off-by: Pete Zaitcev <zaitcev@redhat.com>
```
// Get an CacheItemHelper pointer for value type T and role R.
template <typename T, CacheEntryRole R>
Cache::CacheItemHelper* GetCacheItemHelperForRole() {
static Cache::CacheItemHelper cache_helper(
BlocklikeTraits<T>::SizeCallback, BlocklikeTraits<T>::SaveToCallback,
GetCacheEntryDeleterForRole<T, R>());
return &cache_helper;
}
```
Signed-off-by: Radoslaw Zarzynski <rzarzyns@redhat.com>
This suppression is needed since upgrading to v7.9.2.
See PR https://github.com/ceph/ceph/pull/49006.
Signed-off-by: Radoslaw Zarzynski <rzarzyns@redhat.com>
One of the tests in the orch suite is running distro install
commands from multiple distros, causing it to first install
container-tools 3.0 and then later install container-tools,
which fails, causing the test to fail. This is sort of a bandaid
fix to getthe test to work. It will cause whatever the last
version of the package to be installed to end up being installed
(and will do so without error) which is what we want in the tests.
Fixes: https://tracker.ceph.com/issues/57771
Signed-off-by: Adam King <adking@redhat.com>
only if use_repo_digest is not set.
The commit ac88200 introduced this possibility to skip pulling, but
doing this unconditionally broke a use case when one was able to have
a ceph image on a floating tag, and was able to upgrade to a new image
pushed to that tag. As using a floating tag is possible only when
use_repo_digest is enabled (the default), now skipping the pull
if use_repo_digest is disabled will not break it anymore.
Signed-off-by: Mykola Golub <mykola.golub@clyso.com>
/home/pdonnell/ceph/src/client/Client.cc:8575:13: warning: ‘void attr_set_atime_and_mtime(stat*, const utime_t&, const utime_t&)’ defined but not used [-Wunused-function]
8575 | static void attr_set_atime_and_mtime(struct stat *attr,
| ^~~~~~~~~~~~~~~~~~~~~~~~
Fixes: 8abccedd12
Signed-off-by: Patrick Donnelly <pdonnell@redhat.com>
Throwing away the NOP-looking-like `maybe_delay` concept became
possible after eradication of the `with_interruption` call nested
within `SnapTrimSubEvent`. Before, on Ubuntu and GCC 11.2.1, lack
of it was the reson behind assertion failures on resetting the
`thread_local` intteruption condition.
Signed-off-by: Radoslaw Zarzynski <rzarzyns@redhat.com>
`crimson::interruptible` does not support that. See the
`DISABLED_nested_interruptors` unit test.
Signed-off-by: Radoslaw Zarzynski <rzarzyns@redhat.com>
The rationale
=============
Calling `get()` on an unavailable future can result in yielding
the reactor, so -- from the interruptor's POV -- the interrupt
condition must be handled exactly like it is done for `yield()`.
Interruptor takes care about that but, at the moment, only for the
interruptible futures; there is mechanism for plain `seastar::future`.
This patch paves the way for handling them as well.
Signed-off-by: Radoslaw Zarzynski <rzarzyns@redhat.com>
