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@
