lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87cyjpj6qx.fsf@mail.lhotse>
Date: Fri, 25 Oct 2024 12:44:54 +1100
From: Michael Ellerman <mpe@...erman.id.au>
To: Sasha Levin <sashal@...nel.org>, torvalds@...ux-foundation.org
Cc: kuba@...nel.org, davem@...emloft.net, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org, pabeni@...hat.com, kees@...nel.org,
 broonie@...nel.org
Subject: Re: [GIT PULL] Networking for v6.12-rc5

Sasha Levin <sashal@...nel.org> writes:
> Sorry for the spam below, this is another attempt to solicit feedback to
> the -next analysis tools that a few of us were working on.
>
> Bigger changes since the last attempt:
>
>    - Count calendar days rather than number of tags for the histogram.
    
I think this is a good change, but the presentation of the information
probably needs a bit of work.

Some of the commits below are in next-20241024, which was tagged less
than one day ago, but some are not. But they're all shown as "0 days",
which I think will confuse people.

I think you need to differentiate between 0 days in linux-next vs
*never* in linux-next. Otherwise folks are going to yell at you and say
"that commit was in linux-next!".

>    - Make histogram more concise when possible (the below is *not* a good
>      example of the new functionality).
>    - Add more statistics to the report.
>
> On Thu, Oct 24, 2024 at 04:01:01PM +0200, Paolo Abeni wrote:
>>Hi Linus!
>>
>>Oddily this includes a fix for posix clock regression; in our previous PR
>>we included a change there as a pre-requisite for networking one.
>>Such fix proved to be buggy and requires the follow-up included here.
>>Thomas suggested we should send it, given we sent the buggy patch.
>>
>>The following changes since commit 07d6bf634bc8f93caf8920c9d61df761645336e2:
>>
>>  Merge tag 'net-6.12-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net (2024-10-17 09:31:18 -0700)
>>
>>are available in the Git repository at:
>>
>>  git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git net-6.12-rc5
>
> Days in linux-next:
> ----------------------------------------
>   0 | █████████████████████████████████████████████████ (14)
>   1 | ███████ (2)
   
So I think here you need something like (numbers made up):

Days in linux-next:
----------------------------------------
   0 | ███████████████ (4)
 < 1 | █████████████████████████████████████████████████ (10)
   1 | ███████ (2)

To make it clear that some commits were not in linux-next at all,
whereas some were but for such a short time that they can hardly have
seen any testing. (Which still has some value, because at least we know
they didn't cause a merge conflict and passed at least some build
testing that sfr does during the linux-next merge).

>   2 | █████████████████████ (6)
>   3 | ██████████████████████████████████████████ (12)
>   4 |
>   5 |
>   6 | ███ (1)
>   7 |
>   8 | ███ (1)
>   9 |
> 10 |
> 11 |
> 12 |
> 13 |
> 14+| ██████████████ (4)
>
> Commits with 0 days in linux-next (14 of 40: 35.0%):
> --------------------------------
> 3e65ede526cf4 net: dsa: mv88e6xxx: support 4000ps cycle counter period
> 7e3c18097a709 net: dsa: mv88e6xxx: read cycle counter period from hardware
> 67af86afff74c net: dsa: mv88e6xxx: group cycle counter coefficients
> 64761c980cbf7 net: usb: qmi_wwan: add Fibocom FG132 0x0112 composition
> 4c262801ea60c hv_netvsc: Fix VF namespace also in synthetic NIC NETDEV_REGISTER event
> ee76eb24343bd net: dsa: microchip: disable EEE for KSZ879x/KSZ877x/KSZ876x
> 246b435ad6685 Bluetooth: ISO: Fix UAF on iso_sock_timeout
> 1bf4470a3939c Bluetooth: SCO: Fix UAF on sco_sock_timeout
> 989fa5171f005 Bluetooth: hci_core: Disable works on hci_unregister_dev
 
The commits below here are in today's linux-next (next-20241024):

> 6e62807c7fbb3 posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()
> 10ce0db787004 r8169: avoid unsolicited interrupts
> b22db8b8befe9 net: sched: use RCU read-side critical section in taprio_dump()
> f504465970aeb net: sched: fix use-after-free in taprio_change()
> 34d35b4edbbe8 net/sched: act_api: deny mismatched skip_sw/skip_hw flags for actions created by classifiers

The first question that comes to mind here is what's the diffstat for
these like.

There's a big difference if these are all tight few-line fixes to
individual drivers or sprawling hundred line changes that touch arch
code etc.

Listing the diffstat for all of them individually would be way too
spammy. Passing all the sha's to git show and using diffstat seems to
give a reasonable overview, eg:

$ git show -p 3e65ede526cf4 7e3c18097a709 67af86afff74c 64761c980cbf7 4c262801ea60c ee76eb24343bd 246b435ad6685 1bf4470a3939c 989fa5171f005 | diffstat -p1

 drivers/net/dsa/microchip/ksz_common.c |   21 +++++++++++----------
 drivers/net/dsa/mv88e6xxx/chip.h       |    8 +++-----
 drivers/net/dsa/mv88e6xxx/ptp.c        |  142 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--------------------------------------------------
 drivers/net/hyperv/netvsc_drv.c        |   30 ++++++++++++++++++++++++++++++
 drivers/net/usb/qmi_wwan.c             |    1 +
 include/net/bluetooth/bluetooth.h      |    1 +
 net/bluetooth/af_bluetooth.c           |   22 ++++++++++++++++++++++
 net/bluetooth/hci_core.c               |   24 +++++++++++++++---------
 net/bluetooth/hci_sync.c               |   12 +++++++++---
 net/bluetooth/iso.c                    |   18 ++++++++++++------
 net/bluetooth/sco.c                    |   18 ++++++++++++------
 11 files changed, 208 insertions(+), 89 deletions(-)

I know the pull request has a diffstat, but they are significantly different.

Apologies for bike-shedding this so hard, it's just because I think it
would be a good addition to the development culture.

cheers

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