| To: | "Frank Ch. Eigler" <fche@xxxxxxxxxx> |
|---|---|
| Subject: | Re: scsi indom in linux PMDA - issues! |
| From: | Ken McDonell <kenj@xxxxxxxxxxxxxxxx> |
| Date: | Thu, 22 Jan 2015 06:15:03 +1100 |
| Cc: | pcp@xxxxxxxxxxx |
| Delivered-to: | pcp@xxxxxxxxxxx |
| In-reply-to: | <20150121162140.GD19099@xxxxxxxxxx> |
| References: | <00d101d0350b$a9263430$fb729c90$@internode.on.net> <y0mtwzkdimv.fsf@xxxxxxxx> <54BF3607.5040301@xxxxxxxxxxxxxxxx> <20150121162140.GD19099@xxxxxxxxxx> |
| User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 |
On 22/01/15 03:21, Frank Ch. Eigler wrote: ... Sorry, to some extent I was conflating the __pmHash* stuff in pmdas/linux_proc, where the case is even more clear-cut. We use lookup tables of both sorts for much more than externally-visible API-dicated-persistentish number<->string mappings. They are used as a place to hang off (via the void* data/private fields) all kinds of extra stuff, like metric values fetched sometime in the past, whether they were requested or not (=> leading to inflated syscall traffic), regardless of whether a future pcp-fetcher will have access permissions or not (=> leading to security bugs). That's the problem I'm hoping to fix. *nod* ... these are examples of hijacking the pmdaCache API for purposes beyond the original intent and warranty obligations. Thanks for the clarification Frank, I think we're on the same page here. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | lustre pmda, Martins Innus |
|---|---|
| Next by Date: | pernode metrics still wrong on 1 CPU systems, Ken McDonell |
| Previous by Thread: | Re: scsi indom in linux PMDA - issues!, Frank Ch. Eigler |
| Next by Thread: | Re: [pcp] scsi indom in linux PMDA - issues!, Mark Goodwin |
| Indexes: | [Date] [Thread] [Top] [All Lists] |