On Tue, Feb 28, 2017 at 7:28 PM, Tom Herbert wrote:
> On Tue, Feb 28, 2017 at 3:22 PM, Eric Dumazet wrote:
>> On Tue, 2017-02-28 at 14:52 -0800, Andy Lutomirski wrote:
>>
>>> The user pages are a gift to the kernel. The application may not
>>> modify this memory ever, otherwise the page cache
On Tue, 28 Feb 2017, Bart Van Assche wrote:
> On 02/28/2017 02:23 PM, Joe Perches wrote:
> > On Tue, 2017-02-28 at 15:35 +, Bart Van Assche wrote:
> >> On Tue, 2017-02-28 at 15:02 +0300, Dan Carpenter wrote:
> >>> Bitwise & was obviously intended here.
> > []
> >>> diff --git a/include/linux/m
To allow canceling all packets of a connection.
Reviewed-by: Stefan Hajnoczi
Reviewed-by: Jorgen Hansen
Signed-off-by: Peng Tao
---
drivers/vhost/vsock.c | 41 +
include/net/af_vsock.h | 3 +++
2 files changed, 44 insertions(+)
diff --git a/drivers/vh
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Peng Tao
---
net/vmw_vsock/virtio_transport.c | 42
1 file changed, 42 insertions(+)
diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c
index 6788264..f5c44b5 100644
--- a/net/vmw_
Otherwise we'll leave the packets queued until releasing vsock device.
E.g., if guest is slow to start up, resulting ETIMEDOUT on connect, guest
will get the connect requests from failed host sockets.
Reviewed-by: Stefan Hajnoczi
Reviewed-by: Jorgen Hansen
Signed-off-by: Peng Tao
---
net/vmw_v
Hi David,
These patchsets were sent before and reviewed by Stefan and Jorgen
[https://www.spinics.net/lists/kvm/msg142367.html].
If there is any blocker, please do tell and I'll see to it. Thanks!
Currently, if a connect call fails on a signal or timeout (e.g., guest is still
in the process of s
So that we can cancel a queued pkt later if necessary.
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Peng Tao
---
include/linux/virtio_vsock.h| 2 ++
net/vmw_vsock/virtio_transport_common.c | 7 +++
2 files changed, 9 insertions(+)
diff --git a/include/linux/virtio_vsock.h b/incl
On Tue, 2017-02-28 at 22:28 -0500, David Miller wrote:
> These device are already choking, because as I stated this can already
> be done via sendfile().
>
> Networking card wise this isn't an issue, chips bring the entire packet
> into their FIFO, compute checksums on the fly mid-stream, and the
From: Andy Lutomirski
Date: Tue, 28 Feb 2017 13:06:49 -0800
> On Tue, Feb 28, 2017 at 12:43 PM, Willem de Bruijn
> wrote:
>> On Tue, Feb 28, 2017 at 2:46 PM, Andy Lutomirski wrote:
>>> On Mon, Feb 27, 2017 at 10:57 AM, Michael Kerrisk
>>> wrote:
[CC += linux-...@vger.kernel.org]
From: Andy Lutomirski
Date: Tue, 28 Feb 2017 11:46:23 -0800
> On Mon, Feb 27, 2017 at 10:57 AM, Michael Kerrisk
> wrote:
>> [CC += linux-...@vger.kernel.org]
>>
>> Hi Willem
>>
>
>>> On a send call with MSG_ZEROCOPY, the kernel pins the user pages and
>>> creates skbuff fragments directly from
On Tue, Feb 28, 2017 at 2:46 PM, Alexander Duyck
wrote:
> On Tue, Feb 28, 2017 at 2:32 AM, Davide Caratti wrote:
>> sctp_compute_checksum requires crc32c symbol (provided by libcrc32c), so
>> it can't be used in net core. Like it has been done previously with other
>> symbols (e.g. ipv6_dst_looku
Please add a changelog and mention that this adds IPv6 support.
Will do, thanks!
Fix pch_gbe driver for ethernet operations for a big endian CPU.
Values written to and read from transmit and receive descriptors
in the pch_gbe driver are byte swapped from the perspective of a
big endian CPU, since the ethernet controller always operates in
little endian mode. Rectify this by app
On 2/28/17 3:14 PM, Eric Dumazet wrote:
> On Tue, Feb 28, 2017 at 3:09 PM, David Ahern wrote:
>> On 2/28/17 5:10 AM, Eric Dumazet wrote:
>>> David, rt->rt6i_idev can be NULL.
>>
>> Do you know of an example where rt6i_idev can be NULL - besides the
>> null_entry rt which is null only because of in
On Tue, Feb 28, 2017 at 4:58 PM, Willem de Bruijn
wrote:
> On Tue, Feb 28, 2017 at 7:28 PM, Tom Herbert wrote:
>> On Tue, Feb 28, 2017 at 3:22 PM, Eric Dumazet wrote:
>>> On Tue, 2017-02-28 at 14:52 -0800, Andy Lutomirski wrote:
>>>
The user pages are a gift to the kernel. The application
On Tue, 2017-02-28 at 14:25 -0800, Andy Lutomirski wrote:
> On Tue, Feb 28, 2017 at 1:47 PM, Eric Dumazet wrote:
> > On Tue, 2017-02-28 at 13:09 -0800, Andy Lutomirski wrote:
> >
> >> Does this mean that a user program that does a zerocopy send can cause
> >> a retransmitted segment to contain dif
On Tue, Feb 28, 2017 at 3:22 PM, Eric Dumazet wrote:
> On Tue, 2017-02-28 at 14:52 -0800, Andy Lutomirski wrote:
>
>> The user pages are a gift to the kernel. The application may not
>> modify this memory ever, otherwise the page cache and on-disk data may
>> differ.
>>
>> This is just not okay
On Wed, 1 Mar 2017 01:22:40 +0100
Francois Romieu wrote:
> David Miller :
> > From: Eric Dumazet
> > Date: Mon, 27 Feb 2017 08:44:14 -0800
> >
> > > Any point doing a napi_schedule() not from device hard irq handler
> > > is subject to the race for NIC using some kind of edge trigger
> > > i
On Tue, Feb 28, 2017 at 9:08 AM, Alban Bedel
wrote:
> On DT systems the driver require a clock, but the probe just print a
> warning and continue, leading to a crash when resetting the device.
> To fix this crash and properly handle probe deferals only ignore the
> missing clock if DT isn't used o
David Miller :
> From: Eric Dumazet
> Date: Mon, 27 Feb 2017 08:44:14 -0800
>
> > Any point doing a napi_schedule() not from device hard irq handler
> > is subject to the race for NIC using some kind of edge trigger
> > interrupts.
> >
> > Since we do not provide a ndo to disable device interru
On Tue, 2017-02-28 at 16:28 -0800, Tom Herbert wrote:
> The Mellanox team working on TLS offload pointed out to us that if
> data is changed for a retransmit then it becomes trivial for someone
> snooping to break the encryption. Sounds pretty scary and it would be
> a shame if we couldn't use zer
On 2/28/17 5:10 AM, Eric Dumazet wrote:
> David, rt->rt6i_idev can be NULL.
Do you know of an example where rt6i_idev can be NULL - besides the
null_entry rt which is null only because of init order?
This is a test patch being supplied for a trial run on syzkaller.
Explicitly cancel the workq before releasing resources that
will allow netns deletion, so that the connect request does
not trip up on a use-after free of the netns afterward.
Signed-off-by: Sowmini Varadhan
Reported-by: Dmitry Vy
Actually, I'm not sure if I can assert that these are all manifestations
of the same bug- was a netns-delete involved in this one as well?
I see:
> BUG: KASAN: use-after-free in memcmp+0xe3/0x160 lib/string.c:768 at
:
> memcmp+0xe3/0x160 lib/string.c:768
:
> rds_find_bound+0x4fe/0x8a0
If an SFP module is not present, xgbe_phy_sfp_phy_settings() should
return after applying the default settings. Currently there is no return
statement and the default settings are overwritten.
Signed-off-by: Tom Lendacky
---
drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c |2 ++
1 file changed,
Adjust the impedance values of the RX and TX lanes in the SGMII block
so that they are closer to optimal values.
Signed-off-by: Timur Tabi
---
drivers/net/ethernet/qualcomm/emac/emac-sgmii-qdf2400.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/qualcomm/emac/emac
On Tue, 2017-02-28 at 14:52 -0800, Andy Lutomirski wrote:
> The user pages are a gift to the kernel. The application may not
> modify this memory ever, otherwise the page cache and on-disk data may
> differ.
>
> This is just not okay IMO.
TCP works just fine in this case.
TX checksum will be
On Tue, Feb 28, 2017 at 2:40 PM, Eric Dumazet wrote:
> On Tue, 2017-02-28 at 14:25 -0800, Andy Lutomirski wrote:
>> On Tue, Feb 28, 2017 at 1:47 PM, Eric Dumazet wrote:
>> > On Tue, 2017-02-28 at 13:09 -0800, Andy Lutomirski wrote:
>> >
>> >> Does this mean that a user program that does a zerocop
On Tue, Feb 28, 2017 at 3:09 PM, David Ahern wrote:
> On 2/28/17 5:10 AM, Eric Dumazet wrote:
>> David, rt->rt6i_idev can be NULL.
>
> Do you know of an example where rt6i_idev can be NULL - besides the
> null_entry rt which is null only because of init order?
I might have been mistaken, but man
On Tue, Feb 28, 2017 at 2:32 AM, Davide Caratti wrote:
> sctp_compute_checksum requires crc32c symbol (provided by libcrc32c), so
> it can't be used in net core. Like it has been done previously with other
> symbols (e.g. ipv6_dst_lookup), introduce a stub struct skb_checksum_ops
> to allow comput
Changes in v3:
* Corrected a bug Florian found and added his Reviewed-by
Changes in v2:
* Reworked the PM patch with Florian's suggestions
Add code to support Power Management (only tested on NS2), and add some
code clean-ups
Joey Zhong (1):
net: ethernet: bgmac: driver power manangement
Jo
The maximum frame size is really just the standard ethernet frame size
and FCS. So use those existing defines to make the code a little more
beautiful.
Signed-off-by: Jon Mason
---
drivers/net/ethernet/broadcom/bgmac.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/
On Tue, Feb 28, 2017 at 1:47 PM, Eric Dumazet wrote:
> On Tue, 2017-02-28 at 13:09 -0800, Andy Lutomirski wrote:
>
>> Does this mean that a user program that does a zerocopy send can cause
>> a retransmitted segment to contain different data than the original
>> segment? If so, is that okay?
>
>
On Tue, Feb 21, 2017 at 5:26 PM, Mickaël Salaün wrote:
> The seccomp(2) syscall can be use to apply a Landlock rule to the
> current process. As with a seccomp filter, the Landlock rule is enforced
> for all its future children. An inherited rule tree can be updated
> (append-only) by the owner of
On 02/28/2017 02:23 PM, Joe Perches wrote:
> On Tue, 2017-02-28 at 15:35 +, Bart Van Assche wrote:
>> On Tue, 2017-02-28 at 15:02 +0300, Dan Carpenter wrote:
>>> Bitwise & was obviously intended here.
> []
>>> diff --git a/include/linux/mlx4/driver.h b/include/linux/mlx4/driver.h
> []
>>> @@ -1
The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.
As I don't have the hardware, I'd be very pleased if
someone may test this patch.
Signed-off-by: Philippe Reynes
---
drivers/net/ethernet/smsc/smc911x.c | 51 ++--
On Tue, 2017-02-28 at 15:35 +, Bart Van Assche wrote:
> On Tue, 2017-02-28 at 15:02 +0300, Dan Carpenter wrote:
> > Bitwise & was obviously intended here.
[]
> > diff --git a/include/linux/mlx4/driver.h b/include/linux/mlx4/driver.h
[]
> > @@ -109,7 +109,7 @@ static inline void (u8 *addr,
On 2/28/17 11:48 AM, Cong Wang wrote:
> On Tue, Feb 28, 2017 at 11:01 AM, David Ahern
> wrote:
>> On 2/28/17 10:44 AM, Cong Wang wrote:
>>> Like commit 1f17e2f2c8a8 ("net: ipv6: ignore null_entry on route dumps"),
>>> we need to ignore null entry in inet6_rtm_getroute() too.
>>>
>>> Return -ENOEN
On (03/01/17 00:14), Dmitry Vyukov wrote:
>
> But the other 2 use-after-frees happened on cp->cp_send_w. Shouldn't
> we cancel it as well? And cp_recv_w?
yes, good point, I missed that. let me see if I can refactor the code
to release the netns as the last thing before free..
Logging output was changed when simple printks without KERN_CONT
are now emitted on a new line and KERN_CONT is required to continue
lines so use pr_cont.
Miscellanea:
o realign arguments
o use print_hex_dump instead of a local variant
Signed-off-by: Joe Perches
---
net/bridge/netfilter/ebt_lo
From: Joey Zhong
Implement suspend/resume callbacks in the bgmac driver. This makes sure
that we de-initialize and re-initialize the hardware correctly before
entering suspend and when resuming.
Signed-off-by: Joey Zhong
Signed-off-by: Jon Mason
Reviewed-by: Florian Fainelli
---
drivers/net/
On Tue, 2017-02-28 at 13:09 -0800, Andy Lutomirski wrote:
> Does this mean that a user program that does a zerocopy send can cause
> a retransmitted segment to contain different data than the original
> segment? If so, is that okay?
Same remark applies to sendfile() already, or other zero copy m
Tue, Feb 28, 2017 at 09:19:23PM CET, zaboj.camp...@post.cz wrote:
>On Mon, 2017-02-27 at 10:55 -0800, Stephen Hemminger wrote:
>>
>> Another alternative format would be to make -tree a output modifier and
>> ident (like ps tree options).
>>
>> $ ip -t link
>> 1: lo: mtu 65536 qdisc noqueue stat
This patch series addresses some issues in the AMD XGBE driver.
The following fixes are included in this driver update series:
- Stop the PHY before disabling and releasing device interrupts so that
MDIO requests issued by the device can be properly handled
- Set the MDIO communication mode on
On Tue, Feb 28, 2017 at 12:43 PM, Willem de Bruijn
wrote:
>
>> I can see this working if you have a special type of skb that
>> indicates that the data might be concurrently written and have all the
>> normal skb APIs (including, especially, anything that clones it) make
>> a copy first.
>
> Suppo
>>> I can see this working if you have a special type of skb that
>>> indicates that the data might be concurrently written and have all the
>>> normal skb APIs (including, especially, anything that clones it) make
>>> a copy first.
>>
>> Support for cloned skbs is required for TCP, both at tcp_tra
On Tue, Feb 28, 2017 at 6:03 AM, 颜小波 wrote:
> But I don’t find any rcu_read_lock invoked before travelling fdb_head list.
> In vxlan_xmit and vxlan_snoop function, vxlan_find_mac function is called to
> search the vxlan_fdb of the dst_mac or src_mac. Then information in vxlan_fdb
> is used fo
>> > With this change I'm getting two error messages per transmission, but
>> > it looks like it may need some additional changes.
>> >
>> > If the first error message is received after the HW timestamp was
>> > captured,
>>
>> When does this happen? The first timestamp is generated from
>> skb_tx_
On Wed, Mar 1, 2017 at 12:06 AM, Sowmini Varadhan
wrote:
> Just posted an RFC patch, that I'm also testing here..
> hopefully we'll se the pr_info light up, and know that the problematic
> situation actually happened (I'll remove the pr_info if/when this
> gets submitted as a non-RFC patch).. than
The ethernet support now calls directly into the ipv6 core code, which
fails if IPV6 is a loadable module but mlx5 is built-in:
drivers/net/ethernet/mellanox/mlx5/core/en_tc.o: In function
`mlx5e_create_encap_header_ipv6':
en_tc.c:(.text.mlx5e_create_encap_header_ipv6+0x110): undefined reference
Some configurations require the use of the hardware's MDIO support to
communicate with external PHYs. The MDIO commands indicate completion
through the device interrupt. When bringing down the device the interrupts
were released before stopping the external PHY, resulting in MDIO command
timeouts.
The MDIO register mode is set when the device is probed. But when the
device is brought down and then back up, the MDIO register mode has been
reset. Be sure to reset the mode during device startup and only change
the mode of the address specified.
Signed-off-by: Tom Lendacky
---
drivers/net/et
Hi guys,
Commit a79ca223e029 ('ipv6: fix bad free of addrconf_init_net')
introduced in linux 3.9 tries to fix an issue involving free-ing
statically allocated memory. Additionally, it subtly changes behavior
of how certain ipv6 sysctl values are inherited from the default net
namespace to the chil
> -Original Message-
> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
> Behalf Of Neftin, Sasha
> Sent: Monday, February 27, 2017 12:40 AM
> To: Bernd Faust ; Kirsher, Jeffrey T
> ; intel-wired-...@lists.osuosl.org;
> netdev@vger.kernel.org; linux-ker...@vger.ker
Just posted an RFC patch, that I'm also testing here..
hopefully we'll se the pr_info light up, and know that the problematic
situation actually happened (I'll remove the pr_info if/when this
gets submitted as a non-RFC patch).. thanks for helping with testing
this..
--Sowmini
On Tue, Feb 28, 2017 at 12:43 PM, Willem de Bruijn
wrote:
> On Tue, Feb 28, 2017 at 2:46 PM, Andy Lutomirski wrote:
>> On Mon, Feb 27, 2017 at 10:57 AM, Michael Kerrisk
>> wrote:
>>> [CC += linux-...@vger.kernel.org]
>>>
>>> Hi Willem
>>>
>>
On a send call with MSG_ZEROCOPY, the kernel pins
On Mon, 2017-02-27 at 10:55 -0800, Stephen Hemminger wrote:
>
> Another alternative format would be to make -tree a output modifier and ident
> (like ps tree options).
>
> $ ip -t link
> 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode
> DEFAULT group default qlen 1
> link/loopback 00:00:
On Tue, Feb 28, 2017 at 2:46 PM, Andy Lutomirski wrote:
> On Mon, Feb 27, 2017 at 10:57 AM, Michael Kerrisk
> wrote:
>> [CC += linux-...@vger.kernel.org]
>>
>> Hi Willem
>>
>
>>> On a send call with MSG_ZEROCOPY, the kernel pins the user pages and
>>> creates skbuff fragments directly from these
On Tue, Feb 28, 2017 at 6:33 PM, Sowmini Varadhan
wrote:
> On (02/28/17 17:51), Dmitry Vyukov wrote:
>> Searching other crashes for "net/rds" I found 2 more crashes that may
>> be related. They suggest that the delayed works are not properly
>> stopped when the socket is destroyed. That would expl
On Mon, Feb 27, 2017 at 10:57 AM, Michael Kerrisk
wrote:
> [CC += linux-...@vger.kernel.org]
>
> Hi Willem
>
>> On a send call with MSG_ZEROCOPY, the kernel pins the user pages and
>> creates skbuff fragments directly from these pages. On tx completion,
>> it notifies the socket owner that it is
On Mon, 2017-02-27 at 17:38 +0100, Jiri Benc wrote:
>
> It produces dot (graphviz) output or json and has no dependencies on
> anything GUI related. Just run it on the remote machine and display the
> output locally.
>
> ssh root@remote plotnetcfg | dot -Tpdf | whatever_pdf_viewer
>
> Note that
On Tue, Feb 28, 2017 at 2:32 AM, Davide Caratti wrote:
> Introduce skb->csum_not_inet to identify not-yet-checksummed SCTP packets.
> Use this bit in combination with netdev feature bit in validate_xmit_skb,
> to discriminate whether skb needs crc32c or 2-complement Internet Checksum
> (or none of
On Tue, Feb 28, 2017 at 11:01 AM, David Ahern wrote:
> On 2/28/17 10:44 AM, Cong Wang wrote:
>> Like commit 1f17e2f2c8a8 ("net: ipv6: ignore null_entry on route dumps"),
>> we need to ignore null entry in inet6_rtm_getroute() too.
>>
>> Return -ENOENT here because we return the same errno when del
On 2/28/17 10:44 AM, Cong Wang wrote:
> Like commit 1f17e2f2c8a8 ("net: ipv6: ignore null_entry on route dumps"),
> we need to ignore null entry in inet6_rtm_getroute() too.
>
> Return -ENOENT here because we return the same errno when deleting
> the null entry.
>
> Fixes: a1a22c1206 ("net: ipv6:
From: Eric Dumazet
While playing with mlx4 hardware timestamping of RX packets, I found
that some packets were received by TCP stack with a ~200 ms delay...
Since the timestamp was provided by the NIC, and my probe was added
in tcp_v4_rcv() while in BH handler, I was confident it was not
a sende
Hi Stefan,
On Tue, Feb 28, 2017 at 05:21:18PM +0100, Stefan Wahren wrote:
> Am 28.02.2017 um 13:01 schrieb Baruch Siach:
> > On Tue, Feb 28, 2017 at 10:28:10AM +0200, Baruch Siach wrote:
> > > I'm hitting this warning consistently on my Raspberry Pi 3 running
> > > kernel
> > > v4.10.1 with some
BCM471X and BCM535X are of the same family (from what I can derive from
internal documents). Group them into the case statement together, which
results in more code reuse.
Also, use existing helper variables to make the code a little more
readable too.
Signed-off-by: Jon Mason
---
drivers/net/
Fix a bug in the 'bgmac' driver init sequence that blind writes for init
sequence where it should preserve most bits other than the ones it is
deliberately manipulating.
The code now checks to see if the adapter needs to be brought out of
reset (where as before it was doing an IDM write to bring i
Changes in v4:
* Added the udelays from the previous code (per David Miller)
Changes in v3:
* Reworked the init sequence patch to only remove the device reset if
the device is actually in reset. Given that this code doesn't bear
much resemblance to the original code, I'm changing the author o
Like commit 1f17e2f2c8a8 ("net: ipv6: ignore null_entry on route dumps"),
we need to ignore null entry in inet6_rtm_getroute() too.
Return -ENOENT here because we return the same errno when deleting
the null entry.
Fixes: a1a22c1206 ("net: ipv6: Keep nexthop of multipath route on admin down")
Rep
From: Hari Vyas
ndo_set_mac_address() passes struct sockaddr * as 2nd parameter to
bgmac_set_mac_address() but code assumed u8 *. This caused two bytes
chopping and the wrong mac address was configured.
Signed-off-by: Hari Vyas
Signed-off-by: Jon Mason
Fixes: 4e209001b86 ("bgmac: write mac ad
Hi Baruch,
> Baruch Siach hat am 28. Februar 2017 um 19:07 geschrieben:
>
>
> Hi Stefan,
>
> On Tue, Feb 28, 2017 at 05:21:18PM +0100, Stefan Wahren wrote:
> > Am 28.02.2017 um 13:01 schrieb Baruch Siach:
> > > On Tue, Feb 28, 2017 at 10:28:10AM +0200, Baruch Siach wrote:
> > > > I'm hitting t
On 28/02/2017 2:02 PM, Dan Carpenter wrote:
Bitwise & was obviously intended here.
Sure! Thanks for your patch.
Fixes: 745d8ae4622c ("net/mlx4: Spoofcheck and zero MAC can't coexist")
Signed-off-by: Dan Carpenter
---
Applies to net.git.
diff --git a/include/linux/mlx4/driver.h b/include/
On Tue, Feb 28, 2017 at 5:10 AM, Eric Dumazet wrote:
> On Tue, 2017-02-28 at 12:34 +0100, Dmitry Vyukov wrote:
>> Hello,
>>
>> The following program triggers GPF in rt6_nexthop_info
>>
>> // autogenerated by syzkaller (http://github.com/google/syzkaller)
>> #include
>> #include
>> #include
>> #
On Mon, Feb 27, 2017 at 6:21 AM, Eric Dumazet wrote:
> From: Eric Dumazet
>
> While playing with mlx4 hardware timestamping of RX packets, I found
> that some packets were received by TCP stack with a ~200 ms delay...
>
> Since the timestamp was provided by the NIC, and my probe was added
> in tc
Could use a proper changelog.
Will do, thanks!
On DT systems the driver require a clock, but the probe just print a
warning and continue, leading to a crash when resetting the device.
To fix this crash and properly handle probe deferals only ignore the
missing clock if DT isn't used or if the clock doesn't exist.
Signed-off-by: Alban Bedel
--
Could use a proper changelog.
Otherwise looks fine:
Reviewed-by: Christoph Hellwig
On Tue, Feb 28, 2017 at 10:38:44AM -0500, David Miller wrote:
> From: Baruch Siach
> Date: Tue, 28 Feb 2017 10:39:48 +0200
>
> > The email address of Jan Dumon bounces, and there is not relevant
> > information
> > in the linked website.
> >
> > Signed-off-by: Baruch Siach
>
> This patch is f
On (02/28/17 18:45), Dmitry Vyukov wrote:
>
> Yes, I can now apply custom patches to the bots. However, it fired
> only 3 times, so it will give weak signal. But at least it will test
> that the patch does not cause other bad things.
Ok, let me do my bit of homework on this one and get back to yo
On Tue, 2017-02-28 at 09:20 -0800, Alexander Duyck wrote:
> On Mon, Feb 27, 2017 at 6:21 AM, Eric Dumazet wrote:
> > +bool napi_schedule_prep(struct napi_struct *n)
> > +{
> > + unsigned long val, new;
> > +
> > + do {
> > + val = READ_ONCE(n->state);
> > +
On (02/28/17 17:51), Dmitry Vyukov wrote:
> Searching other crashes for "net/rds" I found 2 more crashes that may
> be related. They suggest that the delayed works are not properly
> stopped when the socket is destroyed. That would explain how
> rds_connect_worker accesses freed net, right?
yes, I
On Tue, 2017-02-28 at 08:17 -0800, Stephen Hemminger wrote:
> Maybe just as simple as using irqsave/irqrestore in driver.
CPU can be differents.
irqsave will not help.
On Tue, Feb 28, 2017 at 5:38 PM, Sowmini Varadhan
wrote:
> On (02/28/17 17:32), Dmitry Vyukov wrote:
>> Not reproducible so far.
>>
>> rds is compiled into kernel (no modules):
>> CONFIG_RDS=y
>> CONFIG_RDS_TCP=y
>
> I see. So if it never gets unloaded, the rds_connections "should"
> be around for
On 2/27/2017 10:45 PM, Zhu Yanjun wrote:
The variables rds_ib_mr_1m_pool_size and rds_ib_mr_8k_pool_size
are used only in the ib.c file. As such, the static type is
added to limit them in this file.
Cc: Joe Jin
Cc: Junxiao Bi
Signed-off-by: Zhu Yanjun
---
Looks good.
Acked-by: Santosh Shilim
On (02/28/17 17:32), Dmitry Vyukov wrote:
> Not reproducible so far.
>
> rds is compiled into kernel (no modules):
> CONFIG_RDS=y
> CONFIG_RDS_TCP=y
I see. So if it never gets unloaded, the rds_connections "should"
be around forever.. let me inspect code and see if I spot some
race-window..
>
On Tue, Feb 28, 2017 at 5:15 PM, Sowmini Varadhan
wrote:
> On (02/28/17 16:49), Dmitry Vyukov wrote:
>>
>> Grepping "socket" there, it was doing lots of things with sockets. Are
>> we looking for some particular socket type? If there are few programs
>> that create sockets of that type, then we ca
Hi Baruch,
Am 28.02.2017 um 13:01 schrieb Baruch Siach:
Hi linux-usb list,
(Dropped Jan's bouncing address, added Rpi3 platform lists)
On Tue, Feb 28, 2017 at 10:28:10AM +0200, Baruch Siach wrote:
Hi linux-usb list,
I'm hitting this warning consistently on my Raspberry Pi 3 running kernel
v4
Please add a changelog and mention that this adds IPv6 support.
Otherwise looks fine:
Reviewed-by: Christoph Hellwig
Looks fine,
Reviewed-by: Christoph Hellwig
On Mon, 27 Feb 2017 12:18:31 -0800
Eric Dumazet wrote:
> This can happen with busy polling users, or if gro_flush_timeout is
> used. But some other uses of napi_schedule() in drivers can cause this
> as well.
Where were IRQ's re-enabled?
> thread 1 thread 2 (cou
On (02/28/17 16:49), Dmitry Vyukov wrote:
>
> Grepping "socket" there, it was doing lots of things with sockets. Are
> we looking for some particular socket type? If there are few programs
> that create sockets of that type, then we can narrow down the set:
Yes, we are looking for PF_RDS/AF_RDS -
On Tue, 2017-02-28 at 14:01 +0200, Baruch Siach wrote:
> Hi linux-usb list,
>
> (Dropped Jan's bouncing address, added Rpi3 platform lists)
>
> On Tue, Feb 28, 2017 at 10:28:10AM +0200, Baruch Siach wrote:
> > Hi linux-usb list,
> >
> > I'm hitting this warning consistently on my Raspberry Pi 3
On Tue, Feb 28, 2017 at 4:37 PM, Sowmini Varadhan
wrote:
> On (02/28/17 15:22), Dmitry Vyukov wrote:
>>
>> Hello,
>>
>> I've got the following report while running syzkaller fuzzer on
>> linux-next/8d01c069486aca75b8f6018a759215b0ed0c91f0. So far it
>> happened only once. net was somehow deleted f
From: Baruch Siach
Date: Tue, 28 Feb 2017 10:39:48 +0200
> The email address of Jan Dumon bounces, and there is not relevant information
> in the linked website.
>
> Signed-off-by: Baruch Siach
This patch is fine and I will apply it later, however I will make a
general statement that we list U
On Tue, Feb 28, 2017 at 11:35 PM, Dmitry Vyukov wrote:
> On Mon, Feb 27, 2017 at 5:27 PM, Xin Long wrote:
>> On Mon, Feb 27, 2017 at 11:45 PM, Andrey Konovalov
>> wrote:
>>> Hi,
>>>
>>> I've got the following error report while fuzzing the kernel with syzkaller.
>>>
>>> On commit e5d56efc97f8240
On Mon, Feb 27, 2017 at 5:27 PM, Xin Long wrote:
> On Mon, Feb 27, 2017 at 11:45 PM, Andrey Konovalov
> wrote:
>> Hi,
>>
>> I've got the following error report while fuzzing the kernel with syzkaller.
>>
>> On commit e5d56efc97f8240d0b5d66c03949382b6d7e5570 (Feb 26).
>>
>> A reproducer and .confi
On Tue, 2017-02-28 at 15:02 +0300, Dan Carpenter wrote:
> Bitwise & was obviously intended here.
>
> Fixes: 745d8ae4622c ("net/mlx4: Spoofcheck and zero MAC can't coexist")
> Signed-off-by: Dan Carpenter
> ---
> Applies to net.git.
>
> diff --git a/include/linux/mlx4/driver.h b/include/linux/mlx
On (02/28/17 15:22), Dmitry Vyukov wrote:
>
> Hello,
>
> I've got the following report while running syzkaller fuzzer on
> linux-next/8d01c069486aca75b8f6018a759215b0ed0c91f0. So far it
> happened only once. net was somehow deleted from underneath
> inet_create. I've noticed that rds uses sock_cr
On Tue, Feb 28, 2017 at 7:26 AM, Dmitry Vyukov wrote:
> Hello,
>
> I've got the following WARNING while running syzkaller fuzzer:
>
> [ cut here ]
> WARNING: CPU: 0 PID: 9197 at kernel/sched/core.c:6149
> __might_sleep+0x149/0x1a0 kernel/sched/core.c:6144
> do not call bloc
1 - 100 of 148 matches
Mail list logo