Re: [PATCH] staging: lustre: delete the filesystem from the tree.
On Fri, Jun 01, 2018 at 02:30:49PM -0400, Andreas Dilger wrote: > On Jun 1, 2018, at 5:11 AM, Greg Kroah-Hartman > wrote: > > > > The Lustre filesystem has been in the kernel tree for over 5 years now. > > While it has been an endless source of enjoyment for new kernel > > developers learning how to do basic codingstyle cleanups, as well as an > > semi-entertaining source of bewilderment from the vfs developers any > > time they have looked into the codebase to try to figure out how to port > > their latest api changes to this filesystem, it has not really moved > > forward into the "this is in shape to get out of staging" despite many > > half-completed attempts. > > I am happy to submit a patch that moves Lustre out of staging and into > the mainline. I'm just about to board a flight, but it could be done > later today. Then we can avoid the constant churn of kernel newbies > submitting patches that break the code. It's not the kernel newbies that are your biggest problem. It's your development model, and lack of support from anyone to actually do real cleanups. Every few months, when I get really bored, I do a drive-by pass and have never yet failed to find numerous problems that you all have been totally ignoring. Look at the debugfs patch series I sent out this week. Look at all of the wonderful work that NeilBrown has been doing on core cleanups for your mess. Neither he nor I should be the ones that have to do this stuff, you all should be doing it yourself. You all have had over 5 years to work on cleaning up your crazy shim layers. It's still not done. And based on the recent patch series that was sent to me, I don't even see anyone planning on working on that type of thing. I'm sorry, but I am tired of it. If you want to submit this for the filesystem maintainers to accept, wonderful, please do so. But that will not consist of a patch that just moves the directories. You have to create a real set of patches and send them to linux-fsdevel, just like any other new filesystem does. And I would like to point out the fact that while this whole thing sat in staging, other filesystems and major driver subsystems entered staging, got cleaned up, and moved on out. It can be done. But for some reason you all don't want to do the real work to do it, which is fine, I understand that you need management buy-in to make that happen, and you all need to focus on your users and new features for them. So if you really do want this out of staging, go off and do the real work to do so and then merge it the "real" way. I'm tired of dealing with it in staging as-is and having to every few months start rejecting new feature patches and tell people that "this is the last time I'm going to tell you..." You all were warned many times, this is not my fault, but rather, yours, or your management for not allowing you to prioritize this work. > Lustre has been in use at large sites around the world for 18 years now. > Over 70% of the largest 100 systems in the world use Lustre. It runs at > universities, oil companies, weather bureaus around the world, etc. And yet, I bet none of them run the in-kernel codebase, right? I bet you could get all of this cleaned up and merge properly in 6 months if you really wanted to do so. But it seems that no one really wants to do that work, which is sad. I should not have to be the one to force you all, but it seems like I now have to be. > I know Andrew has long been a supporter of getting code into the kernel > that users are using. This is code that thousands of large computers > are using with exabytes of storage, a lot more than orangefs, exofs, and > random other filesystems that seem to get into the kernel easily. Because those developers took the time and did it right. Please, compare yourself to orangefs. That is the perfect example of how to do everything right. They got their code into staging, cleaned it up, talked to us about what was needed to do to get the remaining bits in proper shape, they assigned dedicated developers to do that work, talked with all of us at different conferences around the world to check up and constantly ensure that they were doing the right thing, and most importantly, they asked for feedback and acted on it. In the end, their codebase is much smaller, works better, is in the "real" part of the kernel, and available to every Linux user out there. So yes, you are no orangefs, but you really should aspire to be just like them, as they know how to do all of this correctly. > It's true the code is not as pretty as it could be, but the same is true > of code that has been in the kernel for ages. If you know of major subsystems that look at bad as lustre does with the numerous wrapper layers and other crazy things that you all do, please let me know and I will be glad to go point people at that code to help get it fixed up. Also note that the attempt to defend your behavior with "but he's doing the same thing over
Re: [PATCH] staging: lustre: delete the filesystem from the tree.
On Jun 1, 2018, at 5:11 AM, Greg Kroah-Hartman wrote: > > The Lustre filesystem has been in the kernel tree for over 5 years now. > While it has been an endless source of enjoyment for new kernel > developers learning how to do basic codingstyle cleanups, as well as an > semi-entertaining source of bewilderment from the vfs developers any > time they have looked into the codebase to try to figure out how to port > their latest api changes to this filesystem, it has not really moved > forward into the "this is in shape to get out of staging" despite many > half-completed attempts. I am happy to submit a patch that moves Lustre out of staging and into the mainline. I'm just about to board a flight, but it could be done later today. Then we can avoid the constant churn of kernel newbies submitting patches that break the code. Lustre has been in use at large sites around the world for 18 years now. Over 70% of the largest 100 systems in the world use Lustre. It runs at universities, oil companies, weather bureaus around the world, etc. I know Andrew has long been a supporter of getting code into the kernel that users are using. This is code that thousands of large computers are using with exabytes of storage, a lot more than orangefs, exofs, and random other filesystems that seem to get into the kernel easily. It's true the code is not as pretty as it could be, but the same is true of code that has been in the kernel for ages. We've spent years cleaning it up in staging, and it has gotten a lot better. Getting the client into the mainline kernel will accelerate the development and cleanup, and Christoph will no longer be able to submit patches that break the code because it is only in staging. This will also (finally) allow us to get this code in sync with the out-of-tree code and converge on a single tree. Cheers, Andreas > And getting code out of staging is the main goal of that portion of the > kernel tree. Code should not stagnate and it feels like having this > code in staging is only causing the development cycle of the filesystem > to take longer than it should. There is a whole separate out-of-tree > copy of this codebase where the developers work on it, and then random > changes are thrown over the wall at staging at some later point in time. > This dual-tree development model has never worked, and the state of this > codebase is proof of that. > > So, let's just delete the whole mess. Now the lustre developers can go > off and work in their out-of-tree codebase and not have to worry about > providing valid changelog entries and breaking their patches up into > logical pieces. They can take the time they have spend doing those > types of housekeeping chores and get the codebase into a much better > shape, and it can be submitted for inclusion into the real part of the > kernel tree when ready. > > Signed-off-by: Greg Kroah-Hartman > --- > MAINTAINERS |9 - > drivers/staging/Kconfig |2 - > drivers/staging/Makefile |1 - > drivers/staging/lustre/Kconfig|3 - > drivers/staging/lustre/Makefile |2 - > drivers/staging/lustre/README.txt | 83 - > drivers/staging/lustre/TODO | 302 -- > .../lustre/include/linux/libcfs/libcfs.h | 76 - > .../lustre/include/linux/libcfs/libcfs_cpu.h | 434 -- > .../include/linux/libcfs/libcfs_crypto.h | 208 - > .../include/linux/libcfs/libcfs_debug.h | 207 - > .../lustre/include/linux/libcfs/libcfs_fail.h | 194 - > .../lustre/include/linux/libcfs/libcfs_hash.h | 869 > .../include/linux/libcfs/libcfs_private.h | 200 - > .../include/linux/libcfs/libcfs_string.h | 102 - > .../staging/lustre/include/linux/lnet/api.h | 212 - > .../lustre/include/linux/lnet/lib-lnet.h | 652 --- > .../lustre/include/linux/lnet/lib-types.h | 666 --- > .../lustre/include/linux/lnet/socklnd.h | 87 - > .../include/uapi/linux/lnet/libcfs_debug.h| 149 - > .../include/uapi/linux/lnet/libcfs_ioctl.h| 141 - > .../lustre/include/uapi/linux/lnet/lnet-dlc.h | 150 - > .../include/uapi/linux/lnet/lnet-types.h | 669 --- > .../lustre/include/uapi/linux/lnet/lnetctl.h | 123 - > .../lustre/include/uapi/linux/lnet/lnetst.h | 556 --- > .../lustre/include/uapi/linux/lnet/nidstr.h | 119 - > .../lustre/include/uapi/linux/lnet/socklnd.h | 44 - > .../include/uapi/linux/lustre/lustre_cfg.h| 261 - > .../include/uapi/linux/lustre/lustre_fid.h| 293 -- > .../include/uapi/linux/lustre/lustre_fiemap.h | 72 - > .../include/uapi/linux/lustre/lustre_idl.h| 2690 --- > .../include/uapi/linux/lustre/lustre_ioctl.h | 229 - > .../uapi/linux/lustre/lustre_kernelcomm.h | 94 - > .../include/uapi/linux/lustre/lustre_ostid.h | 236 - > .../include/uapi/linux/lustre/lustre_param.h | 94 - > .../include/uapi/linux/lustre/lustre_user.h | 1327 --
Re: [lustre-devel] [PATCH] staging: lustre: delete the filesystem from the tree.
Would it makes sense to land LNet and LNDs on their own first? Get the networking house in order first before layering on the file system? Doug > On Jun 1, 2018, at 11:20 AM, Andreas Dilger wrote: > > On Jun 1, 2018, at 7:41 AM, Christoph Hellwig wrote: >> >> Thanks, >> >> all that churn without much visible progress to a mergeable codebase >> was really ennoying. >> >> I'd recommend if people want to merge lustre they start with a managable >> subset first, e.g. the fs client code with simple IP-only networking. > > Adding or removing the IB networking makes basically no difference to the > code size. This would also make the client much less useful, since a large > number of sites use Lustre with IB networks. > > Cheers, Andreas > > > > > > ___ > lustre-devel mailing list > lustre-de...@lists.lustre.org > http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [PATCH] staging: lustre: delete the filesystem from the tree.
On Jun 1, 2018, at 7:41 AM, Christoph Hellwig wrote: > > Thanks, > > all that churn without much visible progress to a mergeable codebase > was really ennoying. > > I'd recommend if people want to merge lustre they start with a managable > subset first, e.g. the fs client code with simple IP-only networking. Adding or removing the IB networking makes basically no difference to the code size. This would also make the client much less useful, since a large number of sites use Lustre with IB networks. Cheers, Andreas signature.asc Description: Message signed with OpenPGP ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [PATCH V3 2/5 selinux-next] selinux: Introduce selinux_ruleset struct
Hi Peter,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on pcmoore-selinux/next]
[also build test ERROR on v4.17-rc7]
[cannot apply to security/next next-20180531]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Peter-Enderborg/selinux-Make-allocation-atomic-in-policydb-objects-functions/20180601-205558
base: https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git next
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sh
All error/warnings (new ones prefixed by >>):
security/selinux/ss/policydb.c: In function 'policydb_flattened_alloc':
>> security/selinux/ss/policydb.c:3544:12: error: implicit declaration of
>> function 'vmalloc'; did you mean 'kvmalloc'?
>> [-Werror=implicit-function-declaration]
*tmpbuf = vmalloc(*size);
^~~
kvmalloc
>> security/selinux/ss/policydb.c:3544:10: warning: assignment makes pointer
>> from integer without a cast [-Wint-conversion]
*tmpbuf = vmalloc(*size);
^
In file included from include/linux/printk.h:7:0,
from include/linux/kernel.h:14,
from security/selinux/ss/policydb.c:33:
include/linux/kern_levels.h:5:18: warning: format '%ld' expects argument of
type 'long int', but argument 2 has type 'size_t {aka unsigned int}' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:11:18: note: in expansion of macro 'KERN_SOH'
#define KERN_ERR KERN_SOH "3" /* error conditions */
^~~~
security/selinux/ss/policydb.c:3548:10: note: in expansion of macro
'KERN_ERR'
printk(KERN_ERR "SELinux: vmalloc failed for %ld\n", *size);
^~~~
security/selinux/ss/policydb.c:3548:50: note: format string is defined here
printk(KERN_ERR "SELinux: vmalloc failed for %ld\n", *size);
~~^
%d
security/selinux/ss/policydb.c: In function 'policydb_flattened_free':
>> security/selinux/ss/policydb.c:3555:2: error: implicit declaration of
>> function 'vfree'; did you mean 'kvfree'?
>> [-Werror=implicit-function-declaration]
vfree(tmpbuf);
^
kvfree
cc1: some warnings being treated as errors
vim +3544 security/selinux/ss/policydb.c
3538
3539 int policydb_flattened_alloc(struct policydb *db, void **tmpbuf, size_t
*size)
3540 {
3541 int rc = 0;
3542
3543 *size = db->len;
> 3544 *tmpbuf = vmalloc(*size);
3545
3546 if (!*tmpbuf) {
3547 rc = -ENOMEM;
> 3548 printk(KERN_ERR "SELinux: vmalloc failed for %ld\n",
> *size);
3549 }
3550 return rc;
3551 }
3552
3553 int policydb_flattened_free(void *tmpbuf)
3554 {
> 3555 vfree(tmpbuf);
3556 return 0;
3557 }
3558
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [PATCH V3 2/5 selinux-next] selinux: Introduce selinux_ruleset struct
Hi Peter,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on pcmoore-selinux/next]
[also build test WARNING on v4.17-rc7]
[cannot apply to security/next next-20180531]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Peter-Enderborg/selinux-Make-allocation-atomic-in-policydb-objects-functions/20180601-205558
base: https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git next
config: i386-defconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
In file included from include/linux/printk.h:7:0,
from include/linux/kernel.h:14,
from security/selinux/ss/policydb.c:33:
security/selinux/ss/policydb.c: In function 'policydb_flattened_alloc':
>> include/linux/kern_levels.h:5:18: warning: format '%ld' expects argument of
>> type 'long int', but argument 2 has type 'size_t {aka unsigned int}'
>> [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:11:18: note: in expansion of macro 'KERN_SOH'
#define KERN_ERR KERN_SOH "3" /* error conditions */
^~~~
>> security/selinux/ss/policydb.c:3548:10: note: in expansion of macro
>> 'KERN_ERR'
printk(KERN_ERR "SELinux: vmalloc failed for %ld\n", *size);
^~~~
security/selinux/ss/policydb.c:3548:50: note: format string is defined here
printk(KERN_ERR "SELinux: vmalloc failed for %ld\n", *size);
~~^
%d
--
In file included from include/linux/printk.h:7:0,
from include/linux/kernel.h:14,
from security//selinux/ss/policydb.c:33:
security//selinux/ss/policydb.c: In function 'policydb_flattened_alloc':
>> include/linux/kern_levels.h:5:18: warning: format '%ld' expects argument of
>> type 'long int', but argument 2 has type 'size_t {aka unsigned int}'
>> [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:11:18: note: in expansion of macro 'KERN_SOH'
#define KERN_ERR KERN_SOH "3" /* error conditions */
^~~~
security//selinux/ss/policydb.c:3548:10: note: in expansion of macro
'KERN_ERR'
printk(KERN_ERR "SELinux: vmalloc failed for %ld\n", *size);
^~~~
security//selinux/ss/policydb.c:3548:50: note: format string is defined here
printk(KERN_ERR "SELinux: vmalloc failed for %ld\n", *size);
~~^
%d
vim +/KERN_ERR +3548 security/selinux/ss/policydb.c
3538
3539 int policydb_flattened_alloc(struct policydb *db, void **tmpbuf, size_t
*size)
3540 {
3541 int rc = 0;
3542
3543 *size = db->len;
3544 *tmpbuf = vmalloc(*size);
3545
3546 if (!*tmpbuf) {
3547 rc = -ENOMEM;
> 3548 printk(KERN_ERR "SELinux: vmalloc failed for %ld\n",
> *size);
3549 }
3550 return rc;
3551 }
3552
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
[PATCH] staging: lustre: delete the filesystem from the tree.
The Lustre filesystem has been in the kernel tree for over 5 years now. While it has been an endless source of enjoyment for new kernel developers learning how to do basic codingstyle cleanups, as well as an semi-entertaining source of bewilderment from the vfs developers any time they have looked into the codebase to try to figure out how to port their latest api changes to this filesystem, it has not really moved forward into the "this is in shape to get out of staging" despite many half-completed attempts. And getting code out of staging is the main goal of that portion of the kernel tree. Code should not stagnate and it feels like having this code in staging is only causing the development cycle of the filesystem to take longer than it should. There is a whole separate out-of-tree copy of this codebase where the developers work on it, and then random changes are thrown over the wall at staging at some later point in time. This dual-tree development model has never worked, and the state of this codebase is proof of that. So, let's just delete the whole mess. Now the lustre developers can go off and work in their out-of-tree codebase and not have to worry about providing valid changelog entries and breaking their patches up into logical pieces. They can take the time they have spend doing those types of housekeeping chores and get the codebase into a much better shape, and it can be submitted for inclusion into the real part of the kernel tree when ready. Signed-off-by: Greg Kroah-Hartman --- MAINTAINERS |9 - drivers/staging/Kconfig |2 - drivers/staging/Makefile |1 - drivers/staging/lustre/Kconfig|3 - drivers/staging/lustre/Makefile |2 - drivers/staging/lustre/README.txt | 83 - drivers/staging/lustre/TODO | 302 -- .../lustre/include/linux/libcfs/libcfs.h | 76 - .../lustre/include/linux/libcfs/libcfs_cpu.h | 434 -- .../include/linux/libcfs/libcfs_crypto.h | 208 - .../include/linux/libcfs/libcfs_debug.h | 207 - .../lustre/include/linux/libcfs/libcfs_fail.h | 194 - .../lustre/include/linux/libcfs/libcfs_hash.h | 869 .../include/linux/libcfs/libcfs_private.h | 200 - .../include/linux/libcfs/libcfs_string.h | 102 - .../staging/lustre/include/linux/lnet/api.h | 212 - .../lustre/include/linux/lnet/lib-lnet.h | 652 --- .../lustre/include/linux/lnet/lib-types.h | 666 --- .../lustre/include/linux/lnet/socklnd.h | 87 - .../include/uapi/linux/lnet/libcfs_debug.h| 149 - .../include/uapi/linux/lnet/libcfs_ioctl.h| 141 - .../lustre/include/uapi/linux/lnet/lnet-dlc.h | 150 - .../include/uapi/linux/lnet/lnet-types.h | 669 --- .../lustre/include/uapi/linux/lnet/lnetctl.h | 123 - .../lustre/include/uapi/linux/lnet/lnetst.h | 556 --- .../lustre/include/uapi/linux/lnet/nidstr.h | 119 - .../lustre/include/uapi/linux/lnet/socklnd.h | 44 - .../include/uapi/linux/lustre/lustre_cfg.h| 261 - .../include/uapi/linux/lustre/lustre_fid.h| 293 -- .../include/uapi/linux/lustre/lustre_fiemap.h | 72 - .../include/uapi/linux/lustre/lustre_idl.h| 2690 --- .../include/uapi/linux/lustre/lustre_ioctl.h | 229 - .../uapi/linux/lustre/lustre_kernelcomm.h | 94 - .../include/uapi/linux/lustre/lustre_ostid.h | 236 - .../include/uapi/linux/lustre/lustre_param.h | 94 - .../include/uapi/linux/lustre/lustre_user.h | 1327 -- .../include/uapi/linux/lustre/lustre_ver.h| 27 - drivers/staging/lustre/lnet/Kconfig | 46 - drivers/staging/lustre/lnet/Makefile |1 - drivers/staging/lustre/lnet/klnds/Makefile|1 - .../lustre/lnet/klnds/o2iblnd/Makefile|5 - .../lustre/lnet/klnds/o2iblnd/o2iblnd.c | 2958 .../lustre/lnet/klnds/o2iblnd/o2iblnd.h | 1048 .../lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c| 3763 --- .../lnet/klnds/o2iblnd/o2iblnd_modparams.c| 296 -- .../lustre/lnet/klnds/socklnd/Makefile|6 - .../lustre/lnet/klnds/socklnd/socklnd.c | 2921 .../lustre/lnet/klnds/socklnd/socklnd.h | 704 --- .../lustre/lnet/klnds/socklnd/socklnd_cb.c| 2586 -- .../lustre/lnet/klnds/socklnd/socklnd_lib.c | 534 --- .../lnet/klnds/socklnd/socklnd_modparams.c| 184 - .../lustre/lnet/klnds/socklnd/socklnd_proto.c | 810 drivers/staging/lustre/lnet/libcfs/Makefile | 16 - drivers/staging/lustre/lnet/libcfs/debug.c| 461 -- drivers/staging/lustre/lnet/libcfs/fail.c | 146 - drivers/staging/lustre/lnet/libcfs/hash.c | 2065 .../staging/lustre/lnet/libcfs/libcfs_cpu.c | 1086 - .../staging/lustre/lnet/libcfs/libcfs_lock.c | 155 - .../staging/lustre/lnet/libcfs/libcfs_mem.c | 171 - .../lustre/lnet/libcfs/libcfs_string.c| 562 ---
Re: [PATCH V3 0/5] selinux:Significant reduce of preempt_disable holds
On 05/31/2018 02:42 PM, Stephen Smalley wrote: > On 05/31/2018 05:04 AM, peter enderborg wrote: >> On 05/30/2018 10:34 PM, Stephen Smalley wrote: >>> On 05/30/2018 10:10 AM, Peter Enderborg wrote: The boolean change becomes a lot more heavy with this patch, but it is a very rare usage in compare with read only operations. The lock held during a policydb_copy is about 1ms on a XEON. >>> This has a very substantial performance impact on setsebool, e.g. time >>> setsebool httpd_can_sendmail=1. >>> That's because you are doing a full >>> vmalloc();policydb_write();policydb_read();vfree() sequence on it. >>> In comparison, KaiGai's old attempt to replace the policy rwlock with RCU >>> only duplicated the conditional policydb state (via a cond_policydb_dup) >>> that he introduced. Is there a reason you couldn't use that approach? >> That one did not make it, so I went for a other path. Make it simple, using >> the same serialisation that exist. That also make it easier to maintain. >> We do not use the booleans in android since they are not allowed so im not >> aware of any use case where this administrative function are >> used in such frequent manner that it would have an impact. And it must be >> some other large overhead with interprocess communication and >> a multiple writes to sysfs during a boolean settings? However my concern >> is/was memory pressure, setting booleans will generate pressure >> with lot of atomic allocation and large vmallocs. > Yes, that is also a concern. I would prefer to only duplicate the > conditional policydb state as in KaiGai's patch. > Keeping temporary setting of booleans lightweight is desirable for other use > cases than Android. > > I'm also concerned by the implications of switching all of the allocations to > atomic. KaiGai's patch did not take that approach either, and it obviously > could make policy reload more prone to transient failures. It maybe not needed atomic at the time. But the duplication holds a rcu_read_lock so it need to be atomic now. > > But my goal is the fast path for real time critical functions such as audio, > and it will be a cost for >> administrative tasks. On the xeon it takes about ~98 ms to run the >> security_set_bools compared to about ~8 ms without the overhead >> of copying the policydb. About ~6 ms is rcu sync and ~8 ms is the same as >> the original update of selinux statuses, and about ~25 ms >> is policydb_destroy() of the old copy. > > > ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [PATCH] staging: lustre: delete the filesystem from the tree.
Thanks, all that churn without much visible progress to a mergeable codebase was really ennoying. I'd recommend if people want to merge lustre they start with a managable subset first, e.g. the fs client code with simple IP-only networking. ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
[PATCH V2] selinux-testsuite: Add SCTP test support
The sctp testsuite tests all new sctp SELinux functionality. Signed-off-by: Richard Haines --- V2 Changes: Add -v option to test Add info in README.md regarding lksctp-tools-devel requirements Fix asconf parameter chunk processing in test Fix merge error for policy/Makefile Fix buffer overflow in sctp_asconf_params_client.c README.md | 4 +- policy/Makefile| 4 + policy/test_sctp.te| 159 + tests/Makefile | 4 + tests/sctp/Makefile| 13 + tests/sctp/calipso-flush | 5 + tests/sctp/calipso-load| 7 + tests/sctp/cipso-fl-flush | 5 + tests/sctp/cipso-fl-load | 7 + tests/sctp/cipso-flush | 5 + tests/sctp/cipso-load-t1 | 7 + tests/sctp/cipso-load-t2 | 7 + tests/sctp/cipso-load-t5 | 7 + tests/sctp/fb-deny-label-flush | 6 + tests/sctp/fb-deny-label-load | 7 + tests/sctp/fb-label-flush | 6 + tests/sctp/fb-label-load | 8 + tests/sctp/iptables-flush | 4 + tests/sctp/iptables-load | 27 + tests/sctp/sctp_asconf_params_client.c | 298 + tests/sctp/sctp_asconf_params_server.c | 236 +++ tests/sctp/sctp_bind.c | 81 +++ tests/sctp/sctp_bindx.c| 116 tests/sctp/sctp_client.c | 220 +++ tests/sctp/sctp_common.c | 101 +++ tests/sctp/sctp_common.h | 27 + tests/sctp/sctp_connectx.c | 124 tests/sctp/sctp_peeloff_server.c | 260 tests/sctp/sctp_server.c | 335 ++ tests/sctp/sctp_set_params.c | 205 +++ tests/sctp/sctp_set_peer_addr.c| 414 + tests/sctp/sctp_set_pri_addr.c | 135 tests/sctp/test| 814 + 33 files changed, 3657 insertions(+), 1 deletion(-) create mode 100644 policy/test_sctp.te create mode 100644 tests/sctp/Makefile create mode 100644 tests/sctp/calipso-flush create mode 100644 tests/sctp/calipso-load create mode 100644 tests/sctp/cipso-fl-flush create mode 100644 tests/sctp/cipso-fl-load create mode 100644 tests/sctp/cipso-flush create mode 100644 tests/sctp/cipso-load-t1 create mode 100644 tests/sctp/cipso-load-t2 create mode 100644 tests/sctp/cipso-load-t5 create mode 100644 tests/sctp/fb-deny-label-flush create mode 100644 tests/sctp/fb-deny-label-load create mode 100644 tests/sctp/fb-label-flush create mode 100644 tests/sctp/fb-label-load create mode 100644 tests/sctp/iptables-flush create mode 100644 tests/sctp/iptables-load create mode 100644 tests/sctp/sctp_asconf_params_client.c create mode 100644 tests/sctp/sctp_asconf_params_server.c create mode 100644 tests/sctp/sctp_bind.c create mode 100644 tests/sctp/sctp_bindx.c create mode 100644 tests/sctp/sctp_client.c create mode 100644 tests/sctp/sctp_common.c create mode 100644 tests/sctp/sctp_common.h create mode 100644 tests/sctp/sctp_connectx.c create mode 100644 tests/sctp/sctp_peeloff_server.c create mode 100644 tests/sctp/sctp_server.c create mode 100644 tests/sctp/sctp_set_params.c create mode 100644 tests/sctp/sctp_set_peer_addr.c create mode 100644 tests/sctp/sctp_set_pri_addr.c create mode 100755 tests/sctp/test diff --git a/README.md b/README.md index 60a249e..2c871d3 100644 --- a/README.md +++ b/README.md @@ -49,6 +49,7 @@ similar dependencies): * net-tools _(for `ifconfig`, used by `capable_net/test`)_ * netlabel\_tools _(to load NetLabel configuration during `inet_socket` tests)_ * iptables _(to load the `iptables SECMARK` rules during `inet_socket` tests)_ +* lksctp-tools-devel _(to build the SCTP test programs)_ On a modern Fedora system you can install these dependencies with the following command: @@ -61,7 +62,8 @@ following command: libselinux-devel \ net-tools \ netlabel_tools \ - iptables + iptables \ + lksctp-tools-devel The testsuite requires a pre-existing base policy configuration of SELinux, using either the old example policy or the reference policy as the baseline. diff --git a/policy/Makefile b/policy/Makefile index 15e3a0c..cc70d33 100644 --- a/policy/Makefile +++ b/policy/Makefile @@ -67,6 +67,10 @@ ifeq ($(shell grep -q binder $(POLDEV)/include/support/all_perms.spt && echo tru TARGETS += test_binder.te endif +ifeq ($(shell grep -q corenet_sctp_bind_all_nodes $(POLDEV)/include/kernel/corenetwork.if && echo true),true) +TARGETS += test_sctp.te +endif + ifeq (x$(DISTRO),$(filter x$(DISTRO),xRHEL4 xRHEL5 xRHEL6)) TARGETS:=$(filter-out test_overlayfs.te test_mqueue.te, $(TARGETS)) endif diff --git a/policy/test_sctp.te b/policy/test_sctp.te new file mode 100644 index 000..6d43208 --- /dev/null
