Libseccomp: RFE: अधिक सटीक रूप से परिभाषित त्रुटि वापसी मान

हाय @topimiettinen , क्षमा करें, इसे प्राप्त करने में इतना समय लगा है, लेकिन मुझे लगता है कि यह समय है कि हम इसे ठीक करें।

@drakenclimber यह एक डोज़ी होने जा रहा है। इस बिंदु पर सभी libseccomp API में मैनपेज होने चाहिए (यदि उन्हें इसके लिए हमें कोई समस्या बनाने की आवश्यकता नहीं है), सभी मैनपेज में रिटर्न वैल्यू सेक्शन में कुछ हाथ से लहराती "त्रुटि पर नकारात्मक मान" टिप्पणियां हैं। मुझे लगता है कि हमें निम्नलिखित करने की आवश्यकता है:

• संभावित रिटर्न वैल्यू की सूची बनाने के लिए प्रत्येक एपीआई कॉल को मैन्युअल रूप से ऑडिट करें
• तय करें कि क्या ये रिटर्न मान समझ में आते हैं, कोड को संशोधित करें यदि वे नहीं करते हैं
• त्रुटि कोड क्या इंगित करता है, इसकी संक्षिप्त व्याख्या के साथ संबद्ध मैनपेज में प्रत्येक संभावित वापसी मूल्य का दस्तावेजीकरण करें

विचार?

हाय @topimiettinen , क्षमा करें, इसे प्राप्त करने में इतना समय लगा है, लेकिन मुझे लगता है कि यह समय है कि हम इसे ठीक करें।

@drakenclimber यह एक डोज़ी होने जा रहा है। इस बिंदु पर सभी libseccomp API में मैनपेज होने चाहिए (यदि उन्हें इसके लिए हमें कोई समस्या बनाने की आवश्यकता नहीं है), सभी मैनपेज में रिटर्न वैल्यू सेक्शन में कुछ हाथ से लहराती "त्रुटि पर नकारात्मक मान" टिप्पणियां हैं। मुझे लगता है कि हमें निम्नलिखित करने की आवश्यकता है:

* manually audit each API call to generate a list of possible return values

* decide if these return values make sense, modify the code if they don't

* document each possible return value in the associated manpage with a brief explanation of what the error code indicates

विचार?

डांग .... आपने ऊपर जो कुछ भी लिखा है, मैं उससे सहमत हूं, विशेष रूप से आवश्यक प्रयास :)। रिटर्न कोड को सही तरीके से प्राप्त करना, और फिर उनका दस्तावेजीकरण करना वास्तव में एक बड़ा प्रयास होगा।

और हाँ, जबकि ग्लैमरस काम नहीं है, मुझे लगता है कि यह महत्वपूर्ण है। मैं कुछ सीग्रुप सामग्री पर काम कर रहा हूं और हमने हाल ही में एक कंटेनर कार्यान्वयन में भाग लिया जिसने पूरी तरह से एक सीग्रुप फीचर को गलत समझा ... वे कर सकते।

इस मुद्दे पर गतिविधि देखकर बहुत अच्छा लगा! मैं पूरी तरह से समीक्षा के खिलाफ नहीं हूं, लेकिन मूल अनुरोध केवल विभिन्न विफलता मोड को अलग करने में सक्षम होने के लिए सीमित था, जो कुछ हद तक ऑर्थोगोनल है। समीक्षा निश्चित रूप से मदद करेगी, यहां तक ​​​​कि मेरे विचार से एक हद तक पूर्वापेक्षाएँ भी।

इस मुद्दे पर गतिविधि देखकर बहुत अच्छा लगा! मैं पूरी तरह से समीक्षा के खिलाफ नहीं हूं, लेकिन मूल अनुरोध केवल विभिन्न विफलता मोड को अलग करने में सक्षम होने के लिए सीमित था, जो कुछ हद तक ऑर्थोगोनल है। समीक्षा निश्चित रूप से मदद करेगी, यहां तक ​​​​कि मेरे विचार से एक हद तक पूर्वापेक्षाएँ भी।

