<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git, branch v3.18.52</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>Linux 3.18.52</title>
<updated>2017-05-08T05:44:29+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2017-05-08T05:44:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=68e50dad01f491a0645b720d6bf5a2f00411fbec'/>
<id>68e50dad01f491a0645b720d6bf5a2f00411fbec</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>dm ioctl: prevent stack leak in dm ioctl call</title>
<updated>2017-05-08T05:44:13+00:00</updated>
<author>
<name>Adrian Salido</name>
<email>salidoa@google.com</email>
</author>
<published>2017-04-27T17:32:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d9684d5c04a6640c463c9531f238b759ff8d41ca'/>
<id>d9684d5c04a6640c463c9531f238b759ff8d41ca</id>
<content type='text'>
commit 4617f564c06117c7d1b611be49521a4430042287 upstream.

When calling a dm ioctl that doesn't process any data
(IOCTL_FLAGS_NO_PARAMS), the contents of the data field in struct
dm_ioctl are left initialized.  Current code is incorrectly extending
the size of data copied back to user, causing the contents of kernel
stack to be leaked to user.  Fix by only copying contents before data
and allow the functions processing the ioctl to override.

Signed-off-by: Adrian Salido &lt;salidoa@google.com&gt;
Reviewed-by: Alasdair G Kergon &lt;agk@redhat.com&gt;
Signed-off-by: Mike Snitzer &lt;snitzer@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 4617f564c06117c7d1b611be49521a4430042287 upstream.

When calling a dm ioctl that doesn't process any data
(IOCTL_FLAGS_NO_PARAMS), the contents of the data field in struct
dm_ioctl are left initialized.  Current code is incorrectly extending
the size of data copied back to user, causing the contents of kernel
stack to be leaked to user.  Fix by only copying contents before data
and allow the functions processing the ioctl to override.

Signed-off-by: Adrian Salido &lt;salidoa@google.com&gt;
Reviewed-by: Alasdair G Kergon &lt;agk@redhat.com&gt;
Signed-off-by: Mike Snitzer &lt;snitzer@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>kbuild: mergeconfig: fix "jobserver unavailable" warning</title>
<updated>2017-05-08T05:44:13+00:00</updated>
<author>
<name>Masahiro Yamada</name>
<email>yamada.masahiro@socionext.com</email>
</author>
<published>2015-03-13T06:21:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a82c4da20443788041c089417b6ae7400af44dcf'/>
<id>a82c4da20443788041c089417b6ae7400af44dcf</id>
<content type='text'>
commit de4619937229378e81f95e99c9866acc8e207d34 upstream.

