Skip to content

L
linux
Switch branch/tag
  1. 01 Dec, 2011 8 commits
    • Haiyang Zhang's avatar
      net/hyperv: Fix long lines in netvsc.c · c1813200
      Haiyang Zhang authored 
      Signed-off-by: default avatarHaiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      c1813200
    • Dan Carpenter's avatar
      Staging: line6: NULL dereference in dev_err() · 4bd8b4de
      Dan Carpenter authored 
      "line6" hasn't been set at this point and we should be using
&interface->dev instead.

Gcc would have complained about this if it weren't for the fact that we
initialized line6 to NULL.  I removed the initialization.
Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: default avatarStefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      4bd8b4de
    • K. Y. Srinivasan's avatar
      Staging: hv: mousevsc: Properly add the hid device · f75c0510
      K. Y. Srinivasan authored 
      We need to properly add the hid device to correctly initialize the
sysfs state. While this patch is against the staging tree; Jiri,
please pick up this patch as you merge the Hyper-V mouse driver.
Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: default avatarHaiyang Zhang <haiyangz@microsoft.com>
Reported-by: default avatarFuzhou Chen <fuzhouch@microsoft.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      f75c0510
    • Mathieu Desnoyers's avatar
      staging: lttng: cleanup one-bit signed bitfields · 0dcbcbb4
      Mathieu Desnoyers authored 
      * Dan Carpenter <dan.carpenter@oracle.com> wrote:
> Sparse complains that these signed bitfields look "dubious".  The
> problem is that instead of being either 0 or 1 like people would expect,
> signed one bit variables like this are either 0 or -1.  It doesn't cause
> a problem in this case but it's ugly so lets fix them.

* walter harms (wharms@bfs.de) wrote:
> hi,
> This patch looks ok to me but this design is ugly by itself.
> It should be replaced by an uchar uint whatever or use a
> real bool (obviously not preferred by this programmes).

bool :1, uchar :1 or uint :1 could make sense. uchar:1/bool:1 won't save
any space here, because the surrounding fields are either uint or
pointers, so alignment will just add padding.

I try to use int/uint whenever possible because x86 CPUs tend to get
less register false-dependencies when using instructions modifying the
whole register (generated by using int/uint types) rather than only part
of it (uchar/char/bool). I only use char/uchar/bool when there is a
clear wanted space gain.

The reason why I never use the bool type within a structure when I want
a compact representation is that bool takes a whole byte just to
represent one bit:

struct usebitfield {
    int a;
    unsigned int f:1, g:1, h:1, i:1, j:1;
    int b;
};

struct usebool {
    int a;
    bool f, g, h, i, j;
    int b;
};

struct useboolbf {
    int a;
    bool f:1, g:1, h:1, i:1, j:1;
    int b;
};

int main()
{
    printf("bitfield %d bytes, bool %d bytes, boolbitfield %d bytes\n",
            sizeof(struct usebitfield), sizeof(struct usebool),
            sizeof(struct useboolbf));
}

result:

bitfield 12 bytes, bool 16 bytes, boolbitfield 12 bytes

This is because each bool takes one byte, while the bitfields are put in
units of "unsigned int" (or bool for the 3rd struct). So in this
example, we need 5 bytes + 3 bytes alignment for the bool, but only 4
bytes to hold the "unsigned int" unit for the bitfields.

The choice between bool and bitfields must also take into account the
frequency of access to the variable, because bitfields require mask
operations to access the selected bit(s). You will notice that none of
these bitfields are accessed on the tracing fast-path: only in
slow-paths. Therefore, space gain is more important than speed here.

One might argue that I have so few of these fields here that it does not
make an actual difference to go for bitfield or bool. I am just trying
to choose types best suited for their intended purpose, ensuring they
are future-proof and will allow simply adding more fields using the same
type, as needed.

So I guess I'll go for uint :1.
Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: default avatarMathieu Desnoyers <mathieu.desnoyers@efficios.com>
Acked-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      0dcbcbb4
    • Mathieu Desnoyers's avatar
      lttng wrapper: add missing include to kallsyms wrapper · 91c0a213
      Mathieu Desnoyers authored 
      Needed to keep bissectability.
