Linux 4.17

Linux 4.17

[Linus Torvalds]

So this last week was pretty calm, even if the pattern of most of the
stuff coming in on a Friday made it feel less so as the weekend
approached.

And while I would have liked even less changes, I really didn't get
the feeling that another week would help the release in any way, so
here we are, with 4.17 released.

No, I didn't call it 5.0, even though all the git object count
numerology was in place for that. It will happen in the not _too_
distant future, and I'm told all the release scripts on kernel.org are
ready for it, but I didn't feel there was any real reason for it. I
suspect that around 4.20 - which is I run out of fingers and toes to
keep track of minor releases, and thus start getting mightily confused
- I'll switch over. That was what happened for 4.0, after all.

As for the actual changes since rc7 - the shortlog is appended - it's
mostly drivers, networking, perf tooling, and a set of nds32 fixes.
With some random other stuff thrown in. Again, the shortlog is
obviously only the last calm week, the overall changes since 4.16 are
much too big to list in that format.

The big 4.17 stuff was mentioned in the rc1 email when the merge
window closed, but I guess it's worth repeating how 4.17 is actually a
slightly smaller kernel than 4.16, thanks to the removal of a number
of effectively dead architectures (blackfin, cris, frv, m32r, metag,
mn10300, score, and tile). Obviously all the other changes are much
more important, but it's always nice to see spring cleaning like that.

And with this, the merge window for 4.18 is obviously open. I actually
have some travel the second week of the merge window, which is very
inconvenient for me, but I do hope that we'll get all the big stuff
merged the first week and it won't impact any release scheduling. But
we'll have to see.

                      Linus


---

Aaron Ma (1):
      Input: synaptics - add Intertouch support on X1 Carbon 6th and X280

Al Viro (2):
      fix io_destroy()/aio_complete() race
      Revert "fs: fold open_check_o_direct into do_dentry_open"

Alex Williamson (1):
      Revert "vfio/type1: Improve memory pinning process for raw PFN mapping"

Alexander Duyck (1):
      net-sysfs: Fix memory leak in XPS configuration

Alexander Shishkin (2):
      stm class: Use vmalloc for the master map
      intel_th: Use correct device when freeing buffers

Antoine Tenart (1):
      crypto: inside-secure - do not use memset on MMIO

Ard Biesheuvel (1):
      net: netsec: reduce DMA mask to 40 bits

Arnaldo Carvalho de Melo (1):
      perf tools: Fix perf.data format description of NRCPUS header

Arnd Bergmann (1):
      IB: Revert "remove redundant INFINIBAND kconfig dependencies"

Bart Van Assche (1):
      scsi: scsi_transport_srp: Fix shost to rport translation

Benjamin Tissoires (2):
      Input: synaptics - add Lenovo 80 series ids to SMBus
      Input: elan_i2c_smbus - fix corrupted stack

Chris Wilson (3):
      drm/i915/lvds: Move acpi lid notification registration to
registration phase
      drm/i915/query: Protect tainted function pointer lookup
      drm/i915/query: nospec expects no more than an unsigned long

Damien Thébault (1):
      net: dsa: b53: Add BCM5389 support

Dan Carpenter (1):
      net: ethernet: davinci_emac: fix error handling in probe()

Daniel Borkmann (1):
      bpf: fix uapi hole for 32 bit compat applications

Daniele Palmas (1):
      net: usb: cdc_mbim: add flag FLAG_SEND_ZLP

Darrick J. Wong (1):
      fs: clear writeback errors in inode_init_always

David Francis (1):
      drm/amd/display: Make atomic-check validate underscan changes

David Howells (1):
      afs: Fix directory permissions check

Davidlohr Bueso (1):
      sched/headers: Fix typo

Devesh Sharma (1):
      RDMA/bnxt_re: Fix broken RoCE driver due to recent L2 driver changes

Dhinakaran Pandiyan (1):
      drm/psr: Fix missed entry in PSR setup time table.

Dmitry Torokhov (1):
      Input: synaptics - Lenovo Carbon X1 Gen5 (2017) devices should use RMI

Edvard Holst (1):
      Input: synaptics - Lenovo Thinkpad X1 Carbon G5 (2017) with
Elantech trackpoints should use RMI

Eric Dumazet (2):
      xfrm6: avoid potential infinite loop in _decode_session6()
      netfilter: provide correct argument to nla_strlcpy()

Eugen Hristev (2):
      iio: adc: at91-sama5d2_adc: fix channel configuration for
differential channels
      iio: adc: select buffer for at91-sama5d2_adc

Fabrice Gasnier (2):
      iio: adc: stm32-dfsdm: fix successive oversampling settings
      iio: adc: stm32-dfsdm: fix sample rate for div2 spi clock

Federico Vaga (1):
      i2c: ocores: update HDL sources URL

Finn Thain (1):
      net/sonic: Use dma_mapping_error()

George Cherian (1):
      i2c: xlp9xx: Add MAINTAINERS entry

Greentime Hu (12):
      nds32: lib: To use generic lib instead of libgcc to prevent the
symbol undefined issue.
      nds32: Fix building error when CONFIG_FREEZE is enabled.
      nds32: Fix building error of crypto/xor.c by adding xor.h
      nds32: Fix drivers/gpu/drm/udl/udl_fb.c building error by
defining PAGE_SHARED
      nds32: Fix xfs_buf built failed by export
invalidate_kernel_vmap_range and flush_kernel_vmap_range
      nds32: Fix the symbols undefined issue by exporting them.
      nds32: Fix the unknown type u8 issue.
      nds32: Fix build failed because arch_trace_hardirqs_off is
changed to trace_hardirqs_off.
      nds32: Fix the allmodconfig build. To make sure
CONFIG_CPU_LITTLE_ENDIAN is default y
      nds32: Fix the virtual address may map too much range by tlbop issue.
      nds32: To refine readability of INT_MASK_INITAIAL_VAL
      nds32: To fix a cache inconsistency issue by setting correct
cacheability of NTC

Greg Kroah-Hartman (1):
      hwtracing: stm: fix build error on some arches

Hans de Goede (1):
      iio: hid-sensor-trigger: Fix sometimes not powering up the
sensor after resume

Hao Wei Tee (1):
      iwlwifi: pcie: compare with number of IRQs requested for, not
number of CPUs

Hugh Dickins (2):
      mm/huge_memory.c: __split_huge_page() use atomic ClearPageDirty()
      mm: fix the NULL mapping case in __isolate_lru_page()

Ivan Bornyakov (1):
      atm: zatm: fix memcmp casting

Jason Wang (1):
      vhost_net: flush batched heads before trying to busy polling

Josh Hill (1):
      net: qmi_wwan: Add Netgear Aircard 779S

João Paulo Rechi Vita (1):
      platform/x86: asus-wmi: Fix NULL pointer dereference

Julian Anastasov (1):
      ipvs: fix buffer overflow with sync daemon and service

Juri Lelli (1):
      sched/deadline: Fix missing clock update

Kan Liang (1):
      perf parse-events: Handle uncore event aliases in small groups properly

Kirill Tkhai (1):
      kcm: Fix use-after-free caused by clonned sockets

Leo (Sunpeng) Li (2):
      drm/amd/display: Fix BUG_ON during CRTC atomic check update
      drm/amd/display: Update color props when modeset is required

Leo Yan (1):
      perf script python: Add addr into perf sample dict

Linus Torvalds (1):
      Linux 4.17

Maciej W. Rozycki (2):
      MIPS: prctl: Disallow FRE without FR with PR_SET_FP_MODE requests
      MIPS: ptrace: Fix PTRACE_PEEKUSR requests for 64-bit FGRs

Marc Dionne (1):
      afs: Fix mounting of backup volumes

Martin Kelly (2):
      iio:buffer: make length types match kfifo types
      iio:kfifo_buf: check for uint overflow

Mathias Kresin (1):
      MIPS: lantiq: gphy: Drop reboot/remove reset asserts

Mathieu Poirier (1):
      perf cs-etm: Fix indexing for decoder packet queue

Mathieu Xhonneux (1):
      ipv6: sr: fix memory OOB access in seg6_do_srh_encap/inline

Max Gurtovoy (1):
      nvme: fix extended data LBA supported setting

Michael Nosthoff (1):
      iio: ad7793: implement IIO_CHAN_INFO_SAMP_FREQ

Mika Westerberg (1):
      thunderbolt: Handle NULL boot ACL entries properly

Neil Armstrong (1):
      drm/bridge/synopsys: dw-hdmi: fix dw_hdmi_setup_rx_sense

Nickhu (2):
      nds32: Renaming the file for unaligned access
      nds32: Fix the unaligned access handler

Nicolas Dichtel (2):
      ip_tunnel: restore binding to ifaces with a large mtu
      ip6_tunnel: remove magic mtu value 0xFFF8

Ondrej Zary (1):
      drm/i915: Disable LVDS on Radiant P845

Ondřej Hlavatý (1):
      ixgbe: fix parsing of TC actions for HW offload

Pablo Neira Ayuso (2):
      netfilter: nft_limit: fix packet ratelimiting
      netfilter: nf_tables: disable preemption in nft_update_chain_stats()

Paolo Abeni (1):
      netfilter: ebtables: handle string from userspace with care

Parav Pandit (1):
      IB/core: Fix error code for invalid GID entry

Paul Blakey (1):
      cls_flower: Fix incorrect idr release when failing to modify rule

Paul Burton (1):
      sched/core: Require cpu_active() in select_task_rq(), for user tasks

Peter Zijlstra (1):
      sched/core: Fix rules for running on online && !active CPUs

Petr Machata (1):
      mlxsw: spectrum: Forbid creation of VLAN 1 over port/LAG

Philipp Rudo (1):
      s390/purgatory: Fix endless interrupt loop

Sachin Grover (1):
      selinux: KASAN: slab-out-of-bounds in xattr_getsecurity

Samuel Mendoza-Jonas (1):
      net/ncsi: Fix array size in dumpit handler

Sebastian Ott (1):
      s390/dasd: use blk_mq_rq_from_pdu for per request data

Stanislaw Gruszka (1):
      Revert "rt2800: use TXOP_BACKOFF for probe frames"

Steffen Klassert (1):
      xfrm Fix potential error pointer dereference in xfrm_bundle_create.