If "make kvmconfig" is run with "-j" option, a warning message,
"jobserver unavailable: using -j1.  Add `+' to parent make rule.",
is displayed.

  $ make -s defconfig
  *** Default configuration is based on 'x86_64_defconfig'
  #
  # configuration written to .config
  #
  $ make -j8 kvmconfig
  Using ./.config as base
  Merging ./arch/x86/configs/kvm_guest.config
    [ snip ]
  #
  # merged configuration written to ./.config (needs make)
  #
  make[2]: warning: jobserver unavailable: using -j1.  Add `+' to
  parent make rule.
  scripts/kconfig/conf --oldconfig Kconfig
    [ snip ]
  #
  # configuration written to .config
  #

Signed-off-by: Masahiro Yamada &lt;yamada.masahiro@socionext.com&gt;
Reviewed-by: Josh Triplett &lt;josh@joshtriplett.org&gt;
Reviewed-by: Darren Hart &lt;dvhart@linux.intel.com&gt;
Signed-off-by: Michal Marek &lt;mmarek@suse.cz&gt;
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit de4619937229378e81f95e99c9866acc8e207d34 upstream.

If "make kvmconfig" is run with "-j" option, a warning message,
"jobserver unavailable: using -j1.  Add `+' to parent make rule.",
is displayed.

  $ make -s defconfig
  *** Default configuration is based on 'x86_64_defconfig'
  #
  # configuration written to .config
  #
  $ make -j8 kvmconfig
  Using ./.config as base
  Merging ./arch/x86/configs/kvm_guest.config
    [ snip ]
  #
  # merged configuration written to ./.config (needs make)
  #
  make[2]: warning: jobserver unavailable: using -j1.  Add `+' to
  parent make rule.
  scripts/kconfig/conf --oldconfig Kconfig
    [ snip ]
  #
  # configuration written to .config
  #

Signed-off-by: Masahiro Yamada &lt;yamada.masahiro@socionext.com&gt;
Reviewed-by: Josh Triplett &lt;josh@joshtriplett.org&gt;
Reviewed-by: Darren Hart &lt;dvhart@linux.intel.com&gt;
Signed-off-by: Michal Marek &lt;mmarek@suse.cz&gt;
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>gfs2: remove IS_ERR_VALUE abuse</title>
<updated>2017-05-08T05:44:12+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2017-05-05T11:57:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=12bf6fbc9c1792ffb321035a6b94960db6c5ded7'/>
<id>12bf6fbc9c1792ffb321035a6b94960db6c5ded7</id>
<content type='text'>
Picked from commit 287980e49ffc0f6d911601e7e352a812ed27768e ("remove lots
of IS_ERR_VALUE abuses") upstream.

The original fix that was backported to 3.18 already addressed the warning
in some configurations, but not in others, leaving us with the same output:

../fs/gfs2/dir.c: In function 'get_first_leaf':
../fs/gfs2/dir.c:768:9: warning: 'leaf_no' may be used uninitialized in this function [-Wmaybe-uninitialized]
   error = get_leaf(dip, leaf_no, bh_out);
         ^
../fs/gfs2/dir.c: In function 'dir_split_leaf.isra.20':
../fs/gfs2/dir.c:987:8: warning: 'leaf_no' may be used uninitialized in this function [-Wmaybe-uninitialized]

This takes the approach that we took in later versions in mainline,
but does not backport the entire patch, as that would be too large
for stable and IIRC caused regressions in other drivers.

Fixes: 9d46d31e9aea ("gfs2: avoid uninitialized variable warning")
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Picked from commit 287980e49ffc0f6d911601e7e352a812ed27768e ("remove lots
of IS_ERR_VALUE abuses") upstream.

The original fix that was backported to 3.18 already addressed the warning
in some configurations, but not in others, leaving us with the same output:

../fs/gfs2/dir.c: In function 'get_first_leaf':
../fs/gfs2/dir.c:768:9: warning: 'leaf_no' may be used uninitialized in this function [-Wmaybe-uninitialized]
   error = get_leaf(dip, leaf_no, bh_out);
         ^
../fs/gfs2/dir.c: In function 'dir_split_leaf.isra.20':
../fs/gfs2/dir.c:987:8: warning: 'leaf_no' may be used uninitialized in this function [-Wmaybe-uninitialized]

This takes the approach that we took in later versions in mainline,
but does not backport the entire patch, as that would be too large
for stable and IIRC caused regressions in other drivers.

Fixes: 9d46d31e9aea ("gfs2: avoid uninitialized variable warning")
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>e1000e: fix call to do_div() to use u64 arg</title>
<updated>2017-05-08T05:44:12+00:00</updated>
<author>
<name>Jeff Kirsher</name>
<email>jeffrey.t.kirsher@intel.com</email>
</author>
<published>2015-05-02T08:20:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8d86ef0c8958e5af95d3cef781bf3d44cbd21fef'/>
<id>8d86ef0c8958e5af95d3cef781bf3d44cbd21fef</id>
<content type='text'>
commit 30544af5483755b11bb5924736e9e0b45ef0644a upstream.

We were using s64 for lat_ns (latency nano-second value) since in
our calculations a negative value could be a resultant.  For negative
values, we then assign lat_ns to be zero, so the value passed to
do_div() was never negative, but do_div() expects the argument type
to be u64, so do a cast to resolve a compile warning seen on
PowerPC.

CC: Yanjiang Jin &lt;yanjiang.jin@windriver.com&gt;
CC: Yanir Lubetkin &lt;yanirx.lubetkin@intel.com&gt;
Reported-by: Yanjiang Jin &lt;yanjiang.jin@windriver.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Tested-by: Aaron Brown &lt;aaron.f.brown@intel.com&gt;
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 30544af5483755b11bb5924736e9e0b45ef0644a upstream.

We were using s64 for lat_ns (latency nano-second value) since in
our calculations a negative value could be a resultant.  For negative
values, we then assign lat_ns to be zero, so the value passed to
do_div() was never negative, but do_div() expects the argument type
to be u64, so do a cast to resolve a compile warning seen on
PowerPC.

CC: Yanjiang Jin &lt;yanjiang.jin@windriver.com&gt;
CC: Yanir Lubetkin &lt;yanirx.lubetkin@intel.com&gt;
Reported-by: Yanjiang Jin &lt;yanjiang.jin@windriver.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Tested-by: Aaron Brown &lt;aaron.f.brown@intel.com&gt;
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>cpumask_set_cpu_local_first =&gt; cpumask_local_spread, lament</title>
<updated>2017-05-08T05:44:12+00:00</updated>
<author>
<name>Rusty Russell</name>
<email>rusty@rustcorp.com.au</email>
</author>
<published>2015-05-08T17:44:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=706470a2092a6478edc7e956c6ba20ec0b547057'/>
<id>706470a2092a6478edc7e956c6ba20ec0b547057</id>
<content type='text'>
commit f36963c9d3f6f415732710da3acdd8608a9fa0e5 upstream.

da91309e0a7e (cpumask: Utility function to set n'th cpu...) created a
genuinely weird function.  I never saw it before, it went through DaveM.
(He only does this to make us other maintainers feel better about our own
mistakes.)

cpumask_set_cpu_local_first's purpose is say "I need to spread things
across N online cpus, choose the ones on this numa node first"; you call
it in a loop.

It can fail.  One of the two callers ignores this, the other aborts and
fails the device open.

It can fail in two ways: allocating the off-stack cpumask, or through a
convoluted codepath which AFAICT can only occur if cpu_online_mask
changes.  Which shouldn't happen, because if cpu_online_mask can change
while you call this, it could return a now-offline cpu anyway.

It contains a nonsensical test "!cpumask_of_node(numa_node)".  This was
drawn to my attention by Geert, who said this causes a warning on Sparc.
It sets a single bit in a cpumask instead of returning a cpu number,
because that's what the callers want.

It could be made more efficient by passing the previous cpu rather than
an index, but that would be more invasive to the callers.

[backporting for 3.18: only two callers exist, otherwise no change.
 The same warning shows up for "!cpumask_of_node()", and I thought
 about just addressing the warning, but using the whole fix seemed
 better in the end as one of the two callers also lacks the error
 handling]

Fixes: da91309e0a7e8966d916a74cce42ed170fde06bf
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt; (then rebased)
Tested-by: Amir Vadai &lt;amirv@mellanox.com&gt;
Acked-by: Amir Vadai &lt;amirv@mellanox.com&gt;
Acked-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit f36963c9d3f6f415732710da3acdd8608a9fa0e5 upstream.

da91309e0a7e (cpumask: Utility function to set n'th cpu...) created a
genuinely weird function.  I never saw it before, it went through DaveM.
(He only does this to make us other maintainers feel better about our own
mistakes.)

cpumask_set_cpu_local_first's purpose is say "I need to spread things
across N online cpus, choose the ones on this numa node first"; you call
it in a loop.

It can fail.  One of the two callers ignores this, the other aborts and
fails the device open.

It can fail in two ways: allocating the off-stack cpumask, or through a
convoluted codepath which AFAICT can only occur if cpu_online_mask
changes.  Which shouldn't happen, because if cpu_online_mask can change
while you call this, it could return a now-offline cpu anyway.

It contains a nonsensical test "!cpumask_of_node(numa_node)".  This was
drawn to my attention by Geert, who said this causes a warning on Sparc.
It sets a single bit in a cpumask instead of returning a cpu number,
because that's what the callers want.

It could be made more efficient by passing the previous cpu rather than
an index, but that would be more invasive to the callers.

[backporting for 3.18: only two callers exist, otherwise no change.
 The same warning shows up for "!cpumask_of_node()", and I thought
 about just addressing the warning, but using the whole fix seemed
 better in the end as one of the two callers also lacks the error
 handling]

Fixes: da91309e0a7e8966d916a74cce42ed170fde06bf
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt; (then rebased)
Tested-by: Amir Vadai &lt;amirv@mellanox.com&gt;
Acked-by: Amir Vadai &lt;amirv@mellanox.com&gt;
Acked-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>modpost: don't emit section mismatch warnings for compiler optimizations</title>
<updated>2017-05-08T05:44:12+00:00</updated>
<author>
<name>Paul Gortmaker</name>
<email>paul.gortmaker@windriver.com</email>
</author>
<published>2015-04-20T00:50:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=62011a96b21de60b18b83e2750340f91d369c7e1'/>
<id>62011a96b21de60b18b83e2750340f91d369c7e1</id>
<content type='text'>
commit 4a3893d069b788f3570c19c12d9e986e8e15870f upstream.

Currently an allyesconfig build [gcc-4.9.1] can generate the following:

   WARNING: vmlinux.o(.text.unlikely+0x3864): Section mismatch in
   reference from the function cpumask_empty.constprop.3() to the
   variable .init.data:nmi_ipi_mask

which comes from the cpumask_empty usage in arch/x86/kernel/nmi_selftest.c.

Normally we would not see a symbol entry for cpumask_empty since it is:

	static inline bool cpumask_empty(const struct cpumask *srcp)

however in this case, the variant of the symbol gets emitted when GCC does
constant propagation optimization.

Fix things up so that any locally optimized constprop variants don't warn
when accessing variables that live in the __init sections.

[arnd: adapted text_sections definition to 3.18]

Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 4a3893d069b788f3570c19c12d9e986e8e15870f upstream.

Currently an allyesconfig build [gcc-4.9.1] can generate the following:

   WARNING: vmlinux.o(.text.unlikely+0x3864): Section mismatch in
   reference from the function cpumask_empty.constprop.3() to the
   variable .init.data:nmi_ipi_mask

which comes from the cpumask_empty usage in arch/x86/kernel/nmi_selftest.c.

Normally we would not see a symbol entry for cpumask_empty since it is:

	static inline bool cpumask_empty(const struct cpumask *srcp)

however in this case, the variant of the symbol gets emitted when GCC does
constant propagation optimization.

Fix things up so that any locally optimized constprop variants don't warn
when accessing variables that live in the __init sections.

[arnd: adapted text_sections definition to 3.18]

Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>modpost: expand pattern matching to support substring matches</title>
<updated>2017-05-08T05:44:12+00:00</updated>
<author>
<name>Paul Gortmaker</name>
<email>paul.gortmaker@windriver.com</email>
</author>
<published>2015-04-20T00:50:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0acdf4380cbdc9dbc8d49ee5063295f55873c91b'/>
<id>0acdf4380cbdc9dbc8d49ee5063295f55873c91b</id>
<content type='text'>
commit 09c20c032b0f753969ae778d9783d946f054d7fe upstream.

Currently the match() function supports a leading * to match any
prefix and a trailing * to match any suffix.  However there currently
is not a combination of both that can be used to target matches of
whole families of functions that share a common substring.

Here we expand the *foo and foo* match to also support *foo* with
the goal of targeting compiler generated symbol names that contain
strings like ".constprop." and ".isra."

Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 09c20c032b0f753969ae778d9783d946f054d7fe upstream.

Currently the match() function supports a leading * to match any
prefix and a trailing * to match any suffix.  However there currently
is not a combination of both that can be used to target matches of
whole families of functions that share a common substring.

Here we expand the *foo and foo* match to also support *foo* with
the goal of targeting compiler generated symbol names that contain
strings like ".constprop." and ".isra."

Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>scsi: advansys: remove #warning message</title>
<updated>2017-05-08T05:44:12+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2017-05-05T11:57:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5ef346991a5ec84169456fd71e117c8c62ab6958'/>
<id>5ef346991a5ec84169456fd71e117c8c62ab6958</id>
<content type='text'>
The advansys driver was converted to the proper DMA API in linux-4.2, but
the 3.18-stable kernel still warns about this:

drivers/scsi/advansys.c:71:2: warning: #warning this driver is still not properly converted to the DMA API [-Wcpp]

The warning clearly is not helpful in 3.18 any more, it just clutters up
the build log. This removes the warning instead, and clarifies the
comment above it.

Cc: Hannes Reinecke &lt;hare@suse.de&gt;
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The advansys driver was converted to the proper DMA API in linux-4.2, but
the 3.18-stable kernel still warns about this:

drivers/scsi/advansys.c:71:2: warning: #warning this driver is still not properly converted to the DMA API [-Wcpp]

The warning clearly is not helpful in 3.18 any more, it just clutters up
the build log. This removes the warning instead, and clarifies the
comment above it.

Cc: Hannes Reinecke &lt;hare@suse.de&gt;
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>i2o: hide unsafe ioctl on 64-bit</title>
<updated>2017-05-08T05:44:12+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2017-05-05T19:46:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=85741f9687b7edbae5a7ae113ad4670f2bb9de74'/>
<id>85741f9687b7edbae5a7ae113ad4670f2bb9de74</id>
<content type='text'>
We get a warning about a broken pointer conversion on 64-bit architectures:

drivers/message/i2o/i2o_config.c: In function 'i2o_cfg_passthru':
drivers/message/i2o/i2o_config.c:893:19: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
         (p-&gt;virt, (void __user *)sg[i].addr_bus,
                   ^
drivers/message/i2o/i2o_config.c:953:10: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
         ((void __user *)sg[j].addr_bus, sg_list[j].virt,
          ^

This has clearly never worked right, so we can add an #ifdef around the code.
The driver was moved to staging in linux-4.0 and finally removed in 4.2,
so upstream does not have a fix for it.

The driver originally got this mostly right, though probably by accident.

Fixes: f4c2c15b930b ("[PATCH] Convert i2o to compat_ioctl")
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We get a warning about a broken pointer conversion on 64-bit architectures:

drivers/message/i2o/i2o_config.c: In function 'i2o_cfg_passthru':
drivers/message/i2o/i2o_config.c:893:19: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
         (p-&gt;virt, (void __user *)sg[i].addr_bus,
                   ^
drivers/message/i2o/i2o_config.c:953:10: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
         ((void __user *)sg[j].addr_bus, sg_list[j].virt,
          ^

This has clearly never worked right, so we can add an #ifdef around the code.
The driver was moved to staging in linux-4.0 and finally removed in 4.2,
so upstream does not have a fix for it.

The driver originally got this mostly right, though probably by accident.

Fixes: f4c2c15b930b ("[PATCH] Convert i2o to compat_ioctl")
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
