[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 2/2] tools/xenstore: set open file descriptor limit for xenstored

On 31.08.21 16:22, Ian Jackson wrote:
Andrew Cooper writes ("Re: [PATCH v3 2/2] tools/xenstore: set open file descriptor 
limit for xenstored"):
xenstored is TCB.  It needs a large number of FDs, and can be trusted
with unlimited.

I baseically agree with this.

Also, like xenconsoled, we can calculate an upper bound, which is
derived from the ABI limit of 32k domids.

IMO the default should support at leaat this much.

However, I don't think you are right, because xenstored offers console
connections to (possibly arbitrarily many) local socket connections.

All you're haggling over is the error semantics in the case of:
1) the upper bound calculation is wrong, or
2) there is an fd leak

Personally, I think a fixed calculation is right, so fd leaks can be
spotted more obviously.

An admin knob is not helpful - higher than the upper bound is just
wasteful, while lower will cause malfunctions.

I don't agree.  Firstly, on a technical level, your statement is true
only if the admin does not know they will be running a much smaller
number of domains.  Secondly, we have had several people saying they
want this to be configurable.  I think if several people say they want
something to be configurable, we should respect that, even if we think
the use cases for it are marginal.  If there are hazards in bad
settings of such a know, that can be dealt with in the docs.

Julien's point about not having the limit set by xenstored itself is
very well taken.

ISTM that the following scheme is in the intersection of everyone's

  * The limit will be adjusted/imposed in the startup script.
  * An /etc/{default,sysconfig} parameter will be provided to
    adjust the setting.
  * The default should be `unlimtied` since we cannot calculate
    a safe upper bound for all configurations.
  * Systems like Citrix Hypervisor (XenServer) which can calculate
    a safe upper bound can do so, and adjust the default, enabling
    them to spot fd leaks.

Makes sense for me.

So this would mean:
- the sysconfig parameter will no longer be "number of domains", but the
  fd limit of the Xenstore daemon
- default should be "unlimited"
- the comment should mention the current number of fds needed per domain
  (5 for HVM, 2 for PV/PVH) plus some headroom in dom0 (without any
  guest running on my test system 21 fds are active, so I guess a value
  of 50 seems appropriate)

Is this okay?


Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.