Re: [PATCH linux dev-4.16 v2] i2c: muxes: pca9641: new driver
Hi Peter,
Sorry for late. Here has some event at my company which needs to pause
this work.
If the status changed, I will update my patch.
Thanks.
Ken
2018-04-11 17:37 GMT+08:00 Peter Rosin :
> Hi Ken,
>
> It's been a couple of weeks and I wondered if you are making any
> progress? Simple lack of time perhaps, or are you stuck and need
> help?
>
> Cheers,
> Peter
>
> On 2018-03-20 10:31, Peter Rosin wrote:
>> On 2018-03-20 07:19, Ken Chen wrote:
>>> Signed-off-by: Ken Chen
>>
>> Ok, now that you are not adding a new driver, but instead
>> modify an existing driver, the subject I requested in no
>> longer relevant. Now I would like to see:
>>
>> i2c: mux: pca9541: add support for PCA9641 chips
>>
>> Or something like that.
>>
>>> ---
>>> v1->v2
>>> - Merged PCA9641 code into i2c-mux-pca9541.c
>>> - Modified title
>>> - Add PCA9641 detect function
>>> ---
>>> drivers/i2c/muxes/i2c-mux-pca9541.c | 184
>>> ++--
>>> 1 file changed, 174 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/i2c/muxes/i2c-mux-pca9541.c
>>> b/drivers/i2c/muxes/i2c-mux-pca9541.c
>>> index 6a39ada..493f947 100644
>>> --- a/drivers/i2c/muxes/i2c-mux-pca9541.c
>>> +++ b/drivers/i2c/muxes/i2c-mux-pca9541.c
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * I2C multiplexer driver for PCA9541 bus master selector
>>> + * I2C multiplexer driver for PCA9541/PCA9641 bus master selector
>>> *
>>> * Copyright (c) 2010 Ericsson AB.
>>> *
>>> @@ -26,8 +26,8 @@
>>> #include
>>>
>>> /*
>>> - * The PCA9541 is a bus master selector. It supports two I2C masters
>>> connected
>>> - * to a single slave bus.
>>> + * The PCA9541/PCA9641 is a bus master selector. It supports two I2C
>>> masters
>>
>> PCA9541 and PCA9641 are bus master selectors. They support two I2C masters
>>
>> And make sure to lose the trailing space.
>>
>>> + * connected to a single slave bus.
>>> *
>>> * Before each bus transaction, a master has to acquire bus ownership.
>>> After the
>>> * transaction is complete, bus ownership has to be released. This fits
>>> well
>>> @@ -58,11 +58,43 @@
>>> #define PCA9541_ISTAT_MYTEST(1 << 6)
>>> #define PCA9541_ISTAT_NMYTEST (1 << 7)
>>>
>>> +#define PCA9641_ID 0x00
>>> +#define PCA9641_ID_MAGIC0x38
>>> +
>>> +#define PCA9641_CONTROL 0x01
>>> +#define PCA9641_STATUS 0x02
>>> +#define PCA9641_TIME0x03
>>> +
>>> +#define PCA9641_CTL_LOCK_REQBIT(0)
>>> +#define PCA9641_CTL_LOCK_GRANT BIT(1)
>>> +#define PCA9641_CTL_BUS_CONNECT BIT(2)
>>> +#define PCA9641_CTL_BUS_INITBIT(3)
>>> +#define PCA9641_CTL_SMBUS_SWRST BIT(4)
>>> +#define PCA9641_CTL_IDLE_TIMER_DIS BIT(5)
>>> +#define PCA9641_CTL_SMBUS_DIS BIT(6)
>>> +#define PCA9641_CTL_PRIORITYBIT(7)
>>> +
>>> +#define PCA9641_STS_OTHER_LOCK BIT(0)
>>> +#define PCA9641_STS_BUS_INIT_FAIL BIT(1)
>>> +#define PCA9641_STS_BUS_HUNGBIT(2)
>>> +#define PCA9641_STS_MBOX_EMPTY BIT(3)
>>> +#define PCA9641_STS_MBOX_FULL BIT(4)
>>> +#define PCA9641_STS_TEST_INTBIT(5)
>>> +#define PCA9641_STS_SCL_IO BIT(6)
>>> +#define PCA9641_STS_SDA_IO BIT(7)
>>> +
>>> +#define PCA9641_RES_TIME0x03
>>> +
>>> #define BUSON (PCA9541_CTL_BUSON | PCA9541_CTL_NBUSON)
>>> #define MYBUS (PCA9541_CTL_MYBUS | PCA9541_CTL_NMYBUS)
>>> #define mybus(x)(!((x) & MYBUS) || ((x) & MYBUS) == MYBUS)
>>> #define busoff(x) (!((x) & BUSON) || ((x) & BUSON) == BUSON)
>>>
>>> +#define BUSOFF(x, y)(!((x) & PCA9641_CTL_LOCK_GRANT) && \
>>> +!((y) & PCA9641_STS_OTHER_LOCK))
>>> +#define other_lock(x) ((x) & PCA9641_STS_OTHER_LOCK)
>>> +#define lock_grant(x) ((x) & PCA9641_CTL_LOCK_GRANT)
>> These macro names are now completely hideous. They were bad before,
>> but this is just too much for me. So, instead of adding BUSOFF etc,
>> I would like to see all the macros with a chip prefix. But I think
>> they will get overly long, so I think you should just write trivial
>> pca9541_mybus, pca9541_busoff, pca9641_busoff etc functions. The
>> compiler should inline them just fine.
>>
>> The rename of the existing macros and their conversion to functions
>> should be in the first preparatory patch that I mention below. The
>> new functions should be in the second patch.
>>
>>> +
>>> /* arbitration timeouts, in jiffies */
>>> #define ARB_TIMEOUT (HZ / 8)/* 125 ms until forcing bus ownership
>>> */
>>> #define ARB2_TIMEOUT(HZ / 4)/* 250 ms until acquisition
>>> failure */
>>> @@ -79,6 +111,7 @@ struct pca9541 {
>>>
>>> static const struct i2c_device_id pca9541_id[] = {
>>> {"pca9541", 0},
>>> +{"pca9641", 1},
>>
>> You are actually not using this 0/1 difference. Have a look at
>> e.g. how the i2c-mux-pca954x driver uses this as an index into
>>
[PATCH net] virtio-net: add missing virtqueue kick when flushing packets
We tends to batch submitting packets during XDP_TX. This requires to
kick virtqueue after a batch, we tried to do it through
xdp_do_flush_map() which only makes sense for devmap not XDP_TX. So
explicitly kick the virtqueue in this case.
Reported-by: Kimitoshi Takahashi
Tested-by: Kimitoshi Takahashi
Cc: Daniel Borkmann
Fixes: 186b3c998c50 ("virtio-net: support XDP_REDIRECT")
Signed-off-by: Jason Wang
---
drivers/net/virtio_net.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 2337460..d8e1aea 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1269,7 +1269,9 @@ static int virtnet_poll(struct napi_struct *napi, int
budget)
{
struct receive_queue *rq =
container_of(napi, struct receive_queue, napi);
- unsigned int received;
+ struct virtnet_info *vi = rq->vq->vdev->priv;
+ struct send_queue *sq;
+ unsigned int received, qp;
bool xdp_xmit = false;
virtnet_poll_cleantx(rq);
@@ -1280,8 +1282,13 @@ static int virtnet_poll(struct napi_struct *napi, int
budget)
if (received < budget)
virtqueue_napi_complete(napi, rq->vq, received);
- if (xdp_xmit)
+ if (xdp_xmit) {
+ qp = vi->curr_queue_pairs - vi->xdp_queue_pairs +
+smp_processor_id();
+ sq = &vi->sq[qp];
+ virtqueue_kick(sq->vq);
xdp_do_flush_map();
+ }
return received;
}
--
2.7.4
Re: [PATCH v3] PCI / PM: Always check PME wakeup capability for runtime wakeup support
Hi Bjorn and Rafael,
On Apr 1, 2018, at 12:40 AM, Kai-Heng Feng
wrote:
USB controller ASM1042 stops working after commit de3ef1eb1cd0 ("PM /
core: Drop run_wake flag from struct dev_pm_info").
The device in question is not power managed by platform firmware,
furthermore, it only supports PME# from D3cold:
Capabilities: [78] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA
PME(D0-,D1-,D2-,D3hot-,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Before commit de3ef1eb1cd0, the device never gets runtime suspended.
After that commit, the device gets runtime suspended, so it does not
respond to any PME#.
usb_hcd_pci_probe() mandatorily calls device_wakeup_enable(), hence
device_can_wakeup() in pci_dev_run_wake() always returns true.
So pci_dev_run_wake() needs to check PME wakeup capability as its first
condition.
In addition, change wakeup flag passed to pci_target_state() from false
to true, because we want to find the deepest state that the device can
still generate PME#.
Fixes: de3ef1eb1cd0 ("PM / core: Drop run_wake flag from struct
dev_pm_info")
Cc: sta...@vger.kernel.org # 4.13+
Signed-off-by: Kai-Heng Feng
---
v3: State the reason why the wakeup flag gets changed.
v2: Explicitly check dev->pme_support.
If this patch is good enough, I am hoping it can get merged in v4.17.
Kai-Heng
drivers/pci/pci.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index f6a4dd10d9b0..52821a21fc07 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -2125,16 +2125,16 @@ bool pci_dev_run_wake(struct pci_dev *dev)
{
struct pci_bus *bus = dev->bus;
- if (device_can_wakeup(&dev->dev))
- return true;
-
if (!dev->pme_support)
return false;
/* PME-capable in principle, but not from the target power state */
- if (!pci_pme_capable(dev, pci_target_state(dev, false)))
+ if (!pci_pme_capable(dev, pci_target_state(dev, true)))
return false;
+ if (device_can_wakeup(&dev->dev))
+ return true;
+
while (bus->parent) {
struct pci_dev *bridge = bus->self;
--
2.15.1
Re: [v3 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct
On Thu 12-04-18 09:20:24, Yang Shi wrote: > > > On 4/12/18 5:18 AM, Michal Hocko wrote: > > On Tue 10-04-18 11:28:13, Yang Shi wrote: > > > > > > On 4/10/18 9:21 AM, Yang Shi wrote: > > > > > > > > On 4/10/18 5:28 AM, Cyrill Gorcunov wrote: > > > > > On Tue, Apr 10, 2018 at 01:10:01PM +0200, Michal Hocko wrote: > > > > > > > Because do_brk does vma manipulations, for this reason it's > > > > > > > running under down_write_killable(&mm->mmap_sem). Or you > > > > > > > mean something else? > > > > > > Yes, all we need the new lock for is to get a consistent view on brk > > > > > > values. I am simply asking whether there is something fundamentally > > > > > > wrong by doing the update inside the new lock while keeping the > > > > > > original > > > > > > mmap_sem locking in the brk path. That would allow us to drop the > > > > > > mmap_sem lock in the proc path when looking at brk values. > > > > > Michal gimme some time. I guess we might do so, but I need some > > > > > spare time to take more precise look into the code, hopefully today > > > > > evening. Also I've a suspicion that we've wracked check_data_rlimit > > > > > with this new lock in prctl. Need to verify it again. > > > > I see you guys points. We might be able to move the drop of mmap_sem > > > > before setting mm->brk in sys_brk since mmap_sem should be used to > > > > protect vma manipulation only, then protect the value modify with the > > > > new arg_lock. Then we can eliminate mmap_sem stuff in prctl path, and it > > > > also prevents from wrecking check_data_rlimit. > > > > > > > > At the first glance, it looks feasible to me. Will look into deeper > > > > later. > > > A further look told me this might be *not* feasible. > > > > > > It looks the new lock will not break check_data_rlimit since in my patch > > > both start_brk and brk is protected by mmap_sem. The code flow might look > > > like below: > > > > > > CPU A CPU B > > > > > > prctl sys_brk > > > down_write > > > check_data_rlimit check_data_rlimit (need mm->start_brk) > > > set brk > > > down_write up_write > > > set start_brk > > > set brk > > > up_write > > > > > > > > > If CPU A gets the mmap_sem first, it will set start_brk and brk, then CPU > > > B > > > will check with the new start_brk. And, prctl doesn't care if sys_brk is > > > run > > > before it since it gets the new start_brk and brk from parameter. > > > > > > If we protect start_brk and brk with the new lock, sys_brk might get old > > > start_brk, then sys_brk might break rlimit check silently, is that right? > > > > > > So, it looks using new lock in prctl and keeping mmap_sem in brk path has > > > race condition. > > OK, I've admittedly didn't give it too much time to think about. Maybe > > we do something clever to remove the race but can we start at least by > > reducing the write lock to read on prctl side and use the dedicated > > spinlock for updating values? That should close the above race AFAICS > > and the read lock would be much more friendly to other VM operations. > > Yes, is sounds feasible. We just need care about prctl is run before > sys_brk. There will never be any before/after ordering here. It has never been. We just need the two to be mutually exlusive. We do not really need that for races with the page fault because the prctl doesn't modify the layout AFAIU. > So, you mean: > > down_read > spin_lock > update all the values > spin_unlock > up_read Yes. -- Michal Hocko SUSE Labs
Re: [PATCH] KVM: x86: VMX: hyper-v: Enlightened MSR-Bitmap support
On 4/12/2018 11:25 PM, Vitaly Kuznetsov wrote:
> Enlightened MSR-Bitmap is a natural extension of Enlightened VMCS:
> Hyper-V Top Level Functional Specification states:
>
> "The L1 hypervisor may collaborate with the L0 hypervisor to make MSR
> accesses more efficient. It can enable enlightened MSR bitmaps by setting
> the corresponding field in the enlightened VMCS to 1. When enabled, the L0
> hypervisor does not monitor the MSR bitmaps for changes. Instead, the L1
> hypervisor must invalidate the corresponding clean field after making
> changes to one of the MSR bitmaps."
>
> I reached out to Hyper-V team for additional details and I got the
> following information
>
> "Current Hyper-V implementation works as following.
>
> If the enlightened MSR bitmap is not enabled:
> - All MSR accesses of L2 guests cause physical VM-Exits
>
> If the enlightened MSR bitmap is enabled:
> - Physical VM-Exits for L2 accesses to certain MSRs (currently FS_BASE,
>GS_BASE and KERNEL_GS_BASE) are avoided, thus making these MSR accesses
>faster."
>
> I tested my series with a custom kernel module doing tight rdmsrl loop,
> for KERNEL_GS_BASE the results are:
>
> Without Enlightened MSR-Bitmap: 1300 cycles/read
> With Enlightened MSR-Bitmap: 120 cycles/read
Tested-by: Lan Tianyu
>
> Signed-off-by: Vitaly Kuznetsov
> ---
> arch/x86/include/asm/hyperv-tlfs.h | 9 -
> arch/x86/kvm/vmx.c | 34 +-
> 2 files changed, 41 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/include/asm/hyperv-tlfs.h
> b/arch/x86/include/asm/hyperv-tlfs.h
> index 1c602ad4bda8..26e7e2240066 100644
> --- a/arch/x86/include/asm/hyperv-tlfs.h
> +++ b/arch/x86/include/asm/hyperv-tlfs.h
> @@ -300,6 +300,9 @@ struct ms_hyperv_tsc_page {
> /* TSC emulation after migration */
> #define HV_X64_MSR_REENLIGHTENMENT_CONTROL 0x4106
>
> +/* Nested features (CPUID 0x400A) EAX */
> +#define HV_X64_NESTED_MSR_BITMAP BIT(19)
> +
> struct hv_reenlightenment_control {
> __u64 vector:8;
> __u64 reserved1:8;
> @@ -665,7 +668,11 @@ struct hv_enlightened_vmcs {
> u32 hv_clean_fields;
> u32 hv_padding_32;
> u32 hv_synthetic_controls;
> - u32 hv_enlightenments_control;
> + struct {
> + u32 nested_flush_hypercall:1;
> + u32 msr_bitmap:1;
> + u32 reserved:30;
> + } hv_enlightenments_control;
> u32 hv_vp_id;
>
> u64 hv_vm_id;
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index b2f8a700aeef..c80a48cffc52 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -1014,6 +1014,7 @@ static const u32 vmx_msr_index[] = {
> };
>
> DEFINE_STATIC_KEY_FALSE(enable_evmcs);
> +DEFINE_STATIC_KEY_FALSE(enable_emsr_bitmap);
>
> #define current_evmcs ((struct hv_enlightened_vmcs
> *)this_cpu_read(current_vmcs))
>
> @@ -1090,6 +1091,15 @@ static inline u16 evmcs_read16(unsigned long field)
> return *(u16 *)((char *)current_evmcs + offset);
> }
>
> +static inline void evmcs_touch_msr_bitmap(void)
> +{
> + if (unlikely(!current_evmcs))
> + return;
> +
> + current_evmcs->hv_clean_fields &=
> + ~HV_VMX_ENLIGHTENED_CLEAN_FIELD_MSR_BITMAP;
> +}
> +
> static void evmcs_load(u64 phys_addr)
> {
> struct hv_vp_assist_page *vp_ap =
> @@ -1174,6 +1184,7 @@ static inline u32 evmcs_read32(unsigned long field) {
> return 0; }
> static inline u16 evmcs_read16(unsigned long field) { return 0; }
> static inline void evmcs_load(u64 phys_addr) {}
> static inline void evmcs_sanitize_exec_ctrls(struct vmcs_config *vmcs_conf)
> {}
> +static inline void evmcs_touch_msr_bitmap(void) {}
> #endif /* IS_ENABLED(CONFIG_HYPERV) */
>
> static inline bool is_exception_n(u32 intr_info, u8 vector)
> @@ -4218,6 +4229,13 @@ static int alloc_loaded_vmcs(struct loaded_vmcs
> *loaded_vmcs)
> if (!loaded_vmcs->msr_bitmap)
> goto out_vmcs;
> memset(loaded_vmcs->msr_bitmap, 0xff, PAGE_SIZE);
> +
> + if (static_branch_unlikely(&enable_emsr_bitmap)) {
> + struct hv_enlightened_vmcs *evmcs =
> + (struct hv_enlightened_vmcs *)loaded_vmcs->vmcs;
> +
> + evmcs->hv_enlightenments_control.msr_bitmap = 1;
> + }
> }
> return 0;
>
> @@ -5335,6 +5353,9 @@ static void __always_inline
> vmx_disable_intercept_for_msr(unsigned long *msr_bit
> if (!cpu_has_vmx_msr_bitmap())
> return;
>
> + if (static_branch_unlikely(&enable_emsr_bitmap))
> + evmcs_touch_msr_bitmap();
> +
> /*
>* See Intel PRM Vol. 3, 20.6.9 (MSR-Bitmap Address). Early manuals
>* have the write-low and read-high bitmap offsets the wrong way round.
> @@ -5370,6 +5391,9 @@ static void __always_inline
> vmx_enable_intercept_for_msr(unsigned long *msr_bitm
> if (!cp
Re: [PATCH] mmap.2: MAP_FIXED is okay if the address range has been reserved
On Fri 13-04-18 08:43:27, Michael Kerrisk wrote: [...] > So, you mean remove this entire paragraph: > > For cases in which the specified memory region has not been > reserved using an existing mapping, newer kernels (Linux > 4.17 and later) provide an option MAP_FIXED_NOREPLACE that > should be used instead; older kernels require the caller to > use addr as a hint (without MAP_FIXED) and take appropriate > action if the kernel places the new mapping at a different > address. > > It seems like some version of the first half of the paragraph is worth > keeping, though, so as to point the reader in the direction of a remedy. > How about replacing that text with the following: > > Since Linux 4.17, the MAP_FIXED_NOREPLACE flag can be used > in a multithreaded program to avoid the hazard described > above. Yes, that sounds reasonable to me. -- Michal Hocko SUSE Labs
Re: [PATCH][v4] tools/power turbostat: if --iterations, print for specific time of iterations
On Fri, 2018-04-13 at 11:40 +0800, Yu Chen wrote:
> diff --git a/tools/power/x86/turbostat/turbostat.c
> b/tools/power/x86/turbostat/turbostat.c
> index bd9c6b31a504..a2fe96f038f0 100644
> --- a/tools/power/x86/turbostat/turbostat.c
> +++ b/tools/power/x86/turbostat/turbostat.c
> @@ -48,6 +48,7 @@ char *proc_stat = "/proc/stat";
> FILE *outf;
> int *fd_percpu;
> struct timespec interval_ts = {5, 0};
> +int iterations;
> unsigned int debug;
> unsigned int quiet;
> unsigned int sums_need_wide_columns;
> @@ -470,6 +471,7 @@ void help(void)
> " {core | package | j,k,l..m,n-p }\n"
> "--quietskip decoding system configuration header\n"
> "--interval sec Override default 5-second measurement interval\n"
> + "--iterations count Number of measurement iterations(requires
> '--interval'\n"
Missing white-space and ")".
--
Best Regards,
Artem Bityutskiy
Re: [PATCH] mmap.2: MAP_FIXED is okay if the address range has been reserved
On 04/12/2018 09:24 PM, John Hubbard wrote: > On 04/12/2018 12:18 PM, Jann Horn wrote: >> On Thu, Apr 12, 2018 at 8:59 PM, John Hubbard wrote: >>> On 04/12/2018 11:49 AM, Jann Horn wrote: On Thu, Apr 12, 2018 at 8:37 PM, Michael Kerrisk (man-pages) wrote: > Hi John, > > On 12 April 2018 at 20:33, John Hubbard wrote: >> On 04/12/2018 08:39 AM, Jann Horn wrote: >>> Clarify that MAP_FIXED is appropriate if the specified address range has >>> been reserved using an existing mapping, but shouldn't be used >>> otherwise. >>> >>> Signed-off-by: Jann Horn >>> --- >>> man2/mmap.2 | 19 +++ >>> 1 file changed, 11 insertions(+), 8 deletions(-) >>> >>> diff --git a/man2/mmap.2 b/man2/mmap.2 [...] >>> .IP >>> For example, suppose that thread A looks through >>> @@ -284,13 +285,15 @@ and the PAM libraries >>> .UR http://www.linux-pam.org >>> .UE . >>> .IP >>> -Newer kernels >>> -(Linux 4.17 and later) have a >>> +For cases in which the specified memory region has not been reserved >>> using an >>> +existing mapping, newer kernels (Linux 4.17 and later) provide an >>> option >>> .B MAP_FIXED_NOREPLACE >>> -option that avoids the corruption problem; if available, >>> -.B MAP_FIXED_NOREPLACE >>> -should be preferred over >>> -.BR MAP_FIXED . >>> +that should be used instead; older kernels require the caller to use >>> +.I addr >>> +as a hint (without >>> +.BR MAP_FIXED ) >> >> Here, I got lost: the sentence suddenly jumps into explaining >> non-MAP_FIXED >> behavior, in the MAP_FIXED section. Maybe if you break up the sentence, >> and >> possibly omit non-MAP_FIXED discussion, it will help. > > Hmmm -- true. That piece could be a little clearer. How about something like this? For cases in which MAP_FIXED can not be used because the specified memory region has not been reserved using an existing mapping, newer kernels (Linux 4.17 and later) provide an option MAP_FIXED_NOREPLACE that should be used instead. Older kernels require the caller to use addr as a hint and take appropriate action if the kernel places the new mapping at a different address. John, Michael, what do you think? >>> >>> >>> I'm still having difficulty with it, because this is in the MAP_FIXED >>> section, >>> but I think you're documenting the behavior that you get if you do *not* >>> specify MAP_FIXED, right? Also, the hint behavior is true of both older and >>> new kernels... >> >> The manpage patch you and mhocko wrote mentioned MAP_FIXED_NOREPLACE >> in the MAP_FIXED section - I was trying to avoid undoing a change you >> had just explicitly made. > > heh. So I've succeeding in getting my own wording removed, then? Progress! :) > >> >>> So, if that's your intent (you want to sort of document by contrast to what >>> would happen if this option were not used), then how about something like >>> this: >>> >>> >>> Without the MAP_FIXED option, the kernel would treat addr as a hint, rather >>> than a requirement, and the caller would need to take appropriate action >>> if the kernel placed the mapping at a different address. (For example, >>> munmap and try again.) >> >> I'd be fine with removing the paragraph. As you rightly pointed out, >> it doesn't really describe MAP_FIXED. >> > > OK, that's probably the simplest fix. So, you mean remove this entire paragraph: For cases in which the specified memory region has not been reserved using an existing mapping, newer kernels (Linux 4.17 and later) provide an option MAP_FIXED_NOREPLACE that should be used instead; older kernels require the caller to use addr as a hint (without MAP_FIXED) and take appropriate action if the kernel places the new mapping at a different address. It seems like some version of the first half of the paragraph is worth keeping, though, so as to point the reader in the direction of a remedy. How about replacing that text with the following: Since Linux 4.17, the MAP_FIXED_NOREPLACE flag can be used in a multithreaded program to avoid the hazard described above. ? Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
Re: [PATCH 4/5] dmaengine: sprd: Add Spreadtrum DMA configuration
On 13 April 2018 at 14:36, Vinod Koul wrote:
> On Fri, Apr 13, 2018 at 02:17:34PM +0800, Baolin Wang wrote:
>
>> > Agreed, users only care about grabbing a channel, setting a descriptor and
>> > submitting that.
>> >
>> > I think you need to go back and think about this a bit, please do go thru
>> > dmaengine documentation and see other driver examples.
>> >
>> > We don't typically expose these to users, they give us a transfer and we
>> > set
>> > that up in hardware for efficient. Its DMA so people expect us to use
>> > fastest
>> > mechanism available.
>>
>> But there are some configuration are really special for Spreadtrum
>> DMA, and must need user to specify how to configure, especially some
>> scenarios of audio. So I wander if we can add one pointer for
>> 'dma_slave_config' to expand some special DMA configuration
>> requirements, like:
>>
>> struct dma_slave_config {
>> ..
>> unsigned int slave_id;
>> void *platform_data;
>> };
>>
>> So if some DMA has some special configuration (such as Spreadtrum
>> DMA), they can user this platform_data pointer. Like xilinx DMA, they
>> also have some special configuration.
>
> Well we all think our HW is special and needs some additional stuff, most of
> the cases turns out not to be the case.
>
> Can you explain how audio in this case additional configuration...
>
Beside the general configuration, our audio driver will configure the
fragment length, block length, maybe transaction length, and they must
specify the request type and interrupt type, these are what we want to
export for users.
--
Baolin.wang
Best Regards
Re: [PATCH 4/5] dmaengine: sprd: Add Spreadtrum DMA configuration
On Fri, Apr 13, 2018 at 02:17:34PM +0800, Baolin Wang wrote:
> > Agreed, users only care about grabbing a channel, setting a descriptor and
> > submitting that.
> >
> > I think you need to go back and think about this a bit, please do go thru
> > dmaengine documentation and see other driver examples.
> >
> > We don't typically expose these to users, they give us a transfer and we set
> > that up in hardware for efficient. Its DMA so people expect us to use
> > fastest
> > mechanism available.
>
> But there are some configuration are really special for Spreadtrum
> DMA, and must need user to specify how to configure, especially some
> scenarios of audio. So I wander if we can add one pointer for
> 'dma_slave_config' to expand some special DMA configuration
> requirements, like:
>
> struct dma_slave_config {
> ..
> unsigned int slave_id;
> void *platform_data;
> };
>
> So if some DMA has some special configuration (such as Spreadtrum
> DMA), they can user this platform_data pointer. Like xilinx DMA, they
> also have some special configuration.
Well we all think our HW is special and needs some additional stuff, most of
the cases turns out not to be the case.
Can you explain how audio in this case additional configuration...
--
~Vinod
Re: [RFC PATCH v2 4/6] sched/fair: Introduce an energy estimation helper function
On 06-04-18, 16:36, Dietmar Eggemann wrote:
> +static inline struct capacity_state
> +*find_cap_state(int cpu, unsigned long util) { return NULL; }
I saw this somewhere else as well in this series. I believe the line break
should happen after "*" as "struct capacity_state *" should be read together as
one entity.
--
viresh
[PATCH] efi: Fix the size not consistent issue when unmapping memory map
When using kdump, SOMETIMES the "size not consistent" warning message
shows up when the crash kernel boots with early_ioremap_debug parameter:
WARNING: CPU: 0 PID: 0 at ../mm/early_ioremap.c:182 early_iounmap+0x4f/0x12c()
early_iounmap(ff200180, 0118) [0] size not consistent 0120
The root cause is that the unmapping size of memory map doesn't
match with the original size when mapping:
in __efi_memmap_init()
map.map = early_memremap(phys_map, data->size);
in efi_memmap_unmap()
size = efi.memmap.desc_size * efi.memmap.nr_map;
early_memunmap(efi.memmap.map, size);
But the efi.memmap.nr_map is from __efi_memmap_init(). The remainder
of size was discarded when calculating the nr_map:
map.nr_map = data->size / data->desc_size;
When the original size of memory map region does not equal to the
result of multiplication. The "size not consistent" warning
will be triggered.
This issue sometimes was hit by kdump because kexec set the efi map
size to align with 16 when loading crash kernel image:
in bzImage64_load()
efi_map_sz = efi_get_runtime_map_size();
efi_map_sz = ALIGN(efi_map_sz, 16);
This patch changes the logic in the unmapping function. Using the
end address of map to calcuate original size.
Thank Randy Wright for his report and testing. And also thank
Takashi Iwai for his help to trace issue.
Cc: Ard Biesheuvel
Cc: Randy Wright
Cc: Takashi Iwai
Cc: Vivek Goyal
Cc: Ingo Molnar
Signed-off-by: "Lee, Chun-Yi"
---
drivers/firmware/efi/memmap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/efi/memmap.c b/drivers/firmware/efi/memmap.c
index 5fc7052..1f592d8 100644
--- a/drivers/firmware/efi/memmap.c
+++ b/drivers/firmware/efi/memmap.c
@@ -121,7 +121,7 @@ void __init efi_memmap_unmap(void)
if (!efi.memmap.late) {
unsigned long size;
- size = efi.memmap.desc_size * efi.memmap.nr_map;
+ size = efi.memmap.map_end - efi.memmap.map;
early_memunmap(efi.memmap.map, size);
} else {
memunmap(efi.memmap.map);
--
2.10.2
Re: INFO: task hung in do_ip_vs_set_ctl (2)
syzbot has found reproducer for the following crash on net-next commit
17dec0a949153d9ac00760ba2f5b78cb583e995f (Wed Apr 4 02:15:32 2018 +)
Merge branch 'userns-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace
syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=7810ed2e0cb359580c17
So far this crash happened 2 times on net-next, upstream.
C reproducer: https://syzkaller.appspot.com/x/repro.c?id=5922062967242752
syzkaller reproducer:
https://syzkaller.appspot.com/x/repro.syz?id=5359824032235520
Raw console output:
https://syzkaller.appspot.com/x/log.txt?id=6352399027404800
Kernel config:
https://syzkaller.appspot.com/x/.config?id=-2735707888269579554
compiler: gcc (GCC) 8.0.1 20180301 (experimental)
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+7810ed2e0cb359580...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed.
INFO: task syzkaller402106:4498 blocked for more than 120 seconds.
Not tainted 4.16.0+ #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syzkaller402106 D22184 4498 4494 0x
Call Trace:
context_switch kernel/sched/core.c:2848 [inline]
__schedule+0x807/0x1e40 kernel/sched/core.c:3490
schedule+0xef/0x430 kernel/sched/core.c:3549
schedule_preempt_disabled+0x10/0x20 kernel/sched/core.c:3607
__mutex_lock_common kernel/locking/mutex.c:833 [inline]
__mutex_lock+0xe38/0x17f0 kernel/locking/mutex.c:893
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
do_ip_vs_set_ctl+0x339/0x1d30 net/netfilter/ipvs/ip_vs_ctl.c:2393
nf_sockopt net/netfilter/nf_sockopt.c:106 [inline]
nf_setsockopt+0x7d/0xd0 net/netfilter/nf_sockopt.c:115
ip_setsockopt+0xd8/0xf0 net/ipv4/ip_sockglue.c:1253
tcp_setsockopt+0x93/0xe0 net/ipv4/tcp.c:2888
sock_common_setsockopt+0x9a/0xe0 net/core/sock.c:3039
smc_setsockopt+0xc7/0x120 net/smc/af_smc.c:1289
__sys_setsockopt+0x1bd/0x390 net/socket.c:1903
SYSC_setsockopt net/socket.c:1914 [inline]
SyS_setsockopt+0x34/0x50 net/socket.c:1911
do_syscall_64+0x29e/0x9d0 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x445959
RSP: 002b:7f2770618db8 EFLAGS: 0246 ORIG_RAX: 0036
RAX: ffda RBX: 006dac24 RCX: 00445959
RDX: 048c RSI: RDI: 0003
RBP: 006dac20 R08: 0018 R09:
R10: 2140 R11: 0246 R12:
R13: 7ffd81ae8f6f R14: 7f27706199c0 R15: 0001
Showing all locks held in the system:
3 locks held by kworker/0:0/4:
#0: 7346131c ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
__write_once_size include/linux/compiler.h:215 [inline]
#0: 7346131c ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
#0: 7346131c ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
atomic64_set include/asm-generic/atomic-instrumented.h:40 [inline]
#0: 7346131c ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
atomic_long_set include/asm-generic/atomic-long.h:57 [inline]
#0: 7346131c ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
set_work_data kernel/workqueue.c:617 [inline]
#0: 7346131c ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
set_work_pool_and_clear_pending kernel/workqueue.c:644 [inline]
#0: 7346131c ((wq_completion)"%s"("ipv6_addrconf")){+.+.}, at:
process_one_work+0xaef/0x1b50 kernel/workqueue.c:2116
#1: 894403a3 ((addr_chk_work).work){+.+.}, at:
process_one_work+0xb46/0x1b50 kernel/workqueue.c:2120
#2: ddc85278 (rtnl_mutex){+.+.}, at: rtnl_lock+0x17/0x20
net/core/rtnetlink.c:74
2 locks held by khungtaskd/877:
#0: 706bfe1c (rcu_read_lock){}, at:
check_hung_uninterruptible_tasks kernel/hung_task.c:175 [inline]
#0: 706bfe1c (rcu_read_lock){}, at: watchdog+0x1ff/0xf60
kernel/hung_task.c:249
#1: 761e40d2 (tasklist_lock){.+.+}, at:
debug_show_all_locks+0xde/0x34a kernel/locking/lockdep.c:4470
2 locks held by getty/4464:
#0: f90a9320 (&tty->ldisc_sem){}, at:
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: 5dd151b8 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131
2 locks held by getty/4465:
#0: 737b5b26 (&tty->ldisc_sem){}, at:
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: 17bb1ae5 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131
2 locks held by getty/4466:
#0: badd071e (&tty->ldisc_sem){}, at:
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: a46de9fa (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131
2 locks held by getty/4467:
#0: 112731eb (&tty->ldisc_sem){}, at:
ldsem_down_r
Re: [PATCH] Revert "xhci: plat: Register shutdown for xhci_plat"
On Fri, Apr 13, 2018 at 08:12:31AM +0530, Harsh Shandilya wrote: > On 13 April 2018 5:59:51 AM IST, Greg Hackmann wrote: > >Pixel 2 field testers reported that when they tried to reboot their > >phones with some USB devices plugged in, the reboot would get wedged > >and > >eventually trigger watchdog reset. Once the Pixel kernel team found a > >reliable repro case, they narrowed it down to this commit's 4.4.y > >backport. Reverting the change made the issue go away. > > Are you allowed to make the repro steps public? I'm writing this from > a walleye and would be grateful if I could test for this in the > modifed tree I'm running atm. -- I was told the steps are pretty simple: - reboot the phone a lot eventually it will hang. There's a fix in the code aurora kernel tree for this that they never sent upstream for some odd reason (they sent the first patch, why not the second?) I'll go revert this for now, thanks for the patch! greg k-h
Re: [PATCH 4/5] dmaengine: sprd: Add Spreadtrum DMA configuration
On 13 April 2018 at 11:43, Vinod Koul wrote:
> On Thu, Apr 12, 2018 at 07:36:34PM +0800, Baolin Wang wrote:
>> >>> >> +/*
>> >>> >> + * struct sprd_dma_config - DMA configuration structure
>> >>> >> + * @config: dma slave channel config
>> >>> >> + * @fragment_len: specify one fragment transfer length
>> >>> >> + * @block_len: specify one block transfer length
>> >>> >> + * @transcation_len: specify one transcation transfer length
>> >>> >> + * @wrap_ptr: wrap pointer address, once the transfer address
>> >>> >> reaches the
>> >>> >> + * 'wrap_ptr', the next transfer address will jump to the 'wrap_to'
>> >>> >> address.
>> >>> >> + * @wrap_to: wrap jump to address
>> >>> >> + * @req_mode: specify the DMA request mode
>> >>> >> + * @int_mode: specify the DMA interrupt type
>> >>> >> + */
>> >>> >> +struct sprd_dma_config {
>> >>> >> + struct dma_slave_config config;
>> >>> >> + u32 fragment_len;
>> >>> >
>> >>> > why not use _maxburst?
>> >>>
>> >>> Yes, I can use maxburst.
>> >>>
>> >>> >
>> >>> >> + u32 block_len;
>> >>> >> + u32 transcation_len;
>> >>> >
>> >>> > what does block and transaction len refer to here
>> >>>
>> >>> Our DMA has 3 transfer mode: transaction transfer, block transfer and
>> >>> fragment transfer. One transaction transfer can contain several blocks
>> >>> transfer, and each block can be set proper block step. One block can
>> >>> contain several fragments transfer with proper fragment step. It can
>> >>> generate interrupts when one transaction transfer or block transfer or
>> >>> fragment transfer is completed if user set the interrupt type. So here
>> >>> we should set the length for transaction transfer, block transfer and
>> >>> fragment transfer.
>> >>
>> >> what are the max size these types support?
>> >
>> > These types max size definition:
>> >
>> > #define SPRD_DMA_FRG_LEN_MASK GENMASK(16, 0)
>> >
>> > #define SPRD_DMA_BLK_LEN_MASK GENMASK(16, 0)
>> >
>> > #define SPRD_DMA_TRSC_LEN_MASK GENMASK(27, 0)
>> >
>> >>>
>> >>> >
>> >>> >> + phys_addr_t wrap_ptr;
>> >>> >> + phys_addr_t wrap_to;
>> >>> >
>> >>> > this sound sg_list to me, why are we not using that here
>> >>>
>> >>> It is similar to sg list, but it is not one software action, we have
>> >>> hardware registers to help to jump one specified address.
>> >>>
>> >>> >
>> >>> >> + enum sprd_dma_req_mode req_mode;
>> >>> >
>> >>> > Looking at definition of request mode we have frag, block, transaction
>> >>> > list
>> >>> > etc.. That should depend upon dma request. If you have been asked to
>> >>> > transfer a list, you shall configure list mode. if it is a single
>> >>> > transaction then it should be transaction mode!
>> >>>
>> >>> If I understand your points correctly, you mean we can specify the
>> >>> request mode when requesting one slave channel by
>> >>> 'dma_request_slave_channel()'. But we need change the request mode
>> >>> dynamically following different transfer task for this channel, so I
>> >>> am afraid we can not specify the request mode of this channel at
>> >>> requesting time.
>> >>
>> >> Nope a channel has nothing to do with request type. You request and grab a
>> >> channel. Then you prepare a descriptor for a dma transaction. Based on
>> >> transaction requested you should intelligently break it down and create a
>> >> descriptor which uses transaction/block/fragment so that DMA throughput is
>> >> efficient. If prepare has sg list then you should use link list mode.
>> >> Further if you support max length, say 16KB and request is for 20KB you
>> >> may
>> >> break it down for link list with two segments.
>> >
>> > OK. So I can add one more cell to specify the request mode for this
>> > channel.
>> >
>> > dmas = <&apdma 11 SPRD_DMA_BLK_REQ>
>> >
>> >>
>> >> Each prep call has flags associated, that can help you configure interrupt
>> >> behaviour.
>>
>> After more thinking, I think this will be not useful for users, since
>> users need configure one DMA channel through different 3 places,
>> specify the request mode in dts, specify the interrupt type through
>> prep call flags, and other configuration need to be configured through
>> 'struct sprd_dma_config'. That is not one good design for users. What
>> do you think? Thanks.
>
> Agreed, users only care about grabbing a channel, setting a descriptor and
> submitting that.
>
> I think you need to go back and think about this a bit, please do go thru
> dmaengine documentation and see other driver examples.
>
> We don't typically expose these to users, they give us a transfer and we set
> that up in hardware for efficient. Its DMA so people expect us to use fastest
> mechanism available.
But there are some configuration are really special for Spreadtrum
DMA, and must need user to specify how to configure, especially some
scenarios of audio. So I wander if we can add one pointer for
'dma_slave_config' to expand some special DMA configuration
requirements, like:
struct dma_slave_config {
..
unsigned int
Re: [PATCH 08/14] ARM: OMAP2: Add functions to save and restore pinctrl context.
On Thursday 12 April 2018 07:46 PM, Tony Lindgren wrote: > Hi, > > * Keerthy [180412 03:56]: >> From: Russ Dill >> >> This adds a pair of context save/restore functions to save/restore the >> state of a set of pinctrl registers. This simplifies some of the AM33XX >> PM code as some of the pinctrl registers are lost when the per power >> domain loses power. The pincrtl code can perform the necessary >> save/restore. > > So where's the patch adding callers to this code? This series was to get all the additional save/restores needed for the rtc+ddr mode. Caller patch is in the main patch that implements that mode that i will be posting once the ground is set. Based on enable_off_mode being set this function was called only for rtc+ddr mode. > > If this cannot be done from regular driver suspend/resume calls, > this probably should be done from cpu_pm notifiers CPU_PM_ENTER and > CPU_PM_EXIT. We should also do the same for GPIO BTW. I will look into that. Thanks for suggestion. > > BTW, the subject line is wrong here, it should be "pinctrl" :) Oops yes that should be pinctrl. > > Regards, > > Tony >
Re: [PATCH] f2fs: set deadline to drop expired inmem pages
On 2018/4/13 12:05, Jaegeuk Kim wrote: > On 04/13, Chao Yu wrote: >> On 2018/4/13 9:04, Jaegeuk Kim wrote: >>> On 04/10, Chao Yu wrote: Hi Jaegeuk, On 2018/4/8 16:13, Chao Yu wrote: > f2fs doesn't allow abuse on atomic write class interface, so except > limiting in-mem pages' total memory usage capacity, we need to limit > start-commit time as well, otherwise we may run into infinite loop > during foreground GC because target blocks in victim segment are > belong to atomic opened file for long time. > > Now, we will check the condition with f2fs_balance_fs_bg in > background threads, once if user doesn't commit data exceeding 30 > seconds, we will drop all cached data, so I expect it can keep our > system running safely to prevent Dos attack. Is it worth to add this patch to avoid abuse on atomic write interface by user? >>> >>> Hmm, hope to see a real problem first in this case. >> >> I think this can be a more critical security leak instead of a potential >> issue >> which we can wait for someone reporting that can be too late. >> >> For example, user can simply write a huge file whose data spread in all f2fs >> segments, once user open that file as atomic, foreground GC will suffer >> deadloop, causing denying any further service of f2fs. > > How can you guarantee it won't happen within 30sec? If you want to avoid that, Now the value is smaller than generic hang task threshold in order to avoid foreground GC helding gc_mutex too long, we can tune that parameter? > you have to take a look at foreground gc. What do you mean? let GC moves blocks of atomic write opened file? Thanks, > >> >> Thanks, >> >>> Thanks, >>> >>> . >>> > > . >
Re: [PATCH 3/5] net: stmmac: dwmac-sun8i: Allow getting syscon regmap from device
Hi Chen-Yu, I love your patch! Perhaps something to improve: [auto build test WARNING on robh/for-next] [also build test WARNING on v4.16 next-20180412] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Icenowy-Zheng/Add-support-in-dwmac-sun8i-for-accessing-EMAC-clock/20180413-004816 base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next reproduce: # apt-get install sparse make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c:82:24: sparse: symbol 'old_syscon_reg_field' was not declared. Should it be static? >> drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c:89:24: sparse: symbol >> 'single_reg_field' was not declared. Should it be static? Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation
[RFC PATCH] net: stmmac: dwmac-sun8i: single_reg_field can be static
Fixes: 529123418105 ("net: stmmac: dwmac-sun8i: Allow getting syscon regmap
from device")
Signed-off-by: Fengguang Wu
---
dwmac-sun8i.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index b61210c..842315a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -86,7 +86,7 @@ const struct reg_field old_syscon_reg_field = {
};
/* Specially exported regmap which contains only EMAC register */
-const struct reg_field single_reg_field = {
+static const struct reg_field single_reg_field = {
.reg = 0,
.lsb = 0,
.msb = 31,
Re: [PATCH v2 04/21] kconfig: reference environments directly and remove 'option env=' syntax
2018-04-01 11:27 GMT+09:00 Ulf Magnusson : > Here's a more in-depth review: > > On Tue, Mar 27, 2018 at 7:29 AM, Masahiro Yamada > wrote: >> To get an environment value, Kconfig needs to define a symbol using >> "option env=" syntax. It is tedious to add a config entry for each >> environment given that we need more environments such as 'CC', 'AS', > > "Environment variables" would be clearer. I've never seen them called > "environments". > >> 'srctree' etc. to evaluate the compiler capability in Kconfig. >> >> Adding '$' to symbols is weird. Kconfig can reference symbols directly >> like this: >> >> config FOO >> string >> default BAR >> >> So, I want to use the following syntax to get environment 'BAR' from >> the system: >> >> config FOO >> string >> default $BAR >> >> Looking at the code, the symbols prefixed with 'S' are expanded by: >> - conf_expand_value() >>This is used to expand 'arch/$ARCH/defconfig' and 'defconfig_list' >> - expand_string_value() >>This is used to expand strings in 'source' and 'mainmenu' >> >> All of them are fixed values independent of user configuration. So, >> this kind of syntax should be moved to simply take the environment. >> >> This change makes the code much cleaner. The bounce symbols 'SRCARCH', >> 'ARCH', 'SUBARCH', 'KERNELVERSION' are gone. >> >> sym_init() hard-coding 'UNAME_RELEASE' is also gone. 'UNAME_RELEASE' >> should be be given from the environment. >> >> ARCH_DEFCONFIG is a normal symbol, so it should be simply referenced >> by 'default ARCH_DEFCONFIG'. >> >> The environments are expanding in the lexer; when '$' is encountered, > > s/environments/environment variables/ > >> it is expanded, and resulted strings are pushed back to the input >> stream. This makes the implementation simpler. >> >> For example, the following code works. >> >> [Example code] >> >> config TOOLCHAIN_LIST >> string >> default "My tools: CC=$CC, AS=$AS, CPP=$CPP" >> >> [Result] >> >> $ make -s alldefconfig && tail -n 1 .config >> CONFIG_TOOLCHAIN_LIST="My tools: CC=gcc, AS=as, CPP=gcc -E" >> >> Signed-off-by: Masahiro Yamada >> --- >> >> I tested all 'make *config' for arch architectures. >> I confirmed this commit still produced the same result >> (by my kconfig test tool). >> >> >> Changes in v2: >> - Move the string expansion to the lexer phase. >> - Split environment helpers to env.c >> >> Documentation/kbuild/kconfig-language.txt | 8 --- >> Kconfig | 4 -- >> Makefile | 3 +- >> arch/sh/Kconfig | 4 +- >> arch/sparc/Kconfig| 4 +- >> arch/tile/Kconfig | 2 +- >> arch/um/Kconfig.common| 4 -- >> arch/x86/Kconfig | 4 +- >> arch/x86/um/Kconfig | 4 +- >> init/Kconfig | 10 +--- >> scripts/kconfig/confdata.c| 31 +- >> scripts/kconfig/env.c | 95 >> +++ >> scripts/kconfig/kconf_id.c| 1 - >> scripts/kconfig/lkc.h | 8 +-- >> scripts/kconfig/menu.c| 3 - >> scripts/kconfig/symbol.c | 56 -- >> scripts/kconfig/util.c| 75 >> scripts/kconfig/zconf.l | 20 ++- >> scripts/kconfig/zconf.y | 2 +- >> 19 files changed, 158 insertions(+), 180 deletions(-) >> create mode 100644 scripts/kconfig/env.c >> >> diff --git a/Documentation/kbuild/kconfig-language.txt >> b/Documentation/kbuild/kconfig-language.txt >> index f5b9493..0e966e8 100644 >> --- a/Documentation/kbuild/kconfig-language.txt >> +++ b/Documentation/kbuild/kconfig-language.txt >> @@ -198,14 +198,6 @@ applicable everywhere (see syntax). >> enables the third modular state for all config symbols. >> At most one symbol may have the "modules" option set. >> >> - - "env"= >> -This imports the environment variable into Kconfig. It behaves like >> -a default, except that the value comes from the environment, this >> -also means that the behaviour when mixing it with normal defaults is >> -undefined at this point. The symbol is currently not exported back >> -to the build environment (if this is desired, it can be done via >> -another symbol). >> - > > The new behavior needs to be documented later as well (but iirc you > already mentioned that somewhere else). > >>- "allnoconfig_y" >> This declares the symbol as one that should have the value y when >> using "allnoconfig". Used for symbols that hide other symbols. >> diff --git a/Kconfig b/Kconfig >> index 8c4c1cb..e6ece5b 100644 >> --- a/Kconfig >> +++ b/Kconfig >> @@ -5,8 +5,4 @@ >> # >> mainmenu "Linux/$ARCH $KERNELVERSION Kernel Configuration" >> >> -con
Re: [PATCH 00/30] kconfig: move compiler capability tests to Kconfig
On Thu, Apr 12, 2018 at 10:06 PM, Masahiro Yamada wrote: > [Major Changes in V3] Awesome work! I don't see this pushed to your git tree? I'd like to test it, but I'd rather "git fetch" instead of "git am" :) -Kees -- Kees Cook Pixel Security
Re: [PATCH v2 09/21] kconfig: add 'macro' keyword to support user-defined function
2018-04-01 15:05 GMT+09:00 Ulf Magnusson :
> On Tue, Mar 27, 2018 at 7:29 AM, Masahiro Yamada
> wrote:
>> Now, we got a basic ability to test compiler capability in Kconfig.
>>
>> config CC_HAS_STACKPROTECTOR
>> def_bool $(shell (($CC -Werror -fstack-protector -c -x c /dev/null
>> -o /dev/null) && echo y) || echo n)
>>
>> This works, but it is ugly to repeat this long boilerplate.
>>
>> We want to describe like this:
>>
>> config CC_HAS_STACKPROTECTOR
>> bool
>> default $(cc-option -fstack-protector)
>>
>> It is straight-forward to add a new function, but I do not like to
>> hard-code specialized functions like this. Hence, here is another
>> feature to add functions from Kconfig files.
>>
>> A user-defined function is defined with a special keyword 'macro'.
>> It can be referenced in the same way as built-in functions. This
>> feature was also inspired by Makefile where user-defined functions
>> are referenced by $(call func-name, args...), but I omitted the 'call'
>> to makes it shorter.
>>
>> The macro definition can contain $(1), $(2), ... which will be replaced
>> with arguments from the caller. The macro works just as a textual
>> shorthand, which is also expanded in the lexer phase.
>>
>> [Example Code]
>>
>> macro success $(shell ($(1) && echo y) || echo n)
>>
>> config TRUE
>> bool "true"
>> default $(success true)
>>
>> config FALSE
>> bool "false"
>> default $(success false)
>>
>> [Result]
>>
>> $ make -s alldefconfig
>> $ tail -n 2 .config
>> CONFIG_TRUE=y
>> # CONFIG_FALSE is not set
>>
>> [Example Code]
>>
>> macro success $(shell ($(1) && echo y) || echo n)
>>
>> macro cc-option $(success $CC -Werror $(1) -c -x c /dev/null -o /dev/null)
>>
>> config CC_HAS_STACKPROTECTOR
>> def_bool $(cc-option -fstack-protector)
>>
>> [Result]
>> $ make -s alldefconfig
>> $ tail -n 1 .config
>> CONFIG_CC_HAS_STACKPROTECTOR=y
>>
>> Signed-off-by: Masahiro Yamada
>> ---
>>
>> Reminder for myself:
>> Update Documentation/kbuild/kconfig-language.txt
>>
>> Changes in v2:
>> - Use 'macro' directly instead of inside the string type symbol.
>>
>> scripts/kconfig/function.c | 59
>> +++--
>> scripts/kconfig/lkc_proto.h | 1 +
>> scripts/kconfig/zconf.l | 31
>> 3 files changed, 89 insertions(+), 2 deletions(-)
>>
>> diff --git a/scripts/kconfig/function.c b/scripts/kconfig/function.c
>> index 913685f..389bb44 100644
>> --- a/scripts/kconfig/function.c
>> +++ b/scripts/kconfig/function.c
>> @@ -15,6 +15,7 @@ static LIST_HEAD(function_list);
>> struct function {
>> char *name;
>> char *(*func)(struct function *f, int argc, char *argv[]);
>> + char *macro;
>> struct list_head node;
>> };
>>
>> @@ -31,7 +32,8 @@ static struct function *func_lookup(const char *name)
>> }
>>
>> static void func_add(const char *name,
>> -char *(*func)(struct function *f, int argc, char
>> *argv[]))
>> +char *(*func)(struct function *f, int argc, char
>> *argv[]),
>> +const char *macro)
>> {
>> struct function *f;
>>
>> @@ -44,6 +46,7 @@ static void func_add(const char *name,
>> f = xmalloc(sizeof(*f));
>> f->name = xstrdup(name);
>> f->func = func;
>> + f->macro = macro ? xstrdup(macro) : NULL;
>>
>> list_add_tail(&f->node, &function_list);
>> }
>> @@ -51,6 +54,7 @@ static void func_add(const char *name,
>> static void func_del(struct function *f)
>> {
>> list_del(&f->node);
>> + free(f->macro);
>> free(f->name);
>> free(f);
>> }
>> @@ -108,6 +112,57 @@ char *func_eval_n(const char *func, size_t n)
>> return res;
>> }
>>
>> +/* run user-defined function */
>> +static char *do_macro(struct function *f, int argc, char *argv[])
>> +{
>> + char *new;
>> + char *src, *p, *res;
>> + size_t newlen;
>> + int n;
>> +
>> + new = xmalloc(1);
>> + *new = 0;
>
> new = '\0' would be consistent with the rest of the code.
>
>> +
>> + /*
>> +* This is a format string. $(1), $(2), ... must be replaced with
>> +* function arguments.
>> +*/
>> + src = f->macro;
>> + p = src;
>> +
>> + while ((p = strstr(p, "$("))) {
>> + if (isdigit(p[2]) && p[3] == ')') {
>> + n = p[2] - '0';
>> + if (n < argc) {
>> + newlen = strlen(new) + (p - src) +
>> + strlen(argv[n]) + 1;
>> + new = xrealloc(new, newlen);
>> + strncat(new, src, p - src);
>> + strcat(new, argv[n]);
>> + src = p + 4;
>> + }
>
> Might be nice to warn when a macro call has missing argu
Re: [PATCH 4/5] dmaengine: sprd: Add Spreadtrum DMA configuration
On 13 April 2018 at 11:39, Vinod Koul wrote: > On Thu, Apr 12, 2018 at 07:30:01PM +0800, Baolin Wang wrote: > >> >> > what does block and transaction len refer to here >> >> >> >> Our DMA has 3 transfer mode: transaction transfer, block transfer and >> >> fragment transfer. One transaction transfer can contain several blocks >> >> transfer, and each block can be set proper block step. One block can >> >> contain several fragments transfer with proper fragment step. It can >> >> generate interrupts when one transaction transfer or block transfer or >> >> fragment transfer is completed if user set the interrupt type. So here >> >> we should set the length for transaction transfer, block transfer and >> >> fragment transfer. >> > >> > what are the max size these types support? >> >> These types max size definition: >> >> #define SPRD_DMA_FRG_LEN_MASK GENMASK(16, 0) >> >> #define SPRD_DMA_BLK_LEN_MASK GENMASK(16, 0) >> >> #define SPRD_DMA_TRSC_LEN_MASK GENMASK(27, 0) > > They are register defines. How many items or bytes do each type of txn > support? These macros are the max size definitions, for example one fragment length can support to 0x1 bytes, one transaction transfer can support to 0xfff. -- Baolin.wang Best Regards
Re: [GIT PULL] Thermal management updates for v4.17-rc1
Hi, Eduardo,
On 四, 2018-04-12 at 21:08 -0700, Eduardo Valentin wrote:
> Hello,
>
> On Thu, Apr 12, 2018 at 09:55:19AM -0700, Linus Torvalds wrote:
> >
> > On Wed, Apr 11, 2018 at 10:08 PM, Zhang Rui
> > wrote:
> > >
> > >
> > > could you please illustrate me what the kconfig & warning is?
> > Just "make allmodconfig" and the warning is about a uninitialized
> > variable.
> >
> > Line 304 in drivers/thermal/samsung/exynos_tmu.c if my shell
> > history
> > is to be believed.
> >
> > Linus
> Yeah, this has also passed my local compilation error. Somehow my
> gcc4.9
> is not catching it. Using an older gcc (gcc4.6) does catch it.
>
> Anyways, given that the conversion functions are written to cover
> for unexpected cal_type, the right way of fixing this is to rewrite
> the conversion functions to allow for returning error codes and
> adjusting the callers as expected.
>
> Rui, bzolnier, please consider the following fix:
>
as it is late in this merge window, I'd prefer to
1. drop all the thermal-soc material in the first pull request which I
will send out soon.
2. you can prepare another pull request containing the thermal-soc
materials except the exynos fixes
3. exynos fixes with the problem solved can be queued for -rc2 or
later.
thanks,
rui
> From 2aaf94f80c0021a21b4122c9f4197acff08ea398 Mon Sep 17 00:00:00
> 2001
> From: Eduardo Valentin
> Date: Thu, 12 Apr 2018 21:00:48 -0700
> Subject: [PATCH 1/1] thermal: exynos: fix compilation warning around
> conversion functions
>
> In order to fix the warns:
> drivers/thermal/samsung/exynos_tmu.c:931:37: warning: 'temp' may be
> used uninitialized in this function [-Wmaybe-uninitialized]
> drivers/thermal/samsung/exynos_tmu.c:304:9: warning: 'temp_code' may
> be used uninitialized in this function [-Wmaybe-uninitialized]
>
> the conversion functions should allow return error codes
> and the not mix the converted value with error code.
>
> This patch change the conversion functions to return
> error code or success and adjusts the callers accordingly.
>
> Signed-off-by: Eduardo Valentin
> ---
> drivers/thermal/samsung/exynos_tmu.c | 120 -
> --
> 1 file changed, 84 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c
> index 2ec8548..b3f0704 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -282,52 +282,54 @@ static void exynos_report_trigger(struct
> exynos_tmu_data *p)
> * TMU treats temperature as a mapped temperature code.
> * The temperature is converted differently depending on the
> calibration type.
> */
> -static int temp_to_code(struct exynos_tmu_data *data, u8 temp)
> +static int temp_to_code(struct exynos_tmu_data *data, u8 temp, int
> *temp_code)
> {
> - int temp_code;
> + int ret = 0;
>
> switch (data->cal_type) {
> case TYPE_TWO_POINT_TRIMMING:
> - temp_code = (temp - EXYNOS_FIRST_POINT_TRIM) *
> + *temp_code = (temp - EXYNOS_FIRST_POINT_TRIM) *
> (data->temp_error2 - data->temp_error1) /
> (EXYNOS_SECOND_POINT_TRIM -
> EXYNOS_FIRST_POINT_TRIM) +
> data->temp_error1;
> break;
> case TYPE_ONE_POINT_TRIMMING:
> - temp_code = temp + data->temp_error1 -
> EXYNOS_FIRST_POINT_TRIM;
> + *temp_code = temp + data->temp_error1 -
> EXYNOS_FIRST_POINT_TRIM;
> break;
> default:
> WARN_ON(1);
> + ret = -EINVAL;
> break;
> }
>
> - return temp_code;
> + return ret;
> }
>
> /*
> * Calculate a temperature value from a temperature code.
> * The unit of the temperature is degree Celsius.
> */
> -static int code_to_temp(struct exynos_tmu_data *data, u16 temp_code)
> +static int code_to_temp(struct exynos_tmu_data *data, u16 temp_code,
> int *temp)
> {
> - int temp;
> + int ret = 0;
>
> switch (data->cal_type) {
> case TYPE_TWO_POINT_TRIMMING:
> - temp = (temp_code - data->temp_error1) *
> + *temp = (temp_code - data->temp_error1) *
> (EXYNOS_SECOND_POINT_TRIM -
> EXYNOS_FIRST_POINT_TRIM) /
> (data->temp_error2 - data->temp_error1) +
> EXYNOS_FIRST_POINT_TRIM;
> break;
> case TYPE_ONE_POINT_TRIMMING:
> - temp = temp_code - data->temp_error1 +
> EXYNOS_FIRST_POINT_TRIM;
> + *temp = temp_code - data->temp_error1 +
> EXYNOS_FIRST_POINT_TRIM;
> break;
> default:
> WARN_ON(1);
> + ret = -EINVAL;
> break;
> }
>
> - return temp;
> + return ret;
> }
>
> static void sanitize_temp_error(struct exynos_tmu_data *data, u32
> trim_info)
> @@ -352,7 +354,7 @@ static u32 get_th_reg(struct exynos_tmu_data
> *data, u32 thr
Re: [PATCH 1/5] random: fix crng_ready() test
Am Freitag, 13. April 2018, 03:30:42 CEST schrieb Theodore Ts'o: Hi Theodore, > The crng_init variable has three states: > > 0: The CRNG is not initialized at all > 1: The CRNG has a small amount of entropy, hopefully good enough for >early-boot, non-cryptographical use cases > 2: The CRNG is fully initialized and we are sure it is safe for >cryptographic use cases. > > The crng_ready() function should only return true once we are in the > last state. > Do I see that correctly that getrandom(2) will now unblock after the input_pool has obtained 128 bits of entropy? Similarly for get_random_bytes_wait. As this seems to be the only real use case for crng_ready (apart from logging), what is the purpose of crng_init == 1? Ciao Stephan
Re: [PATCH v2 07/21] kconfig: add function support and implement 'shell' function
2018-04-01 13:19 GMT+09:00 Ulf Magnusson :
> On Tue, Mar 27, 2018 at 7:29 AM, Masahiro Yamada
> wrote:
>> This commit adds a new concept 'function' to do more text processing
>> in Kconfig.
>>
>> A function call looks like this:
>>
>> $(function arg1, arg2, arg3, ...)
>>
>> (Actually, this syntax was inspired by make.)
>>
>> Real examples will look like this:
>>
>> $(shell echo hello world)
>> $(cc-option -fstackprotector)
>>
>> This commit adds the basic infrastructure to add, delete, evaluate
>> functions, and also the first built-in function $(shell ...). This
>> accepts a single command to execute. It returns the standard output
>> from it.
>>
>> [Example code]
>>
>> config HELLO
>> string
>> default "$(shell echo hello world)"
>>
>> config Y
>> def_bool $(shell echo y)
>>
>> [Result]
>>
>> $ make -s alldefconfig && tail -n 2 .config
>> CONFIG_HELLO="hello world"
>> CONFIG_Y=y
>>
>> Caveat:
>> Like environments, functions are expanded in the lexer. You cannot
>> pass symbols to function arguments. This is a limitation to simplify
>> the implementation. I want to avoid the dynamic function evaluation,
>> which would introduce much more complexity.
>>
>> Signed-off-by: Masahiro Yamada
>> ---
>>
>> Reminder for myself:
>> Update Documentation/kbuild/kconfig-language.txt
>>
>>
>> Changes in v2:
>> - Use 'shell' for getting stdout from the comment.
>> It was 'shell-stdout' in the previous version.
>> - Symplify the implementation since the expansion has been moved to
>> lexer.
>>
>> scripts/kconfig/function.c | 170
>>
>> scripts/kconfig/lkc_proto.h | 5 ++
>> scripts/kconfig/util.c | 46 +---
>> scripts/kconfig/zconf.y | 9 +++
>> 4 files changed, 222 insertions(+), 8 deletions(-)
>> create mode 100644 scripts/kconfig/function.c
>>
>> diff --git a/scripts/kconfig/function.c b/scripts/kconfig/function.c
>> new file mode 100644
>> index 000..913685f
>> --- /dev/null
>> +++ b/scripts/kconfig/function.c
>> @@ -0,0 +1,170 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +//
>> +// Copyright (C) 2018 Masahiro Yamada
>> +
>> +#include
>> +#include
>> +#include
>> +
>> +#include "list.h"
>> +
>> +#define FUNCTION_MAX_ARGS 10
>> +
>> +static LIST_HEAD(function_list);
>> +
>> +struct function {
>> + char *name;
>> + char *(*func)(struct function *f, int argc, char *argv[]);
>> + struct list_head node;
>> +};
>> +
>> +static struct function *func_lookup(const char *name)
>> +{
>> + struct function *f;
>> +
>> + list_for_each_entry(f, &function_list, node) {
>> + if (!strcmp(name, f->name))
>> + return f;
>> + }
>> +
>> + return NULL;
>> +}
>> +
>> +static void func_add(const char *name,
>> +char *(*func)(struct function *f, int argc, char
>> *argv[]))
>> +{
>> + struct function *f;
>> +
>> + f = func_lookup(name);
>> + if (f) {
>> + fprintf(stderr, "%s: function already exists. ignored.\n",
>> name);
>> + return;
>> + }
>> +
>> + f = xmalloc(sizeof(*f));
>> + f->name = xstrdup(name);
>> + f->func = func;
>> +
>> + list_add_tail(&f->node, &function_list);
>> +}
>> +
>> +static void func_del(struct function *f)
>> +{
>> + list_del(&f->node);
>> + free(f->name);
>> + free(f);
>> +}
>> +
>> +static char *func_call(int argc, char *argv[])
>> +{
>> + struct function *f;
>> +
>> + f = func_lookup(argv[0]);
>> + if (!f) {
>> + fprintf(stderr, "%s: function not found\n", argv[0]);
>> + return NULL;
>> + }
>> +
>> + return f->func(f, argc, argv);
>> +}
>> +
>> +static char *func_eval(const char *func)
>> +{
>> + char *expanded, *saveptr, *str, *token, *res;
>> + const char *delim;
>> + int argc = 0;
>> + char *argv[FUNCTION_MAX_ARGS];
>> +
>> + expanded = expand_string_value(func);
>> +
>> + str = expanded;
>> + delim = " ";
>> +
>> + while ((token = strtok_r(str, delim, &saveptr))) {
>> + argv[argc++] = token;
>
> Would be nice to error out if the array is overstepped.
In V3, I made this a feature.
>> + str = NULL;
>> + delim = ",";
>> + }
>> +
>> + res = func_call(argc, argv);
>> +
>> + free(expanded);
>> +
>> + return res ?: xstrdup("");
>> +}
>
> Since only 'macro' will take multiple parameters, I wonder if it might
> be better to implement the argument parsing there, and simply pass the
> string (minus the function name) as-is to functions.
I may add more built-in functions in the future.
For example, I want to add 'if' function, which takes two or three arguments.
> You would then be able to have ',' in shell commands, which might be
> required -- think gcc -Wl,option and the like.
I fixed 'shell' functi
Re: [PATCH v2 07/21] kconfig: add function support and implement 'shell' function
2018-03-28 12:41 GMT+09:00 Kees Cook :
> On Mon, Mar 26, 2018 at 10:29 PM, Masahiro Yamada
> wrote:
>> This commit adds a new concept 'function' to do more text processing
>> in Kconfig.
>>
>> A function call looks like this:
>>
>> $(function arg1, arg2, arg3, ...)
>>
>> (Actually, this syntax was inspired by make.)
>>
>> Real examples will look like this:
>>
>> $(shell echo hello world)
>> $(cc-option -fstackprotector)
>>
>> This commit adds the basic infrastructure to add, delete, evaluate
>> functions, and also the first built-in function $(shell ...). This
>> accepts a single command to execute. It returns the standard output
>> from it.
>>
>> [Example code]
>>
>> config HELLO
>> string
>> default "$(shell echo hello world)"
>>
>> config Y
>> def_bool $(shell echo y)
>>
>> [Result]
>>
>> $ make -s alldefconfig && tail -n 2 .config
>> CONFIG_HELLO="hello world"
>> CONFIG_Y=y
>>
>> Caveat:
>> Like environments, functions are expanded in the lexer. You cannot
>> pass symbols to function arguments. This is a limitation to simplify
>> the implementation. I want to avoid the dynamic function evaluation,
>> which would introduce much more complexity.
>>
>> Signed-off-by: Masahiro Yamada
>> ---
>>
>> Reminder for myself:
>> Update Documentation/kbuild/kconfig-language.txt
>
> Yeah, this needs to be included here, especially given the "cannot
> pass symbols" aspect which might surprise people.
>
>> [...]
>> +/* built-in functions */
>> +static char *do_shell(struct function *f, int argc, char *argv[])
>> +{
>> + static const char *pre = "(";
>> + static const char *post = ") 2>/dev/null";
>
> Right now the search and help screens in menuconfig just show the line
> a config is defined and nothing more. I think it would be extremely
> handy to include shell output here in some way.
The current implementation cannot do this.
The $(shell ...) has already expanded
before the parser receives tokens.
There is no way to know whether a token came from a source file as-is,
or it was derived from textual substitution.
> Especially when trying
> to answer questions like "why aren't GCC plugins available?" it's got
> quite a bit harder to debug.
> Could we capture the output (especially stderr) for these kinds of hints?
For example, it would be possible to dump the result of $(shell ...)
evaluation into the console in debug mode.
> Beyond that, looks good!
>
> -Kees
>
> --
> Kees Cook
> Pixel Security
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards
Masahiro Yamada
Re: [GIT PULL] Thermal management updates for v4.17-rc1
On 四, 2018-04-12 at 21:08 -0700, Eduardo Valentin wrote: > Hello, > > On Thu, Apr 12, 2018 at 09:55:19AM -0700, Linus Torvalds wrote: > > > > On Wed, Apr 11, 2018 at 10:08 PM, Zhang Rui > > wrote: > > > > > > > > > could you please illustrate me what the kconfig & warning is? > > Just "make allmodconfig" and the warning is about a uninitialized > > variable. > > > > Line 304 in drivers/thermal/samsung/exynos_tmu.c if my shell > > history > > is to be believed. > > > > Linus > Yeah, this has also passed my local compilation error. Somehow my > gcc4.9 > is not catching it. Using an older gcc (gcc4.6) does catch it. > I think there are two problems here 1. Actually, this error has been raised by 0-day earlier. https://marc.info/?l=linux-pm&m=152107340117077&w=2 Don't know why it still goes into thermal-soc tree. 2. After pulled the thermal-soc changes, I also asked 0-day to run build test, but I didn't get any warning report (email attached), CC Philip and Shun to look at this issue. thanks, rui bin_6r1piPKmQ.bin Description: application/mbox
[PATCH] timekeeping: Remove __current_kernel_time()
The __current_kernel_time() function based on 'struct timespec' is no
longer recommended for new code, and the only user of this function
has been replaced by commit 6909e29fdefb ("kdb: use
__ktime_get_real_seconds instead of __current_kernel_time"). So now we
can remove this obsolete interface.
Signed-off-by: Baolin Wang
---
include/linux/timekeeping32.h |3 ---
kernel/time/timekeeping.c |7 ---
2 files changed, 10 deletions(-)
diff --git a/include/linux/timekeeping32.h b/include/linux/timekeeping32.h
index af4114d..3616b4b 100644
--- a/include/linux/timekeeping32.h
+++ b/include/linux/timekeeping32.h
@@ -9,9 +9,6 @@
extern void do_gettimeofday(struct timeval *tv);
unsigned long get_seconds(void);
-/* does not take xtime_lock */
-struct timespec __current_kernel_time(void);
-
static inline struct timespec current_kernel_time(void)
{
struct timespec64 now = current_kernel_time64();
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index ca90219..dcf7f20 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -2139,13 +2139,6 @@ unsigned long get_seconds(void)
}
EXPORT_SYMBOL(get_seconds);
-struct timespec __current_kernel_time(void)
-{
- struct timekeeper *tk = &tk_core.timekeeper;
-
- return timespec64_to_timespec(tk_xtime(tk));
-}
-
struct timespec64 current_kernel_time64(void)
{
struct timekeeper *tk = &tk_core.timekeeper;
--
1.7.9.5
Re: Crashes/hung tasks with z3pool under memory pressure
Hi Guenter,
Den fre 13 apr. 2018 kl 00:01 skrev Guenter Roeck :
> Hi all,
> we are observing crashes with z3pool under memory pressure. The kernel
version
> used to reproduce the problem is v4.16-11827-g5d1365940a68, but the
problem was
> also seen with v4.14 based kernels.
just before I dig into this, could you please try reproducing the errors
you see with https://patchwork.kernel.org/patch/10210459/ applied?
Thanks,
Vitaly
> For simplicity, here is a set of shortened logs. A more complete log is
> available at [1].
> [ cut here ]
> DEBUG_LOCKS_WARN_ON((preempt_count() & PREEMPT_MASK) >= PREEMPT_MASK - 10)
> WARNING: CPU: 2 PID: 594 at kernel/sched/core.c:3212
preempt_count_add+0x90/0xa0
> Modules linked in:
> CPU: 2 PID: 594 Comm: memory-eater Not tainted 4.16.0-yocto-standard+ #8
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.10.2-1
04/01/2014
> RIP: 0010:preempt_count_add+0x90/0xa0
> RSP: :b12740db7750 EFLAGS: 00010286
> RAX: RBX: 0001 RCX: 00f6
> RDX: 00f6 RSI: 0082 RDI:
> RBP: f00480f357a0 R08: 004a R09: 01ad
> R10: b12740db77e0 R11: R12: 9cbc7e265d10
> R13: 9cbc7cd5e000 R14: 9cbc7a7000d8 R15: f00480f35780
> FS: 7f5140791700() GS:9cbc7fd0()
knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 7f513260f000 CR3: 32086000 CR4: 06e0
> Call Trace:
> _raw_spin_trylock+0x13/0x30
> z3fold_zpool_shrink+0xab/0x3a0
> zswap_frontswap_store+0x10b/0x610
> ...
> WARNING: CPU: 1 PID: 92 at mm/z3fold.c:278
release_z3fold_page_locked+0x25/0x40
> Modules linked in:
> ...
> INFO: rcu_preempt self-detected stall on CPU
> 2-...!: (20958 ticks this GP) idle=5da/1/4611686018427387906
> softirq=4104/4113 fqs=11
> ...
> RIP: 0010:queued_spin_lock_slowpath+0x132/0x190
> RSP: :b12740db7750 EFLAGS: 0202 ORIG_RAX: ff13
> RAX: 00100101 RBX: 9cbc7a7000c8 RCX: 0001
> RDX: 0101 RSI: 0001 RDI: 0101
> RBP: R08: 9cbc7fc21240 R09: af19c900
> R10: b12740db75a0 R11: 0010 R12: f00480522d20
> R13: 9cbc548b4000 R14: 9cbc7a7000d8 R15: f00480522d00
> ? __zswap_pool_current+0x80/0x90
> z3fold_zpool_shrink+0x1d3/0x3a0
> zswap_frontswap_store+0x10b/0x610
> ...
> With lock debugging enabled, the log is a bit different, but similar.
> BUG: MAX_LOCK_DEPTH too low!
> turning off the locking correctness validator.
> depth: 48 max: 48!
> 48 locks held by memory-eater/619:
> #0: 2da807ce (&mm->mmap_sem){}, at:
__do_page_fault+0x122/0x5a0
> #1: 12fa6629 (&(&pool->lock)->rlock#3){+.+.}, at:
z3fold_zpool_shrink+0x47/0x3e0
> #2: c85f45dd (&(&zhdr->page_lock)->rlock){+.+.}, at:
z3fold_zpool_shrink+0xb7/0x3e0
> #3: 876f5fdc (&(&zhdr->page_lock)->rlock){+.+.}, at:
z3fold_zpool_shrink+0xb7/0x3e0
> ...
> watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [memory-eater:613]
> Modules linked in:
> irq event stamp: 1435394
> hardirqs last enabled at (1435393): []
> _raw_spin_unlock_irqrestore+0x51/0x60
> hardirqs last disabled at (1435394): []
__schedule+0xba/0xbb0
> softirqs last enabled at (1434508): []
__do_softirq+0x27c/0x516
> softirqs last disabled at (1434323): []
irq_exit+0xa9/0xc0
> CPU: 0 PID: 613 Comm: memory-eater Tainted: GW
> 4.16.0-yocto-standard+ #9
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.10.2-1
04/01/2014
> RIP: 0010:queued_spin_lock_slowpath+0x177/0x1a0
> RSP: :a61f80e074e0 EFLAGS: 0246 ORIG_RAX: ff13
> RAX: RBX: 9704379cba08 RCX: 97043fc22080
> RDX: 0001 RSI: 9c05f6a0 RDI: 0004
> RBP: R08: 9b1f2215 R09:
> R10: a61f80e07490 R11: 9704379cba20 R12: 97043fc22080
> R13: de77404e0920 R14: 970413824000 R15: 9704379cba00
> FS: 7f8c6317f700() GS:97043fc0()
knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 7f8c43f3d010 CR3: 3aba CR4: 06f0
> Call Trace:
> do_raw_spin_lock+0xad/0xb0
> z3fold_zpool_malloc+0x595/0x790
> ...
> The problem is easy to reproduce. Please see [2] and the other files
> at [3] for details. Various additional crash logs, observed with
> chromeos-4.14, are available at [4].
> Please let me know if there is anything else I can do to help solving
> or debugging the problem. I had a look into the code, but I must admit
> that its locking is a mystery to me.
> Thanks,
> Guenter
> ---
> [1] http://server.roeck-us.net/qemu/z3pool/crashdump
> [2] http://server.roeck-us.net/qemu/z3pool/README
> [3] http://server.roeck-us.net/qemu/z3pool/
> [4] https://bugs.chromium.org/p/chromium/issues/deta
Re: [PATCH 00/30] kconfig: move compiler capability tests to Kconfig
2018-04-13 14:06 GMT+09:00 Masahiro Yamada : I forgot to prefix the patch subjects with the version. This series is V3. > [Introduction] > > The motivation of this work is to move the compiler option tests to > Kconfig from Makefile. A number of kernel features require the > compiler support. Enabling such features blindly in Kconfig ends up > with a lot of nasty build-time testing in Makefiles. If a chosen > feature turns out unsupported by the compiler, what the build system > can do is either to disable it (silently!) or to forcibly break the > build, despite Kconfig has let the user to enable it. > > [Major Changes in V3] > > This version looks more like Make. > > - Use = operator instead of 'macro' keyword > to define a user-defined function. > > - 'Recursively expanded variable' is implemented as a side-effect. > A variable is a function with zero argument. > > - Support simply expanded variable which is defined by := operator > > - Support += operator. > Probably, this feature will be useful to accumulate compiler flags. > At least, Clang needs some prerequisite flags such as triplet > to test other compiler flags. > > - Support $(info ...) and $(warning ...) built-in functions, > which were useful while I was debugging this. > > - Add documentation > > - Add unit tests > > - Collect helpers to scripts/Kconfig.include > > [TODO items] > > I have not been able to finish this. Maybe aiming for v4.18-rc1. > > - The text expansion should be able to defer argument expansion. > This is necessary if we want to implement $(if ...) built-in function. > > - Error out recursive expansion of itself. > For example, > X = $(X) > refers itself. > If referenced, the expansion continues eternally. This must be > terminated. > > - More compatible behavior? > Kconfig works mostly like Make, but there are naive cases > where the behavior is different. > > [Old Versions] > > V2: https://lkml.org/lkml/2018/2/16/610 > V1: https://lkml.org/lkml/2018/2/16/610 > RFC: https://lkml.org/lkml/2018/2/8/429 > > > > Masahiro Yamada (30): > gcc-plugins: fix build condition of SANCOV plugin > kbuild: remove kbuild cache > kbuild: remove CONFIG_CROSS_COMPILE support > kconfig: reference environment variables directly and remove 'option > env=' > kconfig: remove string expansion in file_lookup() > kconfig: remove string expansion for mainmenu after yyparse() > kconfig: remove sym_expand_string_value() > kconfig: add built-in function support > kconfig: add 'shell' built-in function > kconfig: replace $(UNAME_RELEASE) with function call > kconfig: begin PARAM state only when seeing a command keyword > kconfig: support variable and user-defined function > kconfig: support simply expanded variable > kconfig: support append assignment operator > kconfig: expand lefthand side of assignment statement > kconfig: add 'info' and 'warning' built-in functions > Documentation: kconfig: document a new Kconfig macro language > kconfig: test: test text expansion > kconfig: show compiler version text in the top comment > kconfig: add basic helper macros to scripts/Kconfig.include > stack-protector: test compiler capability in Kconfig and drop AUTO > mode > kconfig: add CC_IS_GCC and GCC_VERSION > kconfig: add CC_IS_CLANG and CLANG_VERSION > gcov: remove CONFIG_GCOV_FORMAT_AUTODETECT > kcov: test compiler capability in Kconfig and correct dependency > gcc-plugins: move GCC version check for PowerPC to Kconfig > gcc-plugins: test plugin support in Kconfig and clean up Makefile > gcc-plugins: allow to enable GCC_PLUGINS for COMPILE_TEST > arm64: move GCC version check for ARCH_SUPPORTS_INT128 to Kconfig > kbuild: test dead code/data elimination support in Kconfig > > Documentation/kbuild/kconfig-language.txt | 8 - > Documentation/kbuild/kconfig-macro-language.txt| 179 +++ > Kconfig| 10 +- > MAINTAINERS| 3 +- > Makefile | 113 +--- > arch/Kconfig | 53 +- > arch/arm64/Kconfig | 1 + > arch/arm64/Makefile| 2 - > arch/powerpc/Kconfig | 2 +- > arch/sh/Kconfig| 4 +- > arch/sparc/Kconfig | 4 +- > arch/um/Kconfig.common | 4 - > arch/x86/Kconfig | 15 +- > arch/x86/um/Kconfig| 6 +- > init/Kconfig | 40 +- > kernel/gcov/Kconfig| 17 +- > kernel/gcov/Makefile | 2 - > lib/Kconfig.debug | 11 +- > scripts/K
[PATCH v2] staging: Android: Add 'vsoc' driver for cuttlefish.
From: Greg Hartman The cuttlefish system is a virtual SoC architecture based on QEMU. It uses the QEMU ivshmem feature to share memory regions between guest and host with a custom protocol. Cc: Greg Kroah-Hartman Cc: Arve Hjønnevåg Cc: Todd Kjos Cc: Martijn Coenen Cc: Dan Carpenter Cc: de...@driverdev.osuosl.org Cc: kernel-t...@android.com Signed-off-by: Greg Hartman [astrachan: rebased against 4.16, added TODO, fixed checkpatch issues] Signed-off-by: Alistair Strachan --- v2: addressed issues with class_create() failure handling and redundant null pointer checks noticed by Dan Carpenter drivers/staging/android/Kconfig |9 + drivers/staging/android/Makefile|1 + drivers/staging/android/TODO| 10 + drivers/staging/android/uapi/vsoc_shm.h | 303 ++ drivers/staging/android/vsoc.c | 1169 +++ 5 files changed, 1492 insertions(+) create mode 100644 drivers/staging/android/uapi/vsoc_shm.h create mode 100644 drivers/staging/android/vsoc.c diff --git a/drivers/staging/android/Kconfig b/drivers/staging/android/Kconfig index 71a50b99caff..29d891355f7a 100644 --- a/drivers/staging/android/Kconfig +++ b/drivers/staging/android/Kconfig @@ -14,6 +14,15 @@ config ASHMEM It is, in theory, a good memory allocator for low-memory devices, because it can discard shared memory units when under memory pressure. +config ANDROID_VSOC + tristate "Android Virtual SoC support" + default n + depends on PCI_MSI + ---help--- + This option adds support for the Virtual SoC driver needed to boot + a 'cuttlefish' Android image inside QEmu. The driver interacts with + a QEmu ivshmem device. If built as a module, it will be called vsoc. + source "drivers/staging/android/ion/Kconfig" endif # if ANDROID diff --git a/drivers/staging/android/Makefile b/drivers/staging/android/Makefile index 7cf1564a49a5..90e6154f11a4 100644 --- a/drivers/staging/android/Makefile +++ b/drivers/staging/android/Makefile @@ -3,3 +3,4 @@ ccflags-y += -I$(src) # needed for trace events obj-y += ion/ obj-$(CONFIG_ASHMEM) += ashmem.o +obj-$(CONFIG_ANDROID_VSOC) += vsoc.o diff --git a/drivers/staging/android/TODO b/drivers/staging/android/TODO index 687e0eac85bf..6aab759efa48 100644 --- a/drivers/staging/android/TODO +++ b/drivers/staging/android/TODO @@ -11,5 +11,15 @@ ion/ - Split /dev/ion up into multiple nodes (e.g. /dev/ion/heap0) - Better test framework (integration with VGEM was suggested) +vsoc.c, uapi/vsoc_shm.h + - The current driver uses the same wait queue for all of the futexes in a + region. This will cause false wakeups in regions with a large number of + waiting threads. We should eventually use multiple queues and select the + queue based on the region. + - Add debugfs support for examining the permissions of regions. + - Use ioremap_wc instead of ioremap_nocache. + - Remove VSOC_WAIT_FOR_INCOMING_INTERRUPT ioctl. This functionality has been + superseded by the futex and is there for legacy reasons. + Please send patches to Greg Kroah-Hartman and Cc: Arve Hjønnevåg and Riley Andrews diff --git a/drivers/staging/android/uapi/vsoc_shm.h b/drivers/staging/android/uapi/vsoc_shm.h new file mode 100644 index ..741b1387c25b --- /dev/null +++ b/drivers/staging/android/uapi/vsoc_shm.h @@ -0,0 +1,303 @@ +/* + * Copyright (C) 2017 Google, Inc. + * + * This software is licensed under the terms of the GNU General Public + * License version 2, as published by the Free Software Foundation, and + * may be copied, distributed, and modified under those terms. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + */ + +#ifndef _UAPI_LINUX_VSOC_SHM_H +#define _UAPI_LINUX_VSOC_SHM_H + +#include + +/** + * A permission is a token that permits a receiver to read and/or write an area + * of memory within a Vsoc region. + * + * An fd_scoped permission grants both read and write access, and can be + * attached to a file description (see open(2)). + * Ownership of the area can then be shared by passing a file descriptor + * among processes. + * + * begin_offset and end_offset define the area of memory that is controlled by + * the permission. owner_offset points to a word, also in shared memory, that + * controls ownership of the area. + * + * ownership of the region expires when the associated file description is + * released. + * + * At most one permission can be attached to each file description. + * + * This is useful when implementing HALs like gralloc that scope and pass + * ownership of shared resources via file descriptors. + * + * The caller is responsibe for doing any fencing. + * + * The cal
[PATCH 09/30] kconfig: add 'shell' built-in function
This accepts a single command to execute. It returns the standard
output from it.
[Example code]
config HELLO
string
default "$(shell echo hello world)"
config Y
def_bool $(shell echo y)
[Result]
$ make -s alldefconfig && tail -n 2 .config
CONFIG_HELLO="hello world"
CONFIG_Y=y
Caveat:
Like environments, functions are expanded in the lexer. You cannot
pass symbols to function arguments. This is a limitation to simplify
the implementation. I want to avoid the dynamic function evaluation,
which would introduce much more complexity.
Signed-off-by: Masahiro Yamada
---
Changes in v3: None
Changes in v2: None
scripts/kconfig/preprocess.c | 66
1 file changed, 66 insertions(+)
diff --git a/scripts/kconfig/preprocess.c b/scripts/kconfig/preprocess.c
index e77cf7c..f4c606f 100644
--- a/scripts/kconfig/preprocess.c
+++ b/scripts/kconfig/preprocess.c
@@ -86,7 +86,73 @@ struct function {
char *(*func)(int argc, char *argv[]);
};
+/*
+ * Some commands treats commas verbatim. Concatenate arguments to get
+ * back the original input. The returned string must be freed when done.
+ */
+static char *join_args(int argc, char *argv[])
+{
+ size_t len = 0;
+ char *out;
+ int i;
+
+ for (i = 0; i < argc; i++)
+ len += strlen(argv[i]) + 1;
+
+ out = xmalloc(len);
+ out[0] = 0;
+ for (i = 0; i < argc; i++) {
+ strcat(out, argv[i]);
+ if (i != argc - 1)
+ strcat(out, ",");
+ }
+
+ return out;
+}
+
+static char *do_shell(int argc, char *argv[])
+{
+ FILE *p;
+ char buf[256];
+ char *cmd;
+ size_t nread;
+ int i;
+
+ cmd = join_args(argc, argv);
+
+ p = popen(cmd, "r");
+ if (!p) {
+ perror(cmd);
+ goto free;
+ }
+
+ nread = fread(buf, 1, sizeof(buf), p);
+ if (nread == sizeof(buf))
+ nread--;
+
+ /* remove trailing new lines */
+ while (buf[nread - 1] == '\n')
+ nread--;
+
+ buf[nread] = 0;
+
+ /* replace a new line with a space */
+ for (i = 0; i < nread; i++) {
+ if (buf[i] == '\n')
+ buf[i] = ' ';
+ }
+
+ if (pclose(p) == -1)
+ perror(cmd);
+
+free:
+ free(cmd);
+
+ return xstrdup(buf);
+}
+
static const struct function function_table[] = {
+ { .name = "shell", .func = do_shell },
};
static char *function_call(const char *name, int argc, char *argv[])
--
2.7.4
[PATCH 18/30] kconfig: test: test text expansion
Here are the test cases I used for developing the text expansion feature. I implemented a similar language as you see in Make. The implementation is different (the source code in GNU Make is much longer, so I did not want to pull it in), but the behavior is hopefully almost the same. I intentionally changed some behavior and syntax, but I tried to stick to the make-like behavior where possible. It might be interesting to compare the behavior between Make and Kconfig. [1] Variable test You can directly run scripts/kconfig/tests/preprocess/variable/Kconfig by make. Make and Kconfig produce the exactly the same output for the variable test. The output from Make: $ cd scripts/kconfig/tests/preprocess/variable && make -f Kconfig Kconfig:5: SIMPLE = 1 Kconfig:11: RECURSIVE = 2 Kconfig:17: SIMPLE = 1 3 Kconfig:23: RECURSIVE = 2 4 Kconfig:30: UNDEFINED_VARIABLE = 4 Kconfig:36: AB = 5 Kconfig:39: X = A make: *** No targets. Stop. [2] Built-in function test The output from Make: $ cd scripts/kconfig/tests/preprocess/builtin_func && make -f Kconfig hello,world 0 Kconfig:7: hello,world 1 Kconfig:11: hello, world 2 Kconfig:15: hello,world 3 Kconfig:19: hello, world 4 make: *** No targets. Stop. The output from "$(warning hello, world 2)" is different. "Kconfig:11: hello, world 2" vs "Kconfig:11: hello, world 2" Make strips all leading spaces from the first argument, but does not touch the other arguments. I thought this was inconsistent. So, I changed the behavior to not touch any arguments at all. [3] User-defined function test I changed the syntax for calling a user-defined function. In Make, it is invoked by using the 'call' built-in function as in $(call greeting,Hello,John) but in Kconfig it is invoked without 'call' as in $(greeting Hello,John). Except the syntax difference, the test case works exactly in the same way for Make and Kconfig. [4] Escape sequence test Except the syntax of user-defined function, Make and Kconfig work in the same way. The behavior of a standalone '$' is different among Make versions. By fixing the user-defined function syntax, Make 4.1 or older works like this: Kconfig:5: arg0= arg1= Kconfig:9: arg0=, arg1=, Kconfig:13: ' " '" ' ''' "'" Kconfig:16: $ Kconfig:20: $X Kconfig:26: nasty Kconfig:32: super_nasty Kconfig:41: Kconfig:46: X Kconfig:49: make: *** No targets. Stop. Make 4.2 or newer is like this: Kconfig:5: arg0= arg1= Kconfig:9: arg0=, arg1=, Kconfig:13: ' " '" ' ''' "'" Kconfig:16: $ Kconfig:20: $X Kconfig:26: nasty Kconfig:32: super_nasty Kconfig:41: $ Kconfig:46: $X Kconfig:49: nasty make: *** No targets. Stop. The last three lines are different. I adopted the behavior of the newer Make versions. Of course, you should not write such code. Signed-off-by: Masahiro Yamada --- Changes in v3: None Changes in v2: None .../kconfig/tests/preprocess/builtin_func/Kconfig | 19 + .../tests/preprocess/builtin_func/__init__.py | 8 .../tests/preprocess/builtin_func/expected_stderr | 4 ++ .../tests/preprocess/builtin_func/expected_stdout | 1 + scripts/kconfig/tests/preprocess/escape/Kconfig| 49 ++ .../kconfig/tests/preprocess/escape/__init__.py| 9 .../tests/preprocess/escape/expected_stderr| 10 + scripts/kconfig/tests/preprocess/user_func/Kconfig | 19 + .../kconfig/tests/preprocess/user_func/__init__.py | 7 .../tests/preprocess/user_func/expected_stderr | 5 +++ scripts/kconfig/tests/preprocess/variable/Kconfig | 39 + .../kconfig/tests/preprocess/variable/__init__.py | 7 .../tests/preprocess/variable/expected_stderr | 7 13 files changed, 184 insertions(+) create mode 100644 scripts/kconfig/tests/preprocess/builtin_func/Kconfig create mode 100644 scripts/kconfig/tests/preprocess/builtin_func/__init__.py create mode 100644 scripts/kconfig/tests/preprocess/builtin_func/expected_stderr create mode 100644 scripts/kconfig/tests/preprocess/builtin_func/expected_stdout create mode 100644 scripts/kconfig/tests/preprocess/escape/Kconfig create mode 100644 scripts/kconfig/tests/preprocess/escape/__init__.py create mode 100644 scripts/kconfig/tests/preprocess/escape/expected_stderr create mode 100644 scripts/kconfig/tests/preprocess/user_func/Kconfig create mode 100644 scripts/kconfig/tests/preprocess/user_func/__init__.py create mode 100644 scripts/kconfig/tests/preprocess/user_func/expected_stderr create mode 100644 scripts/kconfig/tests/preprocess/variable/Kconfig create mode 100644 scripts/kconfig/tests/preprocess/variable/__init__.py create mode 100644 scripts/kconfig/tests/preprocess/variable/expected_stderr diff --git a/scripts/kconfig/tests/preprocess/builtin_func/Kconfig b/scripts/kconfig/tests/preprocess/builtin_func/Kconfig new file mode 100644 index 000..5dc454e --- /dev/null +++ b/scripts/kconfig/tests/preproce
[PATCH 00/30] kconfig: move compiler capability tests to Kconfig
[Introduction] The motivation of this work is to move the compiler option tests to Kconfig from Makefile. A number of kernel features require the compiler support. Enabling such features blindly in Kconfig ends up with a lot of nasty build-time testing in Makefiles. If a chosen feature turns out unsupported by the compiler, what the build system can do is either to disable it (silently!) or to forcibly break the build, despite Kconfig has let the user to enable it. [Major Changes in V3] This version looks more like Make. - Use = operator instead of 'macro' keyword to define a user-defined function. - 'Recursively expanded variable' is implemented as a side-effect. A variable is a function with zero argument. - Support simply expanded variable which is defined by := operator - Support += operator. Probably, this feature will be useful to accumulate compiler flags. At least, Clang needs some prerequisite flags such as triplet to test other compiler flags. - Support $(info ...) and $(warning ...) built-in functions, which were useful while I was debugging this. - Add documentation - Add unit tests - Collect helpers to scripts/Kconfig.include [TODO items] I have not been able to finish this. Maybe aiming for v4.18-rc1. - The text expansion should be able to defer argument expansion. This is necessary if we want to implement $(if ...) built-in function. - Error out recursive expansion of itself. For example, X = $(X) refers itself. If referenced, the expansion continues eternally. This must be terminated. - More compatible behavior? Kconfig works mostly like Make, but there are naive cases where the behavior is different. [Old Versions] V2: https://lkml.org/lkml/2018/2/16/610 V1: https://lkml.org/lkml/2018/2/16/610 RFC: https://lkml.org/lkml/2018/2/8/429 Masahiro Yamada (30): gcc-plugins: fix build condition of SANCOV plugin kbuild: remove kbuild cache kbuild: remove CONFIG_CROSS_COMPILE support kconfig: reference environment variables directly and remove 'option env=' kconfig: remove string expansion in file_lookup() kconfig: remove string expansion for mainmenu after yyparse() kconfig: remove sym_expand_string_value() kconfig: add built-in function support kconfig: add 'shell' built-in function kconfig: replace $(UNAME_RELEASE) with function call kconfig: begin PARAM state only when seeing a command keyword kconfig: support variable and user-defined function kconfig: support simply expanded variable kconfig: support append assignment operator kconfig: expand lefthand side of assignment statement kconfig: add 'info' and 'warning' built-in functions Documentation: kconfig: document a new Kconfig macro language kconfig: test: test text expansion kconfig: show compiler version text in the top comment kconfig: add basic helper macros to scripts/Kconfig.include stack-protector: test compiler capability in Kconfig and drop AUTO mode kconfig: add CC_IS_GCC and GCC_VERSION kconfig: add CC_IS_CLANG and CLANG_VERSION gcov: remove CONFIG_GCOV_FORMAT_AUTODETECT kcov: test compiler capability in Kconfig and correct dependency gcc-plugins: move GCC version check for PowerPC to Kconfig gcc-plugins: test plugin support in Kconfig and clean up Makefile gcc-plugins: allow to enable GCC_PLUGINS for COMPILE_TEST arm64: move GCC version check for ARCH_SUPPORTS_INT128 to Kconfig kbuild: test dead code/data elimination support in Kconfig Documentation/kbuild/kconfig-language.txt | 8 - Documentation/kbuild/kconfig-macro-language.txt| 179 +++ Kconfig| 10 +- MAINTAINERS| 3 +- Makefile | 113 +--- arch/Kconfig | 53 +- arch/arm64/Kconfig | 1 + arch/arm64/Makefile| 2 - arch/powerpc/Kconfig | 2 +- arch/sh/Kconfig| 4 +- arch/sparc/Kconfig | 4 +- arch/um/Kconfig.common | 4 - arch/x86/Kconfig | 15 +- arch/x86/um/Kconfig| 6 +- init/Kconfig | 40 +- kernel/gcov/Kconfig| 17 +- kernel/gcov/Makefile | 2 - lib/Kconfig.debug | 11 +- scripts/Kbuild.include | 101 +--- scripts/Kconfig.include| 20 + scripts/Makefile.gcc-plugins | 91 +--- scripts/Makefile.kcov | 10 +- scripts/clang-version.sh | 18 +- scripts/gcc-plugins/Makefile
[PATCH 17/30] Documentation: kconfig: document a new Kconfig macro language
Add a document for the macro language introduced to Kconfig.
The motivation of this work is to move the compiler option tests to
Kconfig from Makefile. A number of kernel features require the
compiler support. Enabling such features blindly in Kconfig ends up
with a lot of nasty build-time testing in Makefiles. If a chosen
feature turns out unsupported by the compiler, what the build system
can do is either to disable it (silently!) or to forcibly break the
build, despite Kconfig has let the user to enable it.
This change was strongly prompted by Linus Torvalds. You can find
his suggestions [1] [2] in ML. The original idea was to add a new
'option', but I found generalized text expansion would make Kconfig
more powerful and lovely. While polishing up the implementation, I
noticed sort of similarity between Make and Kconfig. This might be
too immature to be called 'language', but anyway here it is. All
ideas are from Make (you can even say it is addicted), so people
will easily understand how it works.
[1]: https://lkml.org/lkml/2016/12/9/577
[2]: https://lkml.org/lkml/2018/2/7/527
Signed-off-by: Masahiro Yamada
---
Changes in v3: None
Changes in v2: None
Documentation/kbuild/kconfig-macro-language.txt | 179
MAINTAINERS | 2 +-
2 files changed, 180 insertions(+), 1 deletion(-)
create mode 100644 Documentation/kbuild/kconfig-macro-language.txt
diff --git a/Documentation/kbuild/kconfig-macro-language.txt
b/Documentation/kbuild/kconfig-macro-language.txt
new file mode 100644
index 000..1f6281b
--- /dev/null
+++ b/Documentation/kbuild/kconfig-macro-language.txt
@@ -0,0 +1,179 @@
+Concept
+---
+
+The basic idea was inspired by Make. When we look at Make, we notice sort of
+two languages in one. One language describes dependency graphs consisting of
+targets and prerequisites. The other is a macro language for performing textual
+substitution.
+
+There is clear distinction between the two language stages. For example, you
+can write a makefile like follows:
+
+APP := foo
+SRC := foo.c
+CC := gcc
+
+$(APP): $(SRC)
+$(CC) -o $(APP) $(SRC)
+
+The macro language replaces the variable references with their expanded form,
+and handles as if the source file were input like follows:
+
+foo: foo.c
+gcc -o foo foo.c
+
+Then, Make analyzes the dependency graph and determines the targets to be
+updated.
+
+The idea is quite similar in Kconfig - it is possible to describe a Kconfig
+file like this:
+
+CC := gcc
+
+config CC_HAS_FOO
+def_bool $(shell $(srctree)/scripts/gcc-check-foo.sh $(CC))
+
+The macro language in Kconfig processes the source file into the following
+intermediate:
+
+config CC_HAS_FOO
+def_bool y
+
+Then, Kconfig moves onto the evaluation stage to resolve inter-symbol
+dependency, which is explained in kconfig-language.txt.
+
+
+Variables
+-
+
+Like in Make, a variable in Kconfig works as a macro variable. A macro
+variable is expanded "in place" to yield a text string that may then expanded
+further. To get the value of a variable, enclose the variable name in $( ).
+As a special case, single-letter variable names can omit the parentheses and is
+simply referenced like $X. Unlike Make, Kconfig does not support curly braces
+as in ${CC}.
+
+There are two types of variables: simply expanded variables and recursively
+expanded variables.
+
+A simply expanded variable is defined using the := assignment operator. Its
+righthand side is expanded immediately upon reading the line from the Kconfig
+file.
+
+A recursively expanded variable is defined using the = assignment operator.
+Its righthand side is simply stored as the value of the variable without
+expanding it in any way. Instead, the expansion is performed when the variable
+is used.
+
+There is another type of assignment operator; += is used to append text to a
+variable. The righthand side of += is expanded immediately if the lefthand
+side was originally defined as a simple variable. Otherwise, its evaluation is
+deferred.
+
+
+Functions
+-
+
+Like Make, Kconfig supports both built-in and user-defined functions. A
+function invocation looks much like a variable reference, but includes one or
+more parameters separated by commas:
+
+ $(function-name arg1, arg2, arg3)
+
+Some functions are implemented as a built-in function. Currently, Kconfig
+supports the following:
+
+ - $(shell command)
+
+ The 'shell' function accepts a single argument that is expanded and passed
+ to a subshell for execution. The standard output of the command is then read
+ and returned as the value of the function. Every newline in the output is
+ replaced with a space. Any trailing newlines are deleted. The standard error
+ is not returned, nor is any program exit status.
+
+ - $(warning text)
+
+ The 'warning' function prints its arguments to stderr. The output is prefixed
+ with the n
[PATCH 13/30] kconfig: support simply expanded variable
The previous commit added variable and user-defined function. They
work similarly in the sense that the evaluation is deferred until
they are used.
This commit adds another type of variable, simply expanded variable,
as we see in Make.
The := operator defines a simply expanded variable, expanding the
righthand side immediately. This works like traditional programming
language variables.
Signed-off-by: Masahiro Yamada
---
Changes in v3:
- newly added
Changes in v2: None
scripts/kconfig/lkc_proto.h | 7 ++-
scripts/kconfig/preprocess.c | 6 --
scripts/kconfig/zconf.l | 3 ++-
scripts/kconfig/zconf.y | 5 +++--
4 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/scripts/kconfig/lkc_proto.h b/scripts/kconfig/lkc_proto.h
index 2b16d6e..6303193 100644
--- a/scripts/kconfig/lkc_proto.h
+++ b/scripts/kconfig/lkc_proto.h
@@ -49,8 +49,13 @@ const char * sym_get_string_value(struct symbol *sym);
const char * prop_get_type_name(enum prop_type type);
/* preprocess.c */
+enum variable_flavor {
+ VAR_SIMPLE,
+ VAR_RECURSIVE,
+};
void env_write_dep(FILE *f, const char *auto_conf_name);
-void variable_add(const char *name, const char *value);
+void variable_add(const char *name, const char *value,
+ enum variable_flavor flavor);
void variable_all_del(void);
char *expand_string(const char *in);
char *expand_dollar(const char **str);
diff --git a/scripts/kconfig/preprocess.c b/scripts/kconfig/preprocess.c
index 1b746e0..a835c94 100644
--- a/scripts/kconfig/preprocess.c
+++ b/scripts/kconfig/preprocess.c
@@ -112,7 +112,8 @@ static char *variable_expand(const char *name, int argc,
char *argv[])
return expand_string_with_args(v->value, argc, argv);
}
-void variable_add(const char *name, const char *value)
+void variable_add(const char *name, const char *value,
+ enum variable_flavor flavor)
{
struct variable *v;
@@ -125,7 +126,8 @@ void variable_add(const char *name, const char *value)
list_add_tail(&v->node, &variable_list);
}
- v->value = xstrdup(value);
+ v->value = (flavor == VAR_SIMPLE) ? expand_string(value) :
+ xstrdup(value);
}
static void variable_del(struct variable *v)
diff --git a/scripts/kconfig/zconf.l b/scripts/kconfig/zconf.l
index 19e5ebf..aa76942 100644
--- a/scripts/kconfig/zconf.l
+++ b/scripts/kconfig/zconf.l
@@ -114,7 +114,8 @@ n [A-Za-z0-9_-]
yylval.string = text;
return T_VARIABLE;
}
- "=" { BEGIN(ASSIGN_VAL); return T_ASSIGN; }
+ "=" { BEGIN(ASSIGN_VAL); yylval.flavor = VAR_RECURSIVE; return
T_ASSIGN; }
+ ":="{ BEGIN(ASSIGN_VAL); yylval.flavor = VAR_SIMPLE; return
T_ASSIGN; }
[[:blank:]]+
. warn_ignored_character(*yytext);
\n {
diff --git a/scripts/kconfig/zconf.y b/scripts/kconfig/zconf.y
index 493388c..1ebbf9e 100644
--- a/scripts/kconfig/zconf.y
+++ b/scripts/kconfig/zconf.y
@@ -41,6 +41,7 @@ static struct menu *current_menu, *current_entry;
struct expr *expr;
struct menu *menu;
const struct kconf_id *id;
+ enum variable_flavor flavor;
}
%token T_MAINMENU
@@ -78,7 +79,7 @@ static struct menu *current_menu, *current_entry;
%token T_OPEN_PAREN
%token T_EOL
%token T_VARIABLE
-%token T_ASSIGN
+%token T_ASSIGN
%token T_ASSIGN_VAL
%left T_OR
@@ -517,7 +518,7 @@ word_opt: /* empty */ { $$ = NULL; }
/* assignment statement */
-assignment_stmt: T_VARIABLE T_ASSIGN assign_val T_EOL { variable_add($1, $3);
free($1); free($3); }
+assignment_stmt: T_VARIABLE T_ASSIGN assign_val T_EOL { variable_add($1, $3,
$2); free($1); free($3); }
assign_val:
/* empty */ { $$ = xstrdup(""); };
--
2.7.4
[PATCH 19/30] kconfig: show compiler version text in the top comment
The kernel configuration phase is now tightly coupled with the compiler in use. It will be nice to show the compiler information in Kconfig. The compiler information will be displayed like this: $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- config scripts/kconfig/conf --oldaskconfig Kconfig * * Linux/arm64 4.16.0-rc1 Kernel Configuration * * * Compiler: aarch64-linux-gnu-gcc (Linaro GCC 7.2-2017.11) 7.2.1 20171011 * * * General setup * Compile also drivers which will not load (COMPILE_TEST) [N/y/?] If you use GUI methods such as menuconfig, it will be displayed in the top menu. This is simply implemented by using the 'comment' statement. So, it will be saved into the .config file as well. This commit has a very important meaning. If the compiler is upgraded, Kconfig must be re-run since different compilers have different sets of supported options. All referenced environments are written to include/config/auto.conf.cmd so that any environment change triggers syncconfig, and prompt the user to input new values if needed. With this commit, something like follows will be added to include/config/auto.conf.cmd ifneq "$(CC_VERSION_TEXT)" "aarch64-linux-gnu-gcc (Linaro GCC 7.2-2017.11) 7.2.1 20171011" include/config/auto.conf: FORCE endif Signed-off-by: Masahiro Yamada Reviewed-by: Kees Cook --- Changes in v3: None Changes in v2: None Kconfig | 2 ++ Makefile | 2 ++ 2 files changed, 4 insertions(+) diff --git a/Kconfig b/Kconfig index 4af1b42..5b55d87 100644 --- a/Kconfig +++ b/Kconfig @@ -5,4 +5,6 @@ # mainmenu "Linux/$(ARCH) $(KERNELVERSION) Kernel Configuration" +comment "Compiler: $(CC_VERSION_TEXT)" + source "arch/$(SRCARCH)/Kconfig" diff --git a/Makefile b/Makefile index ca3e3e8..4b36329 100644 --- a/Makefile +++ b/Makefile @@ -442,6 +442,8 @@ export KBUILD_AFLAGS_MODULE KBUILD_CFLAGS_MODULE KBUILD_LDFLAGS_MODULE export KBUILD_AFLAGS_KERNEL KBUILD_CFLAGS_KERNEL export KBUILD_ARFLAGS +export CC_VERSION_TEXT := $(shell $(CC) --version | head -n 1) + # When compiling out-of-tree modules, put MODVERDIR in the module # tree rather than in the kernel tree. The kernel tree might # even be read-only. -- 2.7.4
[PATCH 22/30] kconfig: add CC_IS_GCC and GCC_VERSION
This will be useful to specify the required compiler version, like this: config FOO bool "Use Foo" depends on GCC_VERSION >= 408000 help This feature requires GCC 4.8 or newer. Signed-off-by: Masahiro Yamada Reviewed-by: Kees Cook --- Changes in v3: None Changes in v2: None init/Kconfig | 8 1 file changed, 8 insertions(+) diff --git a/init/Kconfig b/init/Kconfig index 4b0b636..145a534 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -8,6 +8,14 @@ config DEFCONFIG_LIST default ARCH_DEFCONFIG default "arch/$(ARCH)/defconfig" +config CC_IS_GCC + def_bool $(success $(CC) --version | grep -q gcc) + +config GCC_VERSION + int + default $(shell $(srctree)/scripts/gcc-version.sh -p $(CC) | sed 's/^0*//') if CC_IS_GCC + default 0 + config CONSTRUCTORS bool depends on !UML -- 2.7.4
[PATCH 20/30] kconfig: add basic helper macros to scripts/Kconfig.include
Kconfig got text processing tools like we see in Make. Add Kconfig helper macros to scripts/Kconfig.include like we collect Makefile macros in scripts/Kbuild.include. Signed-off-by: Masahiro Yamada Reviewed-by: Kees Cook Reviewed-by: Ulf Magnusson --- Changes in v3: - Move helpers to scripts/Kconfig.include Changes in v2: None Kconfig | 2 ++ MAINTAINERS | 1 + scripts/Kconfig.include | 17 + 3 files changed, 20 insertions(+) create mode 100644 scripts/Kconfig.include diff --git a/Kconfig b/Kconfig index 5b55d87..a90d9f9 100644 --- a/Kconfig +++ b/Kconfig @@ -7,4 +7,6 @@ mainmenu "Linux/$(ARCH) $(KERNELVERSION) Kernel Configuration" comment "Compiler: $(CC_VERSION_TEXT)" +source "scripts/Kconfig.include" + source "arch/$(SRCARCH)/Kconfig" diff --git a/MAINTAINERS b/MAINTAINERS index b9dab38..d962f4a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7624,6 +7624,7 @@ L:linux-kbu...@vger.kernel.org S: Maintained F: Documentation/kbuild/kconfig* F: scripts/kconfig/ +F: scripts/Kconfig.include KDUMP M: Dave Young diff --git a/scripts/Kconfig.include b/scripts/Kconfig.include new file mode 100644 index 000..cac7a81 --- /dev/null +++ b/scripts/Kconfig.include @@ -0,0 +1,17 @@ +# Kconfig helper macros + +# Convenient variables +comma := , +quote := " +squote := ' +empty := +space := $(empty) $(empty) + +# y if the command exits with 0, n otherwise +success = $(shell ($(1)) >/dev/null 2>&1 && echo y || echo n) + +# y if the given compiler flag is supported, n otherwise +cc-option = $(success $(CC) -Werror $(1) -c -x c /dev/null -o /dev/null) + +# y if the given linker flag is supported, n otherwise +ld-option = $(success $(LD) -v $(1)) -- 2.7.4
[PATCH 23/30] kconfig: add CC_IS_CLANG and CLANG_VERSION
This will be useful to describe the clang version dependency.
Signed-off-by: Masahiro Yamada
Reviewed-by: Kees Cook
---
Changes in v3: None
Changes in v2: None
init/Kconfig | 7 +++
scripts/clang-version.sh | 18 --
2 files changed, 11 insertions(+), 14 deletions(-)
diff --git a/init/Kconfig b/init/Kconfig
index 145a534..c8f4ba3 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -16,6 +16,13 @@ config GCC_VERSION
default $(shell $(srctree)/scripts/gcc-version.sh -p $(CC) | sed
's/^0*//') if CC_IS_GCC
default 0
+config CC_IS_CLANG
+ def_bool $(success $(CC) --version | grep -q clang)
+
+config CLANG_VERSION
+ int
+ default $(shell $(srctree)/scripts/clang-version.sh $(CC))
+
config CONSTRUCTORS
bool
depends on !UML
diff --git a/scripts/clang-version.sh b/scripts/clang-version.sh
index 9780efa..dbf0a31 100755
--- a/scripts/clang-version.sh
+++ b/scripts/clang-version.sh
@@ -10,24 +10,14 @@
# clang-5.0.1 etc.
#
-if [ "$1" = "-p" ] ; then
- with_patchlevel=1;
- shift;
-fi
-
compiler="$*"
-if [ ${#compiler} -eq 0 ]; then
- echo "Error: No compiler specified."
- printf "Usage:\n\t$0 \n"
+if !( $compiler --version | grep -q clang) ; then
+ echo 0
exit 1
fi
MAJOR=$(echo __clang_major__ | $compiler -E -x c - | tail -n 1)
MINOR=$(echo __clang_minor__ | $compiler -E -x c - | tail -n 1)
-if [ "x$with_patchlevel" != "x" ] ; then
- PATCHLEVEL=$(echo __clang_patchlevel__ | $compiler -E -x c - | tail -n
1)
- printf "%02d%02d%02d\\n" $MAJOR $MINOR $PATCHLEVEL
-else
- printf "%02d%02d\\n" $MAJOR $MINOR
-fi
+PATCHLEVEL=$(echo __clang_patchlevel__ | $compiler -E -x c - | tail -n 1)
+printf "%d%02d%02d\\n" $MAJOR $MINOR $PATCHLEVEL
--
2.7.4
[PATCH 16/30] kconfig: add 'info' and 'warning' built-in functions
Add 'info' and 'warning' functions as in Make.
They print messages during parsing Kconfig files, which is useful
when debugging Kconfig at least.
Signed-off-by: Masahiro Yamada
---
Changes in v3: None
Changes in v2: None
scripts/kconfig/preprocess.c | 28
1 file changed, 28 insertions(+)
diff --git a/scripts/kconfig/preprocess.c b/scripts/kconfig/preprocess.c
index 85972fb..f8d06d9 100644
--- a/scripts/kconfig/preprocess.c
+++ b/scripts/kconfig/preprocess.c
@@ -203,6 +203,19 @@ static char *join_args(int argc, char *argv[])
return out;
}
+static char *do_info(int argc, char *argv[])
+{
+ char *msg;
+
+ msg = join_args(argc, argv);
+
+ printf("%s\n", msg);
+
+ free(msg);
+
+ return xstrdup("");
+}
+
static char *do_shell(int argc, char *argv[])
{
FILE *p;
@@ -244,8 +257,23 @@ static char *do_shell(int argc, char *argv[])
return xstrdup(buf);
}
+static char *do_warning(int argc, char *argv[])
+{
+ char *msg;
+
+ msg = join_args(argc, argv);
+
+ fprintf(stderr, "%s:%d: %s\n", current_file->name, yylineno, msg);
+
+ free(msg);
+
+ return xstrdup("");
+}
+
static const struct function function_table[] = {
+ { .name = "info", .func = do_info },
{ .name = "shell", .func = do_shell },
+ { .name = "warning", .func = do_warning },
};
static char *function_call(const char *name, int argc, char *argv[])
--
2.7.4
[PATCH 03/30] kbuild: remove CONFIG_CROSS_COMPILE support
Kbuild provides a couple of ways to specify CROSS_COMPILE: [1] Command line [2] Environment [3] arch/*/Makefile (only some architectures) [4] CONFIG_CROSS_COMPILE [4] is problematic for the compiler capability tests in Kconfig. CONFIG_CROSS_COMPILE allows users to change the compiler prefix from 'make menuconfig', etc. It means, the compiler options would have to be all re-calculated everytime CONFIG_CROSS_COMPILE is changed. To avoid complexity and performance issues, I'd like to evaluate the shell commands statically, i.e. only parsing Kconfig files. I guess the majority is [1] or [2]. Currently, there are only 5 defconfig files that specify CONFIG_CROSS_COMPILE. arch/arm/configs/lpc18xx_defconfig arch/hexagon/configs/comet_defconfig arch/nds32/configs/defconfig arch/openrisc/configs/or1ksim_defconfig arch/openrisc/configs/simple_smp_defconfig Signed-off-by: Masahiro Yamada Reviewed-by: Kees Cook --- Changes in v3: None Changes in v2: None Makefile | 3 --- init/Kconfig | 9 - 2 files changed, 12 deletions(-) diff --git a/Makefile b/Makefile index d85cee0..ca3e3e8 100644 --- a/Makefile +++ b/Makefile @@ -316,12 +316,9 @@ SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \ # CROSS_COMPILE can be set on the command line # make CROSS_COMPILE=ia64-linux- # Alternatively CROSS_COMPILE can be set in the environment. -# A third alternative is to store a setting in .config so that plain -# "make" in the configured kernel build directory always uses that. # Default value for CROSS_COMPILE is not to prefix executables # Note: Some architectures assign CROSS_COMPILE in their arch/*/Makefile ARCH ?= $(SUBARCH) -CROSS_COMPILE ?= $(CONFIG_CROSS_COMPILE:"%"=%) # Architecture as present in compile.h UTS_MACHINE:= $(ARCH) diff --git a/init/Kconfig b/init/Kconfig index 9d167a5..c1ca920 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -54,15 +54,6 @@ config INIT_ENV_ARG_LIMIT Maximum of each of the number of arguments and environment variables passed to init from the kernel command line. - -config CROSS_COMPILE - string "Cross-compiler tool prefix" - help - Same as running 'make CROSS_COMPILE=prefix-' but stored for - default make runs in this kernel build directory. You don't - need to set this unless you want the configured kernel build - directory to select the cross-compiler automatically. - config COMPILE_TEST bool "Compile also drivers which will not load" depends on !UML -- 2.7.4
[PATCH 08/30] kconfig: add built-in function support
This commit adds a new concept 'function' to do more text processing
in Kconfig.
A function call looks like this:
$(function arg1, arg2, arg3, ...)
This commit adds the basic infrastructure to expand functions.
Change the text expansion helpers to take arguments.
Signed-off-by: Masahiro Yamada
---
Changes in v3:
- Split base infrastructure and 'shell' function
into separate patches.
Changes in v2:
- Use 'shell' for getting stdout from the comment.
It was 'shell-stdout' in the previous version.
- Symplify the implementation since the expansion has been moved to
lexer.
scripts/kconfig/preprocess.c | 142 +++
1 file changed, 130 insertions(+), 12 deletions(-)
diff --git a/scripts/kconfig/preprocess.c b/scripts/kconfig/preprocess.c
index fa4abc8..e77cf7c 100644
--- a/scripts/kconfig/preprocess.c
+++ b/scripts/kconfig/preprocess.c
@@ -8,6 +8,10 @@
#include "list.h"
+#define ARRAY_SIZE(arr)(sizeof(arr) / sizeof((arr)[0]))
+
+static char *expand_string_with_args(const char *in, int argc, char *argv[]);
+
/*
* Environment variables
*/
@@ -74,9 +78,47 @@ void env_write_dep(FILE *f, const char *autoconfig_name)
}
}
-static char *eval_clause(const char *in)
+/*
+ * Built-in Functions
+ */
+struct function {
+ char *name;
+ char *(*func)(int argc, char *argv[]);
+};
+
+static const struct function function_table[] = {
+};
+
+static char *function_call(const char *name, int argc, char *argv[])
{
- char *res, *name;
+ const struct function *f;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(function_table); i++) {
+ f = &function_table[i];
+ if (!strcmp(f->name, name))
+ return f->func(argc, argv);
+ }
+
+ return NULL;
+}
+
+#define FUNCTION_MAX_ARGS 16
+
+/*
+ * Evaluate a clause with arguments. argc/argv are arguments from the upper
+ * function call.
+ *
+ * Returned string must be freed when done
+ */
+static char *eval_clause(const char *in, int argc, char *argv[])
+{
+ char *tmp, *prev, *p, *res, *name;
+ char delim = ' ';
+ int new_argc = 0;
+ char *new_argv[FUNCTION_MAX_ARGS];
+ int nest = 0;
+ int i;
/*
* Returns an empty string because '$()' should be evaluated
@@ -85,10 +127,73 @@ static char *eval_clause(const char *in)
if (!*in)
return xstrdup("");
- name = expand_string(in);
+ tmp = xstrdup(in);
+
+ prev = p = tmp;
- res = env_expand(name);
+ /*
+* Split into tokens
+* The function name and the first argument are separated by a space.
+* Arguments are separated by a comma.
+* For example, if the function call is like this:
+* $(foo abc,$(x),$(y))
+*
+* The input string for this helper should be:
+* foo abc,$(x),$(y)
+*
+* and split into:
+* new_argv[0]: foo
+* new_argv[1]: abc
+* new_argv[2]: $(x)
+* new_argv[3]: $(y)
+*/
+ while (*p) {
+ if (nest == 0 && *p == delim) {
+ *p = 0;
+ new_argv[new_argc++] = prev;
+ prev = p + 1;
+ delim = ',';
+ } else if (*p == '(') {
+ nest++;
+ } else if (*p == ')') {
+ nest--;
+ }
+
+ p++;
+ }
+ new_argv[new_argc++] = prev;
+
+ /*
+* Shift arguments
+* new_argv[0] represents a function name or a variable name. Put it
+* into 'name', then shift the rest of the arguments. This simplifies
+* 'const' handling.
+*/
+ name = expand_string_with_args(new_argv[0], argc, argv);
+ new_argc--;
+ for (i = 0; i < new_argc; i++)
+ new_argv[i] = expand_string_with_args(new_argv[i + 1],
+ argc, argv);
+
+ free(tmp);
+
+ /* Look for built-in functions */
+ res = function_call(name, new_argc, new_argv);
+ if (res)
+ goto out;
+
+ /* Last, try environment variable */
+ if (new_argc == 0) {
+ res = env_expand(name);
+ if (res)
+ goto out;
+ }
+
+ res = xstrdup("");
+out:
free(name);
+ for (i = 0; i < new_argc; i++)
+ free(new_argv[i]);
return res;
}
@@ -115,7 +220,7 @@ static char *eval_clause(const char *in)
* This is because $ABC is equivalent to $(A)BC. (Like Make, you can omit
* parentheses if the variable name consists of a single character.
*/
-char *expand_dollar(const char **str)
+static char *expand_dollar_with_args(const char **str, int argc, char *argv[])
{
const char *p = *str;
const char *q;
@@ -124,6 +229,9 @@ cha
[PATCH 27/30] gcc-plugins: test plugin support in Kconfig and clean up Makefile
Run scripts/gcc-plugin.sh from Kconfig so that users can enable GCC_PLUGINS only when the compiler supports building plugins. Kconfig defines a new symbol, PLUGIN_HOSTCC. This will contain the compiler (g++ or gcc) used for building plugins, or empty if the plugin can not be supported at all. This allows us to remove all ugly testing in Makefile.gcc-plugins. Signed-off-by: Masahiro Yamada --- Changes in v3: - Respin to keep scripts/gcc-plugin.sh as-is. Changes in v2: None arch/Kconfig | 10 ++ scripts/Kconfig.include | 3 ++ scripts/Makefile.gcc-plugins | 79 scripts/gcc-plugins/Makefile | 1 + 4 files changed, 36 insertions(+), 57 deletions(-) diff --git a/arch/Kconfig b/arch/Kconfig index b0582f2..9166157 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -401,6 +401,15 @@ config SECCOMP_FILTER See Documentation/prctl/seccomp_filter.txt for details. +preferred-plugin-hostcc := $(shell [ $(gcc-version) -ge 40800 ] && echo $(HOSTCXX) || echo $(HOSTCC)) + +config PLUGIN_HOSTCC + string + default "$(shell $(srctree)/scripts/gcc-plugin.sh $(preferred-plugin-hostcc) $(HOSTCXX) $(CC))" + help + Host compiler used to build GCC plugins. This can be $(HOSTCXX), + $(HOSTCC), or a null string if GCC plugin is unsupported. + config HAVE_GCC_PLUGINS bool help @@ -410,6 +419,7 @@ config HAVE_GCC_PLUGINS menuconfig GCC_PLUGINS bool "GCC plugins" depends on HAVE_GCC_PLUGINS + depends on PLUGIN_HOSTCC != "" depends on !COMPILE_TEST help GCC plugins are loadable modules that provide extra features to the diff --git a/scripts/Kconfig.include b/scripts/Kconfig.include index cac7a81..0864a19 100644 --- a/scripts/Kconfig.include +++ b/scripts/Kconfig.include @@ -15,3 +15,6 @@ cc-option = $(success $(CC) -Werror $(1) -c -x c /dev/null -o /dev/null) # y if the given linker flag is supported, n otherwise ld-option = $(success $(LD) -v $(1)) + +# gcc version including patch level +gcc-version := $(shell $(srctree)/scripts/gcc-version.sh -p $(CC) | sed 's/^0*//') diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins index 1e92353..da5d38d 100644 --- a/scripts/Makefile.gcc-plugins +++ b/scripts/Makefile.gcc-plugins @@ -1,72 +1,37 @@ # SPDX-License-Identifier: GPL-2.0 -ifdef CONFIG_GCC_PLUGINS - __PLUGINCC := $(call cc-ifversion, -ge, 0408, $(HOSTCXX), $(HOSTCC)) - PLUGINCC := $(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-plugin.sh "$(__PLUGINCC)" "$(HOSTCXX)" "$(CC)") - - SANCOV_PLUGIN := -fplugin=$(objtree)/scripts/gcc-plugins/sancov_plugin.so - - gcc-plugin-$(CONFIG_GCC_PLUGIN_CYC_COMPLEXITY) += cyc_complexity_plugin.so +gcc-plugin-$(CONFIG_GCC_PLUGIN_CYC_COMPLEXITY) += cyc_complexity_plugin.so - gcc-plugin-$(CONFIG_GCC_PLUGIN_LATENT_ENTROPY) += latent_entropy_plugin.so - gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_LATENT_ENTROPY)+= -DLATENT_ENTROPY_PLUGIN - ifdef CONFIG_GCC_PLUGIN_LATENT_ENTROPY +gcc-plugin-$(CONFIG_GCC_PLUGIN_LATENT_ENTROPY) += latent_entropy_plugin.so +gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_LATENT_ENTROPY) += -DLATENT_ENTROPY_PLUGIN +ifdef CONFIG_GCC_PLUGIN_LATENT_ENTROPY DISABLE_LATENT_ENTROPY_PLUGIN += -fplugin-arg-latent_entropy_plugin-disable - endif - - ifdef CONFIG_GCC_PLUGIN_SANCOV - # It is needed because of the gcc-plugin.sh and gcc version checks. - gcc-plugin-$(CONFIG_GCC_PLUGIN_SANCOV) += sancov_plugin.so - - ifeq ($(PLUGINCC),) -$(warning warning: cannot use CONFIG_KCOV: -fsanitize-coverage=trace-pc is not supported by compiler) - endif - endif - - gcc-plugin-$(CONFIG_GCC_PLUGIN_STRUCTLEAK) += structleak_plugin.so - gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_STRUCTLEAK_VERBOSE)+= -fplugin-arg-structleak_plugin-verbose - gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL) += -fplugin-arg-structleak_plugin-byref-all - gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_STRUCTLEAK)+= -DSTRUCTLEAK_PLUGIN +endif - gcc-plugin-$(CONFIG_GCC_PLUGIN_RANDSTRUCT) += randomize_layout_plugin.so - gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_RANDSTRUCT)+= -DRANDSTRUCT_PLUGIN - gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_RANDSTRUCT_PERFORMANCE)+= -fplugin-arg-randomize_layout_plugin-performance-mode +gcc-plugin-$(CONFIG_GCC_PLUGIN_SANCOV) += sancov_plugin.so +gcc-plugin-$(CONFIG_GCC_PLUGIN_STRUCTLEAK) += structleak_plugin.so +gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_STRUCTLEAK_VERBOSE) += -fplugin-arg-structleak_plugin-verbose +gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL)+= -fplugin-arg-structleak_plugin-byref-all +gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_STRUCTLEAK) += -DSTRUCTLEAK_PLUGIN - GCC_PLUGINS_CFLAGS := $(strip $(addprefix -fplugin=$(objtree)/scripts/gcc-plugins/, $(gcc-plugin-y)) $(gcc-plugin-cflags-y)) +gcc-plugin-$(CONFIG_GCC_PLUGI
[PATCH 14/30] kconfig: support append assignment operator
Support += operator. This appends a space and the text on the
righthand side to a variable.
The timing of the evaluation of the righthand side depends on the
flavor of the variable. If the lefthand side was originally defined
as a simple variable, the righthand side is expanded immediately.
Otherwise, the expansion is deferred. Appending something to an
undefined variable results in a recursive variable.
To implement this, we need to remember the flavor of variables.
Signed-off-by: Masahiro Yamada
---
Changes in v3:
- newly added
Changes in v2: None
scripts/kconfig/lkc_proto.h | 1 +
scripts/kconfig/preprocess.c | 29 +++--
scripts/kconfig/zconf.l | 1 +
3 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/scripts/kconfig/lkc_proto.h b/scripts/kconfig/lkc_proto.h
index 6303193..a8b7a33 100644
--- a/scripts/kconfig/lkc_proto.h
+++ b/scripts/kconfig/lkc_proto.h
@@ -52,6 +52,7 @@ const char * prop_get_type_name(enum prop_type type);
enum variable_flavor {
VAR_SIMPLE,
VAR_RECURSIVE,
+ VAR_APPEND,
};
void env_write_dep(FILE *f, const char *auto_conf_name);
void variable_add(const char *name, const char *value,
diff --git a/scripts/kconfig/preprocess.c b/scripts/kconfig/preprocess.c
index a835c94..85972fb 100644
--- a/scripts/kconfig/preprocess.c
+++ b/scripts/kconfig/preprocess.c
@@ -86,6 +86,7 @@ static LIST_HEAD(variable_list);
struct variable {
char *name;
char *value;
+ enum variable_flavor flavor;
struct list_head node;
};
@@ -116,18 +117,42 @@ void variable_add(const char *name, const char *value,
enum variable_flavor flavor)
{
struct variable *v;
+ char *new_value;
+ bool append = false;
v = variable_lookup(name);
if (v) {
- free(v->value);
+ /* For defined variables, += inherits the existing flavor */
+ if (flavor == VAR_APPEND) {
+ flavor = v->flavor;
+ append = true;
+ } else {
+ free(v->value);
+ }
} else {
+ /* For undefined variables, += assumes the recursive flavor */
+ if (flavor == VAR_APPEND)
+ flavor = VAR_RECURSIVE;
+
v = xmalloc(sizeof(*v));
v->name = xstrdup(name);
list_add_tail(&v->node, &variable_list);
}
- v->value = (flavor == VAR_SIMPLE) ? expand_string(value) :
+ v->flavor = flavor;
+
+ new_value = (flavor == VAR_SIMPLE) ? expand_string(value) :
xstrdup(value);
+
+ if (append) {
+ v->value = xrealloc(v->value,
+ strlen(v->value) + strlen(new_value) + 2);
+ strcat(v->value, " ");
+ strcat(v->value, new_value);
+ free(new_value);
+ } else {
+ v->value = new_value;
+ }
}
static void variable_del(struct variable *v)
diff --git a/scripts/kconfig/zconf.l b/scripts/kconfig/zconf.l
index aa76942..c68ca56b 100644
--- a/scripts/kconfig/zconf.l
+++ b/scripts/kconfig/zconf.l
@@ -116,6 +116,7 @@ n [A-Za-z0-9_-]
}
"=" { BEGIN(ASSIGN_VAL); yylval.flavor = VAR_RECURSIVE; return
T_ASSIGN; }
":="{ BEGIN(ASSIGN_VAL); yylval.flavor = VAR_SIMPLE; return
T_ASSIGN; }
+ "+="{ BEGIN(ASSIGN_VAL); yylval.flavor = VAR_APPEND; return
T_ASSIGN; }
[[:blank:]]+
. warn_ignored_character(*yytext);
\n {
--
2.7.4
[PATCH 21/30] stack-protector: test compiler capability in Kconfig and drop AUTO mode
Move the test for -fstack-protector(-strong) option to Kconfig.
If the compiler does not support the option, the corresponding menu
is automatically hidden. If STRONG is not supported, it will fall
back to REGULAR. If REGULAR is not supported, it will be disabled.
This means, AUTO is implicitly handled by the dependency solver of
Kconfig, hence removed.
I also turned the 'choice' into only two boolean symbols. The use of
'choice' is not a good idea here, because all of all{yes,mod,no}config
would choose the first visible value, while we want allnoconfig to
disable as many features as possible.
X86 has additional shell scripts in case the compiler supports those
options, but generates broken code. I added CC_HAS_SANE_STACKPROTECTOR
to test this. I had to add -m32 to gcc-x86_32-has-stack-protector.sh
to make it work correctly.
Signed-off-by: Masahiro Yamada
---
Changes in v3: None
Changes in v2: None
Makefile | 93 ++-
arch/Kconfig | 32 ---
arch/x86/Kconfig | 11 +++-
scripts/gcc-x86_32-has-stack-protector.sh | 7 +--
scripts/gcc-x86_64-has-stack-protector.sh | 5 --
5 files changed, 28 insertions(+), 120 deletions(-)
diff --git a/Makefile b/Makefile
index 4b36329..889d002 100644
--- a/Makefile
+++ b/Makefile
@@ -672,55 +672,11 @@ ifneq ($(CONFIG_FRAME_WARN),0)
KBUILD_CFLAGS += $(call cc-option,-Wframe-larger-than=${CONFIG_FRAME_WARN})
endif
-# This selects the stack protector compiler flag. Testing it is delayed
-# until after .config has been reprocessed, in the prepare-compiler-check
-# target.
-ifdef CONFIG_CC_STACKPROTECTOR_AUTO
- stackp-flag := $(call cc-option,-fstack-protector-strong,$(call
cc-option,-fstack-protector))
- stackp-name := AUTO
-else
-ifdef CONFIG_CC_STACKPROTECTOR_REGULAR
- stackp-flag := -fstack-protector
- stackp-name := REGULAR
-else
-ifdef CONFIG_CC_STACKPROTECTOR_STRONG
- stackp-flag := -fstack-protector-strong
- stackp-name := STRONG
-else
- # If either there is no stack protector for this architecture or
- # CONFIG_CC_STACKPROTECTOR_NONE is selected, we're done, and $(stackp-name)
- # is empty, skipping all remaining stack protector tests.
- #
- # Force off for distro compilers that enable stack protector by default.
- KBUILD_CFLAGS += $(call cc-option, -fno-stack-protector)
-endif
-endif
-endif
-# Find arch-specific stack protector compiler sanity-checking script.
-ifdef stackp-name
-ifneq ($(stackp-flag),)
- stackp-path :=
$(srctree)/scripts/gcc-$(SRCARCH)_$(BITS)-has-stack-protector.sh
- stackp-check := $(wildcard $(stackp-path))
- # If the wildcard test matches a test script, run it to check functionality.
- ifdef stackp-check
-ifneq ($(shell $(CONFIG_SHELL) $(stackp-check) $(CC) $(KBUILD_CPPFLAGS)
$(biarch)),y)
- stackp-broken := y
-endif
- endif
- ifndef stackp-broken
-# If the stack protector is functional, enable code that depends on it.
-KBUILD_CPPFLAGS += -DCONFIG_CC_STACKPROTECTOR
-# Either we've already detected the flag (for AUTO) or we'll fail the
-# build in the prepare-compiler-check rule (for specific flag).
-KBUILD_CFLAGS += $(stackp-flag)
- else
-# We have to make sure stack protector is unconditionally disabled if
-# the compiler is broken (in case we're going to continue the build in
-# AUTO mode).
-KBUILD_CFLAGS += $(call cc-option, -fno-stack-protector)
- endif
-endif
-endif
+stackp-flags-$(CONFIG_CC_HAS_STACKPROTECTOR_NONE) := -fno-stack-protector
+stackp-flags-$(CONFIG_CC_STACKPROTECTOR) := -fstack-protector
+stackp-flags-$(CONFIG_CC_STACKPROTECTOR_STRONG) := -fstack-protector-strong
+
+KBUILD_CFLAGS += $(stackp-flags-y)
ifeq ($(cc-name),clang)
KBUILD_CPPFLAGS += $(call cc-option,-Qunused-arguments,)
@@ -1096,7 +1052,7 @@ endif
# prepare2 creates a makefile if using a separate output directory.
# From this point forward, .config has been reprocessed, so any rules
# that need to depend on updated CONFIG_* values can be checked here.
-prepare2: prepare3 prepare-compiler-check outputmakefile asm-generic
+prepare2: prepare3 outputmakefile asm-generic
prepare1: prepare2 $(version_h) $(autoksyms_h) include/generated/utsrelease.h \
include/config/auto.conf
@@ -1122,43 +1078,6 @@ uapi-asm-generic:
PHONY += prepare-objtool
prepare-objtool: $(objtool_target)
-# Check for CONFIG flags that require compiler support. Abort the build
-# after .config has been processed, but before the kernel build starts.
-#
-# For security-sensitive CONFIG options, we don't want to fallback and/or
-# silently change which compiler flags will be used, since that leads to
-# producing kernels with different security feature characteristics
-# depending on the compiler used. (For example, "But I selected
-# CC_STACKPROTECTOR_STRONG! Why did it build with _REGULAR?!")
-PHONY += prepare-compiler-check
-prepare-compiler-check: FORCE
[PATCH 01/30] gcc-plugins: fix build condition of SANCOV plugin
Since commit d677a4d60193 ("Makefile: support flag
-fsanitizer-coverage=trace-cmp"), you miss to build the SANCOV
plugin under some circumstances.
CONFIG_KCOV=y
CONFIG_KCOV_ENABLE_COMPARISONS=y
Your compiler does not support -fsanitize-coverage=trace-pc
Your compiler does not support -fsanitize-coverage=trace-cmp
Under this condition, $(CFLAGS_KCOV) is not empty but contains a
space, so the following ifeq-conditional is false.
ifeq ($(CFLAGS_KCOV),)
Then, scripts/Makefile.gcc-plugins misses to add sancov_plugin.so to
gcc-plugin-y while the SANCOV plugin is necessary as an alternative
means.
Fixes: d677a4d60193 ("Makefile: support flag -fsanitizer-coverage=trace-cmp")
Signed-off-by: Masahiro Yamada
---
Changes in v3:
- newly added
Changes in v2: None
scripts/Makefile.gcc-plugins | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins
index b2a95af..7f5c862 100644
--- a/scripts/Makefile.gcc-plugins
+++ b/scripts/Makefile.gcc-plugins
@@ -14,7 +14,7 @@ ifdef CONFIG_GCC_PLUGINS
endif
ifdef CONFIG_GCC_PLUGIN_SANCOV
-ifeq ($(CFLAGS_KCOV),)
+ifeq ($(strip $(CFLAGS_KCOV)),)
# It is needed because of the gcc-plugin.sh and gcc version checks.
gcc-plugin-$(CONFIG_GCC_PLUGIN_SANCOV) += sancov_plugin.so
--
2.7.4
[PATCH 02/30] kbuild: remove kbuild cache
The kbuild cache was introduced to remember the result of shell
commands, some of which are expensive to compute, such as
$(call cc-option,...).
However, this turned out not so clever as I had first expected.
Actually, it is problematic. For example, "$(CC) -print-file-name"
is cached. If the compiler is updated, the stale search path causes
build error, which is difficult to figure out. Another problem
scenario is cache files could be touched while install targets are
running under the root permission. We can patch them if desired,
but the build infrastructure is getting uglier and uglier.
Now, we are going to move compiler flag tests to the configuration
phase. If this is completed, the result of compiler tests will be
naturally cached in the .config file. We will not have performance
issues of incremental building since this testing only happens at
Kconfig time.
To start this work with a cleaner code base, remove the kbuild
cache first.
Revert the following commits:
Commit 9a234a2e3843 ("kbuild: create directory for make cache only when
necessary")
Commit e17c400ae194 ("kbuild: shrink .cache.mk when it exceeds 1000 lines")
Commit 4e56207130ed ("kbuild: Cache a few more calls to the compiler")
Commit 3298b690b21c ("kbuild: Add a cache for generated variables")
Signed-off-by: Masahiro Yamada
Reviewed-by: Kees Cook
---
Changes in v3: None
Changes in v2: None
Makefile | 5 +--
scripts/Kbuild.include | 101 +++--
2 files changed, 16 insertions(+), 90 deletions(-)
diff --git a/Makefile b/Makefile
index c1a608a..d85cee0 100644
--- a/Makefile
+++ b/Makefile
@@ -501,7 +501,7 @@ RETPOLINE_CFLAGS := $(call
cc-option,$(RETPOLINE_CFLAGS_GCC),$(call cc-option,$(
export RETPOLINE_CFLAGS
# check for 'asm goto'
-ifeq ($(call shell-cached,$(CONFIG_SHELL) $(srctree)/scripts/gcc-goto.sh $(CC)
$(KBUILD_CFLAGS)), y)
+ifeq ($(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-goto.sh $(CC)
$(KBUILD_CFLAGS)), y)
CC_HAVE_ASM_GOTO := 1
KBUILD_CFLAGS += -DCC_HAVE_ASM_GOTO
KBUILD_AFLAGS += -DCC_HAVE_ASM_GOTO
@@ -804,7 +804,7 @@ KBUILD_CFLAGS += $(call cc-option,-fdata-sections,)
endif
# arch Makefile may override CC so keep this after arch Makefile is included
-NOSTDINC_FLAGS += -nostdinc -isystem $(call shell-cached,$(CC)
-print-file-name=include)
+NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include)
CHECKFLAGS += $(NOSTDINC_FLAGS)
# warn about C99 declaration after statement
@@ -1617,7 +1617,6 @@ clean: $(clean-dirs)
-o -name '.*.d' -o -name '.*.tmp' -o -name '*.mod.c' \
-o -name '*.symtypes' -o -name 'modules.order' \
-o -name modules.builtin -o -name '.tmp_*.o.*' \
- -o -name .cache.mk \
-o -name '*.c.[012]*.*' \
-o -name '*.ll' \
-o -name '*.gcno' \) -type f -print | xargs rm -f
diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index cce31ee..9f7eb10 100644
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -8,8 +8,6 @@ squote := '
empty :=
space := $(empty) $(empty)
space_escape := _-_SPACE_-_
-right_paren := )
-left_paren := (
###
# Name of target with a '.' as filename prefix. foo/bar.o => foo/.bar.o
@@ -82,71 +80,6 @@ cc-cross-prefix = \
echo $(c);\
fi)))
-# Tools for caching Makefile variables that are "expensive" to compute.
-#
-# Here we want to help deal with variables that take a long time to compute
-# by making it easy to store these variables in a cache.
-#
-# The canonical example here is testing for compiler flags. On a simple system
-# each call to the compiler takes 10 ms, but on a system with a compiler that's
-# called through various wrappers it can take upwards of 100 ms. If we have
-# 100 calls to the compiler this can take 1 second (on a simple system) or 10
-# seconds (on a complicated system).
-#
-# The "cache" will be in Makefile syntax and can be directly included.
-# Any time we try to reference a variable that's not in the cache we'll
-# calculate it and store it in the cache for next time.
-
-# Include values from last time
-make-cache := $(if $(KBUILD_EXTMOD),$(KBUILD_EXTMOD)/,$(if
$(obj),$(obj)/)).cache.mk
-$(make-cache): ;
--include $(make-cache)
-
-cached-data := $(filter __cached_%, $(.VARIABLES))
-
-# If cache exceeds 1000 lines, shrink it down to 500.
-ifneq ($(word 1000,$(cached-data)),)
-$(shell tail -n 500 $(make-cache) > $(make-cache).tmp; \
- mv $(make-cache).tmp $(make-cache))
-endif
-
-create-cache-dir := $(if $(KBUILD_SRC),$(if $(cache-data),,1))
-
-# Usage: $(call __sanitize-opt,Hello=Hola$(comma)Goodbye Adios)
-#
-# Convert all '$', ')', '(', '\', '=', ' ', ',', ':' to '_'
-__sanitize-opt = $(subst $$,_,$(subst $(right_paren),_,$(subst
$(left_paren),_,$(subst \,_,$(subst =,_,$(subst $(space),_,$(subst
$(comma),_,$(subst :,_
[PATCH 12/30] kconfig: support variable and user-defined function
Now, we got a basic ability to test compiler capability in Kconfig.
config CC_HAS_STACKPROTECTOR
def_bool $(shell (($(CC) -Werror -fstack-protector -c -x c /dev/null -o
/dev/null 2>/dev/null) && echo y) || echo n)
This works, but it is ugly to repeat this long boilerplate.
We want to describe like this:
config CC_HAS_STACKPROTECTOR
bool
default $(cc-option -fstack-protector)
It is straight-forward to add a new function, but I do not like to
hard-code specialized functions like this. Hence, here is another
feature, user-defined function. This works as a textual shorthand
with parameterization.
A user-defined function is defined by using the = operator, and can
be referenced in the same way as built-in functions. A user-defined
function in Make is referenced like $(call func-name, arg1, arg2),
but I omitted the 'call' to make the syntax shorter.
The definition of a user-defined function contains $(1), $(2), etc.
in its body to reference the parameters. It is grammatically valid
to pass more or fewer arguments when calling it. We already exploit
this feature in our makefiles; scripts/Kbuild.include defines cc-option
which takes two arguments at most, but most of the callers pass only
one argument.
By the way, a variable is supported at a subset of this feature since
a variable is "a user-defined function with zero argument". In this
context, I mean "variable" as recursively expanded variable. I will
add a different flavored variable later on.
The code above can be written as follows:
[Example Code]
success = $(shell ($(1)) >/dev/null 2>&1 && echo y || echo n)
cc-option = $(success $(CC) -Werror $(1) -c -x c /dev/null -o /dev/null)
config CC_HAS_STACKPROTECTOR
def_bool $(cc-option -fstack-protector)
[Result]
$ make -s alldefconfig && tail -n 1 .config
CONFIG_CC_HAS_STACKPROTECTOR=y
Signed-off-by: Masahiro Yamada
---
Changes in v3:
- Re-implement the parse logic
- Use = operator to define a user-defined function
Changes in v2:
- Use 'macro' directly instead of inside the string type symbol.
scripts/kconfig/lkc_proto.h | 2 +
scripts/kconfig/preprocess.c | 96 +++-
scripts/kconfig/zconf.l | 17 +++-
scripts/kconfig/zconf.y | 21 +-
4 files changed, 132 insertions(+), 4 deletions(-)
diff --git a/scripts/kconfig/lkc_proto.h b/scripts/kconfig/lkc_proto.h
index c46929f..2b16d6e 100644
--- a/scripts/kconfig/lkc_proto.h
+++ b/scripts/kconfig/lkc_proto.h
@@ -50,6 +50,8 @@ const char * prop_get_type_name(enum prop_type type);
/* preprocess.c */
void env_write_dep(FILE *f, const char *auto_conf_name);
+void variable_add(const char *name, const char *value);
+void variable_all_del(void);
char *expand_string(const char *in);
char *expand_dollar(const char **str);
char *expand_one_token(const char **str);
diff --git a/scripts/kconfig/preprocess.c b/scripts/kconfig/preprocess.c
index f4c606f..1b746e0 100644
--- a/scripts/kconfig/preprocess.c
+++ b/scripts/kconfig/preprocess.c
@@ -79,6 +79,72 @@ void env_write_dep(FILE *f, const char *autoconfig_name)
}
/*
+ * Variables and User-defined Functions
+ */
+static LIST_HEAD(variable_list);
+
+struct variable {
+ char *name;
+ char *value;
+ struct list_head node;
+};
+
+static struct variable *variable_lookup(const char *name)
+{
+ struct variable *v;
+
+ list_for_each_entry(v, &variable_list, node) {
+ if (!strcmp(name, v->name))
+ return v;
+ }
+
+ return NULL;
+}
+
+static char *variable_expand(const char *name, int argc, char *argv[])
+{
+ struct variable *v;
+
+ v = variable_lookup(name);
+ if (!v)
+ return NULL;
+
+ return expand_string_with_args(v->value, argc, argv);
+}
+
+void variable_add(const char *name, const char *value)
+{
+ struct variable *v;
+
+ v = variable_lookup(name);
+ if (v) {
+ free(v->value);
+ } else {
+ v = xmalloc(sizeof(*v));
+ v->name = xstrdup(name);
+ list_add_tail(&v->node, &variable_list);
+ }
+
+ v->value = xstrdup(value);
+}
+
+static void variable_del(struct variable *v)
+{
+ list_del(&v->node);
+ free(v->name);
+ free(v->value);
+ free(v);
+}
+
+void variable_all_del(void)
+{
+ struct variable *v, *tmp;
+
+ list_for_each_entry_safe(v, tmp, &variable_list, node)
+ variable_del(v);
+}
+
+/*
* Built-in Functions
*/
struct function {
@@ -175,16 +241,30 @@ static char *function_call(const char *name, int argc,
char *argv[])
* Evaluate a clause with arguments. argc/argv are arguments from the upper
* function call.
*
+ * Let's say 'foo' is defined as:
+ * foo = ABC$(1)PQR(2)XYZ
+ * and you want to evaluate $(foo x,y)
+ *
+ * First, this helper is called with:
+ * in :foo x,y
+ * argc:0
+ * and then, recursively called
[PATCH 05/30] kconfig: remove string expansion in file_lookup()
There are two callers of file_lookup(), but there is no more reason
to expand the given path.
[1] zconf_initscan()
This is used to open the first Kconfig. sym_expand_string_value()
has never been used in a useful way here; before opening the first
Kconfig file, obviously there is no symbol to expand. If you use
expand_string_value() instead, environments in KBUILD_KCONFIG would
be expanded, but I do not see practical benefits for that.
[2] zconf_nextfile()
This is used to open the next file from 'source' statement.
Symbols in the path like "arch/$SRCARCH/Kconfig" needed expanding,
but it was replaced with the direct environment expansion. The
environment has already been expanded before the token is passed
to the parser.
By the way, file_lookup() was already buggy; it expanded a given path,
but it used the path before expansion for look-up:
if (!strcmp(name, file->name)) {
Signed-off-by: Masahiro Yamada
Reviewed-by: Kees Cook
Reviewed-by: Ulf Magnusson
---
Changes in v3: None
Changes in v2:
- Simplify the patch. Just remove text expansion.
scripts/kconfig/util.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/scripts/kconfig/util.c b/scripts/kconfig/util.c
index 807147e..790967df 100644
--- a/scripts/kconfig/util.c
+++ b/scripts/kconfig/util.c
@@ -14,18 +14,16 @@
struct file *file_lookup(const char *name)
{
struct file *file;
- char *file_name = sym_expand_string_value(name);
for (file = file_list; file; file = file->next) {
if (!strcmp(name, file->name)) {
- free(file_name);
return file;
}
}
file = xmalloc(sizeof(*file));
memset(file, 0, sizeof(*file));
- file->name = file_name;
+ file->name = xstrdup(name);
file->next = file_list;
file_list = file;
return file;
--
2.7.4
[PATCH 07/30] kconfig: remove sym_expand_string_value()
There is no more caller of sym_expand_string_value().
Signed-off-by: Masahiro Yamada
---
Changes in v3:
- newly added
Changes in v2: None
scripts/kconfig/lkc_proto.h | 1 -
scripts/kconfig/symbol.c| 53 -
2 files changed, 54 deletions(-)
diff --git a/scripts/kconfig/lkc_proto.h b/scripts/kconfig/lkc_proto.h
index 9f465fe..c46929f 100644
--- a/scripts/kconfig/lkc_proto.h
+++ b/scripts/kconfig/lkc_proto.h
@@ -31,7 +31,6 @@ extern struct symbol * symbol_hash[SYMBOL_HASHSIZE];
struct symbol * sym_lookup(const char *name, int flags);
struct symbol * sym_find(const char *name);
-char *sym_expand_string_value(const char *in);
const char * sym_escape_string_value(const char *in);
struct symbol ** sym_re_search(const char *pattern);
const char * sym_type_name(enum symbol_type type);
diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
index 2460648..7c9a88e 100644
--- a/scripts/kconfig/symbol.c
+++ b/scripts/kconfig/symbol.c
@@ -879,59 +879,6 @@ struct symbol *sym_find(const char *name)
return symbol;
}
-/*
- * Expand symbol's names embedded in the string given in argument. Symbols'
- * name to be expanded shall be prefixed by a '$'. Unknown symbol expands to
- * the empty string.
- */
-char *sym_expand_string_value(const char *in)
-{
- const char *src;
- char *res;
- size_t reslen;
-
- /*
-* Note: 'in' might come from a token that's about to be
-* freed, so make sure to always allocate a new string
-*/
- reslen = strlen(in) + 1;
- res = xmalloc(reslen);
- res[0] = '\0';
-
- while ((src = strchr(in, '$'))) {
- char *p, name[SYMBOL_MAXLENGTH];
- const char *symval = "";
- struct symbol *sym;
- size_t newlen;
-
- strncat(res, in, src - in);
- src++;
-
- p = name;
- while (isalnum(*src) || *src == '_')
- *p++ = *src++;
- *p = '\0';
-
- sym = sym_find(name);
- if (sym != NULL) {
- sym_calc_value(sym);
- symval = sym_get_string_value(sym);
- }
-
- newlen = strlen(res) + strlen(symval) + strlen(src) + 1;
- if (newlen > reslen) {
- reslen = newlen;
- res = xrealloc(res, reslen);
- }
-
- strcat(res, symval);
- in = src;
- }
- strcat(res, in);
-
- return res;
-}
-
const char *sym_escape_string_value(const char *in)
{
const char *p;
--
2.7.4
Re: KMSAN: uninit-value in __netif_receive_skb_core
syzbot has found reproducer for the following crash on https://github.com/google/kmsan.git/master commit 35ff515e4bda2646f6c881d33951c306ea9c282a (Tue Apr 10 08:59:43 2018 +) Merge pull request #11 from parkerduckworth/readme syzbot dashboard link: https://syzkaller.appspot.com/bug?extid=b202b7208664142954fa So far this crash happened 3 times on https://github.com/google/kmsan.git/master. C reproducer: https://syzkaller.appspot.com/x/repro.c?id=455991623680 syzkaller reproducer: https://syzkaller.appspot.com/x/repro.syz?id=4590273065648128 Raw console output: https://syzkaller.appspot.com/x/log.txt?id=4631921027973120 Kernel config: https://syzkaller.appspot.com/x/.config?id=6627248707860932248 compiler: clang version 7.0.0 (trunk 329391) IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+b202b720866414295...@syzkaller.appspotmail.com It will help syzbot understand when the bug is fixed. == BUG: KMSAN: uninit-value in __read_once_size include/linux/compiler.h:197 [inline] BUG: KMSAN: uninit-value in deliver_ptype_list_skb net/core/dev.c:1908 [inline] BUG: KMSAN: uninit-value in __netif_receive_skb_core+0x4630/0x4a80 net/core/dev.c:4545 CPU: 0 PID: 3514 Comm: syzkaller031167 Not tainted 4.16.0+ #83 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:17 [inline] dump_stack+0x185/0x1d0 lib/dump_stack.c:53 kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067 __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:676 __read_once_size include/linux/compiler.h:197 [inline] deliver_ptype_list_skb net/core/dev.c:1908 [inline] __netif_receive_skb_core+0x4630/0x4a80 net/core/dev.c:4545 __netif_receive_skb net/core/dev.c:4627 [inline] process_backlog+0x62d/0xe20 net/core/dev.c:5307 napi_poll net/core/dev.c:5705 [inline] net_rx_action+0x7c1/0x1a70 net/core/dev.c:5771 __do_softirq+0x56d/0x93d kernel/softirq.c:285 do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1040 do_softirq kernel/softirq.c:329 [inline] __local_bh_enable_ip+0x114/0x140 kernel/softirq.c:182 local_bh_enable+0x36/0x40 include/linux/bottom_half.h:32 rcu_read_unlock_bh include/linux/rcupdate.h:726 [inline] __dev_queue_xmit+0x2a31/0x2b60 net/core/dev.c:3584 dev_queue_xmit+0x4b/0x60 net/core/dev.c:3590 packet_snd net/packet/af_packet.c:2944 [inline] packet_sendmsg+0x7c57/0x8a10 net/packet/af_packet.c:2969 sock_sendmsg_nosec net/socket.c:630 [inline] sock_sendmsg net/socket.c:640 [inline] sock_write_iter+0x3b9/0x470 net/socket.c:909 do_iter_readv_writev+0x7bb/0x970 include/linux/fs.h:1776 do_iter_write+0x30d/0xd40 fs/read_write.c:932 vfs_writev fs/read_write.c:977 [inline] do_writev+0x3c9/0x830 fs/read_write.c:1012 SYSC_writev+0x9b/0xb0 fs/read_write.c:1085 SyS_writev+0x56/0x80 fs/read_write.c:1082 do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 RIP: 0033:0x43ffb9 RSP: 002b:7ffd42187708 EFLAGS: 0217 ORIG_RAX: 0014 RAX: ffda RBX: 004002c8 RCX: 0043ffb9 RDX: 0001 RSI: 200010c0 RDI: 0003 RBP: 006ca018 R08: 004002c8 R09: 004002c8 R10: 004002c8 R11: 0217 R12: 004018e0 R13: 00401970 R14: R15: Uninit was stored to memory at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline] kmsan_save_stack mm/kmsan/kmsan.c:293 [inline] kmsan_internal_chain_origin+0x12b/0x210 mm/kmsan/kmsan.c:684 __msan_chain_origin+0x69/0xc0 mm/kmsan/kmsan_instr.c:521 skb_vlan_untag+0x950/0xee0 include/linux/if_vlan.h:597 __netif_receive_skb_core+0x70a/0x4a80 net/core/dev.c:4460 __netif_receive_skb net/core/dev.c:4627 [inline] process_backlog+0x62d/0xe20 net/core/dev.c:5307 napi_poll net/core/dev.c:5705 [inline] net_rx_action+0x7c1/0x1a70 net/core/dev.c:5771 __do_softirq+0x56d/0x93d kernel/softirq.c:285 Uninit was created at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline] kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:188 kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:314 kmsan_slab_alloc+0x11/0x20 mm/kmsan/kmsan.c:321 slab_post_alloc_hook mm/slab.h:445 [inline] slab_alloc_node mm/slub.c:2737 [inline] __kmalloc_node_track_caller+0xaed/0x11c0 mm/slub.c:4369 __kmalloc_reserve net/core/skbuff.c:138 [inline] __alloc_skb+0x2cf/0x9f0 net/core/skbuff.c:206 alloc_skb include/linux/skbuff.h:984 [inline] alloc_skb_with_frags+0x1d4/0xb20 net/core/skbuff.c:5234 sock_alloc_send_pskb+0xb56/0x1190 net/core/sock.c:2085 packet_alloc_skb net/packet/af_packet.c:2803 [inline] packet_snd net/packet/af_packet.c:2894 [inline] packet_sendmsg+0x6444/0x8a10 net/packet/af_packet.c:2969 sock_sendmsg_nosec net/socket.c:630 [inline] sock_sendmsg net/socket.c:640 [inline] sock_write_iter+0x3b9/0x470 net/
[PATCH 06/30] kconfig: remove string expansion for mainmenu after yyparse()
Now that environments are expanded in the lexer, conf_parse() does
not need to expand them explicitly.
The hack introduced by commit 0724a7c32a54 ("kconfig: Don't leak
main menus during parsing") can go away.
Signed-off-by: Masahiro Yamada
Reviewed-by: Kees Cook
Reviewed-by: Ulf Magnusson
---
Changes in v3: None
Changes in v2:
- Simplify the patch. Just remove the text expansion.
scripts/kconfig/zconf.y | 24 +---
1 file changed, 5 insertions(+), 19 deletions(-)
diff --git a/scripts/kconfig/zconf.y b/scripts/kconfig/zconf.y
index 3a4a0fa..22e318c 100644
--- a/scripts/kconfig/zconf.y
+++ b/scripts/kconfig/zconf.y
@@ -109,7 +109,7 @@ static struct menu *current_menu, *current_entry;
%%
input: nl start | start;
-start: mainmenu_stmt stmt_list | no_mainmenu_stmt stmt_list;
+start: mainmenu_stmt stmt_list | stmt_list;
/* mainmenu entry */
@@ -118,19 +118,6 @@ mainmenu_stmt: T_MAINMENU prompt nl
menu_add_prompt(P_MENU, $2, NULL);
};
-/* Default main menu, if there's no mainmenu entry */
-
-no_mainmenu_stmt: /* empty */
-{
- /*
-* Hack: Keep the main menu title on the heap so we can safely free it
-* later regardless of whether it comes from the 'prompt' in
-* mainmenu_stmt or here
-*/
- menu_add_prompt(P_MENU, xstrdup("Linux Kernel Configuration"), NULL);
-};
-
-
stmt_list:
/* empty */
| stmt_list common_stmt
@@ -528,7 +515,6 @@ word_opt: /* empty */ { $$ = NULL; }
void conf_parse(const char *name)
{
- const char *tmp;
struct symbol *sym;
int i;
@@ -544,10 +530,10 @@ void conf_parse(const char *name)
if (!modules_sym)
modules_sym = sym_find( "n" );
- tmp = rootmenu.prompt->text;
- rootmenu.prompt->text = _(rootmenu.prompt->text);
- rootmenu.prompt->text = sym_expand_string_value(rootmenu.prompt->text);
- free((char*)tmp);
+ if (!menu_has_prompt(&rootmenu)) {
+ current_entry = &rootmenu;
+ menu_add_prompt(P_MENU, "Linux Kernel Configuration", NULL);
+ }
menu_finalize(&rootmenu);
for_all_symbols(i, sym) {
--
2.7.4
[PATCH 26/30] gcc-plugins: move GCC version check for PowerPC to Kconfig
For PowerPC, GCC 5.2 is the requirement for GCC plugins. Move the version check to Kconfig so that the GCC plugin menus will be hidden if an older compiler is in use. Signed-off-by: Masahiro Yamada Acked-by: Andrew Donnellan --- Changes in v3: - Move comment to Kconfig as well Changes in v2: None arch/powerpc/Kconfig | 2 +- scripts/Makefile.gcc-plugins | 8 2 files changed, 1 insertion(+), 9 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 73ce5dd..512fcc1 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -195,7 +195,7 @@ config PPC select HAVE_FTRACE_MCOUNT_RECORD select HAVE_FUNCTION_GRAPH_TRACER select HAVE_FUNCTION_TRACER - select HAVE_GCC_PLUGINS + select HAVE_GCC_PLUGINS if GCC_VERSION >= 50200 # plugin support on gcc <= 5.1 is buggy on PPC select HAVE_GENERIC_GUP select HAVE_HW_BREAKPOINT if PERF_EVENTS && (PPC_BOOK3S || PPC_8xx) select HAVE_IDE diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins index 0ce3802..1e92353 100644 --- a/scripts/Makefile.gcc-plugins +++ b/scripts/Makefile.gcc-plugins @@ -53,14 +53,6 @@ gcc-plugins-check: FORCE ifdef CONFIG_GCC_PLUGINS ifeq ($(PLUGINCC),) ifneq ($(GCC_PLUGINS_CFLAGS),) - # Various gccs between 4.5 and 5.1 have bugs on powerpc due to missing - # header files. gcc <= 4.6 doesn't work at all, gccs from 4.8 to 5.1 have - # issues with 64-bit targets. - ifeq ($(ARCH),powerpc) -ifeq ($(call cc-ifversion, -le, 0501, y), y) - @echo "Cannot use CONFIG_GCC_PLUGINS: plugin support on gcc <= 5.1 is buggy on powerpc, please upgrade to gcc 5.2 or newer" >&2 && exit 1 -endif - endif ifeq ($(call cc-ifversion, -ge, 0405, y), y) $(Q)$(srctree)/scripts/gcc-plugin.sh --show-error "$(__PLUGINCC)" "$(HOSTCXX)" "$(CC)" || true @echo "Cannot use CONFIG_GCC_PLUGINS: your gcc installation does not support plugins, perhaps the necessary headers are missing?" >&2 && exit 1 -- 2.7.4
[PATCH 28/30] gcc-plugins: allow to enable GCC_PLUGINS for COMPILE_TEST
Now that the compiler's plugin support is checked in Kconfig,
all{yes,mod}config will not be bothered.
Remove 'depends on !COMPILE_TEST' for GCC_PLUGINS.
'depends on !COMPILE_TEST' for the following three are still kept:
GCC_PLUGIN_CYC_COMPLEXITY
GCC_PLUGIN_STRUCTLEAK_VERBOSE
GCC_PLUGIN_RANDSTRUCT_PERFORMANCE
Kees said to do so because the first two are too noisy, and the last
one would reduce the compile test coverage. I commented the reasons
in arch/Kconfig.
Signed-off-by: Masahiro Yamada
---
Changes in v3: None
Changes in v2: None
arch/Kconfig | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/Kconfig b/arch/Kconfig
index 9166157..95b9b2e 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -420,7 +420,6 @@ menuconfig GCC_PLUGINS
bool "GCC plugins"
depends on HAVE_GCC_PLUGINS
depends on PLUGIN_HOSTCC != ""
- depends on !COMPILE_TEST
help
GCC plugins are loadable modules that provide extra features to the
compiler. They are useful for runtime instrumentation and static
analysis.
@@ -430,7 +429,7 @@ menuconfig GCC_PLUGINS
config GCC_PLUGIN_CYC_COMPLEXITY
bool "Compute the cyclomatic complexity of a function" if EXPERT
depends on GCC_PLUGINS
- depends on !COMPILE_TEST
+ depends on !COMPILE_TEST# too noisy
help
The complexity M of a function's control flow graph is defined as:
M = E - N + 2P
@@ -493,7 +492,7 @@ config GCC_PLUGIN_STRUCTLEAK_BYREF_ALL
config GCC_PLUGIN_STRUCTLEAK_VERBOSE
bool "Report forcefully initialized variables"
depends on GCC_PLUGIN_STRUCTLEAK
- depends on !COMPILE_TEST
+ depends on !COMPILE_TEST# too noisy
help
This option will cause a warning to be printed each time the
structleak plugin finds a variable it thinks needs to be
@@ -533,7 +532,7 @@ config GCC_PLUGIN_RANDSTRUCT
config GCC_PLUGIN_RANDSTRUCT_PERFORMANCE
bool "Use cacheline-aware structure randomization"
depends on GCC_PLUGIN_RANDSTRUCT
- depends on !COMPILE_TEST
+ depends on !COMPILE_TEST# do not reduce test coverage
help
If you say Y here, the RANDSTRUCT randomization will make a
best effort at restricting randomization to cacheline-sized
--
2.7.4
[PATCH 25/30] kcov: test compiler capability in Kconfig and correct dependency
As Documentation/kbuild/kconfig-language.txt notes, 'select' should be
be used with care - it forces a lower limit of another symbol, ignoring
the dependency. Currently, KCOV can select GCC_PLUGINS even if arch
does not select HAVE_GCC_PLUGINS. This could cause the unmet direct
dependency.
Now that Kconfig can test compiler capability, let's handle this in a
more sophisticated way.
There are two ways to enable KCOV; use the compiler that natively
supports -fsanitize-coverage=trace-pc, or build the SANCOV plugin if
the compiler has ability to build GCC plugins. Hence, the correct
dependency for KCOV is:
depends on CC_HAS_SANCOV_TRACE_PC || GCC_PLUGINS
You do not need to build the SANCOV plugin if the compiler already
supports -fsanitize-coverage=trace-pc. Hence, the select should be:
select GCC_PLUGIN_SANCOV if !CC_HAS_SANCOV_TRACE_PC
With this, GCC_PLUGIN_SANCOV is selected only when necessary, so
scripts/Makefile.gcc-plugins can be cleaner.
I also cleaned up Kconfig and scripts/Makefile.kcov as well.
Signed-off-by: Masahiro Yamada
---
Changes in v3:
- Replace the previous 'select -> imply' patch with
a new approach
Changes in v2:
- Drop depends on GCC_VERSION
Makefile | 2 +-
lib/Kconfig.debug| 11 +++
scripts/Makefile.gcc-plugins | 6 +-
scripts/Makefile.kcov| 10 ++
4 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/Makefile b/Makefile
index 889d002..88733b7 100644
--- a/Makefile
+++ b/Makefile
@@ -623,7 +623,7 @@ all: vmlinux
KBUILD_CFLAGS += $(call cc-option,-fno-PIE)
KBUILD_AFLAGS += $(call cc-option,-fno-PIE)
CFLAGS_GCOV:= -fprofile-arcs -ftest-coverage -fno-tree-loop-im $(call
cc-disable-warning,maybe-uninitialized,)
-export CFLAGS_GCOV CFLAGS_KCOV
+export CFLAGS_GCOV
# The arch Makefile can set ARCH_{CPP,A,C}FLAGS to override the default
# values of the respective KBUILD_* variables
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index c40c7b7..1335717 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -736,12 +736,15 @@ config ARCH_HAS_KCOV
only for x86_64. KCOV requires testing on other archs, and most likely
disabling of instrumentation for some early boot code.
+config CC_HAS_SANCOV_TRACE_PC
+ def_bool $(cc-option -fsanitize-coverage=trace-pc)
+
config KCOV
bool "Code coverage for fuzzing"
depends on ARCH_HAS_KCOV
+ depends on CC_HAS_SANCOV_TRACE_PC || GCC_PLUGINS
select DEBUG_FS
- select GCC_PLUGINS if !COMPILE_TEST
- select GCC_PLUGIN_SANCOV if !COMPILE_TEST
+ select GCC_PLUGIN_SANCOV if !CC_HAS_SANCOV_TRACE_PC
help
KCOV exposes kernel code coverage information in a form suitable
for coverage-guided fuzzing (randomized testing).
@@ -755,7 +758,7 @@ config KCOV
config KCOV_ENABLE_COMPARISONS
bool "Enable comparison operands collection by KCOV"
depends on KCOV
- default n
+ depends on $(cc-option -fsanitize-coverage=trace-cmp)
help
KCOV also exposes operands of every comparison in the instrumented
code along with operand sizes and PCs of the comparison instructions.
@@ -765,7 +768,7 @@ config KCOV_ENABLE_COMPARISONS
config KCOV_INSTRUMENT_ALL
bool "Instrument all code by default"
depends on KCOV
- default y if KCOV
+ default y
help
If you are doing generic system call fuzzing (like e.g. syzkaller),
then you will want to instrument the whole kernel and you should
diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins
index 7f5c862..0ce3802 100644
--- a/scripts/Makefile.gcc-plugins
+++ b/scripts/Makefile.gcc-plugins
@@ -14,16 +14,12 @@ ifdef CONFIG_GCC_PLUGINS
endif
ifdef CONFIG_GCC_PLUGIN_SANCOV
-ifeq ($(strip $(CFLAGS_KCOV)),)
# It is needed because of the gcc-plugin.sh and gcc version checks.
gcc-plugin-$(CONFIG_GCC_PLUGIN_SANCOV) += sancov_plugin.so
- ifneq ($(PLUGINCC),)
-CFLAGS_KCOV := $(SANCOV_PLUGIN)
- else
+ ifeq ($(PLUGINCC),)
$(warning warning: cannot use CONFIG_KCOV:
-fsanitize-coverage=trace-pc is not supported by compiler)
endif
-endif
endif
gcc-plugin-$(CONFIG_GCC_PLUGIN_STRUCTLEAK) += structleak_plugin.so
diff --git a/scripts/Makefile.kcov b/scripts/Makefile.kcov
index 5cc7203..d71ba73 100644
--- a/scripts/Makefile.kcov
+++ b/scripts/Makefile.kcov
@@ -1,7 +1,9 @@
ifdef CONFIG_KCOV
-CFLAGS_KCOV:= $(call cc-option,-fsanitize-coverage=trace-pc,)
-ifeq ($(CONFIG_KCOV_ENABLE_COMPARISONS),y)
-CFLAGS_KCOV += $(call cc-option,-fsanitize-coverage=trace-cmp,)
-endif
+
+kcov-flags-$(CONFIG_CC_HAS_SANCOV_TRACE_PC)+= -fsanitize-coverage=trace-pc
+kcov-flags-$(CONFIG_KCOV_ENABLE_COMPARISONS) += -fsanitize-coverage=trace-cmp
+kcov-flags-$(CONFIG_GCC_PLUGIN_SANKOV) +=
-fplugin=$(objtree)/scripts/gcc-plugins/sancov_plugin.so
+
[PATCH 30/30] kbuild: test dead code/data elimination support in Kconfig
This config option should be enabled only when both the compiler and the linker support necessary flags. Add proper dependencies to Kconfig. Unlike 'select', 'imply' is modest enough to observe those dependencies. I suggested this in the help message. Signed-off-by: Masahiro Yamada --- Changes in v3: None Changes in v2: None Makefile | 8 ++-- arch/Kconfig | 4 +++- 2 files changed, 5 insertions(+), 7 deletions(-) diff --git a/Makefile b/Makefile index 88733b7..92db767 100644 --- a/Makefile +++ b/Makefile @@ -754,8 +754,8 @@ KBUILD_CFLAGS += $(call cc-option, -fno-inline-functions-called-once) endif ifdef CONFIG_LD_DEAD_CODE_DATA_ELIMINATION -KBUILD_CFLAGS += $(call cc-option,-ffunction-sections,) -KBUILD_CFLAGS += $(call cc-option,-fdata-sections,) +KBUILD_CFLAGS += -ffunction-sections -fdata-sections +LDFLAGS_vmlinux+= --gc-sections endif # arch Makefile may override CC so keep this after arch Makefile is included @@ -819,10 +819,6 @@ LDFLAGS_BUILD_ID := $(call ld-option, --build-id) KBUILD_LDFLAGS_MODULE += $(LDFLAGS_BUILD_ID) LDFLAGS_vmlinux += $(LDFLAGS_BUILD_ID) -ifdef CONFIG_LD_DEAD_CODE_DATA_ELIMINATION -LDFLAGS_vmlinux+= $(call ld-option, --gc-sections,) -endif - ifeq ($(CONFIG_STRIP_ASM_SYMS),y) LDFLAGS_vmlinux+= $(call ld-option, -X,) endif diff --git a/arch/Kconfig b/arch/Kconfig index 95b9b2e..e88f1ba 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -597,8 +597,10 @@ config CC_STACKPROTECTOR_STRONG config LD_DEAD_CODE_DATA_ELIMINATION bool + depends on $(cc-option -ffunction-sections -fdata-sections) + depends on $(ld-option --gc-sections) help - Select this if the architecture wants to do dead code and + Imply this if the architecture wants to do dead code and data elimination with the linker by compiling with -ffunction-sections -fdata-sections and linking with --gc-sections. -- 2.7.4
[PATCH 24/30] gcov: remove CONFIG_GCOV_FORMAT_AUTODETECT
CONFIG_GCOV_FORMAT_AUTODETECT compiles either gcc_3_4.c or gcc_4_7.c according to your GCC version. We can achieve the equivalent behavior by setting reasonable dependency with the knowledge of the compiler version. If GCC older than 4.7 is used, GCOV_FORMAT_3_4 is the default, but users are still allowed to select GCOV_FORMAT_4_7 in case the newer format is back-ported. On the other hand, If GCC 4.7 or newer is used, there is no reason to use GCOV_FORMAT_3_4, so it should be hidden. If you downgrade the compiler to GCC 4.7 or older, oldconfig/syncconfig will display a prompt for the choice because GCOV_FORMAT_3_4 becomes visible as a new symbol. Signed-off-by: Masahiro Yamada Acked-by: Peter Oberparleiter Reviewed-by: Kees Cook --- Changes in v3: None Changes in v2: None kernel/gcov/Kconfig | 17 + kernel/gcov/Makefile | 2 -- 2 files changed, 5 insertions(+), 14 deletions(-) diff --git a/kernel/gcov/Kconfig b/kernel/gcov/Kconfig index 1276aab..1e3823f 100644 --- a/kernel/gcov/Kconfig +++ b/kernel/gcov/Kconfig @@ -53,23 +53,16 @@ config GCOV_PROFILE_ALL choice prompt "Specify GCOV format" depends on GCOV_KERNEL - default GCOV_FORMAT_AUTODETECT ---help--- - The gcov format is usually determined by the GCC version, but there are + The gcov format is usually determined by the GCC version, and the + default is chosen according to your GCC version. However, there are exceptions where format changes are integrated in lower-version GCCs. - In such a case use this option to adjust the format used in the kernel - accordingly. - - If unsure, choose "Autodetect". - -config GCOV_FORMAT_AUTODETECT - bool "Autodetect" - ---help--- - Select this option to use the format that corresponds to your GCC - version. + In such a case, change this option to adjust the format used in the + kernel accordingly. config GCOV_FORMAT_3_4 bool "GCC 3.4 format" + depends on CC_IS_GCC && GCC_VERSION < 40700 ---help--- Select this option to use the format defined by GCC 3.4. diff --git a/kernel/gcov/Makefile b/kernel/gcov/Makefile index c6c50e5..ff06d64 100644 --- a/kernel/gcov/Makefile +++ b/kernel/gcov/Makefile @@ -4,5 +4,3 @@ ccflags-y := -DSRCTREE='"$(srctree)"' -DOBJTREE='"$(objtree)"' obj-y := base.o fs.o obj-$(CONFIG_GCOV_FORMAT_3_4) += gcc_3_4.o obj-$(CONFIG_GCOV_FORMAT_4_7) += gcc_4_7.o -obj-$(CONFIG_GCOV_FORMAT_AUTODETECT) += $(call cc-ifversion, -lt, 0407, \ - gcc_3_4.o, gcc_4_7.o) -- 2.7.4
[PATCH 04/30] kconfig: reference environment variables directly and remove 'option env='
To get access to environment variables, Kconfig needs to define a symbol using "option env=" syntax. It is tedious to add a symbol entry for each environment variable given that we need to define much more such as 'CC', 'AS', 'srctree' etc. to evaluate the compiler capability in Kconfig. Adding '$' for symbol references is grammatically weird. Looking at the code, the symbols prefixed with 'S' are expanded by: - conf_expand_value() This is used to expand 'arch/$ARCH/defconfig' and 'defconfig_list' - sym_expand_string_value() This is used to expand strings in 'source' and 'mainmenu' All of them are fixed values independent of user configuration. So, they can be changed into the direct expansion instead of symbols. This change makes the code much cleaner. The bounce symbols 'SRCARCH', 'ARCH', 'SUBARCH', 'KERNELVERSION' are gone. sym_init() hard-coding 'UNAME_RELEASE' is also gone. 'UNAME_RELEASE' should be replaced with an environment variable. ARCH_DEFCONFIG is a normal symbol, so it should be simply referenced without '$' prefix. The new syntax is addicted by Make. The variable reference needs parentheses, like $(FOO), but you can omit them for single-letter variables, like $F. Yet, in Makefiles, people tend to use the parenthetical form for consistency / clarification. At this moment, only the environment variable is supported, but I will extend the concept of 'variable' later on. The variables are expanded in the lexer so we can simplify the token handling on the parser side. For example, the following code works. [Example code] config MY_TOOLCHAIN_LIST string default "My tools: CC=$(CC), AS=$(AS), CPP=$(CPP)" [Result] $ make -s alldefconfig && tail -n 1 .config CONFIG_MY_TOOLCHAIN_LIST="My tools: CC=gcc, AS=as, CPP=gcc -E" Signed-off-by: Masahiro Yamada Reviewed-by: Kees Cook --- Changes in v3: - Reimplement - Variable reference need parentheses except single-letter variable Changes in v2: - Move the string expansion to the lexer phase. - Split environment helpers to env.c Documentation/kbuild/kconfig-language.txt | 8 - Kconfig | 8 +- Makefile | 3 +- arch/sh/Kconfig | 4 +- arch/sparc/Kconfig| 4 +- arch/um/Kconfig.common| 4 - arch/x86/Kconfig | 4 +- arch/x86/um/Kconfig | 6 +- init/Kconfig | 16 +- scripts/kconfig/confdata.c| 31 +--- scripts/kconfig/kconf_id.c| 1 - scripts/kconfig/lkc.h | 4 - scripts/kconfig/lkc_proto.h | 6 + scripts/kconfig/menu.c| 3 - scripts/kconfig/preprocess.c | 261 ++ scripts/kconfig/symbol.c | 56 --- scripts/kconfig/util.c| 18 +-- scripts/kconfig/zconf.l | 67 +++- scripts/kconfig/zconf.y | 2 +- 19 files changed, 353 insertions(+), 153 deletions(-) create mode 100644 scripts/kconfig/preprocess.c diff --git a/Documentation/kbuild/kconfig-language.txt b/Documentation/kbuild/kconfig-language.txt index f5b9493..0e966e8 100644 --- a/Documentation/kbuild/kconfig-language.txt +++ b/Documentation/kbuild/kconfig-language.txt @@ -198,14 +198,6 @@ applicable everywhere (see syntax). enables the third modular state for all config symbols. At most one symbol may have the "modules" option set. - - "env"= -This imports the environment variable into Kconfig. It behaves like -a default, except that the value comes from the environment, this -also means that the behaviour when mixing it with normal defaults is -undefined at this point. The symbol is currently not exported back -to the build environment (if this is desired, it can be done via -another symbol). - - "allnoconfig_y" This declares the symbol as one that should have the value y when using "allnoconfig". Used for symbols that hide other symbols. diff --git a/Kconfig b/Kconfig index 8c4c1cb..4af1b42 100644 --- a/Kconfig +++ b/Kconfig @@ -3,10 +3,6 @@ # For a description of the syntax of this configuration file, # see Documentation/kbuild/kconfig-language.txt. # -mainmenu "Linux/$ARCH $KERNELVERSION Kernel Configuration" +mainmenu "Linux/$(ARCH) $(KERNELVERSION) Kernel Configuration" -config SRCARCH - string - option env="SRCARCH" - -source "arch/$SRCARCH/Kconfig" +source "arch/$(SRCARCH)/Kconfig" diff --git a/Makefile b/Makefile index ca3e3e8..5298ad7 100644 --- a/Makefile +++ b/Makefile @@ -284,7 +284,8 @@ include scripts/Kbuild.include # Read KERNELRELEASE from include/config/kernel.release (if it exists) KERNELRELEASE = $(shell cat include/config/kernel.release 2> /dev/null) KERNELVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if
[PATCH 29/30] arm64: move GCC version check for ARCH_SUPPORTS_INT128 to Kconfig
This becomes much neater in Kconfig. Signed-off-by: Masahiro Yamada Acked-by: Will Deacon Reviewed-by: Kees Cook --- Changes in v3: None Changes in v2: None arch/arm64/Kconfig | 1 + arch/arm64/Makefile | 2 -- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index eb2cf49..09d1aee 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -43,6 +43,7 @@ config ARM64 select ARCH_USE_QUEUED_RWLOCKS select ARCH_SUPPORTS_MEMORY_FAILURE select ARCH_SUPPORTS_ATOMIC_RMW + select ARCH_SUPPORTS_INT128 if GCC_VERSION >= 5 select ARCH_SUPPORTS_NUMA_BALANCING select ARCH_WANT_COMPAT_IPC_PARSE_VERSION select ARCH_WANT_FRAME_POINTERS diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile index 1540286..cefd1e9 100644 --- a/arch/arm64/Makefile +++ b/arch/arm64/Makefile @@ -56,8 +56,6 @@ KBUILD_AFLAGS += $(lseinstr) $(brokengasinst) KBUILD_CFLAGS += $(call cc-option,-mabi=lp64) KBUILD_AFLAGS += $(call cc-option,-mabi=lp64) -KBUILD_CFLAGS += $(call cc-ifversion, -ge, 0500, -DCONFIG_ARCH_SUPPORTS_INT128) - ifeq ($(CONFIG_CPU_BIG_ENDIAN), y) KBUILD_CPPFLAGS+= -mbig-endian CHECKFLAGS += -D__AARCH64EB__ -- 2.7.4
[PATCH 11/30] kconfig: begin PARAM state only when seeing a command keyword
Currently, any statement line starts with a keyword with TF_COMMAND
flag. So, the following three lines are dead code.
alloc_string(yytext, yyleng);
zconflval.string = text;
return T_WORD;
If a T_WORD token is returned in this context, it will cause syntax
error in the parser anyway.
The next commit will support the assignment statement where a line
starts with an arbitrary identifier. So, I want the lexer to switch
to the PARAM state only when it sees a command keyword.
Signed-off-by: Masahiro Yamada
---
Changes in v3: None
Changes in v2: None
scripts/kconfig/zconf.l | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/kconfig/zconf.l b/scripts/kconfig/zconf.l
index 9dc5fe3..5e53348 100644
--- a/scripts/kconfig/zconf.l
+++ b/scripts/kconfig/zconf.l
@@ -102,10 +102,10 @@ n [A-Za-z0-9_-]
{
{n}+{
const struct kconf_id *id = kconf_id_lookup(yytext, yyleng);
- BEGIN(PARAM);
current_pos.file = current_file;
current_pos.lineno = yylineno;
if (id && id->flags & TF_COMMAND) {
+ BEGIN(PARAM);
yylval.id = id;
return id->token;
}
--
2.7.4
[PATCH 15/30] kconfig: expand lefthand side of assignment statement
Make allows variable references in the lefthand side of assignment.
X = A
Y = B
$(X)$(Y) = 1
This does 'AB = 1' Do likewise in Kconfig as well.
Signed-off-by: Masahiro Yamada
---
Changes in v3: None
Changes in v2: None
scripts/kconfig/zconf.l | 7 +++
1 file changed, 7 insertions(+)
diff --git a/scripts/kconfig/zconf.l b/scripts/kconfig/zconf.l
index c68ca56b..ae33e9b 100644
--- a/scripts/kconfig/zconf.l
+++ b/scripts/kconfig/zconf.l
@@ -114,6 +114,13 @@ n [A-Za-z0-9_-]
yylval.string = text;
return T_VARIABLE;
}
+ ({n}|$)+{
+ /* this token includes at least one '$' */
+ yylval.string = expand_token(yytext, yyleng);
+ if (strlen(yylval.string))
+ return T_VARIABLE;
+ free(yylval.string);
+ }
"=" { BEGIN(ASSIGN_VAL); yylval.flavor = VAR_RECURSIVE; return
T_ASSIGN; }
":="{ BEGIN(ASSIGN_VAL); yylval.flavor = VAR_SIMPLE; return
T_ASSIGN; }
"+="{ BEGIN(ASSIGN_VAL); yylval.flavor = VAR_APPEND; return
T_ASSIGN; }
--
2.7.4
[PATCH 10/30] kconfig: replace $(UNAME_RELEASE) with function call
Now that 'shell' function is supported, this can be self-contained in Kconfig. Signed-off-by: Masahiro Yamada Reviewed-by: Kees Cook Reviewed-by: Ulf Magnusson --- Changes in v3: None Changes in v2: None Makefile | 3 +-- init/Kconfig | 4 ++-- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/Makefile b/Makefile index 5298ad7..ca3e3e8 100644 --- a/Makefile +++ b/Makefile @@ -284,8 +284,7 @@ include scripts/Kbuild.include # Read KERNELRELEASE from include/config/kernel.release (if it exists) KERNELRELEASE = $(shell cat include/config/kernel.release 2> /dev/null) KERNELVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if $(SUBLEVEL),.$(SUBLEVEL)))$(EXTRAVERSION) -UNAME_RELEASE := $(shell uname --release) -export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION UNAME_RELEASE +export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION # SUBARCH tells the usermode build what the underlying arch is. That is set # first, and if a usermode build is happening, the "ARCH=um" on the command diff --git a/init/Kconfig b/init/Kconfig index e6dafed5..4b0b636 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -2,9 +2,9 @@ config DEFCONFIG_LIST string depends on !UML option defconfig_list - default "/lib/modules/$(UNAME_RELEASE)/.config" + default "/lib/modules/$(shell uname --release)/.config" default "/etc/kernel-config" - default "/boot/config-$(UNAME_RELEASE)" + default "/boot/config-$(shell uname --release)" default ARCH_DEFCONFIG default "arch/$(ARCH)/defconfig" -- 2.7.4
Re: [PATCH v5 05/14] PCI: Add pcie_print_link_status() to log link speed and whether it's limited
On Fri, 30 Mar 2018 16:05:18 -0500, Bjorn Helgaas wrote: > + if (bw_avail >= bw_cap) > + pci_info(dev, "%d Mb/s available bandwidth (%s x%d link)\n", > + bw_cap, PCIE_SPEED2STR(speed_cap), width_cap); > + else > + pci_info(dev, "%d Mb/s available bandwidth, limited by %s x%d > link at %s (capable of %d Mb/s with %s x%d link)\n", > + bw_avail, PCIE_SPEED2STR(speed), width, > + limiting_dev ? pci_name(limiting_dev) : "", > + bw_cap, PCIE_SPEED2STR(speed_cap), width_cap); I was just looking at using this new function to print PCIe BW for a NIC, but I'm slightly worried that there is nothing in the message that says PCIe... For a NIC some people may interpret the bandwidth as NIC bandwidth: [ 39.839989] nfp :04:00.0: Netronome Flow Processor NFP4000/NFP6000 PCIe Card Probe [ 39.848943] nfp :04:00.0: 63.008 Gb/s available bandwidth (8 GT/s x8 link) [ 39.857146] nfp :04:00.0: RESERVED BARs: 0.0: General/MSI-X SRAM, 0.1: PCIe XPB/MSI-X PBA, 0.4: Explicit0, 0.5: Explicit1, fre4 It's not a 63Gbps NIC... I'm sorry if this was discussed before and I didn't find it. Would it make sense to add the "PCIe: " prefix to the message like bnx2x used to do? Like: nfp :04:00.0: PCIe: 63.008 Gb/s available bandwidth (8 GT/s x8 link) Sorry for a very late comment.
Re: [RFC v2] virtio: support packed ring
On 2018年04月01日 22:12, Tiwei Bie wrote:
Hello everyone,
This RFC implements packed ring support for virtio driver.
The code was tested with DPDK vhost (testpmd/vhost-PMD) implemented
by Jens at http://dpdk.org/ml/archives/dev/2018-January/089417.html
Minor changes are needed for the vhost code, e.g. to kick the guest.
TODO:
- Refinements and bug fixes;
- Split into small patches;
- Test indirect descriptor support;
- Test/fix event suppression support;
- Test devices other than net;
RFC v1 -> RFC v2:
- Add indirect descriptor support - compile test only;
- Add event suppression supprt - compile test only;
- Move vring_packed_init() out of uapi (Jason, MST);
- Merge two loops into one in virtqueue_add_packed() (Jason);
- Split vring_unmap_one() for packed ring and split ring (Jason);
- Avoid using '%' operator (Jason);
- Rename free_head -> next_avail_idx (Jason);
- Add comments for virtio_wmb() in virtqueue_add_packed() (Jason);
- Some other refinements and bug fixes;
Thanks!
Signed-off-by: Tiwei Bie
---
drivers/virtio/virtio_ring.c | 1094 +---
include/linux/virtio_ring.h|8 +-
include/uapi/linux/virtio_config.h | 12 +-
include/uapi/linux/virtio_ring.h | 61 ++
4 files changed, 980 insertions(+), 195 deletions(-)
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 71458f493cf8..0515dca34d77 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -58,14 +58,15 @@
struct vring_desc_state {
void *data; /* Data for callback. */
- struct vring_desc *indir_desc; /* Indirect descriptor, if any. */
+ void *indir_desc; /* Indirect descriptor, if any. */
+ int num;/* Descriptor list length. */
};
struct vring_virtqueue {
struct virtqueue vq;
- /* Actual memory layout for this queue */
- struct vring vring;
+ /* Is this a packed ring? */
+ bool packed;
/* Can we use weak barriers? */
bool weak_barriers;
@@ -79,19 +80,45 @@ struct vring_virtqueue {
/* Host publishes avail event idx */
bool event;
- /* Head of free buffer list. */
- unsigned int free_head;
/* Number we've added since last sync. */
unsigned int num_added;
/* Last used index we've seen. */
u16 last_used_idx;
- /* Last written value to avail->flags */
- u16 avail_flags_shadow;
+ union {
+ /* Available for split ring */
+ struct {
+ /* Actual memory layout for this queue. */
+ struct vring vring;
- /* Last written value to avail->idx in guest byte order */
- u16 avail_idx_shadow;
+ /* Head of free buffer list. */
+ unsigned int free_head;
+
+ /* Last written value to avail->flags */
+ u16 avail_flags_shadow;
+
+ /* Last written value to avail->idx in
+* guest byte order. */
+ u16 avail_idx_shadow;
+ };
+
+ /* Available for packed ring */
+ struct {
+ /* Actual memory layout for this queue. */
+ struct vring_packed vring_packed;
+
+ /* Driver ring wrap counter. */
+ u8 wrap_counter;
+
+ /* Index of the next avail descriptor. */
+ unsigned int next_avail_idx;
+
+ /* Last written value to driver->flags in
+* guest byte order. */
+ u16 event_flags_shadow;
+ };
+ };
/* How to notify other side. FIXME: commonalize hcalls! */
bool (*notify)(struct virtqueue *vq);
@@ -201,8 +228,33 @@ static dma_addr_t vring_map_single(const struct
vring_virtqueue *vq,
cpu_addr, size, direction);
}
-static void vring_unmap_one(const struct vring_virtqueue *vq,
- struct vring_desc *desc)
+static void vring_unmap_one_split(const struct vring_virtqueue *vq,
+ struct vring_desc *desc)
+{
+ u16 flags;
+
+ if (!vring_use_dma_api(vq->vq.vdev))
+ return;
+
+ flags = virtio16_to_cpu(vq->vq.vdev, desc->flags);
+
+ if (flags & VRING_DESC_F_INDIRECT) {
+ dma_unmap_single(vring_dma_dev(vq),
+virtio64_to_cpu(vq->vq.vdev, desc->addr),
+virtio32_to_cpu(vq->vq.vdev, desc->len),
+(flags & VRING_DESC_F_WRITE) ?
+DMA_FROM_DEVICE : DMA_TO_DEVICE);
+ } else {
+ dma_unmap_page(vring_dma_dev(vq),
+ virtio64_to_cpu(vq->vq.vdev, desc->addr),
+
RE: [RFC v3 0/2] WhiteEgret LSM module
> Do you have a target date for posting that? Yes, we have the target date. We will submit WhiteEgret v4 by September. > So you have a design for being able to differentiate the interpreters > reading versus reading with the intent to execute? > With or without their help? We will provide WEUA sample to be able to control a script program with WhiteEgret v4. Our WEUA sample does not identify whether to read or to read with the intent to execute. The sample has some restrictions. We consider that the restrictions can be resolved by implementing additional functions for WEUA. It is an implementation-dependent matter. Howerver, we are sure that the restrictions are acceptable for many applications. We would like to discuss about them with WhiteEgret v4 patch! -Original Message- > I am one of developers of WhiteEgret. > > > regardling the last one, do you have a plan for handling it? > Yes, we have a plan to release WhiteEgret v4 patch with a WEUA sample of > access control for script programs. Do you have a target date for posting that? > The latest WhiteEgret cannot control script programs since script files read > by an interpreter are not hooked by the execve system call. > We consider that script programs can be controlled by controlling the files > inputted by interpreters, accordingly. > We consider that the control can be realized using the read system call > hooking. So you have a design for being able to differentiate the interpreters reading versus reading with the intent to execute? With or without their help? > Now, we are developing WhiteEgret with the read system call hooking and WEUA > which controls the script files to be read to interpreters using information > from the read system call hooking and white list. -serge
Re: [GIT PULL] Thermal management updates for v4.17-rc1
Hello,
On Thu, Apr 12, 2018 at 09:55:19AM -0700, Linus Torvalds wrote:
> On Wed, Apr 11, 2018 at 10:08 PM, Zhang Rui wrote:
> >
> > could you please illustrate me what the kconfig & warning is?
>
> Just "make allmodconfig" and the warning is about a uninitialized variable.
>
> Line 304 in drivers/thermal/samsung/exynos_tmu.c if my shell history
> is to be believed.
>
> Linus
Yeah, this has also passed my local compilation error. Somehow my gcc4.9
is not catching it. Using an older gcc (gcc4.6) does catch it.
Anyways, given that the conversion functions are written to cover
for unexpected cal_type, the right way of fixing this is to rewrite
the conversion functions to allow for returning error codes and
adjusting the callers as expected.
Rui, bzolnier, please consider the following fix:
>From 2aaf94f80c0021a21b4122c9f4197acff08ea398 Mon Sep 17 00:00:00 2001
From: Eduardo Valentin
Date: Thu, 12 Apr 2018 21:00:48 -0700
Subject: [PATCH 1/1] thermal: exynos: fix compilation warning around
conversion functions
In order to fix the warns:
drivers/thermal/samsung/exynos_tmu.c:931:37: warning: 'temp' may be used
uninitialized in this function [-Wmaybe-uninitialized]
drivers/thermal/samsung/exynos_tmu.c:304:9: warning: 'temp_code' may be used
uninitialized in this function [-Wmaybe-uninitialized]
the conversion functions should allow return error codes
and the not mix the converted value with error code.
This patch change the conversion functions to return
error code or success and adjusts the callers accordingly.
Signed-off-by: Eduardo Valentin
---
drivers/thermal/samsung/exynos_tmu.c | 120 ---
1 file changed, 84 insertions(+), 36 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index 2ec8548..b3f0704 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -282,52 +282,54 @@ static void exynos_report_trigger(struct exynos_tmu_data
*p)
* TMU treats temperature as a mapped temperature code.
* The temperature is converted differently depending on the calibration type.
*/
-static int temp_to_code(struct exynos_tmu_data *data, u8 temp)
+static int temp_to_code(struct exynos_tmu_data *data, u8 temp, int *temp_code)
{
- int temp_code;
+ int ret = 0;
switch (data->cal_type) {
case TYPE_TWO_POINT_TRIMMING:
- temp_code = (temp - EXYNOS_FIRST_POINT_TRIM) *
+ *temp_code = (temp - EXYNOS_FIRST_POINT_TRIM) *
(data->temp_error2 - data->temp_error1) /
(EXYNOS_SECOND_POINT_TRIM - EXYNOS_FIRST_POINT_TRIM) +
data->temp_error1;
break;
case TYPE_ONE_POINT_TRIMMING:
- temp_code = temp + data->temp_error1 - EXYNOS_FIRST_POINT_TRIM;
+ *temp_code = temp + data->temp_error1 - EXYNOS_FIRST_POINT_TRIM;
break;
default:
WARN_ON(1);
+ ret = -EINVAL;
break;
}
- return temp_code;
+ return ret;
}
/*
* Calculate a temperature value from a temperature code.
* The unit of the temperature is degree Celsius.
*/
-static int code_to_temp(struct exynos_tmu_data *data, u16 temp_code)
+static int code_to_temp(struct exynos_tmu_data *data, u16 temp_code, int *temp)
{
- int temp;
+ int ret = 0;
switch (data->cal_type) {
case TYPE_TWO_POINT_TRIMMING:
- temp = (temp_code - data->temp_error1) *
+ *temp = (temp_code - data->temp_error1) *
(EXYNOS_SECOND_POINT_TRIM - EXYNOS_FIRST_POINT_TRIM) /
(data->temp_error2 - data->temp_error1) +
EXYNOS_FIRST_POINT_TRIM;
break;
case TYPE_ONE_POINT_TRIMMING:
- temp = temp_code - data->temp_error1 + EXYNOS_FIRST_POINT_TRIM;
+ *temp = temp_code - data->temp_error1 + EXYNOS_FIRST_POINT_TRIM;
break;
default:
WARN_ON(1);
+ ret = -EINVAL;
break;
}
- return temp;
+ return ret;
}
static void sanitize_temp_error(struct exynos_tmu_data *data, u32 trim_info)
@@ -352,7 +354,7 @@ static u32 get_th_reg(struct exynos_tmu_data *data, u32
threshold, bool falling)
struct thermal_zone_device *tz = data->tzd;
const struct thermal_trip * const trips =
of_thermal_get_trip_points(tz);
- unsigned long temp;
+ int temp;
int i;
if (!trips) {
@@ -362,6 +364,8 @@ static u32 get_th_reg(struct exynos_tmu_data *data, u32
threshold, bool falling)
}
for (i = 0; i < of_thermal_get_ntrips(tz); i++) {
+ int val, ret;
+
if (trips[i].type == THERMAL_TRIP_CRITICAL)
continue;
@@ -371,7 +375,14 @@ static u32 get_t
Re: [PATCH] f2fs: enlarge block plug coverage
On 04/13, Chao Yu wrote:
> On 2018/4/13 9:06, Jaegeuk Kim wrote:
> > On 04/10, Chao Yu wrote:
> >> On 2018/4/10 12:10, Jaegeuk Kim wrote:
> >>> On 04/10, Chao Yu wrote:
> On 2018/4/10 2:02, Jaegeuk Kim wrote:
> > On 04/08, Chao Yu wrote:
> >> On 2018/4/5 11:51, Jaegeuk Kim wrote:
> >>> On 04/04, Chao Yu wrote:
> This patch enlarges block plug coverage in __issue_discard_cmd, in
> order to collect more pending bios before issuing them, to avoid
> being disturbed by previous discard I/O in IO aware discard mode.
> >>>
> >>> Hmm, then we need to wait for huge discard IO for over 10 secs, which
> >>
> >> We found that total discard latency is rely on total discard number we
> >> issued
> >> last time instead of range or length discard covered. IMO, if we don't
> >> change
> >> .max_requests value, we will not suffer longer latency.
> >>
> >>> will affect following read/write IOs accordingly. In order to avoid
> >>> that,
> >>> we actually need to limit the discard size.
>
> Do you mean limit discard count or discard length?
> >>>
> >>> Both of them.
> >>>
>
> >>
> >> If you are worry about I/O interference in between discard and rw, I
> >> suggest to
> >> decrease .max_requests value.
> >
> > What do you mean? This will produce more pending requests in the queue?
>
> I mean after applying this patch, we can queue more discard IOs in plug
> inside
> task, otherwise, previous issued discard in block layer can make
> is_idle() be false,
> then it can stop IO awared user to issue pending discard command.
> >>>
> >>> Then, unplug will issue lots of discard commands, which affects the
> >>> following rw
> >>> latencies. My preference would be issuing discard commands one by one as
> >>> much as
> >>> possible.
> >>
> >> Hmm.. for you concern, we can turn down IO priority of discard from
> >> background?
> >
> > That makes much more sense to me. :P
>
> Then, this patch which enlarge plug coverage will not still a problem, right?
> ;)
This is different one.
>
> Thanks,
>
> >
> >>
> >> Thanks,
> >>
> >>>
>
> Thanks,
>
> >
> >>
> >> Thanks,
> >>
> >>>
> >>> Thanks,
> >>>
>
> Signed-off-by: Chao Yu
> ---
> fs/f2fs/segment.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> index 8f0b5ba46315..4287e208c040 100644
> --- a/fs/f2fs/segment.c
> +++ b/fs/f2fs/segment.c
> @@ -1208,10 +1208,12 @@ static int __issue_discard_cmd(struct
> f2fs_sb_info *sbi,
> pend_list = &dcc->pend_list[i];
>
> mutex_lock(&dcc->cmd_lock);
> +
> +blk_start_plug(&plug);
> +
> if (list_empty(pend_list))
> goto next;
> f2fs_bug_on(sbi, !__check_rb_tree_consistence(sbi,
> &dcc->root));
> -blk_start_plug(&plug);
> list_for_each_entry_safe(dc, tmp, pend_list, list) {
> f2fs_bug_on(sbi, dc->state != D_PREP);
>
> @@ -1227,8 +1229,9 @@ static int __issue_discard_cmd(struct
> f2fs_sb_info *sbi,
> if (++iter >= dpolicy->max_requests)
> break;
> }
> -blk_finish_plug(&plug);
> next:
> +blk_finish_plug(&plug);
> +
> mutex_unlock(&dcc->cmd_lock);
>
> if (iter >= dpolicy->max_requests)
> --
> 2.15.0.55.gc2ece9dc4de6
> >>>
> >>> .
> >>>
> >
> > .
> >
> >>>
> >>> .
> >>>
> >
> > .
> >
Re: [PATCH] f2fs: set deadline to drop expired inmem pages
On 04/13, Chao Yu wrote: > On 2018/4/13 9:04, Jaegeuk Kim wrote: > > On 04/10, Chao Yu wrote: > >> Hi Jaegeuk, > >> > >> On 2018/4/8 16:13, Chao Yu wrote: > >>> f2fs doesn't allow abuse on atomic write class interface, so except > >>> limiting in-mem pages' total memory usage capacity, we need to limit > >>> start-commit time as well, otherwise we may run into infinite loop > >>> during foreground GC because target blocks in victim segment are > >>> belong to atomic opened file for long time. > >>> > >>> Now, we will check the condition with f2fs_balance_fs_bg in > >>> background threads, once if user doesn't commit data exceeding 30 > >>> seconds, we will drop all cached data, so I expect it can keep our > >>> system running safely to prevent Dos attack. > >> > >> Is it worth to add this patch to avoid abuse on atomic write interface by > >> user? > > > > Hmm, hope to see a real problem first in this case. > > I think this can be a more critical security leak instead of a potential issue > which we can wait for someone reporting that can be too late. > > For example, user can simply write a huge file whose data spread in all f2fs > segments, once user open that file as atomic, foreground GC will suffer > deadloop, causing denying any further service of f2fs. How can you guarantee it won't happen within 30sec? If you want to avoid that, you have to take a look at foreground gc. > > Thanks, > > > > >> Thanks, > > > > . > >
Re: [RFC PATCH v2 2/6] sched: Introduce energy models of CPUs
On 06-04-18, 16:36, Dietmar Eggemann wrote:
> diff --git a/include/linux/sched/energy.h b/include/linux/sched/energy.h
> +#if defined(CONFIG_SMP) && defined(CONFIG_PM_OPP)
> +extern struct sched_energy_model ** __percpu energy_model;
> +extern struct static_key_false sched_energy_present;
> +extern struct list_head sched_freq_domains;
> +
> +static inline bool sched_energy_enabled(void)
> +{
> + return static_branch_unlikely(&sched_energy_present);
> +}
> +
> +static inline struct cpumask *freq_domain_span(struct freq_domain *fd)
> +{
> + return &fd->span;
> +}
> +
> +extern void init_sched_energy(void);
> +
> +#define for_each_freq_domain(fdom) \
> + list_for_each_entry(fdom, &sched_freq_domains, next)
> +
> +#else
> +struct freq_domain;
> +static inline bool sched_energy_enabled(void) { return false; }
> +static inline struct cpumask
> +*freq_domain_span(struct freq_domain *fd) { return NULL; }
> +static inline void init_sched_energy(void) { }
> +#define for_each_freq_domain(fdom) for (; fdom; fdom = NULL)
I am not sure if this is correct. fdom would normally be a local
uninitialized variable and with above we may end up running the loop
once with an invalid pointer. Maybe rewrite it as:
for (fdom = NULL; fdom; )
And for the whole OPP discussion, perhaps we should have another
architecture specific callback which the scheduler can call to get a
ready-made energy model with all the structures filled in. That way
the OPP specific stuff will move to the architecture specific
callback.
--
viresh
Re: [PATCH v2 2/2] dmaengine: stm32-mdma: Fix incomplete Hw descriptors allocator
On Wed, Apr 11, 2018 at 04:44:39PM +0200, Pierre-Yves MORDRET wrote:
> struct stm32_mdma_desc {
> struct virt_dma_desc vdesc;
> u32 ccr;
> - struct stm32_mdma_hwdesc *hwdesc;
> - dma_addr_t hwdesc_phys;
> bool cyclic;
> u32 count;
> + struct stm32_mdma_desc_node node[];
some ppl use node[0] for this but i think either is fine..
> static void stm32_mdma_dump_hwdesc(struct stm32_mdma_chan *chan,
> -struct stm32_mdma_hwdesc *hwdesc)
> +struct stm32_mdma_desc_node *node)
> {
> - dev_dbg(chan2dev(chan), "CTCR:0x%08x\n", hwdesc->ctcr);
> + dev_dbg(chan2dev(chan), "CTCR:0x%08x\n", node->hwdesc->ctcr);
this is noise for this patch and IIUC you should be able to pass
node->hwdesc and keep fn same?
--
~Vinod
Re: [PATCH 4/5] dmaengine: sprd: Add Spreadtrum DMA configuration
On Thu, Apr 12, 2018 at 07:36:34PM +0800, Baolin Wang wrote:
> >>> >> +/*
> >>> >> + * struct sprd_dma_config - DMA configuration structure
> >>> >> + * @config: dma slave channel config
> >>> >> + * @fragment_len: specify one fragment transfer length
> >>> >> + * @block_len: specify one block transfer length
> >>> >> + * @transcation_len: specify one transcation transfer length
> >>> >> + * @wrap_ptr: wrap pointer address, once the transfer address reaches
> >>> >> the
> >>> >> + * 'wrap_ptr', the next transfer address will jump to the 'wrap_to'
> >>> >> address.
> >>> >> + * @wrap_to: wrap jump to address
> >>> >> + * @req_mode: specify the DMA request mode
> >>> >> + * @int_mode: specify the DMA interrupt type
> >>> >> + */
> >>> >> +struct sprd_dma_config {
> >>> >> + struct dma_slave_config config;
> >>> >> + u32 fragment_len;
> >>> >
> >>> > why not use _maxburst?
> >>>
> >>> Yes, I can use maxburst.
> >>>
> >>> >
> >>> >> + u32 block_len;
> >>> >> + u32 transcation_len;
> >>> >
> >>> > what does block and transaction len refer to here
> >>>
> >>> Our DMA has 3 transfer mode: transaction transfer, block transfer and
> >>> fragment transfer. One transaction transfer can contain several blocks
> >>> transfer, and each block can be set proper block step. One block can
> >>> contain several fragments transfer with proper fragment step. It can
> >>> generate interrupts when one transaction transfer or block transfer or
> >>> fragment transfer is completed if user set the interrupt type. So here
> >>> we should set the length for transaction transfer, block transfer and
> >>> fragment transfer.
> >>
> >> what are the max size these types support?
> >
> > These types max size definition:
> >
> > #define SPRD_DMA_FRG_LEN_MASK GENMASK(16, 0)
> >
> > #define SPRD_DMA_BLK_LEN_MASK GENMASK(16, 0)
> >
> > #define SPRD_DMA_TRSC_LEN_MASK GENMASK(27, 0)
> >
> >>>
> >>> >
> >>> >> + phys_addr_t wrap_ptr;
> >>> >> + phys_addr_t wrap_to;
> >>> >
> >>> > this sound sg_list to me, why are we not using that here
> >>>
> >>> It is similar to sg list, but it is not one software action, we have
> >>> hardware registers to help to jump one specified address.
> >>>
> >>> >
> >>> >> + enum sprd_dma_req_mode req_mode;
> >>> >
> >>> > Looking at definition of request mode we have frag, block, transaction
> >>> > list
> >>> > etc.. That should depend upon dma request. If you have been asked to
> >>> > transfer a list, you shall configure list mode. if it is a single
> >>> > transaction then it should be transaction mode!
> >>>
> >>> If I understand your points correctly, you mean we can specify the
> >>> request mode when requesting one slave channel by
> >>> 'dma_request_slave_channel()'. But we need change the request mode
> >>> dynamically following different transfer task for this channel, so I
> >>> am afraid we can not specify the request mode of this channel at
> >>> requesting time.
> >>
> >> Nope a channel has nothing to do with request type. You request and grab a
> >> channel. Then you prepare a descriptor for a dma transaction. Based on
> >> transaction requested you should intelligently break it down and create a
> >> descriptor which uses transaction/block/fragment so that DMA throughput is
> >> efficient. If prepare has sg list then you should use link list mode.
> >> Further if you support max length, say 16KB and request is for 20KB you may
> >> break it down for link list with two segments.
> >
> > OK. So I can add one more cell to specify the request mode for this channel.
> >
> > dmas = <&apdma 11 SPRD_DMA_BLK_REQ>
> >
> >>
> >> Each prep call has flags associated, that can help you configure interrupt
> >> behaviour.
>
> After more thinking, I think this will be not useful for users, since
> users need configure one DMA channel through different 3 places,
> specify the request mode in dts, specify the interrupt type through
> prep call flags, and other configuration need to be configured through
> 'struct sprd_dma_config'. That is not one good design for users. What
> do you think? Thanks.
Agreed, users only care about grabbing a channel, setting a descriptor and
submitting that.
I think you need to go back and think about this a bit, please do go thru
dmaengine documentation and see other driver examples.
We don't typically expose these to users, they give us a transfer and we set
that up in hardware for efficient. Its DMA so people expect us to use fastest
mechanism available.
I would say setup as Link list for sg transfers and use one of them modes
(again think efficiency) for single transfers.
Also use all the parameters in dma_slave_config and also setup capabilities if
not done.
--
~Vinod
[PATCH][v4] tools/power turbostat: if --iterations, print for specific time of iterations
From: Chen Yu
There's a use case during test to only print specific round of iterations
if --iterations is specified, for example, with this patch applied:
turbostat -i 5 -I 4
will capture 4 samples with 5 seconds interval.
Cc: Len Brown
Cc: Rafael J Wysocki
Cc: Artem Bityutskiy
Cc: Doug Smythies
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Chen Yu
---
tools/power/x86/turbostat/turbostat.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/tools/power/x86/turbostat/turbostat.c
b/tools/power/x86/turbostat/turbostat.c
index bd9c6b31a504..a2fe96f038f0 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -48,6 +48,7 @@ char *proc_stat = "/proc/stat";
FILE *outf;
int *fd_percpu;
struct timespec interval_ts = {5, 0};
+int iterations;
unsigned int debug;
unsigned int quiet;
unsigned int sums_need_wide_columns;
@@ -470,6 +471,7 @@ void help(void)
" {core | package | j,k,l..m,n-p }\n"
"--quietskip decoding system configuration header\n"
"--interval sec Override default 5-second measurement interval\n"
+ "--iterations count Number of measurement iterations(requires
'--interval'\n"
"--help print this help message\n"
"--list list column headers only\n"
"--out file create or truncate \"file\" for all output\n"
@@ -2565,6 +2567,7 @@ void turbostat_loop()
{
int retval;
int restarted = 0;
+ int done_iters = 0;
restart:
restarted++;
@@ -2581,6 +2584,7 @@ void turbostat_loop()
goto restart;
}
restarted = 0;
+ done_iters = 0;
gettimeofday(&tv_even, (struct timezone *)NULL);
while (1) {
@@ -2607,6 +2611,10 @@ void turbostat_loop()
compute_average(EVEN_COUNTERS);
format_all_counters(EVEN_COUNTERS);
flush_output_stdout();
+
+ if (iterations && (++done_iters >= iterations))
+ break;
+
nanosleep(&interval_ts, NULL);
if (snapshot_proc_sysfs_files())
goto restart;
@@ -2626,6 +2634,9 @@ void turbostat_loop()
compute_average(ODD_COUNTERS);
format_all_counters(ODD_COUNTERS);
flush_output_stdout();
+
+ if (iterations && (++done_iters >= iterations))
+ break;
}
}
@@ -4999,6 +5010,7 @@ void cmdline(int argc, char **argv)
{"Dump",no_argument,0, 'D'},
{"debug", no_argument,0, 'd'},/*
internal, not documented */
{"interval",required_argument, 0, 'i'},
+ {"iterations", required_argument, 0, 'I'},
{"help",no_argument,0, 'h'},
{"hide",required_argument, 0, 'H'},// meh,
-h taken by --help
{"Joules", no_argument,0, 'J'},
@@ -5014,7 +5026,7 @@ void cmdline(int argc, char **argv)
progname = argv[0];
- while ((opt = getopt_long_only(argc, argv, "+C:c:Ddhi:JM:m:o:qST:v",
+ while ((opt = getopt_long_only(argc, argv, "+C:c:DdhI:i:JM:m:o:qST:v",
long_options, &option_index)) != -1) {
switch (opt) {
case 'a':
@@ -5036,6 +5048,15 @@ void cmdline(int argc, char **argv)
default:
help();
exit(1);
+ case 'I':
+ iterations = strtod(optarg, NULL);
+
+ if (iterations <= 0) {
+ fprintf(outf, "iterations %d should be positive
number\n",
+ iterations);
+ exit(2);
+ }
+ break;
case 'i':
{
double interval = strtod(optarg, NULL);
--
2.13.6
Re: [PATCH 4/5] dmaengine: sprd: Add Spreadtrum DMA configuration
On Thu, Apr 12, 2018 at 07:30:01PM +0800, Baolin Wang wrote: > >> > what does block and transaction len refer to here > >> > >> Our DMA has 3 transfer mode: transaction transfer, block transfer and > >> fragment transfer. One transaction transfer can contain several blocks > >> transfer, and each block can be set proper block step. One block can > >> contain several fragments transfer with proper fragment step. It can > >> generate interrupts when one transaction transfer or block transfer or > >> fragment transfer is completed if user set the interrupt type. So here > >> we should set the length for transaction transfer, block transfer and > >> fragment transfer. > > > > what are the max size these types support? > > These types max size definition: > > #define SPRD_DMA_FRG_LEN_MASK GENMASK(16, 0) > > #define SPRD_DMA_BLK_LEN_MASK GENMASK(16, 0) > > #define SPRD_DMA_TRSC_LEN_MASK GENMASK(27, 0) They are register defines. How many items or bytes do each type of txn support? -- ~Vinod
Re: [PATCH v2] ARM: omap2: Fix build when using split object directories
2018-04-13 11:58 GMT+09:00 Dave Gerlach :
> The sleep33xx and sleep43xx files should not depend on a header file
> generated in drivers/memory. Remove this dependency and instead allow
> both drivers/memory and arch/arm/mach-omap2 to generate all macros
> needed in headers local to their own paths.
>
> This fixes an issue where the build fail will when using O= to set a
> split object directory and arch/arm/mach-omap2 is built before
> drivers/memory with the following error:
>
> .../drivers/memory/emif-asm-offsets.c:1:0: fatal error: can't open
> drivers/memory/emif-asm-offsets.s for writing: No such file or directory
> compilation terminated.
>
> Fixes: 41d9d44d7258 ("ARM: OMAP2+: pm33xx-core: Add platform code needed for
> PM")
> Acked-by: Tony Lindgren
> Reviewed-by: Masahiro Yamada
> Tested-by: Anders Roxell
> Signed-off-by: Dave Gerlach
> ---
> v1 -> v2:
> * Removed drivers/memory/Makefile.asm-offsets and consolidated into
>drivers/memory/Makefile.
I did not mean like this.
I thought this clean-up would be done in a separate patch.
I think your previous patch is OK as-is.
> arch/arm/mach-omap2/Makefile | 6 +--
> arch/arm/mach-omap2/pm-asm-offsets.c | 3 ++
> arch/arm/mach-omap2/sleep33xx.S | 1 -
> arch/arm/mach-omap2/sleep43xx.S | 1 -
> drivers/memory/Makefile | 8 +++-
> drivers/memory/Makefile.asm-offsets | 5 ---
> drivers/memory/emif-asm-offsets.c| 72 +-
> include/linux/ti-emif-sram.h | 75
>
> 8 files changed, 86 insertions(+), 85 deletions(-)
> delete mode 100644 drivers/memory/Makefile.asm-offsets
>
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index 4603c30fef73..0d9ce58bc464 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -243,8 +243,4 @@ arch/arm/mach-omap2/pm-asm-offsets.s:
> arch/arm/mach-omap2/pm-asm-offsets.c
> include/generated/ti-pm-asm-offsets.h: arch/arm/mach-omap2/pm-asm-offsets.s
> FORCE
> $(call filechk,offsets,__TI_PM_ASM_OFFSETS_H__)
>
> -# For rule to generate ti-emif-asm-offsets.h dependency
> -include drivers/memory/Makefile.asm-offsets
> -
> -arch/arm/mach-omap2/sleep33xx.o: include/generated/ti-pm-asm-offsets.h
> include/generated/ti-emif-asm-offsets.h
> -arch/arm/mach-omap2/sleep43xx.o: include/generated/ti-pm-asm-offsets.h
> include/generated/ti-emif-asm-offsets.h
> +$(obj)/sleep33xx.o $(obj)/sleep43xx.o: include/generated/ti-pm-asm-offsets.h
> diff --git a/arch/arm/mach-omap2/pm-asm-offsets.c
> b/arch/arm/mach-omap2/pm-asm-offsets.c
> index 6d4392da7c11..b9846b19e5e2 100644
> --- a/arch/arm/mach-omap2/pm-asm-offsets.c
> +++ b/arch/arm/mach-omap2/pm-asm-offsets.c
> @@ -7,9 +7,12 @@
>
> #include
> #include
> +#include
>
> int main(void)
> {
> + ti_emif_asm_offsets();
> +
> DEFINE(AMX3_PM_WFI_FLAGS_OFFSET,
>offsetof(struct am33xx_pm_sram_data, wfi_flags));
> DEFINE(AMX3_PM_L2_AUX_CTRL_VAL_OFFSET,
> diff --git a/arch/arm/mach-omap2/sleep33xx.S b/arch/arm/mach-omap2/sleep33xx.S
> index 218d79930b04..322b3bb868b4 100644
> --- a/arch/arm/mach-omap2/sleep33xx.S
> +++ b/arch/arm/mach-omap2/sleep33xx.S
> @@ -6,7 +6,6 @@
> * Dave Gerlach, Vaibhav Bedia
> */
>
> -#include
> #include
> #include
> #include
> diff --git a/arch/arm/mach-omap2/sleep43xx.S b/arch/arm/mach-omap2/sleep43xx.S
> index b24be624e8b9..8903814a6677 100644
> --- a/arch/arm/mach-omap2/sleep43xx.S
> +++ b/arch/arm/mach-omap2/sleep43xx.S
> @@ -6,7 +6,6 @@
> * Dave Gerlach, Vaibhav Bedia
> */
>
> -#include
> #include
> #include
> #include
> diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
> index 66f55240830e..b3b95380346f 100644
> --- a/drivers/memory/Makefile
> +++ b/drivers/memory/Makefile
> @@ -28,6 +28,10 @@ ti-emif-sram-objs:= ti-emif-pm.o
> ti-emif-sram-pm.o
>
> AFLAGS_ti-emif-sram-pm.o :=-Wa,-march=armv7-a
>
> -include drivers/memory/Makefile.asm-offsets
> +drivers/memory/emif-asm-offsets.s: drivers/memory/emif-asm-offsets.c
> + $(call if_changed_dep,cc_s_c)
>
> -drivers/memory/ti-emif-sram-pm.o: include/generated/ti-emif-asm-offsets.h
> +include/generated/ti-emif-asm-offsets.h: drivers/memory/emif-asm-offsets.s
> FORCE
> + $(call filechk,offsets,__TI_EMIF_ASM_OFFSETS_H__)
> +
> +$(obj)/ti-emif-sram-pm.o: include/generated/ti-emif-asm-offsets.h
> diff --git a/drivers/memory/Makefile.asm-offsets
> b/drivers/memory/Makefile.asm-offsets
> deleted file mode 100644
> index 843ff60ccb5a..
> --- a/drivers/memory/Makefile.asm-offsets
> +++ /dev/null
> @@ -1,5 +0,0 @@
> -drivers/memory/emif-asm-offsets.s: drivers/memory/emif-asm-offsets.c
> - $(call if_changed_dep,cc_s_c)
> -
> -include/generated/ti-emif-asm-offsets.h: drivers/memory/emif-asm-offsets.s
> FORCE
> - $(call filechk,offsets,__TI_EMIF_ASM_OFFSETS_H__)
> diff --git a/drivers/memory/emif
linux-next: Tree for Apr 13
Hi all, Please do not add any v4.18 destined stuff to your linux-next included trees until after v4.17-rc1 has been released. Changes since 20180412: Non-merge commits (relative to Linus' tree): 940 1017 files changed, 32730 insertions(+), 22106 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 258 trees (counting Linus' and 44 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (80aa76bcd364 Merge tag 'xfs-4.17-merge-4' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux) Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild) Merging kbuild-current/fixes (28913ee8191a netfilter: nf_nat_snmp_basic: add correct dependency to Makefile) Merging arc-current/for-curr (661e50bc8532 Linux 4.16-rc4) Merging arm-current/fixes (2a141cd0d83b ARM: 8758/1: decompressor: restore r1 and r2 just before jumping to the kernel) Merging arm64-fixes/for-next/fixes (e21da1c99200 arm64: Relax ARM_SMCCC_ARCH_WORKAROUND_1 discovery) Merging m68k-current/for-linus (ecd685580c8f m68k/mac: Remove bogus "FIXME" comment) Merging powerpc-fixes/fixes (2675c13b293a powerpc/mm/radix: Fix checkstops caused by invalid tlbiel) Merging sparc/master (17dec0a94915 Merge branch 'userns-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (5d1365940a68 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging bpf/master (3a38bb98d9ab bpf/tracing: fix a deadlock in perf_event_detach_bpf_prog) Merging ipsec/master (4b66af2d6356 af_key: Always verify length of provided sadb_key) Merging netfilter/master (cf43ae63c024 netfilter: xt_connmark: Add bit mapping for bit-shift operation.) Merging ipvs/master (f7fb77fc1235 netfilter: nft_compat: check extension hook mask only if set) Merging wireless-drivers/master (77e30e10ee28 iwlwifi: mvm: query regdb for wmm rule if needed) Merging mac80211/master (b5dbc28762fd Merge tag 'kbuild-fixes-v4.16-3' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild) Merging rdma-fixes/for-rc (84652aefb347 RDMA/ucma: Introduce safer rdma_addr_size() variants) Merging sound-current/for-linus (7ecb46e9ee9a ALSA: line6: Use correct endpoint type for midi output) Merging pci-current/for-linus (adf58458bcb2 PCI: Remove messages about reassigning resources) Merging driver-core.current/driver-core-linus (38c23685b273 Merge tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc) Merging tty.current/tty-linus (38c23685b273 Merge tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc) Merging usb.current/usb-linus (38c23685b273 Merge tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc) Merging usb-gadget-fixes/fixes (c6ba5084ce0d usb: gadget: udc: renesas_usb3: add binging for r8a77965) Merging usb-serial-fixes/usb-linus (86d71233b615 USB: serial: ftdi_sio: add support for Harman FirmwareHubEmulator) Merging usb-chipidea-fixes/ci-for-usb-stable (964728f9f407 USB: chipidea: msm: fix ulpi-node l
Re: [PATCH] kernel/module: silence a gcc warning
Hi Mathieu, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.16 next-20180412] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Mathieu-Malaterre/kernel-module-silence-a-gcc-warning/20180413-044304 config: x86_64-randconfig-h0-04130701 (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All warnings (new ones prefixed by >>): In file included from drivers//of/base.c:22:0: >> include/linux/module.h:794:13: warning: 'struct tracepoint' declared inside >> parameter list will not be visible outside of this definition or declaration struct tracepoint * const *tp); ^~ Cyclomatic Complexity 1 include/linux/ctype.h:isdigit Cyclomatic Complexity 5 include/linux/compiler.h:__write_once_size Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:fls Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:fls64 Cyclomatic Complexity 1 include/uapi/linux/swab.h:__swab32p Cyclomatic Complexity 1 include/uapi/linux/byteorder/little_endian.h:__be32_to_cpup Cyclomatic Complexity 1 include/linux/bitops.h:fls_long Cyclomatic Complexity 1 include/linux/log2.h:__ilog2_u32 Cyclomatic Complexity 1 include/linux/log2.h:__ilog2_u64 Cyclomatic Complexity 1 include/linux/log2.h:__roundup_pow_of_two Cyclomatic Complexity 2 include/linux/list.h:__list_add Cyclomatic Complexity 1 include/linux/list.h:list_add_tail Cyclomatic Complexity 1 include/asm-generic/getorder.h:__get_order Cyclomatic Complexity 2 include/linux/string.h:kbasename Cyclomatic Complexity 3 include/linux/string.h:strncpy Cyclomatic Complexity 1 include/linux/string.h:strnlen Cyclomatic Complexity 4 include/linux/string.h:strlen Cyclomatic Complexity 6 include/linux/string.h:strlcpy Cyclomatic Complexity 3 include/linux/string.h:memset Cyclomatic Complexity 2 include/linux/of.h:of_read_number Cyclomatic Complexity 1 include/linux/of.h:of_find_node_by_path Cyclomatic Complexity 2 include/linux/of.h:of_property_read_u32_array Cyclomatic Complexity 1 include/linux/of.h:of_property_read_bool Cyclomatic Complexity 1 include/linux/of.h:of_property_read_u32 Cyclomatic Complexity 2 include/linux/of_device.h:of_cpu_device_node_get Cyclomatic Complexity 1 include/linux/kasan.h:kasan_kmalloc Cyclomatic Complexity 28 include/linux/slab.h:kmalloc_index Cyclomatic Complexity 1 include/linux/slab.h:kmem_cache_alloc_trace Cyclomatic Complexity 1 include/linux/slab.h:kmalloc_order_trace Cyclomatic Complexity 68 include/linux/slab.h:kmalloc_large Cyclomatic Complexity 5 include/linux/slab.h:kmalloc Cyclomatic Complexity 5 include/linux/slab.h:kmalloc_array Cyclomatic Complexity 1 include/linux/slab.h:kcalloc Cyclomatic Complexity 1 drivers//of/base.c:of_alias_add Cyclomatic Complexity 5 drivers//of/base.c:__of_find_property Cyclomatic Complexity 5 drivers//of/base.c:__of_get_next_child Cyclomatic Complexity 14 drivers//of/base.c:__of_device_is_compatible Cyclomatic Complexity 6 drivers//of/base.c:__of_match_node Cyclomatic Complexity 4 drivers//of/base.c:of_n_addr_cells Cyclomatic Complexity 4 drivers//of/base.c:of_n_size_cells Cyclomatic Complexity 1 drivers//of/base.c:of_find_property Cyclomatic Complexity 5 drivers//of/base.c:__of_find_all_nodes Cyclomatic Complexity 71 drivers//of/base.c:of_populate_phandle_cache Cyclomatic Complexity 4 drivers//of/base.c:of_core_init Cyclomatic Complexity 1 drivers//of/base.c:of_find_all_nodes Cyclomatic Complexity 2 drivers//of/base.c:__of_get_property Cyclomatic Complexity 6 drivers//of/base.c:__of_device_is_available Cyclomatic Complexity 2 drivers//of/base.c:of_get_property Cyclomatic Complexity 1 drivers//of/base.c:arch_match_cpu_phys_id Cyclomatic Complexity 5 drivers//of/base.c:__of_find_n_match_cpu_property Cyclomatic Complexity 1 drivers//of/base.c:arch_find_n_match_cpu_physical_id Cyclomatic Complexity 3 drivers//of/base.c:of_cpu_node_to_id Cyclomatic Complexity 1 drivers//of/base.c:of_device_is_compatible Cyclomatic Complexity 4 drivers//of/base.c:of_device_compatible_match Cyclomatic Complexity 2 drivers//of/base.c:of_machine_is_compatible Cyclomatic Complexity 1 drivers//of/base.c:of_device_is_available Cyclomatic Complexity 2 drivers//of/base.c:of_device_is_big_endian Cyclomatic Complexity 2 drivers//of/base.c:of_get_parent Cyclomatic Complexity 2 drivers//of/base.c:of_get_next_parent Cyclomatic Complexity 1 drivers//of/base.c:of_get_next_child Cyclomatic Complexity 6 drivers//of/base.c:of_get_next_available_child Cyclomatic Complexity 4 drivers//of/base.c:of_get_child_by_name Cyclomatic Com
Re: usercopy whitelist woe in scsi_sense_cache
On Thu, Apr 12, 2018 at 3:47 PM, Kees Cook wrote:
> After fixing up some build issues in the middle of the 4.16 cycle, I
> get an unhelpful bisect result of commit 0a4b6e2f80aa ("Merge branch
> 'for-4.16/block'"). Instead of letting the test run longer, I'm going
> to switch to doing several shorter test boots per kernel and see if
> that helps. One more bisect coming...
Okay, so I can confirm the bisect points at the _merge_ itself, not a
specific patch. I'm not sure how to proceed here. It looks like some
kind of interaction between separate trees? Jens, do you have
suggestions on how to track this down?
-Kees
--
Kees Cook
Pixel Security
Re: [PATCH] ARM: omap2: Fix build when using split object directories
Hi,
On 04/12/2018 04:08 AM, Masahiro Yamada wrote:
> 2018-04-12 17:21 GMT+09:00 Anders Roxell :
>> On 2018-04-11 16:15, Dave Gerlach wrote:
>>> The sleep33xx and sleep43xx files should not depend on a header file
>>> generated in drivers/memory. Remove this dependency and instead allow
>>> both drivers/memory and arch/arm/mach-omap2 to generate all macros
>>> needed in headers local to their own paths.
>>>
>>> This fixes an issue where the build fail will when using O= to set a
>>> split object directory and arch/arm/mach-omap2 is built before
>>> drivers/memory with the following error:
>>>
>>> .../drivers/memory/emif-asm-offsets.c:1:0: fatal error: can't open
>>> drivers/memory/emif-asm-offsets.s for writing: No such file or directory
>>> compilation terminated.
>>>
>>> Fixes: 41d9d44d7258 ("ARM: OMAP2+: pm33xx-core: Add platform code needed
>>> for PM")
>>> Acked-by: Tony Lindgren
>>> Reviewed-by: Masahiro Yamada
>>> Signed-off-by: Dave Gerlach
>>
>> Tested-by: Anders Roxell
>>
>> Maybe we can remove drivers/memory/Makefile.asm-offsets and move those
>> changes into drivers/memory/Makefile ?
>
> Agree!
Alright, I agree as well, fixed in v2.
Regards,
Dave
>
>
>
>
[PATCH v2] ARM: omap2: Fix build when using split object directories
The sleep33xx and sleep43xx files should not depend on a header file
generated in drivers/memory. Remove this dependency and instead allow
both drivers/memory and arch/arm/mach-omap2 to generate all macros
needed in headers local to their own paths.
This fixes an issue where the build fail will when using O= to set a
split object directory and arch/arm/mach-omap2 is built before
drivers/memory with the following error:
.../drivers/memory/emif-asm-offsets.c:1:0: fatal error: can't open
drivers/memory/emif-asm-offsets.s for writing: No such file or directory
compilation terminated.
Fixes: 41d9d44d7258 ("ARM: OMAP2+: pm33xx-core: Add platform code needed for
PM")
Acked-by: Tony Lindgren
Reviewed-by: Masahiro Yamada
Tested-by: Anders Roxell
Signed-off-by: Dave Gerlach
---
v1 -> v2:
* Removed drivers/memory/Makefile.asm-offsets and consolidated into
drivers/memory/Makefile.
arch/arm/mach-omap2/Makefile | 6 +--
arch/arm/mach-omap2/pm-asm-offsets.c | 3 ++
arch/arm/mach-omap2/sleep33xx.S | 1 -
arch/arm/mach-omap2/sleep43xx.S | 1 -
drivers/memory/Makefile | 8 +++-
drivers/memory/Makefile.asm-offsets | 5 ---
drivers/memory/emif-asm-offsets.c| 72 +-
include/linux/ti-emif-sram.h | 75
8 files changed, 86 insertions(+), 85 deletions(-)
delete mode 100644 drivers/memory/Makefile.asm-offsets
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 4603c30fef73..0d9ce58bc464 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -243,8 +243,4 @@ arch/arm/mach-omap2/pm-asm-offsets.s:
arch/arm/mach-omap2/pm-asm-offsets.c
include/generated/ti-pm-asm-offsets.h: arch/arm/mach-omap2/pm-asm-offsets.s
FORCE
$(call filechk,offsets,__TI_PM_ASM_OFFSETS_H__)
-# For rule to generate ti-emif-asm-offsets.h dependency
-include drivers/memory/Makefile.asm-offsets
-
-arch/arm/mach-omap2/sleep33xx.o: include/generated/ti-pm-asm-offsets.h
include/generated/ti-emif-asm-offsets.h
-arch/arm/mach-omap2/sleep43xx.o: include/generated/ti-pm-asm-offsets.h
include/generated/ti-emif-asm-offsets.h
+$(obj)/sleep33xx.o $(obj)/sleep43xx.o: include/generated/ti-pm-asm-offsets.h
diff --git a/arch/arm/mach-omap2/pm-asm-offsets.c
b/arch/arm/mach-omap2/pm-asm-offsets.c
index 6d4392da7c11..b9846b19e5e2 100644
--- a/arch/arm/mach-omap2/pm-asm-offsets.c
+++ b/arch/arm/mach-omap2/pm-asm-offsets.c
@@ -7,9 +7,12 @@
#include
#include
+#include
int main(void)
{
+ ti_emif_asm_offsets();
+
DEFINE(AMX3_PM_WFI_FLAGS_OFFSET,
offsetof(struct am33xx_pm_sram_data, wfi_flags));
DEFINE(AMX3_PM_L2_AUX_CTRL_VAL_OFFSET,
diff --git a/arch/arm/mach-omap2/sleep33xx.S b/arch/arm/mach-omap2/sleep33xx.S
index 218d79930b04..322b3bb868b4 100644
--- a/arch/arm/mach-omap2/sleep33xx.S
+++ b/arch/arm/mach-omap2/sleep33xx.S
@@ -6,7 +6,6 @@
* Dave Gerlach, Vaibhav Bedia
*/
-#include
#include
#include
#include
diff --git a/arch/arm/mach-omap2/sleep43xx.S b/arch/arm/mach-omap2/sleep43xx.S
index b24be624e8b9..8903814a6677 100644
--- a/arch/arm/mach-omap2/sleep43xx.S
+++ b/arch/arm/mach-omap2/sleep43xx.S
@@ -6,7 +6,6 @@
* Dave Gerlach, Vaibhav Bedia
*/
-#include
#include
#include
#include
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index 66f55240830e..b3b95380346f 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -28,6 +28,10 @@ ti-emif-sram-objs:= ti-emif-pm.o
ti-emif-sram-pm.o
AFLAGS_ti-emif-sram-pm.o :=-Wa,-march=armv7-a
-include drivers/memory/Makefile.asm-offsets
+drivers/memory/emif-asm-offsets.s: drivers/memory/emif-asm-offsets.c
+ $(call if_changed_dep,cc_s_c)
-drivers/memory/ti-emif-sram-pm.o: include/generated/ti-emif-asm-offsets.h
+include/generated/ti-emif-asm-offsets.h: drivers/memory/emif-asm-offsets.s
FORCE
+ $(call filechk,offsets,__TI_EMIF_ASM_OFFSETS_H__)
+
+$(obj)/ti-emif-sram-pm.o: include/generated/ti-emif-asm-offsets.h
diff --git a/drivers/memory/Makefile.asm-offsets
b/drivers/memory/Makefile.asm-offsets
deleted file mode 100644
index 843ff60ccb5a..
--- a/drivers/memory/Makefile.asm-offsets
+++ /dev/null
@@ -1,5 +0,0 @@
-drivers/memory/emif-asm-offsets.s: drivers/memory/emif-asm-offsets.c
- $(call if_changed_dep,cc_s_c)
-
-include/generated/ti-emif-asm-offsets.h: drivers/memory/emif-asm-offsets.s
FORCE
- $(call filechk,offsets,__TI_EMIF_ASM_OFFSETS_H__)
diff --git a/drivers/memory/emif-asm-offsets.c
b/drivers/memory/emif-asm-offsets.c
index 71a89d5d3efd..db8043019ec6 100644
--- a/drivers/memory/emif-asm-offsets.c
+++ b/drivers/memory/emif-asm-offsets.c
@@ -16,77 +16,7 @@
int main(void)
{
- DEFINE(EMIF_SDCFG_VAL_OFFSET,
- offsetof(struct emif_regs_amx3, emif_sdcfg_val));
- DEFINE(EMIF_TIMING1_VAL_OFFSET,
- offsetof(struct emif_regs_amx3, emif_timing1
Re: [PATCH] PM / devfreq: use put_device() instead of kfree()
On 2018년 04월 13일 11:37, arvindY wrote:
>
>
> On Friday 13 April 2018 07:59 AM, Chanwoo Choi wrote:
>> On 2018년 04월 13일 11:15, arvindY wrote:
>>> Hi Chanwoo,
>>>
>>> On Friday 13 April 2018 06:43 AM, Chanwoo Choi wrote:
On 2018년 04월 13일 10:03, Chanwoo Choi wrote:
> Hi,
>
> I'm sorry for the late reply.
>
> On 2018년 03월 30일 20:44, Arvind Yadav wrote:
>> Never directly free @dev after calling device_register() or
>> device_unregister(), even if device_register() returned an error.
>> Always use put_device() to give up the reference initialized.
>>
>> Signed-off-by: Arvind Yadav
>> ---
>>drivers/devfreq/devfreq.c | 4 +++-
>>1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
>> index fe2af6a..a225b94 100644
>> --- a/drivers/devfreq/devfreq.c
>> +++ b/drivers/devfreq/devfreq.c
>> @@ -625,7 +625,8 @@ struct devfreq *devfreq_add_device(struct device
>> *dev,
>>err = device_register(&devfreq->dev);
>>if (err) {
>>mutex_unlock(&devfreq->lock);
>> -goto err_dev;
>> +put_device(&devfreq->dev);
>> +goto err_out;
> why do you change the goto postion?
> err_out is correct to free the memory of devfreq instance.
Sorry. err_dev is correct instead of err_out.
>>> If you will see the comment for device_register(drivers/base/core.c)
>>> there is mentioned that 'NOTE: _Never_ directly free @dev
>>> after calling this function, even if it returned an error!
>>> Always use put_device() to give up the reference initialized
>>> in this function instead. Here put_device() will decrement
>>> the last reference and then free the memory by calling dev->release.
>>> Internally put_device() -> kobject_put() -> kobject_cleanup() which
>>> is responsible to call 'dev -> release' and also free other kobject
>>> resources.
>>>
>>> We are releasing devfreq in devfreq_dev_release(). So no need
>>> to call kfree() again. It'll be redundant. 'err_out' is correct.
>> You're right. err_out is correct.
>> put_device() -> dev->release() -> devfreq_dev_release() -> kfree(devfreq)
>>
>>}
>> devfreq->trans_table =devm_kzalloc(&devfreq->dev,
>> @@ -671,6 +672,7 @@ struct devfreq *devfreq_add_device(struct device
>> *dev,
>>mutex_unlock(&devfreq_list_lock);
>> device_unregister(&devfreq->dev);
>> +devfreq = NULL;
> It is wrong. If you initialize the devfreq as NULL,
> never free the 'devfreq' instance.
>>> No need to release memory after device_unregister().
>>> driver core will take care of this. It will release memory
>>> So no need to call free again.
>> If you have to initialize the devfreq instance as NULL,
>> I think that you better to init in the devfreq_dev_release()
>> as following:
>>
>> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
>> index fe2af6aa88fc..8c52a13d3887 100644
>> --- a/drivers/devfreq/devfreq.c
>> +++ b/drivers/devfreq/devfreq.c
>> @@ -543,6 +543,7 @@ static void devfreq_dev_release(struct device *dev)
>>mutex_destroy(&devfreq->lock);
>> kfree(devfreq);
>> + devfreq = NULL;
>> }
>
> Yes, You are right. I will share a update patch.
> Thanks for reviewing.
It is my mistake. 'devfreq' is local variable in the devfreq_dev_release(0.
Even if initializes 'devfreq = NULL' in the devfreq_dev_release(),
it cannot initialize the 'devfreq' local variable in the devfreq_add_device().
I think that your original patch is good.
Reviewed-by: Chanwoo Choi
>>
>>err_dev:
>>if (devfreq)
>>kfree(devfreq);
>>
>>> ~arvind
>>>
>>>
>>>
>>
>
>
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH] Revert "xhci: plat: Register shutdown for xhci_plat"
On 13 April 2018 5:59:51 AM IST, Greg Hackmann wrote: >Pixel 2 field testers reported that when they tried to reboot their >phones with some USB devices plugged in, the reboot would get wedged >and >eventually trigger watchdog reset. Once the Pixel kernel team found a >reliable repro case, they narrowed it down to this commit's 4.4.y >backport. Reverting the change made the issue go away. Are you allowed to make the repro steps public? I'm writing this from a walleye and would be grateful if I could test for this in the modifed tree I'm running atm. -- Harsh Shandilya, PRJKT Development LLC
Re: [PATCH][next] scsi: fnic: fix spelling mistake in fnic stats "Abord" -> "Abort"
Colin, > Trivial fix to spelling mistake in fnic stats message text Applied to 4.17/scsi-fixes. Thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] PM / devfreq: use put_device() instead of kfree()
On Friday 13 April 2018 07:59 AM, Chanwoo Choi wrote:
On 2018년 04월 13일 11:15, arvindY wrote:
Hi Chanwoo,
On Friday 13 April 2018 06:43 AM, Chanwoo Choi wrote:
On 2018년 04월 13일 10:03, Chanwoo Choi wrote:
Hi,
I'm sorry for the late reply.
On 2018년 03월 30일 20:44, Arvind Yadav wrote:
Never directly free @dev after calling device_register() or
device_unregister(), even if device_register() returned an error.
Always use put_device() to give up the reference initialized.
Signed-off-by: Arvind Yadav
---
drivers/devfreq/devfreq.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index fe2af6a..a225b94 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -625,7 +625,8 @@ struct devfreq *devfreq_add_device(struct device *dev,
err = device_register(&devfreq->dev);
if (err) {
mutex_unlock(&devfreq->lock);
-goto err_dev;
+put_device(&devfreq->dev);
+goto err_out;
why do you change the goto postion?
err_out is correct to free the memory of devfreq instance.
Sorry. err_dev is correct instead of err_out.
If you will see the comment for device_register(drivers/base/core.c)
there is mentioned that 'NOTE: _Never_ directly free @dev
after calling this function, even if it returned an error!
Always use put_device() to give up the reference initialized
in this function instead. Here put_device() will decrement
the last reference and then free the memory by calling dev->release.
Internally put_device() -> kobject_put() -> kobject_cleanup() which
is responsible to call 'dev -> release' and also free other kobject resources.
We are releasing devfreq in devfreq_dev_release(). So no need
to call kfree() again. It'll be redundant. 'err_out' is correct.
You're right. err_out is correct.
put_device() -> dev->release() -> devfreq_dev_release() -> kfree(devfreq)
}
devfreq->trans_table =devm_kzalloc(&devfreq->dev,
@@ -671,6 +672,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
mutex_unlock(&devfreq_list_lock);
device_unregister(&devfreq->dev);
+devfreq = NULL;
It is wrong. If you initialize the devfreq as NULL,
never free the 'devfreq' instance.
No need to release memory after device_unregister().
driver core will take care of this. It will release memory
So no need to call free again.
If you have to initialize the devfreq instance as NULL,
I think that you better to init in the devfreq_dev_release()
as following:
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index fe2af6aa88fc..8c52a13d3887 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -543,6 +543,7 @@ static void devfreq_dev_release(struct device *dev)
mutex_destroy(&devfreq->lock);
kfree(devfreq);
+ devfreq = NULL;
}
Yes, You are right. I will share a update patch.
Thanks for reviewing.
err_dev:
if (devfreq)
kfree(devfreq);
~arvind
Re: [PATCH v4 2/2] MIPS: io: add a barrier after register read in readX()
On 4/12/2018 10:30 PM, Sinan Kaya wrote: > + /* prevent prefetching of coherent DMA dma prematurely */ \ I tried to write DMA data but my keyboard is not cooperating. I'll hold onto posting another version until I hear back from you for wmb(). -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH] PM / devfreq: use put_device() instead of kfree()
On 2018년 04월 13일 11:15, arvindY wrote:
> Hi Chanwoo,
>
> On Friday 13 April 2018 06:43 AM, Chanwoo Choi wrote:
>> On 2018년 04월 13일 10:03, Chanwoo Choi wrote:
>>> Hi,
>>>
>>> I'm sorry for the late reply.
>>>
>>> On 2018년 03월 30일 20:44, Arvind Yadav wrote:
Never directly free @dev after calling device_register() or
device_unregister(), even if device_register() returned an error.
Always use put_device() to give up the reference initialized.
Signed-off-by: Arvind Yadav
---
drivers/devfreq/devfreq.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index fe2af6a..a225b94 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -625,7 +625,8 @@ struct devfreq *devfreq_add_device(struct device *dev,
err = device_register(&devfreq->dev);
if (err) {
mutex_unlock(&devfreq->lock);
-goto err_dev;
+put_device(&devfreq->dev);
+goto err_out;
>>> why do you change the goto postion?
>>> err_out is correct to free the memory of devfreq instance.
>> Sorry. err_dev is correct instead of err_out.
>
> If you will see the comment for device_register(drivers/base/core.c)
> there is mentioned that 'NOTE: _Never_ directly free @dev
> after calling this function, even if it returned an error!
> Always use put_device() to give up the reference initialized
> in this function instead. Here put_device() will decrement
> the last reference and then free the memory by calling dev->release.
> Internally put_device() -> kobject_put() -> kobject_cleanup() which
> is responsible to call 'dev -> release' and also free other kobject resources.
>
> We are releasing devfreq in devfreq_dev_release(). So no need
> to call kfree() again. It'll be redundant. 'err_out' is correct.
You're right. err_out is correct.
put_device() -> dev->release() -> devfreq_dev_release() -> kfree(devfreq)
>>
}
devfreq->trans_table =devm_kzalloc(&devfreq->dev,
@@ -671,6 +672,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
mutex_unlock(&devfreq_list_lock);
device_unregister(&devfreq->dev);
+devfreq = NULL;
>>> It is wrong. If you initialize the devfreq as NULL,
>>> never free the 'devfreq' instance.
>
> No need to release memory after device_unregister().
> driver core will take care of this. It will release memory
> So no need to call free again.
If you have to initialize the devfreq instance as NULL,
I think that you better to init in the devfreq_dev_release()
as following:
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index fe2af6aa88fc..8c52a13d3887 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -543,6 +543,7 @@ static void devfreq_dev_release(struct device *dev)
mutex_destroy(&devfreq->lock);
kfree(devfreq);
+ devfreq = NULL;
}
>>>
err_dev:
if (devfreq)
kfree(devfreq);
>>>
>>
>
> ~arvind
>
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
[PATCH v4 1/2] MIPS: io: prevent compiler reordering on the default writeX() implementation
writeX() has a strong ordering semantics with respect to memory updates.
In the abscence of a write barrier or a compiler barrier, commpiler can
reorder register and memory update instructions. This breaks the writeX()
API.
Signed-off-by: Sinan Kaya
---
arch/mips/include/asm/io.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips/include/asm/io.h b/arch/mips/include/asm/io.h
index 0cbf3af..fd00ddaf 100644
--- a/arch/mips/include/asm/io.h
+++ b/arch/mips/include/asm/io.h
@@ -307,7 +307,7 @@ static inline void iounmap(const volatile void __iomem
*addr)
#if defined(CONFIG_CPU_CAVIUM_OCTEON) || defined(CONFIG_LOONGSON3_ENHANCEMENT)
#define war_io_reorder_wmb() wmb()
#else
-#define war_io_reorder_wmb() do { } while (0)
+#define war_io_reorder_wmb() barrier()
#endif
#define __BUILD_MEMORY_SINGLE(pfx, bwlq, type, irq)\
--
2.7.4
[PATCH v4 2/2] MIPS: io: add a barrier after register read in readX()
While a barrier is present in writeX() function before the register write, a similar barrier is missing in the readX() function after the register read. This could allow memory accesses following readX() to observe stale data. Signed-off-by: Sinan Kaya Reported-by: Arnd Bergmann --- arch/mips/include/asm/io.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/mips/include/asm/io.h b/arch/mips/include/asm/io.h index fd00ddaf..d96af41 100644 --- a/arch/mips/include/asm/io.h +++ b/arch/mips/include/asm/io.h @@ -377,6 +377,8 @@ static inline type pfx##read##bwlq(const volatile void __iomem *mem)\ BUG(); \ } \ \ + /* prevent prefetching of coherent DMA dma prematurely */ \ + rmb(); \ return pfx##ioswab##bwlq(__mem, __val); \ } -- 2.7.4
ABOUT YOUR ATM CARD
Attention... Please contact Rev. Dr. Dennis Iwuji immediately for your ATM Card payment that will be sent to you through the FedEx representative here.His name and contact is as follows: NAME ; Rev. Dr. Dennis Iwuji Email: revd.iw...@gmail.com He will send you your ATM CARD which you will use to withdraw your money via ATM MACHINE in any part of the world,and the maximum daily limit is Fifteen Thousand United States dollars($15,000.00). And also the Government/Presidency has taken care of the shipping fee of your ATM card,So if the delivery agent is requesting for another shipping fee, You will have to report him to me immediately. When you receive your ATM card, you have to alert me so that we can give you process of how to activate and make use of your ATM CARD.If you like to receive your fund this way,Kindly contact him with the following informations below, Send it to his email address; (1) Your Full Name (2) Full residential address (3) Phone And Fax Number (4) Occupation. (5) Age (6) Marital Status (7) Country This message is supported by the Federal Government, After you might have started making use of your ATM card, you can reward my firm one way or the other you knows best. Thanks for your co-operation. Respectively Ms Elizabeth Squire. Secretary ATM CARD PROCESSING DEPARTMENT. Email: revd.iw...@gmail.com
[git pull] drm fixes for 4.17-rc1
Hi Linus, Decloaking in the middle of holidays (still off all next week), just to vacuum up any outstanding fixes for rc1. One omap, and one alsa pm fix (we merged the breaking patch via drm tree). Otherwise it's two bunches of amdgpu fixes, removing an unneeded file, some DC fixes, HDMI audio regression fix, and some vega12 fixes. I didn't get any i915 fixes so I'm assuming they can wait until -rc2 if they have any, though I probably won't be back until rc2 releases. Thanks, Dave. The following changes since commit 694f54f680f7fd8e9561928fbfc537d9afbc3d79: Merge branch 'drm-misc-next-fixes' of git://anongit.freedesktop.org/drm/drm-misc into drm-next (2018-03-29 09:25:13 +1000) are available in the Git repository at: git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.17-rc1 for you to fetch changes up to a10beabba213924d876f2d10ca9351aeab93f58a: Merge branch 'drm-next-4.17' of git://people.freedesktop.org/~agd5f/linux into drm-next (2018-04-13 09:25:21 +1000) amdgpu, omap and snd regression fix Alex Deucher (3): drm/amdgpu/sdma: fix mask in emit_pipeline_sync drm/amdgpu/si: implement get/set pcie_lanes asic callback drm/amdgpu: Fix PCIe lane width calculation Andrey Grodzovsky (2): drm/amdgpu: Fix KIQ hang on bare metal for device unbind/bind back v2. drm/amdgpu: Add support for SRBM selection v3 Charlene Liu (1): drm/amd/display: HDMI has no sound after Panel power off/on Chunming Zhou (2): drm/amdgpu: fix typo of domain fallback Revert "drm/amdgpu: Don't change preferred domian when fallback GTT v5" Dan Carpenter (1): drm/amd/pp: silence a static checker warning Dave Airlie (4): Merge tag 'drm-misc-next-fixes-2018-04-04' of git://anongit.freedesktop.org/drm/drm-misc into drm-next Merge branch 'drm-next-4.17' of git://people.freedesktop.org/~agd5f/linux into drm-next Merge tag 'drm-misc-next-fixes-2018-04-11' of git://anongit.freedesktop.org/drm/drm-misc into drm-next Merge branch 'drm-next-4.17' of git://people.freedesktop.org/~agd5f/linux into drm-next Eric Huang (1): drm/amd/powerply: fix power reading on Fiji Evan Quan (2): drm/amdgpu: drop compute ring timeout setting for non-sriov only (v2) drm/amdgpu: add MP1 and THM hw ip base reg offset Harry Wentland (3): drm/amd/display: Only register backlight device if embedded panel connected Revert "drm/amd/display: fix dereferencing possible ERR_PTR()" Revert "drm/amd/display: disable CRTCs with NULL FB on their primary plane (V2)" Huang Rui (1): drm/amdgpu: fix null pointer panic with direct fw loading on gpu reset Kenneth Feng (1): drm/amd/powerplay: Enable ACG SS feature Leo (Sunpeng) Li (1): drm/amd/display: Fix regamma not affecting full-intensity color values Lukas Wunner (1): ALSA: hda - Silence PM ops build warning Nico Sneck (1): drm/radeon: add PX quirk for Asus K73TK Paul Parsons (1): drm/radeon: Fix PCIe lane width calculation Rex Zhu (2): drm/amd/pp: Remove Dead functions on Vega12 drm/amd/pp: Clean header file in vega12_smumgr.c Roman Li (2): drm/amd/display: fix brightness level after resume from suspend drm/amd/display: Fix FBC text console corruption Takashi Iwai (1): drm/amdgpu: Fix memory leaks at amdgpu_init() error path Tomi Valkeinen (1): drm/omap: fix crash if there's no video PLL drivers/gpu/drm/amd/amdgpu/amdgpu.h|4 + drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c| 117 +- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|9 +- drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 12 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 16 +- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 18 +- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c|3 + drivers/gpu/drm/amd/amdgpu/cik_sdma.c |2 +- drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c |7 + drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c |7 + drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c |7 + drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 61 +- drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c |2 +- drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c |2 +- drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c |2 +- drivers/gpu/drm/amd/amdgpu/si.c| 67 + drivers/gpu/drm/amd/amdgpu/si_dpm.c|4 +- drivers/gpu/drm/amd/amdgpu/vega10_reg_init.c |3 +- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 89 +- drivers/gpu/drm/amd/display/dc/core/dc_link.c | 13 + drivers/gpu/drm/amd/display/dc/dc_link.h |2 + .../drm/amd/display/dc/dce/dce_stream_encoder.c|2 + .../drm/amd/display/dc/dce110/dce110_compressor.c | 67 +-
Re: [PATCH] PM / devfreq: use put_device() instead of kfree()
Hi Chanwoo,
On Friday 13 April 2018 06:43 AM, Chanwoo Choi wrote:
On 2018년 04월 13일 10:03, Chanwoo Choi wrote:
Hi,
I'm sorry for the late reply.
On 2018년 03월 30일 20:44, Arvind Yadav wrote:
Never directly free @dev after calling device_register() or
device_unregister(), even if device_register() returned an error.
Always use put_device() to give up the reference initialized.
Signed-off-by: Arvind Yadav
---
drivers/devfreq/devfreq.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index fe2af6a..a225b94 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -625,7 +625,8 @@ struct devfreq *devfreq_add_device(struct device *dev,
err = device_register(&devfreq->dev);
if (err) {
mutex_unlock(&devfreq->lock);
- goto err_dev;
+ put_device(&devfreq->dev);
+ goto err_out;
why do you change the goto postion?
err_out is correct to free the memory of devfreq instance.
Sorry. err_dev is correct instead of err_out.
If you will see the comment for device_register(drivers/base/core.c)
there is mentioned that 'NOTE: _Never_ directly free @dev
after calling this function, even if it returned an error!
Always use put_device() to give up the reference initialized
in this function instead. Here put_device() will decrement
the last reference and then free the memory by calling dev->release.
Internally put_device() -> kobject_put() -> kobject_cleanup() which
is responsible to call 'dev -> release' and also free other kobject
resources.
We are releasing devfreq in devfreq_dev_release(). So no need
to call kfree() again. It'll be redundant. 'err_out' is correct.
}
devfreq->trans_table = devm_kzalloc(&devfreq->dev,
@@ -671,6 +672,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
mutex_unlock(&devfreq_list_lock);
device_unregister(&devfreq->dev);
+ devfreq = NULL;
It is wrong. If you initialize the devfreq as NULL,
never free the 'devfreq' instance.
No need to release memory after device_unregister().
driver core will take care of this. It will release memory
So no need to call free again.
err_dev:
if (devfreq)
kfree(devfreq);
~arvind
Re: [PATCH net] net: dsa: mv88e6xxx: Fix receive time stamp race condition.
From: Richard Cochran Date: Thu, 12 Apr 2018 10:35:40 -0700 > On Mon, Apr 09, 2018 at 07:19:31AM -0700, Richard Cochran wrote: >> Dave, please hold off on this patch. I am seeing new problems in my >> testing with this applied. I still need to get to the bottom of >> this. > > Looks like the new problems are a HW/board glitch. > > The patch is good to go. Ok, applied and queued up for -stable. Thanks.
Re: 4.15.14 crash with iscsi target and dvd
On Thu, Apr 12, 2018 at 09:43:02PM -0400, Wakko Warner wrote:
> Ming Lei wrote:
> > On Tue, Apr 10, 2018 at 08:45:25PM -0400, Wakko Warner wrote:
> > > Sorry for the delay. I reverted my change, added this one. I didn't
> > > reboot, I just unloaded and loaded this one.
> > > Note: /dev/sr1 as seen from the initiator is /dev/sr0 (physical disc) on
> > > the
> > > target.
> > >
> > > Doesn't crash, however on the initiator I see this:
> > > [9273849.70] ISO 9660 Extensions: RRIP_1991A
> > > [9273863.359718] scsi_io_completion: 13 callbacks suppressed
> > > [9273863.359788] sr 26:0:0:0: [sr1] tag#1 UNKNOWN(0x2003) Result:
> > > hostbyte=0x00 driverbyte=0x08
> > > [9273863.359909] sr 26:0:0:0: [sr1] tag#1 Sense Key : 0x2 [current]
> > > [9273863.359974] sr 26:0:0:0: [sr1] tag#1 ASC=0x8 ASCQ=0x0
> > > [9273863.360036] sr 26:0:0:0: [sr1] tag#1 CDB: opcode=0x28 28 00 00 22 f6
> > > 96 00 00 80 00
> > > [9273863.360116] blk_update_request: 13 callbacks suppressed
> > > [9273863.360177] blk_update_request: I/O error, dev sr1, sector 9165400
> > > [9273875.864648] sr 26:0:0:0: [sr1] tag#1 UNKNOWN(0x2003) Result:
> > > hostbyte=0x00 driverbyte=0x08
> > > [9273875.864738] sr 26:0:0:0: [sr1] tag#1 Sense Key : 0x2 [current]
> > > [9273875.864801] sr 26:0:0:0: [sr1] tag#1 ASC=0x8 ASCQ=0x0
> > > [9273875.864890] sr 26:0:0:0: [sr1] tag#1 CDB: opcode=0x28 28 00 00 22 f7
> > > 16 00 00 80 00
> > > [9273875.864971] blk_update_request: I/O error, dev sr1, sector 9165912
> > >
> > > To cause this, I mounted the dvd as seen in the first line and ran this
> > > command: find /cdrom2 -type f | xargs -tn1 cat > /dev/null
> > > I did some various tests. Each test was done after umount and mount to
> > > clear the cache.
> > > cat > /dev/null causes the message.
> > > dd if= of=/dev/null bs=2048 doesn't
> > > using bs=4096 doesn't
> > > using bs=64k doesn't
> > > using bs=128k does
> > > cat uses a blocksize of 128k.
> > >
> > > The following was done without being mounted.
> > > ddrescue -f -f /dev/sr1 /dev/null
> > > doesn't cause the message
> > > dd if=/dev/sr1 of=/dev/null bs=128k
> > > doesn't cause the message
> > > using bs=256k causes the message once:
> > > [9275916.857409] sr 27:0:0:0: [sr1] tag#0 UNKNOWN(0x2003) Result:
> > > hostbyte=0x00 driverbyte=0x08
> > > [9275916.857482] sr 27:0:0:0: [sr1] tag#0 Sense Key : 0x2 [current]
> > > [9275916.857520] sr 27:0:0:0: [sr1] tag#0 ASC=0x8 ASCQ=0x0
> > > [9275916.857556] sr 27:0:0:0: [sr1] tag#0 CDB: opcode=0x28 28 00 00 00 00
> > > 00 00 00 80 00
> > > [9275916.857614] blk_update_request: I/O error, dev sr1, sector 0
> > >
> > > If I access the disc from the target natively either by mounting and
> > > accessing files or working with the device directly (ie dd) no errors are
> > > logged on the target.
> >
> > OK, thanks for your test.
> >
> > Could you test the following patch and see if there is still the failure
> > message?
> >
> > diff --git a/drivers/target/target_core_pscsi.c
> > b/drivers/target/target_core_pscsi.c
> > index 0d99b242e82e..6137287b52fb 100644
> > --- a/drivers/target/target_core_pscsi.c
> > +++ b/drivers/target/target_core_pscsi.c
> > @@ -913,9 +913,11 @@ pscsi_map_sg(struct se_cmd *cmd, struct scatterlist
> > *sgl, u32 sgl_nents,
> >
> > rc = bio_add_pc_page(pdv->pdv_sd->request_queue,
> > bio, page, bytes, off);
> > + if (rc != bytes)
> > + goto fail;
> > pr_debug("PSCSI: bio->bi_vcnt: %d nr_vecs: %d\n",
> > bio_segments(bio), nr_vecs);
> > - if (rc != bytes) {
> > + if (/*rc != bytes*/0) {
> > pr_debug("PSCSI: Reached bio->bi_vcnt max:"
> > " %d i: %d bio: %p, allocating another"
> > " bio\n", bio->bi_vcnt, i, bio);
>
> Target doesn't crash but the errors on the initiator are still there.
OK, then this error log isn't related with my commit, because the patch
I sent to you in last email is to revert my commit simply.
But the following patch is one correct fix for your crash.
https://marc.info/?l=linux-kernel&m=152331690727052&w=2
Thanks,
Ming
Re: [PATCH] selftests: net: add in_netns.sh to TEST_PROGS
From: Anders Roxell
Date: Wed, 11 Apr 2018 17:17:34 +0200
> Script in_netns.sh isn't installed.
>
> running psock_fanout test
>
> ./run_afpackettests: line 12: ./in_netns.sh: No such file or directory
> [FAIL]
>
> running psock_tpacket test
>
> ./run_afpackettests: line 22: ./in_netns.sh: No such file or directory
> [FAIL]
>
> In current code added in_netns.sh to be installed.
>
> Fixes: cc30c93fa020 ("selftests/net: ignore background traffic in
> psock_fanout")
> Signed-off-by: Anders Roxell
Applied, thanks.
Re: [PATCHv2] mISDN: Remove VLAs
From: Laura Abbott Date: Tue, 10 Apr 2018 18:04:29 -0700 > There's an ongoing effort to remove VLAs[1] from the kernel to eventually > turn on -Wvla. Remove the VLAs from the mISDN code by switching to using > kstrdup in one place and using an upper bound in another. > > Signed-off-by: Laura Abbott > --- > v2: Switch to a tighter upper bound so we are allocating a more > reasonable amount on the stack (300). This is based on previous checks > against this value. Applied.
Re: [PATCH] net/tls: Remove VLA usage
From: Kees Cook Date: Tue, 10 Apr 2018 17:52:34 -0700 > In the quest to remove VLAs from the kernel[1], this replaces the VLA > size with the only possible size used in the code, and adds a mechanism > to double-check future IV sizes. > > [1] > https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com > > Signed-off-by: Kees Cook Applied.
Re: 4.15.14 crash with iscsi target and dvd
Ming Lei wrote:
> On Tue, Apr 10, 2018 at 08:45:25PM -0400, Wakko Warner wrote:
> > Sorry for the delay. I reverted my change, added this one. I didn't
> > reboot, I just unloaded and loaded this one.
> > Note: /dev/sr1 as seen from the initiator is /dev/sr0 (physical disc) on the
> > target.
> >
> > Doesn't crash, however on the initiator I see this:
> > [9273849.70] ISO 9660 Extensions: RRIP_1991A
> > [9273863.359718] scsi_io_completion: 13 callbacks suppressed
> > [9273863.359788] sr 26:0:0:0: [sr1] tag#1 UNKNOWN(0x2003) Result:
> > hostbyte=0x00 driverbyte=0x08
> > [9273863.359909] sr 26:0:0:0: [sr1] tag#1 Sense Key : 0x2 [current]
> > [9273863.359974] sr 26:0:0:0: [sr1] tag#1 ASC=0x8 ASCQ=0x0
> > [9273863.360036] sr 26:0:0:0: [sr1] tag#1 CDB: opcode=0x28 28 00 00 22 f6
> > 96 00 00 80 00
> > [9273863.360116] blk_update_request: 13 callbacks suppressed
> > [9273863.360177] blk_update_request: I/O error, dev sr1, sector 9165400
> > [9273875.864648] sr 26:0:0:0: [sr1] tag#1 UNKNOWN(0x2003) Result:
> > hostbyte=0x00 driverbyte=0x08
> > [9273875.864738] sr 26:0:0:0: [sr1] tag#1 Sense Key : 0x2 [current]
> > [9273875.864801] sr 26:0:0:0: [sr1] tag#1 ASC=0x8 ASCQ=0x0
> > [9273875.864890] sr 26:0:0:0: [sr1] tag#1 CDB: opcode=0x28 28 00 00 22 f7
> > 16 00 00 80 00
> > [9273875.864971] blk_update_request: I/O error, dev sr1, sector 9165912
> >
> > To cause this, I mounted the dvd as seen in the first line and ran this
> > command: find /cdrom2 -type f | xargs -tn1 cat > /dev/null
> > I did some various tests. Each test was done after umount and mount to
> > clear the cache.
> > cat > /dev/null causes the message.
> > dd if= of=/dev/null bs=2048 doesn't
> > using bs=4096 doesn't
> > using bs=64k doesn't
> > using bs=128k does
> > cat uses a blocksize of 128k.
> >
> > The following was done without being mounted.
> > ddrescue -f -f /dev/sr1 /dev/null
> > doesn't cause the message
> > dd if=/dev/sr1 of=/dev/null bs=128k
> > doesn't cause the message
> > using bs=256k causes the message once:
> > [9275916.857409] sr 27:0:0:0: [sr1] tag#0 UNKNOWN(0x2003) Result:
> > hostbyte=0x00 driverbyte=0x08
> > [9275916.857482] sr 27:0:0:0: [sr1] tag#0 Sense Key : 0x2 [current]
> > [9275916.857520] sr 27:0:0:0: [sr1] tag#0 ASC=0x8 ASCQ=0x0
> > [9275916.857556] sr 27:0:0:0: [sr1] tag#0 CDB: opcode=0x28 28 00 00 00 00
> > 00 00 00 80 00
> > [9275916.857614] blk_update_request: I/O error, dev sr1, sector 0
> >
> > If I access the disc from the target natively either by mounting and
> > accessing files or working with the device directly (ie dd) no errors are
> > logged on the target.
>
> OK, thanks for your test.
>
> Could you test the following patch and see if there is still the failure
> message?
>
> diff --git a/drivers/target/target_core_pscsi.c
> b/drivers/target/target_core_pscsi.c
> index 0d99b242e82e..6137287b52fb 100644
> --- a/drivers/target/target_core_pscsi.c
> +++ b/drivers/target/target_core_pscsi.c
> @@ -913,9 +913,11 @@ pscsi_map_sg(struct se_cmd *cmd, struct scatterlist
> *sgl, u32 sgl_nents,
>
> rc = bio_add_pc_page(pdv->pdv_sd->request_queue,
> bio, page, bytes, off);
> + if (rc != bytes)
> + goto fail;
> pr_debug("PSCSI: bio->bi_vcnt: %d nr_vecs: %d\n",
> bio_segments(bio), nr_vecs);
> - if (rc != bytes) {
> + if (/*rc != bytes*/0) {
> pr_debug("PSCSI: Reached bio->bi_vcnt max:"
> " %d i: %d bio: %p, allocating another"
> " bio\n", bio->bi_vcnt, i, bio);
Target doesn't crash but the errors on the initiator are still there.
Seems that if I do large transfers, I see this in the initiator's logs.
With the previous patch, I burned 3 dvds at the same time, compared the
files to the originals and I have a script that catalogs the files. The
files consist of debian packages and source files. The 3 operations did not
show any errors in the kernel log on either end.
I did this test:
initiator: dd if=/dev/sr1 bs=512k count=1024 | md5sum
target:dd if=/dev/sr0 bs=512k count=1024 | md5sum
Result: the same. It's OK even with the i/o errors shown on the initiator.
The above patch was added on top of the one you gave me before, but I don't
believe that that would be an issue.
... Now if someone could help me with a kvm virtualization problem I'm
having with 4.16 that wasn't there with 4.15...
--
Microsoft has beaten Volkswagen's world record. Volkswagen only created 22
million bugs.
Re: [PATCH] kernel/module: silence a gcc warning
Hi Mathieu, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.16 next-20180412] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Mathieu-Malaterre/kernel-module-silence-a-gcc-warning/20180413-044304 config: x86_64-randconfig-u0-04130525 (attached as .config) compiler: gcc-5 (Debian 5.5.0-3) 5.4.1 20171010 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All error/warnings (new ones prefixed by >>): In file included from drivers/net/ethernet/cavium/common/cavium_ptp.c:7:0: >> include/linux/module.h:794:13: warning: 'struct tracepoint' declared inside >> parameter list struct tracepoint * const *tp); ^ >> include/linux/module.h:794:13: warning: its scope is only this definition or >> declaration, which is probably not what you want Cyclomatic Complexity 1 include/linux/err.h:ERR_PTR Cyclomatic Complexity 1 include/linux/err.h:PTR_ERR Cyclomatic Complexity 1 include/linux/err.h:IS_ERR Cyclomatic Complexity 3 include/linux/err.h:IS_ERR_OR_NULL Cyclomatic Complexity 1 include/linux/math64.h:div_u64_rem Cyclomatic Complexity 1 include/linux/math64.h:div_u64 Cyclomatic Complexity 1 include/linux/spinlock.h:spinlock_check Cyclomatic Complexity 1 include/linux/spinlock.h:spin_unlock_irqrestore Cyclomatic Complexity 1 include/linux/time64.h:timespec64_to_ns Cyclomatic Complexity 1 include/linux/timekeeping.h:ktime_get_real Cyclomatic Complexity 1 arch/x86/include/asm/io.h:readq Cyclomatic Complexity 1 arch/x86/include/asm/io.h:writeq Cyclomatic Complexity 1 include/linux/kobject.h:kobject_name Cyclomatic Complexity 1 include/linux/device.h:devm_kzalloc Cyclomatic Complexity 2 include/linux/device.h:dev_name Cyclomatic Complexity 1 include/linux/device.h:dev_get_drvdata Cyclomatic Complexity 1 include/linux/device.h:dev_set_drvdata Cyclomatic Complexity 1 include/linux/timecounter.h:timecounter_adjtime Cyclomatic Complexity 1 include/linux/pci.h:pci_get_drvdata Cyclomatic Complexity 1 include/linux/pci.h:pci_set_drvdata Cyclomatic Complexity 1 include/linux/pci.h:pci_name Cyclomatic Complexity 1 include/linux/ptp_clock_kernel.h:ptp_clock_register Cyclomatic Complexity 1 include/linux/ptp_clock_kernel.h:ptp_clock_unregister Cyclomatic Complexity 1 drivers/net/ethernet/cavium/common/cavium_ptp.c:cavium_ptp_enable Cyclomatic Complexity 2 drivers/net/ethernet/cavium/common/cavium_ptp.c:cavium_ptp_remove Cyclomatic Complexity 4 drivers/net/ethernet/cavium/common/cavium_ptp.c:cavium_ptp_get Cyclomatic Complexity 2 drivers/net/ethernet/cavium/common/cavium_ptp.c:cavium_ptp_put Cyclomatic Complexity 1 drivers/net/ethernet/cavium/common/cavium_ptp.c:cavium_ptp_driver_init Cyclomatic Complexity 2 drivers/net/ethernet/cavium/common/cavium_ptp.c:cavium_ptp_settime Cyclomatic Complexity 2 drivers/net/ethernet/cavium/common/cavium_ptp.c:cavium_ptp_gettime Cyclomatic Complexity 2 drivers/net/ethernet/cavium/common/cavium_ptp.c:cavium_ptp_adjtime Cyclomatic Complexity 4 drivers/net/ethernet/cavium/common/cavium_ptp.c:cavium_ptp_adjfine Cyclomatic Complexity 2 drivers/net/ethernet/cavium/common/cavium_ptp.c:cavium_ptp_cc_read Cyclomatic Complexity 3 drivers/net/ethernet/cavium/common/cavium_ptp.c:ptp_cavium_clock_get Cyclomatic Complexity 6 drivers/net/ethernet/cavium/common/cavium_ptp.c:cavium_ptp_probe Cyclomatic Complexity 1 drivers/net/ethernet/cavium/common/cavium_ptp.c:cavium_ptp_driver_exit -- In file included from drivers/ntb/ntb.c:58:0: >> include/linux/module.h:794:13: warning: 'struct tracepoint' declared inside >> parameter list struct tracepoint * const *tp); ^ >> include/linux/module.h:794:13: warning: its scope is only this definition or >> declaration, which is probably not what you want Cyclomatic Complexity 1 include/linux/spinlock.h:spinlock_check Cyclomatic Complexity 1 include/linux/spinlock.h:spin_unlock_irqrestore Cyclomatic Complexity 1 include/linux/completion.h:__init_completion Cyclomatic Complexity 1 include/linux/kobject.h:kobject_name Cyclomatic Complexity 2 include/linux/device.h:dev_name Cyclomatic Complexity 3 include/linux/ntb.h:ntb_client_ops_is_valid Cyclomatic Complexity 1 include/linux/ntb.h:ntb_ctx_ops_is_valid Cyclomatic Complexity 29 include/linux/ntb.h:ntb_dev_ops_is_valid Cyclomatic Complexity 1 include/linux/pci.h:pci_name Cyclomatic Complexity 3 drivers/ntb/ntb.c:ntb_set_ctx Cyclomatic Complexity 1 drivers/ntb/ntb.c:ntb_clear_ctx Cyclomatic Complexity 3 drivers/ntb/ntb.c:ntb_link_event Cyclomatic Complexity 3 drivers/ntb/ntb.c:ntb_db_event Cyclomatic Complexit
Re: [PATCH v2 1/6] x86/hyper-v: move struct hv_flush_pcpu{,ex} definitions to common header
Hi Vitaly,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on kvm/linux-next]
[also build test WARNING on v4.16 next-20180412]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Vitaly-Kuznetsov/KVM-x86-hyperv-PV-TLB-flush-for-Windows-guests/20180413-025205
base: https://git.kernel.org/pub/scm/virt/kvm/kvm.git linux-next
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> arch/x86/hyperv/mmu.c:107:22: sparse: incorrect type in initializer
>> (different address spaces) @@expected void const [noderef]
>> *__vpp_verify @@got struct hv_void const [noderef]
>> *__vpp_verify @@
arch/x86/hyperv/mmu.c:107:22:expected void const [noderef]
*__vpp_verify
arch/x86/hyperv/mmu.c:107:22:got struct hv_tlb_flush [noderef]
**
>> arch/x86/hyperv/mmu.c:107:20: sparse: incorrect type in assignment
>> (different address spaces) @@expected struct hv_tlb_flush **flush_pcpu
>> @@got struct hv_tlb_flustruct hv_tlb_flush **flush_pcpu @@
arch/x86/hyperv/mmu.c:107:20:expected struct hv_tlb_flush **flush_pcpu
arch/x86/hyperv/mmu.c:107:20:got struct hv_tlb_flush [noderef]
**
>> arch/x86/hyperv/mmu.c:194:22: sparse: incorrect type in initializer
>> (different address spaces) @@expected void const [noderef]
>> *__vpp_verify @@got struct hv_tlbvoid const [noderef]
>> *__vpp_verify @@
arch/x86/hyperv/mmu.c:194:22:expected void const [noderef]
*__vpp_verify
arch/x86/hyperv/mmu.c:194:22:got struct hv_tlb_flush_ex [noderef]
**
>> arch/x86/hyperv/mmu.c:194:20: sparse: incorrect type in assignment
>> (different address spaces) @@expected struct hv_tlb_flush_ex
>> **flush_pcpu @@got struct hv_tlb_flustruct hv_tlb_flush_ex **flush_pcpu
>> @@
arch/x86/hyperv/mmu.c:194:20:expected struct hv_tlb_flush_ex **flush_pcpu
arch/x86/hyperv/mmu.c:194:20:got struct hv_tlb_flush_ex [noderef]
**
>> arch/x86/hyperv/mmu.c:286:28: sparse: incorrect type in assignment
>> (different address spaces) @@expected struct hv_tlb_flush [noderef]
>> **static [toplevel] pcpu_flush @@got h [noderef] **static
>> [toplevel] pcpu_flush @@
arch/x86/hyperv/mmu.c:286:28:expected struct hv_tlb_flush [noderef]
**static [toplevel] pcpu_flush
arch/x86/hyperv/mmu.c:286:28:got struct hv_tlb_flush *[noderef]
*
>> arch/x86/hyperv/mmu.c:288:31: sparse: incorrect type in assignment
>> (different address spaces) @@expected struct hv_tlb_flush_ex [noderef]
>> **static [toplevel] pcpu_flush_ex @@got h_ex [noderef]
>> **static [toplevel] pcpu_flush_ex @@
arch/x86/hyperv/mmu.c:288:31:expected struct hv_tlb_flush_ex [noderef]
**static [toplevel] pcpu_flush_ex
arch/x86/hyperv/mmu.c:288:31:got struct hv_tlb_flush_ex *[noderef]
*
vim +107 arch/x86/hyperv/mmu.c
628f54cc6 Vitaly Kuznetsov 2017-08-02 87
2ffd9e33c Vitaly Kuznetsov 2017-08-02 88 static void
hyperv_flush_tlb_others(const struct cpumask *cpus,
2ffd9e33c Vitaly Kuznetsov 2017-08-02 89
const struct flush_tlb_info *info)
2ffd9e33c Vitaly Kuznetsov 2017-08-02 90 {
2ffd9e33c Vitaly Kuznetsov 2017-08-02 91int cpu, vcpu, gva_n,
max_gvas;
84d437db6 Vitaly Kuznetsov 2018-04-11 92struct hv_tlb_flush
**flush_pcpu;
84d437db6 Vitaly Kuznetsov 2018-04-11 93struct hv_tlb_flush
*flush;
2ffd9e33c Vitaly Kuznetsov 2017-08-02 94u64 status = U64_MAX;
2ffd9e33c Vitaly Kuznetsov 2017-08-02 95unsigned long flags;
2ffd9e33c Vitaly Kuznetsov 2017-08-02 96
773b79f7a Vitaly Kuznetsov 2017-08-02 97
trace_hyperv_mmu_flush_tlb_others(cpus, info);
773b79f7a Vitaly Kuznetsov 2017-08-02 98
2ffd9e33c Vitaly Kuznetsov 2017-08-02 99if (!pcpu_flush ||
!hv_hypercall_pg)
2ffd9e33c Vitaly Kuznetsov 2017-08-02 100goto do_native;
2ffd9e33c Vitaly Kuznetsov 2017-08-02 101
2ffd9e33c Vitaly Kuznetsov 2017-08-02 102if (cpumask_empty(cpus))
2ffd9e33c Vitaly Kuznetsov 2017-08-02 103return;
2ffd9e33c Vitaly Kuznetsov 2017-08-02 104
2ffd9e33c Vitaly Kuznetsov 2017-08-02 105local_irq_save(flags);
2ffd9e33c Vitaly Kuznetsov 2017-08-02 106
60d73a7c9 Vitaly Kuznetsov 2017-10-05 @107flush_pcpu =
this_cpu_ptr(pcpu_flush);
60d73a7c9 Vitaly Kuznetsov 2017-10-05 108
60d73a7c9 Vitaly Kuznetsov 2017-10-05 109if
(unlikely(!*flush_pcpu))
60d73a7c9 Vitaly Kuznetsov 2017-10-05 110*fl
