feat: track and handle O_CLOEXEC fds#2958
Conversation
|
Please double check driver/API_VERSION file. See versioning. /hold |
probably something stupid but I can't see it: |
a97d65a to
60b1afb
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #2958 +/- ##
==========================================
- Coverage 75.77% 75.73% -0.05%
==========================================
Files 299 299
Lines 33096 33164 +68
Branches 5148 5168 +20
==========================================
+ Hits 25080 25116 +36
- Misses 8016 8048 +32
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Perf diff from master - unit testsHeap diff from master - unit testsHeap diff from master - scap fileBenchmarks diff from master |
4e5ec73 to
4df7f4d
Compare
Signed-off-by: Grzegorz Nosek <grzegorz.nosek@sysdig.com>
Signed-off-by: Grzegorz Nosek <grzegorz.nosek@sysdig.com>
While the new fd may become O_CLOEXEC, the old one is not affected Signed-off-by: Grzegorz Nosek <grzegorz.nosek@sysdig.com>
Signed-off-by: Grzegorz Nosek <grzegorz.nosek@sysdig.com>
(also, do not add an fd for failed system calls) Signed-off-by: Grzegorz Nosek <grzegorz.nosek@sysdig.com>
Signed-off-by: Grzegorz Nosek <grzegorz.nosek@sysdig.com>
O_CLOEXEC file descriptors should be removed when processing a successful execve (execveat etc.), otherwise we end up with bloating the fd tables with bogus fds. Signed-off-by: Grzegorz Nosek <grzegorz.nosek@sysdig.com>
Signed-off-by: Grzegorz Nosek <grzegorz.nosek@sysdig.com>
|
LGTM label has been added. DetailsGit tree hash: 6fe7af60982543a927ac1adbbf785d59f967cd8a |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ekoops, gnosek, therealbobo The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
@irozzo-1A 's concern addressed. |
What type of PR is this?
/kind feature
Any specific area of the project related to this PR?
/area libsinsp
Does this PR require a change in the driver versions?
/version driver-SCHEMA-version-minor
What this PR does / why we need it:
Our O_CLOEXEC handling has always been spotty and in the end we did nothing with the flag (O_CLOEXEC fds survived execve just fine). This PR aims to fix that by:
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Probably best viewed commit by commit.
Does this PR introduce a user-facing change?: