Bug#1021998: CXL -- Salsa MR added

[Adam Borowski]

https://salsa.debian.org/kernel-team/linux/-/merge_requests/563

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄

Re: [Pkg-raspi-maintainers] Bug#948712: Pinebook Pro also uses this chip

[Adam Borowski]

On Tue, Jul 12, 2022 at 12:45:11PM +0200, Diederik de Haas wrote:
> On dinsdag 12 juli 2022 01:47:21 CEST Adam Borowski wrote:
> > Pinebook Pro also wants this firmware, and it's definitely not a raspi,
> > and it doesn't have /boot/firmware either.
> 
> Is this about the /lib/firmware/brcm/brcmfmac434* files?
> 
> IMO, that group of files shouldn't be part of this package, but be moved to 
> another firmware package, perhaps firmware-brcm80211?

Yeah, that.

The idea of moving these files to another package seems good; steev proposed
firmware-linux, firmware-brcm80211 would be a more specific fit.
Both packages are maintained by debian-kernel@l.d.o, could you folks
comment please?


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ What kind of a drug are "base" and "red pill"?  I think acid is
⢿⡄⠘⠷⠚⠋⠀ LSD, which would make base... ?  Judging from the behaviour of
⠈⠳⣄ those "based and redpilled", something nasty.

Bug#993453: linux-image-5.13.0-trunk-riscv64: please enable CONFIG_NUMA on riscv64

[Adam Borowski]

Package: src:linux
Version: 5.13.12-1~exp1
Severity: wishlist
X-Debbugs-Cc: kilob...@angband.pl

Hi!
Please enable CONFIG_NUMA on riscv64.  The relevant code is there since
kernel 5.12.

While there's no physical hardware with multiple nodes that I know of yet,
the arch is meant to include big machines in the future as well.  As such,
it'd be a waste of our time to change packages multiple times -- let's put
riscv64 to the grown-up section of the arch pool quickly.

A package I maintain (memkind) requires the NUMA API (even if it returns
"1") to function and run tests.  Let's have such stuff working so the
software is in place before hardware comes.

I've tested on a self-built kernel (5.14 at this time), and all seems fine.


Meow!
-- Package-specific info:
** Model information
Device Tree model: SiFive HiFive Unmatched A00

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: riscv64
Foreign Architectures: amd64