Steven Rostedt (VMware) (2):
      tracing: Fix crash when freeing instances with event triggers
      tracing: Make the snapshot trigger work with instances

Suresh Reddy (1):
      be2net: Fix error detection logic for BE3

Taehee Yoo (4):
      netfilter: nf_tables: fix NULL pointer dereference on
nft_ct_helper_obj_dump()
      netfilter: nft_meta: fix wrong value dereference in nft_meta_set_eval
      netfilter: nf_tables: fix NULL-ptr in nf_tables_dump_obj()
      netfilter: nf_tables: increase nft_counters_enabled in
nft_chain_stats_replace()

Thomas Richter (2):
      perf test: "Session topology" dumps core on s390
      perf data: Update documentation section on cpu topology

Tomi Valkeinen (1):
      drm/omap: fix NULL deref crash with SDI displays

Toshiaki Makita (1):
      tun: Fix NULL pointer dereference in XDP redirect

Vincent Chen (4):
      nds32: Correct flush_dcache_page function
      nds32: Flush the cache of the page at vmaddr instead of kaddr in
flush_anon_page
      nds32: Disable local irq before calling cpu_dcache_wb_page in
copy_user_highpage
      nds32: Fix compiler warning, Wstringop-overflow, in vdso.c

YueHaibing (1):
      perf bpf: Fix NULL return handling in bpf__prepare_load()

building in 32bit chroot on x86_64 host broken (was: Linux 4.17)

[Thomas Backlund]

I have a 32bit x86 and a 64bit x86_64 install on the system.

With linux source up to 4.16.x I could do:

setarch i686 (or use command linux32)
chroot /path/to/32bit/
(/dev, /proc, /sys, /run is bind mounted in the chroot)

Then I could build a 32bit kernel in the chroot without booting the 
32bit system...

(host is running a 4.14 longterm kernel)

but building from 4.17 source in the chroot I get:


$ uname -m
i686
$ make oldconfig
scripts/kconfig/conf  --oldconfig Kconfig
*
* Restart config...
*
*
* Linux/x86 4.17.0 Kernel Configuration
*
64-bit kernel (64BIT) [Y/n/?] (NEW)




So it does not pick up 32bit anymore ...

Is this intentional ? If so, why ? If not, how can I fix it ?

--
Thomas

Re: building in 32bit chroot on x86_64 host broken (was: Linux 4.17)

[Linus Torvalds]

On Tue, Jun 5, 2018 at 10:51 AM Thomas Backlund <tmb@mageia.org> wrote:
>
> Is this intentional ? If so, why ? If not, how can I fix it ?

It shouldn't be intentional. And I don't see anythin ghaving changed
in this area. We still have

  config 64BIT
        bool "64-bit kernel" if ARCH = "x86"
        default ARCH != "i386"

which is what it was in 4.16 too.

Of course, we also have (in the main Makefile)

  SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \

and

  ARCH            ?= $(SUBARCH)

so if you don't set ARCH explicitly, it will always translate "i686"
into "x86", so it will default to 64-bit.

None of this is new to 4.17, though. Are you sure you didn't use to
have an ARCH=i386 somewhere?

Because this works for me:

    make ARCH=i386 oldconfig

and it's how I have done cross-builds before (although honestly, I
don't do them very often).

But adding Masahiro to the cc in case he sees something I've missed.

Of course, doing a bisect on *when* it broke for you would be good
too. You don't need to actually build the kernel, you can just bisect
the configuration phase (and even automate it with "git bisect run" if
you want to).

                 Linus

Re: building in 32bit chroot on x86_64 host broken - IGNORE

[Thomas Backlund]

Den 2018-06-05 kl. 20:52, skrev Thomas Backlund:
> 
> I have a 32bit x86 and a 64bit x86_64 install on the system.
> 
> With linux source up to 4.16.x I could do:
> 
> setarch i686 (or use command linux32)
> chroot /path/to/32bit/
> (/dev, /proc, /sys, /run is bind mounted in the chroot)
> 
> Then I could build a 32bit kernel in the chroot without booting the 
> 32bit system...
> 
> (host is running a 4.14 longterm kernel)
> 
> but building from 4.17 source in the chroot I get:
> 
> 
> $ uname -m
> i686
> $ make oldconfig
> scripts/kconfig/conf  --oldconfig Kconfig
> *
> * Restart config...
> *
> *
> * Linux/x86 4.17.0 Kernel Configuration
> *
> 64-bit kernel (64BIT) [Y/n/?] (NEW)
> 
> 
> 
> 
> So it does not pick up 32bit anymore ...
> 
> Is this intentional ? If so, why ? If not, how can I fix it ?
> 


Never mind...

For some reason I seem to have lost this  in the .config update to 4.17:

# CONFIG_64BIT is not set


Re-adding it restores proper behaviour...

Sorry for the noise...

--
Thomas

Re: building in 32bit chroot on x86_64 host broken

[Thomas Backlund]

Den 2018-06-05 kl. 21:11, skrev Linus Torvalds:
> On Tue, Jun 5, 2018 at 10:51 AM Thomas Backlund <tmb@mageia.org> wrote:
>> Is this intentional ? If so, why ? If not, how can I fix it ?
> It shouldn't be intentional. And I don't see anythin ghaving changed
> in this area. We still have
>
>    config 64BIT
>          bool "64-bit kernel" if ARCH = "x86"
>          default ARCH != "i386"
>
> which is what it was in 4.16 too.
>
> Of course, we also have (in the main Makefile)
>
>    SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
>
> and
>
>    ARCH            ?= $(SUBARCH)
>
> so if you don't set ARCH explicitly, it will always translate "i686"
> into "x86", so it will default to 64-bit.
>
> None of this is new to 4.17, though. Are you sure you didn't use to
> have an ARCH=i386 somewhere?
>
> Because this works for me:
>
>      make ARCH=i386 oldconfig
>
> and it's how I have done cross-builds before (although honestly, I
> don't do them very often).
>
> But adding Masahiro to the cc in case he sees something I've missed.
>
> Of course, doing a bisect on *when* it broke for you would be good
> too. You don't need to actually build the kernel, you can just bisect
> the configuration phase (and even automate it with "git bisect run" if
> you want to).
>
>                   Linus


Taking back the earlier " IGNORE " part...

This happends on the 64bit host:

# make ARCH=i386 oldconfig

--- .config.old 2018-06-05 21:17:07.829954548 +0300
+++ .config     2018-06-05 21:17:43.367487580 +0300
@@ -1,8 +1,7 @@
  #
  # Automatically generated file; DO NOT EDIT.
-# Linux/i386 4.16.12 Kernel Configuration
+# Linux/i386 4.17.0 Kernel Configuration
  #
-# CONFIG_64BIT is not set




So something _does_ strip away the needed config bit

So any ideas, or should I start bisecting ?

--
Thomas

Re: building in 32bit chroot on x86_64 host broken

[Linus Torvalds]

On Tue, Jun 5, 2018 at 11:23 AM Thomas Backlund <tmb@mageia.org> wrote:
>   #
> -# CONFIG_64BIT is not set
>
> So something _does_ strip away the needed config bit

Why do you need it?

I get

  CONFIG_X86_32=y
  CONFIG_X86=y

and CONFIG_64BIT never gets set.

It is true that I don't get the

  # CONFIG_64BIT is not set

line, but why do you care?

            Linus

Re: building in 32bit chroot on x86_64 host broken

[Thomas Backlund]

Den 2018-06-05 kl. 21:38, skrev Linus Torvalds:
> On Tue, Jun 5, 2018 at 11:23 AM Thomas Backlund <tmb@mageia.org> wrote:
>>    #
>> -# CONFIG_64BIT is not set
>>
>> So something _does_ strip away the needed config bit
> Why do you need it?
>
> I get
>
>    CONFIG_X86_32=y
>    CONFIG_X86=y
>
> and CONFIG_64BIT never gets set.
>
> It is true that I don't get the
>
>    # CONFIG_64BIT is not set
>
> line, but why do you care?
>
>              Linus

Because without it running the build in the 32bit chroot will get the 
initial reported issue:


$ uname -m
i686
$ make oldconfig
scripts/kconfig/conf  --oldconfig Kconfig
*
* Restart config...
*
*
* Linux/x86 4.17.0 Kernel Configuration
*
64-bit kernel (64BIT) [Y/n/?] (NEW)


which breaks our buildbots running in chroots...


Now I can work around it by adding the config bit myself, but I'd like 
to understand what changed and why...

--
Thomas

Re: building in 32bit chroot on x86_64 host broken

[Linus Torvalds]

On Tue, Jun 5, 2018 at 11:50 AM Thomas Backlund <tmb@mageia.org> wrote:
> >
> > but why do you care?
>
> Because without it running the build in the 32bit chroot will get the
> initial reported issue:

Ahh. I can re-create that now.

Yes, doing

      make ARCH=i386 allnoconfig

followed by

      make oldconfig

is broken. And doing a trivial "git bisect run" to pinpoint where
CONFIG_64BIT goes away gives us

f467c5640c29ad258c3cd8186a776c82fc3b8057 is the first bad commit

which does that

  "kconfig: only write '# CONFIG_FOO is not set' for visible symbols"

and it turns out that CONFIG_64BIT is not a visible symbol on x86-32,
because that question is disabled when ARCH != "x86".

        bool "64-bit kernel" if ARCH = "x86"

And the problem with that, is that *next* time around this config file
is used, because we don't have that

  # CONFIG_64BIT is not set

line, we don't turn it into

  CONFIG_64BIT=n

and then the "depends on" in X86_64

  config X86_64
          def_bool y
          depends on 64BIT

no longer hides it.

Hmm. Ulf, Masahiro, comments?

Should we just revert that commit?

Thomas, can you verify that a

        git revert f467c5640c29ad258c3cd8186a776c82fc3b8057

fixes the problem for you?

              Linus

Re: building in 32bit chroot on x86_64 host broken

[Thomas Backlund]

Den 2018-06-05 kl. 22:13, skrev Linus Torvalds:
> On Tue, Jun 5, 2018 at 11:50 AM Thomas Backlund <tmb@mageia.org> wrote:
>>> but why do you care?
>> Because without it running the build in the 32bit chroot will get the
>> initial reported issue:
> Ahh. I can re-create that now.
>
> Yes, doing
>
>        make ARCH=i386 allnoconfig
>
> followed by
>
>        make oldconfig
>
> is broken. And doing a trivial "git bisect run" to pinpoint where
> CONFIG_64BIT goes away gives us
>
> f467c5640c29ad258c3cd8186a776c82fc3b8057 is the first bad commit
>
> which does that
>
>    "kconfig: only write '# CONFIG_FOO is not set' for visible symbols"
>
> and it turns out that CONFIG_64BIT is not a visible symbol on x86-32,
> because that question is disabled when ARCH != "x86".
>
>          bool "64-bit kernel" if ARCH = "x86"
>
> And the problem with that, is that *next* time around this config file
> is used, because we don't have that
>
>    # CONFIG_64BIT is not set
>
> line, we don't turn it into
>
>    CONFIG_64BIT=n
>
> and then the "depends on" in X86_64
>
>    config X86_64
>            def_bool y
>            depends on 64BIT
>
> no longer hides it.
>
> Hmm. Ulf, Masahiro, comments?
>
> Should we just revert that commit?
>
> Thomas, can you verify that a
>
>          git revert f467c5640c29ad258c3cd8186a776c82fc3b8057
>
> fixes the problem for you?
>
>                Linus

Yep, that fixes it so it works both  in the 32bit chroot and on the 
64bit host

--
Thomas

python errors in tools/testing/selftests/tc-testing (was: Linux 4.17)

[Thomas Backlund]

Compiling 
/usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/plugin-lib/rootPlugin.py 
...
   File 
"/usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/plugin-lib/rootPlugin.py", 
line 18
     print('This script must be run with root privileges', file=sys.stderr)
                                                               ^
SyntaxError: invalid syntax


Caused by:

commit f6926e85eee9be08d05170af3a2266b8d7f9cdef
Author: Brenda J. Butler <bjb@mojatatu.com>
Date:   Wed Feb 14 14:08:55 2018 -0500

     tools: tc-testing: rootPlugin

     Move the functionality that checks for root permissions into a plugin.



and:

Compiling 
/usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/tdc.py 
...
   File 
"/usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/tdc.py", 
line 167
     print('', file=sys.stderr)
                   ^
SyntaxError: invalid syntax


Caused by:

commit 93707cbabcc8baf2b2b5f4a99c1f08ee83eb7abd
Author: Brenda J. Butler <bjb@mojatatu.com>
Date:   Wed Feb 14 14:08:54 2018 -0500

     tools: tc-testing: Introduce plugin architecture





And this system has:

$ python3 -V
Python 3.5.3

$ python -V
Python 2.7.15


--

Thomas

Re: python errors in tools/testing/selftests/tc-testing - IGNORE

[Thomas Backlund]

Den 2018-06-05 kl. 23:10, skrev Thomas Backlund:
> Compiling 
> /usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/plugin-lib/rootPlugin.py 
> ...
>    File 
> "/usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/plugin-lib/rootPlugin.py", 
> line 18
>      print('This script must be run with root privileges', file=sys.stderr)
>                                                                ^
> SyntaxError: invalid syntax
> 
> 
> Caused by:
> 
> commit f6926e85eee9be08d05170af3a2266b8d7f9cdef
> Author: Brenda J. Butler <bjb@mojatatu.com>
> Date:   Wed Feb 14 14:08:55 2018 -0500
> 
>      tools: tc-testing: rootPlugin
> 
>      Move the functionality that checks for root permissions into a plugin.
> 
> 
> 
> and:
> 
> Compiling 
> /usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/tdc.py 
> ...
>    File 
> "/usr/src/kernel-linus-4.17.0-1.mga7/tools/testing/selftests/tc-testing/tdc.py", 
> line 167
>      print('', file=sys.stderr)
>                    ^
> SyntaxError: invalid syntax
> 
> 
> Caused by:
> 
> commit 93707cbabcc8baf2b2b5f4a99c1f08ee83eb7abd
> Author: Brenda J. Butler <bjb@mojatatu.com>
> Date:   Wed Feb 14 14:08:54 2018 -0500
> 
>      tools: tc-testing: Introduce plugin architecture
> 
> 
> 
> 
> 
> And this system has:
> 
> $ python3 -V
> Python 3.5.3
> 
> $ python -V
> Python 2.7.15
> 


This one on the other hand seems to be a toolchain issue...

rpmbuild calls out to

/usr/lib/rpm/brp-python-bytecompile /usr/bin/python

which basically in this case seems to try to parse python3 code with 
python2 and it falls over...

So I've disabled bytecompiling on kernel builds until I can check the 
toolchain behaviour...

--
Thomas

Re: building in 32bit chroot on x86_64 host broken

[Masahiro Yamada]

Hi Linus, Thomas,


2018-06-06 4:13 GMT+09:00 Linus Torvalds <torvalds@linux-foundation.org>:
> On Tue, Jun 5, 2018 at 11:50 AM Thomas Backlund <tmb@mageia.org> wrote:
>> >
>> > but why do you care?
>>
>> Because without it running the build in the 32bit chroot will get the
>> initial reported issue:
>
> Ahh. I can re-create that now.
>
> Yes, doing
>
>       make ARCH=i386 allnoconfig
>
> followed by
>
>       make oldconfig
>
> is broken. And doing a trivial "git bisect run" to pinpoint where
> CONFIG_64BIT goes away gives us
>
> f467c5640c29ad258c3cd8186a776c82fc3b8057 is the first bad commit
>
> which does that
>
>   "kconfig: only write '# CONFIG_FOO is not set' for visible symbols"
>
> and it turns out that CONFIG_64BIT is not a visible symbol on x86-32,
> because that question is disabled when ARCH != "x86".
>
>         bool "64-bit kernel" if ARCH = "x86"
>
> And the problem with that, is that *next* time around this config file
> is used, because we don't have that
>
>   # CONFIG_64BIT is not set
>
> line, we don't turn it into
>
>   CONFIG_64BIT=n
>
> and then the "depends on" in X86_64
>
>   config X86_64
>           def_bool y
>           depends on 64BIT
>
> no longer hides it.
>
> Hmm. Ulf, Masahiro, comments?
>
> Should we just revert that commit?


Hmm.

Was the v4.16 behavior intentional,
or just something people found to work?


IMHO, the current behavior in v4.17 is expected
from the Kconfig point of view.


"make ARCH=i386 allnoconfig" hides the prompt
of 64BIT.

Then, "make oldconfig" makes the prompt newly visible,
so it is asking for user input.



However, the previous behavior is desired,
I think we can change the course.




If a symbol is visible (i.e. there is no unmet direct dependency),
'# CONFIG_... is not set' should be written out to the .config
even if its prompt is invisible.


For example,


config FOO
       bool


should write out "# CONFIG_FOO is not set"


I think this will fix the reported problem,
and Kconfig can still keep the grammatical consistency.


Ulf, what do you think?








> Thomas, can you verify that a
>
>         git revert f467c5640c29ad258c3cd8186a776c82fc3b8057
>
> fixes the problem for you?
>
>               Linus



-- 
Best Regards
Masahiro Yamada

Re: building in 32bit chroot on x86_64 host broken

[Linus Torvalds]

On Tue, Jun 5, 2018 at 6:38 PM Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
>
> Was the v4.16 behavior intentional,
> or just something people found to work?

I don't think all the _details_ may be intentional, but the fact that

   make oldconfig

"just works" is definitely a good thing.

> "make ARCH=i386 allnoconfig" hides the prompt
> of 64BIT.
>
> Then, "make oldconfig" makes the prompt newly visible,
> so it is asking for user input.

The "hides the prompt for 64BIT" is just a technical detail.

It could equally well be a pre-determined Kconfig fragment that is
used to generate a particular Kconfig.

But once you *have* that particular Kconfig, I do think that "make
oldconfig" should just work. And it apparently used to.

So I think this is a behavioral regression.

           Linus

Re: building in 32bit chroot on x86_64 host broken

[Linus Torvalds]

On Tue, Jun 5, 2018 at 6:54 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> But once you *have* that particular Kconfig, I do think that "make
> oldconfig" should just work. And it apparently used to.
>
> So I think this is a behavioral regression.

That doesn't necessarily mean that he fix should be to revert.

Maybe the fix is to simply change how we generate the ARCH variable.

Right now, in the Makefile, it is

    ARCH ?= $(SUBARCH)

so basically "if the user didn't specify ARCH, we pick it from SUBARCH".

But that doesn't make much sense for "make oldconfig" does it?

So maybe we could make the rule be that if the user didn't specify
ARCH explicitly, we take it from SUBARCH, _except_ if we are doing
"make oldconfig", in which case we take it from the .config file.

That makes a certain amount of sense, wouldn't you agree? Doing
"oldconfig" and silently changing ARCH under the user seems pretty
user-hostile.

In fact, I think it would _always_ make sense to take ARCH from the
config file, _unless_ we're actively generating a new config file
entirely (ie "make *config", not counting "oldconfig").

Hmm?

                Linus

Re: building in 32bit chroot on x86_64 host broken

[Masahiro Yamada]

Hi Linus,

2018-06-06 11:19 GMT+09:00 Linus Torvalds <torvalds@linux-foundation.org>:
> On Tue, Jun 5, 2018 at 6:54 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> But once you *have* that particular Kconfig, I do think that "make
>> oldconfig" should just work. And it apparently used to.
>>
>> So I think this is a behavioral regression.
>
> That doesn't necessarily mean that he fix should be to revert.


If this is a regression, I am OK with the revert,
and it is the only quick solution.



> Maybe the fix is to simply change how we generate the ARCH variable.
>
> Right now, in the Makefile, it is
>
>     ARCH ?= $(SUBARCH)
>
> so basically "if the user didn't specify ARCH, we pick it from SUBARCH".
>
> But that doesn't make much sense for "make oldconfig" does it?
>
> So maybe we could make the rule be that if the user didn't specify
> ARCH explicitly, we take it from SUBARCH, _except_ if we are doing
> "make oldconfig", in which case we take it from the .config file.
>
> That makes a certain amount of sense, wouldn't you agree? Doing
> "oldconfig" and silently changing ARCH under the user seems pretty
> user-hostile.
>
> In fact, I think it would _always_ make sense to take ARCH from the
> config file, _unless_ we're actively generating a new config file
> entirely (ie "make *config", not counting "oldconfig").
>
> Hmm?
>
>                 Linus


