<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/include/linux, branch v3.18.51</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v3.18.51</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v3.18.51'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2017-04-30T03:49:15+00:00</updated>
<entry>
<title>perf: Avoid horrible stack usage</title>
<updated>2017-04-30T03:49:15+00:00</updated>
<author>
<name>Peter Zijlstra (Intel)</name>
<email>peterz@infradead.org</email>
</author>
<published>2014-12-16T11:47:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=803e3757c40366d673b7792f6ac07793825fafeb'/>
<id>urn:sha1:803e3757c40366d673b7792f6ac07793825fafeb</id>
<content type='text'>
commit 86038c5ea81b519a8a1fcfcd5e4599aab0cdd119 upstream.

Both Linus (most recent) and Steve (a while ago) reported that perf
related callbacks have massive stack bloat.

The problem is that software events need a pt_regs in order to
properly report the event location and unwind stack. And because we
could not assume one was present we allocated one on stack and filled
it with minimal bits required for operation.

Now, pt_regs is quite large, so this is undesirable. Furthermore it
turns out that most sites actually have a pt_regs pointer available,
making this even more onerous, as the stack space is pointless waste.

This patch addresses the problem by observing that software events
have well defined nesting semantics, therefore we can use static
per-cpu storage instead of on-stack.

Linus made the further observation that all but the scheduler callers
of perf_sw_event() have a pt_regs available, so we change the regular
perf_sw_event() to require a valid pt_regs (where it used to be
optional) and add perf_sw_event_sched() for the scheduler.

We have a scheduler specific call instead of a more generic _noregs()
like construct because we can assume non-recursion from the scheduler
and thereby simplify the code further (_noregs would have to put the
recursion context call inline in order to assertain which __perf_regs
element to use).

One last note on the implementation of perf_trace_buf_prepare(); we
allow .regs = NULL for those cases where we already have a pt_regs
pointer available and do not need another.

Reported-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Reported-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Cc: Arnaldo Carvalho de Melo &lt;acme@kernel.org&gt;
Cc: Javi Merino &lt;javi.merino@arm.com&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Mathieu Desnoyers &lt;mathieu.desnoyers@efficios.com&gt;
Cc: Oleg Nesterov &lt;oleg@redhat.com&gt;
Cc: Paul Mackerras &lt;paulus@samba.org&gt;
Cc: Petr Mladek &lt;pmladek@suse.cz&gt;
Cc: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Cc: Tom Zanussi &lt;tom.zanussi@linux.intel.com&gt;
Cc: Vaibhav Nagarnaik &lt;vnagarnaik@google.com&gt;
Link: http://lkml.kernel.org/r/20141216115041.GW3337@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>give up on gcc ilog2() constant optimizations</title>
<updated>2017-04-22T05:15:07+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2017-03-02T20:17:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2143e71aafc634a68d0cf15d6356501f1693c20f'/>
<id>urn:sha1:2143e71aafc634a68d0cf15d6356501f1693c20f</id>
<content type='text'>
commit 474c90156c8dcc2fa815e6716cc9394d7930cb9c upstream.

gcc-7 has an "optimization" pass that completely screws up, and
generates the code expansion for the (impossible) case of calling
ilog2() with a zero constant, even when the code gcc compiles does not
actually have a zero constant.

And we try to generate a compile-time error for anybody doing ilog2() on
a constant where that doesn't make sense (be it zero or negative).  So
now gcc7 will fail the build due to our sanity checking, because it
created that constant-zero case that didn't actually exist in the source
code.

There's a whole long discussion on the kernel mailing about how to work
around this gcc bug.  The gcc people themselevs have discussed their
"feature" in

   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72785

but it's all water under the bridge, because while it looked at one
point like it would be solved by the time gcc7 was released, that was
not to be.

So now we have to deal with this compiler braindamage.

And the only simple approach seems to be to just delete the code that
tries to warn about bad uses of ilog2().

So now "ilog2()" will just return 0 not just for the value 1, but for
any non-positive value too.

