So this was a fairly unusual merge window with the holidays, and as a
result I'm not even going to complain about the pull requests that
ended up coming in late. It all mostly worked out fine, I think. And
lot of people got their pull requests in early, and hopefully had a
calm holiday season. Thanks again to everybody.
The numbering change is not indicative of anything special. If you
want to have an official reason, it's that I ran out of fingers and
toes to count on, so 4.21 became 5.0. There's no nice git object
numerology this time (we're _about_ 6.5M objects in the git repo), and
there isn't any major particular feature that made for the release
numbering either. Of course, depending on your particular interests,
some people might well find a feature _they_ like so much that they
think it can do as a reason for incrementing the major number.
So go wild. Make up your own reason for why it's 5.0.
Because as usual, there's a lot of changes in there. Not because this
merge window was particularly big - but even our smaller merge windows
aren't exactly small. It's a very solid and average merge window with
just under 11k commits (or about 11.5k if you count merges).
The stats look fairly normal. About 50% is drivers, 20% is
architecture updates, 10% is tooling, and the remaining 20% is all
over (documentation, networking, filesystems, header file updates,
core kernel code..). Nothing particular stands out, although I do like
seeing how some ancient drivers are getting put out to pasture
(*cought*isdn*cough*).
As usual even the shortlog is much too big to post, so the summary
below is only a list of the pull requests I merged.
Go test. Kick the tires. Be the first kid on your block running a 5.0
pre-release kernel.
Linus
---
Al Viro (2):
trivial vfs updates
vfs mount API prep
Alex Williamson (1):
VFIO updates
Alexandre Belloni (1):
RTC updates
Andrew Morton (2):
misc updates
more updates
Andy Shevchenko (1):
x86 platform driver updates
Anna Schumaker (1):
NFS client updates
Arnd Bergmann (2):
arch/sh syscall table scripting
y2038 updates
Bartlomiej Zolnierkiewicz (1):
fbdev updates
Benson Leung (1):
chrome platform updates
Bjorn Andersson (1):
hwspinlock updates
Bjorn Helgaas (1):
PCI updates
Bob Peterson (1):
gfs2 updates
Boris Brezillon (2):
initial i3c support
mtd updates
Borislav Petkov (4):
EDAC updates
x86 cache control updates
x86 microcode loading updates
x86 RAS updates
Bruce Fields (1):
nfsd updates
Christoph Hellwig (2):
DMA mapping updates
dma-mapping fixes
Dan Williams (2):
libnvdimm updates
dax fix
Daniel Thompson (1):
kgdb updates
Darrick Wong (4):
XFS updates
iomap update
xfs fixlets
iomap maintainer update
Dave Airlie (3):
drm updates
more drm updates
drm fixes
David Miller (3):
sparc updates
networking updates
networking fixes
David Sterba (1):
btrfs updates
David Teigland (1):
dlm updates
Dennis Zhou (1):
percpu update
Dmitry Torokhov (1):
input updates
Dominique Martinet (1):
9p updates
Eduardo Valentin (1):
thermal SoC updates
Geert Uytterhoeven (1):
m68k updates
Greentime Hu (1):
nds32 updates
Greg KH (5):
USB/PHY updates
tty/serial driver updates
staging/IIO driver updates
driver core updates
char/misc driver updates
Guenter Roeck (1):
hwmon updates
Guo Ren (1):
arch/csky updates
Helge Deller (2):
parisc updates
parisc fix
Herbert Xu (1):
crypto updates
Ilya Dryomov (1):
ceph updates
Ingo Molnar (15):
RCU updates
EFI updates
locking updates
perf updates
scheduler updates
x86 AMD northbridge updates
x86 asm updates
x86 boot updates
x86 build updates
x86 cleanups
x86 cpu updates
x86 fpu updates
x86 mm updates
x86 platform update
scheduler fix
Jacek Anaszewski (1):
LED updates
Jaegeuk Kim (1):
f2fs updates
James Bottomley (1):
SCSI updates
James Morris (5):
general security subsystem updates
integrity updates
seccomp updates
smack updates
TPM updates
Jan Kara (2):
fsnotify updates
ext2, udf, and quota update
Jason Gunthorpe (2):
rdma updates
rdma fixes
Jassi Brar (1):
mailbox updates
Jeff Layton (2):
file locking updates
file locking bugfix
Jens Axboe (6):
block updates
aio updates
libata updates
libata fix
more block updates
block updates and fixes
Jessica Yu (1):
modules updates
Jiri Kosina (2):
livepatch update
HID updates
Joerg Roedel (1):
IOMMU updates
Jonathan Corbet (2):
documentation update
documentation fixes
Juergen Gross (1):
xen updates
Kees Cook (2):
pstore updates
gcc-plugins update
Linus Walleij (2):
GPIO updates
pin control updates
Mark Brown (3):
regulator updates
spi updates
regmap updates
Martin Schwidefsky (1):
s390 updates
Masahiro Yamada (4):
Kbuild updates
Kconfig updates
Kconfig file consolidation
more Kbuild updates
Matt Turner (1):
alpha architecture updates
Mauro Carvalho Chehab (2):
media updates
more media updates
Max Filippov (1):
Xtensa updates
Michael Ellerman (2):
powerpc updates
powerpc fixes
Michael Tsirkin (1):
virtio/vhost updates
Michal Simek (1):
arch/microblaze updates
Mike Snitzer (1):
device mapper updates
Olof Johansson (5):
arm SoC platform updates
ARM SoC driver updates
ARM Device-tree updates
ARM SoC defconfig updates
more ARM SoC updates
Palmer Dabbelt (1):
RISC-V updates
Paolo Bonzini (1):
KVM updates
Paul Burton (2):
MIPS updates
MIPS fixes
Paul Moore (2):
audit updates
selinux patches
Petr Mladek (1):
printk updates
Rafael Wysocki (4):
power management updates
ACPI updates
device properties framework updates
device properties framework fixes
Richard Weinberger (1):
UML updates
Rob Herring (1):
Devicetree updates
Russell King (1):
ARM updates
Sebastian Reichel (2):
power supply and reset updates
HSI update
Shuah Khan (1):
Kselftest updates
Stafford Horne (1):
OpenRISC update
Stefan Richter (1):
firewire fixlet
Stephen Boyd (2):
clk updates
more clk updates
Steve French (2):
cifs updates
smb3 fixes
Steven Rostedt (2):
tracing updates
ftrace sh build fix
Takashi Iwai (2):
sound updates
sound fixes
Ted Ts'o (3):
ext4 updates
ext4 bug fixes
fscrypt updates
Tejun Heo (1):
cgroup updates
Thierry Reding (1):
pwm updates
Thomas Gleixner (3):
irq updates
timer updates
x86 pti updates
Tony Luck (1):
ia64 updates
Ulf Hansson (1):
MMC updates
Vinod Koul (1):
dmaengine updates
Will Deacon (2):
arm64 festive updates
arm64 fixes
Wim Van Sebroeck (1):
watchdog updates
Wolfram Sang (1):
i2c updates
Yoshinori Sato (1):
h8300 fix
Zhang Rui (1):
thermal management updates
Hi all,
As usual, the executive friendly graph is at
http://neuling.org/linux-next-size.html :-)
(No merge commits counted, next-20181224 was the last linux-next before
the merge window opened.)
Commits in v5.0-rc1 (relative to v4.20): 10843
Commits in next-20181224: 10867
Commits with the same SHA1: 10044
Commits with the same patch_id: 301 (1)
Commits with the same subject line: 52 (1)
(1) not counting those in the lines above.
So commits in -rc1 that were in next-20181224: 10397 95%
Some breakdown of the list of extra commits (relative to next-20181224)
in -rc1:
Top ten first word of commit summary:
49 drm
26 cifs
24 perf
19 net
16 um
16 thermal
16 dt-bindings
16 csky
11 arm64
9 pci
Top ten authors:
20 [email protected]
15 [email protected]
12 [email protected]
12 [email protected]
11 [email protected]
11 [email protected]
10 [email protected]
10 [email protected]
9 [email protected]
9 [email protected]
Top ten commiters:
51 [email protected]
46 [email protected]
29 [email protected]
28 [email protected]
23 [email protected]
22 [email protected]
19 [email protected]
19 [email protected]
17 [email protected]
14 [email protected]
There are also 470 commits in next-20181224 that didn't make it into
v5.0-rc1.
Top ten first word of commit summary:
43 asoc
37 mm
23 mfd
23 arm
19 vfs
18 leaking_addresses
15 xtensa
13 nios2
11 nfc
11 dt-bindings
Top ten authors:
34 [email protected]
32 [email protected]
18 [email protected]
17 [email protected]
13 [email protected]
13 [email protected]
13 [email protected]
11 [email protected]
10 [email protected]
9 [email protected]
Some of Andrew's patches are fixes for other patches in his tree (and
have been merged into those).
Top ten commiters:
125 [email protected]
45 [email protected]
36 [email protected]
26 [email protected]
25 [email protected]
18 [email protected]
16 [email protected]
13 [email protected]
13 [email protected]
13 [email protected]
Those commits by me are from the quilt series (mainly Andrew's mmotm
tree).
--
Cheers,
Stephen Rothwell
On Sun, Jan 06, 2019 at 06:14:15PM -0800, Linus Torvalds wrote:
> So this was a fairly unusual merge window with the holidays, and as a
> result I'm not even going to complain about the pull requests that
> ended up coming in late. It all mostly worked out fine, I think. And
> lot of people got their pull requests in early, and hopefully had a
> calm holiday season. Thanks again to everybody.
>
> The numbering change is not indicative of anything special. If you
> want to have an official reason, it's that I ran out of fingers and
> toes to count on, so 4.21 became 5.0. There's no nice git object
> numerology this time (we're _about_ 6.5M objects in the git repo), and
> there isn't any major particular feature that made for the release
> numbering either. Of course, depending on your particular interests,
> some people might well find a feature _they_ like so much that they
> think it can do as a reason for incrementing the major number.
>
> So go wild. Make up your own reason for why it's 5.0.
>
> Because as usual, there's a lot of changes in there. Not because this
> merge window was particularly big - but even our smaller merge windows
> aren't exactly small. It's a very solid and average merge window with
> just under 11k commits (or about 11.5k if you count merges).
>
> The stats look fairly normal. About 50% is drivers, 20% is
> architecture updates, 10% is tooling, and the remaining 20% is all
> over (documentation, networking, filesystems, header file updates,
> core kernel code..). Nothing particular stands out, although I do like
> seeing how some ancient drivers are getting put out to pasture
> (*cought*isdn*cough*).
>
> As usual even the shortlog is much too big to post, so the summary
> below is only a list of the pull requests I merged.
>
> Go test. Kick the tires. Be the first kid on your block running a 5.0
> pre-release kernel.
>
For v5.0-rc1-1-g3bd6e94bec12:
Build results:
total: 158 pass: 155 fail: 3
Failed builds:
csky:defconfig
csky:allnoconfig
csky:tinyconfig
Qemu test results:
total: 332 pass: 332 fail: 0
mm/memory.c: In function ‘__pte_alloc’:
mm/memory.c:406:18: error: too few arguments to function ‘pte_alloc_one’
mm/memory.c: In function ‘__pte_alloc_kernel’:
mm/memory.c:439:15: error: too few arguments to function ‘pte_alloc_one_kernel’
mm/memory.c: In function ‘do_fault_around’:
mm/memory.c:3363:23: error: too few arguments to function ‘pte_alloc_one’
Bisect points to commit 4cf58924951ef ("mm: treewide: remove unused address
argument from pte_alloc functions"). Interesting - wasn't that supposed
to be automatic ?
csky does use the the removed address argument, so I won't even try to
provide a patch. Copying csky maintainer instead.
Guenter
---
# bad: [3bd6e94bec122a951d462c239b47954cf5f36e33] arch: restore generic-y += shmparam.h for some architectures
# good: [3fed6ae4b027f9c93be18520f87bd06bdffd196b] ia64: fix compile without swiotlb
git bisect start 'HEAD' '3fed6ae4b027'
# bad: [e9666d10a5677a494260d60d1fa0b73cc7646eb3] jump_label: move 'asm goto' support test to Kconfig
git bisect bad e9666d10a5677a494260d60d1fa0b73cc7646eb3
# bad: [b23b0ea3708c3dec599966fc856836aca48835b9] Merge tag 'armsoc-late' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
git bisect bad b23b0ea3708c3dec599966fc856836aca48835b9
# bad: [9ee3b3f4a5eb523ef27675ac2fcd2269b9d68767] Merge tag 'csky-for-linus-4.21' of git://github.com/c-sky/csky-linux
git bisect bad 9ee3b3f4a5eb523ef27675ac2fcd2269b9d68767
# good: [655c16a8ce9c15842547f40ce23fd148aeccc074] exec: separate MM_ANONPAGES and RLIMIT_STACK accounting
git bisect good 655c16a8ce9c15842547f40ce23fd148aeccc074
# bad: [a65981109f294ba7e64b33ad3b4575a4636fce66] Merge branch 'akpm' (patches from Andrew)
git bisect bad a65981109f294ba7e64b33ad3b4575a4636fce66
# bad: [3bb5f4ac55dd91d516e7e36b45c94bd57efbb068] kernel/locking/mutex.c: remove caller signal_pending branch predictions
git bisect bad 3bb5f4ac55dd91d516e7e36b45c94bd57efbb068
# good: [b058809bfc8faeb7b7cae047666e23375a060059] scripts/gdb: fix lx-version string output
git bisect good b058809bfc8faeb7b7cae047666e23375a060059
# bad: [4cf58924951ef80eec636b863e7a53973c44261a] mm: treewide: remove unused address argument from pte_alloc functions
git bisect bad 4cf58924951ef80eec636b863e7a53973c44261a
# good: [ff1522bb7d98450c72aea729f0b4147bc9986aed] initramfs: cleanup incomplete rootfs
git bisect good ff1522bb7d98450c72aea729f0b4147bc9986aed
# first bad commit: [4cf58924951ef80eec636b863e7a53973c44261a] mm: treewide: remove unused address argument from pte_alloc functions
On Mon, Jan 7, 2019 at 11:26 AM Guenter Roeck <[email protected]> wrote:
>
> Bisect points to commit 4cf58924951ef ("mm: treewide: remove unused address
> argument from pte_alloc functions"). Interesting - wasn't that supposed
> to be automatic ?
>
> csky does use the the removed address argument, so I won't even try to
> provide a patch. Copying csky maintainer instead.
Hmm. Interesting. The csky code seems to have some odd "poison pte
contents with ones if the address has the high bit set".
Which makes little or no sense. The "high bit set" case is for kernel
page tables, but that's exactly the "pte_alloc_one()" vs
"pte_alloc_one_kernel()" distinction.
So testing the address seems entirely wrong.
But there's other strangeness in there too. For example,
pte_alloc_one_kernel() will just write directly to the page. And
pte_alloc_one() will do a "kmap_atomic()" on the page it allocates,
except since it uses GFP_KERNEL, that's entirely pointless.
Is the alloc_pages() in pte_alloc_one() perhaps meant to use
GFP_HIGHUSER instead? Is this perhaps some copy-paste issue?
So I *think* the removal of the 'address' use in csky should be
simple, but yes, this needs a csky maintainer to look at.
Thanks,
Linus
Hi Linus,
On Mon, Jan 07, 2019 at 03:21:45PM -0800, Linus Torvalds wrote:
> On Mon, Jan 7, 2019 at 11:26 AM Guenter Roeck <[email protected]> wrote:
> >
> > Bisect points to commit 4cf58924951ef ("mm: treewide: remove unused address
> > argument from pte_alloc functions"). Interesting - wasn't that supposed
> > to be automatic ?
> >
> > csky does use the the removed address argument, so I won't even try to
> > provide a patch. Copying csky maintainer instead.
>
> Hmm. Interesting. The csky code seems to have some odd "poison pte
> contents with ones if the address has the high bit set".
PTE contents is the only _PAGE_GLOBAL bit which could let mmu ignore the
ASID. One tlb entry is composed of 2 pfns and there is one GLOBAL bit in
the tlb entry. When C-SKY MMU hard-refill a tlb entry into the TLB buffer,
it will get pfn0-GLOBAL & pfn1-GLOBAL from the memory and put the result
into the TLB buffer.
If pfn0 is valid & pfn1 is invalid, we also must keep invalid pte_t with GLOBAL
bit set for C-SKY MMU.
Also see pte_clear() and pte_none() in pgtable.h.
>
> Which makes little or no sense. The "high bit set" case is for kernel
> page tables, but that's exactly the "pte_alloc_one()" vs
> "pte_alloc_one_kernel()" distinction.
>
> So testing the address seems entirely wrong.
Yes, testing address is no necessary, I'll remove it.
>
> But there's other strangeness in there too. For example,
> pte_alloc_one_kernel() will just write directly to the page. And
> pte_alloc_one() will do a "kmap_atomic()" on the page it allocates,
> except since it uses GFP_KERNEL, that's entirely pointless.
>
> Is the alloc_pages() in pte_alloc_one() perhaps meant to use
> GFP_HIGHUSER instead?
No GFP_HIGHUSER, kmap_atomic should be removed and I'll use __GFP_ZERO
instead.
> Is this perhaps some copy-paste issue?
:P
>
> So I *think* the removal of the 'address' use in csky should be
> simple, but yes, this needs a csky maintainer to look at.
>
Here is my new implementation:
static inline pte_t *pte_alloc_one_kernel(struct mm_struct *mm)
{
pte_t *pte;
unsigned long i;
pte = (pte_t *) __get_free_page(GFP_KERNEL | __GFP_RETRY_MAYFAIL);
^^^^^^^^^^^^^^^^^^^
It's necessary ?
x86 & arm don't use
it.
if (!pte)
return NULL;
for (i = 0; i < PAGE_SIZE/sizeof(pte_t); i++)
(pte + i)->pte_low = _PAGE_GLOBAL;
return pte;
}
static inline struct page *pte_alloc_one(struct mm_struct *mm)
{
struct page *pte;
pte = alloc_pages(GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_ZERO, 0);
if (!pte)
return NULL;
if (!pgtable_page_ctor(pte)) {
__free_page(pte);
return NULL;
}
return pte;
}
Best Regards
Guo Ren
Thx Michal,
On Tue, Jan 08, 2019 at 04:40:31PM +0100, Michal Hocko wrote:
> On Tue 08-01-19 17:51:07, Guo Ren wrote:
> [...]
> > static inline pte_t *pte_alloc_one_kernel(struct mm_struct *mm)
> > {
> > pte_t *pte;
> > unsigned long i;
> >
> > pte = (pte_t *) __get_free_page(GFP_KERNEL | __GFP_RETRY_MAYFAIL);
> > ^^^^^^^^^^^^^^^^^^^
> > It's necessary ?
> > x86 & arm don't use
> > it.
> > if (!pte)
> > return NULL;
>
> That depends on whether you want OOM killer to be triggered for these
> allocations. If you add the flag then the allocation bails out with a
> failure rather than kill an oom victim.
Yes, in page_alloc.c:
if (gfp_mask & __GFP_RETRY_MAYFAIL)
goto out;
...
if (out_of_memory(&oc) || WARN_ON_ONCE(gfp_mask & __GFP_NOFAIL)) {
^^^^^^^^^^^^^ OOM kill victim
...
if (gfp_mask & __GFP_NOFAIL)
page = __alloc_pages_cpuset_fallback(gfp_mask, order,
ALLOC_NO_WATERMARKS, ac);
}
Seems it could affect the behavior of the system which is out of memory.
OOM killer could help to get_page for current. So keep the same as x86 &
arm here. I'll remove __GFP_RETRY_MAYFAIL in patch.
Best Regards
Guo Ren
On Tue 08-01-19 17:51:07, Guo Ren wrote:
[...]
> static inline pte_t *pte_alloc_one_kernel(struct mm_struct *mm)
> {
> pte_t *pte;
> unsigned long i;
>
> pte = (pte_t *) __get_free_page(GFP_KERNEL | __GFP_RETRY_MAYFAIL);
> ^^^^^^^^^^^^^^^^^^^
> It's necessary ?
> x86 & arm don't use
> it.
> if (!pte)
> return NULL;
That depends on whether you want OOM killer to be triggered for these
allocations. If you add the flag then the allocation bails out with a
failure rather than kill an oom victim.
--
Michal Hocko
SUSE Labs
On Wed 09-01-19 00:16:59, Guo Ren wrote:
> Thx Michal,
>
> On Tue, Jan 08, 2019 at 04:40:31PM +0100, Michal Hocko wrote:
> > On Tue 08-01-19 17:51:07, Guo Ren wrote:
> > [...]
> > > static inline pte_t *pte_alloc_one_kernel(struct mm_struct *mm)
> > > {
> > > pte_t *pte;
> > > unsigned long i;
> > >
> > > pte = (pte_t *) __get_free_page(GFP_KERNEL | __GFP_RETRY_MAYFAIL);
> > > ^^^^^^^^^^^^^^^^^^^
> > > It's necessary ?
> > > x86 & arm don't use
> > > it.
> > > if (!pte)
> > > return NULL;
> >
> > That depends on whether you want OOM killer to be triggered for these
> > allocations. If you add the flag then the allocation bails out with a
> > failure rather than kill an oom victim.
>
> Yes, in page_alloc.c:
> if (gfp_mask & __GFP_RETRY_MAYFAIL)
> goto out;
> ...
> if (out_of_memory(&oc) || WARN_ON_ONCE(gfp_mask & __GFP_NOFAIL)) {
> ^^^^^^^^^^^^^ OOM kill victim
> ...
> if (gfp_mask & __GFP_NOFAIL)
> page = __alloc_pages_cpuset_fallback(gfp_mask, order,
> ALLOC_NO_WATERMARKS, ac);
> }
Btw. we have that nice documentation in gfp.h. I would encourage you to
read through that rather than try to imply the semantic from the
implementation.
> Seems it could affect the behavior of the system which is out of memory.
> OOM killer could help to get_page for current. So keep the same as x86 &
> arm here. I'll remove __GFP_RETRY_MAYFAIL in patch.
OK
--
Michal Hocko
SUSE Labs
The copyright owner can rescind. Those saying you cannot are wrong.
Explained. In american vernacular:
Video: http://www.veoh.com/watch/v141917696RbH96XaD
https://openload.co/f/mT_AH3xmIUM/TruthAboutLinuxandGPLv2__.mp4
Audio: http://ufile.io/sdhpl
If you hit a video about a speedrunner: that's the wrong one.
There ain't no speed-runs through the court system.
(People been trying to give you false links, if it ain't a thug negro
rap God tellin' you the in's and outs of licensing, GPLv2, and linux:
sorry man you at the wrong address.)
Remember: If it is from the streets; you can rest easy regarding the
veracity of the information given.
Linus Torvalds schreef op zo 06-01-2019 om 18:14 [-0800]:
> Nothing particular stands out, although I do like
> seeing how some ancient drivers are getting put out to pasture
> (*cought*isdn*cough*).
Just to let people know: the gigaset drivers will get my palliative care until
a few weeks before September 1, 2019. Because at that date the Dutch consumer
grade ISDN network (the "BRI" part of ISDN) will be shut down. So expect a
patch to remove me from MAINTAINERS sometime during the v5.2 cycle.
That leaves just Karsten Keil to look after all the ISDN drivers. Karsten's
last activity was in 2016. See commit 1e1589ad8b5c ("mISDN: Support DR6
indication in mISDNipac driver"). Which is also the last commit apparently
resolving an issue noticed by an actual _user_ of one of the ISDN drivers.
Perhaps Karsten could tell us whether there's any point in keeping the ISDN
subsystem in the tree after September 1, 2019, and if so, in what form. I'm in
no position to properly answer that question.
Paul Bolle
Hi all,
Am 09.02.19 um 20:42 schrieb Paul Bolle:
> Linus Torvalds schreef op zo 06-01-2019 om 18:14 [-0800]:
>> Nothing particular stands out, although I do like
>> seeing how some ancient drivers are getting put out to pasture
>> (*cought*isdn*cough*).
>
> Just to let people know: the gigaset drivers will get my palliative care until
> a few weeks before September 1, 2019. Because at that date the Dutch consumer
> grade ISDN network (the "BRI" part of ISDN) will be shut down. So expect a
> patch to remove me from MAINTAINERS sometime during the v5.2 cycle.
>
> That leaves just Karsten Keil to look after all the ISDN drivers. Karsten's
> last activity was in 2016. See commit 1e1589ad8b5c ("mISDN: Support DR6
> indication in mISDNipac driver"). Which is also the last commit apparently
> resolving an issue noticed by an actual _user_ of one of the ISDN drivers.
>
> Perhaps Karsten could tell us whether there's any point in keeping the ISDN
> subsystem in the tree after September 1, 2019, and if so, in what form. I'm in
> no position to properly answer that question.
I still follow the kernel ISDN patches. I very glad that Paul, Kees,
David and others handle everything without the need to jump in. I still
have some ISDN equipment running behind VOIP lines.
I do not think that here are so much direct users of BRI ISDN left, I
known only very few, but here are at least some.
mISDN is still used in embedded routers to emulate the classic ISDN S0
bus to use ISDN equipment on Internet based lines and last designs for
this usage are not so long ago (less a year ago, I know from questions I
got).
But of course ISDN is in palliative care and finally removing it is
maybe not a bad idea now.
Best
Karsten