[no subject]
S V wrote: > 2023-07-27 17:24 GMT+03:00, Theo de Raadt : > > You don't explain why you are trying to enable floating point register > > use in the kernel. > > I just have CPU with it (Cortex-a57 with NEON), so was toying with it > trying to look if I get more performance. > Got this error and decided to post, thinking - maybe I got some "not > yet discovered" problem. > > I'm not good with kernel development (sent only simple patches) so was > curious about it. What you are trying to do won't work at all. If the kernel uses floating point registers, it must save/restore them at multiple types of context switching points, which is why kernels normally do not do this, except in very controlled fashion. One doesn't set a compile option, and get this. You are in way over your head
[no subject]
I was trying (as an experiment) to build aarch64 current kernel with -march=armv8-a+simd and stumble upon error Interesting to notice that armv8-a+nofp+simd compiles and runs OK part of output with error: cc -g -Werror -Wall -Wimplicit-function-declaration -Wno-pointer-sign -Wno-constant-conversion -Wno-address-of-packed-member -Wno-unused-but-set-variable -Wno-gnu-folding-constant -Wframe-larger-than=2047 -Wno-deprecated-non-prototype -Wno-unknown-warning-option -march=armv8-a+fp+simd -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -ffixed-x18 -ffreestanding -fno-pie -mbranch-protection=bti -O2 -pipe -nostdinc -I/usr/src/sys -I/usr/src/sys/arch/arm64/compile/CUSTOM.MP/obj -I/usr/src/sys/arch -I/usr/src/sys/dev/pci/drm/include -I/usr/src/sys/dev/pci/drm/include/uapi -I/usr/src/sys/dev/pci/drm/amd/include/asic_reg -I/usr/src/sys/dev/pci/drm/amd/include -I/usr/src/sys/dev/pci/drm/amd/amdgpu -I/usr/src/sys/dev/pci/drm/amd/display -I/usr/src/sys/dev/pci/drm/amd/display/include -I/usr/src/sys/dev/pci/drm/amd/display/dc -I/usr/src/sys/dev/pci/drm/amd/display/amdgpu_dm -I/usr/src/sys/dev/pci/drm/amd/pm/inc -I/usr/src/sys/dev/pci/drm/amd/pm/legacy-dpm -I/usr/src/sys/dev/pci/drm/amd/pm/swsmu -I/usr/src/sys/dev/pci/drm/amd/pm/swsmu/inc -I/usr/src/sys/dev/pci/drm/amd/pm/swsmu/smu11 -I/usr/src/sys/dev/pci/drm/amd/pm/swsmu/smu12 -I/usr/src/sys/dev/pci/drm/amd/pm/swsmu/smu13 -I/usr/src/sys/dev/pci/drm/amd/pm/powerplay/inc -I/usr/src/sys/dev/pci/drm/amd/pm/powerplay/hwmgr -I/usr/src/sys/dev/pci/drm/amd/pm/powerplay/smumgr -I/usr/src/sys/dev/pci/drm/amd/pm/swsmu/inc -I/usr/src/sys/dev/pci/drm/amd/pm/swsmu/inc/pmfw_if -I/usr/src/sys/dev/pci/drm/amd/display/dc/inc -I/usr/src/sys/dev/pci/drm/amd/display/dc/inc/hw -I/usr/src/sys/dev/pci/drm/amd/display/dc/clk_mgr -I/usr/src/sys/dev/pci/drm/amd/display/modules/inc -I/usr/src/sys/dev/pci/drm/amd/display/modules/hdcp -I/usr/src/sys/dev/pci/drm/amd/display/dmub/inc -DDDB -DDIAGNOSTIC -DKTRACE -DACCOUNTING -DKMEMSTATS -DPTRACE -DPOOL_DEBUG -DCRYPTO -DSYSVMSG -DSYSVSEM -DSYSVSHM -DUVM_SWAP_ENCRYPT -DFFS -DFFS2 -DFFS_SOFTUPDATES -DUFS_DIRHASH -DQUOTA -DEXT2FS -DMFS -DNFSCLIENT -DNFSSERVER -DCD9660 -DUDF -DMSDOSFS -DFIFO -DFUSE -DSOCKET_SPLICE -DTCP_ECN -DTCP_SIGNATURE -DINET6 -DIPSEC -DPPP_BSDCOMP -DPPP_DEFLATE -DPIPEX -DMROUTING -DMPLS -DBOOT_CONFIG -DPCIVERBOSE -DUSER_PCICONF -DUSBVERBOSE -DSUSPEND -DWSDISPLAY_COMPAT_USL -DWSDISPLAY_COMPAT_RAWKBD -DWSDISPLAY_DEFAULTSCREENS="6" -DONEWIREVERBOSE -DMULTIPROCESSOR -DMAXUSERS=80 -D_KERNEL -D__arm64__ -MD -MP -c /usr/src/sys/dev/usb/ohci.c /usr/src/sys/dev/usb/ohci.c:708:1: error: stack frame size (2192) exceeds limit (2047) in function 'ohci_init' [-Werror,-Wframe-larger-than] ohci_init(struct ohci_softc *sc) ^ 1 error generated. *** Error 1 in /usr/src/sys/arch/arm64/compile/CUSTOM.MP (Makefile:1562 'ohci.o') -- Nerfur Dragon -==(UDIC)==-
[no subject]
On Tue, 08 Nov 2022 18:05:24 +, Klemens Nanni wrote: > Subject: Document ifc_list immutability Sure. OK millert@ - todd
[no subject]
Subject: Document ifc_list immutability
OK?
diff --git a/sys/net/if_var.h b/sys/net/if_var.h
index 28514a0bfcd..a472c586f3c 100644
--- a/sys/net/if_var.h
+++ b/sys/net/if_var.h
@@ -78,11 +78,15 @@ struct ifnet;
struct task;
struct cpumem;
+/*
+ * Locks used to protect struct members in this file:
+ * I immutable after creation
+ */
/*
* Structure describing a `cloning' interface.
*/
struct if_clone {
- LIST_ENTRY(if_clone) ifc_list; /* on list of cloners */
+ LIST_ENTRY(if_clone) ifc_list; /* [I] on list of cloners */
const char *ifc_name; /* name of device, e.g. `gif' */
size_t ifc_namelen; /* length of name */
[no subject]
Hello OpenBSD developers! I have a suggestion on how to get the current executable path in OpenBSD that might be reliable enough and not too costly that it might be accepted for a future OpenBSD version. Even if it won't be accepted, I need a little help completing the solution I have in mind. The current solution relies on $PWD, $PATH, and argv[0] to guess the most-likely executable path if $PWD, $PATH, or arv[0] were not modified from their original values. The code that does this i originally wrote in C++, I found someone else wrote a C solution which does the same thing, and I helped them by adding the $PWD code logic as a replacement for the cwd. The code is here: https://github.com/time-killer-games/getexecname/blob/patch-1/getexecname.c Due to the use of realpath() if the exe is not found, an empty string or NULL can be returned. However, I want to take it a step further in terms of error codes if an existing executable is in fact found, though it does not point to the same executable that actually spawned the current process. For example: Running firefox but argv[0] was modified to look like it was actually chromium that was running when it isn't chromium. Just an example of that. This doesn't solve the issue of multiple hard links to the executable, which is unlikely to happen enough I'm not worried about it all that much. Maybe an error code could be done in the case of multiple executable hard links which the number of hard links could be retrieved from the stat structure. Which leads to how my other error codes will be returned: Here's my thoughts on the matter as discussed on implementing this feature for the OpenBSD version of the fish shell: The issue: linking errors and not knowing what libraries to link (documentation on the function I use seem incomplete): https://github.com/fish-shell/fish-shell/issues/9086#issuecomment-1194464329 "I've come up with a means to get a proper error code if the executable path returns a path to the wrong file. Basically if meams getting the vnode from the current process id, get the stat struct from the vnode, the compare a few stat structure members with the stat structure returned by opening the path the function guessed points to the current executable. It involves working with a lot of kernel functions which do have documentation but for one reason or another I can't get any of it to compile because linking errors, and the docs don't say anything about what libraries I should be linking to. It will take a while, but this is a lot better." The implementation I am using explained, which is currently incomplete: https://github.com/fish-shell/fish-shell/issues/9086#issuecomment-1194504685 Note: This code won't be implemented in fish shell as the idea was rejected by them, however I'd like to use this code for my own libraries once it is finished. "To expand on my previous comment, here's some general notes from my research yesterday. To get the vnode from a process id, you must get the struct process * from the process id using the function struct process *prfind(pid_t) declared in sys/proc.h. Then from that struct process * there is the member of the struct called struct vnode *ps_textvp which according to the code comment and other research is in fact the struct vnode * of the process's executable file. The struct process * structure is defined in sys/proc.h. The _KERNEL and __need_process macros need to be defined before including the sys/proc.h header otherwise the struct process * will not be defined. Defining _KERNEL before including sys/proc.h must be done, however it breaks my code if I define that macro before including sys/vnode.h, which is required for the int VOP_GETATTR(struct vnode *, struct vattr *, struct ucred *, struct proc *) function among other things we need, like the struct vattr * structure, which holds the information necessary to get a proper struct stat * from the struct vnode *. To actually get the struct stat * from the struct vnode *, we call int vn_stat(struct vnode *, struct stat *, struct proc *) which also relies on another structure we need to magically get from the current process id, struct proc *. I'm not sure if that parameter can be null or not, or if that would cause issues. MAXCPUS is a macro which needs to be defined, and I'm not sure what header is the right one to include for it, but it depends on the architecture when done incorrectly because each architecture of binary has its own definition of its macro in a different folder in the source tree named after the architecture. For example, if you are building for amd64, it will be in a folder named amd64, etc. Despute having all the right includes and defining that MAXCPUS macro on my own as 64, it still gives me undefined references when building. According to the multiple sources I've found, comparing the ino_t, dev_t, (and possible filesize, modified timestamp) members of struct stat is good
[no subject]
Hi,
I sent this to bugs a while back, but it doesn't seem to have been picked up by
anyone.
On both i386 and amd64, the machine boot command in the bootloader has an off
by one bug, which has been present since revision 1.20 in 1998.
The machine boot command is implemented by patching the in-memory copy of the
MBR to set the active partition flag on the selected partition, and reset it on
the other three partitions. The test for part>0 will be false if the first MBR
partition is selected for boot, and in that case no patching of the active
partition flag is performed. The desired behaviour when entering machine boot
hd0a, for example, is that the first partition will be booted regardless of the
state of the flags in the on-disk MBR. However, with the code as it is, the
currently active partition will be booted instead, which may or may not be the
first.
untrusted comment: verify with signify key for exoticsilicon.com
RWRn5d3Yx35u0w51USyxAkjCzjLo99UNE67gXzvuaTGbD9cMlTKdDTOAOe7JA6LV/VLWqmomwo7D9m399vKnra2KyrUn/EYcUgo=
--- arch/amd64/stand/libsa/cmd_i386.c.dist Fri May 10 18:20:43 2019
+++ arch/amd64/stand/libsa/cmd_i386.c Sun Aug 15 23:44:45 2021
@@ -107,7 +107,7 @@
dev += (cmd.argv[1][2] - '0');
part = (cmd.argv[1][3] - 'a');
- if (part > 0)
+ if (part >= 0)
printf("[%x,%d]\n", dev, part);
else
printf("[%x]\n", dev);
@@ -119,7 +119,7 @@
goto bad;
/* Frob boot flag in buffer from HD */
- if ((dev & 0x80) && (part > 0)){
+ if ((dev & 0x80) && (part >= 0)){
int i, j;
for (i = 0, j = DOSPARTOFF; i < 4; i++, j += 16)
--- arch/i386/stand/libsa/cmd_i386.c.dist Fri Jun 10 15:36:06 2016
+++ arch/i386/stand/libsa/cmd_i386.cSun Aug 15 23:44:23 2021
@@ -119,7 +119,7 @@
dev += (cmd.argv[1][2] - '0');
part = (cmd.argv[1][3] - 'a');
- if (part > 0)
+ if (part >= 0)
printf("[%x,%d]\n", dev, part);
else
printf("[%x]\n", dev);
@@ -131,7 +131,7 @@
goto bad;
/* Frob boot flag in buffer from HD */
- if ((dev & 0x80) && (part > 0)){
+ if ((dev & 0x80) && (part >= 0)){
int i, j;
for (i = 0, j = DOSPARTOFF; i < 4; i++, j += 16)
(No Subject)
subscribe
[no subject]
foo
[no subject]
subscribe tech@openbsd.org
[no subject]
Currently, pcap_setdirection() is described in pcap.3 as follows: pcap_setdirection() is used to limit the direction that packets must be flowing in order to be captured. The "direction" is not described, except in pcap.h. Should the constants be mentioned in the manpage? Also, the direction only seems to matter for live captures. Jan Index: pcap.3 === RCS file: /cvs/src/lib/libpcap/pcap.3,v retrieving revision 1.48 diff -u -p -r1.48 pcap.3 --- pcap.3 3 Jun 2018 10:45:15 - 1.48 +++ pcap.3 10 Dec 2018 07:12:53 - @@ -535,6 +535,15 @@ datalink types. .Fn pcap_setdirection is used to limit the direction that packets must be flowing in order to be captured. +The direction is either +.Dv PCAP_D_INOUT , +.Dv PCAP_D_IN +or +.Dv PCAP_D_OUT . +Direction is only relevant to live captures. +When reading from a dump file, +.Fn pcap_setdirection +has no effect . .Pp .Fn pcap_list_datalinks returns an array of the supported datalink types for an opened live capture
[no subject]
Hi,
this removes the currently unused arguments *warnmess and ratecap from
pool_sethardlimit().
ok?
diff --git share/man/man9/pool.9 share/man/man9/pool.9
index 75742cf12ab..27226e14a25 100644
--- share/man/man9/pool.9
+++ share/man/man9/pool.9
@@ -72,8 +72,6 @@
.Fo pool_sethardlimit
.Fa "struct pool *pp"
.Fa "unsigned n"
-.Fa "const char *warnmess"
-.Fa "int ratecap"
.Fc
.Sh DESCRIPTION
These utility routines provide management of pools of fixed-sized
@@ -286,11 +284,6 @@ The function
sets a hard limit on the pool to
.Fa n
items.
-If the hard limit is reached
-.Fa warnmess
-will be printed to the console, but no more than every
-.Fa ratecap
-seconds.
Upon successful completion, a value of 0 is returned.
The value EINVAL is returned when the current size of the pool
already exceeds the requested hard limit.
diff --git sys/kern/subr_pool.c sys/kern/subr_pool.c
index 54688dfe0ea..1c8af82b851 100644
--- sys/kern/subr_pool.c
+++ sys/kern/subr_pool.c
@@ -427,11 +427,6 @@ pool_init(struct pool *pp, size_t size, u_int align, int
ipl, int flags,
pp->pr_nitems = 0;
pp->pr_nout = 0;
pp->pr_hardlimit = UINT_MAX;
- pp->pr_hardlimit_warning = NULL;
- pp->pr_hardlimit_ratecap.tv_sec = 0;
- pp->pr_hardlimit_ratecap.tv_usec = 0;
- pp->pr_hardlimit_warning_last.tv_sec = 0;
- pp->pr_hardlimit_warning_last.tv_usec = 0;
RBT_INIT(phtree, &pp->pr_phtree);
/*
@@ -1074,7 +1069,7 @@ pool_sethiwat(struct pool *pp, int n)
}
int
-pool_sethardlimit(struct pool *pp, u_int n, const char *warnmsg, int ratecap)
+pool_sethardlimit(struct pool *pp, u_int n)
{
int error = 0;
@@ -1084,10 +1079,6 @@ pool_sethardlimit(struct pool *pp, u_int n, const char
*warnmsg, int ratecap)
}
pp->pr_hardlimit = n;
- pp->pr_hardlimit_warning = warnmsg;
- pp->pr_hardlimit_ratecap.tv_sec = ratecap;
- pp->pr_hardlimit_warning_last.tv_sec = 0;
- pp->pr_hardlimit_warning_last.tv_usec = 0;
done:
return (error);
diff --git sys/net/pf_ioctl.c sys/net/pf_ioctl.c
index ece193752a8..87f097dac6f 100644
--- sys/net/pf_ioctl.c
+++ sys/net/pf_ioctl.c
@@ -175,7 +175,7 @@ pfattach(int num)
pf_osfp_initialize();
pool_sethardlimit(pf_pool_limits[PF_LIMIT_STATES].pp,
- pf_pool_limits[PF_LIMIT_STATES].limit, NULL, 0);
+ pf_pool_limits[PF_LIMIT_STATES].limit);
if (physmem <= atop(100*1024*1024))
pf_pool_limits[PF_LIMIT_TABLE_ENTRIES].limit =
@@ -2448,7 +2448,7 @@ pfioctl(dev_t dev, u_long cmd, caddr_t addr, int flags,
struct proc *p)
if (pf_pool_limits[i].limit_new !=
pf_pool_limits[i].limit &&
pool_sethardlimit(pf_pool_limits[i].pp,
- pf_pool_limits[i].limit_new, NULL, 0) != 0) {
+ pf_pool_limits[i].limit_new) != 0) {
free(table, M_TEMP, sizeof(*table));
free(ioe, M_TEMP, sizeof(*ioe));
error = EBUSY;
diff --git sys/net/pf_norm.c sys/net/pf_norm.c
index 68308b027d3..de1eeab612b 100644
--- sys/net/pf_norm.c
+++ sys/net/pf_norm.c
@@ -166,7 +166,7 @@ pf_normalize_init(void)
IPL_SOFTNET, 0, "pfstscr", NULL);
pool_sethiwat(&pf_frag_pl, PFFRAG_FRAG_HIWAT);
- pool_sethardlimit(&pf_frent_pl, PFFRAG_FRENT_HIWAT, NULL, 0);
+ pool_sethardlimit(&pf_frent_pl, PFFRAG_FRENT_HIWAT);
TAILQ_INIT(&pf_fragqueue);
diff --git sys/netinet/tcp_subr.c sys/netinet/tcp_subr.c
index 67e8c1a80a1..e142df36525 100644
--- sys/netinet/tcp_subr.c
+++ sys/netinet/tcp_subr.c
@@ -141,10 +141,10 @@ tcp_init(void)
"tcpcb", NULL);
pool_init(&tcpqe_pool, sizeof(struct tcpqent), 0, IPL_SOFTNET, 0,
"tcpqe", NULL);
- pool_sethardlimit(&tcpqe_pool, tcp_reass_limit, NULL, 0);
+ pool_sethardlimit(&tcpqe_pool, tcp_reass_limit);
pool_init(&sackhl_pool, sizeof(struct sackhole), 0, IPL_SOFTNET, 0,
"sackhl", NULL);
- pool_sethardlimit(&sackhl_pool, tcp_sackhole_limit, NULL, 0);
+ pool_sethardlimit(&sackhl_pool, tcp_sackhole_limit);
in_pcbinit(&tcbtable, TCB_INITIAL_HASH_SIZE);
tcpcounters = counters_alloc(tcps_ncounters);
diff --git sys/netinet/tcp_usrreq.c sys/netinet/tcp_usrreq.c
index cc2b23e0661..1570eca653f 100644
--- sys/netinet/tcp_usrreq.c
+++ sys/netinet/tcp_usrreq.c
@@ -1043,7 +1043,7 @@ tcp_sysctl(int *name, u_int namelen, void *oldp, size_t
*oldlenp, void *newp,
nval = tcp_reass_limit;
error = sysctl_int(oldp, oldlenp, newp, newlen, &nval);
if (!error && nval != tcp_reass_limit) {
- error = pool_sethardlimit(&tcpqe_pool, nval, NULL, 0);
+ error = pool_sethardlimit(&tcpqe_pool, nval);
if (!error)
[no subject]
Including when using getopt(3) also makes
extern int opterr, optind, optopt, optreset;
and friends declared, but many utils redeclare them again.
Is there a reason for that, or can those be removed?
As a harmless example, here's a diff to games.
Jan
Index: fortune/strfile/strfile.c
===
RCS file: /cvs/src/games/fortune/strfile/strfile.c,v
retrieving revision 1.29
diff -u -p -r1.29 strfile.c
--- fortune/strfile/strfile.c 4 Jun 2017 13:39:25 - 1.29
+++ fortune/strfile/strfile.c 3 Nov 2017 17:32:52 -
@@ -252,8 +252,6 @@ main(int ac, char *av[])
void
getargs(int argc, char *argv[])
{
- extern char *optarg;
- extern int optind;
int ch;
while ((ch = getopt(argc, argv, "c:hiorsx")) != -1) {
Index: hunt/hunt/hunt.c
===
RCS file: /cvs/src/games/hunt/hunt/hunt.c,v
retrieving revision 1.22
diff -u -p -r1.22 hunt.c
--- hunt/hunt/hunt.c8 Apr 2017 22:50:41 - 1.22
+++ hunt/hunt/hunt.c3 Nov 2017 17:32:52 -
@@ -85,8 +85,6 @@ int
main(int ac, char **av)
{
int c;
- extern int optind;
- extern char *optarg;
longenter_status;
int option;
struct servent *se;
Index: hunt/huntd/driver.c
===
RCS file: /cvs/src/games/hunt/huntd/driver.c,v
retrieving revision 1.29
diff -u -p -r1.29 driver.c
--- hunt/huntd/driver.c 21 Jan 2017 08:22:57 - 1.29
+++ hunt/huntd/driver.c 3 Nov 2017 17:32:52 -
@@ -80,8 +80,6 @@ main(int ac, char **av)
static fd_set read_fds;
static FLAG first = TRUE;
static FLAG server = FALSE;
- extern int optind;
- extern char *optarg;
extern char *__progname;
int c;
static struct timeval linger = { 0, 0 };
Index: robots/main.c
===
RCS file: /cvs/src/games/robots/main.c,v
retrieving revision 1.26
diff -u -p -r1.26 main.c
--- robots/main.c 28 May 2017 21:01:13 - 1.26
+++ robots/main.c 3 Nov 2017 17:32:52 -
@@ -56,7 +56,6 @@ main(int ac, char *av[])
int score_err = 0; /* hold errno from score file open */
int ch;
int ret;
- extern int optind;
char*home;
#ifdef FANCY
char*sp;
[no subject]
espie@openbsd, dera...@cvs.openbsd.org Bcc: Subject: Re: sqlite 3.8.11.1 Reply-To: In-Reply-To: <20150909084510.gh30...@tazenat.gentiane.org> On Wed, Sep 09, 2015 at 08:45:10AM +, Miod Vallat wrote: > > Hi, > > > > thanks to the hard work of jturner@, here's a 650kb gzipped update to > > sqlite 3.8.11.1, bumping shlib to 31.0. This is needed for upcoming > > firefox 41 update, but anyone is welcome to look into the update itself. > > > > Not attaching the diff because of the size, available at > > http://rhaalovely.net/~landry/stuff/sqlite-3.8.11.1.diff.gz > > Do we really need to import lib/libsqlite3/ext/fts5/test/ which amounts > for half of the diff? > To give a little background on why we have all these directories and files based on my understanding... When espie@ imported sqlite he wanted to follow upstream so he imported what was distrubuted with sqlite. Since then we do tagged (based on the sqlite version) imports whenever we do an update. So when a diff is sent out it includes all new files in that sqlite release. In this case there is a new fts5 backend which contains a lot of tests (which we never run). We also haven't enabled the fts5 backend at this time. Now we could change strategies and I could only create a diff of the changes we actually want and then remove all these extra files from our tree and the use commit rather then import going forward. I would be fine with this as it would make each update more manageable but I'm not sure what espie@ original goals where with following upstream. -- James Turner
[no subject]
Merge two identical if() statements. The change in ip_spd.c 1.59
makes it appear that there is a cut & pasto. We should merge the
two identical and adjacent if() statements to avoid confusing people
(and static analyzers).
- todd
Index: sys/netinet/ip_spd.c
===
RCS file: /cvs/src/sys/netinet/ip_spd.c,v
retrieving revision 1.83
diff -u -p -r1.83 ip_spd.c
--- sys/netinet/ip_spd.c16 Apr 2015 19:24:13 - 1.83
+++ sys/netinet/ip_spd.c30 Apr 2015 16:19:00 -
@@ -687,15 +687,13 @@ ipsp_acquire_sa(struct ipsec_policy *ipo
if (ipsp_is_unspecified(ipo->ipo_dst)) {
ipa->ipa_info.sen_ip_src = ddst->sen_ip_src;
ipa->ipa_mask.sen_ip_src.s_addr = INADDR_BROADCAST;
- } else {
- ipa->ipa_info.sen_ip_src = ipo->ipo_addr.sen_ip_src;
- ipa->ipa_mask.sen_ip_src = ipo->ipo_mask.sen_ip_src;
- }
- if (ipsp_is_unspecified(ipo->ipo_dst)) {
ipa->ipa_info.sen_ip_dst = ddst->sen_ip_dst;
ipa->ipa_mask.sen_ip_dst.s_addr = INADDR_BROADCAST;
} else {
+ ipa->ipa_info.sen_ip_src = ipo->ipo_addr.sen_ip_src;
+ ipa->ipa_mask.sen_ip_src = ipo->ipo_mask.sen_ip_src;
+
ipa->ipa_info.sen_ip_dst = ipo->ipo_addr.sen_ip_dst;
ipa->ipa_mask.sen_ip_dst = ipo->ipo_mask.sen_ip_dst;
}
[no subject]
[no subject]
Hi again after discussins with Helg, second change is not relevant, so only the first should remains. Kind regards. Index: fuse.c === RCS file: /cvs/src/lib/libfuse/fuse.c,v retrieving revision 1.24 diff -u -p -r1.24 fuse.c --- fuse.c 20 May 2014 13:32:22 - 1.24 +++ fuse.c 1 Jan 2015 13:17:02 - @@ -493,5 +493,8 @@ fuse_main(int argc, char **argv, const s if (!fuse) return (-1); + if (mp) + free(mp); + return (fuse_loop(fuse)); }
[no subject]
Envoyé depuis Windows Mail
[no subject]
Yes. As it would seem, that was unintentional, possibly caused by a bad merge. I didn't pick this up as it worked on my system. It was thanks to Otto's messae re parsing changes that I managed to pick that up. I am working on a new diff which will be released some time within the next few hours. - Adam. On Thu, 18 Sep 2014 17:58:14 +0200 Alexander Hall wrote: > Aren't you missing something relevant here...? :-) > > /Alexander >
[no subject]
Fcc: +outbox Subject: Re: that private mailing list (fwd) Solar Designer: Re: that private mailing list I haven't even read this. I don't care. if this is the situation with open source disclosure, all of you users are fucked. --- Forwarded Message Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by cvs.openbsd.org (8.14.8/8.12.1) with SMTP id s564LjFg027340 for ; Thu, 5 Jun 2014 22:21:46 -0600 (MDT) Received: (qmail 19629 invoked from network); 6 Jun 2014 04:21:39 - Received: from localhost (HELO pvt.openwall.com) (127.0.0.1) by localhost with SMTP; 6 Jun 2014 04:21:39 - Received: by pvt.openwall.com (Postfix, from userid 503) id 82DA048BCE; Fri, 6 Jun 2014 08:21:05 +0400 (MSK) Date: Fri, 6 Jun 2014 08:21:05 +0400 From: Solar Designer To: Theo de Raadt Subject: Re: that private mailing list Message-ID: <20140606042105.gb26...@openwall.com> References: <201406052157.s55lvh7j020...@cvs.openbsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201406052157.s55lvh7j020...@cvs.openbsd.org> User-Agent: Mutt/1.4.2.3i Hi Theo, I'll reply only in private first, because I am referring to the past discussion we had in private and that you didn't want to be made public. Also, please note that I wrote the below with no hard feelings, and I don't mean to offend you. I am just being sincere and direct. I think that is your preferred way to communicate, so I've adopted it. :-) On Thu, Jun 05, 2014 at 03:57:43PM -0600, Theo de Raadt wrote: > I only know parts. It sound like some people who claim they stand > up for what is right really don't stand up for what is right. I can't comment about OpenSSL folks, but my own impression certainly was that you didn't want your project to be provided advance notification - not only via distros list, but at all. Now you're saying you actually wanted folks on your team to be notified, just not you personally. Hmm? As you had mentioned to me in the private discussion when stu@ wanted to get OpenBSD onto distros, you didn't want folks on your team to accept any kind of embargo. I wish we had that discussion in public, as I had suggested at the time. You objected to that. (And I understand that with that discussion in public you might not have been willing to blame some others in it, which would possibly hamper my understanding of your position. So your objection did make some sense.) Now you appear to be misinforming folks on your own team (I hope not intentionally) that those evil people on distros list and OpenSSL maintainers deliberately didn't want to notify you. You might be right about OpenSSL maintainers (although I think you are not) - I just don't know, and can't speak for them - but at least for me (as someone who was notified via distros list) it appeared that you actually didn't want your team to be notified in a manner that would impose any restrictions on when you can commit a fix. So, believe it or not, it didn't even occur to me to put your project in a position where your folks would be asked to accept an embargo, which you didn't want. Would you like me to suggest (to whoever reports an issue) that someone on your team (who?) be notified next time an OpenSSL issue is brought up on distros? (It doesn't have to be one person on your team - it can be several. This is to address Bob's comment on your lists.) What about issues in other projects (not OpenSSL)? Which other projects would you also like notifications about? It appears that you've made a (political) decision for your projects not to join distros (or possibly any such channels in general), but are now asking for people/projects to be notifying your folks anyway when appropriate (whatever that means), and this is difficult for everyone. How do you suggest we make things better (in whatever sense you like) going forward? /sd --- End of Forwarded Message
[no subject]
I generally associate negative connotations with so-called, as in
the "so-called free world". I wouldn't use it just to name something,
as in "the kernel is written in the so-called C language". so-called
implies "it's called this, but it's not".
Two imo dubious occurrences in the install notes. It's not a so-called
MBR partition; it is an MBR partition. Similarly with hppa LIF.
There's one other use in loongson about initrd which seems ok.
(There is another definition of so-called which isn't negative, as in
"if you want a great OS check out OpenBSD, so-called because the
source is all open". But that's not how so-called is used below.)
Index: m4.common
===
RCS file: /cvs/src/distrib/notes/m4.common,v
retrieving revision 1.99
diff -u -p -r1.99 m4.common
--- m4.common 4 Dec 2013 23:20:19 - 1.99
+++ m4.common 25 Jan 2014 00:54:18 -
@@ -477,8 +477,8 @@ dnl Describes MBR partitioning. So much
dnl duplicated 5 times.
dnl
define({:-OpenBSDInstallMBRPart1-:},
-{:-Disks on OpenBSD/MACHINE are partitioned using the so-called
- ``MBR'' partitioning scheme. You will need to create one
+{:-Disks on OpenBSD/MACHINE are partitioned using the ``MBR''
+ partitioning scheme. You will need to create one
MBR partition, in which all the real OpenBSD partitions will
be created.-:})dnl
dnl
Index: hppa/install
===
RCS file: /cvs/src/distrib/notes/hppa/install,v
retrieving revision 1.24
diff -u -p -r1.24 install
--- hppa/install4 Dec 2013 23:20:19 - 1.24
+++ hppa/install25 Jan 2014 00:54:33 -
@@ -47,7 +47,7 @@ Booting from Network:
reasonably portable to other UN*X-like operating systems. More information
on diskless booting can be found in the OpenBSD diskless(8) manual page.
- Your MACHINE expects to be able to download a so-called LIF (``Logical
+ Your MACHINE expects to be able to download a LIF (``Logical
Interchange Format'') image, containing both the boot code and the kernel,
via the HP rboot protocol, for older firmware, or via the bootp protocol,
for more recent firmware.
[no subject]
Dk sqoexmncn p`gbhrh ahgmeq` menaundhl` j`weqrbemm` h dnqrsom` pejk`l`. B
m`xe bpel nqmnbm{l qpedqrbnl pejk`l{ bkerq Hmrepmer, on qjnk|js d`er
bnglnfmnqr| p`qxhphr| cp`mhv{, nap`rhr| m` qea bmhl`mhe h ophbkew| mnb{u
jkhemrnb hg whqk` xhpnjni `sdhrnphh "bqelhpmni o`srhm{".
Opedk`c`el B`l sqksch on qngd`mh~ Hmrepmer-q`irnb h kncnrhonb.
Cnrnb{i q`ir ond jk~w nr 8 000 psakei.
Kncnrho{ nr 1000 psakei.
(no subject)
What's happening! I was searching the web and found... there doing a giveaway for an iPad2! you need to hurry up and get yours before they run out heres the web link.. http://so.ee/K50
[no subject]
Index: dev/pci/piixpm.c
===
RCS file: /cvs/src/sys/dev/pci/piixpm.c,v
retrieving revision 1.35
diff -u -r1.35 piixpm.c
--- dev/pci/piixpm.c9 Apr 2011 04:33:40 - 1.35
+++ dev/pci/piixpm.c24 Apr 2011 03:16:31 -
@@ -115,6 +115,7 @@
struct piixpm_softc *sc = (struct piixpm_softc *)self;
struct pci_attach_args *pa = aux;
struct i2cbus_attach_args iba;
+ u_int8_t base_en_low, base_en_high;
pcireg_t base, conf;
pci_intr_handle_t ih;
const char *intrstr = NULL;
@@ -123,19 +124,33 @@
conf = pci_conf_read(pa->pa_pc, pa->pa_tag, PIIX_SMB_HOSTC);
DPRINTF((": conf 0x%08x", conf));
- if ((conf & PIIX_SMB_HOSTC_HSTEN) == 0) {
- printf(": SMBus disabled\n");
- return;
- }
-
/* Map I/O space */
sc->sc_iot = pa->pa_iot;
- base = pci_conf_read(pa->pa_pc, pa->pa_tag, PIIX_SMB_BASE) & 0x;
- if (PCI_MAPREG_IO_ADDR(base) == 0 ||
- bus_space_map(sc->sc_iot, PCI_MAPREG_IO_ADDR(base),
- PIIX_SMB_SIZE, 0, &sc->sc_ioh)) {
- printf(": can't map i/o space\n");
- return;
+ if (PCI_VENDOR(pa->pa_id) == PCI_VENDOR_ATI &&
+ PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_ATI_SBX00_SMB &&
+ PCI_REVISION(pa->pa_class) >= 0x40) {
+ /* SB800+ SMB configuration.. pio macros avoidable? */
+ outb(0xcd6, 0x2c);
+ base_en_low = inb(0xcd7);
+ outb(0xcd6, 0x2d);
+ base_en_high = inb(0xcd7);
+ base = ((base_en_high << 8) | base_en_low) & 0xffe0;
+ bus_space_map(sc->sc_iot, PCI_MAPREG_IO_ADDR(base),
+ PIIX_SMB_SIZE, 0, &sc->sc_ioh);
+ } else {
+ if ((conf & PIIX_SMB_HOSTC_HSTEN) == 0) {
+ printf(": SMBus disabled\n");
+ return;
+ }
+
+ base = pci_conf_read(pa->pa_pc, pa->pa_tag,
+ PIIX_SMB_BASE) & 0x;
+ if (PCI_MAPREG_IO_ADDR(base) == 0 ||
+ bus_space_map(sc->sc_iot, PCI_MAPREG_IO_ADDR(base),
+ PIIX_SMB_SIZE, 0, &sc->sc_ioh)) {
+ printf(": can't map i/o space\n");
+ return;
+ }
}
sc->sc_poll = 1;
[no subject]
Hi,
Here are a couple of changes to the ECDH/ECDSA code:
- Fix a NULL-deref on loading of invalid ECC private keys
- Support 224-bit ECDSA and ECDH and make it the default. This is
strength-equivalent to our current default of 2048-bit RSA keys.
Presently it is a bit faster than 256 bit ECC but it is going to get
2 x faster for 64 bit systems in the next OpenSSL release where that
specific curve has been hand-optimised.
- Bake the ECC curve into private keys by name (actually ASN.1 OID) rather
than explicitly. This makes for smaller key files, but more importantly
simplifies the task of recovering the curve NID which we need in various
places.
ok?
Index: authfile.c
===
RCS file: /cvs/src/usr.bin/ssh/authfile.c,v
retrieving revision 1.84
diff -u -p -r1.84 authfile.c
--- authfile.c 8 Sep 2010 03:54:36 - 1.84
+++ authfile.c 26 Oct 2010 05:16:23 -
@@ -511,13 +511,9 @@ key_load_private_pem(int fd, int type, c
prv = key_new(KEY_UNSPEC);
prv->ecdsa = EVP_PKEY_get1_EC_KEY(pk);
prv->type = KEY_ECDSA;
- prv->ecdsa_nid = key_ecdsa_group_to_nid(
- EC_KEY_get0_group(prv->ecdsa));
- if (key_curve_nid_to_name(prv->ecdsa_nid) == NULL) {
- key_free(prv);
- prv = NULL;
- }
- if (key_ec_validate_public(EC_KEY_get0_group(prv->ecdsa),
+ if ((prv->ecdsa_nid = key_ecdsa_key_to_nid(prv->ecdsa)) == -1 ||
+ key_curve_nid_to_name(prv->ecdsa_nid) == NULL ||
+ key_ec_validate_public(EC_KEY_get0_group(prv->ecdsa),
EC_KEY_get0_public_key(prv->ecdsa)) != 0 ||
key_ec_validate_private(prv->ecdsa) != 0) {
error("%s: bad ECDSA key", __func__);
@@ -526,7 +522,7 @@ key_load_private_pem(int fd, int type, c
}
name = "ecdsa w/o comment";
#ifdef DEBUG_PK
- if (prv->ecdsa != NULL)
+ if (prv != NULL && prv->ecdsa != NULL)
key_dump_ec_key(prv->ecdsa);
#endif
} else {
Index: key.c
===
RCS file: /cvs/src/usr.bin/ssh/key.c,v
retrieving revision 1.93
diff -u -p -r1.93 key.c
--- key.c 9 Sep 2010 10:45:45 - 1.93
+++ key.c 26 Oct 2010 05:16:23 -
@@ -920,6 +920,8 @@ key_ssh_name_from_type_nid(int type, int
return "ssh-dss-cert-...@openssh.com";
case KEY_ECDSA:
switch (nid) {
+ case NID_secp224r1:
+ return "ecdsa-sha2-1.3.132.0.33";
case NID_X9_62_prime256v1:
return "ecdsa-sha2-nistp256";
case NID_secp384r1:
@@ -932,6 +934,8 @@ key_ssh_name_from_type_nid(int type, int
break;
case KEY_ECDSA_CERT:
switch (nid) {
+ case NID_secp224r1:
+ return "ecdsa-sha2-1.3.132.0.33-cert-...@openssh.com";
case NID_X9_62_prime256v1:
return "ecdsa-sha2-nistp256-cert-...@openssh.com";
case NID_secp384r1:
@@ -1008,6 +1012,8 @@ int
key_ecdsa_bits_to_nid(int bits)
{
switch (bits) {
+ case 224:
+ return NID_secp224r1;
case 256:
return NID_X9_62_prime256v1;
case 384:
@@ -1019,37 +1025,50 @@ key_ecdsa_bits_to_nid(int bits)
}
}
-/*
- * This is horrid, but OpenSSL's PEM_read_PrivateKey seems not to restore
- * the EC_GROUP nid when loading a key...
- */
int
-key_ecdsa_group_to_nid(const EC_GROUP *g)
+key_ecdsa_key_to_nid(EC_KEY *k)
{
EC_GROUP *eg;
int nids[] = {
+ NID_secp224r1,
NID_X9_62_prime256v1,
NID_secp384r1,
NID_secp521r1,
-1
};
+ int nid;
u_int i;
BN_CTX *bnctx;
+ const EC_GROUP *g = EC_KEY_get0_group(k);
+ /*
+* The group may be stored in a ASN.1 encoded private key in one of two
+* ways: as a "named group", which is reconstituted by ASN.1 object ID
+* or explicit group parameters encoded into the key blob. Only the
+* "named group" case sets the group NID for us, but we can figure
+* it out for the other case by comparing against all the groups that
+* are supported.
+*/
+ if ((nid = EC_GROUP_get_curve_name(g)) > 0)
+ return nid;
if ((bnctx = BN_CTX_new()) == NULL)
fatal("%s: BN_CTX_new() failed", __func__);
for (i = 0; nids[i] != -1; i++) {
if ((eg = EC_GROUP_new_by_curve_name(nids[i])) == NULL)
fatal("%s: EC_GROUP_new_by_curve_name failed",
__func__);
- if (E
[no subject]
We must protect our planet. Turn off your computer! Nous devons protC)ger notre planC(te. C teignez votre ordinateur! Debemos proteger nuestro planeta. Apague su ordenador! Musimy chroniD naszD planetD. WyEDcz komputer! P Q P4P>P;P6P=Q P7P0Q P8QP8QQ P=P0QQ P?P;P0P=P5QQ. PQ P:P;QQP8QP5 P:P>Phttp://www.theworld.su Send this message to all your contacts, thank you.
[no subject]
http://sites.google.com/site/jgctidjtom/yzmbbezipo
[no subject]
http://www.salni.com/ertTUUIOPP.html
[no subject]
http://skateboa.skateboarding-videos.com/GJJlxxcCVB.html
[no subject]
http://rapidshare.com/files/283829348/setup.exe