हमें किसी बिंदु पर समीक्षा करने की आवश्यकता है, और यह अभी भी हो सकता है। हम जितनी देर रुकेंगे, कॉल करने वालों के लिए त्रुटि कोड उतने ही कम उपयोगी होंगे और libseccomp का पूरा बिंदु इस सामान का उपयोग करना आसान बनाना है :)

डांग .... आपने ऊपर जो कुछ भी लिखा है, मैं उससे सहमत हूं, विशेष रूप से आवश्यक प्रयास :)। रिटर्न कोड को सही तरीके से प्राप्त करना, और फिर उनका दस्तावेजीकरण करना वास्तव में एक बड़ा प्रयास होगा।

हाँ, यह एक कारण है कि यह मुद्दा इतने लंबे समय से है, लेकिन मैं इसे काफी समय से बंद कर रहा हूं (कम से कम @drakenclimber कह सकता है कि वह इसे एक साल से भी कम समय से बंद कर रहा है!) बाद में आज (कल?) मैं इसे टुकड़ों/एकाधिक-मुद्दों (कुछ सुझावों के साथ) में तोड़ दूंगा ताकि टुकड़ों में निपटना थोड़ा आसान हो सके।

एक सकारात्मक के रूप में, ऐसा लगता है कि libseccomp वास्तव में केवल नौ अद्वितीय त्रुटि मानों का उपयोग करता है (एक बहुत ही कच्चे चेक के अनुसार):

# grep -e "-E[A-Z0-9]\+" src/*.{h,c} | sed 's/.*-\(E[A-Z0-9]\+\).*/\1/' | sort -u
EACCES
EDOM
EEXIST
EFAULT
EINVAL
ENOMEM
EOPNOTSUPP
EPERM
ESRCH

... इससे समस्या स्थान को थोड़ा कम करने में मदद मिलनी चाहिए, खासकर यदि हम पुस्तकालय में प्रत्येक त्रुटि कोड के लिए सामान्य अर्थपूर्ण मान से सहमत हो सकते हैं (जो हमें निश्चित रूप से करना चाहिए)।

यह इरादा से थोड़ी देर बाद है, लेकिन यहां libseccomp API बनाने वाले कार्यों की पूरी सूची है:

const struct scmp_version *seccomp_version(void)
unsigned int seccomp_api_get(void)
int seccomp_api_set(unsigned int level)
scmp_filter_ctx seccomp_init(uint32_t def_action)
int seccomp_reset(scmp_filter_ctx ctx, uint32_t def_action)
void seccomp_release(scmp_filter_ctx ctx)
int seccomp_merge(scmp_filter_ctx ctx_dst, scmp_filter_ctx ctx_src)
uint32_t seccomp_arch_resolve_name(const char *arch_name)
uint32_t seccomp_arch_native(void)
int seccomp_arch_exist(const scmp_filter_ctx ctx, uint32_t arch_token)
int seccomp_arch_add(scmp_filter_ctx ctx, uint32_t arch_token)
int seccomp_arch_remove(scmp_filter_ctx ctx, uint32_t arch_token)
int seccomp_load(const scmp_filter_ctx ctx)
int seccomp_attr_get(const scmp_filter_ctx ctx, enum scmp_filter_attr attr, uint32_t *value)
int seccomp_attr_set(scmp_filter_ctx ctx, enum scmp_filter_attr attr, uint32_t value)
char *seccomp_syscall_resolve_num_arch(uint32_t arch_token, int num)
int seccomp_syscall_resolve_name_arch(uint32_t arch_token, const char *name)
int seccomp_syscall_resolve_name_rewrite(uint32_t arch_token, const char *name)
int seccomp_syscall_resolve_name(const char *name)
int seccomp_syscall_priority(scmp_filter_ctx ctx, int syscall, uint8_t priority)
int seccomp_rule_add_array(scmp_filter_ctx ctx, uint32_t action, int syscall, unsigned int arg_cnt, const struct scmp_arg_cmp *arg_array)
int seccomp_rule_add(scmp_filter_ctx ctx, uint32_t action, int syscall, unsigned int arg_cnt, ...)
int seccomp_rule_add_exact_array(scmp_filter_ctx ctx, uint32_t action, int syscall, unsigned int arg_cnt, const struct scmp_arg_cmp *arg_array)
int seccomp_rule_add_exact(scmp_filter_ctx ctx, uint32_t action, int syscall, unsigned int arg_cnt, ...)
int seccomp_notify_alloc(struct seccomp_notif **req, struct seccomp_notif_resp **resp)
void seccomp_notify_free(struct seccomp_notif *req, struct seccomp_notif_resp *resp)
int seccomp_notify_receive(int fd, struct seccomp_notif *req)
int seccomp_notify_respond(int fd, struct seccomp_notif_resp *resp)
int seccomp_notify_id_valid(int fd, uint64_t id)
int seccomp_notify_fd(const scmp_filter_ctx ctx)
int seccomp_export_pfc(const scmp_filter_ctx ctx, int fd)
int seccomp_export_bpf(const scmp_filter_ctx ctx, int fd)

