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 下
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_
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
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:
> > >
> 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
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, 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
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
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/
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 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
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 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
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
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
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/
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
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
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 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
> >
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, 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
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 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/
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:
> 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
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 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
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 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.
>
> To fix this issue:
> 1. i
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 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 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 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 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
41 matches
Mail list logo