This is a big hammer.

It is difficult to make a quick answer.


In fact, I saw a patch series a few years ago.

https://lkml.org/lkml/2014/9/1/70

It was not accepted.
(I was not a maintainer at that time)

I do not remember the details,
but I thought it was a double-edged sword.




-- 
Best Regards
Masahiro Yamada

Re: building in 32bit chroot on x86_64 host broken

[Thomas Backlund]

Den 2018-06-06 kl. 06:30, skrev Masahiro Yamada:
> Hi Linus,
>
> 2018-06-06 11:19 GMT+09:00 Linus Torvalds <torvalds@linux-foundation.org>:
>> On Tue, Jun 5, 2018 at 6:54 PM Linus Torvalds
>> <torvalds@linux-foundation.org> wrote:
>>> But once you *have* that particular Kconfig, I do think that "make
>>> oldconfig" should just work. And it apparently used to.
>>>
>>> So I think this is a behavioral regression.
>> That doesn't necessarily mean that he fix should be to revert.
>
> If this is a regression, I am OK with the revert,
> and it is the only quick solution.
>

It is a regression as the same "make oldconfig routine" has been working 
iirc since atleast 2.4 series kernels :)

But I dont see it as needing a "quick solution" revert if the "kconfig: 
only write '# CONFIG_FOO is not set' for visible symbols" is considered 
a "useful thing we want to keep"... I'd rather think waiting/working a 
bit for a proper fix is the better way then...

I can work around it for now (or keep the revert in our kernel builds 
for now) until it gets properly fixed...

Feel free to cc me on suggested fixes to test

--
Thomas

Re: building in 32bit chroot on x86_64 host broken

[Linus Torvalds]

On Thu, Jun 7, 2018 at 12:35 PM Thomas Backlund <tmb@mageia.org> wrote:
>
> I can work around it for now (or keep the revert in our kernel builds
> for now) until it gets properly fixed...

So rather than doing the revert, it's probably better if  your
workaround just does

   make ARCH=i386 oldconfig

(or maybe even just a "export ARCH=i386" in the environment)

That should get you to continue to otherwise do the same thing.

And if it turns out that your flow is the *only* one affected by this,
and nobody else complains, maybe we can just say "yeah, slight change
in build rules, easy to work around" and leave it at that.

                Linus

Re: building in 32bit chroot on x86_64 host broken

[Thomas Backlund]

Den 2018-06-07 kl. 22:40, skrev Linus Torvalds:
> On Thu, Jun 7, 2018 at 12:35 PM Thomas Backlund <tmb@mageia.org> wrote:
>> I can work around it for now (or keep the revert in our kernel builds
>> for now) until it gets properly fixed...
> So rather than doing the revert, it's probably better if  your
> workaround just does
>
>     make ARCH=i386 oldconfig
>
> (or maybe even just a "export ARCH=i386" in the environment)
>
> That should get you to continue to otherwise do the same thing.
>
> And if it turns out that your flow is the *only* one affected by this,
> and nobody else complains, maybe we can just say "yeah, slight change
> in build rules, easy to work around" and leave it at that.
>
>                  Linus

Yeah, I can live with that too :)

I just wanted to point out the regression in case it was not (sort of) 
intentional...

--
Thomas

Re: building in 32bit chroot on x86_64 host broken

[Michal Kubecek]

On Thu, Jun 07, 2018 at 12:40:30PM -0700, Linus Torvalds wrote:
> On Thu, Jun 7, 2018 at 12:35 PM Thomas Backlund <tmb@mageia.org> wrote:
> >
> > I can work around it for now (or keep the revert in our kernel builds
> > for now) until it gets properly fixed...
> 
> So rather than doing the revert, it's probably better if  your
> workaround just does
> 
>    make ARCH=i386 oldconfig
> 
> (or maybe even just a "export ARCH=i386" in the environment)
> 
> That should get you to continue to otherwise do the same thing.
> 
> And if it turns out that your flow is the *only* one affected by this,
> and nobody else complains, maybe we can just say "yeah, slight change
> in build rules, easy to work around" and leave it at that.

Not the only one, we hit the same problem when building openSUSE
packages (4.17-rc1) but we resolved it by always setting ARCH:

  https://github.com/openSUSE/kernel-source/commit/fb21b7321ab5

It also revealed that we forgot to pass MAKE_ARGS to other phases of RPM
build process so we don't have reason to complain.

Michal Kubecek

Re: building in 32bit chroot on x86_64 host broken

[Masahiro Yamada]

2018-06-08 4:49 GMT+09:00 Thomas Backlund <tmb@mageia.org>:
>
> Den 2018-06-07 kl. 22:40, skrev Linus Torvalds:
>>
>> On Thu, Jun 7, 2018 at 12:35 PM Thomas Backlund <tmb@mageia.org> wrote:
>>>
>>> I can work around it for now (or keep the revert in our kernel builds
>>> for now) until it gets properly fixed...
>>
>> So rather than doing the revert, it's probably better if  your
>> workaround just does
>>
>>     make ARCH=i386 oldconfig
>>
>> (or maybe even just a "export ARCH=i386" in the environment)
>>
>> That should get you to continue to otherwise do the same thing.
>>
>> And if it turns out that your flow is the *only* one affected by this,
>> and nobody else complains, maybe we can just say "yeah, slight change
>> in build rules, easy to work around" and leave it at that.
>>
>>                  Linus
>
>
> Yeah, I can live with that too :)
>
> I just wanted to point out the regression in case it was not (sort of)
> intentional...



