>> instead of the more clear:
>>
>> br->br_hfsn_ops = au_hfsn_ops;
>
> you can keep using the simple code if you use the proper types ;).
>
>> Is this going to work?
>
> you/someone will have to determine which of the 3 cases you have in aufs (for
> each affected type).
>
> here, if 'br' points to a dynamically allocated structure (think kmalloc) then
> it means that for this ops type you have case #1 or #2, so you'll either need
> __no_const on the original declaration or a new typedef'ed no_const type.
>
Having stripped something from PLD Linux
kernel-aufs2-no-const-grsec.patch, this is a patch for #2:
zrouter aufs # cat kernel-aufs3-no-const-grsec.patch
--- /usr/src/linux/include/linux/fsnotify_backend.h
+++ /usr/src/linux/include/linux/fsnotify_backend.h
@@ -105,6 +105,7 @@ struct fsnotify_ops {
void (*freeing_mark)(struct fsnotify_mark *mark, struct
fsnotify_group *group);
void (*free_event_priv)(struct fsnotify_event_private_data *priv);
};
+typedef struct fsnotify_ops __no_const fsnotify_ops_no_const;
/*
* A group is a "thing" that wants to receive notification about filesystem
--- fs/aufs/branch.h
+++ fs/aufs/branch.h
@@ -83,7 +83,7 @@ struct au_branch {
#ifdef CONFIG_AUFS_HFSNOTIFY
struct fsnotify_group *br_hfsn_group;
- struct fsnotify_ops br_hfsn_ops;
+ fsnotify_ops_no_const br_hfsn_ops;
#endif
#ifdef CONFIG_SYSFS
This should be integrated in Gentoo Hardened aufs3 ebuild, right?
If #1 could be confirmed then the patch would be in grsec, but looking
for fsnotify_ops use cases I have found only static const initializers
(inotify for instance).
Thanks for your explanation
------------------------------------------------------------------------------
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