It's not like I can recall anybody having ever actually tried to use
this function on any invalid value, but maybe the sanity check just
meant that such code never made it out in public.

Reported-by: Laura Abbott &lt;labbott@redhat.com&gt;
Cc: John Stultz &lt;john.stultz@linaro.org&gt;,
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>KVM: kvm_io_bus_unregister_dev() should never fail</title>
<updated>2017-04-22T05:15:03+00:00</updated>
<author>
<name>David Hildenbrand</name>
<email>david@redhat.com</email>
</author>
<published>2017-03-23T17:24:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=07882feab469f30e8e67b6aa02e2913004dac1da'/>
<id>urn:sha1:07882feab469f30e8e67b6aa02e2913004dac1da</id>
<content type='text'>
commit 90db10434b163e46da413d34db8d0e77404cc645 upstream.

No caller currently checks the return value of
kvm_io_bus_unregister_dev(). This is evil, as all callers silently go on
freeing their device. A stale reference will remain in the io_bus,
getting at least used again, when the iobus gets teared down on
kvm_destroy_vm() - leading to use after free errors.

There is nothing the callers could do, except retrying over and over
again.

So let's simply remove the bus altogether, print an error and make
sure no one can access this broken bus again (returning -ENOMEM on any
attempt to access it).

Fixes: e93f8a0f821e ("KVM: convert io_bus to SRCU")
Reported-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Reviewed-by: Cornelia Huck &lt;cornelia.huck@de.ibm.com&gt;
Signed-off-by: David Hildenbrand &lt;david@redhat.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>usb-core: Add LINEAR_FRAME_INTR_BINTERVAL USB quirk</title>
<updated>2017-04-18T05:55:53+00:00</updated>
<author>
<name>Samuel Thibault</name>
<email>samuel.thibault@ens-lyon.org</email>
</author>
<published>2017-03-13T19:50:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b3f13aba40ef73f86c23c3b3825f953d7d403f69'/>
<id>urn:sha1:b3f13aba40ef73f86c23c3b3825f953d7d403f69</id>
<content type='text'>
commit 3243367b209faed5c320a4e5f9a565ee2a2ba958 upstream.

Some USB 2.0 devices erroneously report millisecond values in
bInterval. The generic config code manages to catch most of them,
but in some cases it's not completely enough.

The case at stake here is a USB 2.0 braille device, which wants to
announce 10ms and thus sets bInterval to 10, but with the USB 2.0
computation that yields to 64ms.  It happens that one can type fast
enough to reach this interval and get the device buffers overflown,
leading to problematic latencies.  The generic config code does not
catch this case because the 64ms is considered a sane enough value.

This change thus adds a USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL quirk
to mark devices which actually report milliseconds in bInterval,
and marks Vario Ultra devices as needing it.

Signed-off-by: Samuel Thibault &lt;samuel.thibault@ens-lyon.org&gt;
Acked-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>libceph: use BUG() instead of BUG_ON(1)</title>
<updated>2017-04-18T05:55:49+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2017-01-16T11:06:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f36055e763e7c930ac9ebc7bada3282980ae9ebb'/>
<id>urn:sha1:f36055e763e7c930ac9ebc7bada3282980ae9ebb</id>
<content type='text'>
commit d24cdcd3e40a6825135498e11c20c7976b9bf545 upstream.

I ran into this compile warning, which is the result of BUG_ON(1)
not always leading to the compiler treating the code path as
unreachable:

    include/linux/ceph/osdmap.h: In function 'ceph_can_shift_osds':
    include/linux/ceph/osdmap.h:62:1: error: control reaches end of non-void function [-Werror=return-type]

Using BUG() here avoids the warning.

Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>nlm: Ensure callback code also checks that the files match</title>
<updated>2017-04-18T05:55:49+00:00</updated>
<author>
<name>Trond Myklebust</name>
<email>trond.myklebust@primarydata.com</email>
</author>
<published>2017-02-11T15:37:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=abf22f568aa653d958786a33971461e1c7444082'/>
<id>urn:sha1:abf22f568aa653d958786a33971461e1c7444082</id>
<content type='text'>
commit 251af29c320d86071664f02c76f0d063a19fefdf upstream.

