Re: [PATCH 6/7] md/raid10, LLVM: get rid of variable length array

[Fengguang Wu]

Hi Dmitry,

On Fri, Mar 17, 2017 at 08:05:16PM +0100, Dmitry Vyukov wrote:

On Fri, Mar 17, 2017 at 7:57 PM, Borislav Petkov  wrote:

On Fri, Mar 17, 2017 at 07:47:33PM +0100, Dmitry Vyukov wrote:

This problem is more general and is not specific to clang. It equally
applies to different versions of gcc, different arches and different
configs (namely, anything else than what a developer used for
testing).


I guess. We do carry a bunch of gcc workarounds along with the cc-*
macros in scripts/Kbuild.include.


A known, reasonably well working solution to this problem is
a system of try bots that test patches before commit with different
compilers/configs/archs. We already have such system in the form of
0-day bots. It would be useful to extend it with clang as soon as
kernel builds.


Has someone actually already talked to Fengguang about it?


+Fengguang


I've actually tried clang long time ago. It quickly fails the build
for vanilla kernel. So it really depends on when the various clang
build fix patches can be accepted into mainline kernel.

Thanks,
Fengguang

Re: [kbuild-all] [PATCH] crypto: af_alg - add async support to algif_aead

[Fengguang Wu]

On Wed, Jan 27, 2016 at 02:41:36PM -0800, Tadeusz Struk wrote:
> On 01/27/2016 02:29 PM, kbuild test robot wrote:
> > Hi Tadeusz,
> > 
> > [auto build test ERROR on cryptodev/master]
> > [also build test ERROR on v4.5-rc1 next-20160127]
> > [if your patch is applied to the wrong git tree, please drop us a note to 
> > help improving the system]
> > 
> > url:
> > https://github.com/0day-ci/linux/commits/Tadeusz-Struk/crypto-af_alg-add-async-support-to-algif_aead/20160128-061818
> > base:   
> > https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git 
> > master
> > config: x86_64-randconfig-x011-01270835 (attached as .config)
> > reproduce:
> > # save the attached .config to linux build tree
> > make ARCH=x86_64 
> > 
> > All error/warnings (new ones prefixed by >>):
> > 
> >crypto/algif_aead.c: In function 'aead_async_cb':
> >>> crypto/algif_aead.c:386:29: error: implicit declaration of function 
> >>> 'aead_request_cast' [-Werror=implicit-function-declaration]
> >  struct aead_request *req = aead_request_cast(_req);
> > ^
> >>> crypto/algif_aead.c:386:29: warning: initialization makes pointer from 
> >>> integer without a cast [-Wint-conversion]
> >cc1: some warnings being treated as errors
> > 
> > vim +/aead_request_cast +386 crypto/algif_aead.c
> > 
> >380  static void aead_async_cb(struct crypto_async_request *_req, 
> > int err)
> >381  {
> >382  struct sock *sk = _req->data;
> >383  struct alg_sock *ask = alg_sk(sk);
> >384  struct aead_ctx *ctx = ask->private;
> >385  struct crypto_aead *tfm = 
> > crypto_aead_reqtfm(>aead_req);
> >  > 386  struct aead_request *req = aead_request_cast(_req);
> >387  struct aead_async_req *areq = GET_ASYM_REQ(req, tfm);
> >388  struct scatterlist *sg = areq->tsgl;
> >389  struct aead_async_rsgl *rsgl;
> > 
> 
> Thanks for the report.
> It has dependency on this one https://patchwork.kernel.org/patch/8144731/
> which has been sent one minute earlier.
> I do not want to squash them into one patch, because they are not really 
> related.
> Herbert, how should this be handled?

Sorry for the noise -- you may either ignore the warning or send
dependent patches in one same patch series in future.

Thanks,
Fengguang
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [kbuild-all] [cryptodev:master 119/123] include/linux/pci.h:389:12: error: 'struct pci_dev' has no member named 'physfn'

[Fengguang Wu]

On Mon, Aug 10, 2015 at 12:06:56PM -0700, Tadeusz Struk wrote:
 On 08/10/2015 11:47 AM, kbuild test robot wrote:
  tree:   
  git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git 
  master
  head:   9cfaf082b8775e9f99fa5f2e8b2ae0ca8baff785
  commit: dd0f368398ea100e34259bf812bc482e15c81991 [119/123] crypto: qat - 
  Add qat dh895xcc VF driver
  config: sh-allyesconfig (attached as .config)
  reproduce:
wget 
  https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
   -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout dd0f368398ea100e34259bf812bc482e15c81991
# save the attached .config to linux build tree
make.cross ARCH=sh 
  
  All error/warnings (new ones prefixed by ):
  
 In file included from drivers/media/common/b2c2/flexcop-common.h:10:0,
  from drivers/media/usb/b2c2/flexcop-usb.c:8:
 include/linux/pci.h: In function 'pci_physfn':
   include/linux/pci.h:389:12: error: 'struct pci_dev' has no member 
   named 'physfn'
  vim +389 include/linux/pci.h
  
  ^1da177e Linus Torvalds 2005-04-16  383  };
  ^1da177e Linus Torvalds 2005-04-16  384  
  dda56549 Yinghai2010-04-09  385  static inline struct pci_dev 
  *pci_physfn(struct pci_dev *dev)
  dda56549 Yinghai2010-04-09  386  {
  dda56549 Yinghai2010-04-09  387  #ifdef CONFIG_PCI_IOV
  dda56549 Yinghai2010-04-09  388 if (dev-is_virtfn)
  dda56549 Yinghai2010-04-09 @389 dev = dev-physfn;
  dda56549 Yinghai2010-04-09  390  #endif
  dda56549 Yinghai2010-04-09  391 return dev;
  dda56549 Yinghai2010-04-09  392  }
 
 Sorry, but what commit dd0f368398ea100e34259bf812bc482e15c81991 crypto: qat - 
 Add qat dh895xcc VF driver
 has to do with drivers/media/usb/b2c2/flexcop-usb.c?