इन कार्यों में से, हमें केवल "int" लौटने वाले कार्यों के बारे में चिंता करने की आवश्यकता है।

फ़ंक्शंस के संभावित समूह जिनमें समान कोड पथ और वापसी मान होने चाहिए।

• समूह अ

int seccomp_arch_exist(const scmp_filter_ctx ctx, uint32_t arch_token)
int seccomp_arch_add(scmp_filter_ctx ctx, uint32_t arch_token)
int seccomp_arch_remove(scmp_filter_ctx ctx, uint32_t arch_token)

• ग्रुप बी

int seccomp_attr_get(const scmp_filter_ctx ctx, enum scmp_filter_attr attr, uint32_t *value)
int seccomp_attr_set(scmp_filter_ctx ctx, enum scmp_filter_attr attr, uint32_t value)

• समूह सी

int seccomp_syscall_resolve_name_arch(uint32_t arch_token, const char *name)
int seccomp_syscall_resolve_name_rewrite(uint32_t arch_token, const char *name)
int seccomp_syscall_resolve_name(const char *name)

• समूह डी

int seccomp_rule_add_array(scmp_filter_ctx ctx, uint32_t action, int syscall, unsigned int arg_cnt, const struct scmp_arg_cmp *arg_array)
int seccomp_rule_add(scmp_filter_ctx ctx, uint32_t action, int syscall, unsigned int arg_cnt, ...)
int seccomp_rule_add_exact_array(scmp_filter_ctx ctx, uint32_t action, int syscall, unsigned int arg_cnt, const struct scmp_arg_cmp *arg_array)
int seccomp_rule_add_exact(scmp_filter_ctx ctx, uint32_t action, int syscall, unsigned int arg_cnt, ...)

• समूह ई

int seccomp_notify_receive(int fd, struct seccomp_notif *req)
int seccomp_notify_respond(int fd, struct seccomp_notif_resp *resp)
int seccomp_notify_id_valid(int fd, uint64_t id)
int seccomp_notify_fd(const scmp_filter_ctx ctx)

• समूह एफ

int seccomp_load(const scmp_filter_ctx ctx)
int seccomp_export_bpf(const scmp_filter_ctx ctx, int fd)

... यदि फ़ंक्शन उपरोक्त समूहों में से किसी एक में नहीं है, तो यह संभवतः इसके कोड पथ और/या वापसी मान में अद्वितीय है।

समूह सी केवल __NR_SCMP_ERROR लौटाता है।

ग्रुप डी EINVAL, EPERM, EOPNOTSUPP, ENOMEM, EDOM, EFAULT, EEXIST में से किसी एक को वापस कर सकता है।

seccomp_load() EINVAL, ENOMEM, ESRCH और prctl() (केवल EACCES, EFAULT, EINVAL के लिए PR_SET_NO_NEW_PRIVS और PR_SET_SECCOMP) और seccomp() (EACCES, EFAULT, MEINVAL, ENOME) syscalls से उनके मैनुअल के अनुसार गलत मान लौटा सकता है। पन्ने।