It is not sufficient to just check that the lock pids match when
granting a callback, we also need to ensure that we're granting
the callback on the right file.

Reported-by: Pankaj Singh &lt;psingh.ait@gmail.com&gt;
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Trond Myklebust &lt;trond.myklebust@primarydata.com&gt;
Signed-off-by: Anna Schumaker &lt;Anna.Schumaker@Netapp.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ipmr, ip6mr: fix scheduling while atomic and a deadlock with ipmr_get_route</title>
<updated>2017-04-18T05:55:46+00:00</updated>
<author>
<name>Nikolay Aleksandrov</name>
<email>nikolay@cumulusnetworks.com</email>
</author>
<published>2016-09-25T21:08:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ad7db1290185be22dfcf13261ffcedd4409abfdb'/>
<id>urn:sha1:ad7db1290185be22dfcf13261ffcedd4409abfdb</id>
<content type='text'>
[ Upstream commit 2cf750704bb6d7ed8c7d732e071dd1bc890ea5e8 ]

Since the commit below the ipmr/ip6mr rtnl_unicast() code uses the portid
instead of the previous dst_pid which was copied from in_skb's portid.
Since the skb is new the portid is 0 at that point so the packets are sent
to the kernel and we get scheduling while atomic or a deadlock (depending
on where it happens) by trying to acquire rtnl two times.
Also since this is RTM_GETROUTE, it can be triggered by a normal user.

Here's the sleeping while atomic trace:
[ 7858.212557] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:620
[ 7858.212748] in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper/0
[ 7858.212881] 2 locks held by swapper/0/0:
[ 7858.213013]  #0:  (((&amp;mrt-&gt;ipmr_expire_timer))){+.-...}, at: [&lt;ffffffff810fbbf5&gt;] call_timer_fn+0x5/0x350
[ 7858.213422]  #1:  (mfc_unres_lock){+.....}, at: [&lt;ffffffff8161e005&gt;] ipmr_expire_process+0x25/0x130
[ 7858.213807] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.0-rc7+ #179
[ 7858.213934] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
[ 7858.214108]  0000000000000000 ffff88005b403c50 ffffffff813a7804 0000000000000000
[ 7858.214412]  ffffffff81a1338e ffff88005b403c78 ffffffff810a4a72 ffffffff81a1338e
[ 7858.214716]  000000000000026c 0000000000000000 ffff88005b403ca8 ffffffff810a4b9f
[ 7858.215251] Call Trace:
[ 7858.215412]  &lt;IRQ&gt;  [&lt;ffffffff813a7804&gt;] dump_stack+0x85/0xc1
[ 7858.215662]  [&lt;ffffffff810a4a72&gt;] ___might_sleep+0x192/0x250
[ 7858.215868]  [&lt;ffffffff810a4b9f&gt;] __might_sleep+0x6f/0x100
[ 7858.216072]  [&lt;ffffffff8165bea3&gt;] mutex_lock_nested+0x33/0x4d0
[ 7858.216279]  [&lt;ffffffff815a7a5f&gt;] ? netlink_lookup+0x25f/0x460
[ 7858.216487]  [&lt;ffffffff8157474b&gt;] rtnetlink_rcv+0x1b/0x40
[ 7858.216687]  [&lt;ffffffff815a9a0c&gt;] netlink_unicast+0x19c/0x260
[ 7858.216900]  [&lt;ffffffff81573c70&gt;] rtnl_unicast+0x20/0x30
[ 7858.217128]  [&lt;ffffffff8161cd39&gt;] ipmr_destroy_unres+0xa9/0xf0
[ 7858.217351]  [&lt;ffffffff8161e06f&gt;] ipmr_expire_process+0x8f/0x130
[ 7858.217581]  [&lt;ffffffff8161dfe0&gt;] ? ipmr_net_init+0x180/0x180
[ 7858.217785]  [&lt;ffffffff8161dfe0&gt;] ? ipmr_net_init+0x180/0x180
[ 7858.217990]  [&lt;ffffffff810fbc95&gt;] call_timer_fn+0xa5/0x350
[ 7858.218192]  [&lt;ffffffff810fbbf5&gt;] ? call_timer_fn+0x5/0x350
[ 7858.218415]  [&lt;ffffffff8161dfe0&gt;] ? ipmr_net_init+0x180/0x180
[ 7858.218656]  [&lt;ffffffff810fde10&gt;] run_timer_softirq+0x260/0x640
[ 7858.218865]  [&lt;ffffffff8166379b&gt;] ? __do_softirq+0xbb/0x54f
[ 7858.219068]  [&lt;ffffffff816637c8&gt;] __do_softirq+0xe8/0x54f
[ 7858.219269]  [&lt;ffffffff8107a948&gt;] irq_exit+0xb8/0xc0
[ 7858.219463]  [&lt;ffffffff81663452&gt;] smp_apic_timer_interrupt+0x42/0x50
[ 7858.219678]  [&lt;ffffffff816625bc&gt;] apic_timer_interrupt+0x8c/0xa0
[ 7858.219897]  &lt;EOI&gt;  [&lt;ffffffff81055f16&gt;] ? native_safe_halt+0x6/0x10
[ 7858.220165]  [&lt;ffffffff810d64dd&gt;] ? trace_hardirqs_on+0xd/0x10
[ 7858.220373]  [&lt;ffffffff810298e3&gt;] default_idle+0x23/0x190
[ 7858.220574]  [&lt;ffffffff8102a20f&gt;] arch_cpu_idle+0xf/0x20
[ 7858.220790]  [&lt;ffffffff810c9f8c&gt;] default_idle_call+0x4c/0x60
[ 7858.221016]  [&lt;ffffffff810ca33b&gt;] cpu_startup_entry+0x39b/0x4d0
[ 7858.221257]  [&lt;ffffffff8164f995&gt;] rest_init+0x135/0x140
[ 7858.221469]  [&lt;ffffffff81f83014&gt;] start_kernel+0x50e/0x51b
[ 7858.221670]  [&lt;ffffffff81f82120&gt;] ? early_idt_handler_array+0x120/0x120
[ 7858.221894]  [&lt;ffffffff81f8243f&gt;] x86_64_start_reservations+0x2a/0x2c
[ 7858.222113]  [&lt;ffffffff81f8257c&gt;] x86_64_start_kernel+0x13b/0x14a

