>> Using the gcc flag option willl turn it off only for this case. > > and this will never work ;). consider that you compile your kernel with > constification enabled but some external module without it. now this external > module will believe that it has free reign over ops structures whereas the > kernel will happily enforce the read-only property on at least its own static > instances and may cause the external module to oops at runtime.
I don't want to turn off the plugin. I understand the reasons for its existence. Just gave a try to some undocumented gcc options. > now if some code needs writable ops structure variables it has 3 options under > the plugin approach: > > 1. add __no_const to the structure declaration > > 2. typedef a __no_const version of the constified structure type > > 3. use pax_open_kernel/pax_close_kernel to temporarily override > the (runtime enforced) constness of a given variable > > each approach has its own conditions to use, here's a quick summary: > > 1. when all instances of the given structure type are runtime allocated > (i.e., there're no static instances) > > 2. when some instances of the given structure type are statically allocated > it's best to let them be consitified by the plugin and use the typedef'd > __no_const type for dynamically allocated ones > > 3. when some constified statically allocated variables do need to be modified > at runtime > > if you look at PaX carefully, you'll find use cases for each of the above, > it should be your guidance for patching aufs as well. although i didn't look > at its code, i think aufs is case #1 or #2. > I agree with option 1: types should be declared const or no_const As enforcing this should lead to a more robust kernel. And this means there should not be any constify_plugin trick to infer if a type is const or not. The compiler should require attribute declaration. But this is just utopia.... The problem with option 2 is that this leaves the constification question unsolved. Beside that this forces developers to modify their code either to use "no_const" types or to write specific patches. Looking at code I don't understand why, for example, grsecurity patch provides a "no_const" struct for seq_operations (in include/linux/seq_file.h) and no special "typedef" for "struct fsnotify_ops"... However neither I nor Okajima are fsnotify mantainers, nor I can find any docs for how it should be used. Probably we should ask to Eric Paris <epa...@redhat.com> who wrote fsnotify infrastructure.... This means I cannot support option 1 and then the best is to bypass compiler constification, using Okajima trick... //br->br_hfsn_ops = au_hfsn_ops; BUILD_BUG_ON(sizeof(br->br_hfsn_ops) != sizeof(au_hfsn_ops)); memcoy((void *)&br->br_hfsn_ops, (void *)&au_hfsn_ops, sizeof(au_hfsn_ops)); instead of the more clear: br->br_hfsn_ops = au_hfsn_ops; Is this going to work? Aren't const struct enforced at runtime? ------------------------------------------------------------------------------ Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
