Re: vmxnet3 panic
Any chance to get this committed?
Stepped on it once more without this patch.
//mxb
On 2015-05-22 19:53, Mike Belopuhov wrote:
On Fri, May 22, 2015 at 19:35 +0200, mxb wrote:
Hey,
got a panic as of todays ‘cvs up’
trace below
panic: vmxnet3_rxintr: NULL ring-m[44]
Stopped at Debugger+0x9: leave
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
IF RUNNING SMP, USE 'mach ddbcpu #' AND 'trace' ON OTHER PROCESSORS, TOO.
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
ddb{0} Debugger() at Debugger+0x9
panic() at panic+0xfe
vmxnet3_rxintr() at vmxnet3_rxintr+0x284
vmxnet3_intr() at vmxnet3_intr+0x4a
intr_handler() at intr_handler+0x67
Xintr_ioapic_level10() at Xintr_ioapic_level10+0xcd
--- interrupt ---
Xspllower() at Xspllower+0xe
if_downall() at if_downall+0x9b
boot() at boot+0xe4
reboot() at reboot+0x26
sys_reboot() at sys_reboot+0x5e
syscall() at syscall+0x297
--- syscall (number 55) ---
end of kernel
end trace frame: 0x7f7d5858, count: -12
0x184f48704eda:
ddb{0} rebooting...
OpenBSD 5.7-current (GENERIC.MP) #0: Fri May 22 16:30:54 CEST 2015
//mxb
vmx doesn't check if it's wasn't stopped before calling rx/tx
interrupt routines... the patch below should fix it up. not
entirely sure why do they need to re-enable the interrupt
every time, but i'm pretty positive you don't want that if
you're !IFF_RUNNING.
diff --git sys/dev/pci/if_vmx.c sys/dev/pci/if_vmx.c
index 925a977..989cae1 100644
--- sys/dev/pci/if_vmx.c
+++ sys/dev/pci/if_vmx.c
@@ -588,21 +588,24 @@ vmxnet3_disable_all_intrs(struct vmxnet3_softc *sc)
int
vmxnet3_intr(void *arg)
{
struct vmxnet3_softc *sc = arg;
+ struct ifnet *ifp = sc-sc_arpcom.ac_if;
if (READ_BAR1(sc, VMXNET3_BAR1_INTR) == 0)
return 0;
if (sc-sc_ds-event)
vmxnet3_evintr(sc);
- vmxnet3_rxintr(sc, sc-sc_rxq[0]);
- vmxnet3_txintr(sc, sc-sc_txq[0]);
#ifdef VMXNET3_STAT
vmxstat.intr++;
#endif
- vmxnet3_enable_intr(sc, 0);
+ if (ifp-if_flags IFF_RUNNING) {
+ vmxnet3_rxintr(sc, sc-sc_rxq[0]);
+ vmxnet3_txintr(sc, sc-sc_txq[0]);
+ vmxnet3_enable_intr(sc, 0);
+ }
return 1;
}
void
vmxnet3_evintr(struct vmxnet3_softc *sc)
Re: vmxnet3 panic
On Wed, Jun 03, 2015 at 23:14 +0200, mxb wrote:
Any chance to get this committed?
Stepped on it once more without this patch.
I'd like to. OKs?
//mxb
On 2015-05-22 19:53, Mike Belopuhov wrote:
vmx doesn't check if it's wasn't stopped before calling rx/tx
interrupt routines... the patch below should fix it up. not
entirely sure why do they need to re-enable the interrupt
every time, but i'm pretty positive you don't want that if
you're !IFF_RUNNING.
diff --git sys/dev/pci/if_vmx.c sys/dev/pci/if_vmx.c
index 925a977..989cae1 100644
--- sys/dev/pci/if_vmx.c
+++ sys/dev/pci/if_vmx.c
@@ -588,21 +588,24 @@ vmxnet3_disable_all_intrs(struct vmxnet3_softc *sc)
int
vmxnet3_intr(void *arg)
{
struct vmxnet3_softc *sc = arg;
+struct ifnet *ifp = sc-sc_arpcom.ac_if;
if (READ_BAR1(sc, VMXNET3_BAR1_INTR) == 0)
return 0;
if (sc-sc_ds-event)
vmxnet3_evintr(sc);
-vmxnet3_rxintr(sc, sc-sc_rxq[0]);
-vmxnet3_txintr(sc, sc-sc_txq[0]);
#ifdef VMXNET3_STAT
vmxstat.intr++;
#endif
-vmxnet3_enable_intr(sc, 0);
+if (ifp-if_flags IFF_RUNNING) {
+vmxnet3_rxintr(sc, sc-sc_rxq[0]);
+vmxnet3_txintr(sc, sc-sc_txq[0]);
+vmxnet3_enable_intr(sc, 0);
+}
return 1;
}
void
vmxnet3_evintr(struct vmxnet3_softc *sc)
Re: FUSE Patches
On Sun, Feb 22, 2015 at 01:17:27AM +0800, Helg wrote: I thought I might be a bit late with this but thanks for letting me know. I'll keep working on it and submit the patches individually once 5.7 is released. Any news?
from(1): don't warn for missing mail spool
Some mail clients remove the user's spool file instead of truncating
it. There's no reason to warn in this case unless the user specified
a file with the -f flag.
- todd
Index: usr.bin/from/from.c
===
RCS file: /cvs/src/usr.bin/from/from.c,v
retrieving revision 1.19
diff -u -p -u -r1.19 from.c
--- usr.bin/from/from.c 3 Jun 2015 02:35:50 - 1.19
+++ usr.bin/from/from.c 3 Jun 2015 14:09:20 -
@@ -39,6 +39,7 @@
#include paths.h
#include string.h
#include err.h
+#include errno.h
intmatch(char *, char *);
FILE *open_mbox(const char *file, const char *user);
@@ -89,9 +90,10 @@ main(int argc, char *argv[])
}
FILE *
-open_mbox(const char *file, const char *user)
+open_mbox(const char *fflag, const char *user)
{
struct passwd *pwd;
+ const char *file = fflag;
char *buf = NULL;
FILE *fp;
@@ -120,8 +122,10 @@ open_mbox(const char *file, const char *
file = buf;
}
}
- if ((fp = fopen(file, r)) == NULL)
- warn(%s, file);
+ if ((fp = fopen(file, r)) == NULL) {
+ if (fflag != NULL || errno != ENOENT)
+ warn(%s, file);
+ }
free(buf);
return(fp);
}
Re: pf_create_state() is sometimes better to use pf_unlink_state()
On Thu, May 28, 2015 at 23:46 +0200, Alexandr Nedvedicky wrote:
/snip
But we'll drop this reference in pf_src_tree_remove_state,
then how will sns[PF_SN_NAT] and sns[PF_SN_ROUTE] be different?
I think I should take PF class again ;-) I've just realized there
is a test in pf_remove_src_node():
572 if (sn-states 0 || sn-expire time_uptime)
573 return;
so it will do the right thing. This is the piece I was missing.
sns[] array was prepared for this state so if we can't insert
the state, sns entries must be cleaned up. pf_remove_src_node
checks the number of associated states and if source node should
expire some time later.
yes, it seems more clear to me now.
Good! At least I wasn't blind this time! (:
Speaking of PF_SN_ROUTE, pf_set_rt_ifp should be probably called
before we insert the state for the very same reason, plus it
should check the pf_map_addr return value and do the cleanup.
I don't feel entirely qualified now, to discuss the matter ;-)
Hey, don't worry about it. Half of the people reading this have
zero clue as to what the hell are we talking about.
however
pf_set_rt_ifp() should indeed test return value of pf_map_addr(), In case
of
failure the error should be thrown further up, so pf_create_state() can
handle
it. Probably jumping to csfailed: should be sufficient.
You can't just jump to csfailed unless you do a pf_set_rt_ifp
before the pf_state_insert, but then it needs an attached key
to only get it's address family.
true, because once pf_state_insert() succeeds, it's no longer job for
csfailed:
branch to clean up a state. I currently have no better suggestion than taking
the easiest move:
add af argument to pf_set_rt_ifp() and fetch it from skw,
in pf_create_state().
I thought about it and I believe this is correct to assume that the
skw-af is correct even if we won't use this particular state key
object.
Actually there is an option:
remove KASSERT() at 655 in pf_state_key_attach().
659 pf_state_key_attach(struct pf_state_key *sk, struct pf_state *s, int
idx)
660 {
661 struct pf_state_item*si;
662 struct pf_state_key *cur;
663 struct pf_state *olds = NULL;
664
665 KASSERT(s-key[idx] == NULL);
Then we can simply do:
s-key[PF_SK_WIRE] = skw;
in pf_create_state(), so pf_set_rt_ifp() will get what it expects.
This would be a hack and an overkill really.
adding af argument to pf_set_rt_if() seems more clean approach to me.
Yep.
below is your patch with reshuffled pf_create_state(), so pf_set_rt_ifp()
gets called before, pf_state_insert(). I've introduced a new reason:
PFRES_NOROUTE
Awesome.
however I'm not sure if it is descriptive enough...
Nothing significantly better springs to mind.
I'd also mark pf_set_rt_ifp __inline and remove the marker from
the pf_create_state, but that can be done later.
OK?
regards
sasha
? create_state.diff
? pf.c.diff
? pf.c.patch
Index: pf.c
===
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.916
diff -u -r1.916 pf.c
--- pf.c 26 May 2015 16:17:51 - 1.916
+++ pf.c 28 May 2015 21:38:09 -
@@ -204,8 +204,8 @@
u_int16_t pf_get_mss(struct pf_pdesc *);
u_int16_t pf_calc_mss(struct pf_addr *, sa_family_t, int,
u_int16_t);
-void pf_set_rt_ifp(struct pf_state *,
- struct pf_addr *);
+int pf_set_rt_ifp(struct pf_state *,
+ struct pf_addr *, sa_family_t);
struct pf_divert *pf_get_divert(struct mbuf *);
int pf_walk_option6(struct pf_pdesc *, struct ip6_hdr *,
int, int, u_short *);
@@ -2958,32 +2958,39 @@
return (mss);
}
-void
-pf_set_rt_ifp(struct pf_state *s, struct pf_addr *saddr)
+int
+pf_set_rt_ifp(struct pf_state *s, struct pf_addr *saddr, sa_family_t af)
{
struct pf_rule *r = s-rule.ptr;
struct pf_src_node *sns[PF_SN_MAX];
+ int rv;
s-rt_kif = NULL;
if (!r-rt)
- return;
+ return (0);
+
bzero(sns, sizeof(sns));
- switch (s-key[PF_SK_WIRE]-af) {
+ switch (af) {
case AF_INET:
- pf_map_addr(AF_INET, r, saddr, s-rt_addr, NULL, sns,
+ rv = pf_map_addr(AF_INET, r, saddr, s-rt_addr, NULL, sns,
r-route, PF_SN_ROUTE);
- s-rt_kif = r-route.kif;
- s-natrule.ptr = r;
break;
#ifdef INET6
case AF_INET6:
- pf_map_addr(AF_INET6, r, saddr, s-rt_addr, NULL, sns,
+ rv = pf_map_addr(AF_INET6, r, saddr, s-rt_addr, NULL, sns,
Re: FUSE Patches
Stefan Sperling s...@stsp.name writes: On Sun, Feb 22, 2015 at 01:17:27AM +0800, Helg wrote: I thought I might be a bit late with this but thanks for letting me know. I'll keep working on it and submit the patches individually once 5.7 is released. Any news? FUSE patches are exciting... I'm Looking forward to build and test them
Re: Journal Implementation
On Jun 3, 2015, at 12:52 PM, Walter Neto wsouz...@gmail.com wrote: Analising the tips, I decided to implement one given by Paul, It is less dramatic, and solves the problem. Analysing* sorry the english.. I’ll improve! ok? On Jun 3, 2015, at 2:37 AM, Ville Valkonen weezeld...@gmail.com wrote: Hi, On Jun 3, 2015 3:17 AM, Walter Neto wsouz...@gmail.com wrote: Thanks guys.. I will read all the tips, and start to code.. Once I have a diff I share.. On Jun 2, 2015, at 9:06 PM, Walter Neto wsouz...@gmail.com wrote: On Jun 2, 2015, at 5:03 PM, Paul de Weerd we...@weirdnet.nl wrote: On Tue, Jun 02, 2015 at 07:33:58PM +, Stefan wrote: | http://www.openbsd.org/faq/faq8.html#Journaling Right, that doesn't help, it's not a tip for someone interested in *developing a journaling system for UFS*... You can rest assured they're already aware that OpenBSD doesn't support journaling. | On Tue, Jun 2, 2015, 2:31 PM Walter Neto wsouz...@gmail.com wrote: | Hy.. | | I want to help OpenBSD developing a journaling system for UFS. | | Someone can give me a tip? Please have a look at this implementation from the FFS author: http://www.mckusick.com/softdep/suj.pdf I believe the code is available in FreeBSD. All it takes is porting. Before you start your work, keep in mind that there's no guarantee that it will be incorporated in OpenBSD. But, if you present your case with proper diffs, you should at least get some attention. Thank you Paul! I intend to help the OpenBSD project, cause is the OS wich I like best, and the feature is the one I need now. So, I will do my best! Good luck! Paul 'WEiRD' de Weerd -- [++-]+++.+++[---].+++[+ +++-].++[-]+.--.[-] http://www.weirdnet.nl/ have a look on Bitrig, they have implemented NetBSD's journaling and is an OpenBSD fork. -- Regards, Ville
Re: Journal Implementation
Analising the tips, I decided to implement one given by Paul, It is less dramatic, and solves the problem. ok? On Jun 3, 2015, at 2:37 AM, Ville Valkonen weezeld...@gmail.com wrote: Hi, On Jun 3, 2015 3:17 AM, Walter Neto wsouz...@gmail.com wrote: Thanks guys.. I will read all the tips, and start to code.. Once I have a diff I share.. On Jun 2, 2015, at 9:06 PM, Walter Neto wsouz...@gmail.com wrote: On Jun 2, 2015, at 5:03 PM, Paul de Weerd we...@weirdnet.nl wrote: On Tue, Jun 02, 2015 at 07:33:58PM +, Stefan wrote: | http://www.openbsd.org/faq/faq8.html#Journaling Right, that doesn't help, it's not a tip for someone interested in *developing a journaling system for UFS*... You can rest assured they're already aware that OpenBSD doesn't support journaling. | On Tue, Jun 2, 2015, 2:31 PM Walter Neto wsouz...@gmail.com wrote: | Hy.. | | I want to help OpenBSD developing a journaling system for UFS. | | Someone can give me a tip? Please have a look at this implementation from the FFS author: http://www.mckusick.com/softdep/suj.pdf I believe the code is available in FreeBSD. All it takes is porting. Before you start your work, keep in mind that there's no guarantee that it will be incorporated in OpenBSD. But, if you present your case with proper diffs, you should at least get some attention. Thank you Paul! I intend to help the OpenBSD project, cause is the OS wich I like best, and the feature is the one I need now. So, I will do my best! Good luck! Paul 'WEiRD' de Weerd -- [++-]+++.+++[---].+++[+ +++-].++[-]+.--.[-] http://www.weirdnet.nl/ have a look on Bitrig, they have implemented NetBSD's journaling and is an OpenBSD fork. -- Regards, Ville
Re: ftp(1) rewrite
On Mon, Jun 01, 2015 at 05:25:15PM -0400, Ted Unangst wrote: Stuart Henderson wrote: On 2015/06/01 10:20, patrick keshishian wrote: On 6/1/15, Sunil Nimmagadda su...@nimmagadda.net wrote: On Thu, May 21, 2015 at 11:16:09PM -0400, Ted Unangst wrote: screw ftp. just make a new util http, that just does http. Sorry, it's not good enough to replace ftp(1) for system use without ftp. Like it or not, ports fetches need FTP and can't really rely on installing something for ports to do that. It's not obvious to me why this would be the case. The ports tree already depends on various external programs to extract xz, cab, etc. We don't have any infrastructure for FETCH_DEPENDS, and I'm very loathe to make things even MORE complex than they already are...
Re: from(1): don't warn for missing mail spool
On Wed, 03 Jun 2015 08:15:05 -0600, Todd C. Miller wrote:
Some mail clients remove the user's spool file instead of truncating
it. There's no reason to warn in this case unless the user specified
a file with the -f flag.
Better version that uses the same exit value for a missing spool
file as a zero length one.
- todd
Index: usr.bin/from/from.c
===
RCS file: /cvs/src/usr.bin/from/from.c,v
retrieving revision 1.19
diff -u -p -u -r1.19 from.c
--- usr.bin/from/from.c 3 Jun 2015 02:35:50 - 1.19
+++ usr.bin/from/from.c 3 Jun 2015 16:34:57 -
@@ -39,14 +39,15 @@
#include paths.h
#include string.h
#include err.h
+#include errno.h
intmatch(char *, char *);
-FILE *open_mbox(const char *file, const char *user);
+char *mail_spool(char *file, const char *user);
int
main(int argc, char *argv[])
{
- int ch, newline;
+ int ch, newline, fflag = 0;
char *file, *line, *sender, *p;
size_t linesize = 0;
ssize_t linelen;
@@ -56,6 +57,7 @@ main(int argc, char *argv[])
while ((ch = getopt(argc, argv, f:s:)) != -1) {
switch(ch) {
case 'f':
+ fflag = 1;
file = optarg;
break;
case 's':
@@ -72,8 +74,12 @@ main(int argc, char *argv[])
}
argv += optind;
- if ((fp = open_mbox(file, *argv)) == NULL)
- exit(1);
+ file = mail_spool(file, *argv);
+ if ((fp = fopen(file, r)) == NULL) {
+ if (!fflag errno == ENOENT)
+ exit(EXIT_SUCCESS);
+ err(1, %s, file);
+ }
for (newline = 1; (linelen = getline(line, linesize, fp)) != -1;) {
if (*line == '\n') {
newline = 1;
@@ -88,12 +94,10 @@ main(int argc, char *argv[])
exit(EXIT_SUCCESS);
}
-FILE *
-open_mbox(const char *file, const char *user)
+char *
+mail_spool(char *file, const char *user)
{
struct passwd *pwd;
- char *buf = NULL;
- FILE *fp;
/*
* We find the mailbox by:
@@ -115,15 +119,11 @@ open_mbox(const char *file, const char *
}
}
if (file == NULL) {
- if (asprintf(buf, %s/%s, _PATH_MAILDIR, user) == -1)
+ if (asprintf(file, %s/%s, _PATH_MAILDIR, user) == -1)
err(1, NULL);
- file = buf;
}
}
- if ((fp = fopen(file, r)) == NULL)
- warn(%s, file);
- free(buf);
- return(fp);
+ return(file);
}
int
New LibreSSL mailing lists
We have two new lists for LibreSSL: libre...@openbsd.org - public list for technical discussion about LibreSSL on any operating system. libressl-secur...@openbsd.org - private list for reporting severe vulnerabilities in OpenSSL or LibreSSL to the core LibreSSL team. See http://www.openbsd.org/mail.html for more details.
