On 2020/6/4 上午12:52, Al Viro wrote:
On Wed, Jun 03, 2020 at 01:29:00AM -0400, Michael S. Tsirkin wrote:
On Wed, Jun 03, 2020 at 02:48:15AM +0100, Al Viro wrote:
On Tue, Jun 02, 2020 at 04:45:05AM -0400, Michael S. Tsirkin wrote:
So vhost needs to poke at userspace *a lot* in a quick successi
On 2020-06-03 15:05, Florian Westphal wrote:
David Wilder wrote:
This crash happened on a ppc64le system running ltp network tests when
ltp script ran "rmmod iptable_mangle".
[213425.602369] BUG: Kernel NULL pointer dereference at 0x0010
[213425.602388] Faulting instruction address: 0xc00
Hi
I'm testing linux kernels(v5.7, v4.19, ...) to get ipv6ready logo certificate.
The reason why I am writing this mail is to inquire about the failed test case.
In the test case, It appears to be verifying the following clause.
RFC8200/page-21
( https://tools.ietf.org/html/rfc8200#page-21 )
On Mon, 2020-06-01 at 19:45 +0300, Denis Efremov wrote:
> Variable "in" in dr_create_rc_qp() is allocated with kvzalloc() and
> should be freed with kvfree().
>
> Fixes: 297cccebdc5a ("net/mlx5: DR, Expose an internal API to issue
> RDMA operations")
> Cc: sta...@vger.kernel.org
> Signed-off-by: D
On Wed, 2020-06-03 at 11:34 -0700, Nathan Chancellor wrote:
> On Tue, Jun 02, 2020 at 12:27:24PM -0700, Nathan Chancellor wrote:
> > On Tue, Jun 02, 2020 at 03:28:37PM +0300, Leon Romanovsky wrote:
> > > From: Leon Romanovsky
> > >
> > > Clang warns:
> > >
> > > drivers/net/ethernet/mellanox/mlx
Quoting Kees Cook (2020-06-03 16:31:59)
> Using uninitialized_var() is dangerous as it papers over real bugs[1]
> (or can in the future), and suppresses unrelated compiler warnings (e.g.
> "unused variable"). If the compiler thinks it is uninitialized, either
> simply initialize the variable or mak
On Wed, Jun 03, 2020 at 01:05:28PM +0200, Toke Høiland-Jørgensen wrote:
> > Hi Toke,
> >
> > Here is the result I tested with 2 i40e 10G ports on physical machine.
> > The pktgen pkt_size is 64.
>
> These numbers seem a bit low (I'm getting ~8.5MPPS on my test machine
> for a simple redirect). Som
On Wed, Jun 03, 2020 at 08:33:15PM -0700, Nathan Chancellor wrote:
> On Wed, Jun 03, 2020 at 04:32:02PM -0700, Kees Cook wrote:
> > Using uninitialized_var() is dangerous as it papers over real bugs[1]
> > (or can in the future), and suppresses unrelated compiler warnings
> > (e.g. "unused variable
On 6/3/2020 8:16 PM, Jakub Kicinski wrote:
> On Wed, 3 Jun 2020 11:12:51 -0700 Florian Fainelli wrote:
>> Any reason why this is written in python versus shell?
>
> Perhaps personal preference of the author :)
>
> I'd be curious to hear the disadvantages, is python too big for
> embedded targ
On Thu, Jun 04, 2020 at 04:53:34AM +0200, Sedat Dilek wrote:
> can you push that change also to kees/linux.git#kspp/uninit/v5.7/macro ?
Done! :)
--
Kees Cook
On Wed, Jun 03, 2020 at 04:31:53PM -0700, Kees Cook wrote:
> Using uninitialized_var() is dangerous as it papers over real bugs[1]
> (or can in the future), and suppresses unrelated compiler warnings
> (e.g. "unused variable"). If the compiler thinks it is uninitialized,
> either simply initialize
On Wed, Jun 03, 2020 at 04:32:02PM -0700, Kees Cook wrote:
> Using uninitialized_var() is dangerous as it papers over real bugs[1]
> (or can in the future), and suppresses unrelated compiler warnings
> (e.g. "unused variable"). If the compiler thinks it is uninitialized,
> either simply initialize
Hi Vinay,
I love your patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Vinay-Kumar-Yadav/crypto-chtls-Fix-compile-error-when-CONFIG_IPV6-is-disabled/20200603-184315
base: https://git.kernel.org/pub/scm/linux
On Wed, 3 Jun 2020 11:12:51 -0700 Florian Fainelli wrote:
> Any reason why this is written in python versus shell?
Perhaps personal preference of the author :)
I'd be curious to hear the disadvantages, is python too big for
embedded targets?
On Wed, 3 Jun 2020 08:50:21 + same...@amazon.com wrote:
> From: Sameeh Jubran
>
> This patchset includes 2 XDP related bug fixes
All clean now :)
Acked-by: Jakub Kicinski
On 2020/6/4 11:01, Jakub Kicinski wrote:
> On Wed, 3 Jun 2020 14:20:15 +0800 Luo bin wrote:
>> add support to get eeprom information from the plug-in module
>> with ethtool -m cmd.
>>
>> Signed-off-by: Luo bin
>
> drivers/net/ethernet/huawei/hinic/hinic_port.c:1386:5: warning: variable
> port_id
On Wed, 3 Jun 2020 16:01:46 -0700 Miao-chen Chou wrote:
> This adds the request handler of MGMT_OP_ADD_ADV_PATTERNS_MONITOR command.
> Note that the controller-based monitoring is not yet in place. This tracks
> the content of the monitor without sending HCI traffic, so the request
> returns immed
On Wed, 3 Jun 2020 14:20:15 +0800 Luo bin wrote:
> add support to get eeprom information from the plug-in module
> with ethtool -m cmd.
>
> Signed-off-by: Luo bin
drivers/net/ethernet/huawei/hinic/hinic_port.c:1386:5: warning: variable
port_id set but not used [-Wunused-but-set-variable]
1386
On Wed, 3 Jun 2020 10:02:33 +0300 Tariq Toukan wrote:
> > IIUC the HW asks for a resync at the first record after a specific seq
> > (the record header is in the frame that carried the OOO marking, right?)
> >
> > Can we make the core understand those semantics and avoid trying to
> > resync at th
Hi Kees,
can you push that change also to kees/linux.git#kspp/uninit/v5.7/macro ?
Thanks in advance.
Regards,
- Sedat -
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=kspp/uninit/v5.7/macro
On Thu, Jun 4, 2020 at 4:44 AM Kees Cook wrote:
>
> On Wed, Jun 03, 2020 at
On Wed, 3 Jun 2020 12:45:04 +0200 Jiri Pirko wrote:
> Tue, Jun 02, 2020 at 09:33:11PM CEST, k...@kernel.org wrote:
> >On Tue, 2 Jun 2020 14:31:11 +0300 Danielle Ratson wrote:
> >> Currently, user has no way of knowing if a port can be split and into
> >> how many ports.
> >>
> >> Among other th
On Wed, Jun 03, 2020 at 06:47:13PM -0700, Joe Perches wrote:
> On Wed, 2020-06-03 at 18:40 -0700, Kees Cook wrote:
> > On Wed, Jun 03, 2020 at 05:02:29PM -0700, Joe Perches wrote:
> > > On Wed, 2020-06-03 at 16:32 -0700, Kees Cook wrote:
> > > > Using uninitialized_var() is dangerous as it papers o
From: Dan Carpenter Sent: Thursday, June 4, 2020
1:50 AM
> The code is return PTR_ERR(NULL) which is zero or success. We should
> return -ENOMEM instead.
>
> Fixes: 94abdad6974a5 ("net: ethernet: dwmac: add ethernet glue logic for
> NXP imx8 chip")
> Signed-off-by: Dan Carpenter
Thanks!
Acke
On Thu, Jun 4, 2020 at 3:44 AM Kees Cook wrote:
>
> On Thu, Jun 04, 2020 at 03:23:28AM +0200, Sedat Dilek wrote:
> > what is the base for your patchset?
>
> Hi! This was actually on Linus's latest tree (which is basically -next),
> mostly because I figured this might be a bit of an RFC but if it w
On Wed, 2020-06-03 at 18:40 -0700, Kees Cook wrote:
> On Wed, Jun 03, 2020 at 05:02:29PM -0700, Joe Perches wrote:
> > On Wed, 2020-06-03 at 16:32 -0700, Kees Cook wrote:
> > > Using uninitialized_var() is dangerous as it papers over real bugs[1]
> > > (or can in the future), and suppresses unrelat
On Thu, Jun 04, 2020 at 03:23:28AM +0200, Sedat Dilek wrote:
> what is the base for your patchset?
Hi! This was actually on Linus's latest tree (which is basically -next),
mostly because I figured this might be a bit of an RFC but if it was
clean enough, it might actually make the merge window (I
On Wed, Jun 03, 2020 at 05:02:29PM -0700, Joe Perches wrote:
> On Wed, 2020-06-03 at 16:32 -0700, Kees Cook wrote:
> > Using uninitialized_var() is dangerous as it papers over real bugs[1]
> > (or can in the future), and suppresses unrelated compiler warnings
> > (e.g. "unused variable"). If the co
Hi all,
On Tue, 2 Jun 2020 12:09:57 +1000 Stephen Rothwell
wrote:
>
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt
>
> between commit:
>
> 7b9e111a5216 ("dt-bindings: clock: mediatek:
On Thu, Jun 4, 2020 at 1:32 AM Kees Cook wrote:
>
> Using uninitialized_var() is dangerous as it papers over real bugs[1]
> (or can in the future), and suppresses unrelated compiler warnings
> (e.g. "unused variable"). If the compiler thinks it is uninitialized,
> either simply initialize the vari
Hi all,
On Tue, 2 Jun 2020 12:17:35 +1000 Stephen Rothwell
wrote:
>
> Hi all,
>
> After merging the net-next tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c:666:13: warning:
> 'cxgb4_uld_in_use' defined but n
On Wed, Jun 03, 2020 at 11:54:14PM +0200, Roelof Berg wrote:
> Corrected the MAC_CR configuration bits for 1 GBit operation. The data
> sheet allows MAC_CR(2:1) to be 10 and also 11 for 1 GBit/s speed, but
> only 10 works correctly.
>
> Devices tested:
> Microchip Lan7431, fixed-phy mode
> Microch
> > Where is spanning tree performed? In the switch, or by the
> > host?
>
> In the switch I think.
> There is a register in the ASIC to set the spanning tree status
> to disabled, blocking, learning or forwarding.
Hi Linus
Spanning tree needs two parts. You need to be able to change the ports
b
Hi Kees,
On Thu, Jun 4, 2020 at 1:32 AM Kees Cook wrote:
>
> Using uninitialized_var() is dangerous as it papers over real bugs[1]
> (or can in the future), and suppresses unrelated compiler warnings
> (e.g. "unused variable"). If the compiler thinks it is uninitialized,
> either simply initializ
Hi--
Here are a few comments for you.
On 5/26/20 4:03 AM, Emanuele Giuseppe Esposito wrote:
> Html docs for a complete documentation of the stats_fs API,
> filesystem and usage.
>
> Signed-off-by: Emanuele Giuseppe Esposito
> ---
> Documentation/filesystems/index.rst| 1 +
> Documentati
On Wed, 2020-06-03 at 16:32 -0700, Kees Cook wrote:
> Using uninitialized_var() is dangerous as it papers over real bugs[1]
> (or can in the future), and suppresses unrelated compiler warnings
> (e.g. "unused variable"). If the compiler thinks it is uninitialized,
> either simply initialize the var
On 2020-06-03 16:32, Kees Cook wrote:
> Using uninitialized_var() is dangerous as it papers over real bugs[1]
> (or can in the future), and suppresses unrelated compiler warnings
> (e.g. "unused variable"). If the compiler thinks it is uninitialized,
> either simply initialize the variable or make
Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings (e.g.
"unused variable"). If the compiler thinks it is uninitialized, either
simply initialize the variable or make compiler changes. As a precursor
to removing[2
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you can confirm the sender and know the
content is safe.
On Tue, May 19, 2020 at 11:27:50PM +, Anchal Agarwal wrote:
> From: Munehisa Kamata
>
> S4 power transi
Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings (e.g.
"unused variable"). If the compiler thinks it is uninitialized, either
simply initialize the variable or make compiler changes. As a precursor
to removing[2
Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings
(e.g. "unused variable"). If the compiler thinks it is uninitialized,
either simply initialize the variable or make compiler changes.
As recommended[2] by[3] Lin
Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings (e.g.
"unused variable"). If the compiler thinks it is uninitialized, either
simply initialize the variable or make compiler changes. As a precursor
to removing[2
Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings (e.g.
"unused variable"). If the compiler thinks it is uninitialized, either
simply initialize the variable or make compiler changes. As a precursor
to removing[2
Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings (e.g.
"unused variable"). If the compiler thinks it is uninitialized, either
simply initialize the variable or make compiler changes. As a precursor
to removing[2
Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings (e.g.
"unused variable"). If the compiler thinks it is uninitialized, either
simply initialize the variable or make compiler changes. As a precursor
to removing[2
Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings
(e.g. "unused variable"). If the compiler thinks it is uninitialized,
either simply initialize the variable or make compiler changes.
As recommended[2] by[3] Lin
Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings
(e.g. "unused variable"). If the compiler thinks it is uninitialized,
either simply initialize the variable or make compiler changes.
In preparation for removing
Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings
(e.g. "unused variable"). If the compiler thinks it is uninitialized,
either simply initialize the variable or make compiler changes.
I preparation for removing[
Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings (e.g.
"unused variable"). If the compiler thinks it is uninitialized, either
simply initialize the variable or make compiler changes. As a precursor
to removing[2
On Fri, 29 May 2020, Andrew Lunn wrote:
> > while browsing the sourcefile of lib8390.c in
> > drivers/net/ethernet/8390/, i noticed that inside
> > of ei_rx_overrun(), which is called from inside
> > a Interrupt handler, mdelay() is being used.
> > So i wonder if the usage of mdelay() inside the
>
Hi Marcel,
Thanks for your review. V2 was uploaded to address these 3 comments.
Regards,
Miao
On Wed, Jun 3, 2020 at 10:59 AM Marcel Holtmann wrote:
>
> Hi Miao-chen,
>
> > This adds the request handler of MGMT_OP_READ_ADV_MONITOR_FEATURES
> > command. Since the controller-based monitoring is n
This notifies management sockets on MGMT_EV_ADV_MONITOR_REMOVED event.
The following test was performed.
- Start two btmgmt consoles, issue a btmgmt advmon-remove command on one
console and observe a MGMT_EV_ADV_MONITOR_REMOVED event on the other.
Signed-off-by: Miao-chen Chou
---
Changes in v2
This adds support for Advertisement Monitor API. Here are the commands
and events added.
- Read Advertisement Monitor Feature command
- Add Advertisement Pattern Monitor command
- Remove Advertisement Monitor command
- Advertisement Monitor Added event
- Advertisement Monitor Removed event
Signed-
This adds the request handler of MGMT_OP_READ_ADV_MONITOR_FEATURES
command. Since the controller-based monitoring is not yet in place, this
report only the supported features but not the enabled features.
The following test was performed.
- Issuing btmgmt advmon-features.
Signed-off-by: Miao-chen
This notifies management sockets on MGMT_EV_ADV_MONITOR_ADDED event.
The following test was performed.
- Start two btmgmt consoles, issue a btmgmt advmon-add command on one
console and observe a MGMT_EV_ADV_MONITOR_ADDED event on the other
Signed-off-by: Miao-chen Chou
---
Changes in v2: None
This adds the request handler of MGMT_OP_REMOVE_ADV_MONITOR command.
Note that the controller-based monitoring is not yet in place. This
removes the internal monitor(s) without sending HCI traffic, so the
request returns immediately.
The following test was performed.
- Issue btmgmt advmon-remove w
This adds the request handler of MGMT_OP_ADD_ADV_PATTERNS_MONITOR command.
Note that the controller-based monitoring is not yet in place. This tracks
the content of the monitor without sending HCI traffic, so the request
returns immediately.
The following manual test was performed.
- Issue btmgmt
This calls hci_update_background_scan() when there is any update on the
advertisement monitors. If there is at least one advertisement monitor,
the filtering policy of scan parameters should be 0x00. This also reports
device found mgmt events if there is at least one monitor.
The following cases w
Jakub Sitnicki wrote:
> On Wed, Jun 03, 2020 at 08:35 PM CEST, John Fastabend wrote:
> > Jakub Sitnicki wrote:
>
> [...]
>
> >> I'm not sure that the check for map->refcnt when sock is unlinking
> >> itself from the map will do it. I worry we will then have issues when
> >> sockhash is unlinking
CAUTION: This email originated from outside of the organization. Do not
click links or open attachments unless you can confirm the sender and know the
content is safe.
On 5/19/20 7:26 PM, Anchal Agarwal wrote:
> From: Munehisa Kamata
>
> Add Xen PVHVM specific system core
David Wilder wrote:
> This crash happened on a ppc64le system running ltp network tests when ltp
> script ran "rmmod iptable_mangle".
>
> [213425.602369] BUG: Kernel NULL pointer dereference at 0x0010
> [213425.602388] Faulting instruction address: 0xc00800550bdc
[..]
> In the crash we
Thanks, I found the cause, the delta patch is submitted. Lan7430 runs now in
different speeds, also ‚hot swap‘ between different speeds works well. Normal
mode and fixed-phy mode coexist properly.
So, I guess we’re done :) However, I’ll spend some more time testing to ensure
we’re really safe.
Hi Andrew!
On Wed, Jun 3, 2020 at 3:52 PM Andrew Lunn wrote:
> Do you think you are passed basic debug/reverse engineering? There are
> a lot of netdev_dbg() statements here. It would be nice to remove most
> of them, if you think the code is stable.
OK
> Is there any hint in OpenRRPC that tag
Corrected the MAC_CR configuration bits for 1 GBit operation. The data
sheet allows MAC_CR(2:1) to be 10 and also 11 for 1 GBit/s speed, but
only 10 works correctly.
Devices tested:
Microchip Lan7431, fixed-phy mode
Microchip Lan7430, normal phy mode
Signed-off-by: Roelof Berg
---
drivers/net/e
net/sch_generic.h does not need to be included, remove it.
Signed-off-by: Valentin Longchamp
---
drivers/net/ethernet/freescale/ucc_geth.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/ucc_geth.c
b/drivers/net/ethernet/freescale/ucc_geth.c
index 552e7554a9f8.
This crash happened on a ppc64le system running ltp network tests when ltp
script ran "rmmod iptable_mangle".
[213425.602369] BUG: Kernel NULL pointer dereference at 0x0010
[213425.602388] Faulting instruction address: 0xc00800550bdc
[213425.602399] Oops: Kernel access of bad area, sig: 1
On 2020-06-02, Alexei Starovoitov wrote:
> ISO C forbids zero-size arrays, unnamed struct/union, gcc extensions,
> empty unions, etc
> So ?
So their use should be avoided in UAPI headers whenever possible.
While the other extensions are simple and have clear semantics, enums
with out-of-range val
Remove dev_watchdog_up() that directly called __netdev_watchdog_up() and
rename dev_watchdog_down() to __netdev_watchdog_down() for symmetry.
Signed-off-by: Valentin Longchamp
---
net/sched/sch_generic.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/net/sched/sc
Since the quiesce/activate rework, __netdev_watchdog_up() is directly
called in the ucc_geth driver.
Unfortunately, this function is not available for modules and thus
ucc_geth cannot be built as a module anymore. Fix it by exporting
__netdev_watchdog_up().
Since the commit introducing the regres
On Wed, Jun 3, 2020 at 12:05 PM Matthieu Baerts
wrote:
>
> A recent commit added new variables only used if CONFIG_NETDEVICES is
> set. A simple fix would be to only declare these variables if the same
> condition is valid but Alexei suggested an even simpler solution:
>
> since CONFIG_NETDEVI
On Wed, Jun 03, 2020 at 08:35 PM CEST, John Fastabend wrote:
> Jakub Sitnicki wrote:
[...]
>> I'm not sure that the check for map->refcnt when sock is unlinking
>> itself from the map will do it. I worry we will then have issues when
>> sockhash is unlinking itself from socks (so the other way ar
Th referenced change added an extra hw reset to rtl8169_net_suspend()
what makes WoL fail on few chip versions. Therefore skip the extra
reset if we're going down and WoL is enabled.
In rtl_shutdown() rtl8169_hw_reset() is called by rtl8169_net_suspend()
already if needed, therefore avoid issues is
It is preferable to allow suspend even when Bluetooth has problems
preparing for sleep. When Bluetooth fails to finish preparing for
suspend, log the error and allow the suspend notifier to continue
instead.
To also make it clearer why suspend failed, change bt_dev_dbg to
bt_dev_err when handling
On 03.06.2020 20:57, Eivind Uggedal wrote:
> Hi,
>
> I saw you added the initial RTL8125 support in r8169.
>
> I have a recent x570 motherboard (MSI x570 Tomahawk) with onboard RTL8125.
> With r8169 from 5.4 and 5.7 I get:
>
>> unknown chip XID 641
>
> from the r8169 driver since XID==641 does
A recent commit added new variables only used if CONFIG_NETDEVICES is
set. A simple fix would be to only declare these variables if the same
condition is valid but Alexei suggested an even simpler solution:
since CONFIG_NETDEVICES doesn't change anything in .h I think the
best is to remove
>
> Hi Alexei,
>
> On 03/06/2020 20:14, Alexei Starovoitov wrote:
> > On Wed, Jun 03, 2020 at 11:12:01AM +0200, Matthieu Baerts wrote:
> >> Hi Ferenc,
> >>
> >> On 03/06/2020 10:56, Ferenc Fejes wrote:
> >>> Matthieu Baerts ezt írta (időpont:
> >>> 2020. jún. 3., Sze, 10:11):
>
> A recen
On Wed, Jun 3, 2020 at 11:41 AM Matthieu Baerts
wrote:
>
> Hi Alexei,
>
> On 03/06/2020 20:14, Alexei Starovoitov wrote:
> > On Wed, Jun 03, 2020 at 11:12:01AM +0200, Matthieu Baerts wrote:
> >> Hi Ferenc,
> >>
> >> On 03/06/2020 10:56, Ferenc Fejes wrote:
> >>> Matthieu Baerts ezt írta (időpont:
Hi Alexei,
On 03/06/2020 20:14, Alexei Starovoitov wrote:
On Wed, Jun 03, 2020 at 11:12:01AM +0200, Matthieu Baerts wrote:
Hi Ferenc,
On 03/06/2020 10:56, Ferenc Fejes wrote:
Matthieu Baerts ezt írta (időpont:
2020. jún. 3., Sze, 10:11):
A recent commit added new variables only used if CON
Jakub Sitnicki wrote:
> On Wed, Jun 03, 2020 at 08:13 AM CEST, Eric Dumazet wrote:
> > On 3/10/20 9:41 AM, John Fastabend wrote:
> >> The bucket->lock is not needed in the sock_hash_free and sock_map_free
> >> calls, in fact it is causing a splat due to being inside rcu block.
> >>
[...]
>> diff
On Tue, Jun 02, 2020 at 12:27:24PM -0700, Nathan Chancellor wrote:
> On Tue, Jun 02, 2020 at 03:28:37PM +0300, Leon Romanovsky wrote:
> > From: Leon Romanovsky
> >
> > Clang warns:
> >
> > drivers/net/ethernet/mellanox/mlx5/core/main.c:1278:6: warning: variable
> > 'err' is used uninitialized wh
I’m testing with Microchip Lan7430, which is an integrated circuit that
contains MAC and PHY in one package. With the release kernel the hardware works
fine, so the overall configuration is ok (jumpers).
I will verify wether the effective RGMII and delay settings, you mention, are
equal in both
On Wed, Jun 03, 2020 at 11:12:01AM +0200, Matthieu Baerts wrote:
> Hi Ferenc,
>
> On 03/06/2020 10:56, Ferenc Fejes wrote:
> > Matthieu Baerts ezt írta (időpont:
> > 2020. jún. 3., Sze, 10:11):
> > >
> > > A recent commit added new variables only used if CONFIG_NETDEVICES is
> > > set.
> >
> >
On 6/2/2020 4:31 AM, Danielle Ratson wrote:
> Test port split configuration using previously added number of port lanes
> attribute.
>
> Check that all the splittable ports are successfully split to their maximum
> number of lanes and below, and that those which are not splittable fail to
> be
On Wed, Jun 03, 2020 at 06:33:28PM +0200, Roelof Berg wrote:
> Ok, let's proceed :) The code runs well, dmesg looks good, ip addr shows me a
> link up, speed/duplex looks ok. But it does not transfer any data.
>
> Debugging steps (A/B versions):
> - Check clocks with oscilloscope (10/100/1000)
>
On Wed, Jun 03, 2020 at 06:36:28PM +0200, Roelof Berg wrote:
> If I find a fix, would I need to submit a delta patch (to our last one) or a
> full patch ?
A delta.
Andrew
On Wed, Jun 3, 2020 at 8:35 AM Carlos Neira wrote:
>
> folds tests from test_current_pid_tgid_new_ns into test_progs.
>
> Signed-off-by: Carlos Neira
Please resubmit when bpf-next reopens. Thanks
Hi Miao-chen,
> This adds the request handler of MGMT_OP_READ_ADV_MONITOR_FEATURES
> command. Since the controller-based monitoring is not yet in place, this
> report only the supported features but not the enabled features.
>
> The following test was performed.
> - Issuing btmgmt advmon-features
On Tue, Jun 2, 2020 at 3:19 PM Jakub Kicinski wrote:
>
> On Tue, 2 Jun 2020 14:56:25 + Pooja Trivedi wrote:
> > This selftest tests for cases where sendfile's 'count'
> > parameter is provided with a size greater than the intended
> > file size.
> >
> > Motivation: When sendfile is provided w
>
> net-next is CLOSED
>
Okay, I will resend in next merge window
signature.asc
Description: OpenPGP digital signature
Hi Manish,
> Check current scan state by checking HCI_LE_SCAN flag and send scan
> disable command only if scan is already enabled.
>
> Signed-off-by: Manish Mandlik
> ---
>
> net/bluetooth/hci_request.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
patch has been applied t
The code is return PTR_ERR(NULL) which is zero or success. We should
return -ENOMEM instead.
Fixes: 94abdad6974a5 ("net: ethernet: dwmac: add ethernet glue logic for NXP
imx8 chip")
Signed-off-by: Dan Carpenter
---
drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c | 2 +-
1 file changed, 1 inser
Hi Manish,
> Based on your feedback, in the BlueZ kernel, if we plan to track whether the
> link was created because of Pair Device action or not, we'll need to add a
> flag in struch hci_conn and update related functions/APIs. I was wondering if
> this would look like a clean fix or not.
>
>
From: Richard Sailer
Date: Wed, 3 Jun 2020 13:10:51 +0200
> This adds support for the SIOCOUTQ IOCTL to get the send buffer fill
> of a DCCP socket, like UDP and TCP sockets already have.
>
> Regarding the used data field: DCCP uses per packet sequence numbers,
> not per byte, so sequence numbe
From: Vinay Kumar Yadav
Date: Wed, 3 Jun 2020 16:03:17 +0530
> @@ -102,19 +100,24 @@ static struct net_device *chtls_find_netdev(struct
> chtls_dev *cdev,
> return ndev;
> ndev = ip_dev_find(&init_net, inet_sk(sk)->inet_rcv_saddr);
> break;
> +#
net-next is closed
[ Just a re-send without html and a few fixes for mobile editing,
since that email got eaten by the mailing list Gods ]
On Tue, Jun 2, 2020, 23:02 Michael S. Tsirkin wrote:
>
> Right and we do that, but that still sets the segment according to the
> current thread's flags, right?
But that should
On Wed, Jun 03, 2020 at 01:29:00AM -0400, Michael S. Tsirkin wrote:
> On Wed, Jun 03, 2020 at 02:48:15AM +0100, Al Viro wrote:
> > On Tue, Jun 02, 2020 at 04:45:05AM -0400, Michael S. Tsirkin wrote:
> > > So vhost needs to poke at userspace *a lot* in a quick succession. It
> > > is thus benefitia
If I find a fix, would I need to submit a delta patch (to our last one) or a
full patch ?
Thanks.
> So lets try to fix it.
>
>Thanks
> Andrew
>
Ok, let's proceed :) The code runs well, dmesg looks good, ip addr shows me a
link up, speed/duplex looks ok. But it does not transfer any data.
Debugging steps (A/B versions):
- Check clocks with oscilloscope (10/100/1000)
- Dump actual register settings
- Trace Phy-Phy autonegotiation and ensur
On Wed, Jun 03, 2020 at 05:44:43PM +0200, Jesper Dangaard Brouer wrote:
> The recent commit fbee97feed9b ("bpf: Add support to attach bpf program to a
> devmap entry"), introduced ability to attach (and run) a separate XDP
> bpf_prog for each devmap entry. A bpf_prog is added via a file-descriptor,
On Wed, Jun 03, 2020 at 11:11:58AM +0200, Jesper Dangaard Brouer wrote:
> On Tue, 2 Jun 2020 11:27:03 -0700
> Alexei Starovoitov wrote:
>
> > On Tue, Jun 2, 2020 at 12:00 AM Jesper Dangaard Brouer
> > wrote:
> > >
> > > On Mon, 1 Jun 2020 14:30:12 -0700
> > > Alexei Starovoitov wrote:
> > >
>
1 - 100 of 172 matches
Mail list logo
