Re: [PATCH v2 2/3] CMA: aggressively allocate the pages on cma reserved memory when not used
I found 2 problems at my platform.
1st is occured when I set CMA size 528MB and total memory is 960MB.
I print some values in adjust_managed_cma_page_count(),
the total value becomes 105439 and cma value 131072.
Finally movable value becomes negative value.
The total value 105439 means 411MB.
Is the zone->managed_pages value pages amount except the CMA?
I think zone->managed_pages value is including CMA size but it's value is
strange.
2nd is a kernel panic at __netdev_alloc_skb().
I'm not sure it is caused by the CMA.
I'm checking it again and going to send you another report with detail
call-stacks.
2014-05-30 오후 11:23, Joonsoo Kim 쓴 글:
2014-05-30 16:53 GMT+09:00 Gioh Kim :
Joonsoo,
I'm attaching a patch for combination of __rmqueue and __rmqueue_cma.
I didn't test fully but my board is turned on and working well if no frequent
memory allocations.
I'm sorry to send not-tested code.
I just want to report this during your working hour ;-)
I'm testing this this evening and reporting next week.
Have a nice weekend!
Thanks Gioh. :)
-- 8<
-
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 7f97767..9ced736 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -964,7 +964,7 @@ static int fallbacks[MIGRATE_TYPES][4] = {
[MIGRATE_RECLAIMABLE] = { MIGRATE_UNMOVABLE, MIGRATE_MOVABLE,
MIGRATE_R
#ifdef CONFIG_CMA
[MIGRATE_MOVABLE] = { MIGRATE_CMA, MIGRATE_RECLAIMABLE,
MIGRATE_U
- [MIGRATE_CMA] = { MIGRATE_RESERVE }, /* Never used */
+ [MIGRATE_CMA] = { MIGRATE_MOVABLE, MIGRATE_RECLAIMABLE,
MIGRATE_U
I don't want to use __rmqueue_fallback() for CMA.
__rmqueue_fallback() takes big order page rather than small order page
in order to steal large amount of pages and continue to use them in
next allocation attempts.
We can use CMA pages on limited cases, so stealing some pages from
other migrate type
to CMA type isn't good idea to me.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] replace PAGECACHE_TAG_* definition with enumeration
We need number of pagecache tags in later patches, this patch prepares it.
Signed-off-by: Naoya Horiguchi
---
include/linux/fs.h | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git v3.15-rc7.orig/include/linux/fs.h v3.15-rc7/include/linux/fs.h
index 878031227c57..5b489df9d964 100644
--- v3.15-rc7.orig/include/linux/fs.h
+++ v3.15-rc7/include/linux/fs.h
@@ -447,9 +447,12 @@ struct block_device {
* Radix-tree tags, for tagging dirty and writeback pages within the pagecache
* radix trees
*/
-#define PAGECACHE_TAG_DIRTY0
-#define PAGECACHE_TAG_WRITEBACK1
-#define PAGECACHE_TAG_TOWRITE 2
+enum {
+ PAGECACHE_TAG_DIRTY,
+ PAGECACHE_TAG_WRITEBACK,
+ PAGECACHE_TAG_TOWRITE,
+ __NR_PAGECACHE_TAGS,
+};
int mapping_tagged(struct address_space *mapping, int tag);
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] mm: introduce fincore()
This patch provides a new system call fincore(2), which provides mincore()- like information, i.e. page residency of a given file. But unlike mincore(), fincore() can have a mode flag and it enables us to extract more detailed information about page cache like pfn and page flag. This kind of information is very helpful for example when applications want to know the file cache status to control IO on their own way. Detail about the data format being passed to userspace are explained in inline comment, but generally in long entry format, we can choose which information is extraced flexibly, so you don't have to waste memory by extracting unnecessary information. And with FINCORE_SKIP_HOLE flag, we can skip hole pages (not on memory,) which makes us avoid a flood of meaningless zero entries when calling on extremely large (but only few pages of it are loaded on memory) file. Basic testset is added in a next patch on tools/testing/selftests/fincore/. [1] http://thread.gmane.org/gmane.linux.kernel/1439212/focus=1441919 Signed-off-by: Naoya Horiguchi --- arch/x86/syscalls/syscall_64.tbl | 1 + include/linux/syscalls.h | 2 + mm/Makefile | 2 +- mm/fincore.c | 362 +++ 4 files changed, 366 insertions(+), 1 deletion(-) create mode 100644 mm/fincore.c diff --git v3.15-rc7.orig/arch/x86/syscalls/syscall_64.tbl v3.15-rc7/arch/x86/syscalls/syscall_64.tbl index 04376ac3d9ef..0a6b6dd77708 100644 --- v3.15-rc7.orig/arch/x86/syscalls/syscall_64.tbl +++ v3.15-rc7/arch/x86/syscalls/syscall_64.tbl @@ -323,6 +323,7 @@ 314common sched_setattr sys_sched_setattr 315common sched_getattr sys_sched_getattr 316common renameat2 sys_renameat2 +317common fincore sys_fincore # # x32-specific system call numbers start at 512 to avoid cache impact diff --git v3.15-rc7.orig/include/linux/syscalls.h v3.15-rc7/include/linux/syscalls.h index a4a0588c5397..d625ec9cb73d 100644 --- v3.15-rc7.orig/include/linux/syscalls.h +++ v3.15-rc7/include/linux/syscalls.h @@ -866,4 +866,6 @@ asmlinkage long sys_process_vm_writev(pid_t pid, asmlinkage long sys_kcmp(pid_t pid1, pid_t pid2, int type, unsigned long idx1, unsigned long idx2); asmlinkage long sys_finit_module(int fd, const char __user *uargs, int flags); +asmlinkage long sys_fincore(int fd, loff_t start, long nr_pages, + int mode, unsigned char __user *vec); #endif diff --git v3.15-rc7.orig/mm/Makefile v3.15-rc7/mm/Makefile index b484452dac57..55e1d13ddb76 100644 --- v3.15-rc7.orig/mm/Makefile +++ v3.15-rc7/mm/Makefile @@ -18,7 +18,7 @@ obj-y := filemap.o mempool.o oom_kill.o fadvise.o \ mm_init.o mmu_context.o percpu.o slab_common.o \ compaction.o balloon_compaction.o vmacache.o \ interval_tree.o list_lru.o workingset.o \ - iov_iter.o $(mmu-y) + iov_iter.o fincore.o $(mmu-y) obj-y += init-mm.o diff --git v3.15-rc7.orig/mm/fincore.c v3.15-rc7/mm/fincore.c new file mode 100644 index ..3fc3ef465471 --- /dev/null +++ v3.15-rc7/mm/fincore.c @@ -0,0 +1,362 @@ +/* + * fincore(2) system call + * + * Copyright (C) 2014 NEC Corporation, Naoya Horiguchi + */ + +#include +#include +#include +#include +#include +#include +#include + +/* + * You can control how the buffer in userspace is filled with this mode + * parameters: + * + * - FINCORE_BMAP: + * The page status is returned in a vector of bytes. + * The least significant bit of each byte is 1 if the referenced page + * is in memory, otherwise it is zero. + * + * - FINCORE_PFN: + * stores pfn, using 8 bytes. + * + * - FINCORE_PAGEFLAGS: + * stores page flags, using 8 bytes. See definition of KPF_* for details. + * + * - FINCORE_PAGECACHE_TAGS: + * stores pagecache tags, using 8 bytes. See definition of PAGECACHE_TAG_* + * for details. + * + * - FINCORE_SKIP_HOLE: if this flag is set, fincore() doesn't store any + * information about hole. Instead each records per page has the entry + * of page offset (using 8 bytes.) This mode is useful if we handle + * large file and only few pages are on memory for the file. + * + * FINCORE_BMAP shouldn't be used combined with any other flags, and returnd + * data in this mode is like this: + * + * page offset 0 1 2 3 4 + * +---+---+---+---+---+ + * | 1 | 0 | 0 | 1 | 1 | ... + * +---+---+---+---+---+ + * <-> + * 1 byte + * + * For FINCORE_PFN, page data is formatted like this: + * + * page offset0 1 2 3 4 + * +---+---+---+---+---+ + * | pfn | pfn | pfn | pfn | pfn | ... + * +---+---+---+---+---+
[PATCH 3/3] selftest: add test code for fincore()
This patch adds simple test programs for fincore(), which contains the
following testcase:
- test_unaligned_start_address
- test_unaligned_start_address_hugetlb
- test_invalid_mode
- test_smallfile_bytemap
- test_smallfile_pfn
- test_smallfile_multientry
- test_largefile_pfn
- test_largefile_pfn_offset
- test_largefile_pfn_overrun
- test_tmpfs_pfn
- test_hugetlb_pfn
- test_largefile_pfn_skiphole
- test_smallfile_pfn_skiphole
-
Signed-off-by: Naoya Horiguchi
---
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/fincore/Makefile | 31 ++
.../selftests/fincore/create_hugetlbfs_file.c | 49 +++
tools/testing/selftests/fincore/fincore.c | 153 +
tools/testing/selftests/fincore/run_fincoretests | 355 +
5 files changed, 589 insertions(+)
create mode 100644 tools/testing/selftests/fincore/Makefile
create mode 100644 tools/testing/selftests/fincore/create_hugetlbfs_file.c
create mode 100644 tools/testing/selftests/fincore/fincore.c
create mode 100644 tools/testing/selftests/fincore/run_fincoretests
diff --git v3.15-rc7.orig/tools/testing/selftests/Makefile
v3.15-rc7/tools/testing/selftests/Makefile
index 32487ed18354..820813f571fb 100644
--- v3.15-rc7.orig/tools/testing/selftests/Makefile
+++ v3.15-rc7/tools/testing/selftests/Makefile
@@ -10,6 +10,7 @@ TARGETS += timers
TARGETS += vm
TARGETS += powerpc
TARGETS += user
+TARGETS += fincore
all:
for TARGET in $(TARGETS); do \
diff --git v3.15-rc7.orig/tools/testing/selftests/fincore/Makefile
v3.15-rc7/tools/testing/selftests/fincore/Makefile
new file mode 100644
index ..ab4361c70da5
--- /dev/null
+++ v3.15-rc7/tools/testing/selftests/fincore/Makefile
@@ -0,0 +1,31 @@
+# Makefile for vm selftests
+
+uname_M := $(shell uname -m 2>/dev/null || echo not)
+ARCH ?= $(shell echo $(uname_M) | sed -e s/i.86/i386/)
+ifeq ($(ARCH),i386)
+ARCH := X86
+CFLAGS := -DCONFIG_X86_32 -D__i386__
+endif
+ifeq ($(ARCH),x86_64)
+ARCH := X86
+CFLAGS := -DCONFIG_X86_64 -D__x86_64__
+endif
+
+CC = $(CROSS_COMPILE)gcc
+CFLAGS = -Wall
+CFLAGS += -I../../../../arch/x86/include/generated/
+CFLAGS += -I../../../../include/
+CFLAGS += -I../../../../usr/include/
+CFLAGS += -I../../../../arch/x86/include/
+
+BINARIES = fincore create_hugetlbfs_file
+
+all: $(BINARIES)
+%: %.c
+ $(CC) $(CFLAGS) -o $@ $^
+
+run_tests: all
+ @/bin/sh ./run_fincoretests || (echo "fincoretests: [FAIL]"; exit 1)
+
+clean:
+ $(RM) $(BINARIES)
diff --git
v3.15-rc7.orig/tools/testing/selftests/fincore/create_hugetlbfs_file.c
v3.15-rc7/tools/testing/selftests/fincore/create_hugetlbfs_file.c
new file mode 100644
index ..a46ccf0af5f2
--- /dev/null
+++ v3.15-rc7/tools/testing/selftests/fincore/create_hugetlbfs_file.c
@@ -0,0 +1,49 @@
+#define _GNU_SOURCE 1
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define err(x) (perror(x), exit(1))
+
+unsigned long default_hugepage_size(void)
+{
+ unsigned long hps = 0;
+ char *line = NULL;
+ size_t linelen = 0;
+ FILE *f = fopen("/proc/meminfo", "r");
+ if (!f)
+ err("open /proc/meminfo");
+ while (getline(, , f) > 0) {
+ if (sscanf(line, "Hugepagesize: %lu kB", ) == 1) {
+ hps <<= 10;
+ break;
+ }
+ }
+ free(line);
+ return hps;
+}
+
+int main(int argc, char **argv)
+{
+ int ret;
+ int fd;
+ char *p;
+ unsigned long hpsize = default_hugepage_size();
+ fd = open(argv[1], O_RDWR|O_CREAT);
+ if (fd == -1)
+ err("open");
+ p = mmap(NULL, 10 * hpsize, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
+ if (p == (void *)-1)
+ err("mmap");
+ memset(p, 'a', 3 * hpsize);
+ memset(p + 7 * hpsize, 'a', 3 * hpsize - 1);
+ ret = close(fd);
+ if (ret == -1)
+ err("close");
+ return 0;
+}
diff --git v3.15-rc7.orig/tools/testing/selftests/fincore/fincore.c
v3.15-rc7/tools/testing/selftests/fincore/fincore.c
new file mode 100644
index ..b089fe5f6bdf
--- /dev/null
+++ v3.15-rc7/tools/testing/selftests/fincore/fincore.c
@@ -0,0 +1,153 @@
+/*
+ * fincore(2) test program
+ */
+
+#define _GNU_SOURCE 1
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define err(x) (perror(x), exit(1))
+
+#define FINCORE_BMAP 0x01
+#define FINCORE_PFN0x02
+#define FINCORE_PAGE_FLAGS 0x04
+#define FINCORE_PAGECACHE_TAGS 0x08
+#define FINCORE_SKIP_HOLE 0x10
+
+#define FINCORE_MODE_MASK 0x1f
+#define FINCORE_LONGENTRY_MASK (FINCORE_PFN | FINCORE_PAGE_FLAGS | \
+FINCORE_PAGECACHE_TAGS | FINCORE_SKIP_HOLE)
+
+static int sys_fincore(int fd, loff_t start, size_t len, int mode,
+ unsigned char
[RFC][PATCH 0/3] mm: introduce fincore()
Due to the previous discussion[1], I learned that you people have discussed this system call a few times (but not conclusion) and it can solve my problem about pagecache scanning (see[2] for my motivation.) So I try it now. The main patch of this patchset is patch 2, and this is based on Johannes's previous version[3], so I CCed people who joined that discussion. While there might be controversies about the format of data copied from kernel to userspace, I take the Kirill's suggestion[4] which uses a flag to choose the data format, which is extensible and flexible (you can cut off some info if you don't need it.) And I added simple tests at patch 3, and patch 2 passes all the tests. Any comments are welcomed. [1] http://marc.info/?l=linux-kernel=140072606903894=2 [2] http://marc.info/?l=linux-mm=140072522603776=2 [3] http://thread.gmane.org/gmane.linux.kernel/1439212/focus=1441919 [4] http://marc.info/?l=linux-kernel=140075509611532=2 Thanks, Naoya Horiguchi --- Summary: Naoya Horiguchi (3): replace PAGECACHE_TAG_* definition with enumeration mm: introduce fincore() selftest: add test code for fincore() arch/x86/syscalls/syscall_64.tbl | 1 + include/linux/fs.h | 9 +- include/linux/syscalls.h | 2 + mm/Makefile| 2 +- mm/fincore.c | 362 + tools/testing/selftests/Makefile | 1 + tools/testing/selftests/fincore/Makefile | 31 ++ .../selftests/fincore/create_hugetlbfs_file.c | 49 +++ tools/testing/selftests/fincore/fincore.c | 153 + tools/testing/selftests/fincore/run_fincoretests | 355 10 files changed, 961 insertions(+), 4 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/6 RESEND V2] staging: dgap: unwind on error in dgap_found_board()
Adds a label for "kfree(brd)". And also remove
a state value as BOARD_FAILED in brd when dgap_do_remap() is failed.
Because "brd" will free after failure.
Signed-off-by: Daeseok Youn
Reviewed-by: Dan Carpenter
---
RESEND: this patch is included into newly series of patches.
V2: add "Reviewed-by" line in change log.
drivers/staging/dgap/dgap.c | 19 ++-
1 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index af78f6f..5556a6e 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -673,6 +673,7 @@ static int dgap_found_board(struct pci_dev *pdev, int id)
struct board_t *brd;
unsigned int pci_irq;
int i;
+ int ret;
/* get the board structure and prep it */
brd = kzalloc(sizeof(struct board_t), GFP_KERNEL);
@@ -728,8 +729,10 @@ static int dgap_found_board(struct pci_dev *pdev, int id)
brd->membase_end = pci_resource_end(pdev, 0);
}
- if (!brd->membase)
- return -ENODEV;
+ if (!brd->membase) {
+ ret = -ENODEV;
+ goto free_brd;
+ }
if (brd->membase & 1)
brd->membase &= ~3;
@@ -770,14 +773,20 @@ static int dgap_found_board(struct pci_dev *pdev, int id)
tasklet_init(>helper_tasklet, dgap_poll_tasklet,
(unsigned long) brd);
- i = dgap_do_remap(brd);
- if (i)
- brd->state = BOARD_FAILED;
+ ret = dgap_do_remap(brd);
+ if (ret)
+ goto free_brd;
pr_info("dgap: board %d: %s (rev %d), irq %ld\n",
dgap_numboards, brd->name, brd->rev, brd->irq);
return 0;
+
+free_brd:
+ kfree(brd);
+ dgap_board[dgap_numboards] = NULL;
+
+ return ret;
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net] bridge: notify user space after fdb update
From: Jon Maxwell Date: Thu, 29 May 2014 17:27:16 +1000 > There has been a number incidents recently where customers running KVM have > reported that VM hosts on different Hypervisors are unreachable. Based on > pcap traces we found that the bridge was broadcasting the ARP request out > onto the network. However some NICs have an inbuilt switch which on occasions > were broadcasting the VMs ARP request back through the physical NIC on the > Hypervisor. This resulted in the bridge changing ports and incorrectly > learning > that the VMs mac address was external. As a result the ARP reply was directed > back onto the external network and VM never updated it's ARP cache. This patch > will notify the bridge command, after a fdb has been updated to identify such > port toggling. > > Signed-off-by: Jon Maxwell Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] kvm/irqchip: Speed up KVM_SET_GSI_ROUTING
Hi,
I think you missed a cleanup_srcu_struct(>irq_srcu) in kvm_destroy_vm().
On Mon, May 5, 2014 at 10:26 PM, Paolo Bonzini wrote:
> Il 05/05/2014 16:21, Christian Borntraeger ha scritto:
>
>> On 28/04/14 18:39, Paolo Bonzini wrote:
>>>
>>> From: Christian Borntraeger
>>
>>
>> Given all your work, What about From: Paolo Bonzini
>> plus "Based on an inital patch from Christian Borntraeger"
>
>
> No big deal, I don't care about authorship that much.
>
>
>>> @@ -221,17 +225,18 @@ irqfd_wakeup(wait_queue_t *wait, unsigned mode, int
>>> sync, void *key)
>>> unsigned long flags = (unsigned long)key;
>>> struct kvm_kernel_irq_routing_entry *irq;
>>> struct kvm *kvm = irqfd->kvm;
>>> + int idx;
>>>
>>> if (flags & POLLIN) {
>>> - rcu_read_lock();
>>> - irq = rcu_dereference(irqfd->irq_entry);
>>> + idx = srcu_read_lock(>irq_srcu);
>>> + irq = srcu_dereference(irqfd->irq_entry, >irq_srcu);
>>> /* An event has been signaled, inject an interrupt */
>>> if (irq)
>>> kvm_set_msi(irq, kvm,
>>> KVM_USERSPACE_IRQ_SOURCE_ID, 1,
>>> false);
>>> else
>>> schedule_work(>inject);
>>> - rcu_read_unlock();
>>> + srcu_read_unlock(>irq_srcu, idx);
>>> }
>>>
>>> if (flags & POLLHUP) {
>>> @@ -363,7 +368,7 @@ kvm_irqfd_assign(struct kvm *kvm, struct kvm_irqfd
>>> *args)
>>> }
>>>
>>> list_add_rcu(>resampler_link,
>>> >resampler->list);
>>> - synchronize_rcu();
>>> + synchronize_srcu(>irq_srcu);
>>
>>
>> No idea what resampler is, can this become time critical as well - iow do
>> we need expedited here?
>
>
> It's for level-triggered interrupts. I decided that if synchronize_rcu was
> good enough before, synchronize_srcu will do after the patch.
>
>
>>> @@ -85,7 +86,7 @@ void kvm_unregister_irq_ack_notifier(struct kvm *kvm,
>>> mutex_lock(>irq_lock);
>>> hlist_del_init_rcu(>link);
>>> mutex_unlock(>irq_lock);
>>> - synchronize_rcu();
>>> + synchronize_srcu_expedited(>irq_srcu);
>>
>>
>> Hmm, looks like all callers are slow path (shutdown, deregister assigned
>> dev). Couldnt
>> we use the non expedited variant?
>
>
> ... but I have screwed up this one. Thanks, I'll change it.
>
>
>>> r = kvm_arch_init_vm(kvm, type);
>>> if (r)
>>> - goto out_err_nodisable;
>>> + goto out_err_no_disable;
>>>
>>> r = hardware_enable_all();
>>> if (r)
>>> - goto out_err_nodisable;
>>> + goto out_err_no_disable;
>>>
>>> #ifdef CONFIG_HAVE_KVM_IRQCHIP
>>> INIT_HLIST_HEAD(>mask_notifier_list);
>>> @@ -473,10 +473,12 @@ static struct kvm *kvm_create_vm(unsigned long
>>> type)
>>> r = -ENOMEM;
>>> kvm->memslots = kzalloc(sizeof(struct kvm_memslots), GFP_KERNEL);
>>> if (!kvm->memslots)
>>> - goto out_err_nosrcu;
>>> + goto out_err_no_srcu;
>>> kvm_init_memslots_id(kvm);
>>> if (init_srcu_struct(>srcu))
>>> - goto out_err_nosrcu;
>>> + goto out_err_no_srcu;
>>> + if (init_srcu_struct(>irq_srcu))
>>> + goto out_err_no_irq_srcu;
>>> for (i = 0; i < KVM_NR_BUSES; i++) {
>>> kvm->buses[i] = kzalloc(sizeof(struct kvm_io_bus),
>>> GFP_KERNEL);
>>> @@ -505,10 +507,12 @@ static struct kvm *kvm_create_vm(unsigned long
>>> type)
>>> return kvm;
>>>
>>> out_err:
>>> + cleanup_srcu_struct(>irq_srcu);
>>> +out_err_no_irq_srcu:
>>> cleanup_srcu_struct(>srcu);
>>> -out_err_nosrcu:
>>> +out_err_no_srcu:
>>> hardware_disable_all();
>>> -out_err_nodisable:
>>> +out_err_no_disable:
>>
>>
>>
>> the patch would be smaller without this change, but it makes the naming
>> more consistent, so ok.
>
>
> Yeah, out_err_noirq_srcu or out_err_noirqsrcu are both very ugly.
>
> Thanks for the review, I'm making the small change to remove expedited and
> applying to kvm/queue.
>
> Paolo
>
>
>>
>>> for (i = 0; i < KVM_NR_BUSES; i++)
>>> kfree(kvm->buses[i]);
>>> kfree(kvm->memslots);
>>>
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next V6 2/2] net/mlx4_en: Use affinity hint
On Sun, 2014-06-01 at 21:56 -0700, David Miller wrote: > Indeed you have to provide a dummy version for a non-SMP build etc. > > I'm reverting. > Hi David. I think your revert took one wrong commit. # git show ee39facbf82e73e468c504d2b40e83e2d223c28c | diffstat -p1 -w70 drivers/net/ethernet/micrel/ks8851.c | 50 ++- include/linux/cpumask.h |2 lib/cpumask.c| 64 - 3 files changed, 28 insertions(+), 88 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the mmc tree
Hi Chris,
On Mon, 26 May 2014 14:07:35 +1000 Stephen Rothwell
wrote:
>
> After merging the mmc tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> drivers/mmc/host/sdhci-s3c.c: In function 'sdhci_s3c_notify_change':
> drivers/mmc/host/sdhci-s3c.c:402:25: error: 'struct sdhci_host' has no member
> named 'card_tasklet'
>
> Caused by commit 3560db8e247a ("mmc: sdhci: push card_tasklet into
> threaded irq handler"). This is the second left over one I found.
> Please check for any more (grep is your friend).
>
> I have used the mmc tree from next-20140522 again for today.
This is back again. I have no idea why I didn't get this failure on
Friday. Please, guys, go through your tree and fix this problem once
and for all. Grep is your friend.
I have used the mmc tree from next-20140522 again for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
[PATCH 6/6] staging: dgap: make dgap_config_buf a local buffer
The dgap_config_buf is only used in dgap_firmware_load().
Signed-off-by: Daeseok Youn
---
drivers/staging/dgap/dgap.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index 3e716fe..c78c8e2 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -211,7 +211,6 @@ static const struct file_operations dgap_board_fops = {
static uint dgap_numboards;
static struct board_t *dgap_board[MAXBOARDS];
static ulong dgap_poll_counter;
-static char *dgap_config_buf;
static int dgap_driver_state = DRIVER_INITIALIZED;
static wait_queue_head_t dgap_dl_wait;
static int dgap_poll_tick = 20;/* Poll interval - 20 ms */
@@ -823,11 +822,12 @@ static int dgap_firmware_load(struct pci_dev *pdev, int
card_type)
const struct firmware *fw;
char *tmp_ptr;
int ret;
+ char *dgap_config_buf;
dgap_get_vpd(brd);
dgap_do_reset_board(brd);
- if ((fw_info[card_type].conf_name) && !dgap_config_buf) {
+ if (fw_info[card_type].conf_name) {
ret = request_firmware(, fw_info[card_type].conf_name,
>dev);
if (ret) {
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/6] staging: dgap: unwind on error in dgap_tty_register_ports()
- The dgap_tty_register_ports() needs to handle if the
tty_port_register_device() fails.
Signed-off-by: Daeseok Youn
---
drivers/staging/dgap/dgap.c | 44 +-
1 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index 8580f4b..3e716fe 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -4143,6 +4143,7 @@ static int dgap_tty_register_ports(struct board_t *brd)
{
struct channel_t *ch;
int i;
+ int ret;
brd->serial_ports = kcalloc(brd->nasync, sizeof(*brd->serial_ports),
GFP_KERNEL);
@@ -4152,8 +4153,8 @@ static int dgap_tty_register_ports(struct board_t *brd)
brd->printer_ports = kcalloc(brd->nasync, sizeof(*brd->printer_ports),
GFP_KERNEL);
if (!brd->printer_ports) {
- kfree(brd->serial_ports);
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto free_serial_ports;
}
for (i = 0; i < brd->nasync; i++) {
@@ -4170,6 +4171,11 @@ static int dgap_tty_register_ports(struct board_t *brd)
brd->serial_driver,
brd->firstminor + i, NULL);
+ if (IS_ERR(classp)) {
+ ret = PTR_ERR(classp);
+ goto unregister_ttys;
+ }
+
dgap_create_tty_sysfs(>ch_tun, classp);
ch->ch_tun.un_sysfs = classp;
@@ -4177,12 +4183,46 @@ static int dgap_tty_register_ports(struct board_t *brd)
brd->print_driver,
brd->firstminor + i, NULL);
+ if (IS_ERR(classp)) {
+ ret = PTR_ERR(classp);
+ goto unregister_ttys;
+ }
+
dgap_create_tty_sysfs(>ch_pun, classp);
ch->ch_pun.un_sysfs = classp;
}
dgap_create_ports_sysfiles(brd);
return 0;
+
+unregister_ttys:
+ while (i >= 0) {
+ ch = brd->channels[i];
+ if (ch->ch_tun.un_sysfs) {
+ dgap_remove_tty_sysfs(ch->ch_tun.un_sysfs);
+ tty_unregister_device(brd->serial_driver, i);
+ }
+
+ if (ch->ch_pun.un_sysfs) {
+ dgap_remove_tty_sysfs(ch->ch_pun.un_sysfs);
+ tty_unregister_device(brd->print_driver, i);
+ }
+ i--;
+ }
+
+ for (i = 0; i < brd->nasync; i++) {
+ tty_port_destroy(>serial_ports[i]);
+ tty_port_destroy(>printer_ports[i]);
+ }
+
+ kfree(brd->printer_ports);
+ brd->printer_ports = NULL;
+
+free_serial_ports:
+ kfree(brd->serial_ports);
+ brd->serial_ports = NULL;
+
+ return ret;
}
/*
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] extcon next-v2 for v3.16
Dear Greg, This is extcon-next-v2 full request for v3.16. This pull request includes additional patchset after merged previous extcon-next pull request(tags/extcon-next-for-v3.16). I add detailed description of this pull request on below. Please pull extcon with following update. Best Regards, Chanwoo Choi The following changes since commit 3f79a3fb5f41e8f2229e5bf8aa725eaa79686f14: extcon: palmas: Use devm_extcon_dev_allocate for extcon_dev (2014-04-29 09:52:12 +0900) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git tags/extcon-next-v2-for-3.16 for you to fetch changes up to 19c27d2fe7773f07ed53126f04ff9d7d62f64672: extcon: sm5502: Change internal hardware switch according to cable type (2014-06-02 09:28:34 +0900) Update extcon for v3.16 This patchset add new extcon provider driver and fix minor issue of extcon driver. Detailed description for patchset: 1. Add new Silicon-Mitus SM5502 MUIC (Micro-USB Interface Controller) device - extcon-sm5502 driver is capable of identifying the type of the external power source and attached accessory. And external power sources, such as Dedicated charger or a standard USB port, are able to charge the battery in the smart phone via the connector. 2. Fix minor issue of extcon driver - extcon-arizona driver - extcon-palmas driver 3. Fix minor issue of extcon core - Re-order the sequence of extcon device driver in Kconfig/Makefile alphabitically - Set parent device of extcon device automatically using devm_extcon_dev_allocate() Chanwoo Choi (5): extcon: Reorder the sequence of extcon device driver alphabetically extcon: Set parent device of extcon device using prameter of devm_extcon_dev_allocate extcon: sm5502: Add support new SM5502 extcon device driver extcon: sm5502: Detect cable state after completing platform booting extcon: sm5502: Change internal hardware switch according to cable type Charles Keepax (3): extcon: arizona: Remove duplicate set of input parent device extcon: arizona: Correct typo to disable regulation for button detection extcon: arizona: Update manual headphone detection calculation Krzysztof Kozlowski (1): extcon: palmas: Make of_device_id array const Nikesh Oswal (1): extcon: arizona: Use extcon cable API with index of extcon cable instead of string Richard Fitzgerald (1): extcon: arizona: support inverted jack detect switch drivers/extcon/Kconfig| 35 +- drivers/extcon/Makefile | 7 +- drivers/extcon/extcon-adc-jack.c | 1 - drivers/extcon/extcon-arizona.c | 68 ++-- drivers/extcon/extcon-class.c | 2 + drivers/extcon/extcon-gpio.c | 1 - drivers/extcon/extcon-max77693.c | 1 - drivers/extcon/extcon-max8997.c | 1 - drivers/extcon/extcon-palmas.c| 3 +- drivers/extcon/extcon-sm5502.c| 726 ++ include/linux/extcon/sm5502.h | 287 +++ include/linux/mfd/arizona/pdata.h | 3 + 12 files changed, 1087 insertions(+), 48 deletions(-) create mode 100644 drivers/extcon/extcon-sm5502.c create mode 100644 include/linux/extcon/sm5502.h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/6] staging: dgap: unwind on error in dgap_tty_init()
If the kzalloc() fails for channels, it need to handle
that error. It should free channels which were already
allocated.
And also removes the call to dgap_tty_uninit() in
dgap_firmware_load().
Signed-off-by: Daeseok Youn
---
drivers/staging/dgap/dgap.c | 18 +-
1 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index fcfa061..8580f4b 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -957,10 +957,8 @@ static int dgap_firmware_load(struct pci_dev *pdev, int
card_type)
* Do tty device initialization.
*/
ret = dgap_tty_init(brd);
- if (ret < 0) {
- dgap_tty_uninit(brd);
+ if (ret < 0)
return ret;
- }
ret = dgap_tty_register_ports(brd);
if (ret)
@@ -1330,6 +1328,7 @@ static int dgap_tty_init(struct board_t *brd)
struct channel_t *ch;
struct bs_t __iomem *bs;
struct cm_t __iomem *cm;
+ int ret;
if (!brd)
return -EIO;
@@ -1381,8 +1380,10 @@ static int dgap_tty_init(struct board_t *brd)
for (i = 0; i < brd->nasync; i++) {
brd->channels[i] =
kzalloc(sizeof(struct channel_t), GFP_KERNEL);
- if (!brd->channels[i])
- return -ENOMEM;
+ if (!brd->channels[i]) {
+ ret = -ENOMEM;
+ goto free_chan;
+ }
}
ch = brd->channels[0];
@@ -1478,6 +1479,13 @@ static int dgap_tty_init(struct board_t *brd)
}
return 0;
+
+free_chan:
+ while (--i >= 0) {
+ kfree(brd->channels[i]);
+ brd->channels[i] = NULL;
+ }
+ return ret;
}
/*
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/6] staging: dgap: remove bogus null test in dgap_tty_init()
- The channels array were set to NULL in dgap_found_board().
- Removes redundant null check for channels array in for loop,
if one of the channel cannot be allocated, dgap_tty_init() just returns
an error.
Signed-off-by: Daeseok Youn
---
drivers/staging/dgap/dgap.c | 13 -
1 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index 5556a6e..fcfa061 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -1379,12 +1379,10 @@ static int dgap_tty_init(struct board_t *brd)
* when the driver was first loaded.
*/
for (i = 0; i < brd->nasync; i++) {
- if (!brd->channels[i]) {
- brd->channels[i] =
- kzalloc(sizeof(struct channel_t), GFP_KERNEL);
- if (!brd->channels[i])
- return -ENOMEM;
- }
+ brd->channels[i] =
+ kzalloc(sizeof(struct channel_t), GFP_KERNEL);
+ if (!brd->channels[i])
+ return -ENOMEM;
}
ch = brd->channels[0];
@@ -1398,9 +1396,6 @@ static int dgap_tty_init(struct board_t *brd)
/* Set up channel variables */
for (i = 0; i < brd->nasync; i++, ch = brd->channels[i], bs++) {
- if (!brd->channels[i])
- continue;
-
spin_lock_init(>ch_lock);
/* Store all our magic numbers */
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/6 RESEND] staging: dgap: unwind on error in dgap_found_board()
Adds a label for "kfree(brd)". And also remove
a state value as BOARD_FAILED in brd when dgap_do_remap() is failed.
Because "brd" will free after failure.
Signed-off-by: Daeseok Youn
---
RESEND: this patch is included into newly series of patches.
drivers/staging/dgap/dgap.c | 19 ++-
1 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index af78f6f..5556a6e 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -673,6 +673,7 @@ static int dgap_found_board(struct pci_dev *pdev, int id)
struct board_t *brd;
unsigned int pci_irq;
int i;
+ int ret;
/* get the board structure and prep it */
brd = kzalloc(sizeof(struct board_t), GFP_KERNEL);
@@ -728,8 +729,10 @@ static int dgap_found_board(struct pci_dev *pdev, int id)
brd->membase_end = pci_resource_end(pdev, 0);
}
- if (!brd->membase)
- return -ENODEV;
+ if (!brd->membase) {
+ ret = -ENODEV;
+ goto free_brd;
+ }
if (brd->membase & 1)
brd->membase &= ~3;
@@ -770,14 +773,20 @@ static int dgap_found_board(struct pci_dev *pdev, int id)
tasklet_init(>helper_tasklet, dgap_poll_tasklet,
(unsigned long) brd);
- i = dgap_do_remap(brd);
- if (i)
- brd->state = BOARD_FAILED;
+ ret = dgap_do_remap(brd);
+ if (ret)
+ goto free_brd;
pr_info("dgap: board %d: %s (rev %d), irq %ld\n",
dgap_numboards, brd->name, brd->rev, brd->irq);
return 0;
+
+free_brd:
+ kfree(brd);
+ dgap_board[dgap_numboards] = NULL;
+
+ return ret;
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/6 RESEND] staging: dgap: remove useless dgap_probe1() function
The dgap_probe1() function is just calling dgap_found_board().
So it is removed and dgap_found_board() is called directly.
Signed-off-by: Daeseok Youn
---
RESEND : this patch is included into newly serise of patches
so renumbered and resend.
drivers/staging/dgap/dgap.c |8 +---
1 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index 170d6f3..af78f6f 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -76,7 +76,6 @@ static void dgap_poll_handler(ulong dummy);
static int dgap_init_pci(void);
static int dgap_init_one(struct pci_dev *pdev, const struct pci_device_id
*ent);
static void dgap_remove_one(struct pci_dev *dev);
-static int dgap_probe1(struct pci_dev *pdev, int card_type);
static int dgap_do_remap(struct board_t *brd);
static irqreturn_t dgap_intr(int irq, void *voidbrd);
@@ -577,7 +576,7 @@ static int dgap_init_one(struct pci_dev *pdev, const struct
pci_device_id *ent)
if (rc)
return -EIO;
- rc = dgap_probe1(pdev, ent->driver_data);
+ rc = dgap_found_board(pdev, ent->driver_data);
if (rc)
return rc;
@@ -585,11 +584,6 @@ static int dgap_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
return dgap_firmware_load(pdev, ent->driver_data);
}
-static int dgap_probe1(struct pci_dev *pdev, int card_type)
-{
- return dgap_found_board(pdev, card_type);
-}
-
static void dgap_remove_one(struct pci_dev *dev)
{
/* Do Nothing */
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next V6 2/2] net/mlx4_en: Use affinity hint
From: Eric Dumazet
Date: Sun, 01 Jun 2014 21:37:11 -0700
> On Sun, 2014-06-01 at 21:16 -0700, Eric Dumazet wrote:
>> CC [M] drivers/net/ethernet/mellanox/mlx4/en_netdev.o
>> drivers/net/ethernet/mellanox/mlx4/en_netdev.c: In function
>> ‘mlx4_en_init_affinity_hint’:
>> drivers/net/ethernet/mellanox/mlx4/en_netdev.c:1546:23: error: incompatible
>> types when assigning to type ‘cpumask_var_t’ from type ‘void *’
>> drivers/net/ethernet/mellanox/mlx4/en_netdev.c: In function
>> ‘mlx4_en_free_affinity_hint’:
>> drivers/net/ethernet/mellanox/mlx4/en_netdev.c:1553:41: error: incompatible
>> types when assigning to type ‘cpumask_var_t’ from type ‘void *’
>
>
> And :
>
> ERROR: "cpumask_set_cpu_local_first"
> [drivers/net/ethernet/mellanox/mlx4/mlx4_en.ko] undefined!
>
>
> $ git grep -n cpumask_set_cpu_local_first
> drivers/net/ethernet/mellanox/mlx4/en_netdev.c:1542:if
> (cpumask_set_cpu_local_first(ring_idx, numa_node,
> include/linux/cpumask.h:260:int cpumask_set_cpu_local_first(int i, int
> numa_node, cpumask_t *dstp);
> lib/cpumask.c:168: * cpumask_set_cpu_local_first - set i'th cpu with local
> numa cpu's first
> lib/cpumask.c:182:int cpumask_set_cpu_local_first(int i, int numa_node,
> cpumask_t *dstp)
> lib/cpumask.c:228:EXPORT_SYMBOL(cpumask_set_cpu_local_first);
>
> Fixes are needed if CONFIG_CPUMASK_OFFSTACK is not used.
>
> $ grep CONFIG_CPUMASK_OFFSTACK .config
> $ echo $?
> 1
>
Indeed you have to provide a dummy version for a non-SMP build etc.
I'm reverting.
N§²ζμrΈyϊθΨb²X¬ΆΗ§vΨ^)ήΊ{.nΗ+·₯{±κηzX§Ά‘ά¨}©²Ζ
zΪ:+v¨Ύ«κηzZ+Κ+zf£’·h§~Ϋi�ϋΰzΉ �w₯’Έ?¨θΪ&’)ί’fω^jΗ«y§m
α@A«aΆΪ�
0Άμh�εi
Re: [PATCH net-next V6 2/2] net/mlx4_en: Use affinity hint
From: Eric Dumazet Date: Sun, 01 Jun 2014 21:16:50 -0700 > CC [M] drivers/net/ethernet/mellanox/mlx4/en_netdev.o > drivers/net/ethernet/mellanox/mlx4/en_netdev.c: In function > ‘mlx4_en_init_affinity_hint’: > drivers/net/ethernet/mellanox/mlx4/en_netdev.c:1546:23: error: incompatible > types when assigning to type ‘cpumask_var_t’ from type ‘void *’ > drivers/net/ethernet/mellanox/mlx4/en_netdev.c: In function > ‘mlx4_en_free_affinity_hint’: > drivers/net/ethernet/mellanox/mlx4/en_netdev.c:1553:41: error: incompatible > types when assigning to type ‘cpumask_var_t’ from type ‘void *’ What configuration/compiler combination generates this warning? I didn't see it with allmodconfig.
Re: [PATCH v2 0/3] File Sealing & memfd_create()
Hello, On Mon, May 19, 2014 at 01:44:25PM +0200, David Herrmann wrote: > Hi > > On Thu, May 15, 2014 at 12:35 AM, Hugh Dickins wrote: > > The aspect which really worries me is this: the maintenance burden. > > This approach would add some peculiar new code, introducing a rare > > special case: which we might get right today, but will very easily > > forget tomorrow when making some other changes to mm. If we compile > > a list of danger areas in mm, this would surely belong on that list. > > I tried doing the page-replacement in the last 4 days, but honestly, > it's far more complex than I thought. So if no-one more experienced > with mm/ comes up with a simple implementation, I'll have to delay > this for some more weeks. > > However, I still wonder why we try to fix this as part of this > patchset. Using FUSE, a DIRECT-IO call can be delayed for an arbitrary > amount of time. Same is true for network block-devices, NFS, iscsi, > maybe loop-devices, ... This means, _any_ once mapped page can be > written to after an arbitrary delay. This can break any feature that > makes FS objects read-only (remounting read-only, setting S_IMMUTABLE, > sealing, ..). > > Shouldn't we try to fix the _cause_ of this? I didn't follow this patchset and couldn't find what's your most cocern but at a first glance, it seems you have troubled with pinned page. If so, it's really big problem for CMA and I think peterz's approach(ie, mm_mpin) is really make sense to me. https://lkml.org/lkml/2014/5/26/340 > > Isn't there a simple way to lock/mark/.. affected vmas in > get_user_pages(_fast)() and release them once done? We could increase > i_mmap_writable on all affected address_space and decrease it on > release. This would at least prevent sealing and could be check on > other operations, too (like setting S_IMMUTABLE). > This should be as easy as checking page_mapping(page) != NULL and then > adjusting ->i_mmap_writable in > get_writable_user_pages/put_writable_user_pages, right? > > Thanks > David > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org;> em...@kvack.org -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm 8/8] slab: reap dead memcg caches aggressively
On Fri, May 30, 2014 at 05:51:11PM +0400, Vladimir Davydov wrote:
> There is no use in keeping free objects/slabs on dead memcg caches,
> because they will never be allocated. So let's make cache_reap() shrink
> as many free objects from such caches as possible.
>
> Note the difference between SLAB and SLUB handling of dead memcg caches.
> For SLUB, dead cache destruction is scheduled as soon as the last object
> is freed, because dead caches do not cache free objects. For SLAB, dead
> caches can keep some free objects on per cpu arrays, so that an empty
> dead cache will be hanging around until cache_reap() drains it.
>
> We don't disable free objects caching for SLAB, because it would force
> kfree to always take a spin lock, which would degrade performance
> significantly.
>
> Since cache_reap() drains all caches once ~4 secs on each CPU, empty
> dead caches will die quickly.
>
> Signed-off-by: Vladimir Davydov
> ---
> mm/slab.c | 17 -
> 1 file changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/mm/slab.c b/mm/slab.c
> index cecc01bba389..d81e46316c99 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -3985,6 +3985,11 @@ static void cache_reap(struct work_struct *w)
> goto out;
>
> list_for_each_entry(searchp, _caches, list) {
> + int force = 0;
> +
> + if (memcg_cache_dead(searchp))
> + force = 1;
> +
> check_irq_on();
>
> /*
> @@ -3996,7 +4001,7 @@ static void cache_reap(struct work_struct *w)
>
> reap_alien(searchp, n);
>
> - drain_array(searchp, n, cpu_cache_get(searchp), 0, node);
> + drain_array(searchp, n, cpu_cache_get(searchp), force, node);
>
> /*
>* These are racy checks but it does not matter
> @@ -4007,15 +4012,17 @@ static void cache_reap(struct work_struct *w)
>
> n->next_reap = jiffies + REAPTIMEOUT_NODE;
>
> - drain_array(searchp, n, n->shared, 0, node);
> + drain_array(searchp, n, n->shared, force, node);
>
> if (n->free_touched)
> n->free_touched = 0;
> else {
> - int freed;
> + int freed, tofree;
> +
> + tofree = force ? slabs_tofree(searchp, n) :
> + DIV_ROUND_UP(n->free_limit, 5 * searchp->num);
Hello,
According to my code reading, slabs_to_free() doesn't return number of
free slabs. This bug is introduced by 0fa8103b. I think that it is
better to fix it before applyting this patch. Otherwise, use n->free_objects
instead of slabs_tofree() to achieve your purpose correctly.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next V6 2/2] net/mlx4_en: Use affinity hint
On Sun, 2014-06-01 at 21:16 -0700, Eric Dumazet wrote: > On Sun, 2014-05-25 at 17:47 +0300, Amir Vadai wrote: > > From: Yuval Atias > > > > The “affinity hint” mechanism is used by the user space > > daemon, irqbalancer, to indicate a preferred CPU mask for irqs. > > Irqbalancer can use this hint to balance the irqs between the > > cpus indicated by the mask. > > > > We wish the HCA to preferentially map the IRQs it uses to numa cores > > close to it. To accomplish this, we use cpumask_set_cpu_local_first(), that > > sets the affinity hint according the following policy: > > First it maps IRQs to “close” numa cores. If these are exhausted, the > > remaining IRQs are mapped to “far” numa cores. > > > > Signed-off-by: Yuval Atias > > Signed-off-by: Amir Vadai > > --- > > CC [M] drivers/net/ethernet/mellanox/mlx4/en_netdev.o > drivers/net/ethernet/mellanox/mlx4/en_netdev.c: In function > ‘mlx4_en_init_affinity_hint’: > drivers/net/ethernet/mellanox/mlx4/en_netdev.c:1546:23: error: incompatible > types when assigning to type ‘cpumask_var_t’ from type ‘void *’ > drivers/net/ethernet/mellanox/mlx4/en_netdev.c: In function > ‘mlx4_en_free_affinity_hint’: > drivers/net/ethernet/mellanox/mlx4/en_netdev.c:1553:41: error: incompatible > types when assigning to type ‘cpumask_var_t’ from type ‘void *’ And : ERROR: "cpumask_set_cpu_local_first" [drivers/net/ethernet/mellanox/mlx4/mlx4_en.ko] undefined! $ git grep -n cpumask_set_cpu_local_first drivers/net/ethernet/mellanox/mlx4/en_netdev.c:1542:if (cpumask_set_cpu_local_first(ring_idx, numa_node, include/linux/cpumask.h:260:int cpumask_set_cpu_local_first(int i, int numa_node, cpumask_t *dstp); lib/cpumask.c:168: * cpumask_set_cpu_local_first - set i'th cpu with local numa cpu's first lib/cpumask.c:182:int cpumask_set_cpu_local_first(int i, int numa_node, cpumask_t *dstp) lib/cpumask.c:228:EXPORT_SYMBOL(cpumask_set_cpu_local_first); Fixes are needed if CONFIG_CPUMASK_OFFSTACK is not used. $ grep CONFIG_CPUMASK_OFFSTACK .config $ echo $? 1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] ftrace: print max callstack
While I played with my own feature(ex, something on the way to reclaim), kernel went to oops easily. I guessed reason would be stack overflow and wanted to prove it. I found stack tracer which would be very useful for me but kernel went oops before my user program gather the information via "watch cat /sys/kernel/debug/tracing/stack_trace" so I couldn't get any message from that. What I want was that emit the kernel stack usage when kernel goes oops so I could find what's the stack hogger. This patch shows callstack of max stack usage right before oops so we can find a culprit. So, the result is as follows. [ 1116.522206] init: lightdm main process (1246) terminated with status 1 [ 1119.922916] init: failsafe-x main process (1272) terminated with status 1 [ 3887.728131] kworker/u24:1 (6637) used greatest stack depth: 256 bytes left [ 6397.629227] cc1 (9554) used greatest stack depth: 128 bytes left [ 7174.467392] DepthSize Location(47 entries) [ 7174.467392] - [ 7174.467785] 0) 7248 256 get_page_from_freelist+0xa7/0x920 [ 7174.468506] 1) 6992 352 __alloc_pages_nodemask+0x1cd/0xb20 [ 7174.469224] 2) 6640 8 alloc_pages_current+0x10f/0x1f0 [ 7174.469413] 3) 6632 168 new_slab+0x2c5/0x370 [ 7174.469413] 4) 6464 8 __slab_alloc+0x3a9/0x501 [ 7174.469413] 5) 6456 80 __kmalloc+0x1cb/0x200 [ 7174.469413] 6) 6376 376 vring_add_indirect+0x36/0x200 [ 7174.469413] 7) 6000 144 virtqueue_add_sgs+0x2e2/0x320 [ 7174.469413] 8) 5856 288 __virtblk_add_req+0xda/0x1b0 [ 7174.469413] 9) 5568 96 virtio_queue_rq+0xd3/0x1d0 [ 7174.469413] 10) 5472 128 __blk_mq_run_hw_queue+0x1ef/0x440 [ 7174.469413] 11) 5344 16 blk_mq_run_hw_queue+0x35/0x40 [ 7174.469413] 12) 5328 96 blk_mq_insert_requests+0xdb/0x160 [ 7174.469413] 13) 5232 112 blk_mq_flush_plug_list+0x12b/0x140 [ 7174.469413] 14) 5120 112 blk_flush_plug_list+0xc7/0x220 [ 7174.469413] 15) 5008 64 io_schedule_timeout+0x88/0x100 [ 7174.469413] 16) 4944 128 mempool_alloc+0x145/0x170 [ 7174.469413] 17) 4816 96 bio_alloc_bioset+0x10b/0x1d0 [ 7174.469413] 18) 4720 48 get_swap_bio+0x30/0x90 [ 7174.469413] 19) 4672 160 __swap_writepage+0x150/0x230 [ 7174.469413] 20) 4512 32 swap_writepage+0x42/0x90 [ 7174.469413] 21) 4480 320 shrink_page_list+0x676/0xa80 [ 7174.469413] 22) 4160 208 shrink_inactive_list+0x262/0x4e0 [ 7174.469413] 23) 3952 304 shrink_lruvec+0x3e1/0x6a0 [ 7174.469413] 24) 3648 80 shrink_zone+0x3f/0x110 [ 7174.469413] 25) 3568 128 do_try_to_free_pages+0x156/0x4c0 [ 7174.469413] 26) 3440 208 try_to_free_pages+0xf7/0x1e0 [ 7174.469413] 27) 3232 352 __alloc_pages_nodemask+0x783/0xb20 [ 7174.469413] 28) 2880 8 alloc_pages_current+0x10f/0x1f0 [ 7174.469413] 29) 2872 200 __page_cache_alloc+0x13f/0x160 [ 7174.469413] 30) 2672 80 find_or_create_page+0x4c/0xb0 [ 7174.469413] 31) 2592 80 ext4_mb_load_buddy+0x1e9/0x370 [ 7174.469413] 32) 2512 176 ext4_mb_regular_allocator+0x1b7/0x460 [ 7174.469413] 33) 2336 128 ext4_mb_new_blocks+0x458/0x5f0 [ 7174.469413] 34) 2208 256 ext4_ext_map_blocks+0x70b/0x1010 [ 7174.469413] 35) 1952 160 ext4_map_blocks+0x325/0x530 [ 7174.469413] 36) 1792 384 ext4_writepages+0x6d1/0xce0 [ 7174.469413] 37) 1408 16 do_writepages+0x23/0x40 [ 7174.469413] 38) 1392 96 __writeback_single_inode+0x45/0x2e0 [ 7174.469413] 39) 1296 176 writeback_sb_inodes+0x2ad/0x500 [ 7174.469413] 40) 1120 80 __writeback_inodes_wb+0x9e/0xd0 [ 7174.469413] 41) 1040 160 wb_writeback+0x29b/0x350 [ 7174.469413] 42) 880 208 bdi_writeback_workfn+0x11c/0x480 [ 7174.469413] 43) 672 144 process_one_work+0x1d2/0x570 [ 7174.469413] 44) 528 112 worker_thread+0x116/0x370 [ 7174.469413] 45) 416 240 kthread+0xf3/0x110 [ 7174.469413] 46) 176 176 ret_from_fork+0x7c/0xb0 [ 7174.469413] [ cut here ] [ 7174.469413] kernel BUG at kernel/trace/trace_stack.c:174! [ 7174.469413] invalid opcode: [#1] SMP DEBUG_PAGEALLOC [ 7174.469413] Dumping ftrace buffer: [ 7174.469413](ftrace buffer empty) [ 7174.469413] Modules linked in: [ 7174.469413] CPU: 0 PID: 440 Comm: kworker/u24:0 Not tainted 3.14.0+ #212 [ 7174.469413] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 7174.469413] Workqueue: writeback bdi_writeback_workfn (flush-253:0) [ 7174.469413] task: 88003417 ti: 880029518000 task.ti: 880029518000 [ 7174.469413] RIP: 0010:[] [] stack_trace_call+0x2de/0x340 [ 7174.469413] RSP: :880029518290 EFLAGS: 00010046 [ 7174.469413] RAX: 0030 RBX:
Re: [PATCH -mm 7/8] slub: make dead caches discard free slabs immediately
On Sat, May 31, 2014 at 03:04:58PM +0400, Vladimir Davydov wrote: > On Fri, May 30, 2014 at 09:57:10AM -0500, Christoph Lameter wrote: > > On Fri, 30 May 2014, Vladimir Davydov wrote: > > > > > (3) is a bit more difficult, because slabs are added to per-cpu partial > > > lists lock-less. Fortunately, we only have to handle the __slab_free > > > case, because, as there shouldn't be any allocation requests dispatched > > > to a dead memcg cache, get_partial_node() should never be called. In > > > __slab_free we use cmpxchg to modify kmem_cache_cpu->partial (see > > > put_cpu_partial) so that setting ->partial to a special value, which > > > will make put_cpu_partial bail out, will do the trick. > > > > > > Note, this shouldn't affect performance, because keeping empty slabs on > > > per node lists as well as using per cpu partials are only worthwhile if > > > the cache is used for allocations, which isn't the case for dead caches. > > > > This all sounds pretty good to me but we still have some pretty extensive > > modifications that I would rather avoid. > > > > In put_cpu_partial you can simply check that the memcg is dead right? This > > would avoid all the other modifications I would think and will not require > > a special value for the per cpu partial pointer. > > That would be racy. The check if memcg is dead and the write to per cpu > partial ptr wouldn't proceed as one atomic operation. If we set the dead > flag from another thread between these two operations, put_cpu_partial > will add a slab to a per cpu partial list *after* the cache was zapped. Hello, Vladimir. I think that we can do (3) easily. If we check memcg_cache_dead() in the end of put_cpu_partial() rather than in the begin of put_cpu_partial(), we can avoid the race you mentioned. If someone do put_cpu_partial() before dead flag is set, it can be zapped by who set dead flag. And if someone do put_cpu_partial() after dead flag is set, it can be zapped by who do put_cpu_partial(). Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Licensing & copyright of kernel .config files (defconfig, *config)
I'm not seeing where there is a problem, unless you are trying to assume that you have no right to distribute them at all. there is no source for the .config file, it is the source. so when you distribute it, you are complying with any distribution requirements. it could be argued that distributing the kernel requires distribution of the .config, but that's been violated so much that it's hard to see anyone worrying about it (and it's best practice to distribute it anyway, and trival to make it be part of the kernel via /proc) what is it that's worrying you and causing the need to question the licenseing? David Lang On Sun, 1 Jun 2014, Robin H. Johnson wrote: On Mon, Jun 02, 2014 at 12:01:46AM +0100, Ken Moffat wrote: Naively, since the defconfigs are bundled with the kernel, that could fall under GPLv2-only implicitly, but lacking any explicit copyright headers makes this interesting (arch/*/configs/* contain lots of files, no copyright headers on them). I am not a lawyer, but surely _many_ of the kernel files do not contain any explicit copyright information ? On closer inspection, more files than I thought don't have any explicit copyrights on them. ~67% of files in v3.13 had the text 'Copyright' or 'Licens' appear in them. Why does your editor put a default license on anything ? It's my stock header, customized by per-directory vimrc. The non-project-specific default one actually has a CHANGEME string it in, to help remind me that it needs an edit before I release that file. I was just using the BSD license on the file as an example. Submissions to other open source projects are generally bound by the license of the project, with a few exceptions (I've put patches into public domain to avoid signing some CLA-like agreements). If I was being awkward, I would suggest that the config would not be useful until you had run it through "make oldconfig" or similar, and that therefore the kernel license of GPL-2 applies. That's the case I was interested in :-). If the files are to be marked with a copyright header, who is the holder of it that it should be attributed to? Iff the work is copyrightable (I do not have an opinion on that), surely the license only matters if you breach it ? ;-) If you distribute a compiled kernel with the source, and all of that source is GPL-2, then I assume you are in the clear. For "extras" which include binaries without source, my understanding is that you would always be vulnerable to kernel copyright holders. So, I suspect that the attribution of a config file is not particularly important. I agree with your reasoning if I was distributing kernel sources or compiled kernels, but this is going to be a package of kernel configurations only. Background: Gentoo has a bunch of "stock" kernel configurations for release engineering, our initramfs tool (genkernel), and other endeavors over the years. These projects claim BSD, GPL2, LGPL2 on various pieces, and I don't think they can all be correct. I'm working on getting them into one place, because some of them have been getting stale, but the differing licenses raised a red flag to me. To the extent that GPL-2 can include LGPL-2 and BSD, I suggest that you label them all as GPL-2. That is the licence of the kernel, and for practical reasons it will not change (this was discussed when somebody asked about GPL-3 : even if the main copyright holders wanted to make the change (and many do not), some copyright holders are no longer contactable). You might be able to dual-license some of these distro files, but I have no idea if that would be appropriate. If the rest of the logic is correct, then the non-GPL2 license on these files was never valid in the first place; they inherited GPL2 from the kernel from the get go, and I don't need to be concerned about the hassle of formally relicensing them by contacting the authors of the configs (which again, aren't always contactable anymore). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next V6 2/2] net/mlx4_en: Use affinity hint
On Sun, 2014-05-25 at 17:47 +0300, Amir Vadai wrote: > From: Yuval Atias > > The “affinity hint” mechanism is used by the user space > daemon, irqbalancer, to indicate a preferred CPU mask for irqs. > Irqbalancer can use this hint to balance the irqs between the > cpus indicated by the mask. > > We wish the HCA to preferentially map the IRQs it uses to numa cores > close to it. To accomplish this, we use cpumask_set_cpu_local_first(), that > sets the affinity hint according the following policy: > First it maps IRQs to “close” numa cores. If these are exhausted, the > remaining IRQs are mapped to “far” numa cores. > > Signed-off-by: Yuval Atias > Signed-off-by: Amir Vadai > --- CC [M] drivers/net/ethernet/mellanox/mlx4/en_netdev.o drivers/net/ethernet/mellanox/mlx4/en_netdev.c: In function ‘mlx4_en_init_affinity_hint’: drivers/net/ethernet/mellanox/mlx4/en_netdev.c:1546:23: error: incompatible types when assigning to type ‘cpumask_var_t’ from type ‘void *’ drivers/net/ethernet/mellanox/mlx4/en_netdev.c: In function ‘mlx4_en_free_affinity_hint’: drivers/net/ethernet/mellanox/mlx4/en_netdev.c:1553:41: error: incompatible types when assigning to type ‘cpumask_var_t’ from type ‘void *’ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/3] CMA: always treat free cma pages as non-free on watermark checking
Hi Joonsoo,
CC'ing the developer of the patch (Tomasz Stanislawski)
On Fri, May 30, 2014 at 8:16 PM, Joonsoo Kim wrote:
> 2014-05-30 19:40 GMT+09:00 Ritesh Harjani :
>> Hi Joonsoo,
>>
>> I think you will be loosing the benefit of below patch with your changes.
>> I am no expert here so please bear with me. I tried explaining in the
>> inline comments, let me know if I am wrong.
>>
>> commit 026b08147923142e925a7d0aaa39038055ae0156
>> Author: Tomasz Stanislawski
>> Date: Wed Jun 12 14:05:02 2013 -0700
>
> Hello, Ritesh.
>
> Thanks for notifying that.
>
>>
>> On Wed, May 28, 2014 at 12:34 PM, Joonsoo Kim wrote:
>>> commit d95ea5d1('cma: fix watermark checking') introduces ALLOC_CMA flag
>>> for alloc flag and treats free cma pages as free pages if this flag is
>>> passed to watermark checking. Intention of that patch is that movable page
>>> allocation can be be handled from cma reserved region without starting
>>> kswapd. Now, previous patch changes the behaviour of allocator that
>>> movable allocation uses the page on cma reserved region aggressively,
>>> so this watermark hack isn't needed anymore. Therefore remove it.
>>>
>>> Acked-by: Michal Nazarewicz
>>> Signed-off-by: Joonsoo Kim
>>>
>>> diff --git a/mm/compaction.c b/mm/compaction.c
>>> index 627dc2e..36e2fcd 100644
>>> --- a/mm/compaction.c
>>> +++ b/mm/compaction.c
>>> @@ -1117,10 +1117,6 @@ unsigned long try_to_compact_pages(struct zonelist
>>> *zonelist,
>>>
>>> count_compact_event(COMPACTSTALL);
>>>
>>> -#ifdef CONFIG_CMA
>>> - if (allocflags_to_migratetype(gfp_mask) == MIGRATE_MOVABLE)
>>> - alloc_flags |= ALLOC_CMA;
>>> -#endif
>>> /* Compact each zone in the list */
>>> for_each_zone_zonelist_nodemask(zone, z, zonelist, high_zoneidx,
>>> nodemask) {
>>> diff --git a/mm/internal.h b/mm/internal.h
>>> index 07b6736..a121762 100644
>>> --- a/mm/internal.h
>>> +++ b/mm/internal.h
>>> @@ -384,7 +384,6 @@ unsigned long reclaim_clean_pages_from_list(struct zone
>>> *zone,
>>> #define ALLOC_HARDER 0x10 /* try to alloc harder */
>>> #define ALLOC_HIGH 0x20 /* __GFP_HIGH set */
>>> #define ALLOC_CPUSET 0x40 /* check for correct cpuset */
>>> -#define ALLOC_CMA 0x80 /* allow allocations from CMA areas */
>>> -#define ALLOC_FAIR 0x100 /* fair zone allocation */
>>> +#define ALLOC_FAIR 0x80 /* fair zone allocation */
>>>
>>> #endif /* __MM_INTERNAL_H */
>>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>>> index ca678b6..83a8021 100644
>>> --- a/mm/page_alloc.c
>>> +++ b/mm/page_alloc.c
>>> @@ -1764,20 +1764,22 @@ static bool __zone_watermark_ok(struct zone *z, int
>>> order, unsigned long mark,
>>> long min = mark;
>>> long lowmem_reserve = z->lowmem_reserve[classzone_idx];
>>> int o;
>>> - long free_cma = 0;
>>>
>>> free_pages -= (1 << order) - 1;
>>> if (alloc_flags & ALLOC_HIGH)
>>> min -= min / 2;
>>> if (alloc_flags & ALLOC_HARDER)
>>> min -= min / 4;
>>> -#ifdef CONFIG_CMA
>>> - /* If allocation can't use CMA areas don't use free CMA pages */
>>> - if (!(alloc_flags & ALLOC_CMA))
>>> - free_cma = zone_page_state(z, NR_FREE_CMA_PAGES);
>>> -#endif
>>> + /*
>>> +* We don't want to regard the pages on CMA region as free
>>> +* on watermark checking, since they cannot be used for
>>> +* unmovable/reclaimable allocation and they can suddenly
>>> +* vanish through CMA allocation
>>> +*/
>>> + if (IS_ENABLED(CONFIG_CMA) && z->managed_cma_pages)
>>> + free_pages -= zone_page_state(z, NR_FREE_CMA_PAGES);
>>
>> make this free_cma instead of free_pages.
>>
>>>
>>> - if (free_pages - free_cma <= min + lowmem_reserve)
>>> + if (free_pages <= min + lowmem_reserve)
>> free_pages - free_cma <= min + lowmem_reserve
>>
>> Because in for loop you subtract nr_free which includes the CMA pages.
>> So if you have subtracted NR_FREE_CMA_PAGES
>> from free_pages above then you will be subtracting cma pages again in
>> nr_free (below in for loop).
>
> Yes, I understand the problem you mentioned.
>
> I think that this is complicated issue.
>
> Comit '026b081' you mentioned makes watermark_ok() loose for high order
> allocation compared to kernel that CMA isn't enabled, since free_pages
> includes
> free_cma pages and most of high order allocation except THP would be
> non-movable allocation. This non-movable allocation can't use cma pages,
> so we shouldn't include free_cma pages.
>
> If most of free cma pages are 0 order, that commit works correctly. We
> subtract
> nr of free cma pages at the first loop, so there is no problem. But,
> if the system
> have some free high-order cma pages, watermark checking allow high-order
> allocation more easily.
>
> I think that loosing the watermark
Re: [PATCH] block: virtio_blk: don't hold spin lock during world switch
Jens Axboe writes: > On 2014-05-30 00:10, Rusty Russell wrote: >> Jens Axboe writes: >>> If Rusty agrees, I'd like to add it for 3.16 with a stable marker. >> >> Really stable? It improves performance, which is nice. But every patch >> which goes into the kernel fixes a bug, improves clarity, improves >> performance or adds a feature. I've now seen all four cases get CC'd >> into stable. >> >> Including some of mine explicitly not marked stable which get swept up >> by enthusiastic stable maintainers :( >> >> Is now there *any* patch short of a major rewrite which shouldn't get >> cc: stable? > > I agree that there's sometimes an unfortunate trend there. I didn't > check, but my assumption was that this is a regression after the blk-mq > conversion, in which case I do think it belongs in stable. No, it's always been that way. In the original driver the entire "issue requests" function was under the lock. It was your mq conversion which made this optimization possible, and also made it an optimization: now other the queues can continue while this one is going. > But in any case, I think the patch is obviously correct and the wins are > sufficiently large to warrant a stable inclusion even if it isn't a > regression. If you're running SMP under an emulator where exits are expensive, then this wins. Under KVM it's marginal at best. Locking changes which are "obviously correct" make me nervous, too :) But IIRC last KS the argument is that not *enough* is going into stable, not that stable isn't stable enough. So maybe it's a non-problem? Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/6] staging: comedi: addi_apci_1564: cleanup v_ADDI_Interrupt()
On Fri, May 30, 2014 at 12:26 PM, Hartley Sweeten wrote: > On Thursday, May 29, 2014 9:44 PM, Chase Southwood wrote: >> Move the function apci1564_interrupt() from hwdrv_apci1564.c to >> addi_apci_1564.c. On moving, for now just strip out all of the >> code for interrupts that the driver does not yet support at this >> time. >> >> Rename the variable ui_InterruptStatus_1564 to ctrl, and change the return >> from IRQ_RETVAL(1) to IRQ_HANDLED. >> >> We also check the device is asserting the shared interrupt line and check >> that interrupts have been enabled. >> >> Signed-off-by: Chase Southwood >> Cc: Ian Abbott >> Cc: H Hartley Sweeten >> --- Hartley, Excellent...I will draft up a new version of this set based on all of your comments, but I will hold off on sending until I see if Ian has anything further to offer. Things are certainly looking better already though. Thanks, Chase -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the infiniband tree with the net-next tree
Hi all,
Today's linux-next merge of the infiniband tree got a conflict in
drivers/net/ethernet/mellanox/mlx4/cmd.c between commit 1a91de28831a
("mellanox: Logging message cleanups") from the net-next tree and
commit 97982f5a91e9 ("IB/mlx4: Preparation for VFs to issue/receive SMI
(QP0) requests/responses") from the infiniband tree.
I fixed it up (the latter seems to be a superset of the former, so I
just used that) and can carry the fix as necessary (no action is
required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: [RFC][PATCH 2/2] tux3: Use writeback hook to remove duplicated core code
On Sun, Jun 01, 2014 at 02:42:48PM -0700, Daniel Phillips wrote:
> Instead of re-implementing part of fs/fs-writeback.c, use a proposed
> net ->writeback super operation to drive delta writeback. For each
> inode that is cleaned, call inode_writeback_done(inode). For each
> inode that will be kept dirty in cache, call inode_writeback_touch
> so that the inode appears young to fs-writeback and does not trigger
> repeated ->writeback flushes.
>
> Signed-off-by: Daniel Phillips
I have not looked at the sanity of the tux3 writeback algorithm, so
I'm not commenting on whether it works or not. However, this caught
my eye:
> static void __tux3_clear_dirty_inode(struct inode *inode, unsigned delta)
> {
> struct tux3_inode *tuxnode = tux_inode(inode);
> -tux3_inode_wb_lock(inode);
> spin_lock(>i_lock);
> spin_lock(>lock);
> tux3_clear_dirty_inode_nolock(inode, delta, 0);
> spin_unlock(>lock);
> spin_unlock(>i_lock);
> -tux3_inode_wb_unlock(inode);
> +inode_writeback_done(inode);
> }
I get very worried whenever I see locks inside inode->i_lock. In
general, i_lock is supposed to be the innermost lock that is taken,
and there are very few exceptions to that - the inode LRU list is
one of the few.
I don't know what the tuxnode->lock is, but I found this:
* inode->i_lock
* tuxnode->lock (to protect tuxnode data)
* tuxnode->dirty_inodes_lock (for i_ddc->dirty_inodes,
* Note: timestamp can be updated
* outside inode->i_mutex)
and this:
* inode->i_lock
* tuxnode->lock
* sb->dirty_inodes_lock
Which indicates that you take a filesystem global lock a couple of
layers underneath the VFS per-inode i_lock. I'd suggest you want to
separate the use of the vfs inode ilock from the locking heirarchy
of the tux3 inode
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the arm-soc tree with the arm tree
On Sun, Jun 1, 2014 at 5:49 PM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the arm-soc tree got a conflict in
> arch/arm/mach-exynos/exynos.c between commits dfbdd3d55403 ("ARM: l2c:
> exynos: remove cache size override"), 25a9ef63cd2b ("ARM: l2c: exynos:
> convert to common l2c310 early resume functionality") and 15b0bc4041ba
> ("ARM: l2c: exynos: convert to generic l2c OF initialisation (and
> thereby fix it)") from the arm tree and commit b5b9324a6296 ("ARM:
> exynos: don't run exynos4 l2x0 setup on other platforms") from the
> arm-soc tree.
>
> I fixed it up (the former removes the code updated by the latter) and
> can carry the fix as necessary (no action is required).
Looks good. Thanks.
-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 1/2] Add a super operation for writeback
On Sun, Jun 01, 2014 at 02:41:02PM -0700, Daniel Phillips wrote:
> ---
> From: Daniel Phillips
> Subject: [PATCH] Add a super operation for writeback
>
> Add a "writeback" super operation to be called in the
> form:
>
> progress = sb->s_op->writeback(sb, , );
>
> The filesystem is expected to flush some inodes to disk
> and return progress of at least 1, or if no inodes are
> flushed, return progress of zero. The filesystem should
> try to flush at least the number of pages specified in
> *pages, or if that is not possible, return approximately
> the number of pages not flushed into *pages.
>
> Within the ->writeback callback, the filesystem should
> call inode_writeback_done(inode) for each inode flushed
> (and therefore set clean) or inode_writeback_touch(inode)
> for any inode that will be retained dirty in cache.
>
> Signed-off-by: Daniel Phillips
> Signed-off-by: OGAWA Hirofumi
> ---
>
> fs/fs-writeback.c | 59
> +---
> include/linux/fs.h |4 +++
> 2 files changed, 60 insertions(+), 3 deletions(-)
>
> diff -puN fs/fs-writeback.c~core-writeback fs/fs-writeback.c
> --- linux-tux3/fs/fs-writeback.c~core-writeback 2014-05-31
> 06:43:19.416031712 +0900
> +++ linux-tux3-hirofumi/fs/fs-writeback.c 2014-05-31 06:44:46.087904373
> +0900
> @@ -192,6 +192,35 @@ void inode_wb_list_del(struct inode *ino
> }
>
> /*
> + * Remove inode from writeback list if clean.
> + */
> +void inode_writeback_done(struct inode *inode)
> +{
> + struct backing_dev_info *bdi = inode_to_bdi(inode);
> +
> + spin_lock(>wb.list_lock);
> + spin_lock(>i_lock);
> + if (!(inode->i_state & I_DIRTY))
> + list_del_init(>i_wb_list);
> + spin_unlock(>i_lock);
> + spin_unlock(>wb.list_lock);
> +}
> +EXPORT_SYMBOL_GPL(inode_writeback_done);
> +
> +/*
> + * Add inode to writeback dirty list with current time.
> + */
> +void inode_writeback_touch(struct inode *inode)
> +{
> + struct backing_dev_info *bdi = inode->i_sb->s_bdi;
> + spin_lock(>wb.list_lock);
> + inode->dirtied_when = jiffies;
> + list_move(>i_wb_list, >wb.b_dirty);
> + spin_unlock(>wb.list_lock);
> +}
> +EXPORT_SYMBOL_GPL(inode_writeback_touch);
You should be able to use redirty_tail() for this
H - this is using the wb dirty lists and locks, but you
don't pass the wb structure to the writeback callout? That seem
wrong to me - why would you bother manipulating these lists if you
aren't using them to track dirty inodes in the first place?
> +
> +/*
> * Redirty an inode: set its when-it-was dirtied timestamp and move it to the
> * furthest end of its superblock's dirty-inode list.
> *
> @@ -593,9 +622,9 @@ static long writeback_chunk_size(struct
> *
> * Return the number of pages and/or inodes written.
> */
> -static long writeback_sb_inodes(struct super_block *sb,
> - struct bdi_writeback *wb,
> - struct wb_writeback_work *work)
> +static long __writeback_sb_inodes(struct super_block *sb,
> + struct bdi_writeback *wb,
> + struct wb_writeback_work *work)
> {
> struct writeback_control wbc = {
> .sync_mode = work->sync_mode,
> @@ -710,6 +739,30 @@ static long writeback_sb_inodes(struct s
> return wrote;
> }
>
> +static long writeback_sb_inodes(struct super_block *sb,
> + struct bdi_writeback *wb,
> + struct wb_writeback_work *work)
> +{
> + if (sb->s_op->writeback) {
> + struct writeback_control wbc = {
> + .sync_mode = work->sync_mode,
> + .tagged_writepages = work->tagged_writepages,
> + .for_kupdate= work->for_kupdate,
> + .for_background = work->for_background,
> + .for_sync = work->for_sync,
> + .range_cyclic = work->range_cyclic,
> + };
> + long ret;
> +
> + spin_unlock(>list_lock);
> + ret = sb->s_op->writeback(sb, , >nr_pages);
> + spin_lock(>list_lock);
> + return ret;
> + }
> +
> + return __writeback_sb_inodes(sb, wb, work);
> +}
The first thing that __writeback_sb_inodes() does is create a struct
writeback_control from the wb_writeback_work. That should be done
here and passed to __writeback_sb_inodes(), which should be renamed
"generic_writeback_sb_inodes()". Also, all the fields in the wbc
need to be initialised correctly (i.e including range_start/end).
Further, a writeback implementation will need to use the generic bdi
list and lock structures and so we need to pass the bdi_writeback.
Similarly, if we are going to pass nr_pages, we might as well pass
the entire work structure.
Finally, I don't like the way the
Donation From Mrs. Magaret Crawford
I am Mrs. Magaret Crawford. I have decided pick you for a donation. Please,
contact my attorney via email: mark.laws...@rogers.com
___
This email is intended for the designated recipient(s) only, and may be
confidential, non-public, proprietary, protected by the attorney/client or
other privilege. Unauthorized reading, distribution, copying or other use of
this communication is prohibited and may be unlawful. Receipt by anyone other
than the intended recipient(s) should not be deemed a waiver of any privilege
or protection. If you are not the intended recipient or if you believe that you
have received this email in error, please notify the sender immediately and
delete all copies from your computer system without reading, saving, or using
it in any manner. Although it has been checked for viruses and other malicious
software ("malware"), we do not warrant, represent or guarantee in any way that
this communication is free of malware or potentially damaging defects. All
liability for any actual or alleged loss, damage, or injury arising out of or
resulting in any way from the receipt, opening or use of this email is e
xpressly disclaimed.
__
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: vt6655: replace C99 style comments
Signed-off-by: James A Shackleford
---
drivers/staging/vt6655/baseband.c | 300 ++---
1 file changed, 150 insertions(+), 150 deletions(-)
diff --git a/drivers/staging/vt6655/baseband.c
b/drivers/staging/vt6655/baseband.c
index 6f95fb6..490ca96 100644
--- a/drivers/staging/vt6655/baseband.c
+++ b/drivers/staging/vt6655/baseband.c
@@ -57,7 +57,7 @@
#include "rf.h"
/*- Static Definitions -*/
-//static int msglevel=MSG_LEVEL_DEBUG;
+/* static int msglevel=MSG_LEVEL_DEBUG; */
static int msglevel = MSG_LEVEL_INFO;
/*- Static Classes */
@@ -785,7 +785,7 @@ unsigned char byVT3253B0_RFMD[CB_VT3253B0_INIT_FOR_RFMD][2]
= {
};
#define CB_VT3253B0_AGC_FOR_RFMD2959 195
-// For RFMD2959
+/* For RFMD2959 */
unsigned char byVT3253B0_AGC4_RFMD2959[CB_VT3253B0_AGC_FOR_RFMD2959][2] = {
{0xF0, 0x00},
{0xF1, 0x3E},
@@ -985,7 +985,7 @@ unsigned char
byVT3253B0_AGC4_RFMD2959[CB_VT3253B0_AGC_FOR_RFMD2959][2] = {
};
#define CB_VT3253B0_INIT_FOR_AIROHA2230 256
-// For AIROHA
+/* For AIROHA */
unsigned char byVT3253B0_AIROHA2230[CB_VT3253B0_INIT_FOR_AIROHA2230][2] = {
{0x00, 0x31},
{0x01, 0x00},
@@ -1095,7 +1095,7 @@ unsigned char
byVT3253B0_AIROHA2230[CB_VT3253B0_INIT_FOR_AIROHA2230][2] = {
{0x69, 0x00},
{0x6a, 0x00},
{0x6b, 0x00},
- {0x6c, 0x00}, //RobertYu:20050125, request by JJSue
+ {0x6c, 0x00}, /* RobertYu:20050125, request by JJSue */
{0x6d, 0x03},
{0x6e, 0x01},
{0x6f, 0x00},
@@ -1246,7 +1246,7 @@ unsigned char
byVT3253B0_AIROHA2230[CB_VT3253B0_INIT_FOR_AIROHA2230][2] = {
};
#define CB_VT3253B0_INIT_FOR_UW2451 256
-//For UW2451
+/* For UW2451 */
unsigned char byVT3253B0_UW2451[CB_VT3253B0_INIT_FOR_UW2451][2] = {
{0x00, 0x31},
{0x01, 0x00},
@@ -1356,7 +1356,7 @@ unsigned char
byVT3253B0_UW2451[CB_VT3253B0_INIT_FOR_UW2451][2] = {
{0x69, 0x00},
{0x6a, 0x00},
{0x6b, 0x00},
- {0x6c, 0x00}, //RobertYu:20050125, request by JJSue
+ {0x6c, 0x00}, /* RobertYu:20050125, request by JJSue */
{0x6d, 0x03},
{0x6e, 0x01},
{0x6f, 0x00},
@@ -1507,7 +1507,7 @@ unsigned char
byVT3253B0_UW2451[CB_VT3253B0_INIT_FOR_UW2451][2] = {
};
#define CB_VT3253B0_AGC 193
-// For AIROHA
+/* For AIROHA */
unsigned char byVT3253B0_AGC[CB_VT3253B0_AGC][2] = {
{0xF0, 0x00},
{0xF1, 0x00},
@@ -1783,29 +1783,29 @@ BBuGetFrameTime(
uRate = (unsigned int)awcFrameTime[uRateIdx];
- if (uRateIdx <= 3) { //CCK mode
- if (byPreambleType == 1) //Short
+ if (uRateIdx <= 3) { /* CCK mode */
+ if (byPreambleType == 1) /* Short */
uPreamble = 96;
else
uPreamble = 192;
- uFrameTime = (cbFrameLength * 80) / uRate; //?
+ uFrameTime = (cbFrameLength * 80) / uRate; /* ? */
uTmp = (uFrameTime * uRate) / 80;
if (cbFrameLength != uTmp)
uFrameTime++;
return uPreamble + uFrameTime;
} else {
- uFrameTime = (cbFrameLength * 8 + 22) / uRate; //
+ uFrameTime = (cbFrameLength * 8 + 22) / uRate; /* */
uTmp = ((uFrameTime * uRate) - 22) / 8;
if (cbFrameLength != uTmp)
uFrameTime++;
- uFrameTime = uFrameTime * 4;//???
+ uFrameTime = uFrameTime * 4;/* ??? */
if (byPktType != PK_TYPE_11A)
- uFrameTime += 6; //??
+ uFrameTime += 6; /* ?? */
- return 20 + uFrameTime; //??
+ return 20 + uFrameTime; /* ?? */
}
}
@@ -1856,7 +1856,7 @@ BBvCalculateParameter(
cbUsCount = cbBitCount / 2;
if (byPreambleType == 1)
*pbyPhySgn = 0x09;
- else // long preamble
+ else /* long preamble */
*pbyPhySgn = 0x01;
break;
@@ -1869,7 +1869,7 @@ BBvCalculateParameter(
cbUsCount++;
if (byPreambleType == 1)
*pbyPhySgn = 0x0a;
- else // long preamble
+ else /* long preamble */
*pbyPhySgn = 0x02;
break;
@@ -1886,79 +1886,79 @@ BBvCalculateParameter(
}
if (byPreambleType == 1)
*pbyPhySgn = 0x0b;
- else // long preamble
+ else /* long preamble */
*pbyPhySgn = 0x03;
break;
case RATE_6M:
- if (byPacketType ==
Re: [PATCH] net: ks8851: Don't use regulator_get_optional()
From: Stephen Boyd Date: Wed, 28 May 2014 13:11:12 -0700 > We shouldn't be using regulator_get_optional() here. These > regulators are always present as part of the physical design and > there isn't any way to use an internal regulator or change the > source of the reference voltage via software. Given that the only > users of this driver in the kernel are DT based, this change > should be transparent to them even if they don't specify any > supplies because the regulator framework will insert dummy > supplies as needed. > > Cc: Nishanth Menon > Cc: Mark Brown > Signed-off-by: Stephen Boyd This patch only applies to net-next, please make that explicit in your future submissions by saying something like "[PATCH net-next] ..." in your Subject line. Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH V2] regulator: DA9211 : new regulator driver
> -Original Message-
> From: Mark Brown [mailto:broo...@kernel.org]
> Sent: Monday, June 02, 2014 4:02 AM
> To: Opensource [James Seong-Won Ban]
> Cc: Liam Girdwood; Support Opensource; LKML; Guennadi Liakhovetski;
> David Dajun Chen
> Subject: Re: [PATCH V2] regulator: DA9211 : new regulator driver
>
> On Mon, May 19, 2014 at 02:45:51AM +0100, Opensource [James Seong-Won
> Ban] wrote:
>
> > This is the driver for the Dialog DA9211 Multi-phase 12A DC-DC Buck
> > Converter regulator. It communicates via an I2C bus to the device.
>
> I'm still really not convinced that the whole handling of the A and B
> settings is
> doing what it's supposed to be doing. Like I said before I know another one
> of your drivers is doing something similar (and not sharing the code!) but
> still...
>
> It looks like the driver is basically written so that register set A must be
> used
> when Linux is running and set B must be used in suspend mode but not
> everything seems joined up and consistent.
>
> > Signed-off-by: Opensource [James Seong-Won Ban]
> >
>
> Please just use your name in signoffs, the "Opensource []" garbage that your
> mail system inserts isn't helping.
it will be fixed in next PATCH.
>
> > +static int da9211_regulator_get_voltage_sel(struct regulator_dev
> > +*rdev) {
>
> > + /*
> > +* There are two voltage register set A & B for voltage ramping but
> > +* either one of then can be active therefore we first determine
> > +* the active register set.
> > +*/
> > + ret = regmap_read(chip->regmap, info->conf.reg, );
> > + if (ret < 0)
> > + return ret;
>
> This appears to be picking the active register set...
>
> > + /*
> > +* Regulator register set A/B is not selected through GPIO therefore
> > +* we use default register set A for voltage ramping.
> > +*/
> > + if (regulator->reg_rselect == DA9211_RSEL_NO_GPIO) {
> > + /* Select register set A */
> > + ret = regmap_update_bits(chip->regmap, info->conf.reg,
> > + info->conf.sel_mask,
> > + DA9211_VBUCKA_SEL_A);
> > + if (ret < 0)
> > + return ret;
> > +
> > + /* Set the voltage */
> > + return regmap_update_bits(chip->regmap, info->volt.reg_a,
> > +info->volt.v_mask, selector);
> > + }
>
> This forces to register set A.
>
> > + /*
> > +* Here regulator register set A/B is selected through GPIO.
> > +* Therefore we first determine the selected register set A/B and
> > +* then set the desired voltage for that register set A/B.
> > +*/
> > + ret = regmap_read(chip->regmap, info->conf.reg, );
> > + if (ret < 0)
> > + return ret;
>
> We don't appear to be controlling this GPIO - this then assumes that the
> GPIO can only be used for selecting suspend mode but doesn't impose any
> restrictions on this.
In this device, the values of selection register for A/B voltage are changed
automatically if the status of GPIO is changed.
So it is possible to know the status of GPIO through the value of register.
>
> > +static int da9211_regulator_set_suspend_voltage(struct regulator_dev
> *rdev,
> > + int uV)
> > +{
> > + struct da9211_regulator *regulator = rdev_get_drvdata(rdev);
> > + struct da9211_regulator_info *info = regulator->info;
> > + struct da9211 *chip = regulator->da9211;
> > + int ret;
> > +
> > + /* Select register set B for suspend voltage ramping. */
> > + if (regulator->reg_rselect == DA9211_RSEL_NO_GPIO) {
> > + ret = regmap_update_bits(chip->regmap, info->conf.reg,
> > + info->conf.sel_mask,
> > + DA9211_VBUCKA_SEL_B);
> > + if (ret < 0)
> > + return ret;
> > + }
>
> This appears to immediately change the active register set to set B which as I
> said previously is broken; we may not be suspended yet and clearly we
> haven't actually applied the desired setting yet either.
Your suggestion is correct. The code for the change of the active register
in the function should be removed. I will send PATCH again.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Linux 3.15-rc8 ... and merge window for 3.16
I was really hoping that rc7 would be the last rc, but it appears that
reality is once against conspiring against my well-laid plans, and is
forcing me to do an rc8. It's not like there were a lot of changes,
but the last-minute dcache fixes in particular made it not really sane
to just make a final release without another week of testing.
Now, normally, an rc8 isn't really a big deal - 3.15 is one of the
biggest (if not _the_ biggest) releases in a long time, and we do
rc8's with some regularity. It may not be every release, but I think
it's about a fifty-fifty chance whether any particular release goes to
rc8. So I shouldn't be upset, and I'm certainly not surprised.
No, the real reason I was hoping that we wouldn't need to do an rc8
for 3.15 is that school is out in two weeks, and we're doing our
family vacation immediately after that. And I'd hate to have yet
another "Linus is traveling during the merge window" thing. Normally I
have been luckier with my trips than that.
Now, I'll have internet, and I *could* do the merge window while on
vacation with the family. I'd just prefer not to.
SO... Let's try something new. I suspect most people are ready to
start the merge window, and we could try how it would be to overlap
the first week of the merge window with the last week of the previous
release. Most of the submaintainers already use git branches
actively, so I doubt anybody will find it too confusing if I end up
having a "next" branch for a week that contains the stuff I pull for
3.16.
So let's try to see how well that works - the last weeks of the
release tends to be me just waiting around to make sure nothing bad is
happening, so doing this kind of overlapping development *should* work
fine. Maybe it works so well that we'll end up doing it in the future
even if there *isn't* some kind of scheduling conflict that makes me
want to start the merge window before I'm 100% comfortable doing the
release for the previous version.
And it's not like I think rc8 is in any way broken. I just don't feel
comfortable doing a real 3.15 release without a _bit_ more time for
people to use the fixed dentry code.
Anyway, apart from the dcache changes, there's a lot of random smaller
stuff. One one-liner in particular is interesting: Minchan Kim had a
load that basically ate up all the kernel stack on x86-64, and so this
finally does something I've been trying to delay for a long time - it
expands the stack to 16kB. I think all other 64-bit architectures have
done that a long time ago already, so it's not exactly shocking, but
it's a somewhat fundamental change on one of the main architectures.
Linus
---
Aaron Lu (1):
ACPI / thermal: fix workqueue destroy order
Al Viro (6):
lift the "already marked killed" case into shrink_dentry_list()
split dentry_kill()
expand dentry_kill(dentry, 0) in shrink_dentry_list()
shrink_dentry_list(): take parent's ->d_lock earlier
dealing with the rest of shrink_dentry_list() livelock
dentry_kill() doesn't need the second argument now
Alex Smith (1):
MIPS: ptrace: Avoid smp_processor_id() in preemptible code
Alexander Graf (2):
KVM: PPC: Book3S: ifdef on CONFIG_KVM_BOOK3S_32_HANDLER for 32bit
KVM guest: Make pv trampoline code executable
Alexandre Belloni (2):
ARM: at91/dt: sam9260: correct external trigger value
ARM: at91: sam9260: fix compilation issues
Alexandre Courbot (1):
ARM: trusted_foundations: fix compile error on non-SMP
Alexey Charkov (1):
pinctrl: vt8500: Ensure value reg is updated when setting direction
Andrey Ryabinin (1):
ARM: 8051/1: put_user: fix possible data corruption in put_user
Andy Shevchenko (1):
dmaengine: dw: went back to plain {request,free}_irq() calls
Arnd Bergmann (4):
Input: fix ps2/serio module dependency
Input: atmel-wm97xx - only build for AVR32
dmaengine: omap: hide filter_fn for built-in drivers
dmaengine: sa11x0: remove broken #ifdef
Arun Kumar K (1):
ARM: dts: Remove g2d_pd node for exynos5420
Benjamin Herrenschmidt (1):
powerpc: Wire renameat2() syscall
Beomho Seo (1):
ARM: dts: fix incorrect ak8975 compatible for exynos4412-trats2 board
Bibek Basu (1):
cpufreq: remove race while accessing cur_policy
Chao Xie (1):
Input: pxa27x-keypad - fix generating scancode
Chris Wilson (3):
drm/i915: Fix dynamic allocation of physical handles
drm/i915: Only copy back the modified fields to userspace from execbuffer
drm/i915: Prevent negative relocation deltas from wrapping
Christian König (3):
drm/radeon: lower the ref * post PLL maximum once more
drm/radeon: avoid crash if VM command submission isn't available
drm/radeon: only allocate necessary size for vm bo list
Cornelia Huck (1):
KVM: s390: announce irqfd capability
Daniel Vetter (1):
drm/radeon: Resume fbcon last
David Jander (1):
clocksource: tcb_clksrc: Make
Re: [PATCH 1/1] md: Do only necessary operations when adding device to RO array
On Fri, 30 May 2014 13:17:14 + "Baldysiak, Pawel" wrote: > Commit 8313b8e57f55b15e5b7f7fc5d1630bbf686a9a97 changed > way of adding device to read-only array. Used routine > md_reap_sync_thread() which also trigger finish_reshape(), > can break reshape process, if it was restarted. Exactly how can it break? This is probably fixed by a couple of patches in my for-next branch which I will be sending to Linus shortly. NeilBrown > This part of function should do only necessary operations, that is: > 1) call ->spare_active > 2) clear saved_raid_disk if array is no longer degraded > > Signed-off-by: Pawel Baldysiak > Reviewed-by: Artur Paszkiewicz > > --- > drivers/md/md.c | 10 ++ > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/drivers/md/md.c b/drivers/md/md.c > index 237b7e0..cf073de2 100644 > --- a/drivers/md/md.c > +++ b/drivers/md/md.c > @@ -7820,11 +7820,13 @@ void md_check_recovery(struct mddev *mddev) > * As we only add devices that > are already in-sync, > * we can activate the spares > immediately. > */ > + struct md_rdev *rdev; >remove_and_add_spares(mddev, > NULL); > - /* There is no thread, but we > need to call > - * ->spare_active and clear > saved_raid_disk > - */ > - md_reap_sync_thread(mddev); > + > mddev->pers->spare_active(mddev); > + rdev_for_each(rdev, mddev) > + if > (!mddev->degraded || > + > test_bit(In_sync, >flags)) > + > rdev->saved_raid_disk = -1; >clear_bit(MD_RECOVERY_NEEDED, > >recovery); >goto unlock; >} > -- > 1.9.0 signature.asc Description: PGP signature
Re: [PATCH 2/2] lpc_eth: Use resource_size instead of computation
From: Benoit Taine Date: Wed, 28 May 2014 17:14:07 +0200 > @@ -1419,8 +1419,7 @@ static int lpc_eth_drv_probe(struct platform_device > *pdev) > > netdev_dbg(ndev, "IO address start :0x%08x\n", > res->start); > - netdev_dbg(ndev, "IO address size :%d\n", > - res->end - res->start + 1); > + netdev_dbg(ndev, "IO address size :%d\n", resource_size(res)); > netdev_dbg(ndev, "IO address (mapped) :0x%p\n", > pldat->net_base); Please replace all of this with %pR as suggested by Joe, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: ft1000: ft1000-usb: ft1000_debug.c: Fix style errors and some warnings.
Don't use spaces as tabs, and fix other style errors and warnings.
Signed-off-by: Thomas Wood
---
I think that this is correctly indented now, but I didn't touch the double
parentheses on line 322 because I wasn't sure if they were necessary or not.
drivers/staging/ft1000/ft1000-usb/ft1000_debug.c | 960 +++
1 file changed, 475 insertions(+), 485 deletions(-)
diff --git a/drivers/staging/ft1000/ft1000-usb/ft1000_debug.c
b/drivers/staging/ft1000/ft1000-usb/ft1000_debug.c
index a8945b7..af0844f 100644
--- a/drivers/staging/ft1000/ft1000-usb/ft1000_debug.c
+++ b/drivers/staging/ft1000/ft1000-usb/ft1000_debug.c
@@ -38,12 +38,12 @@
#include
#include "ft1000_usb.h"
-static int ft1000_flarion_cnt = 0;
+static int ft1000_flarion_cnt;
static int ft1000_open(struct inode *inode, struct file *file);
static unsigned int ft1000_poll_dev(struct file *file, poll_table *wait);
static long ft1000_ioctl(struct file *file, unsigned int command,
- unsigned long argument);
+ unsigned long argument);
static int ft1000_release(struct inode *inode, struct file *file);
/* List to free receive command buffer pool */
@@ -81,23 +81,23 @@ static const struct file_operations ft1000fops = {
*/
struct dpram_blk *ft1000_get_buffer(struct list_head *bufflist)
{
-unsigned long flags;
+ unsigned long flags;
struct dpram_blk *ptr;
-spin_lock_irqsave(_buff_lock, flags);
-/* Check if buffer is available */
-if (list_empty(bufflist)) {
-DEBUG("ft1000_get_buffer: No more buffer - %d\n", numofmsgbuf);
-ptr = NULL;
-} else {
-numofmsgbuf--;
- ptr = list_entry(bufflist->next, struct dpram_blk, list);
-list_del(>list);
-/* DEBUG("ft1000_get_buffer: number of free msg buffers = %d\n",
numofmsgbuf); */
-}
-spin_unlock_irqrestore(_buff_lock, flags);
-
-return ptr;
+ spin_lock_irqsave(_buff_lock, flags);
+ /* Check if buffer is available */
+ if (list_empty(bufflist)) {
+ DEBUG("ft1000_get_buffer: No more buffer - %d\n", numofmsgbuf);
+ ptr = NULL;
+ } else {
+ numofmsgbuf--;
+ ptr = list_entry(bufflist->next, struct dpram_blk, list);
+ list_del(>list);
+ /* DEBUG("ft1000_get_buffer: number of free msg buffers =
%d\n", numofmsgbuf); */
+ }
+ spin_unlock_irqrestore(_buff_lock, flags);
+
+ return ptr;
}
@@ -119,14 +119,14 @@ struct dpram_blk *ft1000_get_buffer(struct list_head
*bufflist)
*/
void ft1000_free_buffer(struct dpram_blk *pdpram_blk, struct list_head *plist)
{
-unsigned long flags;
-
-spin_lock_irqsave(_buff_lock, flags);
-/* Put memory back to list */
-list_add_tail(_blk->list, plist);
-numofmsgbuf++;
-/*DEBUG("ft1000_free_buffer: number of free msg buffers = %d\n",
numofmsgbuf); */
-spin_unlock_irqrestore(_buff_lock, flags);
+ unsigned long flags;
+
+ spin_lock_irqsave(_buff_lock, flags);
+ /* Put memory back to list */
+ list_add_tail(_blk->list, plist);
+ numofmsgbuf++;
+ /*DEBUG("ft1000_free_buffer: number of free msg buffers = %d\n",
numofmsgbuf); */
+ spin_unlock_irqrestore(_buff_lock, flags);
}
/*
@@ -145,25 +145,25 @@ void ft1000_free_buffer(struct dpram_blk *pdpram_blk,
struct list_head *plist)
*/
int ft1000_create_dev(struct ft1000_usb *dev)
{
-int result;
-int i;
+ int result;
+ int i;
struct dentry *dir, *file;
struct ft1000_debug_dirs *tmp;
-/* make a new device name */
-sprintf(dev->DeviceName, "%s%d", "FT1000_", dev->CardNumber);
+ /* make a new device name */
+ sprintf(dev->DeviceName, "%s%d", "FT1000_", dev->CardNumber);
-DEBUG("%s: number of instance = %d\n", __func__, ft1000_flarion_cnt);
-DEBUG("DeviceCreated = %x\n", dev->DeviceCreated);
+ DEBUG("%s: number of instance = %d\n", __func__, ft1000_flarion_cnt);
+ DEBUG("DeviceCreated = %x\n", dev->DeviceCreated);
-if (dev->DeviceCreated) {
- DEBUG("%s: \"%s\" already registered\n", __func__, dev->DeviceName);
- return -EIO;
-}
+ if (dev->DeviceCreated) {
+ DEBUG("%s: \"%s\" already registered\n", __func__,
dev->DeviceName);
+ return -EIO;
+ }
-/* register the device */
-DEBUG("%s: \"%s\" debugfs device registration\n", __func__,
dev->DeviceName);
+ /* register the device */
+ DEBUG("%s: \"%s\" debugfs device registration\n", __func__,
dev->DeviceName);
tmp = kmalloc(sizeof(struct ft1000_debug_dirs), GFP_KERNEL);
if (tmp == NULL) {
@@ -189,25 +189,25 @@ int ft1000_create_dev(struct ft1000_usb *dev)
tmp->int_number = dev->CardNumber;
list_add(&(tmp->list), &(dev->nodes.list));
-DEBUG("%s: registered debugfs directory \"%s\"\n", __func__,
dev->DeviceName);
-
-/*
Re: [PATCH 1/3] phy: exynos-dp-video: Use PTR_ERR_OR_ZERO
On Thursday, May 29, 2014 3:31 PM, Sachin Kamat wrote:
>
> PTR_ERR_OR_ZERO simplifies the code.
>
> Signed-off-by: Sachin Kamat
> Cc: Jingoo Han
Acked-by: Jingoo Han
Best regards,
Jingoo Han
> ---
> drivers/phy/phy-exynos-dp-video.c |5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/phy/phy-exynos-dp-video.c
> b/drivers/phy/phy-exynos-dp-video.c
> index 0786fef842e7..098f822a2fa4 100644
> --- a/drivers/phy/phy-exynos-dp-video.c
> +++ b/drivers/phy/phy-exynos-dp-video.c
> @@ -9,6 +9,7 @@
> * published by the Free Software Foundation.
> */
>
> +#include
> #include
> #include
> #include
> @@ -84,10 +85,8 @@ static int exynos_dp_video_phy_probe(struct
> platform_device *pdev)
> phy_set_drvdata(phy, state);
>
> phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
> - if (IS_ERR(phy_provider))
> - return PTR_ERR(phy_provider);
>
> - return 0;
> + return PTR_ERR_OR_ZERO(phy_provider);
> }
>
> static const struct of_device_id exynos_dp_video_phy_of_match[] = {
> --
> 1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 11/32] xfs: convert to struct inode_time
On Sun, Jun 01, 2014 at 09:36:26PM -0400, Nicolas Pitre wrote: > On Sun, 1 Jun 2014, Arnd Bergmann wrote: > > On Saturday 31 May 2014 11:46:16 Nicolas Pitre wrote: > > For actually running kernels beyond 2038, the best idea I've seen so > > far is to disallow all broken code at compile time. I don't see > > a choice but to audit the entire kernel for invalid uses on both > > 32 and 64 bit in the next few years. A lot of code will get changed > > in the process so we can actually keep running 32-bit kernels and > > file systems, but other code will likely go away: > > > > * any system calls that pass a time_t, timeval or timespec on > > 32-bit systems return -ENOSYS, to ensure all user land uses > > the replacements we will put into place > > * The definition of 'time_t', 'timval' and 'timespec' can be hidden > > from the kernel, and all code using it left out. > > * ext2 and ext3 file system code will have to be disabled, but that's > > file since ext4 can mount old file systems. > > Syscalls and libs can be "fixed". Existing filesystem content might > not. So if you need to mount some old media in read-write mode after > 2038 and that happens to content an ext2 or similarly limited filesystem > then it'd better just "work". Having the kernel refuse to modify the > filesystem would be unacceptable. We can already tell the VFS/filesystems not to update timestamps: inode->i_flags |= S_NOATIME | S_NOCMTIME; Just enforce that everywhere (i.e. notify_change()) rather than just on the IO path and the "legacy filesystem timestamp" problem is "solved". New interfaces need to return errors when an out-of-range parameter is set. And right now, >epoch dates are out of range for most filesystems, and so we need to handle that condition appropriately. Silent date overflow == filesystem corruption, and as such I'm going to error out such conditions in the filesystem regardless of what the userspace API says. Filesystems place all sorts of userspace visible limits on storage - ever tried to create a file >16TB on ext4? The on-disk format doesn't support it, so it returns an out of range error (E2BIG, I think) if you try. XFS, OTOH, handles this just fine and so it continues to work. It's exactly the same with timestamps - there's a physical limit to what can sanely be stored in any given filesystem and it's an *error condition* to go beyond that limit Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] staging: vt6655: fix sparse warning for static declarations
This patch fixes the following sparse warnings: iwctl.c:76:22: warning: symbol 'iwctl_get_wireless_stats' was not declared. Should it be static? iwctl.c:118:5: warning: symbol 'iwctl_giwname' was not declared. Should it be static? iwctl.c:131:5: warning: symbol 'iwctl_siwscan' was not declared. Should it be static? iwctl.c:192:5: warning: symbol 'iwctl_giwscan' was not declared. Should it be static? iwctl.c:344:5: warning: symbol 'iwctl_siwfreq' was not declared. Should it be static? iwctl.c:390:5: warning: symbol 'iwctl_giwfreq' was not declared. Should it be static? iwctl.c:420:5: warning: symbol 'iwctl_siwmode' was not declared. Should it be static? iwctl.c:486:5: warning: symbol 'iwctl_giwmode' was not declared. Should it be static? iwctl.c:520:5: warning: symbol 'iwctl_giwrange' was not declared. Should it be static? iwctl.c:626:5: warning: symbol 'iwctl_siwap' was not declared. Should it be static? iwctl.c:684:5: warning: symbol 'iwctl_giwap' was not declared. Should it be static? iwctl.c:711:5: warning: symbol 'iwctl_giwaplist' was not declared. Should it be static? iwctl.c:784:5: warning: symbol 'iwctl_siwessid' was not declared. Should it be static? iwctl.c:893:5: warning: symbol 'iwctl_giwessid' was not declared. Should it be static? iwctl.c:923:5: warning: symbol 'iwctl_siwrate' was not declared. Should it be static? iwctl.c:1004:5: warning: symbol 'iwctl_giwrate' was not declared. Should it be static? iwctl.c:1049:5: warning: symbol 'iwctl_siwrts' was not declared. Should it be static? iwctl.c:1077:5: warning: symbol 'iwctl_giwrts' was not declared. Should it be static? iwctl.c:1096:5: warning: symbol 'iwctl_siwfrag' was not declared. Should it be static? iwctl.c:1123:5: warning: symbol 'iwctl_giwfrag' was not declared. Should it be static? iwctl.c:1141:5: warning: symbol 'iwctl_siwretry' was not declared. Should it be static? iwctl.c:1176:5: warning: symbol 'iwctl_giwretry' was not declared. Should it be static? iwctl.c:1205:5: warning: symbol 'iwctl_siwencode' was not declared. Should it be static? iwctl.c:1336:5: warning: symbol 'iwctl_giwencode' was not declared. Should it be static? iwctl.c:1398:5: warning: symbol 'iwctl_siwpower' was not declared. Should it be static? iwctl.c:1448:5: warning: symbol 'iwctl_giwpower' was not declared. Should it be static? iwctl.c:1478:5: warning: symbol 'iwctl_giwsens' was not declared. Should it be static? iwctl.c:1502:5: warning: symbol 'iwctl_siwauth' was not declared. Should it be static? iwctl.c:1603:5: warning: symbol 'iwctl_giwauth' was not declared. Should it be static? iwctl.c:1611:5: warning: symbol 'iwctl_siwgenie' was not declared. Should it be static? iwctl.c:1644:5: warning: symbol 'iwctl_giwgenie' was not declared. Should it be static? iwctl.c:1669:5: warning: symbol 'iwctl_siwencodeext' was not declared. Should it be static? iwctl.c:1783:5: warning: symbol 'iwctl_giwencodeext' was not declared. Should it be static? iwctl.c:1791:5: warning: symbol 'iwctl_siwmlme' was not declared. Should it be static? iwctl.c:1900:21: warning: symbol 'iwctl_private_args' was not declared. Should it be static? iwctl.c:1906:33: warning: symbol 'iwctl_handler_def' was not declared. Should it be static? Signed-off-by: James A Shackleford --- drivers/staging/vt6655/iwctl.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/vt6655/iwctl.c b/drivers/staging/vt6655/iwctl.c index ae2b87f..ba50d7f 100644 --- a/drivers/staging/vt6655/iwctl.c +++ b/drivers/staging/vt6655/iwctl.c @@ -33,6 +33,7 @@ #include "device.h" #include "ioctl.h" #include "iocmd.h" +#include "iwctl.h" #include "mac.h" #include "card.h" #include "hostap.h" -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] staging: vt6655: update out-of-date function declaration
The function iwctl_siwscan() is defined in iwctl.c as:
int iwctl_siwscan(struct net_device *dev,
struct iw_request_info *info,
struct iw_point *wrq,
char *extra)
{
...
This patch updates iwctl.h so that the type of the 3rd parameter (*wqr) in the
function declaration matches the definition.
Signed-off-by: James A Shackleford
---
drivers/staging/vt6655/iwctl.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/vt6655/iwctl.h b/drivers/staging/vt6655/iwctl.h
index 871bd7c..4ad5e48 100644
--- a/drivers/staging/vt6655/iwctl.h
+++ b/drivers/staging/vt6655/iwctl.h
@@ -168,7 +168,7 @@ int iwctl_giwscan(struct net_device *dev,
int iwctl_siwscan(struct net_device *dev,
struct iw_request_info *info,
- struct iw_param *wrq,
+ struct iw_point *wrq,
char *extra);
//2008-0409-07, by Einsn Liu
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] staging: vt6655: update iwctl_private_args extern declaration
Update declaration of iwctl_private_args to match definition in iwctl.c Signed-off-by: James A Shackleford --- drivers/staging/vt6655/iwctl.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/vt6655/iwctl.h b/drivers/staging/vt6655/iwctl.h index 4ad5e48..10564b4 100644 --- a/drivers/staging/vt6655/iwctl.h +++ b/drivers/staging/vt6655/iwctl.h @@ -211,6 +211,6 @@ int iwctl_siwmlme(struct net_device *dev, //End Add -- //2008-0409-07, by Einsn Liu extern const struct iw_handler_def iwctl_handler_def; -extern const struct iw_priv_args iwctl_private_args; +extern struct iw_priv_args iwctl_private_args[]; #endif // __IWCTL_H__ -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next V6 0/2] cpumask,net: Affinity hint helper function
From: Amir Vadai Date: Sun, 25 May 2014 17:47:25 +0300 > This patchset will set affinity hint to influence IRQs to be allocated on the > same NUMA node as the one where the card resides. As discussed in > http://www.spinics.net/lists/netdev/msg271497.html > > If the number of IRQs allocated is greater than the number of local NUMA > cores, all > local cores will be used first, and the rest of the IRQs will be on a remote > NUMA node. > If no NUMA support - IRQ's and cores will be mapped 1:1 > > Since the utility function to calculate the mapping could be useful in other > mq > drivers in the kernel, it was added to cpumask.[ch] > > This patchset was tested and applied on top of net-next since the first > consumer is a network device (mlx4_en). Over commit 506724c: "tg3: Override > clock, link aware and link idle mode during NVRAM dump" > > I couldn't find a maintainer for cpumask.c, so only added the kernel mailing > list Applied to net-next, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i2c: busses: i2c-pxa.c: Fix for possible null pointer dereference
On Monday, June 02, 2014 5:27 AM, Wolfram Sang wrote:
> On Sat, May 17, 2014 at 07:14:08PM +0200, Rickard Strandqvist wrote:
> > There is otherwise a risk of a possible null pointer dereference.
> >
> > Was largely found by using a static code analysis program called cppcheck.
>
> It is useful to put the output of the analyzer here.
>
> >
> > Signed-off-by: Rickard Strandqvist
> > ---
> > drivers/i2c/busses/i2c-pxa.c |4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
> > index bbe6dfb..dbe5ebe 100644
> > --- a/drivers/i2c/busses/i2c-pxa.c
> > +++ b/drivers/i2c/busses/i2c-pxa.c
> > @@ -1269,7 +1269,9 @@ eremap:
> > eclk:
> > kfree(i2c);
> > emalloc:
> > - release_mem_region(res->start, resource_size(res));
> > + if(res) {
> > + release_mem_region(res->start, resource_size(res));
> > + }
>
> The proper fix is to move the release to the proper place, before kfree.
> Even better would probably be a devm_* conversion.
+1
I agree with Wolfram Sang's opinion. Please call release_mem_region()
prior to kfree().
One more thing, don't use braces when a single statement
is used. Please refer to 'Chapter 3: Placing Braces and Spaces'
of 'Documentation/CodingStyle'.
Best regards,
Jingoo Han
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: sparc: kernel: smp_64.c: Optimization of the Code
From: Rickard Strandqvist Date: Sun, 1 Jun 2014 23:48:18 +0200 > From what I know, AND is faster then modulo. > Not sure if this is worth changing though. > > Signed-off-by: Rickard Strandqvist This code came from the IA-64 arch code, so you probably want to fix either both or neither. I'd say neither, this is not a performance critical path and the intent is clearer when expressed as a modulus. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] usb/ftdi_sio: Add support for setting CBUS pins on FT232H
On 02.06.2014 03:38, Greg KH wrote: >> Yes but... I should have avoided the term "GPIO".> No, you used the right term :) Sorry for using the right term :) > No, I am not going to add custom ioctls to a single driver for this. I did neither request nor expect that - did it sound that way? > It would not be lost at all, you can see that relationship in sysfs > between the gpio device and the tty device, they are both attached to > the same "parent" usb interface. Ok, I understand. This is a real argument for the GPIO stuff. I'm just beginning to understand that using the GPIO stuff will make everyone happy. > This comes up every 6 months or so, you aren't the first to ask for > custom ioctls / sysfs files for this chip. But no one seems to want to > to do the work to make it a proper gpio device, which is sad :( Ok, ok. I will do it but it will take some time. I will resend my two patches then. Kind regards Philipp -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arm: dma-mapping: fix potential build error under !CMA
This patch fixes build error under !CONFIG_CMA. dev_get_cma_area can be used
when CMA is disabled when the bellow patch is appied.
"arm: dma-mapping: add checking cma area initialized"
https://lkml.org/lkml/2014/5/22/35
arch/arm/mm/dma-mapping.c: In function 'atomic_pool_init':
arch/arm/mm/dma-mapping.c:361:2: error: implicit declaration of function
'dev_get_cma_area' [-Werror=implicit-function-declaration]
Signed-off-by: Chanho Min
---
arch/arm/include/asm/dma-contiguous.h |2 +-
include/asm-generic/dma-contiguous.h | 13 +++--
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/dma-contiguous.h
b/arch/arm/include/asm/dma-contiguous.h
index 3ed37b4..56c17bc 100644
--- a/arch/arm/include/asm/dma-contiguous.h
+++ b/arch/arm/include/asm/dma-contiguous.h
@@ -2,11 +2,11 @@
#define ASMARM_DMA_CONTIGUOUS_H
#ifdef __KERNEL__
-#ifdef CONFIG_CMA
#include
#include
+#ifdef CONFIG_CMA
void dma_contiguous_early_fixup(phys_addr_t base, unsigned long size);
#endif
diff --git a/include/asm-generic/dma-contiguous.h
b/include/asm-generic/dma-contiguous.h
index 294b1e7..3d48460 100644
--- a/include/asm-generic/dma-contiguous.h
+++ b/include/asm-generic/dma-contiguous.h
@@ -2,11 +2,11 @@
#define ASM_DMA_CONTIGUOUS_H
#ifdef __KERNEL__
-#ifdef CONFIG_CMA
#include
#include
+#ifdef CONFIG_CMA
static inline struct cma *dev_get_cma_area(struct device *dev)
{
if (dev && dev->cma_area)
@@ -22,7 +22,16 @@ static inline void dev_set_cma_area(struct device *dev,
struct cma *cma)
dma_contiguous_default_area = cma;
}
-#endif
+#else
+static inline struct cma *dev_get_cma_area(struct device *dev)
+{
+ return NULL;
+}
+
+static inline void dev_set_cma_area(struct device *dev, struct cma *cma)
+{
+}
#endif
#endif
+#endif
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] usb/ftdi_sio: Add support for setting CBUS pins on FT232H
On Mon, Jun 02, 2014 at 02:57:39AM +0200, Philipp Hachtmann wrote: > On 01.06.2014 04:31, Greg KH wrote: > >As they are GPIO pins on this device, it should be the subsystem that > >controls it. That way, userspace programs that are used to talk to a > >GPIO device will "just work", and not have to be customized just for > >this specific device and sysfs file. > > >So please use the GPIO subsystem instead of creating your own interface. > > Yes but... I should have avoided the term "GPIO". No, you used the right term :) > The FT232H (and other chips of the family) are communication controller ICs > that support several operation modes. The usb-serial driver partially > supports the chips' functionalities by supplying a tty device to the system. > At least the FT232H has something called CBUS: Four (!) bits of GPIO that > *might* be available depending on the device's configuration stored in an > EEPROM attached to the chip. For example if the chip is in sync FIFO mode, > only two of those bits reach the chip's surface. > > I'll try to discuss two use cases: > > 1. Someone builds hardware with an FT chip and some general functionality > attached to the four usable CBUS lines, totally unrelated to the chip's > FIFO/UART etc. functionality. > In that case I would strongly recommend to register the CBUS stuff with the > GPIO subsystem. The user then could - as you noted - run any program used to > deal with official GPIO pins on top of the four lines. > But I think that this use case is one of the less likely ones. But you don't know... > 2. Someone builds hardware which uses some CBUS pins to control external > circuitry that also uses the UART/FIFO interface. Both with tight functional > integration. The CBUS pins become something in the rank of modem status > lines. > An application that uses the port also wants to easily access the CBUS pins. > And it really knows what it does because it knows what it is doing. From my > point of view this is the more common use case. > > Consequently the best way to cover the CBUS pins would be via the device's > ioctls. But as the device is driven by common tty and usb-serial code which > handles the ioctls I currently see how to achieve that without breaking a > lot. No, I am not going to add custom ioctls to a single driver for this. Please just use the gpio subsystem, that is what it is there for, and if you need to interleave led flashing or modem control line signals with the data you are sending, then just do that in your program. It's no different than sending custom ioctls, you have to know what you are doing. This comes up every 6 months or so, you aren't the first to ask for custom ioctls / sysfs files for this chip. But no one seems to want to to do the work to make it a proper gpio device, which is sad :( > For me personally it's most important to get access to CBUS in any way where > the relation of the tty and the CBUS is *not* lost. It would not be lost at all, you can see that relationship in sysfs between the gpio device and the tty device, they are both attached to the same "parent" usb interface. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 11/32] xfs: convert to struct inode_time
On Sun, 1 Jun 2014, Arnd Bergmann wrote: > On Saturday 31 May 2014 11:46:16 Nicolas Pitre wrote: > > > readonly if not in reality than in practice. > > > > For those (legacy) filesystems with a signed 32-bit timestamps, any > > attempt to create a timestamp past Jan 19 03:14:06 2038 UTC should be > > (silently) clamped to 0x7fff and that value (the last representable > > time) used as an overflow indicator. The filesystem driver should > > convert that value into a corresponding overflow value for whatever > > kernel internal time representation being used when read back, and this > > should be propagated up to user space. It should not be a hard error > > otherwise, as you rightfully stated, everything non read-only would come > > to a halt on that day. > > I don't think there is much of a difference between not being able to > write at all and all newly written files having the same timestamp, > causing random things to break differently. Well, in one case you have a crash certitude. In the other case you have some probability that your system might still be usable. > The clamp to the maximum supported time stamp sounds like a reasonable > choice for 'utimens' and related syscalls for the case of someone > setting an arbitrary future date beyond what the file system can > represent. Then again, I don't see a reason why that shouldn't just > cause an error to be returned. Resiliance is better than outright failure. > For actually running kernels beyond 2038, the best idea I've seen so > far is to disallow all broken code at compile time. I don't see > a choice but to audit the entire kernel for invalid uses on both > 32 and 64 bit in the next few years. A lot of code will get changed > in the process so we can actually keep running 32-bit kernels and > file systems, but other code will likely go away: > > * any system calls that pass a time_t, timeval or timespec on > 32-bit systems return -ENOSYS, to ensure all user land uses > the replacements we will put into place > * The definition of 'time_t', 'timval' and 'timespec' can be hidden > from the kernel, and all code using it left out. > * ext2 and ext3 file system code will have to be disabled, but that's > file since ext4 can mount old file systems. Syscalls and libs can be "fixed". Existing filesystem content might not. So if you need to mount some old media in read-write mode after 2038 and that happens to content an ext2 or similarly limited filesystem then it'd better just "work". Having the kernel refuse to modify the filesystem would be unacceptable. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] uprobes/x86: Rename arch_uprobe->def into ->dflt, minor comment updates
(2014/06/02 4:25), Oleg Nesterov wrote:
> Purely cosmetic, no changes in .o,
>
> 1. As Jim pointed out arch_uprobe->def looks ambiguous, rename it to
>->dflt.
>
> 2. Add the comment into default_post_xol_op() to explain "regs->sp +=".
>
> 3. Remove the stale part of the comment in arch_uprobe_analyze_insn().
>
> Suggested-by: Jim Keniston
> Signed-off-by: Oleg Nesterov
Looks OK for me :)
Reviewed-by: Masami Hiramatsu
> ---
> arch/x86/include/asm/uprobes.h |2 +-
> arch/x86/kernel/uprobes.c | 37 ++---
> 2 files changed, 19 insertions(+), 20 deletions(-)
>
> diff --git a/arch/x86/include/asm/uprobes.h b/arch/x86/include/asm/uprobes.h
> index 7be3c07..b3d9442 100644
> --- a/arch/x86/include/asm/uprobes.h
> +++ b/arch/x86/include/asm/uprobes.h
> @@ -52,7 +52,7 @@ struct arch_uprobe {
> struct {
> u8 fixups;
> u8 ilen;
> - } def;
> + } dflt;
> };
> };
>
> diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
> index fcf6279..33e239f 100644
> --- a/arch/x86/kernel/uprobes.c
> +++ b/arch/x86/kernel/uprobes.c
> @@ -254,7 +254,7 @@ static inline bool is_64bit_mm(struct mm_struct *mm)
> * If arch_uprobe->insn doesn't use rip-relative addressing, return
> * immediately. Otherwise, rewrite the instruction so that it accesses
> * its memory operand indirectly through a scratch register. Set
> - * def->fixups accordingly. (The contents of the scratch register
> + * dflt->fixups accordingly. (The contents of the scratch register
> * will be saved before we single-step the modified instruction,
> * and restored afterward).
> *
> @@ -372,14 +372,14 @@ static void riprel_analyze(struct arch_uprobe *auprobe,
> struct insn *insn)
>*/
> if (reg != 6 && reg2 != 6) {
> reg2 = 6;
> - auprobe->def.fixups |= UPROBE_FIX_RIP_SI;
> + auprobe->dflt.fixups |= UPROBE_FIX_RIP_SI;
> } else if (reg != 7 && reg2 != 7) {
> reg2 = 7;
> - auprobe->def.fixups |= UPROBE_FIX_RIP_DI;
> + auprobe->dflt.fixups |= UPROBE_FIX_RIP_DI;
> /* TODO (paranoia): force maskmovq to not use di */
> } else {
> reg2 = 3;
> - auprobe->def.fixups |= UPROBE_FIX_RIP_BX;
> + auprobe->dflt.fixups |= UPROBE_FIX_RIP_BX;
> }
> /*
>* Point cursor at the modrm byte. The next 4 bytes are the
> @@ -398,9 +398,9 @@ static void riprel_analyze(struct arch_uprobe *auprobe,
> struct insn *insn)
> static inline unsigned long *
> scratch_reg(struct arch_uprobe *auprobe, struct pt_regs *regs)
> {
> - if (auprobe->def.fixups & UPROBE_FIX_RIP_SI)
> + if (auprobe->dflt.fixups & UPROBE_FIX_RIP_SI)
> return >si;
> - if (auprobe->def.fixups & UPROBE_FIX_RIP_DI)
> + if (auprobe->dflt.fixups & UPROBE_FIX_RIP_DI)
> return >di;
> return >bx;
> }
> @@ -411,18 +411,18 @@ scratch_reg(struct arch_uprobe *auprobe, struct pt_regs
> *regs)
> */
> static void riprel_pre_xol(struct arch_uprobe *auprobe, struct pt_regs *regs)
> {
> - if (auprobe->def.fixups & UPROBE_FIX_RIP_MASK) {
> + if (auprobe->dflt.fixups & UPROBE_FIX_RIP_MASK) {
> struct uprobe_task *utask = current->utask;
> unsigned long *sr = scratch_reg(auprobe, regs);
>
> utask->autask.saved_scratch_register = *sr;
> - *sr = utask->vaddr + auprobe->def.ilen;
> + *sr = utask->vaddr + auprobe->dflt.ilen;
> }
> }
>
> static void riprel_post_xol(struct arch_uprobe *auprobe, struct pt_regs
> *regs)
> {
> - if (auprobe->def.fixups & UPROBE_FIX_RIP_MASK) {
> + if (auprobe->dflt.fixups & UPROBE_FIX_RIP_MASK) {
> struct uprobe_task *utask = current->utask;
> unsigned long *sr = scratch_reg(auprobe, regs);
>
> @@ -499,16 +499,16 @@ static int default_post_xol_op(struct arch_uprobe
> *auprobe, struct pt_regs *regs
> struct uprobe_task *utask = current->utask;
>
> riprel_post_xol(auprobe, regs);
> - if (auprobe->def.fixups & UPROBE_FIX_IP) {
> + if (auprobe->dflt.fixups & UPROBE_FIX_IP) {
> long correction = utask->vaddr - utask->xol_vaddr;
> regs->ip += correction;
> - } else if (auprobe->def.fixups & UPROBE_FIX_CALL) {
> - regs->sp += sizeof_long();
> - if (push_ret_address(regs, utask->vaddr + auprobe->def.ilen))
> + } else if (auprobe->dflt.fixups & UPROBE_FIX_CALL) {
> + regs->sp += sizeof_long(); /* Pop incorrect return address */
> + if (push_ret_address(regs, utask->vaddr + auprobe->dflt.ilen))
> return -ERESTART;
> }
> /* popf; tell the caller to not touch TF */
> - if (auprobe->def.fixups & UPROBE_FIX_SETF)
> + if
Re: [PATCH 11/11] drivers/net/ethernet/intel: Remove useless return variables
On Sat, 2014-05-31 at 10:14 -0300, Peter Senna Tschudin wrote: > This patch remove variables that are initialized with a constant, > are never updated, and are only used as parameter of return. > Return the constant instead of using a variable. > > Verified by compilation only. > > The coccinelle script that find and fixes this issue is: > // > @@ > type T; > constant C; > identifier ret; > @@ > - T ret = C; > ... when != ret > when strict > return > - ret > + C > ; > // > > Signed-off-by: Peter Senna Tschudin > > --- > drivers/net/ethernet/intel/i40e/i40e_adminq.c | 12 +++- > drivers/net/ethernet/intel/i40evf/i40e_adminq.c | 12 +++- > drivers/net/ethernet/intel/igb/e1000_82575.c| 22 > -- > 3 files changed, 14 insertions(+), 32 deletions(-) I have added this patch to my queue, thanks. signature.asc Description: This is a digitally signed message part
Re: 3.14.1 network issue with rtl81xx chip
On 2014-06-01 19:42, Francois Romieu wrote: > Udo van den Heuvel : > [...] >> On two boxes with rtl network chip I see connections going down. > > Do you notice netdev watchdog messages in the kernel log ? I do not see messages that look like that. >> 3.14.1 has the issue. > > Does it qualify as a (recent ?) regression or is it a fresh new setup ? This machine has been running for over a year and some time ago the problem occurred. Same for the other problem machine which is even older. Udo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] usb/ftdi_sio: Add support for setting CBUS pins on FT232H
On 01.06.2014 04:31, Greg KH wrote: As they are GPIO pins on this device, it should be the subsystem that controls it. That way, userspace programs that are used to talk to a GPIO device will "just work", and not have to be customized just for this specific device and sysfs file. So please use the GPIO subsystem instead of creating your own interface. Yes but... I should have avoided the term "GPIO". The FT232H (and other chips of the family) are communication controller ICs that support several operation modes. The usb-serial driver partially supports the chips' functionalities by supplying a tty device to the system. At least the FT232H has something called CBUS: Four (!) bits of GPIO that *might* be available depending on the device's configuration stored in an EEPROM attached to the chip. For example if the chip is in sync FIFO mode, only two of those bits reach the chip's surface. I'll try to discuss two use cases: 1. Someone builds hardware with an FT chip and some general functionality attached to the four usable CBUS lines, totally unrelated to the chip's FIFO/UART etc. functionality. In that case I would strongly recommend to register the CBUS stuff with the GPIO subsystem. The user then could - as you noted - run any program used to deal with official GPIO pins on top of the four lines. But I think that this use case is one of the less likely ones. 2. Someone builds hardware which uses some CBUS pins to control external circuitry that also uses the UART/FIFO interface. Both with tight functional integration. The CBUS pins become something in the rank of modem status lines. An application that uses the port also wants to easily access the CBUS pins. And it really knows what it does because it knows what it is doing. From my point of view this is the more common use case. Consequently the best way to cover the CBUS pins would be via the device's ioctls. But as the device is driven by common tty and usb-serial code which handles the ioctls I currently see how to achieve that without breaking a lot. The second best way I see is adding a property to sysfs. This would already help a lot. A program knowing about the hardware then *can* sanely play with the CBUS. Adding the functionality to sysfs should not interfere with a possible provision of an "official" GPIO device (struct gpio_chip). For me personally it's most important to get access to CBUS in any way where the relation of the tty and the CBUS is *not* lost. I see no point in exposing the CBUS to any userspace application that thinks it can play blinkenlights on them. But I also see no problem if someone wants the possibility and adds general GPIO support. The patch will provide a stable base to do so. So please consider the patches as a starting point. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the arm-soc tree with the arm tree
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-exynos/exynos.c between commits dfbdd3d55403 ("ARM: l2c:
exynos: remove cache size override"), 25a9ef63cd2b ("ARM: l2c: exynos:
convert to common l2c310 early resume functionality") and 15b0bc4041ba
("ARM: l2c: exynos: convert to generic l2c OF initialisation (and
thereby fix it)") from the arm tree and commit b5b9324a6296 ("ARM:
exynos: don't run exynos4 l2x0 setup on other platforms") from the
arm-soc tree.
I fixed it up (the former removes the code updated by the latter) and
can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/mach-exynos/exynos.c
index a763c0862da9,bc43e22693b7..
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@@ -305,17 -246,25 +243,6 @@@ void __init exynos_init_io(void
exynos_map_io();
}
- struct bus_type exynos_subsys = {
- .name = "exynos-core",
- .dev_name = "exynos-core",
- };
-
- static int __init exynos_core_init(void)
-static int __init exynos4_l2x0_cache_init(void)
--{
- return subsys_system_register(_subsys, NULL);
- int ret;
-
- if (!soc_is_exynos4())
- return 0;
-
- ret = l2x0_of_init(L2_AUX_VAL, L2_AUX_MASK);
- if (ret)
- return ret;
-
- if (IS_ENABLED(CONFIG_S5P_SLEEP)) {
- l2x0_regs_phys = virt_to_phys(_saved_regs);
- clean_dcache_area(_regs_phys, sizeof(unsigned long));
- }
- return 0;
--}
- core_initcall(exynos_core_init);
-early_initcall(exynos4_l2x0_cache_init);
--
static void __init exynos_dt_machine_init(void)
{
struct device_node *i2c_np;
signature.asc
Description: PGP signature
Re: [PATCH v3] zram: remove global tb_lock with fine grain lock
Hello Weijie, Thanks for resending. Below are mostly nitpicks. On Fri, May 30, 2014 at 04:34:44PM +0800, Weijie Yang wrote: > Currently, we use a rwlock tb_lock to protect concurrent access to > the whole zram meta table. However, according to the actual access model, > there is only a small chance for upper user to access the same table[index], > so the current lock granularity is too big. > > The idea of optimization is to change the lock granularity from whole > meta table to per table entry (table -> table[index]), so that we can > protect concurrent access to the same table[index], meanwhile allow > the maximum concurrency. > With this in mind, several kinds of locks which could be used as a > per-entry lock were tested and compared: > > Test environment: > x86-64 Intel Core2 Q8400, system memory 4GB, Ubuntu 12.04, > kernel v3.15.0-rc3 as base, zram with 4 max_comp_streams LZO. > > iozone test: > iozone -t 4 -R -r 16K -s 200M -I +Z > (1GB zram with ext4 filesystem, take the average of 10 tests, KB/s) > > Test base CASspinlockrwlock bit_spinlock > --- > Initial write 1381094 1425435 1422860 1423075 1421521 >Rewrite 1529479 1641199 1668762 1672855 1654910 > Read 8468009 11324979 11305569 7273 10997202 >Re-read 8467476 11260914 11248059 11145336 10906486 > Reverse Read 6821393 8106334 8282174 8279195 8109186 >Stride read 7191093 8994306 9153982 8961224 9004434 >Random read 7156353 8957932 9167098 8980465 8940476 > Mixed workload 4172747 5680814 5927825 5489578 5972253 > Random write 1483044 1605588 1594329 1600453 1596010 > Pwrite 1276644 1303108 1311612 1314228 1300960 > Pread 4324337 4632869 4618386 4457870 4500166 > > To enhance the possibility of access the same table[index] concurrently, > set zram a small disksize(10MB) and let threads run with large loop count. > > fio test: > fio --bs=32k --randrepeat=1 --randseed=100 --refill_buffers > --scramble_buffers=1 --direct=1 --loops=3000 --numjobs=4 > --filename=/dev/zram0 --name=seq-write --rw=write --stonewall > --name=seq-read --rw=read --stonewall --name=seq-readwrite > --rw=rw --stonewall --name=rand-readwrite --rw=randrw --stonewall > (10MB zram raw block device, take the average of 10 tests, KB/s) > > Test base CASspinlockrwlock bit_spinlock > - > seq-write 933789 999357 1003298995961 1001958 > seq-read 5634130 6577930 6380861 6243912 6230006 >seq-rw 1405687 1638117 1640256 1633903 1634459 > rand-rw 1386119 1614664 1617211 1609267 1612471 > > All the optimization methods show a higher performance than the base, > however, it is hard to say which method is the most appropriate. > > On the other hand, zram is mostly used on small embedded system, so we > don't want to increase any memory footprint. > > This patch pick the bit_spinlock method, pack object size and page_flag > into an unsigned long table.value, so as to not increase any memory > overhead on both 32-bit and 64-bit system. > > On the third hand, even though different kinds of locks have different > performances, we can ignore this difference, because: > if zram is used as zram swapfile, the swap subsystem can prevent concurrent > access to the same swapslot; > if zram is used as zram-blk for set up filesystem on it, the upper filesystem > and the page cache also prevent concurrent access of the same block mostly. > So we can ignore the different performances among locks. Nice description. :) > > Changes since v1: https://lkml.org/lkml/2014/5/5/1 > - replace CAS method with bit_spinlock method > - rename zram_test_flag() to zram_test_zero() > - add some comments > > Changes since v2: https://lkml.org/lkml/2014/5/15/113 > - change size type from int to size_t in zram_set_obj_size() > - refactor zram_set_obj_size() to make it readable > - add comments > > Signed-off-by: Weijie Yang > --- > drivers/block/zram/zram_drv.c | 89 > - > drivers/block/zram/zram_drv.h | 22 +++--- > 2 files changed, 68 insertions(+), 43 deletions(-) > > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c > index 9849b52..166e882 100644 > --- a/drivers/block/zram/zram_drv.c > +++ b/drivers/block/zram/zram_drv.c > @@ -179,23 +179,32 @@ static ssize_t comp_algorithm_store(struct device *dev, > return len; > } > > -/* flag operations needs meta->tb_lock */ > -static int zram_test_flag(struct zram_meta *meta, u32 index, > - enum zram_pageflags flag) > +static int zram_test_zero(struct zram_meta *meta, u32 index) Why do you want to create specific function for zero? It would be one of usecase for various potential flags. Do
Re: [PATCH v2] extcon: arizona: Update manual headphone detection calculation
On 05/30/2014 09:19 PM, Charles Keepax wrote: > The higher levels of impedance have a higher minimum value than the > first level. As the same value was used for all levels, higher impedances > were reported with a very low level of accuracy. This patch applies the > approriate lower threshold for each level, whilst we are changing things > add a define for the maximum value at each level to improve readability. > > Signed-off-by: Charles Keepax > --- > > Changes since v1: > - Added define for range maximum as per review comments > > drivers/extcon/extcon-arizona.c | 15 ++- > 1 files changed, 10 insertions(+), 5 deletions(-) Applied. Thanks, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH V2 2/2] ftrace: Introduce nr_saved_cmdlines I/F
Hi Steven, Thank you for your review and fixing my patch. (2014/05/31 2:08), Steven Rostedt wrote: On Fri, 30 May 2014 10:02:23 -0400 Steven Rostedt wrote: This last part conflicts with my current 3.16 queue. You can see how it does in my for-next repo. But I'll be pushing my latest with the updates I mentioned above soon and will let you know where to get them. I just pushed my updates to my repo, which includes your first patch plus a fix. This may still rebase, I only solidify my "for-next" branch. But if you rewrite your patch against this branch with my updates, then I can take it and test it for 3.16. Still have one week left, but the earlier the better. OK, I understood. I'll fix my 2nd patch based on your review, and I'll resend the patch as soon as possible. Thank you, Yoshihiro YUNOMAE -- Yoshihiro YUNOMAE Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: yoshihiro.yunomae...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 11/32] xfs: convert to struct inode_time
On Sun, Jun 01, 2014 at 10:24:37AM +1000, Dave Chinner wrote: > On Sat, May 31, 2014 at 05:37:52PM +0200, Arnd Bergmann wrote: > > In my list at http://kernelnewbies.org/y2038, I found that almost > > all file systems at least times until 2106, because they treat > > the on-disk value as unsigned on 64-bit systems, or they use > > a completely different representation. My guess is that somebody > > earlier spent a lot of work on making that happen. > > > > The exceptions are: > > > > * exofs uses signed values, which can probably be changed to be > > consistent with the others. > > * isofs has a bug that limits it until 2027 on architectures with > > a signed 'char' type (otherwise it's 2155). > > * udf can represent times for many thousands of years through a > > 16-bit year representation, but the code to convert to epoch > > uses a const array that ends at 2038. > > * afs uses signed seconds and can probably be fixed > > * coda relies on user space time representation getting passed > > through an ioctl. > > * I miscategorized xfs/ext2/ext3 as having unsigned 32-bit seconds, > > where they really use signed. > > > > I was confused about XFS since I didn't noticed that there are > > separate xfs_ictimestamp_t and xfs_timestamp_t types, so I expected > > XFS to also use the 1970-2106 time range on 64-bit systems today. > > You've missed an awful lot more than just the implications for the > core kernel code. > > There's a good chance such changes propagate to APIs elsewhere in > the filesystems, because something you haven't realised is that XFS > effectively exposes the on-disk timestamp format directly to > userspace via the bulkstat interface (see struct xfs_bstat). It also > affects the XFS open-by-handle ioctl and the swap extent ioctl used > by the online defragmenter. > > IOWs, if we are changing the on-disk timestamp format then this > affects several ioctl()s and hence quite a few of the XFS userspace > utilities. The hardest to fix will be xfsdump which would need a new > dump format to store the extended timestamp ranges, and then > xfs_restore will need to be able to handle restoring such timestamps > on filesystems that don't have extended timestamp support... > > Put simply, changing the structure of system time isn't as straight > forward as changing the kernel structures. System time gets stored > permanently, and that has a cascade effect through the kernel all > to all of the filesystem utilities that know about that permanent > storage in some way > > So yes, you can change the kernel definition, but until the > permanent storage of system time can be extended to support the same > range as the kernel the *system* will still have nasty, silent epoch > overflow, truncation or corruption issues. Just to put that in context, here's the kernel patch to add extended epoch support to XFS. It's completely untested as I haven't done any userspace code changes to enable the feature. However, it should give you an indication of how far the simple act of changing the kernel time representation spread through the filesystem. This does not include any of the VFS infrastructure to specifying the range of supported timestamps. It survives some smoke testing, but dies when the online defragmenter starts using the bulkstat and swap extent ioctls (the assert in xfs_inode_time_from_epoch() fires), so I probably don't have that all sorted correctly yet... To test extended epoch support, however, I need to some fstests that define and validate the behaviour of the new syscalls - until we get those we can't validate that the filesystem follows the spec properly. I also suspect we are going to need an interface to query the supported range of timestamps from a filesystem so that we can test boundary conditions in an automated fashion Cheers, Dave. -- Dave Chinner da...@fromorbit.com xfs: support timestamps beyond Unix epochs From: Dave Chinner The 32 bit second counters in timestamps are too small to represent time beyond the unix epoch (jan 2038) correctly. Extend the on-disk format for a timestamp to include an 8-bit epoch counter so that we can extend time for up to 255 Unix epochs. This should be good for representing timestamps from 1970 to somewhere around 19,000 A.D Signed-off-by: Dave Chinner --- fs/xfs/time.h| 7 -- fs/xfs/xfs_bmap_util.c | 35 +--- fs/xfs/xfs_dinode.h | 48 ++- fs/xfs/xfs_fs.h | 9 +++- fs/xfs/xfs_fsops.c | 5 +++- fs/xfs/xfs_inode.c | 16 ++--- fs/xfs/xfs_inode_buf.c | 8 +++ fs/xfs/xfs_ioctl32.c | 3 +++ fs/xfs/xfs_ioctl32.h | 5 +++- fs/xfs/xfs_iops.c| 59 +++- fs/xfs/xfs_itable.c | 12 ++ fs/xfs/xfs_log_format.h | 4 fs/xfs/xfs_sb.h | 12 +- fs/xfs/xfs_trans_inode.c | 2 +- 14 files changed, 175 insertions(+),
[git pull] Please pull powerpc.git merge branch
Hi Linus ! Here's just one trivial patch to wire up sys_renameat2 which I seem to have completely missed so far. (My test build scripts fwd me warnings but miss the ones generated for missing syscalls). Cheers, Ben. The following changes since commit 011e4b02f1da156ac7fea28a9da878f3c23af739: powerpc, kexec: Fix "Processor X is stuck" issue during kexec from ST mode (2014-05-28 13:24:26 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge for you to fetch changes up to 8212f58a9b151d842fa60a70f354e43c61fad839: powerpc: Wire renameat2() syscall (2014-06-02 09:24:27 +1000) Benjamin Herrenschmidt (1): powerpc: Wire renameat2() syscall arch/powerpc/include/asm/systbl.h | 1 + arch/powerpc/include/asm/unistd.h | 2 +- arch/powerpc/include/uapi/asm/unistd.h | 1 + 3 files changed, 3 insertions(+), 1 deletion(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: vt6655: fix sparse warning for static declarations
This patch fixes the following sparse warnings:
dpc.c:65:21: warning: symbol 'acbyRxRate' was not declared. Should it be static?
dpc.c:272:9: warning: symbol 'MngWorkItem' was not declared. Should it be
static?
dpc.c:288:1: warning: symbol 'device_receive_frame' was not declared. Should it
be static?
Signed-off-by: James A Shackleford
---
drivers/staging/vt6655/dpc.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/vt6655/dpc.c b/drivers/staging/vt6655/dpc.c
index 7ddaf26..696564b 100644
--- a/drivers/staging/vt6655/dpc.c
+++ b/drivers/staging/vt6655/dpc.c
@@ -54,6 +54,7 @@
#include "rf.h"
#include "iowpa.h"
#include "aes_ccmp.h"
+#include "dpc.h"
/*- Static Definitions -*/
@@ -62,7 +63,7 @@
/*- Static Variables --*/
static int msglevel = MSG_LEVEL_INFO;
-const unsigned char acbyRxRate[MAX_RATE] =
+static const unsigned char acbyRxRate[MAX_RATE] =
{2, 4, 11, 22, 12, 18, 24, 36, 48, 72, 96, 108};
/*- Static Functions --*/
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] atm: fore200e.c: Cleaning up uninitialized variables
On Sat, May 31, 2014 at 4:08 PM, Rickard Strandqvist
wrote:
> There is a risk that the variable will be used without being initialized.
>
> This was largely found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
> ---
> drivers/atm/fore200e.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/atm/fore200e.c b/drivers/atm/fore200e.c
> index 204814e..d4725fc 100644
> --- a/drivers/atm/fore200e.c
> +++ b/drivers/atm/fore200e.c
> @@ -2780,7 +2780,7 @@ static struct pci_driver fore200e_pca_driver = {
>
> static int __init fore200e_module_init(void)
> {
> - int err;
> + int err = 0;
>
> printk(FORE200E "FORE Systems 200E-series ATM driver - version "
> FORE200E_VERSION "\n");
I can see how a tool that doesn't know about Kconfig dependencies
might think so, but if you look at Kconfig you'll see that for this
driver to be enabled for building either CONFIG_SBUS or CONFIG_PCI
must be set, and if either of them is then this variable will not be
used without first being set.
-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: skein: fix sparse warning for static arrays
This patch fixes the following sparse warnings:
skein_iv.h:23:11: warning: symbol 'SKEIN_256_IV_128' was not declared. Should
it be static?
skein_iv.h:31:11: warning: symbol 'SKEIN_256_IV_160' was not declared. Should
it be static?
skein_iv.h:39:11: warning: symbol 'SKEIN_256_IV_224' was not declared. Should
it be static?
skein_iv.h:47:11: warning: symbol 'SKEIN_256_IV_256' was not declared. Should
it be static?
skein_iv.h:55:11: warning: symbol 'SKEIN_512_IV_128' was not declared. Should
it be static?
skein_iv.h:67:11: warning: symbol 'SKEIN_512_IV_160' was not declared. Should
it be static?
skein_iv.h:79:11: warning: symbol 'SKEIN_512_IV_224' was not declared. Should
it be static?
skein_iv.h:91:11: warning: symbol 'SKEIN_512_IV_256' was not declared. Should
it be static?
skein_iv.h:103:11: warning: symbol 'SKEIN_512_IV_384' was not declared. Should
it be static?
skein_iv.h:115:11: warning: symbol 'SKEIN_512_IV_512' was not declared. Should
it be static?
skein_iv.h:127:11: warning: symbol 'SKEIN_1024_IV_384' was not declared. Should
it be static?
skein_iv.h:147:11: warning: symbol 'SKEIN_1024_IV_512' was not declared. Should
it be static?
skein_iv.h:167:11: warning: symbol 'SKEIN_1024_IV_1024' was not declared.
Should it be static?
by declaring the initialization vectors in question as static. The header
skein_iv.h is only included by skein.c
Signed-off-by: James A Shackleford
---
drivers/staging/skein/skein_iv.h | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/skein/skein_iv.h b/drivers/staging/skein/skein_iv.h
index a03703d..d9dc1d5 100644
--- a/drivers/staging/skein/skein_iv.h
+++ b/drivers/staging/skein/skein_iv.h
@@ -20,7 +20,7 @@
#define MK_64 SKEIN_MK_64
/* blkSize = 256 bits. hashSize = 128 bits */
-const u64 SKEIN_256_IV_128[] = {
+static const u64 SKEIN_256_IV_128[] = {
MK_64(0xE906, 0x964D7260),
MK_64(0x883DAAA7, 0x7C8D811C),
MK_64(0x10080DF4, 0x91960F7A),
@@ -28,7 +28,7 @@ const u64 SKEIN_256_IV_128[] = {
};
/* blkSize = 256 bits. hashSize = 160 bits */
-const u64 SKEIN_256_IV_160[] = {
+static const u64 SKEIN_256_IV_160[] = {
MK_64(0x14202314, 0x72825E98),
MK_64(0x2AC4E9A2, 0x5A77E590),
MK_64(0xD47A5856, 0x8838D63E),
@@ -36,7 +36,7 @@ const u64 SKEIN_256_IV_160[] = {
};
/* blkSize = 256 bits. hashSize = 224 bits */
-const u64 SKEIN_256_IV_224[] = {
+static const u64 SKEIN_256_IV_224[] = {
MK_64(0xC6098A8C, 0x9AE5EA0B),
MK_64(0x876D5686, 0x08C5191C),
MK_64(0x99CB88D7, 0xD7F53884),
@@ -44,7 +44,7 @@ const u64 SKEIN_256_IV_224[] = {
};
/* blkSize = 256 bits. hashSize = 256 bits */
-const u64 SKEIN_256_IV_256[] = {
+static const u64 SKEIN_256_IV_256[] = {
MK_64(0xFC9DA860, 0xD048B449),
MK_64(0x2FCA6647, 0x9FA7D833),
MK_64(0xB33BC389, 0x6656840F),
@@ -52,7 +52,7 @@ const u64 SKEIN_256_IV_256[] = {
};
/* blkSize = 512 bits. hashSize = 128 bits */
-const u64 SKEIN_512_IV_128[] = {
+static const u64 SKEIN_512_IV_128[] = {
MK_64(0xA8BC7BF3, 0x6FBF9F52),
MK_64(0x1E9872CE, 0xBD1AF0AA),
MK_64(0x309B1790, 0xB32190D3),
@@ -64,7 +64,7 @@ const u64 SKEIN_512_IV_128[] = {
};
/* blkSize = 512 bits. hashSize = 160 bits */
-const u64 SKEIN_512_IV_160[] = {
+static const u64 SKEIN_512_IV_160[] = {
MK_64(0x28B81A2A, 0xE013BD91),
MK_64(0xC2F11668, 0xB5BDF78F),
MK_64(0x1760D8F3, 0xF6A56F12),
@@ -76,7 +76,7 @@ const u64 SKEIN_512_IV_160[] = {
};
/* blkSize = 512 bits. hashSize = 224 bits */
-const u64 SKEIN_512_IV_224[] = {
+static const u64 SKEIN_512_IV_224[] = {
MK_64(0xCCD06162, 0x48677224),
MK_64(0xCBA65CF3, 0xA92339EF),
MK_64(0x8CCD69D6, 0x52FF4B64),
@@ -88,7 +88,7 @@ const u64 SKEIN_512_IV_224[] = {
};
/* blkSize = 512 bits. hashSize = 256 bits */
-const u64 SKEIN_512_IV_256[] = {
+static const u64 SKEIN_512_IV_256[] = {
MK_64(0xCCD044A1, 0x2FDB3E13),
MK_64(0xE8359030, 0x1A79A9EB),
MK_64(0x55AEA061, 0x4F816E6F),
@@ -100,7 +100,7 @@ const u64 SKEIN_512_IV_256[] = {
};
/* blkSize = 512 bits. hashSize = 384 bits */
-const u64 SKEIN_512_IV_384[] = {
+static const u64 SKEIN_512_IV_384[] = {
MK_64(0xA3F6C6BF, 0x3A75EF5F),
MK_64(0xB0FEF9CC, 0xFD84FAA4),
MK_64(0x9D77DD66, 0x3D770CFE),
@@ -112,7 +112,7 @@ const u64 SKEIN_512_IV_384[] = {
};
/* blkSize = 512 bits. hashSize = 512 bits */
-const u64 SKEIN_512_IV_512[] = {
+static const u64 SKEIN_512_IV_512[] = {
MK_64(0x4903ADFF, 0x749C51CE),
MK_64(0x0D95DE39, 0x9746DF03),
MK_64(0x8FD19341, 0x27C79BCE),
@@ -124,7 +124,7 @@ const u64 SKEIN_512_IV_512[] = {
};
/* blkSize = 1024 bits. hashSize = 384 bits */
-const u64 SKEIN_1024_IV_384[] = {
+static const u64 SKEIN_1024_IV_384[] = {
MK_64(0x5102B6B8, 0xC1894A35),
MK_64(0xFEEBC9E3, 0xFE8AF11A),
MK_64(0x0C807F06,
Re: [RESEND PATCH] kexec : add sparse memory related values to vmcore
On Fri, May 30, 2014 at 04:14:33PM +0800, Liu hua wrote: > On 2014/5/29 8:13, Simon Horman wrote: > > On Wed, May 28, 2014 at 09:49:56PM +0800, Liu Hua wrote: > >> This patch deales with sparse memory model. > >> > >> For ARM32 platforms, different vendors may define different > >> SECTION_SIZE_BITS, which we did not write to vmcore. > >> > >> For example: > >> > >> 1 arch/arm/mach-clps711x/include/mach/memory.h > >> #define SECTION_SIZE_BITS 24 > >> 2 arch/arm/mach-exynos/include/mach/memory.h > >> #define SECTION_SIZE_BITS 28 > >> 3 arch/arm/mach-sa1100/include/mach/memory.h > >> #define SECTION_SIZE_BITS 27 > > > > I wonder if this problem will eventually go away, or at least only > > apply to older platforms, as ARM moves towards multiplatform: a single > > kernel for more than one platform. > > For ARM32 platform, it may cost a long time. And when glancing over > the commit log of kernel, we can find this macro changed several times. > The user space tools must take care of all these changed for compatibility. Sure, that reasoning is fine by me. > >> It is really a bad news for user space tools such as > >> makedumpfile and crash, who have to defines them as > >> macros. So for the same architecture, we may need to > >> recomile them to parse vmcores with different > >> SECTION_SIZE_BITS. > >> > >> And if we enable LPAE, MAX_PHYSMEM_SIZE can alse > >> be variable. > >> > >> This patch adds these SECTION_SIZE_BITS and MAX_PHYSMEM_SIZE > >> to vmcore. which makes user space tools more compatible. > >> > >> BTW, makedumpfile has queued the related patch. > >> > >> Signed-off-by: Liu Hua > >> --- > >> kernel/kexec.c | 2 ++ > >> 1 file changed, 2 insertions(+) > >> > >> diff --git a/kernel/kexec.c b/kernel/kexec.c > >> index bf0b929e..8b1a193 100644 > >> --- a/kernel/kexec.c > >> +++ b/kernel/kexec.c > >> @@ -1577,6 +1577,8 @@ static int __init crash_save_vmcoreinfo_init(void) > >>VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS); > >>VMCOREINFO_STRUCT_SIZE(mem_section); > >>VMCOREINFO_OFFSET(mem_section, section_mem_map); > >> + VMCOREINFO_NUMBER(MAX_PHYSMEM_BITS); > >> + VMCOREINFO_NUMBER(SECTION_SIZE_BITS); > >> #endif > >>VMCOREINFO_STRUCT_SIZE(page); > >>VMCOREINFO_STRUCT_SIZE(pglist_data); > >> -- > >> 1.9.0 > >> > >> > >> ___ > >> kexec mailing list > >> ke...@lists.infradead.org > >> http://lists.infradead.org/mailman/listinfo/kexec > >> > > > > ___ > > kexec mailing list > > ke...@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/kexec > > > > . > > > > > > ___ > kexec mailing list > ke...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: skein: fix sparse warning for static declarations
This patch fixes the following sparse warnings: skein_block.c:43:6: warning: symbol 'skein_256_process_block' was not declared. Should it be static? skein_block.c:252:6: warning: symbol 'skein_512_process_block' was not declared. Should it be static? skein_block.c:483:6: warning: symbol 'skein_1024_process_block' was not declared. Should it be static? by including the header skein_block.h, which contains the declarations in question. Signed-off-by: James A Shackleford --- drivers/staging/skein/skein_block.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/skein/skein_block.c b/drivers/staging/skein/skein_block.c index f49eb2e..04ce1d0 100644 --- a/drivers/staging/skein/skein_block.c +++ b/drivers/staging/skein/skein_block.c @@ -16,6 +16,7 @@ #include #include "skein.h" +#include "skein_block.h" #ifndef SKEIN_USE_ASM #define SKEIN_USE_ASM (0) /* default is all C code (no ASM) */ -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] arm: tegra: initial support for apalis t30
This patch adds the device tree to support Toradex Apalis T30, a
computer on module which can be used on different carrier boards.
The module consists of a Tegra 3 SoC, two PMICs, 1 or 2 GB of DDR3L
RAM, eMMC, an LM95245 temperature sensor chip, an i210 resp. i211
gigabit Ethernet controller, an STMPE811 ADC/touch controller as well
as two MCP2515 CAN controllers. Furthermore, there is an SGTL5000 audio
codec which is not yet supported. Anything that is not self contained
on the module is disabled by default.
The device tree for the Evaluation Board includes the modules device
tree and enables the supported peripherals of the carrier board (the
Evaluation Board supports almost all of them).
While at it also add the device tree binding documentation for Apalis
T30 as well as the previously missing one for the recently added
Colibri T30.
Signed-off-by: Marcel Ziswiler
---
Documentation/devicetree/bindings/arm/tegra.txt |4 +
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/tegra30-apalis-eval.dts | 258 +
arch/arm/boot/dts/tegra30-apalis.dtsi | 671 +++
4 files changed, 934 insertions(+)
create mode 100644 arch/arm/boot/dts/tegra30-apalis-eval.dts
create mode 100644 arch/arm/boot/dts/tegra30-apalis.dtsi
diff --git a/Documentation/devicetree/bindings/arm/tegra.txt
b/Documentation/devicetree/bindings/arm/tegra.txt
index 558ed4b..428e098 100644
--- a/Documentation/devicetree/bindings/arm/tegra.txt
+++ b/Documentation/devicetree/bindings/arm/tegra.txt
@@ -30,7 +30,11 @@ board-specific compatible values:
nvidia,seaboard
nvidia,ventana
nvidia,whistler
+ toradex,apalis_t30
+ toradex,apalis_t30-eval
toradex,colibri_t20-512
+ toradex,colibri_t30
+ toradex,colibri_t30-eval-v3
toradex,iris
Trusted Foundations
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index c1a257a..333ac53 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -364,6 +364,7 @@ dtb-$(CONFIG_ARCH_TEGRA) += tegra20-harmony.dtb \
tegra20-trimslice.dtb \
tegra20-ventana.dtb \
tegra20-whistler.dtb \
+ tegra30-apalis-eval.dtb \
tegra30-beaver.dtb \
tegra30-cardhu-a02.dtb \
tegra30-cardhu-a04.dtb \
diff --git a/arch/arm/boot/dts/tegra30-apalis-eval.dts
b/arch/arm/boot/dts/tegra30-apalis-eval.dts
new file mode 100644
index 000..347cc60
--- /dev/null
+++ b/arch/arm/boot/dts/tegra30-apalis-eval.dts
@@ -0,0 +1,258 @@
+/dts-v1/;
+
+#include
+#include "tegra30-apalis.dtsi"
+
+/ {
+ model = "Toradex Apalis T30 on Apalis Evaluation Board";
+ compatible = "toradex,apalis_t30-eval", "nvidia,tegra30";
+
+ aliases {
+ rtc0 = "/i2c@7000c000/rtc@68";
+ rtc1 = "/i2c@7000d000/tps65911@2d";
+ rtc2 = "/rtc@7000e000";
+ };
+
+ pcie-controller@3000 {
+ status = "okay";
+
+ pci@1,0 {
+ status = "okay";
+ };
+
+ pci@2,0 {
+ status = "okay";
+ };
+
+ pci@3,0 {
+ status = "okay";
+ };
+ };
+
+ host1x@5000 {
+ dc@5420 {
+ rgb {
+ status = "okay";
+ nvidia,panel = <>;
+ };
+ };
+ hdmi@5428 {
+ status = "okay";
+ };
+ };
+
+ serial@70006000 {
+ status = "okay";
+ };
+
+ serial@70006040 {
+ compatible = "nvidia,tegra30-hsuart";
+ status = "okay";
+ };
+
+ serial@70006200 {
+ compatible = "nvidia,tegra30-hsuart";
+ status = "okay";
+ };
+
+ serial@70006300 {
+ compatible = "nvidia,tegra30-hsuart";
+ status = "okay";
+ };
+
+ pwm@7000a000 {
+ status = "okay";
+ };
+
+ /*
+* GEN1_I2C: I2C1_SDA/SCL on MXM3 pin 209/211 (e.g. RTC on carrier
+* board)
+*/
+ i2c@7000c000 {
+ status = "okay";
+ clock-frequency = <10>;
+
+ pcie-switch@58 {
+ compatible = "plx,pex8605";
+ reg = <0x58>;
+ };
+
+ /* M41T0M6 real time clock on carrier board */
+ rtc@68 {
+ compatible = "st,m41t00";
+ reg = <0x68>;
+ };
+ };
+
+ /* GEN2_I2C: unused */
+
+ /*
+* CAM_I2C: I2C3_SDA/SCL on MXM3 pin 201/203 (e.g. camera sensor on
+* carrier board)
+*/
+ cami2c: i2c@7000c500 {
+ status = "okay";
+ clock-frequency = <40>;
+ };
+
+ /* DDC: I2C2_SDA/SCL on MXM3 pin 205/207 (e.g. display
[PATCH 2/3] arm: tegra: enable igb, stmpe, i2c chardev, spidev, lm95245, pwm leds
The NVIDIA Tegra 3 based Apalis T30 module contains an Intel i210 resp. i211 gigabit Ethernet controller, an STMPE811 ADC/touch controller, I2C as well as SPI buses and PWM LEDs generically accessible from user space and an LM95245 temperature sensor chip. The later five can also be found on the Colibri T30 module. While at it move the PCA953x GPIO entry down to its proper place to have it all nicely ordered again. Signed-off-by: Marcel Ziswiler --- BTW: How about MTD_SPI_NOR, PROC_DEVICETREE and CRYPTO_DEV_TEGRA_AES which I haven't found any mentioning anywhere? arch/arm/configs/tegra_defconfig | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig index fb25e29..4ed82f9 100644 --- a/arch/arm/configs/tegra_defconfig +++ b/arch/arm/configs/tegra_defconfig @@ -23,7 +23,6 @@ CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_PARTITION_ADVANCED=y # CONFIG_IOSCHED_DEADLINE is not set # CONFIG_IOSCHED_CFQ is not set -CONFIG_GPIO_PCA953X=y CONFIG_ARCH_TEGRA=y CONFIG_ARCH_TEGRA_2x_SOC=y CONFIG_ARCH_TEGRA_3x_SOC=y @@ -111,6 +110,7 @@ CONFIG_SCSI_MULTI_LUN=y # CONFIG_SCSI_LOWLEVEL is not set CONFIG_NETDEVICES=y CONFIG_DUMMY=y +CONFIG_IGB=y CONFIG_R8169=y CONFIG_USB_PEGASUS=y CONFIG_USB_USBNET=y @@ -125,6 +125,8 @@ CONFIG_KEYBOARD_GPIO=y CONFIG_KEYBOARD_TEGRA=y CONFIG_KEYBOARD_CROS_EC=y CONFIG_MOUSE_PS2_ELANTECH=y +CONFIG_INPUT_TOUCHSCREEN=y +CONFIG_TOUCHSCREEN_STMPE=y CONFIG_INPUT_MISC=y CONFIG_INPUT_MPU3050=y # CONFIG_LEGACY_PTYS is not set @@ -135,6 +137,7 @@ CONFIG_SERIAL_TEGRA=y CONFIG_SERIAL_OF_PLATFORM=y # CONFIG_HW_RANDOM is not set # CONFIG_I2C_COMPAT is not set +CONFIG_I2C_CHARDEV=y CONFIG_I2C_MUX_PCA954x=y CONFIG_I2C_MUX_PINCTRL=y CONFIG_I2C_TEGRA=y @@ -142,8 +145,10 @@ CONFIG_SPI=y CONFIG_SPI_TEGRA114=y CONFIG_SPI_TEGRA20_SFLASH=y CONFIG_SPI_TEGRA20_SLINK=y +CONFIG_SPI_SPIDEV=y CONFIG_PINCTRL_AS3722=y CONFIG_PINCTRL_PALMAS=y +CONFIG_GPIO_PCA953X=y CONFIG_GPIO_PCA953X_IRQ=y CONFIG_GPIO_PALMAS=y CONFIG_GPIO_TPS6586X=y @@ -155,10 +160,12 @@ CONFIG_POWER_RESET=y CONFIG_POWER_RESET_AS3722=y CONFIG_POWER_RESET_GPIO=y CONFIG_SENSORS_LM90=y +CONFIG_SENSORS_LM95245=y CONFIG_MFD_AS3722=y CONFIG_MFD_CROS_EC=y CONFIG_MFD_CROS_EC_SPI=y CONFIG_MFD_MAX8907=y +CONFIG_MFD_STMPE=y CONFIG_MFD_PALMAS=y CONFIG_MFD_TPS65090=y CONFIG_MFD_TPS6586X=y @@ -221,6 +228,7 @@ CONFIG_MMC_SDHCI_TEGRA=y CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=y CONFIG_LEDS_GPIO=y +CONFIG_LEDS_PWM=y CONFIG_LEDS_TRIGGERS=y CONFIG_LEDS_TRIGGER_TIMER=y CONFIG_LEDS_TRIGGER_ONESHOT=y -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: silicom: fix sparse warning for static variable
This patch fixes the following sparse warning in bpctl_mod.c:
warning: symbol 'bpvm_lock' was not declared. Should it be static?
Signed-off-by: James A Shackleford
---
drivers/staging/silicom/bpctl_mod.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/silicom/bpctl_mod.c
b/drivers/staging/silicom/bpctl_mod.c
index f74b5e7..765fce8 100644
--- a/drivers/staging/silicom/bpctl_mod.c
+++ b/drivers/staging/silicom/bpctl_mod.c
@@ -41,7 +41,7 @@ MODULE_AUTHOR("Anna Lukin, an...@silicom.co.il");
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION(BP_MOD_DESCR);
MODULE_VERSION(BP_MOD_VER);
-spinlock_t bpvm_lock;
+static spinlock_t bpvm_lock;
#define unlock_bpctl() \
up(_sema);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Licensing & copyright of kernel .config files (defconfig, *config)
On Mon, Jun 02, 2014 at 12:01:46AM +0100, Ken Moffat wrote: > > Naively, since the defconfigs are bundled with the kernel, that could > > fall under GPLv2-only implicitly, but lacking any explicit copyright > > headers makes this interesting (arch/*/configs/* contain lots of files, > > no copyright headers on them). > I am not a lawyer, but surely _many_ of the kernel files do not > contain any explicit copyright information ? On closer inspection, more files than I thought don't have any explicit copyrights on them. ~67% of files in v3.13 had the text 'Copyright' or 'Licens' appear in them. > Why does your editor put a default license on anything ? It's my stock header, customized by per-directory vimrc. The non-project-specific default one actually has a CHANGEME string it in, to help remind me that it needs an edit before I release that file. I was just using the BSD license on the file as an example. Submissions to other open source projects are generally bound by the license of the project, with a few exceptions (I've put patches into public domain to avoid signing some CLA-like agreements). > If I was being awkward, I would suggest that the config would not > be useful until you had run it through "make oldconfig" or similar, > and that therefore the kernel license of GPL-2 applies. That's the case I was interested in :-). > > If the files are to be marked with a copyright header, who is the holder > > of it that it should be attributed to? > Iff the work is copyrightable (I do not have an opinion on that), > surely the license only matters if you breach it ? ;-) If you > distribute a compiled kernel with the source, and all of that source > is GPL-2, then I assume you are in the clear. For "extras" which > include binaries without source, my understanding is that you would > always be vulnerable to kernel copyright holders. So, I suspect > that the attribution of a config file is not particularly important. I agree with your reasoning if I was distributing kernel sources or compiled kernels, but this is going to be a package of kernel configurations only. > > Background: > > Gentoo has a bunch of "stock" kernel configurations for release > > engineering, our initramfs tool (genkernel), and other endeavors over > > the years. These projects claim BSD, GPL2, LGPL2 on various pieces, and > > I don't think they can all be correct. I'm working on getting them into > > one place, because some of them have been getting stale, but the > > differing licenses raised a red flag to me. > To the extent that GPL-2 can include LGPL-2 and BSD, I suggest that > you label them all as GPL-2. That is the licence of the kernel, and > for practical reasons it will not change (this was discussed when > somebody asked about GPL-3 : even if the main copyright holders > wanted to make the change (and many do not), some copyright holders > are no longer contactable). You might be able to dual-license some > of these distro files, but I have no idea if that would be appropriate. If the rest of the logic is correct, then the non-GPL2 license on these files was never valid in the first place; they inherited GPL2 from the kernel from the get go, and I don't need to be concerned about the hassle of formally relicensing them by contacting the authors of the configs (which again, aren't always contactable anymore). -- Robin Hugh Johnson Gentoo Linux: Developer, Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] x86, Clean up smp_num_siblings calculation
On 06/01/2014 05:23 AM, Oren Twaig wrote:
> Hi Prarit,
>
> See below,
>
> On 05/30/2014 02:43 PM, Prarit Bhargava wrote:
>> I have a system on which I have disabled threading in the BIOS, and I am
>> booting
>> the kernel with the option "idle=poll".
>>
>> The kernel displays
>>
>> process: WARNING: polling idle and HT enabled, performance may degrade
>>
>> which is incorrect -- I've already disabled HT.
>>
>> This warning is issued here:
>>
>> void select_idle_routine(const struct cpuinfo_x86 *c)
>> {
>> if (boot_option_idle_override == IDLE_POLL && smp_num_siblings > 1)
>> pr_warn_once("WARNING: polling idle and HT enabled,
>> performance may degrade\n");
>>
>> >From my understanding of the other ares of kernel that use
>> smp_num_siblings, the value is supposed to be the the number of threads
>> per core.
>>
>> The value of smp_num_siblings is incorrect. In theory, it should be 1 but it
>> is reported as 2. When I looked into how smp_num_siblings is calculated I
>> found the following call sequence in the kernel:
>>
>> start_kernel ->
>> check_bugs ->
>> identify_boot_cpu ->
>> identify_cpu ->
>> c_init = init_intel
>> init_intel ->
>>
>> detect_extended_topology
>> (sets value)
>>
>> OR
>>
>> c_init = init_amd
>> init_amd -> amd_detect_cmp
>> ->
>> amd_get_topology
>> (sets value)
>> -> detect_ht()
>> ...(sets value)
>> detect_ht()
>> (also sets value)
>>
>> ie) it is set three times in some cases and is overwritten by the call
>> to detect_ht() from identify_cpu() in all cases.
>>
>> It should be noted that nothing in the identify_cpu() path or the cpu_up()
>> path requires smp_num_siblings to be set, prior to the final call to
>> detect_ht().
>>
>> For x86 boxes, smp_num_siblings is set to a value read in a CPUID call in
>> detect_ht(). This value is the *factory defined* value in all cases; even
>> if HT is disabled in BIOS the value still returns 2 if the CPU supports
>> HT. AMD also reports the factory defined value in all cases.
>
> The above is incorrect in case of X-TOPOLOGY mode. I such a case the
> information
> about number of siblings comes from the LEVEL_MAX_SIBLINGS() macro and the
> X86_FEATURE_XTOPOLOGY flag is set to skip detect_ht() work :
> void detect_ht(struct cpuinfo_x86 *c)
> ...
> if (cpu_has(c, X86_FEATURE_XTOPOLOGY))
> return;
>
> In addition, the information about the number of sibling no longer comes from
> CPUID(0x1)->ebx but rather from the 0xb leaf of CPUID.
>
> I've marked below the problematic code change.
I will do a [v2] of the patchset that omits this change
>> -core_level_siblings = smp_num_siblings = LEVEL_MAX_SIBLINGS(ebx);
>> +core_level_siblings = LEVEL_MAX_SIBLINGS(ebx);
and then removes the setting of smp_num_siblings in 2/2.
Thanks,
P.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Licensing & copyright of kernel .config files (defconfig, *config)
On Sun, Jun 01, 2014 at 01:43:01AM +, Robin H. Johnson wrote: > (Please CC me on replies, not subscribed to LKML) > > Hi, > > Somewhat of an odd question, but none of the files in question seem to > have a copyright header on them... > > For a kernel .config file, either from one of the defconfig or any other > *config option that automates the answer: > 1. What license does the file fall under? > 2. Who are the copyright holders? > > Naively, since the defconfigs are bundled with the kernel, that could > fall under GPLv2-only implicitly, but lacking any explicit copyright > headers makes this interesting (arch/*/configs/* contain lots of files, > no copyright headers on them). > I am not a lawyer, but surely _many_ of the kernel files do not contain any explicit copyright information ? > If I manually write the names of some configuration options to a new > .config file, at that point I logically am the only author and have > copyright of it. My editor slaps a default license on it of BSD-2. > Thereafter I run olddefconfig, and now it's a combined work of the > kernel's defconfig and my manual settings. If GPL-2 was inherited from > the kernel tree, this is now a combined BSD-GPL2 work, or is it? The > kernel config tools did consider my file as input, possibly overrode the > settings if they didn't work with others, and re-output everything. > Why does your editor put a default license on anything ? In some cases, it is bound to be wrong. For example, if you were to ever submit a kernel patch, in the kernel the license would be GPL-2 although, if you created a new file, you could also license that as BSD-2 if it was not a derivative of existing kernel code. Similarly, if you ever create a patch for any other project which does not use a BSD license, then your patch will have uncertain status. If I was being awkward, I would suggest that the config would not be useful until you had run it through "make oldconfig" or similar, and that therefore the kernel license of GPL-2 applies. > If the files are to be marked with a copyright header, who is the holder > of it that it should be attributed to? > Iff the work is copyrightable (I do not have an opinion on that), surely the license only matters if you breach it ? ;-) If you distribute a compiled kernel with the source, and all of that source is GPL-2, then I assume you are in the clear. For "extras" which include binaries without source, my understanding is that you would always be vulnerable to kernel copyright holders. So, I suspect that the attribution of a config file is not particularly important. > Alternatively, is this a case where the work is not copyrightable, and > the files should have a notice to that effect? > > Background: > Gentoo has a bunch of "stock" kernel configurations for release > engineering, our initramfs tool (genkernel), and other endeavors over > the years. These projects claim BSD, GPL2, LGPL2 on various pieces, and > I don't think they can all be correct. I'm working on getting them into > one place, because some of them have been getting stale, but the > differing licenses raised a red flag to me. > To the extent that GPL-2 can include LGPL-2 and BSD, I suggest that you label them all as GPL-2. That is the licence of the kernel, and for practical reasons it will not change (this was discussed when somebody asked about GPL-3 : even if the main copyright holders wanted to make the change (and many do not), some copyright holders are no longer contactable). You might be able to dual-license some of these distro files, but I have no idea if that would be appropriate. ĸen -- Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/15] Thunderbolt driver for Apple MacBooks
On Sun, Jun 01, 2014 at 10:02:04PM +, Matthew Garrett wrote: > On Sun, 2014-06-01 at 22:45 +0200, Andreas Noever wrote: > > On Sun, Jun 1, 2014 at 6:07 PM, Matthew Garrett > > wrote: > > > Yeah, it seems I don't need the suspend quirk - the NHI is still there > > > without it. I still think we should make the quirk general rather than > > > tying it to the machines, the worst case is that it'll just do nothing. > > Ok, agreed. The "wait" quirk has to run on all machines and the other > > one will fail if the ACPI methods are not there. Should I resend the > > series or just the patch or should I (or do you want to) make a > > separate patch? > > Probably best to ask Greg - I'm fine with this stuff going through his > tree (note to Greg: the Apple ACPI patches I just sent need to be merged > before this stuff will work properly) Ok, I'll still queue these up, I don't want the to be lost at all, and will wait for the ACPI patches to land before starting to complain that things don't work on my box :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: rtl8712: rtl871x_ioctl_linux.c: Cleaning up memory leak
On Sun, 1 Jun 2014 13:30:43 +0200, Rickard Strandqvist wrote: > There is a risk for memory leak in when something unexpected happens > and the function returns. > > This was largely found by using a static code analysis program called > cppcheck. > > Signed-off-by: Rickard Strandqvist > --- > drivers/staging/rtl8712/rtl871x_ioctl_linux.c |1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c > b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c > index 23d539d..27e0243 100644 > --- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c > +++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c > @@ -1822,6 +1822,7 @@ static int r871x_wx_set_enc_ext(struct net_device *dev, > alg_name = "CCMP"; > break; > default: > + kfree(param); > return -EINVAL; > } > strncpy((char *)param->u.crypt.alg, alg_name, IEEE_CRYPT_ALG_NAME_LEN); Hi Rickard, This one doesn't apply either. Commit 55d4f6cc (staging: rtl8712: fix potential leak in r871x_wx_set_enc_ext()) moved the input verification to the beginning of the function so that the direct return no longer hurt. This change was also already in flight at the time of Your first version of the patch in May. Please check that Your patches are based on linux-next. Best Regards, Christian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: rtl8712: rtl871x_mlme.c: Cleaning up memory leak
Hi Christian! Yes! I mail about this for the first time in early May, but ther were many other faults in the design of my patch, had several different types of errors in the same path etc. So good that they have already been solved then :) Best regards Rickard Strandqvist 2014-06-01 23:50 GMT+02:00 Christian Engelmayer : > On Sun, 1 Jun 2014 13:32:20 +0200, Rickard Strandqvist > wrote: >> There is a risk for memory leak in when something unexpected happens >> and the function returns. >> >> This was largely found by using a static code analysis program called >> cppcheck. >> >> Signed-off-by: Rickard Strandqvist > > This doesn't apply against staging-next. This fix seems to attack the same > problem as existing commit 2af9e74 (staging: rtl8712: fix potential leaks in > r8712_set_key()) - > http://www.spinics.net/lists/linux-driver-devel/msg46501.html > > I think we talked about that already - see > http://www.spinics.net/lists/linux-driver-devel/msg46294.html > > Regards, > Christian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Thunderbolt: Add support for Thunderbolt 2 host controllers
On Sun, 2014-06-01 at 22:42 +0200, Andreas Noever wrote: > Just to check: Did they split up the device ids? Is 0x156d for the > bridges and 0x156c for the NHI? Yes. Some kind of progress. I did notice that the Apple driver binds to all devices with the system peripheral class, vendor 8086 and device 15xx - I don't think we can represent that in Linux at the moment. > I have had a look at what os x does. They split between: > 1513, 151a, 1549 and 1547, 1548, 1567, 1569, 156b, 156d (the latter > group gets bit 3 set) > > It looks like the first 3 are legacy devices, so maybe reverse the check? Seems fair. I probably won't have time to resend for a couple of days - if it's easier, please do just rework this yourself. -- Matthew Garrett
Re: [PATCH v4 00/15] Thunderbolt driver for Apple MacBooks
On Sun, 2014-06-01 at 22:45 +0200, Andreas Noever wrote: > On Sun, Jun 1, 2014 at 6:07 PM, Matthew Garrett > wrote: > > Yeah, it seems I don't need the suspend quirk - the NHI is still there > > without it. I still think we should make the quirk general rather than > > tying it to the machines, the worst case is that it'll just do nothing. > Ok, agreed. The "wait" quirk has to run on all machines and the other > one will fail if the ACPI methods are not there. Should I resend the > series or just the patch or should I (or do you want to) make a > separate patch? Probably best to ask Greg - I'm fine with this stuff going through his tree (note to Greg: the Apple ACPI patches I just sent need to be merged before this stuff will work properly) -- Matthew Garrett
Re: [PATCH] staging: rtl8712: rtl871x_mlme.c: Cleaning up memory leak
On Sun, 1 Jun 2014 13:32:20 +0200, Rickard Strandqvist wrote: > There is a risk for memory leak in when something unexpected happens > and the function returns. > > This was largely found by using a static code analysis program called > cppcheck. > > Signed-off-by: Rickard Strandqvist This doesn't apply against staging-next. This fix seems to attack the same problem as existing commit 2af9e74 (staging: rtl8712: fix potential leaks in r8712_set_key()) - http://www.spinics.net/lists/linux-driver-devel/msg46501.html I think we talked about that already - see http://www.spinics.net/lists/linux-driver-devel/msg46294.html Regards, Christian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arch: sparc: kernel: smp_64.c: Optimization of the Code
>From what I know, AND is faster then modulo. Not sure if this is worth changing though. Signed-off-by: Rickard Strandqvist --- arch/sparc/kernel/smp_64.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/sparc/kernel/smp_64.c b/arch/sparc/kernel/smp_64.c index 745a363..921d924 100644 --- a/arch/sparc/kernel/smp_64.c +++ b/arch/sparc/kernel/smp_64.c @@ -179,7 +179,7 @@ static inline long get_delta (long *rt, long *master) /* average best_t0 and best_t1 without overflow: */ tcenter = (best_t0/2 + best_t1/2); - if (best_t0 % 2 + best_t1 % 2 == 2) + if ((best_t0 & 1) + (best_t1 & 1) == 2) tcenter++; return tcenter - best_tm; } -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix a race condition in cancelable mcs spinlocks
On Sun, Jun 01, 2014 at 11:30:03PM +0200, Peter Zijlstra wrote: > On Sun, Jun 01, 2014 at 04:46:26PM -0400, John David Anglin wrote: > > On 1-Jun-14, at 3:20 PM, Peter Zijlstra wrote: > > > > >>If you write to some variable with ACCESS_ONCE and use cmpxchg or xchg > > >>at > > >>the same time, you break it. ACCESS_ONCE doesn't take the hashed > > >>spinlock, > > >>so, in this case, cmpxchg or xchg isn't really atomic at all. > > > > > >And this is really the first place in the kernel that breaks like this? > > >I've been using xchg() and cmpxchg() without such consideration for > > >quite a while. > > > > I believe Mikulas is correct. Even in a controlled situation where a > > cmpxchg operation > > is used to implement pthread_spin_lock() in userspace, we found recently > > that the lock > > must be released with a cmpxchg operation and not a simple write on SMP > > systems. > > There is a race in the cache operations or instruction ordering that's not > > present with > > the ldcw instruction. > > Oh, I'm not arguing that. He's quite right that its broken, but this > form of atomic ops is also quite insane and unusual. Most sane machines > don't have this problem. > > My main concern is how are we going to avoid breaking parisc (and I > think sparc32, which is similarly retarded) in the future; we should > invest in machinery to find and detect these things. I cannot see an easy way to fix this by making ACCESS_ONCE() arch-dependent. But could the compiler help out by recognizing ACCESS_ONCE() and generating the needed code for it on sparc and pa-risc? Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arch: ia64: kernel: smpboot.c: Optimization of the Code
>From what I know, AND is faster then modulo. Not sure if this is worth changing though. Signed-off-by: Rickard Strandqvist --- arch/ia64/kernel/smpboot.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/ia64/kernel/smpboot.c b/arch/ia64/kernel/smpboot.c index 547a48d..8d41119 100644 --- a/arch/ia64/kernel/smpboot.c +++ b/arch/ia64/kernel/smpboot.c @@ -237,7 +237,7 @@ get_delta (long *rt, long *master) /* average best_t0 and best_t1 without overflow: */ tcenter = (best_t0/2 + best_t1/2); - if (best_t0 % 2 + best_t1 % 2 == 2) + if ((best_t0 & 1) + (best_t1 & 1) == 2) ++tcenter; return tcenter - best_tm; } -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arch: ia64: kernel: patch.c: Optimization of the Code
>From what I know, AND is faster then modulo.
Not sure if this is worth changing though.
Signed-off-by: Rickard Strandqvist
---
arch/ia64/kernel/patch.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/ia64/kernel/patch.c b/arch/ia64/kernel/patch.c
index 1cf0917..0152455 100644
--- a/arch/ia64/kernel/patch.c
+++ b/arch/ia64/kernel/patch.c
@@ -49,7 +49,8 @@ ia64_patch (u64 insn_addr, u64 mask, u64 val)
unsigned long shift;
b0 = b[0]; b1 = b[1];
- shift = 5 + 41 * (insn_addr % 16); /* 5 bits of template, then 3 x
41-bit instructions */
+ /* 5 bits of template, then 3 x 41-bit instructions */
+ shift = 5 + 41 * (insn_addr & 0xf);
if (shift >= 64) {
m1 = mask << (shift - 64);
v1 = val << (shift - 64);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arch: ia64: kernel: palinfo.c: Optimization of the Code
>From what I know, AND is faster then modulo.
Not sure if this is worth changing though.
Signed-off-by: Rickard Strandqvist
---
arch/ia64/kernel/palinfo.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/ia64/kernel/palinfo.c b/arch/ia64/kernel/palinfo.c
index c39c3cd..7915b02 100644
--- a/arch/ia64/kernel/palinfo.c
+++ b/arch/ia64/kernel/palinfo.c
@@ -156,7 +156,8 @@ static void bitregister_process(struct seq_file *m, u64
*reg_info, int max)
for(; i < max; i++ ) {
- if (i != 0 && (i%64) == 0) value = *++reg_info;
+ if (i != 0 && (i&63) == 0)
+ value = *++reg_info;
if ((value & 0x1) == 0 && skip == 0) {
if (begin <= i - 2)
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH 2/2] tux3: Use writeback hook to remove duplicated core code
Instead of re-implementing part of fs/fs-writeback.c, use a proposed
net ->writeback super operation to drive delta writeback. For each
inode that is cleaned, call inode_writeback_done(inode). For each
inode that will be kept dirty in cache, call inode_writeback_touch
so that the inode appears young to fs-writeback and does not trigger
repeated ->writeback flushes.
Signed-off-by: Daniel Phillips
---
fs/tux3/Makefile | 2 +-
fs/tux3/commit.c | 1 -
fs/tux3/commit_flusher.c | 180 ++
fs/tux3/commit_flusher.h | 16 --
fs/tux3/commit_flusher_hack.c | 423 --
fs/tux3/inode.c | 2 -
fs/tux3/super.c | 17 +-
fs/tux3/tux3.h| 11 +-
fs/tux3/writeback.c | 75 ++--
11 files changed, 128 insertions(+), 599 deletions(-)
delete mode 100644 fs/tux3/commit_flusher.h
delete mode 100644 fs/tux3/commit_flusher_hack.c
diff --git a/fs/tux3/Makefile b/fs/tux3/Makefile
index 9623a54..30faba5 100644
--- a/fs/tux3/Makefile
+++ b/fs/tux3/Makefile
@@ -13,7 +13,7 @@ tux3-objs += balloc.o btree.o buffer.o commit.o dir.o dleaf.o
\
EXTRA_CFLAGS += -Werror -std=gnu99 -Wno-declaration-after-statement
#EXTRA_CFLAGS += -DTUX3_FLUSHER=TUX3_FLUSHER_SYNC
#EXTRA_CFLAGS += -DTUX3_FLUSHER=TUX3_FLUSHER_ASYNC_OWN
-EXTRA_CFLAGS += -DTUX3_FLUSHER=TUX3_FLUSHER_ASYNC_HACK
+EXTRA_CFLAGS += -DTUX3_FLUSHER=TUX3_FLUSHER_ASYNC
obj-$(CONFIG_TUX3_MMAP) += mmap_builtin_hack.o
endif
diff --git a/fs/tux3/commit.c b/fs/tux3/commit.c
index dd76d49..84e686e 100644
--- a/fs/tux3/commit.c
+++ b/fs/tux3/commit.c
@@ -638,7 +638,6 @@ static void delta_transition(struct sb *sb)
((int)(a) - (int)(b) >= 0))
#include "commit_flusher.c"
-#include "commit_flusher_hack.c"
int force_unify(struct sb *sb)
{
diff --git a/fs/tux3/commit_flusher.c b/fs/tux3/commit_flusher.c
index 8e7057d..2d938c5 100644
--- a/fs/tux3/commit_flusher.c
+++ b/fs/tux3/commit_flusher.c
@@ -4,7 +4,7 @@
* Copyright (c) 2008-2014 OGAWA Hirofumi
*/
-#if TUX3_FLUSHER != TUX3_FLUSHER_ASYNC_HACK
+#if TUX3_FLUSHER == TUX3_FLUSHER_SYNC
#include "tux3.h"
static void __tux3_init_flusher(struct sb *sb)
@@ -15,72 +15,6 @@ static void __tux3_init_flusher(struct sb *sb)
#endif
}
-#if TUX3_FLUSHER == TUX3_FLUSHER_ASYNC_OWN
-static int flush_delta_work(void *data)
-{
-struct sb *sb = data;
-int err;
-
-set_freezable();
-
-/*
- * Our parent may run at a different priority, just set us to normal
- */
-set_user_nice(current, 0);
-
-while (!kthread_freezable_should_stop(NULL)) {
-if (test_bit(TUX3_COMMIT_PENDING_BIT, >backend_state)) {
-clear_bit(TUX3_COMMIT_PENDING_BIT, >backend_state);
-
-err = flush_delta(sb);
-/* FIXME: error handling */
-}
-
-set_current_state(TASK_INTERRUPTIBLE);
-if (!test_bit(TUX3_COMMIT_PENDING_BIT, >backend_state) &&
-!kthread_should_stop())
-schedule();
-__set_current_state(TASK_RUNNING);
-}
-
-return 0;
-}
-
-int tux3_init_flusher(struct sb *sb)
-{
-struct task_struct *task;
-char b[BDEVNAME_SIZE];
-
-__tux3_init_flusher(sb);
-
-bdevname(vfs_sb(sb)->s_bdev, b);
-
-/* FIXME: we should use normal bdi-writeback by changing core */
-task = kthread_run(flush_delta_work, sb, "tux3/%s", b);
-if (IS_ERR(task))
-return PTR_ERR(task);
-
-sb->flush_task = task;
-
-return 0;
-}
-
-void tux3_exit_flusher(struct sb *sb)
-{
-if (sb->flush_task) {
-kthread_stop(sb->flush_task);
-sb->flush_task = NULL;
-}
-}
-
-static void schedule_flush_delta(struct sb *sb)
-{
-/* Start the flusher for pending delta */
-wake_up_process(sb->flush_task);
-}
-
-#else /* TUX3_FLUSHER != TUX3_FLUSHER_ASYNC_OWN */
-
int tux3_init_flusher(struct sb *sb)
{
__tux3_init_flusher(sb);
@@ -109,7 +43,6 @@ static int flush_pending_delta(struct sb *sb)
out:
return err;
}
-#endif /* TUX3_FLUSHER != TUX3_FLUSHER_ASYNC_OWN */
/* Try delta transition */
static void try_delta_transition(struct sb *sb)
@@ -155,10 +88,8 @@ static int try_flush_pending_until_delta(struct sb *sb,
unsigned delta)
trace("delta %u, committed %u, backend_state %lx",
delta, sb->committed_delta, sb->backend_state);
-#if TUX3_FLUSHER == TUX3_FLUSHER_SYNC
if (!delta_after_eq(sb->committed_delta, delta))
flush_pending_delta(sb);
-#endif
return delta_after_eq(sb->committed_delta, delta);
}
@@ -175,9 +106,7 @@ static int sync_current_delta(struct sb *sb, enum
unify_flags unify_flag)
unsigned delta;
int err = 0;
-#if TUX3_FLUSHER == TUX3_FLUSHER_SYNC
down_write(>delta_lock);
-#endif
/* Get delta that have to write */
delta_ref = delta_get(sb);
#ifdef UNIFY_DEBUG
@@ -197,10 +126,111 @@ static int sync_current_delta(struct sb *sb, enum
unify_flags unify_flag)
/* Wait until committing the
[RFC][PATCH 1/2] Add a super operation for writeback
Hi, This is the first of four core changes we would like for Tux3. We start with a hard one and suggest a simple solution. The first patch in this series adds a new super operation to write back multiple inodes in a single call. The second patch applies to our linux-tux3 repository at git.kernel.org to demonstrate how this interface is used, and removes about 450 lines of workaround code. Traditionally, core kernel tells each mounted filesystems which dirty pages of which inodes should be flushed to disk, but unfortunately, is blissfully ignorant of filesystem-specific ordering constraints. This scheme was really invented for Ext2 and has not evolved much recently. Tux3, with its strong ordering and optimized delta commit, cannot tolerate random flushing and therefore takes responsibility for flush ordering itself. On the other hand, Tux3 has no good way to know when is the right time to flush, but core is good at that. This proposed API harmonizes those two competencies so that Tux3 and core each take care of what they are good at, and not more. The API extension consists of a new writeback hook and two helpers to be uses within the hook. The hook sits about halfway down the fs-writeback stack, just after core has determined that some dirty inodes should be flushed to disk and just before it starts thinking about which inodes those should be. At that point, core calls Tux3 instead of continuing on down the usual do_writepages path. Tux3 responds by staging a new delta commit, using the new helpers to tell core which inodes were flushed versus being left dirty in cache. This is pretty much the same behavior as the traditional writeout path, but less convoluted, probably more efficient, and certainly easier to analyze. The new writeback hook looks like: progress = sb->s_op->writeback(sb, _control, _pages); This should be self-explanatory: nr_pages and progress have the semantics of existing usage in fs-writeback; writeback_control is ignored by Tux3, but that is only because Tux3 always flushes everything and does not require hints for now. We can safely assume that or equivalent is wanted here. An obvious wart is the overlap between "progress" and "nr_pages", but fs-writeback thinks that way, so it would not make much sense to improve one without improving the other. Tux3 necessarily keeps its own dirty inode list, which is an area of overlap with fs-writeback. In a perfect world, there would be just one dirty inode list per superblock, on which both fs-writeback and Tux3 would operate. That would be a deeper core change than seems appropriate right now. Potential races are a big issue with this API, which is no surprise. The fs-writeback scheme requires keeping several kinds of object in sync: tux3 dirty inode lists, fs-writeback dirty inode lists and inode dirty state. The new helpers inode_writeback_done(inode) and inode_writeback_touch(inode) take care of that while hiding internal details of the fs-writeback implementation. Tux3 calls inode_writeback_done when it has flushed an inode and marked it clean, or calls inode_writeback_touch if it intends to retain a dirty inode in cache. These have simple implementations. The former just removes a clean inode from any fs-writeback list. The latter updates the inode's dirty timestamp so that fs-writeback does not keep trying flush it. Both these things could be done more efficiently by re-engineering fs-writeback, but we prefer to work with the existing scheme for now. Hirofumi's masterful hack nicely avoided racy removal of inodes from the writeback list by taking an internal fs-writeback lock inside filesystem code. The new helper requires dropping i_lock inside filesystem code and retaking it in the helper, so inode redirty can race with writeback list removal. This does not seem to present a problem because filesystem code is able to enforce strict alternation of cleaning and calling the helper. As an offsetting advantage, writeback lock contention is reduced. Compared to Hirofumi's hack, the cost of this interface is one additional spinlock per inode_writeback_done, which is insignificant compared to the convoluted code path that is avoided. Regards, Daniel --- From: Daniel Phillips Subject: [PATCH] Add a super operation for writeback Add a "writeback" super operation to be called in the form: progress = sb->s_op->writeback(sb, , ); The filesystem is expected to flush some inodes to disk and return progress of at least 1, or if no inodes are flushed, return progress of zero. The filesystem should try to flush at least the number of pages specified in *pages, or if that is not possible, return approximately the number of pages not flushed into *pages. Within the ->writeback callback, the filesystem should call inode_writeback_done(inode) for each inode flushed (and therefore set clean) or inode_writeback_touch(inode) for any inode that will be retained dirty in cache. Signed-off-by: Daniel Phillips Signed-off-by:
Re: [PATCH] fix a race condition in cancelable mcs spinlocks
On Sun, Jun 01, 2014 at 04:46:26PM -0400, John David Anglin wrote: > On 1-Jun-14, at 3:20 PM, Peter Zijlstra wrote: > > >>If you write to some variable with ACCESS_ONCE and use cmpxchg or xchg > >>at > >>the same time, you break it. ACCESS_ONCE doesn't take the hashed > >>spinlock, > >>so, in this case, cmpxchg or xchg isn't really atomic at all. > > > >And this is really the first place in the kernel that breaks like this? > >I've been using xchg() and cmpxchg() without such consideration for > >quite a while. > > I believe Mikulas is correct. Even in a controlled situation where a > cmpxchg operation > is used to implement pthread_spin_lock() in userspace, we found recently > that the lock > must be released with a cmpxchg operation and not a simple write on SMP > systems. > There is a race in the cache operations or instruction ordering that's not > present with > the ldcw instruction. Oh, I'm not arguing that. He's quite right that its broken, but this form of atomic ops is also quite insane and unusual. Most sane machines don't have this problem. My main concern is how are we going to avoid breaking parisc (and I think sparc32, which is similarly retarded) in the future; we should invest in machinery to find and detect these things. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: rtl8192u: r8192U_core.c: Cleaning up uninitialized variables
Hi Dan I agree, this looks strange. Have been looking for a while in history with, to see if the code has been removed. I start my search using cppcheck for over three months ago. But could not find anything. Sorry about that :-( But I'll make a patch that completely removes testing variable then instead? Best regards Rickard Strandqvist 2014-06-01 22:37 GMT+02:00 Dan Carpenter : > On Sun, Jun 01, 2014 at 03:28:35PM +0200, Rickard Strandqvist wrote: >> There is a risk that the variable will be used without being initialized. >> >> This was largely found by using a static code analysis program called >> cppcheck. >> > > I've looked at the code, but I don't see this variable actually used > anywhere. What is the exact cppcheck warning message? > > regards, > dan carpenter > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix a race condition in cancelable mcs spinlocks
On 1-Jun-14, at 3:20 PM, Peter Zijlstra wrote: If you write to some variable with ACCESS_ONCE and use cmpxchg or xchg at the same time, you break it. ACCESS_ONCE doesn't take the hashed spinlock, so, in this case, cmpxchg or xchg isn't really atomic at all. And this is really the first place in the kernel that breaks like this? I've been using xchg() and cmpxchg() without such consideration for quite a while. I believe Mikulas is correct. Even in a controlled situation where a cmpxchg operation is used to implement pthread_spin_lock() in userspace, we found recently that the lock must be released with a cmpxchg operation and not a simple write on SMP systems. There is a race in the cache operations or instruction ordering that's not present with the ldcw instruction. Dave -- John David Anglin dave.ang...@bell.net -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/15] Thunderbolt driver for Apple MacBooks
On Sun, Jun 1, 2014 at 6:07 PM, Matthew Garrett
wrote:
> On Sun, 2014-06-01 at 12:11 +0200, Andreas Noever wrote:
>> On Sun, Jun 1, 2014 at 1:51 AM, Matthew Garrett
>> wrote:
>> > This seems to be working well on my MBP. It appears to broadly work on
>> > my Mac Pro, which has Thunderbolt 2 hardware - I added the PCI ID, and
>> > loading the thunderbolt driver after the device is plugged in works, but
>> > it won't recognise hotplug events. I don't appear to get any interrupts
>> > from the Thunderbolt controller. Any idea what might be happening there?
>> So the communication with the controller works (dmesg dumps a list of
>> ports etc.)? Do you get plug events ("resetting error on port ...")?
>> You could try to play around with tb_plug_events_active, if you want
>> to experiment. I can also take another look at what OS X does once I
>> get back to my workstation (when I worked on this part falcon ridge
>> was not jet released, so maybe they do things differently now).
>
> Yeah, that was it. I'll mail the patch separately.
Great
>
>> > As far as the quirks go - perhaps something like this would be
>> > reasonable, rather than maintaining a list of machines?
>> I have obtained ACPI dumps from a late 2013 MBP and from a MacPro
>> (both are falcon ridge devices) and these contain a few firmware
>> changes. For example SXIO, SXIL and SXLV are gone so the shutdown
>> quirk will fail. With some luck that means that the shutdown quirk is
>> no longer required for falcon ridge hardware.
>
> Yeah, it seems I don't need the suspend quirk - the NHI is still there
> without it. I still think we should make the quirk general rather than
> tying it to the machines, the worst case is that it'll just do nothing.
Ok, agreed. The "wait" quirk has to run on all machines and the other
one will fail if the ACPI methods are not there. Should I resend the
series or just the patch or should I (or do you want to) make a
separate patch?
Andreas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usb: musb/backfin: Introduce the use of the managed version of kzalloc
This patch moves data allocated using kzalloc to managed data allocated
using devm_kzalloc and cleans now unnecessary kfrees in probe and remove
functions. Also, a label is done away with and err2 and err3 renamed.
The following Coccinelle semantic patch was used for making the change:
@platform@
identifier p, probefn, removefn;
@@
struct platform_driver p = {
.probe = probefn,
.remove = removefn,
};
@prb@
identifier platform.probefn, pdev;
expression e, e1, e2;
@@
probefn(struct platform_device *pdev, ...) {
<+...
- e = kzalloc(e1, e2)
+ e = devm_kzalloc(>dev, e1, e2)
...
?-kfree(e);
...+>
}
@rem depends on prb@
identifier platform.removefn;
expression e;
@@
removefn(...) {
<...
- kfree(e);
...>
}
Signed-off-by: Himangi Saraogi
Acked-by: Julia Lawall
---
Not compile tested due to incompatible architechture.
why is platform_device_alloc called for allocating musb from within the
platform driver probe function where presumably the platform device structure
is already available? I would like to know whether the incoming pdev structure
is somehow not usable or it is a parent device of the device to be used.
drivers/usb/musb/blackfin.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index d40d5f0..ac4422b 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -455,7 +455,7 @@ static int bfin_probe(struct platform_device *pdev)
int ret = -ENOMEM;
- glue = kzalloc(sizeof(*glue), GFP_KERNEL);
+ glue = devm_kzalloc(>dev, sizeof(*glue), GFP_KERNEL);
if (!glue) {
dev_err(>dev, "failed to allocate glue context\n");
goto err0;
@@ -464,7 +464,7 @@ static int bfin_probe(struct platform_device *pdev)
musb = platform_device_alloc("musb-hdrc", PLATFORM_DEVID_AUTO);
if (!musb) {
dev_err(>dev, "failed to allocate musb device\n");
- goto err1;
+ goto err0;
}
musb->dev.parent= >dev;
@@ -478,7 +478,7 @@ static int bfin_probe(struct platform_device *pdev)
glue->phy = usb_phy_generic_register();
if (IS_ERR(glue->phy))
- goto err2;
+ goto err1;
platform_set_drvdata(pdev, glue);
memset(musb_resources, 0x00, sizeof(*musb_resources) *
@@ -498,31 +498,28 @@ static int bfin_probe(struct platform_device *pdev)
ARRAY_SIZE(musb_resources));
if (ret) {
dev_err(>dev, "failed to add resources\n");
- goto err3;
+ goto err2;
}
ret = platform_device_add_data(musb, pdata, sizeof(*pdata));
if (ret) {
dev_err(>dev, "failed to add platform_data\n");
- goto err3;
+ goto err2;
}
ret = platform_device_add(musb);
if (ret) {
dev_err(>dev, "failed to register musb device\n");
- goto err3;
+ goto err2;
}
return 0;
-err3:
- usb_phy_generic_unregister(glue->phy);
-
err2:
- platform_device_put(musb);
+ usb_phy_generic_unregister(glue->phy);
err1:
- kfree(glue);
+ platform_device_put(musb);
err0:
return ret;
@@ -534,7 +531,6 @@ static int bfin_remove(struct platform_device *pdev)
platform_device_unregister(glue->musb);
usb_phy_generic_unregister(glue->phy);
- kfree(glue);
return 0;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Thunderbolt: Add support for Thunderbolt 2 host controllers
On Sun, Jun 1, 2014 at 6:13 PM, Matthew Garrett
wrote:
> Adding extra device IDs is enough to get this working on the second-gen
> Thunderbolt controller in the Mac Pro.
>
> Signed-off-by: Matthew Garrett
> ---
> drivers/pci/quirks.c | 2 ++
> drivers/thunderbolt/nhi.c| 5 +
> drivers/thunderbolt/switch.c | 5 -
> 3 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index c3170d4..20e76d0 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -3083,6 +3083,8 @@ out:
> }
> DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_INTEL, 0x1547,
>quirk_apple_wait_for_thunderbolt);
> +DECLARE_PCI_FIXUP_SUSPEND_LATE(PCI_VENDOR_ID_INTEL, 0x156d,
> + quirk_apple_wait_for_thunderbolt);
> #endif
Just to check: Did they split up the device ids? Is 0x156d for the
bridges and 0x156c for the NHI?
>
> static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f,
> diff --git a/drivers/thunderbolt/nhi.c b/drivers/thunderbolt/nhi.c
> index 6f666fa..85b11d6 100644
> --- a/drivers/thunderbolt/nhi.c
> +++ b/drivers/thunderbolt/nhi.c
> @@ -642,6 +642,11 @@ struct pci_device_id nhi_ids[] = {
> .vendor = PCI_VENDOR_ID_INTEL, .device = 0x1547,
> .subvendor = 0x, .subdevice = 0x,
> },
> + {
> + .class = PCI_CLASS_SYSTEM_OTHER << 8, .class_mask = ~0,
> + .vendor = PCI_VENDOR_ID_INTEL, .device = 0x156c,
> + .subvendor = 0x, .subdevice = 0x,
> + },
> { 0,}
> };
>
> diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c
> index 2e19045..1fccdbf 100644
> --- a/drivers/thunderbolt/switch.c
> +++ b/drivers/thunderbolt/switch.c
> @@ -294,8 +294,11 @@ static int tb_plug_events_active(struct tb_switch *sw,
> bool active)
>
> if (active) {
> data = data & 0xFF83;
> - if (sw->config.device_id == 0x1547)
> + switch (sw->config.device_id) {
> + case 0x1547:
> + case 0x156d:
> data |= 4;
> + }
> } else {
> data = data | 0x7c;
> }
> --
> 2.0.0
>
I have had a look at what os x does. They split between:
1513, 151a, 1549 and 1547, 1548, 1567, 1569, 156b, 156d (the latter
group gets bit 3 set)
It looks like the first 3 are legacy devices, so maybe reverse the check?
So far I could decode:
1547: cactus ridge (2 and 4 port?)
1549: ethernet adapter
156b: 2 port falcon ridge
156d: 4 port falcon ridge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: rtl8192u: r8192U_core.c: Cleaning up uninitialized variables
On Sun, Jun 01, 2014 at 03:28:35PM +0200, Rickard Strandqvist wrote: > There is a risk that the variable will be used without being initialized. > > This was largely found by using a static code analysis program called > cppcheck. > I've looked at the code, but I don't see this variable actually used anywhere. What is the exact cppcheck warning message? regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 11/32] xfs: convert to struct inode_time
Perhaps we should make this a kernel command line option instead, with the settings: error out on outside the standard window, or a date indicating the earliest date that should be recognized and do windowing (0 for no windowing, 1970 for retconning the Unix epoch as unsigned...) But again, the kernel is probably the least problem here... On June 1, 2014 12:56:52 PM PDT, Arnd Bergmann wrote: >On Saturday 31 May 2014 11:46:16 Nicolas Pitre wrote: >> > readonly if not in reality than in practice. >> >> For those (legacy) filesystems with a signed 32-bit timestamps, any >> attempt to create a timestamp past Jan 19 03:14:06 2038 UTC should be > >> (silently) clamped to 0x7fff and that value (the last >representable >> time) used as an overflow indicator. The filesystem driver should >> convert that value into a corresponding overflow value for whatever >> kernel internal time representation being used when read back, and >this >> should be propagated up to user space. It should not be a hard error > >> otherwise, as you rightfully stated, everything non read-only would >come >> to a halt on that day. > >I don't think there is much of a difference between not being able to >write at all and all newly written files having the same timestamp, >causing random things to break differently. > >The clamp to the maximum supported time stamp sounds like a reasonable >choice for 'utimens' and related syscalls for the case of someone >setting an arbitrary future date beyond what the file system can >represent. Then again, I don't see a reason why that shouldn't just >cause an error to be returned. > >For actually running kernels beyond 2038, the best idea I've seen so >far is to disallow all broken code at compile time. I don't see >a choice but to audit the entire kernel for invalid uses on both >32 and 64 bit in the next few years. A lot of code will get changed >in the process so we can actually keep running 32-bit kernels and >file systems, but other code will likely go away: > >* any system calls that pass a time_t, timeval or timespec on > 32-bit systems return -ENOSYS, to ensure all user land uses > the replacements we will put into place >* The definition of 'time_t', 'timval' and 'timespec' can be hidden > from the kernel, and all code using it left out. >* ext2 and ext3 file system code will have to be disabled, but that's > file since ext4 can mount old file systems. >* until xfs gets extended, we can also disiable it at build time. > >For most users, we probably want to leave all that enabled by >default until we get much closer to 2038, but a compile time >option should allow us to test what works or doesn't, and it >can be set by embedded developers that want to ensure their >code keeps running for the next few decades. > > Arnd -- Sent from my mobile phone. Please pardon brevity and lack of formatting. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i2c: busses: i2c-pxa.c: Fix for possible null pointer dereference
On Sat, May 17, 2014 at 07:14:08PM +0200, Rickard Strandqvist wrote:
> There is otherwise a risk of a possible null pointer dereference.
>
> Was largely found by using a static code analysis program called cppcheck.
It is useful to put the output of the analyzer here.
>
> Signed-off-by: Rickard Strandqvist
> ---
> drivers/i2c/busses/i2c-pxa.c |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
> index bbe6dfb..dbe5ebe 100644
> --- a/drivers/i2c/busses/i2c-pxa.c
> +++ b/drivers/i2c/busses/i2c-pxa.c
> @@ -1269,7 +1269,9 @@ eremap:
> eclk:
> kfree(i2c);
> emalloc:
> - release_mem_region(res->start, resource_size(res));
> + if(res) {
> + release_mem_region(res->start, resource_size(res));
> + }
The proper fix is to move the release to the proper place, before kfree.
Even better would probably be a devm_* conversion.
signature.asc
Description: Digital signature
[PATCH] net: wireless: rtlwifi: rtl8192de: phy.c: Cleaning up uninitialized variable
There is a risk that the variables will be used without being initialized.
Have also moved variable to the part of the code where it is used.
This was largely found by using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/net/wireless/rtlwifi/rtl8192de/phy.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192de/phy.c
b/drivers/net/wireless/rtlwifi/rtl8192de/phy.c
index 3d1f0dd..592125a 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192de/phy.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192de/phy.c
@@ -203,11 +203,12 @@ u32 rtl92d_phy_query_bb_reg(struct ieee80211_hw *hw, u32
regaddr, u32 bitmask)
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_hal *rtlhal = rtl_hal(rtlpriv);
u32 returnvalue, originalvalue, bitshift;
- u8 dbi_direct;
RT_TRACE(rtlpriv, COMP_RF, DBG_TRACE, "regaddr(%#x), bitmask(%#x)\n",
regaddr, bitmask);
if (rtlhal->during_mac1init_radioa || rtlhal->during_mac0init_radiob) {
+ u8 dbi_direct = 0;
+
/* mac1 use phy0 read radio_b. */
/* mac0 use phy1 read radio_b. */
if (rtlhal->during_mac1init_radioa)
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i2c-davinci: Handle signals gracefully
> Feel free to adap my patch or comments and commit. Or wait a few weeks for > when I have a sponsor to split and update the patch. OK, I'll hope you can make it for 3.17. Thanks! signature.asc Description: Digital signature
[PATCH] power: ab8500_fg.c: Cleaning up uninitialized variables
In this case the wrong variable is used, which has never been initialized.
This will lead to a serious error.
This was largely found by using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/power/ab8500_fg.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/power/ab8500_fg.c b/drivers/power/ab8500_fg.c
index 3cb4178..019e33f 100644
--- a/drivers/power/ab8500_fg.c
+++ b/drivers/power/ab8500_fg.c
@@ -2969,7 +2969,7 @@ static struct device_attribute
ab8505_fg_sysfs_psy_attrs[] = {
static int ab8500_fg_sysfs_psy_create_attrs(struct device *dev)
{
- unsigned int i, j;
+ unsigned int j;
struct power_supply *psy = dev_get_drvdata(dev);
struct ab8500_fg *di;
@@ -2986,7 +2986,7 @@ static int ab8500_fg_sysfs_psy_create_attrs(struct device
*dev)
sysfs_psy_create_attrs_failed_ab8505:
dev_err(dev, "Failed creating sysfs psy attrs for ab8505.\n");
while (j--)
- device_remove_file(dev, _fg_sysfs_psy_attrs[i]);
+ device_remove_file(dev, _fg_sysfs_psy_attrs[j]);
return -EIO;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 11/32] xfs: convert to struct inode_time
On Saturday 31 May 2014 11:46:16 Nicolas Pitre wrote: > > readonly if not in reality than in practice. > > For those (legacy) filesystems with a signed 32-bit timestamps, any > attempt to create a timestamp past Jan 19 03:14:06 2038 UTC should be > (silently) clamped to 0x7fff and that value (the last representable > time) used as an overflow indicator. The filesystem driver should > convert that value into a corresponding overflow value for whatever > kernel internal time representation being used when read back, and this > should be propagated up to user space. It should not be a hard error > otherwise, as you rightfully stated, everything non read-only would come > to a halt on that day. I don't think there is much of a difference between not being able to write at all and all newly written files having the same timestamp, causing random things to break differently. The clamp to the maximum supported time stamp sounds like a reasonable choice for 'utimens' and related syscalls for the case of someone setting an arbitrary future date beyond what the file system can represent. Then again, I don't see a reason why that shouldn't just cause an error to be returned. For actually running kernels beyond 2038, the best idea I've seen so far is to disallow all broken code at compile time. I don't see a choice but to audit the entire kernel for invalid uses on both 32 and 64 bit in the next few years. A lot of code will get changed in the process so we can actually keep running 32-bit kernels and file systems, but other code will likely go away: * any system calls that pass a time_t, timeval or timespec on 32-bit systems return -ENOSYS, to ensure all user land uses the replacements we will put into place * The definition of 'time_t', 'timval' and 'timespec' can be hidden from the kernel, and all code using it left out. * ext2 and ext3 file system code will have to be disabled, but that's file since ext4 can mount old file systems. * until xfs gets extended, we can also disiable it at build time. For most users, we probably want to leave all that enabled by default until we get much closer to 2038, but a compile time option should allow us to test what works or doesn't, and it can be set by embedded developers that want to ensure their code keeps running for the next few decades. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