जब libseccomp की बात आती है तो कॉलर को वापस syscall त्रुटियाँ, जैसे prctl() और seccomp(), मैं सोच रहा हूँ कि हमें केवल उन लोगों को एक त्रुटिपूर्ण मान (शायद ENOSYS?) के पीछे छिपाने की आवश्यकता है ताकि libseccomp इससे प्रभावित न हो कर्नेल में कोई भी परिवर्तन (या ABI अंतर)।

यदि यह डिबगिंग के लिए एक समस्या बन जाती है, तो शायद हम एक नया attr पेश कर सकते हैं जो गलत मान को सीधे कॉलर को वापस कर देगा।

संभवतः, लेकिन फिर यह सुनिश्चित करना अच्छा होगा कि कोई एबीआई/एपीआई टूटना नहीं है यदि libseccomp के उपयोगकर्ता पहले से ही कुछ गलत मूल्यों की अपेक्षा कर रहे हैं। मूल समस्या यह थी कि कुछ सिस्टम कॉल केवल कुछ आर्किटेक्चर पर मौजूद होते हैं (जैसे ugetrlimit केवल x86_32 पर) लेकिन इसे गलत टाइप किए गए सिस्टम कॉल नाम से अलग नहीं किया जा सकता है, इसलिए अलग (संभवतः सिंथेटिक) त्रुटि कोड की आवश्यकता होगी .

ठीक है, जैसा कि हमने पहले कहा है, वर्तमान में हम वास्तव में विशिष्ट त्रुटि मूल्यों की गारंटी नहीं देते हैं, केवल "विफलता पर नकारात्मक मूल्य" इसलिए जब उन उपयोगकर्ताओं को तोड़ना दुर्भाग्यपूर्ण होगा जो वर्तमान में विशिष्ट गलत मूल्यों के बारे में धारणा बना रहे हैं, मुझे लगता है कि चीजें बदल रही हैं भविष्य में कर्नेल संस्करणों और ABI में एक मजबूत गलत गारंटी प्रदान करना एक सार्थक व्यापार है।

ठीक है, जैसा कि हमने पहले कहा है, वर्तमान में हम वास्तव में विशिष्ट त्रुटि मूल्यों की गारंटी नहीं देते हैं, केवल "विफलता पर नकारात्मक मूल्य" इसलिए जब उन उपयोगकर्ताओं को तोड़ना दुर्भाग्यपूर्ण होगा जो वर्तमान में विशिष्ट गलत मूल्यों के बारे में धारणा बना रहे हैं, मुझे लगता है कि चीजें बदल रही हैं भविष्य में कर्नेल संस्करणों और ABI में एक मजबूत गलत गारंटी प्रदान करना एक सार्थक व्यापार है।

मैं सहमत हूं।

एक बार जब यह मूल्यांकन पूरा हो जाता है और हम विफलताओं पर गलत मूल्यों को अपडेट कर देते हैं, तो मुझे वापस किए गए गलत मूल्यों की किसी प्रकार की गारंटी देने में अधिक सहज महसूस होगा।

समूहीकरण का विचार शायद सबसे अच्छा नहीं था, तो चलिए इस सब पर नज़र रखने के लिए एक सूची शुरू करते हैं _ (जैसे-जैसे हम आगे बढ़ेंगे, मैं इसे अपडेट करता रहूंगा)_:

• [x] seccomp_reset
  वर्तमान में रिटर्न: EINVAL, ENOMEM।

• [x] seccomp_merge
  वर्तमान में रिटर्न: EINVAL, EDOM, EEXIST, ENOMEM।

• [x] seccomp_arch_exist
  वर्तमान में रिटर्न: EINVAL, EEXIST।

• [x] seccomp_arch_add
  वर्तमान में रिटर्न: EINVAL, EEXIST, ENOMEM, EDOM।

