On 12/21/2018 12:27 PM, Deepa Dinamani wrote:
> Al Viro mentioned that there is probably a race condition
> lurking in accesses of sk_tstamp on 32-bit machines.
>
> sock->sk_tstamp is of type ktime_t which is always an s64.
> On a 32 bit architecture, we might run into situations of
> unsafe ac
Hello,
syzbot found the following crash on:
HEAD commit:ce28bb445388 Merge git://git.kernel.org/pub/scm/linux/kern..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=10eddf9740
kernel config: https://syzkaller.appspot.com/x/.config?x=67a2081147a23142
da
On Sat, Dec 22, 2018 at 04:53:45PM -0500, Willem de Bruijn wrote:
> From: Willem de Bruijn
>
> Validate packet socket address length if a length is given. Zero
> length is equivalent to not setting an address.
>
> Fixes: 99137b7888f4 ("packet: validate address length")
> Reported-by: Ido Schimme
On Sat, Dec 22, 2018 at 08:02:16PM +0800, kbuild test robot wrote:
> From: kbuild test robot
>
> drivers/net/ethernet/mellanox/mlx5/core/en_rep.c:1339:57-58: Unneeded
> semicolon
>
>
> Remove unneeded semicolon.
>
> Generated by: scripts/coccinelle/misc/semicolon.cocci
>
> Fixes: 4c8fb2986d44 ("
On Sat, Dec 22, 2018 at 11:03:31PM -0600, Gustavo A. R. Silva wrote:
> Alexei,
>
> On 12/22/18 10:12 PM, Alexei Starovoitov wrote:
> > On Sat, Dec 22, 2018 at 09:37:02PM -0600, Gustavo A. R. Silva wrote:
> > >
> > > Can't we have the case in which the code can be "trained" to read
> > > perfectly
Alexei,
On 12/22/18 10:12 PM, Alexei Starovoitov wrote:
On Sat, Dec 22, 2018 at 09:37:02PM -0600, Gustavo A. R. Silva wrote:
Can't we have the case in which the code can be "trained" to read
perfectly valid values for prog->len for quite a while, making the
microcode come into place and specul
On 2018-12-22 8:29 p.m., Robert Hancock wrote:
I have a device using a KSZ9897 switch
(CONFIG_MICROCHIP_KSZ_SPI_DRIVER=y) using a 4.19.9 kernel, where I am
trying to enable a bridge on some of the ports using systemd-networkd.
However, it seems to be getting an error when it tries to configure th
On Sat, Dec 22, 2018 at 09:37:02PM -0600, Gustavo A. R. Silva wrote:
>
> Can't we have the case in which the code can be "trained" to read
> perfectly valid values for prog->len for quite a while, making the
> microcode come into place and speculate about:
>
> 1013 if (flen == 0 || flen >
On 12/22/18 9:00 PM, Alexei Starovoitov wrote:
On Sat, Dec 22, 2018 at 08:53:40PM -0600, Gustavo A. R. Silva wrote:
Hi,
On 12/22/18 8:40 PM, David Miller wrote:
From: Alexei Starovoitov
Date: Sat, 22 Dec 2018 15:59:54 -0800
On Sat, Dec 22, 2018 at 03:07:22PM -0800, David Miller wrote:
F
Alexei,
On 12/22/18 9:37 PM, Gustavo A. R. Silva wrote:
On 12/22/18 9:00 PM, Alexei Starovoitov wrote:
On Sat, Dec 22, 2018 at 08:53:40PM -0600, Gustavo A. R. Silva wrote:
Hi,
On 12/22/18 8:40 PM, David Miller wrote:
From: Alexei Starovoitov
Date: Sat, 22 Dec 2018 15:59:54 -0800
On Sat,
On 12/22/18 8:42 PM, David Miller wrote:
From: "Gustavo A. R. Silva"
Date: Sat, 22 Dec 2018 17:37:35 -0600
I wonder if you can take this one too:
https://lore.kernel.org/lkml/20181221212229.GA32635@embeddedor/
It's pretty similar to the af_nfc one.
Sure, done.
Great. Thanks.
--
Gusta
On Sat, Dec 22, 2018 at 08:53:40PM -0600, Gustavo A. R. Silva wrote:
> Hi,
>
> On 12/22/18 8:40 PM, David Miller wrote:
> > From: Alexei Starovoitov
> > Date: Sat, 22 Dec 2018 15:59:54 -0800
> >
> > > On Sat, Dec 22, 2018 at 03:07:22PM -0800, David Miller wrote:
> > > > From: "Gustavo A. R. Silv
I have a device using a KSZ9897 switch
(CONFIG_MICROCHIP_KSZ_SPI_DRIVER=y) using a 4.19.9 kernel, where I am
trying to enable a bridge on some of the ports using systemd-networkd.
However, it seems to be getting an error when it tries to configure the
ports to be part of the bridge. systemd-network
Al Viro mentioned (Message-ID
<20170626041334.gz10...@zeniv.linux.org.uk>)
that there is probably a race condition
lurking in accesses of sk_stamp on 32-bit machines.
sock->sk_stamp is of type ktime_t which is always an s64.
On a 32 bit architecture, we might run into situations of
unsafe access a
Hi,
On 12/22/18 8:40 PM, David Miller wrote:
From: Alexei Starovoitov
Date: Sat, 22 Dec 2018 15:59:54 -0800
On Sat, Dec 22, 2018 at 03:07:22PM -0800, David Miller wrote:
From: "Gustavo A. R. Silva"
Date: Fri, 21 Dec 2018 14:49:01 -0600
flen is indirectly controlled by user-space, hence le
From: "Gustavo A. R. Silva"
Date: Sat, 22 Dec 2018 17:37:35 -0600
> I wonder if you can take this one too:
>
> https://lore.kernel.org/lkml/20181221212229.GA32635@embeddedor/
>
> It's pretty similar to the af_nfc one.
Sure, done.
From: Alexei Starovoitov
Date: Sat, 22 Dec 2018 15:59:54 -0800
> On Sat, Dec 22, 2018 at 03:07:22PM -0800, David Miller wrote:
>> From: "Gustavo A. R. Silva"
>> Date: Fri, 21 Dec 2018 14:49:01 -0600
>>
>> > flen is indirectly controlled by user-space, hence leading to
>> > a potential exploitat
On Sat, Dec 22, 2018 at 03:07:22PM -0800, David Miller wrote:
> From: "Gustavo A. R. Silva"
> Date: Fri, 21 Dec 2018 14:49:01 -0600
>
> > flen is indirectly controlled by user-space, hence leading to
> > a potential exploitation of the Spectre variant 1 vulnerability.
> >
> > This issue was dete
On 12/22/18 5:09 PM, David Miller wrote:
From: "Gustavo A. R. Silva"
Date: Fri, 21 Dec 2018 15:47:53 -0600
proto is indirectly controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.
This issue was detected with the help of Smatch:
net/n
From: Willem de Bruijn
Date: Sat, 22 Dec 2018 16:53:45 -0500
> From: Willem de Bruijn
>
> Validate packet socket address length if a length is given. Zero
> length is equivalent to not setting an address.
>
> Fixes: 99137b7888f4 ("packet: validate address length")
> Reported-by: Ido Schimmel
From: "Gustavo A. R. Silva"
Date: Fri, 21 Dec 2018 15:47:53 -0600
> proto is indirectly controlled by user-space, hence leading to
> a potential exploitation of the Spectre variant 1 vulnerability.
>
> This issue was detected with the help of Smatch:
>
> net/nfc/af_nfc.c:42 nfc_sock_create() wa
From: "Gustavo A. R. Silva"
Date: Fri, 21 Dec 2018 15:41:17 -0600
> protocol is indirectly controlled by user-space, hence leading to
> a potential exploitation of the Spectre variant 1 vulnerability.
>
> This issue was detected with the help of Smatch:
>
> net/phonet/af_phonet.c:48 phonet_prot
From: "Gustavo A. R. Silva"
Date: Fri, 21 Dec 2018 14:49:01 -0600
> flen is indirectly controlled by user-space, hence leading to
> a potential exploitation of the Spectre variant 1 vulnerability.
>
> This issue was detected with the help of Smatch:
>
> net/core/filter.c:1101 bpf_check_classic(
From: Deepa Dinamani
Date: Fri, 21 Dec 2018 12:27:33 -0800
> Al Viro mentioned that there is probably a race condition
> lurking in accesses of sk_tstamp on 32-bit machines.
>
> sock->sk_tstamp is of type ktime_t which is always an s64.
> On a 32 bit architecture, we might run into situations of
On Fri, 21 Dec 2018 17:24:01 -0800, Alexei Starovoitov wrote:
> On Fri, Dec 21, 2018 at 03:46:32PM -0800, Jakub Kicinski wrote:
> > On Thu, 20 Dec 2018 07:19:06 +, Yonghong Song wrote:
> > > > I think this will break func_info, since it's not adjusted here.
> > > > Also iirc line_info is relyin
Hello,
hns_nic_dev_probe() increments refcount of ae_node device node:
ae_node = of_parse_phandle(dev->of_node, "ae-handle", 0);
But there is no of_node_put() for ae_node.
What is the right place to decrement the ae_node refount?
Should it be placed in hns_nic_dev_probe() or in hns_nic_d
From: Willem de Bruijn
Validate packet socket address length if a length is given. Zero
length is equivalent to not setting an address.
Fixes: 99137b7888f4 ("packet: validate address length")
Reported-by: Ido Schimmel
Signed-off-by: Willem de Bruijn
---
net/packet/af_packet.c | 4 ++--
1 file
On 22.12.2018 00:35, Marek Vasut wrote:
> Add driver for the NXP TJA1100 and TJA1101 PHYs. These PHYs are special
> BroadRReach 100BaseT1 PHYs used in automotive.
>
> Signed-off-by: Marek Vasut
> Cc: Andrew Lunn
> Cc: Florian Fainelli
> Cc: Heiner Kallweit
> ---
> V2: - Use phy_modify(), phy_{
On Tue, Dec 18, 2018 at 12:13:38PM -0800, Florian Fainelli wrote:
> On 12/17/18 11:01 PM, Ido Schimmel wrote:
> > On Sun, Dec 16, 2018 at 09:14:09AM -0800, Florian Fainelli wrote:
> >> Le 12/16/18 à 12:25 AM, Ido Schimmel a écrit :
> >>> On Wed, Dec 12, 2018 at 03:09:43PM -0800, Florian Fainelli wr
On Sat, Dec 22, 2018 at 10:39 AM Ido Schimmel wrote:
>
> On Fri, Dec 21, 2018 at 12:06:59PM -0500, Willem de Bruijn wrote:
> > From: Willem de Bruijn
> >
> > Packet sockets with SOCK_DGRAM may pass an address for use in
> > dev_hard_header. Ensure that it is of sufficient length.
> >
> > Reported
From: Colin Ian King
The two different assignments for pkt_len are actually the same and
so the if statement is redundant and can be removed. Masking a u8
return value from inb() with 0xFF is also redundant and can also be
emoved. Remove the redundant code.
Detected by CoverityScan, CID#147563
Switch bindings for spi managed mode are using spaces instead of tabs.
Fix them to get a file with a proper kernel indentation style.
Signed-off-by: Sergio Paracuellos
---
.../devicetree/bindings/net/dsa/ksz.txt | 110 +-
1 file changed, 55 insertions(+), 55 deletions(-)
d
A recent change reduced max line length from 4096 to 2048 bytes,
but we already have lines above the 2048 threshold, and we keep
adding more SNMP counters in linux.
Switch to getline() and do not worry about future kernel changes.
Fixes: da8034a01904 ("misc: avoid snprintf warnings in ss and nsta
On Fri, Dec 21, 2018 at 09:59:12AM -0700, Jason Gunthorpe wrote:
> On Fri, Dec 21, 2018 at 03:59:54PM +0200, Leon Romanovsky wrote:
>
> > > diff --git a/drivers/infiniband/core/umem.c
> > > b/drivers/infiniband/core/umem.c
> > > index c6144df47ea47e..c2615b6bb68841 100644
> > > +++ b/drivers/infin
Thanks Steffen, but I don't think it is the case.
I shut down VTI interface toward another VPS and GRE on top of it,
enabled the plain GRE for transport SA. It works on one end, but not for
the other end which has to leave VTI with `remote any` up. How can the
transport SA match this `remote any`
On 22.12.2018 00:35, Marek Vasut wrote:
> Add driver for the NXP TJA1100 and TJA1101 PHYs. These PHYs are special
> BroadRReach 100BaseT1 PHYs used in automotive.
>
> Signed-off-by: Marek Vasut
> Cc: Andrew Lunn
> Cc: Florian Fainelli
> Cc: Heiner Kallweit
> ---
> V2: - Use phy_modify(), phy_{
On 22.12.2018 00:22, Marek Vasut wrote:
> On 12/15/2018 06:38 PM, Heiner Kallweit wrote:
>> On 15.12.2018 18:01, Andrew Lunn wrote:
+static struct tja11xx_phy_stats tja11xx_hw_stats[] = {
+ { "phy_symbol_error_count", 20, 0, 0x },
+ { "phy_overtemp_error", 21, 1, BIT(1) },
Hello!
On 21.12.2018 23:57, Florian Westphal wrote:
skb->sp doesn't exist anymore in the next-next tree, so mips defconfig
It's net-next. :-)
no longer builds. Use helper instead to reset the secpath.
Not even compile tested.
Cc: Greg Kroah-Hartman
Reported-by: Guenter Roeck
Fixes:
On 12/21/18, Deepa Dinamani wrote:
> diff --git a/include/net/sock.h b/include/net/sock.h
> index fe58aec00d09..2cb641606533 100644
> --- a/include/net/sock.h
> +++ b/include/net/sock.h
> @@ -2311,8 +2313,11 @@ sock_recv_timestamp(struct msghdr *msg, struct sock
> *sk, struct sk_buff *skb)
>
From: kbuild test robot
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c:1339:57-58: Unneeded semicolon
Remove unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
Fixes: 4c8fb2986d44 ("net/mlx5e: Increase VF representors' SQ size to 128")
CC: Gavi Teitz
Signed-off-by:
> Are we actually worried about concurrent writers here? I thought the
> only problem was a race between writer and reader, which would mean
> that we could solve it using only a seqcount_t which is cheaper to
> update than a seqlock_t.
I considered using just the seqcount_t. But, I think we do ca
On Fri, Dec 21, 2018 at 12:06:59PM -0500, Willem de Bruijn wrote:
> From: Willem de Bruijn
>
> Packet sockets with SOCK_DGRAM may pass an address for use in
> dev_hard_header. Ensure that it is of sufficient length.
>
> Reported-by: syzbot
> Signed-off-by: Willem de Bruijn
Willem,
We use mau
Avoid unneeded recreation of these in the incremental build.
Signed-off-by: Masahiro Yamada
---
arch/arm/mach-at91/Makefile | 2 ++
arch/arm/mach-omap2/Makefile| 2 ++
arch/ia64/kernel/Makefile | 2 ++
arch/x86/um/Makefile| 1 +
drivers/memory/Makefile.
On Fri, 21 Dec 2018 14:22:23 +0100
Domagoj Pintaric wrote:
> Add initial mvneta XDP support for hardware buffer management enabled
> devices only.
Hi Domagoj,
I would really appreciate if we could coordinate our work on the mvneta
driver. Ilias (Cc'ed) and I are also working on adding XDP supp
On Fri, 21 Dec 2018 at 20:57, Edgecombe, Rick P
wrote:
>
> On Fri, 2018-12-21 at 18:25 +0100, Ard Biesheuvel wrote:
> > On Fri, 21 Dec 2018 at 18:12, Andy Lutomirski
> > wrote:
> > > > On Dec 21, 2018, at 9:39 AM, Ard Biesheuvel <
> > > > ard.biesheu...@linaro.org> wrote:
> > > >
> > > > > On Wed
syzbot has found a reproducer for the following crash on:
HEAD commit:ce28bb445388 Merge git://git.kernel.org/pub/scm/linux/kern..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1673fb1b40
kernel config: https://syzkaller.appspot.com/x/.config?x=67a208
These explicit rules are unneeded because scripts/Makefile.build
provides a pattern rule to create %.s from %.c
Signed-off-by: Masahiro Yamada
---
Kbuild | 9 +
arch/arm/mach-at91/Makefile | 3 ---
arch/arm/mach-omap2/Makefile| 3 ---
arch/ia
47 matches
Mail list logo