If you want to do 'make oldconfig' without setting ARCH,
maybe the following could work.



diff --git a/Makefile b/Makefile
index 019a5a0..b491e86 100644
--- a/Makefile
+++ b/Makefile
@@ -292,7 +292,7 @@ export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE
KERNELVERSION
 # then ARCH is assigned, getting whatever value it gets normally, and
 # SUBARCH is subsequently ignored.

-SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
+SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/x86_64/x86/ \
                                  -e s/sun4u/sparc64/ \
                                  -e s/arm.*/arm/ -e s/sa110/arm/ \
                                  -e s/s390x/s390/ -e s/parisc64/parisc/ \


or


diff --git a/Makefile b/Makefile
index 019a5a0..3586967 100644
--- a/Makefile
+++ b/Makefile
@@ -292,7 +292,7 @@ export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE
KERNELVERSION
 # then ARCH is assigned, getting whatever value it gets normally, and
 # SUBARCH is subsequently ignored.

-SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
+SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ \
                                  -e s/sun4u/sparc64/ \
                                  -e s/arm.*/arm/ -e s/sa110/arm/ \
                                  -e s/s390x/s390/ -e s/parisc64/parisc/ \





-- 
Best Regards
Masahiro Yamada

Re: building in 32bit chroot on x86_64 host broken

[Masahiro Yamada]

2018-06-08 18:12 GMT+09:00 Michal Kubecek <mkubecek@suse.cz>:
> On Thu, Jun 07, 2018 at 12:40:30PM -0700, Linus Torvalds wrote:
>> On Thu, Jun 7, 2018 at 12:35 PM Thomas Backlund <tmb@mageia.org> wrote:
>> >
>> > I can work around it for now (or keep the revert in our kernel builds
>> > for now) until it gets properly fixed...
>>
>> So rather than doing the revert, it's probably better if  your
>> workaround just does
>>
>>    make ARCH=i386 oldconfig
>>
>> (or maybe even just a "export ARCH=i386" in the environment)
>>
>> That should get you to continue to otherwise do the same thing.
>>
>> And if it turns out that your flow is the *only* one affected by this,
>> and nobody else complains, maybe we can just say "yeah, slight change
>> in build rules, easy to work around" and leave it at that.
>
> Not the only one, we hit the same problem when building openSUSE
> packages (4.17-rc1) but we resolved it by always setting ARCH:
>
>   https://github.com/openSUSE/kernel-source/commit/fb21b7321ab5
>
> It also revealed that we forgot to pass MAKE_ARGS to other phases of RPM
> build process so we don't have reason to complain.
>
> Michal Kubecek


Just a note.

In case of cross-compiling, not only ARCH but also CROSS_COMPILE
must be passed when you do "make *config".

In this merge window, some compiler option tests are being moved
from Makefiles to the Kconfig phase.

People tend to set "export CROSS_COMPILE=..."
in their build environment.
I have not received any complaint about this change so far.



-- 
Best Regards
Masahiro Yamada

Re: building in 32bit chroot on x86_64 host broken

[Theodore Y. Ts'o]

On Sat, Jun 09, 2018 at 09:23:55PM +0900, Masahiro Yamada wrote:
> Just a note.
> 
> In case of cross-compiling, not only ARCH but also CROSS_COMPILE
> must be passed when you do "make *config".

Sure, what was being discussed was people who build 32-bit x86 kernels
on a 64-bit platform.  I do this occasionally to check and make sure
that 32-compat ioctl handling is working correctly, etc.  I suspect
there are more developers setting just ARCH= and not CROSS_COMPILE
because they are building 32-bit x86 kernels (which can then be
trivially tested using qemu) than there are building cross-compiled
kernels for a completely different architecture.

I saw this thread and decided I didn't care because I use a standard
"kbuild32" script (I also have a "kbuild" script for building normal
64-bit kernels), and it always passes ARCH=i386.

					- Ted

#!/bin/bash

N=$(getconf _NPROCESSORS_ONLN)

if test -f .git/kbuild/config ; then
    . .git/kbuild/config
else
    echo "Missing kbuild configuration file!"
    exit 1
fi

if test ! -d "$BLD_DIR_32" ; then
    mkdir -p "$BLD_DIR_32"
    if test -f .git/kbuild/kernel-config ; then
	cp .git/kbuild/kernel-config-32 "$BLD_DIR_32/.config"
    fi
    for i in x509.genkey signing_key.pem signing_key.x509
    do
	if test -f ".git/kbuild/$i" ; then
	    mkdir -p "$BLD_DIR_32/certs"
	    cp ".git/kbuild/$i" "$BLD_DIR_32/certs"
	fi
    done
fi

time nice make O="$BLD_DIR_32" ARCH=i386 -j$N $*

cp "$BLD_DIR_32/.config" .git/kbuild/kernel-config-32