• [x] seccomp_arch_remove
  वर्तमान में रिटर्न: EINVAL, EEXIST।

• [x] seccomp_load
  वर्तमान में रिटर्न: EINVAL, ENOMEM, ESRCH, ECANCELED।

• [x] seccomp_attr_get
  वर्तमान में रिटर्न: EINVAL, EEXIST।

• [x] seccomp_attr_set
  वर्तमान में रिटर्न: EINVAL, EACCES, EOPNOTSUPP, EEXIST।

• [x] seccomp_syscall_resolve_name_arch
  पहले से ही अच्छी तरह से परिभाषित, विफलता पर syscall मान या __NR_SCMP_ERROR लौटाता है।

• [x] seccomp_syscall_resolve_name_rewrite
  पहले से ही अच्छी तरह से परिभाषित, विफलता पर syscall मान या __NR_SCMP_ERROR लौटाता है।

• [x] seccomp_syscall_resolve_name
  पहले से ही अच्छी तरह से परिभाषित, विफलता पर syscall मान या __NR_SCMP_ERROR लौटाता है।

• [x] seccomp_syscall_priority
  वर्तमान में रिटर्न: EINVAL, EDOM, EFAULT, ENOMEM।

• [x] seccomp_rule_add_array
  वर्तमान में रिटर्न: EINVAL, EOPNOTSUPP, ENOMEM, EDOM, EFAULT, EEXIST।

• [x] seccomp_rule_add
  वर्तमान में रिटर्न: EINVAL, EOPNOTSUPP, ENOMEM, EDOM, EFAULT, EEXIST।

• [x] seccomp_rule_add_exact_array
  वर्तमान में रिटर्न: EINVAL, EOPNOTSUPP, ENOMEM, EDOM, EFAULT, EEXIST।

• [x] seccomp_rule_add_exact
  वर्तमान में रिटर्न: EINVAL, EOPNOTSUPP, ENOMEM, EDOM, EFAULT, EEXIST।

• [x] seccomp_notify_alloc
  वर्तमान में रिटर्न: EOPNOTSUPP, ENOMEM, EFAULT, ECANCELED। मैनपेज पहले से ही त्रुटि पर -1 निर्दिष्ट करता है, जो संभवतः केवल seccomp() त्रुटि को संदर्भित करता है।

• [x] seccomp_notify_receive
  वर्तमान में रिटर्न: EOPNOTSUPP और ECANCELED। मैनपेज पहले से ही त्रुटि पर -1 निर्दिष्ट करता है, जो संभवतः केवल seccomp() त्रुटि को संदर्भित करता है।

• [x] seccomp_notify_response
  वर्तमान में रिटर्न: EOPNOTSUPP और ECANCELED। मैनपेज पहले से ही त्रुटि पर -1 निर्दिष्ट करता है, जो संभवतः केवल seccomp() त्रुटि को संदर्भित करता है।

• [x] seccomp_notify_id_valid
  वर्तमान में रिटर्न: EOPNOTSUPP और ECANCELED। मैनपेज पहले से ही -ENOENT ऑन एरर (अमान्य आईडी) निर्दिष्ट करता है, जो संभवत: केवल seccomp() इरनो को संदर्भित करता है।

• [x] seccomp_notify_fd
  पहले से ही अच्छी तरह से परिभाषित, अधिसूचना fd लौटाता है।

• [x] seccomp_export_pfc
  वर्तमान में रिटर्न: EINVAL और ECANCELED।

• [x] seccomp_export_bpf
  वर्तमान में रिटर्न: EINVAL, ENOMEM, और ECANCELED।

अब जबकि हमारे पास इस बात की एक सूची है कि कौन से फ़ंक्शन कौन से त्रुटि कोड लौटाते हैं, मैं इसके बारे में थोड़ा बेहतर महसूस कर रहा हूं, खासकर जब से हम अपने त्रुटि कोड का उपयोग करने के तरीके के साथ पहले से ही काफी संगत हैं। उस आखिरी बिट को काफी मदद करनी चाहिए।

