Re: pkg_delete recursive uninstall option
Luis Useche wrote: I implemented this option for the pkg_delete that remove all the 'non-used' dependencies of all packages you are deleting. It first check that the package is not a dependency of another installed package and it was not installed manually. I usually remove the diff between manually installed pkgs and all top-level pkgs, then repeat until there is no more diff. But this always seemed so ad-hoc. This feature Useche submitted would make my life slightly easier and keep my system cleaner while being less error prone.
Re: Add back-to-indentation (M-m) for mg
On Fri, Dec 24, 2010 at 03:28:49PM +0200, Henri Kemppainen wrote: > This adds the command that moves the dot to the first non-whitespace > character on the line. Thanks for this. Working great for me on 4.8-current/sparc64. Cheers, -Nima
add back tcp sysctls
As I mentioned previously, the auto recv space scaling algorithm isn't
optimized for all links. At list in my case, with the proverbial
satellite link (high bandwidth, high latency), the window never appears to
grow.
Manually setting the default recv space allows me to download at high
speed again. This diff brings back the two relevant sysctls.
Index: tcp_var.h
===
RCS file: /home/tedu/cvs/src/sys/netinet/tcp_var.h,v
retrieving revision 1.97
diff -u -r1.97 tcp_var.h
--- tcp_var.h 21 Oct 2010 11:38:27 - 1.97
+++ tcp_var.h 24 Dec 2010 23:08:33 -
@@ -481,8 +481,8 @@
{ "keepintvl", CTLTYPE_INT }, \
{ "slowhz", CTLTYPE_INT }, \
{ "baddynamic", CTLTYPE_STRUCT }, \
- { NULL, 0 }, \
- { NULL, 0 }, \
+ { "recvspace", CTLTYPE_INT }, \
+ { "sendspace", CTLTYPE_INT }, \
{ "ident", CTLTYPE_STRUCT }, \
{ "sack", CTLTYPE_INT }, \
{ "mssdflt",CTLTYPE_INT }, \
@@ -506,8 +506,8 @@
&tcp_keepintvl, \
NULL, \
NULL, \
- NULL, \
- NULL, \
+ &tcp_recvspace, \
+ &tcp_sendspace, \
NULL, \
NULL, \
&tcp_mssdflt, \
Re: Make sys/user.h safe for multiple includes
On Mon, Dec 20, 2010 at 4:06 PM, Christian Ludwig wrote: > I was playing around in the arch code of OpenBSD/i386 lately, and again > and again found that sys/user.h was not safe against multiple inclusions > from the same source file. Is that for a reason? One of my header files > needs to include sys/user.h, which creates a huge mess. You have a header that needs the full struct user definition and can't make do with a forward declaration of it? (Note that the struct user definition is the _only_ correct reason to #include ) This has been handled so far by simply including sys/user.h in each file that needs the header. For example, machine/freebsd_machdep.h would seem to need the struct user definition for its offsetof usage, but instead the one .c file that uses that header pulls it in. Philip Guenther
Re: compat_bsdos leftover
On Fri, Dec 24, 2010 at 12:45 PM, Mark Kettenis wrote: ... > Well, changing NLDT to 17 should defenitely be tested, but leaving it > at 17 is a bit odd. I'm actually wondering whether the default LDT is > necessary at all now that LBSDICALLS_SEL is gone. Then NLDT can go > completely. Yep, the default ldt should be able to go away completely and the ldt register explicitly set to zero except for processes that use the i386_set_ldt() sysarch call. I'm currently separated from my i386 test box, so I won't hazard a diff for this right now, but it deserves a blow torch to clean it out. Philip Guenther
Re: cleanup i386 pmap_fork()
On Fri, Dec 24, 2010 at 2:00 PM, Mark Kettenis wrote: >> Date: Fri, 24 Dec 2010 16:45:59 -0500 >> From: Ted Unangst >> >> On Fri, Dec 24, 2010 at 11:42 AM, Vladimir Kirillov wrote: >> > Hello t...@! >> > >> > I guess there's no need to acquire pmap locks when there's nothing >> > to do (USER_LDT unset). s/if defined/ifdef/ for consistency. >> >> PMAP_FORK and USER_LDT are only ever set together, and the >> simple_locks don't do anything anyway. I guess we could just delete >> the USERLDT checks if we wanted to clean it up. > > I don't think that would be a good idea. I agree with Mark. If something is going to be deleted, it should be those misleading simple_locks. Philip
Re: increase i386 data size
> Date: Fri, 24 Dec 2010 17:17:51 -0500
> From: Ted Unangst
>
> On Fri, Dec 24, 2010 at 5:14 PM, Ted Unangst wrote:
> > Anyone who stores the limit in a signed int (or long). Do I know of
> > any such software? No. Am I willing to risk the possibility of such
> > existing to squeeze out a few more bytes? No.
You mean, in the kernel? There the limits are stored in rlim_t, which
is a 64-bit type on all our architectures. There is one comparison in
uvm_mmap.c that had me worried for a bit:
if (size >
(p->p_rlimit[RLIMIT_DATA].rlim_cur - ptoa(p->p_vmspace->vm_dused))) {
but this is safe since ptoa() casts to paddr_t, which is unsigned long.
There is also 'struct orlimit' in , which is used for
BSD4.3 compat code in compat/common/kern_resource_43.c. But
RLIMIT_DATA isn't the only resource limit that can be set to 2GB or
beyond. So I'm happy to ignore that issue.
For userland, I have very little sympathy. If stuff doesn't run with
the limits cranked up all the way to 2GB, fix it, or crank the limit
down a tad bit.
> > I will happily set it to straight 2GB, or even higher if we don't care
> > about possible trouble, so long as everybody promises not to complain
> > if an issue is found. :)
>
> To phrase it another way, I was actually hoping that by avoiding the
> "what about overflow?" worries, we could move forward faster. If
> that's not a worry, great, I just didn't want to get tied down.
I don't think this is a worry. Wouldn't mind if somebody else takes a
look at this as well.
Re: increase i386 data size
On Fri, Dec 24, 2010 at 5:14 PM, Ted Unangst wrote: > Anyone who stores the limit in a signed int (or long). Do I know of > any such software? No. Am I willing to risk the possibility of such > existing to squeeze out a few more bytes? No. > > I will happily set it to straight 2GB, or even higher if we don't care > about possible trouble, so long as everybody promises not to complain > if an issue is found. :) To phrase it another way, I was actually hoping that by avoiding the "what about overflow?" worries, we could move forward faster. If that's not a worry, great, I just didn't want to get tied down.
Re: increase i386 data size
On Fri, Dec 24, 2010 at 5:02 PM, Mark Kettenis wrote: >> Date: Fri, 24 Dec 2010 16:54:23 -0500 (EST) >> From: Ted Unangst >> >> increase the hard limit on i386 max data size to 2GB-1. This will allow >> memory hungry processes to potentially use more RAM if you increase data >> limits appropriately. > > I really think that -1 is odd. Where would those potential overflows be? Anyone who stores the limit in a signed int (or long). Do I know of any such software? No. Am I willing to risk the possibility of such existing to squeeze out a few more bytes? No. I will happily set it to straight 2GB, or even higher if we don't care about possible trouble, so long as everybody promises not to complain if an issue is found. :)
Re: increase i386 data size
> Date: Fri, 24 Dec 2010 16:54:23 -0500 (EST) > From: Ted Unangst > > increase the hard limit on i386 max data size to 2GB-1. This will allow > memory hungry processes to potentially use more RAM if you increase data > limits appropriately. I really think that -1 is odd. Where would those potential overflows be? > Index: vmparam.h > === > RCS file: /home/tedu/cvs/src/sys/arch/i386/include/vmparam.h,v > retrieving revision 1.45 > diff -u -r1.45 vmparam.h > --- vmparam.h 15 Dec 2010 05:30:19 - 1.45 > +++ vmparam.h 24 Dec 2010 21:52:07 - > @@ -63,7 +63,7 @@ > #define DFLDSIZ (64*1024*1024) /* initial data size > limit */ > #endif > #ifndef MAXDSIZ > -#define MAXDSIZ (1024*1024*1024)/* max data size */ > +#define MAXDSIZ (2UL*1024*1024*1024-1) /* max data size. -1 to > avoid overflow */ > #endif > #ifndef BRKSIZ > #define BRKSIZ (1024*1024*1024)/* heap gap size */
Re: cleanup i386 pmap_fork()
> Date: Fri, 24 Dec 2010 16:45:59 -0500 > From: Ted Unangst > > On Fri, Dec 24, 2010 at 11:42 AM, Vladimir Kirillov > wrote: > > Hello t...@! > > > > I guess there's no need to acquire pmap locks when there's nothing > > to do (USER_LDT unset). s/if defined/ifdef/ for consistency. > > PMAP_FORK and USER_LDT are only ever set together, and the > simple_locks don't do anything anyway. I guess we could just delete > the USERLDT checks if we wanted to clean it up. I don't think that would be a good idea.
increase i386 data size
increase the hard limit on i386 max data size to 2GB-1. This will allow memory hungry processes to potentially use more RAM if you increase data limits appropriately. Index: vmparam.h === RCS file: /home/tedu/cvs/src/sys/arch/i386/include/vmparam.h,v retrieving revision 1.45 diff -u -r1.45 vmparam.h --- vmparam.h 15 Dec 2010 05:30:19 - 1.45 +++ vmparam.h 24 Dec 2010 21:52:07 - @@ -63,7 +63,7 @@ #defineDFLDSIZ (64*1024*1024) /* initial data size limit */ #endif #ifndef MAXDSIZ -#defineMAXDSIZ (1024*1024*1024)/* max data size */ +#defineMAXDSIZ (2UL*1024*1024*1024-1) /* max data size. -1 to avoid overflow */ #endif #ifndef BRKSIZ #defineBRKSIZ (1024*1024*1024)/* heap gap size */
Re: cleanup i386 pmap_fork()
On Fri, Dec 24, 2010 at 11:42 AM, Vladimir Kirillov wrote: > Hello t...@! > > I guess there's no need to acquire pmap locks when there's nothing > to do (USER_LDT unset). s/if defined/ifdef/ for consistency. PMAP_FORK and USER_LDT are only ever set together, and the simple_locks don't do anything anyway. I guess we could just delete the USERLDT checks if we wanted to clean it up.
Re: compat_bsdos leftover
On Fri, 24 Dec 2010, Mark Kettenis wrote:
> Well, changing NLDT to 17 should defenitely be tested, but leaving it
> at 17 is a bit odd. I'm actually wondering whether the default LDT is
> necessary at all now that LBSDICALLS_SEL is gone. Then NLDT can go
> completely.
>From a brief look, eliminating the default entirely just makes things more
complicated, but we can shrink it down to 1. I switched things over to
using malloc instead of uvm_km_alloc because there's no reason to allocate
full pages for tiny things.
This will need more testing, of course.
Index: i386/machdep.c
===
RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,v
retrieving revision 1.485
diff -u -r1.485 machdep.c
--- i386/machdep.c 2 Oct 2010 23:31:34 - 1.485
+++ i386/machdep.c 24 Dec 2010 21:35:04 -
@@ -2868,7 +2868,7 @@
union descriptor *cpu_ldt;
size_t len = sizeof(ldt);
- cpu_ldt = (union descriptor *)uvm_km_alloc(kernel_map, len);
+ cpu_ldt = malloc(len, M_DEVBUF, M_WAITOK);
bcopy(ldt, cpu_ldt, len);
ci->ci_ldt = cpu_ldt;
ci->ci_ldt_len = len;
Index: i386/pmap.c
===
RCS file: /cvs/src/sys/arch/i386/i386/pmap.c,v
retrieving revision 1.151
diff -u -r1.151 pmap.c
--- i386/pmap.c 30 Nov 2010 19:28:59 - 1.151
+++ i386/pmap.c 24 Dec 2010 21:35:06 -
@@ -1547,8 +1547,7 @@
* we're the last one to use it.
*/
ldt_free(pmap);
- uvm_km_free(kernel_map, (vaddr_t)pmap->pm_ldt,
- pmap->pm_ldt_len * sizeof(union descriptor));
+ free(pmap->pm_ldt, M_DEVBUF);
}
#endif
pool_put(&pmap_pmap_pool, pmap);
@@ -1586,11 +1585,7 @@
size_t len;
len = pmap1->pm_ldt_len * sizeof(union descriptor);
- new_ldt = (union descriptor *)uvm_km_alloc(kernel_map, len);
- if (new_ldt == NULL) {
- /* XXX needs to be able to fail properly */
- panic("pmap_fork: out of kva");
- }
+ new_ldt = malloc(len, M_DEVBUF, M_WAITOK);
bcopy(pmap1->pm_ldt, new_ldt, len);
pmap2->pm_ldt = new_ldt;
pmap2->pm_ldt_len = pmap1->pm_ldt_len;
@@ -1642,7 +1637,7 @@
simple_unlock(&pmap->pm_obj.vmobjlock);
if (old_ldt != NULL)
- uvm_km_free(kernel_map, (vaddr_t)old_ldt, len);
+ free(old_ldt, M_DEVBUF);
}
#endif /* USER_LDT */
Index: i386/sys_machdep.c
===
RCS file: /cvs/src/sys/arch/i386/i386/sys_machdep.c,v
retrieving revision 1.27
diff -u -r1.27 sys_machdep.c
--- i386/sys_machdep.c 20 Nov 2010 20:21:13 - 1.27
+++ i386/sys_machdep.c 24 Dec 2010 21:35:06 -
@@ -262,8 +262,7 @@
new_len = ldt_len * sizeof(union descriptor);
simple_unlock(&pmap->pm_lock);
- new_ldt = (union descriptor *)uvm_km_alloc(kernel_map,
- new_len);
+ new_ldt = malloc(new_len, M_DEVBUF, M_WAITOK);
if (new_ldt == NULL) {
error = ENOMEM;
goto out;
@@ -279,7 +278,7 @@
* hey.. not our problem if user applications
* have race conditions like that.
*/
- uvm_km_free(kernel_map, (vaddr_t)new_ldt, new_len);
+ free(new_ldt, M_DEVBUF);
goto copy;
}
@@ -296,7 +295,7 @@
memset((caddr_t)new_ldt + old_len, 0, new_len - old_len);
if (old_ldt != ldt)
- uvm_km_free(kernel_map, (vaddr_t)old_ldt, old_len);
+ free(old_ldt, M_DEVBUF);
pmap->pm_ldt = new_ldt;
pmap->pm_ldt_len = ldt_len;
Index: include/segments.h
===
RCS file: /cvs/src/sys/arch/i386/include/segments.h,v
retrieving revision 1.18
diff -u -r1.18 segments.h
--- include/segments.h 24 Dec 2010 20:26:30 - 1.18
+++ include/segments.h 24 Dec 2010 21:35:06 -
@@ -227,7 +227,8 @@
/*
* Entries in the Local Descriptor Table (LDT)
+ * (not normally used)
*/
-#defineNLDT17
+#defineNLDT1
#endif /* _I386_SEGMENTS_H_ */
Re: Allegations regarding OpenBSD IPSEC
Otto Moerbeek drijf.net> writes: > Huh, I quote: > > "So a subverted developer would probably need to work on the network stack. > I can think of a few obvious ways that they could leak plaintext or key > material:" > > and then Damien gives a few examples of how that could be accomplished. > > What you describe above is one of the ways Damien mentions (as I read > it): "If I was doing it, I'd try to make the reuse happen on something > like ICMP errors, so I could send error-inducing probe packets at > times I thought were interesting " > > Note the reuse of mbus will have the effect of sending key material to > the outside. > > Please elaborate in what respect you suggestion is different. > > -Otto Yeah, the words network stack and crafted packet are there, though the rest is significantly different. It's all network stack and the ICMP thing does focus on randomly probing for a potentially not-cleared buffer, ie intentional failures in the encryption. What I try to make clear: Don't focus on the encryption stuff, no need to break that, nor focus on the used buffers, etc. Just look what the STATE MACHINE in the IPSEC network stack (or if you want: What the state machine in the encryption setup) does, especially the handling of the error conditions. pretty easy to send a crafted packet and let the stack release the keys to the one asking. So: Don't look for "technical" bugs like failing memory clearing or potentially insufficient entropy. But look for a function feature in the error handling, technically perfect, though with an unwanted functionality. Such a construction would look pretty legit and would work very well with normal not-specifically crafted packets. This thread (and the message you refer to) is moving into the direction of encryption short-comings and I don't think that's where a backdoor has to be expected.
Re: compat_bsdos leftover
> Date: Fri, 24 Dec 2010 15:27:37 -0500 > From: Ted Unangst > > On Fri, Dec 24, 2010 at 12:10 PM, Vladimir Kirillov > wrote: > > Hi! > > I guess the following is the leftover. > > Thanks, I removed it. I left NLDT at 17, though, because there > doesn't appear to be much benefit in shrinking that vs whatever weird > binary compatibility issues there may be. Well, changing NLDT to 17 should defenitely be tested, but leaving it at 17 is a bit odd. I'm actually wondering whether the default LDT is necessary at all now that LBSDICALLS_SEL is gone. Then NLDT can go completely.
Re: compat_bsdos leftover
On Fri, Dec 24, 2010 at 12:10 PM, Vladimir Kirillov wrote: > Hi! > I guess the following is the leftover. Thanks, I removed it. I left NLDT at 17, though, because there doesn't appear to be much benefit in shrinking that vs whatever weird binary compatibility issues there may be. > > Index: include/segments.h > === > RCS file: /cvs/src/sys/arch/i386/include/segments.h,v > retrieving revision 1.17 > diff -u -p -r1.17 segments.h > --- include/segments.h 1 Jul 2010 17:30:27 - 1.17 > +++ include/segments.h 24 Dec 2010 17:09:07 - > @@ -228,7 +228,6 @@ void idt_vec_free(int); > /* > * Entries in the Local Descriptor Table (LDT) > */ > -#defineLBSDICALLS_SEL 16 /* BSDI system call gate */ > -#defineNLDT17 > +#defineNLDT16 > > #endif /* _I386_SEGMENTS_H_ */
Re: Allegations regarding OpenBSD IPSEC
On Fri, Dec 24, 2010 at 07:53:52PM +, martin tarb wrote: > Otto Moerbeek drijf.net> writes: > > Please also check what djm@ wrote in one of the first replies to Theo > > original mail: > > > > http://marc.info/?l=openbsd-tech&m=129237675106730&w=2 > > > > -Otto > > > Yep, I did see that one, though that one does focus on (intentional) bugs in > the > the main crypto stuff, and my suggestion is that's not the location where to > look for backdoors. Huh, I quote: "So a subverted developer would probably need to work on the network stack. I can think of a few obvious ways that they could leak plaintext or key material:" and then Damien gives a few examples of how that could be accomplished. > > To obvious, to complicated, to much coding required to realize something > usefull, etc. > > There is no need to "break" the crypto stuff, if you can convince the IPSec > stack to send you the keys. When you do have the keys, the only thing you have > to do is decode the recorded crypted stream. When you are the FBI, you > definately have access to intermediate nodes, there's no need to let one of > the > end-nodes generate the traffic to you. You only need the keys, just take care > the IPSec stack will tell you when you ask for it and only when you ask for it > with a crafted IPSec init packet. What you describe above is one of the ways Damien mentions (as I read it): "If I was doing it, I'd try to make the reuse happen on something like ICMP errors, so I could send error-inducing probe packets at times I thought were interesting " Note the reuse of mbus will have the effect of sending key material to the outside. Please elaborate in what respect you suggestion is different. -Otto
Re: Allegations regarding OpenBSD IPSEC
Otto Moerbeek drijf.net> writes: > Please also check what djm@ wrote in one of the first replies to Theo > original mail: > > http://marc.info/?l=openbsd-tech&m=129237675106730&w=2 > > -Otto Yep, I did see that one, though that one does focus on (intentional) bugs in the the main crypto stuff, and my suggestion is that's not the location where to look for backdoors. To obvious, to complicated, to much coding required to realize something usefull, etc. There is no need to "break" the crypto stuff, if you can convince the IPSec stack to send you the keys. When you do have the keys, the only thing you have to do is decode the recorded crypted stream. When you are the FBI, you definately have access to intermediate nodes, there's no need to let one of the end-nodes generate the traffic to you. You only need the keys, just take care the IPSec stack will tell you when you ask for it and only when you ask for it with a crafted IPSec init packet.
Re: Allegations regarding OpenBSD IPSEC
On Fri, Dec 24, 2010 at 07:27:02PM +, martin tarb wrote: > Theo de Raadt cvs.openbsd.org> writes: > > > > > > regarding the allegations about a backdoor beeing planted into OpenBSD, I > > > did a code review myself [...] > > > > By the way... > > > > It is unfortunate that it required an allegation of this sort for > > people to get to the point where they stop blindly trusting and > > instead go audit the code > > > > But looked at from the half-glass-full side, it is refreshing to see > > people trying! > > > > > Actually, when I would design such a backdoor, I wouldn't go for the item > getting highest attention and most difficult to crack. And because the crypto > stuff is getting most attention, it's highly likely it'll be replaced every > now > and then with something "better": Backdoor gone. > > I would do a "social engineering". Challenge the IPSec stack to tell me what I > want to know. > > How: > - Try to setup a connection with the server you want to have the keys from. > - Make a "failure" with this connection. > - This failure would use an additional parameter in the setup payload and > answer > with the info I want to have. > > So where to look: > In the state machine to initiate/setup the IPSec connection, especially the > error/declines it sends out. Things like: "setup failure, invalid key: > &(Yourkey+"additional parameter")". > > That'll be something very difficult to find in reviews (who does look at the > error notices, reviews are in general looking after the main functionality) > > Stack state machines tend to be related to the protocol basics and these don't > change, so it's very unlikely a backdoor like this is overruled by a "better" > implementation, especially if the original implementation is decent and > robust. > > This mechanism would need a handfull of connection setup attempts to get > everything you need to decompose a recorded stream. No intrusions will be > detected ever, unless logging is at debug level and who does wade through that > amount of logging ... > > In some situations, you might need to be able to spoof the originating IP, > though having access to the network infrastructure itself, will be enough. > > Easy, hardly any code required, very difficult to detect and very likely to > survive for a long period. Please also check what djm@ wrote in one of the first replies to Theo original mail: http://marc.info/?l=openbsd-tech&m=129237675106730&w=2 -Otto
Re: Allegations regarding OpenBSD IPSEC
Theo de Raadt cvs.openbsd.org> writes: > > > regarding the allegations about a backdoor beeing planted into OpenBSD, I > > did a code review myself [...] > > By the way... > > It is unfortunate that it required an allegation of this sort for > people to get to the point where they stop blindly trusting and > instead go audit the code > > But looked at from the half-glass-full side, it is refreshing to see > people trying! > > Actually, when I would design such a backdoor, I wouldn't go for the item getting highest attention and most difficult to crack. And because the crypto stuff is getting most attention, it's highly likely it'll be replaced every now and then with something "better": Backdoor gone. I would do a "social engineering". Challenge the IPSec stack to tell me what I want to know. How: - Try to setup a connection with the server you want to have the keys from. - Make a "failure" with this connection. - This failure would use an additional parameter in the setup payload and answer with the info I want to have. So where to look: In the state machine to initiate/setup the IPSec connection, especially the error/declines it sends out. Things like: "setup failure, invalid key: &(Yourkey+"additional parameter")". That'll be something very difficult to find in reviews (who does look at the error notices, reviews are in general looking after the main functionality) Stack state machines tend to be related to the protocol basics and these don't change, so it's very unlikely a backdoor like this is overruled by a "better" implementation, especially if the original implementation is decent and robust. This mechanism would need a handfull of connection setup attempts to get everything you need to decompose a recorded stream. No intrusions will be detected ever, unless logging is at debug level and who does wade through that amount of logging ... In some situations, you might need to be able to spoof the originating IP, though having access to the network infrastructure itself, will be enough. Easy, hardly any code required, very difficult to detect and very likely to survive for a long period.
compat_bsdos leftover
Hi! I guess the following is the leftover. Index: include/segments.h === RCS file: /cvs/src/sys/arch/i386/include/segments.h,v retrieving revision 1.17 diff -u -p -r1.17 segments.h --- include/segments.h 1 Jul 2010 17:30:27 - 1.17 +++ include/segments.h 24 Dec 2010 17:09:07 - @@ -228,7 +228,6 @@ void idt_vec_free(int); /* * Entries in the Local Descriptor Table (LDT) */ -#defineLBSDICALLS_SEL 16 /* BSDI system call gate */ -#defineNLDT17 +#defineNLDT16 #endif /* _I386_SEGMENTS_H_ */
Re: working hotplug for busy devices on mpii(4)
On Fri, Dec 24, 2010 at 04:01:19PM +1000, David Gwynne wrote:
> hi guys,
>
> this makes mpii properly detach devices, which helps a lot if they
> have commands in flight. to relevant changes are:
>
> - call the activate(DVACT_DEACTIVATE) function against all the luns
> on the target that is going away.
> - issue the target reset BEFORE detaching the children devices.
> this is needed now tha the midlayer will sleep until all outstanding
> commands on a device come back from the adapter before calling the
> child devices attach routine.
>
> i have tested this on straight disks, but not on raid volumes. i
> need someone to test disk removal behind a raid set before i can
> commit it.
>
> assuming testing goes well, can i get oks too?
>
> dlg
If testing goes well, ok k...@. Alas I don't have any to test.
Ken
>
> Index: mpii.c
> ===
> RCS file: /cvs/src/sys/dev/pci/mpii.c,v
> retrieving revision 1.35
> diff -u -p -r1.35 mpii.c
> --- mpii.c23 Aug 2010 00:53:36 - 1.35
> +++ mpii.c24 Dec 2010 05:46:34 -
> @@ -3417,6 +3417,8 @@ mpii_event_sas(struct mpii_softc *sc, st
> mpii_remove_dev(sc, dev);
> if (sc->sc_scsibus) {
> SET(dev->flags, MPII_DF_DETACH);
> + scsi_activate(sc->sc_scsibus, dev->slot, -1,
> + DVACT_DEACTIVATE);
> if (scsi_task(mpii_event_defer, sc,
> dev, 0) != 0)
> printf("%s: unable to run device "
> @@ -3529,27 +3531,19 @@ mpii_event_defer(void *xsc, void *arg)
> struct mpii_softc *sc = xsc;
> struct mpii_device *dev = arg;
>
> - /*
> - * SAS and IR events are delivered separately, so it won't hurt
> - * to wait for a second.
> - */
> - tsleep(sc, PRIBIO, "mpiipause", hz);
> -
> - if (!ISSET(dev->flags, MPII_DF_HIDDEN)) {
> - if (ISSET(dev->flags, MPII_DF_ATTACH))
> - scsi_probe_target(sc->sc_scsibus, dev->slot);
> - else if (ISSET(dev->flags, MPII_DF_DETACH))
> - scsi_detach_target(sc->sc_scsibus, dev->slot,
> - DETACH_FORCE);
> - }
> -
> if (ISSET(dev->flags, MPII_DF_DETACH)) {
> mpii_sas_remove_device(sc, dev->dev_handle);
> + if (!ISSET(dev->flags, MPII_DF_HIDDEN)) {
> + scsi_detach_target(sc->sc_scsibus, dev->slot,
> + DETACH_FORCE);
> + }
> free(dev, M_DEVBUF);
> - return;
> - }
>
> - CLR(dev->flags, MPII_DF_ATTACH);
> + } else if (ISSET(dev->flags, MPII_DF_ATTACH)) {
> + CLR(dev->flags, MPII_DF_ATTACH);
> + if (!ISSET(dev->flags, MPII_DF_HIDDEN))
> + scsi_probe_target(sc->sc_scsibus, dev->slot);
> + }
> }
>
> void
> @@ -4547,9 +4541,12 @@ mpii_scsi_cmd_done(struct mpii_ccb *ccb)
>
> case MPII_IOCSTATUS_BUSY:
> case MPII_IOCSTATUS_INSUFFICIENT_RESOURCES:
> + xs->error = XS_BUSY;
> + break;
> +
> case MPII_IOCSTATUS_SCSI_IOC_TERMINATED:
> case MPII_IOCSTATUS_SCSI_TASK_TERMINATED:
> - xs->error = XS_BUSY;
> + xs->error = XS_RESET;
> break;
>
> case MPII_IOCSTATUS_SCSI_INVALID_DEVHANDLE:
> @@ -4559,6 +4556,7 @@ mpii_scsi_cmd_done(struct mpii_ccb *ccb)
>
> default:
> xs->error = XS_DRIVER_STUFFUP;
> + break;
> }
>
> if (sie->scsi_state & MPII_SCSIIO_ERR_STATE_AUTOSENSE_VALID)
pkg_delete recursive uninstall option
Hi Guys,
I implemented this option for the pkg_delete that remove all the 'non-used'
dependencies of all packages you are deleting. It first check that the
package is not a dependency of another installed package and it was not
installed manually.
I sent an email about this a long time ago but I guess it didn't have too
much attention. At some point @espie ask me to hold it for some time and
re-submit later. This is the discussion:
http://marc.info/?l=openbsd-misc&m=124939917102094&w=2
I am copying this functionality from other package managers like apt or
pacman. They seem to work very well and I really miss it in OpenBSD.
I am sorry for my perl-fu.
Index: pkg_delete.1
===
RCS file: /cvs/src/usr.sbin/pkg_add/pkg_delete.1,v
retrieving revision 1.35
diff -u -r1.35 pkg_delete.1
--- pkg_delete.15 Jun 2010 07:11:43 - 1.35
+++ pkg_delete.124 Dec 2010 16:38:36 -
@@ -106,6 +106,9 @@
For signed packages, do not bother verifying signatures either.
If used twice,
it will not bother with checksums for configuration files either.
+.It Fl r
+Remove the package dependencies recursively except for those that are
required
+for other installed packages or were installed manually.
.It Fl s
Don't actually deinstall packages, report the disk size changes
that would happen.
cvs server: Diffing OpenBSD
Index: OpenBSD/PkgDelete.pm
===
RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PkgDelete.pm,v
retrieving revision 1.11
diff -u -r1.11 PkgDelete.pm
--- OpenBSD/PkgDelete.pm24 Dec 2010 09:04:14 - 1.11
+++ OpenBSD/PkgDelete.pm24 Dec 2010 16:38:36 -
@@ -27,8 +27,8 @@
sub handle_options
{
my $state = shift;
- $state->SUPER::handle_options('',
- '[-cIinqsvx] [-B pkg-destdir] [-D name[=value]] pkg-name
[...]');
+ $state->SUPER::handle_options('r',
+ '[-cIinqrsvx] [-B pkg-destdir] [-D name[=value]] pkg-name
[...]');
my $base = $state->opt('B') // $ENV{'PKG_DESTDIR'} // '';
if ($base ne '') {
@@ -108,6 +108,41 @@
$state->{bad}++;
}
}
+
+ if($state->opt('r')) {
+ # calculate dependencies to be removed:
+ # 1. Not installed manually
+ # 2. Not dependecy for other package
+
+ # bfs over the graph of packages
+ my %q = map {($_,1)} @toremove;
+ my %todoh;
+
+ while(%q) {
+ my $pkg = (keys %q)[0];
+ delete $q{$pkg};
+
+ # pkg to delete
+ $todoh{$pkg} = 1;
+
+ # expand to the dependencies of the current pkg
+ for my $dep (OpenBSD::Requiring->new($pkg)->list) {
+ my @dependents =
OpenBSD::RequiredBy->compute_closure($dep);
+
+ # if the dependent package will be removed,
then we shouldn't
+ # be worried about keeping its dependencies.
+ # calculate @dependen...@q-@todo.
+ @dependents = grep {not($q{$_} or $todoh{$_}
or ($_ eq $dep))} @dependents;
+
+ # check if $dep was manually installed
+ my $manual =
OpenBSD::PackingList->from_installation($dep)->has('manual-installation');
+
+ $q{$dep} = 1 unless (@dependents or
$manual);
+ }
+ }
+ @toremove = keys %todoh;
+ }
+
$state->{toremove} = \...@toremove;
}
Luis.
cleanup i386 pmap_fork()
Hello t...@!
I guess there's no need to acquire pmap locks when there's nothing
to do (USER_LDT unset). s/if defined/ifdef/ for consistency.
Index: pmap.c
===
RCS file: /cvs/src/sys/arch/i386/i386/pmap.c,v
retrieving revision 1.151
diff -u -p -r1.151 pmap.c
--- pmap.c 30 Nov 2010 19:28:59 - 1.151
+++ pmap.c 24 Dec 2010 16:40:47 -
@@ -1567,7 +1567,7 @@ pmap_reference(struct pmap *pmap)
simple_unlock(&pmap->pm_obj.vmobjlock);
}
-#if defined(PMAP_FORK)
+#ifdef PMAP_FORK
/*
* pmap_fork: perform any necessary data structure manipulation when
* a VM space is forked.
@@ -1576,10 +1576,10 @@ pmap_reference(struct pmap *pmap)
void
pmap_fork(struct pmap *pmap1, struct pmap *pmap2)
{
+#ifdef USER_LDT
simple_lock(&pmap1->pm_obj.vmobjlock);
simple_lock(&pmap2->pm_obj.vmobjlock);
-#ifdef USER_LDT
/* Copy the LDT, if necessary. */
if (pmap1->pm_flags & PMF_USER_LDT) {
union descriptor *new_ldt;
@@ -1597,10 +1597,10 @@ pmap_fork(struct pmap *pmap1, struct pma
pmap2->pm_flags |= PMF_USER_LDT;
ldt_alloc(pmap2, new_ldt, len);
}
-#endif /* USER_LDT */
simple_unlock(&pmap2->pm_obj.vmobjlock);
simple_unlock(&pmap1->pm_obj.vmobjlock);
+#endif /* USER_LDT */
}
#endif /* PMAP_FORK */
Re: upgrade and fsck
On Fri, Dec 24, 2010 at 10:05:28AM +0100, Otto Moerbeek wrote:
> Hi,
>
> It has been a long time since a saw an incosistent fs with the clean
> flag set. So default to no and rephrase a litle to make it clearer.
>
> -Otto
I like the question. ok krw@ for that. I also always type 'n' to
that question, but I go back and forth on changing the default.
Ken
>
> Index: install.sub
> ===
> RCS file: /cvs/src/distrib/miniroot/install.sub,v
> retrieving revision 1.631
> diff -u -p -r1.631 install.sub
> --- install.sub 22 Nov 2010 14:10:42 - 1.631
> +++ install.sub 24 Dec 2010 09:03:12 -
> @@ -1727,7 +1727,7 @@ getdevname() {
> check_fs() {
> local _dev _mp _fstype _rest _fail _f
>
> - ask_yn "Force checking of non-root filesystems?" yes
> + ask_yn "Force checking of clean non-root filesystems?"
> [[ $resp == y ]] && _f=f
>
> while read _dev _mp _fstype _rest; do
Re: timeout io on mpii(4)
This is great but the real question is why does the IO get jammed?
On Fri, Dec 24, 2010 at 04:09:23PM +1000, David Gwynne wrote:
> i can reliably produce a situation where an io on a disk attached
> to mpii(4) never completes. this implements timeouts on scsi io so
> we can recover from this situation.
>
> ok?
>
> Index: mpii.c
> ===
> RCS file: /cvs/src/sys/dev/pci/mpii.c,v
> retrieving revision 1.35
> diff -u -p -r1.35 mpii.c
> --- mpii.c23 Aug 2010 00:53:36 - 1.35
> +++ mpii.c24 Dec 2010 06:04:38 -
> @@ -1757,7 +1757,8 @@ struct mpii_ccb {
> volatile enum {
> MPII_CCB_FREE,
> MPII_CCB_READY,
> - MPII_CCB_QUEUED
> + MPII_CCB_QUEUED,
> + MPII_CCB_TIMEOUT
> } ccb_state;
>
> void(*ccb_done)(struct mpii_ccb *);
> @@ -1822,6 +1823,15 @@ struct mpii_softc {
> struct mpii_ccb_listsc_ccb_free;
> struct mutexsc_ccb_free_mtx;
>
> + struct mutexsc_ccb_mtx;
> + /*
> + * this protects the ccb state and list entry
> + * between mpii_scsi_cmd and scsidone.
> + */
> +
> + struct mpii_ccb_listsc_ccb_tmos;
> + struct scsi_iohandler sc_ccb_tmo_handler;
> +
> struct scsi_iopool sc_iopool;
>
> struct mpii_dmamem *sc_requests;
> @@ -1894,6 +1904,10 @@ intmpii_alloc_queues(struct mpii_softc
> void mpii_push_reply(struct mpii_softc *, struct mpii_rcb *);
> void mpii_push_replies(struct mpii_softc *);
>
> +void mpii_scsi_cmd_tmo(void *);
> +void mpii_scsi_cmd_tmo_handler(void *, void *);
> +void mpii_scsi_cmd_tmo_done(struct mpii_ccb *);
> +
> int mpii_alloc_dev(struct mpii_softc *);
> int mpii_insert_dev(struct mpii_softc *, struct mpii_device *);
> int mpii_remove_dev(struct mpii_softc *, struct mpii_device *);
> @@ -4035,7 +4049,11 @@ mpii_alloc_ccbs(struct mpii_softc *sc)
> int i;
>
> SLIST_INIT(&sc->sc_ccb_free);
> + SLIST_INIT(&sc->sc_ccb_tmos);
> mtx_init(&sc->sc_ccb_free_mtx, IPL_BIO);
> + mtx_init(&sc->sc_ccb_mtx, IPL_BIO);
> + scsi_ioh_set(&sc->sc_ccb_tmo_handler, &sc->sc_iopool,
> + mpii_scsi_cmd_tmo_handler, sc);
>
> sc->sc_ccbs = malloc(sizeof(*ccb) * (sc->sc_request_depth-1),
> M_DEVBUF, M_NOWAIT | M_ZERO);
> @@ -4448,6 +4466,7 @@ mpii_scsi_cmd(struct scsi_xfer *xs)
> DNPRINTF(MPII_D_CMD, "%s: Offset0: 0x%02x\n", DEVNAME(sc),
> io->sgl_offset0);
>
> + timeout_set(&xs->stimeout, mpii_scsi_cmd_tmo, ccb);
> if (xs->flags & SCSI_POLL) {
> if (mpii_poll(sc, ccb) != 0) {
> xs->error = XS_DRIVER_STUFFUP;
> @@ -4459,10 +4478,66 @@ mpii_scsi_cmd(struct scsi_xfer *xs)
> DNPRINTF(MPII_D_CMD, "%s:mpii_scsi_cmd(): opcode: %02x "
> "datalen: %d\n", DEVNAME(sc), xs->cmd->opcode, xs->datalen);
>
> + timeout_add_msec(&xs->stimeout, xs->timeout);
> mpii_start(sc, ccb);
> }
>
> void
> +mpii_scsi_cmd_tmo(void *xccb)
> +{
> + struct mpii_ccb *ccb = xccb;
> + struct mpii_softc *sc = ccb->ccb_sc;
> +
> + printf("%s: mpii_scsi_cmd_tmo\n", DEVNAME(sc));
> +
> + mtx_enter(&sc->sc_ccb_mtx);
> + if (ccb->ccb_state == MPII_CCB_QUEUED) {
> + ccb->ccb_state = MPII_CCB_TIMEOUT;
> + SLIST_INSERT_HEAD(&sc->sc_ccb_tmos, ccb, ccb_link);
> + }
> + mtx_leave(&sc->sc_ccb_mtx);
> +
> + scsi_ioh_add(&sc->sc_ccb_tmo_handler);
> +}
> +
> +void
> +mpii_scsi_cmd_tmo_handler(void *cookie, void *io)
> +{
> + struct mpii_softc *sc = cookie;
> + struct mpii_ccb *tccb = io;
> + struct mpii_ccb *ccb;
> + struct mpii_msg_scsi_task_request *stq;
> +
> + mtx_enter(&sc->sc_ccb_mtx);
> + ccb = SLIST_FIRST(&sc->sc_ccb_tmos);
> + if (ccb != NULL) {
> + SLIST_REMOVE_HEAD(&sc->sc_ccb_tmos, ccb_link);
> + ccb->ccb_state = MPII_CCB_QUEUED;
> + }
> + /* should remove any other ccbs for the same dev handle */
> + mtx_leave(&sc->sc_ccb_mtx);
> +
> + if (ccb == NULL) {
> + scsi_io_put(&sc->sc_iopool, tccb);
> + return;
> + }
> +
> + stq = tccb->ccb_cmd;
> + stq->function = MPII_FUNCTION_SCSI_TASK_MGMT;
> + stq->task_type = MPII_SCSI_TASK_TARGET_RESET;
> + stq->dev_handle = htole16(ccb->ccb_dev_handle);
> +
> + tccb->ccb_done = mpii_scsi_cmd_tmo_done;
> + mpii_start(sc, tccb);
> +}
> +
> +void
> +mpii_scsi_cmd_tmo_done(struct mpii_ccb *tccb)
> +{
> + mpii_scsi_cmd_tmo_handler(tccb->ccb_sc, tccb);
> +}
> +
> +void
> mpii_scsi_cmd_done(struct mpii_ccb
Add back-to-indentation (M-m) for mg
This adds the command that moves the dot to the first non-whitespace
character on the line.
Index: src/usr.bin/mg/def.h
===
RCS file: /cvs/src/usr.bin/mg/def.h,v
retrieving revision 1.113
diff -u -p -r1.113 def.h
--- src/usr.bin/mg/def.h30 Jun 2010 19:12:54 - 1.113
+++ src/usr.bin/mg/def.h22 Dec 2010 16:12:15 -
@@ -511,6 +511,7 @@ int indent(int, int);
int forwdel(int, int);
int backdel(int, int);
int space_to_tabstop(int, int);
+int gotoindent(int, int);
/* extend.c X */
int insert(int, int);
Index: src/usr.bin/mg/funmap.c
===
RCS file: /cvs/src/usr.bin/mg/funmap.c,v
retrieving revision 1.32
diff -u -p -r1.32 funmap.c
--- src/usr.bin/mg/funmap.c 15 Sep 2008 16:13:35 - 1.32
+++ src/usr.bin/mg/funmap.c 22 Dec 2010 16:12:15 -
@@ -191,6 +191,7 @@ static struct funmap functnames[] = {
{showcpos, "what-cursor-position",},
{filewrite, "write-file",},
{yank, "yank",},
+ {gotoindent, "back-to-indentation",},
{NULL, NULL,}
};
Index: src/usr.bin/mg/keymap.c
===
RCS file: /cvs/src/usr.bin/mg/keymap.c,v
retrieving revision 1.43
diff -u -p -r1.43 keymap.c
--- src/usr.bin/mg/keymap.c 27 Aug 2008 04:11:52 - 1.43
+++ src/usr.bin/mg/keymap.c 22 Dec 2010 16:12:15 -
@@ -241,7 +241,7 @@ static PF metasqf[] = {
static PF metal[] = {
lowerword, /* l */
- rescan, /* m */
+ gotoindent, /* m */
rescan, /* n */
rescan, /* o */
rescan, /* p */
Index: src/usr.bin/mg/mg.1
===
RCS file: /cvs/src/usr.bin/mg/mg.1,v
retrieving revision 1.47
diff -u -p -r1.47 mg.1
--- src/usr.bin/mg/mg.1 7 Oct 2010 17:08:58 - 1.47
+++ src/usr.bin/mg/mg.1 22 Dec 2010 16:12:15 -
@@ -230,6 +230,8 @@ kill-word
forward-word
.It M-l
downcase-word
+.It M-m
+back-to-indentation
.It M-q
fill-paragraph
.It M-r
@@ -402,6 +404,8 @@ Set all characters in the region to lowe
Set characters to lower case, starting at the dot, and ending
.Va n
words away.
+.It back-to-indentation
+Move the dot to the first non-whitespace character of the line.
.It emacs-version
Return an
.Nm
Index: src/usr.bin/mg/random.c
===
RCS file: /cvs/src/usr.bin/mg/random.c,v
retrieving revision 1.26
diff -u -p -r1.26 random.c
--- src/usr.bin/mg/random.c 15 Sep 2008 16:13:35 - 1.26
+++ src/usr.bin/mg/random.c 22 Dec 2010 16:12:15 -
@@ -440,3 +440,16 @@ space_to_tabstop(int f, int n)
return (linsert((n << 3) - (curwp->w_doto & 7), ' '));
}
#endif /* NOTAB */
+
+/*
+ * Move the dot to the first non-whitespace character of the current line.
+ */
+int
+gotoindent(int f, int n)
+{
+ gotobol(FFRAND, 1);
+ while (curwp->w_doto < llength(curwp->w_dotp) &&
+ (isspace(lgetc(curwp->w_dotp, curwp->w_doto
+ ++curwp->w_doto;
+ return (TRUE);
+}
Re: upgrade and fsck
On Fri, Dec 24, 2010 at 10:05:28AM +0100, Otto Moerbeek wrote:
> Hi,
>
> It has been a long time since a saw an incosistent fs with the clean
> flag set. So default to no and rephrase a litle to make it clearer.
I like it because I always type "n" at that prompt. ok.
>
> -Otto
>
> Index: install.sub
> ===
> RCS file: /cvs/src/distrib/miniroot/install.sub,v
> retrieving revision 1.631
> diff -u -p -r1.631 install.sub
> --- install.sub 22 Nov 2010 14:10:42 - 1.631
> +++ install.sub 24 Dec 2010 09:03:12 -
> @@ -1727,7 +1727,7 @@ getdevname() {
> check_fs() {
> local _dev _mp _fstype _rest _fail _f
>
> - ask_yn "Force checking of non-root filesystems?" yes
> + ask_yn "Force checking of clean non-root filesystems?"
> [[ $resp == y ]] && _f=f
>
> while read _dev _mp _fstype _rest; do
upgrade and fsck
Hi,
It has been a long time since a saw an incosistent fs with the clean
flag set. So default to no and rephrase a litle to make it clearer.
-Otto
Index: install.sub
===
RCS file: /cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.631
diff -u -p -r1.631 install.sub
--- install.sub 22 Nov 2010 14:10:42 - 1.631
+++ install.sub 24 Dec 2010 09:03:12 -
@@ -1727,7 +1727,7 @@ getdevname() {
check_fs() {
local _dev _mp _fstype _rest _fail _f
- ask_yn "Force checking of non-root filesystems?" yes
+ ask_yn "Force checking of clean non-root filesystems?"
[[ $resp == y ]] && _f=f
while read _dev _mp _fstype _rest; do
