Re: Reduce KAUTH_GENERIC_ISSUSER usage (batch 1)
Hello, On Tue, 17 Jan 2012 20:36:35 -0500 Elad Efrat e...@netbsd.org wrote: Most of it is mechanically replacing the above action with something more meaningful, together with the necessary secmodel bits. To make reviewing easier, below there's a list of files. If you see a file you want to double-check on that list, see the diff. The files not on the list are the back-end ones (kauth.h, secmodel_suser.c). ... arch/macppc/dev/ofb.c This is obsolete and should probably go to the attic, no need to bother with. have fun Michael
Re: updated patch Re: buffer cache ufs changes (preliminary ffsv2 extattr support)
On Wed, Jan 18, 2012 at 10:21:13AM +1100, matthew green wrote: I am in agreement with Manuel. Without going into argument on BSD LFS design issues, current code is way too far from being anywhere stable and reliable. It should not block any progress in other subsystems. irregardless of what LFS is or isn't, breaking it on the branch is not acceptable. you might not use it or trust it, but there are people who do -- the people who maintain it -- and the same argument applies equally to their work as to any other work. It's not breaking it on the branch, it introducing a backward compat problem with the lfs modules, for those who are using the lfs module (it's statically built into the kernel by default). I didn't feel it's a problem, but if it is it can fixed in a simple way: I could add the extra parameter to UFS_BALLOC() now, but not use it. this is for a change that i'm not even convinced is a good thing, Because you don't need extended attributes ? let alone deserves to invade changing the buffer cache so close to a release. more generally on this issue: i don't think it matters if netbsd-6 and -current end up having non-trivially different implementations of this code. what matters most is that we (a) release netbsd-6 soon and (b) keep it stable. if non-trivial changes are necessary for ffsv2 extattr support to be part of netbsd-6 then i think that those changes have missed the boat. if those changes can be kept localised, but not entirely clean, then netbsd-6 can still have the feature without the potential for disrupting the release. OK, so I guess we're back to using a B_ALTDATA in b_flags for netbsd-6. It has more potential to break things, but doesn't break backward compatibility for modules and so doesn't need changes to the buffer cache now. -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Veriexec lock_state misuse
Hi, The current code confuses lock_state for something that it isn't. I discussed this a while ago with hannken@ and blymn@ and came up with the attached patch. We change the semantics to require locking and add a KASSERT to make sure they're followed. Missing locking bits are added in two places to comply. I'm not seeking feedback on this one as there's more Veriexec locking work pending. It's posted merely for the chance that someone might want this in netbsd-6. Elad veriexec_lock_state.diff Description: Binary data
Re: Reduce KAUTH_GENERIC_ISSUSER usage (batch 1)
On Tue, 17 Jan 2012 20:36:35 -0500 Elad Efrat e...@netbsd.org wrote: Attached is a diff that reduces the use of KAUTH_GENERIC_ISSUSER. I plan to commit it a week or so after the branch. Thanks for working on this. While I understand most changes, after looking at the diff I wondered: anyone know what is special about pxg(4) that requires a special MACHDEP_PXG check as opposed to MACHDEP_UNMANAGEDMEM? Thanks, -- Matt
Re: updated patch Re: buffer cache ufs changes (preliminary ffsv2 extattr support)
On Wed, Jan 18, 2012 at 04:24:27PM +0100, Manuel Bouyer wrote: On Wed, Jan 18, 2012 at 10:03:02AM +0100, Manuel Bouyer wrote: It's not breaking it on the branch, it introducing a backward compat problem with the lfs modules, for those who are using the lfs module (it's statically built into the kernel by default). I didn't feel it's a problem, but if it is it can fixed in a simple way: I could add the extra parameter to UFS_BALLOC() now, but not use it. I'd add that the compat problem is what you run a new ffs module with an older lfs one. That would mean one has to update only some modules to run into it. So, leaving aside the question of whether this kind of code to support a new feature should go in so soon before a release -- it seems to me that the compatibility problem here is basically illusory. To see it, you'd have to be running the branch, using LFS as a module (which is not the default configuration), then update to a newer snapshot of the branch, then update only some of your modules, right? So, who cares? Thor
Re: updated patch Re: buffer cache ufs changes (preliminary ffsv2 extattr support)
On Wed, Jan 18, 2012 at 02:27:30PM -0500, Thor Lancelot Simon wrote: On Wed, Jan 18, 2012 at 04:24:27PM +0100, Manuel Bouyer wrote: On Wed, Jan 18, 2012 at 10:03:02AM +0100, Manuel Bouyer wrote: It's not breaking it on the branch, it introducing a backward compat problem with the lfs modules, for those who are using the lfs module (it's statically built into the kernel by default). I didn't feel it's a problem, but if it is it can fixed in a simple way: I could add the extra parameter to UFS_BALLOC() now, but not use it. I'd add that the compat problem is what you run a new ffs module with an older lfs one. That would mean one has to update only some modules to run into it. So, leaving aside the question of whether this kind of code to support a new feature should go in so soon before a release -- it seems to me that the compatibility problem here is basically illusory. To see it, you'd have to be running the branch, using LFS as a module (which is not the default configuration), then update to a newer snapshot of the branch, then update only some of your modules, right? that's it for the changes in sys/ufs/ufs; the changes to struct buf affects much more modules. So, who cares? I don't, but others may have a different view. -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: kmem-pool-uvm
On 11/03/2011 02:02 AM, Mindaugas Rasiukevicius wrote:
Hello Lars,
Sorry for late reply.
Lars Heidieker l...@heidieker.de wrote:
i uploaded a new version of the kmem-pool-vmem-uvm patch:
ftp://ftp.netbsd.org/pub/NetBSD/misc/para/kmem-pool-vmem-uvm.patch
...
I've uploaded a new Version of the patch and a small patch that
replaces malloc with kmem in the ufs/ext2 (mainly) readdir code as
those allocation were (due to blocksize) 4k which made them just too
large with the malloc-header for the max 4k caches currently
implemented in the patch.
Thanks, I think the changes in essence are great and we should have
them for netbsd-6. Few comments:
- Having IPL_VM lock for kmem(9) can increase masking of interrupts and
given that we want to reduce allocations from the interrupt context,
it is not really desirable. However, there is a long way to go and at
this point I think it is not a problem, since kmem cache layer will
minimise the use of the lock.
- As already said, in the long term we want to minimise memory allocations
from the interrupt context. With kmem(9) becoming interrupt-safe, there
is a potential for abuse. I think that the general purpose kmem_alloc(9)
and kmem_free(9) routines should explicitly prohibit calls from interrupt
context by keeping the asserts on !cpu_intr_p() and !cpu_softintr_p().
For this purpose, there can be e.g. kmem_intr_alloc()/kmem_intr_free(),
so we would have strict interface level separation preventing for abuse.
It would also be easier to find such allocations from interrupt-context.
- I would leave uvm_km_alloc/free() interface naming as is and instead of
heap_va_arena would have something similar to old, e.g. kmem_va_arena.
Also, perhaps s/heap_meta_arena/kmem_va_meta_arena/.
- From bt_refillglobal:
+ if (vmem_alloc(heap_meta_arena, PAGE_SIZE,
+ (flags ~VM_FITMASK) | VM_INSTANTFIT | VM_POPULATING, va) != 0)
{
+ return ENOMEM;
+ }
Error path leaks vmem_btag_lock.
I've uploaded a new version of the kmem-pool-vmem-uvm patch:
ftp://ftp.netbsd.org/pub/NetBSD/misc/para/kmem-pool-vmem-uvm.patch
It incorporates some enhancements and makes the talked about interrupt
safe version private to malloc(9) and fixes the leakage of vmem_btag_lock.
Lars
--
Mystische Erklärungen:
Die mystischen Erklärungen gelten für tief;
die Wahrheit ist, dass sie noch nicht einmal oberflächlich sind.
-- Friedrich Nietzsche
[ Die Fröhliche Wissenschaft Buch 3, 126 ]
Re: buffer cache ufs changes (preliminary ffsv2 extattr support)
hi, On Mon, Jan 16, 2012 at 10:48:37PM +, YAMAMOTO Takashi wrote: hi, On Mon, Jan 16, 2012 at 10:00:05PM +, YAMAMOTO Takashi wrote: have you considered to separate the entity being cached from vnode? What would this buy us ? the data are intimely tied to the inode, cleaning the cache when a file is deleted or would be more difficult, isn't it ? it allows us to have more than one such entities for a vnode. it's what you want here, isn't it? I'm not sure I'm understanding you. There is only one set of extended attributes blocks per vnode. let's call the entity buf_targ_t. the most of vnode * for buffer cache API would be changed to take buf_targ_t * instead of vnode *. callers would be changed from bread(vp, ...) to bread(vp-v_contents_buf_targ, ...). you might want to do bread(ip-i_xattr_buf_targ, ...) for extended attribute. you need two buf_targ_t for a vnode. (v_contents_buf_targ and i_xattr_buf_targ in the above example.) YAMAMOTO Takashi -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: Areca SAS controllers (was: NetBSD on current AMD motherboards)
On Jun 10, 9:36am, =?iso-8859-1?Q?Edgar_Fu=DF?= wrote: } } Areca is one decent choice. } Thanks. But which Areca controllers are supported by NetBSD? } I can find lots of their PCI IDs in dev/pci/arcmsr.c, bu I fail to map } product names (e.g. ARC-1320-8i) to PCI IDs. I'm using: arcmsr0 at pci1 dev 0 function 0 arcmsr0: interrupting at ioapic1 pin 0, event channel 5 arcmsr0: Areca ARC-1680 Host Adapter RAID controller arcmsr0: 8 ports, 2048MB SDRAM, firmware V1.49 2010-12-02 004:00:0: Areca ARC-1680 (RAID mass storage) 004:00:0: 0x168017d3 (0x0104) (VendID = 17d3, ProdID = 1680) It works fine for accessing disks, but management and monitoring (i.e. bioctl) doesn't work. }-- End of excerpt from =?iso-8859-1?Q?Edgar_Fu=DF?=
