Project

General

Profile

Bug #14934

common/config_opts.h: audit OPT_INT/OPT_UINT and handle incorrect signed uint

Added by Joao Eduardo Luis about 8 years ago. Updated over 6 years ago.

Status:
Won't Fix
Priority:
Normal
Assignee:
-
Category:
common
Target version:
-
% Done:

0%

Source:
other
Tags:
low-hanging-fruit
Backport:
Regression:
No
Severity:
2 - major
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

The fix for #13829 uncovered something that concerns me deeply: all the options that are marked as 'OPT_INT' when they should be 'OPT_UINT' and the fact that we have no good way to avoid the user from specifying a negative uint via the interface.

While a negative uint is completely valid, bitwise, from the user's pov it doesn't make much sense to pass "-1' to something that should expect an unsigned int (say, 'num_client') and have the cluster say "Good news everybody! num_client has been set to 18446744073709551615'. Of course, this would not actually happen right now because 'num_client' is set as an 'OPT_INT' instead of unsigned -- imo, it should be a uint though --, but it begs the question: how many unguarded OPT_UINTs do we have out there that could easily, deeply suffer from this?

History

#1 Updated by Daniel Oliveira about 8 years ago

I can take a look into this Joao.

#3 Updated by Sage Weil over 6 years ago

  • Status changed from New to Won't Fix

This is obsolete with teh new options framework. What we probably want instead is an audit of min/max values.

Also available in: Atom PDF