Thu, Jan 31, 2019 at 06:29:25PM CET, jakub.kicin...@netronome.com wrote:
>On Thu, 31 Jan 2019 09:25:08 -0800, Jakub Kicinski wrote:
>> On Thu, 31 Jan 2019 09:23:03 -0800 (PST), David Miller wrote:
>> > From: kbuild test robot
>> > Date: Fri, 1 Feb 2019 00:19:33 +0800
>> >
>> > > All errors (new
Thu, Jan 31, 2019 at 07:50:47PM CET, jakub.kicin...@netronome.com wrote:
>If driver did not fill the fw_version field, try to call into
>the new devlink get_info op and collect the versions that way.
>We assume ethtool was always reporting running versions.
>
>v4:
> - use IS_REACHABLE() to avoid pr
On 2019/2/1 0:59, Russell King wrote:
> This reverts commit 6623c0fba10ef45b64ca213ad5dec926f37fa9a0.
>
> The original diagnosis was incorrect: it appears that the NIC had
> PHY polling mode enabled, which meant that it overwrote the PHYs
> advertisement register during negotiation.
>
> Signed-of
> I am not sure what does assignment of pointers mean in this context.
> ptr_ring is designed for a single producer and a single consumer. For
> why it works see explanation about data dependencies in
> Documentation/memory-barriers.txt. You will have to be more specific
> about the data race tha
On Tue, Jan 29, 2019 at 04:33:58PM +0100, Stefano Garzarella wrote:
> Kindly ping :)
Hi Stefano,
It probably didn't get picked up due to the "RFC" (Request for
Comments).
I suggest rebasing, retesting, and resending to be sure it will be
noticed and merged without conflicts.
Stefan
signature.a
We recently changed this function in commit f9fc54d313fa ("ethtool:
check the return value of get_regs_len") such that if "reglen" is zero
we return directly. That means we can remove this condition as well.
Signed-off-by: Dan Carpenter
---
net/core/ethtool.c | 9 +++--
1 file changed, 3 in
Currently, the libbpf API function libbpf_set_print()
takes three function pointer parameters for warning, info
and debug printout respectively.
This patch changes the API to have just one function pointer
parameter and the function pointer has one additional
parameter "debugging level". So if in
These are concrete patches responding to my comments for
Magnus's patch. Specifically, Patch #1 used global functions
to facilitate pr_* macros in the header files so they
are available in different C files.
Patch #2 simplified libbpf_set_print() takes only one print
function and the print function
A global function libbpf_dprint, which is invisible
outside the shared library, is defined to print based
on levels. The pr_warning, pr_info and pr_debug
macros are moved into the newly created header
common.h. So any .c file including common.h can
use these macros directly.
Currently btf__new and
The "p" buffer is 0x4000 bytes long. B3_RI_WTO_R1 is 0x190. The value
of "regs->len" is in the 1-0x4000 range. The bug here is that
"regs->len - B3_RI_WTO_R1" can be a negative value which would lead to
memory corruption and an abrupt crash.
Fixes: c3f8be961808 ("[PATCH] skge: expand ethtool de
We should return -ENOMEM if the kcalloc() fails.
Fixes: d174ea75c96a ("net: hns3: add statistics for PFC frames and MAC control
frame")
Signed-off-by: Dan Carpenter
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethe
On Fri, Feb 01, 2019 at 04:19:41PM +0800, Stefan Hajnoczi wrote:
> On Tue, Jan 29, 2019 at 04:33:58PM +0100, Stefano Garzarella wrote:
> > Kindly ping :)
>
> Hi Stefano,
> It probably didn't get picked up due to the "RFC" (Request for
> Comments).
>
> I suggest rebasing, retesting, and resending to
gbefb uses managed resources, so it should do the same for DMA
allocations.
Signed-off-by: Christoph Hellwig
---
drivers/video/fbdev/gbefb.c | 24
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/video/fbdev/gbefb.c b/drivers/video/fbdev/gbefb.c
ind
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
sound/mips/hal2.c | 31 +--
1
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Also use GFP_KERNEL instead of GFP_USER as the gfp_t for the memory
allocation, as we should tre
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
drivers/usb/gadget/udc/fotg210-udc.c | 7 ---
1 file
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
drivers/parport/parport_ip32.c | 18 ++
1
dma_map_single already transfers ownership to the device.
Signed-off-by: Christoph Hellwig
---
drivers/usb/gadget/udc/fotg210-udc.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/usb/gadget/udc/fotg210-udc.c
b/drivers/usb/gadget/udc/fotg210-udc.c
index bc6abaea907d..fe9cf415f2f1
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
drivers/net/ethernet/moxa/moxart_ether.c | 11 +++
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Also use GFP_KERNEL instead of GFP_ATOMIC as the gfp_t for the memory
allocation, as we aren't i
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Note that this driver seems to entirely lack dma_map_single error
handling, but that is left for
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Also use the proper Kconfig symbol to check for DMA API availability.
Signed-off-by: Christoph
We still have a few drivers which pass a NULL struct device pointer
to DMA API functions, which generally is a bad idea as the API
implementations rely on the device not only for ops selection, but
also the dma mask and various other attributes.
This series contains all easy conversions to pass a
Just like we do for all other DMA operations.
Signed-off-by: Christoph Hellwig
---
drivers/video/fbdev/pxa3xx-gcu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/pxa3xx-gcu.c b/drivers/video/fbdev/pxa3xx-gcu.c
index 69cfb337c857..047a2fa4b87e 100644
-
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
drivers/video/fbdev/da8xx-fb.c | 13 +++--
1 file
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
drivers/net/ethernet/amd/au1000_eth.c | 6 +++---
1 file
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Note this driver seems to lack dma_unmap_* calls entirely, but fixing
that is left for another t
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
drivers/net/ethernet/cadence/macb_main.c | 8
1
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
drivers/net/ethernet/smsc/smc911x.c | 4 ++--
1 file chan
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Also use GFP_KERNEL instead of GFP_ATOMIC as the gfp_t for the memory
allocation, as we aren't i
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
drivers/dma/imx-sdma.c | 10 +-
1 file changed, 5
> -Original Message-
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Wednesday, 30 January, 2019 08:53 PM
> To: Pankaj Bansal
> Cc: Florian Fainelli ; netdev@vger.kernel.org; Varun
> Sethi
>
> Subject: Re: [PATCH 0/1] add MDIO bus multiplexer driven by a regmap device
>
> On Wed,
Hi Dave,
Two more fixes for the current cycle, one is a new bug introduced
in 4.20, the other one seems to be much older.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 5e66e35aab335b83d9ffb220d8a3a13986a7a60e:
bnxt_en: Disable inter
This adds support for generating bpf line info for
JITed programs.
Signed-off-by: Sandipan Das
---
arch/powerpc/net/bpf_jit_comp64.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/net/bpf_jit_comp64.c
b/arch/powerpc/net/bpf_jit_comp64.c
index 15bba765fa79..4194d3cfb60c 100644
From: Alexander Onnasch
With Micrel KSZ8061 PHY, the link may occasionally not come up after
Ethernet cable connect. The vendor's (Microchip, former Micrel) errata
sheet 8688A.pdf describes the problem and possible workarounds in
detail, see below.
The patch implements workaround 1, which per
Hi Vivien,
Vivien Didelot wrote on Wed, 30 Jan 2019
19:46:08 -0500:
> Hi Miquèl,
>
> On Wed, 30 Jan 2019 10:46:06 +0100, Miquel Raynal
> wrote:
>
> > > > > Today, there is no S2RAM support for switches. First, I proposed to
> > > > > add
> > > > > suspend/resume callbacks to the mv88e6xxx d
On Thu, Jan 31, 2019, at 8:35 PM, Alexei Starovoitov wrote:
> On Wed, Jan 30, 2019 at 03:02:51PM +0100, Martynas Pumputis wrote:
> > Previously, memory allocated for a map was not accounted. Therefore,
> > this memory could not be taken into consideration by the cgroups
> > memory controller.
>
Hi Dave,
Here's my next pull request for net-next. I wanted to include more,
notably the multi-BSSID work that's going on now (multi-BSSID lets
a single AP with a single beacon have multiple networks, rather than
requiring a beacon for each), but we're still finding small issues
and bugs in it, so
nux/kernel/git/herbert/crypto-2.6 (2018-12-27
13:53:32 -0800)
are available in the git repository at:
git://git.open-mesh.org/linux-merge.git tags/batadv-net-for-davem-20190201
for you to fetch changes up to 7d652669b61d702c6e62a39579d17f6881670ab6:
batman-adv: release station info tidstat
From: Felix Fietkau
With the addition of TXQ stats in the per-tid statistics the struct
station_info grew significantly. This resulted in stack size warnings
due to the structure itself being above the limit for the warnings.
To work around this, the TID array was allocated dynamically. Also a
f
From: Sven Eckelmann
The caller of ndo_start_xmit may not already have called
skb_reset_mac_header. The returned value of skb_mac_header/eth_hdr
therefore can be in the wrong position and even outside the current skbuff.
This for example happens when the user binds to the device using a
PF_PACKET
From: Sven Eckelmann
It is not allowed to use WARN* helpers on potential incorrect input from
the user or transient problems because systems configured as panic_on_warn
will reboot due to such a problem.
A NULL return value of __dev_get_by_index can be caused by various problems
which can either
rg/pub/scm/linux/kernel/git/herbert/crypto-2.6 (2018-12-27
13:53:32 -0800)
are available in the git repository at:
git://git.open-mesh.org/linux-merge.git tags/batadv-next-for-davem-20190201
for you to fetch changes up to 7a79d717e0817610932ce3b7b6033ea06ee1d577:
batman-adv: Update copyright
From: Sven Eckelmann
Signed-off-by: Sven Eckelmann
Signed-off-by: Simon Wunderlich
---
include/uapi/linux/batadv_packet.h | 2 +-
include/uapi/linux/batman_adv.h| 2 +-
net/batman-adv/Kconfig | 2 +-
net/batman-adv/Makefile| 2 +-
net/batman-adv/bat_
Signed-off-by: Simon Wunderlich
---
net/batman-adv/main.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/batman-adv/main.h b/net/batman-adv/main.h
index b572066325e4..f3ef2c725a41 100644
--- a/net/batman-adv/main.h
+++ b/net/batman-adv/main.h
@@ -25,7 +25,7 @@
#define BA
From: Linus Lüssing
In a 1000 nodes mesh network (Freifunk Hamburg) we can still see
30KBit/s of ARP traffic (equalling about 25% of all layer two
specific overhead, remaining after some filtering) flooded through
the mesh. These 30KBit/s are mainly ARP Requests from the
gateways / DHCP servers.
{t4/t4_vf}_change_mac() API's were only doing additions to MPS_TCAM.
This will fail, when the number of tcam entries is limited particularly
in vf's.
This fix programs hash region with the mac address, when TCAM
addtion fails for {t4/t4vf}_change_mac(). Since the locally maintained
driver list for
{t4/t4_vf}_change_mac() API's were only doing additions to MPS_TCAM.
This will fail, when the number of tcam entries is limited particularly
in vf's.
This fix programs hash region with the mac address, when TCAM
addtion fails for {t4/t4vf}_change_mac(). Since the locally maintained
driver list for
These patches try to handle the hot-unplug of vsock virtio transport device in
a proper way.
Maybe move the vsock_core_init()/vsock_core_exit() functions in the module_init
and module_exit of vsock_virtio_transport module can't be the best way, but the
architecture of vsock_core forces us to this
When the virtio transport device disappear, we should reset all
connected sockets in order to inform the users.
Signed-off-by: Stefano Garzarella
Reviewed-by: Stefan Hajnoczi
---
net/vmw_vsock/virtio_transport.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/vmw_vsock/virtio_transpo
virtio_vsock_remove() invokes the vsock_core_exit() also if there
are opened sockets for the AF_VSOCK protocol family. In this way
the vsock "transport" pointer is set to NULL, triggering the
kernel panic at the first socket activity.
This patch move the vsock_core_init()/vsock_core_exit() in the
"Gustavo A. R. Silva" wrote:
> One of the more common cases of allocation size calculations is finding the
> size of a structure that has a zero-sized array at the end, along with memory
> for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> void *entr
Kangjie Lu wrote:
> sysfs_create_group() could fail. The fix checkes its return values
> and issue error messages if it fails.
>
> Signed-off-by: Kangjie Lu
Patch applied to wireless-drivers-next.git, thanks.
434256833d8e libertas: add checks for the return value of sysfs_create_group
--
ht
Bernd Edlinger wrote:
> This appears to trigger a firmware bug and causes severe
> problems with rtl8723ae PCI devices.
>
> When the power save mode is activated for longer periods
> of time the firmware stops to receive any packets.
>
> This problem was exposed by commit 873ffe154ae0 ("rtlwifi
Bernd Edlinger wrote:
> Apparently the rt2x61 firmware fails temporarily to decode
> broadcast packets if the shared keys are not assigned
> in the "correct" sequence. At the same time unicast
> packets work fine, since they are encrypted with the
> pairwise key.
>
> At least with WPA2 CCMP mode
Colin King wrote:
> From: Colin Ian King
>
> There are two lines that have indentation issues, fix these.
>
> Signed-off-by: Colin Ian King
Patch applied to wireless-drivers-next.git, thanks.
b0535d502d18 cw1200: fix indentation issues
--
https://patchwork.kernel.org/patch/10768357/
http
Colin King wrote:
> From: Colin Ian King
>
> There is a goto statement that is missing a tab for indentation. Fix this.
>
> Signed-off-by: Colin Ian King
Patch applied to wireless-drivers-next.git, thanks.
112ec26fcdc5 wlcore: clean up an indentation issue
--
https://patchwork.kernel.org/
Colin King wrote:
> From: Colin Ian King
>
> There is a statement that is indented too deeply. Fix this.
>
> Signed-off-by: Colin Ian King
> Acked-by: John W. Linville
Patch applied to wireless-drivers-next.git, thanks.
2d76fff865d6 rtlwifi: rtl818x: fix indentation issue
--
https://patc
Colin King wrote:
> From: Colin Ian King
>
> There is a statement that is incorrectly indented, fix it.
>
> Signed-off-by: Colin Ian King
Patch applied to wireless-drivers-next.git, thanks.
6dcbe4592e7a libertas: fix indentation issue
--
https://patchwork.kernel.org/patch/10766467/
https
YueHaibing wrote:
> remove unneeded semicolon
>
> Signed-off-by: YueHaibing
> Acked-by: Ping-Ke Shih
> Acked-by: Steve deRosier
> Acked-by: Arend van Spriel
Patch applied to wireless-drivers-next.git, thanks.
999eb686aa90 wireless: remove unneeded semicolon
--
https://patchwork.kernel.or
On Thu, Jan 31, 2019 at 10:39:41PM -0200, Marcelo Ricardo Leitner wrote:
> On Tue, Jan 29, 2019 at 07:58:07PM +0100, Tuxdriver wrote:
> > I was initially under the impression that with Kent's repost, the radixtree
> > (which is what I think you meant by rhashtables) updates would be merged
>
> Oop
Masahiro Yamada wrote:
> Currently, the Kbuild core manipulates header search paths in a crazy
> way [1].
>
> To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
> the search paths in the srctree. Some Makefiles are already written in
> that way, but not all. The goal of this w
On Fri, 01 Feb 2019 09:48:00 +0100,
Christoph Hellwig wrote:
>
> The DMA API generally relies on a struct device to work properly, and
> only barely works without one for legacy reasons. Pass the easily
> available struct device from the platform_device to remedy this.
>
> Signed-off-by: Christo
On Fri, 01 Feb 2019 09:48:01 +0100,
Christoph Hellwig wrote:
>
> The DMA API generally relies on a struct device to work properly, and
> only barely works without one for legacy reasons. Pass the easily
> available struct device from the platform_device to remedy this.
>
> Also use GFP_KERNEL in
On Fri, 01 Feb 2019 09:47:43 +0100,
Christoph Hellwig wrote:
>
> We still have a few drivers which pass a NULL struct device pointer
> to DMA API functions, which generally is a bad idea as the API
> implementations rely on the device not only for ops selection, but
> also the dma mask and various
Christoph Hellwig writes:
> The DMA API generally relies on a struct device to work properly, and
> only barely works without one for legacy reasons. Pass the easily
> available struct device from the platform_device to remedy this.
>
> Signed-off-by: Christoph Hellwig
In case you're taking th
On Tue, Jan 29, 2019 at 10:02:01AM +0200, Paul Blakey wrote:
...
> diff --git a/include/uapi/linux/tc_act/tc_ct.h
> b/include/uapi/linux/tc_act/tc_ct.h
> new file mode 100644
> index 000..6dbd771
> --- /dev/null
> +++ b/include/uapi/linux/tc_act/tc_ct.h
> @@ -0,0 +1,29 @@
> +/* SPDX-License-Id
Christoph Hellwig writes:
> dma_map_single already transfers ownership to the device.
>
> Signed-off-by: Christoph Hellwig
Do you want me to take the USB bits or will you take the entire series?
In case you're taking the entire series:
Acked-by: Felipe Balbi
> ---
> drivers/usb/gadget/udc/f
On 01/02/2019 at 09:47, Christoph Hellwig wrote:
> The DMA API generally relies on a struct device to work properly, and
> only barely works without one for legacy reasons. Pass the easily
> available struct device from the platform_device to remedy this.
>
> Signed-off-by: Christoph Hellwig
Ac
On Thu, Jan 31, 2019, at 10:04 PM, Jakub Kicinski wrote:
> On Thu, 31 Jan 2019 10:38:01 +0100, Martynas Pumputis wrote:
> > Previously, memory allocated for a map was not accounted. Therefore,
> > this memory could not be taken into consideration by the cgroups
> > memory controller.
> >
> > Thi
> This is not a new driver for a device. Which is why there is no compatible
> field that I have used in these APIs.
> Should I create a new binding document for it ?
Yes, you always need to document the binding.
Andrew
On 01/02/2019 08:47, Christoph Hellwig wrote:
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Also use the proper Kconfig symbol to check for
On Thu, Jan 31, 2019 at 10:47:50AM -0800, Alexei Starovoitov wrote:
> On Thu, Jan 31, 2019 at 06:01:56AM -0800, Paul E. McKenney wrote:
> > On Wed, Jan 30, 2019 at 02:57:43PM -0800, Alexei Starovoitov wrote:
> > > On Wed, Jan 30, 2019 at 01:05:36PM -0800, Paul E. McKenney wrote:
> > > > On Wed, Jan
On Fri, Feb 01, 2019 at 12:01:19PM +0100, Miquel Raynal wrote:
> Hi Vivien,
>
> Vivien Didelot wrote on Wed, 30 Jan 2019
> 19:46:08 -0500:
>
> > Hi Miquèl,
> >
> > On Wed, 30 Jan 2019 10:46:06 +0100, Miquel Raynal
> > wrote:
> >
> > > > > > Today, there is no S2RAM support for switches. Firs
On 01/02/2019 08:47, Christoph Hellwig wrote:
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Hmm, as far as I'm aware these are PIO chips wi
In sctp_sendmesg(), when walking the list of endpoint associations, the
association can be dropped from the list, making the list corrupt.
Properly handle this by using list_for_each_entry_safe()
Fixes: 4910280503f3 ("sctp: add support for snd flag SCTP_SENDALL process in
sendmsg")
Reported-by: S
On Fri, Feb 01, 2019 at 03:15:22PM +0100, Greg Kroah-Hartman wrote:
> In sctp_sendmesg(), when walking the list of endpoint associations, the
> association can be dropped from the list, making the list corrupt.
> Properly handle this by using list_for_each_entry_safe()
>
> Fixes: 4910280503f3 ("sc
On Fri, Feb 01, 2019 at 12:20:37PM -0200, Marcelo Ricardo Leitner wrote:
> On Fri, Feb 01, 2019 at 03:15:22PM +0100, Greg Kroah-Hartman wrote:
> > In sctp_sendmesg(), when walking the list of endpoint associations, the
> > association can be dropped from the list, making the list corrupt.
> > Prope
Hi Andrew,
Andrew Lunn wrote on Fri, 1 Feb 2019 15:08:31 +0100:
> On Fri, Feb 01, 2019 at 12:01:19PM +0100, Miquel Raynal wrote:
> > Hi Vivien,
> >
> > Vivien Didelot wrote on Wed, 30 Jan 2019
> > 19:46:08 -0500:
> >
> > > Hi Miquèl,
> > >
> > > On Wed, 30 Jan 2019 10:46:06 +0100, Miquel R
On Fri, Feb 01, 2019 at 03:43:59PM +0100, Greg Kroah-Hartman wrote:
> On Fri, Feb 01, 2019 at 12:20:37PM -0200, Marcelo Ricardo Leitner wrote:
> > On Fri, Feb 01, 2019 at 03:15:22PM +0100, Greg Kroah-Hartman wrote:
> > > In sctp_sendmesg(), when walking the list of endpoint associations, the
> > >
Kernel panic while running bpf: test_tunnel.sh on linux -next
5.0.0-rc4-next-20190129.
selftests: bpf: test_tunnel.sh
[ 273.997647] IPv6: ADDRCONF(NETDEV_CHANGE): veth1: link becomes ready
[ 274.054068] ip (11458) used greatest stack depth: 11448 bytes left
[ 274.120445] BUG: unable to handle k
On Fri, Feb 01, 2019 at 04:12:46PM +0800, fei phung wrote:
> > I am not sure what does assignment of pointers mean in this context.
> > ptr_ring is designed for a single producer and a single consumer. For
> > why it works see explanation about data dependencies in
> > Documentation/memory-barrier
Many architectures maintain an arch specific copy of the
file even though there are no differences with the asm-generic
one. Allow these architectures to use the generic one instead.
Signed-off-by: Deepa Dinamani
Acked-by: Max Filippov
Acked-by: Heiko Carstens
Cc: ch...@zankel.net
Cc: fenghua..
struct __kernel_old_timeval is supposed to have the same
layout as struct timeval. But, it was inadvarently missed
that __kernel_suseconds has a different definition for
sparc64.
Provide an asm-specific override that fixes it.
Reported-by: Arnd Bergmann
Suggested-by: Arnd Bergmann
Signed-off-by:
Add SO_TIMESTAMP_NEW and SO_TIMESTAMPNS_NEW variants of
socket timestamp options.
These are the y2038 safe versions of the SO_TIMESTAMP_OLD
and SO_TIMESTAMPNS_OLD for all architectures.
Note that the format of scm_timestamping.ts[0] is not changed
in this patch.
Signed-off-by: Deepa Dinamani
Cc:
The new type is meant to be used as a y2038 safe structure
to be used as part of cmsg data.
Presently the SO_TIMESTAMP socket option uses struct timeval
for timestamps. This is not y2038 safe.
Subsequent patches in the series add new y2038 safe socket
option to be used in the place of SO_TIMESTAMP_
With the new y2038 safe timestamping options added, update the
documentation to reflect the changes.
Signed-off-by: Deepa Dinamani
Acked-by: Willem de Bruijn
---
Documentation/networking/timestamping.txt | 43 ---
1 file changed, 38 insertions(+), 5 deletions(-)
diff --git
Add SO_TIMESTAMPING_NEW variant of socket timestamp options.
This is the y2038 safe versions of the SO_TIMESTAMPING_OLD
for all architectures.
Signed-off-by: Deepa Dinamani
Cc: ch...@zankel.net
Cc: fenghua...@intel.com
Cc: r...@twiddle.net
Cc: t...@linutronix.de
Cc: ubr...@linux.ibm.com
Cc: linux
SO_RCVTIMEO and SO_SNDTIMEO socket options use struct timeval
as the time format. struct timeval is not y2038 safe.
The subsequent patches in the series add support for new socket
timeout options with _NEW suffix that will use y2038 safe
data structures. Although the existing struct timeval layout
Add new socket timeout options that are y2038 safe.
Signed-off-by: Deepa Dinamani
Cc: ccaul...@redhat.com
Cc: da...@davemloft.net
Cc: del...@gmx.de
Cc: pau...@samba.org
Cc: r...@linux-mips.org
Cc: r...@twiddle.net
Cc: cluster-de...@redhat.com
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-al...@vger
As part of y2038 solution, all internal uses of
struct timeval are replaced by struct __kernel_old_timeval
and struct compat_timeval by struct old_timeval32.
Make socket timestamps use these new types.
This is mainly to be able to verify that the kernel build
is y2038 safe when such non y2038 safe
From: Arnd Bergmann
This is a cleanup to prepare for the addition of 64-bit time_t
in O_SNDTIMEO/O_RCVTIMEO. The existing compat handler seems
unnecessarily complex and error-prone, moving it all into the
main setsockopt()/getsockopt() implementation requires half
as much code and is easier to ex
Compiling rxtimestamp.c generates error messages due to
non-existing declaration for write() library call.
Add missing unistd.h include to provide the declaration and
silence the error.
Signed-off-by: Deepa Dinamani
---
tools/testing/selftests/networking/timestamping/rxtimestamp.c | 1 +
1 file
SO_TIMESTAMP, SO_TIMESTAMPNS and SO_TIMESTAMPING options, the
way they are currently defined, are not y2038 safe.
Subsequent patches in the series add new y2038 safe versions
of these options which provide 64 bit timestamps on all
architectures uniformly.
Hence, rename existing options with OLD tag
The series introduces new socket timestamps that are
y2038 safe.
The time data types used for the existing socket timestamp
options: SO_TIMESTAMP, SO_TIMESTAMPNS and SO_TIMESTAMPING
are not y2038 safe. The series introduces SO_TIMESTAMP_NEW,
SO_TIMESTAMPNS_NEW and SO_TIMESTAMPING_NEW to replace th
On Fri, Feb 01, 2019 at 03:15:22PM +0100, Greg Kroah-Hartman wrote:
> In sctp_sendmesg(), when walking the list of endpoint associations, the
> association can be dropped from the list, making the list corrupt.
> Properly handle this by using list_for_each_entry_safe()
>
> Fixes: 4910280503f3 ("sc
On Fri, Feb 01, 2019 at 02:12:45PM +0100, Takashi Iwai wrote:
> Shall I take this one through sound git tree or all through yours?
Feel free to merge the sound bits through your tree!
On Fri, Feb 01, 2019 at 02:16:08PM +0100, Takashi Iwai wrote:
> Actually there are a bunch of ISA sound drivers that still call
> allocators with NULL device.
>
> The patch below should address it, although it's only compile-tested.
Oh, I missed these "indirect" calls. This looks good to me:
Re
On Fri, Feb 01, 2019 at 03:19:41PM +0200, Felipe Balbi wrote:
> Christoph Hellwig writes:
>
> > dma_map_single already transfers ownership to the device.
> >
> > Signed-off-by: Christoph Hellwig
>
> Do you want me to take the USB bits or will you take the entire series?
> In case you're taking
On Fri, Feb 01, 2019 at 02:14:34PM +, Robin Murphy wrote:
> And equivalently for rxdma here. However, given that this all seems only
> relevant to antique ARCH_PXA platforms which are presumably managing to
> work as-is, it's probably not worth tinkering too much. I'd just stick a
> note in
1 - 100 of 243 matches
Mail list logo
