Re: [PATCH 0/3]: net: dsa: mt7530: support MT7530 in the MT7621 SoC

[Greg Ungerer]

Hi John,

On 4/12/18 12:02 am, John Crispin wrote:

On 03/12/2018 15:00, René van Dorst wrote:

Quoting Bjørn Mork :

Greg Ungerer  writes:


The following change helped alot, but I still get some problems under
sustained load and some types of port setups. Still trying to figure
out what exactly is going on.

--- a/linux/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/linux/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1750,8 +1750,8 @@ static irqreturn_t mtk_handle_irq_rx(int irq, void *_eth)
   if (likely(napi_schedule_prep(>rx_napi))) {
    __napi_schedule(>rx_napi);
-   mtk_rx_irq_disable(eth, MTK_RX_DONE_INT);
    }
+   mtk_rx_irq_disable(eth, MTK_RX_DONE_INT);
   return IRQ_HANDLED;
 }
@@ -1762,11 +1762,53 @@ static irqreturn_t mtk_handle_irq_tx(int irq, void 
*_eth)
   if (likely(napi_schedule_prep(>tx_napi))) {
    __napi_schedule(>tx_napi);
-   mtk_tx_irq_disable(eth, MTK_TX_DONE_INT);
    }
+   mtk_tx_irq_disable(eth, MTK_TX_DONE_INT);
   return IRQ_HANDLED;
 }


Yes, sorry I didn't point to that as well.  Just to be clear:  I have no
clue how this thing is actually wired up, or if you could use three
interrupts on the MT7621 too. I just messed with it until I got
something to work, based on Renés original idea and code.


My idea is a just a copy of mtk_handle_irq_{rx,tx} see [1]
You probably want to look at the staging driver or Ubiquity source with a 
3.10.x kernel [2] or padavan with 3.4.x kernel [3].
AFAIK mt7621 only has 1 IRQ for ethernet part.


correct there is only 1 single IRQ on mt7621


One of the main differences I see between the mainline mtk_eth_soc.c
and the older mediatek/openwrt driver is that the older driver uses
the PDMA module for TX transmission, while the mainline uses the
QDMA module. I have no documentation on the what the differences
are between the 2 (or why there is even 2 DMA engines in there?).
Can you shed any light on that?

I did a quick and dirty recode of the QDMA transmission parts of
the mainline driver code to use the PDMA engine instead. The most
immediate result is that it suffers the same IP header checksum
problem on TX packets :-(  But it also still suffers from the
same occasional TX watchdog timeout I see with only the mainline
driver and basic support of MT7621.

What I see with the TX watchdog timeouts is that there is valid
TX descriptors, but the frame engine is just not processing them.
It seems to be just sitting there idle. The CTX and DTX registers
look valid and consistent with the local last_free/next_free
pointers.

Regards
Greg

Re: [PATCH 0/3]: net: dsa: mt7530: support MT7530 in the MT7621 SoC

[Greg Ungerer]

Hi Bjorn,

On 3/12/18 9:34 pm, Bjørn Mork wrote:

[ fixed Johns address - the openwrt.org email was apparently never restored? ]

Greg Ungerer  writes:


The following change helped alot, but I still get some problems under
sustained load and some types of port setups. Still trying to figure
out what exactly is going on.

--- a/linux/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/linux/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1750,8 +1750,8 @@ static irqreturn_t mtk_handle_irq_rx(int irq, void *_eth)
if (likely(napi_schedule_prep(>rx_napi))) {
 __napi_schedule(>rx_napi);
-   mtk_rx_irq_disable(eth, MTK_RX_DONE_INT);
 }
+   mtk_rx_irq_disable(eth, MTK_RX_DONE_INT);
return IRQ_HANDLED;
  }
@@ -1762,11 +1762,53 @@ static irqreturn_t mtk_handle_irq_tx(int irq, void 
*_eth)
if (likely(napi_schedule_prep(>tx_napi))) {
 __napi_schedule(>tx_napi);
-   mtk_tx_irq_disable(eth, MTK_TX_DONE_INT);
 }
+   mtk_tx_irq_disable(eth, MTK_TX_DONE_INT);
return IRQ_HANDLED;
  }


Yes, sorry I didn't point to that as well.  Just to be clear:  I have no
clue how this thing is actually wired up, or if you could use three
interrupts on the MT7621 too. I just messed with it until I got
something to work, based on Renés original idea and code.


Understood.

By way of progress I have found that making the single IRQ handler
look like this is better than the last patch:

static irqreturn_t mtk_handle_irq(int irq, void *_eth)
{
struct mtk_eth *eth = _eth;
irqreturn_t rc = IRQ_NONE;

if (mtk_r32(eth, MTK_PDMA_INT_MASK) & MTK_RX_DONE_INT) {
if (mtk_r32(eth, MTK_PDMA_INT_STATUS) & MTK_RX_DONE_INT)
rc = mtk_handle_irq_rx(irq, _eth);
}

if (mtk_r32(eth, MTK_QDMA_INT_MASK) & MTK_TX_DONE_INT) {
if (mtk_r32(eth, MTK_QMTK_INT_STATUS) & MTK_TX_DONE_INT)
rc = mtk_handle_irq_tx(irq, _eth);
}

return rc;
}

So not calling the RX or TX handlers if their interrupts
where not masked on. For some work loads that is quite reliable.
Flood ping through one port and out the other can get a lof of
packets through.

However I still get dev_watchdog timeouts after a while and with
more mixed packet loads. Seems like something is racing on the
TX path side.

Regards
Greg




Anyway, this really looks like the right approach to me. This driver is
clearly capable of supporting the mt7621 ethernet ports. No need for the
staging driver.


Great! Thanks for doing this.

I did make a feeble attempt at testing this with current mainline
myself, but the only MT7621 board I have is using NAND flash.  So I
started trying to forward port the mtk-nand2 driver from OpenWrt. And
failed. Probably a simple mixup while trying to adjust to the many
changes in the raw NAND API between v4.14 and v.4.20.  Then I
optimistically attempted to use the mainline mtk-nand driver instead,
assuming it would be as simple as with the mtk-eth driver.  Which it
wasn't, of course. I guess there are a lot of things I do not understand
wrt flash and HW ECC etc...

Short version: I won't be able to test the mainline mtk-eth driver with
MT7621 on newer kernels before smarter people like John upgrade the
OpenWrt kernel.


Bjørn

Re: [PATCH 0/3]: net: dsa: mt7530: support MT7530 in the MT7621 SoC

[Greg Ungerer]

Hi Bjorn,

On 30/11/18 10:16 pm, Bjørn Mork wrote:

g...@kernel.org writes:


I have been working towards supporting the MT7530 switch as used in the
MediaTek MT7621 SoC. Unlike the MediaTek MT7623 the MT7621 is built around
a dual core MIPS CPU architecture. But underneath it is what appears to
be the same 7530 switch.


Great!  Good to see someone pushing this idea forward.


The following 3 patches are more of an RFC than anything. They allow
use of the mt7530 dsa driver on this device - though with some issues
still to resolve. The primary change required is to not use the 7623
specific clock and regulator setup - none of that applies when using
the 7621 (and maybe other devices?). The other change required is to
set the 7530 MFC register CPU port number and enable bit.

