Project

General

Profile

Actions

Bug #15034

open

port_close acts strangely on count > 1

Added by Patrick Mooney 2 months ago. Updated 21 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
kernel
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
vop_close
Gerrit CR:
External Bug:

Description

The VOP_CLOSE handler for event ports (port_close) differs from nearly all other VFS providers in that it performs some clean-up tasks when count > 1. Most other VFS providers defer clean-up until count == 1, which indicates the final close of the resource. While there are some cases such as a close() after dup() or fork() where event ports must do processing (clean-up of registrations, etc), the logic as a whole should be scrutinized.

This came about as a part of #15031, where closef() calls added in #14788 were found to be interfering with expected event ports operation. The clean-up on count > 1 does break with certain standing expectations in VFS.


Related issues

Related to illumos gate - Bug #15031: event ports impacted by FDINFO accessesClosedPatrick Mooney

Actions
Related to illumos gate - Bug #14788: FDINFO misbehaves in multiple waysClosedDan McDonald

Actions
Actions #1

Updated by Patrick Mooney 2 months ago

  • Related to Bug #15031: event ports impacted by FDINFO accesses added
Actions #2

Updated by Patrick Mooney 2 months ago

  • Related to Bug #14788: FDINFO misbehaves in multiple ways added
Actions #3

Updated by Gordon Ross 21 days ago

  • Tags set to vop_close
Actions

Also available in: Atom PDF