* Linux 4.17
@ 2018-06-03 21:58 Linus Torvalds
2018-06-05 17:53 ` building in 32bit chroot on x86_64 host broken (was: Linux 4.17) Thomas Backlund
2018-06-05 20:10 ` python errors in tools/testing/selftests/tc-testing (was: Linux 4.17) Thomas Backlund
0 siblings, 2 replies; 22+ messages in thread
From: Linus Torvalds @ 2018-06-03 21:58 UTC (permalink / raw)
To: Linux Kernel Mailing List
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()
^ permalink raw reply [flat|nested] 22+ messages in thread
* building in 32bit chroot on x86_64 host broken (was: Linux 4.17)
2018-06-03 21:58 Linux 4.17 Linus Torvalds
@ 2018-06-05 17:53 ` Thomas Backlund
2018-06-05 18:11 ` Linus Torvalds
2018-06-05 18:12 ` building in 32bit chroot on x86_64 host broken - IGNORE Thomas Backlund
2018-06-05 20:10 ` python errors in tools/testing/selftests/tc-testing (was: Linux 4.17) Thomas Backlund
1 sibling, 2 replies; 22+ messages in thread
From: Thomas Backlund @ 2018-06-05 17:53 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Linus Torvalds
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: building in 32bit chroot on x86_64 host broken (was: Linux 4.17)
2018-06-05 17:53 ` building in 32bit chroot on x86_64 host broken (was: Linux 4.17) Thomas Backlund
@ 2018-06-05 18:11 ` Linus Torvalds
2018-06-05 18:24 ` building in 32bit chroot on x86_64 host broken Thomas Backlund
2018-06-05 18:12 ` building in 32bit chroot on x86_64 host broken - IGNORE Thomas Backlund
1 sibling, 1 reply; 22+ messages in thread
From: Linus Torvalds @ 2018-06-05 18:11 UTC (permalink / raw)
To: tmb, Masahiro Yamada; +Cc: Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: building in 32bit chroot on x86_64 host broken - IGNORE
2018-06-05 17:53 ` building in 32bit chroot on x86_64 host broken (was: Linux 4.17) Thomas Backlund
2018-06-05 18:11 ` Linus Torvalds
@ 2018-06-05 18:12 ` Thomas Backlund
1 sibling, 0 replies; 22+ messages in thread
From: Thomas Backlund @ 2018-06-05 18:12 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Linus Torvalds
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: building in 32bit chroot on x86_64 host broken
2018-06-05 18:11 ` Linus Torvalds
@ 2018-06-05 18:24 ` Thomas Backlund
2018-06-05 18:38 ` Linus Torvalds
0 siblings, 1 reply; 22+ messages in thread
From: Thomas Backlund @ 2018-06-05 18:24 UTC (permalink / raw)
To: Linus Torvalds, Masahiro Yamada; +Cc: Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: building in 32bit chroot on x86_64 host broken
2018-06-05 18:24 ` building in 32bit chroot on x86_64 host broken Thomas Backlund
@ 2018-06-05 18:38 ` Linus Torvalds
2018-06-05 18:51 ` Thomas Backlund
0 siblings, 1 reply; 22+ messages in thread
From: Linus Torvalds @ 2018-06-05 18:38 UTC (permalink / raw)
To: tmb; +Cc: Masahiro Yamada, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: building in 32bit chroot on x86_64 host broken
2018-06-05 18:38 ` Linus Torvalds
@ 2018-06-05 18:51 ` Thomas Backlund
2018-06-05 19:13 ` Linus Torvalds
0 siblings, 1 reply; 22+ messages in thread
From: Thomas Backlund @ 2018-06-05 18:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Masahiro Yamada, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: building in 32bit chroot on x86_64 host broken
2018-06-05 18:51 ` Thomas Backlund
@ 2018-06-05 19:13 ` Linus Torvalds
2018-06-05 19:36 ` Thomas Backlund
2018-06-06 1:37 ` Masahiro Yamada
0 siblings, 2 replies; 22+ messages in thread
From: Linus Torvalds @ 2018-06-05 19:13 UTC (permalink / raw)
To: tmb, Ulf Magnusson; +Cc: Masahiro Yamada, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: building in 32bit chroot on x86_64 host broken
2018-06-05 19:13 ` Linus Torvalds
@ 2018-06-05 19:36 ` Thomas Backlund
2018-06-06 1:37 ` Masahiro Yamada
1 sibling, 0 replies; 22+ messages in thread
From: Thomas Backlund @ 2018-06-05 19:36 UTC (permalink / raw)
To: Linus Torvalds, Ulf Magnusson; +Cc: Masahiro Yamada, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* python errors in tools/testing/selftests/tc-testing (was: Linux 4.17)
2018-06-03 21:58 Linux 4.17 Linus Torvalds
2018-06-05 17:53 ` building in 32bit chroot on x86_64 host broken (was: Linux 4.17) Thomas Backlund
@ 2018-06-05 20:10 ` Thomas Backlund
2018-06-05 21:01 ` python errors in tools/testing/selftests/tc-testing - IGNORE Thomas Backlund
1 sibling, 1 reply; 22+ messages in thread
From: Thomas Backlund @ 2018-06-05 20:10 UTC (permalink / raw)
To: Linus Torvalds, bjb; +Cc: Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: python errors in tools/testing/selftests/tc-testing - IGNORE
2018-06-05 20:10 ` python errors in tools/testing/selftests/tc-testing (was: Linux 4.17) Thomas Backlund
@ 2018-06-05 21:01 ` Thomas Backlund
0 siblings, 0 replies; 22+ messages in thread
From: Thomas Backlund @ 2018-06-05 21:01 UTC (permalink / raw)
To: Linus Torvalds, bjb; +Cc: Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: building in 32bit chroot on x86_64 host broken
2018-06-05 19:13 ` Linus Torvalds
2018-06-05 19:36 ` Thomas Backlund
@ 2018-06-06 1:37 ` Masahiro Yamada
2018-06-06 1:54 ` Linus Torvalds
1 sibling, 1 reply; 22+ messages in thread
From: Masahiro Yamada @ 2018-06-06 1:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: tmb, Ulf Magnusson, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: building in 32bit chroot on x86_64 host broken
2018-06-06 1:37 ` Masahiro Yamada
@ 2018-06-06 1:54 ` Linus Torvalds
2018-06-06 2:19 ` Linus Torvalds
0 siblings, 1 reply; 22+ messages in thread
From: Linus Torvalds @ 2018-06-06 1:54 UTC (permalink / raw)
To: Masahiro Yamada; +Cc: tmb, Ulf Magnusson, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: building in 32bit chroot on x86_64 host broken
2018-06-06 1:54 ` Linus Torvalds
@ 2018-06-06 2:19 ` Linus Torvalds
2018-06-06 3:31 ` Masahiro Yamada
0 siblings, 1 reply; 22+ messages in thread
From: Linus Torvalds @ 2018-06-06 2:19 UTC (permalink / raw)
To: Masahiro Yamada; +Cc: tmb, Ulf Magnusson, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: building in 32bit chroot on x86_64 host broken
2018-06-06 2:19 ` Linus Torvalds
@ 2018-06-06 3:31 ` Masahiro Yamada
2018-06-07 19:36 ` Thomas Backlund
0 siblings, 1 reply; 22+ messages in thread
From: Masahiro Yamada @ 2018-06-06 3:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: tmb, Ulf Magnusson, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: building in 32bit chroot on x86_64 host broken
2018-06-06 3:31 ` Masahiro Yamada
@ 2018-06-07 19:36 ` Thomas Backlund
2018-06-07 19:40 ` Linus Torvalds
0 siblings, 1 reply; 22+ messages in thread
From: Thomas Backlund @ 2018-06-07 19:36 UTC (permalink / raw)
To: Masahiro Yamada, Linus Torvalds; +Cc: Ulf Magnusson, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: building in 32bit chroot on x86_64 host broken
2018-06-07 19:36 ` Thomas Backlund
@ 2018-06-07 19:40 ` Linus Torvalds
2018-06-07 19:49 ` Thomas Backlund
2018-06-08 9:12 ` Michal Kubecek
0 siblings, 2 replies; 22+ messages in thread
From: Linus Torvalds @ 2018-06-07 19:40 UTC (permalink / raw)
To: tmb; +Cc: Masahiro Yamada, Ulf Magnusson, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: building in 32bit chroot on x86_64 host broken
2018-06-07 19:40 ` Linus Torvalds
@ 2018-06-07 19:49 ` Thomas Backlund
2018-06-09 12:16 ` Masahiro Yamada
2018-06-08 9:12 ` Michal Kubecek
1 sibling, 1 reply; 22+ messages in thread
From: Thomas Backlund @ 2018-06-07 19:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Masahiro Yamada, Ulf Magnusson, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: building in 32bit chroot on x86_64 host broken
2018-06-07 19:40 ` Linus Torvalds
2018-06-07 19:49 ` Thomas Backlund
@ 2018-06-08 9:12 ` Michal Kubecek
2018-06-09 12:23 ` Masahiro Yamada
1 sibling, 1 reply; 22+ messages in thread
From: Michal Kubecek @ 2018-06-08 9:12 UTC (permalink / raw)
To: Linus Torvalds
Cc: tmb, Masahiro Yamada, Ulf Magnusson, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: building in 32bit chroot on x86_64 host broken
2018-06-07 19:49 ` Thomas Backlund
@ 2018-06-09 12:16 ` Masahiro Yamada
0 siblings, 0 replies; 22+ messages in thread
From: Masahiro Yamada @ 2018-06-09 12:16 UTC (permalink / raw)
To: Thomas Backlund; +Cc: Linus Torvalds, Ulf Magnusson, Linux Kernel Mailing List
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
^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: building in 32bit chroot on x86_64 host broken
2018-06-08 9:12 ` Michal Kubecek
@ 2018-06-09 12:23 ` Masahiro Yamada
2018-06-09 16:49 ` Theodore Y. Ts'o
0 siblings, 1 reply; 22+ messages in thread
From: Masahiro Yamada @ 2018-06-09 12:23 UTC (permalink / raw)
To: Michal Kubecek
Cc: Linus Torvalds, Thomas Backlund, Ulf Magnusson,
Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: building in 32bit chroot on x86_64 host broken
2018-06-09 12:23 ` Masahiro Yamada
@ 2018-06-09 16:49 ` Theodore Y. Ts'o
0 siblings, 0 replies; 22+ messages in thread
From: Theodore Y. Ts'o @ 2018-06-09 16:49 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Michal Kubecek, Linus Torvalds, Thomas Backlund, Ulf Magnusson,
Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2018-06-09 16:49 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-06-03 21:58 Linux 4.17 Linus Torvalds
2018-06-05 17:53 ` building in 32bit chroot on x86_64 host broken (was: Linux 4.17) Thomas Backlund
2018-06-05 18:11 ` Linus Torvalds
2018-06-05 18:24 ` building in 32bit chroot on x86_64 host broken Thomas Backlund
2018-06-05 18:38 ` Linus Torvalds
2018-06-05 18:51 ` Thomas Backlund
2018-06-05 19:13 ` Linus Torvalds
2018-06-05 19:36 ` Thomas Backlund
2018-06-06 1:37 ` Masahiro Yamada
2018-06-06 1:54 ` Linus Torvalds
2018-06-06 2:19 ` Linus Torvalds
2018-06-06 3:31 ` Masahiro Yamada
2018-06-07 19:36 ` Thomas Backlund
2018-06-07 19:40 ` Linus Torvalds
2018-06-07 19:49 ` Thomas Backlund
2018-06-09 12:16 ` Masahiro Yamada
2018-06-08 9:12 ` Michal Kubecek
2018-06-09 12:23 ` Masahiro Yamada
2018-06-09 16:49 ` Theodore Y. Ts'o
2018-06-05 18:12 ` building in 32bit chroot on x86_64 host broken - IGNORE Thomas Backlund
2018-06-05 20:10 ` python errors in tools/testing/selftests/tc-testing (was: Linux 4.17) Thomas Backlund
2018-06-05 21:01 ` python errors in tools/testing/selftests/tc-testing - IGNORE Thomas Backlund
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.