Signed-off-by: default avatarMathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      91c0a213
    • Mathieu Desnoyers's avatar
      lttng lib: ring buffer move null pointer check to open · eeb34e21
      Mathieu Desnoyers authored 
      * Dan Carpenter <dan.carpenter@oracle.com> wrote:
> The patch c844b2f5: "lttng lib: ring buffer" from Nov 28, 2011,
> leads to the following Smatch complaint:
>
> drivers/staging/lttng/lib/ringbuffer/ring_buffer_mmap.c +86
> +lib_ring_buffer_mmap_buf()
>          warn: variable dereferenced before check 'buf' (see line 79)
>
> drivers/staging/lttng/lib/ringbuffer/ring_buffer_mmap.c
>     78          unsigned long length = vma->vm_end - vma->vm_start;
>     79          struct channel *chan = buf->backend.chan;
>                                        ^^^^^^^^^^^^^^^^^
> Dereference.
>
>     80          const struct lib_ring_buffer_config *config = chan->backend.config;
>     81          unsigned long mmap_buf_len;
>     82
>     83          if (config->output != RING_BUFFER_MMAP)
>     84                  return -EINVAL;
>     85
>     86          if (!buf)
>                     ^^^^
> Check.
>
>     87                  return -EBADF;
>     88

Let's move the NULL buf check to the file "open", where it belongs. The
"open" file operation is the actual interface between lib ring buffer
and the modules using it.
Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: default avatarMathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      eeb34e21
    • Mathieu Desnoyers's avatar
      lttng lib: ring buffer remove duplicate null pointer · e5f77873
      Mathieu Desnoyers authored 
      * Dan Carpenter <dan.carpenter@oracle.com> wrote:
> The patch c844b2f5: "lttng lib: ring buffer" from Nov 28, 2011,
> leads to the following Smatch complaint:
>
> drivers/staging/lttng/lib/ringbuffer/ring_buffer_mmap.c +33
> +lib_ring_buffer_fault()
>          warn: variable dereferenced before check 'buf' (see line 26)
>
> drivers/staging/lttng/lib/ringbuffer/ring_buffer_mmap.c
>     25          struct lib_ring_buffer *buf = vma->vm_private_data;
>     26          struct channel *chan = buf->backend.chan;
>                                        ^^^^^^^^^^^^^^^^^
> Dereference.
>
>     27          const struct lib_ring_buffer_config *config = chan->backend.config;
>     28          pgoff_t pgoff = vmf->pgoff;
>     29          struct page **page;
>     30          void **virt;
>     31          unsigned long offset, sb_bindex;
>     32
>     33          if (!buf)
>                     ^^^^
> Check.
>
>     34                  return VM_FAULT_OOM;
>     35

This check is performed at mapping setup time in
lib_ring_buffer_mmap_buf() already, so we can safely remove this
duplicata.
Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: default avatarMathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      e5f77873
    • Mathieu Desnoyers's avatar
      lttng lib: ring buffer: remove stale null-pointer · 2f8e0b31
      Mathieu Desnoyers authored 
      * Dan Carpenter <dan.carpenter@oracle.com> wrote:
[...]
> The patch c844b2f5: "lttng lib: ring buffer" from Nov 28, 2011,
> leads to the following Smatch complaint:
>
> drivers/staging/lttng/lib/ringbuffer/ring_buffer_frontend.c +1150
> +lib_ring_buffer_print_buffer_errors()
>          warn: variable dereferenced before check 'chan' (see line 1143)
>
> drivers/staging/lttng/lib/ringbuffer/ring_buffer_frontend.c
>   1142  {
>   1143          const struct lib_ring_buffer_config *config =
> +chan->backend.config;
>
> +^^^^^^^^^^^^^^^^^^^^
> Dereference.
>
>   1144          unsigned long write_offset, cons_offset;
>   1145
>   1146          /*
>   1147           * Can be called in the error path of allocation when
>   1148           * trans_channel_data is not yet set.
>   1149           */
>   1150          if (!chan)
>                 ^^^^^^^^^
> Check.  At first glance the comment seems out of date, I think check can
> be removed safely.
>
>   1151                  return;
>   1152          /*
Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: default avatarMathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      2f8e0b31
  3. 30 Nov, 2011 32 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7