The unresolved issues I still have appear to be more related to the
MT7621 ethernet driver (drivers/staging/mt7621-eth/*). I am hoping
someone might have some ideas on these. I don't really have any good
documentation on the ethernet devices on the 7621, so I am kind of
working in the dark here.


No offense, but the mt7621-eth driver in staging is horrible.  What both
René and I have had some success with is adapting the mtk_eth_soc driver
already in drivers/net/ethernet/mediatek/.  Yes, I know this is supposed
to be for other SoCs, but the basic design is obviously the same.

I have had some success with a first hackish attemt based on OpenWrt.
You can find the early tree here, but note that my focus was basically
getting one specific MT7621 board up and running:
https://github.com/bmork/LEDE/tree/mt7621-with-mainline-eth-driver

This patch has most of the necessary changes to enable that driver for
MT7621:
https://github.com/bmork/LEDE/commit/3293bc63f5461ca1eb0bbc4ed90145335e7e3404


I applied this to my main debug linux-4.19 kernel. Didn't apply completely
cleanly but was easy to fix up.

Using that everything came up detected (the 7530 switch) and I could
quickly see that it does not suffer the problems I listed below. Both
RX and TX packets of any size work!

However I also quickly discovered that this driver was pretty unstable.
Put a bit of packet load on it, and it would stop responding, CPU lock up,
and occasional rcu stalled messages from the kernel.

The following change helped alot, but I still get some problems under
sustained load and some types of port setups. Still trying to figure
out what exactly is going on.

--- a/linux/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/linux/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1750,8 +1750,8 @@ static irqreturn_t mtk_handle_irq_rx(int irq, void *_eth)
 
if (likely(napi_schedule_prep(>rx_napi))) {

__napi_schedule(>rx_napi);
-   mtk_rx_irq_disable(eth, MTK_RX_DONE_INT);
}
+   mtk_rx_irq_disable(eth, MTK_RX_DONE_INT);
 
return IRQ_HANDLED;

 }
@@ -1762,11 +1762,53 @@ static irqreturn_t mtk_handle_irq_tx(int irq, void 
*_eth)
 
if (likely(napi_schedule_prep(>tx_napi))) {

__napi_schedule(>tx_napi);
-   mtk_tx_irq_disable(eth, MTK_TX_DONE_INT);
}
+   mtk_tx_irq_disable(eth, MTK_TX_DONE_INT);
 
return IRQ_HANDLED;

 }


Anyway, this really looks like the right approach to me. This driver is
clearly capable of supporting the mt7621 ethernet ports. No need for the
staging driver.

Regards
Greg




Not a big deal, as you can see.  There is of course a reason I didn't
submit this here yet: It is by no means finished...  But it works. And I
have both GMACs working with this driver, which was my primary goal.


1. TX packets are not getting an IP header checksum via the normal
off-loaded checksumming when in DSA mode. I have to switch off
NETIF_F_IP_CSUM, so the software stack generates the checksum.
That checksum offloading works ok when not using the 7530 DSA driver.


Hmm.  How do I test this?


2. Maximal sized RX packets get silently dropped. So receive side packets
that are large (perfect case is the all-but-last packets in a fragemented
larger packet) appear to be dropped at the mt7621 ethernet MAC level.
The 7530 MIB switch register counters show receive packets at the physical
switch port side and at the CPU switch port - but I get no packets
received or errors in the 7621 ethernet MAC. If I set the mtu of the
server at the other end a little smaller (a few bytes is enough) then
I get all the packets through. It seems like the DSA/VLAN tag bytes
are causing a too large packet to get silently dropped somewhere.


Are you referring to the configured MTU size or some other maximal size?
If MTU, then I don't seem to have this issue with the driver from
drivers/net/ethernet/mediatek/.



Bjørn

Re: [PATCH 3/3] dt-bindings: net: dsa: add new bindings MT7530

[Greg Ungerer]

Hi Florian,

On 1/12/18 3:41 am, Florian Fainelli wrote:

Hi Greg,

On 11/29/2018 11:57 PM, g...@kernel.org wrote:

From: Greg Ungerer 

Add descriptive entries for the new bindings introduced to support the
MT7530 implementation in the MediaTek MT7621 SoC.

New bindings added for:

   mediatek,no-clock-regulator
   mediatek,mfc-has-cpuport


I don't think any of these properties are necessary, if you can either
use a compatible string, and/or infer the actual model at runtime in the
driver's probe function, then you can assess based on that chip model as


There is an ID register in the 7530 - though I don't know if the lower
16 bits of it can tell us enough information about the device. For me on
the MT7621 they return "0001", I assume it is a revsion ID of some type.
Problem is we do not read that until after the regulators and some of
the clocking is setup.

A compatible string of some description would be simple enough.
Are you thinking something like "mediatek,mt7621" before
"mediatek,mt7530"?



well as the properties being provided in Device Tree whether these
resources must be grabbed and used. See mv88e6xxx and b53 for how these
drivers deal with supporting several distinct models within the same
code base.


I will have a close look at those, thanks.



As far as the MFC programming goes, this is definitively something that
must be done once you know the chip model you are dealing with.


Yep, certainly.

Thanks
Greg

Re: [PATCH 0/3]: net: dsa: mt7530: support MT7530 in the MT7621 SoC

[Greg Ungerer]

Hi Andrew,

On 30/11/18 11:33 pm, Andrew Lunn wrote:

2. Maximal sized RX packets get silently dropped. So receive side packets
that are large (perfect case is the all-but-last packets in a fragemented
larger packet) appear to be dropped at the mt7621 ethernet MAC level.
The 7530 MIB switch register counters show receive packets at the physical
switch port side and at the CPU switch port - but I get no packets
received or errors in the 7621 ethernet MAC. If I set the mtu of the
server at the other end a little smaller (a few bytes is enough) then
I get all the packets through. It seems like the DSA/VLAN tag bytes
are causing a too large packet to get silently dropped somewhere.


Hi Gerg

Try increasing the MTU on the master device. Some hardware will reject
receiving packets bigger than the MTU. But if you increase the MTU by
the DSA header size, it will then receive the frame.


I tried increasing it on the master, and it fails to set:

 # ifconfig eth0 mut 1500
 # ifconfig eth0 mtu 1504
 eth0: mtu greater than device maximum
 SIOCSIFMTU: Invalid argument

Looking within that staging driver it seems to generously set the size
of the RX descriptor buffers, so there is enough room in them. And glancing
around the driver I don't see it using the MTU to restrict the receive
packaet size (though I may be missing it).



I have a patchset i will be posting soon to do this automatically.


That would be good.

Regards
Greg

Re: [PATCH 0/3]: net: dsa: mt7530: support MT7530 in the MT7621 SoC

[Greg Ungerer]

Hi Andrew,

On 30/11/18 11:37 pm, Andrew Lunn wrote:

1. TX packets are not getting an IP header checksum via the normal
off-loaded checksumming when in DSA mode. I have to switch off
NETIF_F_IP_CSUM, so the software stack generates the checksum.
That checksum offloading works ok when not using the 7530 DSA driver.


With some vendors MAC hardware, there is a field in the descriptor to
indicate how big a VLAN tag the frame has. The hardware can then use
this information to skip over the VLAN tags to find the IP header, and
then perform checksuming. You might be able to re-use that, consider
the DSA header as part of the VLAN header.

Other vendors, there is no way i've found to get hadware offload of
checksumming working.


Thanks for the tips, I will try out the master mtu change too.

Regards
Greg

Re: [PATCH 0/3]: net: dsa: mt7530: support MT7530 in the MT7621 SoC

[Greg Ungerer]

Hi Bjorn,

On 30/11/18 10:16 pm, Bjørn Mork wrote:

g...@kernel.org writes:


I have been working towards supporting the MT7530 switch as used in the
MediaTek MT7621 SoC. Unlike the MediaTek MT7623 the MT7621 is built around
a dual core MIPS CPU architecture. But underneath it is what appears to
be the same 7530 switch.


Great!  Good to see someone pushing this idea forward.


The following 3 patches are more of an RFC than anything. They allow
use of the mt7530 dsa driver on this device - though with some issues
still to resolve. The primary change required is to not use the 7623
specific clock and regulator setup - none of that applies when using
the 7621 (and maybe other devices?). The other change required is to
set the 7530 MFC register CPU port number and enable bit.

The unresolved issues I still have appear to be more related to the
MT7621 ethernet driver (drivers/staging/mt7621-eth/*). I am hoping
someone might have some ideas on these. I don't really have any good
documentation on the ethernet devices on the 7621, so I am kind of
working in the dark here.


No offense, but the mt7621-eth driver in staging is horrible.  What both
René and I have had some success with is adapting the mtk_eth_soc driver
already in drivers/net/ethernet/mediatek/.  Yes, I know this is supposed
to be for other SoCs, but the basic design is obviously the same.


Yes, that makes a lot of sense. I have only been working with the
linux mainline mt7621 staging driver so far for this mt7530 work.
(I started trying to make this work with linux 4.19).



I have had some success with a first hackish attemt based on OpenWrt.
You can find the early tree here, but note that my focus was basically
getting one specific MT7621 board up and running:
https://github.com/bmork/LEDE/tree/mt7621-with-mainline-eth-driver


Thats great, thanks for the pointer, I'll have a close look at that.



This patch has most of the necessary changes to enable that driver for
MT7621:
https://github.com/bmork/LEDE/commit/3293bc63f5461ca1eb0bbc4ed90145335e7e3404

Not a big deal, as you can see.  There is of course a reason I didn't
submit this here yet: It is by no means finished...  But it works. And I
have both GMACs working with this driver, which was my primary goal.


1. TX packets are not getting an IP header checksum via the normal
off-loaded checksumming when in DSA mode. I have to switch off
NETIF_F_IP_CSUM, so the software stack generates the checksum.
That checksum offloading works ok when not using the 7530 DSA driver.


Hmm.  How do I test this?


For me every transmitted packet had the wrong IP header checksum.
Every packet I received at the other end of the wire (dumped with
tcpdump) showed up with wrong header checksum. I am guessing you didn't
see this behavior - you can't really miss it :-)



2. Maximal sized RX packets get silently dropped. So receive side packets
that are large (perfect case is the all-but-last packets in a fragemented
larger packet) appear to be dropped at the mt7621 ethernet MAC level.
The 7530 MIB switch register counters show receive packets at the physical
switch port side and at the CPU switch port - but I get no packets
received or errors in the 7621 ethernet MAC. If I set the mtu of the
server at the other end a little smaller (a few bytes is enough) then
I get all the packets through. It seems like the DSA/VLAN tag bytes
are causing a too large packet to get silently dropped somewhere.


Are you referring to the configured MTU size or some other maximal size?
If MTU, then I don't seem to have this issue with the driver from
drivers/net/ethernet/mediatek/.


I was referring to the mtu on the system at the other end of the wire.
For me that was my development PC (just a xubuntu 18.04, x86 machine).
If I reduced it there from the default mtu of 1500 I could get packets
to be received on the mt7621. The behavior was obvious to see with large
sent packets (something simple like ping -s 2000), the first fragment was
silently dropped bu the second fragment would get through.

Anyway, I will try out the changes you have for the 
drivers/net/ethernet/mediatek
driver, they sound very promising.

Thanks
Greg

Re: [PATCH 0/3]: net: dsa: mt7530: support MT7530 in the MT7621 SoC

[Greg Ungerer]

Hi Rene,

On 30/11/18 9:27 pm, René van Dorst wrote:

Quoting g...@kernel.org:


I have been working towards supporting the MT7530 switch as used in the
MediaTek MT7621 SoC. Unlike the MediaTek MT7623 the MT7621 is built around
a dual core MIPS CPU architecture. But underneath it is what appears to
be the same 7530 switch.

The following 3 patches are more of an RFC than anything. They allow
use of the mt7530 dsa driver on this device - though with some issues
still to resolve. The primary change required is to not use the 7623
specific clock and regulator setup - none of that applies when using
the 7621 (and maybe other devices?). The other change required is to
set the 7530 MFC register CPU port number and enable bit.



Hi Greg,

Good to see that more people are working on the MT7621 device [1].
So I added Bjorn to the CC.


Nice, thanks for the pointers.



I am also working on this but on the OpenWRT side.
My current code works for a Ubiquiti EdgeRouter X SFP. See kernel [2], openwrt 
[3]


I forgot to mention I am working from mainline kernels, so those
patches of mine are against 4.20-rc4. I am working on some new
custom hardware at the moment, but I have an Oolite v8.0 board I
can run code on too.



Current status:

Using OpenWRT provided mainline v4.14 driver MT7530 and MT7623.
I patches so that MT7621 is supported.
This means DSA part is also working, internal and external phys are detected.
I can use all of the five RJ45 ports and also MT7520 switch port 5 which 
connects to a external phy (at8033) for the SFP port.
Last added TRGMII part also seems to work but with issues, see below.
Openwrt uses port 5 as wan and gets a dhcp lease.

Issues:
- I can't get 2nd GMAC talk to external phy. I have tried many many knobs but 
without success.
   GMAC seems to work but no data is transmitted/received over the cable.
   But I think this can be done later on. Adding basic support for MT7621 is 
good start.
- Ethernet driver expects that the macs are initialized so that the mtk_hw_init 
can setup the hardware registers.
   But they are not. See [4]
   I don't know how to fix this. For the current code it is not an issue. It 
still works.
   But it should be fixed.
   Because of this I can't read the mac0 "phy-mode". I need this info to setup 
the tgrmii clock at hardware init.
- Ethernet speed is unstable ~30-100mbit. I think I broke something. I have 
seems 1gbit before.

I hope that this can help you the get a step further.


Thanks, that is all good info.

Regards
Greg



René

[1] https://lists.openwrt.org/pipermail/openwrt-devel/2018-August/013614.html
[2] https://github.com/vDorst/linux-1/commits/mt7621-dsa-trgmii
[3] https://github.com/vDorst/openwrt/commits/mt7621-dsa-trgmii
[4] 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/ethernet/mediatek/mtk_eth_soc.c?h=v4.14.84#n1946

Re: [PATCH bpf] bpf: Fix integer overflow in queue_stack_map_alloc.

[Greg KH]

On Thu, Nov 22, 2018 at 11:59:02PM +0800, Wei Wu wrote:
> Integer overflow in queue_stack_map_alloc when calculating size may
> lead to heap overflow of arbitrary length.
> The patch fix it by checking whether attr->max_entries+1 <
> attr->max_entries and bailing out if it is the case.
> The vulnerability is discovered with the assistance of syzkaller.
> 
> Reported-by: Wei Wu 
> To: Alexei Starovoitov 
> Cc: Daniel Borkmann 
> Cc: netdev 
> Cc: Eric Dumazet 
> Cc: Greg KH 
> Signed-off-by: Wei Wu 
> ---
>  kernel/bpf/queue_stack_maps.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/kernel/bpf/queue_stack_maps.c b/kernel/bpf/queue_stack_maps.c
> index 8bbd72d3a121..c35a8a4721c8 100644
> --- a/kernel/bpf/queue_stack_maps.c
> +++ b/kernel/bpf/queue_stack_maps.c
> @@ -67,6 +67,8 @@ static struct bpf_map *queue_stack_map_alloc(union
> bpf_attr *attr)
>   u64 queue_size, cost;
> 
>   size = attr->max_entries + 1;
> + if (size < attr->max_entries)
> + return ERR_PTR(-EINVAL);
>   value_size = attr->value_size;

Your tabs got eaten by your email client and they all disappeared,
making the patch impossible to apply :(

Care to try again?

thanks,

greg k-h

Re: Application of f8b39039cbf2a15f ("net: fs_enet: do not call phy_stop() in interrupts") to 4.9 and 4.14 stable

[Greg KH]

On Wed, Oct 17, 2018 at 02:08:41PM +0200, Christophe LEROY wrote:
> Hi,
> 
> Could you please apply f8b39039cbf2a15f2b8c9f081e1cbd5dee00aaf5 to 4.9 and
> 4.14 ?
> 
> It fixes an Oops when Ethernet transmission times out.
> 
> As you can observe in the commit log, the Oops what initially observed in
> 4.9.
> 
> The fix has been in mainline since 4.15

And it was released in 4.9.136 and 4.14.80 already :)

thanks,

greg k-h

Re: [PATCH stable 4.9 v2 00/29] backport of IP fragmentation fixes

[Greg Kroah-Hartman]

On Mon, Oct 15, 2018 at 10:53:02AM -0700, Eric Dumazet wrote:
> On Mon, Oct 15, 2018 at 10:47 AM Florian Fainelli  
> wrote:
> >
> >
> >
> > On 10/10/2018 12:29 PM, Florian Fainelli wrote:
> > > This is based on Stephen's v4.14 patches, with the necessary merge
> > > conflicts, and the lack of timer_setup() on the 4.9 baseline.
> > >
> > > Perf results on a gigabit capable system, before and after are below.
> > >
> > > Series can also be found here:
> > >
> > > https://github.com/ffainelli/linux/commits/fragment-stack-v4.9-v2
> > >
> > > Changes in v2:
> > >
> > > - drop "net: sk_buff rbnode reorg"
> > > - added original "ip: use rb trees for IP frag queue." commit
> >
> > Eric, does this look reasonable to you?
> 
> Yes, thanks a lot Florian.

Wonderful, all now queued up, thanks!

greg k-h

Re: [PATCH stable 4.4 V2 0/6] fix SegmentSmack in stable branch (CVE-2018-5390)

[Greg KH]

On Wed, Sep 26, 2018 at 10:21:21PM +0200, Greg KH wrote:
> On Tue, Sep 25, 2018 at 10:10:15PM +0800, maowenan wrote:
> > Hi Greg:
> > 
> > can you review this patch set?
> 
> It is still in the queue, don't worry.  It will take some more time to
> properly review and test it.
> 
> Ideally you could get someone else to test this and provide a
> "tested-by:" tag for it?

All now queued up, let's see what breaks :)

thanks,

greg k-h

Re: [PATCH v3 00/30] backport of IP fragmentation fixes

[Greg KH]

On Thu, Sep 13, 2018 at 07:58:32AM -0700, Stephen Hemminger wrote:
> Took the set of patches from 4.19 to handle IP fragmentation DoS
> and applied them against 4.14.69.  Most of these are from Eric.
> In a couple case, it required some manual merge conflict resolution.
> 
> Tested normal IP fragmentation with iperf3 and malicious IP fragments
> with fragmentsmack. Under fragmentation attack (700Kpps) the original
> 4.14.69 consumes 97% CPU; with this patch it drops to 5%.

All now queued up, thanks for doing the backport.

greg k-h

Re: [PATCH stable 4.4 0/9] fix SegmentSmack in stable branch (CVE-2018-5390)

[Greg KH]

On Thu, Aug 16, 2018 at 05:24:09PM +0200, Greg KH wrote:
> On Thu, Aug 16, 2018 at 02:33:56PM +0200, Michal Kubecek wrote:
> > On Thu, Aug 16, 2018 at 08:05:50PM +0800, maowenan wrote:
> > > On 2018/8/16 19:39, Michal Kubecek wrote:
> > > > 
> > > > I suspect you may be doing something wrong with your tests. I checked
> > > > the segmentsmack testcase and the CPU utilization on receiving side
> > > > (with sending 10 times as many packets as default) went down from ~100%
> > > > to ~3% even when comparing what is in stable 4.4 now against older 4.4
> > > > kernel.
> > > 
> > > There seems no obvious problem when you send packets with default
> > > parameter in Segmentsmack POC, Which is also very related with your
> > > server's hardware configuration. Please try with below parameter to
> > > form OFO packets
> > 
> > I did and even with these (questionable, see below) changes, I did not
> > get more than 10% (of one core) by receiving ksoftirqd.
> > 
> > >   for (i = 0; i < 1024; i++)  // 128->1024
> > ...
> > >   usleep(10*1000); // Adjust this and packet count to match the 
> > > target!, sleep 100ms->10ms
> > 
> > The comment in the testcase source suggests to do _one_ of these two
> > changes so that you generate 10 times as many packets as the original
> > testcase. You did both so that you end up sending 102400 packets per
> > second. With 55 byte long packets, this kind of attack requires at least
> > 5.5 MB/s (44 Mb/s) of throughput. This is no longer a "low packet rate
> > DoS", I'm afraid.
> > 
> > Anyway, even at this rate, I only get ~10% of one core (Intel E5-2697).
> > 
> > What I can see, though, is that with current stable 4.4 code, modified
> > testcase which sends something like
> > 
> >   2:3, 3:4, ..., 3001:3002, 3003:3004, 3004:3005, ... 6001:6002, ...
> > 
> > I quickly eat 6 MB of memory for receive queue of one socket while
> > earlier 4.4 kernels only take 200-300 KB. I didn't test latest 4.4 with
> > Takashi's follow-up yet but I'm pretty sure it will help while
> > preserving nice performance when using the original segmentsmack
> > testcase (with increased packet ratio).
> 
> Ok, for now I've applied Takashi's fix to the 4.4 stable queue and will
> push out a new 4.4-rc later tonight.  Can everyone standardize on that
> and test and let me know if it does, or does not, fix the reported
> issues?
> 
> If not, we can go from there and evaluate this much larger patch series.
> But let's try the simple thing first.

So, is the issue still present on the latest 4.4 release?  Has anyone
tested it?  If not, I'm more than willing to look at backported patches,
but I want to ensure that they really are needed here.

thanks,

greg k-h

Re: [PATCH 0/2] staging: Fix some warnings from strncpy()

[Greg KH]

On Mon, Aug 20, 2018 at 12:51:22PM -0500, Larry Finger wrote:
> When the size argument in a call to strncpy() is the size of the
> destimation, gcc8 issues a warning. These patches fix the potential
> problem by replacing the strncpy() with strlcpy().
> 
> Signed-off-by: Larry Finger 
> 
> 
> Larry Finger (2):
>   staging: rtl8192e: Fix compiler warning about strncpy
>   staging: rtl8712u: Fix compiler warning about strncpy
> 
>  drivers/staging/rtl8192e/rtllib_softmac.c | 4 ++--
>  drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)

I'm guessing you will send a second set of this patch series, right?
This one is now dropped, thanks.

greg k-h

Re: [PATCH stable 4.4 0/9] fix SegmentSmack in stable branch (CVE-2018-5390)

[Greg KH]

On Thu, Aug 16, 2018 at 06:06:16PM +0200, Michal Kubecek wrote:
> > If not, we can go from there and evaluate this much larger patch
> > series.  But let's try the simple thing first.
> 
> At high packet rates (say 30K pkt/s and more), we can still saturate the
> CPU. This is also mentioned in the announcement with claim that switch
> to rbtree based queue would be necessary to fully address that. My tests
> seem to confirm that but I'm still not sure it is worth backporting
> something as intrusive into stable 4.4.

No, it is not.  If you worry about those things, you should not be
running a 4.4 kernel, use 4.14 or newer please.

thanks,

greg k-h

Re: [PATCH stable 4.4 0/9] fix SegmentSmack in stable branch (CVE-2018-5390)

[Greg KH]

On Thu, Aug 16, 2018 at 02:33:56PM +0200, Michal Kubecek wrote:
> On Thu, Aug 16, 2018 at 08:05:50PM +0800, maowenan wrote:
> > On 2018/8/16 19:39, Michal Kubecek wrote:
> > > 
> > > I suspect you may be doing something wrong with your tests. I checked
> > > the segmentsmack testcase and the CPU utilization on receiving side
> > > (with sending 10 times as many packets as default) went down from ~100%
> > > to ~3% even when comparing what is in stable 4.4 now against older 4.4
> > > kernel.
> > 
> > There seems no obvious problem when you send packets with default
> > parameter in Segmentsmack POC, Which is also very related with your
> > server's hardware configuration. Please try with below parameter to
> > form OFO packets
> 
> I did and even with these (questionable, see below) changes, I did not
> get more than 10% (of one core) by receiving ksoftirqd.
> 
> >   for (i = 0; i < 1024; i++)  // 128->1024
> ...
> >   usleep(10*1000); // Adjust this and packet count to match the 
> > target!, sleep 100ms->10ms
> 
> The comment in the testcase source suggests to do _one_ of these two
> changes so that you generate 10 times as many packets as the original
> testcase. You did both so that you end up sending 102400 packets per
> second. With 55 byte long packets, this kind of attack requires at least
> 5.5 MB/s (44 Mb/s) of throughput. This is no longer a "low packet rate
> DoS", I'm afraid.
> 
> Anyway, even at this rate, I only get ~10% of one core (Intel E5-2697).
> 
> What I can see, though, is that with current stable 4.4 code, modified
> testcase which sends something like
> 
>   2:3, 3:4, ..., 3001:3002, 3003:3004, 3004:3005, ... 6001:6002, ...
> 
> I quickly eat 6 MB of memory for receive queue of one socket while
> earlier 4.4 kernels only take 200-300 KB. I didn't test latest 4.4 with
> Takashi's follow-up yet but I'm pretty sure it will help while
> preserving nice performance when using the original segmentsmack
> testcase (with increased packet ratio).

Ok, for now I've applied Takashi's fix to the 4.4 stable queue and will
push out a new 4.4-rc later tonight.  Can everyone standardize on that
and test and let me know if it does, or does not, fix the reported
issues?

If not, we can go from there and evaluate this much larger patch series.
But let's try the simple thing first.

thanks,

greg k-h

Re: [PATCH stable 4.4 1/9] Revert "tcp: detect malicious patterns in tcp_collapse_ofo_queue()"

[Greg KH]

On Thu, Aug 16, 2018 at 09:55:42AM +0800, maowenan wrote:
> 
> 
> On 2018/8/15 21:18, Greg KH wrote:
> > On Wed, Aug 15, 2018 at 09:21:00PM +0800, Mao Wenan wrote:
> >> This reverts commit dc6ae4dffd656811dee7151b19545e4cd839d378.
> > 
> > I need a reason why, and a signed-off-by line :(
> 
> stable 4.4 only back port two patches to fix CVE-2018-5390, I have tested 
> they can't
> fix fully because of simple queue used in lower version, so we need change 
> simple queue
> to RB tree to finally resolve. But 9f5afeae have many conflicts with tcp: 
> detect malicious patterns in tcp_collapse_ofo_queue()
> and tcp: avoid collapses in tcp_prune_queue() if possible, and there are 
> patch series from Eric in mainline to fix CVE-2018-5390,
> so I need revert part of patches in stable 4.4 firstly, then apply 9f5afeae, 
> and reapply five patches from Eric.
> 9f5afeae tcp: use an RB tree for ooo receive queue

Then please put this information in the changelog text, that's what we
need to see here.

thanks,

greg k-h

Re: [PATCH stable 4.4 0/9] fix SegmentSmack (CVE-2018-5390)

[Greg KH]

On Wed, Aug 15, 2018 at 03:24:32PM +0200, Greg KH wrote:
> On Wed, Aug 15, 2018 at 09:20:59PM +0800, Mao Wenan wrote:
> > There are five patches to fix CVE-2018-5390 in latest mainline 
> > branch, but only two patches exist in stable 4.4 and 3.18: 
> > dc6ae4d tcp: detect malicious patterns in tcp_collapse_ofo_queue()
> > 5fbec48 tcp: avoid collapses in tcp_prune_queue() if possible
> > but I have tested with these patches, and found the cpu usage was very high.
> > test results:
> > with fix patch： 78.2%   ksoftirqd
> > no fix patch：   90% ksoftirqd
> > 
> > After analysing the codes of stable 4.4, and debuging the 
> > system, the search of ofo_queue(tcp ofo using a simple queue) cost more 
> > cycles.
> > So I think only two patches can't fix the CVE-2018-5390.
> > So I try to backport "tcp: use an RB tree for ooo receive queue" using RB 
> > tree 
> > instead of simple queue, then backport Eric Dumazet 5 fixed patches in 
> > mainline,
> > good news is that ksoftirqd is turn to about 20%, which is the same with 
> > mainline now.
> 
> Thanks for doing this work, I had some questions on the individual
> patches.  Can you address them and resend?

Also, always cc: the stable@vger list when sending stable patches so
that others can review and comment on them.

thanks,

greg k-h

Re: [PATCH stable 4.4 4/9] tcp: use an RB tree for ooo receive queue

[Greg KH]

On Wed, Aug 15, 2018 at 09:21:03PM +0800, Mao Wenan wrote:
> From: Yaogong Wang 
> 
> Over the years, TCP BDP has increased by several orders of magnitude,
> and some people are considering to reach the 2 Gbytes limit.
> 
> Even with current window scale limit of 14, ~1 Gbytes maps to ~740,000
> MSS.
> 
> In presence of packet losses (or reorders), TCP stores incoming packets
> into an out of order queue, and number of skbs sitting there waiting for
> the missing packets to be received can be in the 10^5 range.
> 
> Most packets are appended to the tail of this queue, and when
> packets can finally be transferred to receive queue, we scan the queue
> from its head.
> 
> However, in presence of heavy losses, we might have to find an arbitrary
> point in this queue, involving a linear scan for every incoming packet,
> throwing away cpu caches.
> 
> This patch converts it to a RB tree, to get bounded latencies.
> 
> Yaogong wrote a preliminary patch about 2 years ago.
> Eric did the rebase, added ofo_last_skb cache, polishing and tests.
> 
> Tested with network dropping between 1 and 10 % packets, with good
> success (about 30 % increase of throughput in stress tests)
> 
> Next step would be to also use an RB tree for the write queue at sender
> side ;)
> 
> Signed-off-by: Yaogong Wang 
> Signed-off-by: Eric Dumazet 
> Cc: Yuchung Cheng 
> Cc: Neal Cardwell 
> Cc: Ilpo Järvinen 
> Acked-By: Ilpo Järvinen 
> Signed-off-by: David S. Miller 
> Signed-off-by: root 

root and commit id?

Re: [PATCH stable 4.4 6/9] tcp: avoid collapses in tcp_prune_queue() if possible

[Greg KH]

On Wed, Aug 15, 2018 at 09:21:05PM +0800, Mao Wenan wrote:
> From: Eric Dumazet 
> 
> [ Upstream commit f4a3313d8e2ca9fd8d8f45e40a2903ba782607e7 ]
> 
> Right after a TCP flow is created, receiving tiny out of order
> packets allways hit the condition :
> 
> if (atomic_read(>sk_rmem_alloc) >= sk->sk_rcvbuf)
>   tcp_clamp_window(sk);
> 
> tcp_clamp_window() increases sk_rcvbuf to match sk_rmem_alloc
> (guarded by tcp_rmem[2])
> 
> Calling tcp_collapse_ofo_queue() in this case is not useful,
> and offers a O(N^2) surface attack to malicious peers.
> 
> Better not attempt anything before full queue capacity is reached,
> forcing attacker to spend lots of resource and allow us to more
> easily detect the abuse.
> 
> Signed-off-by: Eric Dumazet 
> Acked-by: Soheil Hassas Yeganeh 
> Acked-by: Yuchung Cheng 
> Signed-off-by: David S. Miller 
> Signed-off-by: Greg Kroah-Hartman 
> Signed-off-by: root 

root?

Re: [PATCH stable 4.4 5/9] tcp: free batches of packets in tcp_prune_ofo_queue()

[Greg KH]

On Wed, Aug 15, 2018 at 09:21:04PM +0800, Mao Wenan wrote:
> From: Eric Dumazet 
> 
> Juha-Matti Tilli reported that malicious peers could inject tiny
> packets in out_of_order_queue, forcing very expensive calls
> to tcp_collapse_ofo_queue() and tcp_prune_ofo_queue() for
> every incoming packet. out_of_order_queue rb-tree can contain
> thousands of nodes, iterating over all of them is not nice.
> 
> Before linux-4.9, we would have pruned all packets in ofo_queue
> in one go, every  packets.  depends on sk_rcvbuf and skbs
> truesize, but is about 7000 packets with tcp_rmem[2] default of 6 MB.
> 
> Since we plan to increase tcp_rmem[2] in the future to cope with
> modern BDP, can not revert to the old behavior, without great pain.
> 
> Strategy taken in this patch is to purge ~12.5 % of the queue capacity.
> 
> Fixes: 36a6503fedda ("tcp: refine tcp_prune_ofo_queue() to not drop all 
> packets")
> Signed-off-by: Eric Dumazet 
> Reported-by: Juha-Matti Tilli 
> Acked-by: Yuchung Cheng 
> Acked-by: Soheil Hassas Yeganeh 
> Signed-off-by: David S. Miller 
> Signed-off-by: root 

root?

And commit id?

thanks,

greg k-h

Re: [PATCH stable 4.4 9/9] tcp: add tcp_ooo_try_coalesce() helper

[Greg KH]

On Wed, Aug 15, 2018 at 09:21:08PM +0800, Mao Wenan wrote:
> From: Eric Dumazet 
> 
> In case skb in out_or_order_queue is the result of
> multiple skbs coalescing, we would like to get a proper gso_segs
> counter tracking, so that future tcp_drop() can report an accurate
> number.
> 
> I chose to not implement this tracking for skbs in receive queue,
> since they are not dropped, unless socket is disconnected.
> 
> Signed-off-by: Eric Dumazet 
> Acked-by: Soheil Hassas Yeganeh 
> Acked-by: Yuchung Cheng 
> Signed-off-by: David S. Miller 
> Signed-off-by: Mao Wenan 

Upstream commit id?

Re: [PATCH stable 4.4 0/9] fix SegmentSmack (CVE-2018-5390)

[Greg KH]

On Wed, Aug 15, 2018 at 09:20:59PM +0800, Mao Wenan wrote:
> There are five patches to fix CVE-2018-5390 in latest mainline 
> branch, but only two patches exist in stable 4.4 and 3.18: 
> dc6ae4d tcp: detect malicious patterns in tcp_collapse_ofo_queue()
> 5fbec48 tcp: avoid collapses in tcp_prune_queue() if possible
> but I have tested with these patches, and found the cpu usage was very high.
> test results:
> with fix patch： 78.2%   ksoftirqd
> no fix patch：   90% ksoftirqd
> 
> After analysing the codes of stable 4.4, and debuging the 
> system, the search of ofo_queue(tcp ofo using a simple queue) cost more 
> cycles.
> So I think only two patches can't fix the CVE-2018-5390.
> So I try to backport "tcp: use an RB tree for ooo receive queue" using RB 
> tree 
> instead of simple queue, then backport Eric Dumazet 5 fixed patches in 
> mainline,
> good news is that ksoftirqd is turn to about 20%, which is the same with 
> mainline now.

Thanks for doing this work, I had some questions on the individual
patches.  Can you address them and resend?

thanks,

greg k-h

Re: [PATCH stable 4.4 8/9] tcp: call tcp_drop() from tcp_data_queue_ofo()

[Greg KH]

On Wed, Aug 15, 2018 at 09:21:07PM +0800, Mao Wenan wrote:
> From: Eric Dumazet 
> 
> In order to be able to give better diagnostics and detect
> malicious traffic, we need to have better sk->sk_drops tracking.
> 
> Fixes: 9f5afeae5152 ("tcp: use an RB tree for ooo receive queue")
> Signed-off-by: Eric Dumazet 
> Acked-by: Soheil Hassas Yeganeh 
> Acked-by: Yuchung Cheng 
> Signed-off-by: David S. Miller 
> Signed-off-by: Mao Wenan 
> ---
>  net/ipv4/tcp_input.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Upstream commit id?

Re: [PATCH stable 4.4 3/9] tcp: increment sk_drops for dropped rx packets

[Greg KH]

On Wed, Aug 15, 2018 at 09:21:02PM +0800, Mao Wenan wrote:
> From: Eric Dumazet 
> 
> Now ss can report sk_drops, we can instruct TCP to increment
> this per socket counter when it drops an incoming frame, to refine
> monitoring and debugging.
> 
> Following patch takes care of listeners drops.
> 
> Signed-off-by: Eric Dumazet 
> Signed-off-by: David S. Miller 
> Signed-off-by: Mao Wenan 

What is the upstream git commit id for this?

thanks,

greg k-h

Re: [PATCH stable 4.4 7/9] tcp: detect malicious patterns in tcp_collapse_ofo_queue()

[Greg KH]

On Wed, Aug 15, 2018 at 09:21:06PM +0800, Mao Wenan wrote:
> From: Eric Dumazet 
> 
> [ Upstream commit 3d4bf93ac12003f9b8e1e2de37fe27983deebdcf ]
> 
> In case an attacker feeds tiny packets completely out of order,
> tcp_collapse_ofo_queue() might scan the whole rb-tree, performing
> expensive copies, but not changing socket memory usage at all.
> 
> 1) Do not attempt to collapse tiny skbs.
> 2) Add logic to exit early when too many tiny skbs are detected.
> 
> We prefer not doing aggressive collapsing (which copies packets)
> for pathological flows, and revert to tcp_prune_ofo_queue() which
> will be less expensive.
> 
> In the future, we might add the possibility of terminating flows
> that are proven to be malicious.
> 
> Signed-off-by: Eric Dumazet 
> Acked-by: Soheil Hassas Yeganeh 
> Signed-off-by: David S. Miller 
> Signed-off-by: Greg Kroah-Hartman 
> Signed-off-by: root 

signed off by from "root"?  :)

And why are you adding the patch back after removing it?

thanks,

greg k-h

Re: [PATCH stable 4.4 2/9] Revert "tcp: avoid collapses in tcp_prune_queue() if possible"

[Greg KH]

On Wed, Aug 15, 2018 at 09:21:01PM +0800, Mao Wenan wrote:
> This reverts commit 5fbec4801264cb3279ef6ac9c70bcbe2aaef89d5.
> ---

Same here for description and signed off by.

thanks,

greg k-h

Re: [PATCH stable 4.4 1/9] Revert "tcp: detect malicious patterns in tcp_collapse_ofo_queue()"

[Greg KH]

On Wed, Aug 15, 2018 at 09:21:00PM +0800, Mao Wenan wrote:
> This reverts commit dc6ae4dffd656811dee7151b19545e4cd839d378.

I need a reason why, and a signed-off-by line :(

thanks,

greg k-h

Re: [PATCH 4.9-stable] tcp: add tcp_ooo_try_coalesce() helper

[Greg KH]

On Thu, Aug 09, 2018 at 08:37:13PM +0800, maowenan wrote:
> 
> 
> On 2018/8/7 21:22, Greg KH wrote:
> > On Sat, Aug 04, 2018 at 10:10:00AM +0100, David Woodhouse wrote:
> >> From: Eric Dumazet 
> >>
> >> commit 58152ecbbcc6a0ce7fddd5bf5f6ee535834ece0c upstream.
> >>
> >> In case skb in out_or_order_queue is the result of
> >> multiple skbs coalescing, we would like to get a proper gso_segs
> >> counter tracking, so that future tcp_drop() can report an accurate
> >> number.
> >>
> >> I chose to not implement this tracking for skbs in receive queue,
> >> since they are not dropped, unless socket is disconnected.
> >>
> >> Signed-off-by: Eric Dumazet 
> >> Acked-by: Soheil Hassas Yeganeh 
> >> Acked-by: Yuchung Cheng 
> >> Signed-off-by: David S. Miller 
> >> Signed-off-by: David Woodhouse 
> >> ---
> >>  net/ipv4/tcp_input.c | 23 +--
> >>  1 file changed, 21 insertions(+), 2 deletions(-)
> > 
> > Now applied, thanks,
> > 
> > greg k-h
> > 
> > .
> > 
> 
> Hello,
> 
> There are two patches in stable branch linux-4.4, but I have tested with 
> below patches, and found that the cpu usage was very high.
> dc6ae4d tcp: detect malicious patterns in tcp_collapse_ofo_queue()
> 5fbec48 tcp: avoid collapses in tcp_prune_queue() if possible
> 
> test results:
> with fix patch： 78.2%   ksoftirqd
> no fix patch：   90% ksoftirqd
> 
> there is %0 when no attack packets.
> 
> so please help verify that fixed patches are enough in linux-stable 4.4.
> 

I do not know, I am not a network developer.  Please try to reproduce
the same thing on a newer kernel release and see if the result is the
same or not.  If you can find a change that I missed, please let me know
and I will be glad to apply it.

thnaks,

greg k-h

Re: [PATCH 4.9-stable] tcp: add tcp_ooo_try_coalesce() helper

[Greg KH]

On Sat, Aug 04, 2018 at 10:10:00AM +0100, David Woodhouse wrote:
> From: Eric Dumazet 
> 
> commit 58152ecbbcc6a0ce7fddd5bf5f6ee535834ece0c upstream.
> 
> In case skb in out_or_order_queue is the result of
> multiple skbs coalescing, we would like to get a proper gso_segs
> counter tracking, so that future tcp_drop() can report an accurate
> number.
> 
> I chose to not implement this tracking for skbs in receive queue,
> since they are not dropped, unless socket is disconnected.
> 
> Signed-off-by: Eric Dumazet 
> Acked-by: Soheil Hassas Yeganeh 
> Acked-by: Yuchung Cheng 
> Signed-off-by: David S. Miller 
> Signed-off-by: David Woodhouse 
> ---
>  net/ipv4/tcp_input.c | 23 +--
>  1 file changed, 21 insertions(+), 2 deletions(-)

Now applied, thanks,

greg k-h

Re: [PATCH 3.18.y] Fix compilation error backporting upstream commit 9fc12023d6f5

[Greg KH]

On Sat, Aug 04, 2018 at 02:27:41PM +0200, Lorenzo Bianconi wrote:
> Fix following compilation error backporting upstream commit
> 9fc12023d6f5 ("ipv4: remove BUG_ON() from fib_compute_spec_dst)
> 
> net/ipv4/fib_frontend.c: In function 'fib_compute_spec_dst':
> net/ipv4/fib_frontend.c:225:3: error: expected expression before 'if'
>if (!fib_lookup(net, , ))
> 
> net/ipv4/fib_frontend.c:200:20: warning: unused variable 'res'
>   struct fib_result res;
> 
> Fixes: 0e46da6c6fac ("ipv4: remove BUG_ON() from fib_compute_spec_dst")
> Signed-off-by: Lorenzo Bianconi 
> ---
>  net/ipv4/fib_frontend.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
> index 924db4bedd88..0b29649627a7 100644
> --- a/net/ipv4/fib_frontend.c
> +++ b/net/ipv4/fib_frontend.c
> @@ -221,7 +221,7 @@ __be32 fib_compute_spec_dst(struct sk_buff *skb)
>   fl4.saddr = 0;
>   fl4.flowi4_tos = RT_TOS(ip_hdr(skb)->tos);
>   fl4.flowi4_scope = scope;
> - fl4.flowi4_mark = vmark ? skb->mark : 0,
> + fl4.flowi4_mark = vmark ? skb->mark : 0;
>   if (!fib_lookup(net, , ))
>   return FIB_RES_PREFSRC(net, res);
>   } else {

Thanks, but I fixed this about 6 hours ago, right?

greg k-h

Re: [PATCH net 0/5] tcp: more robust ooo handling

[Greg KH]

On Fri, Aug 03, 2018 at 04:53:27PM -0700, David Miller wrote:
> From: David Woodhouse 
> Date: Fri, 03 Aug 2018 11:55:37 +0100
> 
> > I see the first four in 4.9.116 but not the fifth (adding
> > tcp_ooo_try_coalesce()).
> > 
> > Is that intentional? 
> 
> I don't work on the 4.9 -stable backports, so I personally have
> no idea.
> 
> I submitted for 4.17 and 4.14

Ok, then it's my fault :)

Odds are it did not apply and so I didn't backport it.  If you think it
should be there, please provide a working backport.

thanks,

greg k-h

Re: 862591bf4("xfrm: skip policies marked as dead while rehashing")

[Greg KH]

On Wed, Jun 20, 2018 at 05:42:51PM -0400, Zubin Mithra wrote:
> Hello,
> 
> Syzkaller has reported a crash here[1] for a slab OOB read in
> xfrm_hash_rebuild.
> 
> Could the following 2 patches be applied in order to on 4.4.y?
> 
> 6916fb3b10("xfrm: Ignore socket policies when rebuilding hash tables")
> 862591bf4f("xfrm: skip policies marked as dead while rehashing")
> 
> [1] 
> https://syzkaller.appspot.com/bug?id=1c11a638b7d27e871aa297f3b4d5fd5bc90f0cb4

Both now queued up, thanks.

greg k-h

Re: Incomplete fix for be9c798 / 7b2ee50 hv_netvsc: common detach logic?

[Greg KH]

On Tue, Jun 19, 2018 at 03:19:41PM -0400, Thomas Walker wrote:
> Upon updating some internal kernels from 4.14.18 to 4.14.49, our hyper-v 
> guests failed to bring up network interfaces on boot, logging "A link change 
> request failed with some changes committed already. Interface eth0 may have 
> been left with an inconsistent configuration, please check."  Running 
> 'ifconfig eth0 up' appears to fix the problem temporarily so I went about 
> bisecting which landed on:
> 
> commit be9c798d0d13ae609a91177323ac816545c39d28
> Author: Stephen Hemminger 
> Date:   Mon May 14 15:32:18 2018 -0700
> 
> hv_netvsc: common detach logic
> 
> [ Commit 7b2ee50c0cd513a176a26a71f2989facdd75bfea upstream. ]
> 
> Make common function for detaching internals of device
> during changes to MTU and RSS. Make sure no more packets
> are transmitted and all packets have been received before
> doing device teardown.
> 
> Change the wait logic to be common and use usleep_range().
> 
> Changes transmit enabling logic so that transmit queues are disabled
> during the period when lower device is being changed. And enabled
> only after sub channels are setup. This avoids issue where it could
> be that a packet was being sent while subchannel was not initialized.
> 
> Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug")
> Signed-off-by: Stephen Hemminger 
> Signed-off-by: David S. Miller 
> Signed-off-by: Greg Kroah-Hartman 
> 
> 
> The removal of which does indeed fix the problem.  That led me to:
> 
> commit 52acf73b6e9a6962045feb2ba5a8921da2201915
> Author: Dexuan Cui 
> Date:   Wed Jun 6 21:32:51 2018 +
> 
> hv_netvsc: Fix a network regression after ifdown/ifup
> 
> Recently people reported the NIC stops working after
> "ifdown eth0; ifup eth0". It turns out in this case the TX queues are not
> enabled, after the refactoring of the common detach logic: when the NIC
> has sub-channels, usually we enable all the TX queues after all
> sub-channels are set up: see rndis_set_subchannel() ->
> netif_device_attach(), but in the case of "ifdown eth0; ifup eth0" where
> the number of channels doesn't change, we also must make sure the TX 
> queues
> are enabled. The patch fixes the regression.
> 
> Fixes: 7b2ee50c0cd5 ("hv_netvsc: common detach logic")
> Signed-off-by: Dexuan Cui 
> Cc: Stephen Hemminger 
> Cc: K. Y. Srinivasan 
> Cc: Haiyang Zhang 
> Signed-off-by: David S. Miller 
> 
> Which sounded very promising, but does not seem to fully fix the issue.  
> Doing some more digging, I was able to determine that the message coincides 
> with 'ip link set dev eth0 mtu 1300 up' very shortly (>~1 second) after the 
> hv_netvsc driver loads.  If I delay the mtu change until well after the 
> driver loads, everything works fine.  If I unload hv_netvsc and then reload 
> it and apply the mtu change immediately, the failure re-occurs.  So something 
> is racy here, and the above doesn't entirely address it.
> 
> I'm happy to test out any suggested patches and/or do additional debugging if 
> anyone has any suggestions.
> 
> (oh, and I did also try 4.18-rc1 and the problem still persists)

Always cc: the authors of the patch you are having problems with, along
with the mailing list for the networking subsystem, so that the right
people know to look at this.

Now fixed...

thanks,

greg k-h

Re: [Patch net-next] netdev-FAQ: clarify DaveM's position for stable backports

[Greg KH]

On Mon, Jun 04, 2018 at 11:07:19AM -0700, Cong Wang wrote:
> Per discussion with David at netconf 2018, let's clarify
> DaveM's position of handling stable backports in netdev-FAQ.
> 
> This is important for people relying on upstream -stable
> releases.
> 
> Cc: sta...@vger.kernel.org
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Cong Wang 
> ---
>  Documentation/networking/netdev-FAQ.txt | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/Documentation/networking/netdev-FAQ.txt 
> b/Documentation/networking/netdev-FAQ.txt
> index 2a3278d5cf35..6dde6686c870 100644
> --- a/Documentation/networking/netdev-FAQ.txt
> +++ b/Documentation/networking/netdev-FAQ.txt
> @@ -179,6 +179,15 @@ A: No.  See above answer.  In short, if you think it 
> really belongs in
> dash marker line as described in 
> Documentation/process/submitting-patches.rst to
> temporarily embed that information into the patch that you send.
>  
> +Q: Are all networking bug fixes backported to all stable releases?
> +
> +A: Due to capacity, Dave could only take care of the backports for the last
> +   3 stable releases. For earlier stable releases, each stable branch 
> maintainer

s/3/2/

There's no need for Dave to do more work than he currently does :)

thanks,

greg k-h

Re: [PATCH] IB: Revert "remove redundant INFINIBAND kconfig dependencies"

[Greg Thelen]

Jason Gunthorpe  wrote:


On Fri, May 25, 2018 at 05:32:52PM -0700, Greg Thelen wrote:

On Fri, May 25, 2018 at 2:32 PM Arnd Bergmann  wrote:


> Several subsystems depend on INFINIBAND_ADDR_TRANS, which in turn  
depends

> on INFINIBAND. However, when with CONFIG_INIFIBAND=m, this leads to a
> link error when another driver using it is built-in. The
> INFINIBAND_ADDR_TRANS dependency is insufficient here as this is
> a 'bool' symbol that does not force anything to be a module in turn.



> fs/cifs/smbdirect.o: In function `smbd_disconnect_rdma_work':
> smbdirect.c:(.text+0x1e4): undefined reference to `rdma_disconnect'
> net/9p/trans_rdma.o: In function `rdma_request':
> trans_rdma.c:(.text+0x7bc): undefined reference to `rdma_disconnect'
> net/9p/trans_rdma.o: In function `rdma_destroy_trans':
> trans_rdma.c:(.text+0x830): undefined reference to `ib_destroy_qp'
> trans_rdma.c:(.text+0x858): undefined reference to `ib_dealloc_pd'



> Fixes: 9533b292a7ac ("IB: remove redundant INFINIBAND kconfig
dependencies")
> Signed-off-by: Arnd Bergmann 



Acked-by: Greg Thelen 



Sorry for the 9533b292a7ac problem.
At this point the in release cycle, I think Arnd's revert is best.



If there is interest, I've put a little thought into an alternative fix:
making INFINIBAND_ADDR_TRANS tristate.  But it's nontrivial.
So I prefer this simple revert for now.



Is that a normal thing to do?


For me: no, it's not normal.  In my use case I merely want to disable
INFINIBAND_ADDR_TRANS while continuing to use INFINIBAND.  This is
supported with f7cb7b85be55 ("IB: make INFINIBAND_ADDR_TRANS
configurable").

During f7cb7b85be55 development https://lkml.org/lkml/2018/4/30/1073
suggested that we drop dependency on both INFINIBAND and
INFINIBAND_ADDR_TRANS.  Thus 9533b292a7ac ("IB: remove redundant
INFINIBAND kconfig dependencies").

But 9533b292a7ac led to the randconfig build errors reported and thus
("IB: Revert "remove redundant INFINIBAND kconfig dependencies"").

So I see no need to do anything more than apply ("IB: Revert "remove
redundant INFINIBAND kconfig dependencies"").


Doug: do you need anything from me on this?



I can take the revert..



Jason


Thanks.

Re: 4.16 issue with mbim modem and ping with size > 14552 bytes

[Greg KH]

On Mon, May 28, 2018 at 09:58:01AM +0200, Daniele Palmas wrote:
> 2018-05-25 0:54 GMT+02:00 Daniele Palmas <dnl...@gmail.com>:
> > Hi Greg,
> >
> > 2018-05-24 17:53 GMT+02:00 Greg KH <gre...@linuxfoundation.org>:
> >> On Thu, May 24, 2018 at 05:04:49PM +0200, Daniele Palmas wrote:
> >>> Hello,
> >>>
> >>> I have an issue with an USB mbim modem when trying to send with ping
> >>> more than 14552 bytes: it looks like to me a kernel issue, but not at
> >>> the cdc_mbim or cdc_ncm level, anyway not sure, so I'm reporting the
> >>> issue.
> >>>
> >>> My kernel is 4.16. The device is the following:
> >>
> >> Does older kernels work, or is this something that has always been
> >> there?
> >>
> >
> > Not tested yet, I'm going to do.
> >
> 
> So, ping with more than 14552 was working properly until v4.5-rc7:
> starting from v4.5 I'm not even able to make a data connection with
> mbim since things fail badly with the following:
> 
> [  259.551836] [ cut here ]
> [  259.551848] WARNING: CPU: 2 PID: 0 at
> /home/kernel/COD/linux/net/sched/sch_generic.c:303
> dev_watchdog+0x237/0x240()
> [  259.551860] NETDEV WATCHDOG: wwp0s20u7i2 (cdc_mbim): transmit queue
> 0 timed out
> [  259.551861] Modules linked in: cdc_mbim cdc_wdm cdc_ncm usbnet mii
> intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm
> snd_hda_codec_realtek snd_hda_codec_hdmi snd_hda_codec_generic
> irqbypass crct10dif_pclmul snd_hda_intel snd_hda_codec snd_hda_core
> crc32_pclmul snd_hwdep ghash_clmulni_intel aesni_intel aes_x86_64
> snd_pcm snd_seq_midi lrw snd_seq_midi_event gf128mul input_leds
> snd_rawmidi snd_seq glue_helper snd_seq_device ablk_helper snd_timer
> cryptd snd soundcore shpchp serio_raw mac_hid lpc_ich 8250_fintek
> mei_me mei parport_pc ppdev lp parport autofs4 hid_generic usbhid hid
> i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect psmouse
> sysimgblt ahci fb_sys_fops e1000e libahci drm ptp pps_core wmi fjes
> video
> [  259.551889] CPU: 2 PID: 0 Comm: swapper/2 Not tainted
> 4.5.0-040500-generic #201603140130
> [  259.551890] Hardware name: LENOVO 10A6A0J5IX/SHARKBAY, BIOS
> FBKT79AUS 04/17/2014
> [  259.551891]  0286 108c91d75cf5b65f 88021eb03d98
> 813e0233
> [  259.551893]  88021eb03de0 81d816a0 88021eb03dd0
> 81080e72
> [  259.551894]   8800cee81880 0002
> 8800a19f8000
> [  259.551895] Call Trace:
> [  259.551896][] dump_stack+0x63/0x90
> [  259.551903]  [] warn_slowpath_common+0x82/0xc0
> [  259.551904]  [] warn_slowpath_fmt+0x5c/0x80
> [  259.551907]  [] dev_watchdog+0x237/0x240
> [  259.551909]  [] ? qdisc_rcu_free+0x40/0x40
> [  259.551910]  [] call_timer_fn+0x35/0x120
> [  259.551911]  [] ? qdisc_rcu_free+0x40/0x40
> [  259.551912]  [] run_timer_softirq+0x246/0x2f0
> [  259.551914]  [] __do_softirq+0xf6/0x280
> [  259.551916]  [] irq_exit+0xa3/0xb0
> [  259.551919]  [] smp_apic_timer_interrupt+0x42/0x50
> [  259.551920]  [] apic_timer_interrupt+0x82/0x90
> [  259.551922][] ? cpuidle_enter_state+0x11d/0x2c0
> [  259.551925]  [] cpuidle_enter+0x17/0x20
> [  259.551928]  [] call_cpuidle+0x2a/0x40
> [  259.551929]  [] cpu_startup_entry+0x295/0x350
> [  259.551931]  [] start_secondary+0x15e/0x190
> [  259.551933] ---[ end trace 6f8d3c1a1b02644d ]---
> 
> but this is probably something different, cause with v4.16 data
> connection works fine.
> 
> If this is not helpful I guess I need to bisect.

Bisection would be best.  It looks like you narrowed things down really
well already, bisection should go very quickly.

thanks,

greg k-h

Re: [PATCH v2] netfilter: properly initialize xt_table_info structure

[Greg Kroah-Hartman]

On Fri, May 18, 2018 at 11:27:56AM +0200, Florian Westphal wrote:
> Greg Kroah-Hartman <gre...@linuxfoundation.org> wrote:
> > On Thu, May 17, 2018 at 12:42:00PM +0200, Jan Engelhardt wrote:
> > > 
> > > On Thursday 2018-05-17 12:09, Greg Kroah-Hartman wrote:
> > > >> > --- a/net/netfilter/x_tables.c
> > > >> > +++ b/net/netfilter/x_tables.c
> > > >> > @@ -1183,11 +1183,10 @@ struct xt_table_info 
> > > >> > *xt_alloc_table_info(unsigned int size)
> > > >> >   * than shoot all processes down before realizing there is 
> > > >> > nothing
> > > >> >   * more to reclaim.
> > > >> >   */
> > > >> > -info = kvmalloc(sz, GFP_KERNEL | __GFP_NORETRY);
> > > >> > +info = kvzalloc(sz, GFP_KERNEL | __GFP_NORETRY);
> > > >> >  if (!info)
> > > >> >  return NULL;
> > > >>
> > > >> I am curious, what particular path does not later overwrite the whole 
> > > >> zone ?
> > > >
> > > >In do_ipt_get_ctl, the IPT_SO_GET_ENTRIES: option uses a len value that
> > > >can be larger than the size of the structure itself.
> > > >
> > > >Then the data is copied to userspace in copy_entries_to_user() for ipv4
> > > >and v6, and that's where the "bad data"
> > > 
> > > If the kernel incorrectly copies more bytes than it should, isn't that
> > > a sign that may be going going past the end of the info buffer?
> > > (And thus, zeroing won't truly fix the issue)
> > 
> > No, the buffer size is correct, we just aren't filling up the whole
> > buffer as the data requested is smaller than the buffer size.
> 
> I have no objections to the patch but I'd like to understand what
> problem its fixing.
> 
> Normal pattern is:
> newinfo = xt_alloc_table_info(tmp.size);
> copy_from_user(newinfo->entries, user + sizeof(tmp), tmp.size);
> 
> So inital value of the rule blob area should not matter.
> 
> Furthermore, when copying the rule blob back to userspace,
> the kernel is not supposed to copy any padding back to userspace either,
> since commit f32815d21d4d8287336fb9cef4d2d9e0866214c2 only the
> user-relevant parts should be copied (some matches and targets allocate
> kernel-private data such as pointers, and we did use to leak such pointer
> values back to userspace).

Adding Peter to this thread, as he originally reported this issue to
Google back in February.

Peter, I know you reported this against the 4.4 kernel tree, but since
then, commit f32815d21d4d ("xtables: add xt_match, xt_target and data
copy_to_user functions") has been added to the kernel in release 4.11.
In digging through this crazy code path, I think the issue is still
there, but can not verify it for sure.

Is there any way you can run your tests on the 4.14 or newer kernel tree
to see if this issue really is fixed or not?

thanks,

greg k-h

Re: [PATCH] IB: Revert "remove redundant INFINIBAND kconfig dependencies"

[Greg Thelen]

On Fri, May 25, 2018 at 2:32 PM Arnd Bergmann <a...@arndb.de> wrote:

> Several subsystems depend on INFINIBAND_ADDR_TRANS, which in turn depends
> on INFINIBAND. However, when with CONFIG_INIFIBAND=m, this leads to a
> link error when another driver using it is built-in. The
> INFINIBAND_ADDR_TRANS dependency is insufficient here as this is
> a 'bool' symbol that does not force anything to be a module in turn.

> fs/cifs/smbdirect.o: In function `smbd_disconnect_rdma_work':
> smbdirect.c:(.text+0x1e4): undefined reference to `rdma_disconnect'
> net/9p/trans_rdma.o: In function `rdma_request':
> trans_rdma.c:(.text+0x7bc): undefined reference to `rdma_disconnect'
> net/9p/trans_rdma.o: In function `rdma_destroy_trans':
> trans_rdma.c:(.text+0x830): undefined reference to `ib_destroy_qp'
> trans_rdma.c:(.text+0x858): undefined reference to `ib_dealloc_pd'

> Fixes: 9533b292a7ac ("IB: remove redundant INFINIBAND kconfig
dependencies")
> Signed-off-by: Arnd Bergmann <a...@arndb.de>

Acked-by: Greg Thelen <gthe...@google.com>

Sorry for the 9533b292a7ac problem.
At this point the in release cycle, I think Arnd's revert is best.

If there is interest, I've put a little thought into an alternative fix:
making INFINIBAND_ADDR_TRANS tristate.  But it's nontrivial.
So I prefer this simple revert for now.

Doug: do you need anything from me on this?

> ---
> The patch that introduced the problem has been queued in the
> rdma-fixes/for-rc tree. Please revert the patch before sending
> the branch to Linus.
> ---
> drivers/infiniband/ulp/srpt/Kconfig | 2 +-
> drivers/nvme/host/Kconfig   | 2 +-
> drivers/nvme/target/Kconfig | 2 +-
> drivers/staging/lustre/lnet/Kconfig | 2 +-
> fs/cifs/Kconfig | 2 +-
> net/9p/Kconfig  | 2 +-
> net/rds/Kconfig | 2 +-
> net/sunrpc/Kconfig  | 2 +-
> 8 files changed, 8 insertions(+), 8 deletions(-)

> diff --git a/drivers/infiniband/ulp/srpt/Kconfig
b/drivers/infiniband/ulp/srpt/Kconfig
> index 25bf6955b6d0..fb8b7182f05e 100644
> --- a/drivers/infiniband/ulp/srpt/Kconfig
> +++ b/drivers/infiniband/ulp/srpt/Kconfig
> @@ -1,6 +1,6 @@
> config INFINIBAND_SRPT
>tristate "InfiniBand SCSI RDMA Protocol target support"
> -   depends on INFINIBAND_ADDR_TRANS && TARGET_CORE
> +   depends on INFINIBAND && INFINIBAND_ADDR_TRANS && TARGET_CORE
>---help---

>  Support for the SCSI RDMA Protocol (SRP) Target driver. The
> diff --git a/drivers/nvme/host/Kconfig b/drivers/nvme/host/Kconfig
> index dbb7464c018c..88a8b5916624 100644
> --- a/drivers/nvme/host/Kconfig
> +++ b/drivers/nvme/host/Kconfig
> @@ -27,7 +27,7 @@ config NVME_FABRICS

> config NVME_RDMA
>tristate "NVM Express over Fabrics RDMA host driver"
> -   depends on INFINIBAND_ADDR_TRANS && BLOCK
> +   depends on INFINIBAND && INFINIBAND_ADDR_TRANS && BLOCK
>select NVME_CORE
>select NVME_FABRICS
>select SG_POOL
> diff --git a/drivers/nvme/target/Kconfig b/drivers/nvme/target/Kconfig
> index 7595664ee753..3c7b61ddb0d1 100644
> --- a/drivers/nvme/target/Kconfig
> +++ b/drivers/nvme/target/Kconfig
> @@ -27,7 +27,7 @@ config NVME_TARGET_LOOP

> config NVME_TARGET_RDMA
>tristate "NVMe over Fabrics RDMA target support"
> -   depends on INFINIBAND_ADDR_TRANS
> +   depends on INFINIBAND && INFINIBAND_ADDR_TRANS
>depends on NVME_TARGET
>select SGL_ALLOC
>help
> diff --git a/drivers/staging/lustre/lnet/Kconfig
b/drivers/staging/lustre/lnet/Kconfig
> index f3b1ad4bd3dc..ad049e6f24e4 100644
> --- a/drivers/staging/lustre/lnet/Kconfig
> +++ b/drivers/staging/lustre/lnet/Kconfig
> @@ -34,7 +34,7 @@ config LNET_SELFTEST

> config LNET_XPRT_IB
>tristate "LNET infiniband support"
> -   depends on LNET && PCI && INFINIBAND_ADDR_TRANS
> +   depends on LNET && PCI && INFINIBAND && INFINIBAND_ADDR_TRANS
>default LNET && INFINIBAND
>help
>  This option allows the LNET users to use infiniband as an
> diff --git a/fs/cifs/Kconfig b/fs/cifs/Kconfig
> index d61e2de8d0eb..5f132d59dfc2 100644
> --- a/fs/cifs/Kconfig
> +++ b/fs/cifs/Kconfig
> @@ -197,7 +197,7 @@ config CIFS_SMB311

> config CIFS_SMB_DIRECT
>bool "SMB Direct support (Experimental)"
> -   depends on CIFS=m && INFINIBAND_ADDR_TRANS || CIFS=y &&
INFINIBAND_ADDR_TRANS=y
> +   depends on CIF

Re: [PATCH 1/7] core, dma-direct: add a flag 32-bit dma limits

[Greg Kroah-Hartman]

On Fri, May 25, 2018 at 06:23:07PM +0200, Christoph Hellwig wrote:
> On Fri, May 25, 2018 at 04:50:12PM +0200, Greg Kroah-Hartman wrote:
> > On Fri, May 25, 2018 at 04:35:06PM +0200, Christoph Hellwig wrote:
> > > Various PCI bridges (VIA PCI, Xilinx PCIe) limit DMA to only 32-bits
> > > even if the device itself supports more.  Add a single bit flag to
> > > struct device (to be moved into the dma extension once we around it)
> > 
> > "once we around it"?  I don't understand, sorry.
> 
> Should be "once we get around it", which in proper grammar should
> probably be "once we get to it".  Anyway, the point is that right
> now struct device is bloated with a lot of fields for dma/iommu
> purposes and we need to clean this up.  It's been on my TODO list
> for a while.

Ah, makes sense, that's fine with me, I'd love to see that get cleaned
up.

thanks,

greg k-h

Re: [PATCH 1/7] core, dma-direct: add a flag 32-bit dma limits

[Greg Kroah-Hartman]

On Fri, May 25, 2018 at 04:35:06PM +0200, Christoph Hellwig wrote:
> Various PCI bridges (VIA PCI, Xilinx PCIe) limit DMA to only 32-bits
> even if the device itself supports more.  Add a single bit flag to
> struct device (to be moved into the dma extension once we around it)

"once we around it"?  I don't understand, sorry.

> to flag such devices and reject larger DMA to them.
> 
> Signed-off-by: Christoph Hellwig <h...@lst.de>
> ---
>  include/linux/device.h | 3 +++
>  lib/dma-direct.c   | 6 ++
>  2 files changed, 9 insertions(+)

For the patch, no objection from me:

Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

Re: 4.16 issue with mbim modem and ping with size > 14552 bytes

[Greg KH]

On Thu, May 24, 2018 at 05:04:49PM +0200, Daniele Palmas wrote:
> Hello,
> 
> I have an issue with an USB mbim modem when trying to send with ping
> more than 14552 bytes: it looks like to me a kernel issue, but not at
> the cdc_mbim or cdc_ncm level, anyway not sure, so I'm reporting the
> issue.
> 
> My kernel is 4.16. The device is the following:

Does older kernels work, or is this something that has always been
there?

I ask, as my mobile provider does horrible things to large packet sizes.
So much so that I have to set the mtu to 1280 just to get things to work
properly when tethering my phone through to my laptop.  So this might be
a network provider issue :)

thanks,

greg k-h

Re: [V9fs-developer] [PATCH] net/9p: fix error path of p9_virtio_probe

[Greg Kurz]

On Thu, 24 May 2018 11:10:21 +0100
Jean-Philippe Brucker <jean-philippe.bruc...@arm.com> wrote:

> Currently when virtio_find_single_vq fails, we go through del_vqs which
> throws a warning (Trying to free already-free IRQ). Skip del_vqs if vq
> allocation failed.
> 
> Signed-off-by: Jean-Philippe Brucker <jean-philippe.bruc...@arm.com>
> ---

Reviewed-by: Greg Kurz <gr...@kaod.org>

>  net/9p/trans_virtio.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c
> index 4d0372263e5d..1c87eee522b7 100644
> --- a/net/9p/trans_virtio.c
> +++ b/net/9p/trans_virtio.c
> @@ -562,7 +562,7 @@ static int p9_virtio_probe(struct virtio_device *vdev)
>   chan->vq = virtio_find_single_vq(vdev, req_done, "requests");
>   if (IS_ERR(chan->vq)) {
>   err = PTR_ERR(chan->vq);
> - goto out_free_vq;
> + goto out_free_chan;
>   }
>   chan->vq->vdev->priv = chan;
>   spin_lock_init(>lock);
> @@ -615,6 +615,7 @@ static int p9_virtio_probe(struct virtio_device *vdev)
>   kfree(tag);
>  out_free_vq:
>   vdev->config->del_vqs(vdev);
> +out_free_chan:
>   kfree(chan);
>  fail:
>   return err;

Re: [PATCH v3 net-next 0/2] bpfilter

[Greg KH]

On Wed, May 23, 2018 at 01:26:48PM -0400, David Miller wrote:
> From: Alexei Starovoitov 
> Date: Mon, 21 May 2018 19:22:28 -0700
> 
> > v2->v3:
> > - followed Luis's suggestion and significantly simplied first patch
> >   with shmem_kernel_file_setup+kernel_write. Added kdoc for new helper
> > - fixed typos and race to access pipes with mutex
> > - tested with bpfilter being 'builtin'. CONFIG_BPFILTER_UMH=y|m both work.
> >   Interesting to see a usermode executable being embedded inside vmlinux.
> > - it doesn't hurt to enable bpfilter in .config.
> >   ip_setsockopt commands sent to usermode via pipes and -ENOPROTOOPT is
> >   returned from userspace, so kernel falls back to original iptables code
> > 
> > v1->v2:
> > this patch set is almost a full rewrite of the earlier umh modules approach
> > The v1 of patches and follow up discussion was covered by LWN:
> > https://lwn.net/Articles/749108/
> > 
> > I believe the v2 addresses all issues brought up by Andy and others.
> > Mainly there are zero changes to kernel/module.c
> > Instead of teaching module loading logic to recognize special
> > umh module, let normal kernel modules execute part of its own
> > .init.rodata as a new user space process (Andy's idea)
> > Patch 1 introduces this new helper:
> > int fork_usermode_blob(void *data, size_t len, struct umh_info *info);
> > Input:
> >   data + len == executable file
> > Output:
> >   struct umh_info {
> >struct file *pipe_to_umh;
> >struct file *pipe_from_umh;
> >pid_t pid;
> >   };
> 
> Series applied, let the madness begin... :-)

Yeah, this is going to be fun :)

Re: [PATCH v2] netfilter: properly initialize xt_table_info structure

[Greg Kroah-Hartman]

On Fri, May 18, 2018 at 11:27:56AM +0200, Florian Westphal wrote:
> Greg Kroah-Hartman <gre...@linuxfoundation.org> wrote:
> > On Thu, May 17, 2018 at 12:42:00PM +0200, Jan Engelhardt wrote:
> > > 
> > > On Thursday 2018-05-17 12:09, Greg Kroah-Hartman wrote:
> > > >> > --- a/net/netfilter/x_tables.c
> > > >> > +++ b/net/netfilter/x_tables.c
> > > >> > @@ -1183,11 +1183,10 @@ struct xt_table_info 
> > > >> > *xt_alloc_table_info(unsigned int size)
> > > >> >   * than shoot all processes down before realizing there is 
> > > >> > nothing
> > > >> >   * more to reclaim.
> > > >> >   */
> > > >> > -info = kvmalloc(sz, GFP_KERNEL | __GFP_NORETRY);
> > > >> > +info = kvzalloc(sz, GFP_KERNEL | __GFP_NORETRY);
> > > >> >  if (!info)
> > > >> >  return NULL;
> > > >>
> > > >> I am curious, what particular path does not later overwrite the whole 
> > > >> zone ?
> > > >
> > > >In do_ipt_get_ctl, the IPT_SO_GET_ENTRIES: option uses a len value that
> > > >can be larger than the size of the structure itself.
> > > >
> > > >Then the data is copied to userspace in copy_entries_to_user() for ipv4
> > > >and v6, and that's where the "bad data"
> > > 
> > > If the kernel incorrectly copies more bytes than it should, isn't that
> > > a sign that may be going going past the end of the info buffer?
> > > (And thus, zeroing won't truly fix the issue)
> > 
> > No, the buffer size is correct, we just aren't filling up the whole
> > buffer as the data requested is smaller than the buffer size.
> 
> I have no objections to the patch but I'd like to understand what
> problem its fixing.
> 
> Normal pattern is:
> newinfo = xt_alloc_table_info(tmp.size);
> copy_from_user(newinfo->entries, user + sizeof(tmp), tmp.size);
> 
> So inital value of the rule blob area should not matter.
> 
> Furthermore, when copying the rule blob back to userspace,
> the kernel is not supposed to copy any padding back to userspace either,
> since commit f32815d21d4d8287336fb9cef4d2d9e0866214c2 only the
> user-relevant parts should be copied (some matches and targets allocate
> kernel-private data such as pointers, and we did use to leak such pointer
> values back to userspace).

Ah, fun, commit f32815d21d4d ("xtables: add xt_match, xt_target and data
copy_to_user functions") showed up in 4.11 and this was reported in 4.4 :(

However, the "bad" code path seems to be from the IPT_SO_GET_ENTRIES
request, which does not look to use the new functions provided in
f32815d21d4d, or am I mistaken?

Let me go work on a reproducer for this to make it a lot more obvious
what is happening, and if it is still even an issue after f32815d21d4d
is applied to a kernel.  Sorry for not providing that in the first
place...

thanks,

greg k-h

Re: Request for -stable inclusion: time stamping fix for nfp

[Greg KH]

On Thu, May 17, 2018 at 08:32:02PM +0200, Willy Tarreau wrote:
> Adding Greg here.
> 
> Greg, apparently a backport of 46f1c52e66db is needed in 4.9 according
> to the thread below. It was merged in 4.13 so 4.14 already has it.

Thanks for the notice, now queued up.

greg k-h

Re: [PATCH] net: ethernet: ti: cpsw: fix packet leaking in dual_mac mode

[Greg Kroah-Hartman]

On Thu, May 17, 2018 at 11:18:16PM +0530, Naresh Kamboju wrote:
> On 2 May 2018 at 20:38, David Miller <da...@davemloft.net> wrote:
> > From: Grygorii Strashko <grygorii.stras...@ti.com>
> > Date: Tue, 1 May 2018 12:41:22 -0500
> 
> >> Signed-off-by: Grygorii Strashko <grygorii.stras...@ti.com>
> >
> > Applied and queued up for -stable, thank you.
> 
> 4.4 stable-rc build failed for arm32.
> MACHINE=am57xx-evm
> 
> Build error log:
> 
> drivers/net/ethernet/ti/cpsw.c:
>  In function 'cpsw_add_dual_emac_def_ale_entries':
> drivers/net/ethernet/ti/cpsw.c:1112:23:
>  error: 'cpsw' undeclared (first use in this function)
>cpsw_ale_control_set(cpsw->ale, slave_port,
> ^~~~
> drivers/net/ethernet/ti/cpsw.c:1112:23: note:
>  each undeclared identifier is reported only once for each function it appears
>  in
> scripts/Makefile.build:269: recipe for target 'drivers/net/ethernet/ti/cpsw.o'
>  failed
>  make[6]: *** [drivers/net/ethernet/ti/cpsw.o] Error 1
> scripts/Makefile.build:476: recipe for target 'drivers/net/ethernet/ti' failed
>  make[5]: *** [drivers/net/ethernet/ti] Error 2
> 

Now dropped, it's nice to see I got 3 reports about this :)

greg k-h

Re: net: ieee802154: 6lowpan: fix frag reassembly

[Greg KH]

On Thu, May 17, 2018 at 04:16:20PM +0200, Stefan Schmidt wrote:
> Hello Greg.
> 
> On 17.05.2018 10:59, Greg KH wrote:
> > On Mon, May 14, 2018 at 05:22:18PM +0200, Stefan Schmidt wrote:
> >> Hello.
> >>
> >>
> >> Please apply f18fa5de5ba7f1d6650951502bb96a6e4715a948
> >>
> >> (net: ieee802154: 6lowpan: fix frag reassembly) to the 4.16.x stable tree.
> >>
> >>
> >> Earlier trees are not needed as the problem was introduced in 4.16.
> > 
> > Really?  Commit f18fa5de5ba7 ("net: ieee802154: 6lowpan: fix frag
> > reassembly") says it fixes commit 648700f76b03 ("inet: frags: use
> > rhashtables for reassembly units") which did not show up until 4.17-rc1:
> > $ git describe --contains 648700f76b03
> > v4.17-rc1~148^2~20^2~11
> > 
> > Also, it did not get backported to 4.16.y, so I don't see how it is
> > needed in 4.16-stable.
> 
> I guess its time to blush on my side. During the bisection for the
> commit that introduced the problem I came to the point where it was
> clear to me that it was already in 4.16. This was a while back I have
> have honestly no idea how I did this mistake.
> 
> I tested again now with plain 4.16 and it works fine.
> The fix is also in 4.17-rcX where it actually is needed. In the end I am
> glad that it was not introduced and slipped me in an earlier release.
> 
> > To verify this, I tried applying the patch, and it totally fails to
> > apply to the 4.16.y tree.
> > 
> > So are you _sure_ you want/need this in 4.16?  If so, can you provide a
> > working backport that you have verified works?
> 
> No backport needed. I simply screwed up when verifying this for 4.16.
> I put on the hat of shame for today and will try harder the next time.

Hey, not a problem, thanks for verifying, 'git describe --contains' is
your friend :)

thanks,

greg k-h

Re: [PATCH v2] netfilter: properly initialize xt_table_info structure

[Greg Kroah-Hartman]

On Thu, May 17, 2018 at 12:42:00PM +0200, Jan Engelhardt wrote:
> 
> On Thursday 2018-05-17 12:09, Greg Kroah-Hartman wrote:
> >> > --- a/net/netfilter/x_tables.c
> >> > +++ b/net/netfilter/x_tables.c
> >> > @@ -1183,11 +1183,10 @@ struct xt_table_info 
> >> > *xt_alloc_table_info(unsigned int size)
> >> >   * than shoot all processes down before realizing there is 
> >> > nothing
> >> >   * more to reclaim.
> >> >   */
> >> > -info = kvmalloc(sz, GFP_KERNEL | __GFP_NORETRY);
> >> > +info = kvzalloc(sz, GFP_KERNEL | __GFP_NORETRY);
> >> >  if (!info)
> >> >  return NULL;
> >>
> >> I am curious, what particular path does not later overwrite the whole zone 
> >> ?
> >
> >In do_ipt_get_ctl, the IPT_SO_GET_ENTRIES: option uses a len value that
> >can be larger than the size of the structure itself.
> >
> >Then the data is copied to userspace in copy_entries_to_user() for ipv4
> >and v6, and that's where the "bad data"
> 
> If the kernel incorrectly copies more bytes than it should, isn't that
> a sign that may be going going past the end of the info buffer?
> (And thus, zeroing won't truly fix the issue)

No, the buffer size is correct, we just aren't filling up the whole
buffer as the data requested is smaller than the buffer size.

thanks,

greg k-h

Re: [PATCH v2] netfilter: properly initialize xt_table_info structure

[Greg Kroah-Hartman]

On Thu, May 17, 2018 at 02:55:42AM -0700, Eric Dumazet wrote:
> 
> 
> On 05/17/2018 02:34 AM, Greg Kroah-Hartman wrote:
> > When allocating a xt_table_info structure, we should be clearing out the
> > full amount of memory that was allocated, not just the "header" of the
> > structure.  Otherwise odd values could be passed to userspace, which is
> > not a good thing.
> > 
> > Cc: stable <sta...@vger.kernel.org>
> > Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> > ---
> > v2: use kvzalloc instead of kvmalloc/memset pair, as suggested by Michal 
> > Kubecek
> > 
> >  net/netfilter/x_tables.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c
> > index cb7cb300c3bc..cd22bb9b66f3 100644
> > --- a/net/netfilter/x_tables.c
> > +++ b/net/netfilter/x_tables.c
> > @@ -1183,11 +1183,10 @@ struct xt_table_info *xt_alloc_table_info(unsigned 
> > int size)
> >  * than shoot all processes down before realizing there is nothing
> >  * more to reclaim.
> >  */
> > -   info = kvmalloc(sz, GFP_KERNEL | __GFP_NORETRY);
> > +   info = kvzalloc(sz, GFP_KERNEL | __GFP_NORETRY);
> > if (!info)
> > return NULL;
> >  
> > -   memset(info, 0, sizeof(*info));
> > info->size = size;
> > return info;
> >  }
> > 
> 
> I am curious, what particular path does not later overwrite the whole zone ?

The path back was long, adding Greg Hackman who helped to debug this to
the To: to confirm that I got this correct...

In do_ipt_get_ctl, the IPT_SO_GET_ENTRIES: option uses a len value that
can be larger than the size of the structure itself.

Then the data is copied to userspace in copy_entries_to_user() for ipv4
and v6, and that's where the "bad data" was noticed (a researcher was
using a kernel patch to determine what the data was)

Greg, that's the correct path here, right?

> Do not get me wrong, this is not fast path, but these blobs can be huge.

Yeah, I bet, but for "normal" cases the size should be small and all
should be fine.

thanks,

greg k-h

[PATCH v2] netfilter: properly initialize xt_table_info structure

[Greg Kroah-Hartman]

When allocating a xt_table_info structure, we should be clearing out the
full amount of memory that was allocated, not just the "header" of the
structure.  Otherwise odd values could be passed to userspace, which is
not a good thing.

Cc: stable <sta...@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
v2: use kvzalloc instead of kvmalloc/memset pair, as suggested by Michal Kubecek

 net/netfilter/x_tables.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c
index cb7cb300c3bc..cd22bb9b66f3 100644
--- a/net/netfilter/x_tables.c
+++ b/net/netfilter/x_tables.c
@@ -1183,11 +1183,10 @@ struct xt_table_info *xt_alloc_table_info(unsigned int 
size)
 * than shoot all processes down before realizing there is nothing
 * more to reclaim.
 */
-   info = kvmalloc(sz, GFP_KERNEL | __GFP_NORETRY);
+   info = kvzalloc(sz, GFP_KERNEL | __GFP_NORETRY);
if (!info)
return NULL;
 
-   memset(info, 0, sizeof(*info));
info->size = size;
return info;
 }
-- 
2.17.0

Re: [PATCH] netfilter: properly initialize xt_table_info structure

[Greg Kroah-Hartman]

On Thu, May 17, 2018 at 10:59:51AM +0200, Michal Kubecek wrote:
> On Thu, May 17, 2018 at 10:44:42AM +0200, Greg Kroah-Hartman wrote:
> > When allocating a xt_table_info structure, we should be clearing out the
> > full amount of memory that was allocated, not just the "header" of the
> > structure.  Otherwise odd values could be passed to userspace, which is
> > not a good thing.
> > 
> > Cc: stable <sta...@vger.kernel.org>
> > Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> > ---
> >  net/netfilter/x_tables.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c
> > index cb7cb300c3bc..a300e8252bb6 100644
> > --- a/net/netfilter/x_tables.c
> > +++ b/net/netfilter/x_tables.c
> > @@ -1187,7 +1187,7 @@ struct xt_table_info *xt_alloc_table_info(unsigned 
> > int size)
> > if (!info)
> > return NULL;
> >  
> > -   memset(info, 0, sizeof(*info));
> > +   memset(info, 0, sz);
> > info->size = size;
> > return info;
> >  }
> > -- 
> > 2.17.0
> > 
> 
> Or we can replace kvmalloc() by kvzalloc() and remove the memset().

That works for me too, either is sufficient to solve the problem.

Let me go respin this, less lines of code is always better :)

thanks,

greg k-h

Re: net: ieee802154: 6lowpan: fix frag reassembly

[Greg KH]

On Mon, May 14, 2018 at 05:22:18PM +0200, Stefan Schmidt wrote:
> Hello.
> 
> 
> Please apply f18fa5de5ba7f1d6650951502bb96a6e4715a948
> 
> (net: ieee802154: 6lowpan: fix frag reassembly) to the 4.16.x stable tree.
> 
> 
> Earlier trees are not needed as the problem was introduced in 4.16.

Really?  Commit f18fa5de5ba7 ("net: ieee802154: 6lowpan: fix frag
reassembly") says it fixes commit 648700f76b03 ("inet: frags: use
rhashtables for reassembly units") which did not show up until 4.17-rc1:
$ git describe --contains 648700f76b03
v4.17-rc1~148^2~20^2~11

Also, it did not get backported to 4.16.y, so I don't see how it is
needed in 4.16-stable.

To verify this, I tried applying the patch, and it totally fails to
apply to the 4.16.y tree.

So are you _sure_ you want/need this in 4.16?  If so, can you provide a
working backport that you have verified works?

thanks,

greg k-h

[PATCH] netfilter: properly initialize xt_table_info structure

[Greg Kroah-Hartman]

When allocating a xt_table_info structure, we should be clearing out the
full amount of memory that was allocated, not just the "header" of the
structure.  Otherwise odd values could be passed to userspace, which is
not a good thing.

Cc: stable <sta...@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 net/netfilter/x_tables.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c
index cb7cb300c3bc..a300e8252bb6 100644
--- a/net/netfilter/x_tables.c
+++ b/net/netfilter/x_tables.c
@@ -1187,7 +1187,7 @@ struct xt_table_info *xt_alloc_table_info(unsigned int 
size)
if (!info)
return NULL;
 
-   memset(info, 0, sizeof(*info));
+   memset(info, 0, sz);
info->size = size;
return info;
 }
-- 
2.17.0

Re: [PATCH 41/42] tty: replace ->proc_fops with ->proc_show

[Greg Kroah-Hartman]

On Wed, May 16, 2018 at 11:43:45AM +0200, Christoph Hellwig wrote:
> Just set up the show callback in the tty_operations, and use
> proc_create_single_data to create the file without additional
> boilerplace code.
> 
> Signed-off-by: Christoph Hellwig <h...@lst.de>

Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

Re: [PATCH v4 1/1] drivers core: multi-threading device shutdown

[Greg KH]

On Mon, May 14, 2018 at 03:42:54PM -0400, Pavel Tatashin wrote:
> When system is rebooted, halted or kexeced device_shutdown() is
> called.
> 
> This function shuts down every single device by calling either:
> 
>   dev->bus->shutdown(dev)
>   dev->driver->shutdown(dev)
> 
> Even on a machine with just a moderate amount of devices, device_shutdown()
> may take multiple seconds to complete. This is because many devices require
> a specific delays to perform this operation.
> 
> Here is a sample analysis of time it takes to call device_shutdown() on a
> two socket Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz machine.
> 
> device_shutdown   2.95s
> -
>  mlx4_shutdown1.14s
>  megasas_shutdown 0.24s
>  ixgbe_shutdown   0.37s x 4 (four ixgbe devices on this machine).
>  the rest 0.09s
> 
> In mlx4 we spent the most time, but that is because there is a 1 second
> sleep, which is defined by hardware specifications:
> mlx4_shutdown
>  mlx4_unload_one
>   mlx4_free_ownership
>msleep(1000)
> 
> With megasas we spend a quarter of a second, but sometimes longer (up-to
> 0.5s) in this path:
> 
> megasas_shutdown
>   megasas_flush_cache
> megasas_issue_blocked_cmd
>   wait_event_timeout
> 
> Finally, with ixgbe_shutdown() it takes 0.37 for each device, but that time
> is spread all over the place, with bigger offenders:
> 
> ixgbe_shutdown
>   __ixgbe_shutdown
> ixgbe_close_suspend
>   ixgbe_down
> ixgbe_init_hw_generic
>   ixgbe_reset_hw_X540
> msleep(100);0.104483472
> ixgbe_get_san_mac_addr_generic  0.048414851
> ixgbe_get_wwn_prefix_generic0.048409893
>   ixgbe_start_hw_X540
> ixgbe_start_hw_generic
>   ixgbe_clear_hw_cntrs_generic  0.048581502
>   ixgbe_setup_fc_generic0.024225800
> 
> All the ixgbe_*generic functions end-up calling:
> ixgbe_read_eerd_X540()
>   ixgbe_acquire_swfw_sync_X540
> usleep_range(5000, 6000);
>   ixgbe_release_swfw_sync_X540
> usleep_range(5000, 6000);
> 
> While these are short sleeps, they end-up calling them over 24 times!
> 24 * 0.0055s = 0.132s. Adding-up to 0.528s for four devices. Also we have
> four msleep(100). Totaling to:  0.928s
> 
> While we should keep optimizing the individual device drivers, in some
> cases this is simply a hardware property that forces a specific delay, and
> we must wait.
> 
> So, the solution for this problem is to shutdown devices in parallel.
> However, we must shutdown children before shutting down parents, so parent
> device must wait for its children to finish.
> 
> With this patch, on the same machine devices_shutdown() takes 1.142s, and
> without mlx4 one second delay only 0.38s
> 
> This feature can be optionally disabled via kernel parameter:
> device_shutdown_serial. When booted with this parameter, device_shutdown()
> will shutdown devices one by one.
> 
> Signed-off-by: Pavel Tatashin <pasha.tatas...@oracle.com>
> ---
>  drivers/base/core.c | 292 
>  1 file changed, 242 insertions(+), 50 deletions(-)

Can you refactor this to be at least 2 patches?  One that moves code
around to comon functions to make the second patch, that adds the new
functionality, easier to review and understand?

And I echo the "don't use kerneldoc for static functions" review
comment, that's not needed at all.

thanks,

greg k-h

Re: net: ieee802154: 6lowpan: fix frag reassembly

[Greg KH]

On Mon, May 14, 2018 at 05:22:18PM +0200, Stefan Schmidt wrote:
> Hello.
> 
> 
> Please apply f18fa5de5ba7f1d6650951502bb96a6e4715a948
> 
> (net: ieee802154: 6lowpan: fix frag reassembly) to the 4.16.x stable tree.
> 
> 
> Earlier trees are not needed as the problem was introduced in 4.16.
> 
> 
> Normally net/ patches would come through DaveM, but he asked me for this one 
> to submit it directly when i sent him the pull request.
> 
> 
> First time stable request on my side here, let me know if I got something 
> wrong.

Looks fine, I'll queue it up later this week in the next release after
these go out on Wednesday.

thanks,

greg k-h

Re: [PATCH v3 0/1] multi-threading device shutdown

[Greg KH]

On Mon, May 07, 2018 at 11:54:01AM -0400, Pavel Tatashin wrote:
> Changelog
> v2 - v3
>   - Fixed warning from kbuild test.
>   - Moved device_lock/device_unlock inside device_shutdown_tree().
> 
> v1 - v2
>   - It turns out we cannot lock more than MAX_LOCK_DEPTH by a single
> thread. (By default this value is 48), and is used to detect
> deadlocks. So, I re-wrote the code to only lock one devices per
> thread instead of pre-locking all devices by the main thread.
>   - Addressed comments from Tobin C. Harding.
>   - As suggested by Alexander Duyck removed ixgbe changes. It can be
> done as a separate work scaling RTNL mutex.
> 
> Do a faster shutdown by calling dev->*->shutdown(dev) in parallel.
> device_shutdown() calls these functions for every single device but
> only using one thread.
> 
> Since, nothing else is running on the machine by the device_shutdown()
> s called, there is no reason not to utilize all the available CPU
> resources.

Ah, we can hope so.  I bet this is going to break something, so can we
have some way of turning it on/off dynamically for when it does?

thanks,

greg k-h

Re: Please apply 3f1e53abff84c (" netfilter: ebtables: don't attempt to allocate 0-sized compat array") to v4.14.y and later

[Greg Kroah-Hartman]

On Wed, May 09, 2018 at 06:26:29AM -0700, Guenter Roeck wrote:
> Hi Greg,
> 
> Commit 3f1e53abff84c fixes commit 7d7d7e02111e9 ("("netfilter: compat: reject 
> huge
> allocation requests"), which has found its way into 4.14.y and 4.16.y.
> This causes syzcaller hiccups at least in 4.14.y (more specifically 
> chromeos-4.14).
> 
> Please apply 3f1e53abff84c to v4.14.y and v4.16.y to fix the problem. Copying 
> Dave
> and netdev in case he wants to handle it.
> 
> Sorry for the noise if this has already been queued.

I queued it up 2 hours ago :)

But thanks for asking, it's better to make sure it gets added.

thanks,

greg k-h

Re: WARNING in kernfs_add_one

[Greg KH]

On Sat, May 05, 2018 at 10:43:45AM -0700, Eric Dumazet wrote:
> 
> 
> On 05/05/2018 09:40 AM, Greg KH wrote:
> > On Sat, May 05, 2018 at 08:47:02AM -0700, syzbot wrote:
> >> Hello,
> >>
> >> syzbot found the following crash on:
> >>
> >> HEAD commit:8fb11a9a8d51 net/ipv6: rename rt6_next to fib6_next
> >> git tree:   net-next
> >> console output: https://syzkaller.appspot.com/x/log.txt?x=14b2723780
> >> kernel config:  https://syzkaller.appspot.com/x/.config?x=c416c61f3cd96be
> >> dashboard link: 
> >> https://syzkaller.appspot.com/bug?extid=df47f81c226b31d89fb1
> >> compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
> >> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=172fb3e780
> >> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=16552e5780
> >>
> >> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> >> Reported-by: syzbot+df47f81c226b31d89...@syzkaller.appspotmail.com
> >>
> >> RBP: 7fff808f3e10 R08: 0002 R09: 7fff80003534
> >> R10:  R11: 0246 R12: 
> >> R13: 0006 R14:  R15: 
> >> [ cut here ]
> >> kernfs: ns required in 'ieee80211' for 'phy3'
> > 
> > That's interesting, this looks like a netfilter bug (adding netdev to
> > the report here.)
> 
> 
> I do not see anything netfilter related here.
> 
> More likely wireless territory

Ugh, that's what I get for writing emails before coffee in the
morning...

Yes, you are right, this looks like a wireless issue.

Now cc: linux-wireless.

> > Yes, we can "tone down" the kernfs warning to just be an error message
> > in the log, but there might be something worse going on here.
> > 
> > Network developers, any idea?  Rest of the callback chain is here:
> > 
> > 
> >> WARNING: CPU: 0 PID: 4538 at fs/kernfs/dir.c:759 kernfs_add_one+0x406/0x4d0
> >> fs/kernfs/dir.c:758
> >> Kernel panic - not syncing: panic_on_warn set ...
> >>
> >> CPU: 0 PID: 4538 Comm: syz-executor486 Not tainted 4.17.0-rc3+ #33
> >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> >> Google 01/01/2011
> >> Call Trace:
> >>  __dump_stack lib/dump_stack.c:77 [inline]
> >>  dump_stack+0x1b9/0x294 lib/dump_stack.c:113
> >>  panic+0x22f/0x4de kernel/panic.c:184
> >>  __warn.cold.8+0x163/0x1b3 kernel/panic.c:536
> >>  report_bug+0x252/0x2d0 lib/bug.c:186
> >>  fixup_bug arch/x86/kernel/traps.c:178 [inline]
> >>  do_error_trap+0x1de/0x490 arch/x86/kernel/traps.c:296
> >>  do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
> >>  invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
> >> RIP: 0010:kernfs_add_one+0x406/0x4d0 fs/kernfs/dir.c:758
> >> RSP: 0018:8801ca9eece0 EFLAGS: 00010286
> >> RAX: 002d RBX: 87d5cee0 RCX: 8160ba7d
> >> RDX:  RSI: 81610731 RDI: 8801ca9ee840
> >> RBP: 8801ca9eed20 R08: 8801d9538500 R09: 0006
> >> R10: 8801d9538500 R11:  R12: 8801ad1cb6c0
> >> R13: 885da640 R14: 0020 R15: 
> >>  kernfs_create_link+0x112/0x180 fs/kernfs/symlink.c:41
> >>  sysfs_do_create_link_sd.isra.2+0x90/0x130 fs/sysfs/symlink.c:43
> >>  sysfs_do_create_link fs/sysfs/symlink.c:79 [inline]
> >>  sysfs_create_link+0x65/0xc0 fs/sysfs/symlink.c:91
> >>  device_add_class_symlinks drivers/base/core.c:1612 [inline]
> >>  device_add+0x7a0/0x16d0 drivers/base/core.c:1810
> >>  wiphy_register+0x178a/0x2430 net/wireless/core.c:806
> >>  ieee80211_register_hw+0x13cd/0x35d0 net/mac80211/main.c:1047
> >>  mac80211_hwsim_new_radio+0x1d9b/0x3410
> >> drivers/net/wireless/mac80211_hwsim.c:2772
> >>  hwsim_new_radio_nl+0x7a7/0xa60 drivers/net/wireless/mac80211_hwsim.c:3246
> >>  genl_family_rcv_msg+0x889/0x1120 net/netlink/genetlink.c:599
> >>  genl_rcv_msg+0xc6/0x170 net/netlink/genetlink.c:624
> >>  netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2448
> >>  genl_rcv+0x28/0x40 net/netlink/genetlink.c:635
> >>  netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
> >>  netlink_unicast+0x58b/0x740 net/netlink/af_netlink.c:1336
> >>  netlink_sendmsg+0x9f0/0xfa0 net/netlink/af_netlink.c:1901
> >>  sock_sendmsg_nosec net/socket.c:629 [inline]
> >>  sock_sendmsg+0xd5/0x120 n

Re: WARNING in kernfs_add_one

[Greg KH]

On Sat, May 05, 2018 at 08:47:02AM -0700, syzbot wrote:
> Hello,
> 
> syzbot found the following crash on:
> 
> HEAD commit:8fb11a9a8d51 net/ipv6: rename rt6_next to fib6_next
> git tree:   net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=14b2723780
> kernel config:  https://syzkaller.appspot.com/x/.config?x=c416c61f3cd96be
> dashboard link: https://syzkaller.appspot.com/bug?extid=df47f81c226b31d89fb1
> compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=172fb3e780
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=16552e5780
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+df47f81c226b31d89...@syzkaller.appspotmail.com
> 
> RBP: 7fff808f3e10 R08: 0002 R09: 7fff80003534
> R10:  R11: 0246 R12: 
> R13: 0006 R14:  R15: 
> [ cut here ]
> kernfs: ns required in 'ieee80211' for 'phy3'

That's interesting, this looks like a netfilter bug (adding netdev to
the report here.)

Yes, we can "tone down" the kernfs warning to just be an error message
in the log, but there might be something worse going on here.

Network developers, any idea?  Rest of the callback chain is here:


> WARNING: CPU: 0 PID: 4538 at fs/kernfs/dir.c:759 kernfs_add_one+0x406/0x4d0
> fs/kernfs/dir.c:758
> Kernel panic - not syncing: panic_on_warn set ...
> 
> CPU: 0 PID: 4538 Comm: syz-executor486 Not tainted 4.17.0-rc3+ #33
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:77 [inline]
>  dump_stack+0x1b9/0x294 lib/dump_stack.c:113
>  panic+0x22f/0x4de kernel/panic.c:184
>  __warn.cold.8+0x163/0x1b3 kernel/panic.c:536
>  report_bug+0x252/0x2d0 lib/bug.c:186
>  fixup_bug arch/x86/kernel/traps.c:178 [inline]
>  do_error_trap+0x1de/0x490 arch/x86/kernel/traps.c:296
>  do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
>  invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
> RIP: 0010:kernfs_add_one+0x406/0x4d0 fs/kernfs/dir.c:758
> RSP: 0018:8801ca9eece0 EFLAGS: 00010286
> RAX: 002d RBX: 87d5cee0 RCX: 8160ba7d
> RDX:  RSI: 81610731 RDI: 8801ca9ee840
> RBP: 8801ca9eed20 R08: 8801d9538500 R09: 0006
> R10: 8801d9538500 R11:  R12: 8801ad1cb6c0
> R13: 885da640 R14: 0020 R15: 
>  kernfs_create_link+0x112/0x180 fs/kernfs/symlink.c:41
>  sysfs_do_create_link_sd.isra.2+0x90/0x130 fs/sysfs/symlink.c:43
>  sysfs_do_create_link fs/sysfs/symlink.c:79 [inline]
>  sysfs_create_link+0x65/0xc0 fs/sysfs/symlink.c:91
>  device_add_class_symlinks drivers/base/core.c:1612 [inline]
>  device_add+0x7a0/0x16d0 drivers/base/core.c:1810
>  wiphy_register+0x178a/0x2430 net/wireless/core.c:806
>  ieee80211_register_hw+0x13cd/0x35d0 net/mac80211/main.c:1047
>  mac80211_hwsim_new_radio+0x1d9b/0x3410
> drivers/net/wireless/mac80211_hwsim.c:2772
>  hwsim_new_radio_nl+0x7a7/0xa60 drivers/net/wireless/mac80211_hwsim.c:3246
>  genl_family_rcv_msg+0x889/0x1120 net/netlink/genetlink.c:599
>  genl_rcv_msg+0xc6/0x170 net/netlink/genetlink.c:624
>  netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2448
>  genl_rcv+0x28/0x40 net/netlink/genetlink.c:635
>  netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
>  netlink_unicast+0x58b/0x740 net/netlink/af_netlink.c:1336
>  netlink_sendmsg+0x9f0/0xfa0 net/netlink/af_netlink.c:1901
>  sock_sendmsg_nosec net/socket.c:629 [inline]
>  sock_sendmsg+0xd5/0x120 net/socket.c:639
>  ___sys_sendmsg+0x805/0x940 net/socket.c:2117
>  __sys_sendmsg+0x115/0x270 net/socket.c:2155
>  __do_sys_sendmsg net/socket.c:2164 [inline]
>  __se_sys_sendmsg net/socket.c:2162 [inline]
>  __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2162
>  do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
>  entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x4404c9
> RSP: 002b:7fff808f3e08 EFLAGS: 0246 ORIG_RAX: 002e
> RAX: ffda RBX:  RCX: 004404c9
> RDX:  RSI: 20b3dfc8 RDI: 0005
> RBP: 7fff808f3e10 R08: 0002 R09: 7fff80003534
> R10:  R11: 0246 R12: 
> R13: 0006 R14:  R15: 
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..


Any ideas?

thanks,

greg k-h

Re: Request for stable 4.14.x inclusion: net: don't call update_pmtu unconditionally

[Greg KH]

On Tue, May 01, 2018 at 12:15:37AM +0200, Thomas Deutschmann wrote:
> Hi,
> 
> On 2018-04-30 20:22, Greg KH wrote:
> > The geneve hunk doesn't apply at all to the 4.14.y tree, so I think
> > someone has a messed up tree somewhere...
> > 
> > I'll go look into this now.
> 
> Mh?
> 
> > $ git clone 
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> > $ cd linux-stable
> > $ git checkout v4.14.38
> > $ git cherry-pick 52a589d51f1008f62569bf89e95b26221ee76690
> 
> Works for me... then I cherry-pick
> f15ca723c1ebe6c1a06bc95fda6b62cd87b44559 on top, adjust
> "net/ipv6/ip6_tunnel.c" like shown in my previous mail and everything is
> fine for me...

Ah crap, I missed the dependancy here as well, it was a long day
yesterday...

I'll drop this and try it again for the next release.

greg k-h

Re: Request for stable 4.14.x inclusion: net: don't call update_pmtu unconditionally

[Greg KH]

On Fri, Apr 27, 2018 at 07:43:52PM +0100, Eddie Chapman wrote:
> On 27/04/18 19:07, Thomas Deutschmann wrote:
> > Hi Greg,
> > 
> > first, we need to cherry-pick another patch first:
> > >  From 52a589d51f1008f62569bf89e95b26221ee76690 Mon Sep 17 00:00:00 2001
> > > From: Xin Long <lucien@gmail.com>
> > > Date: Mon, 25 Dec 2017 14:43:58 +0800
> > > Subject: [PATCH] geneve: update skb dst pmtu on tx path
> > > 
> > > Commit a93bf0ff4490 ("vxlan: update skb dst pmtu on tx path") has fixed
> > > a performance issue caused by the change of lower dev's mtu for vxlan.
> > > 
> > > The same thing needs to be done for geneve as well.
> > > 
> > > Note that geneve cannot adjust it's mtu according to lower dev's mtu
> > > when creating it. The performance is very low later when netperfing
> > > over it without fixing the mtu manually. This patch could also avoid
> > > this issue.
> > > 
> > > Signed-off-by: Xin Long <lucien@gmail.com>
> > > Signed-off-by: David S. Miller <da...@davemloft.net>
> 
> Oops, I completely missed that the coreos patch doesn't have the geneve hunk
> that is in the original 4.15 patch. I don't load the geneve module on my box
> hence why no problems surfaced on my machine.

The geneve hunk doesn't apply at all to the 4.14.y tree, so I think
someone has a messed up tree somewhere...

I'll go look into this now.

greg k-h

Re: Request for stable 4.14.x inclusion: net: don't call update_pmtu unconditionally

[Greg KH]

On Fri, Apr 27, 2018 at 07:43:52PM +0100, Eddie Chapman wrote:
> On 27/04/18 19:07, Thomas Deutschmann wrote:
> > Hi Greg,
> > 
> > first, we need to cherry-pick another patch first:
> > >  From 52a589d51f1008f62569bf89e95b26221ee76690 Mon Sep 17 00:00:00 2001
> > > From: Xin Long <lucien@gmail.com>
> > > Date: Mon, 25 Dec 2017 14:43:58 +0800
> > > Subject: [PATCH] geneve: update skb dst pmtu on tx path
> > > 
> > > Commit a93bf0ff4490 ("vxlan: update skb dst pmtu on tx path") has fixed
> > > a performance issue caused by the change of lower dev's mtu for vxlan.
> > > 
> > > The same thing needs to be done for geneve as well.
> > > 
> > > Note that geneve cannot adjust it's mtu according to lower dev's mtu
> > > when creating it. The performance is very low later when netperfing
> > > over it without fixing the mtu manually. This patch could also avoid
> > > this issue.
> > > 
> > > Signed-off-by: Xin Long <lucien@gmail.com>
> > > Signed-off-by: David S. Miller <da...@davemloft.net>
> 
> Oops, I completely missed that the coreos patch doesn't have the geneve hunk
> that is in the original 4.15 patch. I don't load the geneve module on my box
> hence why no problems surfaced on my machine.
> 
> Thanks Thomas for the correct instructions. Ignore my message Greg, I'll
> drop back into the shadows where I belong, sorry for the noise!

Talking about patches and pointing me at them is not noise at all, don't
be sorry! :)

I'll work on this after these next kernels are released, thanks all for
the details on what needs to be done.

greg k-h

Re: Request for stable 4.14.x inclusion: net: don't call update_pmtu unconditionally

[Greg KH]

On Fri, Apr 27, 2018 at 03:51:25PM +0200, Greg KH wrote:
> On Fri, Apr 27, 2018 at 02:20:07PM +0200, Thomas Deutschmann wrote:
> > On 2018-04-22 23:50, Thomas Deutschmann wrote:
> > > Hi,
> > > 
> > > please add
> > > 
> > >> From f15ca723c1ebe6c1a06bc95fda6b62cd87b44559 Mon Sep 17 00:00:00 2001
> > >> From: Nicolas Dichtel <nicolas.dich...@6wind.com>
> > >> Date: Thu, 25 Jan 2018 19:03:03 +0100
> > >> Subject: net: don't call update_pmtu unconditionally
> > >>
> > >> Some dst_ops (e.g. md_dst_ops)) doesn't set this handler. It may result 
> > >> to:
> > >> "BUG: unable to handle kernel NULL pointer dereference at   
> > >> (null)"
> > >>
> > >> Let's add a helper to check if update_pmtu is available before calling 
> > >> it.
> > >>
> > >> Fixes: 52a589d51f10 ("geneve: update skb dst pmtu on tx path")
> > >> Fixes: a93bf0ff4490 ("vxlan: update skb dst pmtu on tx path")
> > >> CC: Roman Kapl <c...@rkapl.cz>
> > >> CC: Xin Long <lucien@gmail.com>
> > >> Signed-off-by: Nicolas Dichtel <nicolas.dich...@6wind.com>
> > >> Signed-off-by: David S. Miller <da...@davemloft.net>
> > > 
> > > to 4.14.x.
> > > 
> > > This fixes NULL derefs caused by a93bf0ff4490 ("vxlan: update
> > > skb dst pmtu on tx path"), which was backported to 4.14.24.
> > 
> > *ping* - Not yet applied and not yet queued. Is there a problem with the
> > patch which prevents a cherry-pick for 4.14.x?
> 
> This looks like an "obvious" fix for me to pick up.

Well, it would be "obvious" if it actually applied to the 4.14.y tree :(

Thomas, did you try this patch out?  I can't apply it as-is, it will
need a backport.  Please work on that, and test it out, as I don't get
the impression that you did that here.

Then post the working backport and I'll be glad to consider it for
future 4.14.y releases.

thanks,

greg k-h

Re: Request for stable 4.14.x inclusion: net: don't call update_pmtu unconditionally

[Greg KH]

On Fri, Apr 27, 2018 at 02:20:07PM +0200, Thomas Deutschmann wrote:
> On 2018-04-22 23:50, Thomas Deutschmann wrote:
> > Hi,
> > 
> > please add
> > 
> >> From f15ca723c1ebe6c1a06bc95fda6b62cd87b44559 Mon Sep 17 00:00:00 2001
> >> From: Nicolas Dichtel <nicolas.dich...@6wind.com>
> >> Date: Thu, 25 Jan 2018 19:03:03 +0100
> >> Subject: net: don't call update_pmtu unconditionally
> >>
> >> Some dst_ops (e.g. md_dst_ops)) doesn't set this handler. It may result to:
> >> "BUG: unable to handle kernel NULL pointer dereference at   (null)"
> >>
> >> Let's add a helper to check if update_pmtu is available before calling it.
> >>
> >> Fixes: 52a589d51f10 ("geneve: update skb dst pmtu on tx path")
> >> Fixes: a93bf0ff4490 ("vxlan: update skb dst pmtu on tx path")
> >> CC: Roman Kapl <c...@rkapl.cz>
> >> CC: Xin Long <lucien@gmail.com>
> >> Signed-off-by: Nicolas Dichtel <nicolas.dich...@6wind.com>
> >> Signed-off-by: David S. Miller <da...@davemloft.net>
> > 
> > to 4.14.x.
> > 
> > This fixes NULL derefs caused by a93bf0ff4490 ("vxlan: update
> > skb dst pmtu on tx path"), which was backported to 4.14.24.
> 
> *ping* - Not yet applied and not yet queued. Is there a problem with the
> patch which prevents a cherry-pick for 4.14.x?

This looks like an "obvious" fix for me to pick up.

Dave, any objections for me just grabbing it as-is?

thanks,

greg k-h

Re: [PATCH stable v4.4+] r8152: add Linksys USB3GIGV1 id

[Greg KH]

On Wed, Apr 25, 2018 at 11:54:37AM +0200, Krzysztof Kozlowski wrote:
> commit 90841047a01b452cc8c3f9b990698b264143334a upstream
> 
> This linksys dongle by default comes up in cdc_ether mode.
> This patch allows r8152 to claim the device:
>Bus 002 Device 002: ID 13b1:0041 Linksys
> 
> Signed-off-by: Grant Grundler <grund...@chromium.org>
> Reviewed-by: Douglas Anderson <diand...@chromium.org>
> Signed-off-by: David S. Miller <da...@davemloft.net>
> [krzk: Rebase on v4.4]

Also added to 4.9.y, thanks.

greg k-h

Re: [PATCH 09/15] net: irda: pxaficp_ir: remove the dmaengine compat need

[Greg Kroah-Hartman]

On Mon, Apr 02, 2018 at 04:26:50PM +0200, Robert Jarzmik wrote:
> As the pxa architecture switched towards the dmaengine slave map, the
> old compatibility mechanism to acquire the dma requestor line number and
> priority are not needed anymore.
> 
> This patch simplifies the dma resource acquisition, using the more
> generic function dma_request_slave_channel().
> 
> Signed-off-by: Robert Jarzmik <robert.jarz...@free.fr>
> ---
>  drivers/staging/irda/drivers/pxaficp_ir.c | 14 ++
>  1 file changed, 2 insertions(+), 12 deletions(-)

This file is no longer in Linus's tree :)

thanks,

greg k-h

Re: [PATCH net-next v4 1/3] vmcore: add API to collect hardware dump in second kernel

[Greg KH]

On Tue, Apr 17, 2018 at 01:14:17PM +0530, Rahul Lakkireddy wrote:
> +config PROC_VMCORE_DEVICE_DUMP
> + bool "Device Hardware/Firmware Log Collection"
> + depends on PROC_VMCORE
> + default y

Only things that require the machine to keep working should be 'default
y', please remove this, it's an option.

> + help
> +   Device drivers can collect the device specific snapshot of
> +   their hardware or firmware before they are initialized in
> +   crash recovery kernel. If you say Y here, the device dumps
> +   will be added as ELF notes to /proc/vmcore

Which exact "device drivers" are you referring to here?

thanks,

greg k-h

[PATCH 4.4 004/190] x86/asm: Dont use RBP as a temporary register in csum_partial_copy_generic()

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Josh Poimboeuf <jpoim...@redhat.com>


[ Upstream commit 42fc6c6cb1662ba2fa727dd01c9473c63be4e3b6 ]

Andrey Konovalov reported the following warning while fuzzing the kernel
with syzkaller:

  WARNING: kernel stack regs at 8800686869f8 in a.out:4933 has bad 'bp' 
value c3fc855a10167ec0

The unwinder dump revealed that RBP had a bad value when an interrupt
occurred in csum_partial_copy_generic().

That function saves RBP on the stack and then overwrites it, using it as
a scratch register.  That's problematic because it breaks stack traces
if an interrupt occurs in the middle of the function.

Replace the usage of RBP with another callee-saved register (R15) so
stack traces are no longer affected.

Reported-by: Andrey Konovalov <andreyk...@google.com>
Tested-by: Andrey Konovalov <andreyk...@google.com>
Signed-off-by: Josh Poimboeuf <jpoim...@redhat.com>
Cc: Cong Wang <xiyou.wangc...@gmail.com>
Cc: David S . Miller <da...@davemloft.net>
Cc: Dmitry Vyukov <dvyu...@google.com>
Cc: Eric Dumazet <eduma...@google.com>
Cc: Kostya Serebryany <k...@google.com>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Marcelo Ricardo Leitner <marcelo.leit...@gmail.com>
Cc: Neil Horman <nhor...@tuxdriver.com>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Vlad Yasevich <vyasev...@gmail.com>
Cc: linux-s...@vger.kernel.org
Cc: netdev <netdev@vger.kernel.org>
Cc: syzkaller <syzkal...@googlegroups.com>
Link: 
http://lkml.kernel.org/r/4b03a961efda5ec9bfe46b7b9c9ad72d1efad343.1493909486.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar <mi...@kernel.org>
Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 arch/x86/lib/csum-copy_64.S |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

--- a/arch/x86/lib/csum-copy_64.S
+++ b/arch/x86/lib/csum-copy_64.S
@@ -55,7 +55,7 @@ ENTRY(csum_partial_copy_generic)
movq  %r12, 3*8(%rsp)
movq  %r14, 4*8(%rsp)
movq  %r13, 5*8(%rsp)
-   movq  %rbp, 6*8(%rsp)
+   movq  %r15, 6*8(%rsp)
 
movq  %r8, (%rsp)
movq  %r9, 1*8(%rsp)
@@ -74,7 +74,7 @@ ENTRY(csum_partial_copy_generic)
/* main loop. clear in 64 byte blocks */
/* r9: zero, r8: temp2, rbx: temp1, rax: sum, rcx: saved length */
/* r11: temp3, rdx: temp4, r12 loopcnt */
-   /* r10: temp5, rbp: temp6, r14 temp7, r13 temp8 */
+   /* r10: temp5, r15: temp6, r14 temp7, r13 temp8 */
.p2align 4
 .Lloop:
source
@@ -89,7 +89,7 @@ ENTRY(csum_partial_copy_generic)
source
movq  32(%rdi), %r10
source
-   movq  40(%rdi), %rbp
+   movq  40(%rdi), %r15
source
movq  48(%rdi), %r14
source
@@ -103,7 +103,7 @@ ENTRY(csum_partial_copy_generic)
adcq  %r11, %rax
adcq  %rdx, %rax
adcq  %r10, %rax
-   adcq  %rbp, %rax
+   adcq  %r15, %rax
adcq  %r14, %rax
adcq  %r13, %rax
 
@@ -121,7 +121,7 @@ ENTRY(csum_partial_copy_generic)
dest
movq %r10, 32(%rsi)
dest
-   movq %rbp, 40(%rsi)
+   movq %r15, 40(%rsi)
dest
movq %r14, 48(%rsi)
dest
@@ -203,7 +203,7 @@ ENTRY(csum_partial_copy_generic)
movq 3*8(%rsp), %r12
movq 4*8(%rsp), %r14
movq 5*8(%rsp), %r13
-   movq 6*8(%rsp), %rbp
+   movq 6*8(%rsp), %r15
addq $7*8, %rsp
ret
 

[PATCH 4.9 005/310] x86/asm: Dont use RBP as a temporary register in csum_partial_copy_generic()

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Josh Poimboeuf <jpoim...@redhat.com>


[ Upstream commit 42fc6c6cb1662ba2fa727dd01c9473c63be4e3b6 ]

Andrey Konovalov reported the following warning while fuzzing the kernel
with syzkaller:

  WARNING: kernel stack regs at 8800686869f8 in a.out:4933 has bad 'bp' 
value c3fc855a10167ec0

The unwinder dump revealed that RBP had a bad value when an interrupt
occurred in csum_partial_copy_generic().

That function saves RBP on the stack and then overwrites it, using it as
a scratch register.  That's problematic because it breaks stack traces
if an interrupt occurs in the middle of the function.

Replace the usage of RBP with another callee-saved register (R15) so
stack traces are no longer affected.

Reported-by: Andrey Konovalov <andreyk...@google.com>
Tested-by: Andrey Konovalov <andreyk...@google.com>
Signed-off-by: Josh Poimboeuf <jpoim...@redhat.com>
Cc: Cong Wang <xiyou.wangc...@gmail.com>
Cc: David S . Miller <da...@davemloft.net>
Cc: Dmitry Vyukov <dvyu...@google.com>
Cc: Eric Dumazet <eduma...@google.com>
Cc: Kostya Serebryany <k...@google.com>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Marcelo Ricardo Leitner <marcelo.leit...@gmail.com>
Cc: Neil Horman <nhor...@tuxdriver.com>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Vlad Yasevich <vyasev...@gmail.com>
Cc: linux-s...@vger.kernel.org
Cc: netdev <netdev@vger.kernel.org>
Cc: syzkaller <syzkal...@googlegroups.com>
Link: 
http://lkml.kernel.org/r/4b03a961efda5ec9bfe46b7b9c9ad72d1efad343.1493909486.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar <mi...@kernel.org>
Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 arch/x86/lib/csum-copy_64.S |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

--- a/arch/x86/lib/csum-copy_64.S
+++ b/arch/x86/lib/csum-copy_64.S
@@ -55,7 +55,7 @@ ENTRY(csum_partial_copy_generic)
movq  %r12, 3*8(%rsp)
movq  %r14, 4*8(%rsp)
movq  %r13, 5*8(%rsp)
-   movq  %rbp, 6*8(%rsp)
+   movq  %r15, 6*8(%rsp)
 
movq  %r8, (%rsp)
movq  %r9, 1*8(%rsp)
@@ -74,7 +74,7 @@ ENTRY(csum_partial_copy_generic)
/* main loop. clear in 64 byte blocks */
/* r9: zero, r8: temp2, rbx: temp1, rax: sum, rcx: saved length */
/* r11: temp3, rdx: temp4, r12 loopcnt */
-   /* r10: temp5, rbp: temp6, r14 temp7, r13 temp8 */
+   /* r10: temp5, r15: temp6, r14 temp7, r13 temp8 */
.p2align 4
 .Lloop:
source
@@ -89,7 +89,7 @@ ENTRY(csum_partial_copy_generic)
source
movq  32(%rdi), %r10
source
-   movq  40(%rdi), %rbp
+   movq  40(%rdi), %r15
source
movq  48(%rdi), %r14
source
@@ -103,7 +103,7 @@ ENTRY(csum_partial_copy_generic)
adcq  %r11, %rax
adcq  %rdx, %rax
adcq  %r10, %rax
-   adcq  %rbp, %rax
+   adcq  %r15, %rax
adcq  %r14, %rax
adcq  %r13, %rax
 
@@ -121,7 +121,7 @@ ENTRY(csum_partial_copy_generic)
dest
movq %r10, 32(%rsi)
dest
-   movq %rbp, 40(%rsi)
+   movq %r15, 40(%rsi)
dest
movq %r14, 48(%rsi)
dest
@@ -203,7 +203,7 @@ ENTRY(csum_partial_copy_generic)
movq 3*8(%rsp), %r12
movq 4*8(%rsp), %r14
movq 5*8(%rsp), %r13
-   movq 6*8(%rsp), %rbp
+   movq 6*8(%rsp), %r15
addq $7*8, %rsp
ret
 

Re: [PATCH 1/2] staging: irda: Replace mdelay with usleep_range in stir421x_fw_upload

[Greg KH]

On Wed, Apr 11, 2018 at 04:11:00PM +0800, Jia-Ju Bai wrote:
> 
> 
> On 2018/4/11 16:03, Greg KH wrote:
> > On Wed, Apr 11, 2018 at 03:17:10PM +0800, Jia-Ju Bai wrote:
> > > 
> > > On 2018/4/11 14:41, Greg KH wrote:
> > > > On Wed, Apr 11, 2018 at 09:29:34AM +0800, Jia-Ju Bai wrote:
> > > > > stir421x_fw_upload() is never called in atomic context.
> > > > > 
> > > > > The call chain ending up at stir421x_fw_upload() is:
> > > > > [1] stir421x_fw_upload() <- stir421x_patch_device() <- 
> > > > > irda_usb_probe()
> > > > > 
> > > > > irda_usb_probe() is set as ".probe" in struct usb_driver.
> > > > > This function is not called in atomic context.
> > > > > 
> > > > > Despite never getting called from atomic context, stir421x_fw_upload()
> > > > > calls mdelay() to busily wait.
> > > > > This is not necessary and can be replaced with usleep_range() to
> > > > > avoid busy waiting.
> > > > > 
> > > > > This is found by a static analysis tool named DCNS written by myself.
> > > > > And I also manually check it.
> > > > > 
> > > > > Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
> > > > > ---
> > > > >drivers/staging/irda/drivers/irda-usb.c | 2 +-
> > > > >1 file changed, 1 insertion(+), 1 deletion(-)
> > > > Please, at the very least, work off of Linus's tree.  There is no
> > > > drivers/staging/irda/ anymore :)
> > > > 
> > > Okay, sorry.
> > > Could you please recommend me a right tree or its git address?
> > Have you looked in the MAINTAINERS file?  Worst case, always use
> > linux-next.
> > 
> > greg k-h
> 
> Oh, sorry, I did notice the git tree in the MAINTAINERS file.
> I always used linux-stable.

linux-stable is almost never the tree to use as it is almost always
12000 patches behind what is in Linus's tree and about 2 changes
behind linux-next.

thanks,

greg k-h

Re: [PATCH 1/2] staging: irda: Replace mdelay with usleep_range in stir421x_fw_upload

[Greg KH]

On Wed, Apr 11, 2018 at 03:17:10PM +0800, Jia-Ju Bai wrote:
> 
> 
> On 2018/4/11 14:41, Greg KH wrote:
> > On Wed, Apr 11, 2018 at 09:29:34AM +0800, Jia-Ju Bai wrote:
> > > stir421x_fw_upload() is never called in atomic context.
> > > 
> > > The call chain ending up at stir421x_fw_upload() is:
> > > [1] stir421x_fw_upload() <- stir421x_patch_device() <- irda_usb_probe()
> > > 
> > > irda_usb_probe() is set as ".probe" in struct usb_driver.
> > > This function is not called in atomic context.
> > > 
> > > Despite never getting called from atomic context, stir421x_fw_upload()
> > > calls mdelay() to busily wait.
> > > This is not necessary and can be replaced with usleep_range() to
> > > avoid busy waiting.
> > > 
> > > This is found by a static analysis tool named DCNS written by myself.
> > > And I also manually check it.
> > > 
> > > Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
> > > ---
> > >   drivers/staging/irda/drivers/irda-usb.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > Please, at the very least, work off of Linus's tree.  There is no
> > drivers/staging/irda/ anymore :)
> > 
> 
> Okay, sorry.
> Could you please recommend me a right tree or its git address?

Have you looked in the MAINTAINERS file?  Worst case, always use
linux-next.

greg k-h

Re: [PATCH 1/2] staging: irda: Replace mdelay with usleep_range in stir421x_fw_upload

[Greg KH]

On Wed, Apr 11, 2018 at 09:29:34AM +0800, Jia-Ju Bai wrote:
> stir421x_fw_upload() is never called in atomic context.
> 
> The call chain ending up at stir421x_fw_upload() is:
> [1] stir421x_fw_upload() <- stir421x_patch_device() <- irda_usb_probe()
> 
> irda_usb_probe() is set as ".probe" in struct usb_driver.
> This function is not called in atomic context.
> 
> Despite never getting called from atomic context, stir421x_fw_upload()
> calls mdelay() to busily wait.
> This is not necessary and can be replaced with usleep_range() to
> avoid busy waiting.
> 
> This is found by a static analysis tool named DCNS written by myself.
> And I also manually check it.
> 
> Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>
> ---
>  drivers/staging/irda/drivers/irda-usb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Please, at the very least, work off of Linus's tree.  There is no
drivers/staging/irda/ anymore :)

thanks,

greg k-h

Re: [PATCH] Patch to replace DEFINE_SEMAPHORE with DEFINE_BINARY_SEMAPHORE

[Greg Kroah-Hartman]

On Sat, Mar 31, 2018 at 07:16:21PM +0530, Wasim Nazir wrote:
> This message contains confidential information and is intended only for the 
> individual(s) named. If you are not the intended recipient, you are 
> notified that disclosing, copying, distributing or taking any action in 
> reliance on the contents of this mail and attached file/s is strictly 
> prohibited. Please notify the sender immediately and delete this e-mail 
> from your system. E-mail transmission cannot be guaranteed to be secured or 
> error-free as information could be intercepted, corrupted, lost, destroyed, 
> arrive late or incomplete, or contain viruses. The sender therefore does 
> not accept liability for any errors or omissions in the contents of this 
> message, which arise as a result of e-mail transmission.


This footer is not compatible with patches submitted to the kernel,
sorry.  email is now deleted.

greg k-h

Re: [PATCH] net: fec: set dma_coherent_mask

[Greg Ungerer]

Hi Geert,

On 28/03/18 17:57, Geert Uytterhoeven wrote:
[skip]

[PATCH] m68k: set dma and coherent masks for platform FEC ethernets

As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
coherent_dma_mask") the Freescale FEC driver is issuing the following
warning on driver initialization on ColdFire systems:

WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 0x40159e20
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc7-dirty #4
Stack from 41833dd8:
 41833dd8 40259c53 40025534 40279e26 0003  4004e514 41827000
 400255de 40244e42 0204 40159e20 0009   4024531d
 40159e20 40244e42 0204    0007 
  40279e26 4028d040 40226576 4003ae88 40279e26 418273f6 41833ef8
 7fff 418273f2 41867028 4003c9a2 4180ac6c 0004 41833f8c 4013e71c
 40279e1c 40279e26 40226c16 4013ced2 40279e26 40279e58 4028d040 
Call Trace:
 [<40025534>] 0x40025534
  [<4004e514>] 0x4004e514
  [<400255de>] 0x400255de
  [<40159e20>] 0x40159e20
  [<40159e20>] 0x40159e20

It is not fatal, the driver and the system continue to function normally.

As per the warning the coherent_dma_mask is not set on this device.
There is nothing special about the DMA memory coherency on this hardware
so we can just set the mask to 32bits in the platform data for the FEC
ethernet devices.

Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
---
  arch/m68k/coldfire/device.c | 14 --
  1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/m68k/coldfire/device.c b/arch/m68k/coldfire/device.c
index 84938fd..f93e0e5 100644
--- a/arch/m68k/coldfire/device.c
+++ b/arch/m68k/coldfire/device.c
@@ -130,12 +130,18 @@
 },
  };

+static u64 mcf_dma_mask = DMA_BIT_MASK(32);
+
  static struct platform_device mcf_fec0 = {
 .name   = FEC_NAME,
 .id = 0,
 .num_resources  = ARRAY_SIZE(mcf_fec0_resources),
 .resource   = mcf_fec0_resources,
-   .dev.platform_data  = FEC_PDATA,
+   .dev = {
+   .dma_mask   = _dma_mask,


Can you make this _fec0.dev.coherent_dma_mask, removing the need for
mcf_dma_mask, or doesn't C allow that?


Yes, sure can. Looks like some other architectures do that too.
I'll change it. Thanks.

Regards
Greg




+   .coherent_dma_mask  = DMA_BIT_MASK(32),
+   .platform_data  = FEC_PDATA,
+   }
  };

  #ifdef MCFFEC_BASE1
@@ -167,7 +173,11 @@
 .id = 1,
 .num_resources  = ARRAY_SIZE(mcf_fec1_resources),
 .resource   = mcf_fec1_resources,
-   .dev.platform_data  = FEC_PDATA,
+   .dev = {
+   .dma_mask   = _dma_mask,


Likewise.


+   .coherent_dma_mask  = DMA_BIT_MASK(32),
+   .platform_data  = FEC_PDATA,
+   }


Gr{oetje,eeting}s,

 Geert

Re: [PATCH] net: fec: set dma_coherent_mask

[Greg Ungerer]

Hi Geert,

On 27/03/18 22:59, Geert Uytterhoeven wrote:
> On Mon, Mar 26, 2018 at 3:36 PM, Greg Ungerer <g...@linux-m68k.org> wrote:
>> As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
>> coherent_dma_mask") the Freescale FEC driver is issuing the following
>> warning on driver initialization on ColdFire systems:
>>
>> WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 0x40159e20
>> Modules linked in:
>> CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc7-dirty #4
>> Stack from 41833dd8:
>> 41833dd8 40259c53 40025534 40279e26 0003  4004e514 
>> 41827000
>> 400255de 40244e42 0204 40159e20 0009   
>> 4024531d
>> 40159e20 40244e42 0204    0007 
>> 
>>  40279e26 4028d040 40226576 4003ae88 40279e26 418273f6 
>> 41833ef8
>> 7fff 418273f2 41867028 4003c9a2 4180ac6c 0004 41833f8c 
>> 4013e71c
>> 40279e1c 40279e26 40226c16 4013ced2 40279e26 40279e58 4028d040 
>> 
>> Call Trace:
>> [<40025534>] 0x40025534
>>  [<4004e514>] 0x4004e514
>>  [<400255de>] 0x400255de
>>  [<40159e20>] 0x40159e20
>>  [<40159e20>] 0x40159e20
>>
>> It is not fatal, the driver and the system continue to function normally.
>>
>> As per the warning the coherent_dma_mask is not set on this device.
>> There is nothing special about the DMA memory coherency on this hardware
>> so we can just set the mask to 32bits during probe.
>>
>> Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
> 
> Thanks for your patch!
> 
>> ---
>>  drivers/net/ethernet/freescale/fec_main.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> Is this the best way to handle this problem?
>> Comments welcome...
>>
>> diff --git a/drivers/net/ethernet/freescale/fec_main.c 
>> b/drivers/net/ethernet/freescale/fec_main.c
>> index d4604bc..3cb130a 100644
>> --- a/drivers/net/ethernet/freescale/fec_main.c
>> +++ b/drivers/net/ethernet/freescale/fec_main.c
>> @@ -2702,6 +2702,8 @@ static int fec_enet_alloc_queue(struct net_device 
>> *ndev)
>> int ret = 0;
>> struct fec_enet_priv_tx_q *txq;
>>
>> +   dma_set_coherent_mask(>pdev->dev, DMA_BIT_MASK(32));
>> +
>> for (i = 0; i < fep->num_tx_queues; i++) {
>> txq = kzalloc(sizeof(*txq), GFP_KERNEL);
>> if (!txq) {
> 
> As per your other email, this does not trigger on iMX systems using DT.
> Hence I'm wondering if the Coldfire platform code shouldn't just do the
> same what drivers/of/device.c does, cfr.
> https://www.spinics.net/lists/linux-m68k/msg10929.html?

I had been thinking that all along, but I couldn't see how to set this when
there was no real bus involved that would have configured this. Turns out
for platform devices you can set it as part of the platform setup. So now
the patch becomes specific to the ColdFire and FEC ethernet devices.

Regards
Greg

---

[PATCH] m68k: set dma and coherent masks for platform FEC ethernets

As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
coherent_dma_mask") the Freescale FEC driver is issuing the following
warning on driver initialization on ColdFire systems:

WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 0x40159e20
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc7-dirty #4
Stack from 41833dd8:
41833dd8 40259c53 40025534 40279e26 0003  4004e514 41827000
400255de 40244e42 0204 40159e20 0009   4024531d
40159e20 40244e42 0204    0007 
 40279e26 4028d040 40226576 4003ae88 40279e26 418273f6 41833ef8
7fff 418273f2 41867028 4003c9a2 4180ac6c 0004 41833f8c 4013e71c
40279e1c 40279e26 40226c16 4013ced2 40279e26 40279e58 4028d040 
Call Trace:
[<40025534>] 0x40025534
 [<4004e514>] 0x4004e514
 [<400255de>] 0x400255de
 [<40159e20>] 0x40159e20
 [<40159e20>] 0x40159e20

It is not fatal, the driver and the system continue to function normally.

As per the warning the coherent_dma_mask is not set on this device.
There is nothing special about the DMA memory coherency on this hardware
so we can just set the mask to 32bits in the platform data for the FEC
ethernet devices.

Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
---
 arch/m68k/coldfire/device.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/m68k/coldfire/device.c b/arch/m68k/coldfire/device.c
index 84938fd

[PATCH] net: fec: set dma_coherent_mask

[Greg Ungerer]

As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
coherent_dma_mask") the Freescale FEC driver is issuing the following
warning on driver initialization on ColdFire systems:

WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 0x40159e20
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc7-dirty #4
Stack from 41833dd8:
41833dd8 40259c53 40025534 40279e26 0003  4004e514 41827000
400255de 40244e42 0204 40159e20 0009   4024531d
40159e20 40244e42 0204    0007 
 40279e26 4028d040 40226576 4003ae88 40279e26 418273f6 41833ef8
7fff 418273f2 41867028 4003c9a2 4180ac6c 0004 41833f8c 4013e71c
40279e1c 40279e26 40226c16 4013ced2 40279e26 40279e58 4028d040 
Call Trace:
[<40025534>] 0x40025534
 [<4004e514>] 0x4004e514
 [<400255de>] 0x400255de
 [<40159e20>] 0x40159e20
 [<40159e20>] 0x40159e20

It is not fatal, the driver and the system continue to function normally.

As per the warning the coherent_dma_mask is not set on this device.
There is nothing special about the DMA memory coherency on this hardware
so we can just set the mask to 32bits during probe.

Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
---
 drivers/net/ethernet/freescale/fec_main.c | 2 ++
 1 file changed, 2 insertions(+)

Is this the best way to handle this problem?
Comments welcome...

diff --git a/drivers/net/ethernet/freescale/fec_main.c 
b/drivers/net/ethernet/freescale/fec_main.c
index d4604bc..3cb130a 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -2702,6 +2702,8 @@ static int fec_enet_alloc_queue(struct net_device *ndev)
int ret = 0;
struct fec_enet_priv_tx_q *txq;
 
+   dma_set_coherent_mask(>pdev->dev, DMA_BIT_MASK(32));
+
for (i = 0; i < fep->num_tx_queues; i++) {
txq = kzalloc(sizeof(*txq), GFP_KERNEL);
if (!txq) {
-- 
1.9.1

[PATCH 4.9 015/177] time: Change posix clocks ops interfaces to use timespec64

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Deepa Dinamani <deepa.ker...@gmail.com>


[ Upstream commit d340266e19ddb70dbd608f9deedcfb35fdb9d419 ]

struct timespec is not y2038 safe on 32 bit machines.

The posix clocks apis use struct timespec directly and through struct
itimerspec.

Replace the posix clock interfaces to use struct timespec64 and struct
itimerspec64 instead.  Also fix up their implementations accordingly.

Note that the clock_getres() interface has also been changed to use
timespec64 even though this particular interface is not affected by the
y2038 problem. This helps verification for internal kernel code for y2038
readiness by getting rid of time_t/ timeval/ timespec.

Signed-off-by: Deepa Dinamani <deepa.ker...@gmail.com>
Cc: a...@arndb.de
Cc: y2...@lists.linaro.org
Cc: netdev@vger.kernel.org
Cc: Richard Cochran <richardcoch...@gmail.com>
Cc: john.stu...@linaro.org
Link: 
http://lkml.kernel.org/r/1490555058-4603-3-git-send-email-deepa.ker...@gmail.com
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 drivers/ptp/ptp_clock.c |   18 +++---
 include/linux/posix-clock.h |   10 +-
 kernel/time/posix-clock.c   |   34 --
 3 files changed, 36 insertions(+), 26 deletions(-)

--- a/drivers/ptp/ptp_clock.c
+++ b/drivers/ptp/ptp_clock.c
@@ -97,30 +97,26 @@ static s32 scaled_ppm_to_ppb(long ppm)
 
 /* posix clock implementation */
 
-static int ptp_clock_getres(struct posix_clock *pc, struct timespec *tp)
+static int ptp_clock_getres(struct posix_clock *pc, struct timespec64 *tp)
 {
tp->tv_sec = 0;
tp->tv_nsec = 1;
return 0;
 }
 
-static int ptp_clock_settime(struct posix_clock *pc, const struct timespec *tp)
+static int ptp_clock_settime(struct posix_clock *pc, const struct timespec64 
*tp)
 {
struct ptp_clock *ptp = container_of(pc, struct ptp_clock, clock);
-   struct timespec64 ts = timespec_to_timespec64(*tp);
 
-   return  ptp->info->settime64(ptp->info, );
+   return  ptp->info->settime64(ptp->info, tp);
 }
 
-static int ptp_clock_gettime(struct posix_clock *pc, struct timespec *tp)
+static int ptp_clock_gettime(struct posix_clock *pc, struct timespec64 *tp)
 {
struct ptp_clock *ptp = container_of(pc, struct ptp_clock, clock);
-   struct timespec64 ts;
int err;
 
-   err = ptp->info->gettime64(ptp->info, );
-   if (!err)
-   *tp = timespec64_to_timespec(ts);
+   err = ptp->info->gettime64(ptp->info, tp);
return err;
 }
 
@@ -133,7 +129,7 @@ static int ptp_clock_adjtime(struct posi
ops = ptp->info;
 
if (tx->modes & ADJ_SETOFFSET) {
-   struct timespec ts;
+   struct timespec64 ts;
ktime_t kt;
s64 delta;
 
@@ -146,7 +142,7 @@ static int ptp_clock_adjtime(struct posi
if ((unsigned long) ts.tv_nsec >= NSEC_PER_SEC)
return -EINVAL;
 
-   kt = timespec_to_ktime(ts);
+   kt = timespec64_to_ktime(ts);
delta = ktime_to_ns(kt);
err = ops->adjtime(ops, delta);
} else if (tx->modes & ADJ_FREQUENCY) {
--- a/include/linux/posix-clock.h
+++ b/include/linux/posix-clock.h
@@ -59,23 +59,23 @@ struct posix_clock_operations {
 
int  (*clock_adjtime)(struct posix_clock *pc, struct timex *tx);
 
-   int  (*clock_gettime)(struct posix_clock *pc, struct timespec *ts);
+   int  (*clock_gettime)(struct posix_clock *pc, struct timespec64 *ts);
 
-   int  (*clock_getres) (struct posix_clock *pc, struct timespec *ts);
+   int  (*clock_getres) (struct posix_clock *pc, struct timespec64 *ts);
 
int  (*clock_settime)(struct posix_clock *pc,
- const struct timespec *ts);
+ const struct timespec64 *ts);
 
int  (*timer_create) (struct posix_clock *pc, struct k_itimer *kit);
 
int  (*timer_delete) (struct posix_clock *pc, struct k_itimer *kit);
 
void (*timer_gettime)(struct posix_clock *pc,
- struct k_itimer *kit, struct itimerspec *tsp);
+ struct k_itimer *kit, struct itimerspec64 *tsp);
 
int  (*timer_settime)(struct posix_clock *pc,
  struct k_itimer *kit, int flags,
- struct itimerspec *tsp, struct itimerspec *old);
+ struct itimerspec64 *tsp, struct itimerspec64 
*old);
/*
 * Optional character device methods:
 */
--- a/kernel/time/posix-clock.c
+++ b/kernel/time/posix-clock.c
@@ -300,14 +300,17 @@ out:
 static int pc_clock_gettime(clo

[PATCH 4.4 11/97] time: Change posix clocks ops interfaces to use timespec64

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Deepa Dinamani <deepa.ker...@gmail.com>


[ Upstream commit d340266e19ddb70dbd608f9deedcfb35fdb9d419 ]

struct timespec is not y2038 safe on 32 bit machines.

The posix clocks apis use struct timespec directly and through struct
itimerspec.

Replace the posix clock interfaces to use struct timespec64 and struct
itimerspec64 instead.  Also fix up their implementations accordingly.

Note that the clock_getres() interface has also been changed to use
timespec64 even though this particular interface is not affected by the
y2038 problem. This helps verification for internal kernel code for y2038
readiness by getting rid of time_t/ timeval/ timespec.

Signed-off-by: Deepa Dinamani <deepa.ker...@gmail.com>
Cc: a...@arndb.de
Cc: y2...@lists.linaro.org
Cc: netdev@vger.kernel.org
Cc: Richard Cochran <richardcoch...@gmail.com>
Cc: john.stu...@linaro.org
Link: 
http://lkml.kernel.org/r/1490555058-4603-3-git-send-email-deepa.ker...@gmail.com
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 drivers/ptp/ptp_clock.c |   18 +++---
 include/linux/posix-clock.h |   10 +-
 kernel/time/posix-clock.c   |   34 --
 3 files changed, 36 insertions(+), 26 deletions(-)

--- a/drivers/ptp/ptp_clock.c
+++ b/drivers/ptp/ptp_clock.c
@@ -97,30 +97,26 @@ static s32 scaled_ppm_to_ppb(long ppm)
 
 /* posix clock implementation */
 
-static int ptp_clock_getres(struct posix_clock *pc, struct timespec *tp)
+static int ptp_clock_getres(struct posix_clock *pc, struct timespec64 *tp)
 {
tp->tv_sec = 0;
tp->tv_nsec = 1;
return 0;
 }
 
-static int ptp_clock_settime(struct posix_clock *pc, const struct timespec *tp)
+static int ptp_clock_settime(struct posix_clock *pc, const struct timespec64 
*tp)
 {
struct ptp_clock *ptp = container_of(pc, struct ptp_clock, clock);
-   struct timespec64 ts = timespec_to_timespec64(*tp);
 
-   return  ptp->info->settime64(ptp->info, );
+   return  ptp->info->settime64(ptp->info, tp);
 }
 
-static int ptp_clock_gettime(struct posix_clock *pc, struct timespec *tp)
+static int ptp_clock_gettime(struct posix_clock *pc, struct timespec64 *tp)
 {
struct ptp_clock *ptp = container_of(pc, struct ptp_clock, clock);
-   struct timespec64 ts;
int err;
 
-   err = ptp->info->gettime64(ptp->info, );
-   if (!err)
-   *tp = timespec64_to_timespec(ts);
+   err = ptp->info->gettime64(ptp->info, tp);
return err;
 }
 
@@ -133,7 +129,7 @@ static int ptp_clock_adjtime(struct posi
ops = ptp->info;
 
if (tx->modes & ADJ_SETOFFSET) {
-   struct timespec ts;
+   struct timespec64 ts;
ktime_t kt;
s64 delta;
 
@@ -146,7 +142,7 @@ static int ptp_clock_adjtime(struct posi
if ((unsigned long) ts.tv_nsec >= NSEC_PER_SEC)
return -EINVAL;
 
-   kt = timespec_to_ktime(ts);
+   kt = timespec64_to_ktime(ts);
delta = ktime_to_ns(kt);
err = ops->adjtime(ops, delta);
} else if (tx->modes & ADJ_FREQUENCY) {
--- a/include/linux/posix-clock.h
+++ b/include/linux/posix-clock.h
@@ -59,23 +59,23 @@ struct posix_clock_operations {
 
int  (*clock_adjtime)(struct posix_clock *pc, struct timex *tx);
 
-   int  (*clock_gettime)(struct posix_clock *pc, struct timespec *ts);
+   int  (*clock_gettime)(struct posix_clock *pc, struct timespec64 *ts);
 
-   int  (*clock_getres) (struct posix_clock *pc, struct timespec *ts);
+   int  (*clock_getres) (struct posix_clock *pc, struct timespec64 *ts);
 
int  (*clock_settime)(struct posix_clock *pc,
- const struct timespec *ts);
+ const struct timespec64 *ts);
 
int  (*timer_create) (struct posix_clock *pc, struct k_itimer *kit);
 
int  (*timer_delete) (struct posix_clock *pc, struct k_itimer *kit);
 
void (*timer_gettime)(struct posix_clock *pc,
- struct k_itimer *kit, struct itimerspec *tsp);
+ struct k_itimer *kit, struct itimerspec64 *tsp);
 
int  (*timer_settime)(struct posix_clock *pc,
  struct k_itimer *kit, int flags,
- struct itimerspec *tsp, struct itimerspec *old);
+ struct itimerspec64 *tsp, struct itimerspec64 
*old);
/*
 * Optional character device methods:
 */
--- a/kernel/time/posix-clock.c
+++ b/kernel/time/posix-clock.c
@@ -300,14 +300,17 @@ out:
 static int pc_clock_gettime(clo

Re: [net-next] intel: add SPDX identifiers to all the Intel drivers

[Greg Kroah-Hartman]

On Tue, Mar 20, 2018 at 06:09:20PM -0700, Jeff Kirsher wrote:
> > When the kernel maintainers decide to switch to V3.0 of the SPDX list,
> > the doc will be updated and then Joe's script could be applied at once
> > to update the past.
> 
> I am fine with changing my patch back to v2.6 SPDX ids, as long as Joe's
> script in the future won't touch the Intel wired LAN drivers, since we need
> to retain copyright on several files through out our drivers.

Changing SPDX comment lines should never change the "copyright" of a
file.  If you have questions about stuff like that, please talk to your
corporate lawyers, they will be glad to talk to you all about what
defines "copyright" :)

thanks,

greg "I talk to too many lawyers..." k-h

Re: [PATCH 12/28] net: convert datagram_poll users tp ->poll_mask

[Greg KH]

On Wed, Mar 21, 2018 at 08:40:16AM +0100, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig <h...@lst.de>
> ---
>  drivers/isdn/mISDN/socket.c|  2 +-
>  drivers/net/ppp/pppoe.c|  2 +-
>  drivers/staging/ipx/af_ipx.c   |  2 +-
>  drivers/staging/irda/net/af_irda.c |  6 +++---

irda is now gone in linux-next, but that's an easy thing to handle when
merging.

Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

Re: [PATCH 28/28] random: convert to ->poll_mask

[Greg KH]

On Wed, Mar 21, 2018 at 08:40:32AM +0100, Christoph Hellwig wrote:
> The big change is that random_read_wait and random_write_wait are merged
> into a single waitqueue that uses keyed wakeups.  Because wait_event_*
> doesn't know about that this will lead to occassional spurious wakeups
> in _random_read and add_hwgenerator_randomness, but wait_event_* is
> designed to handle these and were are not in a a hot path there.
> 
> Signed-off-by: Christoph Hellwig <h...@lst.de>
> ---
>  drivers/char/random.c | 27 +++
>  1 file changed, 15 insertions(+), 12 deletions(-)

Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

Re: [PATCH 06/28] aio: implement IOCB_CMD_POLL

[Greg KH]

On Wed, Mar 21, 2018 at 08:40:10AM +0100, Christoph Hellwig wrote:
> Simple one-shot poll through the io_submit() interface.  To poll for
> a file descriptor the application should submit an iocb of type
> IOCB_CMD_POLL.  It will poll the fd for the events specified in the
> the first 32 bits of the aio_buf field of the iocb.
> 
> Unlike poll or epoll without EPOLLONESHOT this interface always works
> in one shot mode, that is once the iocb is completed, it will have to be
> resubmitted.
> 
> Signed-off-by: Christoph Hellwig <h...@lst.de>
> Acked-by: Jeff Moyer <jmo...@redhat.com>

Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

Re: [PATCH 05/28] fs: introduce new ->get_poll_head and ->poll_mask methods

[Greg KH]

On Wed, Mar 21, 2018 at 08:40:09AM +0100, Christoph Hellwig wrote:
> ->get_poll_head returns the waitqueue that the poll operation is going
> to sleep on.  Note that this means we can only use a single waitqueue
> for the poll, unlike some current drivers that use two waitqueues for
> different events.  But now that we have keyed wakeups and heavily use
> those for poll there aren't that many good reason left to keep the
> multiple waitqueues, and if there are any ->poll is still around, the
> driver just won't support aio poll.
> 
> Signed-off-by: Christoph Hellwig <h...@lst.de>

Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

Re: [PATCH 03/28] fs: update documentation to mention __poll_t

[Greg KH]

On Wed, Mar 21, 2018 at 08:40:07AM +0100, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig <h...@lst.de>

Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

Re: [PATCH 04/28] fs: add new vfs_poll and file_can_poll helpers

[Greg KH]

On Wed, Mar 21, 2018 at 08:40:08AM +0100, Christoph Hellwig wrote:
> These abstract out calls to the poll method in preparation for changes
> in how we poll.

Yeah!!!

> 
> Signed-off-by: Christoph Hellwig <h...@lst.de>
> Reviewed-by: Darrick J. Wong <darrick.w...@oracle.com>

Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

Re: [PATCH 02/28] fs: cleanup do_pollfd

[Greg KH]

On Wed, Mar 21, 2018 at 08:40:06AM +0100, Christoph Hellwig wrote:
> Use straigline code with failure handling gotos instead of a lot

"straightline"?  :)

> of nested conditionals.
> 
> Signed-off-by: Christoph Hellwig <h...@lst.de>
> Reviewed-by: Darrick J. Wong <darrick.w...@oracle.com>

Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

Re: [PATCH 01/28] fs: unexport poll_schedule_timeout

[Greg KH]

On Wed, Mar 21, 2018 at 08:40:05AM +0100, Christoph Hellwig wrote:
> No users outside of select.c.
> 
> Signed-off-by: Christoph Hellwig <h...@lst.de>
> Reviewed-by: Darrick J. Wong <darrick.w...@oracle.com>

Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

[PATCH 3.18 34/68] MIPS: BPF: Quit clobbering callee saved registers in JIT code.

[Greg Kroah-Hartman]

3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: David Daney <david.da...@cavium.com>


[ Upstream commit 1ef0910cfd681f0bd0b81f8809935b2006e9cfb9 ]

If bpf_needs_clear_a() returns true, only actually clear it if it is
ever used.  If it is not used, we don't save and restore it, so the
clearing has the nasty side effect of clobbering caller state.

Also, don't emit stack pointer adjustment instructions if the
adjustment amount is zero.

Signed-off-by: David Daney <david.da...@cavium.com>
Cc: James Hogan <james.ho...@imgtec.com>
Cc: Alexei Starovoitov <a...@kernel.org>
Cc: Steven J. Hill <steven.h...@cavium.com>
Cc: linux-m...@linux-mips.org
Cc: netdev@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/15745/
Signed-off-by: Ralf Baechle <r...@linux-mips.org>
Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 arch/mips/net/bpf_jit.c |   16 
 1 file changed, 12 insertions(+), 4 deletions(-)

--- a/arch/mips/net/bpf_jit.c
+++ b/arch/mips/net/bpf_jit.c
@@ -562,7 +562,8 @@ static void save_bpf_jit_regs(struct jit
u32 sflags, tmp_flags;
 
/* Adjust the stack pointer */
-   emit_stack_offset(-align_sp(offset), ctx);
+   if (offset)
+   emit_stack_offset(-align_sp(offset), ctx);
 
if (ctx->flags & SEEN_CALL) {
/* Argument save area */
@@ -641,7 +642,8 @@ static void restore_bpf_jit_regs(struct
emit_load_stack_reg(r_ra, r_sp, real_off, ctx);
 
/* Restore the sp and discard the scrach memory */
-   emit_stack_offset(align_sp(offset), ctx);
+   if (offset)
+   emit_stack_offset(align_sp(offset), ctx);
 }
 
 static unsigned int get_stack_depth(struct jit_ctx *ctx)
@@ -689,8 +691,14 @@ static void build_prologue(struct jit_ct
if (ctx->flags & SEEN_X)
emit_jit_reg_move(r_X, r_zero, ctx);
 
-   /* Do not leak kernel data to userspace */
-   if (bpf_needs_clear_a(>skf->insns[0]))
+   /*
+* Do not leak kernel data to userspace, we only need to clear
+* r_A if it is ever used.  In fact if it is never used, we
+* will not save/restore it, so clearing it in this case would
+* corrupt the state of the caller.
+*/
+   if (bpf_needs_clear_a(>skf->insns[0]) &&
+   (ctx->flags & SEEN_A))
emit_jit_reg_move(r_A, r_zero, ctx);
 }
 

[PATCH 4.4 062/134] MIPS: BPF: Quit clobbering callee saved registers in JIT code.

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: David Daney <david.da...@cavium.com>


[ Upstream commit 1ef0910cfd681f0bd0b81f8809935b2006e9cfb9 ]

If bpf_needs_clear_a() returns true, only actually clear it if it is
ever used.  If it is not used, we don't save and restore it, so the
clearing has the nasty side effect of clobbering caller state.

Also, don't emit stack pointer adjustment instructions if the
adjustment amount is zero.

Signed-off-by: David Daney <david.da...@cavium.com>
Cc: James Hogan <james.ho...@imgtec.com>
Cc: Alexei Starovoitov <a...@kernel.org>
Cc: Steven J. Hill <steven.h...@cavium.com>
Cc: linux-m...@linux-mips.org
Cc: netdev@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/15745/
Signed-off-by: Ralf Baechle <r...@linux-mips.org>
Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 arch/mips/net/bpf_jit.c |   16 
 1 file changed, 12 insertions(+), 4 deletions(-)

--- a/arch/mips/net/bpf_jit.c
+++ b/arch/mips/net/bpf_jit.c
@@ -527,7 +527,8 @@ static void save_bpf_jit_regs(struct jit
u32 sflags, tmp_flags;
 
/* Adjust the stack pointer */
-   emit_stack_offset(-align_sp(offset), ctx);
+   if (offset)
+   emit_stack_offset(-align_sp(offset), ctx);
 
tmp_flags = sflags = ctx->flags >> SEEN_SREG_SFT;
/* sflags is essentially a bitmap */
@@ -579,7 +580,8 @@ static void restore_bpf_jit_regs(struct
emit_load_stack_reg(r_ra, r_sp, real_off, ctx);
 
/* Restore the sp and discard the scrach memory */
-   emit_stack_offset(align_sp(offset), ctx);
+   if (offset)
+   emit_stack_offset(align_sp(offset), ctx);
 }
 
 static unsigned int get_stack_depth(struct jit_ctx *ctx)
@@ -626,8 +628,14 @@ static void build_prologue(struct jit_ct
if (ctx->flags & SEEN_X)
emit_jit_reg_move(r_X, r_zero, ctx);
 
-   /* Do not leak kernel data to userspace */
-   if (bpf_needs_clear_a(>skf->insns[0]))
+   /*
+* Do not leak kernel data to userspace, we only need to clear
+* r_A if it is ever used.  In fact if it is never used, we
+* will not save/restore it, so clearing it in this case would
+* corrupt the state of the caller.
+*/
+   if (bpf_needs_clear_a(>skf->insns[0]) &&
+   (ctx->flags & SEEN_A))
emit_jit_reg_move(r_A, r_zero, ctx);
 }
 

[PATCH 4.4 063/134] MIPS: BPF: Fix multiple problems in JIT skb access helpers.

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: David Daney <david.da...@cavium.com>


[ Upstream commit a81507c79f4ae9a0f9fb1054b59b62a090620dd9 ]

o Socket data is unsigned, so use unsigned accessors instructions.

 o Fix path result pointer generation arithmetic.

 o Fix half-word byte swapping code for unsigned semantics.

Signed-off-by: David Daney <david.da...@cavium.com>
Cc: James Hogan <james.ho...@imgtec.com>
Cc: Alexei Starovoitov <a...@kernel.org>
Cc: Steven J. Hill <steven.h...@cavium.com>
Cc: linux-m...@linux-mips.org
Cc: netdev@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/15747/
Signed-off-by: Ralf Baechle <r...@linux-mips.org>
Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 arch/mips/net/bpf_jit_asm.S |   23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

--- a/arch/mips/net/bpf_jit_asm.S
+++ b/arch/mips/net/bpf_jit_asm.S
@@ -90,18 +90,14 @@ FEXPORT(sk_load_half_positive)
is_offset_in_header(2, half)
/* Offset within header boundaries */
PTR_ADDU t1, $r_skb_data, offset
-   .setreorder
-   lh  $r_A, 0(t1)
-   .setnoreorder
+   lhu $r_A, 0(t1)
 #ifdef CONFIG_CPU_LITTLE_ENDIAN
 # if defined(__mips_isa_rev) && (__mips_isa_rev >= 2)
-   wsbht0, $r_A
-   seh $r_A, t0
+   wsbh$r_A, $r_A
 # else
-   sll t0, $r_A, 24
-   andit1, $r_A, 0xff00
-   sra t0, t0, 16
-   srl t1, t1, 8
+   sll t0, $r_A, 8
+   srl t1, $r_A, 8
+   andit0, t0, 0xff00
or  $r_A, t0, t1
 # endif
 #endif
@@ -115,7 +111,7 @@ FEXPORT(sk_load_byte_positive)
is_offset_in_header(1, byte)
/* Offset within header boundaries */
PTR_ADDU t1, $r_skb_data, offset
-   lb  $r_A, 0(t1)
+   lbu $r_A, 0(t1)
jr  $r_ra
 move   $r_ret, zero
END(sk_load_byte)
@@ -139,6 +135,11 @@ FEXPORT(sk_load_byte_positive)
  * (void *to) is returned in r_s0
  *
  */
+#ifdef CONFIG_CPU_LITTLE_ENDIAN
+#define DS_OFFSET(SIZE) (4 * SZREG)
+#else
+#define DS_OFFSET(SIZE) ((4 * SZREG) + (4 - SIZE))
+#endif
 #define bpf_slow_path_common(SIZE) \
/* Quick check. Are we within reasonable boundaries? */ \
LONG_ADDIU  $r_s1, $r_skb_len, -SIZE;   \
@@ -150,7 +151,7 @@ FEXPORT(sk_load_byte_positive)
PTR_LA  t0, skb_copy_bits;  \
PTR_S   $r_ra, (5 * SZREG)($r_sp);  \
/* Assign low slot to a2 */ \
-   movea2, $r_sp;  \
+   PTR_ADDIU   a2, $r_sp, DS_OFFSET(SIZE); \
jalrt0; \
/* Reset our destination slot (DS but it's ok) */   \
 INT_S  zero, (4 * SZREG)($r_sp);   \

[PATCH 4.9 129/241] MIPS: BPF: Quit clobbering callee saved registers in JIT code.

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: David Daney <david.da...@cavium.com>


[ Upstream commit 1ef0910cfd681f0bd0b81f8809935b2006e9cfb9 ]

If bpf_needs_clear_a() returns true, only actually clear it if it is
ever used.  If it is not used, we don't save and restore it, so the
clearing has the nasty side effect of clobbering caller state.

Also, don't emit stack pointer adjustment instructions if the
adjustment amount is zero.

Signed-off-by: David Daney <david.da...@cavium.com>
Cc: James Hogan <james.ho...@imgtec.com>
Cc: Alexei Starovoitov <a...@kernel.org>
Cc: Steven J. Hill <steven.h...@cavium.com>
Cc: linux-m...@linux-mips.org
Cc: netdev@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/15745/
Signed-off-by: Ralf Baechle <r...@linux-mips.org>
Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 arch/mips/net/bpf_jit.c |   16 
 1 file changed, 12 insertions(+), 4 deletions(-)

--- a/arch/mips/net/bpf_jit.c
+++ b/arch/mips/net/bpf_jit.c
@@ -526,7 +526,8 @@ static void save_bpf_jit_regs(struct jit
u32 sflags, tmp_flags;
 
/* Adjust the stack pointer */
-   emit_stack_offset(-align_sp(offset), ctx);
+   if (offset)
+   emit_stack_offset(-align_sp(offset), ctx);
 
tmp_flags = sflags = ctx->flags >> SEEN_SREG_SFT;
/* sflags is essentially a bitmap */
@@ -578,7 +579,8 @@ static void restore_bpf_jit_regs(struct
emit_load_stack_reg(r_ra, r_sp, real_off, ctx);
 
/* Restore the sp and discard the scrach memory */
-   emit_stack_offset(align_sp(offset), ctx);
+   if (offset)
+   emit_stack_offset(align_sp(offset), ctx);
 }
 
 static unsigned int get_stack_depth(struct jit_ctx *ctx)
@@ -625,8 +627,14 @@ static void build_prologue(struct jit_ct
if (ctx->flags & SEEN_X)
emit_jit_reg_move(r_X, r_zero, ctx);
 
-   /* Do not leak kernel data to userspace */
-   if (bpf_needs_clear_a(>skf->insns[0]))
+   /*
+* Do not leak kernel data to userspace, we only need to clear
+* r_A if it is ever used.  In fact if it is never used, we
+* will not save/restore it, so clearing it in this case would
+* corrupt the state of the caller.
+*/
+   if (bpf_needs_clear_a(>skf->insns[0]) &&
+   (ctx->flags & SEEN_A))
emit_jit_reg_move(r_A, r_zero, ctx);
 }
 

[PATCH 4.9 130/241] MIPS: BPF: Fix multiple problems in JIT skb access helpers.

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: David Daney <david.da...@cavium.com>


[ Upstream commit a81507c79f4ae9a0f9fb1054b59b62a090620dd9 ]

o Socket data is unsigned, so use unsigned accessors instructions.

 o Fix path result pointer generation arithmetic.

 o Fix half-word byte swapping code for unsigned semantics.

Signed-off-by: David Daney <david.da...@cavium.com>
Cc: James Hogan <james.ho...@imgtec.com>
Cc: Alexei Starovoitov <a...@kernel.org>
Cc: Steven J. Hill <steven.h...@cavium.com>
Cc: linux-m...@linux-mips.org
Cc: netdev@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/15747/
Signed-off-by: Ralf Baechle <r...@linux-mips.org>
Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 arch/mips/net/bpf_jit_asm.S |   23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

--- a/arch/mips/net/bpf_jit_asm.S
+++ b/arch/mips/net/bpf_jit_asm.S
@@ -90,18 +90,14 @@ FEXPORT(sk_load_half_positive)
is_offset_in_header(2, half)
/* Offset within header boundaries */
PTR_ADDU t1, $r_skb_data, offset
-   .setreorder
-   lh  $r_A, 0(t1)
-   .setnoreorder
+   lhu $r_A, 0(t1)
 #ifdef CONFIG_CPU_LITTLE_ENDIAN
 # if defined(__mips_isa_rev) && (__mips_isa_rev >= 2)
-   wsbht0, $r_A
-   seh $r_A, t0
+   wsbh$r_A, $r_A
 # else
-   sll t0, $r_A, 24
-   andit1, $r_A, 0xff00
-   sra t0, t0, 16
-   srl t1, t1, 8
+   sll t0, $r_A, 8
+   srl t1, $r_A, 8
+   andit0, t0, 0xff00
or  $r_A, t0, t1
 # endif
 #endif
@@ -115,7 +111,7 @@ FEXPORT(sk_load_byte_positive)
is_offset_in_header(1, byte)
/* Offset within header boundaries */
PTR_ADDU t1, $r_skb_data, offset
-   lb  $r_A, 0(t1)
+   lbu $r_A, 0(t1)
jr  $r_ra
 move   $r_ret, zero
END(sk_load_byte)
@@ -139,6 +135,11 @@ FEXPORT(sk_load_byte_positive)
  * (void *to) is returned in r_s0
  *
  */
+#ifdef CONFIG_CPU_LITTLE_ENDIAN
+#define DS_OFFSET(SIZE) (4 * SZREG)
+#else
+#define DS_OFFSET(SIZE) ((4 * SZREG) + (4 - SIZE))
+#endif
 #define bpf_slow_path_common(SIZE) \
/* Quick check. Are we within reasonable boundaries? */ \
LONG_ADDIU  $r_s1, $r_skb_len, -SIZE;   \
@@ -150,7 +151,7 @@ FEXPORT(sk_load_byte_positive)
PTR_LA  t0, skb_copy_bits;  \
PTR_S   $r_ra, (5 * SZREG)($r_sp);  \
/* Assign low slot to a2 */ \
-   movea2, $r_sp;  \
+   PTR_ADDIU   a2, $r_sp, DS_OFFSET(SIZE); \
jalrt0; \
/* Reset our destination slot (DS but it's ok) */   \
 INT_S  zero, (4 * SZREG)($r_sp);   \

Re: [PATCH] ncpfs: memory corruption in ncp_read_kernel()

[Greg Kroah-Hartman]

On Mon, Mar 19, 2018 at 02:07:45PM +0300, Dan Carpenter wrote:
> If the server is malicious then *bytes_read could be larger than the
> size of the "target" buffer.  It would lead to memory corruption when we
> do the memcpy().
> 
> Reported-by: Dr Silvio Cesare of InfoSect  <silvio.ces...@gmail.com>
> Signed-off-by: Dan Carpenter <dan.carpen...@oracle.com>
> 
> diff --git a/drivers/staging/ncpfs/ncplib_kernel.c 
> b/drivers/staging/ncpfs/ncplib_kernel.c
> index 804adfebba2f..3e047eb4cc7c 100644
> --- a/drivers/staging/ncpfs/ncplib_kernel.c
> +++ b/drivers/staging/ncpfs/ncplib_kernel.c

Ugh, I have like 2 more months before I delete this code :)

Anyway, nice find, and fix, I'll go queue it up now, thanks.

greg k-h

Re: [PATCH v2 1/2] sysfs: symlink: export sysfs_create_link_nowarn()

[Greg Kroah-Hartman]

On Fri, Mar 16, 2018 at 05:08:34PM -0500, Grygorii Strashko wrote:
> The sysfs_create_link_nowarn() is going to be used in phylib framework in
> subsequent patch which can be built as module. Hence, export
> sysfs_create_link_nowarn() to avoid build errors.
> 
> Cc: Florian Fainelli <f.faine...@gmail.com>
> Cc: Andrew Lunn <and...@lunn.ch>
> Fixes: a3995460491d ("net: phy: Relax error checking on sysfs_create_link()")

This specific patch doesn't fix anything, it just _allows_ it to be
fixed in the second patch :)

Anyway, just a nit...

Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

Re: [PATCH 2/2] net: phy: relax error checking when creating sysfs link netdev->phydev

[Greg Kroah-Hartman]

On Wed, Mar 14, 2018 at 05:26:24PM -0500, Grygorii Strashko wrote:
> Some ethernet drivers (like TI CPSW) may connect and manage >1 Net PHYs per
> one netdevice, as result such drivers will produce warning during system
> boot and fail to connect second phy to netdevice when PHYLIB framework
> will try to create sysfs link netdev->phydev for second PHY
> in phy_attach_direct(), because sysfs link with the same name has been
> created already for the first PHY. As result, second CPSW external
> port will became unusable.
> 
> Fix it by relaxing error checking when PHYLIB framework is creating sysfs
> link netdev->phydev in phy_attach_direct(), suppressing warning by using
> sysfs_create_link_nowarn() and adding debug message instead.
> 
> Cc: Florian Fainelli <f.faine...@gmail.com>
> Fixes: a3995460491d ("net: phy: Relax error checking on sysfs_create_link()")
> Signed-off-by: Grygorii Strashko <grygorii.stras...@ti.com>
> ---
>  drivers/net/phy/phy_device.c | 15 +++
>  1 file changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index 478405e..fe16f58 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -1012,10 +1012,17 @@ int phy_attach_direct(struct net_device *dev, struct 
> phy_device *phydev,
>   err = sysfs_create_link(>mdio.dev.kobj, >dev.kobj,
>   "attached_dev");
>   if (!err) {
> - err = sysfs_create_link(>dev.kobj, >mdio.dev.kobj,
> - "phydev");
> - if (err)
> - goto error;
> + err = sysfs_create_link_nowarn(>dev.kobj,
> +>mdio.dev.kobj,
> +"phydev");
> + if (err) {
> + dev_err(>dev, "could not add device link to %s err 
> %d\n",
> + kobject_name(>mdio.dev.kobj),
> + err);

dev_err() is not a "debugging" message :)

What is a user going to do with this new error?  If it's not important
at all, why care about it?

> + /* non-fatal - some net drivers can use one netdevice
> +  * with more then one phy
> +  */

What about devices that do not have more than one phy and this call
fails for?  Shouldn't you check for that?

thanks,

greg k-h

Re: [PATCH 46/47] staging: irda: remove bfin_sir driver

[Greg Kroah-Hartman]

On Wed, Mar 14, 2018 at 04:35:59PM +0100, Arnd Bergmann wrote:
> The blackfin architecture is getting removed, so this
> driver is now obsolete.
> 
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
> ---
>  drivers/staging/irda/drivers/Kconfig|  45 --
>  drivers/staging/irda/drivers/Makefile   |   1 -
>  drivers/staging/irda/drivers/bfin_sir.c | 819 
> 
>  drivers/staging/irda/drivers/bfin_sir.h |  93 
>  4 files changed, 958 deletions(-)
>  delete mode 100644 drivers/staging/irda/drivers/bfin_sir.c
>  delete mode 100644 drivers/staging/irda/drivers/bfin_sir.h

I just deleted all of drivers/staging/irda/ earlier today :)

thanks,

greg k-h

Re: [PATCH v5 1/6] staging: fsl-dpaa2/ethsw: Add APIs for DPSW object

[Greg KH]

DVISED OF THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + */

Can you resend this series and just use the correct SPDX identifiers for
all of the new files, instead of all of this horrid boiler-plate code?

That will save me time when I have to go delete all of this in the near
future :)

Also, why dual license it?  Are you _SURE_ you want to do that, and are
totally aware of all of the crazy issues surrounding it?  Hint, it
almost never means what you might think it does, and I have yet to know
of anyone doing anything "real" with any dual-licensed Linux kernel
code.

Remember, BSD is not the license you want/need for GPL header files that
are exposed to userspace...


thanks,

greg k-h