मैं एक पीआर शुरू करने जा रहा हूं ताकि हम परिवर्तनों पर सुधार और प्रतिक्रिया एकत्र करना शुरू कर सकें, मैं इसे जल्द ही यहां पोस्ट करूंगा।

ENOSYS की बजाय "विशेष" प्रकृति को देखते हुए, मुझे हमारे कर्नेल/libc कैच-ऑल के रूप में त्रुटि का उपयोग करने के बारे में आरक्षण है। मुझे अन्य मूल्यों पर एक नज़र डालनी होगी, क्या किसी के पास इस पर कोई मजबूत भावना/विचार है?

अभी भी बहुत कुछ गायब है, ज्यादातर मैनपेज संपादन और कोड टिप्पणियां (परीक्षण का उल्लेख नहीं करने के लिए), लेकिन मैं जो सोच रहा हूं उसका एक विचार प्राप्त करने के लिए आप निम्न शाखा को देख सकते हैं:

• https://github.com/pcmoore/misc-libseccomp/tree/working-rc

ENOSYS की बजाय "विशेष" प्रकृति को देखते हुए, मुझे हमारे कर्नेल/libc कैच-ऑल के रूप में त्रुटि का उपयोग करने के बारे में आरक्षण है। मुझे अन्य मूल्यों पर एक नज़र डालनी होगी, क्या किसी के पास इस पर कोई मजबूत भावना/विचार है?

ईआईओ के बारे में क्या?

ईआईओ के बारे में क्या?

मुझे नहीं पता कि क्या इससे त्रुटि और अधिक कार्रवाई योग्य हो जाएगी। इसके बजाय एपीआई को ऐसे कार्यों के साथ विस्तारित करने के बारे में जो गलत मानों का उपयोग नहीं करते हैं, लेकिन उदाहरण के लिए:

• SCMP_ERROR_UNKNOWN_SYSCALL: syscall libseccomp द्वारा ज्ञात नहीं है: कॉलर उपयोगकर्ता इनपुट को अस्वीकार करने के लिए इसका उपयोग कर सकता है (उदाहरण के लिए syscall नाम में टाइपो)
• SCMP_ERROR_SYSCALL_NOT_FOR_THIS_ARCH: syscall libseccomp द्वारा जाना जाता है, लेकिन यहां उपलब्ध नहीं है: कॉलर केवल इस आर्किटेक्चर के लिए इस त्रुटि को अनदेखा कर सकता है
• SCMP_ERROR_API_USAGE: libseccomp कॉलिंग लॉजिक के साथ एक समस्या का पता लगाता है जो सही ढंग से लिखे गए कोड में नहीं होनी चाहिए: कॉलर जोर दे सकता है ()
• SCMP_ERROR_KERNEL_OTHER: libseccomp इनपुट और कॉल के अनुक्रम के साथ ठीक था, लेकिन कर्नेल ने कुछ अच्छी तरह से परिभाषित त्रुटियां जैसे ENOMEM, EPERM, ENOSYS: कॉलर को कार्रवाई के लिए त्रुटि की जांच करनी चाहिए। यदि कॉलर द्वारा की गई त्रुटि (जैसे EFAULT) के कारण libseccomp द्वारा त्रुटि का कारण जाना जाता है, तो शायद इसके बजाय SCMP_ERROR_API_USAGE का उपयोग किया जा सकता है।
• SCMP_ERROR_KERNEL_API_USAGE: libseccomp इनपुट आदि के साथ ठीक था, लेकिन कर्नेल को यह इतना स्पष्ट और स्पष्ट कारणों से पसंद नहीं आया। यह कर्नेल परिवर्तन, अक्षम कॉन्फ़िगरेशन, libseccomp या कॉलर में बग, बहुत अजीब उपयोगकर्ता इनपुट आदि का संकेत दे सकता है। कॉलर के लिए कार्रवाई ईवेंट को लॉग करना और डेवलपर्स (कॉलर और/या libseccomp) को जानकारी पास करने के अनुरोध के साथ त्रुटि हो सकती है। आगे का विश्लेषण, मुखर नहीं () सक्षम।

