lkml.org 
[lkml]   [2006]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 1/2] iWARP Connection Manager.
    Steve Wise wrote:
    >>>+int iw_cm_disconnect(struct iw_cm_id *cm_id, int abrupt)
    >>>+{
    >>>+ struct iwcm_id_private *cm_id_priv;
    >>>+ unsigned long flags;
    >>>+ int ret = 0;
    >>>+
    >>>+ cm_id_priv = container_of(cm_id, struct iwcm_id_private, id);
    >>>+ /* Wait if we're currently in a connect or accept downcall */
    >>>+ wait_event(cm_id_priv->connect_wait,
    >>>+ !test_bit(IWCM_F_CONNECT_WAIT, &cm_id_priv->flags));
    >>
    >>Am I understanding this check correctly? You're checking to see if the user has
    >>called iw_cm_disconnect() at the same time that they called iw_cm_connect() or
    >>iw_cm_accept(). Are connect / accept blocking, or are you just waiting for an
    >>event?
    >
    >
    > The CM must wait for the low level provider to finish a connect() or
    > accept() operation before telling the low level provider to disconnect
    > via modifying the iwarp QP. Regardless of whether they block, this
    > disconnect can happen concurrently with the connect/accept so we need to
    > hold the disconnect until the connect/accept completes.
    >
    >
    >>>+EXPORT_SYMBOL(iw_cm_disconnect);
    >>>+static void destroy_cm_id(struct iw_cm_id *cm_id)
    >>>+{
    >>>+ struct iwcm_id_private *cm_id_priv;
    >>>+ unsigned long flags;
    >>>+ int ret;
    >>>+
    >>>+ cm_id_priv = container_of(cm_id, struct iwcm_id_private, id);
    >>>+ /* Wait if we're currently in a connect or accept downcall. A
    >>>+ * listening endpoint should never block here. */
    >>>+ wait_event(cm_id_priv->connect_wait,
    >>>+ !test_bit(IWCM_F_CONNECT_WAIT, &cm_id_priv->flags));
    >>
    >>Same question/comment as above.
    >>
    >
    >
    > Same answer.

    There's a difference between trying to handle the user calling
    disconnect/destroy at the same time a call to accept/connect is active, versus
    the user calling disconnect/destroy after accept/connect have returned. In the
    latter case, I think you're fine. In the first case, this is allowing a user to
    call destroy at the same time that they're calling accept/connect.
    Additionally, there's no guarantee that the F_CONNECT_WAIT flag has been set by
    accept/connect by the time disconnect/destroy tests it.

    - Sean
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-06-01 23:11    [W:0.027 / U:2.000 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site