Kyle Bader: > I've discovered a that if atomic counters are intentionally > overflowed in patchsets applied to my kernel that the PAX code > from the grsecurity hardening patch will trigger a refcount overflow > prevention mechanism. I plan on doing the rediff myself but > was hoping that you could point me to places in the aufs codebase where > you might have such counters so I can change them to > atomic_inc_unchecked variants.
Unfortunately I might not fully understand what you wrote. Do you mean all operations for atomic_t should be ..._unchecked version? If so, you can grep atomic from aufs source files. By the way, according to grsecurity.net/test/grsecurity-2.1.14-2.6.31.5-200910312135.patch, those _unchecked version has no difference from its base version. What are they for? Are there external check tool or something? About the overflow of atomic_t, you may want to do something for struct dentry.d_count, struct inode.i_count or struct kref.refcount before the counters in aufs. The first candidate among atomic_t in aufs is struct au_branch.br_count, I guess. The br_count is incremented when a file on that branch is opened, and decremented at closing. Other atomic_t will not overflow generally, or if it gets overflowed, it is harmless which represents the generation for instance. J. R. Okajima ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
