lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Mon, 22 Oct 2012 14:05:37 -0700
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Sangho Yi <antiroot@...il.com>
Cc:	devel@...verdev.osuosl.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/4] staging: csr: Fixed indentation from 4 spaces to
 tabs on mlme.c

On Wed, Oct 17, 2012 at 01:36:45AM +0900, Sangho Yi wrote:
> There were all the 4 spaces indentation, so I fixed them using the tabs.
> 
> Signed-off-by: Sangho Yi <antiroot@...il.com>
> ---
>  drivers/staging/csr/mlme.c |  598 ++++++++++++++++++++++----------------------
>  1 file changed, 299 insertions(+), 299 deletions(-)
> 
> diff --git a/drivers/staging/csr/mlme.c b/drivers/staging/csr/mlme.c
> index ed767ec..a16841f 100644
> --- a/drivers/staging/csr/mlme.c
> +++ b/drivers/staging/csr/mlme.c
> @@ -1,9 +1,9 @@
>  /*
>   * ---------------------------------------------------------------------------
> - * FILE:     mlme.c
> + * FILE:	 mlme.c
>   *
>   * PURPOSE:
> - *      This file provides functions to send MLME requests to the UniFi.
> + *	  This file provides functions to send MLME requests to the UniFi.
>   *
>   * Copyright (C) 2007-2008 by Cambridge Silicon Radio Ltd.
>   *
> @@ -19,114 +19,114 @@
>   * ---------------------------------------------------------------------------
>   * unifi_mlme_wait_for_reply
>   *
> - *      Wait for a reply after sending a signal.
> + *	  Wait for a reply after sending a signal.
>   *
>   * Arguments:
> - *      priv            Pointer to device private context struct
> - *      ul_client       Pointer to linux client
> - *      sig_reply_id    ID of the expected reply (defined in sigs.h).
> - *      timeout         timeout in ms
> + *	  priv			Pointer to device private context struct
> + *	  ul_client	   Pointer to linux client
> + *	  sig_reply_id	ID of the expected reply (defined in sigs.h).
> + *	  timeout		 timeout in ms
>   *
>   * Returns:
> - *      0 on success, -ve POSIX code on error.
> + *	  0 on success, -ve POSIX code on error.
>   *
>   * Notes:
> - *      This function waits for a specific (sig_reply_id) signal from UniFi.
> - *      It also match the sequence number of the received (cfm) signal, with
> - *      the latest sequence number of the signal (req) we have sent.
> - *      These two number match be equal.
> - *      Should only be used for waiting xxx.cfm signals and only after
> - *      we have sent the matching xxx.req signal to UniFi.
> - *      If no response is received within the expected time (timeout), we assume
> - *      that the UniFi is busy and return an error.
> - *      If the wait is aborted by a kernel signal arriving, we stop waiting.
> - *      If a response from UniFi is not what we expected, we discard it and
> - *      wait again. This could be a response from an aborted request. If we
> - *      see several bad responses we assume we have lost synchronisation with
> - *      UniFi.
> + *	  This function waits for a specific (sig_reply_id) signal from UniFi.
> + *	  It also match the sequence number of the received (cfm) signal, with
> + *	  the latest sequence number of the signal (req) we have sent.
> + *	  These two number match be equal.
> + *	  Should only be used for waiting xxx.cfm signals and only after
> + *	  we have sent the matching xxx.req signal to UniFi.
> + *	  If no response is received within the expected time (timeout), we assume
> + *	  that the UniFi is busy and return an error.
> + *	  If the wait is aborted by a kernel signal arriving, we stop waiting.
> + *	  If a response from UniFi is not what we expected, we discard it and
> + *	  wait again. This could be a response from an aborted request. If we
> + *	  see several bad responses we assume we have lost synchronisation with
> + *	  UniFi.
>   * ---------------------------------------------------------------------------
>   */
>  static int
>  unifi_mlme_wait_for_reply(unifi_priv_t *priv, ul_client_t *pcli, int sig_reply_id, int timeout)
>  {
> -    int retries = 0;
> -    long r;
> -    long t = timeout;
> -    unsigned int sent_seq_no;
> -
> -    /* Convert t in ms to jiffies */
> -    t = msecs_to_jiffies(t);
> -
> -    do {
> -        /* Wait for the confirm or timeout. */
> -        r = wait_event_interruptible_timeout(pcli->udi_wq,
> -                                             (pcli->wake_up_wq_id) || (priv->io_aborted == 1),
> -                                             t);
> -        /* Check for general i/o error */
> -        if (priv->io_aborted) {
> -            unifi_error(priv, "MLME operation aborted\n");
> -            return -EIO;
> -        }
> -
> -        /*
> -         * If r=0 the request has timed-out.
> -         * If r>0 the request has completed successfully.
> -         * If r=-ERESTARTSYS an event (kill signal) has interrupted the wait_event.
> -         */
> -        if ((r == 0) && (pcli->wake_up_wq_id == 0)) {
> -            unifi_error(priv, "mlme_wait: timed-out waiting for 0x%.4X, after %lu msec.\n",
> -                        sig_reply_id,  jiffies_to_msecs(t));
> -            pcli->wake_up_wq_id = 0;
> -            return -ETIMEDOUT;
> -        } else if (r == -ERESTARTSYS) {
> -            unifi_error(priv, "mlme_wait: waiting for 0x%.4X was aborted.\n", sig_reply_id);
> -            pcli->wake_up_wq_id = 0;
> -            return -EINTR;
> -        } else {
> -            /* Get the sequence number of the signal that we previously set. */
> -            if (pcli->seq_no != 0) {
> -                sent_seq_no = pcli->seq_no - 1;
> -            } else {
> -                sent_seq_no = 0x0F;
> -            }
> -
> -            unifi_trace(priv, UDBG5, "Received 0x%.4X, seq: (r:%d, s:%d)\n",
> -                        pcli->wake_up_wq_id,
> -                        pcli->wake_seq_no, sent_seq_no);
> -
> -            /* The two sequence ids must match. */
> -            if (pcli->wake_seq_no == sent_seq_no) {
> -                /* and the signal ids must match. */
> -                if (sig_reply_id == pcli->wake_up_wq_id) {
> -                    /* Found the expected signal */
> -                    break;
> -                } else {
> -                    /* This should never happen ... */
> -                    unifi_error(priv, "mlme_wait: mismatching signal id (0x%.4X - exp 0x%.4X) (seq %d)\n",
> -                                pcli->wake_up_wq_id,
> -                                sig_reply_id,
> -                                pcli->wake_seq_no);
> -                    pcli->wake_up_wq_id = 0;
> -                    return -EIO;
> -                }
> -            }
> -            /* Wait for the next signal. */
> -            pcli->wake_up_wq_id = 0;
> -
> -            retries ++;
> -            if (retries >= 3) {
> -                unifi_error(priv, "mlme_wait: confirm wait retries exhausted (0x%.4X - exp 0x%.4X)\n",
> -                            pcli->wake_up_wq_id,
> -                            sig_reply_id);
> -                pcli->wake_up_wq_id = 0;
> -                return -EIO;
> -            }
> -        }
> -    } while (1);
> -
> -    pcli->wake_up_wq_id = 0;
> -
> -    return 0;
> +	int retries = 0;
> +	long r;
> +	long t = timeout;
> +	unsigned int sent_seq_no;
> +
> +	/* Convert t in ms to jiffies */
> +	t = msecs_to_jiffies(t);
> +
> +	do {
> +		/* Wait for the confirm or timeout. */
> +		r = wait_event_interruptible_timeout(pcli->udi_wq,
> +											 (pcli->wake_up_wq_id) || (priv->io_aborted == 1),
> +											 t);

What happened there?

Please be smart about your cleanups, you have to do it by hand in
places.

Care to redo this series also and resend it?

thanks,

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