[PATCH 1/1] Adds support for Lenovo 10/100 USB dongle.
This dongle ships with the X1 Carbon, and has an AX88772B
usb to ethernet chip in it.
Signed-off-by: Quinlan Pfiffer
---
drivers/net/usb/asix_devices.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
index 32e31c5..fc20e53 100644
--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -930,6 +930,10 @@ static const struct usb_device_id products [] = {
USB_DEVICE (0x04f1, 0x3008),
.driver_info = (unsigned long) _info,
}, {
+ // Lenovo U2L100P 10/100
+ USB_DEVICE (0x17ef, 0x7203),
+ .driver_info = (unsigned long) _info,
+}, {
// ASIX AX88772B 10/100
USB_DEVICE (0x0b95, 0x772b),
.driver_info = (unsigned long) _info,
--
1.7.12.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] loop: Make explicit loop device destruction lazy
On 2012-09-28 16:38, Dave Jones wrote: > On Fri, Sep 28, 2012 at 10:41:50AM +0200, Jens Axboe wrote: > > > > Turns out that blkid is running simultaneously with losetup -d, and > > > so it sees an elevated reference count and returns EBUSY. But why > > > is blkid running? It's obvious, isn't it? udev has decided to try > > > and find out what is on the block device as a result of a creation > > > notification. And it is racing with mkfs, so might still be scanning > > > the device when mkfs finishes and we try to tear it down. > > > > > I hear that %^#@#! blkid behavior, it is such a pain in the neck. I > > don't know how many times I've had to explain that behaviour to people > > who run write testing with tracing, wonder wtf there are reads in the > > trace. > > Could this problem explain this bug too ? > https://bugzilla.redhat.com/show_bug.cgi?id=853674 It certainly looks like it! -- Jens Axboe -- 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] loop: Make explicit loop device destruction lazy
On 2012-09-28 17:02, Jeff Moyer wrote: > Jens Axboe writes: > >> On 2012-09-28 08:09, Dave Chinner wrote: >>> From: Dave Chinner >>> >>> xfstests has always had random failures of tests due to loop devices >>> failing to be torn down and hence leaving filesytems that cannot be >>> unmounted. This causes test runs to immediately stop. >>> >>> Over the past 6 or 7 years we've added hacks like explicit unmount >>> -d commands for loop mounts, losetup -d after unmount -d fails, etc, >>> but still the problems persist. Recently, the frequency of loop >>> related failures increased again to the point that xfstests 259 will >>> reliably fail with a stray loop device that was not torn down. >>> >>> That is despite the fact the test is above as simple as it gets - >>> loop 5 or 6 times running mkfs.xfs with different paramters: >>> >>> lofile=$(losetup -f) >>> losetup $lofile "$testfile" >>> "$MKFS_XFS_PROG" -b size=512 $lofile >/dev/null || echo "mkfs >>> failed!" >>> sync >>> losetup -d $lofile >>> >>> And losteup -d $lofile is failing with EBUSY on 1-3 of these loops >>> every time the test is run. >>> >>> Turns out that blkid is running simultaneously with losetup -d, and >>> so it sees an elevated reference count and returns EBUSY. But why >>> is blkid running? It's obvious, isn't it? udev has decided to try >>> and find out what is on the block device as a result of a creation >>> notification. And it is racing with mkfs, so might still be scanning >>> the device when mkfs finishes and we try to tear it down. >>> >>> So, make losetup -d force autoremove behaviour. That is, when the >>> last reference goes away, tear down the device. xfstests wants it >>> *gone*, not causing random teardown failures when we know that all >>> the operations the tests have specifically run on the device have >>> completed and are no longer referencing the loop device. >> >> I hear that %^#@#! blkid behavior, it is such a pain in the neck. I >> don't know how many times I've had to explain that behaviour to people >> who run write testing with tracing, wonder wtf there are reads in the >> trace. >> >> Patch looks fine, seems like the sane thing to do (lazy-remove on last >> drop) for this case. > > Do we also want to prevent further opens? That's not a bad idea, at least it would be the logical thing to do. But it does get into the realm of potentially breaking existing behaviour. -- Jens Axboe -- 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/
Etron usb3 device not detected on Qnap TS 119 P II
I have a situation where a single-bay NAS, the Qnap TS 119 P II in the newest revision has 2 usb3 ports on the back. When using the 3.6-rc7 kernel (and earlier ones), these ports don't exist. There is no output with lsusb, and the device doesn't show up with lspci or dmesg. The directory /sys/devices/pci is empty. Qnap's own kernel, a patched variety of 2.6.33.2, adds a separate etcxhci-pci driver that does find the hardware, with vendorid PCI_VENDOR_ID_ETRON 0x1b6f and PCI_DEVICE_ID_ASROCK_P67 0x7023. I did notice these ids are in the 3.6-rc7 xhci-pci.c file, so the new kernel should support the hardware. Contact with Sarah Sharp, the author of xhci-pci.c, pointed out that Qnap likely did something in the pci-enumeration code to get the device activated. This is a armiv5tel device, running a Marvell Feroceon cpu. I have a serial console cable and can run experimental kernels/patches. What I would dearly like is some pointers about where to turn on debugging and what to post here to get find out where things go wrong. I'm posting it here, since I think it might be more of a general pci device problem than an usb problem. Thanks, Jurriaan -- 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 scsi] Short the path length of scsi_cmd_to_driver()
As suggested by James: this patch tries to short the path length of
scsi_cmd_to_driver(). As only REQ_TYPE_BLOCK_PC commands can be
submitted without a driver, so we could avoid the related NULL
checking, as long as we make sure we don't use it for REQ_TYPE_BLOCK_PC
type commands. Plus, this fixes a bug where you get different behaviors
from REQ_TYPE_BLOCK_PC commands when a driver is and isn't attached.
v2: mirror code != REQ_TYPE_BLOCK_PC in scsi.c, rather than == REQ_TYPE_FS
Signed-off-by: Li Zhong
---
drivers/scsi/scsi_error.c |8 +---
include/scsi/scsi_cmnd.h | 12 ++--
2 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index de2337f..c1b05a8 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -789,7 +789,6 @@ static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd,
unsigned char *cmnd,
int cmnd_size, int timeout, unsigned sense_bytes)
{
struct scsi_device *sdev = scmd->device;
- struct scsi_driver *sdrv = scsi_cmd_to_driver(scmd);
struct Scsi_Host *shost = sdev->host;
DECLARE_COMPLETION_ONSTACK(done);
unsigned long timeleft;
@@ -845,8 +844,11 @@ static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd,
unsigned char *cmnd,
scsi_eh_restore_cmnd(scmd, );
- if (sdrv && sdrv->eh_action)
- rtn = sdrv->eh_action(scmd, cmnd, cmnd_size, rtn);
+ if (scmd->request->cmd_type != REQ_TYPE_BLOCK_PC) {
+ struct scsi_driver *sdrv = scsi_cmd_to_driver(scmd);
+ if (sdrv->eh_action)
+ rtn = sdrv->eh_action(scmd, cmnd, cmnd_size, rtn);
+ }
return rtn;
}
diff --git a/include/scsi/scsi_cmnd.h b/include/scsi/scsi_cmnd.h
index ac06cc5..de5f5d8 100644
--- a/include/scsi/scsi_cmnd.h
+++ b/include/scsi/scsi_cmnd.h
@@ -132,18 +132,10 @@ struct scsi_cmnd {
unsigned char tag; /* SCSI-II queued command tag */
};
+/* make sure not to use it with REQ_TYPE_BLOCK_PC commands */
static inline struct scsi_driver *scsi_cmd_to_driver(struct scsi_cmnd *cmd)
{
- struct scsi_driver **sdp;
-
- if (!cmd->request->rq_disk)
- return NULL;
-
- sdp = (struct scsi_driver **)cmd->request->rq_disk->private_data;
- if (!sdp)
- return NULL;
-
- return *sdp;
+ return *(struct scsi_driver **)cmd->request->rq_disk->private_data;
}
extern struct scsi_cmnd *scsi_get_command(struct scsi_device *, gfp_t);
--
1.7.7.6
--
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 v9 PATCH 00/21] memory-hotplug: hot-remove physical memory
On 09/05/2012 05:25 PM, we...@cn.fujitsu.com wrote:
From: Wen Congyang
This patch series aims to support physical memory hot-remove.
The patches can free/remove the following things:
- acpi_memory_info : [RFC PATCH 4/19]
- /sys/firmware/memmap/X/{end, start, type} : [RFC PATCH 8/19]
- iomem_resource: [RFC PATCH 9/19]
- mem_section and related sysfs files : [RFC PATCH 10-11, 13-16/19]
- page table of removed memory : [RFC PATCH 12/19]
- node and related sysfs files : [RFC PATCH 18-19/19]
If you find lack of function for physical memory hot-remove, please let me
know.
Since patchset is too big, could you add more patchset changelog to
describe how this patchset works? in order that it is easier to review.
How to test this patchset?
1. apply this patchset and build the kernel. MEMORY_HOTPLUG, MEMORY_HOTREMOVE,
ACPI_HOTPLUG_MEMORY must be selected.
2. load the module acpi_memhotplug
3. hotplug the memory device(it depends on your hardware)
You will see the memory device under the directory /sys/bus/acpi/devices/.
Its name is PNP0C80:XX.
4. online/offline pages provided by this memory device
You can write online/offline to /sys/devices/system/memory/memoryX/state to
online/offline pages provided by this memory device
5. hotremove the memory device
You can hotremove the memory device by the hardware, or writing 1 to
/sys/bus/acpi/devices/PNP0C80:XX/eject.
Note: if the memory provided by the memory device is used by the kernel, it
can't be offlined. It is not a bug.
Known problems:
1. memory can't be offlined when CONFIG_MEMCG is selected.
For example: there is a memory device on node 1. The address range
is [1G, 1.5G). You will find 4 new directories memory8, memory9, memory10,
and memory11 under the directory /sys/devices/system/memory/.
If CONFIG_MEMCG is selected, we will allocate memory to store page cgroup
when we online pages. When we online memory8, the memory stored page cgroup
is not provided by this memory device. But when we online memory9, the
memory
stored page cgroup may be provided by memory8. So we can't offline memory8
now. We should offline the memory in the reversed order.
When the memory device is hotremoved, we will auto offline memory provided
by this memory device. But we don't know which memory is onlined first, so
offlining memory may fail. In such case, you should offline the memory by
hand before hotremoving the memory device.
2. hotremoving memory device may cause kernel panicked
This bug will be fixed by Liu Jiang's patch:
https://lkml.org/lkml/2012/7/3/1
change log of v9:
[RFC PATCH v9 8/21]
* add a lock to protect the list map_entries
* add an indicator to firmware_map_entry to remember whether the memory
is allocated from bootmem
[RFC PATCH v9 10/21]
* change the macro to inline function
[RFC PATCH v9 19/21]
* don't offline the node if the cpu on the node is onlined
[RFC PATCH v9 21/21]
* create new patch: auto offline page_cgroup when onlining memory block
failed
change log of v8:
[RFC PATCH v8 17/20]
* Fix problems when one node's range include the other nodes
[RFC PATCH v8 18/20]
* fix building error when CONFIG_MEMORY_HOTPLUG_SPARSE or CONFIG_HUGETLBFS
is not defined.
[RFC PATCH v8 19/20]
* don't offline node when some memory sections are not removed
[RFC PATCH v8 20/20]
* create new patch: clear hwpoisoned flag when onlining pages
change log of v7:
[RFC PATCH v7 4/19]
* do not continue if acpi_memory_device_remove_memory() fails.
[RFC PATCH v7 15/19]
* handle usemap in register_page_bootmem_info_section() too.
change log of v6:
[RFC PATCH v6 12/19]
* fix building error on other archtitectures than x86
[RFC PATCH v6 15-16/19]
* fix building error on other archtitectures than x86
change log of v5:
* merge the patchset to clear page table and the patchset to hot remove
memory(from ishimatsu) to one big patchset.
[RFC PATCH v5 1/19]
* rename remove_memory() to offline_memory()/offline_pages()
[RFC PATCH v5 2/19]
* new patch: implement offline_memory(). This function offlines pages,
update memory block's state, and notify the userspace that the memory
block's state is changed.
[RFC PATCH v5 4/19]
* offline and remove memory in acpi_memory_disable_device() too.
[RFC PATCH v5 17/19]
* new patch: add a new function __remove_zone() to revert the things done
in the function __add_zone().
[RFC PATCH v5 18/19]
* flush work befor reseting node device.
change log of v4:
* remove "memory-hotplug : unify argument of firmware_map_add_early/hotplug"
from the patch series, since the patch is a bugfix. It is being disccussed
on other thread. But for testing the patch series, the patch is needed.
So I added the patch as
[PATCH 0/3] Volatile Ranges (v7) & Lots of words
After Kernel Summit and Plumbers, I wanted to consider all the various side-discussions and try to summarize my current thoughts here along with sending out my current implementation for review. Also: I'm going on four weeks of paternity leave in the very near (but non-deterministic) future. So while I hope I still have time for some discussion, I may have to deal with fussier complaints then yours. :) In any case, you'll have more time to chew on the idea and come up with amazing suggestions. :) General Interface semantics: -- The high level interface I've been pushing has so far stayed fairly consistent: Application marks a range of data as volatile. Volatile data may be purged at any time. Accessing volatile data is undefined, so applications should not do so. If the application wants to access data in a volatile range, it should mark it as non-volatile. If any of the pages in the range being marked non-volatile had been purged, the kernel will return an error, notifying the application that the data was lost. But one interesting new tweak on this design, suggested by the Taras Glek and others at Mozilla, is as follows: Instead of leaving volatile data access as being undefined , when accessing volatile data, either the data expected will be returned if it has not been purged, or the application will get a SIGBUS when it accesses volatile data that has been purged. Everything else remains the same (error on marking non-volatile if data was purged, etc). This model allows applications to avoid having to unmark volatile data when it wants to access it, then immediately re-mark it as volatile when its done. It is in effect "lazy" with its marking, allowing the kernel to hit it with a signal when it gets unlucky and touches purged data. From the signal handler, the application can note the address it faulted on, unmark the range, and regenerate the needed data before returning to execution. Since this approach avoids the more explicit unmark/access/mark pattern, it avoids the extra overhead required to ensure data is non-volatile before being accessed. However, If applications don't want to deal with handling the sigbus, they can use the more straightforward (but more costly) unmark/access/mark pattern in the same way as my earlier proposals. This allows folks to balance the cost vs complexity in their application appropriately. So that's a general overview of how the idea I'm proposing could be used. Specific Interface semantics: - Here are some of the open question about how the user interface should look: fadvise vs fallocate: So while originally I used fadvise, currently my implementation uses fallocate(fd, FALLOC_FL_MARK_VOLATILE, start, len) to mark a range as volatile and fallocate(fd, FALLOC_FL_UNMARK_VOLATILE, start, len) to unmark ranges. During kernel summit, the question was brought up if fallocate was really the right interface to be using, and if fadvise would be better. To me fadvise makes a little more sense, but earlier it was pointed out that marking data ranges as volatile could also be seen as a type of cancellable and lazy hole-punching, so from that perspective fallocate might make more sense. This is still an open question and I'd appreciate further input here. tmpfs vs non-shmem filesystems: Android's ashmem primarily provides a way to get unlinked tmpfs fds that can be shared between applications. Its just an additional feature that those pages can "unpinned" or marked volatile in my terminology. Thus in implementing volatile ranges, I've focused on getting it to work on tmpfs file descriptors. However, there has been some interest in using volatile ranges with more traditional filesystems. The semantics for how volatile range purging would work on a real filesystem are not well established, and I can't say I understand the utility quite yet, but there may be a case for having data that you know won't be committed to disk until it is marked as non-volatile. However, returning an EINVAL on non-tmpfs filesystems until such a use is established should be fine. fd based interfaces vs madvise: In talking with Taras Glek, he pointed out that for his needs, the fd based interface is a little annoying, as it requires having to get access to tmpfs file and mmap it in, then instead of just referencing a pointer to the data he wants to mark volatile, he has to calculate the offset from start of the mmap and pass those file offsets to the interface. Instead he mentioned that using something like madvise would be much nicer, since they could just pass a pointer to the object in memory they want to make
[PATCH 3/3] [RFC] ashmem: Convert ashmem to use volatile ranges
Rework of my first pass attempt at getting ashmem to utilize
the volatile range code, now using the fallocate interface.
In this implementation GET_PIN_STATUS is unimplemented, due to
the fact that adding a ISVOLATILE check wasn't considered
terribly useful in earlier reviews. It would be trivial to
re-add that functionality, but I wanted to check w/ the
Android developers to see how often GET_PIN_STATUS is actually
used?
Similarly the ashmem PURGE_ALL_CACHES ioctl does not function,
as the volatile range purging is no longer directly under its
control.
Cc: Andrew Morton
Cc: Android Kernel Team
Cc: Robert Love
Cc: Mel Gorman
Cc: Hugh Dickins
Cc: Dave Hansen
Cc: Rik van Riel
Cc: Dmitry Adamushko
Cc: Dave Chinner
Cc: Neil Brown
Cc: Andrea Righi
Cc: Aneesh Kumar K.V
Cc: Mike Hommey
Cc: Taras Glek
Cc: Jan Kara
Cc: KOSAKI Motohiro
Cc: Michel Lespinasse
Cc: Minchan Kim
Cc: linux...@kvack.org
Signed-off-by: John Stultz
---
drivers/staging/android/ashmem.c | 335 ++
1 file changed, 10 insertions(+), 325 deletions(-)
diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c
index 69cf2db..9f9654c 100644
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -52,26 +52,6 @@ struct ashmem_area {
};
/*
- * ashmem_range - represents an interval of unpinned (evictable) pages
- * Lifecycle: From unpin to pin
- * Locking: Protected by `ashmem_mutex'
- */
-struct ashmem_range {
- struct list_head lru; /* entry in LRU list */
- struct list_head unpinned; /* entry in its area's unpinned list */
- struct ashmem_area *asma; /* associated area */
- size_t pgstart; /* starting page, inclusive */
- size_t pgend; /* ending page, inclusive */
- unsigned int purged;/* ASHMEM_NOT or ASHMEM_WAS_PURGED */
-};
-
-/* LRU list of unpinned pages, protected by ashmem_mutex */
-static LIST_HEAD(ashmem_lru_list);
-
-/* Count of pages on our LRU list, protected by ashmem_mutex */
-static unsigned long lru_count;
-
-/*
* ashmem_mutex - protects the list of and each individual ashmem_area
*
* Lock Ordering: ashmex_mutex -> i_mutex -> i_alloc_sem
@@ -79,102 +59,9 @@ static unsigned long lru_count;
static DEFINE_MUTEX(ashmem_mutex);
static struct kmem_cache *ashmem_area_cachep __read_mostly;
-static struct kmem_cache *ashmem_range_cachep __read_mostly;
-
-#define range_size(range) \
- ((range)->pgend - (range)->pgstart + 1)
-
-#define range_on_lru(range) \
- ((range)->purged == ASHMEM_NOT_PURGED)
-
-#define page_range_subsumes_range(range, start, end) \
- (((range)->pgstart >= (start)) && ((range)->pgend <= (end)))
-
-#define page_range_subsumed_by_range(range, start, end) \
- (((range)->pgstart <= (start)) && ((range)->pgend >= (end)))
-
-#define page_in_range(range, page) \
- (((range)->pgstart <= (page)) && ((range)->pgend >= (page)))
-
-#define page_range_in_range(range, start, end) \
- (page_in_range(range, start) || page_in_range(range, end) || \
- page_range_subsumes_range(range, start, end))
-
-#define range_before_page(range, page) \
- ((range)->pgend < (page))
#define PROT_MASK (PROT_EXEC | PROT_READ | PROT_WRITE)
-static inline void lru_add(struct ashmem_range *range)
-{
- list_add_tail(>lru, _lru_list);
- lru_count += range_size(range);
-}
-
-static inline void lru_del(struct ashmem_range *range)
-{
- list_del(>lru);
- lru_count -= range_size(range);
-}
-
-/*
- * range_alloc - allocate and initialize a new ashmem_range structure
- *
- * 'asma' - associated ashmem_area
- * 'prev_range' - the previous ashmem_range in the sorted asma->unpinned list
- * 'purged' - initial purge value (ASMEM_NOT_PURGED or ASHMEM_WAS_PURGED)
- * 'start' - starting page, inclusive
- * 'end' - ending page, inclusive
- *
- * Caller must hold ashmem_mutex.
- */
-static int range_alloc(struct ashmem_area *asma,
- struct ashmem_range *prev_range, unsigned int purged,
- size_t start, size_t end)
-{
- struct ashmem_range *range;
-
- range = kmem_cache_zalloc(ashmem_range_cachep, GFP_KERNEL);
- if (unlikely(!range))
- return -ENOMEM;
-
- range->asma = asma;
- range->pgstart = start;
- range->pgend = end;
- range->purged = purged;
-
- list_add_tail(>unpinned, _range->unpinned);
-
- if (range_on_lru(range))
- lru_add(range);
-
- return 0;
-}
-
-static void range_del(struct ashmem_range *range)
-{
- list_del(>unpinned);
- if (range_on_lru(range))
- lru_del(range);
- kmem_cache_free(ashmem_range_cachep, range);
-}
-
-/*
- * range_shrink - shrinks a range
- *
- * Caller must hold ashmem_mutex.
- */
-static inline void range_shrink(struct ashmem_range *range,
-
[PATCH 1/3] [RFC] Add volatile range management code
This patch provides the volatile range management code
that filesystems can utilize when implementing
FALLOC_FL_MARK_VOLATILE.
It tracks a collection of page ranges against a mapping
stored in an interval-tree. This code handles coalescing
overlapping and adjacent ranges, as well as splitting
ranges when sub-chunks are removed.
The ranges can be marked purged or unpurged. And there is
a per-fs lru list that tracks all the unpurged ranges for
that fs.
v2:
* Fix bug in volatile_ranges_get_last_used returning bad
start,end values
* Rework for intervaltree renaming
* Optimize volatile_range_lru_size to avoid running through
lru list each time.
v3:
* Improve function name to make it clear what the
volatile_ranges_pluck_lru() code does.
* Drop volatile_range_lru_size and unpurged_page_count
mangement as its now unused
v4:
* Re-add volatile_range_lru_size and unpruged_page_count
* Fix bug in range_remove when we split ranges, we add
an overlapping range before resizing the existing range.
v5:
* Drop intervaltree for prio_tree usage per Michel &
Dmitry's suggestions.
* Cleanups
v6:
* Drop prio_tree usage for rbtree per Michel Lespinasse's
suggestion.
v7:
* Use byte ranges instead of page ranges to make userspace's
life easier.
* Add volatile_range_address_is_purged check for SIGBUS on
purged page access.
Cc: Andrew Morton
Cc: Android Kernel Team
Cc: Robert Love
Cc: Mel Gorman
Cc: Hugh Dickins
Cc: Dave Hansen
Cc: Rik van Riel
Cc: Dmitry Adamushko
Cc: Dave Chinner
Cc: Neil Brown
Cc: Andrea Righi
Cc: Aneesh Kumar K.V
Cc: Mike Hommey
Cc: Taras Glek
Cc: Jan Kara
Cc: KOSAKI Motohiro
Cc: Michel Lespinasse
Cc: Minchan Kim
Cc: linux...@kvack.org
Signed-off-by: John Stultz
---
include/linux/volatile.h | 46
mm/Makefile |2 +-
mm/volatile.c| 580 ++
3 files changed, 627 insertions(+), 1 deletion(-)
create mode 100644 include/linux/volatile.h
create mode 100644 mm/volatile.c
diff --git a/include/linux/volatile.h b/include/linux/volatile.h
new file mode 100644
index 000..c59a0f9
--- /dev/null
+++ b/include/linux/volatile.h
@@ -0,0 +1,46 @@
+#ifndef _LINUX_VOLATILE_H
+#define _LINUX_VOLATILE_H
+
+#include
+
+struct volatile_fs_head {
+ struct mutex lock;
+ struct list_head lru_head;
+ s64 unpurged_page_count;
+};
+
+#define DEFINE_VOLATILE_FS_HEAD(name) struct volatile_fs_head name = { \
+ .lock = __MUTEX_INITIALIZER(name.lock), \
+ .lru_head = LIST_HEAD_INIT(name.lru_head), \
+ .unpurged_page_count = 0, \
+}
+
+static inline void volatile_range_lock(struct volatile_fs_head *head)
+{
+ mutex_lock(>lock);
+}
+
+static inline void volatile_range_unlock(struct volatile_fs_head *head)
+{
+ mutex_unlock(>lock);
+}
+
+extern long volatile_range_add(struct volatile_fs_head *head,
+ struct address_space *mapping,
+ u64 *start, u64 *end);
+extern long volatile_range_remove(struct volatile_fs_head *head,
+ struct address_space *mapping,
+ u64 start, u64 end);
+
+extern s64 volatile_range_lru_size(struct volatile_fs_head *head);
+
+extern void volatile_range_clear(struct volatile_fs_head *head,
+ struct address_space *mapping);
+
+extern s64 volatile_ranges_pluck_lru(struct volatile_fs_head *head,
+ struct address_space **mapping,
+ u64 *start, u64 *end);
+
+extern int volatile_range_is_purged(struct address_space *mapping, u64 addr);
+
+#endif /* _LINUX_VOLATILE_H */
diff --git a/mm/Makefile b/mm/Makefile
index 92753e2..4c18cd1 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -16,7 +16,7 @@ obj-y := filemap.o mempool.o oom_kill.o
fadvise.o \
readahead.o swap.o truncate.o vmscan.o shmem.o \
prio_tree.o util.o mmzone.o vmstat.o backing-dev.o \
mm_init.o mmu_context.o percpu.o slab_common.o \
- compaction.o $(mmu-y)
+ compaction.o volatile.o $(mmu-y)
obj-y += init-mm.o
diff --git a/mm/volatile.c b/mm/volatile.c
new file mode 100644
index 000..6d3e418
--- /dev/null
+++ b/mm/volatile.c
@@ -0,0 +1,580 @@
+/* mm/volatile.c
+ *
+ * Volatile range management.
+ * Copyright 2011 Linaro
+ *
+ * Based on mm/ashmem.c
+ * by Robert Love
+ * Copyright (C) 2008 Google, Inc.
+ *
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the
[PATCH 2/3] [RFC] tmpfs: Add FALLOC_FL_MARK_VOLATILE/UNMARK_VOLATILE handlers
This patch enables FALLOC_FL_MARK_VOLATILE/UNMARK_VOLATILE
functionality for tmpfs making use of the volatile range
management code.
Conceptually, FALLOC_FL_MARK_VOLATILE is like a delayed
FALLOC_FL_PUNCH_HOLE. This allows applications that have
data caches that can be re-created to tell the kernel that
some memory contains data that is useful in the future, but
can be recreated if needed, so if the kernel needs, it can
zap the memory without having to swap it out.
In use, applications use FALLOC_FL_MARK_VOLATILE to mark
page ranges as volatile when they are not in use. Then later
if they wants to reuse the data, they use
FALLOC_FL_UNMARK_VOLATILE, which will return an error if the
data has been purged.
This is very much influenced by the Android Ashmem interface by
Robert Love so credits to him and the Android developers.
In many cases the code & logic come directly from the ashmem patch.
The intent of this patch is to allow for ashmem-like behavior, but
embeds the idea a little deeper into the VM code.
This is a reworked version of the fadvise volatile idea submitted
earlier to the list. Thanks to Dave Chinner for suggesting to
rework the idea in this fashion. Also thanks to Dmitry Adamushko
for continued review and bug reporting, and Dave Hansen for
help with the original design and mentoring me in the VM code.
v3:
* Fix off by one issue when truncating page ranges
* Use Dave Hansesn's suggestion to use shmem_writepage to trigger
range purging instead of using a shrinker.
v4:
* Revert the shrinker removal, since writepage won't get called
if we don't have swap.
v5:
* Cleanups
v7:
* Convert to byte ranges rather then page ranges to make userland's
life easier.
* Add volatile_range_address_is_purged checking in shmem_fault to
proivde SIGBUS on purged page access.
Cc: Andrew Morton
Cc: Android Kernel Team
Cc: Robert Love
Cc: Mel Gorman
Cc: Hugh Dickins
Cc: Dave Hansen
Cc: Rik van Riel
Cc: Dmitry Adamushko
Cc: Dave Chinner
Cc: Neil Brown
Cc: Andrea Righi
Cc: Aneesh Kumar K.V
Cc: Mike Hommey
Cc: Taras Glek
Cc: Jan Kara
Cc: KOSAKI Motohiro
Cc: Michel Lespinasse
Cc: Minchan Kim
Cc: linux...@kvack.org
Signed-off-by: John Stultz
---
fs/open.c |3 +-
include/linux/falloc.h |7 +--
mm/shmem.c | 120
3 files changed, 126 insertions(+), 4 deletions(-)
diff --git a/fs/open.c b/fs/open.c
index e1f2cdb..6b8b983 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -225,7 +225,8 @@ int do_fallocate(struct file *file, int mode, loff_t
offset, loff_t len)
return -EINVAL;
/* Return error if mode is not supported */
- if (mode & ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE))
+ if (mode & ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE |
+ FALLOC_FL_MARK_VOLATILE | FALLOC_FL_UNMARK_VOLATILE))
return -EOPNOTSUPP;
/* Punch hole must have keep size set */
diff --git a/include/linux/falloc.h b/include/linux/falloc.h
index 73e0b62..3e47ad5 100644
--- a/include/linux/falloc.h
+++ b/include/linux/falloc.h
@@ -1,9 +1,10 @@
#ifndef _FALLOC_H_
#define _FALLOC_H_
-#define FALLOC_FL_KEEP_SIZE0x01 /* default is extend size */
-#define FALLOC_FL_PUNCH_HOLE 0x02 /* de-allocates range */
-
+#define FALLOC_FL_KEEP_SIZE0x01 /* default is extend size */
+#define FALLOC_FL_PUNCH_HOLE 0x02 /* de-allocates range */
+#define FALLOC_FL_MARK_VOLATILE0x04 /* mark range volatile */
+#define FALLOC_FL_UNMARK_VOLATILE 0x08 /* mark range non-volatile */
#ifdef __KERNEL__
/*
diff --git a/mm/shmem.c b/mm/shmem.c
index d4e184e..9403ffb 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -64,6 +64,7 @@ static struct vfsmount *shm_mnt;
#include
#include
#include
+#include
#include
#include
@@ -633,6 +634,100 @@ static int shmem_setattr(struct dentry *dentry, struct
iattr *attr)
return error;
}
+static DEFINE_VOLATILE_FS_HEAD(shmem_volatile_head);
+
+static int shmem_mark_volatile(struct inode *inode, loff_t offset, loff_t len)
+{
+ u64 start, end;
+ int ret;
+
+ start = offset;
+ end = offset + len;
+
+ volatile_range_lock(_volatile_head);
+ ret = volatile_range_add(_volatile_head, >i_data,
+ , );
+ if (ret > 0) { /* immdiately purge */
+ shmem_truncate_range(inode, (loff_t)start, (loff_t)end-1);
+ ret = 0;
+ }
+ volatile_range_unlock(_volatile_head);
+
+ return ret;
+}
+
+static int shmem_unmark_volatile(struct inode *inode, loff_t offset, loff_t
len)
+{
+ u64 start, end;
+ int ret;
+
+ start = offset;
+ end = offset + len;
+
+ volatile_range_lock(_volatile_head);
+ ret = volatile_range_remove(_volatile_head, >i_data,
+ start, end);
+
Re: [RFC] x86: mtrr: Constrain WB MTRR to max phys mem prior to cleanup
On 09/28/2012 10:37 AM, Peter Hurley wrote: > > An interesting side note: more recent revisions of this BIOS (rev. A11) > report one less variable MTRR (so, IA32_MTRRCAP is writable?) > >>> However, the right way to fix that is to use the PAT interfaces, which >>> doesn't have this drawback -- then MTRR cleanup becomes entirely >>> superfluous and the problem goes away. >> Do you mean disable MTRR totally here? > > Well, since PAT entries marked WC override all MTRR settings, whatever > the BIOS set the variable MTRRs to becomes irrelevant, so not disabled > but rather ignored. > The whole point is that the display stuff should not use MTRR, but rather use PAT to provide WC. Then we don't need to "clean up" the BIOS-set MTRRs. -hpa -- 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 v3 1/3] tracing,x86: add a TSC trace_clock
On Thu, 2012-09-20 at 15:52 -0700, David Sharp wrote: > diff --git a/include/asm-generic/trace_clock.h > b/include/asm-generic/trace_clock.h > new file mode 100644 > index 000..6726f1b > --- /dev/null > +++ b/include/asm-generic/trace_clock.h > @@ -0,0 +1,16 @@ > +#ifndef _ASM_GENERIC_TRACE_CLOCK_H > +#define _ASM_GENERIC_TRACE_CLOCK_H > +/* > + * Arch-specific trace clocks. > + */ > + > +/* > + * Additional trace clocks added to the trace_clocks > + * array in kernel/trace/trace.c > + * None if the architecture has not defined it. > + */ > +#ifndef ARCH_TRACE_CLOCKS > +# define ARCH_TRACE_CLOCKS > +#endif > + > +#endif /* _ASM_GENERIC_TRACE_CLOCK_H */ Unfortunately this isn't enough. You need to add a stub in all arch/*/include/asm/ directories. That has: --- trace_clock.h: #ifndef _ASM_TRACE_CLOCK_H #define _ASM_TRACE_CLOCK_H #include #endif --- Because running this against my cross-compile test, failed on all archs but x86. -- Steve -- 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 8/10] bug.h: Make BUILD_BUG_ON generate compile-time error
On Fri, Sep 28, 2012 at 08:26:08PM -0500, Daniel Santos wrote:
> On 09/28/2012 07:32 PM, Josh Triplett wrote:
> > On Fri, Sep 28, 2012 at 06:20:09PM -0500, Daniel Santos wrote:
> >> Negative sized arrays wont create a compile-time error in some cases
> >> starting with gcc 4.4 (e.g., inlined functions), but gcc 4.3 introduced
> >> the error function attribute that will. This patch modifies
> >> BUILD_BUG_ON to behave like BUILD_BUG already does, using the error
> >> function attribute so that you don't have to build the entire kernel to
> >> discover that you have a problem, and then enjoy trying to track it down
> >> from a link-time error.
> >
> > Rather than doing both, and potentially producing two errors for the
> > same issue, how about using __compiletime_error only, and only using the
> > negative-sized array when __compiletime_error has no useful definition?
> >
> > For instance, in compiler.h, when defining __compiletime_error as an
> > empty macro in the fallback case, you could define a
> > __compiletime_error_fallback() macro that declares a negative-sized
> > array; you could then define __compiletime_error_fallback() as an empty
> > macro when it doesn't exist.
> It may also make sense to define
> #define BUILD_BUG() BUILD_BUG_ON(1)
>
> I haven't examined this really closely yet and my eyes are getting a
> little bleary :)
>
>
> Really, I would have liked to be able to set the error message as
> well, but we would have to have the macro generate a unique function
> name for each time its expanded to make that work. Example:
>
> #define BUILD_BUG_ON(cond) BUILD_BUG_ON_MSG(cond, #cond)
> #define BUILD_BUG_ON_MSG(cond, msg)\
> do { \
> extern void __build_bug_on_failed ## something_unique(void)\
> __compiletime_error("BUILD_BUG_ON failed: " msg); \
> __compiletime_error_fallback(cond);\
> if (cond) \
> __build_bug_on_failed(); \
> } while(0)
>
> I just don't know any tricks to generate unique pre-processor
> value automatically.
Assuming you don't call BUILD_BUG_ON_MSG more than once per line:
/tmp$ cat test.c
#define BUILD_BUG_ON_MSG_INTERNAL2(cond, msg, line) \
do { \
extern void __build_bug_on_failed_ ## line (void)
__attribute__((error(msg))); \
if (cond) \
__build_bug_on_failed_ ## line(); \
} while (0)
#define BUILD_BUG_ON_MSG_INTERNAL(cond, msg, line)
BUILD_BUG_ON_MSG_INTERNAL2(cond, msg, line)
#define BUILD_BUG_ON_MSG(cond, msg) BUILD_BUG_ON_MSG_INTERNAL(cond, msg,
__LINE__)
void f(void)
{
BUILD_BUG_ON_MSG(0, "test 1");
BUILD_BUG_ON_MSG(1, "test 2");
BUILD_BUG_ON_MSG(0, "test 3");
BUILD_BUG_ON_MSG(1, "test 4");
}
/tmp$ gcc -c test.c
test.c: In function ‘f’:
test.c:14:119: error: call to ‘__build_bug_on_failed_14’ declared with
attribute error: test 2
test.c:16:119: error: call to ‘__build_bug_on_failed_16’ declared with
attribute error: test 4
- Josh Triplett
--
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] mm: frontswap: fix a wrong if condition in frontswap_shrink
On 2012-09-28 22:54, Paul Bolle wrote: On Fri, 2012-09-28 at 11:43 +0800, Zhenzhong Duan wrote: On 2012-09-27 19:35, Paul Bolle wrote: I think setting pages_to_unuse to zero here is not needed. It is initiated to zero in frontswap_shrink() and hasn't been touched since. See my patch at https://lkml.org/lkml/2012/9/27/250. Yes, it's unneeded. But I didn't see warning as you said in above link when run 'make V=1 mm/frontswap.o'. Not even before applying your patch? Anyhow, after applying your patch the warnings gone here too. I tested both cases, no warning, also didn't see -Wmaybe-uninitialized when make. My env is el5. gcc version 4.1.2 20080704 (Red Hat 4.1.2-52) Maybe your gcc built in/implicit spec use that option? thanks zduan -- 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] x86: mtrr: Constrain WB MTRR to max phys mem prior to cleanup
On 2012-09-29 01:37, Peter Hurley wrote: On Sun, 2012-09-09 at 23:54 -0400, zhenzhong.duan wrote: On 2012-09-08 02:40, H. Peter Anvin wrote: On 09/07/2012 10:44 AM, Peter Hurley wrote: diff --git a/arch/x86/kernel/cpu/mtrr/cleanup.c b/arch/x86/kernel/cpu/mtrr/cleanup.c I really don't like it as it introduces yet another user of max_pfn, which should be going away. Furthermore, the better question is what remaining needs there are for MTRR cleanup; historically the reason was that it prevented the display from being mapped WC via MTRR due to the MTRR conflict resolution rules favoring UC. For a large memory system, mtrr_cleanup offten fail in most case. Even if it succeed, it often occupy all of MTRR entrys. How was display mapped as WC in above case? Without this patch, mtrr_cleanup could not optimize. The original MTRR setup from BIOS remained, which left the display as UC (and a lot of log spew). Hi, I am confused here. Does HPA means mtrr_cleanup's purpose is to occupy all mtrr entrys and prevent display setting a WC entry in it? As page level will do that in current code? If it is, then mtrr_cleanup could be removed now. Why did bios give a lot of space then real mem, for hotplug? I assume the reason was for hotplug. An interesting side note: more recent revisions of this BIOS (rev. A11) report one less variable MTRR (so, IA32_MTRRCAP is writable?) From manual, it's readonly, writing it will lead to #GP. However, the right way to fix that is to use the PAT interfaces, which doesn't have this drawback -- then MTRR cleanup becomes entirely superfluous and the problem goes away. Do you mean disable MTRR totally here? Well, since PAT entries marked WC override all MTRR settings, whatever the BIOS set the variable MTRRs to becomes irrelevant, so not disabled but rather ignored. Oh, I see, WC in page level take precedence. Is the fix already in upstream? thanks zduan -- 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 0/7] rcu: optimize RCU trace on the huge platform
On 09/29/2012 01:53 AM, Paul E. McKenney wrote: > On Thu, Sep 20, 2012 at 08:51:01AM +0800, Michael Wang wrote: >> This patch set optimize the RCU trace to make it perform better on the >> platform with thousands of cpus. >> >> The optimization including: >> -- the cpu info will be separated by each flavor of rcu. >> -- implement the 'cpu units sequence reading' to avoid losing data. >> >> Michael Wang (7): >> [PATCH 1/7] rcu: create directory for each flavor of rcu >> [PATCH 2/7] rcu: fundamental facility for 'cpu units sequence reading' >> [PATCH 3/7] rcu: optimize the 'rcudata' for RCU trace >> [PATCH 4/7] rcu: optimize the 'rcudata.csv' for RCU trace >> [PATCH 5/7] rcu: optimize the 'rcu_pending' for RCU trace >> [PATCH 6/7] rcu: replace the old interface with the new one >> [PATCH 7/7] rcu: remove the interface "rcudata.csv" >> >> Signed-off-by: Michael Wang >> --- >> b/kernel/rcutree_trace.c |8 + >> kernel/rcutree_trace.c | 368 >> --- >> 2 files changed, 170 insertions(+), 206 deletions(-) > > Queued for 3.8, thank you Michael! Thanks for your review. Regards, Michael Wang > > 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/
Re: [PATCH 0/4] bugfix for memory hotplug
On 09/27/2012 01:45 PM, we...@cn.fujitsu.com wrote: From: Wen Congyang Wen Congyang (2): memory-hotplug: clear hwpoisoned flag when onlining pages memory-hotplug: auto offline page_cgroup when onlining memory block failed Again, you should explain these two patches are the new version of memory-hotplug: hot-remove physical memory [20/21,21/21] Yasuaki Ishimatsu (2): memory-hotplug: add memory_block_release memory-hotplug: add node_device_release drivers/base/memory.c |9 - drivers/base/node.c | 11 +++ mm/memory_hotplug.c |8 mm/page_cgroup.c |3 +++ 4 files changed, 30 insertions(+), 1 deletions(-) -- 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 -- 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] lib tools traceevent: Add back pevent assignment in __pevent_parse_format()
Even though with the change of commit commit 2b29175 "tools lib traceevent:
Carve out events format parsing routine", allowed __pevent_parse_format() to
parse an event without the need of a pevent handler, the event still needs to
assign the pevent handed to it.
There's no problem with assigning it if the pevent is NULL, as the event->pevent
would be NULL without the assignment. But function parsing handlers may be
assigned to the pevent handler to help in parsing the event. If there's no
pevent then there would not be any function handlers, but if the pevent
isn't assigned first before parsing the event, it wont honor the function
handlers that were assigned.
Worse yet, the current code crashes if an event has a function that it tries
to parse. For example:
# perf record -e scsi:scsi_dispatch_cmd_timeout
Segmentation fault (core dumped)
This happens because the scsi_dispatch_cmd_timeout event format has the
following:
__print_hex(__get_dynamic_array(cmnd), REC->cmd_len)
which hasn't been defined by the pevent code.
Signed-off-by: Steven Rostedt
diff --git a/tools/lib/traceevent/event-parse.c
b/tools/lib/traceevent/event-parse.c
index 47264b4..f2989c5 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -2602,6 +2602,9 @@ find_func_handler(struct pevent *pevent, char *func_name)
{
struct pevent_function_handler *func;
+ if (!pevent)
+ return NULL;
+
for (func = pevent->func_handlers; func; func = func->next) {
if (strcmp(func->name, func_name) == 0)
break;
@@ -4938,6 +4941,9 @@ enum pevent_errno __pevent_parse_format(struct
event_format **eventp,
goto event_alloc_failed;
}
+ /* Add pevent to event so that it can be referenced */
+ event->pevent = pevent;
+
ret = event_read_format(event);
if (ret < 0) {
ret = PEVENT_ERRNO__READ_FORMAT_FAILED;
@@ -5041,9 +5047,6 @@ enum pevent_errno pevent_parse_event(struct pevent
*pevent, const char *buf,
if (event == NULL)
return ret;
- /* Add pevent to event so that it can be referenced */
- event->pevent = pevent;
-
if (add_event(pevent, event)) {
ret = PEVENT_ERRNO__MEM_ALLOC_FAILED;
goto event_add_failed;
--
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 v9 PATCH 13/21] memory-hotplug: check page type in get_page_bootmem
On 09/05/2012 05:25 PM, we...@cn.fujitsu.com wrote:
From: Yasuaki Ishimatsu
The function get_page_bootmem() may be called more than one time to the same
page. There is no need to set page's type, private if the function is not
the first time called to the page.
Note: the patch is just optimization and does not fix any problem.
Hi Yasuaki,
this patch is reasonable to me. I have another question associated to
get_page_bootmem(), the question is from another fujitsu guy's patch
changelog [commit : 04753278769f3], the changelog said that:
1) When the memmap of removing section is allocated on other
section by bootmem, it should/can be free.
2) When the memmap of removing section is allocated on the
same section, it shouldn't be freed. Because the section has to be
logical memory offlined already and all pages must be isolated against
page allocater. If it is freed, page allocator may use it which will
be removed physically soon.
but I don't see his patch guarantee 2), it means that his patch doesn't
guarantee the memmap of removing section which is allocated on other
section by bootmem doesn't be freed. Hopefully get your explaination in
details, thanks in advance. :-)
CC: David Rientjes
CC: Jiang Liu
CC: Len Brown
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
CC: Christoph Lameter
Cc: Minchan Kim
CC: Andrew Morton
CC: KOSAKI Motohiro
CC: Wen Congyang
Signed-off-by: Yasuaki Ishimatsu
---
mm/memory_hotplug.c | 15 +++
1 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index d736df3..26a5012 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -95,10 +95,17 @@ static void release_memory_resource(struct resource *res)
static void get_page_bootmem(unsigned long info, struct page *page,
unsigned long type)
{
- page->lru.next = (struct list_head *) type;
- SetPagePrivate(page);
- set_page_private(page, info);
- atomic_inc(>_count);
+ unsigned long page_type;
+
+ page_type = (unsigned long)page->lru.next;
+ if (page_type < MEMORY_HOTPLUG_MIN_BOOTMEM_TYPE ||
+ page_type > MEMORY_HOTPLUG_MAX_BOOTMEM_TYPE){
+ page->lru.next = (struct list_head *)type;
+ SetPagePrivate(page);
+ set_page_private(page, info);
+ atomic_inc(>_count);
+ } else
+ atomic_inc(>_count);
}
/* reference to __meminit __free_pages_bootmem is valid
--
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/
Subject: pull request: linux-firmware: update cxgb4 firmware
Hi, Can you please pull from the following URL? git://git.chelsio.net/pub/git/linux-firmware.git for-upstream The following changes since commit 236367db10f1e618a3ced2538f5cd1802c31ebd8: Yuval Mintz (1): bnx2x: update fw to 7.8.2 are available in the git repository at: git://git.chelsio.net/pub/git/linux-firmware.git for-upstream Divy Le Ray (1): cxgb4: update firmware to revision 1.6.2.0 WHENCE |2 +- cxgb4/t4fw-1.4.23.0.bin | Bin 326144 -> 0 bytes cxgb4/t4fw-1.6.2.0.bin | Bin 0 -> 431616 bytes cxgb4/t4fw.bin |2 +- 4 files changed, 2 insertions(+), 2 deletions(-) delete mode 100644 cxgb4/t4fw-1.4.23.0.bin create mode 100644 cxgb4/t4fw-1.6.2.0.bin Cheers, Divy -- 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: Probable false positive in checkpatch
On Fri, 28 Sep 2012, Joe Perches wrote: > On Fri, 2012-09-28 at 15:50 -0400, Alan Stern wrote: > > Here's what I just got from checkpatch: > > > > ERROR: space prohibited after that '-' (ctx:BxW) > > #22: FILE: drivers/usb/host/ehci-sched.c:1419: > > + start += (next - start + period - 1) & (- period); > > ^ > > This seems unlikely to be a real style violation. Or if it is, maybe > > it shouldn't be. After all, "(0 - period)" would be okay. > > 2c: I think the recommendation is proper and correct. I just looked in CodingStyle, and sure enough, there it is in section 3.1. The complaint is hereby withdrawn. Alan Stern -- 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 8/10] bug.h: Make BUILD_BUG_ON generate compile-time error
On 09/28/2012 07:32 PM, Josh Triplett wrote:
> On Fri, Sep 28, 2012 at 06:20:09PM -0500, Daniel Santos wrote:
>> Negative sized arrays wont create a compile-time error in some cases
>> starting with gcc 4.4 (e.g., inlined functions), but gcc 4.3 introduced
>> the error function attribute that will. This patch modifies
>> BUILD_BUG_ON to behave like BUILD_BUG already does, using the error
>> function attribute so that you don't have to build the entire kernel to
>> discover that you have a problem, and then enjoy trying to track it down
>> from a link-time error.
>
> Rather than doing both, and potentially producing two errors for the
> same issue, how about using __compiletime_error only, and only using the
> negative-sized array when __compiletime_error has no useful definition?
>
> For instance, in compiler.h, when defining __compiletime_error as an
> empty macro in the fallback case, you could define a
> __compiletime_error_fallback() macro that declares a negative-sized
> array; you could then define __compiletime_error_fallback() as an empty
> macro when it doesn't exist.
It may also make sense to define
#define BUILD_BUG() BUILD_BUG_ON(1)
I haven't examined this really closely yet and my eyes are getting a
little bleary :)
Really, I would have liked to be able to set the error message as
well, but we would have to have the macro generate a unique function
name for each time its expanded to make that work. Example:
#define BUILD_BUG_ON(cond) BUILD_BUG_ON_MSG(cond, #cond)
#define BUILD_BUG_ON_MSG(cond, msg)\
do { \
extern void __build_bug_on_failed ## something_unique(void)\
__compiletime_error("BUILD_BUG_ON failed: " msg); \
__compiletime_error_fallback(cond);\
if (cond) \
__build_bug_on_failed(); \
} while(0)
I just don't know any tricks to generate unique pre-processor
value automatically.
Daniel
--
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 v6 0/3] Add modules to support realtek PCIE card reader
On 09/11/2012 12:54 AM, wei_w...@realsil.com.cn wrote: > From: Wei WANG > > Support for Realtek PCI-Express driver-based card readers including rts5209 > and rts5229. > > v2: > 1. Using platform device to replace realtek slot bus > > v3: > 1. Fix a bug that DMA out of SW-IOMMU space in Lenovo Thinkpad x121e > 2. Tested by Borislav Petkov > > v4: > 1. Fulfill power management callbacks > > v5: > 1. Support Memstick card > > v6: > 1. Fix some coding style > > Wei WANG (3): > drivers/mfd: Add realtek pcie card reader driver > drivers/mmc: Add realtek pcie sdmmc host driver > drivers/memstick: Add realtek pcie memstick host driver I have a recent HP Pavilion dv6 with this card reader, 10ec:5209 (rev 01). I just applied these patches on top of 3.6-rc7. Appears to work properly with a SanDisk 8GB SDHC card. I don't have a memstick to test. For patches 1 & 2, feel free to add my: Tested-by: Philip J. Turmel Regards, Phil -- 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/10] bug.h: Replace __linktime_error with __compiletime_error
On Fri, 2012-09-28 at 17:23 -0700, Josh Triplett wrote:
> On Fri, Sep 28, 2012 at 06:20:07PM -0500, Daniel Santos wrote:
> > Signed-off-by: Daniel Santos
> > ---
> > include/linux/bug.h |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/include/linux/bug.h b/include/linux/bug.h
> > index aaac4bb..298a916 100644
> > --- a/include/linux/bug.h
> > +++ b/include/linux/bug.h
> > @@ -73,7 +73,7 @@ extern int __build_bug_on_failed;
> > #define BUILD_BUG()\
> > do {\
> > extern void __build_bug_failed(void)\
> > - __linktime_error("BUILD_BUG failed"); \
> > + __compiletime_error("BUILD_BUG failed");\
> > __build_bug_failed(); \
> > } while (0)
>
> This change should either occur as part of patch 5 or before patch 5,
> not after.
I noticed the same thing and was about to comment on it.
Please do not break bisectablity. All your patches should compile and
run at every step.
-- Steve
--
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: fix neigh_resolve_output can cause skb_under_panic
On Fri, Sep 28, 2012 at 08:26:51PM -0400, Ramesh Nagappa wrote: > > > > Why is all of this in the middle of the changelog section? > > > > I'm guessing you didn't use 'git send-email' for this? > > > > And why are you copying me on the patch? > > I got the CC list from scripts/get_maintainers.pl > > asglx-2-300 $ scripts/get_maintainer.pl > 0001-net-fix-neigh_resolve_output-can-cause-skb_under_pan.patch > "David S. Miller" (maintainer:NETWORKING > [GENERAL],commit_signer:3/4=75%) > Greg Kroah-Hartman (commit_signer:3/4=75%) > Eric Dumazet (commit_signer:2/4=50%) > Shawn Lu (commit_signer:1/4=25%) > Michel Machado (commit_signer:1/4=25%) > net...@vger.kernel.org (open list:NETWORKING [GENERAL]) > linux-kernel@vger.kernel.org (open list) I can't reproduce this: $ ./scripts/get_maintainer.pl --file net/core/neighbour.c "David S. Miller" (maintainer:NETWORKING [GENERAL],commit_signer:22/22=100%) Eric Dumazet (commit_signer:4/22=18%) "Eric W. Biederman" (commit_signer:2/22=9%) Pavel Emelyanov (commit_signer:2/22=9%) net...@vger.kernel.org (open list:NETWORKING [GENERAL]) linux-kernel@vger.kernel.org (open list) What tree are you doing that against? > > You need a blank line before the first Signed-off-by: line. > > Surely one of the reviewers should have caught this basic thing? > > Outlook mangled the patch. I am unable to use git send-email because of > a corporate firewall on the build machine. Then your patch would also be corrupted, Outlook, and Exchange, can not handle patches at all. Please read Documentation/email_clients.txt for more details. Also, ask your coworkers who properly submit patches what they do to work around your broken email infrastructure. good luck, 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/
[PATCHv4 3/3] efi: Fix the ACPI BGRT driver for images located in EFI boot services memory
The ACPI BGRT driver accesses the BIOS logo image when it initializes.
However, ACPI 5.0 (which introduces the BGRT) recommends putting the
logo image in EFI boot services memory, so that the OS can reclaim that
memory. Production systems follow this recommendation, breaking the
ACPI BGRT driver.
Move the bulk of the BGRT code to run during a new EFI late
initialization phase, which occurs after switching EFI to virtual mode,
and after initializing ACPI, but before freeing boot services memory.
Copy the BIOS logo image to kernel memory at that point, and make it
accessible to the BGRT driver. Rework the existing ACPI BGRT driver to
act as a simple wrapper exposing that image (and the properties from the
BGRT) via sysfs.
Signed-off-by: Josh Triplett
---
arch/x86/platform/efi/Makefile |1 +
arch/x86/platform/efi/efi-bgrt.c | 76 ++
arch/x86/platform/efi/efi.c |6 +++
drivers/acpi/Kconfig |4 +-
drivers/acpi/bgrt.c | 76 +-
include/linux/efi-bgrt.h | 21 +++
include/linux/efi.h |2 +
init/main.c |4 +-
8 files changed, 120 insertions(+), 70 deletions(-)
create mode 100644 arch/x86/platform/efi/efi-bgrt.c
create mode 100644 include/linux/efi-bgrt.h
diff --git a/arch/x86/platform/efi/Makefile b/arch/x86/platform/efi/Makefile
index 73b8be0..6db1cc4 100644
--- a/arch/x86/platform/efi/Makefile
+++ b/arch/x86/platform/efi/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_EFI) += efi.o efi_$(BITS).o efi_stub_$(BITS).o
+obj-$(CONFIG_ACPI_BGRT) += efi-bgrt.o
diff --git a/arch/x86/platform/efi/efi-bgrt.c b/arch/x86/platform/efi/efi-bgrt.c
new file mode 100644
index 000..f6a0c1b
--- /dev/null
+++ b/arch/x86/platform/efi/efi-bgrt.c
@@ -0,0 +1,76 @@
+/*
+ * Copyright 2012 Intel Corporation
+ * Author: Josh Triplett
+ *
+ * Based on the bgrt driver:
+ * Copyright 2012 Red Hat, Inc
+ * Author: Matthew Garrett
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include
+#include
+#include
+#include
+
+struct acpi_table_bgrt *bgrt_tab;
+void *bgrt_image;
+size_t bgrt_image_size;
+
+struct bmp_header {
+ u16 id;
+ u32 size;
+} __packed;
+
+void efi_bgrt_init(void)
+{
+ acpi_status status;
+ void __iomem *image;
+ bool ioremapped = false;
+ struct bmp_header bmp_header;
+
+ if (acpi_disabled)
+ return;
+
+ status = acpi_get_table("BGRT", 0,
+ (struct acpi_table_header **)_tab);
+ if (ACPI_FAILURE(status))
+ return;
+
+ if (bgrt_tab->version != 1)
+ return;
+ if (bgrt_tab->image_type != 0 || !bgrt_tab->image_address)
+ return;
+
+ image = efi_lookup_mapped_addr(bgrt_tab->image_address);
+ if (!image) {
+ image = ioremap(bgrt_tab->image_address, sizeof(bmp_header));
+ ioremapped = true;
+ if (!image)
+ return;
+ }
+
+ memcpy_fromio(_header, image, sizeof(bmp_header));
+ if (ioremapped)
+ iounmap(image);
+ bgrt_image_size = bmp_header.size;
+
+ bgrt_image = kmalloc(bgrt_image_size, GFP_KERNEL);
+ if (!bgrt_image)
+ return;
+
+ if (ioremapped) {
+ image = ioremap(bgrt_tab->image_address, bmp_header.size);
+ if (!image) {
+ kfree(bgrt_image);
+ bgrt_image = NULL;
+ return;
+ }
+ }
+
+ memcpy_fromio(bgrt_image, image, bgrt_image_size);
+ if (ioremapped)
+ iounmap(image);
+}
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index f7f928c..aded2a9 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -745,6 +746,11 @@ void __init efi_init(void)
#endif
}
+void __init efi_late_init(void)
+{
+ efi_bgrt_init();
+}
+
void __init efi_set_executable(efi_memory_desc_t *md, bool executable)
{
u64 addr, npages;
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 8099895..119d58d 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -385,8 +385,8 @@ config ACPI_CUSTOM_METHOD
to override that restriction).
config ACPI_BGRT
-tristate "Boottime Graphics Resource Table support"
-default n
+ bool "Boottime Graphics Resource Table support"
+ depends on EFI
help
This driver adds support for exposing the ACPI Boottime Graphics
Resource Table, which allows the operating system to obtain
diff --git a/drivers/acpi/bgrt.c
[PATCHv4 2/3] efi: Add a function to look up existing IO memory mappings
The EFI initialization creates virtual mappings for EFI boot services
memory, so if a driver wants to access EFI boot services memory, it
cannot call ioremap itself; doing so will trip the WARN about mapping
RAM twice. Thus, a driver accessing EFI boot services memory must do so
via the existing mapping already created during EFI intiialization.
Since the EFI code already maintains a memory map for that memory, add a
function efi_lookup_mapped_addr to look up mappings in that memory map.
Signed-off-by: Josh Triplett
---
arch/x86/platform/efi/efi.c | 28
include/linux/efi.h |1 +
2 files changed, 29 insertions(+)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index b3dbbdb..f7f928c 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -777,6 +777,34 @@ static void __init runtime_code_page_mkexec(void)
}
/*
+ * We can't ioremap data in EFI boot services RAM, because we've already mapped
+ * it as RAM. So, look it up in the existing EFI memory map instead. Only
+ * callable after efi_enter_virtual_mode and before efi_free_boot_services.
+ */
+void __iomem *efi_lookup_mapped_addr(u64 phys_addr)
+{
+ void *p;
+ if (WARN_ON(!memmap.map))
+ return NULL;
+ for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
+ efi_memory_desc_t *md = p;
+ u64 size = md->num_pages << EFI_PAGE_SHIFT;
+ u64 end = md->phys_addr + size;
+ if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
+ md->type != EFI_BOOT_SERVICES_CODE &&
+ md->type != EFI_BOOT_SERVICES_DATA)
+ continue;
+ if (!md->virt_addr)
+ continue;
+ if (phys_addr >= md->phys_addr && phys_addr < end) {
+ phys_addr += md->virt_addr - md->phys_addr;
+ return (__force void __iomem *)(unsigned long)phys_addr;
+ }
+ }
+ return NULL;
+}
+
+/*
* This function will switch the EFI runtime services to virtual mode.
* Essentially, look through the EFI memmap and map every region that
* has the runtime attribute bit set in its memory descriptor and update
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 5782114..fff135d 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -501,6 +501,7 @@ extern void efi_free_boot_services(void);
#else
static inline void efi_free_boot_services(void) {}
#endif
+extern void __iomem *efi_lookup_mapped_addr(u64 phys_addr);
extern u64 efi_get_iobase (void);
extern u32 efi_mem_type (unsigned long phys_addr);
extern u64 efi_mem_attributes (unsigned long phys_addr);
--
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/
[PATCHv4 0/3] Fix ACPI BGRT support for images located in EFI boot services memory
The ACPI BGRT lets the OS access the BIOS logo image and its position on the screen at boot time, allowing it to maintain that image on the screen until ready to display something else, making boot more seamless. This series fixes support for accessing the boot logo image via the BGRT when the BIOS stores it in EFI boot services memory, as recommended by the ACPI 5.0 spec. Linux needs to copy the image out of boot services memory before reclaiming boot services memory. The first patch refactors EFI initialization to defer freeing boot services memory until much later in the boot process, and in particular until after we have ACPI available. The second patch adds a helper function to look up existing EFI boot services mappings, to avoid re-mapping them. The third patch moves BGRT initialization to before the reclamation of boot services memory, copies the logo at that point, and reworks the existing BGRT driver to use that existing copy. v2: Made the new internal function efi_unmap_memmap static. Incorporated feedback from H. Peter Anvin and Matt Fleming: added stubs for x86-specific EFI functions called from init/main.c to eliminate the corresponding ifdefs in start_kernel; deferred efi_free_boot_services even later, to just before free_initmem. v3: Moved efi_free_boot_services back to right after EFI initialization, to avoid a WARN from check_early_ioremap_leak about not calling early_iounmap soon enough. v4: Cast the integral phys_addr through unsigned long before casting it to a pointer, to avoid a warning "cast to pointer from integer of different size" on 32-bit x86. Don't define efi_enter_virtual_mode as a stub on non-x86, because a different function exists on ia64 with that name, and ia64 calls that function in a different point in its initialiation; instead, go back to calling efi_enter_virtual_mode in init/main.c under an #ifdef CONFIG_X86. Define the stubs for efi_late_init and efi_free_boot_services using "static inline" to avoid unused function warnings. v4 should replace the version currently in tip x86/efi. Josh Triplett (3): efi: Defer freeing boot services memory until after ACPI init efi: Add a function to look up existing IO memory mappings efi: Fix the ACPI BGRT driver for images located in EFI boot services memory arch/x86/platform/efi/Makefile |1 + arch/x86/platform/efi/efi-bgrt.c | 76 ++ arch/x86/platform/efi/efi.c | 65 +--- drivers/acpi/Kconfig |4 +- drivers/acpi/bgrt.c | 76 +- include/linux/efi-bgrt.h | 21 +++ include/linux/efi.h |8 init/main.c |5 +++ 8 files changed, 174 insertions(+), 82 deletions(-) create mode 100644 arch/x86/platform/efi/efi-bgrt.c create mode 100644 include/linux/efi-bgrt.h -- 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/
[PATCHv4 1/3] efi: Defer freeing boot services memory until after ACPI init
Some new ACPI 5.0 tables reference resources stored in boot services
memory, so keep that memory around until we have ACPI and can extract
data from it.
Signed-off-by: Josh Triplett
---
arch/x86/platform/efi/efi.c | 31 ++-
include/linux/efi.h |5 +
init/main.c |3 +++
3 files changed, 26 insertions(+), 13 deletions(-)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index f55a4ce..b3dbbdb 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -419,10 +419,21 @@ void __init efi_reserve_boot_services(void)
}
}
-static void __init efi_free_boot_services(void)
+static void __init efi_unmap_memmap(void)
+{
+ if (memmap.map) {
+ early_iounmap(memmap.map, memmap.nr_map * memmap.desc_size);
+ memmap.map = NULL;
+ }
+}
+
+void __init efi_free_boot_services(void)
{
void *p;
+ if (!efi_native)
+ return;
+
for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
efi_memory_desc_t *md = p;
unsigned long long start = md->phys_addr;
@@ -438,6 +449,8 @@ static void __init efi_free_boot_services(void)
free_bootmem_late(start, size);
}
+
+ efi_unmap_memmap();
}
static int __init efi_systab_init(void *phys)
@@ -787,8 +800,10 @@ void __init efi_enter_virtual_mode(void)
* non-native EFI
*/
- if (!efi_native)
- goto out;
+ if (!efi_native) {
+ efi_unmap_memmap();
+ return;
+ }
/* Merge contiguous regions of the same type and attribute */
for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
@@ -878,13 +893,6 @@ void __init efi_enter_virtual_mode(void)
}
/*
-* Thankfully, it does seem that no runtime services other than
-* SetVirtualAddressMap() will touch boot services code, so we can
-* get rid of it all at this point
-*/
- efi_free_boot_services();
-
- /*
* Now that EFI is in virtual mode, update the function
* pointers in the runtime service table to the new virtual addresses.
*
@@ -907,9 +915,6 @@ void __init efi_enter_virtual_mode(void)
if (__supported_pte_mask & _PAGE_NX)
runtime_code_page_mkexec();
-out:
- early_iounmap(memmap.map, memmap.nr_map * memmap.desc_size);
- memmap.map = NULL;
kfree(new_memmap);
}
diff --git a/include/linux/efi.h b/include/linux/efi.h
index ec45ccd..5782114 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -496,6 +496,11 @@ extern void efi_map_pal_code (void);
extern void efi_memmap_walk (efi_freemem_callback_t callback, void *arg);
extern void efi_gettimeofday (struct timespec *ts);
extern void efi_enter_virtual_mode (void); /* switch EFI to virtual mode,
if possible */
+#ifdef CONFIG_X86
+extern void efi_free_boot_services(void);
+#else
+static inline void efi_free_boot_services(void) {}
+#endif
extern u64 efi_get_iobase (void);
extern u32 efi_mem_type (unsigned long phys_addr);
extern u64 efi_mem_attributes (unsigned long phys_addr);
diff --git a/init/main.c b/init/main.c
index b286730..d61ec54 100644
--- a/init/main.c
+++ b/init/main.c
@@ -631,6 +631,9 @@ asmlinkage void __init start_kernel(void)
acpi_early_init(); /* before LAPIC and SMP init */
sfi_init_late();
+ if (efi_enabled)
+ efi_free_boot_services();
+
ftrace_init();
/* Do the rest non-__init'ed, we're now alive */
--
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 8/10] bug.h: Make BUILD_BUG_ON generate compile-time error
On 09/28/2012 07:32 PM, Josh Triplett wrote: > On Fri, Sep 28, 2012 at 06:20:09PM -0500, Daniel Santos wrote: >> Negative sized arrays wont create a compile-time error in some cases >> starting with gcc 4.4 (e.g., inlined functions), but gcc 4.3 introduced >> the error function attribute that will. This patch modifies >> BUILD_BUG_ON to behave like BUILD_BUG already does, using the error >> function attribute so that you don't have to build the entire kernel to >> discover that you have a problem, and then enjoy trying to track it down >> from a link-time error. > Rather than doing both, and potentially producing two errors for the > same issue, how about using __compiletime_error only, and only using the > negative-sized array when __compiletime_error has no useful definition? > > For instance, in compiler.h, when defining __compiletime_error as an > empty macro in the fallback case, you could define a > __compiletime_error_fallback() macro that declares a negative-sized > array; you could then define __compiletime_error_fallback() as an empty > macro when it doesn't exist. Oh, that's a great idea. That will keep more of the compiler's details in compiler*.h. Daniel -- 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 7/10] compiler{,-gcc4}.h: Introduce __flatten function attribute
On Fri, Sep 28, 2012 at 07:38:32PM -0500, Daniel Santos wrote: > On 09/28/2012 07:26 PM, Josh Triplett wrote: > > On Fri, Sep 28, 2012 at 06:20:08PM -0500, Daniel Santos wrote: > >> --- a/include/linux/compiler-gcc4.h > >> +++ b/include/linux/compiler-gcc4.h > >> @@ -15,7 +15,12 @@ > >> > >> #if GCC_VERSION >= 40102 > >> # define __compiletime_object_size(obj) __builtin_object_size(obj, 0) > >> -#endif > >> + > >> +/* flatten introduced in 4.1, but broken in 4.6.0 (gcc bug #48731)*/ > >> +# if GCC_VERSION != 40600 > >> +# define __flatten __attribute__((flatten)) > >> +# endif > >> +#endif /* GCC_VERSION >= 40102 */ > > Same comment as before: why 40102 rather than 40100? > Again, I'm presuming building with 4.1.0 or 4.1.1 will always have the > build broken earlier. I don't have any objections to changing this, but > it would seem that the issue with the __weak attribute needs to be resolved. That issue doesn't relate to __flatten, though; it only relates to __weak. Since __flatten (and __compiletime_object_size) will work fine on 4.1.0 and 4.1.1, don't exclude them just because the definition for __weak elsewhere in the file excludes them. That just makes it harder for anyone who might want to work on the issue with __weak. - Josh Triplett -- 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: [Bulk] Re: [PATCH 5/10] compiler{,-gcc4}.h: Remove duplicate macros
On Fri, Sep 28, 2012 at 07:34:36PM -0500, Daniel Santos wrote: > On 09/28/2012 07:23 PM, Josh Triplett wrote: > > On Fri, Sep 28, 2012 at 06:20:06PM -0500, Daniel Santos wrote: > >> __linktime_error() does the same thing as __compiletime_error() and is > >> only used in bug.h. Since the macro defines a function attribute that > >> will cause a failure at compile-time (not link-time), it makes more > >> sense to keep __compiletime_error(), which is also neatly mated with > >> __compiletime_warning(). > >> > >> Signed-off-by: Daniel Santos > > Why not change bug.h in the same commit? Or alternatively, why not > > change it first? > I'm still new to this project's development process and wasn't sure if > those two changes would be considered lumping multiple changes together > or not. So that type of lumping is acceptable then? I certainly > wouldn't mind squashing them. In general, you shouldn't make *unrelated* changes in the same patch, and you should definitely make fine-grained patches whenever appropriate. However, in this case the changes seem quite related. The rule in the Linux kernel: the kernel should compile and function after every individual patch. You shouldn't introduce breakage in a patch series and fix it later in that series. Commonly called making your patch series "bisectable", since it helps "git bisect" work more smoothly to have every single git commit compile and run. In this case, you removed __linktime_error before removing its caller. > > Getting rid of __linktime_error *before* changing its > > use in bug.h to __compiletime_error seems wrong. > Good point! Thinking about it further, in this case I think it makes sense to just reverse the two patches: remove the one and only use of __linktime_error, then remove its definition. - Josh Triplett -- 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 7/10] compiler{,-gcc4}.h: Introduce __flatten function attribute
On 09/28/2012 07:26 PM, Josh Triplett wrote: > On Fri, Sep 28, 2012 at 06:20:08PM -0500, Daniel Santos wrote: >> --- a/include/linux/compiler-gcc4.h >> +++ b/include/linux/compiler-gcc4.h >> @@ -15,7 +15,12 @@ >> >> #if GCC_VERSION >= 40102 >> # define __compiletime_object_size(obj) __builtin_object_size(obj, 0) >> -#endif >> + >> +/* flatten introduced in 4.1, but broken in 4.6.0 (gcc bug #48731)*/ >> +# if GCC_VERSION != 40600 >> +# define __flatten __attribute__((flatten)) >> +# endif >> +#endif /* GCC_VERSION >= 40102 */ > Same comment as before: why 40102 rather than 40100? Again, I'm presuming building with 4.1.0 or 4.1.1 will always have the build broken earlier. I don't have any objections to changing this, but it would seem that the issue with the __weak attribute needs to be resolved. Daniel -- 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: [Bulk] Re: [PATCH 4/10] compiler-gcc{3,4}.h: Use GCC_VERSION macro
On Fri, Sep 28, 2012 at 07:31:53PM -0500, Daniel Santos wrote: > On 09/28/2012 07:20 PM, Josh Triplett wrote: > > On Fri, Sep 28, 2012 at 06:20:05PM -0500, Daniel Santos wrote: > >> --- a/include/linux/compiler-gcc4.h > >> +++ b/include/linux/compiler-gcc4.h > >> @@ -13,11 +13,11 @@ > >> #define __must_check __attribute__((warn_unused_result)) > >> #define __compiler_offsetof(a,b) __builtin_offsetof(a,b) > >> > >> -#if __GNUC_MINOR__ > 0 > >> +#if GCC_VERSION >= 40102 > >> # define __compiletime_object_size(obj) __builtin_object_size(obj, 0) > >> #endif > > You've changed the semantics of this one; if literally translated, this > > should have become #if GCC_VERSION >= 40100. If you intended to change > > that, could you please document why? And in any case, could you make > > that semantic change in a separate commit from the switch to > > GCC_VERSION? > hmm, it looks like somebody commented out the #error that would normally > prevent that test from ever occurring on 4.1.0 or 4.1.1. > When I had written this patch, it wasn't commented out and I had assumed > that it was obvious from the context. GCC 4.1.0 and 4.1.1 miscompiling __weak has nothing to do with __compiletime_object_size; why should *this* version check exclude those versions? - Josh Triplett -- 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: [Bulk] Re: [PATCH 5/10] compiler{,-gcc4}.h: Remove duplicate macros
On 09/28/2012 07:23 PM, Josh Triplett wrote: > On Fri, Sep 28, 2012 at 06:20:06PM -0500, Daniel Santos wrote: >> __linktime_error() does the same thing as __compiletime_error() and is >> only used in bug.h. Since the macro defines a function attribute that >> will cause a failure at compile-time (not link-time), it makes more >> sense to keep __compiletime_error(), which is also neatly mated with >> __compiletime_warning(). >> >> Signed-off-by: Daniel Santos > Why not change bug.h in the same commit? Or alternatively, why not > change it first? I'm still new to this project's development process and wasn't sure if those two changes would be considered lumping multiple changes together or not. So that type of lumping is acceptable then? I certainly wouldn't mind squashing them. > Getting rid of __linktime_error *before* changing its > use in bug.h to __compiletime_error seems wrong. Good 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/
Re: [PATCH 8/10] bug.h: Make BUILD_BUG_ON generate compile-time error
On Fri, Sep 28, 2012 at 06:20:09PM -0500, Daniel Santos wrote: > Negative sized arrays wont create a compile-time error in some cases > starting with gcc 4.4 (e.g., inlined functions), but gcc 4.3 introduced > the error function attribute that will. This patch modifies > BUILD_BUG_ON to behave like BUILD_BUG already does, using the error > function attribute so that you don't have to build the entire kernel to > discover that you have a problem, and then enjoy trying to track it down > from a link-time error. Rather than doing both, and potentially producing two errors for the same issue, how about using __compiletime_error only, and only using the negative-sized array when __compiletime_error has no useful definition? For instance, in compiler.h, when defining __compiletime_error as an empty macro in the fallback case, you could define a __compiletime_error_fallback() macro that declares a negative-sized array; you could then define __compiletime_error_fallback() as an empty macro when it doesn't exist. - Josh Triplett -- 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: [Bulk] Re: [PATCH 4/10] compiler-gcc{3,4}.h: Use GCC_VERSION macro
On 09/28/2012 07:20 PM, Josh Triplett wrote: > On Fri, Sep 28, 2012 at 06:20:05PM -0500, Daniel Santos wrote: >> --- a/include/linux/compiler-gcc4.h >> +++ b/include/linux/compiler-gcc4.h >> @@ -13,11 +13,11 @@ >> #define __must_check__attribute__((warn_unused_result)) >> #define __compiler_offsetof(a,b) __builtin_offsetof(a,b) >> >> -#if __GNUC_MINOR__ > 0 >> +#if GCC_VERSION >= 40102 >> # define __compiletime_object_size(obj) __builtin_object_size(obj, 0) >> #endif > You've changed the semantics of this one; if literally translated, this > should have become #if GCC_VERSION >= 40100. If you intended to change > that, could you please document why? And in any case, could you make > that semantic change in a separate commit from the switch to > GCC_VERSION? hmm, it looks like somebody commented out the #error that would normally prevent that test from ever occurring on 4.1.0 or 4.1.1. When I had written this patch, it wasn't commented out and I had assumed that it was obvious from the context. > /* GCC 4.1.[01] miscompiles __weak */ > #ifdef __KERNEL__ > -# if __GNUC_MINOR__ == 1 && __GNUC_PATCHLEVEL__ <= 1 > +# if GCC_VERSION >= 40100 && GCC_VERSION <= 40101 > //# error Your version of gcc miscompiles the __weak directive > # endif > #endif > @@ -13,11 +13,11 @@ > #define __must_check __attribute__((warn_unused_result)) > #define __compiler_offsetof(a,b) __builtin_offsetof(a,b) > > -#if __GNUC_MINOR__ > 0 > +#if GCC_VERSION >= 40102 > # define __compiletime_object_size(obj) __builtin_object_size(obj, 0) > #endif I would say that commenting this out is bad if __weak is miscompiled. If we don't want to break the build, should we at least be defining __weak to something else? Daniel -- 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: fix neigh_resolve_output can cause skb_under_panic
> > Why is all of this in the middle of the changelog section? > > I'm guessing you didn't use 'git send-email' for this? > > And why are you copying me on the patch? I got the CC list from scripts/get_maintainers.pl asglx-2-300 $ scripts/get_maintainer.pl 0001-net-fix-neigh_resolve_output-can-cause-skb_under_pan.patch "David S. Miller" (maintainer:NETWORKING [GENERAL],commit_signer:3/4=75%) Greg Kroah-Hartman (commit_signer:3/4=75%) Eric Dumazet (commit_signer:2/4=50%) Shawn Lu (commit_signer:1/4=25%) Michel Machado (commit_signer:1/4=25%) net...@vger.kernel.org (open list:NETWORKING [GENERAL]) linux-kernel@vger.kernel.org (open list) > > > You need a blank line before the first Signed-off-by: line. > Surely one of the reviewers should have caught this basic thing? Outlook mangled the patch. I am unable to use git send-email because of a corporate firewall on the build machine. > > greg k-h > Thanks, Ramesh-- 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 7/10] compiler{,-gcc4}.h: Introduce __flatten function attribute
On Fri, Sep 28, 2012 at 06:20:08PM -0500, Daniel Santos wrote: > --- a/include/linux/compiler-gcc4.h > +++ b/include/linux/compiler-gcc4.h > @@ -15,7 +15,12 @@ > > #if GCC_VERSION >= 40102 > # define __compiletime_object_size(obj) __builtin_object_size(obj, 0) > -#endif > + > +/* flatten introduced in 4.1, but broken in 4.6.0 (gcc bug #48731)*/ > +# if GCC_VERSION != 40600 > +# define __flatten __attribute__((flatten)) > +# endif > +#endif /* GCC_VERSION >= 40102 */ Same comment as before: why 40102 rather than 40100? - Josh Triplett -- 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/10] bug.h: Replace __linktime_error with __compiletime_error
On Fri, Sep 28, 2012 at 06:20:07PM -0500, Daniel Santos wrote:
> Signed-off-by: Daniel Santos
> ---
> include/linux/bug.h |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/include/linux/bug.h b/include/linux/bug.h
> index aaac4bb..298a916 100644
> --- a/include/linux/bug.h
> +++ b/include/linux/bug.h
> @@ -73,7 +73,7 @@ extern int __build_bug_on_failed;
> #define BUILD_BUG() \
> do {\
> extern void __build_bug_failed(void)\
> - __linktime_error("BUILD_BUG failed"); \
> + __compiletime_error("BUILD_BUG failed");\
> __build_bug_failed(); \
> } while (0)
This change should either occur as part of patch 5 or before patch 5,
not after.
- Josh Triplett
--
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 5/10] compiler{,-gcc4}.h: Remove duplicate macros
On Fri, Sep 28, 2012 at 06:20:06PM -0500, Daniel Santos wrote: > __linktime_error() does the same thing as __compiletime_error() and is > only used in bug.h. Since the macro defines a function attribute that > will cause a failure at compile-time (not link-time), it makes more > sense to keep __compiletime_error(), which is also neatly mated with > __compiletime_warning(). > > Signed-off-by: Daniel Santos Why not change bug.h in the same commit? Or alternatively, why not change it first? Getting rid of __linktime_error *before* changing its use in bug.h to __compiletime_error seems wrong. - Josh Triplett -- 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 4/10] compiler-gcc{3,4}.h: Use GCC_VERSION macro
On Fri, Sep 28, 2012 at 06:20:05PM -0500, Daniel Santos wrote: > --- a/include/linux/compiler-gcc4.h > +++ b/include/linux/compiler-gcc4.h > @@ -13,11 +13,11 @@ > #define __must_check __attribute__((warn_unused_result)) > #define __compiler_offsetof(a,b) __builtin_offsetof(a,b) > > -#if __GNUC_MINOR__ > 0 > +#if GCC_VERSION >= 40102 > # define __compiletime_object_size(obj) __builtin_object_size(obj, 0) > #endif You've changed the semantics of this one; if literally translated, this should have become #if GCC_VERSION >= 40100. If you intended to change that, could you please document why? And in any case, could you make that semantic change in a separate commit from the switch to GCC_VERSION? - Josh Triplett -- 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: fix neigh_resolve_output can cause skb_under_panic
Sorry, Outlook managled the patch. I will try to find a way to re-submit it. > > You need a blank line before the first Signed-off-by: line. > Surely one of the reviewers should have caught this basic thing? > > greg k-h > -- Ramesh-- 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: [ 064/218] mmc: card: Skip secure erase on MoviNAND; causes unrecoverable corruption.
On Fri, 2012-09-28 at 13:14 -0700, Greg Kroah-Hartman wrote: > 3.4-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Ian Chen > > commit 3550ccdb9d8d350e526b809bf3dd92b550a74fe1 upstream. > > For several MoviNAND eMMC parts, there are known issues with secure > erase and secure trim. For these specific MoviNAND devices, we skip > these operations. > > Specifically, there is a bug in the eMMC firmware that causes > unrecoverable corruption when the MMC is erased with MMC_CAP_ERASE > enabled. > > References: > > http://forum.xda-developers.com/showthread.php?t=1644364 > https://plus.google.com/111398485184813224730/posts/21pTYfTsCkB#111398485184813224730/posts/21pTYfTsCkB > > Signed-off-by: Ian Chen > Reviewed-by: Namjae Jeon > Acked-by: Jaehoon Chung > Reviewed-by: Linus Walleij > Signed-off-by: Chris Ball > Signed-off-by: Greg Kroah-Hartman [...] I think you owe Greg a backport of this to 3.0. Ben. -- Ben Hutchings Usenet is essentially a HUGE group of people passing notes in class. - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette' signature.asc Description: This is a digitally signed message part
Re: [patch] mm, thp: fix mlock statistics
On Wed, Sep 26, 2012 at 7:29 PM, David Rientjes wrote: > NR_MLOCK is only accounted in single page units: there's no logic to > handle transparent hugepages. This patch checks the appropriate number > of pages to adjust the statistics by so that the correct amount of memory > is reflected. > > Reported-by: Hugh Dickens > Signed-off-by: David Rientjes Looks good, thanks! Reviewed-by: Michel Lespinasse -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- 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: [ 094/127] md: make sure metadata is updated when spares are activated or removed.
On Sat, Sep 29, 2012 at 12:51:04AM +0200, Ben Hutchings wrote: > On Fri, 2012-09-28 at 13:34 -0700, Greg Kroah-Hartman wrote: > > 3.0-stable review patch. If anyone has any objections, please let me know. > > > > -- > > > > From: NeilBrown > > > > commit 6dafab6b1383e912cd252fa809570b484eb6e0dc upstream. > [...] > > This is suitable for -stable as out-of-data metadata could lead > > to data corruption. > > This is only relevant for 3.3 and later 9when 'replacement' as > > introduced. > [...] > > Assuming Neil hasn't changed his mind about this, it should therefore > not be applied to 3.0. Neil, is this true? 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/
[PATCH] net: fix neigh_resolve_output can cause skb_under_panic
>From fd023edd911ef12aca38a72b40241661c202684f Mon Sep 17 00:00:00 2001
From: Ramesh Nagappa
Date: Thu, 27 Sep 2012 10:20:58 -0700
Subject: [PATCH] net: fix neigh_resolve_output can cause skb_under_panic
The retry loop in the neigh_resolve_output() and neigh_connected_output() can
add
a hard_header without resetting the skb to network header. This causes the
skb_push() in dev_hard_header() to fail.
Signed-off-by: Ramesh Nagappa
Signed-off-by: Shawn Lu
Reviewed-by: Billie Alsup
Reviewed-by: Robert Coulson
---
net/core/neighbour.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 96bb0a3..5a3dfec5 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -1327,6 +1327,7 @@ int neigh_resolve_output(struct sk_buff *skb)
do {
seq = read_seqbegin(>ha_lock);
+ __skb_pull(skb, skb_network_offset(skb));
err = dev_hard_header(skb, dev, ntohs(skb->protocol),
neigh->ha, NULL, skb->len);
} while (read_seqretry(>ha_lock, seq));
@@ -1358,10 +1359,10 @@ int neigh_connected_output(struct sk_buff *skb)
struct net_device *dev = neigh->dev;
unsigned int seq;
- __skb_pull(skb, skb_network_offset(skb));
do {
seq = read_seqbegin(>ha_lock);
+ __skb_pull(skb, skb_network_offset(skb));
err = dev_hard_header(skb, dev, ntohs(skb->protocol),
neigh->ha, NULL, skb->len);
} while (read_seqretry(>ha_lock, seq));
--
1.7.3.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: fix neigh_resolve_output can cause skb_under_panic
On Fri, Sep 28, 2012 at 07:40:39PM -0400, Ramesh Nagappa wrote: > >From fd023edd911ef12aca38a72b40241661c202684f Mon Sep 17 00:00:00 2001 > From: Ramesh Nagappa > Date: Thu, 27 Sep 2012 10:20:58 -0700 > Subject: [PATCH] net: fix neigh_resolve_output can cause skb_under_panic Why is all of this in the middle of the changelog section? I'm guessing you didn't use 'git send-email' for this? And why are you copying me on the patch? > The retry loop in the neigh_resolve_output() and neigh_connected_output() can > add > a hard_header without resetting the skb to network header. This causes the > skb_push() in dev_hard_header() to fail. > Signed-off-by: Ramesh Nagappa > Signed-off-by: Shawn Lu > Reviewed-by: Billie Alsup > Reviewed-by: Robert Coulson You need a blank line before the first Signed-off-by: line. Surely one of the reviewers should have caught this basic thing? 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/
[PATCH v6 10/10] selftest: report generation script for test results
A script that uses sqlite to load test results and generates a report
showing differences in performance per compiler used.
Signed-off-by: Daniel Santos
---
tools/testing/selftests/grbtree/user/gen_report.sh | 129
1 files changed, 129 insertions(+), 0 deletions(-)
create mode 100755 tools/testing/selftests/grbtree/user/gen_report.sh
diff --git a/tools/testing/selftests/grbtree/user/gen_report.sh
b/tools/testing/selftests/grbtree/user/gen_report.sh
new file mode 100755
index 000..a0ab88a
--- /dev/null
+++ b/tools/testing/selftests/grbtree/user/gen_report.sh
@@ -0,0 +1,129 @@
+#!/bin/bash
+
+dbfile=results.$$.db
+datafile=runtest.out
+
+die() {
+ echo "ERROR${@:+": "}$@" 1>&2
+ exit -1
+}
+
+find_sqlite() {
+ for suffix in "" 4 3; do
+ which sqlite${suffix} 2> /dev/null && return 0
+ done
+ return 1
+}
+
+sqlite=$(find_sqlite) || die "failed to find sqlite"
+
+${sqlite} "${dbfile}" << asdf
+/* .echo on */
+.headers on
+create table if not exists grbtest_result (
+ compilervarchar(255),
+ key_typevarchar(255),
+ payload int,
+ userlandtinyint,
+ use_generic tinyint,
+ use_leftmosttinyint,
+ use_rightmost tinyint,
+ use_count tinyint,
+ unique_keys tinyint,
+ insert_replaces tinyint,
+ debug tinyint,
+ debug_validate tinyint,
+ archvarchar(255),
+ arch_flags varchar(255),
+ processor varchar(255),
+ cc varchar(255),
+ cflags varchar(255),
+ testtinyint,
+ in_seed bigint,
+ seedbigint,
+ key_maskint,
+ object_countint,
+ pool_count int,
+ repsbigint,
+ node_size int,
+ object_size int,
+ pool_size int,
+ insertions bigint,
+ insertion_time bigint,
+ evictions bigint,
+ deletions bigint,
+ deletion_time bigint
+);
+.separator |
+.import ${datafile} grbtest_result
+/* .mode column */
+select distinct
+ key_type,
+ payload,
+ userland,
+ use_leftmost,
+ use_rightmost,
+ use_count,
+ unique_keys,
+ insert_replaces,
+ debug,
+ debug_validate,
+ arch,
+ arch_flags,
+ processor,
+ cc,
+ test,
+ in_seed,
+ seed,
+ key_mask,
+ object_count,
+ pool_count,
+ reps,
+ node_size,
+ object_size,
+ pool_size,
+ insertions,
+ evictions,
+ deletions
+from grbtest_result;
+
+select distinct
+ a.compiler as 'Compiler',
+ a.key_type,
+ a.payload,
+ a.userland,
+ (case when a.use_leftmost then'L' else '.' end) ||
+ (case when a.use_rightmost then 'R' else '.' end) ||
+ (case when a.use_count then 'C' else '.' end) ||
+ (case when a.unique_keys then 'U' else '.' end) ||
+ (case when a.insert_replaces then 'I' else '.' end) ||
+ (case when a.debug then 'D' else '.' end) ||
+ (case when a.debug_validate then 'V' else '.' end)
+ as config,
+ a.insertion_time as 'Generic Insert Time',
+ b.insertion_time as 'Hand-Coded Insert Time',
+ 1.0 * a.insertion_time / b.insertion_time - 1.0 as 'Insert Diff',
+ a.deletion_time as 'Generic Delete Time',
+ b.deletion_time as 'Hand-Coded Delete Time',
+ 1.0 * a.deletion_time / b.deletion_time - 1.0 as 'Delete Diff'
+from
+ grbtest_result as a inner join grbtest_result as b on (
+ a.compiler = b.compiler
+ AND a.key_type = b.key_type
+ AND a.payload = b.payload
+ AND a.userland = b.userland
+ AND a.use_leftmost = b.use_leftmost
+ AND a.use_rightmost = b.use_rightmost
+ AND a.use_count = b.use_count
+ AND a.unique_keys = b.unique_keys
+ AND a.insert_replaces = b.insert_replaces
+ AND a.debug = b.debug
+ AND a.debug_validate= b.debug_validate
+ )
+where
+ a.use_generic == 1
+ and b.use_generic = 0;
+asdf
+
+rm "${dbfile}"
+
--
1.7.3.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 v6 7/10] selftest: Add userspace test program.
Userspace test program using code from common.{c,h}. Userspace
compliation is accomplished by ovreriding a few kernel headers in the
overrides directory. This is an invasive hack (involving many internals
of kernel headers) that is expected to require fairly frequent
maintainence as kernel headers change.
The program grbtest can be run with -h option for help and outputs both
a human-readable format as well as a delimited text for more extensive
processing.
The exact behavior of the grbtest program depends upon the following
pre-processor variables, which the Makefile expects to be -Defined in a
CONFIG variable. Each variable should be assigned a value of 1 or 0, as
documented in common.h. If CONFIG is not set, a default is assigned in
the Makefile.
GRBTEST_KEY_TYPE
GRBTEST_PAYLOAD
GRBTEST_BUILD_GENERIC
GRBTEST_USE_LEFTMOST
GRBTEST_USE_RIGHTMOST
GRBTEST_USE_COUNT
GRBTEST_UNIQUE_KEYS
GRBTEST_INSERT_REPLACES
Generation of the resultant executable is also dependent upon the below
.config values.
DEBUG_GRBTREE
DEBUG_GRBTREE_VALIDATE
Signed-off-by: Daniel Santos
---
tools/testing/selftests/grbtree/user/Makefile | 68 +++
tools/testing/selftests/grbtree/user/facilities.c | 58 ++
tools/testing/selftests/grbtree/user/main.c| 621
.../grbtree/user/overrides/linux/export.h | 31 +
.../grbtree/user/overrides/linux/kernel.h | 83 +++
5 files changed, 861 insertions(+), 0 deletions(-)
create mode 100644 tools/testing/selftests/grbtree/user/Makefile
create mode 100644 tools/testing/selftests/grbtree/user/facilities.c
create mode 100644 tools/testing/selftests/grbtree/user/main.c
create mode 100644
tools/testing/selftests/grbtree/user/overrides/linux/export.h
create mode 100644
tools/testing/selftests/grbtree/user/overrides/linux/kernel.h
diff --git a/tools/testing/selftests/grbtree/user/Makefile
b/tools/testing/selftests/grbtree/user/Makefile
new file mode 100644
index 000..14380c2
--- /dev/null
+++ b/tools/testing/selftests/grbtree/user/Makefile
@@ -0,0 +1,68 @@
+# Default configuration (used if CONFIG not supplied)
+# See common.h for docs
+CONFIG ?= -DGRBTEST_KEY_TYPE=u32 \
+ -DGRBTEST_PAYLOAD=0 \
+ -DGRBTEST_BUILD_GENERIC=0 \
+ -DGRBTEST_USE_LEFTMOST=1 \
+ -DGRBTEST_USE_RIGHTMOST=1 \
+ -DGRBTEST_USE_COUNT=1 \
+ -DGRBTEST_UNIQUE_KEYS=1 \
+ -DGRBTEST_INSERT_REPLACES=1
+
+ifeq ($(KERNELRELEASE),)
+# Assume the source tree is where the running kernel was built
+# You should set KERNELDIR in the environment if it's elsewhere
+KERNELDIR ?= /lib/modules/$(shell uname -r)/build
+endif
+
+PWD := $(shell pwd)
+
+# The below KERNEL_ARCH works on x86_64, but hasn't been tested elsewhere
+# (e.g., x86 32-bit, ARM, etc.)
+KERNEL_ARCH = $(shell uname -m | sed 's/x86_64/x86/')
+
+# Kernel include directories
+KERNEL_INCLUDES = -I$(KERNELDIR)/include \
+ -I$(KERNELDIR)/arch/$(KERNEL_ARCH)/include
+CPPFLAGS += -DGRBTEST_USERLAND=1 -D__KERNEL__ -I$(PWD)/.. \
+ -I$(PWD)/overrides $(KERNEL_INCLUDES) $(CONFIG)
+WARN_FLAGS = -Wall -Wundef -Wstrict-prototypes -Wno-unused-variable \
+ -Werror-implicit-function-declaration -Wno-trigraphs \
+ -Wno-format-security -Wno-unused-variable
+# on gcc 4.3.6 and prior, we get some warnings for __rb_erase_color declared
+# inline after being called, so remove -Werror for now
+
+# Standard CFLAGS if not already set
+CFLAGS ?= -O2 -pipe
+# FIXME: breaks glibc
+#CFLAGS+= -mno-see
+# TODO: Can get tese from KBUILD_CFLAGS in arch//Makefile?
+#CFLAGS+= -march=native -mno-mmx -mno-sse2 -mno-3dnow -mno-avx
+CFLAGS += $(WARN_FLAGS) -fno-strict-aliasing -fno-common \
+ -fno-delete-null-pointer-checks
+CC ?= gcc
+CPPFLAGS += -DGRBTEST_CFLAGS="$(CFLAGS)" -DGRBTEST_CONFIG="$(CONFIG)" \
+ -DGRBTEST_CC="$(CC)" \
+ -DGRBTEST_ARCH="$(KERNEL_ARCH)" \
+ -DGRBTEST_ARCH_FLAGS="-march=k8 -m64" \
+ -DGRBTEST_PROCESSOR="$(shell uname -p)" \
+
+all: grbtest
+
+OBJ_FILES = main.o rbtree.o common.o facilities.o
+HEADER_FILES = $(KERNELDIR)/include/linux/rbtree.h ../common.h
+
+rbtree.c:
+ ln -s $(KERNELDIR)/lib/rbtree.c $(PWD)/rbtree.c
+
+common.c:
+ ln -s ../common.c common.c
+
+rbtree.o: rbtree.c $(KERNELDIR)/include/linux/rbtree.h
+
+grbtest: $(OBJ_FILES) $(HEADER_FILES)
+ $(CC) $(CFLAGS) $(OBJ_FILES) -o grbtest
+
+clean:
+ rm -f grbtest *.o rbtree.c common.c
+
diff --git a/tools/testing/selftests/grbtree/user/facilities.c
b/tools/testing/selftests/grbtree/user/facilities.c
new file mode 100644
index 000..63c29aa
--- /dev/null
+++ b/tools/testing/selftests/grbtree/user/facilities.c
@@ -0,0 +1,58 @@
+/* facilities.c - userspace facilities used by common.c/h
+ *
[PATCH v6 9/10] selftest: Add basic compiler iterator test script
A Gentoo-specific script (to be run by root) to iterate through all
installed compilers, execte runtest.sh script and collect the output
data.
Signed-off-by: Daniel Santos
---
tools/testing/selftests/grbtree/user/runtests.sh | 52 ++
1 files changed, 52 insertions(+), 0 deletions(-)
create mode 100755 tools/testing/selftests/grbtree/user/runtests.sh
diff --git a/tools/testing/selftests/grbtree/user/runtests.sh
b/tools/testing/selftests/grbtree/user/runtests.sh
new file mode 100755
index 000..d60ec99
--- /dev/null
+++ b/tools/testing/selftests/grbtree/user/runtests.sh
@@ -0,0 +1,52 @@
+#!/bin/bash
+
+# This script is designed for use on Gentoo systems, using gcc-config to
+# change the compiler and must be run as root. I'm lazy, so alter to fit your
+# system.
+
+#key_type_range=$(echo {u,s}{8,16,32,64})
+key_type_range="u32 u64"
+unique_style_range="0 1 2"
+add_ons_range="0 1 2"
+
+user=daniel
+outfile=runtests.$$.out
+
+die() {
+ echo "ERROR${@:+": "}$@" 1>&2
+ exit -1
+}
+
+
+rm -f runtest.log runtest.out
+
+if [[ -e ${outfile} ]]; then
+ echo "File ${outfile} exists, please move it out of the way."
+ exit
+fi
+
+for ((gcc_inst_num = 10; gcc_inst_num > 1; --gcc_inst_num)); do
+ gcc-config $gcc_inst_num || exit
+ . /etc/profile
+
+ for key_type in ${key_type_range}; do
+ for unique_style in ${unique_style_range}; do
+ for add_ons in ${add_ons_range}; do
+
+ nice -n -3 sudo -Hu ${user} \
+ key_type=${key_type}\
+ payload=0 \
+ use_leftmost=$((add_ons > 0)) \
+ use_rightmost=$((add_ons == 2)) \
+ use_count=$((add_ons == 2)) \
+ unique_keys=$((unique_style > 0)) \
+ insert_replaces=$((unique_style == 2)) \
+ reps=0x2\
+ ./runtest.sh >> ${outfile} || die
+
+ done
+ done
+ done
+done
+gcc-config 10
+. /etc/profile
--
1.7.3.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 v6 8/10] selftest: Add script to compile & run userspace test program
This is a basic script is designed to automate the testing process (for
a single compiler) and generate delimited text output suitable for later
processing. All test parameters can be supplied via the environment, or
defaults will be used for them. The following variables affect the
script and if not supplied, will have the these default values:
CC "gcc"
KERNELDIR "../../../../.."
CFLAGS "-O2 -pipe -march=k8"
key_type"u64"
payload 0
use_leftmost0
use_rightmost 0
use_count 0
unique_keys 0
insert_replaces 0
test_num0
reps0x2
count 0x800
keymask 0xfff
logfile runtest.log
datafileruntest.out
Signed-off-by: Daniel Santos
---
tools/testing/selftests/grbtree/user/runtest.sh | 122 +++
1 files changed, 122 insertions(+), 0 deletions(-)
create mode 100755 tools/testing/selftests/grbtree/user/runtest.sh
diff --git a/tools/testing/selftests/grbtree/user/runtest.sh
b/tools/testing/selftests/grbtree/user/runtest.sh
new file mode 100755
index 000..b481ad3
--- /dev/null
+++ b/tools/testing/selftests/grbtree/user/runtest.sh
@@ -0,0 +1,122 @@
+#!/bin/bash
+
+# runtest.sh - script to compile and run userspace tests of gerneric red-black
+# tree implementation for a single compiler.
+#
+# Copyright (C) 2012 Daniel Santos
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License
+# as published by the Free Software Foundation; either version 2
+# of the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
USA.
+
+die() {
+ echo "ERROR${@:+": "}$@" 1>&2
+ exit -1
+}
+
+set_var_default() {
+ (($# == 2)) || die "set_var_default takes two parameters, got $#: $@"
+
+ var="$1"
+ default_val="$2"
+ cur_val=$(eval echo "\$${var}")
+
+ if [[ -z "${cur_val}" ]]; then
+ eval ${var}=\"${default_val}\"
+ fi
+}
+
+# Variables affecting code generation
+set_var_default CC gcc
+set_var_default KERNELDIR "../../../../.."
+set_var_default CFLAGS "-O2 -pipe -march=k8"
+# CONFIG parameters:
+set_var_default key_type u64
+set_var_default payload0
+set_var_default use_leftmost 0
+set_var_default use_rightmost 0
+set_var_default use_count 0
+set_var_default unique_keys0
+set_var_default insert_replaces0
+# For test_num, see grbtest -h
+set_var_default test_num 0
+
+# Variables passed to grbtest program
+set_var_default reps 0x2
+set_var_default count 0x800
+set_var_default keymask0xfff
+
+# Output files
+set_var_default logfileruntest.log
+set_var_default datafile runtest.out
+
+
+build_desc[0]="hand-coded"
+build_desc[1]="generic"
+
+. /etc/profile || die
+
+do_cpp() {
+ echo "$1" > /tmp/gnucver.$$.c || die
+ ${CC} -E /tmp/gnucver.$$.c | grep -v '^#' | tr -d ' '
+ rm /tmp/gnucver.$$.c
+}
+
+gccverstr=$(do_cpp "__GNUC__.__GNUC_MINOR__.__GNUC_PATCHLEVEL__") || die
+
+execute_tests() {
+ for build_generic in 1 0; do
+ CONFIG=$(echo \
+ -DGRBTEST_KEY_TYPE=${key_type} \
+ -DGRBTEST_PAYLOAD=${payload}\
+ -DGRBTEST_BUILD_GENERIC=${build_generic}\
+ -DGRBTEST_USE_LEFTMOST=${use_leftmost} \
+ -DGRBTEST_USE_RIGHTMOST=${use_rightmost}\
+ -DGRBTEST_USE_COUNT=${use_count}\
+ -DGRBTEST_UNIQUE_KEYS=${unique_keys}\
+ -DGRBTEST_INSERT_REPLACES=${insert_replaces}
+ )
+
+ echo ""
+ echo "Starting build at $(date '+%Y-%m-%d %H:%M:%S')..."
+ echo " build_type = ${build_desc[${build_generic}]}"
+ echo " compiler = ${gccverstr}"
+ echo " CFLAGS = ${CFLAGS}"
+ echo " KERNELDIR = ${KERNELDIR}"
+ echo
+
+ #set -x
+ CC="${CC}" \
+ CFLAGS="${CFLAGS}" \
+ CONFIG="${CONFIG}" \
+ KERNELDIR="${KERNELDIR}"\
+ make clean all || die
+ set
[PATCH v6 6/10] selftest: Add generic tree self-test common code.
Self-test code for both performance and correctness testing. The files
tools/testing/selftests/grbtree/common.{h,c} contain code for use in
both the user- and kernel-space test program/module and depends upon a
few functions being made available by said.
The purpose of these tests is to verify correctness across compilers and
document the performance difference between the generic and hand-coded
red-black tree implementations on various compilers, which is identified
as critical for determining feasibility of adding this this tree
implementation to the kernel, as older compilers optimize the generic
code more poorly than its hand-coded counterpart.
Signed-off-by: Daniel Santos
---
tools/testing/selftests/grbtree/common.c | 892 ++
tools/testing/selftests/grbtree/common.h | 293 ++
2 files changed, 1185 insertions(+), 0 deletions(-)
create mode 100644 tools/testing/selftests/grbtree/common.c
create mode 100644 tools/testing/selftests/grbtree/common.h
diff --git a/tools/testing/selftests/grbtree/common.c
b/tools/testing/selftests/grbtree/common.c
new file mode 100644
index 000..f5383be
--- /dev/null
+++ b/tools/testing/selftests/grbtree/common.c
@@ -0,0 +1,892 @@
+/* common.c - generic red-black tree test functions for use in both kernel and
+ * user space.
+ * Copyright (C) 2012 Daniel Santos
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
USA.
+ */
+
+#include "common.h"
+
+#define _CONCAT2(a, b) a ## b
+#define _CONCAT(a, b) _CONCAT2(a, b)
+
+
+const char *grbtest_type_desc[GRBTEST_TYPE_COUNT] = {
+ "insertion performance",
+ "insertion & deletion performance",
+ "insertion validation"
+};
+
+#if GRBTEST_BUILD_GENERIC
+/
+ * Generic Implementation
+ */
+
+#define __GRBTEST_FLAGS\
+ ((GRBTEST_UNIQUE_KEYS ? RB_UNIQUE_KEYS : 0) | \
+(GRBTEST_INSERT_REPLACES ? RB_INSERT_REPLACES : 0))
+
+
+
+static inline long compare_s8(const s8 *a, const s8 *b) {return *a - *b;}
+static inline long greater_s8(const s8 *a, const s8 *b) {return *a > *b;}
+
+static inline long compare_u8(const u8 *a, const u8 *b) {return (long)*a -
(long)*b;}
+static inline long greater_u8(const u8 *a, const u8 *b) {return *a > *b;}
+
+static inline long compare_s16(const s16 *a, const s16 *b) {return *a - *b;}
+static inline long greater_s16(const s16 *a, const s16 *b) {return *a > *b;}
+
+static inline long compare_u16(const u16 *a, const u16 *b) {return (long)*a -
(long)*b;}
+static inline long greater_u16(const u16 *a, const u16 *b) {return *a > *b;}
+
+static inline long compare_s32(const s32 *a, const s32 *b) {return *a - *b;}
+static inline long greater_s32(const s32 *a, const s32 *b) {return *a > *b;}
+
+static inline long compare_u32(const u32 *a, const u32 *b) {return (long)*a -
(long)*b;}
+static inline long greater_u32(const u32 *a, const u32 *b) {return *a > *b;}
+
+static inline long compare_s64(const s64 *a, const s64 *b) {return *a - *b;}
+static inline long greater_s64(const s64 *a, const s64 *b) {return *a > *b;}
+
+static inline long compare_u64(const u64 *a, const u64 *b) {return *a - *b;}
+static inline long greater_u64(const u64 *a, const u64 *b) {return *a > *b;}
+
+
+RB_DEFINE_INTERFACE(
+ mytree,
+ struct container, tree,
+#if GRBTEST_USE_LEFTMOST
+ leftmost
+#endif
+ ,
+#if GRBTEST_USE_RIGHTMOST
+ rightmost
+#endif
+ ,
+#if GRBTEST_USE_COUNT
+ count
+#endif
+ ,
+ struct object, node, key,
+ __GRBTEST_FLAGS, _CONCAT(compare_, GRBTEST_KEY_TYPE),
+#if GRBTEST_UNIQUE_KEYS
+ _CONCAT(compare_, GRBTEST_KEY_TYPE),
+#else
+ _CONCAT(greater_, GRBTEST_KEY_TYPE),
+#endif
+ static __flatten inline,/* find */
+ static __flatten inline,/* insert */
+ static __flatten inline,/* find_near */
+ static __flatten inline); /* insert_near */
+
+
+#else /* GRBTEST_BUILD_GENERIC */
+
+/
+ * Hand-coded Implementation
+ *
+ * This section implements the find, insert & remove functions as one would do
+ * so were they hand-coding it, except that we use
Re: [ 035/218] vfs: make O_PATH file descriptors usable for fstat()
On Fri, Sep 28, 2012 at 4:27 PM, Ben Hutchings wrote: > > The upstream version exchanges fget_light() for fget_raw_light(). Since > 3.2 (and likewise 3.4) have fget() here, I cherry-picked e994def 'VFS: > make vfs_fstat() use f[get|put]_light()' before this. Was that a > bad/good/neutral idea? Pretty neutral, I don't think it matters. Doing like greg did and just doing it with fget_raw() (without the cherry-pick) is fine too. Linus -- 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] checkpatch: fix name of "MODULE_PARM_DESC"
Fix macro name in checkpatch: s/PARAM/PARM/.
Signed-off-by: Kees Cook
---
scripts/checkpatch.pl |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index ca05ba2..df5e229 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2947,7 +2947,7 @@ sub process {
my $exceptions = qr{
$Declare|
module_param_named|
- MODULE_PARAM_DESC|
+ MODULE_PARM_DESC|
DECLARE_PER_CPU|
DEFINE_PER_CPU|
__typeof__\(|
--
1.7.9.5
--
Kees Cook
Chrome OS Security
--
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 v6 2/10] rbtree.h: include kconfig.h
We shouldn't depend upon kernel.h including this for us. However, this
also fixes some issues with compiling in userland (coming later).
Signed-off-by: Daniel Santos
---
include/linux/rbtree.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/rbtree.h b/include/linux/rbtree.h
index 210ebeb..48e325f 100644
--- a/include/linux/rbtree.h
+++ b/include/linux/rbtree.h
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
struct rb_node {
unsigned long __rb_parent_color;
--
1.7.3.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 v6 5/10] rbtree.h: add doc comments for struct rb_node
Signed-off-by: Daniel Santos
---
include/linux/rbtree.h | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/include/linux/rbtree.h b/include/linux/rbtree.h
index 5f10915..c815b5e 100644
--- a/include/linux/rbtree.h
+++ b/include/linux/rbtree.h
@@ -35,6 +35,20 @@
#include
#include
+/**
+ * struct rb_node
+ * @__rb_parent_color: Contains the color in the lower 2 bits (although only
+ *bit zero is currently used) and the address of the
+ *parent in the rest (lower 2 bits of address should
+ *always be zero on any arch supported). If the node is
+ *initialized and not a member of any tree, the parent
+ *point to its self. If the node belongs to a tree, but
+ *is the root element, the parent will be NULL.
+ *Otherwise, parent will always point to the parent node
+ *in the tree.
+ * @rb_right: Pointer to the right element.
+ * @rb_left: Pointer to the left element.
+ */
struct rb_node {
unsigned long __rb_parent_color;
struct rb_node *rb_right;
--
1.7.3.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 v6 4/10] rbtree.h: Add test & validation framework
This introduces the following .config variables:
DEBUG_GRBTREE
DEBUG_GRBTREE_VALIDATE
DEBUG_GRBTREE will enable the use of the following new flags in struct
rb_relationship's flags member. When DEBUG_GRBTREE is not enabled in the
config, these flags will evaluate to zero.
RB_VERIFY_USAGE - Perform additional checks to assure that nodes are not
inserted into more than one tree by mistake, but adds the requirement
that nodes are initialized (rb_debug_clear_node) prior to insertion.
RB_VERIFY_INTEGRITY - Perform exhaustive integrity checks on tree during
most manipulation & access functions (high run-time overhead)
Finally, the DEBUG_GRBTREE_VALIDATE .config variable will force-enable
the RB_VERIFY_INTEGRITY behavior on all trees.
Signed-off-by: Daniel Santos
---
include/linux/rbtree.h | 153 ---
lib/Kconfig.debug | 22 +++-
2 files changed, 164 insertions(+), 11 deletions(-)
diff --git a/include/linux/rbtree.h b/include/linux/rbtree.h
index 48e325f..5f10915 100644
--- a/include/linux/rbtree.h
+++ b/include/linux/rbtree.h
@@ -85,7 +85,6 @@ static inline void rb_link_node(struct rb_node * node, struct
rb_node * parent,
*rb_link = node;
}
-
#define __JUNK junk,
#define _iff_empty(test_or_junk, t, f) __iff_empty(test_or_junk, t, f)
#define __iff_empty(__ignored1, __ignored2, result, ...) result
@@ -134,6 +133,18 @@ static inline void rb_link_node(struct rb_node * node,
struct rb_node * parent,
*/
#define OPT_OFFSETOF(type, member) IFF_EMPTY(member, 0, offsetof(type, member))
+
+#define GRBTREE_DEBUG IS_ENABLED(DEBUG_GRBTREE)
+#define GRBTREE_VALIDATE IS_ENABLED(DEBUG_GRBTREE_VALIDATE)
+
+/* keep disabled debug code out of older compilers that fail to optimize out
+ * const struct member values */
+#if GRBTREE_DEBUG
+# define __RB_DEBUG_ENABLE_MASK 0x
+#else
+# define __RB_DEBUG_ENABLE_MASK 0
+#endif
+
/**
* enum rb_flags - values for strct rb_relationship's flags
* @RB_HAS_LEFTMOST: The container has a struct rb_node *leftmost member
@@ -147,18 +158,47 @@ static inline void rb_link_node(struct rb_node * node,
struct rb_node * parent,
* @RB_INSERT_REPLACES:When set, the rb_insert() will replace a value
if it
* matches the supplied one (valid only when
* RB_UNIQUE_KEYS is set).
+ * @RB_VERIFY_USAGE: Perform checks upon node insertion for a small run-time
+ * overhead. This has other usage restrictions, so read
+ * the Description section before using. Available only
+ * when CONFIG_DEBUG_GRBTREE is enabled.
+ * @RB_VERIFY_INTEGRITY:Perform exauhstive integrity checks on most operations
+ * (large run-time overhead). Available only when
+ * CONFIG_DEBUG_GRBTREE is enabled.
* @RB_ALL_FLAGS: (internal use)
+ *
+ *
+ * When RB_VERIFY_USAGE is set in the relationship flags and
+ * CONFIG_DEBUG_GRBTREE is enabled, you will be required to initialize nodes
+ * with rb_debug_clear_node() prior to inserting them (which is normally not
+ * necessary). Upon insertion (rb_insert and rb_insert_near), additional
+ * checks will be performed to verify that the node is properly initialized and
+ * does not belong to another tree. Upon removal (rb_remove) the node is
+ * re-initialized, so calling rb_debug_clear_node() is only required when you
+ * originally create the node. If you remove it and re-add it multiple times
+ * (or to multiple trees) you do not have to manually re-initialize it. This
+ * causes a small run-time overhead.
+ *
+ * When RB_VERIFY_INTEGRITY is set and CONFIG_DEBUG_GRBTREE is enabled,
+ * validation of tree integrity will occur in most functions. As the tree is
+ * traversed downward, each child's parent link will be verified. When the
+ * tree is traversed upwards (__rb_find_subtree) each parent's left or right
+ * link (respective to the traversal) will be verified. Finally, when
+ * iterating over a tree, the compare function will be called to verify the
+ * order of elements. This has a high run-time overhead.
*/
-
enum rb_flags {
RB_HAS_LEFTMOST = 0x0001,
RB_HAS_RIGHTMOST= 0x0002,
RB_HAS_COUNT= 0x0004,
RB_UNIQUE_KEYS = 0x0008,
RB_INSERT_REPLACES = 0x0010,
+ RB_VERIFY_USAGE = 0x0080 & __RB_DEBUG_ENABLE_MASK,
+ RB_VERIFY_INTEGRITY = 0x0100 & __RB_DEBUG_ENABLE_MASK,
RB_ALL_FLAGS= RB_HAS_LEFTMOST | RB_HAS_RIGHTMOST
| RB_HAS_COUNT | RB_UNIQUE_KEYS
- | RB_INSERT_REPLACES,
+ | RB_INSERT_REPLACES
+ | RB_VERIFY_USAGE | RB_VERIFY_INTEGRITY,
};
/**
@@ -257,7 +297,6 @@ const void *rb_to_key(const void *ptr, const struct
rb_relationship *rel)
return __RB_PTR(const void, ptr,
[PATCH v6 3/10] Generate doc comments for rbtree.h in Kernel-API
Signed-off-by: Daniel Santos --- Documentation/DocBook/kernel-api.tmpl |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl index 00687ee..d270f1e 100644 --- a/Documentation/DocBook/kernel-api.tmpl +++ b/Documentation/DocBook/kernel-api.tmpl @@ -43,6 +43,9 @@ Doubly Linked Lists !Iinclude/linux/list.h + Red-Black Trees +!Iinclude/linux/rbtree.h + -- 1.7.3.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 v6 1/10] rbtree.h: Generic Red-Black Trees
Add generic red-black tree code to rbtree.h.
Signed-off-by: Daniel Santos
---
include/linux/rbtree.h | 1125 +++-
1 files changed, 1123 insertions(+), 2 deletions(-)
diff --git a/include/linux/rbtree.h b/include/linux/rbtree.h
index 0022c1b..210ebeb 100644
--- a/include/linux/rbtree.h
+++ b/include/linux/rbtree.h
@@ -1,7 +1,8 @@
/*
Red Black Trees
(C) 1999 Andrea Arcangeli
-
+ (C) 2012 Daniel Santos
+
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
@@ -31,6 +32,7 @@
#include
#include
+#include
struct rb_node {
unsigned long __rb_parent_color;
@@ -61,6 +63,7 @@ struct rb_root {
extern void rb_insert_color(struct rb_node *, struct rb_root *);
extern void rb_erase(struct rb_node *, struct rb_root *);
+typedef long (*rb_compare_f)(const void *a, const void *b);
/* Find logical next and previous nodes in a tree */
extern struct rb_node *rb_next(const struct rb_node *);
@@ -69,7 +72,7 @@ extern struct rb_node *rb_first(const struct rb_root *);
extern struct rb_node *rb_last(const struct rb_root *);
/* Fast replacement of a single node without remove/rebalance/add/rebalance */
-extern void rb_replace_node(struct rb_node *victim, struct rb_node *new,
+extern void rb_replace_node(struct rb_node *victim, struct rb_node *new,
struct rb_root *root);
static inline void rb_link_node(struct rb_node * node, struct rb_node * parent,
@@ -81,4 +84,1122 @@ static inline void rb_link_node(struct rb_node * node,
struct rb_node * parent,
*rb_link = node;
}
+
+#define __JUNK junk,
+#define _iff_empty(test_or_junk, t, f) __iff_empty(test_or_junk, t, f)
+#define __iff_empty(__ignored1, __ignored2, result, ...) result
+
+/**
+ * IFF_EMPTY() - Expands to the second argument when the first is empty, the
+ * third if non-empty.
+ * @test:An argument to test for emptiness.
+ * @t: A value to expand to if test is empty.
+ * @f: A value to expand to if test is non-empty.
+ *
+ * Caveats:
+ * IFF_EMPTY isn't perfect. The test parameter must either be empty or a valid
+ * pre-processor token as well as result in a valid token when pasted to the
+ * end of a word.
+ *
+ * Valid Examples:
+ * IFF_EMPTY(a, b, c) = c
+ * IFF_EMPTY( , b, c) = b
+ * IFF_EMPTY( , , c) = (nothing)
+ *
+ * Invalid Examples:
+ * IFF_EMPTY(., b, c)
+ * IFF_EMPTY(+, b, c)
+ */
+#define IFF_EMPTY(test, t, f) _iff_empty(__JUNK##test, t, f)
+
+/**
+ * IS_EMPTY() - test if a pre-processor argument is empty.
+ * @arg:An argument (empty or non-empty)
+ *
+ * If empty, expands to 1, 0 otherwise. See IFF_EMPTY() for caveats &
+ * limitations.
+ */
+#define IS_EMPTY(arg) IFF_EMPTY(arg, 1, 0)
+
+/**
+ * OPT_OFFSETOF() - return the offsetof for the supplied expression, or zero
+ * if m is an empty argument.
+ * @type: struct/union type
+ * @member: (optional) struct member name
+ *
+ * Since any offsetof can return zero if the specified member is the first in
+ * the struct/union, you should also check if the argument is empty separately
+ * with IS_EMPTY(m).
+ */
+#define OPT_OFFSETOF(type, member) IFF_EMPTY(member, 0, offsetof(type, member))
+
+/**
+ * enum rb_flags - values for strct rb_relationship's flags
+ * @RB_HAS_LEFTMOST: The container has a struct rb_node *leftmost member
+ * that will receive a pointer to the leftmost (smallest)
+ * object in the tree that is updated during inserts &
+ * deletions.
+ * @RB_HAS_RIGHTMOST: Same as above (for right side of tree).
+ * @RB_HAS_COUNT: The container has an unsigned long field that will
+ * receive updates of the object count in the tree.
+ * @RB_UNIQUE_KEYS:The tree contains only unique values.
+ * @RB_INSERT_REPLACES:When set, the rb_insert() will replace a value
if it
+ * matches the supplied one (valid only when
+ * RB_UNIQUE_KEYS is set).
+ * @RB_ALL_FLAGS: (internal use)
+ */
+
+enum rb_flags {
+ RB_HAS_LEFTMOST = 0x0001,
+ RB_HAS_RIGHTMOST= 0x0002,
+ RB_HAS_COUNT= 0x0004,
+ RB_UNIQUE_KEYS = 0x0008,
+ RB_INSERT_REPLACES = 0x0010,
+ RB_ALL_FLAGS= RB_HAS_LEFTMOST | RB_HAS_RIGHTMOST
+ | RB_HAS_COUNT | RB_UNIQUE_KEYS
+ | RB_INSERT_REPLACES,
+};
+
+/**
+ * struct rb_relationship - Defines relationship between a container and the
+ * objects it contains.
+ * @root_offset: Offset of container's struct rb_root member.
+ * @left_offset: (Used only if RB_HAS_LEFTMOST is set) Offset of the
+ * container's
[PATCH v6 0/10] Generic Red-Black Trees
This patch set depends upon the following:
* Cleanup & new features for compiler*.h and bug.h
* kernel-doc bug fixes (for generating docs)
Summary
===
This patch set improves on Andrea Arcangeli's original Red-Black Tree
implementation by adding generic search and insert functions with
complete support for:
o leftmost - keeps a pointer to the leftmost (lowest value) node cached
in your container struct
o rightmost - ditto for rightmost (greatest value)
o count - optionally update an count variable when you perform inserts
or deletes
o unique or non-unique keys
o find and insert "near" functions - when you already have a node that
is likely near another one you want to search for
o type-safe wrapper interface available via pre-processor macro
Outstanding Issues
==
General
---
o Need something in Documents to explain generic rbtrees.
o Due to a bug in gcc's optimizer, extra instructions are generated in various
places. Pavel Pisa has provided me a possible work-around that should be
examined more closely to see if it can be working in (Discussed in
Performance section).
o Doc-comments are missing or out of date in some places for the new
ins_compare field of struct rb_relationship (including at least one code
example).
Selftests
-
o In-kernel test module not completed.
o Userspace selftest's Makefile should run modules_prepare in KERNELDIR.
o Userspace selftest's Makefile also fairly sucks (doesn't properly check
changes, etc -- I'm not a make guru)
o Validation in self-tests doesn't yet cover tests for
- insert_near
- find_{first,last,next,prev}
o Selftest scripts need better portability (maybe solved? we'll see)
o It would be nice to have some fault-injection in test code to verify that
CONFIG_DEBUG_GRBTREE and CONFIG_DEBUG_GRBTREE_VALIDATE (and it's
RB_VERIFY_INTEGRITY counterpart flag) catch the errors they are supposed to.
Undecided (Opinions Requested!)
---
o With the exception of the rb_node & rb_root structs, "Layer 2" of the code
(see below) completely abstracts away the underlying red-black tree
mechanism. The structs rb_node and rb_root can also be abstracted away via
a typeset or some other mechanism. Thus, should the "Layer 2" code be
separated from "Layer 1" and renamed "Generic Tree (gtree)" or some such,
paving the way for an alternate tree implementation in the future?
o Do we need RB_INSERT_DUPE_RIGHT? (see the last patch)
Theory of Operation
===
Historically, genericity in C meant function pointers, the overhead of a
function call and the inability of the compiler to optimize code across
the function call boundary. GCC has been getting better and better at
optimization and determining when a value is a compile-time constant and
compiling it out. As of gcc 4.6, it has finally reached a point where
it's possible to have generic search & insert cores that optimize
exactly as well as if they were hand-coded. (see also gcc man page:
-findirect-inlining)
This implementation actually consists of two layers written on top of the
existing rbtree implementation.
Layer 1: Type-Specific (But Not Type-Safe)
--
The first layer consists of enum rb_flags, struct rb_relationship and
some generic inline functions(see patch for doc comments).
enum rb_flags {
RB_HAS_LEFTMOST = 0x0001,
RB_HAS_RIGHTMOST= 0x0002,
RB_HAS_COUNT= 0x0004,
RB_UNIQUE_KEYS = 0x0008,
RB_INSERT_REPLACES = 0x0010,
RB_IS_AUGMENTED = 0x0040,
RB_VERIFY_USAGE = 0x0080,
RB_VERIFY_INTEGRITY = 0x0100
};
struct rb_relationship {
ssize_t root_offset;
ssize_t left_offset;
ssize_t right_offset;
ssize_t count_offset;
ssize_t node_offset;
ssize_t key_offset;
int flags;
const rb_compare_f compare; /* comparitor for lookups */
const rb_compare_f ins_compare; /* comparitor for inserts */
unsigned key_size;
};
/* these function for use on all trees */
struct rb_node *rb_find(
struct rb_root *root,
const void *key,
const struct rb_relationship *rel);
struct rb_node *rb_find_near(
struct rb_node *from,
const void *key,
const struct rb_relationship *rel);
struct rb_node *rb_insert(
struct rb_root *root,
struct rb_node *node,
const struct rb_relationship *rel);
struct rb_node *rb_insert_near(
struct rb_root *root,
struct rb_node *start,
struct rb_node *node,
const struct rb_relationship *rel);
void rb_remove( struct rb_root *root,
struct rb_node *node,
const struct rb_relationship *rel);
/* these function for use on
Re: Slow copy_to_user performance after kernel upgrade
On Fri, Sep 28, 2012 at 03:58:26PM -0500, Thad Phetteplace wrote: > I am debugging an issue with copy_to_user performance on recent linux > kernels. I've noticed a 4X slowdown in copy speed when I move from > kernel 2.6.18 to more recent kernels on the same hardware. I've > tested so far on 2.6.32 and on various 3.x kernels. I noticed that > assembly code implementation of copy_to_user has changed, so as a > sanity check I ported the 2.6.18 version over to 2.6.32 but saw the > same slowdown when using it. This is the hardware I am using: > > Dell PowerEdge R710 > BIOS version 6.3.0 > Intel(R) Xeon(R) CPU x5650 @ 2.67GHz > 72GB RAM (ECC DDR3 800MHz) > > I am running the x86_64 version of course. I see the issue when I do > a copy_to_user from a dedicated block of memory located above the 4GB > boundary into normal user space mem. The boot parameter mem=65G is > passed to the kernel to carve off the dedicated block of memory that > is used as a DMA accessible buffer for a specialized network card. > That is the buffer we do the copy_to_user from. I should also mention > we have been testing this on CentOS 4.8, 6.2, and 6.3, though I've > replaced their stock kernels with ones straight from kernel.org, so I > don't know that the linux distro is really relevant. > > I've browsed the kernel mailing list looking for clues and have even > been looking at CPU/hardware specific errata, but so far I can see no > logical reason why the 2.6.32+ kernels should be performing so much > worse than the 2.6.18. Does anyone have any suggestions on areas to > dig into besides the copy_to_user implementation itself? Maybe > somewhere specific in the MMU code? Any suggestions would be > appreciated. Please copy me directly on replies if you don't mind. > What cpu frequency governor are you using for testing? Perhaps the default ondemand governor is not boosting the cpu frequency when you are running yor benchmark? If that's the case, try to rerun with performance governor. Tim -- 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 14/16] iommu/irq: Use amd_iommu_irq_ops if supported
On Fri, Sep 28, 2012 at 6:24 AM, Joerg Roedel wrote:
> Finally enable interrupt remapping for AMD systems.
>
> Signed-off-by: Joerg Roedel
> ---
> drivers/iommu/irq_remapping.c |5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
> index 151690d..faf85d6 100644
> --- a/drivers/iommu/irq_remapping.c
> +++ b/drivers/iommu/irq_remapping.c
> @@ -51,6 +51,11 @@ early_param("intremap", setup_irqremap);
> void __init setup_irq_remapping_ops(void)
> {
> remap_ops = _irq_remap_ops;
> +
> +#ifdef CONFIG_AMD_IOMMU
> + if (amd_iommu_irq_ops.prepare() == 0)
> + remap_ops = _iommu_irq_ops;
> +#endif
Should remap_ops be set to null when amd_iommu_irq_ops.prepare()
fails?What happens if remap_ops left set to intel_irq_remap_ops?
Should remap_ops = _irq_remap_ops; moved into #else case
forifdef CONFIG_AMD_IOMMU?
> }
>
> int irq_remapping_supported(void)
> --
> 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/
--
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: [ 043/218] ARM: 7527/1: uaccess: explicitly check __user pointer when !CPU_USE_DOMAINS
On Fri, 2012-09-28 at 13:14 -0700, Greg Kroah-Hartman wrote:
> 3.4-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Russell King
>
> commit 8404663f81d212918ff85f493649a7991209fa04 upstream.
>
> The {get,put}_user macros don't perform range checking on the provided
> __user address when !CPU_HAS_DOMAINS.
>
> This patch reworks the out-of-line assembly accessors to check the user
> address against a specified limit, returning -EFAULT if is is out of
> range.
>
> [will: changed get_user register allocation to match put_user]
> [rmk: fixed building on older ARM architectures]
[...]
It looks like this is needed for at least some older kernel versions,
but a backported version will be needed for 3.2 and earlier.
Ben.
--
Ben Hutchings
Usenet is essentially a HUGE group of people passing notes in class.
- Rachel Kadel, `A Quick Guide to Newsgroup Etiquette'
signature.asc
Description: This is a digitally signed message part
[PATCH 1/3] asm-generic: introduce pmd_special() and pmd_mkspecial()
From: "Kirill A. Shutemov"
Special PMD is similar to special PTE: it requires special handling.
Currently, it's needed to mark PMD with all PTEs set to zero page.
If an arch wants to provide support of special PMD it need to select
HAVE_PMD_SPECIAL config option and implement pmd_special() and
pmd_mkspecial().
Signed-off-by: Kirill A. Shutemov
---
arch/Kconfig |6 ++
include/asm-generic/pgtable.h | 12
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/Kconfig b/arch/Kconfig
index 72f2fa1..a74ba25 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -281,4 +281,10 @@ config SECCOMP_FILTER
See Documentation/prctl/seccomp_filter.txt for details.
+config HAVE_PMD_SPECIAL
+ bool
+ help
+ An arch should select this symbol if it provides pmd_special()
+ and pmd_mkspecial().
+
source "kernel/gcov/Kconfig"
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index ff4947b..393f3f0 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -59,6 +59,18 @@ static inline int pmdp_test_and_clear_young(struct
vm_area_struct *vma,
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
#endif
+#ifndef CONFIG_HAVE_PMD_SPECIAL
+static inline int pmd_special(pmd_t pmd)
+{
+ return 0;
+}
+
+static inline pmd_t pmd_mkspecial(pmd_t pmd)
+{
+ return pmd;
+}
+#endif
+
#ifndef __HAVE_ARCH_PTEP_CLEAR_YOUNG_FLUSH
int ptep_clear_flush_young(struct vm_area_struct *vma,
unsigned long address, pte_t *ptep);
--
1.7.7.6
--
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 0/3] Virtual huge zero page
From: "Kirill A. Shutemov" Here's alternative implementation of huge zero page: virtual huge zero page. Virtual huge zero page is a PMD table with all entries set to zero page. H. Peter Anvin asked to evaluate this implementation option. Pros: - cache friendly (not yet benchmarked); - less changes required (if I haven't miss something ;); Cons: - increases TLB pressure; - requires per-arch enabling; - one more check on handle_mm_fault() path. At the moment I did only sanity check. Testing is required. Any opinion? Kirill A. Shutemov (3): asm-generic: introduce pmd_special() and pmd_mkspecial() mm, thp: implement virtual huge zero page x86: implement HAVE_PMD_SPECAIL arch/Kconfig |6 ++ arch/x86/Kconfig |1 + arch/x86/include/asm/pgtable.h | 14 +- include/asm-generic/pgtable.h | 12 include/linux/mm.h |8 mm/huge_memory.c | 38 ++ mm/memory.c| 15 --- 7 files changed, 86 insertions(+), 8 deletions(-) -- 1.7.7.6 -- 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] x86: implement HAVE_PMD_SPECAIL
From: "Kirill A. Shutemov"
We can use the same bit as for special PTE.
There's no conflict with _PAGE_SPLITTING since it's only defined for PSE
pmd, but special PMD is only valid for non-PSE.
Signed-off-by: Kirill A. Shutemov
---
arch/x86/Kconfig |1 +
arch/x86/include/asm/pgtable.h | 14 +-
2 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 50a1d1f..b2146c3 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -97,6 +97,7 @@ config X86
select KTIME_SCALAR if X86_32
select GENERIC_STRNCPY_FROM_USER
select GENERIC_STRNLEN_USER
+ select HAVE_PMD_SPECIAL
config INSTRUCTION_DECODER
def_bool (KPROBES || PERF_EVENTS || UPROBES)
diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index 49afb3f..ff61694 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -167,6 +167,12 @@ static inline int has_transparent_hugepage(void)
}
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
+static inline int pmd_special(pmd_t pmd)
+{
+ return !pmd_trans_huge(pmd) &&
+ pmd_flags(pmd) & _PAGE_SPECIAL;
+}
+
static inline pte_t pte_set_flags(pte_t pte, pteval_t set)
{
pteval_t v = native_pte_val(pte);
@@ -290,6 +296,11 @@ static inline pmd_t pmd_mknotpresent(pmd_t pmd)
return pmd_clear_flags(pmd, _PAGE_PRESENT);
}
+static inline pmd_t pmd_mkspecial(pmd_t pmd)
+{
+ return pmd_set_flags(pmd, _PAGE_SPECIAL);
+}
+
/*
* Mask out unsupported bits in a present pgprot. Non-present pgprots
* can use those bits for other purposes, so leave them be.
@@ -474,7 +485,8 @@ static inline pte_t *pte_offset_kernel(pmd_t *pmd, unsigned
long address)
static inline int pmd_bad(pmd_t pmd)
{
- return (pmd_flags(pmd) & ~_PAGE_USER) != _KERNPG_TABLE;
+ pmdval_t flags = pmd_flags(pmd);
+ return (flags & ~(_PAGE_USER | _PAGE_SPECIAL)) != _KERNPG_TABLE;
}
static inline unsigned long pages_to_mb(unsigned long npg)
--
1.7.7.6
--
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, thp: implement virtual huge zero page
From: "Kirill A. Shutemov"
Virtual huge zero page is a PMD table with all entries set to zero page.
When we get write-protect page fault to zero page in such PMD we drop
the whole page table and allow THP (if enabled) to allocate a real
memory instead.
The implementation requires HAVE_PMD_SPECAIL from an arch if it wants to
support virtual zero page.
Signed-off-by: Kirill A. Shutemov
---
include/linux/mm.h |8
mm/huge_memory.c | 38 ++
mm/memory.c| 15 ---
3 files changed, 54 insertions(+), 7 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 311be90..179a41c 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -514,6 +514,14 @@ static inline pte_t maybe_mkwrite(pte_t pte, struct
vm_area_struct *vma)
}
#endif
+#ifndef my_zero_pfn
+static inline unsigned long my_zero_pfn(unsigned long addr)
+{
+ extern unsigned long zero_pfn;
+ return zero_pfn;
+}
+#endif
+
/*
* Multiple processes may "see" the same page. E.g. for untouched
* mappings of /dev/null, all processes see the same page full of
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 57c4b93..8189fb6 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -696,6 +696,33 @@ static inline struct page *alloc_hugepage(int defrag)
}
#endif
+static void set_huge_zero_page(pgtable_t pgtable, struct vm_area_struct *vma,
+ unsigned long haddr, pmd_t *pmd)
+{
+ pmd_t _pmd;
+ int i;
+
+ pmdp_clear_flush_notify(vma, haddr, pmd);
+ /* leave pmd empty until pte is filled */
+
+ pmd_populate(vma->vm_mm, &_pmd, pgtable);
+
+ for (i = 0; i < HPAGE_PMD_NR; i++, haddr += PAGE_SIZE) {
+ pte_t *pte, entry;
+ entry = pfn_pte(my_zero_pfn(haddr), vma->vm_page_prot);
+ entry = pte_mkspecial(entry);
+ pte = pte_offset_map(&_pmd, haddr);
+ VM_BUG_ON(!pte_none(*pte));
+ set_pte_at(vma->vm_mm, haddr, pte, entry);
+ pte_unmap(pte);
+ }
+ smp_wmb(); /* make pte visible before pmd */
+ pmd_populate(vma->vm_mm, pmd, pgtable);
+ _pmd = pmd_mkspecial(*pmd);
+ set_pmd_at(vma->vm_mm, haddr, pmd, _pmd);
+ vma->vm_mm->nr_ptes++;
+}
+
int do_huge_pmd_anonymous_page(struct mm_struct *mm, struct vm_area_struct
*vma,
unsigned long address, pmd_t *pmd,
unsigned int flags)
@@ -709,6 +736,17 @@ int do_huge_pmd_anonymous_page(struct mm_struct *mm,
struct vm_area_struct *vma,
return VM_FAULT_OOM;
if (unlikely(khugepaged_enter(vma)))
return VM_FAULT_OOM;
+ if (IS_ENABLED(CONFIG_HAVE_PMD_SPECIAL) &&
+ !(flags & FAULT_FLAG_WRITE)) {
+ pgtable_t pgtable;
+ pgtable = pte_alloc_one(mm, haddr);
+ if (unlikely(!pgtable))
+ goto out;
+ spin_lock(>page_table_lock);
+ set_huge_zero_page(pgtable, vma, haddr, pmd);
+ spin_unlock(>page_table_lock);
+ return 0;
+ }
page = alloc_hugepage_vma(transparent_hugepage_defrag(vma),
vma, haddr, numa_node_id(), 0);
if (unlikely(!page)) {
diff --git a/mm/memory.c b/mm/memory.c
index 5736170..38dfd5e 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -724,13 +724,6 @@ static inline int is_zero_pfn(unsigned long pfn)
}
#endif
-#ifndef my_zero_pfn
-static inline unsigned long my_zero_pfn(unsigned long addr)
-{
- return zero_pfn;
-}
-#endif
-
/*
* vm_normal_page -- This function gets the "struct page" associated with a
pte.
*
@@ -3514,6 +3507,14 @@ retry:
pmd = pmd_alloc(mm, pud, address);
if (!pmd)
return VM_FAULT_OOM;
+
+ if (pmd_special(*pmd) && flags & FAULT_FLAG_WRITE) {
+ pgtable_t pgtable = pmd_pgtable(*pmd);
+ pmd_clear(pmd);
+ pte_free(mm, pgtable);
+ mm->nr_ptes--;
+ }
+
if (pmd_none(*pmd) && transparent_hugepage_enabled(vma)) {
if (!vma->vm_ops)
return do_huge_pmd_anonymous_page(mm, vma, address,
--
1.7.7.6
--
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] kernel-doc: Don't mangle whitespace in Example section
A section with the name "Example" (case-insensitive) has a special
meaning to kernel-doc. These sections are output using mono-type fonts.
However, leading whitespace is stripped, thus robbing a lot of meaning
from this, as indented code examples will be mangled.
This patch preserves the leading whitespace for "Example" sections.
More accurately, it preserves it for all sections, but removes it later
if the section isn't an "Example" section.
Signed-off-by: Daniel Santos
---
scripts/kernel-doc |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 2be2078..46e7aff 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -296,9 +296,10 @@ my $doc_special = "\@\%\$\&";
my $doc_start = '^/\*\*\s*$'; # Allow whitespace at end of comment start.
my $doc_end = '\*/';
my $doc_com = '\s*\*\s*';
+my $doc_com_body = '\s*\* ?';
my $doc_decl = $doc_com . '(\w+)';
my $doc_sect = $doc_com . '([' . $doc_special . ']?[\w\s]+):(.*)';
-my $doc_content = $doc_com . '(.*)';
+my $doc_content = $doc_com_body . '(.*)';
my $doc_block = $doc_com . 'DOC:\s*(.*)?';
my %constants;
@@ -486,6 +487,9 @@ sub output_highlight {
$contents =~ s/\s+$//;
}
foreach $line (split "\n", $contents) {
+ if (! $output_preformatted) {
+ $line =~ s/^\s*//;
+ }
if ($line eq ""){
if (! $output_preformatted) {
print $lineprefix, local_unescape($blankline);
@@ -2344,7 +2348,7 @@ sub process_file($) {
$descr= $1;
$descr =~ s/^\s*//;
$descr =~ s/\s*$//;
- $descr =~ s/\s+/ /;
+ $descr =~ s/\s+/ /g;
$declaration_purpose = xml_escape($descr);
$in_purpose = 1;
} else {
@@ -2436,6 +2440,7 @@ sub process_file($) {
# Continued declaration purpose
chomp($declaration_purpose);
$declaration_purpose .= " " . xml_escape($1);
+ $declaration_purpose =~ s/\s+/ /g;
} else {
$contents .= $1 . "\n";
}
--
1.7.3.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 2/3] kernel-doc: bugfix - empty line in Example section
If you have a section named "Example" that contains an empty line,
attempting to generate htmldocs give you the error:
/path/Documentation/DocBook/kernel-api.xml:3455: parser error : Opening and
ending tag mismatch: programlisting line 3449 and para
^
/path/Documentation/DocBook/kernel-api.xml:3473: parser error : Opening and
ending tag mismatch: para line 3467 and programlisting
^
/path/Documentation/DocBook/kernel-api.xml:3678: parser error : Opening and
ending tag mismatch: programlisting line 3672 and para
^
/path/Documentation/DocBook/kernel-api.xml:3701: parser error : Opening and
ending tag mismatch: para line 3690 and programlisting
^
unable to parse
/path/Documentation/DocBook/kernel-api.xml
Essentially, the script attempts to close a with a
closing tag for a block. This patch corrects the problem by
simply not outputting anything extra when we're dumping pre-formatted
text, since the empty line will be rendered correctly anyway.
Signed-off-by: Daniel Santos
---
scripts/kernel-doc | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index e6bc9db..2be2078 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -245,6 +245,7 @@ my $dohighlight = "";
my $verbose = 0;
my $output_mode = "man";
+my $output_preformatted = 0;
my $no_doc_sections = 0;
my %highlights = %highlights_man;
my $blankline = $blankline_man;
@@ -486,7 +487,9 @@ sub output_highlight {
}
foreach $line (split "\n", $contents) {
if ($line eq ""){
- print $lineprefix, local_unescape($blankline);
+ if (! $output_preformatted) {
+ print $lineprefix, local_unescape($blankline);
+ }
} else {
$line =~ s/\\/\&/g;
if ($output_mode eq "man" && substr($line, 0, 1) eq ".") {
@@ -902,10 +905,12 @@ sub output_section_xml(%) {
print "$section\n";
if ($section =~ m/EXAMPLE/i) {
print "\n";
+ $output_preformatted = 1;
} else {
print "\n";
}
output_highlight($args{'sections'}{$section});
+ $output_preformatted = 0;
if ($section =~ m/EXAMPLE/i) {
print "\n";
} else {
@@ -1208,10 +1213,12 @@ sub output_blockhead_xml(%) {
}
if ($section =~ m/EXAMPLE/i) {
print "\n";
+ $output_preformatted = 1;
} else {
print "\n";
}
output_highlight($args{'sections'}{$section});
+ $output_preformatted = 0;
if ($section =~ m/EXAMPLE/i) {
print "\n";
} else {
@@ -1287,10 +1294,12 @@ sub output_function_gnome {
print "\n $section\n";
if ($section =~ m/EXAMPLE/i) {
print "\n";
+ $output_preformatted = 1;
} else {
}
print "\n";
output_highlight($args{'sections'}{$section});
+ $output_preformatted = 0;
print "\n";
if ($section =~ m/EXAMPLE/i) {
print "\n";
--
1.7.3.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 1/3] kernel-doc: bugfix - multi-line macros
Prior to this patch the following code breaks:
/**
* multiline_example - this breaks kernel-doc
*/
#define multiline_example( \
myparam)
Producing this error:
Error(somefile.h:983): cannot understand prototype: 'multiline_example( \ '
This patch fixes the issue by appending all lines ending in a blackslash
(optionally followed by whitespace), removing the backslash and any
whitespace after it prior to appending (just like the C pre-processor
would).
This fixes a break in kerel-doc introduced by the additions to rbtree.h.
Signed-off-by: Daniel Santos
---
scripts/kernel-doc |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 5ee8e91..e6bc9db 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -2305,6 +2305,9 @@ sub process_file($) {
$section_counter = 0;
while () {
+ while (s/\\\s*$//) {
+ $_ .= ;
+ }
if ($state == 0) {
if (/$doc_start/o) {
$state = 1; # next line is always the function name
--
1.7.3.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 0/3] kernel-doc bug fixes
Fixes breakages exposed by doc-comments used in the generic red-black tree patch set. -- 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 1/4] mfd: 88pm860x: use irqdomain
Hi Haojian: On Fri, Sep 21, 2012 at 06:06:51PM +0800, Haojian Zhuang wrote: > @@ -593,13 +610,9 @@ static int __devinit device_irq_init(struct pm860x_chip > *chip, > : chip->companion; > unsigned char status_buf[INT_STATUS_NUM]; > unsigned long flags = IRQF_TRIGGER_FALLING | IRQF_ONESHOT; > - int i, data, mask, ret = -EINVAL; That one breaks the build: drivers/mfd/88pm860x-core.c: In function ‘device_irq_init’: drivers/mfd/88pm860x-core.c:628:7: error: ‘i’ undeclared (first use in this function) drivers/mfd/88pm860x-core.c:628:7: note: each undeclared identifier is reported only once for each function it appears in drivers/mfd/88pm860x-core.c:629:3: error: ‘__irq’ undeclared (first use in this function) make[2]: *** [drivers/mfd/88pm860x-core.o] Error 1 I removed this patchset until it builds... Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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: [ 035/218] vfs: make O_PATH file descriptors usable for fstat()
On Fri, 2012-09-28 at 13:14 -0700, Greg Kroah-Hartman wrote:
> 3.4-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Linus Torvalds
>
> commit 55815f70147dcfa3ead5738fd56d3574e2e3c1c2 upstream.
>
> We already use them for openat() and friends, but fstat() also wants to
> be able to use O_PATH file descriptors. This should make it more
> directly comparable to the O_SEARCH of Solaris.
>
> Note that you could already do the same thing with "fstatat()" and an
> empty path, but just doing "fstat()" directly is simpler and faster, so
> there is no reason not to just allow it directly.
>
> See also commit 332a2e1244bd, which did the same thing for fchdir, for
> the same reasons.
>
> Reported-by: ольга крыжановская
> Cc: Al Viro
> Signed-off-by: Linus Torvalds
> Signed-off-by: Greg Kroah-Hartman
The upstream version exchanges fget_light() for fget_raw_light(). Since
3.2 (and likewise 3.4) have fget() here, I cherry-picked e994def 'VFS:
make vfs_fstat() use f[get|put]_light()' before this. Was that a
bad/good/neutral idea?
Ben.
> ---
> fs/stat.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/fs/stat.c
> +++ b/fs/stat.c
> @@ -57,7 +57,7 @@ EXPORT_SYMBOL(vfs_getattr);
>
> int vfs_fstat(unsigned int fd, struct kstat *stat)
> {
> - struct file *f = fget(fd);
> + struct file *f = fget_raw(fd);
> int error = -EBADF;
>
> if (f) {
--
Ben Hutchings
Usenet is essentially a HUGE group of people passing notes in class.
- Rachel Kadel, `A Quick Guide to Newsgroup Etiquette'
signature.asc
Description: This is a digitally signed message part
[PATCH 3/10] compiler-gcc.h: Add gcc-recommended GCC_VERSION macro
Throughout compiler*.h, many version checks are made. These can be simplified by using the macro that gcc's documentation recommends. However, my primary reason for adding this is that I need bug-check macros that are enabled at certain gcc versions and it's cleaner to use this macro than the tradition method: if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ => 2) If you add patch level, it gets this ugly: if __GNUC__ > 4 || (__GNUC__ == 4 && (__GNUC_MINOR__ > 2 || \ __GNUC_MINOR__ == 2 __GNUC_PATCHLEVEL__ >= 1)) As opposed to: if GCC_VERSION >= 40201 While having separate headers for gcc 3 & 4 eliminates some of this verbosity, they can still be cleaned up by this. See also: http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html Signed-off-by: Daniel Santos --- include/linux/compiler-gcc.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h index 6a6d7ae..24545cd 100644 --- a/include/linux/compiler-gcc.h +++ b/include/linux/compiler-gcc.h @@ -5,6 +5,9 @@ /* * Common definitions for all gcc versions go here. */ +#define GCC_VERSION (__GNUC__ * 1 \ + + __GNUC_MINOR__ * 100 \ + + __GNUC_PATCHLEVEL__) /* Optimization barrier */ -- 1.7.3.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 10/10] bug.h: Add gcc 4.2+ versions of BUILD_BUG_ON_* macros
BUILD_BUG_ON42(arg)
BUILD_BUG_ON_CONST42(arg)
Prior to gcc 4.2, the optimizer was unable to determine that many
constant values stored in structs were indeed compile-time constants and
optimize them out. Sometimes, it will find an intergral value to be a
compile-time constant, but fail to perform a bit-wise AND at
compile-time. These two macros provide a mechanism to perform these
build-time checks, but not break on older compilers where we already
know they can't be checked at compile time.
For specific details, consult the doc comments for BUILD_BUG_ON_CONST.
These macros are used in the generic rbtree code.
Signed-off-by: Daniel Santos
---
include/linux/bug.h | 36
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/include/linux/bug.h b/include/linux/bug.h
index e30f600..d14c23c 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -2,6 +2,7 @@
#define _LINUX_BUG_H
#include
+#include
enum bug_trap_type {
BUG_TRAP_TYPE_NONE = 0,
@@ -129,6 +130,41 @@ struct pt_regs;
#define BUILD_BUG_ON_NON_CONST(exp)
#endif
+
+#if GCC_VERSION >= 40200
+/**
+ * BUILD_BUG_ON_NON_CONST42 - break compile if expression cannot be determined
+ *to be a compile-time constant (disabled prior to
+ *gcc 4.2)
+ * @exp: value to test for compile-time constness
+ *
+ * Use this macro instead of BUILD_BUG_ON_NON_CONST when testing struct
+ * members or dereferenced arrays and pointers. Note that the version checks
+ * for this macro are not perfect. BUILD_BUG_ON_NON_CONST42 expands to nothing
+ * prior to gcc-4.2, after which it is the same as BUILD_BUG_ON_NON_CONST.
+ * However, there are still many checks that will break with this macro (see
+ * the Gory Details section of BUILD_BUG_ON_NON_CONST for more info).
+ *
+ * See also BUILD_BUG_ON_NON_CONST()
+ */
+# define BUILD_BUG_ON_NON_CONST42(exp) BUILD_BUG_ON_NON_CONST(exp)
+
+/**
+ * BUILD_BUG_ON42 - break compile if expression cannot be determined
+ * (disabled prior to gcc 4.2)
+ *
+ * This gcc-version check is necessary due to breakages in testing struct
+ * members prior to gcc 4.2.
+ *
+ * See also BUILD_BUG_ON()
+ */
+# define BUILD_BUG_ON42(arg) BUILD_BUG_ON(arg)
+#else
+# define BUILD_BUG_ON_NON_CONST42(exp)
+# define BUILD_BUG_ON42(arg)
+#endif /* GCC_VERSION >= 40200 */
+
+
#endif /* __CHECKER__ */
#ifdef CONFIG_GENERIC_BUG
--
1.7.3.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 9/10] bug.h: Add BUILD_BUG_ON_NON_CONST macro
A very common use of __builtin_constant_p is to make sure that a certain value is a compile time constant and generate a build-time error if it is not. However, __builtin_constant_p is broken in a variety of ways in various situations (on various versions of gcc) and never returns one in an unoptimized build. This macro provide a mechanism to perform these build-time checks, but not break unoptimized builds (or modules being build with -O0), of which there probably aren't many people that care anyway. This patch documents all of the relevant quirks I could find in the "Gory Details" section of the doc-comments. For almost all cases, BUILD_BUG_ON_NON_CONST() should never fail on a primitive, non-pointer type variable declared const. A subsequent patch provides a separate macro for performing tests which are known to be broken in older compilers (pretty much, using __builtin_constant_p on arrays, pointers & structs as well as testing those values). Signed-off-by: Daniel Santos --- include/linux/bug.h | 48 1 files changed, 48 insertions(+), 0 deletions(-) diff --git a/include/linux/bug.h b/include/linux/bug.h index c70b833..e30f600 100644 --- a/include/linux/bug.h +++ b/include/linux/bug.h @@ -81,6 +81,54 @@ struct pt_regs; __build_bug_failed(); \ } while (0) +/** + * BUILD_BUG_ON_NON_CONST - break compile if expression cannot be determined + * to be a compile-time constant. + * @exp: value to test for compile-time constness + * + * __builtin_constant_p() is a work in progress and is broken in various ways + * on various versions of gcc and optimization levels. It can fail, even when + * gcc otherwise determines that the expression is compile-time constant when + * performing actual optimizations and thus, compile out the value anyway. Do + * not use this macro for struct members or dereferenced pointers and arrays, + * as these are broken in many versions of gcc -- use BUILD_BUG_ON_NON_CONST42 + * or another gcc-version-checked macro instead. + * + * As long as you are passing a variable declared const (and not modified), + * this macro should never fail (except for floats). For information on gcc's + * behavior in other cases, see below. + * + * Gory Details: + * + * Normal primitive variables + * - global non-static non-const values are never compile-time constants (but + * you should already know that) + * - all const values (global/local, non/static) should never fail this test + * (3.4+) with one exception (below) + * - floats (which we wont use anyway) are broken in various ways until 4.2 + * (-O1 broken until 4.4) + * - local static non-const broken until 4.2 (-O1 broken until 4.3) + * - local non-static non-const broken until 4.0 + * + * Dereferencing pointers & arrays + * - all static const derefs broken until 4.4 (except arrays at -O2 or better, + * which are fixed in 4.2) + * - global non-static const pointer derefs always fail (<=4.7) + * - local non-static const derefs broken until 4.3, except for array derefs + * to a zero value, which works from 4.0+ + * - local static non-const pointers always fail (<=4.7) + * - local static non-const arrays broken until 4.4 + * - local non-static non-const arrays broken until 4.0 (unless zero deref, + * works in 3.4+) + + */ +#ifdef __OPTIMIZE__ +#define BUILD_BUG_ON_NON_CONST(exp) \ + BUILD_BUG_ON(!__builtin_constant_p(exp)) +#else +#define BUILD_BUG_ON_NON_CONST(exp) +#endif + #endif /* __CHECKER__ */ #ifdef CONFIG_GENERIC_BUG -- 1.7.3.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 8/10] bug.h: Make BUILD_BUG_ON generate compile-time error
Negative sized arrays wont create a compile-time error in some cases
starting with gcc 4.4 (e.g., inlined functions), but gcc 4.3 introduced
the error function attribute that will. This patch modifies
BUILD_BUG_ON to behave like BUILD_BUG already does, using the error
function attribute so that you don't have to build the entire kernel to
discover that you have a problem, and then enjoy trying to track it down
from a link-time error.
Signed-off-by: Daniel Santos
---
include/linux/bug.h | 24 ++--
1 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/include/linux/bug.h b/include/linux/bug.h
index 298a916..c70b833 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -42,24 +42,28 @@ struct pt_regs;
* @condition: the condition which the compiler should know is false.
*
* If you have some code which relies on certain constants being equal, or
- * other compile-time-evaluated condition, you should use BUILD_BUG_ON to
+ * some other compile-time-evaluated condition, you should use BUILD_BUG_ON to
* detect if someone changes it.
*
* The implementation uses gcc's reluctance to create a negative array, but
* gcc (as of 4.4) only emits that error for obvious cases (eg. not arguments
- * to inline functions). So as a fallback we use the optimizer; if it can't
- * prove the condition is false, it will cause a link error on the undefined
- * "__build_bug_on_failed". This error message can be harder to track down
- * though, hence the two different methods.
+ * to inline functions). Luckily, in 4.3 they added the "error" function
+ * attribute just for this type of case. Thus, we use a negative sized array
+ * (should always create an error pre-gcc-4.4) and then call an undefined
+ * function with the error attribute (should always creates an error 4.3+). If
+ * for some reason, neither creates a compile-time error, we'll still have a
+ * link-time error, which is harder to track down.
*/
#ifndef __OPTIMIZE__
#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
#else
-extern int __build_bug_on_failed;
-#define BUILD_BUG_ON(condition)\
- do {\
- ((void)sizeof(char[1 - 2*!!(condition)])); \
- if (condition) __build_bug_on_failed = 1; \
+#define BUILD_BUG_ON(condition)
\
+ do {\
+ extern void __build_bug_on_failed(void) \
+ __compiletime_error("BUILD_BUG_ON failed"); \
+ ((void)sizeof(char[1 - 2*!!(condition)])); \
+ if (condition) \
+ __build_bug_on_failed();\
} while(0)
#endif
--
1.7.3.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 7/10] compiler{,-gcc4}.h: Introduce __flatten function attribute
For gcc 4.1 & later, expands to __attribute__((flatten)) which forces the compiler to inline everything it can into the function. This is useful in combination with noinline when you want to control the depth of inlining, or create a single function where inline expansions will occur. (see http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#index-g_t_0040code_007bflatten_007d-function-attribute-2512) Normally, it's best to leave this type of thing up to the compiler. However, the generic rbtree code uses inline functions just to be able to inject compile-time constant data that specifies how the caller wants the function to behave (via struct rb_relationship). This data can be thought of as the template parameters of a C++ templatized function. Since some of these functions, once expanded, become quite large, gcc sometimes decides not to perform some important inlining, in one case, even generating a few bytes more code by not doing so. (Note: I have not eliminated the possibility that this was an optimization bug, but the flatten attribute fixes it in either case.) Combining __flatten and noinline insures that important optimizations occur in these cases and that the inline expansion occurs in exactly one place, thus not leading to unnecissary bloat. However, it also can eliminate some opportunities for optimization should gcc otherwise decide the function its self is a good candidate for inlining. Signed-off-by: Daniel Santos --- include/linux/compiler-gcc4.h |7 ++- include/linux/compiler.h |4 2 files changed, 10 insertions(+), 1 deletions(-) diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h index ad610f2..5a0897e 100644 --- a/include/linux/compiler-gcc4.h +++ b/include/linux/compiler-gcc4.h @@ -15,7 +15,12 @@ #if GCC_VERSION >= 40102 # define __compiletime_object_size(obj) __builtin_object_size(obj, 0) -#endif + +/* flatten introduced in 4.1, but broken in 4.6.0 (gcc bug #48731)*/ +# if GCC_VERSION != 40600 +# define __flatten __attribute__((flatten)) +# endif +#endif /* GCC_VERSION >= 40102 */ #if GCC_VERSION >= 40300 /* Mark functions as cold. gcc will assume any path leading to a call diff --git a/include/linux/compiler.h b/include/linux/compiler.h index fd455aa..268aeb6 100644 --- a/include/linux/compiler.h +++ b/include/linux/compiler.h @@ -244,6 +244,10 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect); #define __always_inline inline #endif +#ifndef __flatten +#define __flatten +#endif + #endif /* __KERNEL__ */ /* -- 1.7.3.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 5/10] compiler{,-gcc4}.h: Remove duplicate macros
__linktime_error() does the same thing as __compiletime_error() and is only used in bug.h. Since the macro defines a function attribute that will cause a failure at compile-time (not link-time), it makes more sense to keep __compiletime_error(), which is also neatly mated with __compiletime_warning(). Signed-off-by: Daniel Santos --- include/linux/compiler-gcc4.h |2 -- include/linux/compiler.h |3 --- 2 files changed, 0 insertions(+), 5 deletions(-) diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h index b44307d..ad610f2 100644 --- a/include/linux/compiler-gcc4.h +++ b/include/linux/compiler-gcc4.h @@ -33,8 +33,6 @@ the kernel context */ #define __cold __attribute__((__cold__)) -#define __linktime_error(message) __attribute__((__error__(message))) - #ifndef __CHECKER__ # define __compiletime_warning(message) __attribute__((warning(message))) # define __compiletime_error(message) __attribute__((error(message))) diff --git a/include/linux/compiler.h b/include/linux/compiler.h index f430e41..fd455aa 100644 --- a/include/linux/compiler.h +++ b/include/linux/compiler.h @@ -297,9 +297,6 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect); #ifndef __compiletime_error # define __compiletime_error(message) #endif -#ifndef __linktime_error -# define __linktime_error(message) -#endif /* * Prevent the compiler from merging or refetching accesses. The compiler * is also forbidden from reordering successive instances of ACCESS_ONCE(), -- 1.7.3.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 4/10] compiler-gcc{3,4}.h: Use GCC_VERSION macro
Using GCC_VERSION reduces complexity, is easier to read and is GCC's
recommended mechanism for doing version checks. (Just don't ask me why
they didn't define it in the first place.) This also makes it easy to
merge compiler-gcc{3,4}.h should somebody want to.
Signed-off-by: Daniel Santos
---
include/linux/compiler-gcc3.h |8
include/linux/compiler-gcc4.h | 14 +++---
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/include/linux/compiler-gcc3.h b/include/linux/compiler-gcc3.h
index 37d4124..7d89feb 100644
--- a/include/linux/compiler-gcc3.h
+++ b/include/linux/compiler-gcc3.h
@@ -2,22 +2,22 @@
#error "Please don't include directly, include
instead."
#endif
-#if __GNUC_MINOR__ < 2
+#if GCC_VERSION < 30200
# error Sorry, your compiler is too old - please upgrade it.
#endif
-#if __GNUC_MINOR__ >= 3
+#if GCC_VERSION >= 30300
# define __used__attribute__((__used__))
#else
# define __used__attribute__((__unused__))
#endif
-#if __GNUC_MINOR__ >= 4
+#if GCC_VERSION >= 30400
#define __must_check __attribute__((warn_unused_result))
#endif
#ifdef CONFIG_GCOV_KERNEL
-# if __GNUC_MINOR__ < 4
+# if GCC_VERSION < 30400
# error "GCOV profiling support for gcc versions below 3.4 not included"
# endif /* __GNUC_MINOR__ */
#endif /* CONFIG_GCOV_KERNEL */
diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
index 4506d65..b44307d 100644
--- a/include/linux/compiler-gcc4.h
+++ b/include/linux/compiler-gcc4.h
@@ -4,7 +4,7 @@
/* GCC 4.1.[01] miscompiles __weak */
#ifdef __KERNEL__
-# if __GNUC_MINOR__ == 1 && __GNUC_PATCHLEVEL__ <= 1
+# if GCC_VERSION >= 40100 && GCC_VERSION <= 40101
//# error Your version of gcc miscompiles the __weak directive
# endif
#endif
@@ -13,11 +13,11 @@
#define __must_check __attribute__((warn_unused_result))
#define __compiler_offsetof(a,b) __builtin_offsetof(a,b)
-#if __GNUC_MINOR__ > 0
+#if GCC_VERSION >= 40102
# define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
#endif
-#if __GNUC_MINOR__ >= 3
+#if GCC_VERSION >= 40300
/* Mark functions as cold. gcc will assume any path leading to a call
to them will be unlikely. This means a lot of manual unlikely()s
are unnecessary now for any paths leading to the usual suspects
@@ -39,9 +39,9 @@
# define __compiletime_warning(message) __attribute__((warning(message)))
# define __compiletime_error(message) __attribute__((error(message)))
#endif /* __CHECKER__ */
-#endif /* __GNUC_MINOR__ >= 3 */
+#endif /* GCC_VERSION >= 40300 */
-#if __GNUC_MINOR__ >= 5
+#if GCC_VERSION >= 40500
/*
* Mark a position in code as unreachable. This can be used to
* suppress control flow warnings after asm blocks that transfer
@@ -56,9 +56,9 @@
/* Mark a function definition as prohibited from being cloned. */
#define __noclone __attribute__((__noclone__))
-#endif /* __GNUC_MINOR__ >= 5 */
+#endif /* GCC_VERSION >= 40500 */
-#if __GNUC_MINOR__ >= 6
+#if GCC_VERSION >= 40600
/*
* Tell the optimizer that something else uses this function or variable.
*/
--
1.7.3.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 2/10] compiler-gcc4.h: Reorder macros based upon gcc ver
This helps to keep the file from getting confusing, removes one duplicate version check and should encourage future editors to put new macros where they belong. Signed-off-by: Daniel Santos --- include/linux/compiler-gcc4.h | 20 +++- 1 files changed, 11 insertions(+), 9 deletions(-) diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h index 8721704..4506d65 100644 --- a/include/linux/compiler-gcc4.h +++ b/include/linux/compiler-gcc4.h @@ -13,6 +13,10 @@ #define __must_check __attribute__((warn_unused_result)) #define __compiler_offsetof(a,b) __builtin_offsetof(a,b) +#if __GNUC_MINOR__ > 0 +# define __compiletime_object_size(obj) __builtin_object_size(obj, 0) +#endif + #if __GNUC_MINOR__ >= 3 /* Mark functions as cold. gcc will assume any path leading to a call to them will be unlikely. This means a lot of manual unlikely()s @@ -31,6 +35,12 @@ #define __linktime_error(message) __attribute__((__error__(message))) +#ifndef __CHECKER__ +# define __compiletime_warning(message) __attribute__((warning(message))) +# define __compiletime_error(message) __attribute__((error(message))) +#endif /* __CHECKER__ */ +#endif /* __GNUC_MINOR__ >= 3 */ + #if __GNUC_MINOR__ >= 5 /* * Mark a position in code as unreachable. This can be used to @@ -46,8 +56,7 @@ /* Mark a function definition as prohibited from being cloned. */ #define __noclone __attribute__((__noclone__)) -#endif -#endif +#endif /* __GNUC_MINOR__ >= 5 */ #if __GNUC_MINOR__ >= 6 /* @@ -56,10 +65,3 @@ #define __visible __attribute__((externally_visible)) #endif -#if __GNUC_MINOR__ > 0 -#define __compiletime_object_size(obj) __builtin_object_size(obj, 0) -#endif -#if __GNUC_MINOR__ >= 3 && !defined(__CHECKER__) -#define __compiletime_warning(message) __attribute__((warning(message))) -#define __compiletime_error(message) __attribute__((error(message))) -#endif -- 1.7.3.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] tools lib traceevent: Fix missed freeing of subargs in free_arg() in filter
Some of args were missed in free_args(), as well as subargs.
That is args like FILTER_ARG_NUM have left and right pointers to
other args that also need to be freed.
Signed-off-by: Steven Rostedt
---
tools/lib/traceevent/parse-filter.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/tools/lib/traceevent/parse-filter.c
b/tools/lib/traceevent/parse-filter.c
index ad17855..2d907cb 100644
--- a/tools/lib/traceevent/parse-filter.c
+++ b/tools/lib/traceevent/parse-filter.c
@@ -209,7 +209,12 @@ static void free_arg(struct filter_arg *arg)
switch (arg->type) {
case FILTER_ARG_NONE:
case FILTER_ARG_BOOLEAN:
+ break;
+
case FILTER_ARG_NUM:
+ case FILTER_ARG_EXP:
+ free_arg(arg->op.left);
+ free_arg(arg->op.right);
break;
case FILTER_ARG_STR:
@@ -218,6 +223,12 @@ static void free_arg(struct filter_arg *arg)
free(arg->str.buffer);
break;
+ case FILTER_ARG_VALUE:
+ if (arg->value.type == FILTER_STRING ||
+ arg->value.type == FILTER_CHAR)
+ free(arg->value.str);
+ break;
+
case FILTER_ARG_OP:
free_arg(arg->op.left);
free_arg(arg->op.right);
--
1.7.3.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 6/10] bug.h: Replace __linktime_error with __compiletime_error
Signed-off-by: Daniel Santos
---
include/linux/bug.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/bug.h b/include/linux/bug.h
index aaac4bb..298a916 100644
--- a/include/linux/bug.h
+++ b/include/linux/bug.h
@@ -73,7 +73,7 @@ extern int __build_bug_on_failed;
#define BUILD_BUG()\
do {\
extern void __build_bug_failed(void)\
- __linktime_error("BUILD_BUG failed"); \
+ __compiletime_error("BUILD_BUG failed");\
__build_bug_failed(); \
} while (0)
--
1.7.3.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 1/10] compiler-gcc4.h: correct verion check for __compiletime_error
NOTE: this is has already been comitted to -mm __attribute__((error(msg))) was introduced in gcc 4.3 (not 4.4) and as I was unable to find any gcc bugs pertaining to it, I'm presuming that it has functioned as advertised since 4.3.0. Signed-off-by: Daniel Santos Cc: Michal Marek Signed-off-by: Andrew Morton --- include/linux/compiler-gcc4.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h index 997fd8a..8721704 100644 --- a/include/linux/compiler-gcc4.h +++ b/include/linux/compiler-gcc4.h @@ -59,7 +59,7 @@ #if __GNUC_MINOR__ > 0 #define __compiletime_object_size(obj) __builtin_object_size(obj, 0) #endif -#if __GNUC_MINOR__ >= 4 && !defined(__CHECKER__) +#if __GNUC_MINOR__ >= 3 && !defined(__CHECKER__) #define __compiletime_warning(message) __attribute__((warning(message))) #define __compiletime_error(message) __attribute__((error(message))) #endif -- 1.7.3.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 v1 1/7] DA9055 MFD core driver
Hi Jangam, On Fri, Sep 14, 2012 at 06:54:50PM +0530, Ashish Jangam wrote: > This is the DA9055 MFD core driver that instantiate all the dependent > component > drivers and provides them the device access via I2C. > > This patch is functionally tested on Samsung SMDK6410. > > Signed-off-by: David Dajun Chen > Signed-off-by: Ashish Jangam > --- > drivers/mfd/Kconfig | 17 + > drivers/mfd/Makefile |3 + > drivers/mfd/da9055-core.c| 423 +++ > drivers/mfd/da9055-i2c.c | 93 + > include/linux/mfd/da9055/core.h | 94 + > include/linux/mfd/da9055/pdata.h | 32 ++ > include/linux/mfd/da9055/reg.h | 699 > ++ > 7 files changed, 1361 insertions(+), 0 deletions(-) > create mode 100644 drivers/mfd/da9055-core.c > create mode 100644 drivers/mfd/da9055-i2c.c > create mode 100644 include/linux/mfd/da9055/core.h > create mode 100644 include/linux/mfd/da9055/pdata.h > create mode 100644 include/linux/mfd/da9055/reg.h Looks good to me, patch applied. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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 0/10] Cleanup & new features for compiler*.h and bug.h
This patch set is a dependency of the generic red-black tree patch set, which I have now split up into three smaller sets. The major aim of this patch set is to cleanup compiler-gcc*.h and improve the manageability of of compiler features at various versions (when they are broken, etc.), and to add some needed features to bug.h (again, that are compiler-version-dependent). compiler-gcc*.h o Introduce GCC_VERSION - (e.g., gcc 4.7.1 becomes 40701) o Reorder all features based upon the version introduced (readability) o Change all version checks to use GCC_VERSION o Remove redundant __linktime_error o Introduce __flatten function attribute bug.h o Improve BUILD_BUG_ON(expr) - now generates compile-time error post-gcc-4.4 o Introduce BUILD_BUG_ON_NON_CONST(expr) macro, which simply wraps __builtin_constant_p and BUILD_BUG_ON o Documented (in BUILD_BUG_ON_NON_CONST doc-comments) the extensive discrepancies in the behavior of __builtin_constant_p throughout versions of gcc. o Introduce BUILD_BUG_ON_NON_CONST42 macro for compile-time-constant checks that are doomed to fail in older versions of gcc. -- 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 12/16] iommu/amd: Add initialization routines for AMD interrupt remapping
Joerg,
On Fri, Sep 28, 2012 at 6:24 AM, Joerg Roedel wrote:
> Add the six routines required to setup interrupt remapping
> with the AMD IOMMU. Also put it all together into the AMD
> specific irq_remap_ops.
>
> Signed-off-by: Joerg Roedel
> ---
> drivers/iommu/amd_iommu.c | 16 +++
> drivers/iommu/amd_iommu_init.c | 42
> +++
> drivers/iommu/amd_iommu_proto.h |8
> drivers/iommu/irq_remapping.h |1 +
> 4 files changed, 67 insertions(+)
>
> diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
> index af245f4..6fe4ad7 100644
> --- a/drivers/iommu/amd_iommu.c
> +++ b/drivers/iommu/amd_iommu.c
> @@ -45,6 +45,7 @@
>
> #include "amd_iommu_proto.h"
> #include "amd_iommu_types.h"
> +#include "irq_remapping.h"
>
> #define CMD_SET_TYPE(cmd, t) ((cmd)->data[1] |= ((t) << 28))
>
> @@ -4226,4 +4227,19 @@ static int setup_hpet_msi(unsigned int irq, unsigned
> int id)
> return 0;
> }
>
> +struct irq_remap_ops amd_iommu_irq_ops = {
> + .supported = amd_iommu_supported,
> + .prepare= amd_iommu_prepare,
> + .enable = amd_iommu_enable,
> + .disable= amd_iommu_disable,
> + .reenable = amd_iommu_reenable,
> + .enable_faulting= amd_iommu_enable_faulting,
> + .setup_ioapic_entry = setup_ioapic_entry,
> + .set_affinity = set_affinity,
> + .free_irq = free_irq,
> + .compose_msi_msg= compose_msi_msg,
> + .msi_alloc_irq = msi_alloc_irq,
> + .msi_setup_irq = msi_setup_irq,
> + .setup_hpet_msi = setup_hpet_msi,
> +};
> #endif
> diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
> index 202b2b7..42db810 100644
> --- a/drivers/iommu/amd_iommu_init.c
> +++ b/drivers/iommu/amd_iommu_init.c
> @@ -34,6 +34,7 @@
> #include
> #include
> #include
> +#include
>
> #include "amd_iommu_proto.h"
> #include "amd_iommu_types.h"
> @@ -1894,7 +1895,48 @@ static int __init iommu_go_to_state(enum
> iommu_init_state state)
> return ret;
> }
>
> +#ifdef CONFIG_IRQ_REMAP
> +int __init amd_iommu_prepare(void)
> +{
> + return iommu_go_to_state(IOMMU_ACPI_FINISHED);
> +}
> +
> +int __init amd_iommu_supported(void)
> +{
> + return amd_iommu_irq_remap ? 1 : 0;
> +}
> +
> +int __init amd_iommu_enable(void)
> +{
> + int ret;
> +
> + ret = iommu_go_to_state(IOMMU_ENABLED);
> + if (ret)
> + return ret;
>
> + irq_remapping_enabled = 1;
> +
> + return 0;
> +}
> +
> +void amd_iommu_disable(void)
> +{
> + amd_iommu_suspend();
Is it safe to attempt to suspend when iommu is in suspend state? In
other words what happens if amd_iommu_disable() gets called when iommu
is already in suspend state?
> +}
> +
> +int amd_iommu_reenable(int mode)
> +{
> + amd_iommu_resume();
Same question as above. Safe to do a resume, when in resumed state?
> +
> + return 0;
> +}
> +
> +int __init amd_iommu_enable_faulting(void)
> +{
> + /* We enable MSI later when PCI is initialized */
> + return 0;
> +}
> +#endif
>
> /*
> * This is the core init function for AMD IOMMU hardware in the system.
> diff --git a/drivers/iommu/amd_iommu_proto.h b/drivers/iommu/amd_iommu_proto.h
> index 1a7f41c..c294961 100644
> --- a/drivers/iommu/amd_iommu_proto.h
> +++ b/drivers/iommu/amd_iommu_proto.h
> @@ -32,6 +32,14 @@ extern void amd_iommu_uninit_devices(void);
> extern void amd_iommu_init_notifier(void);
> extern void amd_iommu_init_api(void);
>
> +/* Needed for interrupt remapping */
> +extern int amd_iommu_supported(void);
> +extern int amd_iommu_prepare(void);
> +extern int amd_iommu_enable(void);
> +extern void amd_iommu_disable(void);
> +extern int amd_iommu_reenable(int);
> +extern int amd_iommu_enable_faulting(void);
> +
> /* IOMMUv2 specific functions */
> struct iommu_domain;
>
> diff --git a/drivers/iommu/irq_remapping.h b/drivers/iommu/irq_remapping.h
> index 624d360..95363ac 100644
> --- a/drivers/iommu/irq_remapping.h
> +++ b/drivers/iommu/irq_remapping.h
> @@ -82,6 +82,7 @@ struct irq_remap_ops {
> };
>
> extern struct irq_remap_ops intel_irq_remap_ops;
> +extern struct irq_remap_ops amd_iommu_irq_ops;
>
> #else /* CONFIG_IRQ_REMAP */
>
> --
> 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/
--
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] slab: Ignore internal flags in cache creation
On Fri, 28 Sep 2012, Christoph Lameter wrote: > > The first prototype, SLAM XP1, will be posted in October. I'd simply like > > to avoid reverting this patch down the road and having all of us > > reconsider the topic again when clear alternatives exist that, in my > > opinion, make the code cleaner. > > If you want to make changes to the kernel then you need to justify that at > the time when we can consider your patches and the approach taken. > If I cannot speak up and say where there will be conflicts in the future and ask that Glauber spend more of his time down the road to figure all of this out again, especially when a simple and clean alternative exists, then that seems to result in a big waste of time. Nothing is suffering from taking the alternative here, so please follow the best software engineering practices of allowing an implementation to reserve and ignore bits in an API when appropriate and not do it globally in the common code. All of the move to mm/slab_common.c has obviously slowed down posting of SLAM and I haven't complained about that once or asked that it not be done, I'm simply pointing out an instance here that will conflict later on if we go with this patch. That, to me, is respectful of other people's time. That said, I'll leave it to Glauber to decide how he'd like to handle this issue given the knowledge of what is to come. 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 03/16] iommu/amd: Allocate data structures to keep track of irq remapping tables
On Fri, Sep 28, 2012 at 6:23 AM, Joerg Roedel wrote:
> To easily map device ids to interrupt remapping table
> entries a new lookup table is necessary.
>
> Signed-off-by: Joerg Roedel
> ---
> drivers/iommu/amd_iommu_init.c | 16
> drivers/iommu/amd_iommu_types.h |9 +
> 2 files changed, 25 insertions(+)
>
> diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
> index a046a0e..db100c5 100644
> --- a/drivers/iommu/amd_iommu_init.c
> +++ b/drivers/iommu/amd_iommu_init.c
> @@ -181,6 +181,12 @@ u16 *amd_iommu_alias_table;
> struct amd_iommu **amd_iommu_rlookup_table;
>
> /*
> + * This table is used to find the irq remapping table for a given device id
> + * quickly.
> + */
> +struct irq_remap_table **irq_lookup_table;
> +
> +/*
> * AMD IOMMU allows up to 2^16 differend protection
different
domains. This is a bitmap
> * to know which ones are already in use.
> */
> @@ -1529,9 +1535,13 @@ static struct syscore_ops amd_iommu_syscore_ops = {
>
> static void __init free_on_init_error(void)
> {
> + free_pages((unsigned long)irq_lookup_table,
> + get_order(rlookup_table_size));
> +
> if (amd_iommu_irq_cache) {
> kmem_cache_destroy(amd_iommu_irq_cache);
> amd_iommu_irq_cache = NULL;
> +
> }
>
> amd_iommu_uninit_devices();
> @@ -1684,6 +1694,12 @@ static int __init early_amd_iommu_init(void)
> 0, NULL);
> if (!amd_iommu_irq_cache)
> goto out;
> +
> + irq_lookup_table = (void *)__get_free_pages(
> + GFP_KERNEL | __GFP_ZERO,
> + get_order(rlookup_table_size));
> + if (!irq_lookup_table)
> + goto out;
> }
>
> ret = init_memory_definitions(ivrs_base);
> diff --git a/drivers/iommu/amd_iommu_types.h b/drivers/iommu/amd_iommu_types.h
> index 953cea8..1a7d480 100644
> --- a/drivers/iommu/amd_iommu_types.h
> +++ b/drivers/iommu/amd_iommu_types.h
> @@ -175,6 +175,7 @@
> #define DEV_ENTRY_EX0x67
> #define DEV_ENTRY_SYSMGT1 0x68
> #define DEV_ENTRY_SYSMGT2 0x69
> +#define DEV_ENTRY_IRQ_TBL_EN 0x80
> #define DEV_ENTRY_INIT_PASS 0xb8
> #define DEV_ENTRY_EINT_PASS 0xb9
> #define DEV_ENTRY_NMI_PASS 0xba
> @@ -337,6 +338,14 @@ extern bool amd_iommu_iotlb_sup;
> #define MAX_IRQS_PER_TABLE 256
> #define IRQ_TABLE_ALIGNMENT128
>
> +struct irq_remap_table {
> + spinlock_t lock;
> + unsigned min_index;
> + u32 *table;
> +};
> +
> +extern struct irq_remap_table **irq_lookup_table;
> +
> /* Interrupt remapping feature used? */
> extern bool amd_iommu_irq_remap;
>
> --
> 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/
--
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: [ 094/127] md: make sure metadata is updated when spares are activated or removed.
On Fri, 2012-09-28 at 13:34 -0700, Greg Kroah-Hartman wrote: > 3.0-stable review patch. If anyone has any objections, please let me know. > > -- > > From: NeilBrown > > commit 6dafab6b1383e912cd252fa809570b484eb6e0dc upstream. [...] > This is suitable for -stable as out-of-data metadata could lead > to data corruption. > This is only relevant for 3.3 and later 9when 'replacement' as > introduced. [...] Assuming Neil hasn't changed his mind about this, it should therefore not be applied to 3.0. Ben. -- Ben Hutchings Usenet is essentially a HUGE group of people passing notes in class. - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette' signature.asc Description: This is a digitally signed message part
Re: [PATCH v2 0/4] mfd: support dt on 88pm860x
Hi Haojian, On Fri, Sep 21, 2012 at 06:06:50PM +0800, Haojian Zhuang wrote: > Changelog: > v2: > 1. Resolve merge conflict since other patches also update 88pm860x-core.c > 2. Add document of DT support All 4 patches applied, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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: [PATCH] mfd: tps65910: Add alarm interrupt of TPS65910 RTC to mfd device list
Hi Venu, On Fri, Sep 21, 2012 at 04:25:36PM +0530, Venu Byravarasu wrote: > Add RTC alarm interrupt details to TPS65910 MFD device list, to support > RTC alarm events. > > Signed-off-by: Venu Byravarasu > --- > drivers/mfd/tps65910.c | 10 ++ > 1 files changed, 10 insertions(+), 0 deletions(-) Applied, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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: [PATCH 1/4] memory-hotplug: add memory_block_release
> It is not correct. The kobject_put() is prepared against find_memory_block() > in remove_memory_block() since kobject->kref is incremented in it. > So release_memory_block() is called by device_unregister() correctly as > follows: Ok. Looks good then. Please rewrite the description more kindly at next spin. Current one is really really bad. -- 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: [ 056/127] Bluetooth: Fix not removing power_off delayed work
On Fri, Sep 28, 2012 at 07:19:27PM -0300, Gustavo Padovan wrote:
> * Ben Hutchings [2012-09-29 00:13:03 +0200]:
>
> > On Fri, 2012-09-28 at 13:33 -0700, Greg Kroah-Hartman wrote:
> > > 3.0-stable review patch. If anyone has any objections, please let me
> > > know.
> > >
> > > --
> > >
> > > From: Vinicius Costa Gomes
> > >
> > > commit 78c04c0bf52360dc2f7185e99c8e9aa05d73ae5a upstream.
> > >
> > > For example, when a usb reset is received (I could reproduce it
> > > running something very similar to this[1] in a loop) it could be
> > > that the device is unregistered while the power_off delayed work
> > > is still scheduled to run.
> > [...]
> > > --- a/net/bluetooth/hci_core.c
> > > +++ b/net/bluetooth/hci_core.c
> > > @@ -588,6 +588,8 @@ static int hci_dev_do_close(struct hci_d
> > > {
> > > BT_DBG("%s %p", hdev->name, hdev);
> > >
> > > + cancel_delayed_work(>power_off);
> > [...]
> >
> > This is not right for 3.0 as the type of hdev->power_off is struct
> > work_struct, not struct delayed_work.
> >
> > When I looked at this for 3.2 it appeared that this fix might not be
> > required at all.
>
> Yes, at that time we had a timer to run the work, at some point we changed it
> with a delayed_work but I don't remember exactly which version was it, 3.3 I
> think.
Thanks for letting me know, I'll go delete this from the 3.0 queue.
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 2/3] slub, hotplug: ignore unrelated node's hot-adding and hot-removing
On Fri, Sep 28, 2012 at 3:19 AM, Lai Jiangshan wrote: > HI, Christoph, KOSAKI > > SLAB always allocates kmem_list3 for all nodes(N_HIGH_MEMORY), also node > bug/bad things happens. > SLUB always requires kmem_cache_node on the correct node, so these fix is > needed. > > SLAB uses for_each_online_node() to travel nodes and do maintain, > and it tolerates kmem_list3 on alien nodes. > SLUB uses for_each_node_state(node, N_NORMAL_MEMORY) to travel nodes and do > maintain, > and it does not tolerate kmem_cache_node on alien nodes. > > Maybe we need to change SLAB future and let it use > for_each_node_state(node, N_NORMAL_MEMORY), But I don't want to change SLAB > until I find something bad in SLAB. SLAB can't use highmem. then traverse zones which don't have normal memory is silly IMHO. If this is not bug, current slub behavior is also not bug. Is there any difference? If I understand correctly, current code may waste some additional memory on corner case. but it doesn't make memory leak both when slab and slub. -- 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 v9 PATCH 01/21] memory-hotplug: rename remove_memory() to offline_memory()/offline_pages()
On Thu, Sep 27, 2012 at 11:50 PM, Yasuaki Ishimatsu wrote: > Hi Chen, > > > 2012/09/28 11:22, Ni zhan Chen wrote: >> >> On 09/05/2012 05:25 PM, we...@cn.fujitsu.com wrote: >>> >>> From: Yasuaki Ishimatsu >>> >>> remove_memory() only try to offline pages. It is called in two cases: >>> 1. hot remove a memory device >>> 2. echo offline >/sys/devices/system/memory/memoryXX/state >>> >>> In the 1st case, we should also change memory block's state, and notify >>> the userspace that the memory block's state is changed after offlining >>> pages. >>> >>> So rename remove_memory() to offline_memory()/offline_pages(). And in >>> the 1st case, offline_memory() will be used. The function >>> offline_memory() >>> is not implemented. In the 2nd case, offline_pages() will be used. >> >> >> But this time there is not a function associated with add_memory. > > > To associate with add_memory() later, we renamed it. Then, you introduced bisect breakage. It is definitely unacceptable. NAK. -- 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: iwlwifi can't connect to router after resuming from suspend.
Hey Dan, Thanks for the response. >> Linux cyber-ubuntu 3.2.0-30-generic #48-Ubuntu SMP Fri Aug 24 16:52:48 UTC >> 2012 x86_64 x86_64 x86_64 GNU/Linux > That kernel is too old. Can you test with a 3.5.x kernel (or even > better would be a 3.6-rc kernel). Those are the only ones we look > at on lkml. I did try out Sabayon 10 live disk because it said it uses the kernel 3.5.4 but it did not fix the problem. I will definitely try to figure a way to test the 3.6-rc kernel. Do you know any (experimental?) distros that are using it? Is there anything else that I could do that could help, like rerunning any commands/script on a newer kernel? I eventually plan to purchase a [different wireless card][1] and if it does not work, we will know that the problem is not in the wireless driver/card. I'm betting it will fix it for me but I can't be certain. The bug I'm having may be an ACPI or some power management issue as far as I can tell. I'll still be interested in fixing the issue on my current wireless card if the new card fixes the problem. I'm not sure when this will happen though. [1]: https://www.thinkpenguin.com/gnu-linux/penguin-wireless-n-half-height-mini-pcie-card Thanks, Kevin. -- 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/4] memory-hotplug: add node_device_release
>>> I don't understand it. How can we get rid of the warning? >> >> See cpu_device_release() for example. > > If we implement a function like cpu_device_release(), the warning > disappears. But the comment says in the function "Never copy this way...". > So I think it is illegal way. What does "illegal" mean? You still haven't explain any benefit of your code. If there is zero benefit, just kill it. I believe everybody think so. Again, Which benefit do you have? Why do we need this node_device_release() implementation? >>> >>> I think that this is a manner of releasing object related kobject. >> >> No. Usually we never call memset() from release callback. > > What we want to release is a part of array, not a pointer. > Therefore, there is only this way instead of kfree(). Why? Before your patch, we don't have memset() and did work it. I can't understand what mean "only way". -- 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: [ 056/127] Bluetooth: Fix not removing power_off delayed work
* Ben Hutchings [2012-09-29 00:13:03 +0200]:
> On Fri, 2012-09-28 at 13:33 -0700, Greg Kroah-Hartman wrote:
> > 3.0-stable review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Vinicius Costa Gomes
> >
> > commit 78c04c0bf52360dc2f7185e99c8e9aa05d73ae5a upstream.
> >
> > For example, when a usb reset is received (I could reproduce it
> > running something very similar to this[1] in a loop) it could be
> > that the device is unregistered while the power_off delayed work
> > is still scheduled to run.
> [...]
> > --- a/net/bluetooth/hci_core.c
> > +++ b/net/bluetooth/hci_core.c
> > @@ -588,6 +588,8 @@ static int hci_dev_do_close(struct hci_d
> > {
> > BT_DBG("%s %p", hdev->name, hdev);
> >
> > + cancel_delayed_work(>power_off);
> [...]
>
> This is not right for 3.0 as the type of hdev->power_off is struct
> work_struct, not struct delayed_work.
>
> When I looked at this for 3.2 it appeared that this fix might not be
> required at all.
Yes, at that time we had a timer to run the work, at some point we changed it
with a delayed_work but I don't remember exactly which version was it, 3.3 I
think.
Gustavo
--
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/