वैकल्पिक रूप से त्रुटि के साथ एपीआई यथावत रह सकता है, लेकिन उपरोक्त त्रुटि कोड का अनुरोध करने के लिए एक नए फ़ंक्शन का उपयोग किया जा सकता है।

शायद @poettering या @keszybz भी टिप्पणी कर सकते हैं।

मुझे नहीं पता कि क्या इससे त्रुटि और अधिक कार्रवाई योग्य हो जाएगी। इसके बजाय एपीआई को उन कार्यों के साथ विस्तारित करने के बारे में जो गलत मानों का उपयोग नहीं करते हैं ...

ठीक है, इससे पहले कि हम ऐसा कुछ करने पर विचार कर सकें (और मुझे यकीन नहीं है कि हम ऐसा करना चाहते हैं) हमें स्थिर और समर्थित रिटर्न कोड पर समझौता करने की आवश्यकता है। यही हम यहां काम कर रहे हैं और हम v2.5 के लिए क्या लक्ष्य कर रहे हैं।

आइए v2.5 में स्थिर/समर्थित रिटर्न कोड प्राप्त करें और हम देख सकते हैं कि यह कैसे जाता है, अगर हमें कुछ अतिरिक्त करने की आवश्यकता है तो हम इसे v2.6 के लिए मान सकते हैं।

ईआईओ के बारे में क्या?

मैंने अन्य कार्य प्राथमिकताओं और कुछ कर्नेल सामग्री के कारण इसे थोड़ी देर के लिए खींच लिया, लेकिन अब जब मैं libseccomp पर वापस आ गया हूं तो मुझे एहसास हो रहा है कि यहां ईआईओ का उपयोग करना गलत लगता है। मुझे इस पर थोड़ा और सोचने दो।

कैच-ऑल कर्नेल एरर कोड के रूप में ECANCELED के बारे में क्या?

मैं उत्सुक हूं कि आप क्या सोचते हैं @drakenclimber , आप इस पर थोड़ी देर के लिए चुप रहे हैं।

मैंने अन्य कार्य प्राथमिकताओं और कुछ कर्नेल सामग्री के कारण इसे थोड़ी देर के लिए खींच लिया, लेकिन अब जब मैं libseccomp पर वापस आ गया हूं तो मुझे एहसास हो रहा है कि यहां ईआईओ का उपयोग करना गलत लगता है। मुझे इस पर थोड़ा और सोचने दो।

मेरा भी यही विचार है। हाल ही में चीजें थोड़ी व्यस्त रही हैं: /।

मैं उत्सुक हूं कि आप क्या सोचते हैं @drakenclimber , आप इस पर थोड़ी देर के लिए चुप रहे हैं।

ज़रूर। मैं पूरे धागे को फिर से पढ़ना चाहता हूं, और फिर मैं इसमें शामिल हो जाऊंगा।

कैच-ऑल कर्नेल एरर कोड के रूप में ECANCELED के बारे में क्या?

मैं मानता हूँ कि मैं ECANCELED से अत्यधिक परिचित नहीं था। मैंने संक्षेप में इसके उपयोग के लिए कर्नेल स्रोत को देखा और एक Google खोज भी की। ECANCELED का पिछले libseccomp, prctl(), या हमारे द्वारा उपयोग किए गए अन्य API के साथ कोई टकराव नहीं है, और मुझे लगता है कि यह कर्नेल द्वारा हम पर जो भी त्रुटि फेंकता है, वह यथोचित रूप से इनकैप्सुलेट कर सकता है।

टीएल; डॉ - मैं कर्नेल त्रुटियों के लिए हमारे कैच-ऑल के रूप में ECANCELED के साथ अच्छा हूं।

बहुत बहुत शुक्रिया। मेरे पास एक आधा-बेक्ड पैचसेट है जिसे मैं समाप्त कर दूंगा और समीक्षा के लिए पीआर के रूप में जमा करूंगा।