Hi, Daniel Thanks for the sponsoring. > This case was approved during today's PSARC meeting. > > Dan > > > > Dan Hain wrote: >> I am sponsoring this FastTrack for Philippe Jung. Requested binding >> is Patch, timeout 3/28/2008. >> >> - Dan >> >> >> Template Version: @(#)onepager.txt 1.31 07/08/08 SMI This information >> is Copyright 2007 Sun Microsystems >> 1. Introduction >> 1.1. Project/Component Working Name: new mdb stackinfo command >> >> 1.2. Name of Document Author/Supplier: >> Philippe Jung >> >> 1.3. Date of This Document: >> 02/29/2008 >> >> 1.4. Name of Major Document Customer(s)/Consumer(s): >> 1.4.1. The Community you expect to review your project: >> 1.4.2. The ARC(s) you expect to review your project: >> PSARC >> >> 1.5. Email Aliases: >> 1.5.2. Responsible Engineer: Philippe.Jung at sun.com >> 1.5.4. Interest List: >> Ken.Tomlinson at sun.com >> Renaud.Manus at sun.com >> William.Roche at sun.com >> Chris.Beal at sun.com >> >> 2. Project Summary >> 2.1. Project Description: >> >> Context: Some Solaris layered drivers (3rd parties) like EMC, >> Veritas >> requests a change of Solaris default kernel stack size. This project >> adds a new mdb command that helps to answer the following question: >> "How close has this Solaris system be from a kernel stack >> overflow ?". >> This project introduces a new mdb command (::stackinfo) and a new >> kernel >> tunable (kmem_stackinfo). At kernel thread creation time, the >> kernel thread stack is filled with >> a specific pattern (instead of zero filled) if the kmem_stackinfo >> variable >> is set to non zero value. During the kernel thread execution, the >> kernel >> thread stack pattern is progressively overwritten. >> This feature takes in account hardware architecture (stack grows >> either to >> lower or larger addresses). A simple count from stack top >> until pattern is >> not found (or stack botom is reached) gives a high water mark >> value, the >> maximum kernel stack space used by a kernel thread >> This allows to compute the maximum usage (a high water mark) of >> kernel stack >> usage. This new mdb command (::stackinfo) can also display the >> 'dead' kernel >> threads that have exercised their kernel stack the most (a DTRACE >> Statically >> Defined Tracing probe is also provided for this). >> Example: >> /etc/system: set kmem_stackinfo=0x1 >> > ::stackinfo >> THREAD STACK SIZE CUR MAX CMD/LWPID >> 000003000ec76a00 000002a10049a000 5ae0 3% 44% svc.startd/8 >> >> svc.startd/8 is currently at 3% of its kernel stack, but has already >> used up to 44% of its kernel stack. >> >> >> 2.2. Risks and Assumptions: >> >> None. >> 3. Business Summary >> 3.1. Problem Area: >> >> Helps answering Solaris developers/system admins the following >> question: >> "How close has this Solaris system be from a kernel stack >> overflow ?". >> >> 3.2. Market/Requester: >> >> Any Solaris kernel developer (layered drivers), any Solaris system >> administrator. >> >> 3.3. Business Justification: >> >> >> 3.4. Competitive Analysis: >> >> N/A. >> >> 3.5. Opportunity Window/Exposure: >> >> N/A. >> >> 3.6. How will you know when you are done?: >> >> The project is already available. Project and code review has been >> performed by following people: >> Ken.Tomlinson at sun.com Renaud.Manus at sun.com William.Roche at >> sun.com >> Chris.Beal at sun.com >> >> 4. Technical Description: >> 4.1. Details: >> >> file:///net/tb3.uk/tank/u/pjung/onnv_stack/web/stack.html >> /net/tb3.uk/tank/u/pjung/onnv_stack/DOCS/STACKINFO.sxw >> /net/tb3.uk/tank/u/pjung/onnv_stack/DOCS/STACKINFO.pdf >> 4.2. Bug/RFE Number(s): >> >> 6626918 A new (k)mdb command ::stackinfo, kernel thread stack usage >> >> 4.3. In Scope: >> >> N/A. >> >> 4.4. Out of Scope: >> >> N/A. >> >> 4.5. Interfaces: >> >> A new tunable in /etc/system, like slab allocator debug kmem_flags. >> >> set kmem_stackinfo = 0x1 >> >> A new (k)mdb command: >> > ::help stackinfo >> >> NAME >> stackinfo - display kthread_t stack usage >> SYNOPSIS >> [ addr ] ::stackinfo DESCRIPTION >> -a show also TS_FREE kthreads >> -h print history (dead kthreads) >> ATTRIBUTES >> Target: kvm >> Module: genunix >> Interface Stability: Unstable >> >> A new Dtrace probe: >> sdt:genunix:thread_log_stk_usage_free:stack-usage >> >> 4.6. Doc Impact: >> >> None. >> >> 4.7. Admin/Config Impact: >> >> None. >> >> 4.8. HA Impact: >> >> None. >> >> 4.9. I18N/L10N Impact: >> >> None. >> >> 4.10. Packaging & Delivery: >> >> None (no new package or existing package modification). >> >> 4.11. Security Impact: >> >> None. >> >> 4.12. Dependencies: >> >> None. >> >> 5. Reference Documents: >> >> file:///net/tb3.uk/tank/u/pjung/onnv_stack/web/stack.html >> >> 6. Resources and Schedule: >> 6.1. Projected Availability: >> >> 2 weeks >> >> 6.2. Cost of Effort: >> >> development: 2 man/week (done) >> QE: >> QA: >> >> 6.4. Product Approval Committee requested information: >> 6.4.1. Consolidation or Component Name: >> 6.4.7. Target RTI Date/Release: >> 6.4.8. Target Code Design Review Date: >> >> 6.5. ARC review type: >> // Standard >> // SelfReview >> 6.6. ARC Exposure: open >> 6.6.1. Rationale: Part of OpenSolaris >> >> 7. Prototype Availability: >> 7.1. Prototype Availability: >> >> file:///net/tb3.uk/tank/u/pjung/onnv_stack/webrev/index.html >> /net/tb3.uk/tank/u/pjung/onnv_stack/DOCS/STACKINFO.sxw >> /net/tb3.uk/tank/u/pjung/onnv_stack/DOCS/STACKINFO.pdf >> 7.2. Prototype Cost: >> >> None (Prototype done). >> > >
-- Philippe JUNG Sun microsystems GEG http://gec.sun.com/ 180, Avenue de l'Europe mailto:philippe.jung at sun.com ZIRST de Montbonnot tel: +33 4 76 18 80 58 38334 Saint Ismier Cedex