That looks a bad bisect. Sorry for the noise! Bad bisects are rare but
possible because we used optimizations like partial build to speed it up.

Thanks,
Fengguang
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH cryptodev] crypto: echainiv_read_iv() can be static

[Fengguang Wu]

Signed-off-by: Fengguang Wu fengguang...@intel.com
---
 echainiv.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/crypto/echainiv.c b/crypto/echainiv.c
index e5a9878..d0e325d0 100644
--- a/crypto/echainiv.c
+++ b/crypto/echainiv.c
@@ -67,7 +67,7 @@ static int echainiv_setauthsize(struct crypto_aead *tfm,
 }
 
 /* We don't care if we get preempted and read/write IVs from the next CPU. */
-void echainiv_read_iv(u8 *dst, unsigned size)
+static void echainiv_read_iv(u8 *dst, unsigned size)
 {
u32 *a = (u32 *)dst;
u32 __percpu *b = echainiv_iv;
@@ -78,7 +78,7 @@ void echainiv_read_iv(u8 *dst, unsigned size)
}
 }
 
-void echainiv_write_iv(const u8 *src, unsigned size)
+static void echainiv_write_iv(const u8 *src, unsigned size)
 {
const u32 *a = (const u32 *)src;
u32 __percpu *b = echainiv_iv;
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Potential NULL pointer deference in drbg_ctr_df

[Fengguang Wu]

On Sat, Jul 05, 2014 at 02:00:15AM +0200, Stephan Mueller wrote:
 Am Freitag, 4. Juli 2014, 13:50:03 schrieb Dan Carpenter:
 
 Hi Dan,
 
  On Wed, Jun 25, 2014 at 05:06:46PM +0800, Herbert Xu wrote:
   On Sat, Jun 21, 2014 at 02:26:29PM +0200, Stephan Mueller wrote:
The handling of additional input data / personalization string data may
be subject to a NULL pointer deference for the CTR DRBG. The
caller-provided data may be NULL which must be caught by the DRBG.

Reported-by: kbuild test robot fengguang...@intel.com
  
  Oh, huh.  This bug was actually reported by me but I forgot to change
  the from header and apparently my smtp server allows me to send emails
  as if I work for Intel.  :P
  
  Fengguang is much nicer than I am.  :P
 
 Too late, your colleague's name is now in the patches ;-)

Thank you nice guys! :P

Thanks,
Fengguang
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [crypto] BUG: unable to handle kernel paging request at ffff88000bb88000

[Fengguang Wu]

Hi Stephan,

On Sun, Jun 29, 2014 at 09:45:48PM +0200, Stephan Mueller wrote:
 Am Sonntag, 29. Juni 2014, 22:52:46 schrieb Fengguang Wu:
 
 Hi Fengguang,
 
  Greetings,
  
  0day kernel testing robot got the below dmesg and the first bad commit is
 
 May I ask whether there is anything special in your kernel config?

It's an x86_64 randconfig. You may find it in the attachment of the
original report email.

 This very bug should have been triggered already in all previous code levels! 
 I am seriously wondering why this bug was not triggered before -- does kalloc 
 somehow allocates more memory than you requested? And only your specific 
 kernel config made kalloc to allocate the exact amount of memory that was 
 requested?

Yeah the bug may have been triggered in other places. If you see
anything valuable from this bisect result, it would be great. Judging
from the comparison of 64d1cdfbe2 and its parent commit 3332ee2a17,
it's pretty reproducible, so easy to verify the possible fixes.

++++
|| 
3332ee2a17 | 64d1cdfbe2 |
++++
| boot_successes | 
81 | 3  |
| boot_failures  | 
0  | 23 |
| BUG:unable_to_handle_kernel_paging_request | 
0  | 20 |
| Oops   | 
0  | 19 |
| RIP:kzfree | 
0  | 15 |
| WARNING:CPU:PID:at_kernel/rcu/tree.c:rcu_do_batch()| 
0  | 9  |
| backtrace:cryptomgr_test   | 
0  | 18 |
| backtrace:cpu_startup_entry| 
0  | 3  |
| kernel_BUG_at_include/linux/mm.h   | 
0  | 1  |
...

Thanks,
Fengguang
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: initcall calibrate_xor_blocks returned with preemption imbalance

[Fengguang Wu]

Dear Boaz,

On Thu, Oct 10, 2013 at 01:41:23PM -0700, Boaz Harrosh wrote:
 On 10/10/2013 02:02 AM, Fengguang Wu wrote:
  Greetings,
  
  I got the below dmesg and the first bad commit is
  
 
 Dear Wu
 
 This 20545536cd8ea949c61527b6395ec8c0d2c237b1 is from my tree at 
 linux-open-osd.org
 How did you happen to find it and run with it at all?
 
 I have never pushed it to any mailing list or blessed it for release.
 Yes it has a known problem that I never bothered to fix. I carry
 it in my own development trees so I can run xor.ko on UML.
 
 If it has leaked to any upstream trees, I'm so sorry tell me where
 you found it and I'll have it removed.

I'm running kernel build/boot/performance tests for *all* the public
kernel git trees I'm aware of. If this is not necessary for your tree
or some of the branches, sorry I can remove them from the test pool.

 I can see below:
   Merge 'open-osd/exofs_ioctl' into devel-hourly-2013101007
 
 What is devel-hourly and what does exofs_ioctl branch useful for.
 exofs_ioctl is for NFS-Ganesha pnfs support. It is not good for
 any other purpose. 

devel-hourly-* are the internal merge-and-test branches. To be frank I
don't care what the merged branches are for: the system simply tests
all branches that can be merged.

 If you are developing NFS-Ganesha pnfs code feel free to remove
 this patch, again it is so I can run exofs on UML which uses
 xor.ko. If you use VMs or HW you do not have this problem.

I run lots of kernel boot tests in qemu/kvm for now. However may also
consider UML if it's simple, reliable and efficient.

Thanks,
Fengguang

  commit 20545536cd8ea949c61527b6395ec8c0d2c237b1
  Author: Boaz Harrosh bharr...@panasas.com
  Date:   Thu Jul 19 15:22:37 2012 +0300
  
  RFC: do_xor_speed Broken on UML do to jiffies
  
  Remember that hang I reported a while back on UML. Well
  I'm at it again, and it still hangs and I found why.
  
  I have dprinted jiffies and it never advances during the
  loop at do_xor_speed. There for it is stuck in an endless
  loop. I have also dprinted current_kernel_time() and it
  returns the same constant value as well.
  
  Note that it does usually work on UML, only during
  the modprobe of xor.ko while that test is running. It looks
  like some lucking is preventing the clock from ticking.
  
  However ktime_get_ts does work for me so I changed the code
  as below, so I can work. See how I put several safety
  guards, to never get hangs again.
  And I think my time based approach is more accurate then
  previous system.
  
  UML guys please investigate the jiffies issue? what is
  xor.ko not doing right?
  
  Signed-off-by: Boaz Harrosh bharr...@panasas.com
  
  [0.232004]generic_sse:  6816.333 MB/sec
  [0.233534] xor: using function: prefetch64-sse (9178.666 MB/sec)
  [0.235445] [ cut here ]
  [0.236010] WARNING: CPU: 0 PID: 1 at init/main.c:701 
  do_one_initcall+0x128/0x138()
  [0.240041] initcall calibrate_xor_blocks+0x0/0x144 returned with 
  preemption imbalance 
  [0.242872] Modules linked in:
  [0.244006] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
  3.12.0-rc4-wl-02197-g3d5587e #119
  [0.246837] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
  [0.248004]   88000e1e5e00 81a3a6bf 
  88000e1e5e48
  [0.252003]  88000e1e5e38 810c53d5 81000315 
  8256ff16
  [0.255243]    88000e1e5fd8 
  88000e1e5e98
  [0.258537] Call Trace:
  [0.260010]  [81a3a6bf] dump_stack+0x54/0x74
  [0.261730]  [810c53d5] warn_slowpath_common+0x7f/0x98
  [0.263623]  [81000315] ? do_one_initcall+0x128/0x138
  [0.264006]  [8256ff16] ? do_xor_speed+0xe2/0xe2
  [0.265785]  [810c543a] warn_slowpath_fmt+0x4c/0x4e
  [0.268007]  [811767d9] ? free_pages+0x45/0x47
  [0.269751]  [8256ff16] ? do_xor_speed+0xe2/0xe2
  [0.272006]  [81000315] do_one_initcall+0x128/0x138
  [0.273843]  [82532ed3] kernel_init_freeable+0x159/0x1da
  [0.276005]  [8253274d] ? do_early_param+0x88/0x88
  [0.277835]  [81a2a057] ? rest_init+0xdb/0xdb
  [0.280006]  [81a2a065] kernel_init+0xe/0xdb
  [0.281718]  [81a4d97c] ret_from_fork+0x7c/0xb0
  [0.283485]  [81a2a057] ? rest_init+0xdb/0xdb
  [0.284021] ---[ end trace 3592511960ba24aa ]---
  [0.285636] atomic64 test passed for x86-64 platform with CX8 and with 
  SSE
  
  git bisect start 3d5587ec7222eebd6d2fa2d4b245ef837a8f36fa 
  15c03dd4859ab16f9212238f29dd315654aa94f6 --
  git bisect good bd1bc39506ad6ce236bf932757d6e3a81b3e3d55  # 09:41 20+   
 0  Merge 'regmap/topic/core' into devel-hourly-2013101007
  git bisect good f0a6d5852cc8b4e9e518c0426580f0589327e438  # 10:56 20+   
 0

ERROR: __crc32c_le [crypto/crc32c.ko] undefined!

[Fengguang Wu]

Hi Darrick,

I'm not sure if it's a good bisect. Anyway here is a long standing
error and it'd be good to scrub it away.

tree:   git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux master
head:   53b680924800ad6c67f7e54ca7d5bdc4859d2318
commit: 6a0962b22eccc70b8421014022c07efcf194a95e crypto: crc32c should use 
library implementation
date:   1 year ago
config: x86_64-randconfig-x00-0326 (attached as .config)

All error/warnings:

   WARNING: could not open drivers/mtd/ubi/attach.c: No such file or directory
   WARNING: could not open drivers/usb/chipidea/ci13xxx_pci.c: No such file or 
directory
   ERROR: crc32_le [lib/xz/xz_dec_test.ko] undefined!
   ERROR: crc32_le [lib/xz/xz_dec.ko] undefined!
   ERROR: crc32_le [drivers/mtd/ubi/ubi.ko] undefined!
 ERROR: __crc32c_le [crypto/crc32c.ko] undefined!
   ERROR: mcount [crypto/crc32c.ko] undefined!
   ERROR: crc32_le [crypto/crc32.ko] undefined!

---
0-DAY kernel build testing backend  Open Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation

#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 3.3.0 Kernel Configuration
#
CONFIG_64BIT=y
# CONFIG_X86_32 is not set
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT=elf64-x86-64
CONFIG_ARCH_DEFCONFIG=arch/x86/configs/x86_64_defconfig
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_GPIO=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_ARCH_HAS_CPU_AUTOPROBE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx 
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 
-fcall-saved-r11
# CONFIG_KTIME_SCALAR is not set
CONFIG_ARCH_CPU_PROBE_RELEASE=y
CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config
CONFIG_HAVE_IRQ_WORK=y
CONFIG_IRQ_WORK=y

#
# General setup
#
# CONFIG_EXPERIMENTAL is not set
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=
CONFIG_LOCALVERSION=
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
CONFIG_KERNEL_LZO=y
CONFIG_DEFAULT_HOSTNAME=(none)
# CONFIG_SYSVIPC is not set
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_FHANDLE=y
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_HAVE_SPARSE_IRQ=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_PREEMPT_RCU is not set
CONFIG_RCU_FANOUT=64
CONFIG_RCU_FANOUT_EXACT=y
# CONFIG_RCU_FAST_NO_HZ is not set
CONFIG_TREE_RCU_TRACE=y
CONFIG_IKCONFIG=y
# CONFIG_IKCONFIG_PROC is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_CGROUPS=y
CONFIG_CGROUP_DEBUG=y
CONFIG_CGROUP_FREEZER=y
# CONFIG_CGROUP_DEVICE is not set
# CONFIG_CPUSETS is not set
# CONFIG_CGROUP_CPUACCT is not set
# CONFIG_RESOURCE_COUNTERS is not set
CONFIG_CGROUP_PERF=y
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_CHECKPOINT_RESTORE=y
# CONFIG_NAMESPACES is not set
CONFIG_SCHED_AUTOGROUP=y
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=
CONFIG_RD_GZIP=y
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_EXPERT=y
# CONFIG_UID16 is not set
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
# CONFIG_TIMERFD is not set
CONFIG_EVENTFD=y
# CONFIG_SHMEM is not set
# CONFIG_AIO is not set
CONFIG_EMBEDDED=y

Re: [PATCH UPDATED 6/6] workqueue: reimplement WQ_HIGHPRI using a separate worker_pool

[Fengguang Wu]

 v2: nr_running indexing bug in get_pool_nr_running() fixed.
 
 Signed-off-by: Tejun Heo t...@kernel.org
 Reported-by: Josh Hunt joshhun...@gmail.com
 LKML-Reference: 
 CAKA=qzahqwz8eqplnfjxno2fx-tgaojmpvxgbfjv6djeqao...@mail.gmail.com
 Cc: Tony Luck tony.l...@intel.com
 Cc: Fengguang Wu fengguang...@intel.com
 ---
 git branch updated accordingly.  Thanks.

It works now, thank you very much!

Tested-by: Fengguang Wu fengguang...@intel.com

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html