Kernel: Linux 5.14.0-00033-gb0138dc69e0e (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#980813: linux-libc-dev: please ship nolibc.h

[Adam Borowski]

Package: linux-libc-dev
Version: 5.10.5-1
Severity: wishlist

Hi!
The kernel sources these days ship "nolibc.h", a stand-alone header that
defines all syscalls and hides away per-arch differences.  It's great for
writing programs in libc-less situations and/or writing an ad-hoc minimal
libc (and possibly eg. reducing 950KB /sbin/ldconfig to almost nothing).

Thus, could you please install this file?


Meow!
-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.11.0-rc4-00014-gc9b56d9c1053 (SMP w/64 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- no debconf information

Bug#960935: linux: please enable CONFIG_NUMA on sparc64

[Adam Borowski]

Source: linux
Severity: wishlist

Hi!
While discussing porting one of my packages to sparc64 (I wanted to
run its tests, requiring the NUMA API, at least on a single machine)
I was told that a lot of sparc64 machines in the wild have multiple
sockets.  Sparc architecture in general tends to have a lot of slow
CPUs, using many-way SMT and NUMA nodes.

As cross-socket accesses are in general a same-week service, it would
be a good idea to enable this API so programs can be aware of NUMA
setups.

Thus: could you please set CONFIG_NUMA=y on linux-image-sparc64-smp?


Meow!

Bug#940887: Integrate ZSTD patches *Kernel compression: add ZSTD, remove LZMA1 and BZIP2*

[Adam Borowski]

On Sat, Sep 21, 2019 at 04:00:55PM +0200, Paul Menzel wrote:
> Dear Linux folks,
> 
> 
> It’d be awesome, if you applied Adam’s and Nick’s patches for ZSTD support
> [1] to the Debian kernel, so users can test those early for the next Debian
> release.

> [1]: https://lore.kernel.org/patchwork/cover/1009317/

While adding the first part, ZSTD initrd and image, might be plausible,
cleanup like the rest of the patchset is right out.

I guess it's a time to resubmit the patchset upstream... except that we're
right in the middle of the merge window.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.

Bug#901492: Bug#901134: RFS: anbox-modules/0.0~git20180608-1 [ITP]

[Adam Borowski]

On Fri, Jun 22, 2018 at 06:04:14PM +0100, Ben Hutchings wrote:
> I needed to make some small changes to build them as modules.  The next
> upload using Linux 4.17 should include ashmem_linux and binder_linux
> modules for amd64, arm64 and armhf.

I looked at it, and it seemed like making the mainline version of ashmem
build as a module would indeed take only small changes.  I did not have the
time to actually do it, and it sounds like Ben just has done so.

The driver is in staging/ thus perhaps you could push the patch gregkh's
way?  This would help people who use vanilla kernels.

Binder is already module-capable.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ There's an easy way to tell toy operating systems from real ones.
⣾⠁⢰⠒⠀⣿⡁ Just look at how their shipped fonts display U+1F52B, this makes
⢿⡄⠘⠷⠚⠋⠀ the intended audience obvious.  It's also interesting to see OSes
⠈⠳⣄ go back and forth wrt their intended target.

Re: Bug#865153: reportbug: please include kernel taint flags

[Adam Borowski]

On Sun, Jun 17, 2018 at 03:17:38PM -0400, Sandro Tosi wrote:
> On Mon, Jun 19, 2017 at 12:48 PM Adam Borowski  wrote:
> > [Add kernel taint state to reportbug]

> > The state can be read via /proc/sys/kernel/tainted which provides a decimal
> > integer value, with bits meaning the following:
> >
> >'P',/* TAINT_PROPRIETARY_MODULE */
> >'F',/* TAINT_FORCED_MODULE */
> >'S',/* TAINT_CPU_OUT_OF_SPEC */
> > [...]
> 
> this seems to be defined at
> https://github.com/torvalds/linux/blob/master/include/linux/kernel.h#L549
> which saw 2 lines added 2 months ago, and one 7 months ago (ok it's
> not much, as previous changes were 4 years ago, but still since you
> can install a custom kernel in stable, it means reportbug will not be
> able to report correct information). i'm kinda at uneasy to add the
> decoding of the bit string in reportbug if this will change often.

You can show unknown flags as bit numbers, that's somewhat unsightly but
conveys all required information.  I'd say the benefit of showing known
flags (ie, the vast majority of cases) is worth having to update the list
from time to time.
 
> i think it would be ok to have an external tool that could produce the
> tainted information parsing the header files and the tainted file, and
> then include this tool output in reportbug systems information
> section.

If you mean trying to get data from the locally installed kernel, this is
not going to work.  The mapping of bits to letters comes from a file that's
not exported in the headers -- and even if it was, unless you use dkms,
there's little point in installing headers for the exact kernel you have.

If you mean parsing the kernel's source at build time, that would work.
You need actual kernel source rather than just headers, though.

> adding debian-kernel@l.d.o to gather some of their insight on the matter too

I asked on OFTC/#kernelnewbies, was told that manual updates require so
little work that it's a waste to write any complex automated machinery.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ There's an easy way to tell toy operating systems from real ones.
⣾⠁⢰⠒⠀⣿⡁ Just look at how their shipped fonts display U+1F52B, this makes
⢿⡄⠘⠷⠚⠋⠀ the intended audience obvious.  It's also interesting to see OSes
⠈⠳⣄ go back and forth wrt their intended target.

Bug#863290: src:linux: no warning that btrfs RAID5/6 is buggered up

[Adam Borowski]

Package: src:linux
Version: 4.9.25-1
Severity: grave
Tags: patch

(Not sure what an appropriate severity is -- very likely total filesystem
loss screams "critical" but "please add a warning" might be even wishlist.)


Btrfs, while stable and reliable when using a subset of features, or at
least reasonable with some caveats on a bigger feature set, also includes a
couple of experimental eats-data-babies-and-kittens features.  The problem
is, (shouting warranted) THERE'S NO MENTION WHATSOEVER THEY'RE BROKEN!!!

One of those features, qgroups, notoriously causes bogus ENOSPC and kills
performance, but at least leaves data recoverable.

RAID5/6, not so.  It suffers from a number of both implementation and design
errors, resulting in frequent data loss.  Even worse, when such data loss
happens, in a good majority of cases you lose the whole filesystem.

Known implementation issues are mostly fixed in 4.12 (except for 32-bit
kernels which still insta-die the moment you say "scrub"), the design one
(write hole) will be harder to fix but is nowhere as nasty; because of
metadata write patterns, it is still likely to result in whole filesystem
loss but that's easily workable around -- btrfs supports different raid
levels for data-vs-metadata so an adventureous user might live with a
-draid5 -mraid1 profile.  On 4.12.

The last I checked, however, Stretch has kernel 4.9.

There's some discussion on the btrfs mailing list, but it is going quite
slowly; way too slow for a warning to filter past the usual channels
(mainline->GregKH->you) in time for Stretch.

It looks like there's a consensus that such a warning should live in the
kernel rather than userland -- on 4.12 64-bit -draid5/6 is already nowhere
as bad, it's very common to use new kernels on old userland.  This means my
beautiful fiery letters from
https://www.spinics.net/lists/linux-btrfs/msg60913.html will remain unused.

There's no config setting to disable RAID5/6, such a setting would also make
it hard to migrate to supported raid levels as you need to mount rw in order
to convert.  And, you really hate non-trivial divergences from upstream.

A proposed warning patch attached.


-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.12.0-rc1-debug-00011-gb82803d91ae5 (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
>From 5ce4e611eab1a451332e0745ee91f787057e929b Mon Sep 17 00:00:00 2001
From: Adam Borowski <kilob...@angband.pl>
Date: Tue, 28 Mar 2017 16:55:05 +0200
Subject: [PATCH] btrfs: warn about RAID5/6 being experimental at mount time

Too many people come complaining about losing their data -- and indeed,
there's no warning outside a wiki and the mailing list tribal knowledge.
Message severity chosen for consistency with XFS -- "alert" makes dmesg
produce nice red background which should get the point across.

Signed-off-by: Adam Borowski <kilob...@angband.pl>
---
 fs/btrfs/disk-io.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 8685d67185d0..6aad1110602e 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -3068,6 +3068,14 @@ int open_ctree(struct super_block *sb,
btrfs_set_opt(fs_info->mount_opt, SSD);
}
 
+   if ((fs_info->avail_data_alloc_bits |
+fs_info->avail_metadata_alloc_bits |
+fs_info->avail_system_alloc_bits) &
+   BTRFS_BLOCK_GROUP_RAID56_MASK) {
+   btrfs_alert(fs_info,
+   "btrfs RAID5/6 is EXPERIMENTAL and has known data-loss bugs");
+   }
+
/*
 * Mount does not set all options immediately, we can do it now and do
 * not have to wait for transaction commit
-- 
2.11.0

Bug#849474: consolation and kernel issue

[Adam Borowski]

On Wed, Dec 28, 2016 at 09:29:11AM +0100, Adam Borowski wrote:
> However, all my testing so far was on vgacon (because nvidia).  When on
> nouveau, it locks up immediately, after 6 iterations.  Tried on 4.10-rc1+
> (current linus/master).
> 
> Same on a crap armhf laptop using 3.0 vendor kernel, proprietary mali
> module.  Like nouveau, that's some kind of graphical console.
> 
> It's possible it's not a matter of console driver but screen size; however,
> some vandal removed svgatextmode and snapshot.d.o is down, so I can't test
> that right now (assuming svgatextmode would compile...).

... and looks like it's screen size after all.

Can't use svgatextmode to resize vgacon anymore, but it's possible to change
font size on (fb/etc)con.  No idea how to change the resolution these days,
biggest font available is 32x16 -- on 1280x1024 (my monitors) this gives
80x32, on 1280x800 (the armhf laptop) 80x25 (spot on!).

80x32, nouveau, 4.10-rc1+: all is fine.  Resize back: stuck process sleeping
on paste_, once killed it starts taking 100% CPU; otherwise the system
is working.

80x25, mali, 3.0: somehow paste still gets stuck but ^C kills it cleanly,
the process goes away.  Resize back: the reproducer locks up the kernel
dead, can switch VTs and get keyboard echo in canon mode but nothing else
(I got no working serial/USB/netconsole for that laptop).


Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

Bug#849474: consolation and kernel issue

[Adam Borowski]

On Wed, Dec 28, 2016 at 12:50:20AM +0100, Bill Allombert wrote:
> On Wed, Dec 28, 2016 at 12:42:33AM +0100, Adam Borowski wrote:
> > On Tue, Dec 27, 2016 at 10:22:34PM +0100, Bill Allombert wrote:
> > > This can be automated using the attached program
> > > (warning, this is slightly dangerous since it copy-paste dummy text to
> > > the console, be careful. It is safer to use it in a X terminal since then
> > > the pasted text is sent to the underlying VT which is disabled, but it
> > > is less reliable)
> > 
> > My naive attempts to reproduce it on recent kernels have so far failed.
> 
> Thanks!
> 
> I do not know whether this is a good or bad thing :)
> 
> Try to switch VT while the program is running.

Still no badness on vgacon.  On 4.9 and 4.10-rc1+ it survives a long time of
running your reproducer, no matter what VT I'm on.

However, all my testing so far was on vgacon (because nvidia).  When on
nouveau, it locks up immediately, after 6 iterations.  Tried on 4.10-rc1+
(current linus/master).

Same on a crap armhf laptop using 3.0 vendor kernel, proprietary mali
module.  Like nouveau, that's some kind of graphical console.

It's possible it's not a matter of console driver but screen size; however,
some vandal removed svgatextmode and snapshot.d.o is down, so I can't test
that right now (assuming svgatextmode would compile...).


Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

Bug#849474: consolation and kernel issue

[Adam Borowski]

On Tue, Dec 27, 2016 at 10:22:34PM +0100, Bill Allombert wrote:
> This can be automated using the attached program
> (warning, this is slightly dangerous since it copy-paste dummy text to
> the console, be careful. It is safer to use it in a X terminal since then
> the pasted text is sent to the underlying VT which is disabled, but it
> is less reliable)

My naive attempts to reproduce it on recent kernels have so far failed.

-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

Re: [RFC, PATCH, v3.9] default exported asm symbols to zero

[Adam Borowski]

On Fri, Dec 02, 2016 at 01:40:27PM +0100, Arnd Bergmann wrote:
> With binutils-2.16 and before, a weak missing symbol was kept during the
> final link, and a missing CRC for an export would lead to that CRC
> being treated as zero implicitly. With binutils-2.17, the crc
> symbol gets dropped, and any module trying to use it will fail to
> load.
> 
> This sets the weak CRC symbol to zero explicitly, making it defined
> in vmlinux, which in turn lets us load the modules referring to
> that CRC.
> 
> The comment above the __CRC_SYMBOL macro suggests that this was
> always the intention, although it also seems that all symbols
> defined in C have a correct CRC these days, and only the exports
> that are now done in assembly need this.
> 
> Signed-off-by: Arnd Bergmann 
> ---

Looks good, works for me, and, unlike faaae2a5, doesn't produce a nasty
user-scaring warning in normal operation.

> diff --git a/include/asm-generic/export.h b/include/asm-generic/export.h
> index 63554e9..59a3b2f 100644
> --- a/include/asm-generic/export.h
> +++ b/include/asm-generic/export.h
> @@ -54,6 +54,7 @@ KSYM(__kstrtab_\name):
>  KSYM(__kcrctab_\name):
>   __put KSYM(__crc_\name)
>   .weak KSYM(__crc_\name)
> + .set KSYM(__crc_\name), 0
>   .previous
>  #endif
>  #endif

-- 
The bill declaring Jesus as the King of Poland fails to specify whether
the addition is at the top or end of the list of kings.  What should the
historians do?

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

[Adam Borowski]

On Fri, Dec 02, 2016 at 02:07:46AM +, Ben Hutchings wrote:
> Thanks for this; I've applied it to the master branch for Debian. 

Cool!

Alas, it is enough only for x86.

The merge that caused these issues was 84d6984 (pulling in
22823ab4^..590abbdd), you can see it does the same to a number of other
archs.  These are:
x86 alpha m68k s390 arm ppc sparc ia64
Mainline does include fixes for ppc and arm.

For extant Debian architectures this means these need to be checked:
* first class: s390x
* second class: alpha m68k sparc64

Second-class ports don't care that much for stable kernels as they don't
have stables, thus waiting for whatever comes up in 4.10 might be an option,
but porters deserve a heads-up at the very least.

This leaves s390x.  I don't happen to own a s390 machine, porterboxes are no
good for testing module loading, I hear setting it up on qemu-system is not
trivial.  Ben, I don't imagine you not having some kind of a test setup --
could you check whether modules load with CONFIG_MODVERSIONS=y?  It's not
the kind of problem we'd want to face even in unstable.

As for archs not on the above list, I've checked[1] that at least arm64
appears to work fine as of v4.9-rc7.

> After comparing all the symbols potentially exported from assembly with
> those declared in asm-prototypes.h, I found that cmpxchg8b_emu is
> missing.  This is only defined when building for 486 so it doesn't
> affect Debian, but you may want to add that if you resubmit this
> upstream.

Thanks for noticing!  I looked at, and tested, only amd64 -- and 486 are not
exactly in wide use anymore.


Meow!

[1]. For the values of "checked" of: built it on unstable on Pine64 (my only
arm64 machine, a crap little SoC that's not mainlined yet -- Icenowy's
patch set allows running modern kernels) and loaded a bunch of random
modules.
-- 
The bill declaring Jesus as the King of Poland fails to specify whether
the addition is at the top or end of the list of kings.  What should the
historians do?

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

[Adam Borowski]

On Tue, Nov 29, 2016 at 07:27:12AM -0800, Linus Torvalds wrote:
> On Nov 29, 2016 5:51 AM, "Adam Borowski" <kilob...@angband.pl> wrote:
> > >
> > >  (a) tested
> >
> > By many people.
> 
> No.
> 
> I've tested the build *without* this, and it works fine.

Michal mentioned "why", let's try "where".

I have no idea what setup is required to trigger the problem, but here's a
simple sufficient one:

Current Debian unstable, amd64.
git reset --hard v4.9-rc7
git revert cd3caefb
make defconfig
CONFIG_MODVERSIONS=y
(in my case) CONFIG_BTRFS_FS=y (so I can boot)
enable a module for testing, I used CONFIG_EXT4_FS=m
make bindeb-pkg
dpkg -i linux-image_X.deb

modprobe ext4
[   63.779490] jbd2: no symbol version for memcpy
[   63.779492] jbd2: Unknown symbol memcpy (err -22)
[   63.779550] jbd2: no symbol version for phys_base
[   63.779551] jbd2: Unknown symbol phys_base (err -22)
[   63.779561] jbd2: no symbol version for memset
[   63.779562] jbd2: Unknown symbol memset (err -22)

Not sure which piece of toolchain matters here, someone said binutils.
In that case, Fedora ships 2.26.1-1.fc25, they were frozen so couldn't
update.  Debian is at 2.27.51.20161127-1, Gentoo at 2.27, same for Arch,
OpenSUSE; Ubuntu at 2.27.51.20161124-1.

Thus, if it's indeed binutils, you'll see the breakage as soon as Fedora
recovers from the freeze.


Meow!
-- 
The bill declaring Jesus as the King of Poland fails to specify whether
the addition is at the top or end of the list of kings.  What should the
historians do?

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

[Adam Borowski]

On Tue, Nov 29, 2016 at 02:29:54PM +0100, Ingo Molnar wrote:
> * Adam Borowski <kilob...@angband.pl> wrote:
> 
> > Here's some history:
> > The day of -rc1, multiple people immediately reported the breakage; it was
> > quickly found out that reverting 784d5699eddc fixes it.  A "going forward"
> > patch has been posted but was insufficient; when the real devs went to bed
[...]
> > For some reason the per-arch pieces were excluded; I was instructed
> > to send my part to x86 maintainers.
> > 
> > I did so; the patch later got a better description by Nick and a bunch of
> > Tested-by -- but alas, nary a comment or action from x86 guys, despite
> > pings/resends (last one: https://lkml.org/lkml/2016/11/23/706).  I guess I'm
> > lacking the secret handshake or something -- thus, it looks like it's my
> > fault, the rest of you can be blamed mostly for letting a
> > not-a-real-kernel-dev unsupervised.
> 
> My part of the story is easy to explain: the reason I skipped the 11/23 patch 
> was 
> because it was tagged 'kbuild' and because the commit that broke it was never 
> acked by (or was upstreamed via) the x86 maintainers - we never upstreamed 
> any 
> modversions changes in the past AFAIR - so I assumed it would be handled via 
> whatever path got the breakage upstream (turns out it was via the VFS tree?),
> or via the kbuild tree.

The problematic merge was 84d6984 (it brought in 22823ab4^..590abbdd).
Interesting commits have "$ARCH: move exports to definitions" in their
subjects, they indeed did not go through arch trees.

> > On Nov 24 finally Ingo responded, the discussion ended with you marking 
> > modversions as BROKEN.
> 
> Yeah, that was when my internal timer ran out: modversions breakage was 
> reported 
> against -rc1 already and it still wasn't working (a seemingly working kernel 
> build 
> resulted in an unbootable system) - due to the timeline and confusion you 
> explained.
> 
> I totally agree with marking it BROKEN: it was the simplest, most robust way 
> to 
> fix it and nobody seemed to be owning the modversions feature.

Per Ben Hutchings' objection, it doesn't look like BROKEN is an option at
least for 4.9 -- even if mainline leaves it as is, distro maintainers would
need to do the work themselves.

Architectures that look like they could be affected:
x86 alpha m68k s390 arm ppc sparc ia64
(this list might be incomplete!).

Of these, ppc and arm are already fixed, x86 is in this thread,
arm64 is not on the list which explains why it works for me.  No idea about
the rest.


Meow!
-- 
The bill declaring Jesus as the King of Poland fails to specify whether
the addition is at the top or end of the list of kings.  What should the
historians do?

[PATCH] x86/kbuild: enable modversions for symbols exported from asm

[Adam Borowski]

Commit 4efca4ed ("kbuild: modversions for EXPORT_SYMBOL() for asm") adds
modversion support for symbols exported from asm files. Architectures
must include C-style declarations for those symbols in asm/asm-prototypes.h
in order for them to be versioned.

Add these declarations for x86, and an architecture-independent file that
can be used for common symbols.

User impact: kernels may fail to load modules at all when
CONFIG_MODVERSIONS=y.

Signed-off-by: Adam Borowski <kilob...@angband.pl>
Tested-by: Kalle Valo <kv...@codeaurora.org>
Acked-by: Nicholas Piggin <npig...@gmail.com>
Tested-by: Peter Wu <pe...@lekensteyn.nl>
Tested-by: Oliver Hartkopp <socket...@hartkopp.net>
---

> So somebody send me a minimal patch that is
>
>  (a) tested

By many people.

>  (b) explains it

The actual logic is in 4efca4ed0.  It wants C prototypes defined in
asm/asm-prototypes.h that lists symbols defined in assembly -- genksyms
knows only how to read C code.

>  (c) obvious

To be honest I don't quite understand what's the real gain over code that
was removed by 784d5699eddc, this mostly brings the symbols back.  But
that's for people wiser than me to explain.

> and I'll happily re-enable modversions.


The powerpc counterpart to this patch is in mainline as 9e5f688, although a
file by that name already existed.

As for arm, it looks like it was handled the other way by 8478132.


diff --git a/arch/x86/include/asm/asm-prototypes.h 
b/arch/x86/include/asm/asm-prototypes.h
new file mode 100644
index 000..ae87224
--- /dev/null
+++ b/arch/x86/include/asm/asm-prototypes.h
@@ -0,0 +1,12 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
diff --git a/include/asm-generic/asm-prototypes.h 
b/include/asm-generic/asm-prototypes.h
new file mode 100644
index 000..df13637
--- /dev/null
+++ b/include/asm-generic/asm-prototypes.h
@@ -0,0 +1,7 @@
+#include 
+extern void *__memset(void *, int, __kernel_size_t);
+extern void *__memcpy(void *, const void *, __kernel_size_t);
+extern void *__memmove(void *, const void *, __kernel_size_t);
+extern void *memset(void *, int, __kernel_size_t);
+extern void *memcpy(void *, const void *, __kernel_size_t);
+extern void *memmove(void *, const void *, __kernel_size_t);
-- 
2.10.2

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

[Adam Borowski]

On Mon, Nov 28, 2016 at 08:08:57PM -0800, Linus Torvalds wrote:
> On Mon, Nov 28, 2016 at 5:15 PM, Ben Hutchings  wrote:
> >>
> >> The modversions stuff may just be too painful to bother with. Very few
> >> people probably use it, and the ones that do likely don't have any
> >> overriding reason why.
> > [...]
> >
> > Debian has some strong reasons:
> 
> Honestly, I'd just like to see actual real patches from people who
> care about this.
> 
> The reason I disabled it entirely was simply that the discussions had
> been going on forever, but nobody actually seemed to care enough to
> just fix the damn thing. There was all the _noise_ about "look, here's
> a patch", but nothing got sent to maintainers and actually actively
> pushed as a "this fixes a regression".

Here's some history:
The day of -rc1, multiple people immediately reported the breakage; it was
quickly found out that reverting 784d5699eddc fixes it.  A "going forward"
patch has been posted but was insufficient; when the real devs went to bed
the last message was
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1250370.html
which ends with instructions and "Care to do a patch for x86?".

Then a random person (me) did the legwork, gathered affected symbols, wrote
and tested the x86 patch.  It was then tested by multiple people; Arnd
Bergmann wrote the ARM equivalent.  Whenever a new lkml thread reporting the
breakage popped up, we pointed people to the patches and everyone was happy.
As for upstreaming, there was a delay because Michal Marek was on vacation.

Michal returned and sent you the pull request, you merged it as 04e36857 on
Nov 18.  For some reason the per-arch pieces were excluded; I was instructed
to send my part to x86 maintainers.

I did so; the patch later got a better description by Nick and a bunch of
Tested-by -- but alas, nary a comment or action from x86 guys, despite
pings/resends (last one: https://lkml.org/lkml/2016/11/23/706).  I guess I'm
lacking the secret handshake or something -- thus, it looks like it's my
fault, the rest of you can be blamed mostly for letting a
not-a-real-kernel-dev unsupervised.

On Nov 24 finally Ingo responded, the discussion ended with you marking
modversions as BROKEN.


> So somebody send me a minimal patch that is
> 
>  (a) tested
>  (b) explains it
>  (c) obvious
> 
> and I'll happily re-enable modversions.

Not sure whether you guys want to revert or to go forward.  If the latter,
my piece handles x86, Arnd's ARM.  Powerpc already has the needed bits in
mainline.  I've just tried arm64 -- despite same toolchain versions as
failing x86, with CONFIG_MODVERSIONS=y it loaded a bunch of modules fine so
it appears no arch bits are needed there.  My uneducated guess is that most
other architectures should be fine without special handling, too.  It'd be
nice if someone with an actual clue could confirm.


Meow!
-- 
The bill declaring Jesus as the King of Poland fails to specify whether
the addition is at the top or end of the list of kings.  What should the
historians do?

Bug#841240: similar issue on 4.9-rc1

[Adam Borowski]

Lemme add: there's a similar, more serious issue on 4.9-rc1.  x32 processes
fail not just on preadv but on apparently any startup of something linked
with glibc (although at least _exit() and write() do work).

I haven't yet had the tuits to bisect or debug what's the cause.

-- 
A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg
raspberries, 0.4kg sugar; put into a big jar for 1 month.  Filter out and
throw away the fruits (can dump them into a cake, etc), let the drink age
at least 3-6 months.

Bug#778212: closed by Ben Hutchings b...@decadent.org.uk

[Adam Borowski]

On Thu, Feb 12, 2015 at 05:21:14PM +, Debian Bug Tracking System wrote:
 This is an automatic notification regarding your Bug report
 which was filed against the src:linux package:
 
 #778212: linux: please build the kernel and udebs on x32
 
 It has been closed by Ben Hutchings b...@decadent.org.uk.

 No, you need to make the installer use the amd64 packages for this.

1. d-i cannot currently use packages from a foreign architecture (same
applies for example to i386 on non-ancient hardware)

2. neither can it use udebs (needed to boot d-i itself)

3. amd64 kernels currently have x32 syscalls disabled unless a special
argument is passed on the command line.  This is fragile, especially if
fancy combinations of bootloader with preseeding are involved.


I'm not going to force reopen this, as you know more about Debian kernel
packaging than me (duh), but at least in my unofficial x32 release I'm going
to use kernel+udebs with this patch, unless you can enlighten me.  Would you
please elaborate a bit about what do I understand wrong?  And what the plans
for foreign kernels in d-i are?

-- 
// If you believe in so-called intellectual property, please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150212210808.ga19...@angband.pl

Bug#778212: linux: please build the kernel and udebs on x32

[Adam Borowski]

Source: linux
Version: 3.16.7-ckt4-3
Severity: wishlist
Tags: d-i patch
User: debian-...@lists.debian.org
Usertags: port-x32 di-x32

Hi!  Long ago, when the x32 port started, the linux package on that
architecture got limited to just kernel-derived libc headers.  That made
sense when neither grub nor the installer were ported.  However, that's the
case no more and we need actual kernels.  X32-capable grub is in the
archive, well-tested on crossgraded systems using self-built kernels.
Debian-installer, however, needs udebs that come from the src:linux build 
machinery.

Please apply the attached patch.
   
If you want to see it in action, you can use d-i images available at
http://debian-x32.org/#debian-installer; these have been tested so far on
qemu-kvm (BIOS, EFI), virtualbox (BIOS) and one real box (BIOS). 


-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (600, 'unstable'), (500, 'unreleased'), (50, 'experimental')
Architecture: x32 (x86_64)

Kernel: Linux 3.19.0-x32 (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
diff -Nru linux-3.16.7-ckt2/debian/config/x32/config linux-3.16.7-ckt2/debian/config/x32/config
--- linux-3.16.7-ckt2/debian/config/x32/config	1970-01-01 01:00:00.0 +0100
+++ linux-3.16.7-ckt2/debian/config/x32/config	2014-12-13 14:41:06.0 +0100
@@ -0,0 +1,2 @@
+CONFIG_X86_X32=y
+CONFIG_X86_X32_DISABLED=n
diff -Nru linux-3.16.7-ckt2/debian/config/x32/defines linux-3.16.7-ckt2/debian/config/x32/defines
--- linux-3.16.7-ckt2/debian/config/x32/defines	2014-09-08 06:58:04.0 +0200
+++ linux-3.16.7-ckt2/debian/config/x32/defines	2014-12-13 14:43:54.0 +0100
@@ -1,4 +1,26 @@
 [base]
-kernel-arch: x86
 featuresets:
-# empty; x32 must be part of a multiarch installation with an amd64 kernel
+ none
+ rt
+kernel-arch: x86
+
+[build]
+debug-info: true
+image-file: arch/x86/boot/bzImage
+
+[image]
+bootloaders: grub-pc grub-efi extlinux
+configs:
+install-stem: vmlinuz
+
+[relations]
+headers%gcc-4.8: linux-compiler-gcc-4.8-x86
+
+[amd64_description]
+hardware: 64-bit PCs
+hardware-long: PCs with AMD64, Intel 64 or VIA Nano processors
+
+[amd64_image]
+configs:
+ kernelarch-x86/config-arch-64
+ x32/config
diff -Nru linux-3.16.7-ckt2/debian/config/x32/none/defines linux-3.16.7-ckt2/debian/config/x32/none/defines
--- linux-3.16.7-ckt2/debian/config/x32/none/defines	1970-01-01 01:00:00.0 +0100
+++ linux-3.16.7-ckt2/debian/config/x32/none/defines	2014-09-08 06:58:03.0 +0200
@@ -0,0 +1,10 @@
+[base]
+flavours:
+ amd64
+
+[amd64_description]
+parts: xen
+
+[amd64_xen]
+flavours:
+ amd64
diff -Nru linux-3.16.7-ckt2/debian/config/x32/rt/defines linux-3.16.7-ckt2/debian/config/x32/rt/defines
--- linux-3.16.7-ckt2/debian/config/x32/rt/defines	1970-01-01 01:00:00.0 +0100
+++ linux-3.16.7-ckt2/debian/config/x32/rt/defines	2014-09-08 06:58:03.0 +0200
@@ -0,0 +1,3 @@
+[base]
+flavours:
+ amd64
diff -Nru linux-3.16.7-ckt2/debian/installer/x32/kernel-versions linux-3.16.7-ckt2/debian/installer/x32/kernel-versions
--- linux-3.16.7-ckt2/debian/installer/x32/kernel-versions	1970-01-01 01:00:00.0 +0100
+++ linux-3.16.7-ckt2/debian/installer/x32/kernel-versions	2014-12-13 18:43:59.0 +0100
@@ -0,0 +1,2 @@
+# arch version flavour installedname suffix build-depends
+x32  -   amd64   - -  -
diff -Nru linux-3.16.7-ckt2/debian/installer/x32/modules/x32/acpi-modules linux-3.16.7-ckt2/debian/installer/x32/modules/x32/acpi-modules
--- linux-3.16.7-ckt2/debian/installer/x32/modules/x32/acpi-modules	1970-01-01 01:00:00.0 +0100
+++ linux-3.16.7-ckt2/debian/installer/x32/modules/x32/acpi-modules	2014-09-08 06:58:01.0 +0200
@@ -0,0 +1,2 @@
+#include acpi-modules
+
diff -Nru linux-3.16.7-ckt2/debian/installer/x32/modules/x32/ata-modules linux-3.16.7-ckt2/debian/installer/x32/modules/x32/ata-modules
--- linux-3.16.7-ckt2/debian/installer/x32/modules/x32/ata-modules	1970-01-01 01:00:00.0 +0100
+++ linux-3.16.7-ckt2/debian/installer/x32/modules/x32/ata-modules	2014-09-08 06:58:01.0 +0200
@@ -0,0 +1,2 @@
+#include ata-modules
+
diff -Nru linux-3.16.7-ckt2/debian/installer/x32/modules/x32/btrfs-modules linux-3.16.7-ckt2/debian/installer/x32/modules/x32/btrfs-modules
--- linux-3.16.7-ckt2/debian/installer/x32/modules/x32/btrfs-modules	1970-01-01 01:00:00.0 +0100
+++ linux-3.16.7-ckt2/debian/installer/x32/modules/x32/btrfs-modules	2014-09-08 06:58:01.0 +0200
@@ -0,0 +1 @@
+#include btrfs-modules
diff -Nru linux-3.16.7-ckt2/debian/installer/x32/modules/x32/cdrom-core-modules linux-3.16.7-ckt2/debian/installer/x32/modules/x32/cdrom-core-modules
--- linux-3.16.7-ckt2/debian/installer/x32/modules/x32/cdrom-core-modules	1970-01-01 01:00:00.0 +0100
+++ 

Bug#502346: please rebuild against virtualbox-ose-source in lenny/sid

[Adam Borowski]

On Thu, Oct 23, 2008 at 03:17:34PM +0200, Bastian Blank wrote:
 On Wed, Oct 22, 2008 at 11:49:25PM +0200, Adam Borowski wrote:
  Except, the prebuilt module doesn't work for the version of virtualbox
  in Lenny.  Since that is this package's sole purpose, that makes it useless.
 
 Please explain.

It's not a problem between   kernel = the module.
It's one between the module = virtualbox.

The interface between these two has changed.  You can use the module just
fine if you have an old version of vbox -- just not the one in Lenny (nor
the one in Etch).

Akin to library transitions, all that is needed is a rebuild.  It may be a
good idea to add a Conflicts: virtualbox-ose (1.6.6) -- I'm not sure if a
normal dependency would be the right thing for a kernel module.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#502346: please rebuild against virtualbox-ose-source in lenny/sid

[Adam Borowski]

reopen 502346
kthxbye

 as the message says - /either/ install the prebuilt module, /or/ build
 it yourself with m-a.

Except, the prebuilt module doesn't work for the version of virtualbox
in Lenny.  Since that is this package's sole purpose, that makes it useless.

(Nitpicking, it does have some use if you fetch/hold a virtualbox package
that used to be in unstable at some time between etch and lenny, but even in
such contrived use case, it would need to conflict with lenny's virtualbox.)


Please rebuild it against current virtualbox-ose-source.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#498134: (no subject)

[Adam Borowski]

Package: linux-image-2.6.26-1-vserver-686
Version: 2.6.26-4
Severity: important

It appears that copy-on-write links don't always work, sometimes resulting
in a lock up.  They are supposed to work this way:

echo foo a
ln a b
setattr --iunlink a
# Now both files are immutable but will break away on a write attempt.
echo bar a
# The files should be separated now...

Alas, this is not enough to reproduce.


-- Package-specific info:
** Version:
Linux version 2.6.26-1-vserver-686 (Debian 2.6.26-4) ([EMAIL PROTECTED]) (gcc 
version 4.1.3 20080623 (prerelease) (Debian 4.1.2-23)) #1 SMP Thu Aug 28 
15:12:13 UTC 2008

** Not tainted

** Kernel log:
[478478.685620] INFO: task bash:15850 blocked for more than 120 seconds.
[478478.685651] echo 0  /proc/sys/kernel/hung_task_timeout_secs disables 
this message.
[478478.685687] bash  D e7af588b 0 15850  15848
[478478.685714]f79d0140 0082 7fff e7af588b 0001952e f79d02cc 
c180c140 
[478478.685761]f741da80 dcbdfdf4 0002  dcbdfdf4  
e8524fe9 ee65bb44
[478478.685820]ed859e60 ed859e68 ed859e64 f79d0140 c02ec62c d99e5e0c 
ed859e68 f79d0140
[478478.685878] Call Trace:
[478478.685958]  [c02ec62c] __mutex_lock_slowpath+0x50/0x7b
[478478.686002]  [c02ec4c2] mutex_lock+0xa/0xb
[478478.689522]  [c01849d4] lookup_create+0x14/0x75
[478478.690491]  [c01867dc] cow_break_link+0xd3/0x3f9
[478478.690491]  [f8b7d9e6] jfs_permission+0x0/0xa [jfs]
[478478.690491]  [c0183c9a] permission+0x1ff/0x239
[478478.690491]  [c01858cb] __link_path_walk+0xa9d/0xb7f
[478478.690491]  [c011a636] __wake_up+0x29/0x39
[478478.690491]  [c019078e] mntput_no_expire+0x13/0xd9
[478478.690491]  [c0185a14] path_walk+0x67/0x70
[478478.690491]  [c018c973] __d_lookup+0x98/0xf6
[478478.690491]  [c0183859] __lookup_hash+0x3c/0xdf
[478478.690491]  [c0186e47] do_filp_open+0x345/0x6d3
[478478.690491]  [c0132616] remove_wait_queue+0xc/0x34
[478478.690491]  [c022da7c] tty_ldisc_deref+0x4c/0x5b
[478478.690491]  [c017b726] do_sys_open+0x40/0xb0
[478478.690491]  [c017b7da] sys_open+0x1e/0x23
[478478.690491]  [c0103853] sysenter_past_esp+0x78/0xb1
[478478.690491]  ===

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (501, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-vserver-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#382985: teergrubes NATted connections due to mangled IPv4 checksums

[Adam Borowski]

Package: linux-image-2.6.16-2-xen-686
Version: 2.6.16-17
Severity: grave

A recently added optimization skips checksums on all packets it
believes are destined for another Xen domain inside the same box.
Too bad, it is sometimes wrong -- an analysis can be found on
http://lists.xensource.com/archives/html/xen-users/2006-03/msg00159.html

This had been fixed before -- NETIF_F_NO_CSUM was changed to 0;
however, in the current version of the Xen patch in unstable it is
again enabled, set to NETIF_F_IP_CSUM (ie, IPv4 tcp and udp only) this
time.
Unfortunately, an idiot running nearly only IPv6 can miss this bug,
unknowingly teergrubing other hosts.  I've personally managed to do
this to lists.debian.org, making it keep a number of exim4 processes
trying to deliver mail to my server.  Thus, it was suggested to file
this bug as 'grave'.

IPv4 ICMP, all IPv6 and connections which actually don't leave the
box work fine; same for those which get bridged away to a physical
interface without passing through NAT.

The fix: as in the quoted link, change
  dev-features= NETIF_F_IP_CSUM;
to
  dev-features= 0;

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing'), (202, 'unstable'), (201, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-2-xen-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages linux-image-2.6.16-2-xen-686 depends on:
ii  initramfs-tools [linux-initra 0.73c  tools for generating an initramfs
ii  linux-modules-2.6.16-2-xen-68 2.6.16-17  Linux kernel modules 2.6.16 image

Versions of packages linux-image-2.6.16-2-xen-686 recommends:
ii  libc6-xen 2.3.6-19   GNU C Library: Shared libraries [X

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]