On Tue, Jul 27, 2021 at 12:30:06AM +0300, Vitaliy Makkoveev wrote: > > The diff below makes pipex(4) a little bit more parallelization > > reliable.
> > @@ -2238,10 +2240,6 @@ pipex_mppe_input(struct mbuf *m0, struct > > coher_cnt &= PIPEX_COHERENCY_CNT_MASK; > > pktloss = 0; > > > > - PIPEX_MPPE_DBG((session, LOG_DEBUG, "in coher_cnt=%03x %s%s", > > - mppe->coher_cnt, (flushed) ? "[flushed]" : "", > > - (encrypt) ? "[encrypt]" : "")); > > - > > if (encrypt == 0) { > > pipex_session_log(session, LOG_DEBUG, > > "Received unexpected MPPE packet.(no ecrypt)"); > > @@ -2251,6 +2249,12 @@ pipex_mppe_input(struct mbuf *m0, struct > > /* adjust mbuf */ > > m_adj(m0, sizeof(coher_cnt)); > > > > + mtx_enter(&mppe->pxm_mtx); > > + > > + PIPEX_MPPE_DBG((session, LOG_DEBUG, "in coher_cnt=%03x %s%s", > > + mppe->coher_cnt, (flushed) ? "[flushed]" : "", > > + (encrypt) ? "[encrypt]" : "")); > > + Is is really necessary to move the debug print? encrypt is always 0 now. I guess the author of this line also wanted to see the messages with encrypt == 1. It is only a reading access to mppe->coher_cnt in a debug print that is not MP safe. > > + mtx_enter(&session->pxs_mtx); > > + ccp_id=session->ccp_id; > > + session->ccp_id++; > > + mtx_leave(&session->pxs_mtx); ccp_id=session->ccp_id, there must be spaces around = > > int16_t stateless:1, /* [I] key change mode */ > > - resetreq:1, /* [N] */ > > + resetreq:1, /* [m] */ > > reserved:14; Can we have differnet locks on bit fields? I thought the minimum granulatrity of locked access is an int. anyway OK bluhm@