On Mon, Dec 21, 2020 at 07:27:31PM +0800, Dinghao Liu wrote:
> When mlx5_create_flow_group() fails, ft->g should be
> freed just like when kvzalloc() fails. The caller of
> mlx5e_create_l2_table_groups() does not catch this
> issue on failure, which leads to memleak.
>
> Signed-off-by: Dinghao Liu
On Mon, Dec 21, 2020 at 04:50:31PM +0800, Dinghao Liu wrote:
> mlx5e_create_ttc_table_groups() frees ft->g on failure of
> kvzalloc(), but such failure will be caught by its caller
> in mlx5e_create_ttc_table() and ft->g will be freed again
> in mlx5e_destroy_flow_table(). The same issue also occur
On Thu, Dec 24, 2020 at 07:48:53PM +0800, wangyunjian wrote:
> From: Yunjian Wang
>
> Currently the tun_napi_alloc_frags() function returns -ENOMEM when the
> number of iovs exceeds MAX_SKB_FRAGS + 1. However this is inappropriate,
> we should use -EMSGSIZE instead of -ENOMEM.
>
> Fixes: 90e33d4
On Fri, Dec 25, 2020 at 10:52:16AM +0800, wangyunjian wrote:
> From: Yunjian Wang
>
> Currently the tun_napi_alloc_frags() function returns -ENOMEM when the
> number of iovs exceeds MAX_SKB_FRAGS + 1. However this is inappropriate,
> we should use -EMSGSIZE instead of -ENOMEM.
>
> The following
On Sun, Dec 27, 2020 at 12:34:09PM +0800, Bruce LIU wrote:
> Hi Michal Kubecek and Network dev team,
>
> Good day! Hope you are doing well.
> This is Bruce from China, and please allow me to cc Rudy from Cisco Systems
> in China team.
>
> We are facing a weird behavior about "master-slave configu
On Tue, Dec 22, 2020 at 11:23:56PM +0100, Florian Westphal wrote:
> syzbot reports:
> detected buffer overflow in strlen
> [..]
> Call Trace:
> strlen include/linux/string.h:325 [inline]
> strlcpy include/linux/string.h:348 [inline]
> xt_rateest_tg_checkentry+0x2a5/0x6b0 net/netfilter/xt_RATEEST
On Fri, Dec 25, 2020 at 03:24:33PM +0800, wangyunjian wrote:
> From: Yunjian Wang
>
> Currently the driver doesn't drop a packet which can't be sent by tun
> (e.g bad packet). In this case, the driver will always process the
> same packet lead to the tx queue stuck.
>
> To fix this issue:
> 1. i
On Thu, Dec 24, 2020 at 10:56:16AM -0500, Willem de Bruijn wrote:
> On Thu, Dec 24, 2020 at 6:51 AM wangyunjian wrote:
> >
> > From: Yunjian Wang
> >
> > Currently the tun_napi_alloc_frags() function returns -ENOMEM when the
> > number of iovs exceeds MAX_SKB_FRAGS + 1. However this is inappropri
On Fri, Dec 25, 2020 at 03:24:33PM +0800, wangyunjian wrote:
> From: Yunjian Wang
>
> Currently the driver doesn't drop a packet which can't be sent by tun
> (e.g bad packet). In this case, the driver will always process the
> same packet lead to the tx queue stuck.
So not making progress on a b
On Fri, Dec 25, 2020 at 03:24:25PM +0800, wangyunjian wrote:
> From: Yunjian Wang
>
> Currently the vhost_zerocopy_callback() maybe be called to decrease
> the refcount when sendmsg fails in tun. The error handling in vhost
> handle_tx_zerocopy() will try to decrease the same refcount again.
> Th
Here is the series to enable RAVB on V3U. I took the DTS patches
from the BSP, the rest was developed on mainline tree. Note that only
RAVB0 could be tested because the other ones did not have PHYs attached.
Also, the last patch is a workaround. 'reset-gpios' cannot be obtained
currently which mak
Document the compatible value for the RAVB block in the Renesas R-Car
V3U (R8A779A0) SoC. This variant has no stream buffer, so we only need
to add the new compatible.
Signed-off-by: Wolfram Sang
---
Documentation/devicetree/bindings/net/renesas,etheravb.yaml | 1 +
1 file changed, 1 insertion(+
On Thu, Dec 17, 2020 at 2:59 AM Vladimir Oltean wrote:
> Since the introduction of the switchdev API, port attributes were
> transmitted to drivers for offloading using a two-step transactional
> model, with a prepare phase that was supposed to catch all errors, and a
> commit phase that was supp
On Thu, Dec 17, 2020 at 2:59 AM Vladimir Oltean wrote:
> It should be the driver's business to logically separate its VLAN
> offloading into a preparation and a commit phase, and some drivers don't
> need / can't do this.
>
> So remove the transactional shim from DSA and let drivers to propagate
On Thu, Dec 17, 2020 at 2:59 AM Vladimir Oltean wrote:
> This series comes after the late realization that the prepare/commit
> separation imposed by switchdev does not help literally anybody:
> https://patchwork.kernel.org/project/netdevbpf/patch/20201212203901.351331-1-vladimir.olt...@nxp.com/
After commit 72cdab808714 ("ath9k: Do not select MAC80211_LEDS by
default") a configuration like:
- MAC80211_LEDS=y
- LEDS_CLASS=m
- NEW_LEDS=y
- ATH9K=y
leads to a build failure:
/usr/bin/ld: drivers/net/wireless/ath/ath9k/gpio.o: in function
`ath_deinit_leds':
drivers/net/wireless/a
On Sun, 27 Dec 2020 at 04:27, Cong Wang wrote:
>
Hi Cong,
Thank you so much for the review!
> On Wed, Dec 23, 2020 at 8:55 AM Taehee Yoo wrote:
> >
> > mld_newpack() doesn't allow to allocate high order page,
> > just order-0 allocation is allowed.
> > If headroom size is too large, a kernel pa
From: Léo Le Bouter
This was tested on a RaptorCS Talos II with IBM POWER9 DD2.2 CPUs and an
ASUS XG-C100F PCI-e card without any issue. Speeds of ~8Gbps could be
attained with not-very-scientific (wget HTTP) both-ways measurements on
a local network. No warning or error reported in kernel logs.
On Sun, Dec 27, 2020 at 04:42:38PM +0100, dftxb...@free.fr wrote:
> From: Léo Le Bouter
>
> This was tested on a RaptorCS Talos II with IBM POWER9 DD2.2 CPUs and an
> ASUS XG-C100F PCI-e card without any issue. Speeds of ~8Gbps could be
> attained with not-very-scientific (wget HTTP) both-ways me
From: Léo Le Bouter
This was tested on a RaptorCS Talos II with IBM POWER9 DD2.2 CPUs and an
ASUS XG-C100F PCI-e card without any issue. Speeds of ~8Gbps could be
attained with not-very-scientific (wget HTTP) both-ways measurements on
a local network. No warning or error reported in kernel logs.
On Sun, Dec 27, 2020 at 6:26 AM Michael S. Tsirkin wrote:
>
> On Fri, Dec 25, 2020 at 03:24:25PM +0800, wangyunjian wrote:
> > From: Yunjian Wang
> >
> > Currently the vhost_zerocopy_callback() maybe be called to decrease
> > the refcount when sendmsg fails in tun. The error handling in vhost
> >
On Sat, Dec 26, 2020 at 05:12:30PM +, Taehee Yoo wrote:
> Like other tunneling interfaces, the bareudp doesn't need TXLOCK.
> So, It is good to set the NETIF_F_LLTX flag to improve performance and
> to avoid lockdep's false-positive warning.
Acked-by: Guillaume Nault
On Sat, Dec 26, 2020 at 05:13:08PM +, Taehee Yoo wrote:
> In the bareudp6_xmit_skb(), it calculates min_headroom.
> At that point, it uses struct iphdr, but it's not correct.
> So panic could occur.
> The struct ipv6hdr should be used.
>
> Test commands:
> ip netns add A
> ip netns add
Similar to commit<2423496af35>, the fragmentation code tries to parse the
header options in order
to figure out where to insert the fragment option. Since nexthdr points
to an invalid option, the calculation of the size of the network header
can made to be much larger than the linear section of t
The first patch fixes recovery of fatal AER errors. The second one
fixes a potential array out of bounds issue.
Please queue for -stable. Thanks.
Michael Chan (1):
bnxt_en: Check TQM rings for maximum supported value.
Vasundhara Volam (1):
bnxt_en: Fix AER recovery.
drivers/net/ethernet/
From: Vasundhara Volam
A recent change skips sending firmware messages to the firmware when
pci_channel_offline() is true during fatal AER error. To make this
complete, we need to move the re-initialization sequence to
bnxt_io_resume(), otherwise the firmware messages to re-initialize
will all b
On Thu, Dec 10, 2020 at 08:25:38PM +0100, Thomas Gleixner wrote:
> These checks are used by modules and prevent the removal of the export of
> irq_to_desc(). Move the accessor into the core.
>
> Signed-off-by: Thomas Gleixner
Yes, but that means that irq_check_status_bit() may be called from mod
TQM rings are hardware resources that require host context memory
managed by the driver. The driver supports up to 9 TQM rings and
the number of rings to use is requested by firmware during run-time.
Cap this number to the maximum supported to prevent accessing beyond
the array. Future firmware m
On Sun, Dec 27, 2020 at 6:40 AM Taehee Yoo wrote:
> But I'm so sorry I didn't understand some points.
>
> 1. you said "both side" and I understand these as follows:
> a) failure of allocation because of a high order and it is fixed
> by 72e09ad107e7
> b) kernel panic because of 72e09ad107e7
> Are
Would it not be possible to disable dying gasp (assuming I can access
the module using some other hardware)?
On Sat, Dec 26, 2020 at 10:27 pm, Russell King - ARM Linux admin
wrote:
Sorry, this will not work. The MA5671A modules are configured to use
dying gasp on pin 7, and pin 7 is grounded
On Thu, Dec 24, 2020 at 01:49:47AM -0800, Xie He wrote:
On Wed, Dec 23, 2020 at 9:01 AM Xie He wrote:
I don't think this patch is suitable for stable branches. This patch is
part of a patch series that changes the lapb module from "establishing the
L2 connection only when needed by L3", to "es
ppp_cp_event is called directly or indirectly by ppp_rx with "ppp->lock"
held. It may call mod_timer to add a new timer. However, at the same time
ppp_timer may be already running and waiting for "ppp->lock". In this
case, there's no need for ppp_timer to continue running and it can just
exit.
If
From: Bongsu Jeon
Change the NCI close sequence because the NCI Command timer should be
deleted after flushing the NCI command work queue.
Signed-off-by: Bongsu Jeon
---
net/nfc/nci/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/nfc/nci/core.c b/net/nfc/nci/
On Mon, 28 Dec 2020 at 04:24, Cong Wang wrote:
>
> On Sun, Dec 27, 2020 at 6:40 AM Taehee Yoo wrote:
> > But I'm so sorry I didn't understand some points.
> >
> > 1. you said "both side" and I understand these as follows:
> > a) failure of allocation because of a high order and it is fixed
> > by
On Mon, 28 Dec 2020 at 01:33, Guillaume Nault wrote:
>
Hi Guillaume,
Thank you for the review!
> On Sat, Dec 26, 2020 at 05:13:08PM +, Taehee Yoo wrote:
> > In the bareudp6_xmit_skb(), it calculates min_headroom.
> > At that point, it uses struct iphdr, but it's not correct.
> > So panic cou
ppp_cp_event is called directly or indirectly by ppp_rx with "ppp->lock"
held. It may call mod_timer to add a new timer. However, at the same time
ppp_timer may be already running and waiting for "ppp->lock". In this
case, there's no need for ppp_timer to continue running and it can just
exit.
If
> On Mon, Dec 21, 2020 at 04:50:31PM +0800, Dinghao Liu wrote:
> > mlx5e_create_ttc_table_groups() frees ft->g on failure of
> > kvzalloc(), but such failure will be caught by its caller
> > in mlx5e_create_ttc_table() and ft->g will be freed again
> > in mlx5e_destroy_flow_table(). The same issue
Hi Steffen,
On Mon, Dec 7, 2020 at 11:55 AM Steffen Klassert
wrote:
>
> On Fri, Nov 27, 2020 at 02:32:44PM +0200, Eyal Birger wrote:
> > Hi Steffen,
> >
> > On Fri, Nov 27, 2020 at 11:44 AM Steffen Klassert
> > wrote:
> > >
> > > On Sat, Nov 21, 2020 at 04:28:23PM +0200, Eyal Birger wrote:
> > >
asm/exception.h is included more than once. Remove the one that isn't
necessary.
Signed-off-by: Tian Tao
---
arch/arm64/kernel/traps.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 08156be..6895ce7 100644
--- a/arch/arm64/kernel/tr
In tty layer, it use tty->ldisc_sem to proect tty_ldisc_ops.
So I think tty->ldisc_sem can also protect tty->disc_data;
For examlpe,
When cpu A is running ppp_synctty_ioctl that hold the tty->ldisc_sem,
at the same time if cpu B calls ppp_synctty_close, it will wait until
cpu A release tty->ldisc_
On 2020/12/25 下午6:31, Yongji Xie wrote:
On Fri, Dec 25, 2020 at 2:58 PM Jason Wang wrote:
On 2020/12/24 下午3:37, Yongji Xie wrote:
On Thu, Dec 24, 2020 at 10:41 AM Jason Wang wrote:
On 2020/12/23 下午8:14, Yongji Xie wrote:
On Wed, Dec 23, 2020 at 5:05 PM Jason Wang wrote:
On 2020/12/22 下
41 matches
Mail list logo