Fixes: 2942e9005056 ("[RTNETLINK]: Use rtnl_unicast() for rtnetlink unicasts")
Signed-off-by: Nikolay Aleksandrov &lt;nikolay@cumulusnetworks.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>pwm: Unexport children before chip removal</title>
<updated>2017-04-18T05:55:45+00:00</updated>
<author>
<name>David Hsu</name>
<email>davidhsu@google.com</email>
</author>
<published>2016-08-09T21:57:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=645545fee15cbab94ebf020278b9426620c2fe2e'/>
<id>urn:sha1:645545fee15cbab94ebf020278b9426620c2fe2e</id>
<content type='text'>
commit 0733424c9ba9f42242409d1ece780777272f7ea1 upstream.

Exported pwm channels aren't removed before the pwmchip and are
leaked. This results in invalid sysfs files. This fix removes
all exported pwm channels before chip removal.

Signed-off-by: David Hsu &lt;davidhsu@google.com&gt;
Fixes: 76abbdde2d95 ("pwm: Add sysfs interface")
Signed-off-by: Thierry Reding &lt;thierry.reding@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>can: Fix kernel panic at security_sock_rcv_skb</title>
<updated>2017-04-18T05:55:43+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2017-01-27T16:11:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2b88a4ce00435637e0af808671bbfdcc7ad89d60'/>
<id>urn:sha1:2b88a4ce00435637e0af808671bbfdcc7ad89d60</id>
<content type='text'>
[ Upstream commit f1712c73714088a7252d276a57126d56c7d37e64 ]

Zhang Yanmin reported crashes [1] and provided a patch adding a
synchronize_rcu() call in can_rx_unregister()

The main problem seems that the sockets themselves are not RCU
protected.

If CAN uses RCU for delivery, then sockets should be freed only after
one RCU grace period.

Recent kernels could use sock_set_flag(sk, SOCK_RCU_FREE), but let's
ease stable backports with the following fix instead.

[1]
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [&lt;ffffffff81495e25&gt;] selinux_socket_sock_rcv_skb+0x65/0x2a0

Call Trace:
 &lt;IRQ&gt;
 [&lt;ffffffff81485d8c&gt;] security_sock_rcv_skb+0x4c/0x60
 [&lt;ffffffff81d55771&gt;] sk_filter+0x41/0x210
 [&lt;ffffffff81d12913&gt;] sock_queue_rcv_skb+0x53/0x3a0
 [&lt;ffffffff81f0a2b3&gt;] raw_rcv+0x2a3/0x3c0
 [&lt;ffffffff81f06eab&gt;] can_rcv_filter+0x12b/0x370
 [&lt;ffffffff81f07af9&gt;] can_receive+0xd9/0x120
 [&lt;ffffffff81f07beb&gt;] can_rcv+0xab/0x100
 [&lt;ffffffff81d362ac&gt;] __netif_receive_skb_core+0xd8c/0x11f0
 [&lt;ffffffff81d36734&gt;] __netif_receive_skb+0x24/0xb0
 [&lt;ffffffff81d37f67&gt;] process_backlog+0x127/0x280
 [&lt;ffffffff81d36f7b&gt;] net_rx_action+0x33b/0x4f0
 [&lt;ffffffff810c88d4&gt;] __do_softirq+0x184/0x440
 [&lt;ffffffff81f9e86c&gt;] do_softirq_own_stack+0x1c/0x30
 &lt;EOI&gt;
 [&lt;ffffffff810c76fb&gt;] do_softirq.part.18+0x3b/0x40
 [&lt;ffffffff810c8bed&gt;] do_softirq+0x1d/0x20
 [&lt;ffffffff81d30085&gt;] netif_rx_ni+0xe5/0x110
 [&lt;ffffffff8199cc87&gt;] slcan_receive_buf+0x507/0x520
 [&lt;ffffffff8167ef7c&gt;] flush_to_ldisc+0x21c/0x230
 [&lt;ffffffff810e3baf&gt;] process_one_work+0x24f/0x670
 [&lt;ffffffff810e44ed&gt;] worker_thread+0x9d/0x6f0
 [&lt;ffffffff810e4450&gt;] ? rescuer_thread+0x480/0x480
 [&lt;ffffffff810ebafc&gt;] kthread+0x12c/0x150
 [&lt;ffffffff81f9ccef&gt;] ret_from_fork+0x3f/0x70

Reported-by: Zhang Yanmin &lt;yanmin.zhang@intel.com&gt;
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Acked-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net:Add sysctl_max_skb_frags</title>
<updated>2017-02-08T08:43:05+00:00</updated>
<author>
<name>Hans Westgaard Ry</name>
<email>hans.westgaard.ry@oracle.com</email>
</author>
<published>2016-02-03T08:26:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=df93393787a3fc3b994c5061a890b0250bae0fbc'/>
<id>urn:sha1:df93393787a3fc3b994c5061a890b0250bae0fbc</id>
<content type='text'>
commit 5f74f82ea34c0da80ea0b49192bb5ea06e063593 upstream.

Devices may have limits on the number of fragments in an skb they support.
Current codebase uses a constant as maximum for number of fragments one
skb can hold and use.
When enabling scatter/gather and running traffic with many small messages
the codebase uses the maximum number of fragments and may thereby violate
the max for certain devices.
The patch introduces a global variable as max number of fragments.

Signed-off-by: Hans Westgaard Ry &lt;hans.westgaard.ry@oracle.com&gt;
Reviewed-by: Håkon Bugge &lt;haakon.bugge@oracle.com&gt;
Acked-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
